Support optionally-exposed modules

This is a mechanism to eliminate the appeal of defining orphan instances
in Haskell packages.
The problem: If I define a new type class for which instances may be
defined for types defined in other packages, I must either depend on
those packages or ask that those packages' authors depend on my
package.
The solution: Allow a library author to identify individual modules that
should only be built if a necessary dependency is included in a build in
which the library is involved.
Details:
A new optionally-exposed section of a library stanza supports the
specification of potentially exposed modules and their dependencies. The
inclusion of these modules and dependencies in the generated Cabal file
depends upon the availability of a build plan.
A build plan in this context is simply a list of package names and
versions as output by, for example, stack list-dependencies.
If no build plan is supplied, then all "optionally-exposed" modules are
exposed, and their dependencies must be available.
If a build plan is supplied, then only those "optionally-exposed"
modules whose dependencies are satisfied by the build plan are included
in the Cabal file generated for the package.
Usage by build tools:
A tool like stack can invoke hpack --buildplan min for each listed
dependency when computing an initial build plan. Then it can call
hpack for each package again, this time passing the name of a file
containing the computed build plan. This second round will not add any
new packages to the build plan, but may add dependencies to the
individual packages included in the build plan.
Usage by library authors:
If you wish to provide an instance for, say, Data.Text.Text, but do
not otherwise use the text package, place the instance definition in
its own module, say, src/Foo/Text.hs. Then add an
optionally-exposed section to the library definition so it looks
something like this,
library:
  source-dirs: src
  optionally-exposed:
    dependencies: text > 1.2
    modules: Foo.Text

Now, if somebody uses your library without themselves depending on
text, they may do so without incurring a dependency on text. If they
do depend on text, then they will have access to the instance you
defined.

Ping @mgsloan
This is something a bit out of left field, but I wanted to see if it actually works, and it seems like it does. There may be issues with the overall design, so it needs some thought.
For a quick overview, check out the spec

Awesome!
Maybe "conditionally-exposed" instead of optionally?

I'm open to that. I avoided the word "conditional" since it is a distinct hpack concept.

"expose-if", "expose-when" or "try-exposing"?
On Wed, Jul 6, 2016, 21:59 Anthony Cowley<EMAIL_ADDRESS>wrote:

I'm open to that. I avoided the word "conditional" since it is a distinct
hpack concept.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/sol/hpack/pull/112#issuecomment-230871045, or mute
the thread
https://github.com/notifications/unsubscribe/AAC_A-cpj0-bPEpr3yrgQI4t0Y8DuMLIks5qS_sAgaJpZM4JF2Vq
.

expose-with since it's about sets/pairs of packages?

@acowley This looks very interesting, but it does raise a few questions on the design.
Caveat: I've gotten here from Twitter, skimmed the TODO and looked at hpack's slides, but I probably still don't understand the full workflow, both currently and in your proposal, especially regarding hpack packages depending on other hpack packages.
I also now think the closest thing to a design document might be the discussion on Reddit, though I haven't yet found all the info I'd like: https://www.reddit.com/r/haskell/comments/4pf86b/cabal_build_variants/d4kqfgi

I suspect some of the issues would be addressed (technically speaking) inside Cabal if Cabal had a flag variant with different solver behavior (in principle, the two-step process you describe). Changing Cabal would certainly take longer, but if you don't change cabal it seems you need to change Hackage for a complete solution or use hacks (see point 2).
Nowadays hpack seems to produce one fixed cabal file that can be used for uploading to Hackage (sensei even commits the generated file to the source repo). Your proposal changes that, so I'm not sure how to upload a conditional package to Hackage — do we add the package.yaml and hack tools to ignore the cabal file and actually use package.yaml? Or do we extend the whole pipeline to support hpack without hacks? Cabal flags would address that.
What happens, in your scenario, if I later add text and need it and the "glue code" (src/Foo/Text.hs) together with your library in the same repository/sandbox? I imagine you either cannot, or that package names must be mangled. Cabal flags would address that.

@Blaisorblade This is intended to be used by stack which knows how to generate cabal files using hpack; this addresses your first two points, I think. For the third, if you change the hpack file, a new cabal file is automatically generated, and it would be different from the one in whatever cache is being used so would trigger invalidation.

Ah, didn't know about the hpack support in stack, and the plans (mentioned in https://github.com/commercialhaskell/stack/pull/1773) to add hpack support to Hackage!

For the third, if you change the hpack file, a new cabal file is automatically generated, and it would be different from the one in whatever cache is being used so would trigger invalidation.

Oh I see — invalidation would then rebuild the affected package and the packages depending on it, guaranteeing correctness. I can imagine that implementing invalidation for this scenario is tricky in some cases (especially invalidating a global package used in local snapshots), but I'll just trust stack to get this right.

Ah, didn't know about the hpack support in stack, and the plans (mentioned in commercialhaskell/stack#1773) to add hpack support to Hackage!

I think you're misreading the comments in commercialhaskell/stack#1773. I believe the comments regarding Hackage are only about publishing a new version of hpack to Hackage, not about changing Hackage.

@sjakobi Thanks!
Having a default cabal file on Hackage seems a bit hacky and makes me uneasy. OTOH it guarantees support for other existing tools; and since it's generated without a build plan (I assume) and because of what this PR does in that scenario, it keeps the current behavior of including all dependencies and all code, which is fine for backward-compatibility.
I'm coming to like this design more and more.

Re: interaction with Cabal, historically changing a library's API based on which flags are enabled has been frowned upon. Quoting @dcoutts:

The reason for this is that if this were allowed (and it were used) then it would become impossible to translate cabal packages into binary packages for systems like debian / fedora etc. Many people felt, and still feel that being able to translate into binary package systems is an important feature, and thus this restriction remains.

OTOH, as @ezyang points out in that discussion, it may make sense to allow using flags to expose extra functionality. After all, a lot of software that comes with Debian can be configured in this way (example).

OTOH, as @ezyang points out in that discussion, it may make sense to allow using flags to expose extra functionality. After all, a lot of software that comes with Debian can be configured in this way (example).

@23Skidoo That's correct. Critically, in our scenario we're only subsetting the API, not having incompatible variants, so a distributor can always just add all dependencies if he wants to be safe, he just gets extra options by just omitting packages you don't want. Apparently some distributions already disable some optional dependencies by abusing flags, and @kmett had to add such flags to avoid worse.
Also, in the current vision, adding a package would automatically add the needed instances —
https://github.com/sol/hpack/pull/112#issuecomment-231079444. (Not sure how exactly it works and whether it would be plausible with cabal-install).
Turns out we're discussing pretty much what @ezyang mentions here, though he seems to propose a different approach:

I've recently come around to the idea that maybe we should use flags to expose extra functionality (like instances, optional bonuses when people have more dependencies). This would help package authors address a very big issue, which is "how many dependencies should I put in the core package, as opposed to split out into separate packages." The issue is even more keenly felt when orphans are involved.
[...]

I have a bias against this sort of compile-time Cabal file rewriting, but let me try to comment on this proposal on its merits.
The downside of using this feature is that it interferes with Stack's ability to cache packages across workspaces. Packages that have optional dependencies must be built "in place" in the same way you would build vendored packages with local modifications. This thwarts normal mechanisms for sharing, and for packages which are deep in the dependency tree, this could be very painful—like, cabal sandbox levels of painful!
Of course, the way you fix this is make it so that there is some way to uniquely identify each of these separate Cabal files; in my proposal, the flag selection would identify this (no need to rewrite the Cabal file)—alternately, if you don't want to wait for Cabal to take whatever changes necessary to handle this, you could ask Stack to hash the Cabal file and cache accordingly.
I have a slight suggestion for the Cabal file that would be uploaded to Hackage: instead of uploading a Cabal file which has all or none of the optional dependencies enabled, how about putting all of the optional dependencies within flag conditionals with a special field, e.g.,
flag text-instances
  if-building: text

(You can bikeshed if-building to whatever you want.) cabal-install's solver today will default the flags to true (which is what you want), but in the future the solver could be extended to understand these types of flags and turn them off when they are not needed by the build-plan.
P.S. There is one other minor difficulty with this proposal, which is that is that it can only ever support adding the optional section if ALL of the dependencies are satisfied. In particular, you can't say, "If p is in the build-plan, then I want to generate a Cabal file with an extra dependency q." Then you are going to have to ping-pong with Stack, where Stack says "here's my build plan" and hpack says "oh wait, here is an extra dependency I need now" and then Stack says "here's my build plan"... and so forth. But I can't think of a situation where you'd actually want this.

The downside of using this feature is that it interferes with Stack's ability to cache packages across workspaces. Packages that have optional dependencies must be built "in place" in the same way you would build vendored packages with local modifications.

I also wondered. I think @acowley might have implied otherwise in https://github.com/sol/hpack/pull/112#issuecomment-231079444, but I'm not 100% sure how that would work and I might be misunderstanding him; IIUC not the whole vision is implemented. Also, I'd guess even in the best case lots of pain is involved, even if packages are not built in place.
Which is why I had argued using flags could work better; your idea of generating cabal files with flags appears nice.
I wrote:

What happens, in your scenario, if I later add text and need it and the "glue code" (src/Foo/Text.hs) together with your library in the same repository/sandbox? I imagine you either cannot, or that package names must be mangled. Cabal flags would address that.

@acowley answered:

if you change the hpack file, a new cabal file is automatically generated, and it would be different from the one in whatever cache is being used so would trigger invalidation.

