vkcube is expanding over the time ...

I left the working vkcube in VK_PRESENT_MODE_IMMEDIATE_KHR mode for almost the whole day on the embedded device and noticed that the FPS started to drop very smoothly from 1380 to 1290 in 8 hours, it also became obvious that the cube had swollen a little. Centrifugal force? :D
It looks like a cumulative floating point error.

@mgorchak-blackberry can you say whether your cube was built from before or after a3d954fc13818cc07975dfd6030ad1bacb85e755 ?  Have you tried running cube like this before, and if so, is this new behavior?

I'm pretty sure this patch was not included in the vkcube build. I will apply it and let it run overnight. Will post results tomorrow. Thank you!

I ran it too late yesterday, need a little bit more time, but I do not observe even any minor FPS drops (it was before because cube required more fragment shader works due to expansion). FPS is stable for 4 hours already.
Still testing...

I think the problem was fixed and I will close the issue, 6+ hours of run shows no expansion issue, FPS is stable, no decreases were observed.


promisify tests

mocha supports examples that return promises, see: https://mochajs.org/#working-with-promises
supertest also supports promises, see: https://github.com/visionmedia/supertest#example

Wonder how long we should wait on that security check...

0 seconds

the correct answer is 0, @pklingem wins


Unable to connect

After input ip address, port and the token, the app reports error code 1.
I'm using hassio.
This from the log:
0413 09:42:43 [Debug] :  Use lovelace is true
0413 09:42:43 [Debug] :  Socket connecting...
0413 09:42:43 [Error] :  Socket stream Error: WebSocketChannelException: WebSocketChannelException: HandshakeException: Handshake error in client (OS Error:
WRONG_VERSION_NUMBER(tls_record.cc:242))
0413 09:42:43 [Debug] :  Automatic reconnect is false
0413 09:42:46 [Debug] :  Socket sink closed

Sorry, I fixed using http and not the https protocol.
One tip: can you get the sun elevation text from HA? Now itsn't translated.

WIll be implemented in #190


Feature/issue 778 add mpi build

Submission Checklist

[ ] Run unit tests: ./runTests.py test/unit
[ ] Run cpplint: make cpplint
[X] Declare copyright holder and open-source license: see below

Summary:
Add build for MPI to makefiles
Intended Effect:
Trigger automatic build of boost MPI for tests with mpi in their path IF STAN_MPI is defined in the make/local file.
How to Verify:

Define STAN_MPI in make/local (the value used does not matter).
touch test/unit/fake_mpi_test.cpp
make test/unit/fake_mpi_test

This should trigger the automatic build of the boost MPI and its dependencies as dynamic libraries.
Side Effects:
Documentation:
What we need is a working dynamic library libboost_mpi.dylib and libboost_serialization.dylib (with an .so ending on Linux!). In order to get there we use the boost build system which should be good at figuring out how the MPI installation on a given system needs to be used. If the defaults fail, then the user may himself configure the boost MPI build process by editing the lib/boost/user-config.jam file; the instructions how to do that are found in the boost MPI documentation.
Note that for the matter of the makefiles I am using as target lib/boost/stage/lib/mpi.so, because this files is always generated with the same file ending - on Mac and on Linux.
As I only got MPI working with dynamic linking, there are additional steps on Mac to ensure that the final binary can be executed without additional user interaction. On Mac the absolute paths to the dynamic libraries have to be hardcoded into the final executable. For this to work, the dynamic libraries need to be prepared using then install_name tool. Once that is done, the rpath linker option is sufficient to make things work. On Linux this additional step is not needed.
The plan for cmdstan is to add an if statement to the phony build target. In this if we can then trigger the MPI build whenever STAN_MPI is defined in make/local.
Copyright and Licensing
Please list the copyright holder for the work you are submitting (this will be you or your assignee, such as a university or company): Sebastian Weber
By submitting this pull request, the copyright holder is agreeing to license the submitted work under the following licenses:

Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

I can look into the Jenkinsfile, but I have to say that I have never dealt with the config of Jenkins. Maybe I need help, let's see. For the testing there is actually an additional complication which is that we have to run the mpi tests through mpirun -np 2 (for using 2 cores during testing). So a call to
./tests/unit/some_mpi_test
becomes
mpirun -np 2 ./tests/unit/some_mpi_test
If no MPI stuff is done in the test (so a non-MPI test), then this won't hurt or do anything. So this would need to be configured either in the Jenkinsfile (if possible) OR we update the runTests.py script to evoke mpirun for all tests with mpi_ in their file name. Any preference?
I wasn't aware to do a tricky thing with LIBMPI - I just tried to mimick the other libraries logic here. However, what took me a long time to realize is that stupid ORDER matters for makefiles (the libraries make is included very early on, even before the OS).
@syclik I hope got all change requests, will address them later.

I like the idea of updating runTests to switch to mpirun for the mpi tests.
I can help with that and the Jenkinsfile. Do we want to add a separate
section for MPI enabled unit tests, is that it?
On Thu, Mar 8, 2018 at 03:14 wds15<EMAIL_ADDRESS>wrote:

I can look into the Jenkinsfile, but I have to say that I have never dealt
with the config of Jenkins. Maybe I need help, let's see. For the testing
there is actually an additional complication which is that we have to run
the mpi tests through mpirun -np 2 (for using 2 cores during testing). So
a call to
./tests/unit/some_mpi_test
becomes
mpirun -np 2 ./tests/unit/some_mpi_test
If no MPI stuff is done in the test (so a non-MPI test), then this won't
hurt or do anything. So this would need to be configured either in the
Jenkinsfile (if possible) OR we update the runTests.py script to evoke
mpirun for all tests with mpi_ in their file name. Any preference?
I wasn't aware to do a tricky thing with LIBMPI - I just tried to mimick
the other libraries logic here. However, what took me a long time to
realize is that stupid ORDER matters for makefiles (the libraries make is
included very early on, even before the OS).
@syclik https://github.com/syclik I hope got all change requests, will
address them later.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/783#issuecomment-371412502, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAxJ7CGw6BkEj5YEMfnLxZSKdrM4PihWks5tcOhEgaJpZM4Sa35S
.

We want a separate job where all the unit tests are run with the MPI stuff
turned on. Not just the MPI tests.
On Thu, Mar 8, 2018 at 7:47 AM, seantalts<EMAIL_ADDRESS>wrote:

I like the idea of updating runTests to switch to mpirun for the mpi tests.
I can help with that and the Jenkinsfile. Do we want to add a separate
section for MPI enabled unit tests, is that it?
On Thu, Mar 8, 2018 at 03:14 wds15<EMAIL_ADDRESS>wrote:

I can look into the Jenkinsfile, but I have to say that I have never
dealt
with the config of Jenkins. Maybe I need help, let's see. For the testing
there is actually an additional complication which is that we have to run
the mpi tests through mpirun -np 2 (for using 2 cores during testing). So
a call to
./tests/unit/some_mpi_test
becomes
mpirun -np 2 ./tests/unit/some_mpi_test
If no MPI stuff is done in the test (so a non-MPI test), then this won't
hurt or do anything. So this would need to be configured either in the
Jenkinsfile (if possible) OR we update the runTests.py script to evoke
mpirun for all tests with mpi_ in their file name. Any preference?
I wasn't aware to do a tricky thing with LIBMPI - I just tried to mimick
the other libraries logic here. However, what took me a long time to
realize is that stupid ORDER matters for makefiles (the libraries make is
included very early on, even before the OS).
@syclik https://github.com/syclik I hope got all change requests, will
address them later.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/783#issuecomment-371412502, or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/
AAxJ7CGw6BkEj5YEMfnLxZSKdrM4PihWks5tcOhEgaJpZM4Sa35S>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/783#issuecomment-371477302, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAZ_FwPT89ldU2mLLSVhJ8Hwis55at9Mks5tcSh1gaJpZM4Sa35S
.

Kk, sounds good. Will work on that later today.
On Thu, Mar 8, 2018 at 08:38 Daniel Lee<EMAIL_ADDRESS>wrote:

We want a separate job where all the unit tests are run with the MPI stuff
turned on. Not just the MPI tests.
On Thu, Mar 8, 2018 at 7:47 AM, seantalts<EMAIL_ADDRESS>wrote:

I like the idea of updating runTests to switch to mpirun for the mpi
tests.
I can help with that and the Jenkinsfile. Do we want to add a separate
section for MPI enabled unit tests, is that it?
On Thu, Mar 8, 2018 at 03:14 wds15<EMAIL_ADDRESS>wrote:

I can look into the Jenkinsfile, but I have to say that I have never
dealt
with the config of Jenkins. Maybe I need help, let's see. For the
testing
there is actually an additional complication which is that we have to
run
the mpi tests through mpirun -np 2 (for using 2 cores during testing).
So
a call to
./tests/unit/some_mpi_test
becomes
mpirun -np 2 ./tests/unit/some_mpi_test
If no MPI stuff is done in the test (so a non-MPI test), then this
won't
hurt or do anything. So this would need to be configured either in the
Jenkinsfile (if possible) OR we update the runTests.py script to evoke
mpirun for all tests with mpi_ in their file name. Any preference?
I wasn't aware to do a tricky thing with LIBMPI - I just tried to
mimick
the other libraries logic here. However, what took me a long time to
realize is that stupid ORDER matters for makefiles (the libraries make
is
included very early on, even before the OS).
@syclik https://github.com/syclik I hope got all change requests,
will
address them later.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/783#issuecomment-371412502, or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/
AAxJ7CGw6BkEj5YEMfnLxZSKdrM4PihWks5tcOhEgaJpZM4Sa35S>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/783#issuecomment-371477302, or
mute
the thread
<
https://github.com/notifications/unsubscribe-auth/AAZ_FwPT89ldU2mLLSVhJ8Hwis55at9Mks5tcSh1gaJpZM4Sa35S
.

—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/783#issuecomment-371488535, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAxJ7IiIGHTmp5bDbpS9V6PtBQq9lNT2ks5tcTQ2gaJpZM4Sa35S
.

Thanks! Does that make sense? We want to make sure that the unit tests all
run under both MPI and non MPI. We'd want to catch it as soon as anything
broke under either condition.
On Thu, Mar 8, 2018 at 8:51 AM, seantalts<EMAIL_ADDRESS>wrote:

Kk, sounds good. Will work on that later today.
On Thu, Mar 8, 2018 at 08:38 Daniel Lee<EMAIL_ADDRESS>wrote:

We want a separate job where all the unit tests are run with the MPI
stuff
turned on. Not just the MPI tests.
On Thu, Mar 8, 2018 at 7:47 AM, seantalts<EMAIL_ADDRESS>wrote:

I like the idea of updating runTests to switch to mpirun for the mpi
tests.
I can help with that and the Jenkinsfile. Do we want to add a separate
section for MPI enabled unit tests, is that it?
On Thu, Mar 8, 2018 at 03:14 wds15<EMAIL_ADDRESS>wrote:

