text:
ReferenceError: SVGElement is not defined, weird behavior with different Vue versions

Hi, I am the developer of this library and trying to migrate my tests to v2. However I encounter very confusing behavior with different Vue versions. Especially in the combination 2.0.0-rc.6 and Vue 3.0.11 I get the following error while trying to run my tests:
ReferenceError: SVGElement is not defined
    at Object.app.mount (/home/serg/Documents/Projects/vue-ellipse-progress/dist/js/webpack:/node_modules/@vue/runtime-dom/dist/runtime-dom.esm-bundler.js:1259:1)
    at mount (/home/serg/Documents/Projects/vue-ellipse-progress/dist/js/webpack:/node_modules/@vue/test-utils/dist/vue-test-utils.esm-bundler.js:7891:1)
    at factory (/home/serg/Documents/Projects/vue-ellipse-progress/dist/js/webpack:/tests/unit/container.spec.js:10:1)
    at Suite.<anonymous> (/home/serg/Documents/Projects/vue-ellipse-progress/dist/js/webpack:/tests/unit/container.spec.js:36:1)
    at Object.create (/home/serg/Documents/Projects/vue-ellipse-progress/node_modules/mocha/lib/interfaces/common.js:140:19)
    at context.describe.context.context (/home/serg/Documents/Projects/vue-ellipse-progress/node_modules/mocha/lib/interfaces/bdd.js:42:27)
    at Suite.<anonymous> (/home/serg/Documents/Projects/vue-ellipse-progress/dist/js/webpack:/tests/unit/container.spec.js:34:1)
    at Object.create (/home/serg/Documents/Projects/vue-ellipse-progress/node_modules/mocha/lib/interfaces/common.js:140:19)
    at context.describe.context.context (/home/serg/Documents/Projects/vue-ellipse-progress/node_modules/mocha/lib/interfaces/bdd.js:42:27)
    at Object../tests/unit/container.spec.js (/home/serg/Documents/Projects/vue-ellipse-progress/dist/js/webpack:/tests/unit/container.spec.js:33:1)
    at __webpack_require__ (/home/serg/Documents/Projects/vue-ellipse-progress/dist/js/webpack:/webpack/bootstrap:19:1)
    at run (/home/serg/Documents/Projects/vue-ellipse-progress/dist/js/webpack:/node_modules/mochapack/lib/entry.js:3:1)
    at Array.forEach (<anonymous>)
    at Object../node_modules/mochapack/lib/entry.js (/home/serg/Documents/Projects/vue-ellipse-progress/dist/js/webpack:/node_modules/mochapack/lib/entry.js:10:1)
    at __webpack_require__ (/home/serg/Documents/Projects/vue-ellipse-progress/dist/js/webpack:/webpack/bootstrap:19:1)
    at /home/serg/Documents/Projects/vue-ellipse-progress/dist/js/webpack:/webpack/bootstrap:83:1
    at Object.<anonymous> (/home/serg/Documents/Projects/vue-ellipse-progress/dist/js/main.js:87:10)
    at Module._compile (internal/modules/cjs/loader.js:1063:30)
    at Object.module_1.default._extensions.<computed> [as .js] (/home/serg/Documents/Projects/vue-ellipse-progress/node_modules/mochapack/src/util/registerRequireHook.ts:106:12)
    at Module.load (internal/modules/cjs/loader.js:928:32)
    at Function.Module._load (internal/modules/cjs/loader.js:769:14)
    at Module.require (internal/modules/cjs/loader.js:952:19)
    at require (internal/modules/cjs/helpers.js:88:18)
    at /home/serg/Documents/Projects/vue-ellipse-progress/node_modules/mocha/lib/mocha.js:334:36
    at Array.forEach (<anonymous>)
    at Mocha.loadFiles (/home/serg/Documents/Projects/vue-ellipse-progress/node_modules/mocha/lib/mocha.js:331:14)
    at Mocha.run (/home/serg/Documents/Projects/vue-ellipse-progress/node_modules/mocha/lib/mocha.js:809:10)
    at /home/serg/Documents/Projects/vue-ellipse-progress/node_modules/mochapack/src/runner/TestRunner.ts:105:23
    at /home/serg/Documents/Projects/vue-ellipse-progress/node_modules/mochapack/src/webpack/compiler/registerReadyCallback.ts:14:7
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/home/serg/Documents/Projects/vue-ellipse-progress/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:45:1)
    at AsyncSeriesHook.lazyCompileHook (/home/serg/Documents/Projects/vue-ellipse-progress/node_modules/tapable/lib/Hook.js:154:20)
    at /home/serg/Documents/Projects/vue-ellipse-progress/node_modules/webpack/lib/Compiler.js:304:22
    at Compiler.emitRecords (/home/serg/Documents/Projects/vue-ellipse-progress/node_modules/webpack/lib/Compiler.js:499:39)
    at /home/serg/Documents/Projects/vue-ellipse-progress/node_modules/webpack/lib/Compiler.js:298:10
    at /home/serg/Documents/Projects/vue-ellipse-progress/node_modules/webpack/lib/Compiler.js:485:14
    at eval (eval at create (/home/serg/Documents/Projects/vue-ellipse-progress/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:16:1)
    at /home/serg/Documents/Projects/vue-ellipse-progress/node_modules/copy-webpack-plugin/dist/index.js:115:7
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/home/serg/Documents/Projects/vue-ellipse-progress/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:12:1)
    at AsyncSeriesHook.lazyCompileHook (/home/serg/Documents/Projects/vue-ellipse-progress/node_modules/tapable/lib/Hook.js:154:20)
    at /home/serg/Documents/Projects/vue-ellipse-progress/node_modules/webpack/lib/Compiler.js:482:27
    at /home/serg/Documents/Projects/vue-ellipse-progress/node_modules/neo-async/async.js:2818:7
    at done (/home/serg/Documents/Projects/vue-ellipse-progress/node_modules/neo-async/async.js:3522:9)
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/home/serg/Documents/Projects/vue-ellipse-progress/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1)
    at /home/serg/Documents/Projects/vue-ellipse-progress/node_modules/webpack/lib/Compiler.js:464:33
    at MemoryFileSystem.writeFile (/home/serg/Documents/Projects/vue-ellipse-progress/node_modules/memory-fs/lib/MemoryFileSystem.js:328:9)
    at writeOut (/home/serg/Documents/Projects/vue-ellipse-progress/node_modules/webpack/lib/Compiler.js:462:30)
    at Immediate._onImmediate (/home/serg/Documents/Projects/vue-ellipse-progress/node_modules/memory-fs/lib/MemoryFileSystem.js:288:4)
    at processImmediate (internal/timers.js:461:21)

I have tried different versions combinations and have noticed strange things. The tests run as expected with Vue 3.0.6 - 3.0.7 but with 3.0.8 - 3.0.11 i get the error, same with 3.0.5.
How to reproduce
Clone the repo and run in the v2-unit-test branch with Node.js 14.16:
npm i
npm run test

Hi @setaman , thanks for opening an issue
I think this is unrelated to VTU. The same concern has been raised in the vue-next repo: see https://github.com/vuejs/vue-next/issues/3590 and other related issues.
I'll let you track these issues and I'm going to close this one.

Hi @cexbrayat,
thanks, i see, the issues are coming now.

authors: cexbrayat setaman


text:
Support for renderer options in server-test-utils

Feature Description
An optional server-side rendering config object for the Vue server-side renderer when rendering components using  server-test-utils.
Proposed API:
await render(Component, mountOptions, ssrOptions)

Problem
Projects that use SSR specific configuration like cache or directives have no way of passing those configurations to the render uses in server-test-utils.  This leads to rendering errors/warnings caused by missing configuration in which the component been tested depends on.
For my specific use case, we heavily use serverCacheKey within components to speed up server-side rendering which causes a lot of warnings from Vue in our tests as no cache was provided to the renderer.
Expected behaviour
The SSR options passed to the render in server-test-utils is used to initialize Vue's server-side renderer.