Let me refine my scenario, because I'm not sure I understood your answer, and if @ezyang imagines right I'm concerned.
Say my hpack-developed package depend on foo, which is also developed with hpack, and foo has optional instances for text. Now say my package does not depend on text, then it is built, then I add a dependency on text. It's clear that the cabal file for my package gets invalidated. But what happens with text? Do we need to add dependency tracking to regenerate all cabal files for all packages with optional dependencies on text? Do we invalidate foo even if it's deep in the dependency chain? Do we eagerly or lazily invalidate and rebuild all dependencies? Can foo be shared across workspaces? Do we eagerly invalidate packages in other workspaces? (Answer to the last one: I'd say certainly not, we can do that when using those other workspaces).
The same questions apply to using flags, but with flags I can imagine more easily foo[-text-glue-code] and foo[+text-glue-code] (that is, foo with or without the text-glue-code flag) coexisting. Still, at best we get a lazy invalidation of sorts.
I'm not using text-instances as name because glue code might be more than instances I'd expect. I don't want to bikeshed the name, but point out that "only instances" is nowhere actually written down or enforced, and not sure it's needed—this might warrant discussion.

The details of stack support is out of scope for this PR. It amounts to an easier problem than dealing with multiple flag assignments for the same package since the differences are apparent in concrete cabal files. No new "serialization of settings" format need be invented.
The ping-pong criticism is not possible with this proposal, but may fall into the pre-existing biases bucket. I don't know.

The details of stack support is out of scope for this PR

I'm discussing those details because those details might affect the design of this PR.
But we can indeed defer that, because I realized the "worst-case redesign" is not a problem — if you're curious or @ezyang, see below for why. So 👍 from me on that front. I still guess generating flags by default as @ezyang proposes won't hurt (except maybe warnings), but anybody interested can always change that later somewhat transparently.
Worst-case redesign
Even if

this PR is merged as-is
people start using the new hpack features
later one decides to change design and generate Cabal flags to solve specially (whoever solves these flags)

there's no problem, since one can keep the same hpack syntax.
At worst, Cabal might gain the same feature on its own, making hpack's use arguably somewhat redundant (and not really, since it would still have to expose the feature somehow). But that will take quite a while, if it ever happens, so this shouldn't be an argument against this PR.

@Blaisorblade You're absolutely right, I'm sure there is room for improvement, but my intention is that if you can use this feature manually immediately, which you can, then we don't need to couple hpack to stack too tightly.
The simplest support would be for stack to simply install the package in a local overlay as with any ad hoc patching scenario. More complex support has a variety of prior art to lean on, but there are so many degrees of freedom there that I'd rather the stack developers pick a solution they like than have it nailed down a priori by the package description format.

Closing for lack of interest.

The problem: If I define a new type class for which instances may be
defined for types defined in other packages, I must either depend on
those packages or ask that those packages' authors depend on my
package.

The solution: Allow a library author to identify individual modules that
should only be built if a necessary dependency is included in a build in
which the library is involved.

I'm interested in this, but I can't understand how this solves the orphan instance problem. Unless I'm confused, in your case, for your instances not to be orphans they'll have to be defined in the module which defines the class. In all cases where this has been a problem for me, I want the class to be almost available (for example, for instances against types in base) but I only want to compile instances against other packages if they're needed.
As the class and all the instances need to be in the same file to avoid orphans, what seems to be required is flags passed to the preprocessor to optionally include/exclude the instances based on the available dependencies. Optionally including/excluding modules is not useful because everything has to be one one module anyway to avoid orphans.
Have I got this right or am I completely confused?

Hi @clintonmead, I'm glad you're interested!
There had been talk of re-casting orphans as instances defined outside of the package that defines the type or class. Such a change has its own appeal as it gives the package author a bit more freedom in code organization to avoid mega-modules. Without such a change, one would have to accept an orphan instance warning and use the proposed module-based selective package inclusion scheme implemented here, or make use of preprocessor flags as you describe.
Something I like about making it module-based is that the exports, or public API, of a particular module do not change based on the build environment.

Good point, it doesn't seem you're missing anything. I've seen packages
(IIRC, text) that declare orphans that are "in the wrong module but the
right package" (as this patch would support), but they're still orphans it
seems—it is hard to export them so that they are always imported together
with the typeclass.
Using flags has additional downsides though, because you're supposed to use
such preprocessor flags in a very disciplined way (only add material if an
extra library is present) which isn't compiler-checked.
While most of the discussion applies to the fixed variant you propose, it's
not clear how to avoid your conclusion (or are there tests to the
contrary?). But the problem you point out can be fixed... All other issues
discussed seem bigger problems. Maybe we should accept them, but it seems
things haven't changed.
I've also double-checked lens (the package most in need of this system). It
does have a bunch of "optional modules" like Data.Array.Lens or such, but
those contain lenses, not instances; the instances live together with their
classes:
https://hackage.haskell.org/package/lens-4.15.2/docs/src/Control.Lens.Each.html#line-218
On Jun 5, 2017 04:18, "Clinton Mead"<EMAIL_ADDRESS>wrote:

The problem: If I define a new type class for which instances may be
defined for types defined in other packages, I must either depend on
those packages or ask that those packages' authors depend on my
package.
The solution: Allow a library author to identify individual modules that
should only be built if a necessary dependency is included in a build in
which the library is involved.
I'm interested in this, but I can't understand how this solves the orphan
instance problem. Unless I'm confused, in your case, for your instances not
to be orphans they'll have to be defined in the module which defines the
class. In all cases where this has been a problem for me, I want the class
to be almost available (for example, for instances against types in base)
but I only want to compile instances against other packages if they're
needed.
As the class and all the instances need to be in the same file to avoid
orphans, what seems to be required is flags passed to the preprocessor to
optionally include/exclude the instances based on the available
dependencies. Optionally including/excluding modules is not useful because
everything has to be one one module anyway to avoid orphans.
Have I got this right or am I completely confused?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sol/hpack/pull/112#issuecomment-306087665, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AARsqMPHGsRvoBzoEb0qF3I_nNAvXHvDks5sA2VXgaJpZM4JF2Vq
.

Whoops, sorry for the late answer! Hopefully some bits are still useful.
But @acowley do you have a link to the proposal you mention? It makes a lot
of sense, but preserving coherence seems to require some extra
whole-package checks.
On Jun 5, 2017 05:13, "Paolo Giarrusso"<EMAIL_ADDRESS>wrote:
Good point, it doesn't seem you're missing anything. I've seen packages
(IIRC, text) that declare orphans that are "in the wrong module but the
right package" (as this patch would support), but they're still orphans it
seems—it is hard to export them so that they are always imported together
with the typeclass.
Using flags has additional downsides though, because you're supposed to use
such preprocessor flags in a very disciplined way (only add material if an
extra library is present) which isn't compiler-checked.
While most of the discussion applies to the fixed variant you propose, it's
not clear how to avoid your conclusion (or are there tests to the
contrary?). But the problem you point out can be fixed... All other issues
discussed seem bigger problems. Maybe we should accept them, but it seems
things haven't changed.
I've also double-checked lens (the package most in need of this system). It
does have a bunch of "optional modules" like Data.Array.Lens or such, but
those contain lenses, not instances; the instances live together with their
classes:
https://hackage.haskell.org/package/lens-4.15.2/docs/src/
Control.Lens.Each.html#line-218
On Jun 5, 2017 04:18, "Clinton Mead"<EMAIL_ADDRESS>wrote:

The problem: If I define a new type class for which instances may be
defined for types defined in other packages, I must either depend on
those packages or ask that those packages' authors depend on my
package.
The solution: Allow a library author to identify individual modules that
should only be built if a necessary dependency is included in a build in
which the library is involved.
I'm interested in this, but I can't understand how this solves the orphan
instance problem. Unless I'm confused, in your case, for your instances not
to be orphans they'll have to be defined in the module which defines the
class. In all cases where this has been a problem for me, I want the class
to be almost available (for example, for instances against types in base)
but I only want to compile instances against other packages if they're
needed.
As the class and all the instances need to be in the same file to avoid
orphans, what seems to be required is flags passed to the preprocessor to
optionally include/exclude the instances based on the available
dependencies. Optionally including/excluding modules is not useful because
everything has to be one one module anyway to avoid orphans.
Have I got this right or am I completely confused?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sol/hpack/pull/112#issuecomment-306087665, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AARsqMPHGsRvoBzoEb0qF3I_nNAvXHvDks5sA2VXgaJpZM4JF2Vq
.

I ran into this thread as I've been facing a similar problem myself on a number of occasions. I've got a proposal of my own, but not knowing the details of cabal I'm not sure how well it would work.

Allow "fake" package names with underscores (these are currently forbidden)
The package name "package-name_feature1_feature2" to means "package-name" with "feature1" and "feature2" passed as flags.
Note that if the flags are not in alphabetical order, they are sorted, so "package-name_feature2_feature1" actually refers to "package-name_feature1_feature2".

These means that there will be separate unique packages created for different "features", which are just created by passing different flags.
During dependency search, cabal replaces all dependencies on "package-name" to "package-name_feature-1_feature-2_..._feature-n" with this being the union of all features requested.
Cabal will then compile this "package" and naturally recompile all packages which now depend on it.
As a result, package authors can then use "if" to define different dependencies based on flags, and preprocessor directives to define different code.
As these "feature" packages are completely independent of each other to cabal (they're just downloaded from the same source) there should be no issues with caching etc messing things up.
Whilst I don't think this is a perfect solution (you can get a lot of recompilation if you're often changing your flags) I think it is the simplest and cleanest.
Note the underscore format is not required, just a unique generated package name, and how this is represented in the cabal file something which is open to change. Perhaps a separate "features" section would be better.
Do people think this is a somewhat sensible approach?

Munging package names in this way would work, and it is in fact how we implemented internal libraries (coming in Cabal 2.0) in a backwards compatible way. The downside is that these generated names will get displayed in funny ways by downstream tools like GHC.


go install github.com/xo/usql@latest   does not work anymore because of replace in go.mod

go install github.com/xo/usql@latest
go: github.com/xo/usql@latest (in github.com/xo/usql@v0.14.0):
        The go.mod file for the module providing named packages contains one or
        more replace directives. It must not contain directives that would cause
        it to be interpreted differently than if it were the main module.

replace github.com/google/flatbuffers => github.com/google/flatbuffers v0.0.0-20230110200425-62e4d2e5b215

In the meantime for folks trying to install usql:
 go install<EMAIL_ADDRESS>

@akhenakh I am aware this is broken currently. The issue is that there are quite a number of drivers that use this package, which has general build conflicts from Go modules currently. I'm not aware of a way to fix this at the moment. I'd suggest, temporarily, either installing a binary release, or checking out the code via git clone and installing from the source tree.

This is discussed here: https://github.com/golang/go/issues/44840 -- I'm not really able to maintain soft forks of the (I think?) 5 drivers that this hits. There are a number of untenable options: move all the affected drivers into the bad group, which means they won't be available to build, as there are other drivers that no longer build out of the box, move them to a bad2 group that allows them to build, remove the drivers completely, don't try to get go install working.


Add line swapping

In Atom and Sublime cmdshift↑/cmdshift↓ swap the currently selected line with the line above/below. I find this quite useful and would like to be able to do the same in xi editor.

Working on this atm, should have something by this weekend!


v1.0.0

PR checklist
This is it guys - PR for 1st release 🏁

[x] This comment contains a description of changes (with reason).
[ ] If you've fixed a bug or added code that should be tested, add tests!

[ ] If you've added a new tool - have you followed the pipeline conventions in the contribution docs
[ ] If necessary, also make a PR on the nf-core/bactmap branch on the nf-core/test-datasets repository.

[ ] Make sure your code lints (nf-core lint .).
[ ] Ensure the test suite passes (nextflow run . -profile test,docker).
[ ] Usage Documentation in docs/usage.md is updated.
[ ] Output Documentation in docs/output.md is updated.
[ ] CHANGELOG.md is updated.
[ ] README.md is updated (including new tool citations and authors/contributors).

PS: Don't forget to change the date in the CHANGELOG!


Codegen chokes on imported types

Description
It seems codegen currently chokes on types imported from a different module, i.e. consider this example:
// types.ts
export type MyType = {
  field: string;
};

// NativeReactNativeMyModule.ts
import type { TurboModule } from 'react-native';
import { TurboModuleRegistry } from 'react-native';

import { type MyType } from './types';

export interface Spec extends TurboModule {
  myMethod(arg: MyType): void;
}

export default TurboModuleRegistry.getEnforcing<Spec>('ReactNativeMyModule');

When running the build (for Android on Ubuntu system) the codegen chokes on the method definition saying UnsupportedGenericParserError: Module NativeReactNativeMyModule: Unrecognized generic type 'MyType' in NativeModule spec.
This equivalent code works fine though:
import type { TurboModule } from 'react-native';
import { TurboModuleRegistry } from 'react-native';

export type MyType = {
  field: string;
};

export interface Spec extends TurboModule {
  myMethod(arg: MyType): void;
}

export default TurboModuleRegistry.getEnforcing<Spec>('ReactNativeMyModule');

React Native Version
v0.72.3
Output of npx react-native info
N/A
Steps to reproduce
N/A
Snack, code example, screenshot, or link to a repository
N/A

Yes, that is a currently known limitation of codegen. The (very ugly) workaround is to copy-and-paste the types you need in the module definition.
We are currently working on solving this, so it will be hopefully available soon.
cc. @dmytrorykun


Feature request: allow the command in --bind to open the original stdin

[x] I have read through the manual page (man fzf)
[x] I have the latest version of fzf
[x] I have searched through the existing issues

Info

OS

[x] Linux
[x] Mac OS X
[x] Windows
[x] Etc.

Shell

[x] bash
[x] zsh
[x] fish

Problem / Steps to reproduce
Hi 👋
Following up on #1723 for using fzf as a visualization tool rather than a filter, I'm trying to use fzf to turn jq into an interactive tool.
I'd like to be able to make the command in --bind receive the original stdin that fzf received. So instead of:
FZF_DEFAULT_COMMAND='jq . myfile.json' \
    fzf --disabled --layout=reverse --no-info --bind=enter:print-query \
    --bind='change:reload:jq {q} myfile.json'

I would instead be able to do something like:
cat myfile.json  | \
    fzf --disabled --layout=reverse --no-info --bind=enter:print-query \
    --bind='change:reload-sync:jq {q} <&0'

The latter would allow piping the output of other commands directly to fzf without needing to write the output to a file first.
Not sure if this is stretching the purpose of fzf too far...
EDIT: I'm aware of the tools that make jq interactive, or other tools like fx, jless, jellex, etc. that are also interactive JSON viewers, but using fzf has the benefit of both:

being generic and being able to turn virtually any other tool interactive, and
being powerful and allowing a lot of customization, for example we could switch between the interactive tool filter and fzf's filter.

The standard input is a stream; we can't restart a stream. What fzf can do, is hold the raw input in memory and feed it to its child processes. But of course, that is not equivalent to rerunning the original command, so it may confuse the users.
(date; echo $RANDOM) | fzf

And I don't think fzf having to hold the original raw input in memory just in case the child process may use it can be justified.
Since the suggested feature doesn't solve a problem that can't be circumvented, I'm going to pass on this one, but thanks for the suggestion.


ON and OFF keys are not supported on Unix/IBus

A possible fix: https://github.com/akihikodaki/mozc/commit/f56693f5da2f0f0014e048696045b53923fd6a96

Hi Akihiko,
Thank you for your report.
To understand the issue correctly, would you please describe the following items for the issue?

What the current actual behavior is.
Steps to reproduce the current actual behavior.

Thank you,

^

Hi Akihiko,
Thank you for your report. To understand the issue correctly, would you please describe the following items for the issue?

ON and OFF keys can be set in key binding editor and they can be used to e.g. toggle the conversion state.

* What the current actual behavior is.

Mozc does not respond to ON and OFF keys.

* Steps to reproduce the current actual behavior.

Start ibus_mozc.
Press ON key to find it does not enable conversion. The ON key is present on Macs, some of Microsoft Surfaces and other keyboards.

Thank you,

Let me take time to understand it and make a change.

Here's my understanding of this issue.

ON key is recognized as Hangul, and OFF key is recognized as Hangul_Hanja.

If I understand correctly, I think this is a configuration issue of the keyboard.
Looking at some XKB configuration files (e.g. /usr/share/X11/xkb/symbols in Debian),
expected settings could be configured as follows:
xmodmap -e "keycode 130 = Hiragana_Katakana"
xmodmap -e "keycode 131 = Eisu_toggle"

Having said that, there are two related issues:

Mozc does not recognize Hangul and Hanja keys.
XKB configuration recognizes both keycode 130 (Kana key on macOS) and keycode keycode 208 (Hiragana/Katakana key) as Hiragana_Katakana.

Enabling Mozc to recognize more keys might be a good thing. I will consider it.
XKB configuration is out of focus of this project, but it would be great if it has new keysyms for Ime_on and Ime_off for keycodes 130 and 131.
Thanks,

@hiroyuki-komatsu

Looking at some XKB configuration files (e.g. /usr/share/X11/xkb/symbols in Debian),
expected settings could be configured as follows:
xmodmap -e "keycode 130 = Hiragana_Katakana"
xmodmap -e "keycode 131 = Eisu_toggle"

Hiragana_Katakana key and Eisu_toggle are not semantically equivalent with ON and OFF keys albeit the similarities of their names. As such, it requires handling distinct from those keys everywhere including Mozc. USB HID specification and Mozc are prepared for that by preparing distinct key codes. (Mozc actually already have those key codes for macOS and Windows.)
First, we need to understand there is two distinct states: IME ON/OFF state and input character type. IME ON/OFF state represents whether IME should transform the input. The input character type determines what characters should input: hiragana, katakana, or Latin.
Hiragana_Katakana and Eisu_toggle are to change input character type.
Hiragana_Katakana is used to choose hiragana or katakana as input character type. It is mapped to commands::KeyEvent::KANA or commands::KeyEvent::KATAKANA, depending on the shift state.
Eisu_toggle  is used to choose latin as input character type. Note that IME can be still active even when inputting Latin characters e.g. to use its dictionary.
 It is much more similar to Hankaku_Zenkaku than Hiragana_Katakana and Eisu_toggle. The difference with Hankaku_Zenkaku is that they do not depend on the current IME ON/OFF state and always makes the state ON or OFF while Hankaku_Zenkaku negates the state. They are corresponding to commands::KeyEvent::ON and commands::KeyEvent::OFF.

XKB configuration recognizes both keycode 130 (Kana key on macOS) and keycode keycode 208 (Hiragana/Katakana key) as Hiragana_Katakana.

You meant keycode 131 instead of keycode 208? Anyway, it is not quite a true. Keycode 130 and 131 are mapped to HNGL and HJCV, respectively:
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/72a596dff3405ba9410d81044928400c323a7e83/keycodes/evdev#L160-163
	// Keys that are generated on Korean keyboards

	<HNGL> = 130;	// Hangul Latin toggle
	<HJCV> = 131;	// Hangul to Hanja conversion

HNGL and HJCV generates Hangul and Hangul_Hanja, respectively:
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/72a596dff3405ba9410d81044928400c323a7e83/symbols/inet#L113-114
    key <HNGL>   {      [ Hangul                ]       };
    key <HJCV>   {      [ Hangul_Hanja          ]       };

Here are the files of why I thought Eisu_toggle and Hiragana_Katakana are mapped for Eisu and Kana keys on macOS.

https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/72a596dff3405ba9410d81044928400c323a7e83/keycodes/xfree86#L153-154

    <EISU> =   210;		// Alphanumeric mode on macintosh
    <KANA> =   209;		// Kana mode on macintosh

https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/72a596dff3405ba9410d81044928400c323a7e83/symbols/jp#L87-95

   key <EISU> {
	type[Group1]="PC_ALT_LEVEL2",
	symbols[Group1]= [ Eisu_toggle ]
    };

    key <KANA> {
	type[Group1]="PC_ALT_LEVEL2",
	symbols[Group1]= [ Hiragana_Katakana ]
    };

The keycodes are 209 and 210, but not 130 and 131. So the first point is the gap between the keycodes (209, 210 vs 130, 131).
I agree it is not an ideal mapping. Hiragana_Katakana is also mapped to <HKTG> (keycode 208, Hiragana Katakana toggle key).

https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/72a596dff3405ba9410d81044928400c323a7e83/symbols/jp#L82-85
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/blob/72a596dff3405ba9410d81044928400c323a7e83/keycodes/xfree86#L148

As you mentioned, <HKTG> is usually used to change the input character type, and <KANA> is usually used to turn ON the IME.
So, I mentioned the following as an issue. (correctly speaking the keycode 130 should be 209).

XKB configuration recognizes both keycode 130 (Kana key on macOS) and keycode keycode 208 (Hiragana/Katakana key) as Hiragana_Katakana.

Thus, the second point is the lack of keysyms for Ime_on and Ime_off on the Linux environment. On Windows, they introduced two new virtual keycodes for those keys (VK_IME_ON and OFF).

https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/keyboard-japan-ime

If the Linux environment has distinguishable keycodes for Ime_on and Ime_off like Windows, Mozc would apply them.
Anyway, I'm considering supporting Hangul and Hanja as customizable keys beside ON/OFF keys.

@hiroyuki-komatsu

The keycodes are 209 and 210, but not 130 and 131. So the first point is the gap between the keycodes (209, 210 vs 130, 131).

I guess 209 and 210 actually represent Eisu_toggle and Hiragana_Katakana. The key codes were added in 2006 so we have to look for an old Mac keyboard to understand the intention. I found a picture of an old Mac keyboard which has "カナ/かな" key instead of "かな" as you can find in a recent keyboard:
https://item.rakuten.co.jp/auc-puran/wp1824/?scid=af_pc_etc&sc2id=af_113_0_10001868&iasid=wem_icbs_&icm_agid=135083843412&gclid=CjwKCAjwoduRBhA4EiwACL5RPygueCJk_lI-YvXXrJw2aCjJabVVPa1GSHH9N-6ZZH138b3y7xhG4xoCXlMQAvD_BwE&icm_cid=15280804517&icm_acid=255-776-8501
In this sense, the mappings are probably right. The keys represented by code 209 and 210 are simply different from ones represented by 130 and 131.

If the Linux environment has distinguishable keycodes for Ime_on and Ime_off like Windows, Mozc would apply them.

What is motivation for distinguishable key codes? In fact, macOS shares key codes for those keys.
https://gitlab.com/qemu-project/keycodemapdb/-/commit/8e54850d800e4697a2798fb82ac740e760f8530b
I don't think anything prevents from following the convention of respective platforms (i.e. use distinguishable codes on Windows and use the unified codes on macOS and systems with XKB.)

I guess 209 and 210 actually represent Eisu_toggle and Hiragana_Katakana. The key codes were added in 2006 so we have to look for an old Mac keyboard to understand the intention. I found a picture of an old Mac keyboard which has "カナ/かな" key instead of "かな" as you can find in a recent keyboard:

If I remember correctly, the keys on the sides of the spacebar are always ImeON and ImeOFF on macOS. So the usage on macOS has not been changed.
The following page was written in 2002. It says HID usage IDs of "カナ/かな" and "英数" are 0x90 and 0x91. They are the same numbers as the current ones.
http://www2d.biglobe.ne.jp/~msyk/keyboard/layout/usbkeycode.html
So I think <EISU> and <KANA> were introduced as macOS's ImeOn and ImeOFF keys.

I don't think anything prevents from following the convention of respective platforms (i.e. use distinguishable codes on Windows and use the unified codes on macOS and systems with XKB.)

That is the point. Indeed, I'm wondering what the official convention with XKB is. I'm still not sure if Hangul_hanja and Hangul are official keysyms for ImeON and ImeOFF, or if it's the behavior of the current implementation, since I think <EISU> and <KANA> are keys for ImeOn and ImeOff on macOS.

The following page was written in 2002. It says HID usage IDs of "カナ/かな" and "英数" are 0x90 and 0x91. They are the same numbers as the current ones.
http://www2d.biglobe.ne.jp/~msyk/keyboard/layout/usbkeycode.html
So I think <EISU> and <KANA> were introduced as macOS's ImeOn and ImeOFF keys.

That makes sense. I also found some code of xf86-input-keyboard refers to USB HID usage Lang1 and Lang2.

I don't think anything prevents from following the convention of respective platforms (i.e. use distinguishable codes on Windows and use the unified codes on macOS and systems with XKB.)

That is the point. Indeed, I'm wondering what the official convention with XKB is. I'm still not sure if Hangul_hanja and Hangul are official keysyms for ImeON and ImeOFF, or if it's the behavior of the current implementation, since I think <EISU> and <KANA> are keys for ImeOn and ImeOff on macOS.

I opened a merge request to unify with HNGL and HJCV. It also has an extensive explanation of the situation.
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/merge_requests/311
Let's see how it goes first...

@hiroyuki-komatsu xkeyboard-config-2.36 is released, and now Lang1/Lang2 keycodes are unified to HNGL and HJCV.
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/tags/xkeyboard-config-2.36
That, however, made Mozc unable to detect the keys.
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/326
Can you make the suggested change to fix the key detection and make IME_On and IME_Off work by default on X.org/Wayland?

Acknowledged. I will work on it.
Thanks for confirming the specs.

https://github.com/google/mozc/commit/80bc73f06dcd4e1a52a03f46c2ae308f3e1bddb6 is the change.
If it doesn't work, please feel free to reopen this issue or make a new issue.
Thank you,

I tried  register ON and OFF keys at mozc 2.28.5105.102-1.
But It was ignored at end of keymap editor (see screenshot).

Sorry for lating to report (due to delaying of update of repository).

Hi oech3,
Since ON and OFF are predefined, you don't need to redefine them.

@hiroyuki-komatsu Do you mean that I can enable IME by ON without registering ON as IMEOn?
I can't do it. And I can't see that On is already registered at my keymap.

Do you mean that I can enable IME by ON without registering ON as IMEOn?

Yes.
ON/OFF keys are predefined, and not configurable. So they are invisible from the GUI.
However, it should work without any configurations.
Would you try some predefined keymaps (e.g. MS-IME, Kotoeri, ATOK) to make sure if ON/OFF key works?

ON/OFF not worked with MS-IME, Kotoeri, ATOK.
I'm using mozc with fcitx5 5.0.23.

I see. Then, that's a behavior of Fcitx.
I'd suggest you to file a feature request to the Fcitx project.
Thank you,


Carthage build of Alamofire 4.0.0-beta.2 fails with Xcode 8 GM

All was well when using Carthage with Xcode 8 beta but after moving to the GM version yesterday, carthage update fails on the alamofire build.  I was using Swift3 when I successfully ran this yesterday.  You'll see below that I deleted the Carthage folder in the project so there should be no build artifacts:
01:43:43 ~/dev/smallr:[master !x+] $ rm -rf Carthage/
01:44:40 ~/dev/smallr:[master !x+] $ carthage update
*** Fetching Alamofire
*** Checking out Alamofire at "4.0.0-beta.2"
*** xcodebuild output can be found in /var/folders/vf/3rsfnspx2z995zyfst389tm80000gp/T/carthage-xcodebuild.7tWrvU.log
*** Building scheme "Alamofire tvOS" in Alamofire.xcworkspace
** BUILD FAILED **

The following build commands failed:
       	CompileSwift normal arm64
       	CompileSwiftSources normal arm64 com.apple.xcode.tools.swift.compiler
(2 failures)
/Users/adamn1/dev/smallr/Carthage/Checkouts/Alamofire/Source/SessionDelegate.swift:198:15: warning: instance method 'urlSession(_:didReceive:completionHandler:)' nearly matches optional requirement 'urlSession(_:didReceive:completionHandler:)' of protocol 'URLSessionDelegate'
/Users/adamn1/dev/smallr/Carthage/Checkouts/Alamofire/Source/Validation.swift:54:44: error: closure use of non-escaping parameter 'validation' may allow it to escape
/Users/adamn1/dev/smallr/Carthage/Checkouts/Alamofire/Source/SessionManager.swift:353:24: error: closure use of non-escaping parameter 'destination' may allow it to escape
/Users/adamn1/dev/smallr/Carthage/Checkouts/Alamofire/Source/TaskDelegate.swift:199:10: warning: instance method 'urlSession(_:dataTask:didReceive:completionHandler:)' nearly matches optional requirement 'urlSession(_:dataTask:didReceive:completionHandler:)' of protocol 'URLSessionDataDelegate'
/Users/adamn1/dev/smallr/Carthage/Checkouts/Alamofire/Source/TaskDelegate.swift:251:10: warning: instance method 'urlSession(_:dataTask:willCacheResponse:completionHandler:)' nearly matches optional requirement 'urlSession(_:dataTask:willCacheResponse:completionHandler:)' of protocol 'URLSessionDataDelegate'
A shell task (/usr/bin/xcrun xcodebuild -workspace /Users/adamn1/dev/smallr/Carthage/Checkouts/Alamofire/Alamofire.xcworkspace -scheme "Alamofire tvOS" -configuration Release -sdk appletvos ONLY_ACTIVE_ARCH=NO BITCODE_GENERATION_MODE=bitcode CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES clean build) failed with exit code 65:
** BUILD FAILED **

The following build commands failed:
       	CompileSwift normal arm64
       	CompileSwiftSources normal arm64 com.apple.xcode.tools.swift.compiler
(2 failures)

01:45:08 ~/dev/smallr:[master !x+] $

Master is ahead of 4.0.0-beta.2 so it's just a matter of minting a new version.  Looking into this now.

For those in need, change your Cartfile to:
github "Alamofire/Alamofire" "master"
I was going to fork and PR a change but there's nothing really to be done aside from tagging 4.0.0-beta.3.

Looks like you're all squared away @adamn. 👍🏼


Connection stability

My Bluetooth connection is not great, not sure if that's because of Neewer quality, I'm using a CB60 light and it disconnects very frequently from the app, any idea why?

Do you also have this kind of issue when using their iOS app?

Close as stale. If you have any update, please open a new one.


Fix libcore build

r? @alexcrichton
This is enough to fix the libcore build, all tests are still failing though.

@alexcrichton there are multiple types of issues:
For many functions, the disassembly cannot be found, and there are no similarly named functions:
maybe related functions
thread 'core_arch::x86::abm::assert__popcnt32_popcnt' panicked at 'failed to find disassembly of 0x55b133c17c90 (_popcnt32_shim_popcnt)', crates/stdsimd-test/src/lib.rs:229:5

For some, the shim is there, but not picked, for some reason:
---- core_arch::x86::assert_ud2_ud2 stdout ----
maybe related functions
	- ud2_shim_ud2
thread 'core_arch::x86::assert_ud2_ud2' panicked at 'failed to find disassembly of 0x55b133c0f730 (ud2_shim_ud2)', crates/stdsimd-test/src/lib.rs:229:5

For others, the incorrect function is picked, which results in the intrinsic not being found:
---- core_arch::x86::avx2::assert__mm256_and_si256_vandps stdout ----
disassembly for mm256_alignr_epi8_shim_vpalignr:
	 0: lea 0xc697d(%rip),%rax # 139d94 <anon.a74be2f21bb28e3ca4d40f46667b10a2.432.llvm.6875072480626788463+0x20>
	 1: lea 0x356bf2(%rip),%rcx # 3ca010 <_ZN12stdsimd_test11_DONT_DEDUP17hbfcba4ad5d6f7d95E>
	 2: mov %rax,(%rcx)
	 3: movq $0x42,0x8(%rcx)
	 4:
	 5: vpalignr $0x7,%ymm1,%ymm0,%ymm0
	 6: retq
thread 'core_arch::x86::avx2::assert__mm256_and_si256_vandps' panicked at 'failed to find instruction `vandps` in the disassembly', crates/stdsimd-test/src/lib.rs:180:9

The issues do not appear to be affected by LTO or optimization levels, e.g., RUSTFLAGS="-C lto=off -C opt-level=1" has the same issues.
I'm merging this as is. Figuring out what's broken can be done in a subsequent PR.


Progressive web app

Explore adding in features of Progressive Web Apps

Closing in favour of https://github.com/reactql/kit/issues/31


Shaohua/docs/dg

Pull Request Test Coverage Report for Build 484

0 of 0   changed or added relevant lines in 0 files are covered.
20 unchanged lines in 7 files lost coverage.
Overall coverage increased (+0.2%) to 78.268%

Files with Coverage Reduction
New Missed Lines
%

file:/home/travis/build/AY1920S2-CS2103-W14-2/main/src/main/java/seedu/address/model/AddressBook.java
1
96.15%

file:/home/travis/build/AY1920S2-CS2103-W14-2/main/src/main/java/seedu/address/model/Inventory.java
1
96.43%

file:/home/travis/build/AY1920S2-CS2103-W14-2/main/src/main/java/seedu/address/model/supplier/Name.java
1
92.31%

file:/home/travis/build/AY1920S2-CS2103-W14-2/main/src/main/java/seedu/address/model/TransactionHistory.java
1
95.83%

file:/home/travis/build/AY1920S2-CS2103-W14-2/main/src/main/java/seedu/address/model/VersionedInventory.java
3
90.63%

file:/home/travis/build/AY1920S2-CS2103-W14-2/main/src/main/java/seedu/address/model/ModelManager.java
6
88.79%

file:/home/travis/build/AY1920S2-CS2103-W14-2/main/src/main/java/seedu/address/model/VersionedTransactionHistory.java
7
75.0%

Totals

Change from base Build 461:
0.2%

Covered Lines:
1898

Relevant Lines:
2425

💛  - Coveralls


Require Authentication - Redirect to logon page

When using the functionality "Require Authentication For VPN Sessions", which requires the user to re-authenticate occasionally, then it could be a nice feature to redirect the user the the Firezone logon page.
This is the same functionality as you see on many public wifi, where you will be redirected to the wifi's login page, where you can be forced to accept terms and conditions or something similar before accessing the internet through the network.
At the moment, what happens is that the you just fail to reach the desired website. I find myself refreshing couple of times, until I suddenly realized that I need to re-authenticate.

Hello @mortenbirkelund, this is a great feature suggestion and something we already have on our backlog! Unfortunately, it won't come fast because we need to build client apps first for each of the platforms, so no ETA for now.

Thanks for the info.
BTW, are you planning on an linux client for debian based systems?

We plan to have clients for all major OSes (Windows, Linux, iOS, Android).

Unfortunately client apps are needed as @AndrewDryga points out. See prior discussion: https://github.com/firezone/firezone/issues/689

In the short-term, we're considering refactoring this feature to be a little clearer about its intended use-case, and up the security a tad. See #1236


feat: Add ORM to backend code

Describe the new feature
Currently, we use plain nodejs backend for handling requests and a SQL based DB. But this makes app sharing very challenging as DB is not reflected in code itself.
Describe the possible approach
Add ORM models in the code, enabling new DB migration and creation steps.
Additional context
There are many good ORM libs available for nodejs. One such is prisma.

This issue is open for all, PTAL and let us know if you want to work on this.

hey @dvjsharma,  I would like to work on this issue.

Hey @dvjsharma,  I have implemented Prisma ORM , Please provide me the testing documents of functionalities , if you have.

Closing against #138


AddPart() throws Exception on Mono 4.0.0

In one of my pull requests, I developed a Clone() method that clones OpenXmlPackage instances. For that purpose, it adds OpenXmlPart instances to the clone, using AddPart(T, string).
While this has worked nicely in production on Windows 7, doing the same using Mono 4.0.0 on Mac OS X Yosemite throws an exception:
[ERROR] FATAL UNHANDLED EXCEPTION: System.Xml.XmlException: Document element did not appear.  Line 1, position 1.
  at Mono.Xml2.XmlTextReader.Read () [0x00000] in <filename unknown>:0
  at System.Xml.XmlTextReader.Read () [0x00000] in <filename unknown>:0
  at Mono.Xml.EntityResolvingXmlReader.Read () [0x00000] in <filename unknown>:0
  at Mono.Xml.DTDValidatingReader.ReadContent () [0x00000] in <filename unknown>:0
  at Mono.Xml.DTDValidatingReader.Read () [0x00000] in <filename unknown>:0
  at Mono.Xml.Schema.XsdValidatingReader.Read () [0x00000] in <filename unknown>:0
  at System.Xml.XmlValidatingReader.Read () [0x00000] in <filename unknown>:0
  at System.Xml.XmlDocument.ReadNodeCore (System.Xml.XmlReader reader) [0x00000] in <filename unknown>:0
  at System.Xml.XmlDocument.ReadNode (System.Xml.XmlReader reader) [0x00000] in <filename unknown>:0
  at System.Xml.XmlDocument.Load (System.Xml.XmlReader reader) [0x00000] in <filename unknown>:0
  at System.Xml.XmlDocument.Load (System.IO.Stream inStream) [0x00000] in <filename unknown>:0
  at System.IO.Packaging.Package.LoadRelationships () [0x00000] in <filename unknown>:0
  at System.IO.Packaging.Package.get_Relationships () [0x00000] in <filename unknown>:0
  at System.IO.Packaging.Package.CreateRelationship (System.Uri targetUri, TargetMode targetMode, System.String relationshipType, System.String id, Boolean loading) [0x00000] in <filename unknown>:0
  at System.IO.Packaging.Package.CreateRelationship (System.Uri targetUri, TargetMode targetMode, System.String relationshipType, System.String id) [0x00000] in <filename unknown>:0
  at DocumentFormat.OpenXml.Packaging.OpenXmlPackage.CreateRelationship (System.Uri targetUri, TargetMode targetMode, System.String relationshipType, System.String id) [0x00000] in <filename unknown>:0
  at DocumentFormat.OpenXml.Packaging.OpenXmlPartContainer.AttachChild (DocumentFormat.OpenXml.Packaging.OpenXmlPart part, System.String rId) [0x00000] in <filename unknown>:0
  at DocumentFormat.OpenXml.Packaging.OpenXmlPartContainer.AddSubPartFromOtherPackage (DocumentFormat.OpenXml.Packaging.OpenXmlPart part, IDictionary`2 partDictionary, IDictionary`2 dataPartsDictionary, Boolean keepIdAndUri, System.String rId) [0x00000] in <filename unknown>:0
  at DocumentFormat.OpenXml.Packaging.OpenXmlPartContainer.AddSubPartFromOtherPackage (DocumentFormat.OpenXml.Packaging.OpenXmlPart part, Boolean keepIdAndUri, System.String rId) [0x00000] in <filename unknown>:0
  at DocumentFormat.OpenXml.Packaging.OpenXmlPartContainer.AddSubPart (DocumentFormat.OpenXml.Packaging.OpenXmlPart part, System.String rId) [0x00000] in <filename unknown>:0
  at DocumentFormat.OpenXml.Packaging.OpenXmlPartContainer.SetSubPart (DocumentFormat.OpenXml.Packaging.OpenXmlPart part, System.String rId) [0x00000] in <filename unknown>:0
  at DocumentFormat.OpenXml.Packaging.OpenXmlPartContainer.AddPartFrom (DocumentFormat.OpenXml.Packaging.OpenXmlPart subPart, System.String rId) [0x00000] in <filename unknown>:0
  at DocumentFormat.OpenXml.Packaging.OpenXmlPartContainer.AddPart[OpenXmlPart] (DocumentFormat.OpenXml.Packaging.OpenXmlPart part, System.String id) [0x00000] in <filename unknown>:0
  at DocumentFormat.OpenXml.Packaging.OpenXmlPackage.Clone (System.IO.Stream stream, Boolean isEditable, DocumentFormat.OpenXml.Packaging.OpenSettings openSettings) [0x00000] in <filename unknown>:0
  at DocumentFormat.OpenXml.Packaging.OpenXmlPackage.Clone () [0x00000] in <filename unknown>:0

As with the other issue related to opening a read-only WordprocessingDocument instance, this might be a Mono bug (and the exception message might not even be helpful). It also involves System.IO.Packaging.Package.get_Relationships and related methods.
The same questions arise: To what extent has the Open XML SDK been tested on Mono? Is there any workaround on the level of the Open XML SDK?

@EricWhiteDev Have you tested your new implementation of System.IO.Packaging on Mono? Is this issue now fixed?

FYI, the upcoming Mono 4.2 and later replaced the System.Xml with the open-sourced one from MS, so this bug might not appear there anymore. You can find preview packages here: http://www.mono-project.com/docs/getting-started/install/weekly-packages/

@ThomasBarnekow Is this issue still being seen after upgrading to Mono 4.2?

@twsouthwick, I can't check anymore since I currently don't work with Mono and don't have access to that version of Mono.

I'm closing this issue for now. If someone feels like it should be reopened, please do so and comment on the current status.


Fixed panic error when token.Method != ja.signer

Fixed an issue with panic error when token supplied was signed with a different alg method than expected.
	...
	token, err := ja.Decode(tokenStr)
	if err != nil || !token.Valid || token.Method != ja.signer {
		switch err.Error() { ... } // panic when `err == nil` but `token.Method != ja.signer`
		...
	}

Added test to cover this case.

thank you for this!


Add missing Introduction parts

The introduction is missing some basic topics that seem like they would be helpful.

How to use basic matchers
How to test callbacks and promises

Probably the thing to do is just to add another page or two after Getting Started.

This new page would go between Getting Started and Mocking in the updated sidebar.

https://github.com/facebook/jest/pull/2404
FWIW this doesn't cover callbacks and promises. I think they are pretty straightforward, though, so maybe they could go in the part with "mocking functions". I'll figure that out subsequently


InfluxDB with Let's Encrypt Certs failed to find PEM block

Directions
As asked by Sean Beckett a bug report (or feature request). See https://groups.google.com/forum/#!topic/influxdb/2k6fV_giunA
Bug report
CentOS 7

Install server with hostname, install webpage and configure Let's Encrypt, eg https://m01.outsideit.net/
Install InfluxDB, fix permissions (yes after fresh installation I always need to fix some permissions on /var/lib/influxdb/meta)
Use a influxdb.conf with something like this:

[admin]
  enabled = true
  bind-address = ":8083"
  https-enabled = true
  https-certificate = "/etc/letsencrypt/live/m01.outsideit.net/fullchain.pem"
  https-private-key = "/etc/letsencrypt/live/m01.outsideit.net/privkey.pem"

[http]
  enabled = true
  bind-address = ":8086"
  auth-enabled = true
  log-enabled = true
  write-tracing = false
  pprof-enabled = false
  https-enabled = true
  https-certificate = "/etc/letsencrypt/live/m01.outsideit.net/fullchain.pem"
  https-private-key = "/etc/letsencrypt/live/m01.outsideit.net/privkey.pem"

__Expected behavior:
sudo systemctl start influxdb
results in started service
__Actual behavior:
influxdb service doesn't start
__Additional info:
When trying manually
/usr/bin/influxd -config /etc/influxdb/influxdb.conf
I can see the following error:
run: open server: open service: tls: failed to find PEM block with type ending in "PRIVATE KEY" in key input after skipping PEM blocks of the following types: [CERTIFICATE CERTIFICATE]
But
cat /etc/letsencrypt/live/m01.outsideit.net/privkey.pem
-----BEGIN PRIVATE KEY-----
mycertdarfkzofkjzeifjezfjiozejfaefakjdop

I can make it work when I just concatenate the fullchain and the privkey pems but as Let's Encrypt certificates have to be renewed every three months it would be nice if this just worked automatically with the certificates from the live folder.

+1 having this issue as well!


Update Date and Author

Hi @RenaShahMSFT, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Rena Shah). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