I can look into the Jenkinsfile, but I have to say that I have never
dealt
with the config of Jenkins. Maybe I need help, let's see. For the
testing
there is actually an additional complication which is that we have to
run
the mpi tests through mpirun -np 2 (for using 2 cores during
testing).
So
a call to
./tests/unit/some_mpi_test
becomes
mpirun -np 2 ./tests/unit/some_mpi_test
If no MPI stuff is done in the test (so a non-MPI test), then this
won't
hurt or do anything. So this would need to be configured either in
the
Jenkinsfile (if possible) OR we update the runTests.py script to
evoke
mpirun for all tests with mpi_ in their file name. Any preference?
I wasn't aware to do a tricky thing with LIBMPI - I just tried to
mimick
the other libraries logic here. However, what took me a long time to
realize is that stupid ORDER matters for makefiles (the libraries
make
is
included very early on, even before the OS).
@syclik https://github.com/syclik I hope got all change requests,
will
address them later.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/783#issuecomment-371412502,
or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/
AAxJ7CGw6BkEj5YEMfnLxZSKdrM4PihWks5tcOhEgaJpZM4Sa35S>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/783#issuecomment-371477302, or
mute
the thread
<
https://github.com/notifications/unsubscribe-auth/AAZ_
FwPT89ldU2mLLSVhJ8Hwis55at9Mks5tcSh1gaJpZM4Sa35S
.

—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/783#issuecomment-371488535, or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/
AAxJ7IiIGHTmp5bDbpS9V6PtBQq9lNT2ks5tcTQ2gaJpZM4Sa35S>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/783#issuecomment-371492015, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAZ_Fy89W9kazR0JdsXNiD8ZqynO72xnks5tcTdagaJpZM4Sa35S
.

Yep.
On Thu, Mar 8, 2018 at 08:57 Daniel Lee<EMAIL_ADDRESS>wrote:

Thanks! Does that make sense? We want to make sure that the unit tests all
run under both MPI and non MPI. We'd want to catch it as soon as anything
broke under either condition.
On Thu, Mar 8, 2018 at 8:51 AM, seantalts<EMAIL_ADDRESS>wrote:

Kk, sounds good. Will work on that later today.
On Thu, Mar 8, 2018 at 08:38 Daniel Lee<EMAIL_ADDRESS>wrote:

We want a separate job where all the unit tests are run with the MPI
stuff
turned on. Not just the MPI tests.
On Thu, Mar 8, 2018 at 7:47 AM, seantalts<EMAIL_ADDRESS>wrote:

I like the idea of updating runTests to switch to mpirun for the mpi
tests.
I can help with that and the Jenkinsfile. Do we want to add a
separate
section for MPI enabled unit tests, is that it?
On Thu, Mar 8, 2018 at 03:14 wds15<EMAIL_ADDRESS>wrote:

I can look into the Jenkinsfile, but I have to say that I have
never
dealt
with the config of Jenkins. Maybe I need help, let's see. For the
testing
there is actually an additional complication which is that we have
to
run
the mpi tests through mpirun -np 2 (for using 2 cores during
testing).
So
a call to
./tests/unit/some_mpi_test
becomes
mpirun -np 2 ./tests/unit/some_mpi_test
If no MPI stuff is done in the test (so a non-MPI test), then this
won't
hurt or do anything. So this would need to be configured either in
the
Jenkinsfile (if possible) OR we update the runTests.py script to
evoke
mpirun for all tests with mpi_ in their file name. Any preference?
I wasn't aware to do a tricky thing with LIBMPI - I just tried to
mimick
the other libraries logic here. However, what took me a long time
to
realize is that stupid ORDER matters for makefiles (the libraries
make
is
included very early on, even before the OS).
@syclik https://github.com/syclik I hope got all change
requests,
will
address them later.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<https://github.com/stan-dev/math/pull/783#issuecomment-371412502
,
or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/
AAxJ7CGw6BkEj5YEMfnLxZSKdrM4PihWks5tcOhEgaJpZM4Sa35S>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/783#issuecomment-371477302,
or
mute
the thread
<
https://github.com/notifications/unsubscribe-auth/AAZ_
FwPT89ldU2mLLSVhJ8Hwis55at9Mks5tcSh1gaJpZM4Sa35S
.

—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/783#issuecomment-371488535, or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/
AAxJ7IiIGHTmp5bDbpS9V6PtBQq9lNT2ks5tcTQ2gaJpZM4Sa35S>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/783#issuecomment-371492015, or
mute
the thread
<
https://github.com/notifications/unsubscribe-auth/AAZ_Fy89W9kazR0JdsXNiD8ZqynO72xnks5tcTdagaJpZM4Sa35S
.

—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/783#issuecomment-371493487, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAxJ7EKmv_z1iLPCUXvVOwKwlW4XKKyEks5tcTizgaJpZM4Sa35S
.

@wds15, I've got another pull request that makes the build a lot simpler for math. I've been working on that branch for a few months, taking into account this build process and GPU's build process.
One of the reasons I'm trying to keep this pull request clean is because that's how we got into trickiness in the first place. We tend to pile on technical debt and not back it out -- that's just how development works. It's better to fix it when it's spotted instead of later on. Anyway, we're close.
Question: what happens under Windows? Is it not possible or do you just not want to support it right now?

@syclik should we merge this pull before your reorg of the make system or the reverse?
I have tried to get it working on Windows for 2-3h and then gave up as it is a mystery to me as to how to install a MPI base system onto it. I would need to try again. For the moment I thought we just error out and that's it for now. Maybe we ask on the forum if some windows expert is able to install MPI (and boost_mpi). The thing is that MPI was built for high-performance computing clusters... which is usually not running Windows.
@seantalts Thanks for looking into this as well!

I think MPI is a really high priority for me (Bob mentioned as much as
well). I’d say we get this in as is - Sebastian already put the work into
understanding the current system and creating a solution for it, and Daniel
has in his head the mechanism for translation between the existing system
and his new one, so the labor seems to be well-divided already.
We also all agreed to release first in just CmdStan and Linux I believe in
that call almost a year ago.
On Thu, Mar 8, 2018 at 09:43 wds15<EMAIL_ADDRESS>wrote:

@syclik https://github.com/syclik should we merge this pull before your
reorg of the make system or the reverse?
I have tried to get it working on Windows for 2-3h and then gave up as it
is a mystery to me as to how to install a MPI base system onto it. I would
need to try again. For the moment I thought we just error out and that's it
for now. Maybe we ask on the forum if some windows expert is able to
install MPI (and boost_mpi). The thing is that MPI was built for
high-performance computing clusters... which is usually not running Windows.
@seantalts https://github.com/seantalts Thanks for looking into this as
well!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/783#issuecomment-371506877, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAxJ7Aw9RWK6oOkbYcuo0aB2f0Z3BSzqks5tcUOIgaJpZM4Sa35S
.

Definitely no need to wait for the other pull request!

We also all agreed to release first in just CmdStan and Linux I believe in
that call almost a year ago.

Didn't realize that. (Damn short memory.) I think @wds15 has gotten it going on both mac and linux, so we should test on both? or linux only?

I'd probably just leave that up to him, haha. But I think he's been working
primarily with Mac anyway, so seems like we'll get both ;)
On Thu, Mar 8, 2018 at 12:39 PM Daniel Lee<EMAIL_ADDRESS>wrote:

Definitely no need to wait for the other pull request!
We also all agreed to release first in just CmdStan and Linux I believe in
that call almost a year ago.
Didn't realize that. (Damn short memory.) I think @wds15
https://github.com/wds15 has gotten it going on both mac and linux, so
we should test on both? or linux only?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/783#issuecomment-371563988, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAxJ7N3BqCTs0hO2Uvlxuv-Biivjtq84ks5tcWzGgaJpZM4Sa35S
.

These files have already been removed from develop. A merge with develop should solve this. I will do that now.

We are going to get Mac and Linux support for MPI. I now remember: For Windows I tried to get the cygwin MPI libraries up and running, but I failed to get that working on my laptop. Since cygwin has openmpi it should be possible to do it, but it was not straightforward for me.

Argh... I only tested things to the point that everything got build, but I never executed the foo_mpi_test - which I should have done. Anyway, now it works. Changes:

LIBMPI is not any more defined
I DO NOT use mpi.so as target anymore, because if you do so, then the linker will bring it in and the executable will not start on Mac as the linker tries to get a hold of mpi.so which it cannot find. Adding more of this install-whatever magic did not solve this.
instead I am now making things far more straightforward in terms of makefile logic: In the ifdef block within tests I make the MPI tests dependent on libboost_mpi$(DLL) and libboost_serialization$(DLL). The $(DLL) is defined os dependent. Moreover, these targets themselves depend on mpi.so which is build the usual way. For dylib variants I am moreover adding the install-name magic.

This logic avoids a few if statements and as an upside one even gets an executable which works (yeah).

the unit tests with MPI fail on our Jenkins with:
[workspace] Running shell script

+ echo STAN_MPI:=true

/Users/Shared/Jenkins/Home/jobs/Math<EMAIL_ADDRESS>line 2: /etc/make/local: No such file or directory

Not sure how to fix that... maybe @seantalts can have a look?
BTW, there is more than just a STAN_MPI=true to add to the make/local. In addition the user also must provide the necessary compiler and linker flags such that things get build with reference to the local MPI installation. So for mpich (which is the MPI implementation I would favor to do the testing with) this means to set in make/local
CXX=mpicxx
STAN_MPI=true

Remember that from the Stan side we automate the process to get boost MPI running which is linked against the base MPI installation. For compilation we need to hook up against boost MPI and in order for that library to work you need to throw in things needed to compile and link against the base MPI installation.
My preference for mpich is because our admins here say that it is better integrated with Infiniband (a high-performance network thing).

Hah, fixed that /etc/make/local thing. My editor must have inserted that trying to autocomplete the path and I failed to notice.

Think I fixed those two points - need to now install mpich on the linux and mac machines in Jenkins.

Now that the Jenkins thing is working, it's the code under test that is erroring - we have a bunch of
./stan/math/prim/mat/functor/map_rect.hpp:156:2: error: "MPI not yet supported"
#error "MPI not yet supported"

Ups. Let's just silence the error. I did not foresee that the code gets tested in MPI mode before even any MPI code is there.

hmm... now things fail, because of the order how stuff is build. What should solve it is if we do as @syclik suggested and take the LDFLAGS and CXXFLAGS out of the os files and instead ass to tests this:
$(MPI_TESTS): LDFLAGS += -L$(BOOST)/stage/lib -lboost_serialization -lboost_mpi -Wl,-rpath,$(BOOST)/stage/lib
$(MPI_TESTS): CXXFLAGS += -DSTAN_MPI

Right now the cvodes libraries get build with the above compiler+linker flags, but the MPI stuff has not yet been build such that it fails.
What I like about having the above definitions in the os file is that this will enable them for all matters for cmdstan. Would it be possible to first run any mpi test which ensures that the boost libraries get build? Or would that be too fragile?

Hm, interesting. I bet @syclik's makefile refactor solves this by creating separate flags for the different projects we build.
I don't think we should rely on the user running tests in the correct order. Do we actually want cvodes to be linked against Boost MPI? If so, can we add a dependency there conditional on STAN_MPI? If we don't care if cvodes is built against MPI, maybe we can add that dependency anyway?
(minor note: cvodes probably only gets built with those LDFLAGS because it's not a C++ project (so CXXFLAGS shouldn't apply), but we still need to fix LDFLAGS sharing)

We do not need to link anything against boost MPI or the MPI base libraries unless it is the code which actually uses MPI. So neither the cvodes library nor any non-MPI needs to linked against those MPI dependencies (but it does not hurt either).
My latest commit introduces a CXXFLAGS_MPI and a LDFLAGS_MPI which get defined if STAN_MPI is set. Whenever STAN_MPI is defined the MPI tests now add the mpi.so dependency and for the MPI tests only the CXXFLAGS and LDFLAGS are modified with their _MPI extras.
For cmdstan we should be able to add the _MPI additions respectivley; not sure yet, but let‘s go one step after the other. I hope this makes all sense now.

