text:
Grid's property EmptyDataTemplate is not decorated as a Parameter.

I am using version 2.2.0. When I use the component Grid the paramater from the documentation EmptyDataTemplate is not available, because it is not decorated with Paramater in the Grid implementation.

@kpavlov9 Thank you for using BlazorBootstrap. We will check this.

repo: vikramlearning/blazorbootstrap


text:
Fix documentation issues

Not meant to resolve all github issues with documentation - the primary purpose was to resolve #53 and the documentation issue discussed in #48, but I included some other improvements as well.

Resolve #53 by changing lifetime references of units to those used in the code and levelfiles (femtoseconds, not attoseconds).
Resolve #34 by creating a "Workflow" section in the CONTRIBUTING.
Clarify syntax for verbosity flags (see #48).
Add badge for arXiv (see #37).
Improved CONTRIBUTING organization.

Created pull_request_template.md as a separate file.
Removed templates from CONTRIBUTING - using GitHub's management of templates instead.

Requesting review mostly on the changes to CONTRIBUTING, since I restructured it. Are you okay with moving the code of conduct and all the templates out of the contributing file? Also, I mostly copied what you wrote on the "Workflow" section, but I did make some changes to generalize it - are those still the correct steps?

@villaa Okay, I think I addressed everything we talked about - the only downside is that adding the sphinx requirements to the conda environment seems to have drastically increased the environment build time, depsite adding version numbers for all of the requirements. That said, it's still short enough that the tests pass.

Settling on - since most users aren't building the docs, as they're available online already, the "default" provided environment shouldn't include those dependencies at a cost to the user's time. So, I'm keeping that version of the environment file as a separate yaml (nrCascadeSim_withDocs.yml), and switching the main one back so that anyone who doesn't intend to build the docs can still build the environment in a reasonable amount of time.

source: gharchive/pull-request

repo: villano-lab/nrCascadeSim

license: MIT

license_type: permissive

license_source: github-api


text:
:+1: Add denops-store as a global store

Please up vote (👍 ) if you need this feature on denops.vim itself.

The file-based kv storage is not best because we need to take care of the conflicting thus it requires a lock file.
The localstorage can control the conflicting. Please consider it.

Good point. I'll think about it.


text:
Add out_noscroll and err_noscroll to job options

Is your feature request about something that is currently impossible or hard to do? Please describe the problem.
When job output is written to an empty buffer, it will be scrolled. It is impossible to avoid scrolling and moving the cursor.
This behaviors is documented:

When the buffer written to is displayed in a window and the cursor is in the
first column of the last line, the cursor will be moved to the newly added
line and the window is scrolled up to show the cursor if needed.

Describe the solution you'd like
Add out_noscroll and err_noscroll options.
Describe alternatives you've considered
There is no workaround.

Is your feature request about something that is currently impossible or hard to do? Please describe the problem.
When job output is written to an empty buffer, it will be scrolled. It is impossible to avoid scrolling and moving the cursor.
This behaviors is documented:

When the buffer written to is displayed in a window and the cursor is in the
first column of the last line, the cursor will be moved to the newly added
line and the window is scrolled up to show the cursor if needed.

Describe the solution you'd like
Add out_noscroll and err_noscroll options.
Describe alternatives you've considered
There is no workaround.

I would think the workaround is to move the cursor away from the last
line.  Isn't that working?  If this is really only about starting with
an empty buffer, adding a flag that also changes behavior when the
buffer is not empty is likely to trigger a request for another flag with
slightly different behavior.  I don't think such tweaking is useful
enough.
--
I AM THANKFUL...
...for a lawn that needs mowing, windows that need cleaning
and gutters that need fixing because it means I have a home.
/// 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    ///

@noscript A workaround is to avoid using buffer for the out_io and err_io options.
You can always append to a prepared buffer using a out_cb (and err_cb) function together with setbufline() or appendbufline().
Here's an example:
vim9script

var jobid: job

def Test()
    const bufnr: number = bufadd('job-buffer')
    bufload(bufnr)
    setbufvar(bufnr, '&buflisted', true)
    setbufvar(bufnr, '&buftype', 'nofile')
    silent deletebufline(bufnr, 1, '$')

    if bufnr->win_findbuf()->empty()
        execute 'vertical sbuffer' bufnr
        wincmd p
    endif

    if job_status(jobid) == 'run'
        job_stop(jobid)
    endif

    jobid = job_start([&shell, &shellcmdflag, 'for i in `seq 1 10000`; do echo "$i"; done'], {
        in_io: 'null',
        err_io: 'out',
        out_cb: (ch: channel, msg: string) => setbufline(bufnr, '$', [msg, '']),
        close_cb: (ch: channel) => {
            while ch_status(ch, {part: 'out'}) == 'buffered'
                setbufline(bufnr, '$', [ch_read(ch, {part: 'out'}), ''])
            endwhile
            deletebufline(bufnr, '$')
        }
    })

    if job_status(jobid) == 'fail'
        echohl ErrorMsg
        echomsg 'Failed to run job_start()'
        echohl None
    endif
enddef

command Test Test()

In the example above I use setbufline() in the out_cb function. When the job is done, I end up with an empty line at the very end of the buffer which I delete in the close_cb function. Alternatively, you can use appendbufline(bufnr, 1, msg). In that case you will end up with an empty first line which you need to remove. A third option is use setbufline(bufnr, 1, msg) the first time the out_cb function is called, and afterwards appendbufline(bufnr, '$', msg). In this case you won't end up with an empty line.

out_cb: (ch: channel, msg: string) => setbufline(bufnr, '$', [msg, '']),`

I was afraid that appending line-by-line would be slower than "out_io": "buffer" but there is no major difference.

If this is really only about starting with
an empty buffer, adding a flag that also changes behavior when the
buffer is not empty is likely to trigger a request for another flag with
slightly different behavior.

The flag would keep the scroll position for both empty and not empty buffer cases. I don't think there would be a need for another flag later. But workaround by @bfrg is good enough.
Thank you.

source: gharchive/issue

authors: bfrg brammool noscript

repo: vim/vim

license: Vim


text:
Windows uninstaller doesn't remove vimtutor.bat

Install Vim, make sure you check the "Create .bat files" box during the process
Uninstall Vim. The file C:\Windows\vimtutor.bat is still there.

Vim: https://github.com/vim/vim-win32-installer/releases/download/v8.2.0230/gvim_8.2.0230_x86.exe,
Windows 10 Home 1803.

Fixed by #5603.

authors: k-takata lkintact


text:
On Windows, fnamemodify(..., ":.") can strip the drive letter from the result.

On Windows,

Run vim or gvim with -N -u NONE
note the current directory via :pwd
execute :echo fnamemodify("C:\\X\\y.txt", ":.") (or similar, the important part is that the given filename not be underneath the current working directory).

The result will be something like "\X\y.txt" -- which is unexpected given that the documentation under :help filename-modifiers says that ":." will result in an unmodified file name if the file name is not below the current directory.
This occurred on vim 7.4 (patches 1 - 1087), obtained from the Cream distribution. It also happens on the gvim installed by the official installer on the vim.org website (I tried the Cream build in case it had more recent patches to fix the issue).

I've looked into it a little more and I think the reason this happens is because handling fnamemodify eventually calls shorten_fname in fileio.c, which has this bit of code:
/*
 * When using a file in the current drive, remove the drive name:
 * "A:\dir\file" -> "\dir\file".  This helps when moving a session file on
 * a floppy from "A:\dir" to "B:\dir".
 */
else if (len > 3
  && TOUPPER_LOC(full_path[0]) == TOUPPER_LOC(dir_name[0])
  && full_path[1] == ':'
  && vim_ispathsep(full_path[2]))
    p = full_path + 2;

...which makes it seem like this drive letter stripping is intentional and useful in scenarios other than fnamemodify, but I'm not sure how to suggest fixing fnamemodify without breaking the behavior expected in the above comment.

I don't see why this is anything other than a documentation issue.  The path is semantically the same.

Yeah, it could just be a documentation issue; adjusting the docs to note the potential behavior would certainly seem to me to be the simpler approach. I don't have a strong argument that the behavior should change, it just seemed surprising given the current documentation.

I guess it's also worth noting that fnamemodify("C:\\X\\y.txt", ":~") apparently does not drop the drive letter under the same scenarios that :. does.

authors: jamessan jpetrie


text:
:set guioptions+=v ignored in GTK3 GVIM

Describe the bug
The GTK3 GVIM does not honor the request to use a vertical button layout for dialogs (:set guioptions+=v), and always renders the buttons horizontally, which (when there are many and/or long choices) can lead to ugliness (in a horizontal multi-monitor setup, the dialog spans multiple monitors) or even inaccessibility (the dialog gets truncated and some buttons are now visible).
This affects the default vim-gtk3-2:8.1.2269-1ubuntu5 package that ships with Ubuntu 20.04 LTS, as well as a self-compiled (--enable-gui=gtk3) latest version 8.2.2406.
The GTK2 variant (vim-gnome package, latest version compiled with --enable-gui=gtk2) is showing the vertical button layout just fine.
To Reproduce

Run gvim --clean --cmd 'set guioptions+=v' -c 'call confirm("Test", "one\ntwo\nthree")'

Expected behavior
I have plugins that present a lot of long options and therefore basically only are usable with a vertical button layout; the only fallback would be to use text-based dialogs via :set go+=c.
:help confirm() mentions:

confirm()		tries to put the buttons in one horizontal line.  If they		don't fit, a vertical layout is used anyway.  For some systems		the horizontal layout is always used.

Even if (I'm guessing) GTK3 doesn't allow a vertical layout simply by setting a flag, a custom dialog (basically a modal window with a label, icon, and some buttons) surely could be implemented for it.
Screenshots

Environment (please complete the following information):

Vim version 8.1.2269, 8.2.2406
OS: Ubuntu 16.04, 20.04
GTK3 GUI

This proves to be tougher than it seems at first sight. GtkDialog does not support that kind of option and forcefully packs its buttons into hbox (aka action-area). In Gtk2 Vim does the trick by replacing action-area with a new vbox. This is in src/gui_gtk.c:
    // Check 'v' flag in 'guioptions': vertical button placement.
    if (vim_strchr(p_go, GO_VERTICAL) != NULL)
    {
# if GTK_CHECK_VERSION(3,0,0)
    // Add GTK+ 3 code if necessary.
    // N.B. GTK+ 3 doesn't allow you to access vbox and action_area via
    // the C API.
# else
    GtkWidget   *vbutton_box;

    vbutton_box = gtk_vbutton_box_new();
    gtk_widget_show(vbutton_box);
    gtk_box_pack_end(GTK_BOX(GTK_DIALOG(dialog)->vbox),
                         vbutton_box, TRUE, FALSE, 0);
    // Overrule the "action_area" value, hopefully this works...
    GTK_DIALOG(dialog)->action_area = vbutton_box;
# endif
    }

However, Gtk3 closes this backdoor by hiding action_area inside a private structure (pimpl-alike). So the "vertical" option was never implemented in Gtk3 and it seems there's no easy way to implement it.

So we should then at least add a short comment at options.txt mentioning that GTK3 does not allow this I think.

I'll add a note.  So we close this as "infeasible".

authors: brammool chrisbra inkarkat matveyt


text:
Fix test failure when total time == self time.

From test_profile.vim:
Found errors in Test_profile_file():
function RunTheTest[24]..Test_profile_file line 37: Pattern '^\\s*20\\s\\+\\d\\+\\.\\d\\+\\s\\+\\d\\+\\.\\d\\+\\s\\+call Foo()$' does not match '   20              0.000043   call Foo()'

Codecov Report

Merging #1972 into master will decrease coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1972      +/-   ##
==========================================
- Coverage   74.71%   74.68%   -0.03%
==========================================
  Files          77       77
  Lines      125798   125798
  Branches    28150    28150
==========================================
- Hits        93989    93958      -31
- Misses      31809    31836      +27
- Partials        0        4       +4

Impacted Files
Coverage Δ

src/gui_beval.c
39.93% <0%> (-4.96%)
:arrow_down:

src/window.c
80.86% <0%> (-0.54%)
:arrow_down:

src/if_py_both.h
76.05% <0%> (-0.14%)
:arrow_down:

src/undo.c
81.48% <0%> (-0.07%)
:arrow_down:

src/gui_gtk_x11.c
47.29% <0%> (-0.06%)
:arrow_down:

src/if_xcmdsrv.c
85.18% <0%> (ø)
:arrow_up:

src/evalfunc.c
82.62% <0%> (+0.02%)
:arrow_up:

src/os_unix.c
52.78% <0%> (+0.04%)
:arrow_up:

src/gui.c
45.66% <0%> (+0.05%)
:arrow_up:

src/libvterm/src/screen.c
73.43% <0%> (+0.09%)
:arrow_up:

Continue to review full report at Codecov.

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

authors: codecov-io jamessan


text:
Snackbar link is wrong in readme

Snackbar link points to this link which is for MaterialCircularProgressIndicatorComponent
https://github.com/vinaygaba/Learn-Jetpack-Compose-By-Example/blob/master/app/src/main/java/com/example/jetpackcompose/material/MaterialActivity.kt#L323

Thanks for pointing this out. Yeah it's been a constant battle between adding new code/comments and keeping the README up-to-date. Will update it shortly!

authors: jitinsharma vinaygaba


text:
Default Box Size setting doesn't apply on client restart

Whenever I load RuneLite, my "Default Box Size" setting is correctly set to what I want, but the actual visual size of the box is the default of 25. I have to manually change the setting up and down to 'activate' it again.

Yes you're right. I just fixed it, It should work whenever the update gets pulled


text:
webpack5 issue

Hi, thanks for this great plugin! I've been using this in my apps with NextJS 10 for a while now.
At the time, I set future.webpack5 to false. However, when I switch to true I'm having compile issues. The same goes for Upgrading to NextJS 11 or 12 (which implicitly use webpack5). The error I get relates to getT and useTranslation.
When I stub out those functions, the error goes away, so it definitely appears to happen within those.
Unhandled Runtime Error
TypeError: Cannot read properties of undefined (reading 'default')

@fabien Do you have an example to reproduce the issue? In our example we actually have webpack 5 and it works correctly. Thanks!

@aralroca I managed to solve the issue. I was re-exporting some helper methods as part of a library (index.js) file:
It all worked after changing the code from this:
export { default as getTranslation } from 'next-translate/getT';
export { default as useTranslation } from 'next-translate/useTranslation';

To this:
import getT from 'next-translate/getT';
import useT from 'next-translate/useTranslation';

export const getTranslation = (...args) => getT(...args);
export const useTranslation = (...args) => useT(...args);

authors: aralroca fabien

repo: vinissimus/next-translate


text:
Ayandevelop

Description
I have added the email sign-in process by using google firebase
Fixes # (issue) #194 #5

[x] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] Any dependent changes have been merged and published in downstream modules

Reviewer: Vinit Shahdeo

I have done my PR aginst your review #219 check it

repo: vinitshahdeo/Water-Monitoring-System


text:
Anomalous versions

opauth/opauth                      1.0.x-dev     →     1.0.0-alp

The available version string is getting truncated: the full string is 1.0.0-alpha.1.
league/factory-muffin              2.1.1         →     3.0.0

The available version string implies a stable release, where the actual version string is v3.0.0-RC1. This makes the output less useful, as I have to go to Packagist to confirm whether or not the release is stable.

Yeah, we should exclude RC versions. Thanks for reporting!

This should be fixed in 0.4.0

authors: elazar vinkla

repo: vinkla/climb

license: mit

license_source: bigquery


text:
Laravel 6 support

Hey Vincent!
Thanks for a nice package :)
Will you add Laravel 6 support in near future?

authors: mikkellindblom vinkla

repo: vinkla/laravel-hashids


text:
maven-cache

Noticed we're not caching maven dependencies, also, according to https://docs.travis-ci.com/user/caching/, npm should be cached this way instead of node_modules

will we need to clear the existing cache after this is merged in?

@britneywright don't believe so, we can validate after with the next pr since we can check their logs and if they needed maven dependencies when using masters cache

nuking the cache is a pain though so we should wait to see, remembering that builds took upwards of 40 minutes when we've done it in the past

authors: britneywright nimaeskandary

repo: vinyldns/vinyldns


text:
几个命令编译后都无法执行

编译执行的，难道是我的使用方式或者环境不对吗？白衣大人
vjmap
[root@qa-admin vjmap]# ./vjmap.sh -all 5111
WARNING!! STW(Stop-The-World) will be performed on your Java process, if this is NOT wanted, type 'Ctrl+C' to exit.
sun.jvm.hotspot.runtime.VMVersionMismatchException: Supported versions are 25.111-b14. Target VM is 25.161-b14
[root@qa-admin vjmap]# java -version
java version "1.8.0_111"
Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode)
vjtop
root@qa-admin vjtop]# ./vjtop.sh 5111
六月 20, 2018 5:43:49 下午 com.vip.vjtools.vjtop.VMInfo processNewVM
严重: could not attach (PID=5111)
java.io.IOException: Unable to open socket file: target process not responding or HotSpot VM not loaded
at com.vip.vjtools.vjtop.data.jmx.JmxClient.getConnectorAddress(JmxClient.java:254)
at com.vip.vjtools.vjtop.data.jmx.JmxClient.tryConnect(JmxClient.java:112)
at com.vip.vjtools.vjtop.data.jmx.JmxClient.connect(JmxClient.java:102)
at com.vip.vjtools.vjtop.VMInfo.processNewVM(VMInfo.java:132)
at com.vip.vjtools.vjtop.VMDetailView.(VMDetailView.java:44)
at com.vip.vjtools.vjtop.VJTop.main(VJTop.java:88)
Caused by: com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded
at sun.tools.attach.LinuxVirtualMachine.(LinuxVirtualMachine.java:106)
at sun.tools.attach.LinuxAttachProvider.attachVirtualMachine(LinuxAttachProvider.java:63)
at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:208)
at com.vip.vjtools.vjtop.data.jmx.JmxClient.getConnectorAddress(JmxClient.java:252)
... 5 more
ERROR: Could not attach to process.

你的目标应用JDK是用1.8.0_161在跑，而你执行vjmap的JDK是1.8.0_111

发现问题了，的确是这个原因造成的，谢谢。

我也修改了一下README，强调了大家用同版本的JDK跑：）

repo: vipshop/vjtools


text:
It seems the server doesn't decode utf8 names

Hi! Thanks for maintaining this project.
It seems the go-chromecast httpserver doesn't decode the utf8 names. Is it in purpose or an unreported bug? If that is by design, then how would I decode them in JS?

@walking-octopus is this issues supposed to be closed?

Yes. I accidentally downloaded an older version. Building it from the source fixed it. Sorry for wasting your time.

Ah excellent! No worries at all :)

authors: vishen walking-octopus

repo: vishen/go-chromecast


text:
How do i use this with a Youtube Cast device that isn't a chromecast?

I want to use this with my "smart tv" that has a youtube app and allows casting but isn't a chromecast itself

You should look for something that supports the DIAL (Discovery and Launch) protocol like https://github.com/MarcoLucidi01/ytcast

authors: Bluscream alexballas


text:
eshop-services-products - Creating CD pipeline to deploy to Azure

Project: eshop-services-products
Description:
Creating CD GitHub workflow/pipeline to deploy to Azure

Created and tested

repo: vishipayyallore/eshop-services-products


text:
Fix compile errors

fix issue compile errors #35

@lynch1981 Thank you for submitting this, and I'm very sorry for having taken so long to look into this.
I confirmed the errors you found, and your fixes, and they've now been committed to master.


text:
proxy

Hi!
Please, consider taking care of those who behind proxies ;) Say, https://github.com/dvv/F/blob/master/lib/wget.js
TIA,
--Vladimir

hmmm ... sorry to comment on an old issue, but I have a question, no offense, can't we just respect the environment variable http_proxy but can only rely on another package?

AFAIK node's own http request handling doesn't automagically pick the proxy, and superagent behaving differently could surprising, so an explicit superagent-proxy call seems like an OK solution to me.

authors: PeterDaveHello dvv pornel

repo: visionmedia/superagent


text:
should not retry on 500, 501

The doc says "if they fail in a way that is transient or could be due to a flaky Internet connection".  A response of 500 or 501 is not transient or flaky ... the server is returning that response.  >= 502 should retry.

Since retries are opt-in, I'm going to leave configuring details of them up to #1178.
Retrying of 501 does not make much sense, but 500 does IMO: you may have flaky app severs behind a load-balancer and hit a working app server on the next request.

authors: peebles pornel


text:
Update to latest superagent which has a fixed cookiejar.

This updates to the latest superagent, which includes a cookiejar that addresses some bugs.

I also have encountered bugs in the current version of supertest that really come from the older version of superagent it's using.
+1 for merger!

+1 for updating the superagent dependency. Actually, why does supertest use ~ dependencies? We wouldn't need this kind of PR with ^ dependencies (which means: use latest version with matching major version number – which should guarantee compatibility).

+1 For ^1.0.0.

Any updates?

+1 for superagent v1.7.2

Since this repo seems to be abandoned, we can use one of the forks with updated dependencies, see here and here.

Sorry I have been absent for a while, I'm back and can get this merged in.
Can you also up the version ^1.7.2 for me being pedantic?

Done.

I am excited to back out my horrible postinstall hax. :tada:

authors: andrenarchy andyburke awochna mikelax nschloe zensh

repo: visionmedia/supertest


text:
build_visit pyside build error in docker container

[  9%] Running generator for QtCore...
qt.shiboken: (core) Unable to locate Clang's built-in include directory (neither by checking the environment variables LLVM_INSTALL_DIR, CLANG_INSTALL_DIR  nor running llvm-config). This may lead to parse errors.
(core) clang_parseTranslationUnit2(0x0, cmd[6]=-fPIC -Wno-constant-logical-operand -std=c++14 -I/masonry/build-mb-develop-ci-smoke/thirdparty_shared/pyside-setup-5.14.2/sources/pyside2/PySide2 -I/masonry/build-mb-develop-ci-smoke/thirdparty_shared/third_party/qt/5.14.2/ci/include /tmp/QtCore_global_jFtubQ.hpp)
/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/cstddef:50:10: fatal error: 'stddef.h' file not found
(core) Errors in /tmp/QtCore_global_jFtubQ.hpp:
/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/cstddef:50:10: fatal: 'stddef.h' file not found
   /tmp/QtCore_global_jFtubQ.hpp:1:10: note: in file included from /tmp/QtCore_global_jFtubQ.hpp:1:
   /masonry/build-mb-develop-ci-smoke/thirdparty_shared/pyside-setup-5.14.2-build/sources/pyside2/PySide2/QtCore_global.h:41:10: note: in file included from /masonry/build-mb-develop-ci-smoke/thirdparty_shared/pyside-setup-5.14.2-build/sources/pyside2/PySide2/QtCore_global.h:41:
   /masonry/build-mb-develop-ci-smoke/thirdparty_shared/third_party/qt/5.14.2/ci/include/QtCore/qnamespace.h:43:10: note: in file included from /masonry/build-mb-develop-ci-smoke/thirdparty_shared/third_party/qt/5.14.2/ci/include/QtCore/qnamespace.h:43:
   /masonry/build-mb-develop-ci-smoke/thirdparty_shared/third_party/qt/5.14.2/ci/include/QtCore/qglobal.h:46:12: note: in file included from /masonry/build-mb-develop-ci-smoke/thirdparty_shared/third_party/qt/5.14.2/ci/include/QtCore/qglobal.h:46:

(core) Clang: 1 diagnostic messages:
  /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/cstddef:50:10: fatal: 'stddef.h' file not found
   /tmp/QtCore_global_jFtubQ.hpp:1:10: note: in file included from /tmp/QtCore_global_jFtubQ.hpp:1:
   /masonry/build-mb-develop-ci-smoke/thirdparty_shared/pyside-setup-5.14.2-build/sources/pyside2/PySide2/QtCore_global.h:41:10: note: in file included from /masonry/build-mb-develop-ci-smoke/thirdparty_shared/pyside-setup-5.14.2-build/sources/pyside2/PySide2/QtCore_global.h:41:
   /masonry/build-mb-develop-ci-smoke/thirdparty_shared/third_party/qt/5.14.2/ci/include/QtCore/qnamespace.h:43:10: note: in file included from /masonry/build-mb-develop-ci-smoke/thirdparty_shared/third_party/qt/5.14.2/ci/include/QtCore/qnamespace.h:43:
   /masonry/build-mb-develop-ci-smoke/thirdparty_shared/third_party/qt/5.14.2/ci/include/QtCore/qglobal.h:46:12: note: in file included from /masonry/build-mb-develop-ci-smoke/thirdparty_shared/third_party/qt/5.14.2/ci/include/QtCore/qglobal.h:46:

Keeping temporary file: /tmp/QtCore_global_jFtubQ.hpp
shiboken: Error running ApiExtractor.
Command line: --generator-set=shiboken --enable-parent-ctor-heuristic --enable-pyside-extensions --enable-return-value-heuristic --use-isnull-as-nb_nonzero /masonry/build-mb-develop-ci-smoke/thirdparty_shared/pyside-setup-5.14.2-build/sources/pyside2/PySide2/QtCore_global.h --include-paths=/masonry/build-mb-develop-ci-smoke/thirdparty_shared/pyside-setup-5.14.2/sources/pyside2/PySide2:/masonry/build-mb-develop-ci-smoke/thirdparty_shared/third_party/qt/5.14.2/ci/include/ --typesystem-paths=/masonry/build-mb-develop-ci-smoke/thirdparty_shared/pyside-setup-5.14.2-build/sources/pyside2/PySide2:/masonry/build-mb-develop-ci-smoke/thirdparty_shared/pyside-setup-5.14.2/sources/pyside2/PySide2:/masonry/build-mb-develop-ci-smoke/thirdparty_shared/pyside-setup-5.14.2/sources/pyside2/PySide2/QtCore --output-directory=/masonry/build-mb-develop-ci-smoke/thirdparty_shared/pyside-setup-5.14.2-build/sources/pyside2/PySide2/QtCore --license-file=/masonry/build-mb-develop-ci-smoke/thirdparty_shared/pyside-setup-5.14.2/sources/pyside2/PySide2/QtCore/../licensecomment.txt /masonry/build-mb-develop-ci-smoke/thirdparty_shared/pyside-setup-5.14.2-build/sources/pyside2/PySide2/QtCore/typesystem_core.xml --api-version=5.14 --drop-type-entries=
sources/pyside2/PySide2/QtCore/CMakeFiles/QtCore_generator.dir/build.make:67: recipe for target 'sources/pyside2/PySide2/QtCore/mjb_rejected_classes.log' failed
make[2]: *** [sources/pyside2/PySide2/QtCore/mjb_rejected_classes.log] Error 1
CMakeFiles/Makefile2:771: recipe for target 'sources/pyside2/PySide2/QtCore/CMakeFiles/QtCore_generator.dir/all' failed
make[1]: *** [sources/pyside2/PySide2/QtCore/CMakeFiles/QtCore_generator.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2

cmake configure:
"/masonry/build-mb-develop-ci-smoke/thirdparty_shared/third_party/cmake/3.14.7/ci/bin/cmake"
-DCMAKE_PREFIX_PATH:PATH=/masonry/build-mb-develop-ci-smoke/thirdparty_shared/third_party/qt/5.14.2/ci/lib/cmake/
-DPYTHON_EXECUTABLE:FILEPATH=/masonry/build-mb-develop-ci-smoke/thirdparty_shared/third_party/python/3.7.7/ci/bin/python3
-DCMAKE_C_COMPILER:STRING=gcc
-DCMAKE_CXX_COMPILER:STRING=g++
-DCMAKE_C_FLAGS:STRING=" -m64 -fPIC -O2"
-DCMAKE_CXX_FLAGS:STRING="-std=c++11 -m64 -fPIC -O2"
-DCMAKE_SKIP_BUILD_RPATH:BOOL=false
-DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=false
-DCMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOL=true
-DCMAKE_BUILD_TYPE:STRING="Release"
-DBUILD_TESTS:BOOL=FALSE -DCMAKE_INSTALL_PREFIX:PATH="/masonry/build-mb-develop-ci-smoke/thirdparty_shared/third_party/pyside/5.14.2/ci/"
-DCMAKE_INSTALL_RPATH:FILEPATH="/masonry/build-mb-develop-ci-smoke/thirdparty_shared/third_party/pyside/5.14.2/ci//lib"
-DCMAKE_INSTALL_NAME_DIR:FILEPATH="/masonry/build-mb-develop-ci-smoke/thirdparty_shared/third_party/pyside/5.14.2/ci//lib"
-DGL_H=/masonry/build-mb-develop-ci-smoke/thirdparty_shared/third_party/mesagl/17.3.9/ci/include/GL/gl.h
../pyside-setup-5.14.2

Possible solution: We need to pass llvm details at cmake configure time?

Looks like we are passing those. Ugh, I guess we have to set those env vars when trying to debug (their cmake setup doesn't handle this?)

The commented out section is for building pyside as a python module (eg it gets installed in Python's site-packages).
I experienced LD_LIBRARY_PATH issues with that installation route, hence that section is commented out.
bv_llvm.sh should be exporting the necessary LLVM_INSTALL_DIR/CLANG_INSTALL_DIR.

thanks for the context -- i'll dive deeper tomorrow!

found the issue, it's a linking issue related to there being no system gl.
I'll try to resolve soon

@biagas  I have been spelunking around in pyside, looking for a possible way to inject the proper GL libs.
I see the GL_H which we are using, but I am not really sure how that is leveraged?
Do we need to provide details to supplement FindQt5?

When I ran build_visit with llvm, mesa, qt, python, pyside This was populated in the CMakeCache.txt for Pyside:
//Path to a library.
_Qt5UiTools_RELEASE_GL_PATH:FILEPATH=/usr/WS1/visit/visit/thirdparty_shared/3.2.0-pyside2/toss3/mesagl/17.3.9/linux-x86_64_gcc-6.1/lib/libGL.
Also, I took a look in the pyside build dir:
sources/pyside2/PySide2/QtUiTools/CMakeFiles/QtUiTools.dir/link.txt
According to the contents of this file, its linking with mesa's libGL.so.
Did you build QT with mesa?

It looks like it's in there:
//Path to a library.
_Qt5UiTools_RELEASE_GL_PATH:FILEPATH=/masonry/build-mb-develop-ci-smoke/thirdparty_shared/third_party/mesagl/17.3.9/ci/lib/libGL.so

QtUITools has it, but the GL dep that is causing an error is actually in libQt5Gui.
Whats challenging: It could be an issue with CMake's FindQt, it could be an issue with how CMake was configued, it could be an issue with how pyside is calling FindQt.

I guess I could set LD_LIB path when building?

Trying LD_ LIB_PATH ....

Am I understanding correctly, that the container doesn't have a system-gl and pyside isn't linking correctly?
Do you think that means it actually linked with system-gl on the lc systems where I compiled it, instead of mesa-gl?

That seems to be the case. During some of the build process, it does things like import the python modules - which will dynamically load GL.
If QT was built with an RPATH to the right GL, that might solve the issue.
The LD_LIB_PATH fix worked for building in the container with no system GL.
I am adding a case that sets LD_LIB_PATH when mesa is on.

resolved in #5449

authors: biagas cyrush

repo: visit-dav/visit


text:
Rendeding labels for DOT graphs on playground does not work

I am making few tests using the playground for DOT language.
All works, but how about this example for data structures coming directly from GraphVIZ?
I would expect it works, but in fact it does not work.
There's probably an issue with the example itself, as the node should be ellipse which I think can't render with fields, but removing it, I get nothing.
So I am wondering if the library supports the concept of fields in a node, either directly or as part of DOT language. I would expect to be supported with DOT language, but seems not.

All works, but how about this example for data structures coming directly from GraphVIZ?

It's because that example uses Graphviz HTML-Like Labels, which Vis.js is apparently known to not support - see #505. Perhaps you would like to close this issue as a duplicate of that?

authors: LunaticMuch vorburger

repo: visjs/vis-network


text:
Minor alignment issue on interactive filters

Describe the bug
There's a minor alignment issue for interactive filters when adding more than two, potentially related to whether the filter titles have capital letters (see video). Tested against current deployment on INT (v3.22.7).
Expected behavior
Filter dropdowns are aligned horizontally.
https://github.com/visualize-admin/visualization-tool/assets/6533245/4e226fba-f739-4fda-b992-0a2353ce7613

@bprusinowski i tested this with the following chart https://int.visualize.admin.ch/en/v/cW5M0Qj8roKO?dataSource=Prod and it seems there is still some misalignment (also in the published chart)

Hi @sosiology, the fix is currently available on TEST – let me know if I should deploy the changes to INT. I thought I'll wait with the deployment until it's "approved" on TEST 😅

Sorry about that @bprusinowski on test it looks wonderful 🎉
https://test.visualize.admin.ch/en/v/OktUL-a8JEGs?dataSource=Prod

authors: adintegra bprusinowski sosiology

repo: visualize-admin/visualization-tool


text:
require('@/assets/images'+module.icon)转换结果缺少换行符

环境：
vite: 5.4.0;
vue: 2.7;
@vitejs/plugin-vue2: 2.3.1;
vite-plugin-commonjs: 0.10.1
代码：
<el-badge :value="myTaskCounts" class="badgeItem" type="danger" v-if="module.id == 0">
<img :src="require('@/assets/images'+module.icon)" alt="Module Icon">
</el-badge>
报错：
vite v5.4.0 building for production...
✓ 7 modules transformed.
x Build failed in 2.50s
error during build:
[commonjs--resolver] Expected ';', got 'matchRequireRuntime0' in D:/ideaWork/svn/打包工具替换/ruoyi-ui/src/views/myapp.vue
file: D:/ideaWork/svn/打包工具替换/ruoyi-ui/src/views/myapp.vue:138:45
136:   null
137: )
138: export default component.exportsfunction matchRequireRuntime0(path) {
^
139:   switch(path) {
vite-plugin-commonjs转换前：
xxxx
export default component.exports
vite-plugin-commonjs转换后：
xxxx
export default component.exportsfunction
matchRequireRuntime0(path)
{
switch (path) {
xxxx

提供一个完整复现的可运行的 Demo

authors: touch-xzc yejimeiming

repo: vite-plugin/vite-plugin-commonjs


text:
[Vue3] build + watch + sourcemap cause rollup conflicting error

Describe the bug

Enable sourcemap support in Vite config:

build: {
  sourcemap: true,
}

Run build command in watch mode: vite build --watch
Change any contents in <template> of App.vue
Got Rollup Error: Multiple conflicting contents for sourcemap source /home/projects/vitejs-vite-4gfbyh/src/App.vue

Every build when rollup calls addModuleSource method to process modules, it will figure out should use cache or not:
https://github.com/rollup/rollup/blob/27c0557f904321d649c9bd85f6fb670ca5700427/src/ModuleLoader.ts#L271-L275
During the second build which caused by the change of vue <template>, module /some_paths/index.vue?vue&type=script&lang.ts comes in addModuleSource method.But cachedModule.originalCode === sourceDescription.code is true this time, so rollup uses the cached version of this vue script module.
Finally, sourcemap source of module /some_paths/index.vue?vue&type=script&lang.ts is old template + old script, while sourcemap source of module /some_paths/index.vue is new template + old script.Becasue they all have the same source
filename but having different source contents, thus the error comes from traceMappings method of rollup:
https://github.com/rollup/rollup/blob/69ff4181e701a0fe0026d0ba147f31bc86beffa8/src/utils/collapseSourcemaps.ts#L87-L89
Reproduction
https://stackblitz.com/edit/vitejs-vite-4gfbyh?file=vite.config.js
System Info
System:
    OS: Linux 5.0 undefined
    CPU: (4) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes
    Shell: 1.0 - /bin/jsh

Binaries:
    Node: 16.14.2 - /usr/local/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 7.17.0 - /usr/local/bin/npm

npmPackages:
    @vitejs/plugin-vue: ^3.1.0 => 3.1.0
    vite: ^3.1.3 => 3.1.3

Used Package Manager
pnpm
Logs

Click to expand!
~/projects/vitejs-vite-4gfbyh 40s
❯ npm run build:watch
$ vite build --watch --debug
  vite:config bundled config file loaded in 1193.20ms +0ms
  vite:esbuild init tsconfck (root: /home/projects/vitejs-vite-4gfbyh) +0ms
  vite:esbuild init tsconfck (root: /home/projects/vitejs-vite-4gfbyh) +1ms
  vite:esbuild init tsconfck (root: /home/projects/vitejs-vite-4gfbyh) +1ms
  vite:esbuild init tsconfck (root: /home/projects/vitejs-vite-4gfbyh) +0ms
  vite:esbuild init tsconfck end +2ms
  vite:esbuild init tsconfck end +0ms
  vite:esbuild init tsconfck end +0ms
  vite:esbuild init tsconfck end +0ms
  vite:config using resolved config: {
  vite:config   plugins: [
  vite:config     'vite:ensure-watch',
  vite:config     'vite:build-metadata',
  vite:config     'vite:pre-alias',
  vite:config     'alias',
  vite:config     'vite:modulepreload-polyfill',
  vite:config     'vite:resolve',
  vite:config     'vite:html-inline-proxy',
  vite:config     'vite:css',
  vite:config     'vite:esbuild',
  vite:config     'vite:json',
  vite:config     'vite:wasm-helper',
  vite:config     'vite:worker',
  vite:config     'vite:asset',
  vite:config     'vite:vue',
  vite:config     'vite:wasm-fallback',
  vite:config     'vite:define',
  vite:config     'vite:css-post',
  vite:config     'vite:build-html',
  vite:config     'vite:worker-import-meta-url',
  vite:config     'vite:force-systemjs-wrap-complete',
  vite:config     'vite:ensure-watch',
  vite:config     'vite:watch-package-data',
  vite:config     'commonjs',
  vite:config     'vite:data-uri',
  vite:config     'vite:asset-import-meta-url',
  vite:config     'vite:dynamic-import-vars',
  vite:config     'vite:import-glob',
  vite:config     'vite:build-import-analysis',
  vite:config     'vite:esbuild-transpile',
  vite:config     'vite:terser',
  vite:config     'vite:reporter',
  vite:config     'vite:load-fallback'
  vite:config   ],
  vite:config   build: {
  vite:config     target: [ 'es2020', 'edge88', 'firefox78', 'chrome87', 'safari13' ],
  vite:config     polyfillModulePreload: true,
  vite:config     outDir: 'dist',
  vite:config     assetsDir: 'assets',
  vite:config     assetsInlineLimit: 4096,
  vite:config     cssCodeSplit: true,
  vite:config     cssTarget: [ 'es2020', 'edge88', 'firefox78', 'chrome87', 'safari13' ],
  vite:config     sourcemap: true,
  vite:config     rollupOptions: {},
  vite:config     minify: 'esbuild',
  vite:config     terserOptions: {},
  vite:config     write: true,
  vite:config     emptyOutDir: null,
  vite:config     manifest: false,
  vite:config     lib: false,
  vite:config     ssr: false,
  vite:config     ssrManifest: false,
  vite:config     reportCompressedSize: true,
  vite:config     chunkSizeWarningLimit: 500,
  vite:config     watch: true,
  vite:config     w: true,
  vite:config     commonjsOptions: { include: [Array], extensions: [Array] },
  vite:config     dynamicImportVarsOptions: { warnOnError: true, exclude: [Array] }
  vite:config   },
  vite:config   optimizeDeps: {
  vite:config     disabled: 'build',
  vite:config     force: undefined,
  vite:config     esbuildOptions: { preserveSymlinks: undefined }
  vite:config   },
  vite:config   define: { __VUE_OPTIONS_API__: true, __VUE_PROD_DEVTOOLS__: false },
  vite:config   ssr: {
  vite:config     format: 'esm',
  vite:config     target: 'node',
  vite:config     external: [],
  vite:config     optimizeDeps: { disabled: true, esbuildOptions: [Object] }
  vite:config   },
  vite:config   configFile: '/home/projects/vitejs-vite-4gfbyh/vite.config.js',
  vite:config   configFileDependencies: [ '/home/projects/vitejs-vite-4gfbyh/vite.config.js' ],
  vite:config   inlineConfig: {
  vite:config     root: undefined,
  vite:config     base: undefined,
  vite:config     mode: undefined,
  vite:config     configFile: undefined,
  vite:config     logLevel: undefined,
  vite:config     clearScreen: undefined,
  vite:config     optimizeDeps: { force: undefined },
  vite:config     build: { watch: true, w: true }
  vite:config   },
  vite:config   root: '/home/projects/vitejs-vite-4gfbyh',
  vite:config   base: '/',
  vite:config   resolve: { alias: [ [Object], [Object] ] },
  vite:config   publicDir: '/home/projects/vitejs-vite-4gfbyh/public',
  vite:config   cacheDir: '/home/projects/vitejs-vite-4gfbyh/node_modules/.vite',
  vite:config   command: 'build',
  vite:config   mode: 'production',
  vite:config   isWorker: false,
  vite:config   mainConfig: null,
  vite:config   isProduction: true,
  vite:config   server: {
  vite:config     preTransformRequests: true,
  vite:config     middlewareMode: false,
  vite:config     fs: { strict: true, allow: [Array], deny: [Array] }
  vite:config   },
  vite:config   preview: {
  vite:config     port: undefined,
  vite:config     strictPort: undefined,
  vite:config     host: undefined,
  vite:config     https: undefined,
  vite:config     open: undefined,
  vite:config     proxy: undefined,
  vite:config     cors: undefined,
  vite:config     headers: undefined
  vite:config   },
  vite:config   env: { BASE_URL: '/', MODE: 'production', DEV: false, PROD: true },
  vite:config   assetsInclude: [Function: assetsInclude],
  vite:config   logger: {
  vite:config     hasWarned: false,
  vite:config     info: [Function: info],
  vite:config     warn: [Function: warn],
  vite:config     warnOnce: [Function: warnOnce],
  vite:config     error: [Function: error],
  vite:config     clearScreen: [Function: clearScreen],
  vite:config     hasErrorLogged: [Function: hasErrorLogged]
  vite:config   },
  vite:config   packageCache: Map(0) { set: [Function (anonymous)] },
  vite:config   createResolver: [Function: createResolver],
  vite:config   worker: {
  vite:config     format: 'iife',
  vite:config     plugins: [
  vite:config       'vite:ensure-watch',
  vite:config       'vite:build-metadata',
  vite:config       'vite:pre-alias',
  vite:config       'alias',
  vite:config       'vite:modulepreload-polyfill',
  vite:config       'vite:resolve',
  vite:config       'vite:html-inline-proxy',
  vite:config       'vite:css',
  vite:config       'vite:esbuild',
  vite:config       'vite:json',
  vite:config       'vite:wasm-helper',
  vite:config       'vite:worker',
  vite:config       'vite:asset',
  vite:config       'vite:wasm-fallback',
  vite:config       'vite:define',
  vite:config       'vite:css-post',
  vite:config       'vite:build-html',
  vite:config       'vite:worker-import-meta-url',
  vite:config       'vite:force-systemjs-wrap-complete',
  vite:config       'vite:ensure-watch',
  vite:config       'vite:watch-package-data',
  vite:config       'commonjs',
  vite:config       'vite:data-uri',
  vite:config       'vite:asset-import-meta-url',
  vite:config       'vite:dynamic-import-vars',
  vite:config       'vite:import-glob',
  vite:config       'vite:build-import-analysis',
  vite:config       'vite:esbuild-transpile',
  vite:config       'vite:terser',
  vite:config       'vite:reporter',
  vite:config       'vite:load-fallback'
  vite:config     ],
  vite:config     rollupOptions: {},
  vite:config     getSortedPlugins: [Function: getSortedPlugins],
  vite:config     getSortedPluginHooks: [Function: getSortedPluginHooks]
  vite:config   },
  vite:config   appType: 'spa',
  vite:config   experimental: { importGlobRestoreExtension: false, hmrPartialAccept: false },
  vite:config   getSortedPlugins: [Function: getSortedPlugins],
  vite:config   getSortedPluginHooks: [Function: getSortedPluginHooks]
  vite:config } +10ms
vite v3.1.3 building for production...

watching for file changes...

build started...
✓ 12 modules transformed.
dist/index.html                  0.44 KiB
dist/assets/index.c16bd851.css   1.01 KiB / gzip: 0.54 KiB
dist/assets/index.6b8e1b06.js    51.67 KiB / gzip: 20.79 KiB
dist/assets/index.6b8e1b06.js.map 570.62 KiB
built in 1538ms.

build started...
✓ 13 modules transformed.
rendering chunks (1)...Multiple conflicting contents for sourcemap source /home/projects/vitejs-vite-4gfbyh/src/App.vue

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.

Same here :(

Facing the same issue as described in the report.

@Chen-jj I found a workaround for this - just use. <script setup> notation of the component - it should work

authors: Chen-jj i-platonov marfous obrejla

repo: vitejs/vite


text:
The problem with the order in mongoose

Describe the bug
After the build, the order of some parts of the mongoose changes, which leads to errors at run.
Also see https://github.com/Automattic/mongoose/issues/12335#issuecomment-1299427402.
Most likely the problem is in Vite.
Reproduction
https://stackblitz.com/edit/sveltejs-kit-template-default-jysxco?file=src/hooks.server.js
Steps to reproduce
Run npm i && npm run build && node build/index.js
System Info
any

Used Package Manager
npm
Logs
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 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.

The output is not generated by Vite directly.
The output from Vite is bundled again by svelte-kit.
https://github.com/sveltejs/kit/blob/master/packages/adapter-node/index.js#L55-L68
Also there's many warning about circular dependency around mongoose from rollup.
Closing as this cannot be fixed in Vite. This needs to be reported to svelte kit or rollup.

BTW I guess moving mongoose from devDependencies to dependencies will work.

👍

authors: AlexRMU sapphi-red


text:
build succeed , but run failed with bug   cannot access  "_export_sfc"

Describe the bug
it is ok at dev server , and build succeed .  but  when run the built  files at browser
error  came .
here is  the error   flow
Uncaught ReferenceError: Cannot access '_export_sfc' before initialization
at KIcon.vue:4:33
and the built code is below
const KIcon=_export_sfc(_sfc_main$w,[["render",_sfc_render$h],["__scopeId","data-v-d325524f"]])
Reproduction
none
Steps to reproduce
npm install
System Info
64 win 11

Used Package Manager
npm
Logs
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 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.

@daaku @kamui


text:
The combination of specific statements and comments can cause errors (vite & vite build)

Describe the bug
In a *.vue file with certain statements and comments, a strange error will appear after running yarn dev(vite) and previewing the page in the browser:
<template>

Foobar

</template>

[vite] Internal server error: Element is missing end tag.
  Plugin: vite:vue
  File: /private/tmp/foobar/src/App.vue
  3  |  </template>
  4  |
  5  |

authors: sodatea zaakn


text:
Top-level await is not supported by ssrLoadModule

Describe the bug
If a module uses top-level await, attempting to load it with ssrLoadModule results in an error.

Stack trace
4:03:16 PM [vite] Error when evaluating SSR module src/index.js:
SyntaxError: Cannot use keyword 'await' outside an async function (2:0)
    at Object.pp$5.raise (/path/to/vite-top-level-await-repro/node_modules/vite/dist/node/chunks/dep-36bf480c.js:47485:13)
    at Object.pp$4.checkUnreserved (/path/to/vite-top-level-await-repro/node_modules/vite/dist/node/chunks/dep-36bf480c.js:47391:14)
    at Object.pp$4.parseIdent (/path/to/vite-top-level-await-repro/node_modules/vite/dist/node/chunks/dep-36bf480c.js:47421:10)
    at Object.parseIdent (/path/to/vite-top-level-await-repro/node_modules/vite/dist/node/chunks/dep-36bf480c.js:49866:27)
    at Object.parseIdent (/path/to/vite-top-level-await-repro/node_modules/vite/dist/node/chunks/dep-36bf480c.js:49948:27)
    at Object.pp$4.parseExprAtom (/path/to/vite-top-level-await-repro/node_modules/vite/dist/node/chunks/dep-36bf480c.js:46784:19)
    at Object.pp$4.parseExprSubscripts (/path/to/vite-top-level-await-repro/node_modules/vite/dist/node/chunks/dep-36bf480c.js:46652:19)
    at Object.pp$4.parseMaybeUnary (/path/to/vite-top-level-await-repro/node_modules/vite/dist/node/chunks/dep-36bf480c.js:46618:17)
    at Object.parseMaybeUnary (/path/to/vite-top-level-await-repro/node_modules/vite/dist/node/chunks/dep-36bf480c.js:49793:29)
    at Object.pp$4.parseExprOps (/path/to/vite-top-level-await-repro/node_modules/vite/dist/node/chunks/dep-36bf480c.js:46551:19)
node:internal/process/esm_loader:74
    internalBinding('errors').triggerUncaughtException(
                              ^

SyntaxError: Cannot use keyword 'await' outside an async function (2:0)
    at Object.pp$5.raise (/path/to/vite-top-level-await-repro/node_modules/vite/dist/node/chunks/dep-36bf480c.js:47485:13)
    at Object.pp$4.checkUnreserved (/path/to/vite-top-level-await-repro/node_modules/vite/dist/node/chunks/dep-36bf480c.js:47391:14)
    at Object.pp$4.parseIdent (/path/to/vite-top-level-await-repro/node_modules/vite/dist/node/chunks/dep-36bf480c.js:47421:10)
    at Object.parseIdent (/path/to/vite-top-level-await-repro/node_modules/vite/dist/node/chunks/dep-36bf480c.js:49866:27)
    at Object.parseIdent (/path/to/vite-top-level-await-repro/node_modules/vite/dist/node/chunks/dep-36bf480c.js:49948:27)
    at Object.pp$4.parseExprAtom (/path/to/vite-top-level-await-repro/node_modules/vite/dist/node/chunks/dep-36bf480c.js:46784:19)
    at Object.pp$4.parseExprSubscripts (/path/to/vite-top-level-await-repro/node_modules/vite/dist/node/chunks/dep-36bf480c.js:46652:19)
    at Object.pp$4.parseMaybeUnary (/path/to/vite-top-level-await-repro/node_modules/vite/dist/node/chunks/dep-36bf480c.js:46618:17)
    at Object.parseMaybeUnary (/path/to/vite-top-level-await-repro/node_modules/vite/dist/node/chunks/dep-36bf480c.js:49793:29)
    at Object.pp$4.parseExprOps (/path/to/vite-top-level-await-repro/node_modules/vite/dist/node/chunks/dep-36bf480c.js:46551:19) {
  pos: 43,
  loc: Position { line: 2, column: 0 },
  raisedAt: 52
}

As an aside, npx vite build in the provided repro fails because the esbuild: false config option isn't being respected for some reason. That's unrelated to this issue but I figured I'd mention it in case there's a user error that's obvious to people who aren't me.
Reproduction
https://github.com/Rich-Harris/vite-top-level-await-repro
System Info
System:
    OS: macOS 10.15.7
    CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
    Memory: 5.66 GB / 64.00 GB
    Shell: 5.7.1 - /bin/zsh
  Binaries:
    Node: 16.5.0 - ~/.nvm/versions/node/v16.5.0/bin/node
    Yarn: 1.22.5 - /usr/local/bin/yarn
    npm: 7.19.1 - ~/.nvm/versions/node/v16.5.0/bin/npm
  Browsers:
    Chrome: 93.0.4577.82
    Firefox: 92.0
    Safari: 14.1.2
  npmPackages:
    vite: ^2.5.2 => 2.5.10

Used Package Manager
npm
Logs
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 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 https://github.com/vuejs/vue-next 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.

Vite uses acorn as a JavaScript parser to parse the transformed source code:
https://github.com/vitejs/vite/blob/2fb2561e0b8744d877b46caefb9d07fb2efc587b/packages/vite/src/node/server/pluginContainer.ts#L114-L117
https://github.com/vitejs/vite/blob/2fb2561e0b8744d877b46caefb9d07fb2efc587b/packages/vite/src/node/ssr/ssrTransform.ts#L34-L38
According to the document of acorn:

allowAwaitOutsideFunction: If false, await expressions can only appear inside async functions. Defaults to true for ecmaVersion 2022 and later, false for lower versions. Setting this option to true allows to have top-level await expressions. They are still not allowed in non-async functions, though.

So we can modify the vite's source code of the parser options to ecmaVersion: 2022 or allowAwaitOutsideFunction: true to take effect the code of data.js.
Waiting for core members to respond :eyes:.

We can bump it to 2022, it is the same reason for the latest commit from Evan that modified that field https://github.com/vitejs/vite/commit/407ce3b7c5c07a51b5e20e97bc2fff2f173c74c0. Would you send that PR @ygj6?

We can bump it to 2022, it is the same reason for the latest commit from Evan that modified that field 407ce3b. Would you send that PR @ygj6?

OK, I will do it soon.

thanks for such a speedy diagnosis and fix!

authors: Rich-Harris patak-js ygj6


text:
perf(build): parallelize building process

Description

Additional context

What is the purpose of this pull request?

[ ] Bug fix
[ ] New Feature
[ ] Documentation update
[ ] Other
[X] Perf

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

[ ] Read the Contributing Guidelines.
[ ] Read the Pull Request Guidelines and follow the PR Title Convention.
[ ] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
[ ] 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.

This seems like a breaking change as shown by the CI, but I'm also curious if you have benchmarks of the perf improvements? Running write/generate in parallel could be risky as it'll write to the fs more at once, or have higher memory pressure running the code.

This seems like a breaking change as shown by the CI, but I'm also curious if you have benchmarks of the perf improvements? Running write/generate in parallel(并行) could be risky as it'll write to the fs more at once, or have higher memory pressure running the code.
I git it,  revert to a type fix

authors: bluwy shengxinjing


text:
docs: Module dns has no default export

Signed-off-by: Sepush sepush@outlook.com
Module dns has no default export

Description

Additional context

What is the purpose of this pull request?

[ ] Bug fix
[ ] New Feature
[x] 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 Commit 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).
[x] Ideally, include relevant tests that fail without this PR but pass with it.

I don't think this is needed as all templates have tsconfig.node.json with allowSyntheticDefaultImports: true by default. And it's more common to import this way for nodejs modules.

I don't think this is needed as all templates have tsconfig.node.json with allowSyntheticDefaultImports: true by default. And it's more common to import this way for nodejs modules.

allowSyntheticDefaultImports default value is
true if module is system, or esModuleInterop and module is not es6/es2015 or esnext,false otherwise.
sometimes confuse.

The docs seems to be outdated. IIUC the default value is true if module is system, or esModuleInterop.
main: https://github.com/microsoft/TypeScript/blob/481357a4c83206591091b9b88016e208e3959fce/src/compiler/utilities.ts#L6433-L6439
v4.4.4: https://github.com/microsoft/TypeScript/blob/01de6ff2ecdc6175727f7f999b887519d40ca115/src/compiler/utilities.ts#L6121-L6127

authors: Sepush bluwy sapphi-red


text:
Coverage Reports 0 for a Vue Component with No Functions

Describe the bug
I have a UI component that has no functions in it but vitest run --coverage reports 0% coverage for functions.
If there are no functions to test, the coverage reporter should report 100%
 % Coverage report from v8
---------------------|---------|----------|---------|---------|-------------------
File                 | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
---------------------|---------|----------|---------|---------|-------------------
All files            |     100 |      100 |      80 |     100 |
 components          |     100 |      100 |   66.66 |     100 |
  BasicButton.vue    |     100 |      100 |     100 |     100 |
  ...omButtonNav.vue |     100 |      100 |       0 |     100 |
 store               |     100 |      100 |     100 |     100 |
  index.ts           |     100 |      100 |     100 |     100 |
---------------------|---------|----------|---------|---------|-------------------

Reproduction
BottomButtonNav.vue
<template>

      <slot name="leftSide"></slot>

      <slot name="rightSide"></slot>

</template>

BottomButtonNav.test.ts
import { render, screen } from '@testing-library/vue';
import BottomButtonNav from '~/components/BottomButtonNav.vue';

describe('BottomButtonNav', () => {
  it('renders left and right slots correctly', () => {
    const leftSlotContent = 'Left Slot Content';
    const rightSlotContent = 'Right Slot Content';

    render(BottomButtonNav, {
      slots: {
        leftSide: leftSlotContent,
        rightSide: rightSlotContent,
      },
    });

    const leftContainer = screen.getByTestId('left-container');
    const rightContainer = screen.getByTestId('right-container');

    expect(leftContainer).toHaveTextContent(leftSlotContent);
    expect(rightContainer).toHaveTextContent(rightSlotContent);
  });
});

System Info
System:
    OS: macOS 13.4
    CPU: (12) x64 Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
    Memory: 472.32 MB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.6.0 - ~/.nvm/versions/node/v18.6.0/bin/node
    npm: 8.14.0 - /usr/local/bin/npm
    Watchman: 4.9.0 - /usr/local/bin/watchman
  Browsers:
    Chrome: 114.0.5735.133
    Edge: 114.0.1823.51
    Firefox: 114.0.1
    Safari: 16.5
  npmPackages:
    @vitejs/plugin-vue: ^4.0.0 => 4.2.3
    @vitest/coverage-v8: ^0.32.0 => 0.32.0
    vite: ^4.2.1 => 4.3.9
    vitest: ^0.32.0 => 0.32.0

### Used Package Manager

npm

### Validations

- [X] Follow our [Code of Conduct](https://github.com/vitest-dev/vitest/blob/main/CODE_OF_CONDUCT.md)
- [X] Read the [Contributing Guidelines](https://github.com/vitest-dev/vitest/blob/main/CONTRIBUTING.md).
- [X] Read the [docs](https://vitest.dev/guide/).
- [X] Check that there isn't [already an issue](https://github.com/vitest-dev/vitest/issues) that reports the same bug to avoid creating a duplicate.
- [X] Check that this is a concrete bug. For Q&A open a [GitHub Discussion](https://github.com/vitest-dev/vitest/discussions) or join our [Discord Chat Server](https://chat.vitest.dev).
- [X] The provided reproduction is a [minimal reproducible example](https://stackoverflow.com/help/minimal-reproducible-example) of the bug.

@AriPerkkio  Here's a minimal reproduction repo with PR
https://github.com/merlinstardust/coverage-zero-vitest-example/pull/1

Vue compiler is outputting source maps which are off by one line. This is similar as https://github.com/vitest-dev/vitest/discussions/2874 and https://github.com/vuejs/vue-loader/issues/1778.
Here is what Vue is generating from BottomButtonNav.vue:
const _sfc_main = {}
import { renderSlot as _renderSlot, createElementVNode as _createElementVNode, openBlock as _openBlock, createElementBlock as _createElementBlock, pushScopeId as _pushScopeId, popScopeId as _popScopeId } from "vue"

const _withScopeId = n => (_pushScopeId("data-v-3da707db"),n=n(),_popScopeId(),n)
const _hoisted_1 = { class: "row bottom-button-nav" }
const _hoisted_2 = {
  class: "row left-container",
  "data-testid": "left-container"
}
const _hoisted_3 = {
  class: "row right-container",
  "data-testid": "right-container"
}

function _sfc_render(_ctx, _cache) {
  return (_openBlock(), _createElementBlock("div", _hoisted_1, [
    _createElementVNode("div", _hoisted_2, [
      _renderSlot(_ctx.$slots, "leftSide", {}, undefined, true)
    ]),
    _createElementVNode("div", _hoisted_3, [
      _renderSlot(_ctx.$slots, "rightSide", {}, undefined, true)
    ])
  ]))
}

import "/x/y/coverage-zero-vitest-example/src/components/BottomButtonNav.vue?vue&type=style&index=0&scoped=3da707db&lang.css"

import _export_sfc from 'plugin-vue:export-helper'
export default /*#__PURE__*/_export_sfc(_sfc_main, [['render',_sfc_render],['__scopeId',"data-v-3da707db"],['__file',"/x/y/coverage-zero-vitest-example/src/components/BottomButtonNav.vue"]])

{
  "version": 3,
  "sources": [
    "/x/y/coverage-zero-vitest-example/src/components/BottomButtonNav.vue"
  ],
  "names": [],
  "mappings": ";;;qBACO,KAAK,EAAC,uBAAuB;;EAC3B,KAAK,EAAC,oBAAoB;EAAC,aAAW,EAAC,gBAAgB;;;EAGvD,KAAK,EAAC,qBAAqB;EAAC,aAAW,EAAC,iBAAiB;;;;wBAJhE,oBAOM,OAPN,UAOM;IANJ,oBAEM,OAFN,UAEM;MADJ,YAA6B;;IAE/B,oBAEM,OAFN,UAEM;MADJ,YAA8B",
  "file": "/x/y/coverage-zero-vitest-example/src/components/BottomButtonNav.vue",
  "sourceRoot": "",
  "sourcesContent": [
    "<template>\n
\n
\n      <slot name=\"leftSide\"></slot>\n
\n
\n      <slot name=\"rightSide\"></slot>\n
\n
\n</template>\n\n\n\n\n"
  ]
}

When inspecting the source map it's clearly visible that it's off: https://ariperkkio.github.io/source-map-debugger?s=N4Ig.... Notice how the line 4's _withScopeId helper function is incorrectly included in source maps. This is the uncovered function that your coverage report includes.
  {
    "functionName": "_withScopeId",
    "ranges": [
      {
        "startOffset": 587,
        "endOffset": 689,
        "count": 0
      }
    ],
    "isBlockCoverage": false
  }

Now when we add one extra line to mappings everything looks much better:
-  "mappings": ";;;qBACO,...",
+  "mappings": ";;;;qBACO,...",

---------------------|---------|----------|---------|---------|-------------------
File                 | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
---------------------|---------|----------|---------|---------|-------------------
All files            |     100 |      100 |     100 |     100 |
 BottomButtonNav.vue |     100 |      100 |     100 |     100 |
---------------------|---------|----------|---------|---------|-------------------

https://ariperkkio.github.io/source-map-debugger?s=N4Ig...
This needs to be fixed in one of the Vue compiler related dependencies that your project is using. Maybe it's the vuejs/vue-loader linked above.

Any news on this?

+1, having the same issue with coverage for components with no functions in them

Having the same issue. Any potential fix or workarounds on the horizon?

This worked for me:

+1

authors: AriPerkkio ThomasBerneHCSE bartspiering jordanMeo merlinstardust y-takebe zeropaull

repo: vitest-dev/vitest


text:
Resizable Popup feature

User can't resize any popups.
Maybe it is ok with conception "Popup is popup", but it is not very good with "Popup is window".
Also it will be very good feature to have several popups at the same time. (Several opened windows)

I doubt that @vitmalina has changed his opinion on multiple popups. See #671 and #283.
Maybe you should look at a different popup component (and render your w2ui form/grid/... there).
Or ask user ratones (  #671 ) how his fork is coming along, maybe he has something that can be pushed to the current master.
Or implement it yourself and create a pull request.

Agree with @mpf82. If you need another popup, you can still open a browser window.


text:
fix toolbarColumns bug

Hidden columns are shown in the toolbarColumns because of "col.hideable".
So I changed it to "col.hidden" and fixed judgement.

This is not a bug and does not need fixing. hideable indicates if a column can be hidden, not if a column is hidden.
It's even documentd here: http://w2ui.com/web/docs/w2grid.columns

I see how it is.
So if a column is hidden, it is shown in the toolbarColumns, isn't it?
I think hidden columns should not be shown there...
Could you tell me why hidden columns are shown there by default?

So if a column is hidden, it is shown in the toolbarColumns, isn't it?

If toolbarColumnsis true, both hidden and visible columns are part of the menu.

I think hidden columns should not be shown there...

Why?

Could you tell me why hidden columns are shown there by default?

So you can show hidden columns again if you've hidden them.
If you want to hide columns from your user and you don't want the user to be able to make them visible, you could set hidden to true and hideable to false

Not a bug. @mpf82 is right. The toolbar menu purpose is to allow user to hide or show columns. However, if you want a column that is not in the list, then you use hideable = false;


text:
If delta-buffer grows indefinitely, evict peer(s)

What's a good peer eviction strategy?

Maybe a good peer eviction strategy would:

if after X rounds of state_sync the buffer doesn't shrink, evict the peer with the oldest ack

the buffer doesn't shrink

This means if the oldest delta-group in the delta-buffer doesn't change for X rounds

This should be tracked per peer:

Store in the ack map a pair: last_ack and X number of rounds without ack received

If this X reaches some threshold, kick peer from ack map.

Implemented in #36

repo: vitorenesduarte/ldb


text:
🛑 Mochi is down

In 1d450b5, Mochi (https://mochi.vikshan.tech/) was down:

HTTP code: 503
Response time: 177 ms

Resolved: Mochi is back up in ddeb4a0 after 3 hours, 49 minutes.

repo: vixshan/upptime


text:
Apache Arrow Throws An Exception When Performing SELECT On A Table With UUID Column Type

Table:
DESC test.mocktable;

CREATE TABLE test.mocktable (
    id uuid PRIMARY KEY,
    name text,
    position int
) WITH additional_write_policy = '99p'
    AND bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND cdc = false
    AND comment = ''
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'}
    AND compression = {'chunk_length_in_kb': '16', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND crc_check_chance = 1.0
    AND default_time_to_live = 0
    AND extensions = {}
    AND gc_grace_seconds = 864000
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair = 'BLOCKING'
    AND speculative_retry = '99p';

Query attempted:
SELECT * FROM test.mocktable;

 id                                   | name | position
--------------------------------------+------+----------
 384e004d-4aae-483f-97a5-33eca5daf788 | test |        1

Exception:
│   196 │   def from_pydict(                                                                     ╭─────────────────────────────────────────── locals ───────────────────────────────────────────╮                                                                                │
│   197 │   │   cls, data: Mapping[str, Sequence[Any]], max_rows: int | None = None              │      cls = <class 'textual_fastdatatable.backend.ArrowBackend'>                              │                                                                                │
│   198 │   ) -> "ArrowBackend":                                                                 │     data = {'f0': [UUID('384e004d-4aae-483f-97a5-33eca5daf788')], 'f1': ['test'], 'f2': [1]} │                                                                                │
│ ❱ 199 │   │   tbl = pa.Table.from_pydict(dict(data))                                           │ max_rows = 100000                                                                            │                                                                                │
│   200 │   │   return cls(tbl, max_rows=max_rows)                                               ╰──────────────────────────────────────────────────────────────────────────────────────────────╯                                                                                │
│   201 │                                                                                │
│   202 │   @classmethod                                                                                │
│                                                                                │
│ in pyarrow.lib._Tabular.from_pydict:1812                                                                                │
│                                                                                │
│ in pyarrow.lib._from_pydict:5275                                                                                │
│                                                                                │
│ in pyarrow.lib.asarray:374                                                                                │
│                                                                                │
│ in pyarrow.lib.array:344                                                                                │
│                                                                                │
│ in pyarrow.lib._sequence_to_array:42                                                                                │
│                                                                                │
│ in pyarrow.lib.pyarrow_internal_check_status:154                                                                                │
│                                                                                │
│ in pyarrow.lib.check_status:91                                                                                │
╰─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
ArrowInvalid: Could not convert UUID('384e004d-4aae-483f-97a5-33eca5daf788') with type UUID: did not recognize Python value type when inferring an Arrow data type

cassandra-driver returns cassandra.io.libevreactor.Row(s) objects:
result.one()
Row(id=UUID('384e004d-4aae-483f-97a5-33eca5daf788'), name='test', position=1)

At the time of this issue, harlequin uses Arrow 14.0.1 and it doesn't support UUID type.
https://arrow.apache.org/docs/14.0/python/api/datatypes.html
A workaround for now is to return all values as string.

repo: vkhitrin/harlequin-cassandra


text:
Did vLLM support flashatten to save the memeory?

when i use flash-atten to do the fschat/long-eval test . i see the flash-attn saves a lot of gpu-memory usage.
so im wondering if vLLm support this too?

Hi @Zhuqln thanks for the great question. Instead of the flash-attn library, we use xformers, which provides FlashAttention-like memory-efficient attention implementations. We prefer xformers since it supports a wider range of GPUs, data types, and attention algorithms than flash-attn and can be installed with pre-compiled CUDA binaries.

authors: WoosukKwon Zhuqln

repo: vllm-project/vllm


text:
With OpenAI-Compatible Server, if stream output, some of the Chinese output are garbled text

With the OpenAI-Compatible Server start
curl like this:
curl http://localhost:8000/v1/completions \
-H "Content-Type: application/json" \
-d '{
"model": "WizardLM/WizardCoder",
"prompt": "你是谁？",
"max_tokens": 200,
"temperature": 0
}'

The output all in Chinese and perform well, but when add the {"stream": "true"} param, output will be look like this:
{"id": "cmpl-1dab266887b14793b7a0d7031444c000", "object": "chat.completion.chunk", "created": 1693565963, "model": "WizardLM/WizardCoder-15B-V1.0", "choices": [{"index": 0, "delta": {"role": null, "content": "你好，我是一个人工智能助手，我可以��助你完成��种任务，比如查��信息、������会������、发送��件、提��事件等。你可以"}, "finish_reason": "stop"}]}

Some of the Chinese are garbled

+1
I was just about to ask this as well, that when "stream=True", I think the output isn't using UTF-8, versus "stream=False", we are able to see UTF-8 characters.
Stream False Request:
curl http://127.0.0.1:6655/v1/chat/completions -H "Content-Type: application/json"  -d '{"model": "meta-llama/Llama-2-70b-chat-hf",  "messages": [{"role": "system", "content": "Below is an instruction that describes a task. Write a response that appropriately completes the request."}, {"role": "user", "content": "Give me your favorite emoji."}], "max_tokens": 16, "temperature": 0, "stream": false}'
Response:
Sure! My favorite emoji is 😊
Stream True Request:
curl http://127.0.0.1:6655/v1/chat/completions -H "Content-Type: application/json" -d '{"model": "meta-llama/Llama-2-70b-chat-hf", "messages": [{"role": "system", "content": "Below is an instruction that describes a task. Write a response that appropriately completes the request."}, {"role": "user", "content": "Give me your favorite emoji."}], "max_tokens": 16, "temperature": 0, "stream": true}'
Response :
Sure! My favorite emoji is �

Could you try #589 ?

Could you try #589 ?

@esmeetu Tried, i'm sure #589 can solve it, Thank you so much!
cc @nicobasile

Closing as this appears to be resolved.

authors: esmeetu hmellor jaywongs nicobasile


text:
fix: ensure the full context window is allowed as input

The openai API has a max_tokens parameter geared at controlling the output tokens.
vLLM is currently limiting the input context window according to the input tokens + the output max_tokens. Meanwhile, max_model_len is computed as the input context window.
With the current code, a Llama2 model would run into something like this;
openai.error.APIError: Invalid response object from API: '{"object":"error","message":"This model\'s maximum context lengt
h is 4096 tokens. However, you requested 4726 tokens (3726 in the messages, 1000 in the completion). Please reduce the length of the messages or completio
n.","type":"invalid_request_error","param":null,"code":null}' (HTTP response code was 400)

Which should clearly be ok since Llama2 context window is 4096, so 3726 fits fine.
Either we multiply max_model_len by two, as Llam2 can take 4096 tokens and generate 4096 tokens, or we only check for the input size here. The proposed PR goes with the latter since this appears to be an input validation.

Sorry, I was mistaken. The current code is correct.

Reopening because my tests show that it is true, 4096 input + 4096 output token is possible with Llama2.


text:
Added discrete colormaps of the Scientific Colour Maps

Hello @vmagnin,
This PR adds discrete colormaps from the Scientific Colour Maps.
Changes:

Updated colormap_class.f90 and scientific_colour_maps.f90.
Added gpl_to_lut.f90 to convert '.gpl' files to '.lut' files.
Updated the scripts.
Updated README.md.

Kind regards,
Ali

Thanks Ali @gha3mi ! You now know the project as myself...

Maybe you can consider removing scripts/cp_lut_files.sh since its functionality is already included in scripts/gpl_to_lut.f90.

Done!

repo: vmagnin/forcolormap


text:
Additional details  and  for Motorboat and Canoe routes

I would like to suggest looking into support for tagging of height (vertical clearance) on boat and canoe routes.
Same suggestion, but less pressing, for depth.
Boats need depth underneath, and clearance above. Availabe depth can be mapped on the waterways and clearance can be mapped on the waterways (width) and on bridges and other overhanging elements on the nodes and ways representing the obstacle, but this not really done except for large waterways.
For users plannng routes, especially for smaller vessels, clearance and depth are very important. Usually this is given/required as maximum boat heigth (above waterlevel) that a route tolerates, or the "guaranteed passing height" (gegarandeerde doorvaarthoogte). Which is the same as the lowest vertical clearance you can encounter.
About the same story goes for the depth.
The wish is to show depth and height information for the node2node routes and for the planned route, comparable to and in addtion to route lengths.  In particular the clearance informaton is crucial for motorboats.
A step further would be help with planning. E.g. the line type could show on the map if a route is under or above a certain clearance. Even more helpful would be if the user could set a cut-off value for the session, the planner could then adapt the display and the routing, possiibly even discard routes not guaranteeing this required clearance.

Width is sometimes important too. The tags I use now are:
vertical_clearance=*    /* height above water level of the lowest obstacle for this route relation.
horizontal_clearance=* /* width of the narrowest point of this route relation.
depth=*                        /* depth of the shallowest point in this route relation.
All in m, usaully given with two decimals.
Tagged on the route.
The users probably want this information from the viewpoint of the boat:
How high can a boat be to complete this route;
How wide can a boat be to complete this route;
How deep can the boat go to complete this route.
The information is provided by the operator of the network, as "guaranteed height/width/depth". It is seldom mapped on the ways of the relation or on the obstacles encountered, except for the big waterways where any vessel in this category can pass.

repo: vmarc/knooppuntnet


text:
Display via tag in route label

Some routes have from, to and also via tags.
Via value is not yet displayed by knooppuntnet.
Note: this key could have mullti values (separated by ;)
Waymarked Trails display "Vaucresson - Bougival - Saint-Germain-en-Laye" for the last stage…

Knooppuntnet miss "Bougival".

Route with only via tag: KPN display "?"
Example: Voie de Toulouse


text:
Update cf-mgmt-config global documentation

Describe the solution you'd like

The cf-mgmt-config global README.md should match the output from running cf-mgmt-config global --help command.
The output from cf-mgmt-config global --help does not seem to be complete.

The --no-access-plan flag contains the same description as --all-access-plan=

Sample output:
>cf-mgmt-config global --help
error: Usage:
  cf-mgmt-config [OPTIONS] global [global-OPTIONS]

Help Options:
  -h, --help                                              Show this help message

[global command options]
          --config-dir=                                   Name of the config directory
                                                          (default: config) [$CONFIG_DIR]
          --enable-delete-isolation-segments=[true|false] Enable removing isolation
                                                          segments
          --enable-delete-shared-domains=[true|false]     Enable removing shared domains
          --enable-service-access=[true|false]            Enable managing service access
          --enable-unassign-security-groups=[true|false]  Enable unassigning security
                                                          groups
          --metadata-prefix=                              Prefix for org/space metadata
          --staging-security-group=                       Staging Security Group to add
          --remove-staging-security-group=                Staging Security Group to remove
          --running-security-group=                       Running Security Group to add
          --remove-running-security-group=                Running Security Group to remove
          --shared-domain=                                Shared Domain to add
          --router-group-shared-domain=                   Router Group Shared Domain to
                                                          add
          --router-group-shared-domain-group=             Router Group Shared Domain group
          --internal-shared-domain=                       Internal Shared Domain to add
          --remove-shared-domain=                         Shared Domain to remove

    service-access:
          --broker=                                       Name of Broker
          --service=                                      Name of Service
          --all-access-plan=                              Plan to give access to all orgs
          --limited-access-plan=                          Plan to give limited access to,
                                                          must also provide org list
          --org=                                          Orgs to add to limited plan
          --remove-org=                                   Orgs to remove from limited plan
          --no-access-plan=                               Plan to give access to all orgs

Merged the PR.

repo: vmware-tanzu-labs/cf-mgmt


text:
Fix network policy ingress policy stats

This PR fixes #1976.  The miscalculation is caused by L2ForwardingCalcTable with rule

Specifically, packets to the gateway port or the tunnel port will also go to ConntrackCommitTable and bypass the NetworkPolicy ingress rule tables, as NetworkPolicy ingress rules are not enforced for these packets on the  source Node.

Therefore, these packets will not get counted in this case.

Codecov Report

Merging #2078 (4b4bfe1) into main (599d663) will decrease coverage by 6.10%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #2078      +/-   ##
==========================================
- Coverage   61.05%   54.94%   -6.11%
==========================================
  Files         270      270
  Lines       20366    20366
==========================================
- Hits        12435    11191    -1244
- Misses       6636     7977    +1341
+ Partials     1295     1198      -97

Flag
Coverage Δ

kind-e2e-tests
40.28% <100.00%> (-11.49%)
:arrow_down:

unit-tests
41.35% <0.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/agent/openflow/client.go
51.06% <100.00%> (-8.78%)
:arrow_down:

pkg/apis/controlplane/helper.go
25.00% <0.00%> (-75.00%)
:arrow_down:

pkg/apis/controlplane/v1beta2/helper.go
25.00% <0.00%> (-75.00%)
:arrow_down:

pkg/controller/networkpolicy/mutate.go
0.00% <0.00%> (-71.77%)
:arrow_down:

pkg/controller/networkpolicy/store/group.go
5.00% <0.00%> (-70.00%)
:arrow_down:

pkg/controller/networkpolicy/validate.go
0.00% <0.00%> (-69.47%)
:arrow_down:

pkg/k8s/name.go
33.33% <0.00%> (-66.67%)
:arrow_down:

pkg/agent/controller/networkpolicy/packetin.go
6.20% <0.00%> (-65.52%)
:arrow_down:

...formers/externalversions/security/v1alpha1/tier.go
0.00% <0.00%> (-64.29%)
:arrow_down:

...ers/externalversions/core/v1alpha2/clustergroup.go
0.00% <0.00%> (-64.29%)
:arrow_down:

... and 64 more

And please remove the issue link from the title of the commit message.

And please remove the issue link from the title of the commit message.
removed

It seems updated TestNetworkPolicyStats will still failed in noencap mode. I will take a look later

Could you also wrap the commit message body to ~76 characters per line?
https://github.com/golang/go/wiki/CommitMessage

@tnqn Thanks for review. It seems the current changes make all the tests pass. However, I will update the code and reply the comments after looking at different trafficEncapModes to double check if the change will affect these modes or not. Will at you after that.

Could you also wrap the commit message body to ~76 characters per line?
https://github.com/golang/go/wiki/CommitMessage

commit message formatted

Codecov Report

Merging #2078 (3eccfd0) into main (599d663) will decrease coverage by 0.20%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #2078      +/-   ##
==========================================
- Coverage   61.05%   60.85%   -0.21%
==========================================
  Files         270      270
  Lines       20366    20376      +10
==========================================
- Hits        12435    12400      -35
- Misses       6636     6700      +64
+ Partials     1295     1276      -19

Flag
Coverage Δ

kind-e2e-tests
51.54% <100.00%> (-0.22%)
:arrow_down:

unit-tests
41.55% <100.00%> (+0.19%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/agent/openflow/pipeline.go
65.97% <100.00%> (-4.05%)
:arrow_down:

pkg/agent/controller/traceflow/packetin.go
58.41% <0.00%> (-5.43%)
:arrow_down:

pkg/controller/networkpolicy/tier.go
47.50% <0.00%> (-5.00%)
:arrow_down:

...agent/controller/traceflow/traceflow_controller.go
69.46% <0.00%> (-3.82%)
:arrow_down:

pkg/controller/traceflow/controller.go
67.46% <0.00%> (-2.23%)
:arrow_down:

...ntroller/networkpolicy/networkpolicy_controller.go
69.35% <0.00%> (-1.75%)
:arrow_down:

pkg/agent/openflow/client.go
58.51% <0.00%> (-1.33%)
:arrow_down:

pkg/agent/route/route_linux.go
41.86% <0.00%> (-0.59%)
:arrow_down:

pkg/agent/agent.go
47.48% <0.00%> (-0.24%)
:arrow_down:

... and 13 more

/test-all

/test-integration

@ceclinux could you check the integration failure: https://jenkins.antrea-ci.rocks/job/antrea-integration-manual-for-pull-request/8/console? It seems related to this change

@ceclinux could you check the integration failure: https://jenkins.antrea-ci.rocks/job/antrea-integration-manual-for-pull-request/8/console? It seems related to this change

sure.

/test-integration

/test-integration

updated and integration tests passed @tnqn

/test-all

authors: ceclinux codecov-commenter codecov-io tnqn

repo: vmware-tanzu/antrea


text:
Adobe XD Design Resources

Summary
As Adobe XD is gaining more popularity, support for it would be an great addition in Clarity Design Resources.
Workarounds
Imported sketch resources work somehow, but clumsy
Related
Need an Adobe Experience Design UI Kit for mockup and prototyping #1233

Thanks for the request. I don't see us being able to do this anytime soon, because there are certainly too many potential design tools to support and its already a lot of work to keep up the ones we have. I'd rather focus on what we can do beyond supporting specific tools.
Closing this as something we don't intend to do.

authors: d-m-s gnomeontherun

repo: vmware/clarity


text:
[CSS] Reusing Clarity colors

Hi,
In the previous version of Clarity there was a file called "dependencies.clarity" which included all clarity variables/mixins at one place. We used it to include it in our own components' sass files in order to use clarity's variables/mixins.
In the latest version there is such file. What is your recommendation for consuming Clarity's variables/mixins?

What version are we talking about here? We have issue templates to help fill out useful information like a reproduction if there is a bug or answer questions like what versions of Clarity and Angular you are using, please use them in the future to help organize content better. There is some theming documentation coming for v3 which hasn't landed yet, and probably will address these questions unless its about another version of Clarity.

Hello @ttsvetko, due to inactivity on this issue we're closing it per our issue management policy. If you are able to provide additional details and a reproduction of the issue, we can reopen the ticket as necessary.

authors: gnomeontherun ttsvetko


text:
Long alerts on IE11 are cropped

Describe the bug
Longer alerts (more than a line) in the IE11 are shown with a scroll. And the issue is when we put the alerts inside a div with .main-container class then the scroll is hidden and the text is just cropped.
Same behavior is observed on multiple alerts with the arrow.
All the described cases are working consistently well on other browsers.
How to reproduce
Steps to reproduce the behavior:

  <clr-alerts>
    <clr-alert [clrAlertType]="'info'" [clrAlertAppLevel]="true">
      <clr-alert-item>
        Title of the alert bot in app level. - Lorem Ipsum is simply dummy
          text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever
          since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book.
          It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially
          unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum
          passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem
          Ipsum.

          <button class="btn alert-action">Button title</button>

      </clr-alert-item>
    </clr-alert>
  </clr-alerts>

Expected behavior
This image is taken from Microsoft Edge.Version 84.0.505.0 (Official build) canary (64-bit) (Chromium)

Versions
App

Angular: 7.0.0
Node: 10.16.0
Clarity: 1.0.5

Device:

OS: Windows 10
Browser: IE
Version: 11

Additional notes

Have you tried this on the latest Clarity v1 (or more recent versions of Clarity)? Otherwise can you setup a demo for us to triage?

Hello @gnomeontherun, here is the demo I prepared - https://github.com/aruseff/clarity-demos. It is a GitHub project as I couldn't make stackblitz work for IE11.

Hi @aruseff - I checked the demo provided on IE 11 and can see the issue. I also checked a simple Clarity app with latest Clarity/Angular and its still there.
This issue is with how IE11 deals with flex-basis: auto.
I'll submit a PR with a fix shortly.

authors: aruseff gnomeontherun hippee-lee


text:
Enhancement - Select Component Disabled State Looks Similar to Active State with Placeholder

Summary
Summary the request and address the questions as appropriate.
This is an enhancement request due to the select box's active state with placeholder text looking too similar to the disabled select component.
Use case
Having a clear visual distinction between active and disabled states for any component is crucial to helping to set expectations to users for what they can and cannot perform actions on.
Examples
Workarounds
Continue using as is to remain Clarity compliance

I believe this was handled by #4461
Closing as a duplicate unless that turns out to not be the case.

authors: jkuo-vmware mathisscott


text:
[VSAN] Incorrect 'Used' size reported for volume of diskformat type - zeroedthick on vsan datastore

Created a volume of size 1gb but 'Used' size is reported as 2gb.
Steps:

Created a volume of size 1gb with diskformat set to zeroedthick
docker volume create --driver=vmdk --name=vsanVolm -o size=1gb -o diskformat=zeroedthick

Did docker volume inspect for created volume:

root@photon-TX4FfW2ET [ ~ ]# docker volume inspect vsanVolm
[
    {
        "Name": "vsanVolm",
        "Driver": "vmdk",
        "Mountpoint": "/mnt/vmdk/vsanVolm",
        "Status": {
            "access": "read-write",
            "attach-as": "independent_persistent",
            "capacity": {
                "allocated": "2GB",
                "size": "1GB"
            },
            "clone-from": "None",
            "created": "Thu Feb 23 21:58:53 2017",
            "created by VM": "Worker-1-216",
            "datastore": "vsanDatastore",
            "diskformat": "zeroedthick",
            "fstype": "ext4",
            "status": "detached"
        },
        "Labels": {},
        "Scope": "global"
    }
]

Admin cli command output on ESX

[root@sc2-rdops-vm02-dhcp-89-216:~] /usr/lib/vmware/vmdkops/bin/vmdkops_admin.py ls -c volume,datastore,capacity,used
Volume    Datastore      Capacity  Used
--------  -------------  --------  ----
vol1      vsanDatastore  10GB      8MB
vsanVolm  vsanDatastore  1GB       2GB  <<<<<<<

Did same steps on shared-vmfs datastore. 'Used' and 'Capacity' are same.
Output is as follows:
[root@sc2-rdops-vm02-dhcp-90-19:~] /usr/lib/vmware/vmdkops/bin/vmdkops_admin.py ls -c volume,datastore,capacity,used
Volume    Datastore     Capacity  Used
--------  ------------  --------  ----
vsanVolm  sharedVmfs-0  1GB       1GB

Attached logs:
docker-volume-vsphere.txt
vmdk_ops.txt

This happens only with zeroedthick and eagerzeroedthick disk format
root@photon-xVmYMbyTn [ ~ ]# docker volume create --driver=vsphere --name=vsanVolm2 -o size=3gb -o diskformat=zeroedthick
vsanVolm2
root@photon-xVmYMbyTn [ ~ ]# docker volume inspect vsanVolm2
[
    {
        "Name": "vsanVolm2",
        "Driver": "vsphere",
        "Mountpoint": "/mnt/vmdk/vsanVolm2",
        "Status": {
            "access": "read-write",
            "attach-as": "independent_persistent",
            "capacity": {
                "allocated": "6GB",
                "size": "3GB"
            },
            "clone-from": "None",
            "created": "Sat Mar  4 02:20:07 2017",
            "created by VM": "1_photon",
            "datastore": "vsanDatastore",
            "diskformat": "zeroedthick",
            "fstype": "ext4",
            "status": "detached"
        },
        "Labels": {},
        "Scope": "global"
    }
]
root@photon-xVmYMbyTn [ ~ ]# docker volume create --driver=vsphere --name=vsanVolm6 -o size=3gb
vsanVolm6
root@photon-xVmYMbyTn [ ~ ]# docker volume inspect vsanVolm6
[
    {
        "Name": "vsanVolm6",
        "Driver": "vsphere",
        "Mountpoint": "/mnt/vmdk/vsanVolm6",
        "Status": {
            "access": "read-write",
            "attach-as": "independent_persistent",
            "capacity": {
                "allocated": "204MB",
                "size": "3GB"
            },
            "clone-from": "None",
            "created": "Sat Mar  4 02:20:40 2017",
            "created by VM": "1_photon",
            "datastore": "vsanDatastore",
            "diskformat": "thin",
            "fstype": "ext4",
            "status": "detached"
        },
        "Labels": {},
        "Scope": "global"
    }
]
root@photon-xVmYMbyTn [ ~ ]# docker volume create --driver=vsphere --name=vsanVolm8 -o size=3gb -o diskformat=thin
vsanVolm8
root@photon-xVmYMbyTn [ ~ ]# docker volume inspect vsanVolm8
[
    {
        "Name": "vsanVolm8",
        "Driver": "vsphere",
        "Mountpoint": "/mnt/vmdk/vsanVolm8",
        "Status": {
            "access": "read-write",
            "attach-as": "independent_persistent",
            "capacity": {
                "allocated": "200MB",
                "size": "3GB"
            },
            "clone-from": "None",
            "created": "Sat Mar  4 02:22:49 2017",
            "created by VM": "1_photon",
            "datastore": "vsanDatastore",
            "diskformat": "thin",
            "fstype": "ext4",
            "status": "detached"
        },
        "Labels": {},
        "Scope": "global"
    }
]
root@photon-xVmYMbyTn [ ~ ]# docker volume create --driver=vsphere --name=vsanVolm10 -o size=3gb -o diskformat=eagerzeroedthick
vsanVolm10
root@photon-xVmYMbyTn [ ~ ]# docker volume inspect vsanVolm10
[
    {
        "Name": "vsanVolm10",
        "Driver": "vsphere",
        "Mountpoint": "/mnt/vmdk/vsanVolm10",
        "Status": {
            "access": "read-write",
            "attach-as": "independent_persistent",
            "capacity": {
                "allocated": "6GB",
                "size": "3GB"
            },
            "clone-from": "None",
            "created": "Sat Mar  4 02:23:42 2017",
            "created by VM": "1_photon",
            "datastore": "vsanDatastore",
            "diskformat": "eagerzeroedthick",
            "fstype": "ext4",
            "status": "detached"
        },
        "Labels": {},
        "Scope": "global"
    }
]

@ashahi1 I believe we do have a test in CI which does create "volume of diskformat type - zeroedthick on vsan datastore" .. where is the gap for not reporting this issue through automated test?

The service is using ESX disk library to get the total and allocated size. Is the allocated size including replicas as well.

The API behavior of the ESX disk library is correct for the given disk formats. The result is not intuitive, but this info helps. http://pubs.vmware.com/vsphere-65/index.jsp#com.vmware.vsphere.vm_admin.doc/GUID-4C0F4D73-82F2-4B81-8AA7-1DD752A8A5AC.html
I think we can document this somewhere.

not  bug. behaviour documented. Closing

repo: vmware/docker-volume-vsphere


text:
Trigger ci tests only on certain conditions.

Developer branches should not trigger tests.
If developer wants to trigger a test run, prefix branch name with runci/* Example: runci/reducewaste.kerneltime
Pull Requests should always trigger builds

Testing:
reducewaste.kerneltime branch is not prefixed and the CI run did not run tests for push https://ci.vmware.run/vmware/docker-volume-vsphere/938
runci/reducewaste.kerneltime is prefixed and the same commit when pushed into runci/kerneltime caused all tests to run https://ci.vmware.run/vmware/docker-volume-vsphere/939
This PR without a prefix branch lead to all tests being run. https://ci.vmware.run/vmware/docker-volume-vsphere/942

looks good to my untrained eye - I am afraid we do not have many experts in Drone so as long as the Ci runs for PRs pushes once, does not run for regular branches and does run for runci/branch , it's all good to go.
Minor comment about a comment inside.;

@msterin I can ping the contributors of drone or look in their code if you have a specific question you would like answered for drone ;-) For now the new behavior is that every thing is the same for PRs and master but dev branches do not get tests unless requested by naming scheme (runci/*). Drone supports skipping CI runs via commit messages but not the other way around... so naming scheme in branches is a good bet. Also, we can run all tests locally any how.

authors: kerneltime msterin