Hi! I am not very familiar with SSR - would this just be a matter of allowing an extra object of options to be passed to render?

source: gharchive/issue

repo: vuejs/vue-test-utils

license: MIT

license_type: permissive

license_source: github-api


text:
[Feature request] escape dot in path

https://jsfiddle.net/azamatsharapov/9daapg2u/
Above fiddle is super simple. I had a situation, where I had to set deep nested objects coming from server. Object keys had dots and code became verbose, because I had to first create each key via Vue.set() and then assign value using Vue.set() again. It would be nice if we could escape dot in object.

You can actually do this.$set('obj.subObj["' + keyWithDot + '"]', 'works') ;)

oh :smile: xie xie

repo: vuejs/vue


text:
State of provide/inject

Provide/Inject allows ancestor component to serve as a dependency injector. Injected dependencies are not reactive. As per docs, if an observed property is provided it remains reactive.
I've created a fiddle (https://jsfiddle.net/1hcpbrjz/4/) to demonstrate few scenarios.
This feature is very new, so docs are too shallow.
Question: How to provide reactive data props and computed prop?

@Akryum Can you update the fiddle with an example?
I think we should add some examples in docs too.

https://github.com/vuejs/vue/pull/5075

https://github.com/vuejs/vue/pull/5229

authors: gefangshuai znck


text:
ie下template无法获取v-for的index

Version
2.5.16
Reproduction link
https://codepen.io/zarte-the-bold/pen/MzEqoJ
Steps to reproduce
如下代码

ie中无法正常渲染
What is expected?
.
What is actually happening?
[Vue warn]: Error when rendering root instance:
“index”未定义

It works fine on IE

authors: posva zarte


text:
feat(warnings): Suggest casting boolean keys

Closes #6126

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

[ ] Bugfix
[x] 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 dev 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)
[x] All tests are passing: https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#development-setup
[x] New/updated tests are included

If adding a new feature, the PR's description includes:

[ ] A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:

Let's just support boolean keys, it's not best practice but it should work if the user know what they're doing.

I added the check to isPrimitive

source: gharchive/pull-request


text:
to-iso-string has been deprecated, use segment to iso string

npm WARN deprecated to-iso-string@0.0.2: to-iso-string has been deprecated, use @segment/to-iso-string instead.

These are nested dependencies + non critical deprecation, we have little control over these.

repo: vuejs/vueify


text:
Inaccuracy in comparisons guide

我就觉得官方文档中 “深入响应式原理”一章中，对于数据绑定的解释那里表达的不够清楚，明白。文档上是这么说的：当你把一个普通的 JavaScript 对象传给 Vue 实例的 data 选项，Vue 将遍历此对象所有的属性，并使用 Object.defineProperty 把这些属性全部转为 getter/setter。
什么是getter/setter？   翻阅书籍，书中说是访问器属性的其中两个特性。意思是他是一个属性的特性，而不是属性本身。（因为访问器属性还有另外两个跟数据属性相同的特性，configbale  evaluable）,所以你们想表达的是不是：当你把一个普通的 JavaScript 对象传给 Vue 实例的 data 选项，Vue 将遍历此对象所有的（数据）属性，并使用 Object.defineProperty 把这些（数据）属性全部转为访问器属性。   这个意思？

@Jinjiang Would you say this is an issue with the Chinese docs or does this apply to the English docs as well?

@Jinjiang Thanks! Just added the link. 🙂

authors: CoffeeandTea chrisvfritz


text:
Menu options not working on click while using with LitElement.

Hi,
In my case, I'm using this library with LitElement.
Everything works as expected, but I cannot seem to click the menu options (the one that appears after I right-click the canvas).
:exclamation: JS Fiddle for what I tried and the issue.
Whenever I click on any of these menu options, nothing happens:

My understanding
Also, when I used the chunk of code provided from CDN Quickstart in vanilla JS, everything worked as expected. I think there's some issue because of the shadow DOM.

Thanks for letting me know.
That bug is my mistake!

authors: NadeemShakya dineug

repo: vuerd/vuerd


text:
Nuxt3 compatibility

Version
@vueup/vue-quill version ^1.0.0-beta.7
Nuxt 3
Describe the bug
ReferenceError: document is not defined in node_modules\quill\dist\quill.js
To Reproduce
Steps to reproduce the behavior:

Create nuxt3 App,
install @vueup/vue-quill
create plugins folder
create quill.ts file
Add: import { defineNuxtPlugin } from '#app'
import { QuillEditor } from '@vueup/vue-quill'
import '@vueup/vue-quill/dist/vue-quill.snow.css';
import '@vueup/vue-quill/dist/vue-quill.bubble.css';
export default defineNuxtPlugin(nuxtApp => {
// Doing something with nuxtApp
nuxtApp.vueApp.component('QuillEditor', QuillEditor);
})

Browser (please complete the following information):

Chrome

Sorry! It's working 100%... on nuxt3 you can make your plugins clientside by renaming your file quill.client.ts

Hello @PMLS3
Did the same as you but I'm getting this error -->
Failed to resolve component: QuillEditor
If this is a native custom element, make sure to exclude it from component resolution via compilerOptions.isCustomElement.

i added into component like this.

How did you resolved this?
Thanks for your help.

Sorry! It's working 100%... on nuxt3 you can make your plugins clientside by renaming your file quill.client.ts

how import module to this plugin ?

repo: vueup/vue-quill


text:
Performance issue, one array item update triggers all children components re-render

Describe the bug
when use query result with v-for, any item in the list get updated will trigger all children components rerender.
Steps to reproduce the bug

Define models
Create data
Retrieve data
Bind data to component as computed property
Loop items with v-for, pass items to child component
update one of the item
all the children components get updated/re-rendered

Expected behaviour
Only the component with the updated item should be re-rendered.
Versions

Vuex ORM: 0.36.3
Vue: 2.6.11

Link to minimal reproduction
CodeSandbox https://codesandbox.io/s/broken-https-l8mk8?file=/src/App.vue
Additional context
I tested with normal usage of vuex, has no this kind of issue. please check out the example in the code sandbox above.

it also exists in the next version
https://codesandbox.io/s/sharp-lichterman-5hwnq?file=/src/App.vue

This is currently expected behavior. Your Vuex example is not equal to what Vuex ORM is doing.
The thing is, Vuex ORM returns new records from the store. Try changing your list computed property to this.
const list = computed(() => {
  return store.state.list.map((item) => ({ ...item }));
});

Then you can see 2 update log is called. Vuex ORM must return a new object instead of returning the store state as is because we must "mutate" the state before returning it when we have relationships.
To resolve this issue, I think we need to implement a caching system in Vuex ORM.

authors: axe-me kiaking

repo: vuex-orm/vuex-orm


text:
Link to roadmap broken

Hi there,
the link on the readme page http://www.vui-kit.com/docs/getting-started/roadmap redirects to 404 but website navigation to roadmap works fine.
Keep up the good work.

Issue has been resolved

authors: pongoman vui-kit

repo: vui-kit/vui


text:
FromScript factory method

Before the factory method, FromScript has added it was not possible to create nested Payment based on script.
After the factory method, FromScript returns nested Payment based on script.
It closes #10
Please @altafan can you review this?

@sekulicd can you add the missing commits from master? Although there are no conflicts, your branch is 3 commits behind vulpemventures/master

authors: altafan sekulicd

repo: vulpemventures/go-elements


text:
Fix send all L-BTC behavior

This PR adds a new createSendAllPset method to PsetBuilder class. It lets to handle correctly the SEND ALL behavior in wallet/send/choose-fee.
it also adds receive & send Playwright tests.
it closes #438
@tiero @bordalix please review