Makes sense to me.
On Sun, Mar 11, 2018 at 07:17 wds15<EMAIL_ADDRESS>wrote:

We do not need to link anything against boost MPI or the MPI base
libraries unless it is the code which actually uses MPI. So neither the
cvodes library nor any non-MPI needs to linked against those MPI
dependencies (but it does not hurt either).
My latest commit introduces a CXXFLAGS_MPI and a LDFLAGS_MPI which get
defined if STAN_MPI is set. Whenever STAN_MPI is defined the MPI tests
now add the mpi.so dependency and for the MPI tests only the CXXFLAGS and
LDFLAGS are modified with their _MPI extras.
For cmdstan we should be able to add the _MPI additions respectivley; not
sure yet, but let‘s go one step after the other. I hope this makes all
sense now.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/783#issuecomment-372107470, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAxJ7NKj3rw9wz242HefNhpXZUSeHRYrks5tdQfHgaJpZM4Sa35S
.

@seantalts Could you look into these remaining requests from @syclik ? These are wrt to the Jenkins config and the runTests.py. Thanks!

Woops, yes will do that today! Exciting times folks
On Wed, Mar 14, 2018 at 04:11 wds15<EMAIL_ADDRESS>wrote:

@seantalts https://github.com/seantalts Could you look into these
remaining requests from @syclik https://github.com/syclik ? These are
wrt to the Jenkins config and the runTests.py. Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/783#issuecomment-372937365, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAxJ7JVHZQFQ2XQUCD3PXu29_IFkKVgpks5teNDCgaJpZM4Sa35S
.

Okay, updated to do as you guys suggested. Please ping me again if I can help more!

Jenkins appears to be unstable. I restarted a few times and I end up with the "!" in all boxes / Jenkins deeming results as "unstable".

Unstable means that tests are failing, though it seems to have encountered some kind of Jenkins bug while trying to parse the test XMLs. There are also some new compiler warnings. Here are the warnings from the full console log:
[Unit with MPI] In file included from ./stan/math/rev/mat/functor/integrate_1d_tsc.hpp:14:0,
[Unit with MPI]                  from ./stan/math/rev/mat.hpp:57,
[Unit with MPI]                  from ./stan/math.hpp:4,
[Unit with MPI]                  from test/unit/math/prim/arr/functor/integrate_1d_tsc_test.cpp:1:
[Unit with MPI] ./stan/math/rev/mat/functor/de_integrator.hpp: In instantiation of ‘double stan::math::de_integrator(const F&, double, double, double, double) [with F = std::_Bind_result<double, f1(std::_Placeholder<1>, double, std::reference_wrapper<std::basic_ostream<char> >)>]’:
[Unit with MPI] ./stan/math/rev/mat/functor/integrate_1d_tsc.hpp:151:22:   required from ‘typename stan::scalar_type<T2>::type stan::math::integrate_1d_tsc(const F&, double, double, const T_param&, std::ostream&, double, double) [with F = f1; T_param = double; typename stan::scalar_type<T2>::type = double; std::ostream = std::basic_ostream<char>]’
[Unit with MPI] test/unit/math/prim/arr/functor/integrate_1d_tsc_test.cpp:49:3:   required from here
[Unit with MPI] ./stan/math/rev/mat/functor/de_integrator.hpp:65:7: warning: variable ‘num_function_evaluations’ set but not used [-Wunused-but-set-variable]
[Unit with MPI]    int num_function_evaluations;
[Unit with MPI]        ^
[Unit with MPI] ./stan/math/rev/mat/functor/de_integrator.hpp: In instantiation of ‘double stan::math::de_integrator(const F&, double, double, double, double) [with F = std::_Bind_result<double, double (*(f1, std::_Placeholder<1>, stan::math::var, stan::math::var, std::reference_wrapper<std::basic_ostream<char> >))(const f1&, double, const stan::math::var&, const stan::math::var&, std::basic_ostream<char>&)>]’:
[Unit with MPI] ./stan/math/rev/mat/functor/integrate_1d_tsc.hpp:167:35:   required from ‘typename stan::scalar_type<T2>::type stan::math::integrate_1d_tsc(const F&, double, double, const T_param&, std::ostream&, double, double) [with F = f1; T_param = double; typename stan::scalar_type<T2>::type = double; std::ostream = std::basic_ostream<char>]’
[Unit with MPI] test/unit/math/prim/arr/functor/integrate_1d_tsc_test.cpp:49:3:   required from here
[Unit with MPI] ./stan/math/rev/mat/functor/de_integrator.hpp:65:7: warning: variable ‘num_function_evaluations’ set but not used [-Wunused-but-set-variable]
[Unit with MPI] ./stan/math/rev/mat/functor/de_integrator.hpp: In instantiation of ‘double stan::math::de_integrator(const F&, double, double, double, double) [with F = std::_Bind_result<double, f2(std::_Placeholder<1>, std::vector<double>, std::reference_wrapper<std::basic_ostream<char> >)>]’:
[Unit with MPI] ./stan/math/rev/mat/functor/integrate_1d_tsc.hpp:151:22:   required from ‘typename stan::scalar_type<T2>::type stan::math::integrate_1d_tsc(const F&, double, double, const T_param&, std::ostream&, double, double) [with F = f2; T_param = std::vector<double>; typename stan::scalar_type<T2>::type = double; std::ostream = std::basic_ostream<char>]’
[Unit with MPI] test/unit/math/prim/arr/functor/integrate_1d_tsc_test.cpp:53:3:   required from here
[Unit with MPI] ./stan/math/rev/mat/functor/de_integrator.hpp:65:7: warning: variable ‘num_function_evaluations’ set but not used [-Wunused-but-set-variable]
[Unit with MPI] ./stan/math/rev/mat/functor/de_integrator.hpp: In instantiation of ‘double stan::math::de_integrator(const F&, double, double, double, double) [with F = std::_Bind_result<double, double (*(f2, std::_Placeholder<1>, std::vector<stan::math::var>, stan::math::var, std::reference_wrapper<std::basic_ostream<char> >))(const f2&, double, const std::vector<stan::math::var>&, const stan::math::var&, std::basic_ostream<char>&)>]’:
[Unit with MPI] ./stan/math/rev/mat/functor/integrate_1d_tsc.hpp:167:35:   required from ‘typename stan::scalar_type<T2>::type stan::math::integrate_1d_tsc(const F&, double, double, const T_param&, std::ostream&, double, double) [with F = f2; T_param = std::vector<double>; typename stan::scalar_type<T2>::type = double; std::ostream = std::basic_ostream<char>]’
[Unit with MPI] test/unit/math/prim/arr/functor/integrate_1d_tsc_test.cpp:53:3:   required from here
[Unit with MPI] ./stan/math/rev/mat/functor/de_integrator.hpp:65:7: warning: variable ‘num_function_evaluations’ set but not used [-Wunused-but-set-variable]
[Unit with MPI] ./stan/math/rev/mat/functor/de_integrator.hpp: In instantiation of ‘double stan::math::de_integrator(const F&, double, double, double, double) [with F = std::_Bind_result<double, f3(std::_Placeholder<1>, Eigen::Matrix<double, -1, 1>, std::reference_wrapper<std::basic_ostream<char> >)>]’:
[Unit with MPI] ./stan/math/rev/mat/functor/integrate_1d_tsc.hpp:151:22:   required from ‘typename stan::scalar_type<T2>::type stan::math::integrate_1d_tsc(const F&, double, double, const T_param&, std::ostream&, double, double) [with F = f3; T_param = Eigen::Matrix<double, -1, 1>; typename stan::scalar_type<T2>::type = double; std::ostream = std::basic_ostream<char>]’
[Unit with MPI] test/unit/math/prim/arr/functor/integrate_1d_tsc_test.cpp:62:3:   required from here
[Unit with MPI] ./stan/math/rev/mat/functor/de_integrator.hpp:65:7: warning: variable ‘num_function_evaluations’ set but not used [-Wunused-but-set-variable]
[Unit with MPI] ./stan/math/rev/mat/functor/de_integrator.hpp: In instantiation of ‘double stan::math::de_integrator(const F&, double, double, double, double) [with F = std::_Bind_result<double, double (*(f3, std::_Placeholder<1>, Eigen::Matrix<stan::math::var, -1, 1>, stan::math::var, std::reference_wrapper<std::basic_ostream<char> >))(const f3&, double, const Eigen::Matrix<stan::math::var, -1, 1>&, const stan::math::var&, std::basic_ostream<char>&)>]’:
[Unit with MPI] ./stan/math/rev/mat/functor/integrate_1d_tsc.hpp:167:35:   required from ‘typename stan::scalar_type<T2>::type stan::math::integrate_1d_tsc(const F&, double, double, const T_param&, std::ostream&, double, double) [with F = f3; T_param = Eigen::Matrix<double, -1, 1>; typename stan::scalar_type<T2>::type = double; std::ostream = std::basic_ostream<char>]’
[Unit with MPI] test/unit/math/prim/arr/functor/integrate_1d_tsc_test.cpp:62:3:   required from here
[Unit with MPI] ./stan/math/rev/mat/functor/de_integrator.hpp:65:7: warning: variable ‘num_function_evaluations’ set but not used [-Wunused-but-set-variable]
[Unit with MPI] ./stan/math/rev/mat/functor/de_integrator.hpp: In instantiation of ‘double stan::math::de_integrator(const F&, double, double, double, double) [with F = std::_Bind_result<double, f4(std::_Placeholder<1>, Eigen::Matrix<double, 1, -1>, std::reference_wrapper<std::basic_ostream<char> >)>]’:
[Unit with MPI] ./stan/math/rev/mat/functor/integrate_1d_tsc.hpp:151:22:   required from ‘typename stan::scalar_type<T2>::type stan::math::integrate_1d_tsc(const F&, double, double, const T_param&, std::ostream&, double, double) [with F = f4; T_param = Eigen::Matrix<double, 1, -1>; typename stan::scalar_type<T2>::type = double; std::ostream = std::basic_ostream<char>]’
[Unit with MPI] test/unit/math/prim/arr/functor/integrate_1d_tsc_test.cpp:70:3:   required from here
[Unit with MPI] ./stan/math/rev/mat/functor/de_integrator.hpp:65:7: warning: variable ‘num_function_evaluations’ set but not used [-Wunused-but-set-variable]
[Unit with MPI] ./stan/math/rev/mat/functor/de_integrator.hpp: In instantiation of ‘double stan::math::de_integrator(const F&, double, double, double, double) [with F = std::_Bind_result<double, double (*(f4, std::_Placeholder<1>, Eigen::Matrix<stan::math::var, 1, -1>, stan::math::var, std::reference_wrapper<std::basic_ostream<char> >))(const f4&, double, const Eigen::Matrix<stan::math::var, 1, -1>&, const stan::math::var&, std::basic_ostream<char>&)>]’:
[Unit with MPI] ./stan/math/rev/mat/functor/integrate_1d_tsc.hpp:167:35:   required from ‘typename stan::scalar_type<T2>::type stan::math::integrate_1d_tsc(const F&, double, double, const T_param&, std::ostream&, double, double) [with F = f4; T_param = Eigen::Matrix<double, 1, -1>; typename stan::scalar_type<T2>::type = double; std::ostream = std::basic_ostream<char>]’
[Unit with MPI] test/unit/math/prim/arr/functor/integrate_1d_tsc_test.cpp:70:3:   required from here
[Unit with MPI] ./stan/math/rev/mat/functor/de_integrator.hpp:65:7: warning: variable ‘num_function_evaluations’ set but not used [-Wunused-but-set-variable]

