text:
启动后有大量Groups History:【config.yaml】 Update Faild报错

启动后，每隔一分钟就会有一个报错Update Faild
2021-04-06 11:04:02 Groups History:【config_new.yaml】 Update Faild
2021-04-06 11:03:02 Groups History:【config_new.yaml】 Update Faild
2021-04-06 11:02:02 Groups History:【config_new.yaml】 Update Faild
2021-04-06 11:01:02 Groups History:【config_new.yaml】 Update Faild
2021-04-06 11:00:02 Groups History:【config_new.yaml】 Update Faild
2021-04-06 10:59:02 Groups History:【config_new.yaml】 Update Faild
2021-04-06 10:58:02 Groups History:【config_new.yaml】 Update Faild
2021-04-06 10:57:02 Groups History:【config_new.yaml】 Update Faild

OpenClash 调试日志
生成时间: 2021-04-06 11:02:56
插件版本: v0.42.03-beta
隐私提示: 上传此日志前请注意检查、屏蔽公网IP、节点、密码等相关敏感信息

#===================== 系统信息 =====================#

主机型号: Intel(R) Celeron(R) J4105 CPU @ 1.50GHz : 1 Core 1 Thread
固件版本: OpenWrt SNAPSHOT r3119-5317abee9
LuCI版本: git-21.035.34289-13f96d1-1
内核版本: 5.4.105
处理器架构: x86_64

#此项在使用Tun模式时应为ACCEPT
防火墙转发: ACCEPT

#此项有值时建议到网络-接口-lan的设置中禁用IPV6的DHCP
IPV6-DHCP: server

#此项结果应仅有配置文件的DNS监听地址
Dnsmasq转发设置: 127.0.0.1#7874

#===================== 依赖检查 =====================#

dnsmasq-full: 已安装
coreutils: 已安装
coreutils-nohup: 已安装
bash: 已安装
curl: 已安装
jsonfilter: 已安装
ca-certificates: 已安装
ipset: 已安装
ip-full: 已安装
iptables-mod-tproxy: 已安装
kmod-ipt-tproxy: 已安装
iptables-mod-extra: 已安装
kmod-ipt-extra: 已安装
libcap: 已安装
libcap-bin: 已安装
ruby: 已安装
ruby-yaml: 已安装
ruby-psych: 已安装
ruby-pstore: 已安装
ruby-dbm: 已安装
kmod-tun(TUN模式): 已安装
luci-compat(Luci-19.07): 已安装

#===================== 内核检查 =====================#

运行状态: 运行中
进程pid: 23190
运行权限: 23190: = cap_dac_override,cap_net_bind_service,cap_net_admin,cap_net_raw,cap_sys_resource+eip
运行用户: nobody
已选择的架构: linux-amd64

#下方无法显示内核版本号时请确认您的内核版本是否正确或者有无权限
Tun内核版本: 2021.02.21
Tun内核文件: 存在
Tun内核运行权限: 正常

Game内核版本:
Game内核文件: 不存在
Game内核运行权限: 否

Dev内核版本: v1.3.5-4-g6fedd7e
Dev内核文件: 存在
Dev内核运行权限: 正常

#===================== 插件设置 =====================#

当前配置文件: /etc/openclash/config/config_new.yaml
启动配置文件: /etc/openclash/config_new.yaml
运行模式: redir-host-mix
默认代理模式: rule
UDP流量转发(tproxy): 停用
DNS劫持: 启用
自定义DNS: 启用
IPV6-DNS解析: 启用
禁用Dnsmasq缓存: 启用
自定义规则: 停用
仅允许内网: 启用
仅代理命中规则流量: 停用
仅允许常用端口流量: 停用
绕过中国大陆IP: 启用

#启动异常时建议关闭此项后重试
混合节点: 停用
保留配置: 停用

#启动异常时建议关闭此项后重试
第三方规则: 停用

#===================== 配置文件 =====================#

port: 7890
socks-port: 7891
redir-port: 7892
interface-name: pppoe-wan
allow-lan: true
bind-address: 10.0.0.1
ipv6: true
mode: rule
log-level: silent
external-controller: 10.0.0.1:9090
external-ui: "/usr/share/openclash/dashboard"
tun:
  enable: true
  stack: system
  dns-hijack:
  - tcp://8.8.8.8:53
  - tcp://8.8.4.4:53
hosts:
dns:
  use-hosts: true
  enable: true
  ipv6: true
  enhanced-mode: redir-host
  listen: 0.0.0.0:7874
  nameserver:
  - 127.0.0.1:6053

curl报错了，需要重新编译固件
root@OpenWrt:~# curl
Error loading shared library libwolfssl.so.4.7.0.66253b90: No such file or directory (needed by /usr/bin/curl)

source: gharchive/issue

license: MIT

license_type: permissive

license_source: github-api


text:
Rules port range

How to set rule with port range? example port 1000-1200

script:
  code: |
    def main(ctx, metadata):
        port = int(metadata["dst_port"])
            if port <= 1000 and port >= 1200:
                ctx.log('[Script] matched Port Limit traffic use DIRECT')
                return "DIRECT"

Use the tun core and switch to script mode. The above rules can only restrict ports, you need to combine more rules to divert traffic.
Example here

repo: vernesong/OpenClash


text:
Add device selection dropdown

This makes it easier for users with more than one devices to configure (e.g. a DP player).

Thank you for the PR! I agree this feature is necessary, and in particular I was going to draw inspiration from the configuration tool used by https://github.com/minsang-github/arcin-infinitas
...However, you've caught me in the middle of a massive rewrite of Roxy Tool. I'm porting the entire thing to Avalonia, which compiles natively to Windows and Linux and will allow me to maintain one GUI instead of the two that's currently in this repo. I'm hoping to finalize this by the end of the week.
Again, I truly appreciate it, I just wish the timing worked out a little better!

Thanks for your reply. That's super cool to hear! It's fine if you don't
intend to merge this PR (it fixes my issue with it anyways).
Good luck on the port!
On Sun, Oct 11, 2020, 19:27 veroxzik notifications@github.com wrote:

Thank you for the PR! I agree this feature is necessary, and in particular
I was going to draw inspiration from the configuration tool used by
https://github.com/minsang-github/arcin-infinitas
...However, you've caught me in the middle of a massive rewrite of Roxy
Tool. I'm porting the entire thing to Avalonia, which compiles natively to
Windows and Linux and will allow me to maintain one GUI instead of the two
that's currently in this repo. I'm hoping to finalize this by the end of
the week.
Again, I truly appreciate it, I just wish the timing worked out a little
better!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/veroxzik/roxy-tool/pull/1#issuecomment-706819934, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKSYIXWOQYTKNZ7RITMV2TSKJSQ3ANCNFSM4SMFZ7WQ
.

source: gharchive/pull-request

repo: veroxzik/roxy-tool


text:
it tells me access denied

I solved it was the antivirus.

repo: vertiond/verthash-one-click-miner


text:
Revert "Revert "Use a LeanHit until merging is done." MERGEOK"

Reverts vespa-engine/vespa#10671

@bratseth PR

👍

authors: baldersheim bratseth

repo: vespa-engine/vespa


text:
Feature Requests: Sign On / Sign Offs & Schedule Bumpers

I'm not really sure how to format this post, but do you know how TV networks would have certain bumpers that would air when they started/stopped broadcasting (at least, before everything went 24/7)? I think it would be cool if we could make custom bumpers for when (or if) that happens.
Also, another feature I'd find to be really nice would be bumpers that'd show certain schedule points. I'd probably lay it out like the following: Now, Next, Later.
I'm not exactly sure how these would work, and these may seem like too much to ask, but if these can be implemented, then I'd gladly appreciate it.
Sincerely Yours,
-Olan (AKA TVGFTL2000s)
P.S.: I'm aware that this has been requested before, one way or another.

this would be good:)

repo: vexorian/dizquetv

license: Zlib


text:
add worker index to context

In order to know what worker calls each job, if that is needed, i added workerIndex to the context the job is called with fixes #88

What problem are you trying to solve with this?
Currently you can find a worker ID in the worker-id log context field, for the pool it has the following format %s/worker-%d, where the first string placeholder is the pool id, either randomly generated or explicitly set using pool options, and the second numeric placeholder is the worker index in the pool. So in should look like something like this in the log sAd6yh/worker-0, sAd6yh/worker-1, etc.

I need to know in code each workers identity because the jobs i am going to run are using a resource that has to be locked to each worker. (A key to sign a blockchain transaction)

https://github.com/vgarvardt/gue/pull/91 should solve your problem, will create new beta release so you could test it.

Awesome!

authors: bjartek vgarvardt

repo: vgarvardt/gue


text:
More precise parser error

When the parser encounters a type that is unknown, it fails with the following error:
expected: {"<typedef_name>"}

It would be extremely helpful if the parser would at the following point in the parser code:
__state.mark_failure(__pos, "<typedef_name>");

make an effort to print the actual type that it can not parse.

Indeed, error reporting is one of the weak places currently.
Our current parser generator lacks the facility to report exact text that failed to parse. We do return expanded source code and position, so the type name can be recovered from that. We could provide some helper functions to do that.

authors: sertel vickenty

repo: vickenty/lang-c


text:
Add support for providing arguments to fields that lack resolvers

Mainstream Thunder assumes that a Field will only take arguments if it has a Resolver set. This is problematic for our uses of Thunder: we define a Resolver on each Node (basically just a Field) and have it resolve all child fields.
This commit is squashed from internal work. It changes Thunder to identify when an Args field is defined, and parse those arguments. Those arguments are then available when resolving, even from a resolver on a parent field, using Selection.Arguments.

Thanks, @46bit!

repo: victor-perov/thunder


text:
ayForm title支不支持reactNode

v0.19.1

{
    // @ts-ignore
    title: hello,
    key: "name",
    required: true
}

https://codesandbox.io/s/gracious-montalcini-1moly?file=/App.tsx

repo: viewweiwu/amiya


text:
Recyclable Iterators

I would like to introduce the idea that fastutil should support recyclable iterators.  That is, when calling the iterator() method, the same iterator object should be returned but reset to the start.
When trying to avoid allocations, it's clear that escape analysis [can] (http://psy-lob-saw.blogspot.ca/2014/12/the-escape-of-arraylistiterator.html) remove these allocations, but that means nothing when trying to profile the application, all I can see is these iterators because escape analysis is turned off by the profiler so I just fallback to using elements() where I can.
As long as the collections are not being paired with a lock, it seems like this is pretty straightforward.  For the synchronized collections, this might be complicated.  Although a lock must be held for the duration of the iteration, the iterator itself might be retained beyond the scope of the lock, and then be used again when the lock is re-acquired

Interesting idea.
I think this should not be the default behavior of iterator(); if desired, it should be on a separate method, like fastIterator() is; possibly recycledIterator().
Even in single-threaded applications, multiple iterators can be active over the same object, e.g. in nested loops processing pairs of items in a list or set. Quietly breaking such code by violating the iterator() contract would be a very bad thing.