NIT: maybe on this screen show the amount minus the fee?

authors: bordalix louisinger

repo: vulpemventures/marina


text:
Get the prices by contract id

This PR simplifies the handling of token identifiers by removing all CoinGecko IDs and only adding tokens by contract addresses. It caches tokens by contract address, chain, and fiat, allowing the same contract addresses to exist across multiple chains.
Changes:

Removed CoinGecko IDs for tokens.
Added token caching by contract address, chain, and fiat.
Allowed the same contract addresses to exist in multiple chains.
Removed the unique constraint for the ID to prevent app breaks.

Testing:

Successfully tested adding and removing tokens individually and in bulk.
Verified functionality with max buttons and custom tokens.
Confirmed adding and deleting custom tokens.
Custom tokens now show prices from pools, enhancing competitiveness with MetaMask.

After a few tests, I could see the app was freezing. I will check if it is using the tasks and another thread.

repo: vultisig/vultisig-ios


text:
AOSP 4.4: XmlPullParserException: Binary XML file line #0: invalid drawable tag vector

When starting the GUI app:
06-30 09:40:21.827 1845-1845/org.iseclab.drammer E/AndroidRuntime: FATAL EXCEPTION: main
    Process: org.iseclab.drammer, PID: 1845
    android.content.res.Resources$NotFoundException: File res/drawable/ic_info_outline.xml from drawable resource ID #0x7f060062
        at android.content.res.Resources.loadDrawable(Resources.java:2101)
        at android.content.res.Resources.getDrawable(Resources.java:700)
        at android.support.v4.content.ContextCompat.getDrawable(ContextCompat.java:323)
        at android.support.v7.widget.TintManager.getDrawable(TintManager.java:147)
        at android.support.v7.view.menu.MenuItemImpl.getIcon(MenuItemImpl.java:421)
        at android.support.v7.view.menu.ActionMenuItemView.initialize(ActionMenuItemView.java:114)
        at android.support.v7.widget.ActionMenuPresenter.bindItemView(ActionMenuPresenter.java:206)
        at android.support.v7.view.menu.BaseMenuPresenter.getItemView(BaseMenuPresenter.java:182)
        at android.support.v7.widget.ActionMenuPresenter.getItemView(ActionMenuPresenter.java:192)
        at android.support.v7.widget.ActionMenuPresenter.flagActionItems(ActionMenuPresenter.java:451)
        at android.support.v7.view.menu.MenuBuilder.flagActionItems(MenuBuilder.java:1138)
        at android.support.v7.view.menu.BaseMenuPresenter.updateMenuView(BaseMenuPresenter.java:91)
        at android.support.v7.widget.ActionMenuPresenter.updateMenuView(ActionMenuPresenter.java:229)
        at android.support.v7.view.menu.MenuBuilder.dispatchPresenterUpdate(MenuBuilder.java:284)
        at android.support.v7.view.menu.MenuBuilder.onItemsChanged(MenuBuilder.java:1030)
        at android.support.v7.view.menu.MenuBuilder.startDispatchingItemsChanged(MenuBuilder.java:1053)
        at android.support.v7.app.AppCompatDelegateImplV7.preparePanel(AppCompatDelegateImplV7.java:1315)
        at android.support.v7.app.AppCompatDelegateImplV7.doInvalidatePanelMenu(AppCompatDelegateImplV7.java:1553)
        at android.support.v7.app.AppCompatDelegateImplV7.access$100(AppCompatDelegateImplV7.java:89)
        at android.support.v7.app.AppCompatDelegateImplV7$1.run(AppCompatDelegateImplV7.java:129)
        at android.os.Handler.handleCallback(Handler.java:733)
        at android.os.Handler.dispatchMessage(Handler.java:95)
        at android.os.Looper.loop(Looper.java:136)
        at android.app.ActivityThread.main(ActivityThread.java:5017)
        at java.lang.reflect.Method.invokeNative(Native Method)
        at java.lang.reflect.Method.invoke(Method.java:515)
        at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:779)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:595)
        at dalvik.system.NativeStart.main(Native Method)
     Caused by: org.xmlpull.v1.XmlPullParserException: Binary XML file line #0: invalid drawable tag vector
        at android.graphics.drawable.Drawable.createFromXmlInner(Drawable.java:933)
        at android.graphics.drawable.Drawable.createFromXml(Drawable.java:877)
        at android.content.res.Resources.loadDrawable(Resources.java:2097)
        at android.content.res.Resources.getDrawable(Resources.java:700)
        at android.support.v4.content.ContextCompat.getDrawable(ContextCompat.java:323)
        at android.support.v7.widget.TintManager.getDrawable(TintManager.java:147)
        at android.support.v7.view.menu.MenuItemImpl.getIcon(MenuItemImpl.java:421)
        at android.support.v7.view.menu.ActionMenuItemView.initialize(ActionMenuItemView.java:114)
        at android.support.v7.widget.ActionMenuPresenter.bindItemView(ActionMenuPresenter.java:206)
        at android.support.v7.view.menu.BaseMenuPresenter.getItemView(BaseMenuPresenter.java:182)
        at android.support.v7.widget.ActionMenuPresenter.getItemView(ActionMenuPresenter.java:192)
        at android.support.v7.widget.ActionMenuPresenter.flagActionItems(ActionMenuPresenter.java:451)
        at android.support.v7.view.menu.MenuBuilder.flagActionItems(MenuBuilder.java:1138)
        at android.support.v7.view.menu.BaseMenuPresenter.updateMenuView(BaseMenuPresenter.java:91)
        at android.support.v7.widget.ActionMenuPresenter.updateMenuView(ActionMenuPresenter.java:229)
        at android.support.v7.view.menu.MenuBuilder.dispatchPresenterUpdate(MenuBuilder.java:284)
        at android.support.v7.view.menu.MenuBuilder.onItemsChanged(MenuBuilder.java:1030)
        at android.support.v7.view.menu.MenuBuilder.startDispatchingItemsChanged(MenuBuilder.java:1053)
        at android.support.v7.app.AppCompatDelegateImplV7.preparePanel(AppCompatDelegateImplV7.java:1315)
        at android.support.v7.app.AppCompatDelegateImplV7.doInvalidatePanelMenu(AppCompatDelegateImplV7.java:1553)
        at android.support.v7.app.AppCompatDelegateImplV7.access$100(AppCompatDelegateImplV7.java:89)
        at android.support.v7.app.AppCompatDelegateImplV7$1.run(AppCompatDelegateImplV7.java:129)
        at android.os.Handler.handleCallback(Handler.java:733)
        at android.os.Handler.dispatchMessage(Handler.java:95)
        at android.os.Looper.loop(Looper.java:136)
        at android.app.ActivityThread.main(ActivityThread.java:5017)
        at java.lang.reflect.Method.invokeNative(Native Method)
        at java.lang.reflect.Method.invoke(Method.java:515)
        at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:779)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:595)
        at dalvik.system.NativeStart.main(Native Method)

Thanks! Again, no idea what is happening here. What device are you running? I will share this with Martina (who wrote the app code).

It's the Android Studio emulator with Android 4.4

Aha. Do you have the same issues with later Android versions in the emulator?
Nevertheless, I don't think that the native code will ever work properly from within the emulator, so please avoid any extensive debugging from your side.

I just confirmed with the emulator the problem that I had on a physical Android 4.4 device.

I see. We will have a look. Thanks!

repo: vusec/drammer

license_source: bigquery


text:
vcard export

A https://en.wikipedia.org/wiki/VCard export for users#view. I'm not sure which URL is the best for this. Maybe /users/:slug.vcard

New issue for this: https://github.com/vutuv/vutuv/issues/123

repo: vutuv/vutuv

license: mit


text:
odd indention on async class function

Using async keyword on a class function is causing the function body to not indent (and then screws up the indention for the rest of the file)