I'll dig into this more today, seems like something I should be able to help with.

Thanks!

Oh, I think this is probably from using the mpi compiler, which is grabbing the wrong compiler from the system.

Looks like this went wrong.
It would be best if mpich is compiled itself with the compiler which we want to use for testing. Using a different compiler than the one which was used to build mpich is not really recommended. This is due to mpich figuring out the bit representations of all types when its build. I am not sure if changing the compiler is a good idea then.

Okay, I think everything is building correctly now, but when the tests are executing, they're doing so with two executables running in parallel writing to the same XML file, corrupting it. There's some information about workarounds here. @wds15 want to take a look at that?

Are we currently running any test with mpirun? So even those which are not truly mpi tests? If yes, could we change that such that only MPI tests are executed with mpirun?
Alternativley we could run everything with mpirun -np 1 for the non-MPI tests.
If this is not an option (or not a solution), then we need to dig further.
For the true MPI tests I am already messing with the output such that the real MPI tests should be ok...at least I would hope that.
I am not on a computer until Thursday and can only try these ideas then.

btw, I'm really glad we're tackling these issues now before we get this
into the code base. this type of config wreaks havoc on our users.
On Mon, Mar 19, 2018 at 1:58 PM, wds15<EMAIL_ADDRESS>wrote:

Are we currently running any test with mpirun? So even those which are not
truly mpi tests? If yes, could we change that such that only MPI tests are
executed with mpirun?
Alternativley we could run everything with mpirun -np 1 for the non-MPI
tests.
If this is not an option (or not a solution), then we need to dig further.
For the true MPI tests I am already messing with the output such that the
real MPI tests should be ok...at least I would hope that.
I am not on a computer until Thursday and can only try these ideas then.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/783#issuecomment-374307654, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAZ_FyzAttMIc6t_Pt8JmUupSEps8Cw-ks5tf_G0gaJpZM4Sa35S
.

@syclik had requested we run all unit tests again with the MPI
configuration.
On Mon, Mar 19, 2018 at 14:00 Daniel Lee<EMAIL_ADDRESS>wrote:

btw, I'm really glad we're tackling these issues now before we get this
into the code base. this type of config wreaks havoc on our users.
On Mon, Mar 19, 2018 at 1:58 PM, wds15<EMAIL_ADDRESS>wrote:

Are we currently running any test with mpirun? So even those which are
not
truly mpi tests? If yes, could we change that such that only MPI tests
are
executed with mpirun?
Alternativley we could run everything with mpirun -np 1 for the non-MPI
tests.
If this is not an option (or not a solution), then we need to dig
further.
For the true MPI tests I am already messing with the output such that the
real MPI tests should be ok...at least I would hope that.
I am not on a computer until Thursday and can only try these ideas then.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/783#issuecomment-374307654, or
mute
the thread
<
https://github.com/notifications/unsubscribe-auth/AAZ_FyzAttMIc6t_Pt8JmUupSEps8Cw-ks5tf_G0gaJpZM4Sa35S
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stan-dev/math/pull/783#issuecomment-374308566, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAxJ7FBKIcCCTYhy3XwGRqU3khO5v1mqks5tf_JXgaJpZM4Sa35S
.

We would still run things with mpirun, just with a single process. Is that ok for @syclik ? Otherwise we have to adjust the gtest main cpp file to deal with multiple processes. If we do that, then I would basically suppress execution of the tests for any test other than those running with rank != 0.

While we're waiting for his answer, I committed a change that I think will do as you're suggesting.

@wds15 and @seantalts, it looks like it's tricky gtest to run with multiple threads. I think @seantalts already linked to google/googletest#822.
Below are questions that I haven't thought through and think we should answer:

when we run a unit test, when do we want to run it with mpirun? (why do we run it with mpirun when it's an "mpi test"?)
is there a way to run mpi properly without invoking mpirun?
is there a way to install mpi without installing mpirun? What do we do then?
where should we put this documentation within the Math library? Some reasonable options: Math wiki, makefile help, doxygen doc.

And just to verify, the unit tests are run with mpi and without mpi now? (That's what I think it does, but just wanted to verify.)

We've been talking about some of these already, in this thread and elsewhere. Re: doc - I will add something to runTests.py to print out if mpi is enabled and mpirun is not found and link it to this wiki page: https://github.com/stan-dev/stan/wiki/Parallelism-using-MPI-in-Stan (where I think we should add a "how to run the tests" section, and maybe update / rewrite for users instead of a design doc (not it). I think we can have instructions on what needs to be installed and perhaps even links to installation instructions on the wiki, and instructions on how to run the mpi tests once everything is installed correctly.

I can give more detail later, but mpirun is always part of the base mpi installation. So we can assume its there...otherwise the mpi installation is messed up, but this is a pre—requesite of us.

Let me go through your questions in order:

If you want to run things as close as possible as under MPI conditions, then we always want run tests with mpirun - even those non-MPI tests. However, the non-MPI tests have to be run with only a single thread as these are not capable to deal with multiple threads.

I do not know if you can run MPI properly without it, but it is always available whenever there is a base MPI installation.

I have never seen an MPI installation without mpirun, but I can only speak for the systems I have dealt with.

For stan-math we should probably have MPI unit test specifics in the wiki with a bit more detail and the bare basic info in help printouts, just as @seantalts suggests.

For the record: My understanding of mpirun is that it fires up as many processes as it is supposed to on a given machine. The specifcs of what is started where depends on its command line arguments which includes an optional hostfile which contains the info how many processes are started on which machine in a bigger cluster. Remember that mpirun is usually started from a queing system which assigns these ressources in full automation. On a given machine mpirun then starts the number of processes and codes in the environment of each process all the necessary info which the process needs to know in order to work with all the other MPI processes (which are on the same machine and/or on other machines). I think that you can get by without mpirun, but that is not recommended by any means as I understood it. So mpirun sets up everything needed to make MPI work (including how communication takes place). As MPI is very flexible in how communication is performed there are a few bells and whistles, but for unit testing we only need to deal with the default case and make sure that things work in this case.
What is left now to do, in order to merge?

@syclik just let me know where what documentation should go to. I am also happy to make a first draft as I envision.
BTW, where will we store extra documentation for the GPU stuff? We should probably make this in a consistent manner.

Bump. I put down a lot of documentation in our wiki:
https://github.com/stan-dev/stan/wiki/Parallelism-using-MPI-in-Stan
@syclik Is this along the lines you thought of? It's easy for me to overlook stuff as I am used to it, but I tried to have a comprehensive text on the matter.

Thanks for putting up the doc. A couple generic things:

Can you add a link to the wiki on the original post? It would help to look there instead of searching through the comments to find it.
Since this is just for control of that Math library, could you move the wiki to Math? I don't think this applies to Stan or CmdStan yet.

Specific things for the doc:

We're missing an installation guide to MPI. I understand how it's written, but the audience here is going to be people who want to run MPI and need help setting up first. That's missing.
It needs to clearly state that it will not work for Windows. This PR doesn't allow that to work. We should explicitly state that.
More detail? I don't know how to "Ensure that a base MPI installation is available and accessible on the system" -- what does that mean?
The "How to run MPI tests..." section is really confusing. I don't think I understand how to run them from reading that. Perhaps a code block with an example would help.

Your first two generic things:

It's not quite clear to me what you are referring to. Which post should be changed with a link to the wiki?
Makes sense. Moved to stan-math wiki, now here.

Specifics:

No, the MPI facility is tailored at (Linux) clusters where we can expect that a MPI installation is already available. We always said so (my understanding). I am making this more clear in the doc now, but I also give pointers as to how a "normal" user can use the facility. However, on a single machine users should really just use the threading stuff.
Ok, Windows is now mentioned. The only reason to disable windows is that we are unable to deploy MPI on windows. If a clever user manages to get MPI work on windows, then he can just use it. This is why I felt to just not mention Windows in the first place.
Ensuring that MPI works is described in the text by making reference to the boost.mpi documentation. I have moved this sentence to an earlier place. As we target systems where MPI already works I think its fine to point to other places where such details are described.
I refined this "how to run the MPI tests" section and now also give a code block. This overall block is more than just a "how to run". It also details what is happening. If it were just a how to run, then we could just say "use runTests.py" and the rest is done in full automation.

Thanks for building out the doc here.  The install doc and smoothness is going to be important for getting people spun up on this.
I agree that we don't want to maintain MPI install instructions.  It's a grey area here between something like MPI and something like R for RStan.
What we want to avoid on Windows is ordinary users trying to turn on MPI and having it not work.  We should make it clear in the doc that MPI doesn't work on Windows.  We should also disable it if possible on Windows so that a Windows user will get an error trying to turn MPI on.  Then, we can also ask for help making it work for Windows and provide the hint that they'll need to turn off whatever we do to disable Windows.

@wds15, I'm typing on my phone, so please forgive briefness.

The original post I think should change is here; I'm not sure how to reference it properly: https://github.com/stan-dev/math/pull/783#issue-172661790
thanks for moving the page to the math wiki.
I wasn't trying to say we need to write every detail on how to install. But I'd still like to be friendly to our users. I don't think most of our users are Linux cluster users. That's probably where we're just not on the same page. Even the devs are trying to test this locally. With that in mind, it'd help to just say something like: "here are some resources on how to install MPI."
re: windows, doesn't this PR explicitly make it not run on Windows?
thanks for cleaning up the doc a lot. It's a lot easier to read.

Links to resources are good, especially if they're maintained.  But I wouldn't let worry about maintenance prevent us from including some.
Going forward, we'll be recommending multi-process (MPI) for clusters of multiple machines and multi-threading (C++11 threads) for multi-core single machines.  GPUs will be usable either way, though we have to worry about GPU scheduling with multiple threads or processes on the same machine.
Windows users trying to specify MPI should get an error rather than a fallback to a serial implementation.

On Mar 31, 2018, at 7:36 PM, Daniel Lee<EMAIL_ADDRESS>wrote:
@wds15, I'm typing on my phone, so please forgive briefness.
• The original post I think should change is here; I'm not sure how to reference it properly: #783 (comment)
• thanks for moving the page to the math wiki.
• I wasn't trying to say we need to write every detail on how to install. But I'd still like to be friendly to our users. I don't think most of our users are Linux cluster users. That's probably where we're just not on the same page. Even the devs are trying to test this locally. With that in mind, it'd help to just say something like: "here are some resources on how to install MPI."
• re: windows, doesn't this PR explicitly make it not run on Windows?
• thanks for cleaning up the doc a lot. It's a lot easier to read.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.


Wikipedia extraction seems to be giving bigrams

Repro:
BitFunnel: 9e9e96ecb32841c53edc4542813ed1531fd4c4a9
Workbench: 580b74b421254f82348a811d7a886683c54c5a75
StatisticsBuilder c:\git\Wikipedia\Manifest100.txt c:\temp\wiki\out100 -statistics -text
Shouldn't have bigrams, shouldn't have capital letters:
Bigram where none expected (also capital letter):
72a2c4b53c781027,1,1,0.000144196,zephyrinus
bd01f0b68e57b2a7,1,1,0.000144196,sveshtari
3fad0c4faf3cb52b,1,0,0.000144196,Algebraic geometry
50c9029d9d3c5378,1,1,0.000144196,darabont
a2f5153a7612c5d0,1,1,0.000144196,up─üsik─ü
3ca7b8a975b95d4d,1,1,0.000144196,crisplock
Capital letter
49fc77672b6b54c4,1,0,0.000144196,Alexander Graham Bell
7d8b10a0a2b9f455,1,0,0.000144196,Evolutionarily stable strategy
Random garbase
b651bc4fddcd84af,1,1,0.000144196,86p
6cc733ca24bc18e,1,1,0.000144196,α▓╣α▓░α▓┐α▓╡α│å
5847567b67dc03cb,1,1,0.000144196,xis
a31bc33fc17f3fc6,1,1,0.000144196,αñ▓αñ╛αñû
b3d2c5a33dd1efc6,1,1,0.000144196,k├╢nigsberger

This is probably due to the problem where the Lucene analyzer wasn't run in Workbench. https://github.com/BitFunnel/Workbench/pull/6


Cleanup container rm funcs

LGTM

LGTM

I see problem with stats though. We're unsubscribing even if we're not going to kill container because of force lack.

Fixed in #13499


Add hyperclick support

This is a great package, but i thought it would be useful to add hyperclick support so that you can just cmd+click to jump to declaration instead of a keymap.

Also satisfies #263


Fix deprecated call of scipy.fromfunction()

Codecov Report

Merging #529 into master will decrease coverage by 0.51%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #529      +/-   ##
==========================================
- Coverage   96.36%   95.85%   -0.51%
==========================================
  Files          37       37
  Lines       13347    13347
==========================================
- Hits        12861    12793      -68
- Misses        486      554      +68


[SPARK-12028] [SQL] get_json_object returns an incorrect result when the value is null literals

When calling get_json_object for the following two cases, both results are "null":
    val tuple: Seq[(String, String)] = ("5", """{"f1": null}""") :: Nil
    val df: DataFrame = tuple.toDF("key", "jstring")
    val res = df.select(functions.get_json_object($"jstring", "$.f1")).collect()

    val tuple2: Seq[(String, String)] = ("5", """{"f1": "null"}""") :: Nil
    val df2: DataFrame = tuple2.toDF("key", "jstring")
    val res3 = df2.select(functions.get_json_object($"jstring", "$.f1")).collect()

Fixed the problem and also added a test case.

Test build #46827 has started for PR 10018 at commit 54edc84.

Test build #46827 has finished for PR 10018 at commit 54edc84.

This patch fails from timeout after a configured wait of `250m`.
This patch merges cleanly.
This patch adds no public classes.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/46827/
Test FAILed.

Merged build finished. Test FAILed.

retest this please

Test build #46832 has started for PR 10018 at commit 54edc84.

Test build #46832 has finished for PR 10018 at commit 54edc84.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/46832/
Test PASSed.

@rxin @davies Could you help me review the code changes for fixing get_json_object? The bug was discovered in the PR: https://github.com/apache/spark/pull/9977.
Thank you very much!

LGTM


mongoengine upload image to s3

as titled,
My document looks like this
class Style(db.Document):
    created = db.DateTimeField(default=now)
    updated = db.DateTimeField(default=now)
    name = db.StringField(max_length=32, required=True)
    description = db.StringField()
    cover = db.URLField(required=True)
    published = db.BooleanField(default=False)

So I want to be able to change the widget of cover field to a FileInputField and then get the file upload it to S3 then save the url to cover
any ideas on how to?

Use this https://github.com/flask-admin/flask-admin/blob/master/flask_admin/form/upload.py#L286 (or FileUploadField if you don't need preview) as a foundation, override _save_file (and, maybe, _save_thumbnail) to send file to S3. Initialize your url_relative_path to your field or override get_url in your field: https://github.com/flask-admin/flask-admin/blob/master/flask_admin/form/upload.py#L109

How do I validate the form and save the result (s3 endpoint) to my cover field?

class StyleAdmin(ModelView):
    form_extra_fields = {
        'cover': form.ImageUploadField('Image', base_path='/tmp', thumbnail_size=(100, 100, True))
    }

When I do this, and save the model, I get ValidationError: ValidationError (Style:None) (Invalid scheme logoicon_3.png in URL: LOGOICON_3.png: ['cover'])


Troubleshooting script problem

Just cloned the repo to get the file.
Tried to run the file on an NPS 2019 with Azure MFA extension and I get the following errors:
At C:\Users<my user>\Desktop\MFA_NPS_Troubleshooter.ps1:216 char:293

...  + $MFAVersion + ". The latest version is: " + $latestMFAVersion "."}

                                                                 ~~~

Unexpected token '"."' in expression or statement.
At C:\Users<my user>\Desktop\MFA_NPS_Troubleshooter.ps1:216 char:292

...  + $MFAVersion + ". The latest version is: " + $latestMFAVersion "."}

                                                                ~

