Better documentation interface

Suggestion
Replace api-extractor and api-documenter for a better alternative. Also perhaps remove Jekyll.
Benefit
By switching to TypeDoc (and ditching Jekyll, yay) the documentation will look better and the search will be scoped to every version.
This suggestion is unique

[X] I have searched the issue tracker and did not find an issue describing my suggestion, especially not one that has been rejected.

You may use the editor below to elaborate further.
The subpath exports are not regarded. Probably use typedoc-plugin-external-module-name to fix that.
The documentation will no longer be written in Markdown. It is possible to revert this by using typedoc-plugin-markdown, however it does not look as good as the HTML. Additionally it would need to be converted using Jekyll (as it is currently done. Ugh, what was I thinking?).
Unfortunately we may not be able to use KaTeX. This needs more investigation. But I would doubt anyone needs to write equations in documentation.

Oh, wow. I now realize this requires tremendous effort to integrate everything
together. Plus the possible future effort to convert all fish scripts to
JavaScript, the proposal is almost too much. I will try anyway, but this may get
postponed indefinitely.
The current steps are as follows:

Using the generated files under build directory, and the sub-path exports
in package.json, construct a list of entry points available to the public.
Note that a sub-path export could have no exported file assigned. That is a
mistake to be reported.
Those entry points point to the build directory. Use tsconfig.json to
find the correct source file under the src directory. Note that a built
file could have no source file, or have missing declaration files. That is a
mistake to be reported.
Once we found the source files exported to the public, we will inform the
typedoc-plugin-external-module-name that these files should be aliased.
Then we will call typedoc to generate the documentation. Note that the
aforementioned plugin has a compatibility issue with newer versions of
typedoc. Either the plugin should be rewritten to accommodate for the
breaking change introduced, or forfeit the access to the recent versions of
typedoc for an indefinite length of time awaiting the update. Note that the
last supported version of typedoc does not fully support aggregate exports
(reexports).
Modify the documentation to remove Ruby and Jekyll. My favourite step,
Preceded only by the most burdensome tasks.


Quake 3 arena engines invalid key

Describe the bug
ioquake3 and quake3e give an invalid key error from the key it pulls from steam, restricts single player maps except for demo map
To Reproduce
Steps to reproduce the behaviour:

install quake 3 arena
pick an engine
check options for cd key info

Expected behaviour
cd key should work
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

@FearlessQuality That would most likely be an issue with your cd key and/or how it was entered. There should be a baseq3/q3key file with your key.
I tried the single player just now and it'll show access denied if you haven't started it before. Is that what you are referring to? If so, that just means that you haven't finished the tutorial or the particular tier.
The issue template is there to help diagnose issues, so screenshots should be provided if you are seeing a particular error. If you are seeing "Access Denied" and have not finished the tutorial yet, that is normal behavior.

thanks, didn't realize i had to do intro first before tier 1 unlocked


Science cannot be transmitted through relays

Hmmmm... I wonder if there is another, separate issue from the occlusion issues having to do with science being able to connect.  I seem to remember hearing about a bug in vanilla that sometimes you could use probe control via a relay, but couldn't upload science via relays.  It never caused me grief before because I would always have a big enough antenna with the Communotron 88-88 to call home directly to KSC.  However, now with this mod we're forced to use relays because of the nerfed KSC and occlusion.  Does anyone know if this bug is still a thing in vanilla?  If so, it's a show stopper for this mod (unless we can some how fix it

Hmmmm... I think the problem has been fixed in vanilla but it is a problem with the mod, and I don't think it is due to the occlusion bug.  I've only had the occlusion bug when close to a moon such as Laythe in the Jool system, but not when far out where my higher powered relays are.  However, even after teleporting my vessel right next to one of the relays I can't upload my science.   Here's my mk2 vessel which has a Com-88-88 on board but it isn't open.  It also has integrated transmitters in the Pod and a probe core, so it obviously should be able to reach the relay right next to it.

You can see the relay is connected via map view, and both vessels look like they are connected with a green icon below the compas

Removing the mod allows uploading science without using the Com-88-88:

So... with vanilla, uploading science works through relays.  With CommNext currently, it doesn't appear so.  And I think this is probably separate from the occlusion issues, because it happened while right next to a relay that wasn't experiencing this issue.  Save game below

This should now be fixed in v0.5.1

I believe the bug is back. I have a probe on the mun which is connected to a relay in orbit of the mun and that is connected to a relay in a keo.


Disable dependabot for datafusion major updates, cibuildwheel patch updates