@awdogsgo2heaven please report to https://github.com/Microsoft/TypeScript/ .
typescript-formatter is using language service.
your problem will be resolve when TypeScript support it.

repo: vvakame/typescript-formatter


text:
Step size for value properties

Eg. allows the slider widget to have step resolution (eg. 0.2) ( or 1 to step through integers)

Should this be part of the ValueProperty itself?
...going back to the topic of complexifying the ValueProperty or leaving the complexity into the editor.
connected also to Cycleable component I guess...

Solved with StepSize Component

authors: sebescudie vvvv-dottore


text:
Research svg root element error

Reference Issue
Test case for issue #400 regarding the possible problems with multiple drawing on an open document. The testcase uses the SVG file provided @8m0 and tests multi drawings, one test with drawings after each other, another test with drawing inside of another using block with a bitmap.
What does this implement/fix? Explain your changes.
Put multi-drawing in a test harness.
Any other comments?
Running with a different SVG causes no issues (on MacOs), running with the SVG provided by @8m0 however failed on Mac due to a font issue. The test might need to be validated on a Windows machine.

Thanks a lot! I will check this under Windows.
BTW, I was sure that I added the netcore target back to the unit tests, but looks like I didn't push it to master...

authors: gvheertum mrbean-bremen

repo: vvvv/SVG

license: MS-PL


text:
Fix config import

The config and command line input at the top of cg_enrich, cg_present, and cg_query need to have their order fixed so they import correctly.

Fixed with commit [gabe dd681e2] in cg_enrich.  No config reference in cg_present and cg_query so no changes there.

repo: vz-risk/Verum


text:
Use mySIMBL-Plugins while SIP is enabled

Hello,
Is there any way to use the mysimbl plugins while the SIP is enabled again (after installing MYSIMBL and all of the plugins successfully after disabling the SIP)?. To be precise I want to use the Plugin Safaristand in this way later. (Safari 10, OS X El Cap, latest Version).
Thank you!

Yes you can turn SIP back on after SIMBL is installed. Its possible that a future update may require it to be disabled again to update the SIMBL.osax bundle but aside from that you can continue to use mySIMBL with SIP off, it only needs to be turned on to install SIMBL.osax.

Yes I can use MySIMBL while SIP is turned off without any problems! The problem is that I cannot use Safaristand  (https://github.com/anakinsk/SafariStand) while SIP is turned off.

Dunno what the issue is, could be SafariStand if other plugins are working for you.
Might also just try running this command in terminal after you open Safari
osascript -e "tell application \"Safari\" to inject SIMBL"

When I enter the command I get an error.
"29:41: execution error: „Safari“ hat einen Fehler erhalten: Die Zugriffsrechte wurden verletzt. (-10004)"

I found it out: Under OS X Sierra and Safari 10 it is possible to enable SIP again and to use Safaristand. In OS X El Cap under Safari 10 it is not possible to possible to use Safaristand after enabling SIP again. Thank you all for your help!

I found it out: Under OS X Sierra and Safari 10 it is possible to enable SIP again and to use Safaristand. In OS X El Cap under Safari 10 it is not possible to possible to use Safaristand after enabling SIP again. Thank you all for your help!


text:
ALE and vim-go get in a fight when vim-go gofmt's by default

I'm running into a funky issue where vim-go and ALE get in a fight with each other. When I have both enabled and on purpose introduce an error, then write the file the gutter/sign bar stays empty, until I save the file a second time (no changes). Then ALE will correctly display the >> in the column.
This exact same thing happens if there was an error and I fix it. I need to save twice for the error or warning to be remove from the column.
Once I disable vim-go this behaviour goes away. After some digging this seems to be caused by vim-go's g:go_fmt_autosave being enabled. Once I set that to 0 the issue stops. I'm not entirely sure why this would be the case though and perhaps something @fatih might be able to shed some light on too.

The best way to fix this is to add gofmt support to ALE, which can fix files, and disable the formatting in vim-go. ALE is able to fix files when saving them, and wait until files have been fixed before checking them again.
As an aside, I've been considering letting fixers pass on output to linters, to save time with running certain programs like eslint and gofmt twice.

Why does ale uses gofmt? gofmt is a core part of vim-go and it's essential for formatting the source code. It has many bug fixes, supports for goimports, symlinks, history, etc.. I don't think disabling it is a good idea. However vim-go does not linting like ale or syntastic. What you can do is add the following that disabled opening a quickfix window if something is wrong (instead of turning of autosave for gofmt in vim-go):
let g:go_fmt_fail_silently = 1

Maybe a pull request can be opened for vim-go for returning the command to run for gofmt so that ALE can use it. Then it can fit into ALE's mechanisms.

The command is here: https://github.com/fatih/vim-go/blob/master/autoload/go/fmt.vim#L145 (where cmd is a list and command is a string, both are the same). Not sure how this is going to fix though :)

I agree with @fatih on this one. I also don't think (IMO) ALE should run gofmt.
Setting let g:go_fmt_fail_silently = 1 is a perfect solution for this problem without any compromises (like introducing formatting to ALE).

ALE will probably get gofmt eventually. It already supports some formatters, and more will come. For now, you can set that option to disable the other plugin.

Using let g:go_fmt_fail_silently = 1 seems to cause a different problem though, at least in NeoVim the UI now hangs. If I make change that's purposefully incorrectly indented, after issuing a :w the UI just sits there. Hitting return another time does the trick but now the file is all of a sudden considered read-only.

I don't think this is caused by letting gofmt fail silently. I also use Neovim together with ALE and vim-go and it works like a charm without any issues for me...

Maybe check and/or compare settings: https//github.com/svanharmelen/dotfiles

authors: daenney fatih svanharmelen w0rp


text:
Add support for Vim's tagstack to ALEGoToDefinition

Fixes #1236.
I added tests - but to be fair, this feature won't work on versions of Vim earlier than 8.1.0519 and the test automation script doesn't test on anything that recent.
The feature is designed to degrade gracefully; and I'm open to suggestions on how to best clarify the version requirement in the docs.

I modified the Dockerfile and ./run-tests script; and there are issues with my proposed unit test.  I'll put up a corrected version shortly.

We should add tests for this. I'll have to update the Docker image so the 8.1 version we build is new enough to contain this feature.

Agreed.  The test I added is fairly minimal; but passes when I build a custom Docker image and update the run-tests script to use a local image.  I'm happy to include the Dockerfile change as well, if you'd like.

@w0rp @reedriley doesn't seem to be working for me. :ALEGoToDefinition and when I  then it says tagstack is empty. So right now I use

@w0rp @reedriley doesn't seem to be working for me. :ALEGoToDefinition and when I C-t then it says tagstack is empty. So right now I use C-o

What version of Vim are you running?

@w0rp  @reedriley I have the same problem (tagstack is empty). I am using Vim 8.1. Fresh ALE, commit * 27146ade 2019-05-30

@wrachwal: To be clear, I actually meant to ask which version of Vim.  The tagstack manipulation functions the diff uses were added in Vim 8.1.0519.

Thanks, after upgrade using ppa:jonathonf/vim it works fine.
OLD VIM - Vi IMproved 8.1 (2018 May 18, compiled Nov  6 2018 09:45:53)
Included patches: 1-513
NEW VIM - Vi IMproved 8.1 (2018 May 18, compiled May 27 2019 13:46:23)
Included patches: 1-1408

Is there any plan to provide this functionality for NeoVim? I'm on the latest NeoVim version (v0.3.7) and I'm getting the same 'tagstack is empty' mentioned above

Yep its not working on neovim.

Same issue here. It is not working on neovim 0.3.8. Can we make it work for neovim by any chance? Thanks in advance!

@hourliert @rislah I just checked NeoVim's source, and it appears that their patch for vim-8.1.0519 hasn't made it out to a stable release yet. According  to that pull request, the update is targeted to be out in the 0.4 release. I've tested out the nightly release which contains the fix and verified that this tagstack feature works correctly.

authors: GoingFast dmchoiboi hourliert reedriley rislah wrachwal


text:
Refactor tidy support

Add an option for file encoding
Remove the type from text
Fix linter's name

I've just realized that the formatting does not follow the other files (indentation with spaces....).
Should I fix that?

Those changes were made yesterday, and I forgot to fix the indentation and multiple line continuations when I pushed.
Should be good now.

Looks pretty good to me. Cheers! :beers:


text:
Se mer på Codecov?

https://circleci.com/developer/orbs/orb/codecov/codecov

Fiks badge


text:
Rename localImplementationsConfig.example.cjs to add dot.

The missing dot at the beginning was confusing people.
Now they only have to remove .example from the filename which should be clearer/simpler.

@aljones15 could use your review on this one. I'd also want to roll it out across the other test suites.

@BigBlueHat This makes sense to me

We're going to leave the . prefix off so the file stays visible in more shells/listings.

authors: BigBlueHat tminard


text:
String - Spec minLength & maxLength

https://json-schema.org/understanding-json-schema/reference/string.html#length
We need to check:

ORM nullable capability to force minLength: 1 if not nullable
ORM type to set the max
form Constraint
object Assert
form attr.minlength & attr.maxlength

Hey @laurent-bientz. We're currently evaluating this bundle, and it looks very promising. However, it seems, development has stopped last year, I'm wondering if this is an active project?

Hello @solverat, this bundle is actively used internally on several (big) projects in production but you're right, we are running out of time to develop it deeper.
Actually the state of this bundle and the related front-end is stable and enough to meet ours actual needs.
If you want to contribute to the "missing" features, feel free to open a PR.
It's a complex part that requires time because we need to perform a lot of "reflections" on various vendors to bring these features!

@laurent-bientz I know the pain… :) We're evaluating the support of JSON schema support for our form builder (also open source) and surprisingly, there are not many alternatives out there. Limenius was on our track, but it seems to be dead (besides of some forks).
However, I think we're going to give this one a try, since it have a very solid, clean and nice codebase, the to-dos are well-defined.
First, I'm going to open issues, for everything which seems to be missing, if that's okay. If we're able to fulfill our requirements in the end, we're happy to provide some PRs (if required).