The hash literal was incomplete.
At C:\Users\t1_distathopoulos\Desktop\MFA_NPS_Troubleshooter.ps1:638 char:1

}
~
Unexpected token '}' in expression or statement.

CategoryInfo          : ParserError: (:) [], ParseException
FullyQualifiedErrorId : UnexpectedToken

SOLUTION:

line 216 there is a "+" missing at the end to connect the variable with the string "."

This was my fault, and I just submitted a PR to address it.  I must have messed something up between VS Code and testing on the NPS server...
I generally don't use + to concatenate strings but was trying to leave things similar to the original code. I went ahead and updated it to no longer use +'s.

@sip03ds @nathanmcnulty fixed now. Thanks!

#please-close


added get invoice for lnd-engine

Adds a getInvoice call so we can get destination and value of invoice

 Set up process for delivering satoshis to users for referral program


Replace pbr in favor of importlib

The importlib module has a metadata.version to retrieve the package
version of the given module. This can be used in lieu of pbr for
gathering versioning. And since importlib is part of the base
Python package in 3.8 and greater, we can drop another dependency.
Closes #839
Signed-off-by: Eric Brown<EMAIL_ADDRESS>

FYI, I had to recreate this PR as a result of my fork getting destroyed by accident. The new PR is #1016. That PR also addresses the issues.


Bump Dependencies #2208910053

Bumps dependencies for product-is. Link : https://github.com/wso2/product-is/actions/runs/2208910053

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


Persist the target image digest

Motivation
The fix yesterday https://github.com/DataDog/integrations-core/pull/17331 also introduced another issue 34105da (#17333) which is why the conditional was set up like that originally.
Now both cases are handled; we either get the new digest from registry or we copy the existing one.

Wondering if it wouldn't be simpler and more consistent to just tag the image that we pull? Right after this: https://github.com/DataDog/integrations-core/blob/3b99b43eddd5002ce50388f5424f905269af9139/.builders/build.py#L175


Debug vs Verbose

I understand MF.Logging and Serilog have different priority levels but it's really bothersome to see logger.LogDebug show up as Verbose in serilog.
Is that the final word on how this should work?

Unfortunately yes, unless we can convince the folks over at aspnet/logging to change course on that one :-)
Switching the two levels is likely to be even more confusing I'm afraid :-(

I might make an issue on their side.
Hah, I just checked and there is a similar for NLog: https://github.com/aspnet/Logging/issues/237
Just to validate, Serilog would like Verbose to be the lowest, not Debug.  It looks like NLog wants Trace (instead of Verbose) to be the lowest and not Debug.  MF.Logging has Debug being the lowest below Verbose: https://github.com/serilog/serilog/blob/dev/src/Serilog/Events/LogEventLevel.cs
If they don't change, how awful would it be to make an optional to switch or skip the Verbose level?  I'm just trying to think of something to make it less awkward.

Yes, all options are definitely on the table. Thanks for following up!

This has been fixed in the dev branch of ASP.NET :-) We need to get dev on this repo lined back up with their MyGet builds...

Done - https://www.nuget.org/packages/Serilog.Extensions.Logging/1.0.0-rc2-10096


I donot know this is quill-mention's bug or quill's bug?

set spaceAfterInsert=false, I insert Chinese characters after mention, the first character will appear an error ，As the gif shows

有解了嘛？

@minzhang2  没有


Grid System should support CSS Container Queries for responsive column sizing

Prerequisites

[X] I have searched for duplicate or closed feature requests
[X] I have read the contributing guidelines

Proposal
CSS Container Queries are becoming widely supported.

https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Container_Queries
https://caniuse.com/css-container-queries

Proposal: _breakpoints.scss should be extended to be configurable to use container queries, perhaps defaulting to the body or falling back to media queries where appropriate for backwards compatibility.
Motivation and context
I have pages that can be displayed in either modal or full-page and currently there isn't a good way to wire up this sort of functionality.
Layouts with collapsible side navigation or modal dialogs would benefit from Container Queries instead of using normal Media Queries for responsive widths.

I'm having the same issue, with grid layouts that get squished when rendered inside modals.
Here's a quick hack that just stacks grid columns inside modals:
// Stack grid columns when displayed in a modal
@each $breakpoint in map-keys($grid-breakpoints) {
  $infix: breakpoint-infix($breakpoint, $grid-breakpoints);
  @for $i from 1 through $grid-columns {
    .modal .col#{$infix}-#{$i} {
      width: 100%;
    }
  }
}

Adding this, any .col-BP-I class inside a modal will just stretch to full-width. It's a bit brutal but it works well. And it doesn't even need container queries, making it compatible with older browsers 😉

Thanks @goulvench this is a nice workaround, but doesn't fully solve the need. For instance, if we have a shared component inside one of bootstrap's various modal sizes: https://getbootstrap.com/docs/5.3/components/modal/#optional-sizes
An additional scenario I'm trying to support is a layout with a side nav menu that can be expanded or collapsed. I'd like the grid system to be based on the width of the "main" component rather than the whole page width.

I solved my problem (which was that i wanted to be responsive against the size of my content-container) with patch-package with the following patch (named patches/bootstrap+5.2.3.patch) :

The following Code does not set breakpoints relative to @media but relative to the element you add a specific class to.