I think this should not be the default behavior of iterator()

If you make another method, the standard for loop won't be able to call it.  It might warrant another set of generated classes

How about somehow providing the iterator from outside? This way, it
would be possible to reuse the same iterator for iterating multiple
collections.

This feature would be awesome. But @mdekstrand is correct. It should not be the default behavior of iterator() due to the unforseen amount of multithreading errors

You could add a new constructor which will either use the default iterator or recycled iterator by default with the warning that once such collection is created one behavior or the other applies for all iterators of such instance.

Or another option is to generate recycled iterator variants of each collection.

I think a better option would be to have a reset() (or something) method that resets an iterator. Returning always the same object is too big a break from the current practice (and from the specification).

@vigna yes that's a much better option, basically you reuse the iterator rather than breaking the JCF specs.

I have had this on my wishlist for some time, but I don't think this should be handled by the collection.
Instead, iterators should simply have a reset() function. I'd assume this is fairly easy to implement for all iterators on collections.
Then you could simply get the iterator once, and reset() it before each use. With multiple threads, you can get a separate iterator for each thread, or even handle an "iterator pool" of iterators if necessary (similar to how people have been doing database connection pools).

Maybe "rewind()", and we could have a RewindableIterator interface.
On June 24, 2017 12:19:11 AM GMT+02:00, Erich Schubert notifications@github.com wrote:

I have had this on my wishlist for some time, but I don't think this
should be handled by the collection.
Instead, iterators should simply have a reset() function. I'd assume
this is fairly easy to implement for all iterators on collections.
Then you could simply get the iterator once, and reset() it before
each use. With multiple threads, you can get a separate iterator for
each thread, or even handle an "iterator pool" of iterators if
necessary (similar to how people have been doing database connection
pools).
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/vigna/fastutil/issues/45#issuecomment-310785391

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Since fastutil already adds skip(int), is it really necessary to add a RewindableIterator interface? Why not just add rewind() to drv/Iterator.drv, with a default implementation throwing an exception like remove()?

Well, an interface has the advantage that people can easily check for the feature. What you propose implies that to check one has to try and check the exception with a very complicated logic...

To make it usable, we need the return value to be a RewindableIterator, and at the same time a primitive-specific iterator. So this would mean introducing RewindableFloatIterator etc.; and as far as I can tell we will probably not have a non-rewindable float iterator anywhere in fastutil.

Just as an example of how it could look like, Agrona always returns the same iterator instance on its collections and calls reset() when getting the iterator (example here).

That violates the Map contract.

@jheusser I think that is a really bad idea.
What if I need a nested loop, to compute pairwise similarities? I need to be able to get two different iterators...
I like the idea of rewind(), but iterator recycling needs to be done by the user (you could try to use finalizer/reference magic, but that will likely be more expensive than new iterators!)
With the reset() discussed above, one could do
IntIterator i1 = col.iterator(), i2 = col.iterator();
while(i1.hasNext()) {
  int first = i1.nextInt();
  i2.reset();
  while(i2.hasNext()) {
    int second = i2.nextInt();
    // Do something on (frist, second)
  }
}

Note that in this example, I need the iterator to have both rewind() and nextInt().

@kno10 @vigna just highlighting how another high-performance library does it. Clearly, Agrona is not meant as drop-in replacement for standard collections but for specific use cases.
I do like the explicit rewind() approach as well.

Why was this closed?
Is there an option to reuse/rewind an iterator now?

Why was this closed?
Is there an option to reuse/rewind an iterator now?

Nope, but this was from 5 years ago and no one proposed a PR. I have to clean up issues once in a while or I lost track of what's urgent...

Nope, but this was from 5 years ago and no one proposed a PR. I have to clean up issues once in a while or I lost track of what's urgent...

+1 for explicit rewind() reset()

authors: Jonatino botismarius guidomedina jheusser kno10 mdekstrand mdproctor pjulien vigna

repo: vigna/fastutil

license_source: bigquery


text:
Update sbt to 1.4.6

Updates org.scala-sbt:sbt from 1.4.5 to 1.4.6.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-sbt", artifactId = "sbt" } ]

labels: library-update, semver-patch

Codecov Report

Merging #150 (dfc36b1) into master (4ac3d65) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #150   +/-   ##
=======================================
  Coverage   71.59%   71.59%
=======================================
  Files          12       12
  Lines         426      426
  Branches       23       23
=======================================
  Hits          305      305
  Misses        121      121

Continue to review full report at Codecov.

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

authors: codecov-io scala-steward

repo: vigoo/clipp


text:
Update cats-effect to 3.1.1

Updates org.typelevel:cats-effect from 3.1.0 to 3.1.1.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.typelevel", artifactId = "cats-effect" } ]

labels: library-update, semver-patch

Codecov Report

Merging #214 (96ea17e) into master (9b4e6fd) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #214   +/-   ##
=======================================
  Coverage   70.86%   70.86%
=======================================
  Files          14       14
  Lines         484      484
  Branches       22       22
=======================================
  Hits          343      343
  Misses        141      141

Continue to review full report at Codecov.

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

authors: codecov-commenter scala-steward


text:
remove dependency on TeX

Plot settings were using usetex=True by default which requires TeX installation. This PR makes usetex=False by default and hence requires no TeX installation for things to work smoothly.

I am closing this since the changes are moved to PR #184 from this fork to a  branch. PR from this fork was not starting the CI, PR from the branch does not have this issue.


text:
Author Dashboard

Description
Added author Dashboard
For location I tried to create a user location heatmap
something like this....

but i was unable to do it as it required use of some paid api's
Fixes #39
Note:
Now there is one thing, before I added the automatic location feature, that format of location is not compatible with location metric data as it was kind of random and user dependant, so there might be an error if someone tries to rate the books from id's created before location feature.
But all the users registered after that automatic location are perfectly fine.
Ps: I am not very good at designing but I tried my best.
https://user-images.githubusercontent.com/59139142/114155580-46845880-993f-11eb-93d0-884659d4b086.mp4

also sir label it GSSOC21 and level 3 same as the issue

also sir label it GSSOC21 and level 3 same as the issue

Hey, there are some merge conflicts, kindly review, as I am not able to see where the conflicts occured.

also sir label it GSSOC21 and level 3 same as the issue

Hey, there are some merge conflicts, kindly review, as I am not able to see where the conflicts occured.

sure thing sir

created #82

repo: vikasdo/Book-Recommendation-Analysis


text:
Add $ vike dev and $ vike build

Description
- $ vite dev
+ $ vike dev

- $ vite build
+ $ vike build

Back in the vite-plugin-ssr days, it made sense for the user to directly use the $ vite CLI. But this has limitations: Vike should introduce its own CLI.
We'll most likely need a Vike CLI for https://github.com/vikejs/vike/issues/562, thus labeling as https://github.com/vikejs/vike/labels/server 🌐. Also labelling as https://github.com/vikejs/vike/labels/high-prio 🔥 because it's a blocker.

I would love Vike CLI!
IMO: If we were to do that, I thought it would be easier to use vike to depend on vite and install only vike, instead of having people install vite and vike separately.
If this seems different from Vike's design policy, please forget it.

Hello Kenzo, we're actually already working on at it https://github.com/vikejs/vike/pull/1342.
Contribution much welcome for other https://github.com/vikejs/vike/labels/contribution-welcome %3Atwo_hearts%3A tickets 💯

authors: Kenzo-Wada brillout

repo: vikejs/vike


text:
Is it possible to change the slides at run-time?

I am implementing a filter so I would like to change the content of the slider at run-time.
I understand that rebuild does not work due to a reactivity limitation in the original library, but has anyone managed to work around this? I would appreciate if any of you could share a solution.