Hey @solverat, sounds good to me!
And yes, we also used Limenius before but the project didn't follow the json specs 100% and it was very difficult to discuss with the creator (if u're curious: https://github.com/Limenius/LiformBundle/issues/28), that's why we decided to start from scratch and not fork his work.

authors: laurent-bientz solverat


text:
Issue Opening Share From Obsidian.md

Hey,
I'm trying to use your app to access my Obsidian's vault stored on my TrueNas SMB Share.
I get this error message :

If you could help that would be great,
thanks
Edit For clarification :

Obsidian doesn't natively support opening vaults from a network
I checked the "Use As Local Storage" option and rebooted
When Selecting the location of the vault, Obsidian prompts me with a file explorer. There I am able to find the emulated "local storage" and I see the content of my NAS in there. It is only when I actually select the folder of my vault that I get the error message.

@BOTkirial
Sorry, I can't find the cause of the problem.
Could you please ask the Obsidian developer?


text:
pro_bar接口返回的复权后数据,只有open,high,low,close是复权的, 其他的都还是未复权数据

例如获取000001.SZ 1998年hfq数据, 接口返回的数据为:
 {}"ts_code" : "000001.SZ", "trade_date" : "19980327", "open" : 444.96, "high" : 459.72, "low" : 443.27, "close" : 453.18, "pre_close" : 21.15, "change" : 0.34, "pct_change" : 1.61, "vol" : 41937, "amount" : 89629.4968 }
而pre_close应为446.01, 等等.
id=131486

pre_close并没有加到复权数据里，我加一下吧

authors: SunYusheng jimmysoa

repo: waditu/tushare


text:
Add response font size setup in rem

cc @nicklee as per standard on Torchbox projects. We’ll have to add the base setup, and then roll it out throughout all existing font sizes defined in pixels.

Done in #132.

repo: wagtail/guide


text:
[Enhancement] Bulk purging with wagtailfrontendcache

Occasionally it can be useful to purge a lot or even all of the frontend cache. (For example, if site menus are stored as snippets, one might want to purge the entire site when a change is made to the menus.) I'm fairly certain all or most of the cache services we have backends for provide an API for doing this. It would be great for wagtailfrontendcache to provide a util function for using those.

Great suggestion, @harrislapiroff, we'd definitely use this! While your example covers complex site deployments well, I wager a site-wide cache busting action would be very useful for simple sites, as well.

I'm fairly certain all or most of the cache services we have backends for provide an API for doing this.

Certainly Cloudflare does, for what it's worth.

This is something I'd really like to see happen in Wagtail, I haven't yet managed to figure out a backwards-compatibile way to implement it though.

I'm fairly certain all or most of the cache services we have backends for provide an API for doing this.
Certainly Cloudflare does, for what it's worth.

Cloudfront's API supports this as well. It might also be possible to optimise the HTTP backend to support batching too by sending multiple requests at a time.

Just wrote an RFC for a backwards-compatible way this could be implemented: https://github.com/wagtail/rfcs/issues/20

Started work on an implementation of aforementioned RFC: https://github.com/wagtail/wagtail/compare/master...kaedroho:feature/batch-frontend-cache-invalidation

authors: conorsch harrislapiroff kaedroho

repo: wagtail/wagtail


text:
Telepath: top-level versioned_static calls need to be eliminated

Opening this more as a memo to self: the feature/telepath branch has introduced various class Media definitions containing calls to versioned_static, which get evaluated on startup. As per #5632 / #5693, this isn't valid because ManifestStaticFilesStorage requires collectstatic to run before it can expand static paths (and having calls to versioned_static on startup will prevent collectstatic from running).
Given that we ideally want to decouple telepath as a library from Wagtail, it makes sense to avoid telepath having a hard dependency on Wagtail's versioned_static helper anyhow.

Fixed in #6805


text:
Improve visibility of error messages

Is your proposal related to a problem?

When ever I have validation errors when trying to save a page (or other model) in the Wagtail admin, I find it hard to identify the field with the error.
I believe this is particularly hard for me as I have a form of "deuteranomalia" which causes "red" for me to be less saturated than for other people. As a result, the small red error text appears basically grey to me and is hard to distinguish from the rest of the page content.
On simple field like text inputs this is less annoying since the entire field changes its styling. But, especially on chooser fields there is no indication apart from the small text.
Describe the solution you'd like

I could imagine the style to be updated in the following order of usefulness (most to least):

Add a icon at the beginning of the error text (something like this maybe ❌)
Use a bold font.
Increase the font size.
Use a brighter red.

I understand that might be ugly from a design perspective, but this is only visible when something is amiss and important information needs to be transported to the user.
Describe alternatives you've considered

Not much I can do but slowly scroll the pages.
Additional context

Here is an example comparison:

Here is the changed .error-message class I have used:
.error-message {
    color: #d93030;
    font-weight: bold;
    font-size: small;
}

Thank you for the very solid initial report @tbrlpld, and thank you to @Wicked7000 for making the PR. This will be released in v2.16, due in a few weeks.

authors: tbrlpld thibaudcolas


text:
EmbedBlock.Meta.help_text not used

Found a bug? Please fill out the sections below. 👍
Issue Summary
When subclassing the EmbedBlock and setting the help_text in the Meta class, this help text does not show up in the admin.
When providing the help_text argument to the constructor of the block it is used.
See this example from the bakery demo:
class CustomEmbedBlock(EmbedBlock):

    class Meta:
        help_text='Insert an embed URL e.g https://www.youtube.com/embed/SGJFWirQ3ks'
        icon="fa-s15"
        template="blocks/embed_block.html"