diff --git a/node_modules/bootstrap/scss/mixins/_breakpoints.scss b/node_modules/bootstrap/scss/mixins/_breakpoints.scss
index 286be89..f80a7ea 100644
--- a/node_modules/bootstrap/scss/mixins/_breakpoints.scss
+++ b/node_modules/bootstrap/scss/mixins/_breakpoints.scss
@@ -61,7 +61,7 @@
 @mixin media-breakpoint-up($name, $breakpoints: $grid-breakpoints) {
   $min: breakpoint-min($name, $breakpoints);
   @if $min {
-    @media (min-width: $min) {
+    @container #{$containerName} (min-width: #{$min}) {
       @content;
     }
   } @else {
@@ -74,7 +74,7 @@
 @mixin media-breakpoint-down($name, $breakpoints: $grid-breakpoints) {
   $max: breakpoint-max($name, $breakpoints);
   @if $max {
-    @media (max-width: $max) {
+    @container #{$containerName} (max-width: #{$max}) {
       @content;
     }
   } @else {
@@ -89,7 +89,7 @@
   $max: breakpoint-max($upper, $breakpoints);

   @if $min != null and $max != null {
-    @media (min-width: $min) and (max-width: $max) {
+    @container #{$containerName} (min-width: #{$min}) and (max-width: #{$max}) {
       @content;
     }
   } @else if $max == null {
@@ -112,7 +112,7 @@
   $max:  breakpoint-max($next, $breakpoints);

   @if $min != null and $max != null {
-    @media (min-width: $min) and (max-width: $max) {
+    @container #{$containerName} (min-width: #{$min}) and (max-width: #{$max}) {
       @content;
     }
   } @else if $max == null {

and an additional styling:

$containerName: mainSection;

.breakpoint-container {
  container-type: inline-size;
  container-name: $containerName;
}

and used like this:
...
<app-sidebar ></app-sidebar>

    <app-header></app-header>

      ...

    <app-footer ></app-footer>

...

But i hope it gets built in in some form!

@Joniras where did you add the additional styling?
Could you create a Repository or something like that for your fix?
Thank you!

The additional styling has to be applied on a global level. It has to be included before the bootstrap scss because the scss variable is defined in the additional styling and used in the (changed) bootstrap mixins.

+1 for that feature. E.g. creating cards or square-tiles holding lots of content (e.g. header, sub-header, text, buttons, ...) where the font-size should be scaled beside being rendered in 1-4 responsive columns depending on the parents width, is a huge mess just using breakpoints.

Bootstrap are in dire need of adding this, it is such a basic necessity, that columns should be based on the container that they're in and not the device width. iFrames, modals, even just adding in an aside to a page stuffs up all of your bootstrap responsive classes.
### PLEASE ADD THIS IN ASAP!!!!!!!!!!!!!!!!!!!!!!

I have added this to my scss for the time being:
.cq {
    display: flex;
    flex-wrap: wrap;
    container-type: inline-size;
}

@each $infix, $breakpoint in $grid-breakpoints {
    @container (min-width: #{$breakpoint}) {
        .cq-#{$infix}-1 {
            flex: 0 0 auto;
            width: 8.33333333cqw;
        }

        .cq-#{$infix}-2 {
            flex: 0 0 auto;
            width: 16.66666667cqw;
        }

        .cq-#{$infix}-3 {
            flex: 0 0 auto;
            width: 25cqw;
        }

        .cq-#{$infix}-4 {
            flex: 0 0 auto;
            width: 33.33333333cqw;
        }

        .cq-#{$infix}-5 {
            flex: 0 0 auto;
            width: 41.66666667cqw;
        }

        .cq-#{$infix}-6 {
            flex: 0 0 auto;
            width: 50cqw;
        }

        .cq-#{$infix}-7 {
            flex: 0 0 auto;
            width: 58.33333333cqw;
        }

        .cq-#{$infix}-8 {
            flex: 0 0 auto;
            width: 66.66666667cqw;
        }

        .cq-#{$infix}-9 {
            flex: 0 0 auto;
            width: 75cqw;
        }

        .cq-#{$infix}-10 {
            flex: 0 0 auto;
            width: 83.33333333cqw;
        }

        .cq-#{$infix}-11 {
            flex: 0 0 auto;
            width: 91.66666667cqw;
        }

        .cq-#{$infix}-12 {
            flex: 0 0 auto;
            width: 100cqw;
        }
    }
}

so you can use it like row/col:

Hello

Hello

Hello

I have started a repo to try implementing container queries in the bootstrap way, but it's still work in progress:
https://github.com/bastienmoulia/bootstrap-container-queries
PR welcomed 😉


Launches external WSL terminal when launching VSCode

Type: Bug
When opening VSCode, an external WSL console is unexpectedly opened as well.
VS Code version: Code 1.82.1<PHONE_NUMBER>d557a81c9d0b5f8a5a1e9274db5585, 2023-09-08T08:45:05.575Z)
OS version: Windows_NT x64 10.0.26120
Modes:

System Info

Item
Value

CPUs
AMD EPYC 7763 64-Core Processor                 (16 x 2445)

GPU Status
2d_canvas: unavailable_softwarecanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: disabled_softwaremultiple_raster_threads: enabled_onopengl: disabled_offrasterization: disabled_softwareraw_draw: disabled_off_okvideo_decode: disabled_softwarevideo_encode: disabled_softwarevulkan: disabled_offwebgl: unavailable_softwarewebgl2: unavailable_softwarewebgpu: unavailable_software

Load (avg)
undefined

Memory (System)
63.95GB (51.11GB free)

Process Argv
--crash-reporter-id 989f4572-fa06-4201-a540-b161bb7bafe8

Screen Reader
no

VM
0%

Extensions (8)

Extension
Author (truncated)
Version

cmake-tools
ms-
1.18.41

cpptools
ms-
1.20.5

cpptools-extension-pack
ms-
1.3.0

hexeditor
ms-
1.9.14

vscode-typescript-next
ms-
5.5.20240505

excalidraw-editor
pom
3.7.4

code-spell-checker
str
3.0.1

cmake
twx
0.0.17

(1 theme extensions excluded)

A/B Experiments
vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscorecescf:30445987
vscod805:30301674
binariesv615:30325510
vsaa593:30376534
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyone:30548225
962ge761:30959799
pythongtdpath:30769146
welcomedialog:30910333
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30898717
pythontestfixt:30902429
pythonregdiag2:30936856
pythonmypyd1:30879173
pythoncet0:30885854
pythontbext0:30879054
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
jchc7451:31066414
chatpanelc:31048052
dsvsc021:30996838
jg8ic977:31013176
a69g1124:31058053
dvdeprecationcf:31061161
pythonprt:31056678
dwnewjupyter:31046869
26j00206:31048877

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.89.1. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

I'm not aware of any code in VS Code that runs the WSL command, maybe the terminal does that? @Tyriar
@adettenb Does it reproduce with extensions disabled?

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


No SIGINT handler

gostatsd doesn't terminate if stdin is a tty and SIGINT (CTRL-C) is sent.

My testing shows that it does. In other words - I cannot reproduce it. Here is output if I modify it to print the received signal and run it in a terminal. This is macOS. Are you running linux?
./build/bin/darwin/gostatsd
INFO[0000] Starting server
INFO[0000] No cloud provider specified
INFO[0000] [graphite] address=localhost:2003 dialTimeout=5s writeTimeout=30s
INFO[0000] Initialised backend "graphite"
WARN[0000] Failed to connect: dial tcp [::1]:2003: getsockopt: connection refused
WARN[0001] Failed to connect: dial tcp [::1]:2003: getsockopt: connection refused
^Cinterrupt%

It's observable after a longer period of time has elapsed.   Should be fixed now.


Da consensus abstraction

WIP not ready for review

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: bfish713:x: nmccartyYou have signed the CLA already but the status is still pending? Let us recheck it.


[User questions] How LMCache identifies KV cache of chunk tokens?

Hi. I have some questions unsolved after reading the source code:

In the RAG use case(demo3), how LMCache identifies the KV of each context texts, which is prepended with the user prompt?
After the KV states of each context is retrieved, how are they blended(as described in the paper) and adjust their positional info? I could not find the codes related to it.

Thank you if you could show me the codes addressing issues mentioned above. ❤

Are you referring to the CacheBlend paper? If that's the case, you should wait for pull #121 to be merged.

Hi Taojie @dequeueing  , thanks for the question!
For the first question, LMCache identifies the KV by the tokens of the text chunks.
For the second question, the code is in PR #121 , and the key function is CacheBlendImpl.blend (https://github.com/ApostaC/LMCache/blob/3b10598303ccf6da37073504719773dd4addc8d1/lmcache/blend/executor.py#L76)
Please let us know if there are any other questions.

Hi Taojie @dequeueing , thanks for the question!
For the first question, LMCache identifies the KV by the tokens of the text chunks.
For the second question, the code is in PR #121 , and the key function is CacheBlendImpl.blend (https://github.com/ApostaC/LMCache/blob/3b10598303ccf6da37073504719773dd4addc8d1/lmcache/blend/executor.py#L76)
Please let us know if there are any other questions.

Thanks for the response.
I notice that in demo3(the RAG demo), when fed to LLM, the text chunks are seperated by a seperator if optimization is on.
session.separator = " # # " if optimization else ""

 def set_context(self, context_list):
        input_prompt = ""
        for context in context_list:
            input_prompt +=(self.separator + context)
        self.final_context = input_prompt
        self.messages.append({"role":"user", "content":input_prompt})

I guess that when processing the prompt each chunk will be extracted because of the seperator, but I could not find the corresponding code. Could you show me pls?

Hey, @dequeueing ! Sorry, I somehow missed the notification of your previous question.
The corresponding code is here: https://github.com/LMCache/LMCache/blob/a15c89c20d2e0bd2fd68bbce5f04c797171643d3/lmcache/blend/retriever.py#L217
Btw, CacheBlend logic has already been merged. Feel free to try the blending example in the examples/ folder.

Hey, @dequeueing ! Sorry, I somehow missed the notification of your previous question. The corresponding code is here:
https://github.com/LMCache/LMCache/blob/a15c89c20d2e0bd2fd68bbce5f04c797171643d3/lmcache/blend/retriever.py#L217
Btw, CacheBlend logic has already been merged. Feel free to try the blending example in the examples/ folder.

Thanks very much for the reply! I have a question about the RetrieveStatus:
class RetrieveStatus(Enum):
    PREFILL = 1
    CHUNK_PREFILL = 2 # not last chunk
    CHUNK_PREFILL_LAST = 3
    NONE = 4

Could you please explain when the status would be returned as CHUNK_PREFILL ?
I tried precompute a single chunk, and feed the same chunk back to LLM again. And it prints that the returned status from lmcache_should_retrieve is PREFILL  instead of CHUNK_PREFILL.
 # vllm_injection.py
 # LMCache retrieval
    retrieve_status = lmcache_should_retrieve(model_input, kv_caches)

I am a bit confused about this. Since the chunk given to LLM is exactly the same as the one that was pre-computed, shouldn't we skip prefill at all?
For example, If I change the blend_kv.py as follows:
context_files = ["chunk1.txt"]

user_prompt = [chunks[0]]

I think in this case we should entirely skip prefill.
Thanks in advance!

Hey, @dequeueing , CHUNK_PREFILL is for the "chunked prefill" feature when running vLLM. It's not related to the "chunks" in KV blending.
And if the chunk is exactly the same, it should skip all the prefill