@RenaShahMSFT : Thanks for your contribution to the Azure documentation! The author, @RenaShahMSFT, has been notified to review your proposed change.

Microsoft authors of articles need to make updates through the private repository so the updates can be staged and validated by the current validation rules. After you review staging and fix all validation issues, you can add the sign-off comment to let the PR reviewers know the updates are ready to be merged.
It�s easy to access the private repo version of your articles in GitHub. Just add �pr to the URL, as follows:
Public repo URL: https://github.com/Azure/azure-content/blob/master/articles/azure-portal-overview.md
Private repo URL: https://github.com/Azure/azure-content-pr/blob/master/articles/azure-portal-overview.md
We've closed this pull request. Please resubmit the updates through the private repo. If you need perms to the private repo, see the contributor guide instructions.

#sign-off


compiler chokes on ;;

The compiler seems to choke on double ;;
body{margin: 0 0 0 0;;}

I wasn't able to reproduce this with a unit test (the output is what you'd expect, no error). Do you have a complete test case?


Tag Helper completion should be aware of attribute rules

https://github.com/dotnet/razor-tooling/pull/6823 fixed https://github.com/dotnet/razor-tooling/issues/6583 but it also, in a way, broke it.
In a .cshtml file in an ASP.NET Web App, you can type form, see the form tag helper item in completion, and when you complete the suggestion it gets coloured as a tag helper. This is because there is a FormTagHelper component available.
In a .razor file you can type form, see the form tag helper item in completion, but when you complete the suggestion it doesn't get coloured in as a tag helper. That is because the tag helper found by completion only works when there is an action attribute on the tag, and further only when that attribute starts with ~/. If you go ahead and type that out, the tag turns blue.
This is because semantic classification (really, the compiler) is doing more work than completion is doing, and knows to only colourize the element as a tag helper when it satisfies the attribute rules that are defined. We should make completion smart enough to do this too, so that the form tag helper completion item, for example, only shows when the actual FormTagHelper is available (ASP.NET Web App) or there is a correctly matching action attribute.
This should mean, for example, that form as a tag helper only shows in completion for ASP.NET Web Apps, or when invoked on an existing element in a .razor file that already has the right attribute.