class BaseStreamBlock(StreamBlock):
    """
    Define the custom blocks that `StreamField` will utilize
    """
    heading_block = HeadingBlock()
    paragraph_block = RichTextBlock(
        icon="fa-paragraph",
        template="blocks/paragraph_block.html"
    )
    image_block = ImageBlock()
    block_quote = BlockQuote()
    embed_block = EmbedBlock(
        help_text='Insert an embed URL e.g https://www.youtube.com/embed/SGJFWirQ3ks',
        icon="fa-s15",
        template="blocks/embed_block.html")
    custom_embed_block = CustomEmbedBlock()

Steps to Reproduce

Subclass the wagtail.embeds.blocks.EmbedBlock
Define the Meta class with a help_text attribute.
Add this block to a stream field definition without arguments.
Open the Wagtail admin and create a page with the custom embed block in a streamfield.
Observe that when adding the custom block to the stream field the field is not showing the help text

Any other relevant information. For example, why do you consider this a bug and what did you expect to happen instead?

I have confirmed that this issue can be reproduced as described on a fresh Wagtail project: (yes / no)

Technical details

Python version: 3.9.9
Django version: 3.1.11
Wagtail version: 2.15.1 (and main)
Browser version: You can use https://www.whatsmybrowser.org/ to find this out.

This is because EmbedBlock is derived from URLBlock, which passes help_text directly from the constructor argument to the field object, without any intervention from the meta class:
https://github.com/wagtail/wagtail/blob/c54f7852d04316279fe9d4a3ab2b3a751e5df18f/wagtail/core/blocks/field_block.py#L237-L244
I don't think this counts as a bug though - there's nothing in the docs that suggests that subclassing EmbedBlock or any other FieldBlock-derived block type is a supported mechanism.

@gasman Hm, interesting. True, I had not checked if this is a documented behaviour. I just assumed that it works like that because it does for the structural block types.
I am happy to convert this from a bug report to a feature request, as I think it makes sense to have the help_text be consistent with other attributes like icon or template, which can be defined in the EmbedBlock.Meta class.

OK, yep, that sounds fair enough. There are some extra considerations around migrations when subclassing other block types, detailed in https://docs.wagtail.org/en/stable/advanced_topics/customisation/streamfield_blocks.html#handling-block-definitions-within-migrations, so I'm not sure that this is something we want to actively encourage as part of the documented API - but as long as that note remains in place in the docs I guess we can support it for 'power users'.

authors: gasman tbrlpld


text:
docs search not working in versions

I just noticed this problem: (not very important).
I was looking for something. For some reason the search did not work proper:
https://docs.wagtail.org/en/v3.0.1/search.html?q=ModelAdmin#
This due v3.0.1 in url.
How to repeat. Select V3 and do a search.

Duplicate of known issue.
https://github.com/wagtail/wagtail/issues/8159

authors: lb- onno-timmerman


text:
issue:#10434

Fixes #...
Please check the following:

[ ] Do the tests still pass?[^1]
[ ] 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

@Nukealbert I don't think this will work, if looks like you've used Django template syntax in a Python file.
I've run the tests anyway.
Please read our guide for first time contributors https://docs.wagtail.org/en/latest/contributing/first_contribution_guide.html
This PR needs to have a description that correctly includes the issue being resolved and a title that makes more sense. Unit tests will also be needed.
The guide will walk you through all of this and more.
Thanks for giving this a start though.

authors: Nukealbert lb-


text:
Create raw SQL for SQL Server to be able to display recent edits (on 1.9.x)

This creates corresponding raw SQL for a subselect to maintain SQL Server compatibility.
SQL Server does not support the LIMIT keyword. This should be considered a temporary fix until Django 1.11 subselects are available!

Thanks @FlipperPA! To keep things in one place I'll take #3422 as the canonical PR for this - we'll make a separate decision on whether to make a bugfix release for the 1.9 branch. (If we do, we should probably make a 1.8 one too.)

authors: FlipperPA gasman


text:
Added missing is_stored_locally() to AbstractDocument

Unless I'm missing something obvious, there's no definition of is_stored_locally() in AbstractDocument, so open_file() fails. The functionality seems to mirror AbstractImage, so I have copied the implementation of is_stored_locally() from there and it now works properly.

Thanks @jonny5532! Merged in 851bd5f24d98188ffc6ac0c83fdd62f9c666a6de.


text:
Add new docs page 'Changing rich text representation'

Add a new docs page, 'Changing rich text representation', which describes how to subclass the Format class in order to customise an image's representation in rich text.

Looks good to me!

authors: gasman jacobtoppm


text:
Fix: Define default_app_config only for Django < 3.2

Since Django 3.2 it is not necessary anymore to declare a default_app_config if only a single app config is present in the apps.py.
With that declaration, Django throws deprecation warnings like so:
/venv/lib/python3.8/site-packages/django/apps/registry.py:91: RemovedInDjango41Warning: 'wagtail.core' defines default_app_config = 'wagtail.core.apps.WagtailCoreAppConfig'. Django now detects this configuration automatically. You can remove default_app_config.

This PR adds version checks and only declares the default_app_config for Django versions before 3.2.
There was also a section in the docs that was referencing the need to set default_app_config. That section has been adjusted to make clear that default_app_config is only needed for Django < 3.2.
Closes #7692

Thanks for contributing to Wagtail! 🎉
Before submitting, please review the contributor guidelines https://docs.wagtail.io/en/latest/contributing/index.html and check the following:

