export type { Primitive, Props, PropValue, State, StateView } from "./shared"

mini-van.d.ts
van-plate.d.ts

Removed duplicate types.

I'm adding some isomorphic helpers. Consistent types are useful for adding code that is meant to work both on the browser & server. The second commit adds more types into shared.

shared.ts can instead import from mini-van.d.ts & van-plate.d.ts, allowing the two files to have no dependencies.

Hi,
Thanks for your commit!
Overall this PR seems to do many things and make the type system of Mini-Van much more complicated. But I'm struggling to understand the main motivation of the PR. Preferably, if there are multiple objectives to achieve, we can break down into smaller PRs, so that the change for each objective becomes more clear.
Here are my general opinion regarding the PR:

For now, a good feature of Mini-Van is: you can download a single .js file and a single .d.ts file to start working with, without the need of NPM integration. I would like to keep that feature, unless there is convincing benefit if we give up on it. I tried to find some TypeScript bundling solutions but couldn't get a workable one. In the end, I decided to just have some duplicate code among mini-van.d.ts, van-plate.d.ts and shared.ts. For now the amount of duplication is manageable. I think we can keep the duplication until the complexity hits an inflection point.
I noticed that one improvement of this PR is to enable more type-checkings in shared.ts for tag functions. I can see the benefit. If this is something you want to improve, I would prefer to have a minimal PR just to address that. This way it will be easier to weigh in the pros and cons of the PR. Ideally, I'm hoping we can make the improvement without breaking the feature in 1).

I reverted mini-van.d.ts & van-plate.d.ts, added common types into shared.ts, & rebased.
Here is a couple of extensions that I'm working on:
const protoOf = Object.getPrototypeOf
const objProto = protoOf({})
export type PropsWithUndefined = Record<string, PropValue|undefined|StateView<PropValue>|(()=>PropValue)>
export type TagFuncWithUndefined = (first?:PropsWithUndefined|ChildDom, ...rest:readonly ChildDom[])=>Element
export function Raw(van:VanObj, html:string):ChildDom {
	if (globalThis['window']) {
		const frag = document.createDocumentFragment()
		const temp = document.createElement('div')
		temp.innerHTML = html
		while (temp.firstChild) {
			frag.appendChild(temp.firstChild)
		}
		return frag as any as ChildDom
	}
	else {
		const { __proto__ } = van.tags.div()
		return {
			__proto__,
			renderToBuf(buf:any[]) {
				buf.push(html)
			},
		} as any as ChildDom
	}
}
export function vanProxy<V extends VanObj>(van:V):Omit<V, 'tags'>&{
	tags:Readonly<Record<string, TagFuncWithUndefined>>
} {
	let tags = new Proxy<typeof van.tags>(van.tags, {
		get(target, p, receiver) {
			const f = Reflect.get(target, p, receiver)
			if (!f) return f
			const fn:typeof van.tags[string] = (...args)=>{
				let [props, ...children] = protoOf(args[0] ?? 0) === objProto ? args : [{}, ...args]
				return f(cleanProps(props), ...children)
			}
			return fn
		}
	})
	return new Proxy<typeof van>(van, {
		get(target, p, receiver) {
			if (p === 'tags') return tags
			return Reflect.get(target, p, receiver)
		}
	})
}
function cleanProps(props:Props) {
	for (const key of Object.keys(props)) {
		if (props[key] === undefined) delete props[key]
	}
	return props
}

@Tao-VanJS I took a different approach with shared.ts, adding a VanShape type. VanShaped is used in the generics for types where mini-van.d.ts & van-plate.d.ts differ. Some types were added to mini-van.d.ts & van-plate.d.ts as well.
This gist contains the example that I used.

I left in VanObj but I think VanShape could replace VanObj.

Hi @btakita,
Thank you so much for your contribution! I did take a in-depth review of this PR. It's a difficult decision but I haven't come to a point for merging this PR in.
First, about my view on TypeScript and .d.ts files in VanJS-series projects: I am considering TypeScript as add-on type annotations. The core library should work on its own without the .d.ts annotations, and the purpose of d.ts annotations is to try our best to assist our users for writing correct client code while keeping the type annotations simple and easy to understand. While advanced TypeScript features allow us to do very sophisticated type gymnastics but doing too much will make the type system hard to digest and navigate.
For this specific PR, I'm afraid that we're pushing the complexity of relevant TypeScript files to a point that is no longer easy to understand. This can be judged by the size increases of the files, especially in shared.ts. It's really hard for me to be sure that the benefit we can get from this PR worths the complexity.
Moreover, I don't think this specific PR can significantly enhance the type-checking capabilities of Mini-Van, especially with the introduction of any in different places. Here are a few issues that I noticed:

In Line 20 of van-plate.d.ts:

export type BindingFunc = (dom: Element) => ValidChildDomValue

I don't think this change is right. Indeed, the signature of BindingFunc is quite complex, which is why I'm using any for van-plate to avoid making the type too complex in van-plate. In VanJS, the signature is:
export type BindingFunc = ((dom?: Node) => ValidChildDomValue) | ((dom?: Element) => Element)

In mini-van the signature is:
export type BindingFunc<ElementType extends HasFirstChild, TextNodeType> =
  | ((dom?: ElementType | TextNodeType) => ValidChildDomValue<ElementType, TextNodeType>)
  | ((dom?: ElementType) => ElementType)

In Line 49 of van-plate.d.ts:

readonly add: AddFunc<any, any>

This is reducing the type checking capability of van-plate, as literally any function is compatible to AddFunc<any, any>.
3. In shared.ts, the definition of VanShape, I noticed that the mini-van portion of the definition:
{
  readonly _BindingFunc?: MiniBindingFunc<any, any>
  readonly _ChildDom?: MiniChildDom<any, any>
  readonly _ValidChildDomValue?: MiniValidChildDomValue<any, any>
  readonly add: MiniAddFunc<any, any>
  readonly html: MiniHtmlFunc<any, any>
  readonly tags: MiniTags<any, any>
  readonly tagsNS: MiniTagsNSFunc<any, any>
}

Because of the using of any, we're literally making any function compatible with these defined types, thus the VanShape has hardly any type-checking capability.
It's not 100% clear to me what you're trying to achieve in this PR. i.e.: what exactly is missing in the current type annotations of Mini-Van for the things that you plan to work on. If you're trying to create some utility functions that can work for both mini-van and van-plate, my suggestion is to start with something simple with just some basic type-checking capabilities, and leverage weak-typing (such as any) when type gymnastics are pushed for too far. Then we can start to gradually introduce more type-checking, step by step, with each step we make sure to keep the complexity under control. Another approach is for utility functions to deal with more specific concrete types. The types in van-plate are pretty simple and specific. The types in mini-van are quite generic but you can start working with the concrete specializations that you care about.
Let me know if it makes sense to you.

Hi @Tao-VanJS, thanks for taking a look. I'm attempting to create isomorphic functions to extend Van. I ran into type issues & usability issues using the type system on main. The example I posted in the gist has to work for both the van-plate & mini-van.
I'm having trouble with the types in the main branch, particularly around the types that have the <ElementType extends HasFirstChild, TextNodeType> generics in mini-van. I hope to have a shared set of types that can provide a better experience to verify both type systems work.
Domain Consistency
First I had to wrap my head around the terminology. van-plate for SSR & mini-van for CSR. When making isomorphic components, I want to use the shared types as much as possible, as it indeed is shared between SSR & CSR. Using SSR types for isomorphic components limits the type system capabilities when the component is rendered in CSR. I don't think I could even figure out how to do the example in the gist with the type system in main. Isomorphic components would have to reconcile & support both the <ElementType extends HasFirstChild, TextNodeType> generic for mini-van & the lack of generics for van-plate.
Making van-plate types do double duty as a generic type for isomorphic components adds complexity & influences the decision of how to design the types in van-plate. The types in van-plate are no longer meant to accurately model what happens in SSR, but to also be a generic type for isomorphic components. This forces types to be overly-wide for SSR.
You pointed out:

export type BindingFunc = (dom: Element) => ValidChildDomValue

I don't think this change is right. Indeed, the signature of BindingFunc is quite complex, which is why I'm using any for van-plate to avoid making the type too complex in van-plate. In VanJS, the signature is:
export type BindingFunc = ((dom?: Node) => ValidChildDomValue) | ((dom?: Element) => Element)

I updated the type to:
export type BindingFunc = (dom?: Element) => ValidChildDomValue

From what I understand, dom?: Element is the actual type expected in van-plate for BindingFunc. If there are other types expected, why not explicitly model what is happening during execution? If van-plate's BindingFunc double as the common isomorphic type, then we have to use dom:any.

In Line 49 of van-plate.d.ts:

I missed removing the generic. AddFunc is not a generic type in van-plate.
Consistency with Generics
VanShape is the current try to keep mini-van & van-plate simple with no dependencies, while providing a consistent type api to target isomorphic code.

Because of the using of any, we're literally making any function compatible with these defined types, thus the VanShape has hardly any type-checking capability.

Good catch! I strengthened VanShape:
type VanCommon = {
  readonly state: <T>(initVal: T) => State<T>
  readonly val: <T>(s: T|StateView<T>) => T
  readonly oldVal: <T>(s: T|StateView<T>) => T
  readonly derive: <T>(f: () => T) => State<T>
  readonly _: UnderscoreFunc
}
export type VanShape = VanCommon&(MiniVan|VanPlate)

and removed the defaults for generics using VanShape (<V extends VanShape> instead of <V extends VanShape = VanPlate>):
Now VanShape has stronger typing, there were a couple of errors in the example code that I had to fix.
I updated the example gist.
Raw component
I had to use a ReturnType ternary to resolve correctly.
type Return<V extends VanShape> = V extends MiniVan ? DocumentFragment : VanPlateElement

There are tests at the bottom of the file.
vanCleanProps
With stronger type checking, I got a type error when trying:
				let [
					props,
					...children
				] = (protoOf(args[0] ?? 0) === objProto ? args : [{}, ...args]) as [Props, ...ChildDom<V>[]]
				return tag(cleanProps(props), ...children)

It seems like TagFunc<V> does not narrow the type when checking for valid valid arguments. It needs to work for both MiniVan & the VanPlate types even if the ternary type check is the same between TagFunc<V> & ChildDom<V>. To fix it, I had to use ChildDom<VanPlate>. I'm not satisfied with this solution, but at least it's a stronger type check than what was originally in the shared VanObj, which was:
readonly tags: Record<string, Function>

Note the type return by vanCleanProps
export type PropsWithUndefined = Record<string, Props[string]|undefined>
export type TagFuncWithUndefined<V extends VanShape> =
	(first?:Props|ChildDom<V>|PropsWithUndefined, ...rest:readonly ChildDom<V>[])=>ReturnType<TagFunc<V>>
export type VanWithUndefined<V extends VanShape> = V&{
	tags:Record<string, TagFuncWithUndefined<V>>
	tagsNS:(namespaceURI:string)=>Readonly<Record<string, TagFuncWithUndefined<V>>>
}

