cmd/compile: -d=checkptr doesn't detect invalid pointer fields in converted pointers-to-structs

What version of Go are you using (go version)?

$ go version
go version devel +0915a19a11 Fri Dec 6 05:12:15 2019 +0000 linux/amd64

What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="~/.cache/go-build"
GOENV="~/.config/go/env"
GOEXE=""
GOFLAGS=" -mod="
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="~/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="~/projects/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="~/projects/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build392569888=/tmp/go-build -gno-record-gcc-switches"

What did you do?
package tmp

import (
	"testing"
	"unsafe"
)

func TestUnsafeCast(t *testing.T) {
	var x uint32 = 0
	p := (*uint64)(unsafe.Pointer(&x))
	t.Log(*p)
}

func TestUnsafeStructCast(t *testing.T) {
	var x uint32 = 0

	type A struct {
		p *uint32
	}
	type B struct {
		p *uint64
	}

	v := &A{ptr:&x}
	p := (*B)(unsafe.Pointer(v))
	t.Log(*p.p)
}

What did you expect to see?
Both TestUnsafeCast and TestUnsafeStructCast fail with go test -gcflags=-d=checkptr, since both use invalid unsafe.Pointer casts.
What did you see instead?
Only the TestUnsafeCast fails. Pointer fields are not verified properly.

@mdempsky

This works as intended. The rule 1 of unsafe.Pointer:

B is not larger than A: unsafe.Sizeof(&A{}) == unsafe.Sizeof(&B{})
B and A has the same memory layout, one pointer field.

If you change to:
func TestUnsafeStructCast(t *testing.T) {
	var x uint32 = 0

	type A struct {
		p uint32
	}
	type B struct {
		p uint64
	}

	v := &A{ptr:&x}
	p := *(*B)(unsafe.Pointer(v))
	t.Log(p.p)
}

Then the compiler correctly reports.

@cuonglm Yes, I'm aware that it will work if the struct contains the field directly. It may not break any rules for the root type, but it does break the same rules for the field pointer type.

@cuonglm Yes, I'm aware that it will work if the struct contains the field directly. It may not break any rules for the root type, but it does break the same rules for the pointer type field.

What do you mean "but it does break the same rules for the pointer type field"? In your example, A and B has exactly the same memory layout, both contain one pointer field, so it does not break any unsafe.Pointer rule, so no report.

@cuonglm Yes, both are pointers of the same size.
However, if I understood correctly, checkptr was intended specifically to find bugs with invalid pointer conversions. Although it's intended to only "fail if unsafe.Pointer rules are violated", I think there is a significant value in detecting cases similar to one I've described. If not for checkptr, then maybe for a different flag.

@cuonglm Yes, both are pointers of the same size.
However, if I understood correctly, checkptr was intended specifically to find bugs with invalid pointer conversions. Although it's intended to only "fail if unsafe.Pointer rules are violated", I think there is a significant value in detecting cases similar to one I've described. If not for checkptr, then maybe for a different flag.

Maybe you can read https://go-review.googlesource.com/c/go/+/162237
I quote the commit message here:

cmd/compile: add -d=checkptr to validate unsafe.Pointer rules
This CL adds -d=checkptr as a compile-time option for adding
instrumentation to check that Go code is following unsafe.Pointer
safety rules dynamically. In particular, it currently checks two
things:

When converting unsafe.Pointer to *T, make sure the resulting
pointer is aligned appropriately for T.

When performing pointer arithmetic, if the result points to a Go
heap object, make sure we can find an unsafe.Pointer-typed operand
that pointed into the same object.

Sure, but again, it can be useful to check both rules for pointer fields as well (if the element types are not the same).

Sure, but again, it can be useful to check both rules for pointer fields as well (if the element types are not the same).
Just to clarify: I'm not claiming it's a bug in checkptr. It's rather a feature request to (optionally) add checks for struct fields which are pointers as well.

But those struct fields are the same in your example, both fields are pointer type. So I don't see why you think it's invalid.

OK, sorry, let me explain it a bit more carefully.
Both examples execute the same operation (semantically): cast a pointer to a single uint32 value to a pointer to uint64, which is invalid according to the unsafe.Pointer rules.
The only difference is that the second example does the conversion by using a proxy struct type of the same size. It silently converts a *uint32 field to a *uint64 field, achieving the same invalid behavior as the first example, but without triggering a runtime failure.

OK, sorry, let me explain it a bit more carefully.
Both examples execute the same operation (semantically): cast a pointer to a single uint32 value to a pointer to uint64, which is invalid according to the unsafe.Pointer rules.
The only difference is that the second example does the conversion by using a proxy struct type of the same size. It silently converts a *uint32 field to a *uint64 field, achieving the same invalid behavior as the first example, but without triggering a runtime failure.

No, they're total different. One cast from uint32 to uint64, one cast from a struct which contains a pointer to uint32 to a struct which contains a pointer to uint64.
If you want to understand as using A and B as proxy, then you should set the field to uint32 and uint64 as in my example (Though I don't think it's the right way to think like that). So now it becomes:
the second example does the conversion by using a proxy struct type of the same size. It silently converts a `uint32` field to a `uint64` field

So the point is not that *A -> *B conversion is invalid, but that the cast of underlying pointer field is invalid.

There's no such operation, the conversion is done on the struct, not their fields.

There's no such operation

You are right, there is no such explicit operation. However, there is implicit (or semantic, if you like) operation that happens during this *A -> *B conversion.
If you run both tests, it will be clear that both are invalid semantically. Does it matter that much if there is no field conversion operation defined explicitly in this case?
Both versions have an invalid behavior as a matter of fact, so I'm trying to propose to introduce more (optional) runtime check(s) to detect those issues as well.

I thought about doing this, but it would be very difficult in general. Because data structures can be cyclic, to be fully general, we'd have to test for graph isomorphism, which is NP complete.
Maybe there's some sweet spot of partial testing that still helps but isn't intractable.
(I thought I filed an issue for this, but I can't immediately find it. Maybe I realized the difficulty before even filing the issue.)

@mdempsky Should the unsafe.Pointer rules updated first?

@mdempsky, why would we have to test for graph isomorphism?
Why wouldn't it suffice to check that all pointers reachable by tracing the data structure from a typed root match the size and pointer layout of the type through which they are reached?

@bcmills Yeah, I think graph isomorphism was too general of a problem to reference here. (In particular, graph isomorphism assumes edges are indistinguishable, but our edges are uniquely distinguishable by their memory offset within the origin node/variable.)
I think fully and recursively tracing out all pointers to make sure they point to the right type would be sufficient. It would take at least time proportional to the amount of memory reachable from the converted pointer though, which could be substantial in some cases.
That's also just for handling conversions involving numbers, pointers, and structs. It becomes even more complex if we want to worry about Go language types (channels, maps, interfaces, functions).

Since this is more or less C/syscall-related, limiting the scope to numbers, pointers and structs should be sufficient.
Also, the overhead is clear, but this would still be very useful for debugging unsafe code. I already found a few bugs in one complex codebase using checkptr and I have a few reasons to believe that there is a bug involving an implicit conversion hidden in it as well.
@mdempsky I could help with the implementation, but I might have a few questions along the way. Can I contact you in the Gophers Slack or somewhere else?

@denwc Thanks. Questions related to the issue would be best asked and answered here. General questions about compiler internals would be best on<EMAIL_ADDRESS>


bug: after latest update, there is error in edgy

Did you check docs and existing issues?

[X] I have read all the LazyVim docs
[X] I have searched the existing issues of LazyVim
[X] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)
NVIM v0.10.0
Operating system/version
Linux Ubuntu 22.04
Describe the bug
Failed to run config for edgy.nvim
vim/shared.lua:0: t: expected table, got nil
stacktrace:

vim/shared.lua:0 in validate
vim/shared.lua:0 in list_contains
/LazyVim/lua/lazyvim/plugins/extras/ui/edgy.lua:103 in values

Steps To Reproduce
Start Neovim
I don't have any custom config for edgy
Expected Behavior
no error

@dpetka2001 yes, everything is updated.

What does nvim --version show?

I have the same problem, also on latest. Maybe it's conflict with another package from extra? I have a lot of them enabled :)

NVIM v0.11.0-dev-226+g721551210
Build type: RelWithDebInfo
LuaJIT 2.1.1716656478
Run "nvim -V1 -v" for more info

I just tried with default LazyVim installation and enabled only the edgy Extra, nothing else. And I could not reproduce it. Can you try with default LazyVim installation? If you can't repro with default LazyVim installation, then you should disable all the Extras and enable them again one by one to find out the conflicting one. I don't know which Extras you have installed.

@ibeex What does nvim --version show?

@dpetka2001
❯ nvim --version
NVIM v0.10.0
Build type: Release
LuaJIT 2.1.1713484068
Run "nvim -V1 -v" for more info

@dpetka2001 with clean install there is no error... here is my config for xtra
  "extras": [
    "lazyvim.plugins.extras.coding.copilot",
    "lazyvim.plugins.extras.coding.copilot-chat",
    "lazyvim.plugins.extras.coding.mini-surround",
    "lazyvim.plugins.extras.editor.harpoon2",
    "lazyvim.plugins.extras.editor.mini-files",
    "lazyvim.plugins.extras.editor.refactoring",
    "lazyvim.plugins.extras.formatting.black",
    "lazyvim.plugins.extras.formatting.prettier",
    "lazyvim.plugins.extras.lang.clangd",
    "lazyvim.plugins.extras.lang.markdown",
    "lazyvim.plugins.extras.lang.python",
    "lazyvim.plugins.extras.lang.terraform",
    "lazyvim.plugins.extras.lang.toml",
    "lazyvim.plugins.extras.lang.yaml",
    "lazyvim.plugins.extras.ui.edgy",
    "lazyvim.plugins.extras.util.dot"
  ],

If there's no error, then it's either something in your personal configuration or there might be some other Extra that conflicts. Try enabling them one by one to see which one causes the conflict.

same, no errors on clean, will try to find an extra as I don't configure edgy in any of my plugins