Do the tests still pass? (https://docs.wagtail.io/en/latest/contributing/developing.html#testing) -> yes
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? -> Tested via test matrix.
For front-end changes: Did you test on all of Wagtail’s supported environments? -> n/a
For new features: Has the documentation been updated accordingly? -> Not a new feature, but documentation has been update.

LGTM, will fix a bunch of warnings.
I guess there's a good reason you didn't write if django.VERSION < (3, 2) as you wrote on the issue.

Thanks @adamchainz for review. I went with the django.VERSION >= 3.2 because this follows the style guide in the Wagtail docs.
https://docs.wagtail.io/en/stable/contributing/python_guidelines.html#django-compatibility
I think it's used mainly so that the behaviour for the latest release it up top.

Ah I see.

Thanks @tbrlpld. Merged in 783f0d4a1647123e4053d30512e70d8110584c50 and parents
Also thank you @adamchainz for the review too. My main question was around the comparison, but since we have that in the guidelines.. merged as is

authors: adamchainz tbrlpld zerolab


text:
Eliminate duplicated code on image / document creation

In the various views where images and documents are created or updated, there's a bunch of boilerplate code for setting the file size and hash fields and reindexing the object. Move this to the form / model to eliminate the duplication.
The tradeoff is that we now require custom forms set via WAGTAILIMAGES_IMAGE_FORM_BASE / WAGTAILDOCS_DOCUMENT_FORM_BASE to inherit from Wagtail's base form classes, otherwise they'll be missing core functionality - previously the docs suggested the possibility of replacing them outright. I very much doubt anyone took advantage of that option though...
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.

[ ] 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

Flagging as needs info for now.

authors: gasman lb-


text:
🛑 Gitlab is down

In a29c29e, Gitlab (https://$GITLAB_HOST) was down:

HTTP code: 404
Response time: 714 ms

Resolved: Gitlab is back up in 6f92e1a after 12 minutes.

repo: waja/cyconet-upptime


text:
fix: add payload to relay ping messages to avoid poor relay peer scoring

Note that this keep alive mechanism should probably be removed.

@danisharora099 We discussed about playing around with the new connection maanger and examples and confirming whether or not the relay keep alive is still needed. Where do you track this work please?

Curious to understand how the need for this arose?

Wondering as well

Curious to understand how the need for this arose?

Empty payload are now considered as invalid messages for Waku Relay in nwaku.
See https://discord.com/channels/864066763682218004/978113702471561278/1084612436042186802

authors: fryorcraken weboko

repo: waku-org/js-waku


text:
feat!: add keep alive to Filter

Problem
Filter doesn't keep keep subscription forever and requires periodic pings.
Solution
Implement keep alive feature to do automatic pings to the peers.
Notes

Resolves https://github.com/waku-org/js-waku/issues/1923

Draft for now before https://github.com/waku-org/js-waku/pull/1958 is merged.

Why can't we use the existing keep alive manager for this? Or why is it insufficient?

Why can't we use the existing keep alive manager for this? Or why is it insufficient?

This is because keepAliveManager does libp2p pings
Overall something like that can be implemented for filter pings once logic becomes more sophisticated: perhaps if next steps are implemented from here https://github.com/waku-org/js-waku/issues/1923#issuecomment-2070939508

authors: adklempner weboko


text:
Is FCC 477 per-block, or per-tract?

According to the FCC's data-download page, it's tract-level, but the December 2011 Federal Register filing about the Connect America Fund seems to indicate that it's block-level. Some press coverage says it's block-level. Is it possible that the data is collected at a block level but distributed at a tract level?

All of the data is per-block only for the number of providers (how much competition there is), but it's per-tract for actual connection speed data. The CSV data provided is likewise tract-level.
So looks like it's tract-level, however it's collected.

repo: waldoj/albemarle-broadband


text:
(JS-0128) Should not have unused variables

Description
Found variables that are declared but not used anywhere.
Occurrences
There are 41 occurrences of this issue in the repository.
See all occurrences on DeepSource → deepsource.io/gh/waldothedeveloper/acfix/issue/JS-0128/occurrences/

I replaced the unused function arguments with a more conventional _

repo: waldothedeveloper/acfix


text:
Reinstate properties on errors

When reinstating errors, additional properties on those errors were not correctly preserved. Now they are.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Mitchell Harris seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

LGTM :+1:

authors: CLAassistant heneryville rathbone1200cc

repo: walmartlabs/easy-fix


text:
Nested TabLayout inherit parent style

When nesting TabLayout the child inherit parent CSS.
It's annoying when you want to nest a TabLayout with tabsPosition to top in a TabLayout with tabsPosition to left, it result in the second TabLayout to not draw title and to display them to the left.

Code sample:
new photonui.TabLayout({
    tabsPosition: "left",
    children: [
        new photonui.TabItem({
            title: room.label,
            child: new photonui.GridLayout({
                horizontalSpacing: 5,
                verticalSpacing: 5,
                children: [
                    new photonui.Text({
                        rawHtml: "<strong>" + _("Superficie") + "</strong>",
                        layoutOptions: {
                            x: 0, y: 0,
                            cols: 1, rows: 1
                        }
                    }),
                    new photonui.Label({
                        text:  (room.area / 10000).toFixed(2) + "m²",
                        layoutOptions: {
                            x: 1, y: 0,
                            cols: 1, rows: 1
                        }
                    }),
                    new photonui.TabLayout({
                        tabsPosition: "top",
                        children: [
                            new photonui.TabItem({
                                title: _("Menuiserie"),
                                child: new photonui.Label({text: "Test"})
                            })
                        ],
                        layoutOptions: {
                            x: 0, y: 1,
                            cols: 1, rows: 2
                        }
                    })
                ]
            })
        })
    ]
})

Hi @pstkweb, I just propose a PR to fix your problem. You just need to get the new css files (base + themes).
You could give it a try waiting @flozz validation.

Thanks for the fix @MangelMaxime

Merged on develop :)

Fixed in PhotonUI 1.4.1

authors: MangelMaxime flozz pstkweb

repo: wanadev/PhotonUI


text:
[Potential bug] Grouping changes x values in unexpected way

Describe the bug
What I do is the following: I train a model for 200 epochs and log several metrics (like train.accuracy, test.accuracy..) using wandb.log and everything works as expected. I do not pass a different step argument than the default. Then after training, I save the model and loop over a list of desired sparsities: self.desired_sparsities = [0, 0.3, 0.5, 0.7, 0.9, 0.95, 0.98]. For each of the sparsities, I jump back to the saved model checkpoint, remove as many parameters as desired (e.g. 0,3 = 30%), finetrain the pruned model (without logging anything to wandb). After finetuning it, I use wandb.log to log the current desired_sparsity and training metrics using a different name (e.g. finetune.train.accuracy, finetune.test.accuracy). Then I redo the same steps for the next sparsity in the list. Hence, the new metrics finetune.test.accuracy as well as desired_sparsity are associated with step =201, 202, 203, ...
What I want to achieve: My goal is then to have a line plot in the webinterface which shows desired_sparsity on the x-axis and finetune.test.accuracy on the y axis. I simply add the plot via the Webinterface. This works just fine without grouping of runs, but as soon as I group them together to analyze different hyperparameters, I get weird behaviour: the x-values (i.e. desired_sparsity) seem to allow values greater than 1, even though I fixed the list of values above (see pictures below). I still can't explain why, but this might be because wandb also averages my x-axis (i.e. desired_sparsity).
Expected behavior
I expect to see a correct plot finetune.test.accuracy vs. desired_sparsity, even when I group the runs. When grouping, I'd expect to see some sort of average over the groups, even in this plot. With sparsities between 0 and 1 it is not possible to obtain values greater than 1. Grouping should yield a plot of average finetune.test.accuracy's for each step/desired_sparsity.
Screenshots

The expected and good result:

The unexpected and bad result after grouping:

Operating System

OS: Ubuntu 20.04
Browser: Firefox
Version: 83

Additional context
I hope the above was not diffuse and it was understandable what my problem is, if not feel free to ask. This issue is related to the workaround I proposed here https://github.com/wandb/client/issues/1557#issue-753345198.
Thanks!

Not sure if this is of any help, but I was able to circumvent the problem by plotting finetune.test.accuracy vs step (instead of vs. desired_sparsity). Then I selected desired_sparsity as the X-Axis-Expression, and not the values are at least correct. It would be nice of someone could elaborate on what is happening here, as I seem to have some misunderstandings of the core functionality of lineplot.
How it looks now after grouping:

Can't find a way to scale the x-axis to [0,1] without destroying the plot again.

Hey @zimmer-m , thanks for writing in. @cvphelps can you please help here?

Hey @zimmer-m
I was able to reproduce your issue.
The code
import wandb
import math
import random
for runs in range(10):
  run = wandb.init(project="xxx",entity="xxx")
  for step in range(10):
    wandb.log({
        "train.acc": math.log(.1 + random.random() + step * 0.01),
        "test.val_acc": math.log(.1 + random.random() + step *0.01)
        })
  desired_sparsities = [0, 0.3, 0.5, 0.7, 0.9, 0.95, 0.98]
  for step in desired_sparsities:
    wandb.log({
        "finetune.train.acc": math.log(.1 + random.random() + step * 0.01),
        "finetune.train.val_acc": math.log(.1 + random.random() + step *0.01),
        "desired_sparsities": step
        })
  run.finish()

This is a minimal implementation of your issue. I am considering 10 epochs and then later iterating over the desired_sparsities.
Web-interface
The link to the project page: https://wandb.ai/repro/grouping
My observations:

Line Plots are perfectly fine without grouping. I have made two kinds of line plots, one where the x-axis comes from desired_sparsities and the other where it comes from step. As expected, both the charts have their dissimalirites quite evident. On the one hand step lies in the range of [10-16] and on the other hand desired_sparsities iterate over = [0, 0.3, 0.5, 0.7, 0.9, 0.95, 0.98].
Line Plots plays funny with grouping. The problem for me was to be confused in the two fields namely X and X Axis Expression.

These play an interesting role in the grouping mechanism. As @zimmer-m has mentioned, with X=Step and X Axis Expression=desired_sparsities we get the plots as we would expect, where the x axis has values corresponding desired_sparsity list.

But here we cannot specify the range of the x values.

Hey @zimmer-m
I was able to reproduce your issue.
Thanks for the MWE, appreciate it!

I have the same issue. I'm plotting a certain metric every 5000 steps. When the runs aren't group, the x-values are correct:

But when I group them, the x-values change to fractional values that don't align with the 5000 tick marks:

I can't tell if this is a bug, or if it's intentional behavior from wandb (e.g. an interpolation strategy to efficiently implement the average when there are many runs grouped together). It would be nice to see some documentation about this.

Same problem over here, 0-1 metric used as X-axis hallucinates a value for 1.005, are there any updates on this?

@cvphelps is there any update on this?

+1, facing the same bug with some grouped runs.

authors: AntonioLopardo ariG23498 brett-daley dishank-b htahboub tyomhak zimmer-m

repo: wandb/wandb


text:
fix(sdk): Ensure artifact name strings conform to Artifacts requirements

Fixes
https://github.com/wandb/wandb/issues/5339
Description
Previously, we did not cover the case where artifacts have invalid characters like :/*, etc.
This PR ensures artifact name strings conform to Artifacts requirements.  Invalid characters are replaced with __
Testing
Updated integration tests
Checklist

[ ] Include reference to internal ticket "Fixes WB-NNNN" and/or GitHub issue "Fixes #NNNN" (if applicable)
[ ] Ensure PR title compliance with the conventional commits standards

🤖 Generated by Copilot at 5d83768

MlflowRun fixed
Importing runs and artifacts
Winter of errors

/fix-title

authors: andrewtruong dmitryduev


text:
-ERR Unable to perform background save

2015/07/15 15:21:33 [panic]: invalid sync response, rsp = '-ERR Unable to perform background save
'
/home/go/src/github.com/wandoulabs/codis/ext/redis-port/cmd/utils.go:103
github.com/wandoulabs/codis/ext/redis-port/cmd.func·016

Please google "redis" + "ERR Unable to perform background save". :smile:

ok

repo: wandoulabs/redis-port


text:
这个插件支持CDN方式引用么

如果支持的话，可以放到BootCDN上去

我已经提交到百度cdn，不过至今尚未回复我。你有比较好的免费cdn，也可以推荐给我，不过要知道如何提交进去。

BootCDN我一直没找到如何添加

bootstrap中文网提供的cdn
这个很不错，一直在用，有问题发邮件给他们回复的也很及时

但是我没找到入口，如何申请添加进去？

网页最下方有
cdn@bootcss.com 这是他们的email
他们收录的插件都是同步在 cdnjs这个仓库里的

好，感谢提供。我在发布下一个版本时，就往cdnjs发送一个pul request

@wangfupeng1988 所以最后网cdnjs里面提交了么？提交的地方在这里：https://github.com/cdnjs/cdnjs/issues/new?title=[Request] Add library_name&body=Library%20name%3A%20%0AGit%20repository%20url%3A%20%0Anpm%20package%20name%20or%20url%20(if%20there%20is%20one)%3A%20%0ALicense%20(List%20them%20all%20if%20it%27s%20multiple)%3A%20%0AOfficial%20homepage%3A%20%0AWanna%20say%20something%3F%20Leave%20message%20here%3A%20%0A%0A%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%3D%0A%0ANotes%20from%20cdnjs%20maintainer%3A%0APlease%20read%20the%20%5BREADME.md%5D(https%3A%2F%2Fgithub.com%2Fcdnjs%2Fcdnjs%23cdnjs-library-repository)%20and%20%5BCONTRIBUTING.md%5D(https%3A%2F%2Fgithub.com%2Fcdnjs%2Fcdnjs%2Fblob%2Fmaster%2F.github%2FCONTRIBUTING.md)%20document%20first.%0A%0AWe%20encourage%20you%20to%20add%20a%20library%20via%20sending%20pull%20request%2C%0Ait%27ll%20be%20faster%20than%20just%20opening%20a%20request%20issue%2C%0Asince%20there%20are%20tons%20of%20issues%2C%20please%20wait%20with%20patience%2C%0Aand%20please%20don%27t%20forget%20to%20read%20the%20guidelines%20for%20contributing%2C%20thanks!!%0A

@wangfupeng1988 找到这样一个cdn：https://unpkg.com/wangeditor


text:
add: 拖拽和粘贴的图片上传至七牛云

之前的版本用户粘贴和拖拽的图片只能使用默认的方式上传至服务器，这次的提交修改以下几点：

用户开启editor.config.customUpload = true;后会尝试将粘贴和拖拽的图片上传至七牛云；
前提是用户须配置七牛的上传 token 和 域名

editor.config.uptokenstr = "上传token";
editor.config.domainstr = "http://www.example.com/";

修改了 .gitignore 文件，忽略了node_modules和uploadfiles文件夹。目的在于减少开发前克隆项目所需时间。

增加了imgSuffix图片后缀名配置项，主要用于上传七牛云后的自定义样式，其中!感叹号是样式分隔符。

editor.config.imgSuffix = "!w400";

上传至七牛，已经有了支持 http://www.kancloud.cn/wangfupeng/wangeditor2/123691 何必一开始就尝试上传至七牛呢？并不是所有用户都需要一上来就上传七牛。

这次PR的主要原因在于自己使用的时候发现如果启用自定义上传(editor.config.customUpload = true;)后，粘贴、拖拽上传图片功能无法正常使用，因为这两项功能是否启用依赖于editor.config.uploadImgUrl，然而这个配置参数无法与customUpload共存。
此时的上传方式只剩下手动点击选择图片上传，略有不便，所以有此提交。

@joe223 在项目里试了下很好用. 请问启用 customUpload 后, 如何隐藏工具栏里的上传图片或者让工具栏里的上传图片也生效

@xream http://www.kancloud.cn/wangfupeng/wangeditor2/123691 需要做七牛云的相关配置，菜单配置看这里 http://www.kancloud.cn/wangfupeng/wangeditor2/113975，大兄弟多读文档呀

@joe223 晕...原来你只做了粘贴和拖拽...


text:
do we need to convert the cityscape dataset with 35 classes to 19 classes?

Since the downloaded cityscape dataset has 35 classes, I can't train the previous code due to the setting of num_classes=19.
So I modify the code to num_classes=35, and it begins to train. But I'm worrying about should I use some script to turn the 35 classes into 19 classes? Hope to listen to your advice, thanks.

Hi:
In our experiments, we have converted the original 35 num_classes labels to 19 num_classes labels. You can get some help from the issue #11 .

Thanks! I successfully convert the dataset into 19 classes with that script.


text:
Cocoapods

I'd be cool to also add Cocoapods support. I done this implementation myself last week for my library. Just follow this post and this checklist.
Lemme know if you need any help! :smile:

You’ve been a big help.
Thanks~

authors: lfarah wangjwchn

repo: wangjwchn/JWAnimatedImage


text:
浮点变量报错

Traceback (most recent call last):
File "C:\Users\Cao\Downloads\wechat_jump_game-master\wechat_jump_auto.py", line 288, in
main()
File "C:\Users\Cao\Downloads\wechat_jump_game-master\wechat_jump_auto.py", line 277, in main
piece_x, piece_y, board_x, board_y = find_piece_and_board(im)
File "C:\Users\Cao\Downloads\wechat_jump_game-master\wechat_jump_auto.py", line 202, in find_piece
_and_board
for j in range(board_x_start, board_x_end):
TypeError: 'float' object cannot be interpreted as an integer

修复了，请更新

改成for j in range(int(board_x_start), int(board_x_end)):

authors: Cao-czy Vg1ee xurancrazy