I'm not sure how do accomplish the same thing without chaos with the main branch...

I realize a couple of things now. van is meant to run in the browser. mini-van is meant to run on the server to render to a DOM library (e.g. JSDOM) or in the browser with limited prop & reactive support. van-plate is meant to render to a html string. Is this correct?
I also realize that BindingFunc is not run in van-plate, so (dom: any) makes sense.
With that being said, isomorphic types that delegate based on the Van type would need to depend on van-core in addition to this library. That makes me think that it would make more sense to not include the delegation in this library. The 3 type sets can support the delegation use case by keeping the same set of names.

I realize a couple of things now. van is meant to run in the browser. mini-van is meant to run on the server to render to a DOM library (e.g. JSDOM) or in the browser with limited prop & reactive support. van-plate is meant to render to a html string. Is this correct?

Yes. Your understanding is correct.
I will try to explain my thought process regarding type systems in VanJS-series projects.
Generally speaking, for type systems of projects with the level of generic and flexibility like VanJS, designing a good type system is a challenging task and needs juggling among the 3 main type of problems:

Types are too loose. Cost of this type of problems:

We're not able to catch some bugs before run time.
We lose some perks from the IDE, especially, a better suggestion for auto-complete.

Types are too tight. Cost of this type of problems:

Correct client code result in type errors.

Types are too complex. Cost of this type of problems:

Type system is hard to understand. It's hard to figure out whether there are bugs in the type system by reading the code.
Type system is hard to deal with. It's hard to maintain and keep evolving the type system.
When users get type errors, the error messages are usually hard to understand, sometimes misleading. This is quite evident in C++ template errors.

There are times where it's hard to avoid all 3 types of problems altogether. Thus in case we need to do some tradeoffs, in my opinion, the stack ranking of importance is: 3 > 2 > 1.
This is why in shared.ts, we chose to have problem 1, rather than problem 3 or 2.
Another remark is that, when we're developing VanJS, mini-van, van-plate and VanX, because of the generic and flexibility we have in the implementations, it will make the type system more complex than desired if we had them implemented in TypeScript. As a result, we chose to have the JavaScript-based implementation first, and then try to annotate the public interface of these projects in d.ts files with a type system that is reasonably simple and tries to catch client-side bugs as much as possible. Separating the implementation and type annotations helps us decouple the entangled problems, and as a result greatly simplify things. Indeed, we recognize the limitation of the type checking thus that's why we have van.debug.js which enables more sanity checks than what are possible in TypeScript.
For your specific work stream, I would recommend a similar approach. If I understand correctly, what you want to have is an extension of van object with your preferred behavior. You want the extension to be generic enough so that it can cover VanJS, mini-van and van-plate. I think by trying to implement your extension completely in JavaScript first and then add a d.ts file to annotate the public interface can simplify lots of things.
I think you can simply have some public interface like:
export function extend<T extends ClientVan | MiniVan<Element, Text> | VanPlate>(van: T): T

For Raw function, you can have something like:
type RawReturn<T extends ClientVan | MiniVan<Element, Text> | VanPlate> =
  T extends ClientVan ? DocumentFragment :
  T extends MiniVan<Element, Text> ? MiniVanDocumentFragment :
  PlateElement

export function Raw<T extends ClientVan | MiniVan<Element, Text> | VanPlate>(van: T, html: string): RawReturn<T>

Does it make sense to you?

That makes sense. I agree that .js + .d.ts simplifies things for library development while .ts has been good for app development. I like how having .js decoupled from the types allows "hidden" behavior while the types more-or-less represent the API of the library.
I appreciate you bringing up the 3 tradeoffs re: types. I think different development contexts weigh the tradeoffs differently from each other.
I have a large number of codebases to maintain, both open source & proprietary. Not many developers (if any) use these libraries. I experiment with some techniques & have had significant churn with the code with new libraries, techniques. I'm more concerned about managing isomorphic development across many codebases. I will need to be able to come back to a codebase after time passes (sometimes over a year later) & understand the code. My code bases have also gone through considerable development churn as the state of the art changes, better libraries are introduced, etc.
That being said, I favor flat architectures, consistent type systems, injecting context, reactive programming, modular global state management, custom code for simple behavior, simple dependencies backed by a skillful community for more complex behavior.
I'm not as concerned about some complexity in the types, assuming there is a coherent set of patterns to the types. I'm more concerned about balancing the 3 points depending on the development context. I don't think I can codify a rigid order of preference of the 3 tradeoffs you mentioned at this point.
That being said, I moved the types into https://github.com/btakita/van-type-delegate. I converted my website over to use VanJS. I left in the SolidJS components as well for comparison.
I have to say that I'm very satisfied with moving the components over to VanJS. I think it integrates very well with Astro. For example, within a *.astro or *.mdx component, I can use <Fragment> to render the VanJS component. It's nice to use plain old functions. A VanJS component in Astro does not support <slot>, but it's not a big loss. Using Astro <slot> in a framework (e.g. SolidJS) component has complicated progressive async rendering behavior.
I have a V_footnote & V_footnote_list components where the footnote html is stored & rendered in the V_footnote_list at the bottom of the page. The VanJS implementation is cleaner & more coherent than the Astro + SolidJS (or any other supported framework) implementation...Due to the simplicity of calling synchronous functions instead of working with progressive async rendering.
I'm tweaking van-type-delegate to make it as smooth as possible while providing adequate isomorphic type checking.

Thanks @btakita for sharing your context and perspective! And also thanks for your kind remark on VanJS. I'm really glad it provides you the developer experience you enjoy.
Regarding the support of asynchronous rendering, we have Await utility component in VanJS, thanks to @Hunter-Gu's contribution.


Create example using react-router.

I've seen a few instances where people are trying to use Horizon with react-router.
For it to work it requires all routes to be redirected to index.html. Creating some boilerplate which extends Horizon with koa, hapi, and express to do this I think would be helpful.

I wrote a tutorial about how to integrate React, React Router, Horizon.io with OAuth authentication, and Express:
http://tutorials.pluralsight.com/interesting-apis/building-a-real-time-application-with-react-react-router-horizon-io-and-oauth
The Github repo:
https://github.com/eh3rrera/react-horizon
It's not exactly a boilerplate but it's a simple app and using Koa or Hapi instead of Express should not be a problem.
Made the same comment in issue #534, I think they are related.


Roll engine 113b91fe82f1..e3f1bdc4dd41 (5 commits)