I managed to make it work. I used v-if to remove the slider instance and re-initialize it with the new slides array.
So what I did, when I click on a filter, I set the v-if to false, (to remove the slider instance), then I force an update to make sure with this.$forceUpdate(); and then in the next tick function I set the array of slides so that the new slider instance will be initialized again.
this.$nextTick(function () {
    // ... set new array here
});```

repo: viktorlarsson/vue-tiny-slider


text:
...

...

Coverage remained the same at 100.0% when pulling f5d1ceed7bfa75cbab7e881db84c9d406ceadd94 on X-Bird:master into 988ca3555dc7384af3ddc6acf902067edd133f78 on vilic:master.

authors: X-Bird coveralls

repo: vilic/villa


text:
pythonIdentifier overwrites pythonBuiltinFunc

I dunno who made this change, but now you can't reach pythonBuiltinFunc highlighting group. Because this
syn match pythonIdentifier      '\v[a-zA-Z_][a-zA-Z0-9_]*' nextgroup=FunctionParameters
overwrites any of this
  syn match pythonBuiltinFunc    '\v(\.)@<!\zs<(__import__|abs|all|any)>\ze\(' nextgroup=FunctionParameters
  syn match pythonBuiltinFunc    '\v(\.)@<!\zs<(bin|chr|classmethod|cmp|compile|complex)>\ze\(' nextgroup=FunctionParameters
  syn match pythonBuiltinFunc    '\v(\.)@<!\zs<(delattr|dir|divmod|enumerate|eval)>\ze\(' nextgroup=FunctionParameters
  syn match pythonBuiltinFunc    '\v(\.)@<!\zs<(filter|format|getattr)>\ze\(' nextgroup=FunctionParameters
  syn match pythonBuiltinFunc    '\v(\.)@<!\zs<(globals|hasattr|hash|hex|id)>\ze\(' nextgroup=FunctionParameters
  syn match pythonBuiltinFunc    '\v(\.)@<!\zs<(input|isinstance)>\ze\(' nextgroup=FunctionParameters
  syn match pythonBuiltinFunc    '\v(\.)@<!\zs<(issubclass|iter|len|locals|map|max)>\ze\(' nextgroup=FunctionParameters
  syn match pythonBuiltinFunc    '\v(\.)@<!\zs<(min|next|oct|open|ord)>\ze\(' nextgroup=FunctionParameters
  syn match pythonBuiltinFunc    '\v(\.)@<!\zs<(pow|property|range)>\ze\(' nextgroup=FunctionParameters
  syn match pythonBuiltinFunc    '\v(\.)@<!\zs<(repr|reversed|round|setattr)>\ze\(' nextgroup=FunctionParameters
  syn match pythonBuiltinFunc    '\v(\.)@<!\zs<(slice|sorted|staticmethod|sum|super)>\ze\(' nextgroup=FunctionParameters
  syn match pythonBuiltinFunc    '\v(\.)@<!\zs<(type|vars|zip)>\ze\(' nextgroup=FunctionParameters

Why do you even change syn keyword(that has precedence over match) to syn match for builtins?

Not true. Read :syn-priority.
Because from should be handled differently for import and raise.

2. A Keyword has priority over Match and Region items.
3. An item that starts in an earlier position has priority over items that
   start in later positions.

KEYWORD > MATCH
In the syntax file pythonIdentifier defined early pythonBuiltinFunc
Did i miss something?

Yes, you missed this:
1. When multiple Match or Region items start in the same position, the item
   defined last has priority.

Ah, you talking about that it didn't overwrite pythonBuiltinFunc?
Hm, maybe. I just opened test.py and checked. And now i tested with actual file. Yes it didn't overwrite - my bad.
I think tests.py then should be changed.

Why should it be changed?

Oh, you mean the keyword section. Sure.

Because under the section Builtin function we have pythonIdentifier highlighting for almost all builtins.
Check it.
And actually non-english function and class names didn't recognized at all.

That's a separate issue altogether, and would need a major refactor for proper unicode support.

Sorry. Maybe because of my bad english it's hard for you to understand what i'm trying to say.
I repeat. In test.py file all builtin functions cant be recognized and highlighted as pythonIdentifiers.

Completely missed that, sorry.

Should i rename the issue? Because it is actually working as supposed. And problem only in test.py file itsef.

Now it's fixed, thanks.

authors: monkoose nfnty

repo: vim-python/python-syntax

license: mit


text:
variable g:syntastic_r_checkers has to be a list of strings

OS X 10.11
MacVim 8.0
Syntastic 3.8.0-10
After an update to vim & Syntastic I get the following error:
error: variable g:syntastic_r_checkers has to be a list of strings
Syntastic is installed trough Vundle and it works for different languages.
:SyntasticInfo output:
Syntastic version: 3.8.0-10 (Vim 800, Darwin, GUI)
Info for filetype: r
Global mode: active
Filetype r is active
The current file will be checked automatically
Available checkers: -
Currently enabled checkers: -

vimrc relevant lines:
" R-linter
let g:syntastic_enable_r_lintr_checker = 1
let g:syntastic_r_checkers = ['liner']

Using the following instructions from https://github.com/jimhester/lintr:

Put the file syntastic/lintr.vim in syntastic/syntax_checkers/r. If you are using pathogen this directory is ~/.vim/bundles/syntastic/syntax_checkers/r.
You will also need to add the following lines to your .vimrc.
let g:syntastic_enable_r_lintr_checker = 1
let g:syntastic_r_checkers = ['liner']

I've reread the documentation multiple times and can't find the issue, moreover, it's persistent on two machines with identical versions of Vim, Syntastic.
A solution would be much appreciated

s/liner/lintr/ and try again?

Actually, those instructions tell you to override the lintr checker that comes with syntastic with something else.  Your waranty is void if you do that. :smile: Please consider asking the author of said instructions for help if you insist on doing it that way.

Apparently it was an error caused by the package installation on R's side, working again!

repo: vim-syntastic/syntastic

license: WTFPL


text:
ch_sendraw with callback input as blob

It is currently impossible to communicate with an external application with TCP that uses a binary protocol for the output.
I can send a blob using ch_sendraw(), but the callback always gets a string as input parameter.
Since a string in vim replaces the bytes 00 (= ascii NUL) to 10 (= ascii NL), the returned binary message is not readable.
I would like to have a way to use ch_sendraw() but with a binary/blob callback input, so that I can read the output of the external application.
I would see that as an option of the callback when defining the channel or when sending the message:
call ch_sendraw(l:channel, l:message, { 'callback': l:Handler, 'callback_input': 'string (default)|blob' })
or a separate function:
call ch_sendrawblob(l:channel, l:message, { 'callback': l:Handler })

Hmm, what about adding a new channel mode (bin/binary ?) implementing a raw channel but without the string-conversion woes. The input and output would be blobs rather than strings to avoid problems with embedded NULs.

That is even better.

Hmm, what about adding a new channel mode (bin/binary ?)
implementing a raw channel but without the string-conversion woes. The
input and output would be blobs rather than strings to avoid
problems with embedded NULs.

It might be that the channel input uses something else than a blob.
E.g. sending a name or keyword, getting back a blob.  Thus setting the
callback to receive a blob is the most flexible.
--
GUARD #2:  It could be carried by an African swallow!
GUARD #1:  Oh, yeah, an African swallow maybe, but not a European swallow,
that's my point.
GUARD #2:  Oh, yeah, I agree with that...
The Quest for the Holy Grail (Monty Python)
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

It is currently impossible to communicate with an external application
with TCP that uses a binary protocol for the output.
I can send a blob using ch_sendraw(), but the callback always gets a
string as input parameter.
Since a string in vim replaces the bytes 00 (= ascii NUL) to 10 (=
ascii NL), the returned binary message is not readable.
I would like to have a way to use ch_sendraw() but with a binary/blob
callback input, so that I can read the output of the external
application.
I would see that as an option of the callback when defining the
channel or when sending the message:
call ch_sendraw(l:channel, l:message, { 'callback': l:Handler, 'callback_input': 'string (default)|blob' })
or a separate function:
call ch_sendrawblob(l:channel, l:message, { 'callback': l:Handler })

I would think blob is the only alternative that matters here.  The
alternative is to get a string with NUL bytes replaced by NL.  There
isn't really another type we can use.  When using a blob the callback
can then convert it with the existing blob functions.
So, to keep it simple, we could add a flag "callback_blob", which you
can set to true or false.  Would that work?
Implementing this is a bit of work but not very complicated.  It
probably needs to happen in channel_get_all(), changing it to set
argv[1], or an alternate function that returns a blob.
Pehaps you can suggest a way to test this, once it has been implemented.
--
I still remember when I gave up Smoking, Drinking and Sex.  It was the
most horrifying hour of my life!
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

It might be that the channel input uses something else than a blob.

Is that a problem? Strictly speaking strings are blobs without embedded NULs, sending a string or a blob wouldn't invalidate any invariant, the returned value would always be a blob given there may be NULs in the response.
The "raw" channel mode is quite asymmetrical since it allows strings and blobs to be sent (thus allowing NUL bytes) but implicitly converts NULs to NL on the receiving side, that's not so nice IMO.

So, to keep it simple, we could add a flag "callback_blob", which you can set to true or false.  Would that work?

How would that work with ch_evalexpr? The return type should also change from string to blob if the flag is true.

Concerning the testing protocol, I imagine a simple TCP server that takes any request and answers with binary big endian (for readability) (u32)42: we can send whatever blob to the opened channel the received blob should then be (dec)42<=>(hex)0000.002A, and not (hex)AAAA.AA2A ; if (bin)00 is replaced by (bin)10 then (bin)0000 becomes (bin)1010<=>(hex)A.

authors: LemonBoy Zhern brammool

repo: vim/vim

license: Vim


text:
Bug in gVim 8.0 windows x64: cannot delete file marks or numbered marks

I downloaded my gVim from the nightly built windows gvim repository. Here is the vim version information:
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Oct 18 2016 22:02:07)
MS-Windows 64-bit GUI version with OLE support
Included patches: 1-45
Compiled by appveyor@APPVYR-WIN
Huge version with GUI.

I simply cannot delete file marks by doing for example :delmarks A nor for the numbered marks.
After the deletion when I do :marks, the deleted mark is not in the list. But when I re-entrer gVim, the deleted marks reappear. When I looked into the _viminfo file, the mark is never deleted.
I tried disabing loading _gvimrc and _vimrc files but the deletion still does not work.
I also tried the latest version of x64 windows gVim (8.0.0134) and the one bundled with windows Git (vim 7.4.1721 x86-64 nogui). No luck.
I am a little bit surprised because this should be the core of core features in Vim. I wonder if I am doing wrong. Could someone test on their machine ?

After you use delmarks command, use :wviminfo so that the deleted mark will be recorded in the viminfo file. Please ask user questions on the appropriate forums.

use :wviminfo so that the deleted mark will be recorded in the viminfo file.

Thank you for your reply. @chrisbra  I actually had tried :wviminfo command. But the deleted mark is still retained. You can try that.
You have inspired me to dig more into the vim doc. So finally I make myself understand how vim works on file marks. To delete the existing file marks, we have to use the command :wviminfo! (the exclamation mark version) to forecefully overwrite the existing viminfo file.

This is how I think vim works:

When vim is quitted, :wviminfo is automatically fired. It is of interest when we want to exchange infomation between two instances of vim while vim is running. But we do not need to fire it manually to persist information when quitting vim.
:wviminfo merges the information. As the deleted mark is still in the viminfo file after command :delmarks, it will be merged in viminfo, actually leaving itself not deleted.

IMHO, the behavior should be discussed @brammool @vim-ml :

I have passed hours to test before I fire a bug report. I do not want to pollute the forums either. I cannot say this is a bug. However, IMHO. I insist to reopen this issue.
The :delmarks command should be one shot. the CRUD operation should be consistent. When a user creates or modifies a file mark, he does not do :wviminfo to persist. This should be the same when he wants to delete.
When a merge is done, the deletion should be prioritized over existence.

On 2016-12-28, xc1427 wrote:

  □ When a merge is done, the deletion should be prioritized over
    existence.

Why?  How do you know, or rather, how is Vim supposed to know, that
you prefer deletion over existence?
Say you have a .viminfo file that contains marks a and b.  Now you
open two instances of Vim.  Each reads that .viminfo file and stores
those two marks.  Now in the first Vim instance you create mark
c and close Vim.  Mark c is now added to .viminfo.  Now you close
the second Vim instance.  It sees mark c in the .viminfo file but
not in its memory.  Should it delete mark c?  I don't think so.
The point is that I'm sure you can find a scenario in which Vim's
behavior is not what you want and not what you think it should be,
but that doesn't mean that that behavior is wrong in all scenarios.
Regards,
Gary

Say you have a .viminfo file that contains marks a and b.  Now you
open two instances of Vim.  Each reads that .viminfo file and stores
those two marks.  Now in the first Vim instance you create mark
c and close Vim.  Mark c is now added to .viminfo.  Now you close
the second Vim instance.  It sees mark c in the .viminfo file but
not in its memory.  Should it delete mark c?  I don't think so.

I agree with you that we do not delete mark c in this situation.
So I correct : when a merge is done, the latest operation should be taken. I think that is one of the reasons why a time-stamp is added onto the mark in the recent vim publication. This fits the deletion and your scenario.

Gary's Scenario: Open two instances of vim. One vim creates a mark C and quit, then quit second one.
As the second vim it has no its own time-stamp information of C in memory. it considers no operation on C from itself. So it leaves C as it is in the .viminfo. So no deletion. It's good.

Deletion Scenario: Suppose we have already a mark E. Open one instances of vim. Do delmarks:E the quit.
No other instance of vim touch E while the only vim instance has the latest operation on E. The deletion operation is taken into account. Then E is deleted, as I suggested.

Regards,

I am sorry that I did not see this post #448.
Please forget what I have said.

Actually I thought, that since we have timestamps, it would work with a simple :wviminfo.

authors: chrisbra vim-ml xc1427


text:
Windows: non-latin console input broken since 7.4.852

I've bisected repo and found 7.4.852 patch breaks non-latin (Cyrillic) input in Windows console (random characters inserted instead).
Tested vim.exe without any config. Latest Windows 10 release.

What Windows OS do you use?

Could you please how me the configuration dialog of command prompt?

@mattn not sure which dialog you want to see. If you mean "Font options" - it is "Consolas" font

@k-takata it was cp1251 (why?)
Yes, utf-8 fixes the issue. Is it possible to make it default, without touching any configs? (as input worked before)

This is regression for ANSI encoding. So we should fix for non-UTF8 encodings.

After 7.4.852, console input is UTF-16 and it is converted to 'encoding'.
So your result means that converting UTF-16 to cp1251 fails with some reason. Not sure why.

@k-takata am I understand right that output is still ANSI/OEM-aware? In this case console uses OEM codepage and for Cyrilic it is cp866, not cp1251.

Maybe using GetACP in some part is bad, it should use GetConsoleCP instead.

@vitalyster Can you try to apply this patch?
diff --git a/src/os_win32.c b/src/os_win32.c
index d3cab0223..c1a6be421 100644
--- a/src/os_win32.c
+++ b/src/os_win32.c
@@ -5733,7 +5733,7 @@ write_chars(
     DWORD written;

 #ifdef FEAT_MBYTE
-    if (enc_codepage >= 0 && (int)GetACP() != enc_codepage)
+    if (enc_codepage >= 0 && (int)GetConsoleCP() != enc_codepage)
     {
 	static WCHAR	*unicodebuf = NULL;
 	static int	unibuflen = 0;

@mattn It's not enough, I think.
@vitalyster Can you try this instead?
--- a/src/os_win32.c
+++ b/src/os_win32.c
@@ -5771,21 +5771,22 @@ write_chars(
     DWORD written;

 #ifdef FEAT_MBYTE
-    if (enc_codepage >= 0 && (int)GetACP() != enc_codepage)
+    if (enc_codepage >= 0 && (int)GetConsoleCP() != enc_codepage)
     {
 	static WCHAR	*unicodebuf = NULL;
 	static int	unibuflen = 0;
 	int		length;
+	int		cp = enc_utf8 ? CP_UTF8 : enc_codepage;
 	DWORD		n, cchwritten, cells;

-	length = MultiByteToWideChar(CP_UTF8, 0, (LPCSTR)pchBuf, cbToWrite, 0, 0);
+	length = MultiByteToWideChar(cp, 0, (LPCSTR)pchBuf, cbToWrite, 0, 0);
 	if (unicodebuf == NULL || length > unibuflen)
 	{
 	    vim_free(unicodebuf);
 	    unicodebuf = (WCHAR *)lalloc(length * sizeof(WCHAR), FALSE);
 	    unibuflen = length;
 	}
-	MultiByteToWideChar(CP_UTF8, 0, (LPCSTR)pchBuf, cbToWrite,
+	MultiByteToWideChar(cp, 0, (LPCSTR)pchBuf, cbToWrite,
 			    unicodebuf, unibuflen);

 	cells = mb_string2cells(pchBuf, cbToWrite);

We suspect that the problem is actually in the output, not in the input.

I guess it should check if we are vim or gvim, and call GetACP/GetConsoleCP correctly, isn't it?

Anyway, I don't think using legacy codepages is good solution, and it should output in UTF-16

@k-takata

not in the input.

If input is in WCHARs, why you converting it from CHARs? From my point of view, the problem is in input, as this function (write_chars) output WCHARs correctly

I guess it should check if we are vim or gvim, and call GetACP/GetConsoleCP correctly, isn't it?

The patched function is only used in vim.exe.

Anyway, I don't think using legacy codepages is a good solution, and it should output in UTF-16

If enc is set to utf-8, Unicode APIs are used.

From my point of view, the problem is in input, as this function (write_chars) output WCHARs correctly

How did you verify it?

@vitalyster Console input is working with wide code APIs (when it provided). So we are guessing this issue is caused by output.

Could you please show me screenshot?

How did you verify it?

I mean I see write_chars is using wide functions, so the problem is input

Console input is working with wide code APIs

Can you please point me that in code? If it reads WCHARs, then nothing needed to deal with codepages

I mean I see write_chars is using wide functions to output, so the problem is input

Actually, it was not true in some conditions. The patch fixes it. So please try the patch first.

try the patch first

Just tried. It works, but encoding=cp1251. So I guess it works with my cyrillic input, but will not work with characters out of cp1251 codepage

I set my "Language for non-unicode programs" to "English (United states)", and now vim shows encoding=latin1 and cyrillic input broken. So, definitely, problem is in input.

If enc is set to utf-8, Unicode APIs are used.

But why it is not set?

I can confirm that after :set encoding=utf8 everything works great, even I have "wrong" "language for non-unicode programs", so I'm wonder, why non-unicode api is used by default and not wiped at all

why non-unicode api is used by default and not wiped at all

Because there are still some people who doesn't want to switch to encoding=utf-8.

some people who doesn't want to switch

They already have their configs, isn't it?

Moreover, wonder why they "doesn't want to switch" while non-unicode input is broken :)

It's not broken when GetACP() and GetConsoleCP() return the same results (e.g. Japanese Windows), and that's why I and mattn cannot debug the problem by ourselves.

Can you please point me that in code? If it reads WCHARs, then nothing needed to deal with codepages

See mch_inchar() in os_win32.c: https://github.com/vim/vim/blob/2f3a90a3bd8505728c0b6d9ac3515f64ee19b357/src/os_win32.c#L1757-L1802
tgetch() reads the console using ReadConsoleInputW() and a UTF-16 character is converted to 'enc'.

authors: k-takata mattn vitalyster


text:
Command line -c "normal..." stays in normal mode for subsequent -c commands

I use this little batch file for sticking my company's SVN commit template onto the clipboard:
@echo off
call vim -R "%~0" -c "normal }jvG$""*y" -c quit
goto :eof

BB:
JIRA:
ChangeSummary:
Details:
Platform:

This works in the gvim74.exe installation and fails for the gvim74-1024.exe installation. It appears as though normal mode persists beyond the -c argument because if I change it to -c hello (so it's obvious what's going on) and remove the -R the editor starts up and I'm left with this in the buffer:
@echo off
call vim "%~0" -c "normal }jvG$""*y" -c hello
goto :eof
hello
BB:
JIRA:
ChangeSummary:
Details:
Platform:

The -c hello is interpreted as a continuation of the normal mode command.

tplunket wrote:

I use this little batch file for sticking my company's SVN commit
template onto the clipboard:
@echo off
call vim -R "%~0" -c "normal }jvG$""*y" -c quit
goto :eof

BB:
JIRA:
ChangeSummary:
Details:
Platform:

This works in the gvim74.exe installation and fails for the
gvim74-1024.exe installation. It appears as though normal mode
persists beyond the -c argument because if I change it to -c hello
(so it's obvious what's going on) and remove the -R the editor
starts up and I'm left with this in the buffer:
@echo off
call vim "%~0" -c "normal }jvG$""*y" -c hello
goto :eof
hello
BB:
JIRA:
ChangeSummary:
Details:
Platform:

The -c hello is interpreted as a continuation of the normal mode command.

Isn't this a problem with the quoting of the argument?
I very much doubt this happens inside Vim.
--
ARTHUR:       You are indeed brave Sir knight, but the fight is mine.
BLACK KNIGHT: Had enough?
ARTHUR:       You stupid bastard.  You havn't got any arms left.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

(For the record: I'm calling the Vim executable directly in the below commands rather than using the vim.bat helper script.)
It seems as though Vim is doing something incorrect with the quote. Escaping a double quote inside a quoted string only requires doubling it:
>python -c "import sys; print sys.argv[1]" "hello "" world"
hello " world

Again, this batch file worked fine with the package in the gvim74.exe installer that's on vim.org, and it does not work with the gvim74-1024.exe installed app.
If I run this command:
>vim test.bat -c "execute 'normal }jvG$""*y'" -c quit

then I get the error:
Error detected while processing command line:
E121: Undefined variable: c
E15: Invalid expression: 'normal }jvG$"*y' -c quit

We can see here clearly that it's trying to execute the entire line after the quote, but that the quote was passed through correctly.
The most stripped down command line that causes this error is
vim -c "execute 'normal ""*Y'" -c quit

(If I remove the execute bit I don't get the error but Vim remains running.)
And just as a test to see if the shell is in fact separating the arguments the way we think it should,
>python -c "import sys;print '\n'.join(sys.argv[1:])" -c "execute 'normal ""*Y'" -c quit
-c
execute 'normal "*Y'
-c
quit

All of these tests run with the executable installed by the vim74.exe installer and work correctly. This is a new failure, a regression since its release.

I spent some time looking at the code but it quickly became apparent that I'll need to step through it to see what's going on. However I was struck by the thought that maybe something was doing quote processing inside of vim so I tried to double my ""*Y attempts.
This works as expected in 7.4.0 and fails with an error in 7.4.1023:
vim +"execute 'normal ""*Y""*Y'" +quit

The error in .1023 is:
Error detected while processing command line:
E121: Undefined variable: quit
E15: Invalid expression: 'normal "*Y*Y' +quit

So it's munching an additional quote mark for some reason.
Again, Python shows that the arguments are passed as desired by the shell:
>python -c "import sys;print '\n'.join(sys.argv[1:])" +"execute 'normal ""*Y""*Y'" +quit
+execute 'normal "*Y"*Y'
+quit

I think 7.4.432 is the cause of this difference.
Before 7.4.432, the command line was parsed differently when using gvim.exe or
vim.exe, or even built with VC or MinGW.  After 7.4.432, the command line is
parsed by CommandLineToArgvW() and it behaves same when using gvim.exe or
vim.exe, or built with VC or MinGW.
(Your batch file might not work when using gvim.exe 7.4.000 instead of vim.exe.)
So the current quotation behavior is based on CommandLineToArgvW():
https://msdn.microsoft.com/en-us/library/windows/desktop/bb776391.aspx
If you want to pass a double quotation inside a pair of double quotations,
either of the following might work:

Escape with a backslash.
This should work gvim/vim, before/after 7.4.432, built with VC/MinGW.
E.g. vim -c "echo 'foo\"bar'"
Use triple double-quotations. (Maybe less portable.)
E.g. vim -c "echo 'foo"""bar'"

BTW, it is not well documented that how the CommandLineToArgvW() parses double
quotations inside double quotations. :-(
It seems that 3n quotations inside a pair of quotations produce n quotations.
More detail by my analysis:

A " starts quotation.
Another " or "" ends quotation. If the quotation ends with "", a "
is produced at the end of the quoted string.

E.g.:
    "foo"           -> [foo]
    "foo""          -> [foo"]
    "foo"bar        -> [foobar]
    "foo" bar       -> [foo], [bar]
    "foo""bar       -> [foo"bar]
    "foo"" bar      -> [foo"], [bar]
    "foo"""bar"     -> [foo"bar]

Thanks, @k-takata, for researching this. It was previously safe to send quotes through the vim.bat helper script that gets installed but with the change to command line processing now it seems the command processor gets tripped up by the escaping that CommandLineToArgvW requires/expects. It would appear, then, that if someone uses quotes that they cannot use them through those helper scripts, they have to have the exe on their path.

Ken Takata wrote:

I think 7.4.432 is the cause of this difference.
Before 7.4.432, the command line was parsed differently when using gvim.exe or
vim.exe, or even built with VC or MinGW.  After 7.4.432, the command line is
parsed by CommandLineToArgvW() and it behaves same when using gvim.exe or
vim.exe, or built with VC or MinGW.
(Your batch file might not work when using gvim.exe 7.4.000 instead of vim.exe.)
So the current quotation behavior is based on CommandLineToArgvW():
https://msdn.microsoft.com/en-us/library/windows/desktop/bb776391.aspx
If you want to pass a double quotation inside a pair of double quotations,
either of the following might work:

Escape with a backslash.
This should work gvim/vim, before/after 7.4.432, built with VC/MinGW.
E.g. vim -c "echo 'foo\"bar'"
Use triple double-quotations. (Maybe less portable.)
E.g. vim -c "echo 'foo"""bar'"

BTW, it is not well documented that how the CommandLineToArgvW() parses double
quotations inside double quotations. :-(
It seems that 3n quotations inside a pair of quotations produce n quotations.
More detail by my analysis:

A " starts quotation.
Another " or "" ends quotation. If the quotation ends with "", a "
is produced at the end of the quoted string.

E.g.:
    "foo"           -> [foo]
    "foo""          -> [foo"]
    "foo"bar        -> [foobar]
    "foo" bar       -> [foo], [bar]
    "foo""bar       -> [foo"bar]
    "foo"" bar      -> [foo"], [bar]
    "foo"""bar"     -> [foo"bar]

Thanks, I'll add that to the help.
--
The fastest way to get an engineer to solve a problem is to declare that the
problem is unsolvable.  No engineer can walk away from an unsolvable problem
until it's solved.
(Scott Adams - The Dilbert principle)
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

authors: brammool k-takata tplunket


text:
Utilise string_T structure to store strings

Change the keyvalue_T structure to use string_T instead of separate fields for the value and value's length. Adjust macro KEYVALUE_ENTRY() and use sites accordingly.

thanks!


text:
Fix #4051 (format err in tag file with long line)

Add test for incoming fix of #4051: checking for long lines in tags file is broken.  This should fail; will add patch after CI.

Codecov Report

Merging #4084 into master will increase coverage by 0.02%.
The diff coverage is 72.72%.

@@            Coverage Diff             @@
##           master    #4084      +/-   ##
==========================================
+ Coverage   79.21%   79.23%   +0.02%
==========================================
  Files         105      105
  Lines      141158   141159       +1
==========================================
+ Hits       111818   111851      +33
+ Misses      29340    29308      -32

Impacted Files
Coverage Δ

src/tag.c
75.18% <72.72%> (+0.59%)
:arrow_up:

src/message.c
76.65% <0%> (-0.05%)
:arrow_down:

src/screen.c
80.32% <0%> (+0.02%)
:arrow_up:

src/window.c
83.5% <0%> (+0.03%)
:arrow_up:

src/ex_cmds2.c
84.98% <0%> (+0.09%)
:arrow_up:

src/sign.c
93.51% <0%> (+0.12%)
:arrow_up:

src/if_xcmdsrv.c
84.02% <0%> (+0.17%)
:arrow_up:

src/gui_gtk_x11.c
48.57% <0%> (+0.29%)
:arrow_up:

src/gui_beval.c
62% <0%> (+0.43%)
:arrow_up:

... and 1 more

Continue to review full report at Codecov.

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

authors: andymass codecov-io


text:
Remove BeOS code

Since Haiku support is available, it makes sense to get rid of old BeOS
code. Documentation will be handled later, in order to keep necessary
information.

I suppose this code has not been maintained for a while, might not even build.
If someone thinks it would be good to keep anyway, please speak up!

Before this is done we should probably see if anyone still running BeOS gets a chance to check on this.
As a side note, would it be advisable to use python 3.7 over python 2.7 at this stage?

Well, I haven't heard anything for more than a month.  I also have no idea if the current code even builds.
Python 2 has been deprecated, maintenance is stopped, thus Python 3 should be used if possible.

We've checked the build with python 3.7 that seems to be working OK: https://ibb.co/7pmx65Y

FWIW, @bitigchi is looking into bumping our vim version at: https://github.com/haikuports/haikuports/pull/4900
You could check progress there too :)

authors: Begasus bitigchi brammool


text:
Run DO_AUTOCHDIR (honoring &acd option) when writing an unnamed buffer for the first time.

Hi, this is intended to fix #777.
@h3xx Does this seem right to you now and can you think of unforeseen side-effects?

You may want to surround this with #ifdef FEAT_AUTOCHDIR. I don't really know, I'm not in touch with vim's source code. I base this entirely on this patch.

I don't think it's necessary -- it's already guarded in macros.h:
#ifdef FEAT_AUTOCHDIR
# define DO_AUTOCHDIR if (p_acd) do_autochdir();
#else
# define DO_AUTOCHDIR
#endif

Mister fish wrote:

Hi, this is intended to fix #777.
@h3xx Does this seem right to you now and can you think of unforeseen side-effects?

Thanks.  Can we please have your real name?
--
BEDEVERE: And that, my lord, is how we know the Earth to be banana-shaped.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net   \
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \
\\  an exciting new programming language -- http://www.Zimbu.org        ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

On Fri, May 20, 2016 at 09:17:06AM -0700, Bram Moolenaar wrote:

Mister fish wrote:

Hi, this is intended to fix #777.
@h3xx Does this seem right to you now and can you think of unforeseen side-effects?

Thanks.  Can we please have your real name?

No problem: ‘Allen Haim’
Grts.

I accidentally closed this pull request when I deleted my local branch.
If desired I can make a new one :p

authors: brammool h3xx misterfish


text:
Any interests on helping me to recreate a new IO library?

https://github.com/expnkx/fast_io/blob/master/examples/0045.blizzard_authenticator/enroll.cc
I also implement the ryu algorithm like you did.
https://github.com/expnkx/fast_io/tree/master/include/fast_io_freestanding_impl/ryu

This requires C++20?

This requires C++20?

Yes!
C++ is awesome. No overhead of any abstraction. Easy to read code. Not much of template errors.

C++20 isn't even available yet, and once it is available there will not be any users. I prefer to require only C++11, otherwise not many people can use the lib.

C++20 isn't even available yet, and once it is available there will not be any users. I prefer to require only C++11, otherwise not many people can use the lib.

Nope. My library is designed for C++20. Or it is not possible. All its infrastructure is based on C++20 feature concepts to make all the templates overloading work.
It is a library for the future.
Here is a MinGW GCC 10 I compiled last month. It has the std header . You can try it with this amazing compiler :)
https://bitbucket.org/ejsvifq_mabmip/mingw-gcc/src/master/

Here are all the concepts this library defines.
https://github.com/expnkx/fast_io/blob/master/include/fast_io_core_impl/concept.h

Without C++20, it is not possible :)

There are plenty of libraries that have concepts / named requirements that only use C++11, they just don't use the C++20 syntax of concepts but SFINAE works just fine. Beast is one example, Asio is another. This seems like a gratuitous use of new language features at the expense of limiting who will be able to enjoy the library. If that's what you're into, fine, but I am not interested in that.

Without C++20, it is not possible :)

There are plenty of libraries that have concepts / named requirements that only use C++11, they just don't use the C++20 syntax of concepts but SFINAE works just fine. Beast is one example, Asio is another. This seems like a gratuitous use of new language features at the expense of limiting who will be able to enjoy the library. If that's what you're into, fine, but I am not interested in that.

SFINAE does not work fine. Something like working with fold expression will kill you.

authors: expnkx vinniefalco

repo: vinniefalco/json


text:
Error: Read timed out

The Pledges to my project stopped showing up. Did I do something wrong?
Thanx in advance guys :)
-ken

Which server are you using?

I think I used that secondary server with Joe, since you were gone that weekend I could not get the project file onto the vinumeris server. the domain started with the letter T i think, can't remember the exact name.

OK, then we need to ask @JoeSchmid about it.

Let me know if you need anything from me then, I'm here. My skype too is: kenCode_de

I'm kinda new to github so please ask him if ya could for me, thanx Mike :)

Steps to reproduce: Open Lighthouse on linux mint, sync with bitcoin network works fine, other projects I have imported load just fine and their pledges are viewable. click on my project though, and that error message above appears and the pledges are not viewable.

Hi Ken, it should be fixed now. I needed to restart the Lighthouse server. It's been quite stable, but in this case it seemed to stop responding to HTTPS requests. (It seemed to be responding to bitcoin network messages fine though.)

Yep, everything works perfectly again. Did I mention you guys are gods? Thanx again Joe and Mike :) I'll send it to you in a few days, but fyi: https://twitter.com/kenCode_de/status/565186437281099776

authors: joeschmid kenCode-de mikehearn

repo: vinumeris/lighthouse


text:
Ensure BIND9 config allows underscores

Ensure BIND9 configuration is set to allow zones with underscores

Good candidate files for changes:

Updates to BIND configuration: /docker/bind9/etc/named.conf.local

The config option should be check-names ignore;

If it's as simple as adding a single option, let's just do it.

authors: mitruly remerle

repo: vinyldns/vinyldns


text:
Update swagger.yaml

Changed integer to string

@HenrietteBossen Does this still need to go in? You can just merge it. :-D

authors: HenrietteBossen rebekaburnett

repo: vippsas/access-token-api


text:
[vjtop] 进一步改善 vjtop 的交互式体验

Hi Team,
我很喜欢 vjtop 最新添加的交互式操作，这让 vjtop 更加贴近 top 命令
不过我感觉在输入指令后还要按回车实在不够“Geek”
我在网上搜索以后，找到了下面这篇博客提到了可以实现更加贴近 top 的命令输入方式：
Non blocking console input in Python and Java
不过博客中提到的方法只适用于 Linux，Windows 需要引入额外的包
不知道 vjtools team 有没有兴趣研究一下

比较麻烦，先不做了，不是主要需求

repo: vipshop/vjtools


text:
Cannot login

Logged in successfully to a fresh install with admin@admin.com:1234
Set up a new Administrator user with my own email address
Log out
Log in as new user
Redirected back to empty log in form
No errors in storage/logs/laravel.log
Tried migrate:fresh and db:seed, and recreating new user. No difference.
If I do a forgotten password, following the link in the email and resetting password WILL log me in, but again, after logging out, cannot log back in again using normal login form.

This was caused for me by the password being hashed twice when creating a new user or updating a password, once  in

UserRepository.createUserStub
or
UserRepository.updatePassword

and again in

User.setPasswordAttribute.

I've fixed this by changing $user->password = bcrypt($input['password']); to $user->password = $input['password']; in both createUserStub and updatePassword. The password in the database is still hashed and secure, a logging in now works fine.

Fixed this issue and currently merged in develop branch. closing this issue. Let us know if the issue still persists.

repo: viralsolani/laravel-adminpanel


text:
Updating Errors to correctly use SEV API errors

The AMD PSP provides defined SEV errors in the API with clear codes and mistakes. The library currently only bubbles up IO errors and not the correct SEV error when IOCTL calls fail. This commit rearranges the error file to use SEV errors correctly, and then changes the way IOCTL calls returns errors, so that the appropriate SEV error is bubbled up when an error is encountered.

@larrydewey can you re-review?

authors: DGonzalezVillal tylerfanelli

repo: virtee/sev


text:
Add OYW logo

@vivianross06

will merge after OYW approval


text:
Update Readme.txt file

Currently says Requirements: Unity 2018.4 LTS.
Should probably say Requirements: Unity 2018/2019 LTS.

Closing - Fixed.

Closing - Fixed.


text:
extending msbuild to automatically protect against cecil issues

So there exists a possibility to crash Unity by:

Doing a weaver debug build for testing
Doing a weaver release build for pushing
Waiting for the explosion when Unity runs the AssemblyUpdater.exe

AssemblyUpdater.exe uses Cecil and when it finds your release weaver dll with non matching debug symbols file it will explode. It might just error into console if you are lucky, but it can crash the editor. The exception is:
System.InvalidOperationException: Operation is not valid due to the current state of the object.
   at Mono.Cecil.ModuleDefinition.ReadSymbols(ISymbolReader reader)

And traces all the way back up to AssemblyUpdater's entry point
These new msbuild post build targets in the Weaver csproj file simply delete any symbol files that might exist in our plugin folder of the Unity project any time a new release assembly is built. Oh and also unsafe flag was enabled which we don't need so I took it out. Obviously this is not critical, but it will save us future heart attacks when we are testing Weaver updates and suddenly our console is full of familiar looking Cecil errors :D

nice find @c6burns

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


text:
Use checked() syntax to throw on overflow

and simplify comments.
checked() is literally a language feature purpose-built for exactly this use case. Lets use it!
All tests pass.

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


text:
Fix UI of your webpage

I would like to propose a comprehensive review and fix of the current user interface (UI) of our webpage to enhance the overall user experience. The existing UI may not align with modern design principles or best practices, which can lead to confusion and hinder user engagement. By addressing issues such as inconsistent styling, unresponsive elements, and unclear navigation, we can create a more intuitive and visually appealing interface.
A refined UI will not only improve aesthetics but also make it easier for users to navigate and access important features. Implementing design improvements, such as better color contrast, streamlined layouts, and responsive design elements, can significantly enhance usability across different devices and screen sizes. This initiative will foster a more positive interaction with our project, encouraging users to explore and utilize its full potential. I believe that prioritizing UI enhancements will lead to increased user satisfaction and engagement. Thank you for considering this important update!

Similar issue is already assigned to someone else

repo: vishanurag/Canvas-Editor


text:
How to receive multiple responses from just one request?

Hi all,
I'm working with superagent in a personal project and am implementing an API method that executes a long process. I send response messages every iteration of the process to inform the client but I'm not able to update the browser with the proper information until the end of the process when response ends that shows all messages.
I would like to know if superagent library is able to do this kind of stuff.
As a background, I'm developing my API in node.js and send iterative messages with res.write() method under Express web server.

Will this help?
https://visionmedia.github.io/superagent/#progress-tracking

authors: jaloplo wertlex

repo: visionmedia/superagent


text:
Feature request: set origin

would be awesome to cover allowed origins, i.e.:
// app.js
app.get('/', cors({
  origin: "http://allowed.com"
}), (req, res) => {
  res.sendStatus(200)
})

// app.spec.js
const resp = await request(app).post('/').origin('http://allowed.com')
expect(resp.status).toStrictEqual(200)

You already can Set('Origin', ...)

hmmm, guess it would be nice to have that in the documentation :)

authors: OneCricketeer goldylucks


text:
Save/load functionality

Viskell definitely requires a way to save and load Viskell programs. The load and save events are available and a basic load/save system is available in the https://github.com/wandernauta/viskell/tree/saveload branch.

FYI I'm working on this within the current structure.

I have done a bit of work on this, with some minor changes to the output format and implementing much of the import functionality.
I have it working for a subset of types of blocks - but some others have some complex sub-elements (FunctionInfo, FunctionReference) that I don't understand yet and will need help to serialize and deserialize.
Here are some of my considerations implementing it, and I will share a WIP PR for you to critique.
Output Formats
I don't see anything wrong with JSON, it's well known, easy to parse and read.
I thought about using GSON "totally" for "automatic" serialization and deserialization.
One problem is that the JSON output would be full of fully qualified classnames and not so nice and clean and easy to read.
That makes it also fragile to package or class name changes. That will be true (at least with class names or object names) for almost any solution.
Serialization
I've gone the route of adding more data to the export, splitting it into two collections (JSON Arrays) of two different types ("Blocks" and "Connections"). I was going to serialize into three layers as is structured in memory, but saw that addBlock() figures out which layer a block belongs to and adds accordingly. So I can serialize all blocks into one array and deserialization just adds them all using addBlock().
Deserialization
When I looked more at the code and the need to connect things up after deserialization I decided that deserialization with the help of all the involved objects (like serialization) was probably the best way to go.
There are two main ways I considered to do this:

All serializable classes have a default (zero parameter constructor). This is instantiated by the deserializer, then an instance method is called, passing in the Bundle and it sets it own class-specific parameters from the Bundle.

All seriablizable classes have a static fromBundleFragment() method that reads in a bundle, and instantiates an object using the existing constructors, reading extra class-specific parameters from the bundle and returns the new object.

I decided on 1) as it was less disruptive, avoiding the need for new Constructors for all classes AND the fromBundle() method - and keeping those constructors in-sync with existing ones. Static method maybe is not so nice, but it's less code and any serialization related changes and limited to this method. It also uses the existing Constructors (some of them have non-trivial logic....)
Deserialization Process
The input file is read and GSON is used to parse into two arrays, one for Blocks and one for Connections.
For Blocks I have a map of the class simple names to the full class path to be able to find the correct fromBundleFragment() method. This would survive some automatic code refactorings without change.
The Block class has a fromBundle() method that finds the class based on the short classname ("kind") in the JSON, finding the fromBundleFragment() method for the correct sub-class and invoking it, passing it the "properties" sub-Bundle so it can take care of its per-class specific.
Each instantiated Block is then add it to the TopLevelPanel (preserving x and y onscreen).
I keep track of loaded blocks and their IDs (from the export, not the current ID) in a temporary map.
Then, I parse the array of Connections, finding the source Block and sink Block and Anchors from the temporary map. The COnnection is created with the correct source and sink, and then added to the ToplevelPane also.
The Connection and sink Block are then invalidated to force a redraw.
Other considerations

Should probably put a version number in the file.
Could dump the map of object names to class names at the end of the file....but wouldn't help with forwards compatibility and only makes it uglier.
Needs work on some of the more complex Blocks I don't understand yet.
Needs unit tests for some of this.

I think we can close this one in favor of smaller, more specific issues, like https://github.com/viskell/viskell/issues/432 related to remaining issues in deserialization?

Agreed.

repo: viskell/viskell


text:
Serializer settings should also be used when explicitly passed in

I believe the fix for #49 was incomplete, this.serializerSettings should also be set in the second overload accepting JsonSerializerSettings as an argument.

Agree...good catch.

Yep, we need better tests to catch that

authors: jmpease samuelabj wagich

repo: visualeyes/halcyon


text:
Control deselects when navigating outside the area

A lot of users complain about the fact that the control switches from "editable" to "readonly" when they click inside > move mouse outside > and release the mouse.

Click inside (ex : if you want to select the text and copy paste the information)
Move mouse outside control
Release mouse
--> You are no longer able to copy paste that information

https://github.com/vitalets/angular-xeditable/blob/ca6d768a74f341df2ab6fe498a09fde24ec66926/src/js/editable-form/controller.js#L43
We fixed the issue on our local version by changing the OnClick to a MouseDown.
If we create a pull request for this topic, any chance it can be merged into the main version ?

pls review records - https://www.loom.com/share/2b01f81d1bca49c380a3727bf2147f2a
brief context:
problem: when you are doing mouse up outside on input box, submit is triggering.
reason: because we r listening on click event - line: 1485 - $document.bind('click', function (e) { ....
solution: listen to mousedown like - $document.bind('mousedown', function (e) {

@ckosloski pls take a look and update if that change is ok - sorry for that urgency but we are in a hurry and it cause some usability issue for our customers

What kind of configuration are you using for xeditable?
If I go here - http://vitalets.github.io/angular-xeditable/#text-simple
I can't reproduce the issue
You are welcome to create a pull request.

@ckosloski  thanks for such a quick response. I was able to reproduce same on that link pls take a look - https://www.loom.com/share/5ccd44b7e58d4babbbecd8fea3a17b85
ok thats great ill push a PR

@ckosloski i've made a PR - https://github.com/vitalets/angular-xeditable/pull/758 . pls take a look once u will have some time for that.
thanks a lot 👍

So I was able to reproduce this in chrome, but it works correctly in firefox.

Please close this.

authors: bartdk-be ckosloski drsmog

repo: vitalets/angular-xeditable


text:
internal error: entered unreachable code: auto_accessor pass should remove this

I converted a project from using vite-plugin-react to using this because of https://github.com/vitejs/vite-plugin-react/issues/266 and initially it compiles fine. However, as this plugin enforces useDefineForClassFields I need to add accessor to Lit Element properties for them to keep working (https://lit.dev/docs/components/properties/#avoiding-issues-with-class-fields).
When I change something like
  @state()
  foo = false;

to
  @state()
  accessor foo = false;

It all stops working with
thread '<unnamed>' panicked at /Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/swc_ecma_compat_es2022-0.1.41/src/class_properties/mod.rs:957:21:
internal error: entered unreachable code: auto_accessor pass should remove this
[vite] Internal server error: failed to handle: internal error: entered unreachable code: auto_accessor pass should remove this
Plugin: vite:react-swc

This is in a .ts file, so it sounds like the plugin should not even process it.

This is either a bug in SWC (at least we could consider the parser should error and not panic) either an incompatibility between Lit and the spec (which I think is the case given this TS flag was removed from the lit template IIRC)
This plugins enforce standards for reason stayed here: https://github.com/vitejs/vite-plugin-react-swc/pull/178#issuecomment-1824272225, so it's either a won't fix or upstream issue.

Btw, it looks like it is possible to make this work with SWC, but only if a transform is passed to tell SWC not to use the legacy decorators but to use the new one. It looks like this package deliberately prevents the passing of such transforms.
See:

https://swc.rs/docs/configuration/compilation#jsctransformdecoratorversion
https://github.com/swc-project/swc/issues/8438

I understand that the reasons for not passing through transforms are to encourage the use of standard configurations and to encourage the use of new features. However, but right now this means that we can't use the newer non-legacy decorators.
Is there any prospect of a specific decorators switch so that we could use the non-legacy decorators without having to expose the whole of the transforms API, which causes concern?

authors: ArnaudBarre Artur- RoystonS

repo: vitejs/vite-plugin-react-swc


text:
esbuild now supports the missing features

Description
as per Vite docs, it doesn't use esbuild for bundling because

some of the important features needed for bundling applications are still work in progress - in particular code-splitting and CSS handling

but now esbuild supports code-splitting and CSS handling

Suggested solution
use esbuild for bundling
Alternative
No response
Additional context
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Given Vite's usage of Rollup's plugin API for quite some time now, it's actually harder to transition to esbuild fully without causing a big breaking change. It's probably worth experimenting still but it would be a huge undertaking. We could probably update the docs to reflect the new limitation for now though.

I really wait for supporting esbuild

Could I work on this?

Does this issue refer to working on the documentation website or the README?

authors: bluwy eng-dibo mirchandani-mohnish

repo: vitejs/vite


text:
Automate Housekeeping after template initialization

Description
As a developer using git I want scripts that I can run to automate removal of sample code such as the highlighted code.
This a react from running
npm create vite@latest ... --template react

Suggested solution
A simple node script that can be run using npx
Alternative
No response
Additional context
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

This is out of scope. We keep create-vite as simple as possible. I guess you can create a script that removes some code and use that.

authors: sapphi-red vinceflores


text:
HMR won't work on vue files if import other packages which are in the same monorepo

Describe the bug
Edit a file in a package of a monorepo. No HMR, no reload, but vite log shows that the module has been updated.
Reproduction
https://github.com/niuiic/vue-fusion
Steps to reproduce
git clone https://github.com/niuiic/vue-fusion -b dev
pnpm i
pnpm build
cd packages/styles
pnpm dev

Edit packages/styles/src/App.vue, just add a console.log('hello') in script.
No reload, no HMR.
However HMR works when change code in <style>.
In addition, If I remove some code in App.vue and main.ts, HMR would be able to work, but not always.
In another similar project (almost the same, but not a monorepo).
git clone https://github.com/niuiic/vue-resource
pnpm i
pnpm dev

Edit src/App.vue.
HMR works.
System Info
System:
    OS: Linux 6.9 Arch Linux
    CPU: (16) x64 AMD Ryzen 7 5800H with Radeon Graphics
    Memory: 8.60 GB / 15.58 GB
    Container: Yes
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 22.2.0 - /run/user/1000/fnm_multishells/19365_1718856780871/bin/node
    Yarn: 1.22.22 - /usr/bin/yarn
    npm: 10.7.0 - /run/user/1000/fnm_multishells/19365_1718856780871/bin/npm
    pnpm: 9.4.0 - /run/user/1000/fnm_multishells/19365_1718856780871/bin/pnpm

Used Package Manager
pnpm
Logs

vue-fusion styles
  vite:hmr [file change] src/App.vue +40s
12:04:16 PM [vite] hmr update /src/App.vue
  vite:load 0.92ms [fs] /src/App.vue +40s
  vite:cache [memory] /src/utils/code/index.ts +40s
  vite:cache [memory] /node_modules/.vite/deps/vue.js?v=acf679e9 +1ms
  vite:cache [memory] /node_modules/.vite/deps/element-plus_es_locale_lang_zh-cn.js?v=83fa67f3 +0ms
  vite:cache [memory] plugin-vue:export-helper +0ms
  vite:cache [memory] vite/dynamic-import-helper.js +0ms
  vite:hmr [self-accepts] src/App.vue +64ms
  vite:import-analysis 2.90ms [7 imports rewritten] src/App.vue +40s
  vite:transform 23.73ms /src/App.vue +40s
  vite:time 25.52ms /src/App.vue +40s
  vite:load 1.50ms [plugin] /src/App.vue?vue&type=style&index=0&scoped=7a7a37b1&lang.scss +25ms
  vite:hmr [self-accepts] src/App.vue?vue&type=style&index=0&scoped=7a7a37b1&lang.scss +24ms
  vite:import-analysis 0.30ms [0 imports rewritten] src/App.vue?vue&type=style&index=0&scoped=7a7a37b1&lang.scss +25ms
  vite:transform 23.41ms /src/App.vue?vue&type=style&index=0&scoped=7a7a37b1&lang.scss +25ms

vue-resources
 vite:hmr [file change] src/App.vue +9s
12:01:44 PM [vite] hmr update /src/App.vue (x3)
  vite:load 1.27ms [fs] /src/App.vue +9s
  vite:cache [memory] /src/utils/code/index.ts +9s
  vite:cache [memory] /node_modules/.vite/deps/vue.js?v=bb7042f4 +0ms
  vite:cache [memory] plugin-vue:export-helper +0ms
  vite:cache [memory] vite/dynamic-import-helper.js +0ms
  vite:hmr [self-accepts] src/App.vue +32ms
  vite:import-analysis 1.47ms [8 imports rewritten] src/App.vue +9s
  vite:transform 18.01ms /src/App.vue +9s
  vite:time 20.12ms /src/App.vue +9s
  vite:load 0.98ms [plugin] /src/App.vue?vue&type=style&index=0&scoped=7a7a37b1&lang.scss +19ms
  vite:hmr [self-accepts] src/App.vue?vue&type=style&index=0&scoped=7a7a37b1&lang.scss +19ms
  vite:import-analysis 0.38ms [0 imports rewritten] src/App.vue?vue&type=style&index=0&scoped=7a7a37b1&lang.scss +19ms
  vite:transform 18.03ms /src/App.vue?vue&type=style&index=0&scoped=7a7a37b1&lang.scss +19ms

Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

In packages/styles/src/utils/code/Code.vue, I import something from packages/buintins. Then hmr not work for all vue files in packages/styles


text:
fix(css): use single postcss instance

Description
compileCSS function calls PostCSS inside and #8400 used compileCSS function inside the post-css-import's load option.
This causes a different PostCSS instance to be used inside @import and broke #13732. Also I guess running multiple PostCSS instances will hurt performance if tailwind is used since tailwind will crawl the files for every PostCSS instance.
This PR extracts the preprocessor part of compileCSS function to compileCSSPreprocessor function and uses that function in the post-css-import's load option. I found that #8400 didn't implement sourcemap support but I didn't implemented that because it would be complicated.
close #13732
refs #8400
Additional context

What is the purpose of this pull request?

[x] Bug fix
[ ] New Feature
[ ] Documentation update
[ ] Other

Before submitting the PR, please make sure you do the following

[x] Read the Contributing Guidelines.
[x] Read the Pull Request Guidelines and follow the PR Title Convention.
[x] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
[ ] Ideally, include relevant tests that fail without this PR but pass with it.

/ecosystem-ci run


text:
refactor: standardize create-vite vanilla templates

Description

Includes removal of innerHTML which is not considered a safe practice, replaces it with textContent.
Reduces usage of javascript / typescript to add to DOM, instead relies on standard HTML.
Replaces div#app with standard main tag
As a side effect there might be a slight increase in performance, but that is not the goal here.

Additional context

This PR is meant to be squash merged

What is the purpose of this pull request?

[ ] Bug fix
[ ] New Feature
[ ] Documentation update
[x] Other

Before submitting the PR, please make sure you do the following

[x] Read the Contributing Guidelines, especially the Pull Request Guidelines.
[x] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
[ ] Update the corresponding documentation if needed.
[ ] Ideally, include relevant tests that fail without this PR but pass with it.

I'm not sure if we need this change. The code is meant to mimic how the other framework templates like React and Vue renders things. This makes it less consistent with the other templates.

I agree with bluwy, but thanks for the PR anyways.

authors: bluwy n-ce sapphi-red


text:
Fix typo in getting started guide

"Vitejs" intead of "Vutejs"

thanks ;)

thanks ;)


text:
Deprecate deps.inline in favour of deps.optimizer

Clear and concise description of the problem
Currently, it is not very obvious to most users how deps.inline works and why it needs to be used for certain packages. It also doesn't work with monorepo packages when string version is used (internally it just checks node_modules/{name}).
This option also makes tests run slower because Vitest needs to process these files through Vite pipeline one by one which is not very optimal. This is also not what Vite itself is doing when it's running in the browser.
On the other hand, deps.optimizer does the same thing that Vite does with the package in the browser - it pre-bundles it into a single entry point. This makes it faster to import, fixes CJS compatibility issues, and allows the use of plugins and aliases on a just single compiled file.
Vitest provides this option for quite some time, but we hit the wall with how the optimizer works in the browser. When it hits the new module, Vite just reloads the page and starts optimizing again - we can't do this so easily in our case. We also don't want to bundle actual Node.js packages that are used in setup files, for example. To solve this issue, Vite team introduced noDiscovery option in Vite 4.3. Theoretically, this should solve our issues and be an alternative to deps.inline.
Suggested solution
To make the transition clear, we should deprecate deps.inline, deps.exclude, and deps.registerNodeLoader with a message: Use "deps.optimizer" instead.. Instead of removing these options completely, we should provide them in a new option called server for those who prefer using Vite Node to run their source code instead of native Node (the name of the option is debatable - we can't name it viteNode, because the project will have a different name by the time it is implemented in Vite core).
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

One use case where deps.inline is neccessary is when a module ships CSS imports, e.g. import './style.css'. Vite knows how to load CSS, but vitest doesn't.
Will deps.optimizer help with that, or even better, will there be an automatic solution to CSS imports, e.g. like dynamically creating a <style> element in the virtual DOM (assuming jsdom or happy-dom)?

One use case where deps.inline is neccessary is when a module ships CSS imports, e.g. import './style.css'. Vite knows how to load CSS, but vitest doesn't and throws an error.
Will deps.optimizer help with that, or even better, will there be an automatic solution to CSS imports, e.g. like dynamically creating a <style> element in the virtual DOM (assuming jsdom or happy-dom)?

deps.optimizer works more like Vite works in the browser. deps.inline works like if you disable optimzieDeps.

The idea is to make it easier to work with. We are currently gathering feedback and it looks like this option will stay in one form or another. Ideally, we would like these packages to just work out of the box.

Might be hijacking thread, but is there a plan for vite-node to allow reading values from config file?
I'm trying to run vite-node --config vite.config.ts ./server.ts but this doesn't seem to work, with this config:
    test: {
      deps: {
        external: [/some-package/],
      },
    }

If I do vite-node --config vite.config.ts --options.deps.external='/some-package/' ./server.ts it works.
(got here because I also have similar issue with package that exposes many entry points)

authors: GuskiS sheremet-va silverwind

repo: vitest-dev/vitest


text:
docs: add instructions for debugging tests via terminal

Adds example of running vitest with debugger in the shell (without an IDE)

@sheremet-va check it

Sadly, ndb is unmaintaned and doesn't work with node 19. It shouldn't be recommended.

Thanks @1EDExg0ffyXfTEqdIUAYNZGnCeajIxMWd2vaQeP,
I've opened a PR #2869, to revert this change.


text:
feat: include "vitest" in the process name

Description

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[ ] It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
[ ] Ideally, include a test that fails without this PR but passes with it.
[ ] Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

[ ] Run the tests with pnpm test:ci.

Documentation

[ ] If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

[ ] Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

Why not just proces.title = 'vitest'? Many process list parsing tools can match that out of the box, but can likely not match node (vitest).

Why not just process.title = 'vitest'? Many process list parsing tools can match that out of the box, but can likely not match node (vitest). Also, put a try-catch around it for unsupporting runtimes.

Because people look for the "node" process usually. This is why I asked @AriPerkkio opinion here.

Why not just process.title = 'vitest'?

If you tests spawn external processes you won't see those if you look for vitest. Minimal repro below:
process.title = "vitest";
setTimeout(() => {}, 5000);

$ node repro.mjs

$ pgrep node
> no results

This works:
process.title = "node (vitest)";
setTimeout(() => {}, 5000);

$ node repro.mjs

$ pgrep node
76662       # <--- Yes this is good

$ pgrep vitest
76662          # <-- also here

$ ps $(pgrep node)
  PID   TT  STAT      TIME COMMAND
76662 s008  S+     0:00.04 node (vitest)

I prefer pidof over pgrep because it's a exact match it won't find it with the current name:
$ node -e 'process.title = "node (vitest)"; setTimeout(() => {}, 60000);'

$ pidof vitest # fails

$ node -e 'process.title = "vitest"; setTimeout(() => {}, 60000);'

$ pidof vitest # works

Also, what if vitest is run in another runtime like bun or deno? It's wrong to identify as node in such cases.

Also, what if vitest is run in another runtime like bun or deno? It's wrong to identify as node in such cases.

This should not be a problem because:

bun doesn't support process renaming
Deno doesn't support running vitest

bun doesn't support process renaming

It will eventually and then you'll have to needlessly change the process name again. I still think vitest is the ideal process name but if you persist on this silly name, use at least path.basename(process.argv[0]).

authors: AriPerkkio sheremet-va silverwind


text:
[FEATURE]

Is your feature request related to a problem? Please describe.
No, just my personal opinion.
Describe the solution you'd like
Enable markdown
Additional context
I believe a basic Markdown is highly important. We are creating notes after all and notes are easily readable when we emphasize some important part of our note. I also realize that headers can become a problem to so, I'm proposing to bring back markdown except headers.

If so, we might need a way to know when a post should be rendered as Markdown and when not to. Because most posts will look vastly different when rendered with a Markdown renderer.
Also, Markdown without headers is not Markdown :)

Amethyst now detects if there are markdown tags and render it as such. It's not fool proof but it works most of the time.

authors: StellarStoic vitorpamplona

repo: vitorpamplona/amethyst


text:
Replace NIP93 Profile Gallery with Nip68 Gallery

Rationale:

NIP93 didn't get merged, no other client uses it.
Nip68 (Kind 20 events) are considered "High quality posts" in Olas and they land in the user's gallery in Olas anyways.
This gives us a way to have syncronized galleries over multiple clients, NIP93 then is obsolete.
Instead of clicking an image and hitting "add to gallery" with referencing to the original note, this simply references to the the kind 20 event.  Kind 20 events can be posted in the multimedia (aka tt/insta) feed, and eventually reposted/quote posted to the regular kind 1 feed.

This is an alternative PR to #1210

Additionally, fixes kind20 description not being added to "content" field.

Went with https://github.com/vitorpamplona/amethyst/pull/1210

authors: believethehype vitorpamplona


text:
Server HMR error messages only flashing

After altering our existing Vite project to Vituum the HMR error message overlay only flashes briefly in the browser before disappearing.
Restarting vite will render the error message once, after a browser refresh or a refresh because of a file change the error message will only flash briefly again.
Any ideas what could cause this behaviour?
Cheers

could you send a repro? or vite.config.js atleast?

I hope the vite.config.js helps.
import { defineConfig } from 'vituum'
import twig from '@vituum/twig'

// POSTCSS
import autoprefixer from 'autoprefixer'
import postcssImport from 'postcss-import'
import postcssNested from 'postcss-nested'
import postcssCustomMedia from 'postcss-custom-media'
import postcssImportExtGlob from 'postcss-import-ext-glob'

export default defineConfig({
  integrations: [twig()],
  templates: {
    format: 'twig',
  },
  output: 'dist',
  vite: {
    css: {
      postcss: {
        plugins: [
          autoprefixer,
          postcssImportExtGlob,
          postcssImport,
          postcssNested,
          postcssCustomMedia,
        ],
      },
    },
  },
})

Thanks, I've been able to reproduce this in Chrome, works in Firefox though. Should be fixed in plugin now -> https://github.com/vituum/vite-plugin-twig/commit/3c33dd5a248f3764b3c37a6386210e9ab626e46a
Update your deps in project, eg. with npm update and should be fixed now.

authors: lubomirblazekcz superflausch

repo: vituum/vituum


text:
Policy for editing the ontology

What is the motivation for your change request?
Using different tools/editors can result in different serializations, which makes the git diff function useless.
Describe the solution you'd like
We need to decide on a tool that we make mandatory to be used for edits. I suggest to require certain versions of Protege. Which versions are allowed will depend on their respective OWLAPI version.
Describe alternatives you've considered
A github action that re-serializes every commit in a particular order to make diffs easier to understand. Might be complicated and brings maybe new issues with it.
Additional context
Thanks to @StroemPhi for the discussions and hints!

It was clarified in today's onto call that the suggested solution needs some testing. @brianjlowe volunteered to set up a repo for that purpose.
Decision documented in https://wiki.lyrasis.org/display/VIVO/2024-09-04+Ontology+Interest+Group+Call.

Closed with https://github.com/vivo-ontologies/vivo-ontology/pull/51.
Habemus editing policy!

repo: vivo-ontologies/vivo-ontology

license: Unlicense


text:
Create Gradient Sky Sphere Patch

Given how shit pixel-based sky spheres look (especially with distortion of stars etc), a shader-based sky sphere that just renders a nice sphere in code would be super useful for many scenes. I'm thinking something that will allow you to define two (or more) colours, and then adjust their start & end points, along the lines of the Illustrator one below.

Or maybe a better way to do this would be to create a general purpose gradient tool patch, and then a skysphere that could be controlled by it ?

Vizor chat, Dec 3rd:
Chiarapassa:  "another question: How to build a 360 skydome as interactive gradient color?"
The users are asking for it :)

This could probably be very easily done by a pixel shader . It should be a pixel shader that creates a gradient, and then a couple of color picker inputs into it. Then that would just be piped into a texture of a skysphere.
There might be examples in shadertoy for gradients, so I can see if I could create this myself.

yeah this would be a handy & much used tool i'd say

First try: http://vizor.io/fthr/color-spline/edit
Source for the shader: https://www.shadertoy.com/view/ltfXR4
If only I could make the gradient horizontal though ;)

Must have missed this the first time around. Yeah, this is pretty cool @fthr If we could set the direction of it, and the number of colours in the gradient – perfection :)

authors: fthr mattatgit

repo: vizorvr/vizor


text:
Tutorial - Data chapter - Data cube figure contains wrong value

Smooth Jazz should be 174 (instead of 74)
https://lib.vizzuhq.com/latest/#chapter-0.1

@simzer Fixed in vizzu-lib f12169c

Released

authors: simzer veghdev

repo: vizzuhq/vizzu-lib-doc


text:
V0.1.9

V0.1.8:

Remove cloning resource attributes from prior resource (CHEF-3694)
Permanent fix for #8 - remote_file for enterprise edition with authentication
After PR #12 attribute mesh-seed-address-port not needed.
Update cluster.rb recipe for default value and support chef-solo if possible
Restart amc applicatoin if aerospike was restarted
Update tests and rake's tasks

V0.1.9:

Update default attribute configuration
Remove notify for AMC dashsboard as problem was fixed at AMC 3.6.8.2
Disable empty xdr section in config file, wich caused an error for EE (Enterprise Edition)
Update aerospike-cluster::amc for installation AMC EE. Closed #8

@pioneerit  LGTM

authors: pioneerit vkhatri

repo: vkhatri/chef-aerospike-cluster


text:
Only call powershell resource on windows machines

The powershell resource isn't even defined on non-windows machines in
newer versions of Chef, so only_if is not sufficient to prevent
"resource not found" errors.
Note that this may actually be needed to address #64 because it also applies to powershell_script.

I was going to suggest the same thing however it makes the code slightly less readable and Foodcritic is going to complain about not preferring conditional attributes. I think you need to add the following next to the if statement or the powershell resource. Ex:
if node['platform'] == 'windows' # ~FC023

@JCotton1123 good suggestion. Added.

@eherot Thank you!

authors: JCotton1123 eherot vkhatri

repo: vkhatri/chef-filebeat


text:
Working with Tasks Plugin

If this Plugin could somehow work with the Tasks Plugin and count the Time spent in Tasks that are scheduled for a given Day that would be the holy grail for me. Is something like that planned ?

I haven't used Tasks before. Judging by its description, it works on a different principle: allowing you to work with tasks without having to add them directly to daily notes. At the moment, Timesheet doesn't support this, and I also have no plans to implement such functionality (since it didn't come to mind).
I'll look for some sort of Tasks API next week; probably there is a simple way to get the results of a query for tasks, which allows me to implement the Tasks plugin support in Timesheet relatively quickly. I'll keep you posted.

Took a look. Currently, Obsidian Tasks doesn't provide an API that enables you to get tasks according to a given query for further parsing in another plugin. Consequently, I see no quick solution for the task you are describing. It is possible, for sure, but I have no time frame to work on it in the near future.

yeah I figured, that that will be a problem.  But thank you a lot for at least looking into it!

authors: Admorei vkostyanetsky

repo: vkostyanetsky/ObsidianTimesheet


text:
Implement basic ChannelEnvironment TUI widget and app

Relevant / near-term feature to support development for: https://github.com/vkottler/runtimepy/issues/102.
Implement initial textual (getting started) UI that is wrapped by a runtimepy arbiter application method.
This TUI should have vertical or horizontal tabs to view individual connection metrics, and eventually logging information as well.

Got some solid initial dev: https://github.com/vkottler/conntextual/pull/2.

Some next up things:

stats for the UI itself, number of iterations + rate, number of channel environments, maybe number of channels?
try making a new app that uses tabs for each channel UI?

Initial milestones complete, looking to expand scope now.

repo: vkottler/conntextual