text:
feat(computed): add cleanup method

See https://github.com/vuejs/vue-next/issues/2261#issuecomment-705170322
The cleanup method will remove all dep references to and from dependency sets. This allows the computed to be GC collected (if no other references remain).
Another reason to call this cleanup is to reduce the number of dependencies. Triggering a ref may become slow when there are many stale computeds that depend on it - as they will all have to be triggered. When calling cleanup, you can reduce the amount of stale computeds.
Notice that the computed will remain active and fully functional after cleanup. By simply setting the dirty flag upon cleanup, when getting the computed value later, all dependencies will simply be recovered and the correct value will be returned!

One question @yyx990803
In the final commit, I clear the cached value upon cleanup.
Personally, I think that it should also be cleared immediately after setting the dirty flag in the scheduler. It will never be used anyway and will use memory until the computed is read again.

This is indeed a good addition. However, I am a bit concern about the constancy of the APIs we are going to have.
Currently & On Going
To clean up effects:
Effect
import { stop, effect } from '@vue/reactivity'

const runner = effect(/* ... */)

stop(runner)

Watch / Watch Effect
import { watch } from 'vue'

const stopHandler = watch(/* ... */)

stopHandler()

Scope (PR #2195)
import { effectScope, stop } from '@vue/reactivity'

const scope = effectScope(/* ... */)

stop(scope)

Computed (this PR)
import { computed } from 'vue'

const foo = computed(/* ... */)

foo.cleanup()

Proposal
To have a general interface of disposable effect and let the return value of effect scope watch computed extends it
export interface Disposable {
  stop: () => void
}

const runner = effect(/* ... */)
runner.stop()

const scope = effectScope(/* ... */)
scope.stop()

const foo = computed(/* ... */)
foo.stop()

// as it's a breaking change, not sure if it's worth to do it
const watcher = watch(/* ... */)
watcher.stop()

Wondering what you think?

@antfu
This occurred to me as well, but..
computed.cleanup is different from watch stopHandles, and even effect.stop. When running a stop on a watcher, it makes the effect inactive. It's really destroyed. In case of computed.cleanup it merely dereferences it from all dependencies. It does not make the effect inactive, and it could be re-used without problems.
Maybe I should provide some background on why this is important. I've ran into this situation in a complex scroller with 20'000 rows that all had computeds depending on one other computed. As more and more rows were scrolled into view, scrolling performance degraded. The base computed, upon any trigger, had to trigger all those thousands of computeds that belonged to rows that were no longer 'within view'. Really wasteful. On top of that, as computeds cache their values, it held on to vast amounts of memory unnecessarily. Even when removing those rows later on, the base computed held the references causing a memory leak.

I was misunderstand the original motivation, thanks for the detailed explanation. The naming is good to me then 👍

I was intrigued when I saw this added to the 3.1 plan.
I think that a stop concept is needed (either in addition or in replacement of cleanup).
The issue #2261 notes that a computed having a long-lived dependency will leak itself and all its dependencies.
Looking at WPF for prior art, the "best" (but not really, read on) solution is to use WeakRef for dependency tracking. A weak ref means that a long-lived dependency would not keep a computed alive if nothing can read from that computed anymore.
Problem is that weak references are a recent JS addition. They won't work in pre-2020 browsers, won't work in neither Safari nor Opera, and it's not something you can polyfill. So I suppose they're out of question here.
This means that every effect depending on long-lived dependencies must be carefully tracked and stopped -- otherwise one leaks memory.
There are high-level tools for that in Vue: it's done automatically in components, which are a special case of (upcoming) effectScope.
It seems natural to me that there should be a low-level stop concept as well, for the simple case where a user wants to stop a single computed that they created.
I don't know if a cleanup is needed. I'd tend to think you could destroy (stop) and re-create computeds just as well but I didn't fully grasp the background given by @basvanmeurs. So why not.
When it comes to bikeshedding the name, I find cleanup not a great name. It conveys an after-stop / dispose idea that's more about the internals than the use-cases. Other ideas: pause or suspend? In contrast from stop it conveys that the computed would not be active anymore but ccould be started again.

Hey
I was intrigued as well by this changes to the effectApi and cleanup additions. I haven't gotten to the point where I need them in a project but I really think that the differences in the API's would be a struggle for every dev that wants to use them
I get that there is a difference on low level or how they behave but most of the people who will use it won't really care about that. The only thing they would want is just to stop something from being reactive
If I know that when I define  const myComputedProp = computed(()=>{}) and then can stop it with just myComputedProp.stop(). Tomorrow when I have const myEffect=effect(()={})  I will probably first try  myEffect.stop()
And as I think more about think maybe stop is not the most best name, maybe as mentioned above dereference or deref, or dereact ( as of de-React * badum-ts * ), jokes aside I think standarized API would make it more accessible
Cheers

Problem is that weak references are a recent JS addition. They won't work in pre-2020 browsers, won't work in neither Safari nor Opera, and it's not something you can polyfill. So I suppose they're out of question here.

Maybe we should rethink this. Safari now supports this as well. Now that IE11 support has been dropped, that only leaves Opera. WeakRef provides a native solution for cleaning up. Notice that it also provides a solution for the current problem where async created computes will leak even when they are created from within a component.
I actually tested a basic implementation by simply replacing the Dep set (Set<ReactiveEffect>) by Set<WeakRef<ReactiveEffect>> (https://github.com/Planning-nl/vue-next/commit/701e4e06ff4d67d5ab941da582b216c77ef307d0). I found little to none performance effect, and it provides memory safety with little to no work, which is a huge asset!
It may also affect the need for effectScope PR, as its primary motivations are:

If you like to make your own a framework. For example, @vue/lit, it does not handle effects in the component instance lifecycles, which will cause mem leakage if you try to mount and unmount the sub-component multiple times. In order to solve this, you will need to implement recordInstanceBoundEffect for your framework, which is not an easy & simple task from the outside. And also they will lose the ability to be reused interchangeably with Vue's ecosystem.
Clean up side-effects, preventing mem leak.

Let's close this PR because of the following reasons:

computeds can be stopped by wrapping it in an effectScope (https://github.com/vuejs/vue-next/pull/2195), and stopping that
for convenience and to avoid having to create effectScopes, we could add a stop method to the computed class which simply invokes this.effect.stop(), but that might be better suited for a separate PR (or @yyx990803 could just commit it to 3.2 directly)
on second thought, cleaning up references (which is an edge case) can be done manually by re-creating the same computed and exposing it wrapped in a ref

repo: vuejs/vue-next


text:
hashbang backwards compatibility?

Is it somehow possible to use the old hashbang behaviour with vue-router 2.x?
For our application we need the URLs to be with #! instead of just # in hash mode.

I don't see why you need to use a deprecated practice but you can use history mode and set a base of /#!/ as a workaround. I doubt we add back support for it.

I didn't know about this workaround. Seems to work just fine. Thanks for your help!

Now I am updating Vue-rouer1.x to Vue-router2, and I have the same problem, I wanna urls has #!/ in hash mode, but cannot find the  config option

The doc is here: https://router.vuejs.org/en/api/options.html#base

history mode with /#!/ seems not to be worked properly when served in sub path web app,
such as /appA/#!/ or /appB/#!/.
I found a easy way to compat v1 & v2 route path in hash mode.
Just write a inline script before vue-router loaded,
'''javascript
var hash = location.hash;
if (hash && hash.indexOf('#!') === 0) {
location.hash = hash.slice(2);
}
'''
The old v1 route path will work fine in v2.

source: gharchive/issue

authors: Mr-Hero aftdotleo pehbehbeh posva

repo: vuejs/vue-router

license: mit

license_type: permissive

license_source: bigquery


text:
testing event props

Say we can test a component like this:
<someComponent @wasUpdated="someFunction" />

How should the emitted event be tested? Based on the Vuex example found in the docs, I tried the following and it didn't work:
    const propsData = {
      onWasUpdated: jest.fn()
    }
    const wrapper = mount(someComponent, { propsData })
    expect(propsData.onWasUpdated).toHaveBeenCalled()
  })

Is this currently possible? If so, how should it be done? Thanks

For questions like this, please use StackOverflow 🙂. The issue tracker is reserved for bugs and feature requests.
You can't add a click handler to a component, you need to add it to an element inside the component.

This can defintely be done:
<someComponent @wasUpdated="someFunction" />

I use it all the time to emit actions back up to the parent component. My issue was asking whether this is currently testable (couldn't find how in documentation), if not I'd like to file a feature request.

Sorry @alidcastano , I misread your example as a click handler ☺.
You could find the component with the handler in the parent component and emit on the instance:
find(someComponent).vm.$emit('wasUpdated')

This will trigger the someFunction method. There are a few ways to test that someFunction was called.
You can also test that someComponent emitted the someFunction method inside the component using the emitted method.
What feature would you like to request?

In my specific situation, the method is not emitted directly by the nested component. For example:
<rootComponent @wasUpdated="someFunction" />

<parentComponent @wasUpdated="someFunction" />

// child component
this.$emit('wasUpdated)

I'll try finding the nested component and see if I can trigger the emit. But ideally, this is the feature I had in mind:
 const wrapper = mount(someComponent, {
   propsData: {
    onWasUpdated: jest.fn() // jsx syntax for @wasUpdated
   }
 })

expect(wrapper.vm.wasUpdated).tohaveBeenCalled()

authors: alidcastano eddyerburgh

repo: vuejs/vue-test-utils

license: MIT

license_source: github-api


text:
ReferenceError: requestAnimationFrame is not defined

Version
1.0.0-beta.20
Reproduction link
https://jsfiddle.net/50wL7mdz/734408/
Steps to reproduce
mocha/chai test a .vue file that contains requestAnimationFrame
default eslint config
ReferenceError: requestAnimationFrame is not defined
What is expected?
no this warning
What is actually happening?
ReferenceError: requestAnimationFrame is not defined
eslint config
{
  "name": "xxx",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "serve": "vue-cli-service serve",
    "build": "vue-cli-service build",
    "lint": "vue-cli-service lint",
    "test:unit": "vue-cli-service test:unit",
    "test:e2e": "vue-cli-service test:e2e"
  },
  "dependencies": {
    "@fortawesome/fontawesome-svg-core": "^1.2.4",
    "@fortawesome/free-solid-svg-icons": "^5.3.1",
    "@fortawesome/vue-fontawesome": "^0.1.1",
    "@tweenjs/tween.js": "^17.2.0",
    "axios": "^0.18.0",
    "echarts": "^4.2.0-rc.1",
    "element-ui": "^2.4.7",
    "normalize.css": "^8.0.0",
    "vue": "^2.5.17",
    "vue-router": "^3.0.1",
    "vuex": "^3.0.1"
  },
  "devDependencies": {
    "@vue/cli-plugin-babel": "^3.0.3",
    "@vue/cli-plugin-e2e-cypress": "^3.0.3",
    "@vue/cli-plugin-eslint": "^3.0.3",
    "@vue/cli-plugin-unit-mocha": "^3.0.3",
    "@vue/cli-service": "^3.0.3",
    "@vue/eslint-config-standard": "^3.0.3",
    "@vue/test-utils": "^1.0.0-beta.20",
    "chai": "^4.1.2",
    "node-sass": "^4.9.0",
    "sass-loader": "^7.0.1",
    "vue-template-compiler": "^2.5.17"
  },
  "eslintConfig": {
    "root": true,
    "env": {
      "node": true
    },
    "extends": [
      "plugin:vue/essential",
      "@vue/standard"
    ],
    "rules": {},
    "parserOptions": {
      "parser": "babel-eslint"
    }
  },
  "postcss": {
    "plugins": {
      "autoprefixer": {}
    }
  },
  "browserslist": [
    "> 1%",
    "last 2 versions",
    "not ie <= 8"
  ]
}

I have recently been experiencing a similar issue - I even got as far as creating a repro repo here but you beat me to the bug report.
In my case, I'm using typescript with mocha+chai in addition to vuetify (repo created with @vue/cli v3).
My instinct tells me that we're just missing a polyfill or a shim somewhere but despite my best efforts, I've not been able to reliably find a fix for this myself.

@bugsduggan I still don't know how to fix it.A lot of information has been searched, but no solution has been found :(

The issue is that jsdom-global doesn't add requestAnimationFrame to the global object.
The immediate fix is to add requestAnimationFrame to the global object before your tests run:
global.requestAnimationFrame = cb => cb()

To include requestAnimation with jsdom, you must pass in the pretendToBeVisible option.
const window = (new JSDOM(``, { pretendToBeVisual: true })).window;

I created a PR in vue-cli to get this added to the mocha unit plugin—https://github.com/vuejs/vue-cli/pull/2573

@eddyerburgh I still see this issue and I am making an assumption that the merge PR you linked to is now released.
Is there anything I need to do specifically to use the functionality you added in the PR? Anything I need to set in my configuration?
Quite possible I am seeing an issue with the same symptom but different cause, but wanted to double check.

Hi @JamesMcMahon, sorry that you're experiencing this issue.
Can you open an issue in the vue-cli repo. That's the repo where the fix was made to

Hi @eddyerburgh . I still see this issue when trying to run my tests.
I am using mocha/chai, "@vue/cli-plugin-unit-mocha": "^4.0.5", @vue/cli-service": "^4.0.5" and "@vue/test-utils": "1.0.0-beta.29".
I still don't know how to fix this issue. Can you help me to figure out the source of the problem, and a way to be able to fix it?

Just a note this could happen in ts projects too, and to resolve this problem you have to define the global function in runtime.
tests/setup.ts:
const requestAnimationFrame = (fn: Function) => fn();
globalThis.requestAnimationFrame = requestAnimationFrame;

And make sure that the setup.ts file is require before run the tests in npm script
package.json:
"test": "vue-cli-service test:unit --include ./tests/setup.ts --recursive ./__tests__/",

I'm using Mocha+Chai for my testing, and Vuetify for my component library.
To fix this issue I just added the following to the top of my component.spec.js file
global.requestAnimationFrame = function () {}
I was having this issue when I added a Vuetify v-text-field component in the template of my Vue file
I'm using versions (not sure all packages that relevant),
"devDependencies": {
    ...
    "@vue/cli-plugin-unit-mocha": "~4.2.0",
    "@vue/cli-service": "~4.2.0",
    "@vue/test-utils": "1.0.0-beta.31",
    "chai": "^4.1.2",
    "vue-cli-plugin-vuetify": "~2.0.5",
    "vue-template-compiler": "^2.6.11",
    "vuetify-loader": "^1.3.0"
    ...
}

Do want to say that I'm new to Vue and frontend testing so I don't have JSdom installed for my testing (mainly because I just heard of it and I assumed this was for while using JEST test runner)

the loop is event based, based on a particular wavelength or something, I think it's related to electricity pulses. otherwise you could have user input with a mouse which has x and y as input and when it moves it executes the code, but if you were to make a loop without input such as raf, it would have to go into stable diffusion

authors: JamesMcMahon bugsduggan campbellgoe eddyerburgh marklytonh nargeszmn xinde zzhenryquezz


text:
Cannot set property 'exports' of undefined

I've recently started getting this error with vue-touch. I'm using webpack 2 / vue 2. It works fine in development, but when I create my production build, I get this error.
It looks like the module variable (renamed to t by webpack's uglifier) is being overwritten in the main anonymous method's global.
I suppose that a simple global 'use strict' somewhere in the application would prevent the global object being passed in. I think webpack is forcing strict mode because when I removed the -p flag (but kept the uglifier etc. switched on) it works fine.

...

Is there any solution to this? I'm getting the same error. Removing -p from webpack command helps, but this is not optimal.

@MikaelEdebro this will quite a while ago but I think I got around this in the end by using vue-touch/dist/vue-touch.min.js rather than just vue-touch

@jackmellis thied vue-touch/dist/vue-touch.min.js and it has the same behavior

authors: MikaelEdebro aziev jackmellis

repo: vuejs/vue-touch


text:
[suggestion] Add a transition mode for transition on list (v-for)

Hi,
I have a list of components which are rendered via an array prop like such :
<child-component is="example"
    v-for="item in myArrayProp"
    transition="bounce"
    stagger="200"
</child-component>

Fact is myArrayProp is already filled from the beginning and I would like to transition (bounce-in) the list at the beginning for the first time.
I could do it by triggering myself some class but I'll loose the benefit from the stagger effect.
To achieve it, I found no other way to dirty hack it with flush the prop at the beginning and refills after nextTick
So why not give the option to trigger the "enter" transition for the first time ?
Thanks

Yeah, I've been thinking about this, could be useful.

Glad to hear it will eventually be implemented in future versions. Thanks

I believe this should not take the name of transition-mode, because this would clash with the existing meaning of transition-mode.

This is implemented in 2.0 as the appear prop. Although we'd like to backport it to 1.x, this is a non-critical change that requires non-trivial effort. Given the bandwidth we have, we are reducing the scope of 1.1 to a number of critical features and low hanging fruits, so unfortunately this will not be implemented for 1.x.

It's been 2 years now. Is there any chance of implementing this on Vue2?

Did you read the comment just above yours? 😆

🤦♂, Sorry. I am a terrible reader.

repo: vuejs/vue


text:
[Bug Report] Template conflicted between multi components when dynamically changing template

Vue.js version
1.0.24
Reproduction Link

here is the code:
http://codepen.io/hectorguo/pen/bebEoV
Short Code:
// When I change template like this, it goes not right when multi `<ad-time>` are used in one page.
Vue.component('ad-time', {
        created: function() {
            this.$options.template = NEW_TEMPLATE;
        }
}

What is Expected?
All three components should show different result depending on the format attribute.
What is actually happening?
Now you can see, all three components show the same template (same as the first component) result.
And if you delete the first example, it will show the second example's template.
I'm sure that each component's $options.template is right.
So I am not sure if i could change the template dynamically like this.

No, you can not change the template like this. You should consider anything that is inside $options to be read-only and non-reactive.
If you need template to depend on data, then make multiple components with different template and use dynamic :is="type" to pick the one you need for particular data.

authors: hectorguo simplesmiler


text:
Sorting components produces duplicate nodes in the dom

Thank you so much for this awesome framework. I've only been working with the framework for a couple of months now, and still unsure of all of the limitations. This looks like a limitation of the component system.
Vue.js version
1.0.26
Reproduction Link
https://jsfiddle.net/CristianGiordano/cdLp4uz2/
Steps to reproduce
Move a person from one list to another (The list component is re-rendered alongside the moved dom node)
What is Expected?
No duplication of elements. Here is a working version (same code) without a person component.
https://jsfiddle.net/CristianGiordano/ghwgzgtx/
What is actually happening?
It looks like VueJS cannot re-use existing nodes or find the node which was moved.

I have tried adding a track-by id with the relevant object properties.
I have tried SortableJS and Dragula sorting libraries with the same issue.

p.s. Apologies if this is not the right forum to raise such an issue.

It works when you remove the element : https://jsfiddle.net/Linusborg/cdLp4uz2/8/ (JS Line 54)
The reason that it does not work is that the dropped element somehow looses the connnection to the component instance (it's usually saved on the element in an attribute called __vue__), and I think Vue can't do much about it.

Ok cool thanks. I thought it was as such but thought I could be doing something wrong.
Thanks for your time :)

authors: CristianGiordano LinusBorg


text:
Not importing correctly with Rollup

Vue.js version
2.0.0-rc.7
Reproduction Link
http://vue-rollup-undefined-this.surge.sh
Steps to reproduce
https://github.com/danreeves/vue-rollup-undefined-this-bug-report
What is Expected?
Vue should init
What is actually happening?
From Rollups mouth: "The this keyword is equivalent to undefined at the top level of an ES module, and has been rewritten". A quick fix to test this out is to replace any calls to this with Vue.prototype, and it starts working.

Let me check it. I got vue + rollup working on multiple projects

Vue is a constructor. You have to call it with new

I'm such an idiot! Thanks

方法createComponentInstanceForVnode 的两行注释导致rollup报错，请修改注释位置。能不能发这个方法的注释调整到方法头上？谢谢。
node_modules\vue\dist\vue.runtime.esm.js
function createComponentInstanceForVnode (
vnode, // we know it's MountedComponentVNode but flow doesn't
parent // activeInstance in lifecycle state
) {

authors: danreeves posva standino


text:
Sync v-model during IME composition

What problem does this feature solve?
http://vuejs.org/v2/guide/forms.html#Basic-Usage
For languages that require an IME (Chinese, Japanese, Korean etc.), you’ll notice that v-model doesn’t get updated during IME composition.

msg
<input v-model="msg">

is OK, but type="search" is Not OK

msg
<input type="search" v-model="msg">

What does the proposed API look like?
For languages that require an IME (Chinese, Japanese, Korean etc.),  v-model(type="search") doesn’t get updated during IME composition.

This behavior is intentional because syncing during composition often leads to awkward UX. What's the use case for this?

example:
https://jsfiddle.net/xiaohan1219/k9qbs068/

That's not a use case... what I am asking is why do you want the in-composition string to show up.

I don't want to the in-composition string to show up（in using type="search"）

我的英语水平太烂了，问题的描述如截图，我是认为 search 输入框作为 input，应该具备 text 一样的输入体验，我还没看懂关于此处的代码，应该是vue 处理了但显然处理方式不同，才导致这两种不同的显示结果

ok I get it now...

@yyx990803
Android has the same problem , why not handle composition events ?

Just stumbled on this issue myself. Handling composition events in an MVC way does not seem to be doable with current browser behavior. It is a breaker for a live search/live autocompletion functionality.
As of now, the best way for me to handle this was to make a form with input element and re-read it on every compositionupdate event. This seems to be the only hack that works with UC browser. For some reason, UC does update the inputs inside forms on composition, yet it gives undefined as event data...
It will be very very good is there will be a standard way set by upstream how to handle that.

authors: baybal cloudyan yyx990803 zuibunan


text:
Native Events/Functional Components: Event.stopImmediatePropagation does not cancel event loop.

Version
2.4.1
Reproduction link
https://jsfiddle.net/alexsasharegan/ojymho07/
Steps to reproduce

Create a functional component:

create an event handler that calls Event.stopImmediatePropagation
put the context's event handler in an array with the component's handler, but place the component's handler at the first index. (Allowing the component's handler the first chance to stop propagation)

Using this functional component in a parent component, bind a listener to the same event (e.g. "click")
Execute the event

What is expected?

The functional component's handler should be called first, since it is first in the array
The functional component's handler should execute the stopImmediatePropagation call, and kill the event loop.

What is actually happening?

Execution order is preserved correctly.
The parent component's handler is still being invoked (but additional handlers bound through EventTarget.addEventListener are not).

My use case starts at creating a link component that will respect a disabled property, but continues on to various other components to create a cohesive UI component API.
It would be beneficial to have some way to cancel the Vue event loop. I don't know my way around the source well enough, but I imagine that Vue internally tracks all event handlers for a given node, intercepts the native event first, then invokes all callbacks. This is why natively bound callbacks do not get invoked, but callbacks bound by Vue are invoked.

That's because Vue is wrapping all of those functions in one function so it only has to register 1 instead of n listeners.
https://github.com/vuejs/vue/blob/dev/src/core/vdom/helpers/update-listeners.js#L26
You should simply do the same - wrap it all in your function instead of pushing your own into the array.

authors: LinusBorg alexsasharegan


text:
[bug] conditional change of  type attribute not working?

Version
2.4.2
Reproduction link
https://jsfiddle.net/trusktr/50wL7mdz/52198/
Steps to reproduce
Try to type in the text field. It will keep clearing your input every second.
What is expected?
It should toggle between showing and hiding the password.
What is actually happening?
It is destroying the input (or clearing its value) each time the value of hidden changes.

Using v-if/v-else also doesn't work as would be intuitively expected: https://jsfiddle.net/trusktr/50wL7mdz/52199
Why is it not dom-diffing and applying the change only to the attribute value like one would expect?

Here's the same thing, broken, using a self-closing input tag: https://jsfiddle.net/trusktr/50wL7mdz/52202/

Here's a fiddle showing that it works with vanilla HTML/JS: https://jsfiddle.net/trusktr/50wL7mdz/52205/
This means that if Vue is doing dom diffing like it claims, then this issue should not exist.

@syropian suggested to add a dummy v-model as a workaround, which works, but not intuitive and wasteful: https://jsfiddle.net/50wL7mdz/52203

@trusktr, because type attribute on input is very special this is expected behaviour without v-model. You cannot carry same value around (think of input[type="file"] or even input[type="number"]).

@nickmessing That's not intuitive, please fix.
This is the sort of thing that should work in Vue because it works in the browser.
Sure, switching from password to file won't work, and in that case you should re-renderingthe.
But switching to text should work. Vue can easily make this intuitively easy. (Isn't it a framework like Vue's goal to make these things easy?).

Do you not see the fact that someone telling me to unituitively use v-model as a workaround is a problem?

@trusktr, Well, re-rendering diffs indeed, let's imagine a simple scenario.
Step 1. First render, DOM looks like:
<input type="text" />

Step 2. You add some text, DOM looks like (consider that value is describing a domProp and not attr here)
<input type="text" domProp-value="asdasd" />

Step 3. You change hidden so now vue should calculate the diff and apply it between this 2:
<input type="text" domProp-value="asdasd" />
<input type="password" />

Result: value gets removed. This is intuitive if you understand vue's rendering. It does remove value because there is no value in new input. v-model helps only because it is replaced by :value="str" @input="str = $event.target.value and as you see we have value.

That example isn't really applicable to my case, and you also mentioned some implementation details that end users don't need to care about.
The case is simple: if the only thing changing is type password to type text or vice versa, then you can optimize by DOM diffing as expected in that case, and end users won't run into unexpected behavior.
Another way to put it is: if I can simply change from type password to type text when using vanilla DOM+JS, then it should be as simple in Vue too, because is an extension of what we expect with vanilla DOM. Honestly this is good enough reason to make this optimization on your end, in this case and any other similar cases, and make it just work.

I've updated the title to remove the question mark.
Even with the v-model hack, DOM Diffing is not working. Vue is destroying the existing input element and creating a whole new one (rather than just modifying the type attribute).

This is REALLY bad.

This destroys interoperability with outside code. For example, bootstrap validator stops working because it will have a reference to a no-longer-existing input element.

If Vue is supposed to be incrementally adoptable, and interoperable with outside code (f.e. jQuery plugins) then this simply is not acceptable.

@nickmessing
If Vue is always dom-diffing like it claims, here’s a fiddle that should work: https://jsfiddle.net/trusktr/50wL7mdz/52661/
Start typing in the input field, and you will see the values logged to console.
Then, when you toggle the show/hide of the password, if Vue were dom-diffing properly, it would be changing only the type attribute of the input. If this were the case, then you’d continue to see output in the console.
But this isn’t the case because now there’s no input in the console.
Each time the show/hide is toggled, Vue replaces the entire input element with a new one.
This broke the simple logValues tool, and it will lead to code that will leak un-used DOM into memory.

Here's the same example showing that dom-diffing is working as expected with React: https://jsfiddle.net/trusktr/69z2wepo/84211/

@trusktr, It indeed makes sense to change the type only when it goes from one text-like input to another.
Vue was never claiming be interoperable with outside code. Rather then that, vue guarantees to keep in sync actual dom with virtual dom when using it's reactivity system and it's impossible to predict how it's going to do that since internal API can and will change over time. This is not a bug since it's keeping in sync the actual dom with virtual dom defined by template. It's probably sub-optimal to replace whole input when switching from one text-like to another and I will try to optimize that but Vue was never designed to "be friendly" with jQuery plugins.

it's impossible to predict how it's going to do that since internal API can and will change over time.

True, but some guarantee of atomicity can be proposed regardless of implementation: if only an attribute is supposed to change based on the Vue template, then the only thing in DOM that should change is the corresponding real attribute.

sub-optimal to replace whole input when switching from one text-like to another

It's probably suboptimal to ever replace the input no matter what the type transition. When changing type from text to file, DOM changes value to empty string. I don't think a user is going to try that though. If they do, they can simply use either (or both) v-on:input and v-on:change as needed. They can make that choice the same way they would with vanilla DOM.
In any case, I don't think there's any need to replace the input element.

Here's a fiddle that shows input and change events with type change from text to file: https://jsfiddle.net/trusktr/02gvxyLv/1/
I think it is the interest of a tool to work with existing standardized DOM functionality, not modifying expectations.

FYI this is an intentional mechanism for dealing with <input> with v-model bindings + different type bindings. When you toggle between, say type="text" and type="checkbox", the event/value bindings (generated at compile time) would be different and it is more straightforward to replace the element.
Toggling between text and password is a use case that's not been considered before and is easy to fix.

Hi,
I am using Vue 3.8.4 and this exact behavior it still happening to me:

When text is typed into the input itself, its setting the value of the type property to whatever is typed into the input field

authors: AdamBD nickmessing trusktr yyx990803


text:
Transition behavior is different when an uncalled done is provided in hook method

Version
2.5.16
Reproduction link
http://jsbin.com/wotazalama/1/edit?html,css,js,output
Steps to reproduce
In the demo link, click toggle to show and hide element
What is expected?
The two boxes are configured with <transition>, only differs in enter and leave hook.
One is called with enter(el){...} and leave(el){ ... } .
The other one is called with enter(el, done){...} and `leave(el, done){ .... }.
Both function do the same thing and the done callback is not called.
It is expected that the two boxes enter and leave the same way.
What is actually happening?
Box hooked with enter(el, done){...} and leave(el, done){...} do transition properly.
Box hooked with enter(el){...} and leave(el){...} do not have leave transition.

This is a re-submit of #8275 , I have messed up that demo. This one should properly demo the case.

It also said
  // the done callback is optional when
  // used in combination with CSS

In the demo case, the transition is actually a CSS one. The js hook part only set a max-height which can only be determined using script (el.scrollHeight).
I looked into some source code, the function length do have effect. From what I read is that if done is not provided, it will try to detect the transition end in CSS.
Most interestingly, the behavior is linked with both enter and leave.

enter(el) + leave(el) ==> ❌ leave transition not run
enter(el, done) + leave(el) ==> ✔  leave transition run
enter(el) + `leave(el, done) ==> ❌   leave transition not run
enter(el, done) + leave(el, done) ==> ✔  leave transition run

// the done callback is optional when
// used in combination with CSS

"optional" does not mean it's optional to call it. it's optional to add it.

If you add the argument however, you have to call done() .
If you don't add it, Vue knows that it can only wait for the CSS to finish.

this behaviour of the done parameter is similar to other libraries that provide done callbacks, testing frameworks like mocha, jasmine, jest, ava, etc. pp.

@yyx990803 @LinusBorg I'm using CSS transition here, I should not provide the done call to make it work.
The example itself is trying to use CSS transition, which is supposed to work with enter(el) and leave(el), but it is not. You can check this, which is what I originally intended to do.
It's an accidental discovery  that by provide using enter(el, done), the CSS transition is working unexpectedly.
I tend to think it's a browser limitation on the event looping. So with CSS transition on,  these code will not run the transition:
el.style.maxHeight = '50px';
el.style.maxHeight = 0;

As the doc says, providing done means you intend to explicitly control the end timing of the transition by eventually calling it at some point, so it disables the CSS-based auto transition end timing detection.
Rule of thumb: if you listed done in your arguments you must call it.

@yyx990803
I think I'm not making myself clear here. The CSS transition below is not working. It has no done in the parameter.
/* css */
.slide-down-enter-active,
.slide-down-leave-active
{
  transition: all .5s ease;
  overflow: hidden;
}

/* js */
    beforeEnter(el){
      el.style.maxHeight = '0px';
    },
    enter(el){
      el.style.maxHeight = `${el.scrollHeight}px`;
    },
    afterEnter(el){
      el.style.maxHeight = '';
    },
    beforeLeave(el){
      el.style.maxHeight = `${el.scrollHeight}px`;
    },
    leave(el){
      el.style.maxHeight = '0px';
    },
    afterLeave(el){
      el.style.maxHeight = '';
    }

Should I file another issue on this only?
Sorry that my description here is confusing.

先看下面一个例子
/* css */
.slide-down-enter-active,
.slide-down-leave-active
{
  transition: all .5s ease;
  overflow: hidden;
}

/*js*/
el.style.maxHeight = '100px';
el.style.maxHeight = '0px';

显然，运行上面的代码是不会有任何的过渡效果。
对于enter函数钩子，不传done（第二个参数），过渡效果结束之后，会执行afterEnter函数钩子；如果传了done，1）调用done函数，执行完done，UI上改动会立即执行完毕，然后调用afterEnter。2）不调用done，动画执行完毕也不会调用afterEnter。
例子：
beforeEnter(el){
    el.style.maxHeight = '0px';
 },
enter(el){
   el.style.maxHeight = `100px`;
},
afterEnter(el){
    el.style.maxHeight = '';
},
beforeLeave(el){
    el.style.maxHeight = `100px`;
},
leave(el){
    el.style.maxHeight = '0px';
},
afterLeave(el){
    el.style.maxHeight = '';
}

enter run result:
beforeEnter: el.style.maxHeight = '0px';
enter: el.style.maxHeight = `100px`;
// 这里间隔了0.5s，所以能看到过渡效果
afterEnter: el.style.maxHeight = '';

leave run result(初始值el.style.maxHeight = ''):
beforeLeave: el.style.maxHeight = `100px`;
leave: el.style.maxHeight = '0px';
afterLeave: el.style.maxHeight = '';

上面好3次给 maxHeight 赋值（''->100px->'0px'->''），并且最后一次赋值与初始值相同，每次
赋值时间间隔几乎为0，所以看不到任何过渡效果。
如果把enter钩子改为下面的形式：
enter(el, done){
   el.style.maxHeight = `100px`;
}

这样，afterEnter不会被执行。
enter run result:
beforeEnter: el.style.maxHeight = '0px';
enter: el.style.maxHeight = `100px`;

在0.5s内可以看到过渡效果，之后不会执行 afterEnter;
leave run result(初始值el.style.maxHeight = '100px'):
beforeLeave: el.style.maxHeight = `100px`;
leave: el.style.maxHeight = '0px';
afterLeave: el.style.maxHeight = '';

maxHeight 从100px变为 ‘’，在接下来0.5s内可以看到过渡效果。
现在回过头来看 @yyx990803 尤大 的评论，说的都在点子上。 @jackysee

先看下面一个例子
/* css */
.slide-down-enter-active,
.slide-down-leave-active
{
  transition: all .5s ease;
  overflow: hidden;
}

/*js*/
// el.style.maxHeight 初始值为 0
el.style.maxHeight = '100px';
el.style.maxHeight = '0px';

显然，运行上面的代码是不会有任何的过渡效果。
对于enter函数钩子（对于leave也是这样），不传done（第二个参数），过渡效果结束之后，会执行afterEnter函数钩子；如果传了done，1）调用done函数，执行完done，UI上改动会立即执行完毕，然后调用afterEnter。2）不调用done，动画执行完毕也不会调用afterEnter。
例子：
beforeEnter(el){
    el.style.maxHeight = '0px';
 },
enter(el){
   el.style.maxHeight = `100px`;
},
afterEnter(el){
    el.style.maxHeight = '';
},
beforeLeave(el){
    el.style.maxHeight = `100px`;
},
leave(el){
    el.style.maxHeight = '0px';
},
afterLeave(el){
    el.style.maxHeight = '';
}

enter run result:
beforeEnter: el.style.maxHeight = '0px';
enter: el.style.maxHeight = `100px`;
// 0.5s后执行afterEnter，这里能看到过渡效果
afterEnter: el.style.maxHeight = '';

leave run result(初始值el.style.maxHeight = ''):
beforeLeave: el.style.maxHeight = `100px`;
leave: el.style.maxHeight = '0px';
// 0.5s后执行 afterLeave
afterLeave: el.style.maxHeight = '';

我猜测 el.style.maxHeight = '',当出现过渡动画时，maxHeight会被初始化成 0。
所以上面3次给 maxHeight 赋值，改变过程为0->100->0->0，其中前两次改变时间
间隔几乎为0，所以看不到任何过渡效果。
如果把enter钩子改为下面的形式：
enter(el, done){
   el.style.maxHeight = `100px`;
}

这样，afterEnter不会被执行。
enter run result:
beforeEnter: el.style.maxHeight = '0px';
enter: el.style.maxHeight = `100px`;

在0.5s内可以看到过渡效果，之后不会执行 afterEnter;
leave run result(初始值el.style.maxHeight = '100px'):
beforeLeave: el.style.maxHeight = `100px`;
leave: el.style.maxHeight = '0px';
afterLeave: el.style.maxHeight = '';

maxHeight 从100px变为 0，在接下来0.5s内可以看到过渡效果。
@yyx990803 尤大说的是对的。 @jackysee

authors: LinusBorg jackysee leeezhou yyx990803


text:
Event propogation before component is created and conditional rendering

Version
2.6.8
Reproduction link
https://codesandbox.io/s/wwoxp636jk
Steps to reproduce
Add a click listener on window in a child component
What is expected?
Before Vue 2.6, the click event was not propagated to the child component because it was not created yet.
What is actually happening?
The click event is now propagated to the child after it is created and mounted.

Do I need now to explicitly add the modifier .stop to all my parent click events if I add click listeners on window in my child components?

Duplicate of #9616
Also see https://github.com/vuejs/vue/issues/9478 and https://github.com/vuejs/vue/issues/9464

authors: lucpotage posva


text:
fix #12666: vue.d.ts: Relativise to v3-component-public-instance

What kind of change does this PR introduce? (check at least one)

[x] Bugfix
[ ] Feature
[ ] Code style update
[ ] Refactor
[ ] Build-related changes
[ ] Other, please describe:

Does this PR introduce a breaking change? (check one)

[ ] Yes
[x] No

If yes, please describe the impact and migration path for existing applications:
The PR fulfills these requirements:

[x] It's submitted to the main branch for v2.x (or to a previous version branch), not the master branch
[x] When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)
[ ] All tests are passing: https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#development-setup
[ ] New/updated tests are included

Other information:
I didn't investigate why vue's tsconfig incorrectly resolves an absolute reference to v3-component-public-instance, so I was unable to start with a failing test.

The setting that allows types/tsconfig.json to resolve absolute references by mistake is baseUrl: ".". I removed it, although I don't know if it'll break the tests.

source: gharchive/pull-request


text:
Nested version search index problem

@maxiloc sorry to bother again, but as we are planning to merge multiple major versions of the docs under one domain (from vuejs.org+v1.vuejs.org to vuejs.org/v2 and vuejs.org/v1), we realized that Algalia may end up including both versions under the same index, and the search results can be confusing.
Basically, our question is - is it possible to make one index only crawl pages under vuejs.org/v1, while the other vuejs.org/v2?

Yes we do have a multi version capabilities. I updated the vuejs config to prepare for multiversion
(https://github.com/algolia/docsearch-configs/commit/4b816ab9660c818ecb23bea97870cd0d58dcf52a)
You just need to update the snippet
<!-- at the end of the HEAD -->
<link rel="stylesheet" href="https://cdn.jsdelivr.net/docsearch.js/2/docsearch.min.css" />
<!-- at the end of the BODY -->
<script type="text/javascript" src="https://cdn.jsdelivr.net/docsearch.js/2/docsearch.min.js"></script>
<script type="text/javascript"> docsearch({
  apiKey: '85cc3221c9f23bfbaa4e3913dd7625ea',
  indexName: 'vuejs',
  inputSelector: '### REPLACE ME ####',
  algoliaOptions: { 'facetFilters': ["version:$VERSION"] },
  debug: false // Set debug to true if you want to inspect the dropdown
});
</script>

$VERSION being v2.
When you'll have v1  ready, we'll add it to the config. And you can change the $VERSION to v1 for the v1 part of the website
Does that makes sense ?

@maxiloc awesome, thanks again!

@maxiloc
Does this support for japanese translation?

Yes we can support it as well but right now http://jp.vuejs.org/v2/api/ does not exist so I can not move it to the new config.

@maxiloc
thanks!
I don't deploy the latest version (2.0 japanese translation) yet.
already, I have been set the new configration.
https://github.com/vuejs/jp.vuejs.org/blob/lang-ja-2.0/themes/vue/layout/layout.ejs#L78-L84
Are we ok with new configration?

Yes as soon as you deploy ping me and I'll update the config

@maxiloc thanks!

@maxiloc
deploy done.
search configuration is the following:

configration for v2 japanese translation
https://github.com/vuejs/jp.vuejs.org/blob/lang-ja/themes/vue/layout/layout.ejs#L78-L84

configration for v1 japanese translation
https://github.com/vuejs/v1-jp.vuejs.org/blob/master/themes/vue/source/js/common.js#L20-L25

Ok it's deployed on our side. You just need to update the v1 by this one:
 docsearch({
            apiKey: '0a75952972806d9ad07e387d08e9cc4c',
            indexName: 'vuejs_jp',
            inputSelector: selector,
            algoliaOptions: { facetFilters: ["version:v1"] }
          })

@maxiloc
thanks quick reply!
I' fixed configuration.
https://github.com/vuejs/v1-jp.vuejs.org/commit/267b40f9cdddd6846798f089f908f3b4daee1134

@maxiloc
I think that algolia docsearch does not indexed for vuejs japanese translation.
I checked docsearch config of vuejs_jp.
https://github.com/algolia/docsearch-configs/blob/master/configs/vuejs_jp.json#L21-L37
It's is not  "url": "http://(?P<version>.*?).vuejs.org/guide/", but  "url": "http://(?P<version>.*?)-jp.vuejs.org/guide/", Isn't it?

@kazupon My bad, it should be fixed now

@maxiloc Thank you very much! 😺

@maxiloc, @yyx990803 — could you please give me a hint on how to update Algolia config for Russian translation? Comparing Japanese and English versions I've realized I need to provide different apiKey and indexName, but I don't seem to understand where could I get 'em.

I need to configure it. What is the url ?

https://ru.vuejs.org/

Here you go:
index_name: vuejs_ru
api_key: c6f9366f6f7fe057ee3e01747b603d9f

@maxiloc awesome! Thank you!

I believe this is all resolved now, so closing. 🙂

authors: chrisvfritz gbezyuk kazupon maxiloc yyx990803


text:
Text direction is RTL by default

needs
Can provide clear way to make Text direction is RTL by default.

@Ali7med did you find clear way?

repo: vueup/vue-quill


text:
Version 0.10 fails to build after cargo upgrade

I have a previously working application that uses vulkano version 0.10 and vulkano-shader-derive version 0.10. After a recent cargo update vulkano fails to build with
error[E0422]: cannot find struct, variant or union type `MirSurfaceCreateInfoKHR` in module `vk`
   --> C:\Users\Michael\.cargo\registry\src\github.com-1ecc6299db9ec823\vulkano-0.10.0\src\swapchain\surface.rs:314:29
    |
314 |             let infos = vk::MirSurfaceCreateInfoKHR {
    |                             ^^^^^^^^^^^^^^^^^^^^^^^ did you mean `XcbSurfaceCreateInfoKHR`?

error[E0425]: cannot find value `STRUCTURE_TYPE_MIR_SURFACE_CREATE_INFO_KHR` in module `vk`
   --> C:\Users\Michael\.cargo\registry\src\github.com-1ecc6299db9ec823\vulkano-0.10.0\src\swapchain\surface.rs:315:28
    |
315 |                 sType: vk::STRUCTURE_TYPE_MIR_SURFACE_CREATE_INFO_KHR,
    |                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ did you mean `STRUCTURE_TYPE_XCB_SURFACE_CREATE_INFO_KHR`?

    Building [====================================================>  ] 123/127: vulkano

Might be related to issue #1108 .

Oh oops, I published a breaking change to vk-sys as a minor change. Maybe I should have a separate changelog for vk-sys so this doesnt happen again.

I cant yank vk-sys 0.3.4 because I don't have access. @tomaka
In the meantime you can manually set to 0.3.3in your Cargo.lock

I cant yank vk-sys 0.3.4 because I don't have access. @tomaka

Done!

@tomaka
Oh no, this broke 0.11
When https://github.com/vulkano-rs/vulkano/pull/1115 is merged  can you you yank 0.11.0?

@tomaka
I think you forgot to yank v0.11.0.

@tomaka 0.11.0 still needs to be yanked

@rukai Done!

authors: MichaelMauderer newpavlov rukai tomaka

repo: vulkano-rs/vulkano


text:
Memory leaks if try to unblind a lot of utxos in FetchAndUnblindUtxos

Step to reproduce:

run the tests  a lot of time without resetting nigiri instance (~ 25 times for me)
now the tests accounts have a lot of UTXOS (~ 120)
yarn test fails: "Failed: "abort("Cannot enlarge memory arrays. Either (1) compile with  -s TOTAL_MEMORY=X  with X higher than the current value 16777216, (2) compile with  -s ALLOW_MEMORY_GROWTH=1  which allows increasing the size at runtime, or (3) if you want malloc to return NULL (0) instead of this abort, compile with  -s ABORTING_MALLOC=0 "). Build with -s ASSERTIONS=1 for more info."

---> This is probably due to the secp256k-zkp WASM version.

I investigated a bit, seems to the fact that in the JS bindings are creatign this leak how they are written.
This may be similar https://stackoverflow.com/questions/55884378/why-in-webassembly-does-allow-memory-growth-1-fail-while-total-memory-512mb-succ

Worth investigating
https://github.com/emscripten-core/emscripten/issues/6860

authors: louisinger tiero

repo: vulpemventures/ldk


text:
Standardizing Login Error Messages

Admin and manager-related API tests failed because their emails were not marked as verified in the test fixtures.
When trying to authenticate admin or manager users in tests, the server returned a 401 Unauthorized error with the message Email not verified.

Fixtures Update:
The admin_user and manager_user fixtures in conftest.py were updated:
Set email_verified=True for these users to ensure they could log in during tests.
Verified Admin and Manager Users:
Verified these users in the fixture setup so they could successfully pass login validation in tests.


text:
Please share your setup

Would be nice if you can share your setup with a revers proxy in form of a docker-compose.yml ready to go for popular revers proxy web apps like.

nginx (i will add mine)
traefik
caddy
apache maybe

Thank you

Testing discord webhook

Traefik 2
version: '3.6'
services:
  wg-gen-web:
    image: vx3r/wg-gen-web:latest
    container_name: wg-gen-web
    restart: unless-stopped
    environment:
      - WG_CONF_DIR=/data
      - WG_INTERFACE_NAME=wg0.conf
      - SMTP_HOST=your.smtp.host
      - SMTP_PORT=465
      - SMTP_USERNAME=your_smtp_username
      - SMTP_PASSWORD=your_smtp_password
      - SMTP_FROM=Wg Gen Web <address@to.send.from>
    volumes:
      - /etc/docker/container-data/wg-gen-web:/data
    labels:
      - traefik.http.routers.wg-gen-web.entryPoints=http
      - traefik.enable=true

simple setup with Caddy (i am using my own built container that uses digitalocean token for dns validation - based upon abiosoft/caddy)
version: '3.6'
services:
  caddy:
    image: "sphen/caddy-digitalocean"
    container_name: caddy
    environment:
      - DO_AUTH_TOKEN=abc123
      - ACME_AGREE=TRUE
    volumes:
      - /home/user/caddy/Caddyfile:/etc/Caddyfile
      - /home/user/caddy:/root/.caddy
    ports:
      - 443:443
    depends_on:
      - wg-gen-web
    restart: always

  wg-gen-web:
    image: vx3r/wg-gen-web
    container_name: wg-gen-web
    restart: always
    environment:
      - WG_CONF_DIR=/data
      - WG_INTERFACE_NAME=wg0.conf
    volumes:
      - /etc/wireguard:/data

Caddyfile:
vpn.xxx.com {
  basicauth / user password
  proxy / http://wg-gen-web:8080 {
    transparent
  }
  tls {
    dns digitalocean
  }
}

simple setup with Caddy

@sphen13 you may be interested in https://github.com/lucaslorentz/caddy-docker-proxy - a Caddy proxy to docker containers with automatic reload of the configuration and detection of container exposed ports.
I used it happily for a few months but eventually moved to https://github.com/vx3r/wg-gen-web/issues/19#issuecomment-603488807

Hi (x-posted from the Discord channel), here is a setup for easily running Wg Gen Web on Kubernetes with Kilo:
https://github.com/squat/kilo-wg-gen-web
The manifests can be found at https://raw.githubusercontent.com/squat/kilo-wg-gen-web/master/manifests/kilo-wg-gen-web.yaml

I used it happily for a few months but eventually moved to Traefik

... and then moved back to caddy v2 (using the new API in v2)

Wg Dashboard with caddy
version: '3.6'

networks:
  monitor-net:
    driver: bridge

services:
  wgweb:
    container_name: wgweb
    build:
      context: .
    volumes:
      - /etc/wireguard:/data

    expose:
      - 8888/tcp
    networks:
      - monitor-net

  caddy:
    image: stefanprodan/caddy
    container_name: caddy
    ports:
      - "8282:8888"
    volumes:
      - ./caddy:/etc/caddy
    environment:
      - ADMIN_USER=${ADMIN_USER}
      - ADMIN_PASSWORD=${ADMIN_PASSWORD}
    networks:
      - monitor-net
    labels:
      org.label-schema.group: "monitoring"

Dockerfile
FROM ubuntu
RUN apt update && \
    apt install curl vim net-tools iputils-ping -y
RUN mkdir /data
WORKDIR /app
COPY . /app
WORKDIR /app
EXPOSE 8888
CMD [ "./wg-gen-web" ]

Wireguard API
version: '3.6'
services:
  wg-json-api:
    image: james/wg-api:latest
    container_name: wg-json-api
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
    network_mode: "host"
    command: wg-api --device wg0 --listen 172.27.0.1:8080

Caddyfile
:8888 {
    basicauth / {$ADMIN_USER} {$ADMIN_PASSWORD}
    proxy / wgweb:8888 {
            transparent
        }

    errors stderr
    tls off
}

Env
# IP address to listen to
SERVER=0.0.0.0
# port to bind
PORT=8888
# Gin framework release mode
GIN_MODE=release
# where to write all generated config files
WG_CONF_DIR=/data
# WireGuard main config file name, generally <interface name>.conf
WG_INTERFACE_NAME=wg0.conf

# SMTP settings to send email to clients
SMTP_HOST=smtp.gmail.com
SMTP_PORT=587
SMTP_USERNAME=**************************
SMTP_PASSWORD=**************************
SMTP_FROM=**************************

#fake
OAUTH2_PROVIDER_NAME=fake

ADMIN_USER=**************************
ADMIN_PASSWORD=**************************
WG_STATS_API=http://172.27.0.1:8080

license: WTFPL


text:
在本机部署时出错  python3 manage.py runserver 0.0.0.0:8000

请贴出详细报错信息

默认没有在0.0.0.0上启动，导致docker拉起后，浏览器打不开页面，需要进入w12scan_web_1 手动run起来。

authors: boy-hack coffeehb myxss


text:
Apply one hint at cursor position

I want to apply one hint at cursor position. How should I go about this?

Could you elaborate?

Could you elaborate?

I basically want to do something like this: https://github.com/mpickering/hlint-refactor-vim
With ALE's default setting, when I do :ALEFix, the hlint fixer would apply fixes to all suggestions in the file. But I want to have the ability to apply the suggested fix to where the cursor is at.

Okay. Fixing a range of lines isn't supported and isn't likely to be soon.


text:
the async API breaks process.nextTick() within the callback

I discovered this issue when I wrapped eval(expr,cb) into a Promise-returning API.  Promises execute their callbacks via process.nextTick()
If you call process.nextTick(foo) from within the evaluation callback, then foo will not execute until something else happens (such as another timeout expires).
See these Mocha tests:
import * as julia from 'node-julia';
import { expect } from 'chai';

describe('node-julia', () => {
    it('should work asynchronously', done => {
        julia.eval("2+3", (err, result) => {
            if (!err) {
                expect(result).to.equal(5);
            }
            done(err);
        });
    });

    it('should not mess up process.nextTick() when called asynchronously', done => {
        julia.eval("2+3", (err, result) => {
            if (!err) {
                expect(result).to.equal(5);
            }

            process.nextTick(() => done(err));
        });
    });

    it('should not require calling setTimeout() to fix process.nextTick() when called asynchronously', done => {
        julia.eval("2+3", (err, result) => {
            if (!err) {
                expect(result).to.equal(5);
            }

            process.nextTick(() => done(err));
            setTimeout(() => {}, 0);
        });
    });
});

The first test passes.
The second test fails (times out)
The third test (where I added an empty setTimeout) passes.
It seems like it is related to this issue: https://github.com/joyent/node/issues/7714
I'm guessing your callbacks are somehow bypassing the nodejs event loop and so the event loop does not know to drain the nextTick queue until something else happens to wake up the event loop.

FYI this is the JavaScript stack trace I get if I print it via (console.log(new Error().stack)).
Inside my callback:
at /.../node-julia-test.es6:17:36

Inside my nextTick callback:
at /.../node-julia-test.es6:28:61
at process._tickCallback (node.js:355:11)

node-julia version: node-julia@1.1.2 (git://github.com/wateim/node-julia.git#73eb78f3873eeaafa96e4c81b7b5560f30e35435)
node version: v0.12.5
OS: Linux ubuntu-14 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

and if it helps, https://github.com/JuliaLang/julia/commit/fe7203e8b747a7caf472b59e5fa41f6cc86b1489

I don't remember doing anything non standard as far as async notification.  Just basic uv_async_send, but I do remember there can be only 1 notify delivery for multiple things in uv_async_send so knowing that there's a similar thing that happens in nj maybe something subtle about that.  This might prove difficult as inserting logging will alter the eventing behavior. Might be worth attempting with iojs just for perspective and (lack of) reproducibility. BTW just for info, are you using Q or bluebird or something else for the promises wrapping?

I'm guessing that it may not be enough to notify libuv about your callback, but you may need to specifically kick in nodejs's bookkeeping, e.g. whatever's going on with process._tickCallback

It looks like one way or another you need to call MakeCallback() to actually run the callback and allow nodejs to trigger its nextTick processing logic (and also its domain logic which I also notice is not working with node-julia.
It looks like all of the node native libraries use this method.  Here's the timers, for example: https://github.com/joyent/node/blob/master/src/timer_wrap.cc#L140
FYI, here's some unit tests showing the callbacks also are not running on the current domain:
    it('this one works', done => {
        const d = domain.create();
        d.on('error', () => done());
        d.run(() => {
            process.nextTick(() => { throw new Error("some error"); });
        });
    });
    it('this one fails', done => {
        const d = domain.create();
        d.on('error', () => done());
        d.run(() => {
            julia.eval("2+3", () => { throw new Error("some error"); });
        });
    });

Re: promises.  We use RxJs for most of our async stuff so I chose not to pull in a library like bluebird or Q.
So I just use this function to wrap:
/**
 * Converts a Node.js callback style function to a Promise.  This must be in function (err, ...) format.
 * @param {Function} func The function to call
 * @param {Function} [selector] A selector which takes the arguments from the callback minus the error to produce a single item to yield on next.
 * @returns {Function} An async function which when applied, returns a Promise with the callback results (if there are multiple results, then they are supplied as an array)
 */
export function fromNodeCallback(func, selector) {
    var newFunc = function (...args) {
        return new Promise((resolve, reject) => {
            func(...args, (err, ...results) => {
                if (err) {
                    reject(err);
                }
                else {
                    let finalResults = results.length > 1 ? results : results[0];
                    // run the selector if provided
                    if (selector) {
                        try {
                            finalResults = selector(finalResults);
                        }
                        catch (e) {
                            reject(e);
                        }
                    }
                    resolve(finalResults);
                }
            });
        });
    };

    newFunc.displayName = func.displayName;
    return newFunc;
};

Usage:

const evalAsync = fromNodeCallback(julia.eval);
const myPromise = evalAsync("2+3");

Hey sorry for the catch up questions.  Are you guys using a transpiler like  traceur or babel, I was able to get mocha to process the test but only after changing back to the using require rather than import.

yes I'm using babel + babel runtime + webpack.

I believe a7cbe3b2 has addressed this problem, the test case passes, and according to  nodejs/nan#284  and this stackoverflow question.

Yes this checkin resolves the nextTick issue.  The domain test still fails.  I'll open a different issue for that.
Thanks

authors: bman654 sebastiang waTeim

repo: waTeim/node-julia


text:
🛑 qBit is down

In 3b35e51, qBit ($TORRENT) was down:

HTTP code: 530
Response time: 267 ms

Resolved: qBit is back up in e5bb252 after 9 minutes.

repo: waallaby/up-time


text:
🛑 Plex Server | Waallaby-Net is down

In ebf43b4, Plex Server | Waallaby-Net ($PLEX) was down:

HTTP code: 502
Response time: 1004 ms

Resolved: Plex Server | Waallaby-Net is back up in bc045f6 after 5 days, 21 hours, 56 minutes.


text:
Support wasm32-wasip2 on the stable channel

Hey! 👋🏻
First of all, I'm hugely inspired by how simple this crate makes wasi:http in Rust. It looks really nice, and your implementations feel nice and idiomatic. I was going to do something similar to this for https://wasmcloud.com/, but it looks like you've already done a lot of what I was hoping for 😄
Since this crate depends on url, I'm pretty familiar with one of the small hiccups that affected wasm32-wasip2 on the nightly toolchain https://github.com/servo/rust-url/pull/960. I just filed an upstream PR to fix this for the stable toolchain as well https://github.com/servo/rust-url/pull/983, but I want to be sensitive to how prevalent the url crate is and that this target just landed in Rust 1.82.0. I would love to use this library, selfishly for https://crates.io/crates/wasmcloud-component. To be clear, we're using the wasmcloud-component essentially as a stopgap for things that don't exist in the wasi crate and its wrappers are all wasi-p2 compatible.
Anyways, do you have any thoughts on ways we can support this crate for wasm32-wasip2 on the stable channel in the meantime?

I suppose another possible rabbit hole here is that the request code looks similarly structured to reqwest https://github.com/seanmonstar/reqwest/issues/2294, what do you think about collaborating there to add support to that library, or are you more interested in having a wasi-first library here

Hi @brooksmtownsend, thanks for your interest in this project, I do want to have a wasi-first library here.
Actually, I have already been working on fixing this issue. Since the release of Rust 1.82, I have noticed the problem, and I have also seen your patch in the rust-url crate. I am planning to stop relying on the url crate. A new version will be released in the next few days.

I have released v0.4.0, please give it a try.

Amazing! I'll give it a shot today. Great Monday present @iawia002

repo: wacker-dev/waki


text:
您好，get_k_data 时间参数没传进去

您好，get_k_data函数调用并打印如下：
sxdata = ts.get_k_data(code,start='2017-05-01',end='2017-11-29',ktype='60')
print(sxdata)
结果显示起始日期是2017-06-05，结束日期是2017-12-04（昨日），如附件

分钟数据只有最近两周的，建议用ts.bar

repo: waditu/tushare


text:
Auto-generate tag slugs when creating tags directly in the Snippet panel

Is your proposal related to a problem?

Problem 1:
If you create a tag from the Snippet panel, a slug for the tag is not autogenerated (like how a slug is autogenerated when you create a Page for the first time). Note: This is creating a new slug from the Snippet panel. This is not an issue if creating a new tag directly from a page.
Problem 2:
If you create a tag from the Snippet panel, and you paste the name of the tag into the slug field, it does no convert it into an acceptable format (similar to when you paste text into a page slug). For example, let's say I have a tag called "Life Skills". If this was a page and I pasted "Life Skills" into the page slug field, it would convert the text to "life-skills" (all lower case with dashes instead of spaces). If I paste that into the Tag slug field, it remains "Life Skills".
Setup:

Wagtail 5.2
Python 3.8
Django 4.2.6

Describe the solution you'd like

Solution to Problem 1:

Go to the Snippet panel and click the button to create a new tag.
Enter the name of the tag.
As the name is typed, the tag is created automatically in the proper format (Ex: If I type "Life Skills", the slug becomes "life-skills" automatically).

Solution to Problem 2:

Go to the Snippet panel and click the button to update a tag slug.
Paste some text with or without spaces (with capital letters or not) into the slug field (Ex: "CHORES" or "House Chores").
When pasted, it converts the text to a lower case version of the text with dashes between spaces (EX: "chores" or "house-chores").

Describe alternatives you've considered

I manually write the slug names and try to follow the same rules used when Page slugs are generated or when tags get created directly from a page.
Not sure how feasible a solution would be. It seems to be limitations on tags in general from this discussion: #4109 . So perhaps part of the problem is a side effect of the Taggit library?
Additional context

Since pages use slugs as well, it would be nice from a usability perspective if page slugs and tag slugs shared similar behavior.

We have 3 options.

We can use the slugify library:-

from django.utils.text import slugify
     slug_value=slugify(page_title)

Might need to generate a unique slug using uuid import uuid
#while slug_value already exists in database:
     slug_value=f'{slugify(slug_value)}'-'{str(uuid.uuid4())[:4]}'

We also have AutoSlugField which can be directly added in models.

First we need to install
pip install django-autoslug
from autoslug import AutoSlugField
     slug_value=AutoSlugField(populate_from='title', unique=True, null=True, default=None)

We can also use it directly in jinja.

<p>{{ text|slugify }}</p>

repo: wagtail/wagtail


text:
Issue with column widths in document chooser when there are long filenames

Issue Summary
When there are long filenames (without spaces) for documents, the column widths of the table in the document chooser are stretched (especially when the browser width is narrow) so it is difficult to read the document title.
Steps to Reproduce

Upload a document with a long filename (with no spaces)
Edit a page with a document chooser
View the modal in a narrow browser window

See attached screengrab

Technical details

Python version: unknown, I'm just raising this from an editorial perspective
Django version: unknown, I'm just raising this from an editorial perspective
Wagtail version: 6.1.3
Browser version: Chrome 128

Working on this
Anyone can contribute to this. View our contributing guidelines, add a comment to the issue once you’re ready to start.

Thanks @davidjamesharris! Confirmed on current main branch - it's mitigated somewhat by the fix to the excessive right margin (which was caused by the sidebar styles from the main page leaking into the chooser) but still exists:

@davidjamesharris Can I work on this issue?

@Sumitsh28 Thanks for your interest! Yes, anyone is welcome to work on any issue.

I will give this a go!

I will give it a try!!

I will also trying to give a solution

I want to work on this issue please assign me this issue.

@davidjamesharris is this issue still open?

@shauryapanchal Please see #12390 - a fix has been submitted already, but needs more work. You're welcome to pick this up if you're interested.

@gasman understood.. i'll try to come up with a solution.. thanks for the update!

@shauryapanchal Would you mind i pick this up real quick

authors: Sambodhi-Roy SayanDutta651 Sumitsh28 TejasSaraf aminechm davidjamesharris frankyiu gasman shauryapanchal


text:
Docs/tutorial getting started facelift

No code changes. Only documentation revision for the getting started tutorial. I wanted to learn Wagtail, so I started with the tutorial and made changes along the way when I got confused.
Definitely open to any feedback or improvements that I can make :)
Changes:

Addition of learning objectives describing what the tutorial will accomplish with the learner.
Added base prerequisite knowledge and the description of the intended audience of the tutorial.
Fixed up typos and a couple of inconsistent language occurrences.
Rewrote sections that were lengthy and used numbered lists for complex steps
Simple explanations for admin users, database migrations, SQLite, and Wagtail's QuerySet modifiers.
Added hierarchical tree structure visuals.
Improved call to action at the end of tutorial.
100% more jazz hands (when I was relieved something worked)

Stayed the same:

General tutorial layout, I found it adequate to get me started
Tutorial images, I saw no reason to change, since I think the interfaces are the same.
Odd references like (virtual_environment_creation)= and (tutorial_categories)= which I do not see a reference anywhere in the document?

Tested on Ubuntu 22.04 LTS and Windows 10.
I ran it through a word processor to catch spelling mistakes and generated a working local version using Sphinx.
Please check the following:

[x] Do the tests still pass?[^1]
[x] Does the code comply with the style guide?

[ ] Run make lint from the Wagtail root.

[ ] For Python changes: Have you added tests to cover the new/fixed behaviour?
[ ] For front-end changes: Did you test on all of Wagtail’s supported environments?[^2]

[ ] Please list the exact browser and operating system versions you tested:
[ ] Please list which assistive technologies [^3] you tested:

[ ] For new features: Has the documentation been updated accordingly?

One more helpful resource from our docs for your first contribution - https://docs.wagtail.org/en/stable/contributing/first_contribution_guide.html
It includes some of the general feedback already given but hopefully helps you get to a first few PRs that can be easily reviewed and merged in.

@lb- @thibaudcolas
Thank you both so much for the feedback! I can definitely split these edits into smaller reviewable chunks. Those resources that you listed are incredibly helpful, I am a newbie with contributing to open source so I really appreciate the guidance.
I will work on getting these suggested changes in the coming week. Spending most of my free time in Hyrule this weekend :)
To be clear, I should open separate PRs for each edits to make it easier for the core team to review? Does that mean we should keep this PR open and reference the smaller PRs to this specific thread?
I do not mind if the tutorial goes in a different direction, this exercise helped me solidify the concepts after writing about it and hopefully this is useful to others in their journey. The most confusing portion of the tutorial was the QuerySet modifiers, which is why I created a simple tree visual for the reader. Also it took me some time to figure out why Parents and Children pages were referenced before the Tree hierarchy explanation.
Cheers!

@kev-odin in regards to your question about the PR. It's up to you what you want to do. You can close this and open discrete PRs or change this PR to reflect your first desired change based on feedback.
Maybe in the meantime you can change this to a draft until ready for another review.

authors: kev-odin lb-


text:
Restore the ability to have content type facets when searching pages with an empty query

This restores the ability to have content type facets when searching pages with an empty query:

We lost the ability to do this in 5.1 when the view was refactored from an FBV to a CBV: https://github.com/wagtail/wagtail/pull/10615/commits/52abcee04363ea9dae36ecbd87b01f4137a7ce3e#diff-dc3a1012fc5394a6a1abd8e254ed29cfd5107ba2fc6bb7b6127b4e6386d8dea9L108
The facets are only applied if there's a search query. Previously this was detected with if "q" in request.GET, but it was changed to if self.q (with self.q = request.GET.get("q", "")), so empty queries (e.g. clicking search on the left menu and press enter without typing anything) will not show the content type facets.
In addition, the adoption of #10645 to make the header search use the Stimulus SwapController would mean the facets will also be lost if you type something in the header search and clear it afterwards, as the q query param will be removed:
https://github.com/wagtail/wagtail/blob/ba17ef19d333570d9cca0195178e5e15babae93c/client/src/controllers/SwapController.ts#L178-L183
To fix this, we can either:

always do a search and apply the facets even if the query param is empty (which I've done here)
or, make a distinction between and empty q vs a non-existent q, and then also update SwapController so that it doesn't remove empty query params. I tried doing it this way in 7ec15f7aa08f25df5d27e273d43d98fe3fe13b4e, but it seems more intrusive.

This will probably be made redundant with page type filters in Universal Listings (#10446), but at the moment there's no alternative when you'd like to see all pages filtered by the page type. (Maybe #10850, but that's a separate topic.)
Please check the following:

[x] Do the tests still pass?[^1]
[x] Does the code comply with the style guide?

[x] Run make lint from the Wagtail root.

[x] For Python changes: Have you added tests to cover the new/fixed behaviour?

[^1]: Development Testing
[^2]: Browser and device support
[^3]: Accessibility Target

Merged in 3af26aa30e82bbb6d5c9988fc7d23e1fcc9fe74b (main) / e8ff6a2fa3 (stable/5.2.x).

authors: gasman laymonage


text:
Update Ordering, wording and help text for private pages

Fixes #11535
After Changes:

Please check the following:

[x] Do the tests still pass?[^1]
[x] Does the code comply with the style guide?

[ ] Run make lint from the Wagtail root.

[ ] For Python changes: Have you added tests to cover the new/fixed behaviour?
[ ] For front-end changes: Did you test on all of Wagtail’s supported environments?[^2]

[ ] Please list the exact browser and operating system versions you tested:
[ ] Please list which assistive technologies [^3] you tested:

[ ] For new features: Has the documentation been updated accordingly?

Please describe additional details for testing this change.
[^1]: Development Testing
[^2]: Browser and device support
[^3]: Accessibility Target

@lb- I would greatly appreciate your feedback and suggestions on the current changes. I'll update the tests once I am finished with the updates and everything looks satisfactory.

Sorry it was not clear on the issue, can you please put the shared password option under 'public'.

Thanks @lb-, I've made the changes

authors: lb- rohitsrma


text:
onActivityResult issue

Good day,
I just started using your library. Nice work.
But I can't get 2 static Strings from the LongImageActivity which are LONG_IMAGE_RESULT_CODE and IMAGE_PATH_KEY.
Any solution?
Thanks.

Hello,
These are declared in LongImageActivity like this:
public static final String IMAGE_PATH_KEY = "imagePathKey";
public static final int LONG_IMAGE_RESULT_CODE = 1234;

you can statically import these as well like
import static com.wajahatkarim3.longimagecamera.LongImageCamera.*;

This should solve your issue. Again, still you are facing same kind of issue, then you can use values directly instead of the variables.


text:
Sign cli with digital signature

I used to use WakaTime at work to track my programming time, however, the CLI tool kept getting flagged by security because it isn't signed. I would like to keep using the WakaTime service is it possible to sign the your CLI tool?

What OS are you using? Would you share the report you got?

I'm assuming Windows?

Hi, yes it's Windows 11. I'll get you the full details when I'm at work tomorrow.

Hi,
the exact reports I got from security were

hope you're well. We received an alert this morning that an unsigned software communicating externally to an api for a program called Wakatime. Is this regular behaviour for your device?

I'd expect that there may be other tools that could track this type of performance with the dev team, might be worth finding out if there is such a tool being used as our stance on unsigned Github software may change in the future.

Hi we have had an alert from your machine that "wakatime-cli-windows-amd64.exe" has been making connections to api.wakatime.com any idea what this is.  Many Thanks

Hi, is there a verdict on this request, are you willing you support this feature?

Yes, we're working on getting a cert for signing Windows builds.

Hi all,
I'd like to contribute to this issue as well.
I'm on Win10 and AVG blocks wakatime-cli-windows-amd64.exe from running (stating "IDP.ARES.Generic") though does not detect when scanned, but here's the report from VT: https://www.virustotal.com/gui/file/f2d3bd662aaaa79abd5939cd5b20f0bfe982a6c97582762bc8e9de3d6d867bac
(For the record Immunet does not detect, nor does SpybotS&D.)
I'm curious as to why some providers consider the file malicious. Any comments from the devs?

Adding update here - Previous comment states MalwareBytes does not detect this, however one machine I manage uses MalwareBytes and saw this flagged for the first time beginning 5 hours ago and again in the last 15 minutes.
I can confirm that it was wakatime-cli-windows-amd64.exe and the backup which were flagged. The device running it was operating W11 Pro. The timing coincides with this change by @alanhamlett .

Probably not related to that change, but the fact that 1 hr ago we did a release so the binary signature changed. Usually once the AV programs all see the new binary signature and start trusting it the false positives go away, but the first day of a release it's more likely to get flagged.

That tracks - thanks for the update and great product! I cited that change as the timing matched with the first alert. Likely the second matched as well for the same reason.

authors: AlfredSimpson IzStriker alanhamlett gandarez smladenoff

repo: wakatime/wakatime-cli


text:
SECURITY_VIOLATION in new version

Hello,
does anybody already use this latest version with DHL-Geschäftskundenportal?
In production mode (not using the sandbox) I always get the following error message from DHL:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
 <soap:Body>
  <soap:Fault>
   <faultcode>soap:Client</faultcode>
   <faultstring>SECURITY_VIOLATION</faultstring>
  </soap:Fault>
 </soap:Body>
</soap:Envelope>

The funny thing is, that the request is perfectly working in the sandbox environment.
I would appreciate if anybody already had this problem and knows what was missing.
Cheers,
Hannes
PS: Yes, I have a valid AppID with the necessary approved action items.

You'll want to contact DHL about this. I've not seen it before.

I already did. But till now, I didn't get any helpful responses.
Do you already use this latest version with the new endpoints?

Which new endpoints are you referring to?

To the new one: https://cig.dhl.de/services/production/soap
I figured out what the problem was. The namespace for the envelope was wrong. I used SOAP 1.2 with the Envelope namespace for SOAP 1.1. (or other way arround? doesn't matter anymore)

Hi vinett-de.
Could you please provide more information on how you solved the problem?
I am using Soap::Lite (v1.1) and getting the same error. My Envelope exactly looks like on the developer pages but my code is only working in sandbox mode.
Thanks,
Chris

Hi vinett-de.
I also have the same issue and i am not able to find the solution. Could you please explain how you did it.

Hello.
I have like same eroor "SECURITY_VIOLATION". I have sent  several queries to DHL support  - and in last i got reason - this error can be in name  of action  - example for live  mode SOAPAction: "urn:getVersion" but for test  SOAPAction: "getVersion". so in php SOAP class function just set :
example for createShipmentOrder:
$location = "https://cig.dhl.de/services/production/soap";
$options = array(
                           'login' => $user,                   //ApplikationsID
                           'password' => $password,   //Applikationstoken
                           'soap_version' => SOAP_1_1,
                           'exceptions' =>false,
                           'trace' => 1,
                    );

$client = new SoapClient($wsdl,$options);
$answer = $client->__doRequest($request,$location, 'urn:createShipmentOrder',1);

This error can also occur, if you do not have set the correct permissions for your application inside your dhl developer account. Each method you want to call needs to be activated there.

This error can also occur, if you do not have set the correct permissions for your application inside your dhl developer account. Each method you want to call needs to be activated there.

how to activated?the status of the application is requested granted.

To fix SECURITY_VIOLATION, the following notice on this page helped me:

Zusätzlich ist für die Geschäftskundenversand-API folgendes zu beachten:
In der Produktivumgebung ist im Header zusätzlich zwingend die SOAPAction der jeweiligen Operation mit anzugeben, bspw. "SOAPAction: "urn:createShipmentOrder"

After setting this header, the error was gone.

authors: FloPinguin JahangirNaik bindablue gmile-chris lgbr poviljaj saschanos vinett-de

repo: waldher/dhl-intraship


text:
[linux] reload comand does not pick up source file change because they are forks

Hi,
If I modify server.php and then run php server.php reload in linux, the workers are still running the old code because they are forked process and thus their memory is a copy of the parent process. How then can we reload source code change in linux without having to restart the master process every time?

For example.
start.php
$worker = new Worker('websocket://0.0.0.0:6666');
$worker->onWorkerStart = function($worker){
    // You can also use spl_autoload to require MyClass file.
    require __DIR__ . '/MyClass.php';
    $my_class = new MyClass();
    $worker->onConnect = [$my_class, 'onConnect'];
    $worker->onMessage = [$my_class, 'onMessage'];
    $worker->onClose = [$my_class, 'onClose'];
};
Worker::runAll();

MyClass.php
class MyClass
{
    public function onConnect($connection)
    {

    }

    public function onMessage($connection, $data)
    {

    }

    public function onClose($connection)
    {

    }
}

Thank you, it works.
I'll try to explain what happens here for other people that might face the same problem. We put the application code in a class in a separate file. But we don't load the class in server.php. That way, when the process is forked, the application class does not exist yet in the PHP cache. Then we require the application class in onWorkerStart thus causing it to load the updated application class every time a worker is restarted.

A caveat of this is that since the application code is required inside a function, any global variables inside it need to be declared global.
app.php
global $var;
$var = 'some global value';

function onMessage($connection, $request)
{

}

引入文件报错 咋回事?

 引入文件报错 咋回事?

myclass里操作不了数据库？

authors: char101 shunhua walkor

repo: walkor/Workerman


text:
[Feature]: Overwrite nested default config in sweep

Description
I would love a better handling of nested configs during sweeping. Specifically, I would like to be able to provide a default config in wandb.init(config=defaults) whose parameters are only update by the sweep config.
This is an example sweep configuration (in Jupyter):
sweep_configuration = {     'method': 'bayes',     'metric': {         'goal': 'minimize',          'name': 'valid/best_loss'     },     'parameters': {         'model': {             'parameters': {                 'cgnn': {                     'parameters': {                         'train': {                             'parameters': {                                 'batch_s': {'values': [4, 8, 16]},                                 'lr': {'max': 0.1, 'min': 0.0001}                             }                         },                         'model': {                             'parameters': {                                 'num_layers': {'values': [2, 4, 6]},                                 'head_num': {'values': [4, 8, 16]},                                 'embed_dim': {'values': [64, 128]},                                 'ff_hidden_dim': {'values': [256, 512]},                                 'softmax': {'values': [True, False]},                                 'extra_out': {'values': [True, False]},                             }                         }                     }                 }             }         }     } }
If there is a better way to define a nested sweep config let me know. A solution could massively reduce overhead when setting up a sweep config.
Suggested Solution
When providing a nested default config in wandb.init(config=defaults) the config provided by the sweep should preserve the original nested structure of the default config when adding/overwriting values.
For the above sweep configuration, this would mean the wandb.config would also contain additional training parameters like weight decay etc.
I think a solution should just do a recursive config merge.
Alternatives
No response
Additional Context
No response

Thank you for writing in @dschaub95.  We have recent and in progress updates into how nested sweep configs are handled. I will review your input and provide feedback soon.

Any updates on this? It unfortunately makes nested sweep configs impractical to use.

Here is a minimal reproducible example:
import wandb
print(wandb.__version__)
def main():
    default_config = {'model': {'dim': 2, 'lr': 0.1}}
    wandb.init(config=default_config, mode='disabled')
    print(wandb.config)
    wandb.finish()

print('Wandb context')
main()

print('Sweep Context')
sweep_config = {
    'method': 'grid',
    'parameters': {
        'model.dim': {
            'values': [8, 16]
        }
    }
}
sweep_id = wandb.sweep(sweep_config)
wandb.agent(sweep_id, function=main, count=1)

outputs:
0.14.0
Wandb context
{'model': {'dim': 2, 'lr': 0.1}}
Sweep Context
Create sweep with ID: 2pt4a8no
Sweep URL: https://wandb.ai/rapharomero/uncategorized/sweeps/2pt4a8no
wandb: Agent Starting Run: n9il6acn with config:
wandb:  model.dim: 8
{'model.dim': 8, 'model': {'dim': 2, 'lr': 0.1}}

Instead we would expect the sweep output to be {'model': {'dim': 8, 'lr': 0.1}}} i.e. the model.dim should get updated during the sweep.

A second MRE: Using the nested sweep config configuration, with wandb in disabled mode
import wandb

print(wandb.__version__)
default_config = {'model': {'dim': 2, 'lr': 0.1}}

def main():
    wandb.init(config=default_config, mode='disabled')
    print(wandb.config)
    wandb.finish()

print('Wandb context')
main()

print('Sweep Context')

sweep_config = {
    'method': 'grid',
    'parameters': {
        'model': {
            'parameters': {
                'dim': {
                    'values': [2, 8, 16]
                }
            }
        }
    }
}

sweep_id = wandb.sweep(sweep_config)
wandb.agent(sweep_id, function=main, count=1)

outputs the following error
0.14.0
Wandb context
{'model': {'dim': 2, 'lr': 0.1}}
Sweep Context
Create sweep with ID: fexck74s
Sweep URL: https://wandb.ai/rapharomero/uncategorized/sweeps/fexck74s
wandb: Agent Starting Run: zdg3kzf2 with config:
wandb:  model: {'dim': 2}
Traceback (most recent call last):
  File "/home/raphael/anaconda3/envs/pylab/lib/python3.8/site-packages/wandb/sdk/wandb_init.py", line 1144, in init
    run = wi.init()
  File "/home/raphael/anaconda3/envs/pylab/lib/python3.8/site-packages/wandb/sdk/wandb_init.py", line 556, in init
    return self._make_run_disabled()
  File "/home/raphael/anaconda3/envs/pylab/lib/python3.8/site-packages/wandb/sdk/wandb_init.py", line 513, in _make_run_disabled
    drun.config.update(self.config)
  File "/home/raphael/anaconda3/envs/pylab/lib/python3.8/site-packages/wandb/sdk/wandb_config.py", line 185, in update
    sanitized = self._update(d, allow_val_change)
  File "/home/raphael/anaconda3/envs/pylab/lib/python3.8/site-packages/wandb/sdk/wandb_config.py", line 178, in _update
    sanitized = self._sanitize_dict(
  File "/home/raphael/anaconda3/envs/pylab/lib/python3.8/site-packages/wandb/sdk/wandb_config.py", line 238, in _sanitize_dict
    k, v = self._sanitize(k, v, allow_val_change)
  File "/home/raphael/anaconda3/envs/pylab/lib/python3.8/site-packages/wandb/sdk/wandb_config.py", line 262, in _sanitize
    raise config_util.ConfigError(
wandb.sdk.lib.config_util.ConfigError: Attempted to change value of key "model" from {'dim': 2} to {'dim': 2, 'lr': 0.1}
If you really want to do this, pass allow_val_change=True to config.update()

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/raphael/anaconda3/envs/pylab/lib/python3.8/site-packages/wandb/sdk/wandb_init.py", line 1152, in init
    getcaller()
  File "/home/raphael/anaconda3/envs/pylab/lib/python3.8/site-packages/wandb/sdk/wandb_init.py", line 838, in getcaller
    src, line, func, stack = logger.findCaller(stack_info=True)
AttributeError: '_EarlyLogger' object has no attribute 'findCaller'
wandb: ERROR Abnormal program exit
Run zdg3kzf2 errored: Exception('problem')
wandb: ERROR Run zdg3kzf2 errored: Exception('problem')

However, if I run the same code as before with wandb mode = 'offline',i.e.
import wandb

print(wandb.__version__)
default_config = {'model': {'dim': 2, 'lr': 0.1}}

def main():
    wandb.init(config=default_config, mode='offline')
    print(wandb.config)
    wandb.finish()

print('Wandb context')
main()

print('Sweep Context')

sweep_config = {
    'method': 'grid',
    'parameters': {
        'model': {
            'parameters': {
                'dim': {
                    'values': [8, 16]
                }
            }
        }
    }
}
sweep_id = wandb.sweep(sweep_config)
wandb.agent(sweep_id, function=main, count=1)

I get
0.14.0
Wandb context
wandb: Tracking run with wandb version 0.14.0
wandb: W&B syncing is set to `offline` in this directory.
wandb: Run `wandb online` or set WANDB_MODE=online to enable cloud syncing.
{'model': {'dim': 2, 'lr': 0.1}}
wandb: Waiting for W&B process to finish... (success).
wandb: You can sync this run to the cloud by running:
wandb: wandb sync /home/raphael/Work/aida_ugent/latent_trajectory-private/code/wandb/offline-run-20230403_163408-tv1q7fyx
wandb: Find logs at: ./wandb/offline-run-20230403_163408-tv1q7fyx/logs
Sweep Context
Create sweep with ID: lvqiwynh
Sweep URL: https://wandb.ai/rapharomero/uncategorized/sweeps/lvqiwynh
wandb: Agent Starting Run: iir10yjz with config:
wandb:  model: {'dim': 8}
wandb: Tracking run with wandb version 0.14.0
wandb: W&B syncing is set to `offline` in this directory.
wandb: Run `wandb online` or set WANDB_MODE=online to enable cloud syncing.
{'model': {'dim': 2}}
wandb: Waiting for W&B process to finish... (success).
wandb: You can sync this run to the cloud by running:
wandb: wandb sync /home/raphael/Work/aida_ugent/latent_trajectory-private/code/wandb/offline-run-20230403_163419-iir10yjz
wandb: Find logs at: ./wandb/offline-run-20230403_163419-iir10yjz/logs

However we would expect the printed  output during the sweep to be {'model': {'dim': 8, 'lr': 0.1}}
Instead it seems that during the sweep run, the default configs get erased and replaced by the configs specified in the sweep config.

To summarize, it would be nice if both the 'dot-trick' syntax and the 'nested parameter' sweep config version would replace the relevant default config by their values specified by the sweep.

Just ran into the same issue where the default configs for nested parameter got erased and were replaced by the ones defined in the sweep config. Having the ability to just overwrite the specified keys would be immensely helpful (as well as intuitive). If not, it would be great if this is mentioned in the docs so users know what to expect.

authors: MBakirWB dschaub95 maartenbuyl pecey rapharomero

repo: wandb/wandb


text:
chore(ui): add custom styles to column menu items

Description

Fixes WB-NNNNN
Fixes #NNNN

What does the PR do? Include a concise description of the PR contents.
Testing
How was this PR tested?

#3152  👈 (View in Graphite)
master

This stack of pull requests is managed by Graphite. Learn more about stacking.

repo: wandb/weave


text:
移植了PHP版本

公司项目用百度地图采集了一些点位，需要转换为84和国测局坐标，谢谢您提供的转换库~
因移动端需要移植了PHP版本，并发布了composer包，托管地址：
https://github.com/billy-poon/coordtransform
希望您不介意~

不会不会，随便用

authors: billy-poon wandergis

repo: wandergis/coordtransform


text:
so good

i need it. so good

Thanks.

authors: apimello wandergis


text:
一个页面嵌入多个编辑框产生的问题

一个页面嵌入多个编辑框后 , toolbar 的部分按钮会失常, 例如 背景色 字体色 标题大小 字体等.

已解决 : 在移动端使用editor会使toolbar溢出,添加 overflow-x 之后会使 窗口错误.


text:
editor.config.withCredentials = false;设置无效

设置了editor.config.withCredentials = false;后，在图片上传ajax请求时还是带上了cookie。跟源码发现：//  xhr.withCredentials = editor.config.withCredentials || true;这个一直是true吧？

先自己把源码改一下，后面会统一改了这一个地方

建议升级 v3 版本，v3 解决了这一问题


text:
How do you use this?

Could you show us a guide on how to use this, please? It is very confusing.

pls check example.py under root folder

I mean everything is so confusing and hard to understand to be honest.
On Thu, May 5, 2022 at 4:02 PM anhdodotnet @.***> wrote:

Video GUI .... PLs
—
Reply to this email directly, view it on GitHub
https://github.com/wanghaisheng/youtube-auto-upload/issues/11#issuecomment-1118665077,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AYBHGWT5HSBAAXFLR7ZIV3DVIPPIVANCNFSM5VDSDQXQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

authors: viktorkovach wanghaisheng

repo: wanghaisheng/youtube-auto-upload