Going to wait for https://github.com/dotnet/razor-tooling/pull/6968 to merge before doing this, so we can see if we can share the compiler code that already has this logic, rather than re-invent the wheel


Update to Skia m112 and enable paragraph

Maybe we can make a single PR that updated to latest version of Skia? Then we need to remember to test manually that everything builds locally afterwards and also run the Skia build workflow.

Maybe we can make a single PR that updated to latest version of Skia? Then we need to remember to test manually that everything builds locally afterwards and also run the Skia build workflow.

closing as we will take a different approach for advanced text layouts.

Would like to request if you have any news or updates for the paragraph feature. Excited to try out any new developments. Thanks so much.

Thanks for the update @chrfalch


Proxy option

Hi
Could you add a proxy option?

I will consider adding this feature if needed. @killo3967

Ok, so let me explain my idea.
So far from Calibre (https://calibre-ebook.com/) using the translation plugin (https://github.com/bookfere/Ebook-Translator-Calibre-Plugin) and with the right configuration I can use your software.
{
"name": "DeepL X",
"languages": {
"source": {
"English (British)": "EN-GB"
},
"target": {
"Español de España": "ES
}
},
"request": {
"url": "http://<IP_ADDRESS>:1188/translate",
"method": "POST",
"headers": {
"content-Type": "application/json".
},
"data": {
"source_lang":"",
"target_lang":"",
"text":""
}
},
"response": "response['data']"
}
The problem I have is the one I told you in the previous post. After several requests it gives an error. #40 (https://github.com/OwO-Network/DeepLX/issues/40)
That's why I want to pass your program through the tor network so that each request comes from a different source and with this I think I could bypass the DeepL protections. I have tried with ADVOR ( https://sourceforge.net/projects/advtor/) to capture the program but I get this error message.
DeepL X has been successfully launched!

[GIN] 2023/04/26 - 18:44:58 |←[97;42m 200 ←[0m| 1.905ms | <IP_ADDRESS> |←[97;46m POST ←[0m "/translate"
This is why this is the proxy request. Calibre sends it to your software that via proxy forwards it to the tor router (ADVOR).

I've rewritten a package for Python that you can call directly from within the Python code. You can check this link for details.

Sorry , but i don't understand what are you doing and my skills in pyhton are less than zero. What i need is that your api could have a proxy option.

Sorry , but i don't understand what are you doing and my skills in pyhton are less than zero. What i need is that your api could have a proxy option.

https://github.com/OwO-Network/PyDeepLX/pull/3/commits/e56a61a6f1f52205b2cd42bfa366af6821a637dd
This is a PR to add proxy option. I am using deeplx without restrictions by connecting to tor proxy.


HHH-15146 Run tests against hibernate-jpamodelgen-jakarta

https://hibernate.atlassian.net/browse/HHH-15146

Ha, it looks like I fixed the module by mistake while adding tests xD I'll split the fix and tests into two commits, to make things clearer.

Here @beikov , I moved the fix to a separate commit to be clearer.

Merged, thanks!


Propagate kernel name via KernelSettings

Fixes #234
Names now show up!

Propagating this down from the proc macro until both crates/cubecl-cpp/src/shared/kernel.rs as well as crates/cubecl-cuda/src/compute/server.rs could get a hold of the name required a bit of kernel_name field duplication in the relevant data structures.
If there's a more straight forward way to propagate it I'm happy to do that, but I couldn't see any obvious way.
Also notice from the image that the same four names show up twice, but with different performance characteristics.
This is because the example I ran first goes through f32 then f16.
I hope to support automatically adding a suffix in a follow-up if it's not too hairy.

That's awesome! Had the same problem, but in wgpu. Would it be possible to use the names as a label for the shader on wgpu too?

That's awesome! Had the same problem, but in wgpu. Would it be possible to use the names as a label for the shader on wgpu too?

Yes, from what I've done in wgpu I know that the entry point can be named by users somewhere in the pipeline setup.
Then similarly the CubeCL code that produces wgsl source code should match the pipeline setup.
Do you have a debugger for wgpu that shows just "main" "main" "main" etc.? Asking because I don't know what the best way of seeing compute shader calls from wpgu is.
@maintainers: If you see this PR and you're happy please go ahead and merge. I'll then do the wgpu in a follow-up as I'm out of time right now. Else I'll continue here next time I'm coding

Added a commit to make wgpu + wgsl/spirv also use the kernel name as their entrypoint names.


It's not working at all with current hyper.

Just after installing httpie-http2 it's not possible to make any request with the following error:
http: error: AttributeError: 'module' object has no attribute 'OP_NO_COMPRESSION'

Here's the versions:
httpie-http2==0.0.1
httplib2==0.9.2
hyper==0.5.0```

I've found that It's caused by old python version with outdated ssl module in OS X.
Closing.

OSX currently ships Python 2.7.10. As per documentation, OP_NO_COMPRESSION should actually be supported in >= 2.7.9, still getting this error.
How did you solve this issue?

@sts OP_NO_COMPRESSION is not supported in OS X's system Python because Apple ships it linked against OpenSSL 0.9.8zh, which is ancient and does not support the OP_NO_COMPRESSION flag at all. OS X's system Python is simply entirely unsuitable for use with HTTP/2, unless you install a PyOpenSSL binary wheel.

@sts I've installed python from homebrew.

try this
if not hasattr(ssl, 'OP_NO_COMPRESSION'):
ssl.OP_NO_COMPRESSION = 131072


Add username&password to the hostedSuppressions

Is your feature request related to a problem? Please describe.
With the latest versions of the Gradle plugin (8+), it attempts to retrieve data from https://jeremylong.github.io/DependencyCheck/suppressions/publishedSuppressions.xml. Without storing its certificate on our machine, we are unable to access this site directly. Sadly, its certificate is updated almost every day, and we cannot do this process on every machine every day, so we are stuck.
The file above can be added to our internal Artifactory every day. By using hostedSuppressions, everyone will be able to access it. However, in our Artifactory, there are usernames and API tokens/passwords, and the current hostedSuppressions configuration doesn't provide anything besides the URL.
Describe the solution you'd like
Add username and API token/password to the hostedSuppressions.
Describe alternatives you've considered
I don't have any.
Additional context
In the case that you try to run the plugin without making any changes, you will receive these errors (which is indicative of a missing certificate):
Error downloading file https://jeremylong.github.io/DependencyCheck/suppressions/publishedSuppressions.xml; unable to connect.
.
.
.
javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
.
.
.
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
 .
.
.
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

In the case that you try to run the plugin with our Artifactory URL,
    analyzers {
        hostedSuppressions {
            url = "https://*****.jfrog.io/artifactory/******/owasp/publishedSuppressions.xml"
        }
        assemblyEnabled = false
    }

you will receive these errors (which is indicative of a missing username&password):
Caused by: org.owasp.dependencycheck.utils.DownloadFailedException: Error retrieving https://*****.jfrog.io/artifactory/******/owasp/publishedSuppressions.xml; received response code 401; null

Duplicate of #5387


Various Issues

Starting color is wrong in center
Starting outer selector is off-center (Fix ready for this)
Border is selectable

All of these are taken care of!


URL with posts/pages slug in double-byte character results in 404

I'm using Japanese language which tends to use the letters like "日本語" as in example.com/posts/日本語/, and that is causing 404 error both for posts and pages. I haven't tried in other CJK language or some others that can't be covered in ASCII characters like Arabic yet, so this report is pretty limited.
I didn't have this issue in simple vanilla Next.js implementation without any such special care, so I'm guessing string conversion is happening somewhere in the process?
I want to come back to this issue and see if I can suggest fix, but I'm still in learning process of Next.js, so I'm leaving this here as memo. (I'm pretty determined about using this in production for Japanese clients, so I'll come up with solution somehow anyways.)

hey @iorippi interesting one! do you happen to have your wordpress instance public that i can spin it up? if you're still interested in actually fixing and putting together a PR, i'd be happy to at least try to point you in the right direction :)
if your WP isn't public, do i just simply copy those characters into the post title to reproduce?

@colbyfayock Thanks for heads up! Here's URL for GraphQL API: https://cms.appy.hiup.dev/wp/graphql
There are several Posts and one of them has slug in Japanese.
            "id": "cG9zdDo4",
            "slug": "%e3%81%aa%e3%81%9e%e3%81%aa%e3%81%9e%e3%81%a0%e3%82%88%ef%bc%81"
          }```

`decodeURI()` for the slug does actually return the string identical with the actual slug "なぞなぞだよ！", however, the result is "Not Found" on dev mode, and for deployed & exported static site, it returns "Not Found - The requested URL /posts/ãªãžãªãžã ã‚ˆï¼/ was not found on this server."

I get the same gibberish when I convert UTF-8 string for the slug into ASCII, so I'm guessing that conversion is happening somewhere internally upon resolving the route??


Error: TextGenerationPipeline.call() missing 1 required positional argument: 'text_inputs'

Raised by zephyr when trying to run an inference on most recent branch.

traceback?

This got resolved, it was an error with importing the new pipeline


How to handle such "duplicate" calls?

Hi,
I am using Clair on my raw ONT reads (human), and found the following two calls that I don't know how to handle. They essentially differ by 1 base. So I hope there's a "merge" module in Clair to post process such "duplicated" calls.
chr1	25808786	.	GGAGGTGAGGACAGCTGGGGTGCGACGTGGGGCCCCTCC	G	691	.	.	GT:GQ:DP:AF	0/1:691:31:0.2258
chr1	25808787	.	GAGGTGAGGACAGCTGGGGTGCGACGTGGGGCCCCTCCGC	G	582	.	.	GT:GQ:DP:AF	0/1:582:31:0.3548

Unfortunately, I cannot share the data.
Thanks!

Will investigate and find a method to distinguish homoployer error induced duplication and real overlapped variants.
A quick workaround would be to retain only one copy (preferably the leftmost) of overlapping variants.

Thanks!
Yes, that's a quick workaround, although one can imagine some kind of threshold need to be defined for which two variants are to be considered "should be the same".
The case will be more complicated when insertions are involved, as one need to compare the inserted sequence as well.

We now added a simple way to deal with those variants, can check on https://github.com/HKU-BAL/Clair/blob/master/docs/POST_PROCESSING.md#handle-overlapping-variants


Testing the app on device

Seems to run and show the camera image, does not seem to do anything else.
Looking at the demo, it should segment people and bicycles?
Issue #1 is closed but there have not been any checkins since then.
Does that mean I need to figure out how to disable the GPU delegate myself?

Please test it with commit https://github.com/pillarpond/image-segmenter-android/commit/36e1dd245dca25c8f44e9e217ca280a3a1bf9f1c


Anime model request

I've always seen plenty artefacts when interpolating anime vids using rife. Could you please make a model that's specially trained on anime to create the best results for this content? Besides, rife is commonly used to interpolate anime too so I think a special model for anime would satisfy lots of people!

Hi, after v4.0 model, our training set includes animation. The crux of the problem is that even though the training data is all anime, the effect is still not ideal and even worse than original version.
I know models for anime will be useful for lots of people, We're already targeting this during developing.

I see, how about a 3x interpolation dataset for animation, would that be possible to make?

The question that confuses me the most is actually what dataset can improve the performance of the frame interpolation model.
In my experiments, the dataset has little effect on the performance of the frame interpolation model.
BTW, I think RIFEm can support 3x interpolation in theory.

v4.4 model is specially tuned for animation, welcome to have a try.

v4.4 model is specially tuned for animation, welcome to have a try.

Thanks for your devotion to animation, I'd love to see more development regarding animation content!

I create a patch for anime, that improve a lot, see https://github.com/hzwer/Practical-RIFE/pull/23


home page cards not clickable

http://<IP_ADDRESS>:10010/
clicking on "Learn More" in any card takes me to the apppropriate section, but:
clicking on "Type Reference" does nothing.
I expect the text of the card and the icon to go to the same location as the learn more button.

Closed by https://github.com/Altai-man/docs.raku.org/commit/16755101135966941ef644feecf55df3e6ecafea


Chaotic Feat: Adding a new section named "Emoji-Land"

Describe your chaotic idea

Emoji-Land is a chaotic digital playground where a variety of chaotic emojis float across the screen, growing and shrinking randomly.
The emojis react to your movements, expanding dramatically when you hover over them
Each emoji plays its own unique, glitchy sound effect, creating an irritating atmosphere.
The background flashes through various shades of grey, adding a sense of visual chaos.

Add Screenshots or Sketches

Confirm

[X] I understand that my idea will add to the chaos and I'm okay with it
[X] I agree to follow this project's Code of Conduct
[X] I want to work on this feature
[X] I'm GSSOC'24 Extd registered Contributor
[X] I'm Hacktoberfest registered Contributor

Go ahead!


Capture image from Camera

Is there any interface provided for capturing the current image from the camera buffer? I don't see any in the RNCameraView.

Easily done with RNVRegion component's onFrameCaptured property. Just have look past the VisionCamera examples 🤦


Remoting exception serialization overview doesn't say what to do with uses of ServiceProxy.Create

The remoting exception serialization overview page doesn't explain what to do if the ServiceProxy.Create method is used instead of a ServiceProxyFactory or an ActorProxyFactory
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 7d0933d5-4c89-431d-e082-49553171c3d5
Version Independent ID: 5f34a9a3-841c-45a8-c218-d1459d25b57b
Content: Enable data contract serialization for remoting exceptions in Service Fabric - Azure Service Fabric
Content Source: articles/service-fabric/service-fabric-reliable-services-exception-serialization.md
Service: service-fabric
GitHub Login: @tomvcassidy
Microsoft Alias: tomcassidy

@acarrazzoni-qontigo
Thanks for your feedback! We will investigate and update as appropriate.

@acarrazzoni-qontigo
I'm going to assign this to the document author so they can take a look at it accordingly.
@tomvcassidy
Can you please check and add your comments on this doc update request as applicable.

Hi @acarrazzoni-qontigo ! I spoke with the dev team and was informed that ServiceProxy.Create shouldn't be used instead of ServiceProxyFactory or ActorProxyFactory, because it the method uses the default ServiceProxyFactory. The dev team is considered deprecating ServiceProxy.Create and said that users should be directed to ServiceProxyFactory instead. I'll make notes in the documentation where appropriate.
Thanks for bringing this up! If you find any other issues or have any other questions, please let us know.
#please-close


Minimal node 12 support

Closes #61
I still get some warning when building for node 12 but for node 8.

When will it be released?

@abetomo @legraphista I have released v1.2.0 with node 12 support.

Thank you!


Things missing in the theme without styling supports in the theming API

[ ] Add left border to sidebar - https://github.com/Microsoft/vscode/issues/26530
[ ] Themeing for editor squiggles - https://github.com/Microsoft/vscode/issues/16204 + https://github.com/Microsoft/vscode/issues/9819
[ ] Feature request: bold_folder_labels setting like Sublime's -
https://github.com/Microsoft/vscode/issues/10748
[ ] Hide sidebar's Tree View/Explorer arrows - https://github.com/Microsoft/vscode/issues/25655

@pahen
Thank you for your PR ! :tada::tada::tada:
We track the things which maybe can be fixed with theme API supports in the future here.

Perfect! 🕺

Add these too:
[ ] Text selection color (find, search, etc) https://github.com/Microsoft/vscode/issues/25966
[ ] Allow theming of parameter hints https://github.com/Microsoft/vscode/issues/26671

The "Text selection color" should work already. Can you provide a screenshot where it doesn't work @ajitid? And what version of VSCode are you running?

Latest in stable release, 1.12.2.
Is it available in insiders build and not in stable?

Correct. It was added after 1.12.2 was released. Should work in insiders build.

The same is valid for "Allow theming of parameter hints". Should work in insiders build.

Okay, removed. Thanks!

I moved out the relevant stuff into own issues so I think we can close this now @teabyii


IE9 datepicker has visual issues with how table is rendered

Columns are rendering incorrectly. Days of the weeks is overflowing and incorrectly calculating widths. Dates section is not spanning full width.
Win 7 IE9

@feitla PR's with working examples are always appreciated. Thanks for the info.


Update branding to 3.1.15

Update to ubuntu 18.04

@NTaylorMullen @TanayParikh any idea what this error is about?
$ node ./node_modules/vscode/bin/install
  Detected VS Code engine version: ^1.31.0
/__w/1/s/eng/targets/Npm.Common.targets(45,5): error : installing vscode.d.ts: Error: Request returned status code: 404 [/__w/1/s/src/Razor/src/Microsoft.AspNetCore.Razor.VSCode.Extension/Microsoft.AspNetCore.Razor.VSCode.Extension.npmproj]

I'm not sure how it's related to the branding update.

Haven't seen that before, and I agree definitely doesn't seem branding related.
Re-triggered the CI, I'd chalk this up to intermittent flakiness.
installing vscode.d.ts: Error: Request returned status code: 404
https://github.com/Microsoft/vscode-extension-vscode/issues/44
Potentially related to a github token issue, not sure where that fits into the CI environment though.

I also attempted a few retries so it's definitely not a flaky issue. I suspect this might be related to unbuntu 18.04 update. Perhaps the agent doesn't have the right credentials? Going to revert that part and see what happens.

Actually that doesn't make sense since it's not just linux builds failing. Hmm maybe the release/3.1 branch is just broken.

I'm going to see if this also affects internal builds or an issue with public builds only. I'll try increasing the verbosity of yarn as well to see if we can get more details.

This branch built fine last month, something must have changed with the vscode asset it's trying to acquire

Hmm this also affects internal builds so it looks like 3.1 can't build at the moment. I'll increase the verbosity of logs

Ah I think I figured it out. This is a case of https://github.com/microsoft/vscode/issues/120064. The resolution should be that we update vscode dependencies like in https://github.com/dotnet/aspnetcore-tooling/blob/release/3.1/src/Razor/src/Microsoft.AspNetCore.Razor.VSCode/package.json#L13.
@TanayParikh can you update the vscode npm dependencies? I'm not sure how to determine which version to update to but you might have more context on updating external dependencies in this repo.

Updated per recommended version in https://github.com/microsoft/vscode/issues/119822#issuecomment-806489621

That didn't work either, updated to match the VS Code dependencies form the main branch.

I should have elaborated, there are more than one project that need to be updated:
Microsoft.AspNetCore.Razor.VSCode.Extension.npmproj
Microsoft.AspNetCore.Razor.VSCode.Test.npmproj
From the logs, I think these are the only remaining projects.

Spoke with @NTaylorMullen, we no longer need VSCode on this branch.

@JunTaoLuo CI passing now!


nushellPlugins: hash update for 0.89.0

Description of changes
everytime nushell is updated, the plugins integrated in the repo need to have their cargo hash updated.
this PR is just to fix those plugins following 0.89.0 release.
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 280955 run on x86_64-linux 1

3 packages built:

nushellPlugins.formats
nushellPlugins.gstat
nushellPlugins.query


Some things are not defined

getlogger isn't defined among others when opened in eclipse

The method getLogger() is bundled within Java. Additionally, this project is built and developed with the IntelliJ IDE so please keep that in mind.
Be sure that you have the right Java version and that the SDK is selected properly.

java: java.lang.NoSuchFieldError: Class com.sun.tools.javac.tree.JCTree$JCImport does not have member field 'com.sun.tools.javac.tree.JCTree qualid'

That is an error not even related to the project, that is an issue with your Java setup in eclipse

i switched to intellij

apparently its something to do with lombok


Adding Asini Slackin service to the example website

Doing a bunch of renaming of the form "slackin" --> "react-server-slackin" to make way for another Slackin service.
Adding a second Slackin service for the Asini Slack team.

Thanks for dealing with this @davidalber.


[bug]2.7.0-beta2 crush while loading

gregtech-api has some break change

I'll start working on this when their API is stable.


[OutlinedInput] Improve customization

The classkeys were missing in the overrides typing

That's an internal component. I don't think you're supposed to access that. Our typescript declarations reflect the public API. You should annotate private usage with @ts-ignore or any or however you prefer to circumvent type checking.

But how should i override the outline-color of a input with variant="outlined"
I would expect that I have to do:
I use createMuiTheme({overrides: { MuiNotchedOutline: {root: {borderColor: 'somecolor'}}}})
but atm this throws an typescript error because MuiNotchedOutline is not in the overrides typing.
I`d like to avoid using "as any" casts

@eps1lon is correct, it's considered private as we are speaking. To be consistent, we should be removing the name here:
https://github.com/mui-org/material-ui/blob/063dc82f07c19aaafeb3f0899946a68d5b4b4849/packages/material-ui/src/OutlinedInput/NotchedOutline.js#L156

how should i override the outline-color of a input with variant="outlined"

@daniel-rabe Interesting question.

@daniel-rabe
https://codesandbox.io/s/mmkjqzq28p
So you can change the color via notchedOutline in MuiOutlinedInput but then you can't change that depending on the input state. I added another solution to do this but this is depending on implementation details again.
A solution could be to include the state in the className here:
https://github.com/mui-org/material-ui/blob/bca93d92d65a9fac603c70d4971da09d26022e5d/packages/material-ui/src/OutlinedInput/OutlinedInput.js#L71
Basically moving
https://github.com/mui-org/material-ui/blob/bca93d92d65a9fac603c70d4971da09d26022e5d/packages/material-ui/src/OutlinedInput/NotchedOutline.js#L92-L99
up the component tree.

I can change the border color on hover now thanks to @fillipe-ramos but I still can't get the default border to work.

Thank you @fillipe-ramos !
In my case, with @material/core in "v4.0.0-rc0" I juste did
MuiOutlinedInput: {
  root: {
    '&:hover $notchedOutline': {
      borderColor: '#1788ce'
    }
  }
}

And it seems to be enough to do the trick.

Any advice on how to do this with sx props (no makeStyles classes)?


chore(deps): Updagrade to TypeScript v4.9

:tada: This PR is included in version 1.4.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Solves twitter problem

Got your back @Atinux: https://mobile.twitter.com/Atinux/status/1133719426367410177

🤣

jQuery is missing 🙈

Not sure if I should create another PR - this one got closed so fast... Tried my best :'D


DX-1086-1096 track package tests

JIRA's covered:

DX-1086 - Test track by package ID
DX-1088 - Test initial scan tracking event.
DX-1089 - Test out for delivery tracking event.
DX-1090 - Test multiple delivery attempts tracking event.
DX-1091 - Test delivered on first try tracking event.
DX-1092 - Test delivered with signature tracking event.
DX-1093 - Test delivered after multiple attempts tracking event.
DX-1094 - Test delivered after exception.
DX-1095 - Test single exception tracking event.
DX-1096 - Test multiple exceptions in tracking event.

There is currently no JIRA ticket for the Python SDK that is DX-1087.