In the first step of executing demo3, when preprocessing the text chunk, the following error will occur? Please tell me how to solve it?
Traceback (most recent call last):
  File "/lmcache/demo/precompute.py", line 44, in <module>
    llm = LLM(model=model_name, gpu_memory_utilization=0.5,
  File "/usr/local/lib/python3.10/dist-packages/vllm/entrypoints/llm.py", line 118, in __init__
    self.llm_engine = LLMEngine.from_engine_args(
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/llm_engine.py", line 277, in from_engine_args
    engine = cls(
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/llm_engine.py", line 160, in __init__
    self._initialize_kv_caches()
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/llm_engine.py", line 236, in _initialize_kv_caches
    self.model_executor.determine_num_available_blocks())
  File "/usr/local/lib/python3.10/dist-packages/vllm/executor/gpu_executor.py", line 111, in determine_num_available_blocks
    return self.driver_worker.determine_num_available_blocks()
  File "/usr/local/lib/python3.10/dist-packages/torch/utils/_contextlib.py", line 115, in decorate_context
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/vllm/worker/worker.py", line 153, in determine_num_available_blocks
    self.model_runner.profile_run()
  File "/usr/local/lib/python3.10/dist-packages/torch/utils/_contextlib.py", line 115, in decorate_context
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/vllm/worker/model_runner.py", line 1036, in profile_run
    self.execute_model(seqs, kv_caches)
  File "/usr/local/lib/python3.10/dist-packages/torch/utils/_contextlib.py", line 115, in decorate_context
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/vllm/worker/model_runner.py", line 925, in execute_model
    hidden_states = model_executable(**execute_model_kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1511, in _wrapped_call_impl
    return self._call_impl(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1520, in _call_impl
    return forward_call(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/vllm/model_executor/models/qwen2.py", line 315, in forward
    hidden_states = self.model(input_ids, positions, kv_caches,
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1511, in _wrapped_call_impl
    return self._call_impl(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1520, in _call_impl
    return forward_call(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/vllm/model_executor/models/qwen2.py", line 252, in forward
    hidden_states, residual = layer(
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1511, in _wrapped_call_impl
    return self._call_impl(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1520, in _call_impl
    return forward_call(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/vllm/model_executor/models/qwen2.py", line 205, in forward
    hidden_states = self.self_attn(
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1511, in _wrapped_call_impl
    return self._call_impl(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1520, in _call_impl
    return forward_call(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/vllm/model_executor/models/qwen2.py", line 151, in forward
    attn_output = self.attn(q, k, v, kv_cache, attn_metadata)
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1511, in _wrapped_call_impl
    return self._call_impl(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1520, in _call_impl
    return forward_call(*args, **kwargs)
TypeError: Attention.forward() missing 3 required positional arguments: 'status', 'cache_fuse_metadata', and 'old_kv'

Hey， @ApostaC，In the first step of executing demo3, when preprocessing the text chunk, the following error will occur? Please tell me how to solve it?
The first step is to execute according to the following script：
sudo docker run --runtime nvidia --gpus '"device=0"' \
    -v ${LOCAL_HF_HOME}:/root/.cache/huggingface \
    -v `pwd`/data:/input \
    -v `pwd`/data:/data \
    --env "HF_TOKEN=${HF_TOKEN}" \
    --ipc=host \
    --network=host \
    --entrypoint python3 \
    apostacyh/vllm:lmcache-blend \
    /lmcache/demo/precompute.py \
    --model ${MODEL} --lmcache-config-file /lmcache/demo/example.yaml --data-path /input \

The error that occurs is as follows：
Traceback (most recent call last):
  File "/lmcache/demo/precompute.py", line 44, in <module>
    llm = LLM(model=model_name, gpu_memory_utilization=0.5,
  File "/usr/local/lib/python3.10/dist-packages/vllm/entrypoints/llm.py", line 118, in __init__
    self.llm_engine = LLMEngine.from_engine_args(
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/llm_engine.py", line 277, in from_engine_args
    engine = cls(
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/llm_engine.py", line 160, in __init__
    self._initialize_kv_caches()
  File "/usr/local/lib/python3.10/dist-packages/vllm/engine/llm_engine.py", line 236, in _initialize_kv_caches
    self.model_executor.determine_num_available_blocks())
  File "/usr/local/lib/python3.10/dist-packages/vllm/executor/gpu_executor.py", line 111, in determine_num_available_blocks
    return self.driver_worker.determine_num_available_blocks()
  File "/usr/local/lib/python3.10/dist-packages/torch/utils/_contextlib.py", line 115, in decorate_context
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/vllm/worker/worker.py", line 153, in determine_num_available_blocks
    self.model_runner.profile_run()
  File "/usr/local/lib/python3.10/dist-packages/torch/utils/_contextlib.py", line 115, in decorate_context
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/vllm/worker/model_runner.py", line 1036, in profile_run
    self.execute_model(seqs, kv_caches)
  File "/usr/local/lib/python3.10/dist-packages/torch/utils/_contextlib.py", line 115, in decorate_context
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/vllm/worker/model_runner.py", line 925, in execute_model
    hidden_states = model_executable(**execute_model_kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1511, in _wrapped_call_impl
    return self._call_impl(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1520, in _call_impl
    return forward_call(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/vllm/model_executor/models/qwen2.py", line 315, in forward
    hidden_states = self.model(input_ids, positions, kv_caches,
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1511, in _wrapped_call_impl
    return self._call_impl(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1520, in _call_impl
    return forward_call(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/vllm/model_executor/models/qwen2.py", line 252, in forward
    hidden_states, residual = layer(
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1511, in _wrapped_call_impl
    return self._call_impl(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1520, in _call_impl
    return forward_call(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/vllm/model_executor/models/qwen2.py", line 205, in forward
    hidden_states = self.self_attn(
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1511, in _wrapped_call_impl
    return self._call_impl(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1520, in _call_impl
    return forward_call(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/vllm/model_executor/models/qwen2.py", line 151, in forward
    attn_output = self.attn(q, k, v, kv_cache, attn_metadata)
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1511, in _wrapped_call_impl
    return self._call_impl(*args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/torch/nn/modules/module.py", line 1520, in _call_impl
    return forward_call(*args, **kwargs)
TypeError: Attention.forward() missing 3 required positional arguments: 'status', 'cache_fuse_metadata', and 'old_kv'

Hey，@ ApostaC
I also want to ask, Which version of the code does this image apostacyh/vllm:lmcache-blend use? Can you explain in detail the process of making the image, so that we can debug the problem ourselves?

Thank you @ApostaC
There is a new question: If I want to implement pre_compute online, what should I do?
Because if it calls openai.chat directly, a lot of extra data will be added, such as:
prompt: '<|im_start|>system\nYou are a helpful assistant.<|im_end|>\n<|im_start|>user\n你会做什么呀？<|im_end|>\n<|im_start|>assistant\n'

Hey, @darren-qiu, towards your question:

There is a new question: If I want to implement pre_compute online, what should I do?

Another team member, @XbzOnGit , has been working on this recently.
Hey @XbzOnGit , is there any update about supporting blending for the online chat?

Hi, @darren-qiu, you can try the following code.
class KVPreCompute:

    def __init__(self, openai_api_key, openai_api_base):
        self.client = OpenAI(
            # defaults to os.environ.get("OPENAI_API_KEY")
            api_key=openai_api_key,
            base_url=openai_api_base,
        )
        self.model = self.client.models.list().data[0].id

    def precompute_kv(self, text_chunk):
        completion = self.client.completions.create(
            prompt=text_chunk,
            model=self.model,
            max_tokens=1,
        )
        return completion.choices[0].text

Thanks, @XbzOnGit and @ApostaC
I tested blend kv and found that the program did not take advantage of the kv that was preprocessed in advance.
After that, I tried running the blend_kv example again and found that it had no effect (like #235 mentioned here). I didn’t change any code, but only modification was that the model was changed to Qwen2.5 (the modification method is as follows, #241). I don’t know if it has any impact.
Could you please help confirm the cause of the problem? Thanks

INFO LMCache: Initializing lmcache_vllm version <IP_ADDRESS>, supporting vllm versions: ['0.6.1.post2', '0.6.1.dev238+ge2c6e0a82'] [2024-12-09 11:20:25,926] -- /usr/local/lib/python3.11/site-packages/lmcache_vllm/__init__.py:35
INFO LMCache: Loading LMCache config file example_blending.yaml [2024-12-09 11:20:25,982] -- /usr/local/lib/python3.11/site-packages/lmcache_vllm/vllm_adapter.py:135
INFO 12-09 11:20:26 llm_engine.py:226] Initializing an LLM engine (v0.6.1.dev238+ge2c6e0a82) with config: model='/disk2/adam/zhigpt', speculative_config=None, tokenizer='/disk2/adam/zhigpt', skip_tokenizer_init=False, tokenizer_mode=auto, revision=None, override_neuron_config=None, rope_scaling=None, rope_theta=None, tokenizer_revision=None, trust_remote_code=False, dtype=torch.bfloat16, max_seq_len=32768, download_dir=None, load_format=LoadFormat.AUTO, tensor_parallel_size=1, pipeline_parallel_size=1, disable_custom_all_reduce=False, quantization=None, enforce_eager=False, kv_cache_dtype=auto, quantization_param_path=None, device_config=cuda, decoding_config=DecodingConfig(guided_decoding_backend='outlines'), observability_config=ObservabilityConfig(otlp_traces_endpoint=None, collect_model_forward_time=False, collect_model_execute_time=False), seed=0, served_model_name=/disk2/adam/zhigpt, use_v2_block_manager=False, num_scheduler_steps=1, multi_step_stream_outputs=False, enable_prefix_caching=False, use_async_output_proc=True, use_cached_outputs=False, mm_processor_kwargs=None)
INFO 12-09 11:20:27 model_runner.py:1014] Starting to load model /disk2/adam/zhigpt...
Loading safetensors checkpoint shards:   0% Completed | 0/9 [00:00<?, ?it/s]
Loading safetensors checkpoint shards:  11% Completed | 1/9 [00:00<00:01,  4.57it/s]
Loading safetensors checkpoint shards:  22% Completed | 2/9 [00:00<00:01,  3.98it/s]
Loading safetensors checkpoint shards:  33% Completed | 3/9 [00:00<00:01,  4.71it/s]
Loading safetensors checkpoint shards:  44% Completed | 4/9 [00:00<00:01,  4.68it/s]
Loading safetensors checkpoint shards:  56% Completed | 5/9 [00:01<00:00,  4.47it/s]
Loading safetensors checkpoint shards:  67% Completed | 6/9 [00:01<00:00,  4.98it/s]
Loading safetensors checkpoint shards:  78% Completed | 7/9 [00:01<00:00,  4.85it/s]
Loading safetensors checkpoint shards:  89% Completed | 8/9 [00:01<00:00,  4.61it/s]
Loading safetensors checkpoint shards: 100% Completed | 9/9 [00:01<00:00,  4.47it/s]
Loading safetensors checkpoint shards: 100% Completed | 9/9 [00:01<00:00,  4.57it/s]

INFO 12-09 11:20:29 model_runner.py:1025] Loading model weights took 14.2487 GB
INFO LMCache: Initializing local-only (cpu) backend [2024-12-09 11:20:29,338] -- /usr/local/lib/python3.11/site-packages/lmcache/storage_backend/__init__.py:28
INFO LMCache: Using pinned cpu memory: False [2024-12-09 11:20:29,339] -- /usr/local/lib/python3.11/site-packages/lmcache/storage_backend/local_backend.py:56
DEBUG LMCache: Current storage backend type <class 'lmcache.storage_backend.local_backend.LMCLocalBackend'> [2024-12-09 11:20:29,339] -- /usr/local/lib/python3.11/site-packages/lmcache/cache_engine.py:35
INFO 12-09 11:20:36 gpu_executor.py:122] # GPU blocks: 2099, # CPU blocks: 4681
INFO 12-09 11:20:38 model_runner.py:1329] Capturing the model for CUDA graphs. This may lead to unexpected consequences if the model is not static. To run the model in eager mode, set 'enforce_eager=True' or use '--enforce-eager' in the CLI.
INFO 12-09 11:20:38 model_runner.py:1333] CUDA graphs can take additional 1~3 GiB memory per GPU. If you are running out of memory, consider decreasing `gpu_memory_utilization` or enforcing eager mode. You can also reduce the `max_num_seqs` as needed to decrease memory usage.
INFO 12-09 11:20:50 model_runner.py:1456] Graph capturing finished in 12 secs.
-------------- Pre-computing KV cache for the chunks -------------------
Processed prompts:   0%|                                                                                | 0/1 [00:00<?, ?it/s, est. speed input: 0.00 toks/s, output: 0.00 toks/s]INFO LMCache: KV cache retrieving mode: RetrieveStatus.PREFILL [2024-12-09 11:20:50,497] -- /usr/local/lib/python3.11/site-packages/lmcache_vllm/vllm_injection.py:47
INFO LMCache: Using default batched implementation of the get() method [2024-12-09 11:20:50,498] -- /usr/local/lib/python3.11/site-packages/lmcache/storage_backend/abstract_backend.py:108
INFO LMCache: Retrieved 0 chunks [2024-12-09 11:20:50,498] -- /usr/local/lib/python3.11/site-packages/lmcache/cache_engine.py:382
DEBUG LMCache: Returning the original input! [2024-12-09 11:20:50,498] -- /usr/local/lib/python3.11/site-packages/lmcache_vllm/vllm_adapter.py:640
INFO LMCache: KV cache saving mode: [<StoreStatus.PREFILL: 1>] [2024-12-09 11:20:50,638] -- /usr/local/lib/python3.11/site-packages/lmcache_vllm/vllm_injection.py:126
INFO LMCache: Using default batched implementation of the put() method [2024-12-09 11:20:50,656] -- /usr/local/lib/python3.11/site-packages/lmcache/storage_backend/abstract_backend.py:85
INFO LMCache: Stored/updated 3 chunks, total time 0.00s, make chunks time 0.00s [2024-12-09 11:20:50,656] -- /usr/local/lib/python3.11/site-packages/lmcache/cache_engine.py:311
DEBUG LMCache: Store skips 0 tokens and then stores 648 tokens [2024-12-09 11:20:50,656] -- /usr/local/lib/python3.11/site-packages/lmcache_vllm/vllm_adapter.py:466
Processed prompts: 100%|███████████████████████████████████████████████████████████████████████████| 1/1 [00:00<00:00,  4.89it/s, est. speed input: 3172.65 toks/s, output: 4.90 toks/s]
Processed prompts:   0%|                                                                                | 0/1 [00:00<?, ?it/s, est. speed input: 0.00 toks/s, output: 0.00 toks/s]INFO LMCache: KV cache retrieving mode: RetrieveStatus.PREFILL [2024-12-09 11:20:50,708] -- /usr/local/lib/python3.11/site-packages/lmcache_vllm/vllm_injection.py:47
INFO LMCache: Using default batched implementation of the get() method [2024-12-09 11:20:50,708] -- /usr/local/lib/python3.11/site-packages/lmcache/storage_backend/abstract_backend.py:108
INFO LMCache: Retrieved 0 chunks [2024-12-09 11:20:50,708] -- /usr/local/lib/python3.11/site-packages/lmcache/cache_engine.py:382
DEBUG LMCache: Returning the original input! [2024-12-09 11:20:50,709] -- /usr/local/lib/python3.11/site-packages/lmcache_vllm/vllm_adapter.py:640
INFO LMCache: KV cache saving mode: [<StoreStatus.PREFILL: 1>] [2024-12-09 11:20:50,944] -- /usr/local/lib/python3.11/site-packages/lmcache_vllm/vllm_injection.py:126
INFO LMCache: Using default batched implementation of the put() method [2024-12-09 11:20:50,965] -- /usr/local/lib/python3.11/site-packages/lmcache/storage_backend/abstract_backend.py:85
INFO LMCache: Stored/updated 5 chunks, total time 0.00s, make chunks time 0.00s [2024-12-09 11:20:50,965] -- /usr/local/lib/python3.11/site-packages/lmcache/cache_engine.py:311
DEBUG LMCache: Store skips 0 tokens and then stores 1213 tokens [2024-12-09 11:20:50,965] -- /usr/local/lib/python3.11/site-packages/lmcache_vllm/vllm_adapter.py:466
Processed prompts: 100%|███████████████████████████████████████████████████████████████████████████| 1/1 [00:00<00:00,  2.53it/s, est. speed input: 3076.54 toks/s, output: 2.54 toks/s]
Running the real query here!
Processed prompts:   0%|                                                                                | 0/1 [00:00<?, ?it/s, est. speed input: 0.00 toks/s, output: 0.00 toks/s]INFO LMCache: KV cache retrieving mode: RetrieveStatus.PREFILL [2024-12-09 11:20:51,110] -- /usr/local/lib/python3.11/site-packages/lmcache_vllm/vllm_injection.py:47
INFO LMCache: Using default batched implementation of the get() method [2024-12-09 11:20:51,111] -- /usr/local/lib/python3.11/site-packages/lmcache/storage_backend/abstract_backend.py:108
INFO LMCache: Retrieved 0 chunks [2024-12-09 11:20:51,111] -- /usr/local/lib/python3.11/site-packages/lmcache/cache_engine.py:382
DEBUG LMCache: Returning the original input! [2024-12-09 11:20:51,111] -- /usr/local/lib/python3.11/site-packages/lmcache_vllm/vllm_adapter.py:640
INFO LMCache: KV cache saving mode: [<StoreStatus.PREFILL: 1>] [2024-12-09 11:20:51,493] -- /usr/local/lib/python3.11/site-packages/lmcache_vllm/vllm_injection.py:126
INFO LMCache: Using default batched implementation of the put() method [2024-12-09 11:20:51,523] -- /usr/local/lib/python3.11/site-packages/lmcache/storage_backend/abstract_backend.py:85
INFO LMCache: Stored/updated 8 chunks, total time 0.00s, make chunks time 0.00s [2024-12-09 11:20:51,523] -- /usr/local/lib/python3.11/site-packages/lmcache/cache_engine.py:311
DEBUG LMCache: Store skips 0 tokens and then stores 1894 tokens [2024-12-09 11:20:51,524] -- /usr/local/lib/python3.11/site-packages/lmcache_vllm/vllm_adapter.py:466
Processed prompts: 100%|██████████████████████████████████████████████████████████████████████████| 1/1 [00:00<00:00,  1.17it/s, est. speed input: 2215.10 toks/s, output: 14.03 toks/s]
Newly generated text: ' This document mainly talks about ffmpeg, a video converter.'
DEBUG LMCache: Closing LMCache Engine [2024-12-09 11:20:51,963] -- /usr/local/lib/python3.11/site-packages/lmcache_vllm/vllm_adapter.py:229
INFO LMCache: Closed the put worker in local backend [2024-12-09 11:20:51,964] -- /usr/local/lib/python3.11/site-packages/lmcache/storage_backend/local_backend.py:208

The above is the output log. You can see that generate after precompute is still Retrieved 0 chunks
INFO LMCache: Retrieved 0 chunks [2024-12-09 11:20:51,111] -- /usr/local/lib/python3.11/site-packages/lmcache/cache_engine.py:382

Hey @darren-qiu , we do have some code modifications in vllm/model_executor/models/llama.py (see https://github.com/LMCache/lmcache-vllm/blob/dev/lmcache_vllm/models/llama.py). So if Qwen uses a different model architecture than llama, it may not work.
You can see what we changed in the llama.py by searching for the comment "# Injection for CacheBlend" in https://github.com/LMCache/lmcache-vllm/blob/dev/lmcache_vllm/models/llama.py


⚠ Bofrost.fr has degraded performance

In 205afc2, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1084 ms

Resolved: Bofrost.fr performance has improved in a952ab9 after 13 minutes.


Added new Forked and Star count feature

close: #320
This new feature will tell the new contributors the size of community and will encourage them to contribute and actively participate more in improving the CARE.
It will show the combine counts of forked and start count of all repositories of CARE at once.

@rithviknishad Is this okay or do you want to suggest some changes

@rithviknishad I have made changes please review it.


Adding gnosis and chiado

Motivation
Gnosis mainnet and Chiado testnet
Solution
Adding Gnosis mainnet and Chiado testnet genesis hashes
Related PRs

https://github.com/gakonst/ethers-rs/pull/1809
https://github.com/gakonst/ethers-rs/pull/1811

merging this as is and bump ethers separately once those PRs got merged


Linux build

Bash version of build scripts.
MT_CMAKE="/opt/cmake" bash ./abiproxy/build_release.sh ndk/android-ndk-r16b
bash ./build_release.sh apk/vanilla.apk v0.50 ndk/android-ndk-r21e

The result goes to build/io.kamihama.magiatranslate.v0.50.apk
Interactive input is removed, force-overwrite may be disabled with argv[4] != true
Custom path to system binaries may be provided with MT_ env variables
Assuming version bumps:
android-ndk-r21d -> android-ndk-r21e
apktool_2.4.1 -> apktool_2.5.0
Pillow==8.0.1 -> Pillow>=8.3.1 (or whatever is available)
Signing algo adjusted to SHA512
armeabi-v7a support dropped due to upcoming changes :madoomed:
Building process tested in following environment:
Gentoo default/linux/amd64/17.1/no-multilib
PYTHON_TARGETS: python3_8
app-shells/bash 5.1_p8
dev-util/cmake 3.21.0
sys-libs/ncurses-compat 6.2 ※ ndk requires libncurses5
dev-util/ninja 1.10.2-r1
dev-java/openjdk-bin 8.292_p10 ※ java, jarsigner
dev-lang/python 3.8.11 ※ newer version breaks things
dev-python/pillow 8.3.1 ※ pip-installed didn't work for some reason

The app was successfully built and confirmed to work in:

Bluestacks4 64bit [android Nougat]
Memu 64bit [android 7.1]

apk v2.3.8 for testing

This will be merged upon the release of the 2.3.9 APK.


brushnet is a super easy tool to use, can you do a flux version?

brushnet is a super easy tool to use, can you do a flux version?
brushnet是一个超级好用得工具，会做flux版本得嘛？

Yeah, Flux is good, but it has completely different architecture. The question was already asked.


[test] Temporarily disable Reflection tests on non-macOS

Fix-up for #18966. The change made there was in support of utils/remote-run, which won't run things that are outside of %t, but it broke an internal testing tool at Apple, which doesn't follow symlinks. ~Use a hard link instead, which everything supports.~ Disable the tests on non-macOS for now while I think about this more.

@swift-ci Please test

Build failed
Swift Test OS X Platform
Git Sha - f62b148f52c12937b2b0a74f31e635461734da7a

…curses. I'll have to think harder about this.

@swift-ci Please test

Build failed
Swift Test OS X Platform
Git Sha - f62b148f52c12937b2b0a74f31e635461734da7a

Build failed
Swift Test Linux Platform
Git Sha - f62b148f52c12937b2b0a74f31e635461734da7a

@swift-ci Please test Linux

Build failed
Swift Test Linux Platform
Git Sha - c22939c38b5e296b42f646f08a720ae8ef35b8bf

@swift-ci Please test Linux

Build failed
Swift Test Linux Platform
Git Sha - c22939c38b5e296b42f646f08a720ae8ef35b8bf

Force-merging to bring back internal bots.


Replace Focus block with nn.PixelUnshuffle(2)

Can we use nn.PixelUnshuffle(2) replace the custom Focus block? The difference between the nn.PixelUnshuffle(2) and Focus is the order of output channels, but in my mind, it will not affect model training.

Yes.  Focus  is actually PixelUnshuffle(2) + Conv module