https://github.com/flutter/engine/compare/113b91fe82f1...e3f1bdc4dd41
git log 113b91fe82f147b3fb77899726736171c06dad26..e3f1bdc4dd4146cf7093492526cbe4e5525044e4 --no-merges --oneline
e3f1bdc4d Roll src/third_party/skia adfc6e40df30..4dbb96dfaa04 (6 commits) (flutter/engine#7970)
e32531f0e Switch flutter's dart sdk to full and add dartdevc libraries (flutter/engine#7968)
fb1c543dd Link dart:* sources into engine for debugger source support (flutter/engine#7908)
dd3656a51 Roll src/third_party/dart 0f9a5198bd..385be0cf31 (14 commits)
4434a39c7 Add api 21 check to LocalizationChannel.java (flutter/engine#7967)
The AutoRoll server is located here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff (garyq@google.com), and stop
the roller if necessary.

Trybots failed. These were the failed builds: https://cirrus-ci.com/task/4710305704706048

Commit queue failed; closing this roll.


[Wallet] Add support for 8 digits verification codes

Description
This PR implements short verification codes. See the demo below.
To enable this feature we need all the validators to support https, which is not the case atm, so this feature are disabled by feature flag.
Short code
Essentially, short code, which user receives consist of two parts: prefix and security code (e.g. 12345678: 1 - prefix, 2345678 - security code).
We use prefix to identify which issuer has sent the code. Because we can not store persistent mapping of prefix<>issuer on the client side (will be gone after reinstall), we are doing the following:

Set prefix to issuer's address mod 10 ([0,9]) and pass it with reveal request.
When we receive a short code with a prefix back, we create a list of validators which map to the same prefix.
We send security code to obtain attestation code to all issuers from the previous step
One of them should return a full attestation code, all others should fail.

This approach allows us to scale for more than 10 actionable attestations at the same time and to avoid changing Attestation.sol contract to store mapping prefix<>issuer in it.
Caveat
We do occasionally redundant requests with security code to wrong validators and those exposing the code itself and increasing waiting time for the user. For 3 SMSs the probability of this happening is 30%.
For more information see this discussion https://discord.com/channels/600834479145353243/732977310101405736/778336853505081344
Demo

Tested
With short codes enabled/disabled.
Related issues

Fixes #5384
Fixes #5394

Backwards compatibility
Yes

@aslawson @codyborn I've addressed all the feedback. Also, decided to make requests to obtain attestation code in parallel to all matching issuers in case of a collision, but without a retry.

I've addressed all the feedback. Lmk if there anything else, otherwise I would like to merge it tomorrow before 1.6.0 cut. Thanks!


Weird hang in msys2 makepkg after any interop in PKGBUILD

I have both msys2 and WSL installed, and I was creating a pkgbuild for the wslbridge in msys2:
https://ptpb.pw/1eW1
This PKGBUILD clones the wslbridge repo in the msys2 environment, then builds the frontend in msys2 and the backend in WSL.  However, I found that this hangs when checking the package.  If you kill msys2 and then enter the directory and do makepkg -R (which skips the build step), the part that was hanging works and the final package is built.  I also tried changing it to use any wsl command, not even make, and it still failed the packaging check.
To reproduce, install msys2, and in the msys shell, run the commands
pacman -Syu
pacman -S gcc mingw-w64-x86_64-gcc git curl
mkdir wslbridge
cd wslbridge
curl https://ptpb.pw/1eW1 > PKGBUILD
makepkg

It's not clear to me if this is a bug in the redirection code in WSL or some bug in msys2, or even in makepkg, but something is locking up, and it only happens after a WSL command is run in the build() section of the pkgbuild.
Windows 10 build 16179
PS This is definitely a case of a devtool failing in a crossplatform compilation scenario, so it seems exactly the kind of problem you'd like to look into.  As I mentioned earlier, the packaging step fails even if you just have WSL bash echo anything.

@fpqc - That weird hang occurs in "if find "${pkgdir}" -type f -print0 | xargs -0 grep -q -I "${srcdir}" ; then" line of /usr/share/makepkg/lint_package/build_references.sh file.
More strange thing is... if you split this make package job by "makepkg --noarchive" and "makepkg -R", building and packaging, there is no hang. I guess hidden something (maybe bash.exe? or cache?) hold the compiled binary.
BTW, there need not mingw-w64-x86_64-gcc depencancy in your package, so "makedepends=('gcc' 'make')" be more sutable.

@sunjoong Yeah, I realized it didn't require the mingw64 compiler after i made the pkgbuild but before I made this topic, and I didn't change it haha, but yeah, here's the weirdest part:
Even if the line that builds via WSL,
"$(cygpath -u "$SYSTEMROOT")/System32/bash.exe" -c "make"

is changed to
"$(cygpath -u "$SYSTEMROOT")/System32/bash.exe" -c "echo foo"

and the install line for wsl-backend is commented out, it still hangs in the same place, which makes me think it has something to do with the passing back and forth of the handle.

@fpqc - hang point is xarg program.
pkgname=dummy
pkgver=1
pkgrel=0
pkgdesc=dummy
arch=('any')

build() {
        echo "Hang?"
        $(cygpath -u "$SYSTEMROOT")/System32/bash.exe -c "echo foo"
        echo bar | xargs echo
        echo "If not, will hang."
}

package() {
        touch "${pkgdir}"/dummy
}

Above package source will hang in build(). If change "echo bar | xargs echo" line to "echo bar", hang occurs before package().

Could this be the same issue as #1973?

not sure. I don't think so because I think it still fails even when no file i/o happens at all, see @sunjoong 's minimal example above.  The WSL operation completes fine, but for some reason it messes up the subsequent xargs operation.
It's not clear to me or the msys2 devs why it's doing that (their bug or yours), but it only seems to be happening in scripts making use of WSL interop.

#!/bin/sh
/c/Windows/System32/System32/bash.exe -c "echo foo"
echo bar | xargs echo

Above script has hang. Below script do almost same thing but no hang;
#!/bin/sh
/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe -command "bash.exe -c 'echo foo'"
echo bar | xargs echo

@fpqc - this emergancy PKGBUILD will work;
# Maintainer: mar77i <mar77i at mar77i dot ch>
# Past Maintainer: Gaetan Bisson<EMAIL_ADDRESS># Contributor: Scytrin dai Kinthra<EMAIL_ADDRESS>
pkgname=wslbridge
_pkgname=wslbridge
pkgver=<IP_ADDRESS>.g744be74
pkgrel=1
pkgdesc='MSys2 Bridge for Windows Subsystem for Linux'
url='https://github.com/rprichard/wslbridge'
arch=('i686' 'x86_64')
license=('MIT')
makedepends=('gcc' 'make')
epoch=1
source=('git://github.com/rprichard/wslbridge')
sha1sums=('SKIP')

provides=("${_pkgname}")
conflicts=("${_pkgname}")

pkgver() {
        cd "${_pkgname}"
        git describe --tags |sed 's/-/./g'
}

build() {
        cd "${_pkgname}"
        cd frontend
        make
        cd ../backend
        bash -c "bash.exe -c make"
}

package() {
        cd "${_pkgname}"
        install -Dm755 out/wslbridge.exe "${pkgdir}"/usr/bin/wslbridge.exe
        install -Dm755 out/wslbridge-backend "${pkgdir}"/usr/bin/wslbridge-backend
}

BTW, what can we do with this bridge? Some example?

@sunjoong You can use the bridge to launch WSL with the Mintty terminal emulator or msys2-xterm  instead of conhost.exe (for various reasons, mainly buggy or not-yet-implemented control sequences, or problems passing keyboard commands when running in ConEMU).

The underlying issue with #1973 has to do with processes being terminated racing with signal delivery. It doesn't rely on input / output.

@benhillis It seems like pulling the output stream through an additional instance of (msys2) bash -c is fixing it, so maybe it's some kind of subtle incompatibility between their implementation of pipes and the WSL one?

@fpqc Could be, we'd have to debug this locally to see what's going on.

@benhillis @sunjoong By the way, sunjoong's fix doesn't actually seem to help. The reason why it worked is that it's actually not calling the WSL bash at all.

@fpqc - My bad.  I forgot there is also bash.exe in Msys2! Sorry.

@fpqc @benhillis - New script having no hang;
#!/bin/sh
echo | /c/Windows/System32/bash.exe -c "echo foo"
echo bar | xargs echo

It looks like magic.
@fpqc - New PKGBUILD;
# Maintainer: mar77i <mar77i at mar77i dot ch>
# Past Maintainer: Gaetan Bisson<EMAIL_ADDRESS># Contributor: Scytrin dai Kinthra<EMAIL_ADDRESS>
pkgname=wslbridge
_pkgname=wslbridge
pkgver=<IP_ADDRESS>.g744be74
pkgrel=1
pkgdesc='MSys2 Bridge for Windows Subsystem for Linux'
url='https://github.com/rprichard/wslbridge'
arch=('i686' 'x86_64')
license=('MIT')
makedepends=('gcc' 'make')
epoch=1
source=('git://github.com/rprichard/wslbridge')
sha1sums=('SKIP')

provides=("${_pkgname}")
conflicts=("${_pkgname}")

pkgver() {
        cd "${_pkgname}"
        git describe --tags |sed 's/-/./g'
}

build() {
        cd "${_pkgname}"
        cd frontend
        make
        cd ../backend
        echo | /c/Windows/System32/bash.exe -c make
}

package() {
        cd "${_pkgname}"
        install -Dm755 out/wslbridge.exe "${pkgdir}"/usr/bin/wslbridge.exe
        install -Dm755 out/wslbridge-backend "${pkgdir}"/usr/bin/wslbridge-backend
}

I checked it in WSL like this;
SUNJOONG-DESKTOP bin # file *
wslbridge-backend: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped
wslbridge.exe:     PE32+ executable (console) x86-64 (stripped to external PDB), for MS Windows
SUNJOONG-DESKTOP bin #

Taking word "better now". If there are other problems related to pipes and msys2 feel encouraged to reboot under a new issue.


GenericCollection.remove doesn't honor firstMatchOnly for >= MongoWireVersion.V26

DeleteElement always uses 1 as limit, which translates to firstMatchOnly = true
def remove[T](query: T, writeConcern: WriteConcern = WriteConcern.Default, firstMatchOnly: Boolean = false)(implicit writer: pack.Writer[T], ec: ExecutionContext): Future[WriteResult] =
Failover2(db.connection, failoverStrategy) { () =>
db.connection.metadata match {
case Some(metadata) if metadata.maxWireVersion >= MongoWireVersion.V26 =>
import reactivemongo.api.commands._
import BatchCommands.DeleteCommand.{ Delete, DeleteElement }
runCommand(Delete(DeleteElement(query, 1))).flatMap { wr =>

See #323


Refactor StructureMapExtractionContext to provide workerContext

IMPORTANT: All PRs must be linked to an issue (except for extremely trivial and straightforward changes).
Fixes #[issue number]
Description
Clear and concise code change description.
Alternative(s) considered
Have you considered any alternatives? And if so, why have you chosen the approach in this PR?
Type
Choose one: (Bug fix | Feature | Documentation | Testing | Code health | Builds | Releases | Other)
Screenshots (if applicable)
Checklist

[x] I have read and acknowledged the Code of conduct.
[x] I have read the Contributing page.
[x] I have signed the Google Individual CLA, or I am covered by my company's Corporate CLA.
[x] I have discussed my proposed solution with code owners in the linked issue(s) and we have agreed upon the general approach.
[x] I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the style guide of this project.
[x] I have run ./gradlew check and ./gradlew connectedCheck to test my changes locally.
[x] I have built and run the demo app(s) to verify my change fixes the issue and/or does not break the demo app(s).

closing this in favour of #2280
thanks nitin for the work - even though we're not merging this pr this really furthered our understanding of the issue and hopefully we can improve the knowledge manager and sdc lib apis as a result!!! thank you very much!


cannot build 0.0.18 on Ubuntu

cat /etc/os-release
VERSION="18.04.6 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.6 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

error
 App •  DONE  • "Main" compiled with errors • 25022ms

 App •  ERROR  •  Main  in /home/nikita/ddos/uashield/src-worker/external/proxyPool.ts

[tsl] ERROR in /home/nikita/ddos/uashield/src-worker/external/proxyPool.ts(1,10)
      TS2614: Module '"axios"' has no exported member 'Axios'. Did you mean to use 'import Axios from "axios"' instead?

 App •  ERROR  •  Main  in /home/nikita/ddos/uashield/src-worker/external/proxyPool.ts

[tsl] ERROR in /home/nikita/ddos/uashield/src-worker/external/proxyPool.ts(34,27)
      TS7006: Parameter 'data' implicitly has an 'any' type.

 App •  ERROR  •  Main  in /home/nikita/ddos/uashield/src-worker/external/targetsPool.ts

[tsl] ERROR in /home/nikita/ddos/uashield/src-worker/external/targetsPool.ts(1,10)
      TS2614: Module '"axios"' has no exported member 'Axios'. Did you mean to use 'import Axios from "axios"' instead?

 App •  ERROR  •  Main  in /home/nikita/ddos/uashield/src-worker/external/targetsPool.ts

[tsl] ERROR in /home/nikita/ddos/uashield/src-worker/external/targetsPool.ts(33,27)
      TS7006: Parameter 'data' implicitly has an 'any' type.

 App •  ERROR  •  Main  in /home/nikita/ddos/uashield/src-worker/algorithms/simpleHTTP.ts

[tsl] ERROR in /home/nikita/ddos/uashield/src-worker/algorithms/simpleHTTP.ts(2,33)
      TS2307: Cannot find module 'socks-proxy-agent' or its corresponding type declarations.

 App •  ERROR  •  Main  in /home/nikita/ddos/uashield/src-worker/algorithms/utils/httpHeadersUtils.ts

[tsl] ERROR in /home/nikita/ddos/uashield/src-worker/algorithms/utils/httpHeadersUtils.ts(1,23)
      TS2307: Cannot find module 'user-agents' or its corresponding type declarations.

 App •  COMPILATION FAILED  • Please check the log above for details.

Hi. this is headless version?

@Nikita-Chernenko

Install yarn
Pull changes
Build the project with the same commands but replace npm with yarn

As @iostreamchik said - everything should work with yarn. @Nikita-Chernenko , try with latest version and let us know - we will close issue :)


[ZEPPELIN-5144] Jupyter conda python packages

What is this PR for?
This PR includes:

checkKernelPrerequisite does not fail if the Python packages are installed with conda
Fixes the following Python bug with an additional if check

ERROR [2020-11-24 10:50:23,995] ({grpc-default-executor-2} JupyterKernelClient.java[onError]:231) - Fail to call IPython grpc
io.grpc.StatusRuntimeException: UNKNOWN: Exception iterating responses: 'payload'

What type of PR is it?

Bug Fix

Todos

[x] - Test with CI

What is the Jira issue?

https://issues.apache.org/jira/browse/ZEPPELIN-5144

How should this be tested?

TODO with CI

Questions:

Does the licenses files need update? No
Is there breaking changes for older versions? No
Does this needs documentation? No

Only manually tested without CI.

Now tested with CI.
Since the Conda-Check is necessary for a clean CI with GitHub-Action, I 'll merge this soon in Master and Branch-0.9


Can slideoutpage dismiss amount be modified?

Can the amount someone moves the image to initiate the close of the image be modified?  By default the image has to be moved up a lot to dismiss the image, I'd like it to be a less amount
Thanks!!

please read readme first

I did read it over and over but its not totally clear.  My assumption is that it has to do with slideOffsetHandler but the documentation does not describe how to use it, nor are there any examples of it
Thanks


Presentation Resources

Students can create a new slide on their experience or one of the topics that they have learned till now

We will edit this issue a little. :sweat_smile:

@DrishyaR, please have a look at this.
I hope you will come up with a PR soon. :smile:


[EAGLE-982] The log length has exceeded the limit of 4 MB in Travis

Maven throw too many warnings for checking Code Style in Travis. Should we disable it for a while until we fix those Code Style issues?
The log length has exceeded the limit of 4 MB (this usually means that the test suite is raising the same exception over and over).
The job has been terminated

(https://issues.apache.org/jira/browse/EAGLE-982)

@asdf2014 , can u please squash the commits ?

@jhsenjaliya Already done.

Those changes about .travis.yml file shouldn't effect Jenkins. It seems like the maven-surefire-plugin throw a ExecutionException to make this build process failed.
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on project eagle-app-streamproxy: ExecutionException The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
[ERROR] Command was /bin/sh -c cd /home/jenkins/jenkins-slave/workspace/incubator-eagle-pr-reviewer/eagle-core/eagle-app/eagle-app-streamproxy && /usr/local/asfpackages/java/jdk1.8.0_121/jre/bin/java -XX:-UseGCOverheadLimit -jar /home/jenkins/jenkins-slave/workspace/incubator-eagle-pr-reviewer/eagle-core/eagle-app/eagle-app-streamproxy/target/surefire/surefirebooter8929133803599728653.jar /home/jenkins/jenkins-slave/workspace/incubator-eagle-pr-reviewer/eagle-core/eagle-app/eagle-app-streamproxy/target/surefire/surefire4241285850518905830tmp /home/jenkins/jenkins-slave/workspace/incubator-eagle-pr-reviewer/eagle-core/eagle-app/eagle-app-streamproxy/target/surefire/surefire_2332892144259826349419tmp

@asdf2014 please squash the commits again and I should merge this.


Don't fail sidecar validation on missing port name

Fixes #12396
/assign @rshriram

@ymesika: GitHub didn't allow me to assign the following users: rshriram.
Note that only istio members and repo collaborators can be assigned.
For more information please see the contributor guide

In response to this:

Fixes #12396
/assign @rshriram

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/test-infra repository.

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: ymesika
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

pilot/OWNERS [ymesika]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@ymesika: GitHub didn't allow me to assign the following users: rshriram.
Note that only istio members and repo collaborators can be assigned.
For more information please see the contributor guide

In response to this:

/assign @rshriram

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/test-infra repository.

Appreciate the regression test. Thanks! LGTM.

@ymesika: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-integ-k8s-tests.sh
67b7ecfe31bc9d01f50ab9b27c98c4533436dd74
link
/test istio-integ-k8s-tests

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/test-infra repository. I understand the commands that are listed here.

@ymesika: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-integ-k8s-tests.sh
67b7ecfe31bc9d01f50ab9b27c98c4533436dd74
link
/test istio-integ-k8s-tests

prow/istio-pilot-multicluster-e2e.sh
67b7ecfe31bc9d01f50ab9b27c98c4533436dd74
link
/test istio-pilot-multicluster-e2e

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/test-infra repository. I understand the commands that are listed here.


nixos: nginx.resolver.ipv6 defaults to true even if networking.enableIPv6 is false

Describe the bug
nginx.resolver.ipv6 setting in nginx NixOS module is always set to true by default even if IPv6 is disabled on the networking level.
This then can give pretty cryptic and intermittent failures when using it for proxying or whatever else.
Steps To Reproduce
Steps to reproduce the behavior:
Set networking.enableIPv6 = false. Set something in services.nginx.resolver.addresses. Check the generated nginx config and note that it doesn't add ipv6=off to resolver line.
Expected behavior
It should probably ipv6=off automatically, especially as we already have the enableIPv6 value visible in the module and used for other stuff.
Metadata
I'm on
      url = "https://github.com/NixOS/nixpkgs/archive/5ae933ec0d684e382ee12971de262583524e4538.tar.gz";

Notify maintainers

Note for maintainers: Please tag this issue in your PR.

Add a :+1: reaction to issues you find important.

#368055


fix: displaying invalid material in editor again

Description
Editor never showed the invalid material in inspector

:tada: This PR is included in version 1.8.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Log the proper remote repo for the signatures on verify

Summary
Currently we print the image repo being signed as if we were pushing the
signatures to that same repo, which could lead to users being surprised.
Instead try to get the override and print that instead
Ticket Link
Resolves: #1242
Release Note
NONE

woops sorry, I thought the make golangci-lint would run the linter, seems like it only installs it.


Download study as a zip file of dcm files.

User story
As a user, I want to download all the raw dicom files so that i can view them in my local dicom viewer workstation.
Acceptance criteria

API which will take study id as input and generate zip file to download.

Hi @ashutosh1211, have you looked into our export feature here?

Yes, but it works on blob to blob export, I need to export it as a zip file.

The bulk export API takes a study ID as input, according to your specifications. It then retrieves all the corresponding blobs and stores them in a designated storage account. However, please note that our current feature set does not include the ability to download the blob as a zip file.

Its common requiment of radiologists where they want to view these DICOM files on their preferred workstation.

Each study instance can have a maximum size of up to 4 GB. It is not recommended to download multiple instances in a single API response, as doing so could unnecessarily burden your application server. Instead, consider using the metadata API to retrieve individual study instance UIDs and then use the WADO API for each of them separately.


run this just once!?

thanks for the library
I use it as my main activity! and start another activity in the last page of pager!
would you please tell me how to run this just once when app is recently installed?! and hide it next runs!?

I recommend to not make this in your mainActivity.
In onCreate of mainActivity, check for a boolean in sharedpreference. If boolean doesn't existe, it means that is first time application is open. Save this value to true, and open, for example, "DemoActivity".
This is a example to check if it's first time app is opening : http://stackoverflow.com/questions/4636141/determine-if-android-app-is-the-first-time-used
"DemoActivity" implement demo of your app with this library.
You can listing to last page with "ViewPager.OnPageChangeListener" on viewpage, and check for last page to close your DemoActivity and go back to your mainActivity.

thanks :)
but it would be much better if you implement this in your example app... I mean that demo activity and the way it comes back to main activity...


Address overlaps with bytes in Hex view

This should be easy to fix though. It is correct in linear view

fixed


How to update missing definitions from imported libraries?

In pycharm you are able to directly jump to the function you called in different libraries

pycharm

but in vscode pylance it shows that there is "No definition found".

vscode

is there a similar or same setting I can enable in vscode to allow for the full indexing of the imported library? This issue also fails to autocomplete most functions.

pylance enabled

Version: 1.69.0 (user setup)
Commit: 92d25e35d9bf1a6b16f7d0758f25d48ace11e5b9
Date: 2022-07-07T05:28:36.503Z
Electron: 18.3.5
Chromium: 100.0.4896.160
Node.js: 16.13.2
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.18362

My guess is 'submission' or 'mod' type is unknown.
might need to do something like this
m:XXX = submission.mod

where XXX is the type of mod

could also try generating type stubs. see https://github.com/microsoft/pyright/blob/main/docs/type-stubs.md#generating-type-stubs

could also try generating type stubs. see https://github.com/microsoft/pyright/blob/main/docs/type-stubs.md#generating-type-stubs

Generating Type Stubs doesn't seem to make it better, rather it seems to make it worse as I'm unable to even jump to the r.submission() function like before.

vscode Type Stubs

pycharm jumping to `.mod` function

Adding a type also didn't work.


support size: % and auto when no sprites set

Support size: % and size: [px, auto] when no sprites set, to match ES implementation.
https://github.com/tangrams/tangram-es/blob/43efd63c69d1c018c80ee00bb8eab33f7788168b/core/src/style/pointStyleBuilder.cpp#L350
Related:

https://github.com/tangrams/tangram/issues/438
https://github.com/tangrams/tangram/pull/234

Just a clarification here, no sprite but a texture is used in a draw rule.

@tallytalwar Double-checking: this is the current ES behavior, correct?

Yes, gone through all the issues you have created, the examples you mentioned in those do work in ES. So yes it is the current ES behavior.
Thanks

How about #641? Does 'density' still apply to a texture with no sprites?

Yup it does.
Refer: https://github.com/tangrams/tangram-es/blob/master/core/src/style/pointStyleBuilder.cpp#L313
The size is set using the density if it is determined to have a texture. And then is updated based on the sprite information (using the same texture density) if a sprite is mentioned in the draw rules.


Mobile menu

[ ] This pull request enhances the layout and responsiveness of the website by implementing the following changes:

When the user clicks (or taps) the hamburger button, the mobile menu appears.

When the user clicks (or taps) the close (X) button, the mobile menu disappears.

When the user clicks (or taps) any of the mobile menu options, the mobile menu disappears.

When the user clicks (or taps) any of the mobile menu options, a correct part of the page is displayed.

Ensured adherence to the design provided in the Figma templates, focusing on maintaining consistency with regards to fonts, colors, images, text, and margins.

@joel-kalema Hi, in the dashboard it says required changes. How can I submit the work?


Usage of @EnableJpaRepositories breaks entity scan package re-configuration

Without @EnableJpaRepositories:
INFO 11928 --- [           main] figurationAndEntityScanPackageCustomizer : Re-configuring auto-configuration and entity scan packages to: com.scheible.modulith.service, com.scheible.modulith.infrastructure, com.scheible.modulith.firstfeature.
INFO 11928 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Bootstrapping Spring Data JPA repositories in DEFAULT mode.
INFO 11928 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Finished Spring Data repository scanning in 86ms. Found 1 JPA repository interfaces.

With @EnableJpaRepositories:
INFO 1872 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Bootstrapping Spring Data JPA repositories in DEFAULT mode.
INFO 1872 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Finished Spring Data repository scanning in 98ms. Found 3 JPA repository interfaces.
INFO 1872 --- [           main] figurationAndEntityScanPackageCustomizer : Re-configuring auto-configuration and entity scan packages to: com.scheible.modulith.service, com.scheible.modulith.infrastructure, com.scheible.modulith.firstfeature.

With @EnableJpaRepositories there is an order problem. The Spring Data repositories are scanned before the re-configuration. This leads to Caused by: java.lang.IllegalArgumentException: Not a managed type: class com.scheible.modulith.secondfeature.SecondEntity. The issue https://github.com/odrotbohm/moduliths/issues/4 seems to be related.
The main difference I can see is that without @EnableJpaRepositories RepositoryConfigurationDelegate#registerRepositoriesIn(...) is called by ModuleTestAutoConfiguration.AutoConfigurationAndEntityScanPackageCustomizer#registerBeanDefinitions(...) whilst with the annoation it is called by RepositoryConfigurationDelegate.registerRepositoriesIn(...).
The Spring Boot version is 2.2.5.RELEASE. The moduliths version was from master.

Would you mind verifying whether that's still the case in 1.1 milestone and/or snapshots?

With Spring Boot 2.4.2 and Moduliths 1.1.0-M1 it works (means no error occurs) with and without @EnableJpaRepositories. Thanks!
But it looks like there was a regression introduced. For me #4 strikes again now.
With Spring Boot 2.1.8, Moduliths 1.0.0.BUILD-SNAPSHOT and without @EnableJpaRepositories, only the repositories for the corresponding modules were scanned, whereas with Spring Boot 2.4.2 and Moduliths 1.1.0-M1 (with and without @EnableJpaRepositories), always all repositories are scanned.
Started trying the previous versions and I was in luck: With Spring Boot 2.3.3 and Moduliths 1.0.0 @EnableJpaRepositories usage is already broken again, but the regression of #4 is also gone when omitting @EnableJpaRepositories.
That means  @EnableJpaRepositories usage was fixed in Moduliths 1.1.0-M1 but unfortunately the regression of #4 was introduced.

Please give the latest snapshots a spin. Spring Boot 2.4 changed the way the autoconfiguration packages are handeled and our customizations were applied too late or the wrong what depending on how you look at it. That's been fixed with #153, also due with the imminent RC release.

With Moduliths 1.1.0-SNAPSHOT the regression of #4 is gone. Only the relevant repositories are scanned now.
But unfortunately @EnableJpaRepositories annotation breaks it again with:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'firstRepository' defined in com.scheible.modulith.firstfeature.FirstRepository defined in @EnableJpaRepositories declared on ModulithApplication: Invocation of init method failed; nested exception is java.lang.IllegalArgumentException: Not a managed type: class com.scheible.modulith.firstfeature.FirstEntity

Can you summarize the required constraints and context? Does the annotation have to live in a special place to make this break?
Wouldn't mind a quick reproducer, either.

I prepared a minimal example in https://github.com/janScheible/moduliths-with-enable-jpa-repositories-test.
As soon as there are 2 modules with a JPA repository the problem occurs when executing the tests.
It doesn't matter if I place the @EnableJpaRepositories on the application class or on a @Configuration class.
The test without @ModuleTest works. Running the application also works.

That's very helpful, thanks. At a quick glance, the culprit is the following:

@EnableJpaRepositories on the EnableJpaRespositoryTestApplication class manually enables Spring Data JPA repositories for the base package.
@ModuleTest tweaks Boot's autoconfiguration to limit the entity scanning to the module package.

These two are obviously at odds and I haven't yet made up my mind on how the resolve that. Moving @EnableJpaRepositories to dedicated configuration classes in the module base packages should do the trick as a workaround.
What's the reason you manually declare @EJR on the root package?

To be honest the sole purpose of using @EnableJpaRepositories was to specify enableDefaultTransactions=false. I was not able to find any other way (like for example a property) to set that.
I can confirm that moving the @EnableJpaRepositories annotated @Configuration classes to the modules worked.
Thank you for having a look at it.


display name of the receipes

This dev tasks is still open and unassigned, bc we moved the whole user story to future work.


Distribute opencv4.5 with non-free xfeatures2d opencv_contrib modules

This basically re-implements https://github.com/ros-gbp/opencv3-release, to take us from opencv3 to opencv4.5
These are roughly the steps I took to make this:

Fork opencv, and clone opencv_contrib separately
Copy opencv_contrib/modules into opencv_Contrib in new opencv
Copy package.xml from opencv3-release debian/kinetic branch into this

Had to update python to python3, use our python-numpy-pip spec, update version specs to 4.5.0
Had to hack up the CMakeLists.txt, enable nonfree, basically doing everything they did in opencv3-release

Add FARMWISE_CHANGELOG

If we are lucky we can close this PR in favor of switching to ORB over SURF / SIFT for feature description. We're looking at that in farmwise_main at the moment.


gnu: show the comment if something changed

it doesn't work because of limitation of github:
https://github.com/actions/first-interaction/issues/10


community-profiles: potsdam - changed SSID

Like PR #1650 for the master branch.
After some discussion in our meetings and on the maling list we decided to
change the SSID to a fixed one.
Signed-off-by: Hannes Fuchs<EMAIL_ADDRESS>

Thank you @hnyman


cannot get and set a signal within the same reactive context

The following example panics at already borrowed.
use leptos::*;
use wasm_bindgen::prelude::*;

#[wasm_bindgen(start)]
pub fn start() {
  console_error_panic_hook::set_once();

  mount_to_body(view_fn);
}

fn view_fn(cx: Scope) -> impl Mountable {
  let (a, set_a) = create_signal(cx, false);

  create_effect(cx, move |_| {
    if !a() {
      set_a(true);
    }
  });

  view! { cx,
    <h1>"Hello"</h1>
  }
}

Yeah so this is working as designed, but perhaps should be better documented. This is why I give the advice to avoid setting signals within effects, but rather to derive a signal—it's very easy to create an infinite loop if you do this, and it's basically useless. Your example defines a as false but then immediately, synchronously sets it to true.
Is there a less simple use case you can provide where you might actually want to do this?
Logically it's the equivalent of
let a = RefCell::new(false);

if !a.borrow() {
  *a.borrow_mut() = true;
}

and panics for more or less the same reason.

Yes, of course, this was an min-repro.
I ran into this in the following situation.
I have a list of users, that can potentially change at any time. Let's call this signal users: Vec<User>. I need to create a bool for each user to see if they are selected or not. Let's call this signal selected_users: Vec<bool>. Since the number of users can change, I need to be able to update the size of selected_users, but cannot do this without panicking.
I know one solution would be to move the logic which adjusts the size of the selected_users into it's own effect, but I need this effect to be guaranteed to run before another effect, otherwise I'll break the size invariant, and there's no current way to make sure an effect runs before another.
Here's the above example in more concrete code:
let users_view = move || {
  let users: Vec<User> = users(); // Signal

  if users.len() != selected_users().len() {
    set_selected_users(vec![false; users.len()]);
  }

  users
    .into_iter()
    .map(|u| view! { cx, /* view stuff */})
    .collect::<Vec<_>>()
};

The update function (instead of the set function) gives you a mutable reference to the current value: since users() is the only dependency the below should work fine, shouldn't it?
let users_view = move || {
  let users: Vec<User> = users(); // Signal

  set_selected_users.update(|selected_users| {
    if users.len() != selected_users.len() {
      selected_users. /* whatever the logic is to trim it */
    }
  });

  users
    .into_iter()
    .map(|u| view! { cx, /* view stuff */})
    .collect::<Vec<_>>()
};

I'd probably recommend either bundling selected users and users into one Vec<(User, bool)> but I think the solution I posted should work.

Yes, the update method you suggested above would totally work, but if I may ask, how does it actually work in the implementation?
The example you provided of
let a = RefCell::new(false);

if !*a.borrow() {
  *a.borrow_mut() = true;
}

would not actually panic in practice, because the immutable borrow is dropped as soon as the if is evaluated. I would expect the same behavior to persist within an effect; that is, when you get a signal, it borrows it mutably and immediately releases the borrow, therefore, when a subsequent mutable borrow occurs, it's the sole reference, and therefore will not panic.

Oh you're right of course, about the RefCell parallel.
The reason it doesn't work in the example you gave is
create_effect(cx, move |_| {
  if !a() { // now the effect depends on
    set_a(true);
  }
});

It panics because running an effect, at the moment, mutably borrows the effect function, because create_effect() takes FnMut(Option<&T>) -> T.  set_a() triggers the effect to run again, but the effect function is already borrowed mutably.
So the rule is more like "you can't trigger an effect to re-run from within an effect."

It's possible that effect functions don't need to be FnMut; they can take Fn and you can always wrap a value being moved into it in a RefCell if you need to mutate it.
Let me try to make this change and see if it a) fixes the bug and b) still lets everything else work.
And thanks for pushing on this!

This should be resolved now by #90. Thanks again.


Methods in Simplifier.cs that only access read-only members were made readonly

By doing this, the compiler enforces that no members will be modified by simply calling the method

Why don't you also mark the struct as readonly then

Either way works... and doesn't change anything XD


on possible (minor) tweaks to Annotation.to_samples

holy moly I can't thank past us (but mostly @bmcfee and @justinsalamon) for making #109 happen, just bailed me out of an annoying issue I'm having with open-tag JAMS and issues around what to do with null events (separate issue, will cease tangent).
In working with this super useful feature, I've a couple ideas / questions for the crowd. Not super confident these are worth the effort yet, but this is why this is a question and not a PR..

What if the instantaneous values object is a tuple instead of a list? This would aid in the reuse of other objects (e.g. set, collections.Counter) which need a hashable type for reduction. This wouldn't necessarily be super useful for continuous / float values, but categorical (e.g. tags, like in my case) would be way helpful. The two counterarguments I see are: I understand from looking at the source how a mutable list makes this so much easier to implement; and, if this isn't a standard case, it's easy enough to lambda-map the results into a hashable type after and then do this.
Thoughts on adding a fill_value field to the method's interface? In my case, only positive intervals are labeled, and so I get back empty lists where there is no range. It'd be great to backfill the null class at sample time, and at first blush this seems like an easy feature ... the only issue I see is, what default parameter would give the current result? It can't be None, because one could truly want None as the backfill value, e.g. [[None], [None], ... ]. It shouldn't be [], because semantically one would expect [[[]], [[]], ... ]. Any ideas on this one?

If nothing else, I skimmed the issue that originally spawned this feature, and didn't see a discussion of either (1) or (2) above, and figured they'd be worth adding to the conversation. Tagging this as wontfix is a potentially fine outcome.

The two counterarguments I see are: I understand from looking at the source how a mutable list makes this so much easier to implement; and, if this isn't a standard case, it's easy enough to lambda-map the results into a hashable type after and then do this.

I'm leaning toward leaving it as is.  Tuples, being immutable, can be a little unwieldy for a lot of the things we want to use values outputs for (eg slicing down to a fixed vocab).

2. Thoughts on adding a fill_value field to the method's interface? In my case, only positive intervals are labeled, and so I get back empty lists where there is no range. It'd be great to backfill the null class at sample time, and at first blush this seems like an easy feature ... the only issue I see is, what default parameter would give the current result

I like this in theory, but as you say, the API for it seems awkward, especially when you consider that it should be consistent across all namespaces.  You could do it in two steps by having a flag to control backfill, and a separate fill_value parameter to handle the data itself.

yea, flag + fill_value seems a little unwieldy? it's not terrible to do these things on the user side .. i'm happy to punt for now, and if this ends up becoming a more common use case / pattern, we can figure it out then.

No, but you raise a valid point about the semantics of annotation sampling.
It's presently written from the perspective of positive-only annotations, and null/empty labels are only generated by sampling if there's an observation to that effect.  This is the most conservative form of sampling, and it's not incorrect per se, but it's also not exactly what you want when integrating with sklearn (or whatever) where every input should have an output.

Resurfacing this one too see if anyone's perspective has changed. Should we try to implement a fill parameter? Or leave it as is?
It might be possible to check the fill value against the namespace schema at runtime, but that might get ugly moving forward if we unify all the namespace schemas into one master schema going forward.
Alternately, we could just not validate fill values.

My 2 cents: given that the current implementation returns a list of lists, instead of fill_value, we could have empty_values as an argument. This would represent whatever you want to do with empty values, with [] as default. It'd be the same thing, but semantically makes potentially more sense.
And then, I would simply not validate these custom empty values, let the user take care of it if needed.

And then, I would simply not validate these custom empty values, let the user take care of it if needed.

I guess that's valid.  If a user supplies a bad fill value, that's on them.
So to recap, here's the current logic:

Generate an array of sample positions
Initialize a value for each sample position as an empty list. (Repeat for confidences.)
For each observation, get its value, and append it to each list corresponding to a sample time that lands within the observed interval. (Repeat for confidences.)

The reason for all the list hackery is that observations can overlap, so the to_samples definition for a value at time t is the union of value fields.  Any sample that's outside of any labeled interval retains the empty list as its values.
The proposed change would allow a user to change this by providing a list of default values that it initializes with instead of the empty list.  In writing this up, I see two problems with this idea that had escaped my attention before:

Are fill values retained for non-empty samples?  Or do we only fill when the output would be otherwise empty?  The former is easier programmatically, but the latter might be more what the user would expect.  I really don't know here.
What do we do with confidences?  Another parameter with the same kind of logic?

I'm beginning to think this not worth implementing.  It's easy enough for a user to post-process the values array as follows:
values = ann.to_samples(...)
for v in values:
    if not v:
        v.extend(default_values)
# and repeat for confidences

and then get on with their life.  I think I prefer this solution over trying to implement something general-purpose that leads to awkward and confusing API decisions.


Script for Windows not working

trying to follow this: https://petvana.github.io/AutoSysimages.jl/stable/install/#Script-for-Windows and getting the below error
C:\Users\aryan\Documents\AutoSysimages.jl\scripts>cd windows

C:\Users\aryan\Documents\AutoSysimages.jl\scripts\windows>./asysimg.bat
'.' is not recognized as an internal or external command,
operable program or batch file.

C:\Users\aryan\Documents\AutoSysimages.jl\scripts\windows>asysimg.bat
'"C:\Users\aryan\Documents\AutoSysimages.jl\scripts\windows\\julia.exe"' is not recognized as an internal or external command,
operable program or batch file.

The last one seems to work, but is unable to find Julia in your PATH. Are you able to run Julia from the same terminal? When you install Julia using installer, there is an option to add it to the PATH.
Also, it should be possible to use both asysimg.bat or only asysimg.bat for short.
(I'm not big fan of Windows, so this may not be tested well, sorry for that.)

@petvana I am using juliaup from Microsoft Store. Do you think that's an issue?

@petvana I am using juliaup from Microsoft Store. Do you think that's an issue?

That is weird, it should be in the PATH according the docs in https://github.com/JuliaLang/juliaup

Once you have installed Juliaup, julia is on the PATH, and on Windows there is a start menu shortcut and it will show up as a profile in Windows Terminal. Any of those will start Julia. The VS Code extension will also automatically find this Julia installation.

@petvana looks like it can't access ENV variables

Xref: #14

@AbhimanyuAryan Seems this can be fixed by #17 that sets an absolute path to the Julia binary into asysimg script when calling AutoSysimages.install().

@petvana are you planning to merge this and tag new release?

also why not use Sys.BINDIR for all of these? Checking on Ubuntu WSL with juliaup
https://github.com/petvana/AutoSysimages.jl/blob/c8bfb5dccced031d0e6701dbebb3534864c6129b/src/AutoSysimages.jl#L377-L387
I think a lot of people use juliaup instead of installing directly using deb, exe or dmg

I think a lot of people use juliaup instead of installing directly using deb, exe or dmg

Well, I use jill... Much better than juliaup on Linux...

I think a lot of people use juliaup instead of installing directly using deb, exe or dmg

Well, I use jill... Much better than juliaup on Linux...

Not sure link please?

https://github.com/johnnychen94/jill.py

https://github.com/johnnychen94/jill.py

But this has Python as deps. Windows doesn't really come with Python pre-installed so isn’t it even easier to get juliaup with a winget and not have Python at all?

Yes, on Windows juliaup might be easier... But you you get the latest release only with some delay because you need to update juliaup first which is not required with jill...

And sys.BINDIR() would not work on Linux due to the use of symbolic links...


Add a new perf test

Description of changes:
Testing adding a new perf test.
Resolved issues:
Related RFC:

Optional #ISSUE-NUMBER.
Call-outs:

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

It looks like benchcomp has an issue with diffs in the test suite. 😔

Yes, I noticed that in #2210, and filed this PR to reproduce the issue. I created #2424 to track this.


Multi-Server Deploy

Any improvement on multi server deployment? (not working at all)
I still do it one by one (working) but if someone got a solution, I'll take it.
Thanks!

Same problem...
Any news?

Same on my side, would appreciate a fix.

I have a branch where I fixed the issue by deploying in series rather than in parallel.
https://github.com/clayne11/meteor-up/tree/multi-server-deployment
There must be a race condition somewhere. Not sure about the race condition but at least this fixes the issue.


feature(OcAgentExpoter): Allow to setup the service name from a window variable.

Please refer to #155 for more context.

Codecov Report

Merging #157 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #157   +/-   ##
=======================================
  Coverage   96.01%   96.01%
=======================================
  Files          30       30
  Lines         853      853
  Branches      147      147
=======================================
  Hits          819      819
  Misses         34       34

Impacted Files
Coverage Δ

src/export-initial-load.ts
90% <0%> (ø)
:arrow_up:

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 dd53697...9f49ac5. Read the comment docs.

@googlebot I signed it!

@googlebot please recheck the CLA!

After I get this merged I will also do another release

Great so it will solve the npm issue right ?

Yes, it should. I'm not sure why the CLA bot seems to be moving slowly. I'll see if I can find anything else about it.

Regarding the CLA, is it possible that your commit doesn't have an email address associated with it, or the email your using isn't tied to your GitHub account? See https://opensource.google.com/docs/cla/#troubleshoot

(It's also possible the CLA bot is just running slowly. I'll check back later today on it if it doesn't resolve soon as I have a number of meetings today)

@googlebot I signed it!
Just updated it


Download official binaries

I saw that the README was changed for nodenv and it reminded me to open an issue to first download the official binaries and compile as a fallback, instead of always compiling. I browsed through wfarr's version and found where it does the download. Hopefully this helps, as I don't know enough to incorporate this myself.

@peterkc would you be able to submit a PR to incorporate precompiled binaries into the built-in definitions somehow? (does ruby-build already do something like this? how does it handle the target platform)
This precompiled binary feature is currently blocking getting @OiNutter's nodenv/node-build into homebrew has the default nodenv formula.

Jason,
I will do it today.

Peter C

On Mar 27, 2015, at 08:10, Jason Karns<EMAIL_ADDRESS>wrote:
@peterkc would you be able to submit a PR to incorporate precompiled binaries into the built-in definitions somehow? (does ruby-build already do something like this? how does it handle the target platform)
This precompiled binary feature is currently blocking getting @OiNutter's nodenv/node-build into homebrew has the default nodenv formula.
—
Reply to this email directly or view it on GitHub.

here's an existing discussion on ruby-build for doing binaries: https://github.com/sstephenson/ruby-build/issues/42

any news on this??

BINARIES!!! 474e872d9acd5cc61c909f58d1521626d8c9d385

Awesome :heart: :fireworks:


http://cup.iobusy.com 不能访问

http://cup.iobusy.com 不能访问

是不是 github 被墙了?   因为部门是用的 github page.    有时候也许会不稳定,  原因是你懂的哈
Regards,
Gallon (Guannan) Ma

https://github.com/baidu/CUP  (Common Useful Python Lib's waiting for
you to discover)
On Tue, May 14, 2019 at 10:28 AM fank<EMAIL_ADDRESS>wrote:

http://cup.iobusy.com 不能访问
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/baidu/CUP/issues/34?email_source=notifications&email_token=AAFA5OLLR2ODHAOT2LEA2UDPVIPVVA5CNFSM4HMU35BKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GTSBDHQ,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFA5OIFL2LVZASFPZMVRC3PVIPVVANCNFSM4HMU35BA
.

是不是 github 被墙了? 因为部门是用的 github page. 有时候也许会不稳定, 原因是你懂的哈 Regards, Gallon (Guannan) Ma
…
--- https://github.com/baidu/CUP (Common Useful Python Lib's waiting for you to discover)
On Tue, May 14, 2019 at 10:28 AM fank @.***> wrote: http://cup.iobusy.com 不能访问 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#34?email_source=notifications&email_token=AAFA5OLLR2ODHAOT2LEA2UDPVIPVVA5CNFSM4HMU35BKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GTSBDHQ>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFA5OIFL2LVZASFPZMVRC3PVIPVVANCNFSM4HMU35BA .

果然是这个原因，谢谢

:)


Fix in Makefile of 00-warmup assignment

This fixes the make turnin in Makefile

Thanks. (What was the issue?)


Use URI.escape instead of CGI.escape for vcr passwords

Re-align our VSAC Password escaping to be the same as in Bonnie.  It was changed due to a rubocop suggestion that turns out was incorrect.
Submitter:

[x] This pull request describes why these changes were made.

Codecov Report

Merging #20 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #20   +/-   ##
=======================================
  Coverage   82.76%   82.76%
=======================================
  Files          99       99
  Lines        4665     4665
=======================================
  Hits         3861     3861
  Misses        804      804

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 8f628ae...6a5cce6. Read the comment docs.


Error: Content and Map of this Source is not available (only size() is supported)

Command
serve
Is this a regression?

[ ] Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was
No response
Description
When I run my Angular(v16.1.1) project using ng serve -o, I get the following error sometimes(Not always).
Can someone please clarify this issue.

Thanks a lot!
Minimal Reproduction
ng serve -o
Exception or Error
✔ Browser application bundle generation complete.

Initial Chunk Files   | Names         |  Raw Size
vendor.js             | vendor        |   2.28 MB |
polyfills.js          | polyfills     | 332.98 kB |
styles.css, styles.js | styles        | 231.20 kB |
main.js               | main          | 141.80 kB |
runtime.js            | runtime       |   6.51 kB |

                      | Initial Total |   2.97 MB

Build at: 2023-06-24T12:38:47.643Z - Hash: f7daee3e3b8c4481 - Time: 7248ms

** Angular Live Development Server is listening on localhost:4200, open your browser on http://localhost:4200/ **

√ Compiled successfully.
C:\Users\Prajwal Patil\Desktop\twitter\twitter\node_modules\webpack-sources\lib\SizeOnlySource.js:16
                return new Error(
                       ^

Error: Content and Map of this Source is not available (only size() is supported)
    at SizeOnlySource._error (C:\Users\Prajwal Patil\Desktop\twitter\twitter\node_modules\webpack-sources\lib\SizeOnlySource.js:16:10)
    at SizeOnlySource.buffer (C:\Users\Prajwal Patil\Desktop\twitter\twitter\node_modules\webpack-sources\lib\SizeOnlySource.js:30:14)
    at _isSourceEqual (C:\Users\Prajwal Patil\Desktop\twitter\twitter\node_modules\webpack\lib\util\source.js:21:51)
    at isSourceEqual (C:\Users\Prajwal Patil\Desktop\twitter\twitter\node_modules\webpack\lib\util\source.js:43:17)
    at Compilation.emitAsset (C:\Users\Prajwal Patil\Desktop\twitter\twitter\node_modules\webpack\lib\Compilation.js:4252:9)
    at C:\Users\Prajwal Patil\Desktop\twitter\twitter\node_modules\webpack\lib\Compiler.js:566:28
    at C:\Users\Prajwal Patil\Desktop\twitter\twitter\node_modules\webpack\lib\Compiler.js:1198:17
    at eval (eval at create (C:\Users\Prajwal Patil\Desktop\twitter\twitter\node_modules\tapable\lib\HookCodeFactory.js:33:10), <anonymous>:13:1)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at runNextTicks (node:internal/process/task_queues:65:3)
PS C:\Users\Prajwal Patil\Desktop\twitter\twitter> ng serve -o
⠦ Generating browser application bundles (phase: emitting)...C:\Users\Prajwal Patil\Desktop\twitter\twitter\node_modules\webpack-sources\lib\SizeOnlySource.js:16
                return new Error(
                       ^

Error: Content and Map of this Source is not available (only size() is supported)
    at SizeOnlySource._error (C:\Users\Prajwal Patil\Desktop\twitter\twitter\node_modules\webpack-sources\lib\SizeOnlySource.js:16:10)
    at SizeOnlySource.buffer (C:\Users\Prajwal Patil\Desktop\twitter\twitter\node_modules\webpack-sources\lib\SizeOnlySource.js:30:14)
    at _isSourceEqual (C:\Users\Prajwal Patil\Desktop\twitter\twitter\node_modules\webpack\lib\util\source.js:21:51)
    at isSourceEqual (C:\Users\Prajwal Patil\Desktop\twitter\twitter\node_modules\webpack\lib\util\source.js:43:17)
    at Compilation.emitAsset (C:\Users\Prajwal Patil\Desktop\twitter\twitter\node_modules\webpack\lib\Compilation.js:4252:9)
    at C:\Users\Prajwal Patil\Desktop\twitter\twitter\node_modules\webpack\lib\Compiler.js:566:28
    at C:\Users\Prajwal Patil\Desktop\twitter\twitter\node_modules\webpack\lib\Compiler.js:1198:17
    at eval (eval at create (C:\Users\Prajwal Patil\Desktop\twitter\twitter\node_modules\tapable\lib\HookCodeFactory.js:33:10), <anonymous>:13:1)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at runNextTicks (node:internal/process/task_queues:65:3)

Your Environment
Angular CLI: 16.1.1
Node: 16.17.0
Package Manager: npm 9.7.1
OS: win32 x64

Angular: 16.1.2
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1601.1
@angular-devkit/build-angular   16.1.1
@angular-devkit/core            16.1.1
@angular-devkit/schematics      16.1.1
@angular/cli                    16.1.1
@schematics/angular             16.1.1
rxjs                            7.8.1
typescript                      5.1.3

Anything else relevant?
No response

This seems like a bug but we'll need to look at a reproduction to find and fix the problem. Can you setup a minimal repro please?
You can read here why this is needed. A good way to make a minimal repro is to create a new app via ng new repro-app and adding the minimum possible code to show the problem. Then you can push this repository to github and link it here.
This might be related to your directory structure so its really important to get an accurate repro to diagnose this.

@alan-agius4 The problem is that, this problem occurs occasionally and not always. I made a new angular app for reproducing this error, the new app runs fine now.

Unfortunately without a clear way to reproduce this we will be unable to investigate this issue any further.

Closing as no reproduction was provided.


Document a setup suitable for GitLab

Document a setup suitable for GitLab.

@osslate-rh that's for you

@osslate-rh pretty please


Support Azure OpenAI Service

https://learn.microsoft.com/en-us/azure/ai-services/openai/reference
This has the same basic interface as OpenAI itself, but uses a different auth header.
I called then new version "AzureOpenai" rather than just "Azure" as Azure hosts other LLMs apart from OpenAI as well.
This works fine when the .api_configs.toml and prompts.toml are set to use it. However I did see weirdness when specifying the api on the commandline.
Even though the new strings are AzureOpenai and azureopenai everywhere, the commandline needs --api azure-openai with a hypen to select it. I'm guessing that this is from some default camel-case to kebab-case handling of AzureOpenai.

Hey, that's awesome, thanks a ton!

I called then new version "AzureOpenai" rather than just "Azure" as Azure hosts other LLMs apart from OpenAI as well.

Do you know if the request format is the same for other models (i.e. azure creating their standard) or if it is specific to openai?

I'm guessing that this is from some default camel-case to kebab-case handling of AzureOpenai

You're exactly right!

Alright, let's keep it like it then!


InAppBillingImplementation.PurchaseAsync() bombing

Our app has used the prior version for several years now, no code changes in calling your library.  We downloaded the new version of your library, but are getting a runtime error on iOS and Android.  Below is the debug info.
Please advise on how to fix on our end, but since the error is in your library, we probably need a new fixed version.
Thanks
The error:
{Plugin.InAppBilling.InAppBillingPurchaseException:  An unknown error occurred   at
Plugin.InAppBilling.InAppBillingImplementation.PurchaseAsync (System.String productId,
Plugin.InAppBilling.ItemType itemType, System.String applicationUserName) [0x0017a] in D:\a…}
Plugin.InAppBilling.InAppBillingPurchaseException
Message: An unknown error occurred
Source: mscorlib
Stack trace:
at
Plugin.InAppBilling.InAppBillingImplementation.PurchaseAsync (System.String productId, Plugin.InAppBilling.ItemType itemType, System.String applicationUserName) [0x0017a]
in D:\a\1\s\src\Plugin.InAppBilling\InAppBilling.apple.cs:427
at Plugin.InAppBilling.InAppBillingImplementation.PurchaseAsync (System.String productId, Plugin.InAppBilling.ItemType itemType, System.String obfuscatedAccountId, System.String obfuscatedProfileId, System.String subOfferToken) [0x00036]
in  D:\a\1\s\src\Plugin.InAppBilling\InAppBilling.apple.cs:321
at NineTimesProject.Services.InAppPurchase.Purchasesubscription () [0x00322]
in /Users/dean/Documents/DHT_NineTimesApp/NineTimes/NineTimes/Services/InAppPurchase.cs:159
Bug Information
Version Number of Plugin: 7.0.5
Device Tested On: Android Tablet, latest version
Simulator Tested On: iOS iPhone 14 iOS 16.2
Version of VS: 17.5.4 on mac, latest version on PC
Version of Xamarin: <IP_ADDRESS> Visual Studio Professional
Versions of other things you are using: n/a
Steps to reproduce the Behavior
Make a call to InAppBillingImplementation.PurchaseAsync()
Expected Behavior
For it not to bomb
Actual Behavior
Bobms with unknown error
Code snippet
var billing = CrossInAppBilling.Current;
…
var purchase = await billing.PurchaseAsync(productId, ItemType.InAppPurchaseConsumable);
Screenshotst
n/a

I found the documentation web page, read thru it. I understand that the lib will not work on the simulator. On Android tablet, PurchaseAsync() just shows a dialog to the user that says "Error" with no other text. My Catch() is not displaying this dialog. In the section "Android Testing" I see a few things that I might be doing, hard to tell. If all else fails I will publish to the Google store and test on Production. Someone please at least follow up with some advice. We have a Nov 1 deadline according to Google. Thanks

On iOS you can test on device or publish to test flight for easy testing.
For android you can put it in Internal testing in google play as well

Thanks for the response. I did publish to Google play to test in Prod. Do you have any thoughts on why PurchaseAsync() is throwing an undefined error on an Android tablet? The user dialog pops up when the lib method is called, not in my Catch() statement. We did not change any of our code, simply upgraded the lib via NuGet and rebuilt. Old version worked fine.

Thanks for the response. I did publish to Google play to test in Prod.
Do you have any thoughts on why PurchaseAsync() is throwing an undefined error on an Android tablet?
The user dialog pops up when the lib method is called, not in my Catch() statement.
We did not change any of our code, simply upgraded the lib via NuGet and rebuilt. Old version worked fine.
From: James Montemagno @.>
Date: Thursday, October 12, 2023 at 10:50 PM
To: jamesmontemagno/InAppBillingPlugin @.>
Cc: Dean Curtis @.>, Author @.>
Subject: Re: [jamesmontemagno/InAppBillingPlugin] InAppBillingImplementation.PurchaseAsync() bombing (Issue #564)
On iOS you can test on device or publish to test flight for easy testing.
For android you can put it in Internal testing in google play as well
—
Reply to this email directly, view it on GitHubhttps://github.com/jamesmontemagno/InAppBillingPlugin/issues/564#issuecomment-1760720243, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJT7SRWZZUROREZGV6FV37DX7C3BRANCNFSM6AAAAAA5237RJM.
You are receiving this because you authored the thread.Message ID: @.***>

iOS test on my device worked fine. I suspect the android test from the app store will work too.
My guess is the android tablet is throwing an error because of this from the help "Add a test account to the app, ensure it is the main account on device, and that account is opted-in as tester".
Thanks for you help.


[EAGLE-422] eagle support for mr & spark running job monitoring

https://issues.apache.org/jira/browse/EAGLE-422

LGTM

I have removed the sensitive information and update the code

testApplicationDescWrapperConfigLoadFromXML failed in Jenkins. While unit tests all passed in local


docs: improved README & fixed multiple typos

Description
The mid-section of the README file seems blank & has been produced with too many unnecessary breaks.
https://github.com/google/mediapipe/blob/065d7507818e9bf6f93ae38cbab805c6a4414907/README.md?plain=1#L19-L21
Additionally, fixed a bunch of typos and grammatical mistakes in several docs(guides).
Resolves: #4247
cc: @kuaashish

Hi @schmidt-sebastian,
Could you please look into this pull request. Thank you


KAFKA-16913 Support external schemas in JSONConverter

Currently, when the JsonConverter sends JSON data to Kafka, it includes the entire schema (structure of the data) along with the actual data in every message. This can make the messages quite large, especially if the schema is complex.
The proposed improvement is to allow the JsonConverter to reference an external schema file or service instead of including the full schema in every message. This would make the messages smaller and more efficient.
Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.
Committer Checklist (excluded from commit message)

[x] Verify design and implementation
[x] Verify test coverage and CI build status
[x] Verify documentation (including upgrade notes)

@ganesh-sadanala. Thank you so much for your interest and the effort you put into your PR! We really appreciate your contribution and the feedback you provided. Since your PR, the proposal has undergone substantial changes based on further community feedback.We wanted to acknowledge your work and explain that we are creating a new PR to incorporate the recommended changes from the community as per the  various discussions we had.


arena: possible performance improvements: huge pages, free approach

What version of Go are you using (go version)?
CL 387975 (patch set 5)

$ go version
go version devel go1.18-c217a17823 Tue Mar 1 10:12:02 2022 -0800 linux/amd64

Does this issue reproduce with the latest release?
n/a
What operating system and processor architecture are you using (go env)?

amd64 (AMD EPYC)
Debian 11 bullseye (stock GCE image; some light checking of similar behavior on Ubuntu 20.04 LTS)

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/thepudds1460/.cache/go-build"
GOENV="/home/thepudds1460/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/thepudds1460/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/thepudds1460/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/thepudds1460/sdk/gotip"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/thepudds1460/sdk/gotip/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="devel go1.18-c217a17823 Tue Mar 1 10:12:02 2022 -0800"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/thepudds1460/arena-benchmark-wip/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1871014333=/tmp/go-build -gno-record-gcc-switches"

What did you do?
I was interested in understanding the performance described in the arena proposal (#51317), so ran a few benchmarks using the prototype arena implementation in CL 387975 (patch set 5).
I didn't look very much at the interface{}/reflect based API, and instead started by adding a simple generic API for arena.NewOf[T any](a *Arena) *T.
Looking at the initial performance on this particular benchmark (links below), some things that jumped out:

the cost of first writing to newly allocated memory in the user code seemed to dominate the overall time in these benchmarks.
high system time.
the kernel was spending time in in places like handle_mm_fault, flush_tlb_mm_range, and friends.
many minor page faults.

I poked at it a few different ways, and concluded the arenas in the benchmark were not getting huge pages. I checked some OS-level settings that didn't seem to help (e.g., /sys/kernel/mm/transparent_hugepage/enabled was defaulted to always,  /sys/kernel/mm/transparent_hugepage/defrag defaulted to madvise but changing to always didn't help).
I then built up a simple C program that does a similar series of mmap(... PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, ...), mmap(... PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, ...), madvise(... MADV_HUGEPAGE) on 64 MB chunks at a time in a light attempt to emulate syscalls done by the unmodified arena code. The C program seemed to get "correct" behavior of huge pages. I also used strace to contrast syscalls by the Go runtime vs. glibc malloc (which also does mmaps under the covers and ends up "correctly" with huge pages on this machine).
Based on that, I tried a few modifications to the Go runtime, with the main results below. The largest improvement was forcing huge pages by doing memclr within the runtime on each new 2MB piece of the 64 MB arena chunks.
Some heavy caveats include these were quick YOLO changes to poke at the performance I was observing, and probably not the actual changes you would want 😅, and of course, all of this might be a red herring or an OS config issue or user error or something else entirely...
What did you see?
Here is a summary of main performance results, all with GOMAXPROCS=8:
Baseline: no arenas

Benchmark -- this is the baseline benchmark, which is the currently the fastest Go entry for the binarytree benchmark from the Benchmark Games site.

With unmodified go (no arenas):
$ go install github.com/thepudds/arena-performance/cmd/binarytree-original@f595de77
$ binarytree-original 21    # 21 controls the size of the trees

     5.12 sec wall clock
    34.53 sec user
     5.50 sec system
    40.03 sec total cpu
      537 MB RSS
   76,886 minor page faults

Runtime patch 1: add arenas using arena.NewOf[T any]

Go patch -- add simple implementation of arena.NewOf[T any](a *Arena) *T. No other changes.
Benchmark -- change original benchmark to use arenas via the generic API.

With modified go:
$ go install github.com/thepudds/arena-performance/cmd/binarytree-arena@f595de77
$ binarytree-arena 21

    12.50 sec wall clock   (144% increase from baseline)
    20.80 sec user
    77.92 sec system
    98.72 sec total cpu    (147% increase from baseline)
      750 MB RSS           (40% increase from baseline)
2,334,682 minor page faults

Runtime patch 2: memclr 2MB pieces of arena chunks prior to allowing use

Go patch -- also add calls to memclrNoHeapPointers within runtime/arena.go and reflect/arena.go to help commit memory in 2MB pieces, which seems to result in huge pages from kernel. There is very likely a better change than this, but this seemed to help substantially and at least suggests huge pages have an impact.
Benchmark -- same as prior

With modified go:
$ go install github.com/thepudds/arena-performance/cmd/binarytree-arena@f595de77
$ binarytree-arena 21

     2.55 sec wall clock   (50% reduction from baseline)
    19.34 sec user
     0.89 sec system
    20.23 sec total cpu    (49& reduction from baseline)
      765 MB RSS           (42% increase from baseline)
   14,492 minor page faults

Runtime patch 3: unmap chunk once >8 MB is used

Go patch -- also change reflect/arena.go so that arena Free unmaps a chunk once >8 MB is used (rather than waiting for full 64MB)
Benchmark -- same as prior

With modified go:
$ go install github.com/thepudds/arena-performance/cmd/binarytree-arena@f595de77
$ binarytree-arena 21

     2.71 sec wall clock   (47% reduction from baseline)
    20.11 sec user
     0.97 sec system
    21.08 sec total cpu    (47% reduction from baseline)
      312 MB RSS           (42% reduction from baseline)
   13,980 minor page faults

Sample benchmark output
The benchmark creates a small number of large binary trees and a large number of small binary trees. Here is sample output from binarytree-arena 21. Larger values will create more and larger trees.
$ binarytree-arena 21

   stretch tree of depth 22       arenas: 1      nodes: 8388607    MB: 128.0
  2097152 trees of depth 4        arenas: 992    nodes: 65011712   MB: 992.0
   524288 trees of depth 6        arenas: 1015   nodes: 66584576   MB: 1016.0
   131072 trees of depth 8        arenas: 1017   nodes: 66977792   MB: 1022.0
    32768 trees of depth 10       arenas: 993    nodes: 67076096   MB: 1023.5
     8192 trees of depth 12       arenas: 911    nodes: 67100672   MB: 1023.9
     2048 trees of depth 14       arenas: 683    nodes: 67106816   MB: 1024.0
      512 trees of depth 16       arenas: 512    nodes: 67108352   MB: 1024.0
      128 trees of depth 18       arenas: 128    nodes: 67108736   MB: 1024.0
       32 trees of depth 20       arenas: 32     nodes: 67108832   MB: 1024.0
long lived tree of depth 21       arenas: 1      nodes: 4194303    MB: 64.0

cc @mknyszek

Thanks for the detailed experiments and data.
There's a more direct way to force huge pages that I'd been considering: we already have sysHugePage in the runtime which just just madvise(MADV_HUGEPAGE). I appreciate your experiments there, it shows that this is worthwhile to make work. (This should probably be better than zeroing, because in theory the OS is already giving us zeroed pages so the zeroing is redundant? Unless I'm missing something.)
Also I've got patches on the prototype out to:

Don't actually unmap the region, just re-map it as PROT_NONE. That's not actually safe since something else could map there.
Make the 64 MiB chunk eligible for reuse once the GC finds no pointers into the region.

Your experiments on partial reuse are also great. I feel like that that point we should just use smaller arenas instead. My patch for (2) causes heapArena metadata to retain a 1:1 mapping with address space (as opposed to now, where the heapArena might be used for something else), so it'll be really quite feasible to handle smaller chunks, or partial chunks, in general.

Hi @mknyszek

There's a more direct way to force huge pages that I'd been considering: we already have sysHugePage in the runtime which just just madvise(MADV_HUGEPAGE).

FWIW, I did try that as well, and it did not seem to make a difference, but I might have made a mistake.

Interesting. THP has always been a little specific about its requirements.

Also, it looked like sysHugePage might already be called in the original CL 387975 via reflect_unsafe_newUserArenaChunk -> allocSpan -> sysUsed -> sysHugePage, but not 100% confident in that.

@thepudds Based on your suggestions I implemented https://go.dev/cl/423361. I think I included all your suggestions, though rather than changing the reuse policy I just made arenas 8 MiB in size to begin with. Checking against the same benchmark, I got roughly the same performance difference you got, so yay reproducibility!
Thanks again for the time you took to analyze this more closely. :)

One API implication of wanting to use more arenas concurrently is that there might be some benefit to allowing a user to control or hint the batching size or chunk size.

This is more possible with https://go.dev/cl/423361 since the arena chunk sizes are now decoupled from the heap arena size. You can't have a chunk size larger than a heap arena at the moment, but any power-of-two smaller works.
As for having lots of different chunk sizes, that becomes straightforward if the chunks are just taken from the page allocator, since differently-sized chunks can be returned to the page heap instead of sitting on a list. It wouldn't be too hard to do, I don't think. Something worth considering in the future perhaps!

Hi, thanks so much for working on the arena GOEXPERIMENT! I took it for a test drive today, and found it very usable. However, I quickly ran into the limitations discussed above around many concurrently live arenas.
I'm interested to see if arenas could be applicable for CockroachDB's use cases. In particular, during the query planning phase, CockroachDB performs a large number of allocations that have identical or very similar lifetimes. It would be impactful to be able to arena allocate these allocations.
However, CockroachDB typically hosts a large number of concurrent SQL sessions - in the 1000s. Because of this, the use case I'm describing would really need configurable arena chunk sizes, like you've mentioned above.
So, +1 to that idea!

The other thing that I wanted to mention was that it would be impactful to be able to inspect an arena to understand the amount of memory reserved for it. Without that, it would be tough for the CockroachDB use case I mentioned to use arenas as implemented, because CockroachDB needs to account for memory that it allocates to ensure that when running out of memory the server can react appropriately (e.g. queuing or rejecting incoming queries, and causing queries to spill disk).


Unable to use on Chrome Mobile

I've been trying to use this on my mobile device, both tablet and phone. I've noticed that it requires WebGL to be enabled and have gone into the flags to make enable it. Despite enabling WebGL in Chrome on my mobile device non of the code that is type is in ever visualized like it is on laptop or desktop computer. Is there a simple solution that I could be missing?

I have some changes pending for correcting the size of the canvas, and I have tested using Chrome on both iPhone and iPad. Can you try this URL and report back?
http://<IP_ADDRESS>:7443/openjscad/index.html

Please try the latest version, as commit This was corrected by commit e262bec33168fce099a612044c715f89b80287a2 corrected a lot of issues with the canvas size.


fix level edit cause error

sorry didn't see this pr until now, i discovered this myself and it's been fixed