Maybe it's copilot-chat? Can you try without that?

I get it since https://github.com/LazyVim/LazyVim/blob/main/lua/lazyvim/plugins/extras/ui/edgy.lua#L103 disabling
return {
  { "nvim-neo-tree/neo-tree.nvim", enabled = false },
}

since I am using mini.files reproduce this ...

can also confirm, disabling neo-tree causes the problem on fresh config

Feel free to create a PR so that maintainer can look at it.


Openvpn

Hello,
First of all, thank you for everything you have done.
Would it be possible to have OpenVPN installed to securely access private DNS services like Grafana, etc.?
Nice day :)

Sorry, I replied in the wrong window. :(


Provide helper script for generating certificates and keys

It will be useful to have a script used for development that generate server and client-side certificates.

Done in #126


added the ability to mask with a UIBezierPath that scales to the size of the image

:+1: Thanks! Looks great.


Performance bottleneck with Constant Propagation Pass.

I hope to import the ONNX model of ResNet-50 and lower the input to MLIR built-in transformation dialect. But in the process, I encountered serious performance problems.
Below is the execution time report:
root@a4270fe60c27:/workdir/onnx/onnx-mlir/resnet50# ../build/Debug/bin/onnx-mlir --EmitMLIR  --mlir-timing --onnx-op-transform-report resnet50-v1-12.onnx
../build/Debug/bin/onnx-mlir: /opt/conda/lib/libtinfo.so.6: no version information available (required by ../build/Debug/bin/onnx-mlir)
ONNXOpTransform iterated 0 times, converged true
===-------------------------------------------------------------------------===
                         ... Execution time report ...
===-------------------------------------------------------------------------===
  Total Execution Time: 30.7521 seconds

  ----Wall Time----  ----Name----
    0.0028 (  0.0%)  'func.func' Pipeline
    0.0028 (  0.0%)    {anonymous}::DecomposeONNXToONNXPass
    0.0062 (  0.0%)  onnx_mlir::{anonymous}::ShapeInferencePass
    0.0159 (  0.1%)  Canonicalizer
    0.0092 (  0.0%)  onnx_mlir::{anonymous}::ShapeInferencePass
   26.8833 ( 87.4%)  'func.func' Pipeline
   26.8833 ( 87.4%)    {anonymous}::ConstPropONNXToONNXPass
    2.9017 (  9.4%)  {anonymous}::ONNXOpTransformPass
    0.0109 (  0.0%)    'builtin.module' Pipeline
    0.0018 (  0.0%)      'func.func' Pipeline
    0.0018 (  0.0%)        {anonymous}::DecomposeONNXToONNXPass
    0.0020 (  0.0%)      onnx_mlir::{anonymous}::ShapeInferencePass
    0.0028 (  0.0%)      Canonicalizer
    0.0020 (  0.0%)      onnx_mlir::{anonymous}::ShapeInferencePass
    0.0020 (  0.0%)      'func.func' Pipeline
    0.0020 (  0.0%)        {anonymous}::ConstPropONNXToONNXPass
    0.0016 (  0.0%)  SymbolDCE
    0.0004 (  0.0%)  CSE
    0.0000 (  0.0%)    (A) DominanceInfo
    0.0031 (  0.0%)  'func.func' Pipeline
    0.0016 (  0.0%)    {anonymous}::ONNXPreKrnlVerifyPass
    0.0015 (  0.0%)    {anonymous}::InstrumentONNXPass
    0.0288 (  0.1%)  onnx_mlir::FrontendToKrnlLoweringPass
    0.0202 (  0.1%)  Canonicalizer
    0.0086 (  0.0%)  'func.func' Pipeline
    0.0086 (  0.0%)    {anonymous}::DisconnectKrnlDimFromAllocPass
    0.0149 (  0.0%)  Canonicalizer
    0.0325 (  0.1%)  'func.func' Pipeline
    0.0325 (  0.1%)    onnx_mlir::krnl::ConvertKrnlToAffinePass
    0.0001 (  0.0%)      (A) DataLayoutAnalysis
    0.8216 (  2.7%)  Rest
   30.7521 (100.0%)  Total

It can be seen that ConstPropONNXToONNXPass occupies most of the time.
After that, I used the Tracing SDK provided by perfetto to trace its internal implementation and found that the ConstPropElementwiseBinary function occupies most of the time (about 100%) in the constant propagation pass. Going deeper, I found that the IterateConstPropElementwiseBinary function occupies most of the time (about 92%) in the ConstPropElementwiseBinary.
Has anyone else encountered this strange problem? How should I fix it?

Test environment:

ONNX-MLIR commit ID: 9c62e1a46ec27818dba87724fcf678a7be6059e9
ONNX model of ResNet-50: resnet50-v1-12.onnx

@zincnode constant propagation is to do computation at runtime for operations whose inputs are constant. So for big inputs , it would take time because constant propagation is done in sequential way. We need to parallelize constant propagation to improve its performance. Really appreciate if someone could help with that.

@zincnode constant propagation is to do computation at compile time for operations whose inputs are constant. So for big inputs , it would take time because constant propagation is done in a sequential way. We need to parallelize constant propagation to improve its performance. Really appreciate if someone could help with that.

Thanks for your reply. Parallel execution does improve efficiency. Hope someone can improve on this. 😂


Does not work across all LATS environments

My new agency uses their own LATS, and thus use their own custom URL.
AFAIK all LATS use some part of lats.cma in teh URL (EX: https://oaglats.cma.com)
Can you wildcard lats.cma for applicable URLs for this extension?

Unfortunately Google doesn't allow wildcards like that. Specifically, referring to your idea of *lats.cma*, they say "If '*' is in the host, it must be the first character" so that won't work.
I've updated an existing pattern to *.cma.com. This is a bit overkill since there are other services on that domain besides LATS, but the script should quickly detect this and exit. The only alternative would be to manually add every domain as it's brought to my attention.


ENH add Lambda750kCam

support for ADLambda X-Spectrum Lambda 750K area detector
We also have support for the plugin chain we use now.  That plugin chain is likely to be redeveloped in the next year and might not be useful in ophyd, other than pedagogical value.

The scatter-gather plugins could probably come upstream.  I would be surprised if those go away...

@tacaswell https://github.com/bluesky/ophyd/blob/7f1452d41271d353c3d7d0f6b8a93adef7dc0858/ophyd/areadetector/plugins.py#L1919
https://github.com/bluesky/ophyd/blob/7f1452d41271d353c3d7d0f6b8a93adef7dc0858/ophyd/areadetector/plugins.py#L2251

ah, forgot @prjemian was working from an older version of ophyd.

Thanks.  I had local overrides for UPPER case in scatter and gather
On Thu, Aug 22, 2019, 4:27 PM Thomas A Caswell<EMAIL_ADDRESS>wrote:

ah, forgot @prjemian https://github.com/prjemian was working from an
older version of ophyd.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/bluesky/ophyd/pull/758?email_source=notifications&email_token=AARMUMDJ7LLFNO7AKSAAOOLQF4ADHA5CNFSM4IOWNEGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD46OJ2Y#issuecomment-524084459,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AARMUMBNJADRXQWAK2HWMX3QF4ADHANCNFSM4IOWNEGA
.


Yii2 Guide Incomplete: Internationalization

Page: http://www.yiiframework.com/doc-2.0/guide-tutorial-i18n.html
This page makes reference to storing translations in PHP files for each 'category', but makes no mention at all to what these files look like, what class they extend (if any), or what format the translations are stored in (object? associative array?). This section could be expanded to include this information, as right now it's not of much use to a newcomer to Yii or Yii 2 who doesn't know what these files should look like, just that they should exist.

have you seen the links to 'yii\i18n\PhpMessageSource' http://www.yiiframework.com/doc-2.0/yii-i18n-phpmessagesource.html ?

added some small improvements. is it more clear now?

dynasource: Yes I have, I personally got translations working before I opened the issue; it's not so much a request for help as an indication that I experienced difficulty understanding that part of the documentation, so others might as well.
cebe: It definitely is, as before there was no indication that 'how to make these files' would be covered - it simply jumped from 'you need these files' to 'now that you have them'. So it's more clear now for sure. But unless the major 'push' is to get people to generate it automatically via the message command, it still places no focus on how one might write the translation files manually if one so desired; for very simple sites it's almost more complication than it's worth to run the command line instead of just writing it yourself- it might be well served to have an example of a typical translations file or folder structure, so readers will understand the concept and structure if nothing else. As it stands, a total newcomer is essentially presented with: 'do this command line thing and trust it will work out fine'. I personally prefer to see how something is put together manually, before being shown the automated alternative. Of course that's just my suggestion; there may be deeper intent behind the documentation that I don't see.

@ChrGriffin, thanks for sharing your view on this part of our documentation. It seems that you are confident about what needs to be improved. Are you able to add your improvement with a pull request to https://github.com/yiisoft/yii2/blob/master/docs/guide/tutorial-i18n.md? Would be great!

For sure, as soon as I'm able I'll do that!

great. Thanks


Bug Description
Enabling observability component to get metrics for CSI driver. I apologize for the inconvenience, but it seems that the chart version and AppVersion are not compatible, preventing the installation of the chart. Which one to use? 1.5.1 or 1.5.0?
Logs

Screenshots

Additional Environment Information
No response
Steps to Reproduce
helm install karavi-observability dell/karavi-observability -n kob-csmvxflexos -f csm-observability-values.yml
Error: INSTALLATION FAILED: failed to fetch https://github.com/dell/helm-charts/releases/download/karavi-observability-1.5.1/karavi-observability-1.5.1.tgz : 404 Not Found
Expected Behavior
helm install karavi-observability dell/karavi-observability -n kob-csmvxflexos -f csm-observability-values.yml
NAMESPACE: kob-csmvxflexos
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
CSM Topology
The CSM Topology deployment has been successfully installed.
CSM Driver(s)
PowerFlex Version 3.5.1200 / Build 103
Installation Type
Helm Install
Container Storage Modules Enabled
No response
Container Orchestrator
v1.26.6
Operating System
Ubuntu

Hi @deshab, please use dell/karavi-observability 1.5.0 version and 1.5.0 app version. Thanks!

Thank you @shaynafinocchiaro.

@shaynafinocchiaro Thank you, while version 1.5.0 of the helm chart is successfully installed, it seems that there is a problem retrieving metrics through the endpoint. I would like to confirm if the endpoint you mentioned, "otel-collector:8443," is correct or if there is any missing component such as "/metrics." Could you please provide any relevant documentation or resources that could help in resolving this issue? I would be glad to assist you further.

@deshab - I have pinged you the details in the teams. Let me know if that works.

@deshab  - Query has been addressed.
https://: /metrics - for Metrics
https://: /query - for topology
https://dell.github.io/csm-docs/v3/observability/troubleshooting/

After a quick call with the CORE team, now we are able to access the metrics. Thank you, Raja, Luke & Harsha.


Update SendGridKit to version 2.0.1

This mainly fixes an issue with the email content, as described in #43

Is this project still maintained?

@melgu Can you update the README to reflect to version bump with async await examples etc?


feat: use @grpc/proto-loader

This PR does something similar as https://github.com/googleapis/gax-nodejs/pull/229 but for this codebase.
This is possibly a breaking change because the shape of objects returned by grpcProtoLoader.loadSync is different than those returned by grpc.load. I've tried preserving behavior as best as possible otherwise.
One thing that is clearly different is that loadProtoFile now returns the services defined in a file rather than a specific service. I changed the name (to remove the trailing underscore) since it's already private -- though I didn't change it more liberally because arguably it was a misnomer before, and it is less of a misnomer now.
I tested this with @google-cloud/spanner and @google-cloud/firestore and the system tests seem to work. I am not aware of any other dependencies that use GrpcService.

Codecov Report

Merging #62 into master will decrease coverage by 0.41%.
The diff coverage is 89.58%.

@@            Coverage Diff             @@
##           master      #62      +/-   ##
==========================================
- Coverage   97.57%   97.15%   -0.42%
==========================================
  Files           8        8
  Lines        1484     1478       -6
  Branches       69       68       -1
==========================================
- Hits         1448     1436      -12
- Misses         24       30       +6
  Partials       12       12

Impacted Files
Coverage Δ

src/service.ts
97.17% <100%> (-0.02%)
:arrow_down:

test/service.ts
98.17% <86.84%> (-0.65%)
:arrow_down:

Continue to review full report at Codecov.

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

@JustinBeckwith I realized some tests are being skipped, let me deal with that first before merging

@JustinBeckwith Are you OK with this extra change on top? https://github.com/googleapis/nodejs-common-grpc/pull/62/commits/553ef78571343c2ea02f0fb1bf221f43b815d4de I needed this to make sure all asserts were actually running.

LGTM


test: enable PG regress test numeric.sql

Check https://github.com/risingwavelabs/risingwave/tree/main/src/tests/regress to see how we enable the test case

Probably cannot pass without making a decision on #239


CTC Beam Search - Torchaudio wrapper - CTC Prefix Beam Search and CTC Beam Search from scratch + kenlm

The goal of the PR is to add CTC Frame-synchronous beam search in SpeechBrain. It support kenLM scorers. It works out of the box with a Sentencepiece tokeniser or a CTCLabelEncoder.
Some part of the code is taken and modified from PyCTCDecode (see: https://github.com/kensho-technologies/pyctcdecode).
How to test it?
Download our pertained CTC wav2vec2 from our DropBox
cd recipes/LibriSpeech/ASR/CTC/
wget -O wav2vec.zip https://www.dropbox.com/sh/qj2ps85g8oiicrj/AAAxlkQw5Pfo0M9EyHMi8iAra?dl=1
unzip wav2vec.zip -d wav2vec2_ctc

Run the recipe
# make sure that the `output_folder` name match the pretained folder.
python3 train_with_wav2vec.py hparams/train_hf_wav2vec.yaml --data_folder=path --space_index=29

Results

Test-other WER (%)
Time (minutes)
Test-clean WER (%)
Time (minutes)
Decoder method
Encoder

12.44
1.25
5,17
1.01
CTCPrefixBeamSearch
Transformer

12.44
1.26
5.16
0.59
CTCBeamSearch
Transformer + Sentencepiece

9.07
1.29
3.74
0.59
CTCBeamSearch + 4-grams
Transformer + Sentencepiece

9.22
1.44
3.81
1.04
CTCPrefixBeamSearch + 4-grams
Transformer + Sentencepiece

12.46
1.39
5.22
1.36
Torchaudio CPU Beam Search
Transformer + Sentencepiece

12.44
0.21
5.18
0.22
Torchaudio CUDA Beam Search
Transformer + Sentencepiece

Batch size = 9 and beam_width = 10

Test-other WER (%)
Time (minutes)
Test-clean WER (%)
Time (minutes)
Decoder method
Encoder

3.99
1.38
1.92
1.47
Torchaudio CPU Beam Search
Wav2Vec + LabelEncoder

3.96
2.31
1.90
2.37
CTCBeamSearch
Wav2Vec + LabelEncoder

3.97
2.29
1.90
2.37
CTCPrefixBeamSearch
Wav2Vec + LabelEncoder

3.99
1.46
1.92
1.56
CTCPrefixBeamSearch
Wav2Vec + LabelEncoder

To do:

[x] make it equivalent to the official CTC Prefix Beam Search paper
[x] documentation
[x] clean
[x] report results
[x] add Torchaudio CPU decoding
[x] add Torchaudio GPU decoding
[x] add test examples for each ones
[ ] modify all CTC recipes and use the new Beam Search?
[x] refacto kenLM language model
[x] blank skip heuristic
[x] kenLM support for BS
[x] kenLM support for CTC Prefix BS
[x] SentencePiece compatibility with CTC Prefix BS and BS

Additional Comments:
C. Recipe tests are failing:
 recipes/LibriSpeech/ASR/CTC/hparams/train_hf_wav2vec.yaml
	  File "/workspace/speechbrain_ctc/speechbrain/decoders/ctc.py", line 1146, in partial_decoding
	    token = self.vocab_list[token_index]
	IndexError: list index out of range

recipes/LibriSpeech/ASR/CTC/hparams/downsampled/train_hf_wavlm_*.yaml
   raise KeyError(f"Override '{k}' not found in: {[key for key in d.keys()]}")
KeyError: "Override 'use_language_modelling' not found in: ['seed', '__set_seed', 'output_folder', 'wer_file', 'save_folder', 'train_log', 'wav2vec2_hub', 'wav2vec2_folder', 'data_folder', 'train_splits', 'dev_splits', 'test_splits', 'skip_prep', 'ckpt_interval_minutes', 'train_csv', 'valid_csv', 'test_csv',
'number_of_epochs', 'lr', 'lr_wav2vec', 'sorting', 'auto_mix_prec', 'sample_rate', 'downsampling_factor', 'upsampling', 'batch_size', 'test_batch_size', 'train_dataloader_opts', 'valid_dataloader_opts', 'test_dataloader_opts', 'activation', 'dnn_layers', 'dnn_neurons', 'freeze_wav2vec', 'ctc_neurons', 'outp
ut_neurons', 'blank_index', 'epoch_counter', 'augmentation', 'enc', 'wav2vec2', 'downsampler', 'ctc_lin', 'log_softmax', 'ctc_cost', 'modules', 'model', 'model_opt_class', 'wav2vec_opt_class', 'lr_annealing_model', 'lr_annealing_wav2vec', 'label_encoder', 'checkpointer', 'train_logger', 'error_rate_computer'
, 'cer_computer']"

D. In the seq2seq beamsearcher, we separate the beamsearch from the scorers. Do you think we can do something similar here (e.g, lm rescoring with kenlm can be a scorer)?
E. I would merge the latest devlop here.

A. Comments on train.py and YAML files:

In other recipes, the beam searcher is declared in the YAML file, while here it is declared in train.py. To maintain consistency, could we move it to the YAML file?

Unfortunately, as the implementation expect to have access to the vocab_list which can only be retrieve thanks to the tokenizer, we can't instantiate the searcher in the YAML. As we discusses privately, I will expose some decoding hparams in the YAML such as the beam_size, etc.. as well as clarifying more in the headers of train.py and hparams.py.
What we can do, to make it more modular, is to add a new key called searcher in the YAML such as:
searcher: !name:speechbrain.decoders.CTCBeamSearcher

so that we can directly from the YAML define the BeamSearch that we want to use (except TorchAudioCTCPrefixBeamSearcher as the args differs too much).
See new commits.

The current name "decoder" might cause confusion, as in previous recipes, "decoder" refers to a neural network used after the encoder. I would suggest renaming it to "beamsearcher" to match the naming conventions in other recipes.

I changed all occurrence of decoder to searcher.

Important beam search hyperparameters (e.g., beam size) should be included in the YAML file, allowing users to easily tune them.

Done.

Providing a recipe with an example of a CTC beam search with KenLM would be valuable. We can incorporate this into hparams/train_hf_wav2vec.yaml and hparams/train_sb_wav2vec.yaml. Don't forget to update the README file (and the HF repo just before the release) accordingly.

Done. See README.md and hf/sb/wavlm recipes.
B. Documentation:

class CTCBeam: The docstring could be improved to explain all the arguments and include an example (if possible). Additionally, it would be helpful to provide descriptions of the arguments and return values in the internal methods.

Done.

CTCBaseSearcher: It would be beneficial to add a docstring example to this class as well.

Done.

In both speechbrain/decoders/ctc.py and speechbrain/decoders/language_model.py, adding more in-line comments would greatly enhance understanding of the code flow.

Done.

Clarify in the header of the YAML file that we use beam search.
Done

After merging this PR, it's essential to create a tutorial demonstrating the new features implemented here.
Yes, I'm planning to do a google colab tutorial.

C. Recipe tests are failing:
The issue was related to the space_index that was incorrectly set in new recipes. I replaced it with space_token where the index is automatically retrieved in the vocabulary.

D. In the seq2seq beamsearcher, we separate the beamsearch from the scorers. Do you think we can do something similar here (e.g, lm rescoring with kenlm can be a scorer)?
The issue is that we only have one 'scorer': kenLM. No batching/log_probs. So it means, we would need to have a new ScorerBuilder interface, a different kenLMScorer than the one in scorer.py etc... I think it makes more sense to just leave it as an arg. I don't think we need the extreme modularity provided by ScorerBuilder in the case of CTC only decoding.

E. I would merge the latest devlop here.
Will do.

Thank you @Adel-Moumen for addressing my comments. This is an amazing work. I did some inference tests and everything runs as expected. Here is the second batch of comments:

I think we can now extend the beamsearcher to all the other recipes using CTC (e.g., whisper could be the first one).
We can add some full-inference recipe tests for the CTC beamsearchers. As mentioned privately, we can take this opportunity to make the inference test fasters by downloading a version of LibriSpeech test-clean with only a few sentences.
I would retrain wav2vec2 ctc, due to the dimensionality issues that we have with the previous checkpoints.

Some updates regarding this PR:

I think we can now extend the beamsearcher to all the other recipes using CTC (e.g., whisper could be the first one).

I changed the following recipes: CommonVoice, Aishell, LibriSpeech and Switchboard. I can't change the others recipe due to the argument space_token. On Media for instance, I don't know what could be this value and I prefer to not change anything in case it will harm the results.
One note: Aishell with Beam Search is not leading to any improvement. I tried the TorchAudio/CTCBeamSearch/CTCPrefixBeamsearch with and without kenLM and it doest yield to any gains.

We can add some full-inference recipe tests for the CTC beamsearchers. As mentioned privately, we can take this opportunity to make the inference test fasters by downloading a version of LibriSpeech test-clean with only a few sentences.

Done.

I would retrain wav2vec2 ctc, due to the dimensionality issues that we have with the previous checkpoints.

Done.
I am currently running the recipe tests. I will report shortly if everything went fine.

I am currently running the recipe tests. I will report shortly if everything went fine.

Everything went fine!

I ran again recipe tests and all seem to work. The only tests that fail are the direct recipes in timers and such, SLURM, fluent. This is expected because they use the pattern:
asr_model: !apply:speechbrain.pretrained.EncoderDecoderASR.from_hparams
    source: speechbrain/asr-crdnn-rnnlm-librispeech
    run_opts: {"device":"cuda:0"}

which is calls code not compatible with this version. When we will release the new version, we have to modify the HF repo accordingly and the issues will be fixed.
I think we can finally merge this PR. This is an amazing work @Adel-Moumen l and a fundamental step toward speechbrain 1.0!


Russian date formats do not parse out "real character" escaping single quotes

CLDR stipulates that « Any "real" characters need to be quoted, as in the following where a real character 'g' needs to be in the pattern. », cf. http://cldr.unicode.org/translation/date-time
Starting from line 1810 in the Russian CLDR summary data (http://www.unicode.org/cldr/charts/26/summary/ru.html), we note that the abbreviation for "year" (года) is listed as 'г', where the single quotes should be parsed out of any translations passed on.
We have noticed, however, that the quotes are not being parsed out of translations in the js compiled translations of the CLDR data, where the class 'plaintext' is assigned and the single quotes have not been parsed out:

compiled js file output:

real-life example :

I am unsure how this would accommodate other "real characters" that require the quotes to be parsed out, e.g. Croatian "hour" ("hodina" > 'h') cf line 1862 of http://www.unicode.org/cldr/charts/26/summary/hr.html
Please advise.

@KL-7 - it looks like the single-quotes around the г for "года" have returned.


⚠ Bofrost.at has degraded performance

In 5e963d7, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 2286 ms

Resolved: Bofrost.at performance has improved in 1fd2251.


Fix codecov.yml

Let me know how this works ;) 👍

[Current coverage][cc-pull] is 95.00%

Merging [#62][cc-pull] into [master][cc-base-branch] will increase coverage by 4.59%

@@             master        #62   diff @@
==========================================
  Files            17          7     -10
  Lines          1845        340   -1505
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
- Hits           1668        323   -1345
+ Misses          177         17    -160
  Partials          0          0

7 files (not in diff) in ...oExample/KakapoTests were deleted. more
2 files (not in diff) in ...xample/KakapoExample were deleted. more
1 files (not in diff) in KakapoExample were deleted. more

[][cc-pull]

Powered by Codecov. Last updated by [659735b...7d1862a][cc-compare]
[cc-base-branch]: https://codecov.io/gh/devlucky/Kakapo/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/devlucky/Kakapo/compare/659735bae4417bf2bfa62d0c23526f97d5eeafd3...7d1862a85b2ab999265f846e6c4b668174c2f8ac
[cc-pull]: https://codecov.io/gh/devlucky/Kakapo/pull/62?src=pr

@stevepeak hey! ty very much for the fast reply and PR, looks like now partially works but Source/NSURLRequest+FixCopy.swift is not ignored, any idea?

@stevepeak I'm changing the project structure in #63 and still have some troubles with non-excluded files and folders. Also I was wondering if there is a way to gather only the need coverage (I thin there was a -J 'name' option but sees to not work)
==> Travis CI detected.
(root) .
  -> Swift in /Users/travis/Library/Developer/Xcode/DerivedData
    + Building reports for Kakapo framework
    + Building reports for Pods_Kakapo_iOSTests framework
error: Failed to load coverage: Malformed coverage data
    + Building reports for Kakapo iOSTests xctest
==> Running gcov (disable via -X gcov)
  -> Obj-C in /Users/travis/Library/Developer/Xcode/DerivedData
  -> gcov in .
==> Searching for coverage reports
    Found 4 reports.
**> Python coverage not found
==> Detecting git/mercurial file structure
==> Reading reports
  + ./.fastlane/report.xml bytes=363
  + ./Kakapo.framework.coverage.txt bytes=4852
  + ./KakapoiOSTests.xctest.coverage.txt bytes=14818
  + ./Pods_Kakapo_iOSTests.framework.coverage.txt bytes=0
==> Appending adjustments (http://bit.ly/1O4eBpt)
  --> Found 528 adjustments
(url) https://codecov.io
(query) branch=master&commit=3d935d5c443fe28c0eccd92f8cb006e35ca5aa42&build=388.4&build_url=&tag=&slug=devlucky/Kakapo&yaml=codecov.yml&service=travis-org&flags=&pr=63&job=137092152
==> Uploading reports
    Pinging Codecov
    Uploading to S3
Reports queued to http://codecov.io/github/devlucky/Kakapo/commit/3d935d5c443fe28c0eccd92f8cb006e35ca5aa42
Done. Your build exited with 0.

I guess only ./Kakapo.framework.coverage.txt is needed.

oh I'm going to merge because I have the doubt that codecov might "refresh" the settings only from master, let's try

According to https://travis-ci.org/devlucky/Kakapo/jobs/137095148 when I removed -J the whole project was considered and the coverage dropped at 4X% (BTW the badge should only show the master coverage but was displaying that value). So the iml excluded files seems to not be considered. Also -J 'Kakapo' is considering:
+ ./Kakapo.framework.coverage.txt bytes=4852
  + ./KakapoiOSTests.xctest.coverage.txt bytes=14818
  + ./Pods_Kakapo_iOSTests.framework.coverage.txt bytes=0

instead of only ./Kakapo.framework.coverage.txt. Hope it helps


Multiple GPU - Degradation over time

Checked other resources

[X] I added a very descriptive title to this issue.
[X] I searched the LangChain documentation with the integrated search.
[X] I used the GitHub search to find a similar question and didn't find it.

Example Code
chain = LLMChain(llm=llm, prompt=prompt)
result = chain(inputs={"context": context, "question": question})
answer = result["text"]

I do use the PromptTemplate, but this is not relevant to my issue.
Description
I am using 2x A100 GPU.  What I have noticed is that there is GPU degradation over time.
This is my spool up data:
ggml_init_cublas: GGML_CUDA_FORCE_MMQ:   no
ggml_init_cublas: CUDA_USE_TENSOR_CORES: yes
ggml_init_cublas: found 2 CUDA devices:
  Device 0: NVIDIA A100-PCIE-40GB, compute capability 8.0, VMM: no
  Device 1: NVIDIA A100-PCIE-40GB, compute capability 8.0, VMM: no

In my code, the above is part of an API that takes in a request and then responds to it.  I am making 5 calls to the API one after another, and collating the data for a final summarisation call.
I am not overly impressed with the speeds here in any event - so if anyone has any tips for improving, I don't think 17.25 tokens is very good for dual A100s.
llama_print_timings:        eval time =      57.98 ms /     1 runs   (   57.98 ms per token,    17.25 tokens per second)
llama_print_timings:       total time =    6722.12 ms

llama_print_timings:        eval time =    4804.66 ms /    70 runs   (   68.64 ms per token,    14.57 tokens per second)
llama_print_timings:       total time =   17722.48 ms

llama_print_timings:        eval time =    5950.61 ms /    77 runs   (   77.28 ms per token,    12.94 tokens per second)
llama_print_timings:       total time =   23459.58 ms

I would have expected the "overall" time to change but the actual tokens per second to remain somewhat consistent - but instead it just gets worse.
I also created a GPU monitor tool, and in that tool, the first call is utilising 25% and 20% for GPU 1 and 2 - but then it goes down to 20% and 17% and then 16% and 15%, and when making a LOT of calls, I have seen it as low as 9% on each GPU - at this point the response time is a minute plus.
Why am I writing a bug report here? Sounds like a you problem....because I ran it with Llama-cpp-python - without Langchain and this was not a problem, there was no degradation over time.
System Info
Wrinkles....
I am using Window 10, inside a VMWare Virtual Machine.  Python, Langchain, Llama-cpp-python is all up to date, as are the Nvidia drivers and CUDA toolkit (12.2).
As noted above - this only occurs when using langchain - not when doing the same workflow, without langchain.
Related Components

[ ] LLMs/Chat Models
[ ] Embedding Models
[ ] Prompts / Prompt Templates / Prompt Selectors
[ ] Output Parsers
[ ] Document Loaders
[ ] Vector Stores / Retrievers
[ ] Memory
[ ] Agents / Agent Executors
[ ] Tools / Toolkits
[ ] Chains
[ ] Callbacks/Tracing
[ ] Async

The API calls are being made to FastApi from a C# application - they are each made separately as there is no batching in place as yet.  They are not identical but this is a RAG workflow so the Prompt and Question are the same each time.

Other than FastApi there are no other Python libraries being used.

Apologies, in one of my drafts this was already included - not sure what happened to it:

llm = LlamaCpp(model_path=model_loc, n_ctx=0, verbose=True, n_gpu_layers=-1)

It starts immediately even during the first call.

Yes, but it is a huge amount of data so here are a few from the first call:

Call 1:
Mon Jan 15 05:39:28 2024
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 537.13                 Driver Version: 537.13       CUDA Version: 12.2     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                     TCC/WDDM  | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  NVIDIA A100-PCIE-40GB        TCC   | 00000000:04:00.0 Off |                  Off |
| N/A   36C    P0              41W / 250W |   9437MiB / 40960MiB |     30%      Default |
|                                         |                      |             Disabled |
+-----------------------------------------+----------------------+----------------------+
|   1  NVIDIA A100-PCIE-40GB        TCC   | 00000000:1C:00.0 Off |                  Off |
| N/A   34C    P0              44W / 250W |   3341MiB / 40960MiB |     28%      Default |
|                                         |                      |             Disabled |
+-----------------------------------------+----------------------+----------------------+
Mon Jan 15 05:39:30 2024
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 537.13                 Driver Version: 537.13       CUDA Version: 12.2     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                     TCC/WDDM  | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  NVIDIA A100-PCIE-40GB        TCC   | 00000000:04:00.0 Off |                  Off |
| N/A   36C    P0              41W / 250W |   9437MiB / 40960MiB |     24%      Default |
|                                         |                      |             Disabled |
+-----------------------------------------+----------------------+----------------------+
|   1  NVIDIA A100-PCIE-40GB        TCC   | 00000000:1C:00.0 Off |                  Off |
| N/A   34C    P0              42W / 250W |   3341MiB / 40960MiB |     22%      Default |
|                                         |                      |             Disabled |
+-----------------------------------------+----------------------+----------------------+
Mon Jan 15 05:39:31 2024
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 537.13                 Driver Version: 537.13       CUDA Version: 12.2     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                     TCC/WDDM  | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  NVIDIA A100-PCIE-40GB        TCC   | 00000000:04:00.0 Off |                  Off |
| N/A   36C    P0              40W / 250W |   9437MiB / 40960MiB |     21%      Default |
|                                         |                      |             Disabled |
+-----------------------------------------+----------------------+----------------------+
|   1  NVIDIA A100-PCIE-40GB        TCC   | 00000000:1C:00.0 Off |                  Off |
| N/A   34C    P0              42W / 250W |   3341MiB / 40960MiB |     20%      Default |
|                                         |                      |             Disabled |
+-----------------------------------------+----------------------+----------------------+

You can see that even during the first call, there is a degradation.
Call 2 begins at a worse position than Call 1 started at.
Mon Jan 15 05:39:37 2024
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 537.13                 Driver Version: 537.13       CUDA Version: 12.2     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                     TCC/WDDM  | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  NVIDIA A100-PCIE-40GB        TCC   | 00000000:04:00.0 Off |                  Off |
| N/A   36C    P0              39W / 250W |   9437MiB / 40960MiB |     15%      Default |
|                                         |                      |             Disabled |
+-----------------------------------------+----------------------+----------------------+
|   1  NVIDIA A100-PCIE-40GB        TCC   | 00000000:1C:00.0 Off |                  Off |
| N/A   34C    P0              39W / 250W |   3341MiB / 40960MiB |     14%      Default |
|                                         |                      |             Disabled |
+-----------------------------------------+----------------------+----------------------+

Continuing:

Mon Jan 15 05:39:55 2024
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 537.13                 Driver Version: 537.13       CUDA Version: 12.2     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                     TCC/WDDM  | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  NVIDIA A100-PCIE-40GB        TCC   | 00000000:04:00.0 Off |                  Off |
| N/A   36C    P0              38W / 250W |   9437MiB / 40960MiB |      9%      Default |
|                                         |                      |             Disabled |
+-----------------------------------------+----------------------+----------------------+
|   1  NVIDIA A100-PCIE-40GB        TCC   | 00000000:1C:00.0 Off |                  Off |
| N/A   34C    P0              38W / 250W |   3341MiB / 40960MiB |      9%      Default |
|                                         |                      |             Disabled |
+-----------------------------------------+----------------------+----------------------+

This was the switch I made to llama-cpp-python:
llm = Llama(model_path=model_loc, n_ctx=4096, n_gpu_layers=-1)

Timings - we can see that there is no degradation, it varies but it is down and then up, not just a downward trend.
llama_print_timings:        eval time =   16839.58 ms /   245 runs   (   68.73 ms per token,    14.55 tokens per second)
llama_print_timings:       total time =   21340.13 ms

llama_print_timings:        eval time =    9987.17 ms /   150 runs   (   66.58 ms per token,    15.02 tokens per second)
llama_print_timings:       total time =   14125.37 ms

llama_print_timings:        eval time =    1032.50 ms /    19 runs   (   54.34 ms per token,    18.40 tokens per second)
llama_print_timings:       total time =    2956.17 ms

llama_print_timings:        eval time =     978.67 ms /    17 runs   (   57.57 ms per token,    17.37 tokens per second)
llama_print_timings:       total time =    4137.98 ms

This is mirrored in the SMI where I can see that the GPU usage goes down during a call, but then returns to the original values for the next call:
Call 1:

Mon Jan 15 06:24:29 2024
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 537.13                 Driver Version: 537.13       CUDA Version: 12.2     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                     TCC/WDDM  | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  NVIDIA A100-PCIE-40GB        TCC   | 00000000:04:00.0 Off |                  Off |
| N/A   36C    P0              49W / 250W |  10115MiB / 40960MiB |     26%      Default |
|                                         |                      |             Disabled |
+-----------------------------------------+----------------------+----------------------+
|   1  NVIDIA A100-PCIE-40GB        TCC   | 00000000:1C:00.0 Off |                  Off |
| N/A   34C    P0              36W / 250W |   3767MiB / 40960MiB |     13%      Default |
|                                         |                      |             Disabled |
+-----------------------------------------+----------------------+----------------------+
Mon Jan 15 06:24:30 2024
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 537.13                 Driver Version: 537.13       CUDA Version: 12.2     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                     TCC/WDDM  | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  NVIDIA A100-PCIE-40GB        TCC   | 00000000:04:00.0 Off |                  Off |
| N/A   36C    P0              41W / 250W |  10115MiB / 40960MiB |     21%      Default |
|                                         |                      |             Disabled |
+-----------------------------------------+----------------------+----------------------+
|   1  NVIDIA A100-PCIE-40GB        TCC   | 00000000:1C:00.0 Off |                  Off |
| N/A   34C    P0              42W / 250W |   3767MiB / 40960MiB |     17%      Default |
|                                         |                      |             Disabled |
+-----------------------------------------+----------------------+----------------------+
Mon Jan 15 06:24:31 2024
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 537.13                 Driver Version: 537.13       CUDA Version: 12.2     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                     TCC/WDDM  | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  NVIDIA A100-PCIE-40GB        TCC   | 00000000:04:00.0 Off |                  Off |
| N/A   36C    P0              35W / 250W |  10115MiB / 40960MiB |     21%      Default |
|                                         |                      |             Disabled |
+-----------------------------------------+----------------------+----------------------+
|   1  NVIDIA A100-PCIE-40GB        TCC   | 00000000:1C:00.0 Off |                  Off |
| N/A   34C    P0              35W / 250W |   3767MiB / 40960MiB |     12%      Default |
|                                         |                      |             Disabled |
+-----------------------------------------+----------------------+----------------------+

Call 2:

Mon Jan 15 06:24:33 2024
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 537.13                 Driver Version: 537.13       CUDA Version: 12.2     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                     TCC/WDDM  | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  NVIDIA A100-PCIE-40GB        TCC   | 00000000:04:00.0 Off |                  Off |
| N/A   36C    P0              34W / 250W |  10115MiB / 40960MiB |     25%      Default |
|                                         |                      |             Disabled |
+-----------------------------------------+----------------------+----------------------+
|   1  NVIDIA A100-PCIE-40GB        TCC   | 00000000:1C:00.0 Off |                  Off |
| N/A   34C    P0              36W / 250W |   3767MiB / 40960MiB |     12%      Default |
|                                         |                      |             Disabled |
+-----------------------------------------+----------------------+----------------------+
Mon Jan 15 06:24:34 2024
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 537.13                 Driver Version: 537.13       CUDA Version: 12.2     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                     TCC/WDDM  | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  NVIDIA A100-PCIE-40GB        TCC   | 00000000:04:00.0 Off |                  Off |
| N/A   36C    P0              42W / 250W |  10115MiB / 40960MiB |     20%      Default |
|                                         |                      |             Disabled |
+-----------------------------------------+----------------------+----------------------+
|   1  NVIDIA A100-PCIE-40GB        TCC   | 00000000:1C:00.0 Off |                  Off |
| N/A   34C    P0              44W / 250W |   3767MiB / 40960MiB |     16%      Default |
|                                         |                      |             Disabled |
+-----------------------------------------+----------------------+----------------------+

If this helps to diagnose the issue?


"Got it" button location

Is there a way to move the "Got it" button so it doesn't overlap the target?

@hex6ng In that moment no. I'll add a way soon! Thanks


Screen Rotation on Win Max

The screen on the GPD Win Max displays in portrait (rotated) during install. When it begins the SteamOS install it is still rotated in portrait, but now also has a weird ghosting effect and shows 4 images overlaid on each other. Makes it nearly impossible to see what is on the screen. I tried setting ~/.config/steamos-compositor-plus to ROTATION=right, per the guide here. That had no effect. I then saw Arch has a wiki page for the Win Max and it explains that there isn't a correct screen configuration and you need to manually create a EDID file for it. However, when I tried to create it, I couldn't because the system is mounted read-only.

Looks like you could put the EDID file anywhere. Try putting it somewhere under /etc


Fix conda out of space + pyyaml error

Pull Request Description
Actually fixes the conda out of space.
Workflow run here: https://github.com/alteryx/evalml/actions/runs/6506817876/job/17673105138

After creating the pull request: in order to pass the release_notes_updated check you will need to update the "Future Release" section of docs/source/release_notes.rst to include this pull request by adding :pr:123.

No linked issues found. Please add the corresponding issues in the pull request description.  Use GitHub automation to close the issue when a PR is merged


Fix content alignment

The content on the main page breaks during a certain width range

.

Can I work on this?

Can I work on this?
Sorry we forgot to close the issue.
Actually, the issue has been resolved, and there were slight fixes which is covered in the another issue that has already been taken by someone.


fix: precision not enough should not throw Error (#7096)

Precision not enough should not throw Error.
Approved-By: ZENOTME
(cherry picked from commit 4ba85a8c233e4e8cd0274d77c4bf5f6e731f64ab)
I hereby agree to the terms of the Singularity Data, Inc. Contributor License Agreement.
What's changed and what's your intention?
This section will be used as the commit message. Please do not leave this empty!
Please explain IN DETAIL what the changes are in this PR and why they are needed:

Summarize your change (mandatory)
How does this PR work? Need a brief introduction for the changed logic (optional)
Describe clearly one logical change and avoid lazy messages (optional)
Describe any limitations of the current code (optional)

Checklist

[x] I have written necessary rustdoc comments
[x] I have added necessary unit tests and integration tests
[x] All checks passed in ./risedev check (or alias, ./risedev c)

Documentation
If your pull request contains user-facing changes, please specify the types of the changes, and create a release note. Otherwise, please feel free to remove this section.
Types of user-facing changes
Please keep the types that apply to your changes, and remove those that do not apply.

Installation and deployment
Connector (sources & sinks)
SQL commands, functions, and operators
RisingWave cluster configuration changes
Other (please specify in the release note below)

Release note
Please create a release note for your changes. In the release note, focus on the impact on users, and mention the environment or conditions where the impact may occur.
Refer to a related PR or issue link (optional)

license-header-check Expected — Waiting for status to be reported again? 😭

The weird thing is that this PR cannot be forced to be merged while others can...... Totally lost

Closed because unfinished job


Fix duplicate vowels

Looks like it's possible to get duplicates from getvowel

What if you have A, E, I, O, and U and then run getvowel?

It should probably fail.
Seems like a good edge case to consider, but no game reason to request a
vowel at that point.
On Mon, Sep 6, 2021 at 8:38 AM Wyatt Stanke @.***>
wrote:

What if you have A, E, I, O, and U and then run getvowel?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/maxsaltonstall/letters-with-strangers/issues/172#issuecomment-913616916,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACYFMMKOPTG5FYUKCAP4A3TUASY2TANCNFSM5DCSDZSQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

But some words have two of the same vowels.

You don't need a letter twice to use it two, three or fifty times in a word.

Oops! Sorry, forgot about that :P


Unable to install

deno install --unstable --allow-read --allow-write --allow-net --allow-run -q https://deno.land/x/ssgo/ssgo.ts
error: TS2339 [ERROR]: Property 'getIterator' does not exist on type 'ReadableStream<R>'.
  return res.readable.getIterator();
                      ~~~~~~~~~~~
    at https://deno.land/std@0.77.0/async/pool.ts:45:23

deno --version
deno 1.16.4 (release, aarch64-apple-darwin)
v8 <IP_ADDRESS>
typescript 4.4.2

I just found this site generated, and was hoping to give it a try. It looks very promising, except, that it hasn't been updated in quite a while. Last update to 1.19 was in May, and last release was a year ago.
I tried to give it a look, and see if updating the referenced libraries would resolve the issue, but no.
Updating to current release of the libraries didn't resolve the issue.
I updated all references to current releases, even build a version without dependency of the old OAK framework. And updated to new release of Deno from today (1.17), and libraries to 1.118.
I have no idea where the reference to<EMAIL_ADDRESS>is made. I can capture the error in function runCreator in index.ts. but as mentioned, I have no idea what it is that are referring back to old standard library.
Don't know if this project is dead, given the long time that has past since last update. Would be a shame if that's the case though.

Hello there, thanks for your interest for the project !
I've not had much time lately to take care of it and maintain it but as some people seem to be interested I'll try to take care of it during the week-end 👌

Ok so I've upgraded the sources to use Deno's<EMAIL_ADDRESS>(latest) and refactored some code to match new APIs, could you confirm that the installation command works for you now ?
FIY the<EMAIL_ADDRESS>related error was related to one of ssgo's dependencies, namely oak that was pinned an old version.

Awesome to see this updated. Not sure about oak being the problem though.
I was working on an update that removed OAK entirely, as WebSockets are now part of native Deno, and as WS was removed in latest release of Deno in favor for the new WebSocket API.
Therefore I was working on an update to remove both legacy Deno.WS and oak, but I still got the error message.
I cloned 0.20.0, an get this.
deno run --unstable --allow-read --allow-write --allow-net --allow-run ../ssgo-0.20.0/ssgo.ts build
Check file:///home/jpeterse/ssgo-0.20.0/ssgo.ts
info ssgo 0.20.0
info Emptying dist directory...
info Running creators/index.ts...
Check file:///home/jpeterse/testssgo/creators/index.ts
error: Uncaught (in promise) TypeError: TS2339 [ERROR]: Property 'getIterator' does not exist on type 'ReadableStream<R>'.
  return res.readable.getIterator();
                      ~~~~~~~~~~~
    at https://deno.land/std@0.77.0/async/pool.ts:45:23
  const module = await import(`file://${tempModuleAbs}`)
                 ^
    at async importModule (file:///home/jpeterse/ssgo-0.20.0/src/utils.ts:315:18)
    at async runCreator (file:///home/jpeterse/ssgo-0.20.0/src/index.ts:411:18)
    at async Promise.all (index 0)
    at async Promise.all (index 0)
    at async file:///home/jpeterse/ssgo-0.20.0/src/index.ts:506:5

hm, think I found a work-around.
Clear Deno cache.
Find Deno cache directory with Deno info.
Then clear the directory with rm -rf {DENO_DIR location}
then run SSGO build action again, and it builds without issue.
Why clearing cache works, I don't know.

Yes I've encountered similar cache issues with Deno multiple times already, I'm not sure where it comes from either...
So did the install work as intended, can I close this issue ?

works for me - I'll let @tn confirm it works from him as well

May I ask how one goes about clearing the cache? I’m experiencing this error.

You should be able to force the reload of Deno cache by using the --reload flag:
deno install --unstable --allow-read --allow-write --allow-net --allow-run --reload https://deno.land/x/ssgo/ssgo.ts


Can't receive a message

Hi,
Thanks for the awesome library. I'm trying to receive a message but failed. But when I turn on the js debugger it worked. When I turn off the js debugger it does not working. So why does not it work ?

@bahientn9x react-native uses a different JS engine when the debugger is attached (Google Chrome).  To investigate, try without the debugger, with some extra logging

closing due to inactivity


Fix home page sidebar!

@WisemanLab there may be more tweaking needed but this got a lot of extra stuff added in that I trimmed out - should fix the styling.

Ben
Thanks! I was literally trying to figure out how to fix the homepage sidebar today. I finally got around to changing the logo and the link…  think that was the last obvious remaining UCSF thing… overall its shaping up… slowly, but it is coming together!
Thanks!
Luke
From: Benjamin Barad <notifications<EMAIL_ADDRESS>Reply-To: "WisemanLab/wisemanlab.github.io" <reply<EMAIL_ADDRESS>Date: Wednesday, April 29, 2020 at 2:24 PM
To: "WisemanLab/wisemanlab.github.io" <wisemanlab.github.io<EMAIL_ADDRESS>Cc: Luke Wiseman <wiseman<EMAIL_ADDRESS>Mention <mention<EMAIL_ADDRESS>Subject: Re: [WisemanLab/wisemanlab.github.io] Fix home page sidebar! (#4)
@WisemanLabhttps://github.com/WisemanLab there may be more tweaking needed but this got a lot of extra stuff added in that I trimmed out - should fix the styling.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/WisemanLab/wisemanlab.github.io/pull/4#issuecomment-621472405, or unsubscribehttps://github.com/notifications/unsubscribe-auth/APKDIYBQCURFF3NG3JOPSL3RPCLJ7ANCNFSM4MUCLLVA.

Yes! Only noticeable things for me still are the footer (there is a separate pull request open for that) and the private link (_data/navlinks.yml)


Fixed #31905 -- Made MiddlewareMixin call process_request()/process_response() with thread sensitive.

MiddlewareMixin use sync_to_async with thread_sensitive to prevent errors in database connection clearance.
https://code.djangoproject.com/ticket/31905

@carltongibson
I tried that, see below
class MiddlewareMixinAsyncCorrectThreadTest(SimpleTestCase):
    async def get_response(self):
        return await sync_to_async(HttpResponse)('')

    async def get_middleware(self):
        class SimpleMiddleWare(MiddlewareMixin):
            def process_request(self, request):
                request.id_from_process_request = id(connections['default'])
                return request

            def process_response(self, request, response):
                return request.id_from_process_request, id(connections['default'])

        return await SimpleMiddleWare(self.get_response)(HttpRequest())

    def test_database_wrapper_ids(self):
        database_wrapper_ids = [*(async_to_sync(self.get_middleware)()), id(connections['default'])]
        self.assertEqual(len(database_wrapper_ids), 3)
        self.assertEqual(len(set(database_wrapper_ids)), 1)

It works, but I am not satisfied with it, maybe you are a little more successful.

Thanks both :+1:
@mgaller Welcome aboard :boat:


Music Player

Add music player functionality for when starting a shower
Goal:

Implement custom features on music player

Mostly finished


Improve robustness of test discovery

Also fix tests for old Numpys.

Current coverage is 87.58%

Merging #1804 into master will decrease coverage by -0.01% as of 78dce56

@@            master   #1804   diff @@
======================================
  Files          283     283
  Stmts        50652   50667    +15
  Branches      5252    5257     +5
  Methods
======================================
+ Hit          44367   44376     +9
- Partial        894     899     +5
- Missed        5391    5392     +1

Review entire Coverage Diff as of 78dce56

Powered by Codecov. Updated on successful CI builds.


ARTEMIS-1098 Improve flow control while streaming large messages

(cherry picked from commit c6d24e9073d0793350c24234f85f8d4532d250ff)

@franz1981 Can you close this please.  I've merged but auto close doesn't work for 1.x branch


Force exception variables to escape

Force exception values to live on the ruby stack by adding an artificial reference in a different ruby block.
Motivation

We need to ensure that exception variables are stored in the ruby stack for fixing issues with exception handling.
Test plan

See included automated tests.

We have a policy of testing changes to Sorbet against Stripe's codebase before
merging them. I've kicked off a test run for the current PR.  When the build
finishes, I'll share with you whether or how it failed. Thanks!
Stripe employees can see the build results here:
→ https://go/builds/bui_K2BeILYRHJGSkT
→ https://go/builds/bui_K2Be5gVT3Jp6yk


Packaging ollama + cuda for Arch Linux

Hi! Arch Linux package maintainer for the ollama and ollama-cuda packages here.
Thanks for creating Ollama, it makes LLMs more fun to deal with!
When compiling v0.1.8 for Arch Linux, using this PKGBUILD:
pkgname=ollama-cuda
pkgdesc='Create, run and share large language models (LLMs) with CUDA'
pkgver=0.1.8
pkgrel=1
arch=(x86_64)
url='https://github.com/jmorganca/ollama'
license=(MIT)
provides=(ollama)
conflicts=(ollama)
makedepends=(cmake cuda git go setconf)
_ollamacommit=e21579a0f1548e2d1f77411af3df2037c1f144fe # tag: v0.1.8
# The git submodule commit hashes are here:
# https://github.com/jmorganca/ollama/tree/v0.1.8/llm/llama.cpp
_ggmlcommit=9e232f0234073358e7031c1b8d7aa45020469a3b
_ggufcommit=9e70cc03229df19ca2d28ce23cc817198f897278
source=(git+$url#commit=$_ollamacommit
        ggml::git+https://github.com/ggerganov/llama.cpp#commit=$_ggmlcommit
        gguf::git+https://github.com/ggerganov/llama.cpp#commit=$_ggufcommit)
b2sums=('SKIP'
        'SKIP'
        'SKIP')

prepare() {
  cd ${pkgname/-cuda}

  rm -frv llm/llama.cpp/gg{ml,uf}

  # Copy git submodule files instead of symlinking because the build process is sensitive to symlinks.
  cp -r "$srcdir/ggml" llm/llama.cpp/ggml
  cp -r "$srcdir/gguf" llm/llama.cpp/gguf

  # Do not git clone when "go generate" is being run.
  sed -i 's,git submodule,true,g' llm/llama.cpp/generate_linux.go

  # Set the version number
  setconf version/version.go 'var Version string' "\"$pkgver\""
}

build() {
  export CGO_CFLAGS="$CFLAGS" CGO_CPPFLAGS="$CPPFLAGS" CGO_CXXFLAGS="$CXXFLAGS" CGO_LDFLAGS="$LDFLAGS"
  cd ${pkgname/-cuda}
  go generate ./...
  go build -buildmode=pie -trimpath -mod=readonly -modcacherw -ldflags=-linkmode=external -ldflags=-buildid=''
}

check() {
  cd ${pkgname/-cuda}
  go test ./...
}

package() {
  cd ${pkgname/-cuda}
  install -Dm755 ${pkgname/-cuda} "$pkgdir/usr/bin/${pkgname/-cuda}"
  install -Dm644 LICENSE "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
}

I get:
- Found CUDAToolkit: /opt/cuda/include (found version "12.3.52")
-- cuBLAS found
CMake Error at /usr/share/cmake/Modules/CMakeDetermineCompilerId.cmake:753 (message):
Compiling the CUDA compiler identification source file
"CMakeCUDACompilerId.cu" failed.

Compiler: /opt/cuda/bin/nvcc

Build flags:

Id flags: --keep;--keep-dir;tmp -v

The output was:

2

#$ _NVVM_BRANCH_=nvvm

#$ _SPACE_=

#$ _CUDART_=cudart

#$ _HERE_=/opt/cuda/bin

#$ _THERE_=/opt/cuda/bin

#$ _TARGET_SIZE_=

#$ _TARGET_DIR_=

#$ _TARGET_DIR_=targets/x86_64-linux

#$ TOP=/opt/cuda/bin/..

#$ NVVMIR_LIBRARY_DIR=/opt/cuda/bin/../nvvm/libdevice

#$ LD_LIBRARY_PATH=/opt/cuda/bin/../lib:

#$
PATH=/opt/cuda/bin/../nvvm/bin:/opt/cuda/bin:/usr/lib/go/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_pn

#$ INCLUDES="-I/opt/cuda/bin/../targets/x86_64-linux/include"

#$ LIBRARIES= "-L/opt/cuda/bin/../targets/x86_64-linux/lib/stubs"
"-L/opt/cuda/bin/../targets/x86_64-linux/lib"

#$ CUDAFE_FLAGS=

#$ PTXAS_FLAGS=

#$ rm tmp/a_dlink.reg.c

#$ gcc -D__CUDA_ARCH_LIST__=520 -E -x c++ -D__CUDACC__ -D__NVCC__
"-I/opt/cuda/bin/../targets/x86_64-linux/include" -D__CUDACC_VER_MAJOR__=12
-D__CUDACC_VER_MINOR__=3 -D__CUDACC_VER_BUILD__=52
-D__CUDA_API_VER_MAJOR__=12 -D__CUDA_API_VER_MINOR__=3
-D__NVCC_DIAG_PRAGMA_SUPPORT__=1 -include "cuda_runtime.h" -m64
"CMakeCUDACompilerId.cu" -o "tmp/CMakeCUDACompilerId.cpp4.ii"

#$ cudafe++ --c++17 --gnu_version=130201 --display_error_number
--orig_src_file_name "CMakeCUDACompilerId.cu" --orig_src_path_name
"/build/ollama-cuda/src/ollama/llm/llama.cpp/ggml/build/cuda/CMakeFiles/3.27.7/CompilerIdCUDA/CMakeCUDACompilerId.cu"
--allow_managed --m64 --parse_templates --gen_c_file_name
"tmp/CMakeCUDACompilerId.cudafe1.cpp" --stub_file_name
"CMakeCUDACompilerId.cudafe1.stub.c" --gen_module_id_file
--module_id_file_name "tmp/CMakeCUDACompilerId.module_id"
"tmp/CMakeCUDACompilerId.cpp4.ii"

/usr/include/bits/floatn.h(86): error: invalid combination of type
specifiers

typedef __float128 _Float128;
^

/usr/include/bits/floatn-common.h(214): error: invalid combination of type
specifiers

typedef float _Float32;
^

/usr/include/bits/floatn-common.h(251): error: invalid combination of type
specifiers

typedef double _Float64;
^

/usr/include/bits/floatn-common.h(268): error: invalid combination of type
specifiers

typedef double _Float32x;
^

/usr/include/bits/floatn-common.h(285): error: invalid combination of type
specifiers

typedef long double _Float64x;
^

5 errors detected in the compilation of "CMakeCUDACompilerId.cu".

# --error 0x2 --

Call Stack (most recent call first):
/usr/share/cmake/Modules/CMakeDetermineCompilerId.cmake:8 (CMAKE_DETERMINE_COMPILER_ID_BUILD)
/usr/share/cmake/Modules/CMakeDetermineCompilerId.cmake:53 (__determine_compiler_id_test)
/usr/share/cmake/Modules/CMakeDetermineCUDACompiler.cmake:307 (CMAKE_DETERMINE_COMPILER_ID)
CMakeLists.txt:250 (enable_language)

-- Configuring incomplete, errors occurred!
llm/llama.cpp/generate_linux.go:21: running "cmake": exit status 1

Building the regular ollama package, where cuda/nvcc are not installed before building, works fine.
Attaching logs.
ollama-cuda-0.1.8-1-x86_64-build.log
ollama-cuda-0.1.8-1-x86_64-prepare.log
Advice for how to package ollama + cuda for Arch Linux is welcome.

This error is more llama.cpp specific as far as i understand. I was trying to install the same in nixos yesterday and faced similar issues, https://github.com/NixOS/nixpkgs/pull/257760#issuecomment-1794967371

I haven't tested this yet, but there is a new llama.cpp commit from 2 days ago that might fix this issue:
https://github.com/ggerganov/llama.cpp/commit/2833a6f63c1b87c7f4ac574bcf7a15a2f3bf3ede

I have just compiled llama.cpp on my system and both the versions for CUDA and the compiler toolkit seem too new in your scripts, the CUDA default version for the project is 11.7. I compiled it with CUDA 11.8 and g++ 11.3 and it worked just fine

@xyproto thanks for maintaining this package:)

#1028 did not work out.
Could the errors be related to the cmake defines -DLLAMA_FMA=off or -DLLAMA_F16C=off somehow?

With the latest version of the Arch Linux packages + the latest version of Ollama, this now works again. :+1:

@xyproto thanks for this update. I'd like to use the latest package on my local environment. Can you also update the stable branch too?
Many thanks for Sunday contribution:)

Manjaro is a different Linux distribution, so I don't have access to those packages. They will probably update the stable version soon, though.

@xyproto thanks for the explanation:)

Hey sorry @xyproto to ping you here, but Arch registrations are down at the moment and there's no issue tracker on your fork.  It looks like when you built the ollama-cuda package, the version number was left at 0.0.0.  I'm assuming there should be something in the build process that updates that.
This causes the ollama-webui client to refuse connection, as it requires at least 1.1.16.  Running the ollama bin manually (downloaded from ollama.ai) works.

@BaconIsAVeg Ah, yes. The latest tests added to ollama specifically checked if the version number was 0.0.0 before passing. Following the Arch philosophy of patching as little as possible, I removed the line in the PKGBUILD that patched in the correct version number, while figuring out if this really is on purpose or just a fluke.

See also https://github.com/jmorganca/ollama/issues/1712


Allow a custom setState handler on the using component

Only components having a state are currently working correctly with the sortable mixing. The proposed fix is to allow custom state handling method to be passed in as config.

Ok.


Runtime of the software in question

When I used the software I set -p to 4001 in order to detect larger duplicates, but each genome was running for a long time and still not calculated, the computer has limited running memory -t set to 10, run the command as follows for i in cat list.txt;do ultra -t 10 --tsv --bed -p 4001 --win_size 100000 --overlap 10000 --pval --show_seq --mask . /${i}.mask -o . /${i}.ULTRA ... /... /${i};done, is there any way to increase the speed of the run?
Thank you.

Hello,
For my own high-period analysis I often times reduce the number of indel states to two (or even less) using -i 2 -d 2. I've also generally found that using a maximum repetitive period of 2000 works just as well as larger repetitive periods for most masking tasks in most genomes.
I hope this helps! Let me know if you have any additional questions.
Daniel

Hello，
Thanks for the answer, now that I'm running much faster and have changed the repeat period to 2000, is there any specific effect on the size of this -i -d parameter, I didn't quite understand the explanation in -h, also I didn't notice any significant difference in the results of the different settings.
Have a nice life and good luck with your research!
Chongde Tian

发件人: Daniel Olson @.>
发送时间: 2024年10月23日 0:09
收件人: TravisWheelerLab/ULTRA @.>
抄送: tcd11221 @.>; Author @.>
主题: Re: [TravisWheelerLab/ULTRA] Runtime of the software in question (Issue #69)
Closed #69https://github.com/TravisWheelerLab/ULTRA/issues/69 as completed.
―
Reply to this email directly, view it on GitHubhttps://github.com/TravisWheelerLab/ULTRA/issues/69#event-14788538480, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AX6AQZ5S7HKBAHFRM77SQ3DZ4Z2BZAVCNFSM6AAAAABQLNBC6KVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJUG44DQNJTHA2DQMA.
You are receiving this because you authored the thread.Message ID: @.***>

Glad to hear! The -i and -d options change how many insertions and deletions can occur within a single repetitive unit. If you don't notice any significant annotation changes while using a smaller -i and -d then there's no reason to increase their size.
Best wishes!
Daniel

Thank you very much! First of all, I apologize for taking so long to reply to your email, I've been busy with some other things lately and haven't opened my email.
In that case does this mean that there are very few insertions and deletions of repetitive sequences in my annotation results, and basically complete repetitive units?
Best regards！
Chongde Tian

发件人: Daniel Olson @.>
发送时间: 2024年10月25日 20:44
收件人: TravisWheelerLab/ULTRA @.>
抄送: tcd11221 @.>; Author @.>
主题: Re: [TravisWheelerLab/ULTRA] Runtime of the software in question (Issue #69)
Glad to hear! The -i and -d options change how many insertions and deletions can occur within a single repetitive unit. If you don't notice any significant annotation changes while using a smaller -i and -d then there's no reason to increase their size.
Best wishes!
Daniel
―
Reply to this email directly, view it on GitHubhttps://github.com/TravisWheelerLab/ULTRA/issues/69#issuecomment-2437681459, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AX6AQZ3CAJWOYRRO7WGEXW3Z5I4KRAVCNFSM6AAAAABQLNBC6KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZXGY4DCNBVHE.
You are receiving this because you authored the thread.Message ID: @.***>

Fantastic question!
Potentially, but not necessarily. For small period repeats a single undetected indel will have an affect on the annotation score of the repeat, but is unlikely to change the overall annotation. For large period repeats (like what's found in centromeres) the repetitive patterns are complex hierarchies of smaller tandem repeats, and as a result you can reasonably model many indels by a much smaller collection of indel states.
Here's a toy example that demonstrates what I mean. Suppose we have a tiny Higher Order Repeat (HOR) that has the following repetitive unit:
ATATATATATATATATATATATATATATATATATATATATATATATTATATATATATACTCGGCTACATGGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGGCGCGCGCG
Now lets suppose we have two of these repetitive units occuring one after the other, but one of them has 7 insertions. I'll write the repeat units on separate lines and the inserted characters in lower case:
Repeat Unit 1: ATATcccccccATATATATATATATATATATATATATATATATATATATATATATATATATATACTCGGCTACATGGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGGCGCGCGCG
Repeat Unit 2: ATATATATATATATATATATATATATATATATATATATATATATATATATATATATACTCGGCTACATGGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGGCGCGCGCG

If we were to model this sequence with no insertions then we would see 126 mismatches between the two repetitive units. But if we were to model the repeat with only a single insertion (which I will write below as '_') we can significiantly reduce the number of mismatches observed:
Repeat Unit 1: ATATcccccccATATATATATATATATATATATATATATATATATATATATATATATATATATACTCGGCTACATGGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGGCGCGCGCG
Repeat Unit 2: ATAT_ATATATATATATATATATATATATATATATATATATATATATATATATATATACTCGGCTACATGGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGGCGCGCGCG

Now there are only 23 mismatches between the two repetitive units. Those 23 mismatches will unfairly reduce the annotation score of the tandem repeat, but repeat will be still be found and annotated.
Best wishes,
Daniel

Thank you very much for your answer, it has been very helpful and has deepened my understanding of the repetition!
I wish you a happy life and success in your research!
Best regards！
Chongde Tian

发件人: Daniel Olson @.>
发送时间: 2024年10月29日 21:24
收件人: TravisWheelerLab/ULTRA @.>
抄送: tcd11221 @.>; Author @.>
主题: Re: [TravisWheelerLab/ULTRA] Runtime of the software in question (Issue #69)
Fantastic question!
Potentially, but not necessarily. For small period repeats a single undetected indel will have an affect on the annotation score of the repeat, but is unlikely to change the overall annotation. For large period repeats (like what's found in centromeres) the repetitive patterns are complex hierarchies of smaller tandem repeats, and as a result you can reasonably model many indels by a much smaller collection of indel states.
Here's a toy example that demonstrates what I mean. Suppose we have a tiny Higher Order Repeat (HOR) that has the following repetitive unit:
ATATATATATATATATATATATATATATATATATATATATATATATTATATATATATACTCGGCTACATGGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGGCGCGCGCG
Now lets suppose we have two of these repetitive units occuring one after the other, but one of them has 7 insertions. I'll write the repeat units on separate lines and the inserted characters in lower case:
Repeat Unit 1: ATATcccccccATATATATATATATATATATATATATATATATATATATATATATATATATATACTCGGCTACATGGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGGCGCGCGCG
Repeat Unit 2: ATATATATATATATATATATATATATATATATATATATATATATATATATATATATACTCGGCTACATGGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGGCGCGCGCG
If we were to model this sequence with no insertions then we would see 126 mismatches between the two repetitive units. But if we were to model the repeat with only a single insertion (which I will write below as '_') we can significiantly reduce the number of mismatches observed:
Repeat Unit 1: ATATcccccccATATATATATATATATATATATATATATATATATATATATATATATATATATACTCGGCTACATGGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGGCGCGCGCG
Repeat Unit 2: ATAT_ATATATATATATATATATATATATATATATATATATATATATATATATATATACTCGGCTACATGGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGCGGCGCGCGCG
Now there are only 23 mismatches between the two repetitive units. Those 23 mismatches will unfairly reduce the annotation score of the tandem repeat, but repeat will be still be found and annotated.
Best wishes,
Daniel
―
Reply to this email directly, view it on GitHubhttps://github.com/TravisWheelerLab/ULTRA/issues/69#issuecomment-2444222425, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AX6AQZZ7NXQHSGWCBYF6TF3Z56EAXAVCNFSM6AAAAABQLNBC6KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBUGIZDENBSGU.
You are receiving this because you authored the thread.Message ID: @.***>


issue410 on first click searchbar shows top 5 subreddits by popularity

Closes #410
Description
on first click searchbar shows top 5 subreddits by popularity
Screenshot

Verification
How will a stakeholder test this?

By clicking on the searchBar

@sfrunza13 Thank you!!!


handling code validation

On account creation the if the code is invalid should it OOG?

Looked for the EIP and couldn't find it, I'd be curious to see it.

Agreed to codify what is currently implemented: contract verification failure results in OOG. Need to document this.


EIP4844: modify MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS to 18 days

Part of #3043
As discussed during Devcon, 1.2 months is a bit long as the upper bound for storing the blobs. 2 weeks seems sufficient for any use case we are aware of, and some may argue even shorter. This reduces the storage requirement to 137GB, assuming 1mb target

I agree i'll remover one

Close


[BUG] Player Frame class color  (Classic Era)

The class color option on the Player Frame doesn't always work as intended. Usually, the health bar displays the class color, but sometimes during combat, it reverts to the default green color. I will attach a short video at the end of this report for reference. The video was recorded with only the Dragonflight UI addon active, and there are no BugSack errors.
https://github.com/user-attachments/assets/a2aa5981-ea23-44a3-9d17-6b3f6516a528

The statusbar color gets overriden quite often in the default blizzard code, and it seems like its missing a hook where that happens to override it again. Does this happen often? It seems like it happend as the mana bar gets to 100%, and maybe the playerframe does a complete update then.
I'll investigate a bit more.

I can't reproduce this, but I added some more hooks to fix the class color; it gets called a lot, but should not cause any problems as the function call is quite light: 387b6c820992c5b3a6222d181ee1aca2dbbc8bf0

v0.19.6 live on curseforge.


setup.sh and build.sh missing

instructions stated setup.sh and build.sh, which is missing on git, what happen?

Don't need it.add your repos manually in roomservice.
Its not hard :)

I found it, need to specific branch. Thanks.