This PR modifies the dependabot configuration to ignore major updates to datafusion (xref https://github.com/dask-contrib/dask-sql/pull/1068), and correctly ignore patch updates to pypa/cibuildwheel.

Codecov Report

Merging #1077 (7717dd7) into main (ec7b456) will decrease coverage by 0.45%.
The diff coverage is n/a.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##             main    #1077      +/-   ##
==========================================
- Coverage   81.32%   80.88%   -0.45%
==========================================
  Files          78       78
  Lines        4381     4379       -2
  Branches      788      780       -8
==========================================
- Hits         3563     3542      -21
- Misses        645      656      +11
- Partials      173      181       +8

Impacted Files
Coverage Δ

dask_sql/integrations/fugue.py
84.44% <0.00%> (-13.34%)
:arrow_down:

dask_sql/physical/rex/core/literal.py
58.09% <0.00%> (-2.86%)
:arrow_down:

dask_sql/physical/rel/logical/window.py
93.56% <0.00%> (-1.76%)
:arrow_down:

dask_sql/physical/rel/logical/join.py
94.44% <0.00%> (-1.59%)
:arrow_down:

dask_sql/physical/utils/statistics.py
89.41% <0.00%> (-1.18%)
:arrow_down:

dask_sql/_version.py
32.76% <0.00%> (-1.13%)
:arrow_down:

dask_sql/physical/rel/custom/predict_model.py
91.66% <0.00%> (-0.23%)
:arrow_down:

dask_sql/utils.py
99.06% <0.00%> (-0.01%)
:arrow_down:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


RPC interface seems to silently ignore too-large numbers

I recently tried to list the unspent inputs in my wallet. Since there's no way I know of to ask for "all of them, mature or not", I typically ask for those with between 0 and<PHONE_NUMBER> confirmations, from any address, mature-or-not, like this:
$ clamd listunspent 0<PHONE_NUMBER>9 | grep amount | wc -l
45

... and that works. But this time I put too many 9's, and it returned an empty list:
$ clamd listunspent 0<PHONE_NUMBER>99
[
]

It seems the extra 9 must have made the integer overflow, probably making it go negative, and so no outputs were found to match.
That's eleven 9's works, and twelve 9's doesn't.
Indeed, it's at 2^31 that the issue first happens:
$ clamd listunspent 0 $((2**31 - 1)) | grep amount | wc -l
47

$ clamd listunspent 0 $((2**31)) | grep amount | wc -l
0

In the RPCTypeCheck method @ https://github.com/nochowderforyou/clams/blob/master/src/rpcserver.cpp#L45
string err = strprintf("Expected type %s, got %s",
                                   Value_type_name[t], Value_type_name[v.type()]);
            throw JSONRPCError(RPC_TYPE_ERROR, err);

It appears this bug will display odd/overflow behavior with any RPC command executed with the standard int_type check?
I would assume fixing the call to *.type() might fix the underlying error as opposed to injecting additional checks into the listunspent method itself.

Ref: https://github.com/bitcoin/bitcoin/issues/6765

This is fixed in the update from json_spirit to UniValue.
https://github.com/nochowderforyou/clams/pull/235
Is the pull request but has not been fully tested yet.
createrawtransaction and signrawtransaction especially need to be tested still.

This looks fixed so I'm going to close it. The test numbers you see here are 31 signed bits filled and +1.

$ cct listunspent<PHONE_NUMBER>
[
]
$ cct getblockbynumber<PHONE_NUMBER>
error code: -1
error message: Block number out of range.
$ cct listunspent<PHONE_NUMBER>
error code: -1
error message: JSON integer out of range
$ cct getblockbynumber<PHONE_NUMBER>
error code: -1
error message: JSON integer out of range

I'll try and test createrawtransaction and signrawtransaction soon


Small -nocolor fix

Moved the content of the line 14 after the check for "-nocolor" launch parametter because  it kept changing the output color even if the "-nocolor" was used.
Before:

After:

Good catch.


Error: Post "http://<IP_ADDRESS>:11434/api/chat": read tcp <IP_ADDRESS>:59108-><IP_ADDRESS>:11434: wsarecv: An existing connection was forcibly closed by the remote host.

here is my app.log:
time=2024-04-11T19:53:53.911+08:00 level=INFO source=logging.go:45 msg="ollama app started"
time=2024-04-11T19:53:53.940+08:00 level=DEBUG source=lifecycle.go:32 msg="starting callback loop"
time=2024-04-11T19:53:53.940+08:00 level=DEBUG source=store.go:61 msg="loaded existing store C:\Users\17900\AppData\Local\Ollama\config.json - ID: ef96d596-af07-43a7-97e2-f6af540c5021"
time=2024-04-11T19:53:53.940+08:00 level=DEBUG source=lifecycle.go:66 msg="Not first time, skipping first run notification"
time=2024-04-11T19:53:53.941+08:00 level=DEBUG source=server.go:134 msg="heartbeat from server: Head "http://<IP_ADDRESS>:11434/\": dial tcp <IP_ADDRESS>:11434: connectex: No connection could be made because the target machine actively refused it."
time=2024-04-11T19:53:53.941+08:00 level=INFO source=server.go:135 msg="unable to connect to server"
time=2024-04-11T19:53:53.947+08:00 level=INFO source=server.go:91 msg="started ollama server with pid 7836"
time=2024-04-11T19:53:53.947+08:00 level=INFO source=server.go:93 msg="ollama server logs C:\Users\17900\AppData\Local\Ollama\server.log"
time=2024-04-11T19:53:53.947+08:00 level=DEBUG source=eventloop.go:24 msg="starting event handling loop"
time=2024-04-11T19:53:56.952+08:00 level=DEBUG source=updater.go:73 msg="checking for available update" requestURL="https://ollama.com/api/update?arch=amd64&nonce=4ubr2F5IgZhBzSseU_H9iQ&os=windows&ts=1712836436&version=0.1.31"
time=2024-04-11T19:53:58.123+08:00 level=DEBUG source=updater.go:82 msg="check update response 204 (current version is up to date)"
time=2024-04-11T19:54:06.001+08:00 level=WARN source=server.go:113 msg="server crash 1 - exit code<PHONE_NUMBER> - respawning"
time=2024-04-11T19:54:06.509+08:00 level=ERROR source=server.go:116 msg="failed to restart server exec: already started"
time=2024-04-11T19:54:07.516+08:00 level=WARN source=server.go:113 msg="server crash 2 - exit code<PHONE_NUMBER> - respawning"
time=2024-04-11T19:54:08.022+08:00 level=ERROR source=server.go:116 msg="failed to restart server exec: already started"
time=2024-04-11T19:54:10.031+08:00 level=WARN source=server.go:113 msg="server crash 3 - exit code<PHONE_NUMBER> - respawning"
time=2024-04-11T19:54:10.536+08:00 level=ERROR source=server.go:116 msg="failed to restart server exec: already started"
time=2024-04-11T19:54:12.217+08:00 level=DEBUG source=logging_windows.go:12 msg="viewing logs with start C:\Users\17900\AppData\Local\Ollama"
time=2024-04-11T19:54:13.540+08:00 level=WARN source=server.go:113 msg="server crash 4 - exit code<PHONE_NUMBER> - respawning"
time=2024-04-11T19:54:14.052+08:00 level=ERROR source=server.go:116 msg="failed to restart server exec: already started"
time=2024-04-11T19:54:18.066+08:00 level=WARN source=server.go:113 msg="server crash 5 - exit code<PHONE_NUMBER> - respawning"
time=2024-04-11T19:54:18.573+08:00 level=ERROR source=server.go:116 msg="failed to restart server exec: already started"
time=2024-04-11T19:54:23.575+08:00 level=WARN source=server.go:113 msg="server crash 6 - exit code<PHONE_NUMBER> - respawning"
time=2024-04-11T19:54:24.081+08:00 level=ERROR source=server.go:116 msg="failed to restart server exec: already started"
time=2024-04-11T19:54:30.085+08:00 level=WARN source=server.go:113 msg="server crash 7 - exit code<PHONE_NUMBER> - respawning"
time=2024-04-11T19:54:30.592+08:00 level=ERROR source=server.go:116 msg="failed to restart server exec: already started"
time=2024-04-11T19:54:37.604+08:00 level=WARN source=server.go:113 msg="server crash 8 - exit code<PHONE_NUMBER> - respawning"
time=2024-04-11T19:54:38.106+08:00 level=ERROR source=server.go:116 msg="failed to restart server exec: already started"
time=2024-04-11T19:54:46.117+08:00 level=WARN source=server.go:113 msg="server crash 9 - exit code<PHONE_NUMBER> - respawning"
time=2024-04-11T19:54:46.626+08:00 level=ERROR source=server.go:116 msg="failed to restart server exec: already started"
time=2024-04-11T19:54:55.632+08:00 level=WARN source=server.go:113 msg="server crash 10 - exit code<PHONE_NUMBER> - respawning"
time=2024-04-11T19:54:56.140+08:00 level=ERROR source=server.go:116 msg="failed to restart server exec: already started"
time=2024-04-11T19:55:06.150+08:00 level=WARN source=server.go:113 msg="server crash 11 - exit code<PHONE_NUMBER> - respawning"
time=2024-04-11T19:55:06.655+08:00 level=ERROR source=server.go:116 msg="failed to restart server exec: already started"
time=2024-04-11T19:55:17.667+08:00 level=WARN source=server.go:113 msg="server crash 12 - exit code<PHONE_NUMBER> - respawning"
time=2024-04-11T19:55:18.177+08:00 level=ERROR source=server.go:116 msg="failed to restart server exec: already started"
time=2024-04-11T19:55:30.185+08:00 level=WARN source=server.go:113 msg="server crash 13 - exit code<PHONE_NUMBER> - respawning"
time=2024-04-11T19:55:30.693+08:00 level=ERROR source=server.go:116 msg="failed to restart server exec: already started"
time=2024-04-11T19:55:43.694+08:00 level=WARN source=server.go:113 msg="server crash 14 - exit code<PHONE_NUMBER> - respawning"
time=2024-04-11T19:55:44.205+08:00 level=ERROR source=server.go:116 msg="failed to restart server exec: already started"
time=2024-04-11T19:55:58.210+08:00 level=WARN source=server.go:113 msg="server crash 15 - exit code<PHONE_NUMBER> - respawning"
time=2024-04-11T19:55:58.718+08:00 level=ERROR source=server.go:116 msg="failed to restart server exec: already started"
time=2024-04-11T19:56:06.457+08:00 level=DEBUG source=eventloop.go:148 msg="unmanaged app message, lParm: 0x204"
time=2024-04-11T19:56:07.035+08:00 level=DEBUG source=logging_windows.go:12 msg="viewing logs with start C:\Users\17900\AppData\Local\Ollama"
how to fix it?thanks

I encounter similar problems after I shut my PC down and start it up again the next day. Starting it up again the next day, I can see Ollama running, but running any command throws that error.

The only way I have been able to solve the issues it to kill the process that is actively holding the port and restarting Ollama.

Unfortunately it looks like your server is crashing.  Can you share your server.log so we can see why?

Unfortunately it looks like your server is crashing. Can you share your server.log so we can see why?

time=2024-04-16T09:51:41.678+08:00 level=INFO source=gpu.go:115 msg="Detecting GPU type"
time=2024-04-16T09:51:41.678+08:00 level=INFO source=gpu.go:265 msg="Searching for GPU management library cudart64_*.dll"
time=2024-04-16T09:51:41.678+08:00 level=DEBUG source=gpu.go:283 msg="gpu management search paths: ...
time=2024-04-16T09:51:41.688+08:00 level=INFO source=gpu.go:311 msg="Discovered GPU libraries: [C:\Users\17900\AppData\Local\Programs\Ollama\cudart64_110.dll]"
my GPU break,i just delete it,then everything is ok.

 Starting it up again the next day, I can see Ollama running, but running any command throws that error.
The only way I have been able to solve the issues is to kill the process that is actively holding the port and restarting Ollama.

set OLLAMA_DEBUG=1,then look your sever.log and app.log,i think we are not same mistake.show it,maybe someone can help you

@liquorLiu that log doesn't seem to contain a crash or any error messages.    Let's try a different approach to try to understand what's going wrong.
Please Quit the tray app, and in a powershell terminal run:
$env:OLLAMA_DEBUG="1"
ollama serve 2>&1 | % ToString | Tee-Object server.log

Assuming that doesn't immediately crash and give you back a prompt, in another terminal window run
ollama run llama2 hello

Then in the first window hit <ctrl>-c and attach the server.log to this issue so I can take a look at a full run.
If the ollama serve does immediately crash, share what you see in the terminal, and server.log if it's not empty.

Hi @dhiltgen, I think I may be experiencing the same issue as @liquorLiu, based on the fact that I experienced the same error message in the post title, and well as the same error in app.log and no errors in server.log. Before I applied the steps in your most recent post, here is what my log files looked like:
app.log:
time=2024-04-19T12:43:51.243-07:00 level=INFO source=logging.go:45 msg="ollama app started"
time=2024-04-19T12:43:51.259-07:00 level=INFO source=server.go:167 msg="unable to connect to server"
time=2024-04-19T12:43:51.262-07:00 level=INFO source=server.go:123 msg="started ollama server with pid 2520"
time=2024-04-19T12:43:51.262-07:00 level=INFO source=server.go:125 msg="ollama server logs C:\\Users\\timfd\\AppData\\Local\\Ollama\\server.log"
time=2024-04-19T12:43:53.435-07:00 level=WARN source=server.go:145 msg="server crash 1 - exit code<PHONE_NUMBER> - respawning"
time=2024-04-19T12:43:53.949-07:00 level=ERROR source=server.go:148 msg="failed to restart server exec: already started"
time=2024-04-19T12:43:54.963-07:00 level=WARN source=server.go:145 msg="server crash 2 - exit code<PHONE_NUMBER> - respawning"
time=2024-04-19T12:43:55.475-07:00 level=ERROR source=server.go:148 msg="failed to restart server exec: already started"
time=2024-04-19T12:43:57.486-07:00 level=WARN source=server.go:145 msg="server crash 3 - exit code<PHONE_NUMBER> - respawning"

server.log:
time=2024-04-19T12:43:51.304-07:00 level=INFO source=images.go:817 msg="total blobs: 7"
time=2024-04-19T12:43:51.304-07:00 level=INFO source=images.go:824 msg="total unused blobs removed: 0"
time=2024-04-19T12:43:51.305-07:00 level=INFO source=routes.go:1143 msg="Listening on <IP_ADDRESS>:11434 (version 0.1.32)"
time=2024-04-19T12:43:51.306-07:00 level=INFO source=payload.go:28 msg="extracting embedded files" dir=C:\Users\timfd\AppData\Local\Temp\ollama3627894243\runners
time=2024-04-19T12:43:51.546-07:00 level=INFO source=payload.go:41 msg="Dynamic LLM libraries [cpu cpu_avx cpu_avx2 cuda_v11.3 rocm_v5.7]"
[GIN] 2024/04/19 - 12:43:51 | 200 |            0s |       <IP_ADDRESS> | HEAD     "/"
[GIN] 2024/04/19 - 12:43:51 | 200 |       535.8µs |       <IP_ADDRESS> | POST     "/api/show"
time=2024-04-19T12:43:53.344-07:00 level=INFO source=gpu.go:121 msg="Detecting GPU type"
time=2024-04-19T12:43:53.344-07:00 level=INFO source=gpu.go:268 msg="Searching for GPU management library cudart64_*.dll"
time=2024-04-19T12:43:53.349-07:00 level=INFO source=gpu.go:314 msg="Discovered GPU libraries: [C:\\Users\\timfd\\AppData\\Local\\Programs\\Ollama\\cudart64_110.dll C:\\Program Files (x86)\\NVIDIA Corporation\\PhysX\\Common\\cudart64_65.dll]"

I ran the two lines you provided for PowerShell above, it didn't crash though I'm not sure it ran correctly, it added this to my server.log:
failed to get console mode for stdout: The handle is invalid.
failed to get console mode for stderr: The handle is invalid.
time=2024-04-19T12:45:46.523-07:00 level=INFO source=images.go:817 msg="total blobs: 7"
time=2024-04-19T12:45:46.524-07:00 level=INFO source=images.go:824 msg="total unused blobs removed: 0"
time=2024-04-19T12:45:46.524-07:00 level=INFO source=routes.go:1143 msg="Listening on <IP_ADDRESS>:11434 (version 0.1.32)"
time=2024-04-19T12:45:46.534-07:00 level=INFO source=payload.go:28 msg="extracting embedded files" dir=C:\Users\timfd\AppData\Local\Temp\ollama1521772082\runners
time=2024-04-19T12:45:46.534-07:00 level=DEBUG source=payload.go:160 msg=extracting variant=cpu file=build/windows/amd64/cpu/bin/llama.dll.gz
time=2024-04-19T12:45:46.534-07:00 level=DEBUG source=payload.go:160 msg=extracting variant=cpu file=build/windows/amd64/cpu/bin/ollama_llama_server.exe.gz
time=2024-04-19T12:45:46.534-07:00 level=DEBUG source=payload.go:160 msg=extracting variant=cpu_avx file=build/windows/amd64/cpu_avx/bin/llama.dll.gz
time=2024-04-19T12:45:46.534-07:00 level=DEBUG source=payload.go:160 msg=extracting variant=cpu_avx file=build/windows/amd64/cpu_avx/bin/ollama_llama_server.exe.gz
time=2024-04-19T12:45:46.534-07:00 level=DEBUG source=payload.go:160 msg=extracting variant=cpu_avx2 file=build/windows/amd64/cpu_avx2/bin/llama.dll.gz
time=2024-04-19T12:45:46.534-07:00 level=DEBUG source=payload.go:160 msg=extracting variant=cpu_avx2 file=build/windows/amd64/cpu_avx2/bin/ollama_llama_server.exe.gz
time=2024-04-19T12:45:46.534-07:00 level=DEBUG source=payload.go:160 msg=extracting variant=cuda_v11.3 file=build/windows/amd64/cuda_v11.3/bin/llama.dll.gz
time=2024-04-19T12:45:46.534-07:00 level=DEBUG source=payload.go:160 msg=extracting variant=cuda_v11.3 file=build/windows/amd64/cuda_v11.3/bin/ollama_llama_server.exe.gz
time=2024-04-19T12:45:46.534-07:00 level=DEBUG source=payload.go:160 msg=extracting variant=rocm_v5.7 file=build/windows/amd64/rocm_v5.7/bin/llama.dll.gz
time=2024-04-19T12:45:46.534-07:00 level=DEBUG source=payload.go:160 msg=extracting variant=rocm_v5.7 file=build/windows/amd64/rocm_v5.7/bin/ollama_llama_server.exe.gz
time=2024-04-19T12:45:46.772-07:00 level=DEBUG source=payload.go:68 msg="availableServers : found" file=C:\Users\timfd\AppData\Local\Temp\ollama1521772082\runners\cpu
time=2024-04-19T12:45:46.772-07:00 level=DEBUG source=payload.go:68 msg="availableServers : found" file=C:\Users\timfd\AppData\Local\Temp\ollama1521772082\runners\cpu_avx
time=2024-04-19T12:45:46.772-07:00 level=DEBUG source=payload.go:68 msg="availableServers : found" file=C:\Users\timfd\AppData\Local\Temp\ollama1521772082\runners\cpu_avx2
time=2024-04-19T12:45:46.772-07:00 level=DEBUG source=payload.go:68 msg="availableServers : found" file=C:\Users\timfd\AppData\Local\Temp\ollama1521772082\runners\cuda_v11.3
time=2024-04-19T12:45:46.772-07:00 level=DEBUG source=payload.go:68 msg="availableServers : found" file=C:\Users\timfd\AppData\Local\Temp\ollama1521772082\runners\rocm_v5.7
time=2024-04-19T12:45:46.772-07:00 level=INFO source=payload.go:41 msg="Dynamic LLM libraries [cpu_avx cpu_avx2 cuda_v11.3 rocm_v5.7 cpu]"
time=2024-04-19T12:45:46.772-07:00 level=DEBUG source=payload.go:42 msg="Override detection logic by setting OLLAMA_LLM_LIBRARY"

After that I ran the command ollama run llama3 hello, this is what was added to server.log:
[GIN] 2024/04/19 - 12:49:13 | 200 |            0s |       <IP_ADDRESS> | HEAD     "/"
[GIN] 2024/04/19 - 12:49:13 | 200 |      1.0441ms |       <IP_ADDRESS> | POST     "/api/show"
time=2024-04-19T12:49:13.479-07:00 level=DEBUG source=gguf.go:57 msg="model = &llm.gguf{containerGGUF:(*llm.containerGGUF)(0xc000471180), kv:llm.KV{}, tensors:[]*llm.Tensor(nil), parameters:0x0}"
time=2024-04-19T12:49:15.061-07:00 level=DEBUG source=gguf.go:193 msg="general.architecture = llama"
time=2024-04-19T12:49:15.065-07:00 level=INFO source=gpu.go:121 msg="Detecting GPU type"
time=2024-04-19T12:49:15.065-07:00 level=INFO source=gpu.go:268 msg="Searching for GPU management library cudart64_*.dll"
time=2024-04-19T12:49:15.065-07:00 level=DEBUG source=gpu.go:286 msg="gpu management search paths: [C:\\Users\\timfd\\AppData\\Local\\Programs\\Ollama\\cudart64_*.dll c:\\Program Files\\NVIDIA GPU Computing Toolkit\\CUDA\\v*\\bin\\cudart64_*.dll C:\\Program Files (x86)\\Common Files\\Oracle\\Java\\javapath\\cudart64_*.dll* C:\\Program Files\\Oculus\\Support\\oculus-runtime\\cudart64_*.dll* C:\\Windows\\system32\\cudart64_*.dll* C:\\Windows\\cudart64_*.dll* C:\\Windows\\System32\\Wbem\\cudart64_*.dll* C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\cudart64_*.dll* C:\\Windows\\System32\\OpenSSH\\cudart64_*.dll* C:\\Program Files (x86)\\NVIDIA Corporation\\PhysX\\Common\\cudart64_*.dll* C:\\Program Files\\NVIDIA Corporation\\NVIDIA NvDLISR\\cudart64_*.dll* C:\\Program Files\\dotnet\\cudart64_*.dll* C:\\Program Files (x86)\\AOMEI\\AOMEI Backupper\\7.3.1\\cudart64_*.dll* C:\\Program Files\\Mullvad VPN\\resources\\cudart64_*.dll* C:\\Program Files\\Docker\\Docker\\resources\\bin\\cudart64_*.dll* C:\\Program Files\\Python311\\Scripts\\cudart64_*.dll* C:\\Users\\timfd\\AppData\\Local\\Microsoft\\WindowsApps\\cudart64_*.dll* C:\\Users\\timfd\\AppData\\Local\\Programs\\Microsoft VS Code\\bin\\cudart64_*.dll* C:\\Program Files\\Python311\\cudart64_*.dll* C:\\Users\\timfd\\AppData\\Local\\Ollama\\cudart64_*.dll* C:\\Users\\timfd\\AppData\\Local\\Programs\\Ollama\\cudart64_*.dll*]"
time=2024-04-19T12:49:15.069-07:00 level=INFO source=gpu.go:314 msg="Discovered GPU libraries: [C:\\Users\\timfd\\AppData\\Local\\Programs\\Ollama\\cudart64_110.dll C:\\Program Files (x86)\\NVIDIA Corporation\\PhysX\\Common\\cudart64_65.dll]"

Please let me know if there is any other information that would be helpful to provide, or if I should post this somewhere else, I'm quite new to all of this.

Hi @dhiltgen, I think I may be experiencing the same issue as @liquorLiu, based on the fact that I experienced the same error message in the post title, and well as the same error in app.log and no errors in server.log. Before I applied the steps in your most recent post, here is what my log files looked like:
app.log:
time=2024-04-19T12:43:51.243-07:00 level=INFO source=logging.go:45 msg="ollama app started"
time=2024-04-19T12:43:51.259-07:00 level=INFO source=server.go:167 msg="unable to connect to server"
time=2024-04-19T12:43:51.262-07:00 level=INFO source=server.go:123 msg="started ollama server with pid 2520"
time=2024-04-19T12:43:51.262-07:00 level=INFO source=server.go:125 msg="ollama server logs C:\\Users\\timfd\\AppData\\Local\\Ollama\\server.log"
time=2024-04-19T12:43:53.435-07:00 level=WARN source=server.go:145 msg="server crash 1 - exit code<PHONE_NUMBER> - respawning"
time=2024-04-19T12:43:53.949-07:00 level=ERROR source=server.go:148 msg="failed to restart server exec: already started"
time=2024-04-19T12:43:54.963-07:00 level=WARN source=server.go:145 msg="server crash 2 - exit code<PHONE_NUMBER> - respawning"
time=2024-04-19T12:43:55.475-07:00 level=ERROR source=server.go:148 msg="failed to restart server exec: already started"
time=2024-04-19T12:43:57.486-07:00 level=WARN source=server.go:145 msg="server crash 3 - exit code<PHONE_NUMBER> - respawning"

server.log:
time=2024-04-19T12:43:51.304-07:00 level=INFO source=images.go:817 msg="total blobs: 7"
time=2024-04-19T12:43:51.304-07:00 level=INFO source=images.go:824 msg="total unused blobs removed: 0"
time=2024-04-19T12:43:51.305-07:00 level=INFO source=routes.go:1143 msg="Listening on <IP_ADDRESS>:11434 (version 0.1.32)"
time=2024-04-19T12:43:51.306-07:00 level=INFO source=payload.go:28 msg="extracting embedded files" dir=C:\Users\timfd\AppData\Local\Temp\ollama3627894243\runners
time=2024-04-19T12:43:51.546-07:00 level=INFO source=payload.go:41 msg="Dynamic LLM libraries [cpu cpu_avx cpu_avx2 cuda_v11.3 rocm_v5.7]"
[GIN] 2024/04/19 - 12:43:51 | 200 |            0s |       <IP_ADDRESS> | HEAD     "/"
[GIN] 2024/04/19 - 12:43:51 | 200 |       535.8µs |       <IP_ADDRESS> | POST     "/api/show"
time=2024-04-19T12:43:53.344-07:00 level=INFO source=gpu.go:121 msg="Detecting GPU type"
time=2024-04-19T12:43:53.344-07:00 level=INFO source=gpu.go:268 msg="Searching for GPU management library cudart64_*.dll"
time=2024-04-19T12:43:53.349-07:00 level=INFO source=gpu.go:314 msg="Discovered GPU libraries: [C:\\Users\\timfd\\AppData\\Local\\Programs\\Ollama\\cudart64_110.dll C:\\Program Files (x86)\\NVIDIA Corporation\\PhysX\\Common\\cudart64_65.dll]"

I ran the two lines you provided for PowerShell above, it didn't crash though I'm not sure it ran correctly, it added this to my server.log:
failed to get console mode for stdout: The handle is invalid.
failed to get console mode for stderr: The handle is invalid.
time=2024-04-19T12:45:46.523-07:00 level=INFO source=images.go:817 msg="total blobs: 7"
time=2024-04-19T12:45:46.524-07:00 level=INFO source=images.go:824 msg="total unused blobs removed: 0"
time=2024-04-19T12:45:46.524-07:00 level=INFO source=routes.go:1143 msg="Listening on <IP_ADDRESS>:11434 (version 0.1.32)"
time=2024-04-19T12:45:46.534-07:00 level=INFO source=payload.go:28 msg="extracting embedded files" dir=C:\Users\timfd\AppData\Local\Temp\ollama1521772082\runners
time=2024-04-19T12:45:46.534-07:00 level=DEBUG source=payload.go:160 msg=extracting variant=cpu file=build/windows/amd64/cpu/bin/llama.dll.gz
time=2024-04-19T12:45:46.534-07:00 level=DEBUG source=payload.go:160 msg=extracting variant=cpu file=build/windows/amd64/cpu/bin/ollama_llama_server.exe.gz
time=2024-04-19T12:45:46.534-07:00 level=DEBUG source=payload.go:160 msg=extracting variant=cpu_avx file=build/windows/amd64/cpu_avx/bin/llama.dll.gz
time=2024-04-19T12:45:46.534-07:00 level=DEBUG source=payload.go:160 msg=extracting variant=cpu_avx file=build/windows/amd64/cpu_avx/bin/ollama_llama_server.exe.gz
time=2024-04-19T12:45:46.534-07:00 level=DEBUG source=payload.go:160 msg=extracting variant=cpu_avx2 file=build/windows/amd64/cpu_avx2/bin/llama.dll.gz
time=2024-04-19T12:45:46.534-07:00 level=DEBUG source=payload.go:160 msg=extracting variant=cpu_avx2 file=build/windows/amd64/cpu_avx2/bin/ollama_llama_server.exe.gz
time=2024-04-19T12:45:46.534-07:00 level=DEBUG source=payload.go:160 msg=extracting variant=cuda_v11.3 file=build/windows/amd64/cuda_v11.3/bin/llama.dll.gz
time=2024-04-19T12:45:46.534-07:00 level=DEBUG source=payload.go:160 msg=extracting variant=cuda_v11.3 file=build/windows/amd64/cuda_v11.3/bin/ollama_llama_server.exe.gz
time=2024-04-19T12:45:46.534-07:00 level=DEBUG source=payload.go:160 msg=extracting variant=rocm_v5.7 file=build/windows/amd64/rocm_v5.7/bin/llama.dll.gz
time=2024-04-19T12:45:46.534-07:00 level=DEBUG source=payload.go:160 msg=extracting variant=rocm_v5.7 file=build/windows/amd64/rocm_v5.7/bin/ollama_llama_server.exe.gz
time=2024-04-19T12:45:46.772-07:00 level=DEBUG source=payload.go:68 msg="availableServers : found" file=C:\Users\timfd\AppData\Local\Temp\ollama1521772082\runners\cpu
time=2024-04-19T12:45:46.772-07:00 level=DEBUG source=payload.go:68 msg="availableServers : found" file=C:\Users\timfd\AppData\Local\Temp\ollama1521772082\runners\cpu_avx
time=2024-04-19T12:45:46.772-07:00 level=DEBUG source=payload.go:68 msg="availableServers : found" file=C:\Users\timfd\AppData\Local\Temp\ollama1521772082\runners\cpu_avx2
time=2024-04-19T12:45:46.772-07:00 level=DEBUG source=payload.go:68 msg="availableServers : found" file=C:\Users\timfd\AppData\Local\Temp\ollama1521772082\runners\cuda_v11.3
time=2024-04-19T12:45:46.772-07:00 level=DEBUG source=payload.go:68 msg="availableServers : found" file=C:\Users\timfd\AppData\Local\Temp\ollama1521772082\runners\rocm_v5.7
time=2024-04-19T12:45:46.772-07:00 level=INFO source=payload.go:41 msg="Dynamic LLM libraries [cpu_avx cpu_avx2 cuda_v11.3 rocm_v5.7 cpu]"
time=2024-04-19T12:45:46.772-07:00 level=DEBUG source=payload.go:42 msg="Override detection logic by setting OLLAMA_LLM_LIBRARY"

After that I ran the command ollama run llama3 hello, this is what was added to server.log:
[GIN] 2024/04/19 - 12:49:13 | 200 |            0s |       <IP_ADDRESS> | HEAD     "/"
[GIN] 2024/04/19 - 12:49:13 | 200 |      1.0441ms |       <IP_ADDRESS> | POST     "/api/show"
time=2024-04-19T12:49:13.479-07:00 level=DEBUG source=gguf.go:57 msg="model = &llm.gguf{containerGGUF:(*llm.containerGGUF)(0xc000471180), kv:llm.KV{}, tensors:[]*llm.Tensor(nil), parameters:0x0}"
time=2024-04-19T12:49:15.061-07:00 level=DEBUG source=gguf.go:193 msg="general.architecture = llama"
time=2024-04-19T12:49:15.065-07:00 level=INFO source=gpu.go:121 msg="Detecting GPU type"
time=2024-04-19T12:49:15.065-07:00 level=INFO source=gpu.go:268 msg="Searching for GPU management library cudart64_*.dll"
time=2024-04-19T12:49:15.065-07:00 level=DEBUG source=gpu.go:286 msg="gpu management search paths: [C:\\Users\\timfd\\AppData\\Local\\Programs\\Ollama\\cudart64_*.dll c:\\Program Files\\NVIDIA GPU Computing Toolkit\\CUDA\\v*\\bin\\cudart64_*.dll C:\\Program Files (x86)\\Common Files\\Oracle\\Java\\javapath\\cudart64_*.dll* C:\\Program Files\\Oculus\\Support\\oculus-runtime\\cudart64_*.dll* C:\\Windows\\system32\\cudart64_*.dll* C:\\Windows\\cudart64_*.dll* C:\\Windows\\System32\\Wbem\\cudart64_*.dll* C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\cudart64_*.dll* C:\\Windows\\System32\\OpenSSH\\cudart64_*.dll* C:\\Program Files (x86)\\NVIDIA Corporation\\PhysX\\Common\\cudart64_*.dll* C:\\Program Files\\NVIDIA Corporation\\NVIDIA NvDLISR\\cudart64_*.dll* C:\\Program Files\\dotnet\\cudart64_*.dll* C:\\Program Files (x86)\\AOMEI\\AOMEI Backupper\\7.3.1\\cudart64_*.dll* C:\\Program Files\\Mullvad VPN\\resources\\cudart64_*.dll* C:\\Program Files\\Docker\\Docker\\resources\\bin\\cudart64_*.dll* C:\\Program Files\\Python311\\Scripts\\cudart64_*.dll* C:\\Users\\timfd\\AppData\\Local\\Microsoft\\WindowsApps\\cudart64_*.dll* C:\\Users\\timfd\\AppData\\Local\\Programs\\Microsoft VS Code\\bin\\cudart64_*.dll* C:\\Program Files\\Python311\\cudart64_*.dll* C:\\Users\\timfd\\AppData\\Local\\Ollama\\cudart64_*.dll* C:\\Users\\timfd\\AppData\\Local\\Programs\\Ollama\\cudart64_*.dll*]"
time=2024-04-19T12:49:15.069-07:00 level=INFO source=gpu.go:314 msg="Discovered GPU libraries: [C:\\Users\\timfd\\AppData\\Local\\Programs\\Ollama\\cudart64_110.dll C:\\Program Files (x86)\\NVIDIA Corporation\\PhysX\\Common\\cudart64_65.dll]"

Please let me know if there is any other information that would be helpful to provide, or if I should post this somewhere else, I'm quite new to all of this.

i just remove C:\Users\timfd\AppData\Local\Programs\Ollama\cudart64_110.dll,then everythings is ok,
maybe your gpu break down like me.just use cpu

I have an rx 6600 xt gpu and I tried the HSA_override_gfx environment variable to get ollama use my gpu since my cpu is old and incapable of running models with 7b parameters despite having enough ram and storage. i even tried adding the rocm files from the preview build as provided in the repo https://github.com/brknsoul/ROCmLibs. However, even if I remove the hsa_override variable i keep getting this error:
Error: llama runner process no longer running:<PHONE_NUMBER>
after using the powershell command that was suggested, this is the error log that comes up:
failed to get console mode for stdout: The handle is invalid. failed to get console mode for stderr: The handle is invalid. time=2024-04-20T22:04:24.000+02:00 level=INFO source=images.go:817 msg="total blobs: 180" time=2024-04-20T22:04:24.080+02:00 level=INFO source=images.go:824 msg="total unused blobs removed: 0" time=2024-04-20T22:04:24.132+02:00 level=INFO source=routes.go:1143 msg="Listening on <IP_ADDRESS>:11434 (version 0.1.32)" time=2024-04-20T22:04:24.147+02:00 level=INFO source=payload.go:28 msg="extracting embedded files" dir=C:\Users\mafsa\AppData\Local\Temp\ollama522826981\runners time=2024-04-20T22:04:24.148+02:00 level=DEBUG source=payload.go:160 msg=extracting variant=cpu file=build/windows/amd64/cpu/bin/llama.dll.gz time=2024-04-20T22:04:24.149+02:00 level=DEBUG source=payload.go:160 msg=extracting variant=cpu file=build/windows/amd64/cpu/bin/ollama_llama_server.exe.gz time=2024-04-20T22:04:24.149+02:00 level=DEBUG source=payload.go:160 msg=extracting variant=cpu_avx file=build/windows/amd64/cpu_avx/bin/llama.dll.gz time=2024-04-20T22:04:24.149+02:00 level=DEBUG source=payload.go:160 msg=extracting variant=cpu_avx file=build/windows/amd64/cpu_avx/bin/ollama_llama_server.exe.gz time=2024-04-20T22:04:24.149+02:00 level=DEBUG source=payload.go:160 msg=extracting variant=cpu_avx2 file=build/windows/amd64/cpu_avx2/bin/llama.dll.gz time=2024-04-20T22:04:24.149+02:00 level=DEBUG source=payload.go:160 msg=extracting variant=cpu_avx2 file=build/windows/amd64/cpu_avx2/bin/ollama_llama_server.exe.gz time=2024-04-20T22:04:24.149+02:00 level=DEBUG source=payload.go:160 msg=extracting variant=cuda_v11.3 file=build/windows/amd64/cuda_v11.3/bin/llama.dll.gz time=2024-04-20T22:04:24.149+02:00 level=DEBUG source=payload.go:160 msg=extracting variant=cuda_v11.3 file=build/windows/amd64/cuda_v11.3/bin/ollama_llama_server.exe.gz time=2024-04-20T22:04:24.150+02:00 level=DEBUG source=payload.go:160 msg=extracting variant=rocm_v5.7 file=build/windows/amd64/rocm_v5.7/bin/llama.dll.gz time=2024-04-20T22:04:24.150+02:00 level=DEBUG source=payload.go:160 msg=extracting variant=rocm_v5.7 file=build/windows/amd64/rocm_v5.7/bin/ollama_llama_server.exe.gz time=2024-04-20T22:04:26.645+02:00 level=DEBUG source=payload.go:68 msg="availableServers : found" file=C:\Users\mafsa\AppData\Local\Temp\ollama522826981\runners\cpu time=2024-04-20T22:04:26.645+02:00 level=DEBUG source=payload.go:68 msg="availableServers : found" file=C:\Users\mafsa\AppData\Local\Temp\ollama522826981\runners\cpu_avx time=2024-04-20T22:04:26.645+02:00 level=DEBUG source=payload.go:68 msg="availableServers : found" file=C:\Users\mafsa\AppData\Local\Temp\ollama522826981\runners\cpu_avx2 time=2024-04-20T22:04:26.645+02:00 level=DEBUG source=payload.go:68 msg="availableServers : found" file=C:\Users\mafsa\AppData\Local\Temp\ollama522826981\runners\cuda_v11.3 time=2024-04-20T22:04:26.645+02:00 level=DEBUG source=payload.go:68 msg="availableServers : found" file=C:\Users\mafsa\AppData\Local\Temp\ollama522826981\runners\rocm_v5.7 time=2024-04-20T22:04:26.645+02:00 level=INFO source=payload.go:41 msg="Dynamic LLM libraries [rocm_v5.7 cpu cpu_avx cpu_avx2 cuda_v11.3]" time=2024-04-20T22:04:26.645+02:00 level=DEBUG source=payload.go:42 msg="Override detection logic by setting OLLAMA_LLM_LIBRARY"

@liquorLiu interesting.  So our bundled v11 cuda library didn't work on your system, but removing it so it used the v12(?) version you already had installed fixed the problem, and it is now running on GPU.  Is that correct?  If so, I'm glad we now have a workaround, but I want to understand why this isn't working, since nvidia claims to support backwards compatibility so v11 libraries should work on newer drivers.

Can folks hitting this issue try upgrading to 0.1.33? It looks like at least some of you are likely going to hit #4008 which can be worked around by removing the PhysX directory from your PATH.

Hello, @dhiltgen!
I can can confirm that after 0.1.33 problem with PhysX is still presented (and in some way become even worse). The thing is: after 0.1.33 ollama tends to prefer more recent Nvidia libs, which leads to detecting cudart.dll from PhysX folder (PhysX nstalling alongside drivers and almost always will be selected as preferable in comparison to libs included to portable ollama release from "ollama-windows-amd64.zip").

Please, take a look at PR #4106. You and I almost simultaneously created 2 PRs solving the same problem, but I also added one more important check to the code (presence of three linked Nvidia libraries: cudart, cublas and cubasLt).
Also, in the second commit to PR I adapted your version of anti-PhysX solution into my PR (original version was not drive letter agnostic). I hope you don't mind!

Thanks @alecvern !
We're not sure yet what the right approach is - intentionally skip PhysX, or pivot to the Driver API for discovery of the Nvidia GPUs.  We've reached out to contacts at Nvidia and we're aiming to get closure on this before we cut the next release so we can get past this PhysX problem.

There were a few different topics on this issue, but I believe we've resolved the underlying problems in recent releases.  If anyone is still having problems, please make sure to update to the latest version, and if that doesn't resolve it, please share your server log and I'll re-open the issue.


Add missing "Protocol" to the title

In the content, "boxed protocol types" is used, but it's not used in the title.
I'm not sure if it's intended or not, but it looks missing "Protocol".

Thanks for this PR!
I also discussed this change with @chuckdude and @bjlanier.  I wasn't sure if naming the chapter "Opaque and Boxed Protocol Types" might be misread as "opaque and boxed" modifying "protocol types".  Spelling it out fully as "Opaque Types and Boxed Protocol Types" is a little too long.  They agreed that this change makes sense, and isn't too easy to misread.
They also noted that we want to make sure the URL doesn't change.  I'm pretty sure the URL comes from the filename, not the title — for example, A Swift Tour is at https://docs.swift.org/swift-book/documentation/the-swift-programming-language/guidedtour — but I will confirm when building.

Confirmed the URL path remains /opaquetypes for the chapter we're changing.  Spot-checked the diff in the build product between this PR and 'main' — no unexpected changes to the JSON.  Looks good!


The OpenROAD-Flow repository is closed

Hi, why the OpenROAD-flow repo was closed ?

We are aware of the issue and working to resolve it as quickly as possible.

@rovinski Thanks.

Do we have an ETA on this?

@rashmi2383 unfortunately no ETA at this time. This issue will be closed once it is back up. You can put a watch on this issue to be notified by GitHub when that happens.

A temporary read-only copy is now up at https://github.com/The-OpenROAD-Project/OpenROAD-flow
We are still working on getting the full history restored.

I am seeing some build issues on Ubuntu 18.04 with OpenROAD-flow. Can I open a new issue in this repo?

Is it #482 ?

This is the error:
[INFO][FLOW-0000] using local build method. This will create binaries at tools/build/
[100%] Building yosys
[100%] Building abc/abc-7a98ef0
[100%] Building yosys-filterlib
[100%] Building share/xilinx/brams_init_36.vh
[100%] Building share/xilinx/brams_init_32.vh
[100%] Building share/xilinx/brams_init_18.vh
[100%] Building share/xilinx/brams_init_16.vh
/usr/bin/ld: cannot find -ltcl8.5
[100%] Building share/ice40/brams_init1.vh
[100%] Building share/ice40/brams_init2.vh
collect2: error: ld returned 1 exit status
passes/techmap/Makefile.inc:66: recipe for target 'yosys-filterlib' failed
make: *** [yosys-filterlib] Error 1
make: *** Waiting for unfinished jobs....
ERROR: ABC contains local modifications! Set ABCREV=default in Yosys Makefile!
Makefile:622: recipe for target 'abc/abc-7a98ef0' failed
make: *** [abc/abc-7a98ef0] Error 1
/usr/bin/ld: cannot find -ltcl8.5
collect2: error: ld returned 1 exit status
Makefile:573: recipe for target 'yosys' failed
make: *** [yosys] Error 1
make: *** wait: No child processes.  Stop.

It's looking for tcl8.5 because CentOS 7 is the official platform. If you have tcl8.6 then just replace it in the build script:
sed -i 's/tcl8\.5/tcl8\.6/' build_openroad.sh

If you don't have tcl installed, then install it:
apt-get install tcl-dev

If this doesn't work for you then please open a new issue.

This helped. But I still see the Yosys Makefile error:
ERROR: ABC contains local modifications! Set ABCREV=default in Yosys Makefile!
Makefile:622: recipe for target 'abc/abc-7a98ef0' failed
make: *** [abc/abc-7a98ef0] Error 1
make: *** Waiting for unfinished jobs....

@rashmi2383 please open a new issue, this is not related to the thread.

This is the new area for the flow. https://github.com/The-OpenROAD-Project/OpenROAD-flow-scripts


[QUERY] Is it possible to register different ServiceBus clients in DI with different authentication type

Library name and version
Azure.Messaging.ServiceBus 7.15.0
Query/Question
Hello, we have a scenario that we have several service bus triggers in our Azure function. Some of them need to connect to a service bus using ClientCertificateCredential while one needs to use managed identity. I have this following setup during DI:

services.AddAzureClients(clientBuilder =>
            {
                clientBuilder
                    .AddServiceBusClientWithNamespace("namespace 1")
                    .WithCredential(new ManagedIdentityCredential("managed identity app id"))
                    .WithName("Queue1");

                clientBuilder.AddClient<ServiceBusReceiver, ServiceBusClientOptions>((_, _, provider) =>
                    provider.GetService<IAzureClientFactory<ServiceBusClient>>()
                            .CreateClient("Queue1")
                            .CreateReceiver("queue 1")
                );

                clientBuilder
                    .AddServiceBusClientWithNamespace("namespace 2")
                    .WithCredential(
                        new ClientCertificateCredential(
                                    tenantId: "tenantId",
                                    clientId: "first party app id",
                                    clientCertificate: certificate,
                                    new ClientCertificateCredentialOptions()
                                    {
                                        SendCertificateChain = true,
                                        AuthorityHost = new Uri("https://login.microsoftonline.com/")
                                    })
                        )
                    .WithName("Queue2");

                clientBuilder.AddClient<ServiceBusReceiver, ServiceBusClientOptions>((_, _, provider) =>
                    provider.GetService<IAzureClientFactory<ServiceBusClient>>()
                            .CreateClient("Queue2")
                            .CreateReceiver("queue 2")
                );
            });

However this setup doesnt seem working as the service bus triggers are not able to start. Could someone one provide me with some guidance?
Exception I am seeing in function:
Microsoft.Azure.WebJobs.Host.Listeners.FunctionListenerException : The listener for function {name of the Service bus trigger function} was unable to start.
---> System.InvalidOperationException : Service Bus account connection string 'ScheduleJobServiceBusPrimaryConnection' does not exist. Make sure that it is a defined App Setting.
   at Microsoft.Azure.WebJobs.Extensions.ServiceBus.Config.ServiceBusClientFactory.ResolveConnectionInformation(String connection)
   at Microsoft.Azure.WebJobs.Extensions.ServiceBus.Config.ServiceBusClientFactory.CreateClientFromSetting(String connection)
   at System.Lazy`1.ViaFactory(LazyThreadSafetyMode mode)
   at System.Lazy`1.ExecutionAndPublication(LazyHelper executionAndPublication,Boolean useDefaultConstructor)
   at System.Lazy`1.CreateValue()
   at Microsoft.Azure.WebJobs.ServiceBus.Listeners.ServiceBusListener.<>c__DisplayClass21_0.<.ctor>b__2()
   at System.Lazy`1.ViaFactory(LazyThreadSafetyMode mode)
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Lazy`1.CreateValue()
   at async Microsoft.Azure.WebJobs.ServiceBus.Listeners.ServiceBusListener.StartAsync(CancellationToken cancellationToken)
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at async Microsoft.Azure.WebJobs.Host.Listeners.FunctionListener.StartAsync(??) at D:\a\_work\1\s\src\Microsoft.Azure.WebJobs.Host\Listeners\FunctionListener.cs : 68
   End of inner exception

Environment
No response

@gaoyp830 :  The answer to the question that you're asking is "yes."   You can register multiple clients with different auth types via WithName as you're already doing.   More context and examples for DI scenarios can be found in Dependency Injection with the Azure SDK for .NET.
That's not the cause of the error that you shared.  The Event Hubs trigger does not use the clients that you register with DI - it creates its own based on your trigger configuration.  You didn't show your trigger signature, but the error message is clear:

Service Bus account connection string 'ScheduleJobServiceBusPrimaryConnection' does not exist. Make sure that it is a defined App Setting.

When you configure the trigger, the "Connection" parameter that you supply should be the name of an app setting that holds either your connection string or fully qualified namespace name.   The Functions runtime did not find the one that you registered.  Examples can be found in the product docs  and the README examples.   More discussion about how Functions manages connections can be found in the  Connections section of the docs.


i3 2016 lot's of sensor errors in HASS logs

I have lots of errors in HASS.IO version 91.4:
homeassistant.components.sensor
homeassistant.components.binary_sensor
homeassistant.components.core

are continuously throwing errors like this:
2019-04-21 01:28:23 ERROR (MainThread) [homeassistant.components.sensor] bmw_connected_drive: Error on device update!
Traceback (most recent call last): File "/usr/local/lib/python3.7/site-packages/homeassistant/helpers/entity_platform.py", line 261, in _async_add_entity
await entity.async_device_update(warning=False)
File "/usr/local/lib/python3.7/site-packages/homeassistant/helpers/entity.py", line 379, in async_device_update
await self.hass.async_add_executor_job(self.update)
File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/usr/local/lib/python3.7/site-packages/homeassistant/components/bmw_connected_drive/sensor.py", line 147, in update
self._state = getattr(vehicle_state, self._attribute)
File "/usr/local/lib/python3.7/site-packages/bimmer_connected/state.py", line 264, in __getattr__
return self._attributes[item]
KeyError: 'lastChargingEndReason'

I've enabled the BMW ConnectedDrive component 1 day ago and I have 323 task exepctions:
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/homeassistant/helpers/entity.py", line 225, in async_update_ha_state
    self._async_write_ha_state()
  File "/usr/local/lib/python3.7/site-packages/homeassistant/helpers/entity.py", line 256, in _async_write_ha_state
    device_attr = self.device_state_attributes
  File "/usr/local/lib/python3.7/site-packages/homeassistant/components/bmw_connected_drive/binary_sensor.py", line 111, in device_state_attributes
    result['door_lock_state'] = vehicle_state.door_lock_state.value
AttributeError: 'NoneType' object has no attribute 'value'

Executing services are working,
Please see attached fingerprint files.
status_0.txt
vehicles_0.txt
I also attach my HA log,
home-assistant-log_BMW.txt
I hope this helps.
Thanks
Ben

Have you tried running the demo script from this project in a terminal? If you run {path to script}\bimmerconnected status {your account name} {your password} {your region} and you don't see "doorLockState" in the big json list of attributes that it returns, then you could confim that the BMW server isn't sending you all the data or if it was in there, you'd know that the library wasn't handling the data properly.

"doorLockState" is there. One more strange thing is that mileage appears to be NONE, but earlier I've tried the bmwcdapi by jupe76 and that was able to properly read the milage.
Found 1 vehicles: i3 (+ REX)
VIN: ##########
mileage: None
vehicle properties:
{
"statisticsCommunityEnabled": true,
"hmiVersion": "ID4",
"hornBlow": "ACTIVATED",
"chargingControl": "NOT_SUPPORTED",
"vehicleFinder": "DRIVER_DISABLED",
"lastDestinations": "SUPPORTED",
"rangeMap": "RANGE_CIRCLE",
"dealer": {
"street": "K\u00f6nyves Kalman krt.5",
"name": "Wallis Motor Duna Kft.",
"phone": "+36 20 3336303",
"postalCode": "1097",
"country": "HU",
"city": "Budapest"
},
"lightFlash": "ACTIVATED",
"bodytype": "I01",
"carCloud": "NOT_SUPPORTED",
"climateControl": "NOT_SUPPORTED",
"hub": "HUB_ECE",
"smartSolution": "NOT_SUPPORTED",
"vin": "##############",
"doorLock": "ACTIVATED",
"climateNow": "ACTIVATED",
"hasAlarmSystem": false,
"colorCode": "B85",
"a4a": "USB_ONLY",
"yearOfConstruction": 2016,
"supportedChargingModes": [
"AC_LOW",
"AC_HIGH",
"DC"
],
"statisticsAvailable": true,
"breakdownNumber": "########",
"remote360": "NOT_SUPPORTED",
"onlineSearchMode": "MAP",
"countryCode": "B1-CS-HU",
"climateFunction": "AIRCONDITIONING",
"chargeNow": "NOT_SUPPORTED",
"lscType": "NOT_SUPPORTED",
"color": "CAPPARISWEISS MIT AKZENT BMW I BLAU",
"climateControlRES": "NOT_SUPPORTED",
"intermodalRouting": "NOT_AVAILABLE",
"driveTrain": "BEV_REX",
"doorUnlock": "ACTIVATED",
"sendPoi": "ACTIVATED",
"onlineSearchProvider": "GOOGLE",
"climateNowRES": "NOT_SUPPORTED",
"steering": "LH",
"remoteSoftwareUpgrade": "NOT_SUPPORTED",
"ipa": "NOT_SUPPORTED",
"model": "i3 (+ REX)",
"brand": "BMW_I"
}
vehicle status:
{
"vin": "#############",
"vehicleCountry": "HU",
"position": {
"status": "DRIVER_DISABLED"
},
"DCS_CCH_Activation": "NA",
"DCS_CCH_Ongoing": false,
"updateTime": "2019-04-20T18:17:31+0200"
}

It looks like you've got "doorLock" in properties, but no "doorLockStatus" in the vehicle status section. In fact, you've got almost nothing in the vehicle status section. I write almost since the section is still there, with a few items, just not most -- like leaving someone a single dollar in your will to prove you just didn't forget -- the server didn't forget to send the info, it just didn't send all of it.
By way of contrast, here's my i3's status info:
vehicle status: {     "chargingStatus": "INVALID",     "DCS_CCH_Ongoing": false,     "maxRangeElectric": 223,     "internalDataTimeUTC": "2019-04-23T21:36:55",     "windowPassengerFront": "CLOSED",     "remainingRangeElectric": 196,     "rearWindow": "INVALID",     "hood": "CLOSED",     "mileage": 24696,     "cbsData": [         {             "cbsState": "OK",             "cbsDueDate": "2020-01",             "cbsType": "OIL",             "cbsDescription": "Next service due when the stated distance has been covered or by the specified date."         },         {             "cbsState": "OK",             "cbsDueDate": "2021-01",             "cbsType": "BRAKE_FLUID",             "cbsDescription": "Next change due at the latest by the stated date."         },         {             "cbsState": "OK",             "cbsDueDate": "2021-01",             "cbsType": "VEHICLE_CHECK",             "cbsDescription": "Next visual inspection due when the stated distance has been covered or by the stated date."         }     ],     "windowDriverFront": "CLOSED",     "position": {         "status": "DRIVER_DISABLED"     },     "maxFuel": 8,     "doorLockState": "SELECTIVE_LOCKED",     "checkControlMessages": [],     "trunk": "CLOSED",     "doorPassengerRear": "CLOSED",     "positionLight": "OFF",     "connectionStatus": "DISCONNECTED",     "lastChargingEndReason": "CHARGING_GOAL_REACHED",     "remainingRangeFuelMls": 85,     "doorDriverRear": "CLOSED",     "remainingRangeFuel": 137,     "remainingRangeElectricMls": 121,     "windowDriverRear": "CLOSED",     "sunroof": "CLOSED",     "updateTime": "2019-04-23T17:36:55-0400",     "chargingConnectionType": "CONDUCTIVE",     "vehicleCountry": "US",     "maxRangeElectricMls": 138,     "windowPassengerRear": "CLOSED",     "chargingInductivePositioning": "NOT_POSITIONED",     "parkingLight": "OFF",     "DCS_CCH_Activation": "NA",     "chargingLevelHv": 90,     "updateReason": "VEHICLE_SHUTDOWN",     "doorPassengerFront": "CLOSED",     "lastChargingEndResult": "SUCCESS",     "singleImmediateCharging": false,     "doorDriverFront": "CLOSED",     "vin": "XXXXXXXXXXXXXXXXX",     "remainingFuel": 9 }
So for whatever reason, the BMW server isn't, uh, serving all the data to you. I don't think the problem is on your side of the connection.

Sorry, it was too late at night, and I was so much into it, that I missed the exact key:)
Thanks for the comparison! I've contacted 2 other i3 users in my country and it seems that they have the same amount of info about their cars. I'll contact BMW and try to investigate.
It would be a great feature to be able to configure that HA component, and customize the list of used services and sensors through configuration.yaml.
Ben

Did you receive some more info from BMW on this?
I have made a PR for HA which will be part of HA 0.98 which makes sure only sensors that your car actually supports will be added to HA.


BUILD: Remove dependency on comment-on-pr github action

Signed-off-by: Micah Halter<EMAIL_ADDRESS>

@epatters This removes dependency on the comment-on-pr GitHub actions and does this with just vanilla github-script. I tested this with the pull_request trigger and it should work with the pull_request_target action now. This is a much cleaner approach and is much more future proof. 🤞🏼

Looks good to me!

Thanks @mehalter!


Migration tool applies assertion intent too broadly in "Pop Pop Win"

The tool migration for pop pop win produces the following code:
ResourceManager _resourceManager;

void initialize(ResourceManager resourceManager) {
  /* if (_resourceManager != null) */ throw StateError("already initialized.");
}

This is clearly wrong.
The reason it does this is an assertion in a later function that the resource provider has been initialized:
void _playAudio(String name) {
  assert(_resourceManager != null, 'Not initialized');
  ...
}

https://github.com/dart-lang/sample-pop_pop_win/blob/master/lib/src/audio.dart#L39
A simple solution would be to do postdominator analysis, so that the intent is not propagated in this case.
However, is noteworthy that the human migration is to make this late, and non-nullable. This leaves an interesting question that if we do that, how would the tool know that this is a non-null variable and also that the true branch of the non-null check should be removed??

Upon further investigation, the problem is actually that when analyzing this line:
ResourceManager _resourceManager;`

the migration tool fails to account for the fact ath _resourceManager is implicitly initialized to null.  I'm working on a fix.

Awesome!
On Fri, Feb 21, 2020 at 5:15 PM Paul Berry<EMAIL_ADDRESS>wrote:

Upon further investigation, the problem is actually that when analyzing
this line:
ResourceManager _resourceManager;`
the migration tool fails to account for the fact ath _resourceManager is
implicitly initialized to null. I'm working on a fix.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/dart-lang/sdk/issues/40700?email_source=notifications&email_token=AAAEFCUQ4BLAUSYY62PITZTREB4CBA5CNFSM4KYEMMGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMUSP6I#issuecomment-589899769,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAEFCQEWTKSNVSASMF7USTREB4CBANCNFSM4KYEMMGA
.


Serve rustdoc static files from /-/rustdoc.static/

Fixes #1869
This changes the --static-root-path we pass to rustdoc, so it generates HTML that looks for files in the new location. It also changes where the shared static files are uploaded to in storage. They are uploaded to a matching path (/-/rustdoc.static/).
Files under this path can be served from an ordinary route. After this change, the special logic in SharedResourceHandler (ignore request path, serve file from storage root) will only be needed when serving documentation built prior to this PR being deployed. As such, I've renamed SharedResourceHandler to LegacySharedResourceHandler, and named the new handler SharedResourceHandler.
Note: this does not depend on https://github.com/rust-lang/rust/pull/101702.

also, if you want to copy/paste some things: https://github.com/rust-lang/docs.rs/compare/master...syphar:docs.rs:static-prefix?expand=1

Figured out the problem, rebased, and pushed a new revision. I think I've addressed all feedback.

@jsha it looks like the build & clippy is failing, could you check

Fixed!

I wound up removing the code that tried to detect path traversal by canonicalizing paths. The code I copy-pasted from the docs.rs static assets path was using std::fs to canonicalize paths; that technique doesn't apply to S3.
And in fact according to this, S3 doesn't treat ../ specially anyhow, so I believe we don't need to worry about path traversal here.

I wound up removing the code that tried to detect path traversal by canonicalizing paths. The code I copy-pasted from the docs.rs static assets path was using std::fs to canonicalize paths; that technique doesn't apply to S3.
And in fact according to this, S3 doesn't treat ../ specially anyhow, so I believe we don't need to worry about path traversal here.

TIL, I didn't know that. Then you're right removing the piece.

I just tested https://docs.rs.dev.nemo157.com/cbor-diag/0.1.11/cbor_diag/ locally and confirmed that main-20221019-1.66.0-nightly-4b8f43199.js which it loads isn't available in the minio root, only under docsrs/rust-docs-rs/rustdoc-static/.

( I can't test builds right now on my machine, need to fix that at.. )

Any chance you're running into https://github.com/rust-lang/docs.rs/issues/1881 ?

( I can't test builds right now on my machine, need to fix that at.. )

Any chance you're running into https://github.com/rust-lang/docs.rs/issues/1881 ?

Thanks for the hint, but that's not it. It's because my computer is an M1 Mac, and the "run the build in the web container " doesn't work any more.

@jsha I just deployed the change and the first build uses the  new path:
https://docs.rs/cozo/0.1.3/cozo/


GROUP BY returns 1 invalid result if no rows meet condition

If there is a query that has no results, but contains a GROUP BY, it returns one result regardless, with the data of "undefined"
console.log(alasql('SELECT Name FROM ? WHERE 1=0 GROUP BY Name',[[{Name:'test'}]]));
returns: [{Name: 'undefined'}] but should be []

Another issue with GROUP BY is that any field in the result that is not in the group by is 'undefined'. MySQL simply returns the data from the first retrieved row.

alasql('SELECT Type,Name AS Names FROM ? GROUP BY Type',[[{Type:'PT',Name:'Steve'},{Type:'PT',Name:'Dan'},{Type:'FT',Name:'John'}]]);
Returns
[{Names: undefined, Type: "PT"},{Names: undefined, Type: "FT"}]

Thank you! For the second question you should:
a) add Name to the GROUP BY clause
b) Use FIRST() aggregator
var res = alasql('SELECT Type,Name FROM ? GROUP BY Type, Name',[...);

or
var res = alasql('SELECT Type,FIRST(Name) FROM ? GROUP BY Type',[...]);

For the first question - sorry, it still in progress...

Try this example in jsFiddle

Yes, for first question, I am able to get away with this as I already always check for results:

var res=alasql('SELECT pkey,Name FROM ? WHERE 1=0 GROUP BY Name',[[{Name:'test'}]]));
if(res.length>0 && typeof res[0].pkey !== 'undefined'){} //use a field that is guaranteed to never be undefined

Sorry, just a tweak on your example for others. (It works exactly as I would have expected it to from within mySQL)

var res = alasql('SELECT Type,FIRST(Name) FROM ? GROUP BY Type',[...]);

returns [[{Type:"foo","FIRST(Name)":"bar"}]]
Make sure you include the as statement.

var res = alasql('SELECT Type,FIRST(Name) AS Name FROM ? GROUP BY Type',[...]);
will return [[{Type:"foo",Name:"bar"}]]

Is there a way you can test if the fields are requested naked, to automatically apply the FROM() function when used in  a GROUP BY? Maybe in an upcoming version?

:+1:

Is there a way you can test if the fields are requested naked, to automatically apply the FROM() function when used in a GROUP BY?
I think, that the standard SQL reaction is to throw a error like "column is not found". I think, Alasql can check this, but only for SELECT with GROUP BY clause. Plus, it is hard to recognize these "naked" columns in expressions, like:
    SELECT mycol+1 FROM mytable GROUP BY othercol

Is this issue resolved?

There is news about this bug? Thanks in advance

I dont think so...

Well... its now returning [{}] instead of the original problem - but its still not correct.
http://jsfiddle.net/t780pnz1/

adding HAVING count(*) > 0 seems to fix this problem


C++ build error

Hi, @alexliniger.
Thanks for your contribution.
I am interested in MPCC and want to run on C++ execution on the Ubuntu 18.04.  According to your README, I tried to make the CMakeLists but failed like following:

After failed to make, I changed the CMakeLists and finally succeeded to build. But, I encountered the problem when I launched with './MPCC'. I found that problem is associated with matplotlib-cpp. However, I couldn't find the solution although strive to solve this problem with some modification and trials.

Let me know what is the problem if possible.

the two branches use different approaches for matplotlib-cpp in the CMake file, can you try out the other one as well. I will have a look as soon as possible. But over the years I had also several times issues with matplotlib-cpp.
Best,
Alex

Thanks for your reply.
I tried to change from master branch to /wip/install-target branch. It also happened a same problem.

The python configurations:

Hi, @alexliniger
I finally correct the problem for matplotlib.
But, I want to launch the MPCC path tracking online like README :
https://github.com/alexliniger/MPCC/blob/master/Images/MPC_sim.gif


Send queue message does not support queuename in destination

Describe the issue
Send queue message does not support queue name in destination, it always does a JNDI lookup on the server
Reporter
JJansenvr
Additional Context
a extra checkbox to enable lookup destination

Error occurred browsing messages: (NameNotFoundException) Context: IUFjava_BU_06_HA_AS_V9.0/nodes/AppSrv01/servers/wasap20, name: P2P.GROUPIT.ibis4mq2emsmig.MQ2EMSFFTemplate.Action: First component in name P2P.GROUPIT.ibis4mq2emsmig.MQ2EMSFFTemplate.Action not found.: (NotFound) IDL:omg.org/CosNaming/NamingContext/NotFound:1.0

I think this has already been solved, see #1744

This will still be an issue In 7.5.1 which we decided not to solve


Someone please takeover VSCodeBeautify, its deprecated

please takeover or create new project
repo url: https://github.com/HookyQR/VSCodeBeautify

@ewwink
Perhaps you would like to do so? It is MIT licensed.

I'm not really good 😄

@ewwink

I'm not really good 😄

I'm not sure I understand.  You don't have to be amazing to maintain a project.  Even being willing to do the administrative tasks is often sufficient.


No warning if incorrect yaml is applied for Traffic Split

Describe the proposal

For traffic split, if weights are distributed in an improper way like all weights don't sum up to 100 or all weights sum > 100. We don't get an error message that yaml is incorrect.
Scope

[ ] New specification
[ ] Traffic Access Control
[ ] Traffic Specs
[ ] Traffic Metrics
[X] Traffic Split

Possible use cases

apply the yaml with irregular weights like 1000, -200 etc. the yaml will be applied successfully without error. This should throw an error message.

Hi, @mudit-01. This was discussed on the SMI community call today and the consensus was that this proposal is outside the scope of this spec. Validation beyond that enforced by the OpenAPI schema in the TrafficSplit CRD is left to those implmenting this spec.

if weights are distributed in an improper way like all weights don't sum up to 100 or all weights sum > 100

The weights are not percentages, so there should be no issue if the weights do not add up to 100.


[F 6.2] disable responsive behaviour

I want to disable the responsive behaviour in Foundation 6.2, How to do this ??

You should download a custom Foundation without the grid, select the radius button with the option No Grid.

i want to keep the behaviour in large ...

Maybe you could adjust the breakpoints in the SASS so the smallest breakpoint is at 1440px or something.

Wait for 6.2.1
Rename your smallest breakpoint to "grid" or what ever you want and just use the smallest grid.

Add the same amount of columns to each elements in each breakpoint:

May be this could fit to you, but I'm not really sure of what are you looking for.

I think it's enough to only use the smallest breakpoint, as I asume all bigger breakpoints use the values from the smaller if not present.
This

can be reduced to this

Is that what you wanted @xfifix ? if yes, can you please close this issue?

Looks like this has been answered.  If not, please re-ask in the forum rather than on github: http://foundation.zurb.com/forum


Account validation - Close Window button is non-functional

Expected Result:
The 'close window' button on the success page should be functional. The page should close smoothly, and the user should be redirected to the Expensify inbox page
Actual Result:
The 'close window' button on the success page isn't functional, no further action is observed when user clicks on it
Action Performed:

Navigate to staging.expensify.com
On the email field - enter a new email
Click join button
Log out of the account
Validate account:
In the email field enter the same email
Verify you're asked for a magic code
Navigate to your inbox, copy the Magic link and change it to staging
In success page, click on ''Close Window'' button

Workaround:
Unknown
Notes/Photos/Videos:
https://github.com/Expensify/App/assets/78819774/4e2afb8f-6b13-4e56-8877-4b7f9a90b8ab
Tester login credentials -

Okay so I'm 99% certain this is an artifact of testing. Because the URL was typed in manually (to direct it to staging vs. prod), rather than clicking on a link, it has no "parent" and so cannot be closed by JavaScript. Unfortunately, this doesn't seem to be something we can make a workaround for - but it's also something that's going to be pretty uncommon - almost no one will go to that page without just clicking the link.
@lanitochka17 can you confirm that this doesn't happen on production if you click on the link from the email? If so I think we can close out.
Also this should be in the Expensify/Expensify repo not Expensify/App - if we are going to keep it open we should move it there.

One more question - is this a new bug, or is it instead a new test? If I'm right, this should basically always happen - but if it only just started then maybe there's something else going on.

@dangrous This issue is related to the Login TC in TestRail, which was recently added to the Regression run.
https://expensify.testrail.io/index.php?/runs/view/18896&group_by=cases:section_id&group_order=asc&group_id=288239

hi! @lanitochka17 let us know when you can about the above - thank you!

Okay got it, thank you! So if it's a new test and it wasn't doing something else before, I think we're okay to close this - the reason it's happening is that it's a manual paste/modification of the URL from the magic link email, and so the browser won't allow it to close itself. Not much we can do about this, as far as I'm aware!


getZoomLevel is not a function

I'm trying to use getZoomLevel as in the mapbox demo
map.getZoomLevel().then(
            function(result) {
                dialogs.alert({
                    title: "Zoom Level",
                    message: JSON.stringify(result),
                    okButtonText: "OK"
                });
            },
            function(error) {
                console.log("mapbox getCenter error: " + error);
            }
        );

However, I'm getting this error
An uncaught Exception occurred on "main" thread.
com.tns.NativeScriptException:
Calling js method onMapClick failed

TypeError: map.getZoomLevel is not a function
File: "file:///data/data/org.nativescript.ctdemo/files/app/views/map/map.js, line: 61, column: 19

StackTrace:
	Frame: function:'', file:'file:///data/data/org.nativescript.ctdemo/files/app/views/map/map.js', line: 61, column: 20
	Frame: function:'onMapClick', file:'file:///data/data/org.nativescript.ctdemo/files/app/tns_modules/nativescript-mapbox/mapbox.js', line: 842, column: 15

	at com.tns.Runtime.callJSMethodNative(Native Method)
	at com.tns.Runtime.dispatchCallJSMethodNative(Runtime.java:1197)
	at com.tns.Runtime.callJSMethodImpl(Runtime.java:1061)
	at com.tns.Runtime.callJSMethod(Runtime.java:1047)
	at com.tns.Runtime.callJSMethod(Runtime.java:1028)
	at com.tns.Runtime.callJSMethod(Runtime.java:1018)
	at com.tns.gen.com.mapbox.mapboxsdk.maps.MapboxMap_OnMapClickListener.onMapClick(com.mapbox.mapboxsdk.maps.MapboxMap$OnMapClickListener.java)
	at com.mapbox.mapboxsdk.maps.MapGestureDetector$GestureListener.onSingleTapConfirmed(MapGestureDetector.java:300)
	at android.view.GestureDetector$GestureHandler.handleMessage(GestureDetector.java:300)
	at android.os.Handler.dispatchMessage(Handler.java:102)
	at android.os.Looper.loop(Looper.java:148)
	at android.app.ActivityThread.main(ActivityThread.java:5551)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:730)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:620)

I'm using mapbox plugin 2.5.1 and tried also with 2.5.2 (but the map was not stable with this release). And nativescript 2.5.2
Am I doing anything wrong?

I have the same issue with a XML-based map. With mapbox.show() the getZoomLevel() function works fine.

I have create 3 (sorry!) pull requests to fix this.
Once the code is adapted for XML-based maps, the returned value could not be obtained because the functions in the prototype were not 'thenables'.
This way, you can add more getX() functions.

Thanks for your PR's @seros00, merged them all and will release a new version shortly.


Check and display the conflicting shortcut keys

[x] highlight conflicting shortcut keys with other plugins
[ ] highlight conflicting shortcut keys with Sketch

Developer will not set a shortcut key that conflict with the Sketch, so we need not the second feature.


Add recommendation to install hiredis

What do these changes do?

Add docs about installing hiredis too since it is now an optional dependency.
Are there changes in behavior for the user?
Yes, installing hiredis is a completely different parser.

Related issue number
#1137 points out how hiredis resolved for issue.

Checklist

[X] I think the code is well written
[ ] Unit tests for the changes exist
[X] Documentation reflects the changes
[X] If you provide code modification, please add yourself to CONTRIBUTORS.txt

The format is <Name> <Surname>.
Please keep alphabetical order, the file is sorted by names.

[ ] Add a new news fragment into the CHANGES/ folder

name it <issue_id>.<type> (e.g. 588.bugfix)
if you don't have an issue_id change it to the pr id after creating the PR
ensure type is one of the following:

.feature: Signifying a new feature.
.bugfix: Signifying a bug fix.
.doc: Signifying a documentation improvement.
.removal: Signifying a deprecation or removal of public API.
.misc: A ticket has been closed, but it is not of interest to users.

Make sure to use full sentences with correct case and punctuation, for example:
Fix issue with non-ascii contents in doctest text files.

View rendered README.md

Fixed in #1247


Can't avoid snap near line

First - thanks, this library is amazing. I have worked snapping in the past and it's a real pain!
I ran into a bit of an issue attempting to draw polygons. Here you can see I am attempting to trace the raster.
https://user-images.githubusercontent.com/678344/128818286-6aa70749-d068-4e52-8739-3a35af782de7.mov
The point I am trying to create is not near a vertex, so I don't expect it to snap. But it seems it detects that my point is near the line, and snaps to the nearest vertex.
I'm not sure if this is a bug or just surprising behaviour that should maybe be avoidable with an option.
(I have just discovered that holding Option temporarily prevents snapping, which is a fine workaround for me. That should probably be documented, too...)

Hi,
I'm glad you're finding this useful.
you can actually control the snapping behavior using Boolean option draw.options.snap, changing this would take effect in the snapping modes:
draw.options.snap = false;

there's an example in the docs directory showing this. but you're right I should've mentioned this control option and the Alt (Option) key in the docs, my bad. will add them soon.
on a side note, there's also an option snapPx to reduce snapping distance. In your example specially, this should be reduced because lines are not that long and 15px is probably a lot:
const draw = new MapboxDraw({
  ...
  snapOptions: {
    snapPx: 15,
    snapToMidPoints: true,
  },
});

draw.options.snap = false;

Well, yes - but that just disables snapping entirely, which isn't what I want.

on a side note, there's also an option snapPx to reduce snapping distance.

Yes, I noticed that - but that doesn't really solve the issue either.
The more I think about it, the more I think this is incorrect behaviour - hovering the mouse near the midpoint of a line shouldn't cause any special snapping to happen if snapToMidpoints is false (as it is in my case).

Well, yes - but that just disables snapping entirely, which isn't what I want.

Ah, I thought you can disable it and enable it later.

The more I think about it, the more I think this is incorrect behaviour - hovering the mouse near the midpoint of a line shouldn't cause any special snapping to happen if snapToMidpoints is false (as it is in my case).

setting snapToMidpoints to false would only disable snapping to mid-points (an imaginary point at the middle of a line or segments). I'm guessing when lines are not that long which happens in your case where we are zoomed in near the buildings, snapping wouldn't work properly; and that's because snapping give priority to vertices, and the max distance triggering this is set here manually:
https://github.com/mhsattarian/mapbox-gl-draw-snap-mode/blob/86f7a5d11945c0c488af7ae04c88353aa25d412a/src/utils/index.js#L246
would you think reducing this (and make it dynamic) would solve this problem?

@stevage I tested changing this priorityDistance and it worked quite well:
https://user-images.githubusercontent.com/29674767/129104083-d2f9a987-fb8f-4baf-b09a-c8ef44f5391b.mp4

here I'm setting the value to 0.0025

so, I updated the package on npm, making it possible to pass a custom value for  priorityDistance in snapOptions as below:
snapOptions: {
    snapVertexPriorityDistance: 0.0025, // defaults to 1.25
}

I'm to be honest I'm really confused with the relationship between snapToMidpoints and snapVertexPriorityDistance

snapToMidpoints true, no snapVertexPriorityDistance: mouse snaps to the vertices only, even when you're near the midpoint of a segment (like in my original issue). Seems never useful?
snapToMidpoints false, no snapVertexPriorityDistance: seems exactly the same
snapToMidpoints false, snapVertexPriorityDistance: 0.00001 - snaps either to the vertex or somewhere along the segment, whichever is closer.
snapToMidpoints false, snapVertexPriorityDistance: 0.0025 - snaps either to the vertex or somewhere along the segment, but with a stronger bias for a vertex if there is one. This seems like a good default setting.

Since the behaviour of snapVertexPriorityDistance is subtle, hard to explain, and uses obscure units (what are they?), I'd suggest just picking a good default setting and leaving it at that.
I don't know if there is a bug or I'm not understanding what snapToMidpoints is meant to do, but it doesn't seem to change anything. It seems like it would be useful to be able to avoid snapping to line segments (and only snapping to vertices), but this setting doesn't seem to change that.

Sorry for the late response,
you're assuming snapToMidPoints controls whether to snap only to vertices or also snap to the nearest point in the line/segments as well. but that's not what it does.
snapToMidPoints is controlling whether to snap to the middle point of each line/segment or not. just that. I guess it's not that useful and -as you mentioned- we instead need a more convenient option to control snapping behavior, and select to snap only to vertices, or snap to segments as well. I'm thinking it should not be that hard to add.
on the other hand, the snapVertexPriorityDistance option controls the min distance (in km) from each vertex where snapping to vertex takes priority over snapping to line/segments.
this is why when nothing is set for it, and the default value (which is 1.25km and is too much when the line/segment itself is less than a few kilometers long) is used it only snaps to the vertices and not the line/segment.

Since the behaviour of snapVertexPriorityDistance is subtle, hard to explain, and uses obscure units (what are they?), I'd suggest just picking a good default setting and leaving it at that.

I think its behavior is not that subtle, it can be dynamically (using a range element for example) or programmatically (based on zoom level I think) controlled so that the snaping is always acting as desired.
and I should've mentioned it's the minimum distance in kilometers, sorry.


navbar improved + previous issue solved

in nav bar i have to make navbar sticky  and also i  change the icons hover while hover in navbar the icon icon size will increase and decrease .
https://github.com/user-attachments/assets/60b3819b-c69a-4272-b120-d2de34eb0442
@Tejashri-Taral  :    pls accept my pull request.
#440

Hi, your task was to just add a hovering effect on the shop icon and make the navbar sticky.
But as I can see there 1200+ lines changed and 1000+ lines of code are removed.
So I cant merge this PR due to which the Original website UI will be broke.
you can make a new PR and make the proposed changes.


Specify OpenSearch-Dashboards branch for 2.2.0 release

Signed-off-by: Miki<EMAIL_ADDRESS>By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #2430 (cadb754) into main (b455bd8) will increase coverage by 5.37%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##               main     #2430      +/-   ##
=============================================
+ Coverage     94.62%   100.00%   +5.37%
=============================================
  Files           210         6     -204
  Lines          4317       105    -4212
  Branches         29        19      -10
=============================================
- Hits           4085       105    -3980
+ Misses          226         0     -226
+ Partials          6         0       -6

Impacted Files
Coverage Δ

...rc/test_workflow/test_result/test_suite_results.py

src/build_workflow/build_args.py

src/build_workflow/builder_from_dist.py

src/ci_workflow/ci_check_lists.py

...est_workflow/bwc_test/bwc_test_start_properties.py

src/test_workflow/test_args_path_validator.py

...c/test_workflow/dependency_installer_opensearch.py

...rkflow/integ_test/service_opensearch_dashboards.py

src/run_bwc_test.py

...ensearch_dashboards/build_artifact_check_plugin.py

... and 194 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Add option to add debug keystore in Android export

Some Google Services features require the release keystore even for testing, so this setting might be project specific and therefore can't be changed in editor settings.

Thanks!


U - As the PM I want feedback from writing staff on PVP, so we can make decisions about scope for MVP

Acceptance criteria

[x] Most tech writers on the team and at least one community member have had the chance to use the PVP
[x] Feedback from tech writers recorded
[x] Results of feedback round documented

Sprint Ready Checklist

[ ] Acceptance criteria defined

[ ] Team understands acceptance criteria

[ ] Team has defined solution / steps to satisfy acceptance criteria

[ ] Acceptance criteria is verifiable / testable

[ ] External / 3rd Party dependencies identified

Execution

DDNs selected for each writer.
1-2 hour video interview with each writer where they go through the following tasks
Debrief for each round with tech writer
Summary of notes shared for feedback

Notes on testing: https://docs.google.com/document/d/1fF_sdffIPqvxnqP_tpmeDVQHDAMmxPFC3MzucJwCA34/edit#heading=h.75xy194xzguy


Misleading "Advice" in MSVC error documentation.

The page includes this admonition as some sort of best practice:
"Although there is no specific warning for it, we also recommend that you do not use a parent directory path segment to specify your project include directories."
The example also says this:
#include "..\headers\C4426.h"  // emits warning C4464

// To fix this issue, specify only the header file name, and add
// the absolute path to 'headers\' to your project's include directories
#include "C4426.h"

I don't know who came up with this recommendation, but it's bad advice.  It's very much a standard industry practice to include library prefixes on header files, such as boost:
https://www.boost.org/doc/libs/1_79_0/doc/html/accumulators/reference.html#accumulators_framework_reference
and Microsoft's own WIL library:
https://github.com/microsoft/wil/blob/master/tests/ComTests.cpp
and Google's C++ style guide:
https://google.github.io/styleguide/cppguide.html#Header_Files
Please remove this misleading guidance from this documentation.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: eea6cbb5-c2e6-86f1-817f-0920de9d99e0
Version Independent ID: b645e000-fe3d-187b-671a-46468930fbeb
Content: Compiler Warning (level 4) C4464
Content Source: docs/error-messages/compiler-warnings/compiler-warning-level-4-c4464.md
Product: visual-cpp
Technology: cpp-diagnostics
GitHub Login: @corob-msft
Microsoft Alias: corob

@bradlitterell
Perhaps the advice isn't clear for all readers. My reading of the advice seems unrelated to the examples you cite. There's nothing wrong with an include directive such as #include "headers\C4426.h" or the common #include <sys/types.h>. The advice is to avoid using parent path segments (..) in the include paths in your project environment, because it can be fragile, error-prone, and difficult to share with other developers (who may have installed Boost somewhere different than you did, say). Is that the advice you find objectionable?

@corob-msft
I think you're ascribing a different meaning to the text.
You are saying "parent path segments" means using .., but the text says there is no specific warning for it...do not use a parent directory path segment.  Since there IS  a warning specifically for .., then a "parent directory path segment", cannot refer to .., and must instead refer to header/, which is reinforced by the example's advice to remove header from the include.

@bradlitterell
Yes. I am ascribing exactly the meaning you think I am, because there's no warning message when you use a .. parent directory path segment in an INCLUDE path or in any of the ... Directories properties in the VC++ Directories page in the Property Pages dialog for your project in the IDE.
But from the rest of your explanation, I can see what the source of the confusion must be. When the example says "... add the absolute path to 'headers' to your project's include directories" it means that if, say, the absolute path to the header file is C:\Users\username\source\repos\solution\project\headers\C4426.h, then you should add C:\Users\username\source\repos\solution\project\ (that is, the absolute path required to include headers\) to your INCLUDE paths. It would be easy to read this sentence to mean that you should add C:\Users\username\source\repos\solution\project\headers\ to your INCLUDE path, even though that's not the intent. That wording can be cleared up, and some actual examples added. Would that address your objection?

Created PR #4135

Closed as fixed; merged content is live.


Restrict download permissions

The download endpoint should be more restricted that general item access.  Perhaps it should only be allowed if the current user has write access to the item or an appropriately scoped token.

We can do this by modifying the download endpoints from public access to user access.  We discussed also restricting the associated image endpoint (for macro and label images), which will benefit from https://github.com/girder/large_image/pull/343.
I think this should be one or two settings in the plugin (one for downloads and one for associated images, or just one setting for both), as it may not be desirable to restrict this in development environments.  I think that toggle such settings would require a server restart to take effect.
@dgutman Do you have an opinion on what options we provide in settings?


[bug]: Incorrect diff produced for if expression

was working on https://github.com/uber/piranha/issues/35 but it seems there is an issue in the current master branch where expressions are not correctly handled in if statements
to reproduce simply change the implementation in sample app (MyClass.bak)
  public void bar(boolean base) {
    if (base && expt.flagDisabled(TestExperimentName.SAMPLE_STALE_FLAG)) {
      System.out.println("Hi World");
    }
  }

The output diff is,
  public void bar(boolean y) {

  }

See the configuration option here. Since the conditionalExpression evaluates to false, the output is indeed correct.
Please re-open if you see this behavior when the configuration option is changed.

Shouldn't the diff file be,
  public void bar(boolean base) {
    if (base) {
      System.out.println("Hi World");
    }
  }

as the boolean base is a base check and the feature is checked only after the base passes.

Independent of base, expt.flagDisabled(TestExperimentName.SAMPLE_STALE_FLAG) will return false when flag is treated. So, the entire conditional expression evaluates to false.
Try this example when treated is changed to control.


[Bugs] Issues in reset-posters-tmdb.py and reset-posters-plex.py

It looks like there might be a few issues with the current iteration of the reset posters script:
https://github.com/chazlarson/Media-Scripts/blob/a04a2fc5e1ebfb85c08799ba6e08e51874470104/Plex/reset-posters-tmdb.py#L292
might need to change to (as the method is expecting the 1st arg to be a library rather than a server object and the return signature has changed)
            library_items_count, library_items = get_all_from_library(the_lib)

same goes for
https://github.com/chazlarson/Media-Scripts/blob/a04a2fc5e1ebfb85c08799ba6e08e51874470104/Plex/reset-posters-plex.py#L170
changed to
            items_count, items = get_all_from_library(the_lib)

Submitted pr https://github.com/chazlarson/Media-Scripts/pull/51 to help fix issue


Fix typos

Thanks! I see only three types of changes:

Adding . at the end of sentences in table (few of them).
Adding missing '(' - one place.
Adding missing ':' - one place.

I will merge this shortly.


Current limiting that goes below 5V will cut power to the load key and MOSFET drive circuit

The solutions are:
1: Ignore
2: Put the MOSFET on the source instead
3: Use the 5th 7W2 wire for MOSFET control
Option 2 is the most robust, but having the MOSFET on the source key means the load key's MCU must be powered from before that MOSFET. In other words, it must get its power from the source key via the 4 comms lines. This would not work for series sources, at least not without power isolation as well as signal isolation.
But if a diode is tied from the source's negative rail to the optocoupler's negative rail it should get power to the load key's MCU.
So long as the load tells the source what to do with its supply, such as shut off once it hits a certain voltage or just keep regulating, the system should be self sustaining.
But having series MOSFETs is a bit sketchy, they'd still need to be rated to the total voltage.

Changing the MOSFET to be on the source key would imply that the source should be the master of the communication.


Add Mathias Brossard to the AUTHORS file

AWS CodeBuild CI Report

CodeBuild project: Veracruz
Commit ID: 78c35b194e39ee278fcd98ec4bf8deb307f3b685
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

+1 reached, merging.


client installation: kubectl and helm

[x] neonDESKTOP/neon-cli setup needs to install the kubectl and helm client tools.  We've partially implemented this in KubeSetup.InstallWorkstationBinariesAsync() but this needs more work and also needs to be integrated into neonDESKTOP setup instead of being called during cluster setup.

[x] kubectl.exe
[x] helm.exe

[x] We also need to decide what to do with the kubectl installed by Docker Desktop since it may be older (or newer) than what we require.  Docker installs this here (on the PATH):
C:\Program Files\Docker\Docker\resources\bin\kubectl.exe

One possible solution is to have our setup ensure that our binary folder appears before the Docker folder in the PATH, but that assumes that our version of kubectl is more recent than Docker's and that we're installed after Docker.  The other problem is that Docker may be upgraded later with a newer kubectl version and we may break Docker Kubernetes because out older kubectl will still be executed if our folder still appears earlier in the PATH.
Another idea would be to install a kubectl.cmd script that dynamically probes each kubectl.exe client version and then calls the most recent one.
I'm not entirely sure we actually need to solve this problem though since the whole point of neonKUBE is so user won't ever need to use Docker Kubernetes.  In the rare cases where users do want to use Docker Kubernetes and their version of kubectl is more recent then ours, the workaround would be to have the user manually create a symlink or reorder the PATHs.

[x] Regardless of what we do about the conflicts above, we should probably have neonDESKTOP and neon-cli verify that kubectl.exe on the PATH be at least as recent as what we installed.

[x] Alternatively, we could have neon-cli wrap calls to kubectl and perhaps Kustomize and Helm?

I ended up creating another issue to track this (for no apparent reason): #1327


[WIP] General Glossary

A continuation of the work by @Malvar relating to issue #164.
I think most of the "difficult" terms are now defined in a sufficiently ambiguous way so as to be generally applicable.
Obviously this still needs more work

I know you didn't start it... but why are we putting html in markdown files?

I guess it is for table based alignement. Github flovored md support this. Well,  maybe it isn't worth the unreadability. But the rich diff is nice with this.

I have no attachment to html over markdown. I just continued the work in the style it was originally written in.
The main difference, as far as I can see, with using html over markdown for this is a reduction in the vertical whitespace between the term and the definition.

@TheDevKing How's this coming along?

Can the syntax be changed to be more reader friendly with markdown rather than html?
Other that it looks good to me but it's definitely an on going work. Feel free to merge.

@guitarman0831 I haven't had a chance to make any more progress on this
@ajax-wcd I just did a quick regex replace to change it to markdown, though it would probably benefit from a styling overhaul

@TheDevKing Looks good with the MD. I'm going to merge this.


Build arm64 wheel on MacOs

🚀 Feature
Build arm64 wheel on MacOS but does not test it because we do not have a Cirrus account.
Motivation
New MacBook Pro computers are natively using arm64 processors in their Mx chips. Providing arm64 wheels on MacOs will allow MacBook Pro users to install scikit-decide natively.

Solved by #303.


Add audit dates for Dialog component

Description
The Accessibility team helped upstream the PVC Dialog, which means we should mark it as "reviewed for accessibility" on our status page https://primer.style/status. This PR attempts to do that.
The date I used was based on the date that the issue https://github.com/github/primer/issues/426 was closed.
Integration

Does this change require any updates to code in production?

No
Merge checklist

[N/A] Added/updated tests
[N/A] Added/updated documentation
[N/A] Added/updated previews

Closing because this didn't work as intended: https://primer-e7fe051bc7-26611710.drafts.github.io/components.json. Will file an issue to get this sorted.


Update domain-modeling.md

Wrong entity name associated to key project in Many-to-Many Association. It should be Projects :-)

Thanks a lot, Chiara!


JBPM-4915: Chrome: When deleting task comments, the last comment does…

… not disappear from the table
Removed ListProvider refresh and replaced by displayer refresh
Added columns datastorename.

+1

Merged into 6.4.x.


The home kit app does not show this accessory.

I don't know what I am doing wrong, but the homekit app only shows one accessory and not this one. Could it be caused by the plugin configuration?

The plugin creates a  platform accessory, which means you must manually search for and add the television once it is configured. See the Homebridge wiki for adding TVs for more information.
You should see something like the following in your Homebridge log if you have configured the plugin correctly:
[11/9/2020, 4:12:41 PM] Please add [YOUR DEVICE NAME] manually in Home app. Setup Code: 123-45-678

If you don't see that, attach your configuration and I'll take a look.


Fix telemetry on all API containers

Summary
Fix telemetry on all services.
Intended Outcome
We can visualize telemetry using Jaeger.
Requirements

[ ] All services implement OpenTelemetry auto instrumentation to track all requests (gRPC and Rest).
[ ] Custom Events, Tracers, and Spans are fixed.

@efraa
Thanks for the reference. We have to triage this. If I remember correctly, this only happens when deployed a container. It did not happen in my local environment.

Fixed @psanders


Language options are white links on white background

On the timetable, when I click the select box for the languages - pre-filled with English (UK), the options pop up but are written in white font color on white background.

Also, choosing e.g. German does not cause any parts of the page to be German, at least not that I found one.
Suggested fix
Remove the box

Thanks! This is a more general theme issue, it should be a problem on other pages as well. @petesfrench FYI

@kewisch Thanks for flagging this, I have made an issue on our Jira board so it will get scheduled in. https://warthogs.atlassian.net/browse/WD-6561