text:
fix a typo

Signed-off-by: ktro2828 kotaro.uetake@tier4.jp
Motivation
Thanks for your great work! I fixed typo in README.md
Modification
add apostrophe
BC-breaking (Optional)
Use cases (Optional)
Checklist

Pre-commit or other linting tools are used to fix the potential lint issues.
The modification is covered by complete unit tests. If not, please add more unit test to ensure the correctness.
If the modification has potential influence on downstream projects, this PR should be tested with downstream projects, like MMDet or MMCls.
The documentation has been modified accordingly, like docstring or example tutorials.

Hi @ktro2828  ！First of all, we want to express our gratitude for your significant PR in the MIM . Your contribution is highly appreciated, and we are grateful for your efforts in helping improve this open-source project during your personal time. We believe that many developers will benefit from your PR.
We would also like to invite you to join our Special Interest Group (SIG) private channel on Discord, where you can share your experiences, ideas, and build connections with like-minded peers. To join the SIG channel, simply message moderator— OpenMMLab on Discord or briefly share your open-source contributions in the #introductions channel and we will assist you. Look forward to seeing you there! Join us ：https://discord.gg/UjgXkPWNqA
If you have WeChat account，welcome to join our community on WeChat. You can add our assistant ：openmmlabwx. Please add "mmsig + Github ID" as a remark when adding friends：）
Thank you again for your contribution❤

repo: open-mmlab/mim


text:
About the mean and std of I3D (inception-v1)?

At test_configs/I3D_RGB/i3d_kinetics400_3d_rgb_inception_v1_seg1_f64s1.py, I find out the mean and std is
 img_norm_cfg = dict(     mean=[123.675, 116.28, 103.53], std=[58.395, 57.12, 57.375], to_rgb=True)
But in the source repo kinetics-i3d, whose ReadMe.md tells that:

From the RGB data, we added 1 and then divided by 2 to rescale between 0 and 1.

It seems the mean and std not match.
The mean and std of inception-v1 should be [128,128,128], [128,128,128], which may be mixed with the mean and std of Resnet-50.

Thanks for pointing out the bug, I will provide a fix PR.

source: gharchive/issue

authors: fjchange kennymckormick

repo: open-mmlab/mmaction

license_type: permissive

license_source: github-api


text:
training stuck problem

When i use distributed training for semisupervised object detection, index created! Then it freezes,which can cause the computer to crash and take l long time to report an error.

It's a memory leak issue, and after the reference is established,the memory usage keeps increasing until it crashes

It's a memory leak issue, and after the reference is established,the memory usage keeps increasing until it crashes

Hi, Have you solved the problem? I encounter the same problem for several days. Could you give me your solution to solve the problem

repo: open-mmlab/mmdetection


text:
Rotate Albu Augmentation Error

Dear all,
i'm facing a strange behavior with the data augmentation type ShiftScaleRotate (Albu augmentation). I'm training VFNet. The training procedure works well in general, but when I add the ShiftScaleRotate transform my loss goes to NaN and so I receive
the ERROR-The testing results of the whole dataset is empty. This is the part of the config file regarding the transformation:
albu_train_transforms = [
    dict(
         type='ShiftScaleRotate',
         shift_limit=0.0625,
         scale_limit=0.0,
         rotate_limit=45,
         interpolation=1,
         p=0.5),
    dict(
        type='RandomBrightnessContrast',
        brightness_limit=[0.5, 0.5],
        contrast_limit=[0.1, 0.3],
        p=0.5),

    dict(type='Blur', blur_limit=3, p=0.4)
    ]

train_pipeline = [
    dict(type='LoadImageFromFile'),
    dict(type='LoadAnnotations', with_bbox=True),
    dict(type='Resize', img_scale=(1152, 1152), keep_ratio=True),
    dict(type='RandomFlip', flip_ratio=0.5),
    dict(
        type='Albu',
        transforms=albu_train_transforms,
        bbox_params=dict(
            type='BboxParams',
            format='coco',
            label_fields=['gt_labels'],
            min_visibility=0.0,
            filter_lost_elements=True),
        keymap={
            'img': 'image',
            'gt_bboxes': 'bboxes'
        },
        update_pad_shape=False,
        skip_img_without_anno=True),
    dict(type='Normalize', **img_norm_cfg),
    dict(type='Pad', size_divisor=32),
    dict(type='DefaultFormatBundle'),
    dict(type='Collect', keys=['img', 'gt_bboxes', 'gt_labels']),
]

test_pipeline = [
    dict(type='LoadImageFromFile'),
    dict(
        type='MultiScaleFlipAug',
        img_scale=(4608, 3456),
        flip=False,
        transforms=[
            dict(type='Resize', keep_ratio=True),
            dict(type='RandomFlip'),
            dict(type='Normalize', **img_norm_cfg),
            dict(type='Pad', size_divisor=32),
            dict(type='DefaultFormatBundle'),
            dict(type='Collect', keys=['img']),
        ])
]

Do you know how to fix this error? The rotation transform is important for my task.
Best regard,
mdatres

@mdatres Do you have the latest developments over there?

@mdatres Your configuration is incorrect, you should set format='pascal_voc' instead format='coco'.

authors: hhaAndroid mdatres


text:
关于“遮挡目标”的训练参数优化

mmdet 效果很好，能成功运行。但是在【多个目标之间相互遮挡】的场景下，检测效果一直不好。请问有什么参数可以调节，可以参考什么文档？？
我看有个 iscrowd 参数，但没有找到文档。

iscrowd参数表示是不是群体对象，主要是用于目标比较难以标注所设立的一个属性，可以看到下图中的原图以及它的可视化标注图片。
，

这一图片来自于COCO，COCO在标注的时候，一般对于人群这种比较多的目标是不会全部进行标注的，只是会选择一部分（10~15个）进行标注，剩余都用一个对象（iscorwd=1）进行标注，当你预测出属于iscorwd=1的对象时，是不会进行打分的，而且这个iscrowd这个对象也是不会作为GT进行训练的，因此这个参数与遮挡没有什么关系。
最后，遮挡问题是检测对象面临的一个共同问题，应该有专用的模型来解决吧，希望能帮助到你 : )

多谢解答


text:
show_score_thr not used when multi-gpu test

https://github.com/open-mmlab/mmdetection/blob/1872bc44d04601045110186ad566c7117f9a0b2a/tools/test.py#L236

I wonder how to set score threshold use multi-gpu mode, however the show_score_thr argument sames not used in multi_gpu_test function.

show_score_thr is used for visualization. But visualization is only supported during single-gpu test. If you want to filter bboxes with low scores, please set score_thr in test_cfg.

i see, thx.


text:
Any plan to add Vit and MVit

Describe the feature
Add backbones below:
1.Multiscale Vision Transformer (MViT)
2.Vision Transformer
Motivation
There is a recent paper https://arxiv.org/abs/2203.16527  which is very helpful for Object Detection
Related resources
If there is an official code release or third-party implementations, please also provide the information here, which would be very helpful.
Additional context
Add any other context or screenshots about the feature request here.
If you would like to implement the feature and create a PR, please leave a comment here and that would be much appreciated.

@wqh17101 Backbone related code will be added to mmcls.


text:
base abstract class for components

Describe the feature
Like we have abstract class for the detectors does it make sense to have similar things for individual components such as the backbone, head, etc.
Motivation
I was working on building a new detector with new backbones and new heads and everything and i had to manually figure out what is needed by the pipeline and make the corresponding functions
Related resources
N/A
Additional context
I can work on this and submit a PR

That's a good idea. Maybe you can briefly list the apis for the abstract classes here for discussion.

authors: Ridhwanluthra hellock


text:
to enable htxscreen

changes are to enable htxscreen

Avinash, please consider adding more details about htxscreen program.

source: gharchive/pull-request

authors: avinashkuttan mehuljpatel

repo: open-power/HTX

license_source: bigquery


text:
Test slot location codes

Test that PCI slots have somewhat correct looking slot names.

@stewart-ibm Can you explain a bit more here, so that we can implement it.

So my thought was we could test a few things to see if slot names were remotely correct (or present).
e.g. on Firestone we have slots with te names "Backplane USB", "Backplane SATA", "Backplane BMC". We could test that slots that have these names have the appropriate devices behind them. e.g. if "Backplane SATA" is actually a network card, we know something is wrong (for example, somebody is claiming their machine is a firestone when it obviously isn't). The same with slots named "GPU1"

Thanks! Now we just have to solve the fact that the tests are failing for some systems/slots.

authors: narasimhan-v stewart-ibm

repo: open-power/op-test-framework


text:
エクストルーダーの改造を検討する

細かい丸などリトラクションを短時間に何回も要求するモデルを印刷する際に、失敗することがかなりある。また印刷中には常にエクストルーダー付近から異音がする。K1 Maxのエクストルーダーはフィラメントを入れやすい一方でフィラメントに接触するホブが片持ちで固定されている問題がユーザから挙げられている。上記の問題はおそらくこの設計が原因の一つと考えられるため、エクストルーダーの改造を検討する。

https://github.com/D3vil-Design/Cyclops-Extruder

写真を撮れませんでしたが、細かい造形物を印刷する際にファーストレイヤーにしっかりとフィラメントが押し出されていませんでした。
リトラクションの問題という可能性もありますが、エクストルーダーの性能が理由かもしれません。

Voronなどで使われるエクストルーダー https://github.com/jrlomas/Sherpa-Crew-Mini

こちらはパーツ入手もしやすそうですが、k1に適合したものではないので無理やり装着することになります。その結果エクストルーダーとテフロンチューブが上部の蓋に接触するのを防ぐために蓋の高さをかなりあげる必要がありそうです。 #4 ですでに挙げてありますがさらにあげる必要があり、コストの高い改造になりそうです。

Orbiter ExtruderのパーツをベースにK1機種に対応するよう設計されたエクストルーダー https://github.com/D3vil-Design/Cyclops-Extruder

YouTubeを見た感じOrbiter Extruderのパーツを扱っていそうです。Cyclops-Extruderのキットもありますが入手はかなり困難のようですので、Orbiter ExtruderをAmazon経由で購入し分解、Cyclops-ExtruderのABSパーツは自分たちで印刷し組み立てるのが良さそうです。

Orbiter ExtruderはV1,V1.5,V2.0があるようです。どのバージョンのエクストルーダーがCyclops-Extruderのマニュアルにあるパーツリストをもとに検討します。

Cyclops-Extruder manual
The Orbiter v1.5 140g Dual Drive Direct Extruder
Orbiter v2.0 Direct Drive Extruder
Amazon V2.0 LDO Orbiter Extruder
Amazon Orbiter 1.5 Extruder KIT

Cyclops-ExtruderやOrbiter Extruderは遊星ギアを使用することでエクストルーダーの性能向上を図っているようです。また、軽量化も見込めるとのことでヘッドの軽量化によるCoreXY機構の振動などによる問題にも影響しそうです。

Cyclops-Extruderの部品表や組み立て動画などを確認したところ主要な部品はOrbiter Extruder V2.0からの流用のようです。インサートナットやネジなどは別途用意が必要そうですがそれ以外はOrbiter Extruder V2.0から部品採りをしようと思います。

Orbiter Extruder V2.0からパーツを流用しCyclops-Extruderを途中まで組み立てました。庫内で使用するためABSでボディを印刷しました。

MR128ベアリングはOrbiter Extruder V2.0に使われていなかったため別で用意しました。　また、ロゴマークがベッド側(下向き)になるようにモデルを配置して再印刷しました。これにより遊星ギア周辺に引っ掛かりがある問題が解決しました。

モータ付属のコネクタの違い
K1 Maxの純正エクストルーダのモータは以下のコネクタを採用している。

しかし、Orbiter Extruder V2.0に採用されていいるモータはXHコネクタであったためコネクタを変更する必要がある。

調査したところ MolexのPicoBladeという規格でした

https://www.reddit.com/r/crealityk1/comments/1dnxvkd/question_with_ldo_orbiter_v2_wiring/?rdt=44014

Cycrops Extruderのマニュアルを参考に、printer.cfgを書き換えました。

エクストルーダーを交換し異音やリトラクションの問題が解決したので閉じます。

license: MIT


text:
アームの関節角度の制限とトルクの制限の入力

以下のようにURDFファイルにアームの関節角度とトルクの制限を入力するようになっているので，実ロボットにあわせてパラメータを変更する．
https://github.com/open-rdc/office_robot/blob/0de5121ec7b2284bf2f6032c203eaa540337b438/rdc_manipulation/cit_description/urdf/manipulator.urdf#L114

実ロボットのB3Mのパラメータをwikiにまとめました

サーボゲインもまとめる必要がある

角度制限に関しては、B3M側の設定でセンターポジションを0にし、出力ホーンの固定位置を変えることで対応させる

発熱を抑えるため、Kiゲインを後日0に変更する

アームに使用しているすべてのサーボモータのCentor Pointを0にして初期位置を調整した。
以下にサーボそれぞれのゲインと角度Max,Minを示す。

ID
Kp
Kd
Ki
StaticFriction
DynamicFriction
Min
Max

11
42000
400
1000
0
0
-32000
32000

12
42000
400
1000
0
0
-9000
9000

13
35000
500
1800
0
0
-4000
17000

14
35000
500
1800
0
0
-11000
11000

15
35000
500
1800
0
0
-11000
11000

16
35000
500
1800
0
0
-32000
32000

17
35000
500
1800
0
0
-17000
1990

21
42000
400
1000
0
0
-32000
32000

22
42000
400
1000
0
0
-9000
9000

23
35000
500
1800
0
0
-4000
17000

24
35000
500
1800
0
0
-11000
11000

25
35000
500
1800
0
0
-11000
11000

26
35000
500
1800
0
0
-32000
32000

27
35000
500
1800
0
0
0
10000

@MibuchiYuta 出力トルクはどうする？B3Mの最大トルク？

URDFに、可動域の入力をしました。https://github.com/open-rdc/orne_or/commit/d1fd87f6bc5464e6bd3887ad21d424288fd153d9

本日実ロボットで動作させたところ、r_elbow_roll_link(id:23)が+170まで移動しませんでした。サーボ側の角度制限が間違っている可能性があるため確認します。

@MibuchiYuta 出力トルクはどうする？B3Mの最大トルク？

B3M software manualのp7にスペック表がありますが最大トルクではなく最大連続トルクを参照するのがよさそうです。

最大連続トルクの方が良いと思います．

本日実ロボットで動作させたところ、r_elbow_roll_link(id:23)が+170°まで移動しませんでした。サーボ側の角度制限が間違っている可能性があるため確認します。

確認しましたが、B3M側の制限は問題無さそうです。

アームの全てのサーボモータのKiゲインを0に変更しました。

本日実ロボットで動作させたところ、r_elbow_roll_link(id:23)が+170°まで移動しませんでした。サーボ側の角度制限が間違っている可能性があるため確認します。

B3Mマネージャーから直接角度を指定して動かしたところ170°までしっかり動作したため、モータに問題はなさそうです。

関節角度の制限ですが、driverのconfig側でも記述されていました。どうやらそれが影響していたようです。
https://github.com/open-rdc/orne_or/blob/5f0fd952b46418eb3f8d88e94408ad97bb72babd/orne_or_manipulation/orne_or_manipulator_driver/config/cit_driver.yaml#L23-L31
修正したところ、シミュレータと同じ角度まで動作しました。

URDFのeffortに最大連続トルクを記入しました。https://github.com/open-rdc/orne_or/commit/2ca176ffed8316d8e3633d20789e49a1ede2cb9c
URDF上でのアームの関節角度とトルクの制限は入力し終えたのでissueを閉じます。


text:
Add support for gz harmonic.

Opening for visibility. This branch adds support for gz harmonic.

Any downside to merging this into main since harmonic is LTS? We won't backport to older distros.

I don't think gazebo harmonic can live next to gazebo classic so it has big implications.

But I don't think gazebo classic will be supported on 24.04/Jazzy so we have to get rid of it from main before Rolling switches to 24.04  (around April 2024). Maybe we can combine the removal into this PR but save it for merge until Rolling migrates to the new OS on the buildfarm.

But I don't think gazebo classic will be supported on 24.04/Jazzy so we have to get rid of it from main before Rolling switches to 24.04 (around April 2024). Maybe we can combine the removal into this PR but save it for merge until Rolling migrates to the new OS on the buildfarm.

Sounds good, I would also suggest removing the split into gz and common since the common package was only meant to allow shared logic between classic and gz, which won't really be necessary anymore.
I'll work on the refactor and push it here. I believe that by moving away from the common approach we could do a more ECS based simulation where there is (for example) only one ROS 2 node for all the doors, rather than one per door. I started some work on this here but will resurrect it

Merged into #114

authors: Yadunund arjo129 luca-della-vedova


text:
Bug: missing counts of merged PRs

Describe the bug
In the dashboard when you hover on a user the counts of a merged PRs is shown as zero.

Steps to reproduce

go to the dashboard https://insights.opensauced.pizza/pages/YOURUSERNAME/NUMBER/dashboard
I tried with one repo - related to open sauced insights.
hover on a user

Affected services
insights.opensauced.pizza
Platforms
No response
Browsers
No response
Environment
No response
Additional context
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Contributing Docs

[ ] I agree to follow this project's Contribution Docs

@a0m0rajab I tried to reproduce this on my public OSS page
https://insights.opensauced.pizza/pages/brandonroberts/1/dashboard
I hovered over my avatar

I could not reproduce this again, it might have been resolved.
One minor thing: @takanome-dev has changed his profile picture but it seems not to be changed in the website.

https://insights.opensauced.pizza/pages/a0m0rajab/279/dashboard

One minor thing: @takanome-dev has changed his profile picture but it seems not to be changed in the website.

That was a caching issue, seems to be updated now

authors: a0m0rajab brandonroberts takanome-dev

repo: open-sauced/insights


text:
SeeQR: Version 2

Core Contributors
@caseyescovedo
@JustinD-A
@frakes413
@cwalker3011
Types of changes

[x] Bugfix
[x] New feature
[x] Refactor
[x] Non-breaking change
[ ] Breaking change

Purpose
SeeQR version 2 streamlines application UI, offers enhanced data visualization, and introduces foreign-key compliant dummy-data generation.
Approach
Most components have been refactored, a new backend module was introduced for dummy data generation, and a new component for dummy data generation was added to the frontend.
Learning
Refer to README for updated functionality, resource links, and a look at the new interface.
theseeqr.io

hell yeah

repo: open-source-labs/SeeQR


text:
[Logs SDK] Log Appender for Boost.Log

Implemented as described in https://github.com/open-telemetry/opentelemetry-cpp/issues/2048:

Sink backend allows for mapping customizations to account for the extensive flexibility that boost sinks already provide.
Minimal examples provided to demonstrate the setup required.
Basic unit testing.
Tried using the same flags as those used in otel-cpp for configuring cmake project.
Add clang format file to help keep the style in line with otel-cpp repo.

@chusitoo thank you for your contributions. Would it be fine to add you as the owner of these appender components? This would entail overseeing any pull requests, approvals, and merges for these components.
https://github.com/open-telemetry/opentelemetry-cpp-contrib/blob/main/.github/CODEOWNERS

LGTM in general. Good to add CI for these appenders as separate PR to ensure everything builds and runs fine.

@chusitoo thank you for your contributions. Would it be fine to add you as the owner of these appender components? This would entail overseeing any pull requests, approvals, and merges for these components.
https://github.com/open-telemetry/opentelemetry-cpp-contrib/blob/main/.github/CODEOWNERS

Thanks for the review @lalitb. Sure, I can take care of overseeing request, changes and/or additions to log appenders. Appreciate the offering.

authors: chusitoo lalitb


text:
feat(instrumentation-redis): add support for redis@^4.0.0

Which problem is this PR solving?

fixes #834

Short description of the changes
The new version splits the functionality into sub-packages.
I added patches for the relevant function in the subpackage: @node-redis/client:

patch function extendWithCommands, to allow access to executor which is the function that records spans upon command execution
patch RedisClientMultiCommand.exec function to correctly handle transactions and MULTI commands.
patch RedisClient.multi function to allow setting the client options on the multi command object to allow recording network attributes for transactions.

I added support for all existing config options.
Added tests for v4 + added it to test all versions and made sure it's green
Since v4 supports node >= 12, the package.json and CI actions were updated accordingly. This might be breaking for users of redis 2-3 with node < 12.
Checklist

[x] Ran npm run test-all-versions for the edited package(s) on the latest commit if applicable.

If the implementation doesn't share a lot of code I'd split it into a totally separate package. Do you know of any drawbacks that approach might have?

If the implementation doesn't share a lot of code I'd split it into a totally separate package. Do you know of any drawbacks that approach might have?

I support this too.
The drawbacks I can spot:

Does not enforce consistent types - e.g. the instrumentation config is declared in two different packages. Future fixes and features could be easily added to just one and make them diverge. Not sure how much that actually matters though.
Might be slightly more complicated for consumers - they will have to check versions in the app and choose the right package to use. I guess it shouldn't be a big deal to wrap them both into a single package that installs both and expose them as a single package that covers all versions.
Extra mental step in maintaining these packages - need to support two packages instead of one.

Benefits:

Both variants will have tests in CI
We can state different node version support for each package (redis 3 supports node >=8 but v4 supports node >= 12)
Smoother development - correct version is found in devDependencies
Each instrumentation can depend on the right types for the versions it instruments
Less confusion for the codecov tool - will see tests that cover both patches for old and new versions, as opposed to just running it on a single set.

What do you think a name for a package such as this should be? @opentelemetry/instrumentation-redis-2(covers both 2 and 3), @opentelemetry/instrumentation-redis-4 (covers current 4 and maybe future 5,6,...)?

Naming things - the hardest part.
I don't have a strong preference. If I can come with good heuristics on this those would be:

Don't change the one that's there if possible;
Make what's included as clear as possible;
Make the default clear.

Based on that, I'd leave @opentelemetry/instrumentation-redis to include instrumentation for versions 2 and 3(violates my point nr 3, but anything else would violate nr 1) and @opentelemetry/instrumentation-redis-4 to include one for versions 4 and up until they make another very significant API change.

Naming things - the hardest part.
I don't have a strong preference. If had to come up with good heuristics on this, those would be:

Don't change the one that's there if possible;
Make what's included as clear as possible;
Make the default clear.

Based on that, I'd leave @opentelemetry/instrumentation-redis to include instrumentation for versions 2 and 3(violates my point nr 3, but anything else would violate nr 1) and @opentelemetry/instrumentation-redis-4 to include one for versions 4 and up until they make another very significant API change.

Like, I'll update the PR to express that.
Thanks

If the implementation doesn't share a lot of code I'd split it into a totally separate package. Do you know of any drawbacks that approach might have?

Done. There are now 2 packages: @opentelemetry/instrumentation-redis, @opentelemetry/instrumentation-redis-4

redis package released version 4.1.0 10 days ago (on 02 May 2022) which changed the internal function names and the internal package names.
This currently breaks the tests (and support) for this new version.
I haven't yet checked what should be fixed in the instrumentation for this.
In the meantime, updating here about the status. Hope I can submit a fix soon.

@habmic @Rauno56 @dyladan
After investigating the change, I found out that in version 4.1.0 the internal package namespace in npm changed from @node-redis/client to @redis/client, and the a patched function changed it's name from extendWithCommands to attachCommands.
I udpate the PR accordingly and now test-all-versions is green again for all versions on my local setup (node 16) and CI is green for the latests version (4.1.0) except for node 12.
For node 12 it seems to fail because of an issue with redis package itself, documented here, here and here. The package itself does not publish the supported node version anywhere in a clear way, but I found this text in the changelog of the relevant subpackage of the latest version:

Drop support for node 12

I am going to remove the tests for redis 4 for node 12

CI is now green.
Feel free to review again after the latest changes. This PR is ready to merge as far as I am concerned.

@blumamir, feel free to resolve the conflicts and merge right away.

repo: open-telemetry/opentelemetry-js-contrib


text:
exporter-jaeger not exporting traces to Jaeger when used with sdk-node

Please answer these questions before submitting a bug report.
What version of OpenTelemetry are you using?
"@opentelemetry/api": "^1.0.3",
"@opentelemetry/exporter-jaeger": "^1.0.0",
"@opentelemetry/instrumentation-express": "^0.26.0",
"@opentelemetry/instrumentation-http": "^0.26.0",
"@opentelemetry/instrumentation-pino": "^0.26.0",
"@opentelemetry/resources": "^1.0.0",
"@opentelemetry/sdk-node": "^0.26.0",
"@opentelemetry/sdk-trace-base": "^1.0.0",

What version of Node are you using?
v16.13.0
Please provide the code you used to setup the OpenTelemetry SDK
const opentelemetry = require("@opentelemetry/sdk-node");
const { Resource } = require("@opentelemetry/resources");
const { SemanticResourceAttributes } = require("@opentelemetry/semantic-conventions");
const { HttpInstrumentation } = require("@opentelemetry/instrumentation-http");
const { ExpressInstrumentation } = require("@opentelemetry/instrumentation-express");
const { PinoInstrumentation } = require("@opentelemetry/instrumentation-pino");
const { JaegerExporter } = require("@opentelemetry/exporter-jaeger");
const { SimpleSpanProcessor, BatchSpanProcessor } = require("@opentelemetry/sdk-trace-base");

const sdk = new opentelemetry.NodeSDK({
  resource: new Resource({
    [SemanticResourceAttributes.SERVICE_NAME]:
      process.env.SERVICE_NAME || "my-app",
  }),
  instrumentations: [
    new HttpInstrumentation(),
    new ExpressInstrumentation(),
    new PinoInstrumentation(),
  ],
  traceExporter: new JaegerExporter(),
  // spanProcessor: new BatchSpanProcessor(new JaegerExporter(), { scheduledDelayMillis: 100 }),
  // spanProcessor: new SimpleSpanProcessor(new JaegerExporter()),
});

sdk.start();

I tried with the commented lines also but same result

What did you do?

Clone https://github.com/Olivr/app-node-js
yarn install
yarn dev
open http://localhost:3000

✅ It works when src/index.js is importing src/observability/tracer.js
❌ It doesn't work when src/index.js is importing src/observability/tracer.sdk.js
What did you expect to see?
Traces in Jaeger
What did you see instead?
Nothing

Hi
I follow your step and I worked for me

I set require("./observability/tracer.sdk"); in index.js

It does work for me as well now. Not sure what happened!

authors: OlivierAlbertini politician

repo: open-telemetry/opentelemetry-js


text:
Set the exactOptionalPropertyTypes tsconfig option

Since typescript 4.4 this new tsconfig option has been available, to clarify the difference between { foo: string | undefined } and { foo?: string }. This would be a beneficial option for me to enable in my project, but I cannot as the opentelemetry typings don't typecheck correctly with option.
Affected files that I'm seeing:
Errors  Files
     1  node_modules/@azure/opentelemetry-instrumentation-azure-sdk/node_modules/@opentelemetry/instrumentation/build/src/platform/node/instrumentationNodeModuleDefinition.d.ts:2
     1  node_modules/@opentelemetry/instrumentation-dns/build/src/instrumentation.d.ts:10
     1  node_modules/@opentelemetry/instrumentation-express/build/src/instrumentation.d.ts:9
     1  node_modules/@opentelemetry/instrumentation-http/build/src/http.d.ts:22
     1  node_modules/@opentelemetry/instrumentation-net/build/src/instrumentation.d.ts:5
     1  node_modules/@opentelemetry/instrumentation-pg/build/src/instrumentation.d.ts:9
     1  node_modules/@opentelemetry/instrumentation-winston/build/src/instrumentation.d.ts:5
     1  node_modules/@opentelemetry/instrumentation/build/src/platform/node/instrumentationNodeModuleDefinition.d.ts:2

Link to documentation: https://www.typescriptlang.org/tsconfig#exactOptionalPropertyTypes

[x] This only affects the JavaScript OpenTelemetry library
[ ] This may affect other libraries, but I would like to get opinions here first

please consider this change

Seeing this same issue in my projects

Bumping to keep this alive. This is still desired

We talked about this in the SIG meeting and we are generally in favor of this, assuming it doesn't cause issues. I'm going to mark this as up for grabs and PRs will be welcome.

authors: dyladan googol voxpelli


text:
Unable to send trace data to collector using 'examples/opentelemetry-web'

What happened?
Steps to Reproduce

Set up the collector as follows:

receivers:
  otlp:
    protocols:
      http:
        endpoint: "0.0.0.0:4318"
        cors:
          allowed_origins:
            - http://localhost:8080
            - http://localhost:8090

exporters:
  debug:
    verbosity: normal
    sampling_initial: 1
    sampling_thereafter: 1

service:
  # extensions: [health_check, pprof, zpages]
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [debug]
  telemetry:
    logs:
      level: "debug"

Run the collector:

docker run -v $(pwd)/otel_config.yml:/etc/otelcol-contrib/config.yaml -p 4318:4318 otel/opentelemetry-collector-contrib:0.87.0-armv7

Clone this repo and go into examples/opentelemetry-web.

Run npm install and npm run.

Visit http://localhost:8090/fetch/ and click on 'Test'.

Open up the developer console and under the Network tab, you will see /traces responding with 400s.

Expected Result
The POST /traces requests should succeed.
Actual Result
The POST /traces requests receives a 400 Bad Request. The response is:
{
    "code": 3,
    "message": "ReadUint64: unsupported value type, error found in #10 byte of ...|UnixNano\":{\"low\":102|..., bigger context ...|1\",\"name\":\"HTTP GET\",\"kind\":3,\"startTimeUnixNano\":{\"low\":1029784000,\"high\":395146000},\"endTimeUnixNa|..."
}

The request looks smth as follows:
{
  "resourceSpans": [
    {
      "resource": {
        "attributes": [
          {
            "key": "service.name",
            "value": {
              "stringValue": "unknown_service"
            }
          },
          {
            "key": "telemetry.sdk.language",
            "value": {
              "stringValue": "webjs"
            }
          },
          {
            "key": "telemetry.sdk.name",
            "value": {
              "stringValue": "opentelemetry"
            }
          },
          {
            "key": "telemetry.sdk.version",
            "value": {
              "stringValue": "1.17.1"
            }
          }
        ],
        "droppedAttributesCount": 0
      },
      "scopeSpans": [
        {
          "scope": {
            "name": "@opentelemetry/instrumentation-fetch",
            "version": "0.44.0"
          },
          "spans": [
            {
              "traceId": "b6d98f8d3db156c41479a10dcec7acad",
              "spanId": "d56edc49226cec35",
              "parentSpanId": "dfad940e2086e9c1",
              "name": "HTTP GET",
              "kind": 3,
              "startTimeUnixNano": {
                "low": 1029784000,
                "high": 395146000
              },
              "endTimeUnixNano": {
                "low": 1098784000,
                "high": 395146000
              },
              "attributes": [
                {
                  "key": "component",
                  "value": {
                    "stringValue": "fetch"
                  }
                },
                {
                  "key": "http.method",
                  "value": {
                    "stringValue": "GET"
                  }
                },
                {
                  "key": "http.url",
                  "value": {
                    "stringValue": "https://httpbin.org/get"
                  }
                },
                {
                  "key": "http.status_code",
                  "value": {
                    "intValue": 200
                  }
                },
                {
                  "key": "http.status_text",
                  "value": {
                    "stringValue": ""
                  }
                },
                {
                  "key": "http.host",
                  "value": {
                    "stringValue": "httpbin.org"
                  }
                },
                {
                  "key": "http.scheme",
                  "value": {
                    "stringValue": "https"
                  }
                },
                {
                  "key": "http.user_agent",
                  "value": {
                    "stringValue": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36"
                  }
                },
                {
                  "key": "http.response_content_length",
                  "value": {
                    "intValue": 0
                  }
                }
              ],
              "droppedAttributesCount": 0,
              "events": [
                {
                  "attributes": [],
                  "name": "fetchStart",
                  "timeUnixNano": {
                    "low": 1029984001,
                    "high": 395146000
                  },
                  "droppedAttributesCount": 0
                },
                {
                  "attributes": [],
                  "name": "domainLookupStart",
                  "timeUnixNano": {
                    "low": -956532928,
                    "high": 395145867
                  },
                  "droppedAttributesCount": 0
                },
                {
                  "attributes": [],
                  "name": "domainLookupEnd",
                  "timeUnixNano": {
                    "low": -956532928,
                    "high": 395145867
                  },
                  "droppedAttributesCount": 0
                },
                {
                  "attributes": [],
                  "name": "connectStart",
                  "timeUnixNano": {
                    "low": -956532928,
                    "high": 395145867
                  },
                  "droppedAttributesCount": 0
                },
                {
                  "attributes": [],
                  "name": "secureConnectionStart",
                  "timeUnixNano": {
                    "low": -956532928,
                    "high": 395145867
                  },
                  "droppedAttributesCount": 0
                },
                {
                  "attributes": [],
                  "name": "connectEnd",
                  "timeUnixNano": {
                    "low": -956532928,
                    "high": 395145867
                  },
                  "droppedAttributesCount": 0
                },
                {
                  "attributes": [],
                  "name": "requestStart",
                  "timeUnixNano": {
                    "low": -956532928,
                    "high": 395145867
                  },
                  "droppedAttributesCount": 0
                },
                {
                  "attributes": [],
                  "name": "responseStart",
                  "timeUnixNano": {
                    "low": -956532928,
                    "high": 395145867
                  },
                  "droppedAttributesCount": 0
                },
                {
                  "attributes": [],
                  "name": "responseEnd",
                  "timeUnixNano": {
                    "low": 1094484001,
                    "high": 395146000
                  },
                  "droppedAttributesCount": 0
                }
              ],
              "droppedEventsCount": 0,
              "status": {
                "code": 0
              },
              "links": [],
              "droppedLinksCount": 0
            }
          ]
        }
      ]
    }
  ]
}

Additional Details
I suspect this error has something to do with the negative numbers. But, I don't understand enough about the proper behavior of unsigned_long.js.
I am on an ARM Mac and I am not sure if this could be the cause of this issue? I know that my colleague is able to use opentelemetry-js without much problem.
OpenTelemetry Setup Code
// Directly from the example fetch/index.js

const { context, trace } = require( '@opentelemetry/api');
const { ConsoleSpanExporter, SimpleSpanProcessor } = require( '@opentelemetry/sdk-trace-base');
const { OTLPTraceExporter } = require( '@opentelemetry/exporter-trace-otlp-http');
const { WebTracerProvider } = require( '@opentelemetry/sdk-trace-web');
const { FetchInstrumentation } = require( '@opentelemetry/instrumentation-fetch');
const { ZoneContextManager } = require( '@opentelemetry/context-zone');
const { B3Propagator } = require( '@opentelemetry/propagator-b3');
const { registerInstrumentations } = require( '@opentelemetry/instrumentation');

const provider = new WebTracerProvider();

// Note: For production consider using the "BatchSpanProcessor" to reduce the number of requests
// to your exporter. Using the SimpleSpanProcessor here as it sends the spans immediately to the
// exporter without delay
provider.addSpanProcessor(new SimpleSpanProcessor(new ConsoleSpanExporter()));
provider.addSpanProcessor(new SimpleSpanProcessor(new OTLPTraceExporter()));
provider.register({
  contextManager: new ZoneContextManager(),
  propagator: new B3Propagator(),
});

registerInstrumentations({
  instrumentations: [
    new FetchInstrumentation({
      ignoreUrls: [/localhost:8090\/sockjs-node/],
      propagateTraceHeaderCorsUrls: [
        'https://cors-test.appspot.com/test',
        'https://httpbin.org/get',
      ],
      clearTimingResources: true,
    }),
  ],
});

const webTracerWithZone = provider.getTracer('example-tracer-web');

const getData = (url) => fetch(url, {
  method: 'GET',
  headers: {
    Accept: 'application/json',
    'Content-Type': 'application/json',
  },
});

// example of keeping track of context between async operations
const prepareClickEvent = () => {
  const url = 'https://httpbin.org/get';

  const element = document.getElementById('button1');

  const onClick = () => {
    const singleSpan = webTracerWithZone.startSpan('files-series-info');
    context.with(trace.setSpan(context.active(), singleSpan), () => {
      getData(url).then((_data) => {
        trace.getSpan(context.active()).addEvent('fetching-single-span-completed');
        singleSpan.end();
      });
    });
    for (let i = 0, j = 5; i < j; i += 1) {
      const span = webTracerWithZone.startSpan(`files-series-info-${i}`);
      context.with(trace.setSpan(context.active(), span), () => {
        getData(url).then((_data) => {
          trace.getSpan(context.active()).addEvent(`fetching-span-${i}-completed`);
          span.end();
        });
      });
    }
  };
  element.addEventListener('click', onClick);
};

window.addEventListener('load', prepareClickEvent);

package.json
{
  "name": "web-opentelemetry-example",
  "private": true,
  "version": "0.44.0",
  "description": "Example of using @opentelemetry/sdk-trace-web and @opentelemetry/sdk-metrics in browser",
  "main": "index.js",
  "scripts": {
    "start": "webpack serve --progress --color --port 8090 --config webpack.dev.config.js --hot --host 0.0.0.0 --compress",
    "start-nc": "webpack serve --progress --color --port 8090 --config webpack.dev.config.js --hot --host 0.0.0.0 --no-compress",
    "start-prod": "webpack serve --progress --color --port 8090 --config webpack.prod.config.js --hot --host 0.0.0.0 --compress",
    "start-prodnc": "webpack serve --progress --color --port 8090 --config webpack.prod.config.js --hot --host 0.0.0.0 --no-compress",
    "docker:start": "cd ./docker && docker-compose down && docker-compose up",
    "docker:startd": "cd ./docker && docker-compose down && docker-compose up -d",
    "docker:stop": "cd ./docker && docker-compose down"
  },
  "repository": {
    "type": "git",
    "url": "git+ssh://git@github.com/open-telemetry/opentelemetry-js.git"
  },
  "keywords": [
    "opentelemetry",
    "tracing",
    "metrics",
    "web"
  ],
  "engines": {
    "node": ">=14"
  },
  "author": "OpenTelemetry Authors",
  "license": "Apache-2.0",
  "bugs": {
    "url": "https://github.com/open-telemetry/opentelemetry-js/issues"
  },
  "devDependencies": {
    "@babel/core": "^7.6.0",
    "babel-loader": "^8.0.6",
    "ts-loader": "^9.2.6",
    "typescript": "^4.5.2",
    "webpack": "^5.65.0",
    "webpack-cli": "^4.10.0",
    "webpack-dev-server": "^4.5.0",
    "webpack-merge": "^5.8.0"
  },
  "dependencies": {
    "@opentelemetry/api": "^1.3.0",
    "@opentelemetry/context-zone": "1.17.1",
    "@opentelemetry/core": "1.17.1",
    "@opentelemetry/exporter-metrics-otlp-http": "0.44.0",
    "@opentelemetry/exporter-trace-otlp-http": "0.44.0",
    "@opentelemetry/exporter-trace-otlp-proto": "0.44.0",
    "@opentelemetry/exporter-zipkin": "1.17.1",
    "@opentelemetry/instrumentation": "0.44.0",
    "@opentelemetry/instrumentation-fetch": "0.44.0",
    "@opentelemetry/instrumentation-xml-http-request": "0.44.0",
    "@opentelemetry/propagator-b3": "1.17.1",
    "@opentelemetry/sdk-metrics": "1.17.1",
    "@opentelemetry/sdk-trace-base": "1.17.1",
    "@opentelemetry/sdk-trace-web": "1.17.1",
    "@opentelemetry/semantic-conventions": "1.17.1"
  },
  "homepage": "https://github.com/open-telemetry/opentelemetry-js/tree/main/examples/tracer-web"
}

Relevant log output
On the collector side, these are the output:
WARNING: The requested image's platform (linux/arm/v7) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
2023-10-12T19:32:20.321Z	info	service@v0.87.0/telemetry.go:84	Setting up own telemetry...
2023-10-12T19:32:20.328Z	info	service@v0.87.0/telemetry.go:201	Serving Prometheus metrics	{"address": ":8888", "level": "Basic"}
2023-10-12T19:32:20.335Z	info	exporter@v0.87.0/exporter.go:275	Development component. May change in the future.	{"kind": "exporter", "data_type": "traces", "name": "debug"}
2023-10-12T19:32:20.340Z	debug	receiver@v0.87.0/receiver.go:294	Stable component.{"kind": "receiver", "name": "otlp", "data_type": "traces"}
2023-10-12T19:32:20.343Z	info	service@v0.87.0/service.go:143	Starting otelcol-contrib...	{"Version": "0.87.0", "NumCPU": 5}
2023-10-12T19:32:20.343Z	info	extensions/extensions.go:33	Starting extensions...
2023-10-12T19:32:20.344Z	warn	internal@v0.87.0/warning.go:40	Using the 0.0.0.0 address exposes this server to every network interface, which may facilitate Denial of Service attacks	{"kind": "receiver", "name": "otlp", "data_type": "traces", "documentation": "https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/security-best-practices.md#safeguards-against-denial-of-service-attacks"}
2023-10-12T19:32:20.345Z	info	otlpreceiver@v0.87.0/otlp.go:101	Starting HTTP server	{"kind": "receiver", "name": "otlp", "data_type": "traces", "endpoint": "0.0.0.0:4318"}
2023-10-12T19:32:20.346Z	info	service@v0.87.0/service.go:169	Everything is ready. Begin running and processing data.

On the client side:
[webpack-dev-server] Server started: Hot Module Replacement enabled, Live Reloading enabled, Progress disabled, Overlay enabled.
log.js:39 [HMR] Waiting for update signal from WDS...
ConsoleSpanExporter.js:88 Object
ConsoleSpanExporter.js:88 Object
ConsoleSpanExporter.js:88 Object
ConsoleSpanExporter.js:88 Object
ConsoleSpanExporter.js:88 Object
ConsoleSpanExporter.js:88 Object
ConsoleSpanExporter.js:88 Object
util.js:55     POST http://localhost:4318/v1/traces 400 (Bad Request)
sendWithBeacon @ util.js:55
eval @ OTLPExporterBrowserBase.js:77
ZoneAwarePromise @ zone.js:1429
OTLPExporterBrowserBase.send @ OTLPExporterBrowserBase.js:72
eval @ OTLPExporterBase.js:76
ZoneAwarePromise @ zone.js:1429
OTLPExporterBase._export @ OTLPExporterBase.js:73
OTLPExporterBase.export @ OTLPExporterBase.js:63
eval @ exporter.js:26
invoke @ zone.js:372
run @ zone.js:134
ZoneContextManager.with @ ZoneContextManager.js:219
ContextAPI.with @ context.js:88
eval @ exporter.js:25
ZoneAwarePromise @ zone.js:1429
_export @ exporter.js:23
doExport @ SimpleSpanProcessor.js:98
SimpleSpanProcessor.onEnd @ SimpleSpanProcessor.js:123
MultiSpanProcessor.onEnd @ MultiSpanProcessor.js:84
Span.end @ Span.js:190
eval @ index.js:64
invoke @ zone.js:372
run @ zone.js:134
eval @ zone.js:1275
invokeTask @ zone.js:406
runTask @ zone.js:178
drainMicroTaskQueue @ zone.js:585
Promise.then (async)
nativeScheduleMicroTask @ zone.js:561
scheduleMicroTask @ zone.js:572
scheduleTask @ zone.js:396
scheduleTask @ zone.js:221
scheduleMicroTask @ zone.js:241
scheduleResolveOrReject @ zone.js:1265
resolvePromise @ zone.js:1202
eval @ zone.js:1118
eval @ zone.js:1134
Promise.then (async)
eval @ zone.js:1509
ZoneAwarePromise @ zone.js:1429
Ctor.then @ zone.js:1508
eval @ fetch.js:304
invoke @ zone.js:372
run @ zone.js:134
ZoneContextManager.with @ ZoneContextManager.js:219
ContextAPI.with @ context.js:88
eval @ fetch.js:297
ZoneAwarePromise @ zone.js:1429
patchConstructor @ fetch.js:296
getData @ index.js:37
eval @ index.js:62
invoke @ zone.js:372
run @ zone.js:134
ZoneContextManager.with @ ZoneContextManager.js:219
ContextAPI.with @ context.js:88
onClick @ index.js:61
invokeTask @ zone.js:406
runTask @ zone.js:178
invokeTask @ zone.js:487
invokeTask @ zone.js:1661
globalCallback @ zone.js:1692
globalZoneAwareCallback @ zone.js:1725
util.js:55     POST http://localhost:4318/v1/traces 400 (Bad Request)
sendWithBeacon @ util.js:55
eval @ OTLPExporterBrowserBase.js:77
ZoneAwarePromise @ zone.js:1429
OTLPExporterBrowserBase.send @ OTLPExporterBrowserBase.js:72
eval @ OTLPExporterBase.js:76
ZoneAwarePromise @ zone.js:1429
OTLPExporterBase._export @ OTLPExporterBase.js:73
OTLPExporterBase.export @ OTLPExporterBase.js:63
eval @ exporter.js:26
invoke @ zone.js:372
run @ zone.js:134
ZoneContextManager.with @ ZoneContextManager.js:219
ContextAPI.with @ context.js:88
eval @ exporter.js:25
ZoneAwarePromise @ zone.js:1429
_export @ exporter.js:23
doExport @ SimpleSpanProcessor.js:98
SimpleSpanProcessor.onEnd @ SimpleSpanProcessor.js:123
MultiSpanProcessor.onEnd @ MultiSpanProcessor.js:84
Span.end @ Span.js:190
eval @ index.js:56
invoke @ zone.js:372
run @ zone.js:134
eval @ zone.js:1275
invokeTask @ zone.js:406
runTask @ zone.js:178
drainMicroTaskQueue @ zone.js:585
Promise.then (async)
nativeScheduleMicroTask @ zone.js:561
scheduleMicroTask @ zone.js:572
scheduleTask @ zone.js:396
scheduleTask @ zone.js:221
scheduleMicroTask @ zone.js:241
scheduleResolveOrReject @ zone.js:1265
resolvePromise @ zone.js:1202
eval @ zone.js:1118
eval @ zone.js:1134
Promise.then (async)
eval @ zone.js:1509
ZoneAwarePromise @ zone.js:1429
Ctor.then @ zone.js:1508
eval @ fetch.js:304
invoke @ zone.js:372
run @ zone.js:134
ZoneContextManager.with @ ZoneContextManager.js:219
ContextAPI.with @ context.js:88
eval @ fetch.js:297
ZoneAwarePromise @ zone.js:1429
patchConstructor @ fetch.js:296
getData @ index.js:37
eval @ index.js:54
invoke @ zone.js:372
run @ zone.js:134
ZoneContextManager.with @ ZoneContextManager.js:219
ContextAPI.with @ context.js:88
onClick @ index.js:53
invokeTask @ zone.js:406
runTask @ zone.js:178
invokeTask @ zone.js:487
invokeTask @ zone.js:1661
globalCallback @ zone.js:1692
globalZoneAwareCallback @ zone.js:1725
util.js:55     POST http://localhost:4318/v1/traces 400 (Bad Request)
sendWithBeacon @ util.js:55
eval @ OTLPExporterBrowserBase.js:77
ZoneAwarePromise @ zone.js:1429
OTLPExporterBrowserBase.send @ OTLPExporterBrowserBase.js:72
eval @ OTLPExporterBase.js:76
ZoneAwarePromise @ zone.js:1429
OTLPExporterBase._export @ OTLPExporterBase.js:73
OTLPExporterBase.export @ OTLPExporterBase.js:63
eval @ exporter.js:26
invoke @ zone.js:372
run @ zone.js:134
ZoneContextManager.with @ ZoneContextManager.js:219
ContextAPI.with @ context.js:88
eval @ exporter.js:25
ZoneAwarePromise @ zone.js:1429
_export @ exporter.js:23
doExport @ SimpleSpanProcessor.js:98
SimpleSpanProcessor.onEnd @ SimpleSpanProcessor.js:123
MultiSpanProcessor.onEnd @ MultiSpanProcessor.js:84
Span.end @ Span.js:190
eval @ index.js:64
invoke @ zone.js:372
run @ zone.js:134
eval @ zone.js:1275
invokeTask @ zone.js:406
runTask @ zone.js:178
drainMicroTaskQueue @ zone.js:585
Promise.then (async)
nativeScheduleMicroTask @ zone.js:561
scheduleMicroTask @ zone.js:572
scheduleTask @ zone.js:396
scheduleTask @ zone.js:221
scheduleMicroTask @ zone.js:241
scheduleResolveOrReject @ zone.js:1265
resolvePromise @ zone.js:1202
eval @ zone.js:1118
eval @ zone.js:1134
Promise.then (async)
eval @ zone.js:1509
ZoneAwarePromise @ zone.js:1429
Ctor.then @ zone.js:1508
eval @ fetch.js:304
invoke @ zone.js:372
run @ zone.js:134
ZoneContextManager.with @ ZoneContextManager.js:219
ContextAPI.with @ context.js:88
eval @ fetch.js:297
ZoneAwarePromise @ zone.js:1429
patchConstructor @ fetch.js:296
getData @ index.js:37
eval @ index.js:62
invoke @ zone.js:372
run @ zone.js:134
ZoneContextManager.with @ ZoneContextManager.js:219
ContextAPI.with @ context.js:88
onClick @ index.js:61
invokeTask @ zone.js:406
runTask @ zone.js:178
invokeTask @ zone.js:487
invokeTask @ zone.js:1661
globalCallback @ zone.js:1692
globalZoneAwareCallback @ zone.js:1725
util.js:55     POST http://localhost:4318/v1/traces 400 (Bad Request)
sendWithBeacon @ util.js:55
eval @ OTLPExporterBrowserBase.js:77
ZoneAwarePromise @ zone.js:1429
OTLPExporterBrowserBase.send @ OTLPExporterBrowserBase.js:72
eval @ OTLPExporterBase.js:76
ZoneAwarePromise @ zone.js:1429
OTLPExporterBase._export @ OTLPExporterBase.js:73
OTLPExporterBase.export @ OTLPExporterBase.js:63
eval @ exporter.js:26
invoke @ zone.js:372
run @ zone.js:134
ZoneContextManager.with @ ZoneContextManager.js:219
ContextAPI.with @ context.js:88
eval @ exporter.js:25
ZoneAwarePromise @ zone.js:1429
_export @ exporter.js:23
doExport @ SimpleSpanProcessor.js:98
SimpleSpanProcessor.onEnd @ SimpleSpanProcessor.js:123
MultiSpanProcessor.onEnd @ MultiSpanProcessor.js:84
Span.end @ Span.js:190
eval @ index.js:64
invoke @ zone.js:372
run @ zone.js:134
eval @ zone.js:1275
invokeTask @ zone.js:406
runTask @ zone.js:178
drainMicroTaskQueue @ zone.js:585
Promise.then (async)
nativeScheduleMicroTask @ zone.js:561
scheduleMicroTask @ zone.js:572
scheduleTask @ zone.js:396
scheduleTask @ zone.js:221
scheduleMicroTask @ zone.js:241
scheduleResolveOrReject @ zone.js:1265
resolvePromise @ zone.js:1202
eval @ zone.js:1118
eval @ zone.js:1134
Promise.then (async)
eval @ zone.js:1509
ZoneAwarePromise @ zone.js:1429
Ctor.then @ zone.js:1508
eval @ fetch.js:304
invoke @ zone.js:372
run @ zone.js:134
ZoneContextManager.with @ ZoneContextManager.js:219
ContextAPI.with @ context.js:88
eval @ fetch.js:297
ZoneAwarePromise @ zone.js:1429
patchConstructor @ fetch.js:296
getData @ index.js:37
eval @ index.js:62
invoke @ zone.js:372
run @ zone.js:134
ZoneContextManager.with @ ZoneContextManager.js:219
ContextAPI.with @ context.js:88
onClick @ index.js:61
invokeTask @ zone.js:406
runTask @ zone.js:178
invokeTask @ zone.js:487
invokeTask @ zone.js:1661
globalCallback @ zone.js:1692
globalZoneAwareCallback @ zone.js:1725
util.js:55     POST http://localhost:4318/v1/traces 400 (Bad Request)
sendWithBeacon @ util.js:55
eval @ OTLPExporterBrowserBase.js:77
ZoneAwarePromise @ zone.js:1429
OTLPExporterBrowserBase.send @ OTLPExporterBrowserBase.js:72
eval @ OTLPExporterBase.js:76
ZoneAwarePromise @ zone.js:1429
OTLPExporterBase._export @ OTLPExporterBase.js:73
OTLPExporterBase.export @ OTLPExporterBase.js:63
eval @ exporter.js:26
invoke @ zone.js:372
run @ zone.js:134
ZoneContextManager.with @ ZoneContextManager.js:219
ContextAPI.with @ context.js:88
eval @ exporter.js:25
ZoneAwarePromise @ zone.js:1429
_export @ exporter.js:23
doExport @ SimpleSpanProcessor.js:98
SimpleSpanProcessor.onEnd @ SimpleSpanProcessor.js:123
MultiSpanProcessor.onEnd @ MultiSpanProcessor.js:84
Span.end @ Span.js:190
eval @ index.js:64
invoke @ zone.js:372
run @ zone.js:134
eval @ zone.js:1275
invokeTask @ zone.js:406
runTask @ zone.js:178
drainMicroTaskQueue @ zone.js:585
Promise.then (async)
nativeScheduleMicroTask @ zone.js:561
scheduleMicroTask @ zone.js:572
scheduleTask @ zone.js:396
scheduleTask @ zone.js:221
scheduleMicroTask @ zone.js:241
scheduleResolveOrReject @ zone.js:1265
resolvePromise @ zone.js:1202
eval @ zone.js:1118
eval @ zone.js:1134
Promise.then (async)
eval @ zone.js:1509
ZoneAwarePromise @ zone.js:1429
Ctor.then @ zone.js:1508
eval @ fetch.js:304
invoke @ zone.js:372
run @ zone.js:134
ZoneContextManager.with @ ZoneContextManager.js:219
ContextAPI.with @ context.js:88
eval @ fetch.js:297
ZoneAwarePromise @ zone.js:1429
patchConstructor @ fetch.js:296
getData @ index.js:37
eval @ index.js:62
invoke @ zone.js:372
run @ zone.js:134
ZoneContextManager.with @ ZoneContextManager.js:219
ContextAPI.with @ context.js:88
onClick @ index.js:61
invokeTask @ zone.js:406
runTask @ zone.js:178
invokeTask @ zone.js:487
invokeTask @ zone.js:1661
globalCallback @ zone.js:1692
globalZoneAwareCallback @ zone.js:1725
util.js:55     POST http://localhost:4318/v1/traces 400 (Bad Request)
sendWithBeacon @ util.js:55
eval @ OTLPExporterBrowserBase.js:77
ZoneAwarePromise @ zone.js:1429
OTLPExporterBrowserBase.send @ OTLPExporterBrowserBase.js:72
eval @ OTLPExporterBase.js:76
ZoneAwarePromise @ zone.js:1429
OTLPExporterBase._export @ OTLPExporterBase.js:73
OTLPExporterBase.export @ OTLPExporterBase.js:63
eval @ exporter.js:26
invoke @ zone.js:372
run @ zone.js:134
ZoneContextManager.with @ ZoneContextManager.js:219
ContextAPI.with @ context.js:88
eval @ exporter.js:25
ZoneAwarePromise @ zone.js:1429
_export @ exporter.js:23
doExport @ SimpleSpanProcessor.js:98
SimpleSpanProcessor.onEnd @ SimpleSpanProcessor.js:123
MultiSpanProcessor.onEnd @ MultiSpanProcessor.js:84
Span.end @ Span.js:190
eval @ index.js:64
invoke @ zone.js:372
run @ zone.js:134
eval @ zone.js:1275
invokeTask @ zone.js:406
runTask @ zone.js:178
drainMicroTaskQueue @ zone.js:585
Promise.then (async)
nativeScheduleMicroTask @ zone.js:561
scheduleMicroTask @ zone.js:572
scheduleTask @ zone.js:396
scheduleTask @ zone.js:221
scheduleMicroTask @ zone.js:241
scheduleResolveOrReject @ zone.js:1265
resolvePromise @ zone.js:1202
eval @ zone.js:1118
eval @ zone.js:1134
Promise.then (async)
eval @ zone.js:1509
ZoneAwarePromise @ zone.js:1429
Ctor.then @ zone.js:1508
eval @ fetch.js:304
invoke @ zone.js:372
run @ zone.js:134
ZoneContextManager.with @ ZoneContextManager.js:219
ContextAPI.with @ context.js:88
eval @ fetch.js:297
ZoneAwarePromise @ zone.js:1429
patchConstructor @ fetch.js:296
getData @ index.js:37
eval @ index.js:62
invoke @ zone.js:372
run @ zone.js:134
ZoneContextManager.with @ ZoneContextManager.js:219
ContextAPI.with @ context.js:88
onClick @ index.js:61
invokeTask @ zone.js:406
runTask @ zone.js:178
invokeTask @ zone.js:487
invokeTask @ zone.js:1661
globalCallback @ zone.js:1692
globalZoneAwareCallback @ zone.js:1725
util.js:55     POST http://localhost:4318/v1/traces 400 (Bad Request)
sendWithBeacon @ util.js:55
eval @ OTLPExporterBrowserBase.js:77
ZoneAwarePromise @ zone.js:1429
OTLPExporterBrowserBase.send @ OTLPExporterBrowserBase.js:72
eval @ OTLPExporterBase.js:76
ZoneAwarePromise @ zone.js:1429
OTLPExporterBase._export @ OTLPExporterBase.js:73
OTLPExporterBase.export @ OTLPExporterBase.js:63
eval @ exporter.js:26
invoke @ zone.js:372
run @ zone.js:134
ZoneContextManager.with @ ZoneContextManager.js:219
ContextAPI.with @ context.js:88
eval @ exporter.js:25
ZoneAwarePromise @ zone.js:1429
_export @ exporter.js:23
doExport @ SimpleSpanProcessor.js:98
SimpleSpanProcessor.onEnd @ SimpleSpanProcessor.js:123
MultiSpanProcessor.onEnd @ MultiSpanProcessor.js:84
Span.end @ Span.js:190
eval @ fetch.js:213
timer @ zone.js:2405
invokeTask @ zone.js:406
runTask @ zone.js:178
invokeTask @ zone.js:487
ZoneTask.invoke @ zone.js:476
data.args.<computed> @ zone.js:2385
setTimeout (async)
scheduleTask @ zone.js:2387
scheduleTask @ zone.js:393
scheduleTask @ zone.js:221
scheduleMacroTask @ zone.js:244
scheduleMacroTaskWithCurrentZone @ zone.js:683
eval @ zone.js:2429
proto.<computed> @ zone.js:973
FetchInstrumentation._endSpan @ fetch.js:207
endSpanOnSuccess @ fetch.js:247
eval @ fetch.js:268
invoke @ zone.js:372
run @ zone.js:134
eval @ zone.js:1275
invokeTask @ zone.js:406
runTask @ zone.js:178
drainMicroTaskQueue @ zone.js:585
Promise.then (async)
nativeScheduleMicroTask @ zone.js:561
scheduleMicroTask @ zone.js:572
scheduleTask @ zone.js:396
scheduleTask @ zone.js:221
scheduleMicroTask @ zone.js:241
scheduleResolveOrReject @ zone.js:1265
resolvePromise @ zone.js:1202
eval @ zone.js:1118
eval @ zone.js:1134
Promise.then (async)
eval @ zone.js:1509
ZoneAwarePromise @ zone.js:1429
Ctor.then @ zone.js:1508
read_1 @ fetch.js:265
eval @ fetch.js:271
invoke @ zone.js:372
run @ zone.js:134
eval @ zone.js:1275
invokeTask @ zone.js:406
runTask @ zone.js:178
drainMicroTaskQueue @ zone.js:585
Promise.then (async)
nativeScheduleMicroTask @ zone.js:561
scheduleMicroTask @ zone.js:572
scheduleTask @ zone.js:396
scheduleTask @ zone.js:221
scheduleMicroTask @ zone.js:241
scheduleResolveOrReject @ zone.js:1265
resolvePromise @ zone.js:1202
eval @ zone.js:1118
eval @ zone.js:1134
Promise.then (async)
eval @ zone.js:1509
ZoneAwarePromise @ zone.js:1429
Ctor.then @ zone.js:1508
read_1 @ fetch.js:265
onSuccess @ fetch.js:277
invoke @ zone.js:372
run @ zone.js:134
eval @ zone.js:1275
invokeTask @ zone.js:406
runTask @ zone.js:178
drainMicroTaskQueue @ zone.js:585
Promise.then (async)
nativeScheduleMicroTask @ zone.js:561
scheduleMicroTask @ zone.js:572
scheduleTask @ zone.js:396
scheduleTask @ zone.js:221
scheduleMicroTask @ zone.js:241
scheduleResolveOrReject @ zone.js:1265
resolvePromise @ zone.js:1202
eval @ zone.js:1118
eval @ zone.js:1134
Promise.then (async)
eval @ zone.js:1509
ZoneAwarePromise @ zone.js:1429
Ctor.then @ zone.js:1508
eval @ fetch.js:304
invoke @ zone.js:372
run @ zone.js:134
ZoneContextManager.with @ ZoneContextManager.js:219
ContextAPI.with @ context.js:88
eval @ fetch.js:297
ZoneAwarePromise @ zone.js:1429
patchConstructor @ fetch.js:296
getData @ index.js:37
eval @ index.js:62
invoke @ zone.js:372
run @ zone.js:134
ZoneContextManager.with @ ZoneContextManager.js:219
ContextAPI.with @ context.js:88
onClick @ index.js:61
invokeTask @ zone.js:406
runTask @ zone.js:178
invokeTask @ zone.js:487
invokeTask @ zone.js:1661
globalCallback @ zone.js:1692
globalZoneAwareCallback @ zone.js:1725
ConsoleSpanExporter.js:88

I'm seeing the same issue, and it seems to be related to this change: https://github.com/open-telemetry/opentelemetry-js/pull/4062/
The startTimeUnixNano and endTimeUnixNano are serialized as an object, e.g. {"low":1045401984,"high":395145071}, instead of number or string, therefore collector can not parse it, hence throwing the ReadUint64: unsupported value type error: https://github.com/open-telemetry/opentelemetry-collector/blob/main/pdata/internal/json/number.go#L52-L67

@lingyan Is there an older release of this open-telemetry-js that I could run without running into this issue?

@lingyan Is there an older release of this open-telemetry-js that I could run without running into this issue?

If you can, try downgrading @opentelemetry/exporter-trace-otlp-http to 0.43.0 for now.

I'm seeing the same issue, and it seems to be related to this change: #4062
The startTimeUnixNano and endTimeUnixNano are serialized as an object, e.g. {"low":1045401984,"high":395145071}, instead of number or string, therefore collector can not parse it, hence throwing the ReadUint64: unsupported value type error: https://github.com/open-telemetry/opentelemetry-collector/blob/main/pdata/internal/json/number.go#L71-L86
Based on the parser code, serializing the 64bit value to a string (instead of the object with low high fields) would solve this issue.

The JSON encoding went unnoticed in my PR, where the intermediate types were are serialized directly with JSON.stringify in the HTTP exporter. The conversion code needs another flag (e.g. to serialize fixed64 to strings). I'll try to get a fix in tomorrow.

I'm seeing the same issue, and it seems to be related to this change: #4062
The startTimeUnixNano and endTimeUnixNano are serialized as an object, e.g. {"low":1045401984,"high":395145071}, instead of number or string, therefore collector can not parse it, hence throwing the ReadUint64: unsupported value type error: open-telemetry/opentelemetry-collector@main/pdata/internal/json/number.go#L71-L86
Based on the parser code, serializing the 64bit value to a string (instead of the object with low high fields) would solve this issue.

The JSON encoding went unnoticed in my PR, where the intermediate types were are serialized directly with JSON.stringify in the HTTP exporter. The conversion code needs another flag (e.g. to serialize fixed64 to strings). I'll try to get a fix in tomorrow.

Thank you for picking this up @seemk

One thing to consider is whether CI should run some sort of functional test where the output from NodeJS exporters are sent to an OpenTelemetry Collector - and ensure that the data is parsed and collected correctly.
Such a test would have failed before the original PR #4062 was merged.

Agreed, we should have something like this. There's #2157 to track this. I added it to the Exporter GA Milestone.

Adding toString from long.js[https://github.com/dcodeIO/long.js/blob/main/index.js#L499] would pretty much bring in most of the library.
Wonder if it'd make sense to copy long.js to this codebase instead of copying only the relevant parts.
Another option would be to encode fixed64 as numbers in the JSON exporter, but this means the precision error is back.
I'm for just copying over long.js (as far as I know it can't be added as a dependency due to ESM), but this would cause the package size to go up and I think the JSON exporter is mostly used in browsers :thinking:

Is using JavaScript's built-int BigInt type an option?

Is using JavaScript's built-int BigInt type an option?

Went with the BigInt route with a fallback to the old imprecise (doesn't really matter for browsers anyway) numeric value in case BigInt isn't available: https://github.com/open-telemetry/opentelemetry-js/pull/4220

This was quite the debug session to find the issue. Errors coming from the tools we used weren't helpful.
Give this appears to be a broken release (i assume) could a patch be released or retag latest on npm to 0.43.0? Personally it was my first time using OTEL and without a change log or anything to go off this was very hard to pin down.

This was quite the debug session to find the issue. Errors coming from the tools we used weren't helpful.
Give this appears to be a broken release (i assume) could a patch be released or retag latest on npm to 0.43.0? Personally it was my first time using OTEL and without a change log or anything to go off this was very hard to pin down.

+1 for releasing emergency patches in these cases

https://github.com/open-telemetry/opentelemetry-js/issues/4202#issuecomment-1760315879
This didnt work ... any other alternative fix available?

#4202 (comment)
This didnt work ... any other alternative fix available?

Downgrade everything that's 0.44.0 to 0.43.0, this helped me

Hi all, any traction with this issue? Since it is a major break in functionality, if we believe that having a fix might require more time, I recommend reverting the change that introduced it and re-release asap.
As it is now, the 0.44 version can't be used and there is no indication in any documentation of that fact.

Hi all, any traction with this issue? Since it is a major break in functionality, if we believe that having a fix might require more time, I recommend reverting the change that introduced it and re-release asap. As it is now, the 0.44 version can't be used and there is no indication in any documentation of that fact.

The fix has been in a PR state for a while: https://github.com/open-telemetry/opentelemetry-js/pull/4220

Thanks @seemk What is preventing a merge? I see some unit tests failing. Is that ok?

Looks like all PRs have the same issue currently: https://github.com/open-telemetry/opentelemetry-js/pulls :thinking:

@pichlermarc seems to be out of office. I wonder who else could approve this and generate a new release.

#4202 (comment)
This didnt work ... any other alternative fix available?

Downgrade everything that's 0.44.0 to 0.43.0, this helped me

Thanks @mateusz-lisik .. didnt work
Downgraded these to 0.43.0
@opentelemetry/exporter-trace-otlp-http, @opentelemetry/instrumentation
but still facing the same issue

Any updates on this? It is blocking a project I'm working on.

Any updates on this? It is blocking a project I'm working on.

Welcome to the club :)

#4202 (comment)
This didnt work ... any other alternative fix available?

Downgrade everything that's 0.44.0 to 0.43.0, this helped me

0.43 does not have this issue but it has another bug (fixed in 0.44) where the library cannot be used from a WebWorker.

Hello any progress?

Hello any progress?

They fixed it. I tested the latest version and it works well.

authors: bpsgit clyncha cristianmadularu joshmeads lingyan mateusz-lisik pichlermarc seemk vpmedia yaohongkok


text:
enh: Improve Delete Chat Function

After clicking on "..." beside your chat and then clicking delete, the expectation is that your chat will be deleted.  In practice, after clicking delete a small check mark and x appear beside the chat that is very easy to miss (I missed it).  Unlike the popup, the delete confirmation is not as obvious.
Additionally, the options aren't intuitive.  I want to delete it, so should I click the "x" to delete or the checkmark?
If confirmation is necessary. then I think a popup with "Delete"/"Cancel" is a more elegant solution.

Implemented on dev!

Implemented on dev!

Awesome!

repo: open-webui/open-webui


text:
Ollama Model Pull Error in Huggingface Space

I have hosted open-web UI on a huggingface space but having some difficultly downloading a model via Ollama from the Seetings/Model page.
I receive this Error in the logs:
ERROR [apps.ollama.main] Connection error: Cannot connect to host host.docker.internal:11434 ssl:default [Name or service not known]
If this functionality is even possible in a Huggingface Space, I'm assuming there may be some configuration I have to one of the Docker/docker-composes?
Apologize for the vagueness of this 'Issue'.  It's more of a question if it's possible.
Thank you.

This functionality is not possible in a HF Space unless you use an external-hosted Ollama instance accessed via an HTTP tunnel. For deployment to HF Space, your most convenient options are external OpenAI-compatible APIs, or via adapter pipes with Functions.

authors: justinh-rahb williamzebrowskI


text:
Incorrect docker compose file specified in documentation -> development

The docker compose file mentioned at https://docs.openwebui.com/tutorial-development/ throws the following errors errors -

services.backend.environment.[0]: unexpected type map[string]interface {} -> Caused due to "ENV: dev" inside the environment section
service "ollama" refers to undefined volume ollama: invalid compose project -> missing "ollama:{}" under the volumes section
Due to missing value of WEBUI_AUTH, the exception ERROR_MESSAGES.ENV_VAR_NOT_FOUND is raised

The following docker compose file corrects the both of them. Unable to find the source of the same to raise a PR
name: open-webui-dev

services:
  ollama:
    volumes:
      - ollama:/root/.ollama
    container_name: ollama
    pull_policy: always
    tty: true
    restart: no
    image: ollama/ollama:${OLLAMA_DOCKER_TAG-latest}

  frontend:
    build:
      context: .
      target: build
    command: ["npm", "run", "dev"]
    depends_on:
      - backend
    extra_hosts:
      - host.docker.internal:host-gateway
    ports:
      - "3000:5173"
    develop:
      watch:
        - action: sync
          path: ./src
          target: /app/src
        - action: rebuild
          path: package.json

  backend:
    build:
      context: .
      target: base
    command: ["bash", "dev.sh"]
    env_file: ".env"
    environment:
     - ENV=dev
     - WEBUI_AUTH=False
    volumes:
      - data:/app/backend/data
    extra_hosts:
      - host.docker.internal:host-gateway
    ports:
      - "8080:8080"
    restart: no
    develop:
      watch:
        - action: sync
          path: ./backend
          target: /app/backend
          ignore:
            - backend/data
        - action: rebuild
          path: backend/requirements.txt

volumes:
  data: {}
  ollama: {}

Tracking at - https://github.com/open-webui/docs/issues/179

Tracking at - open-webui/docs#179


text:
issue: windows Functions - [WinError 32] The process cannot access the file because it is being used by another process

Discussed in https://github.com/open-webui/open-webui/discussions/5606

@EtiennePerot Related #5511

Hmm. It seems like it is complaining that a file is being accessed from multiple processes, but the code specifically closes the temporary file prior to calling exec (by virtue of ending the with block):
https://github.com/open-webui/open-webui/blob/6b463164f4b129e0ce4bdc9008dd661214fe5eb5/backend/open_webui/apps/webui/utils.py#L87-L97
I don't have a Windows machine to test this on either, but the Python documentation on tempfile.NamedTemporaryFile helpfully states:

Opening the temporary file again by its name while it is still open works as follows:
On POSIX the file can always be opened again.
On Windows, make sure that at least one of the following conditions are fulfilled:

delete is false
additional open shares delete access (e.g. by calling os.open() with the flag O_TEMPORARY)
delete is true but delete_on_close is false. Note, that in this case the additional opens that do not share delete access (e.g. created via builtin open()) must be closed before exiting the context manager, else the os.unlink() call on context manager exit will fail with a PermissionError.

So I think adding delete_on_close=True should suffice, given that the file is deleted later in the finally block. I can send a PR for that later today.

faced the same problem with the latest build on windows.  @EtiennePerot does your solution solves it? I will try it today.

No, I was wrong above. But I just sent #5649 which should fix it.

Yes. #5649 solved my problem on windows. thanks @EtiennePerot 👏

Thanks everyone!

Just upgraded to 0.3.28 - issue resolved - thanks all for your efforts

authors: EtiennePerot github-pmj tcgumus tjbck


text:
fix of 'show username' feat now working when chat bubbles active

Fixed

Fixes "show username" feat not working when "Chat Bubbles UI" is aktive. User now gets notified by a toast and "show username" will be deactivated automatically when both active.
Added one missing i18n key to a toast in the same file
Fixed missing padding for the UserMessage. I noticed that when I deactivated Chat Bubbles UI the space between the ProfileImage and the Username was missing

Cherry-picked changes :), Thanks!

authors: jannikstdl tjbck


text:
WIP: add embedding pipelines support

related to https://github.com/open-webui/pipelines/issues/81

This is great, I'll take a look in a bit!

authors: RobinBia tjbck

repo: open-webui/pipelines


text:
open3e --scanall fails with NegativeResponseException

After a firmware update on my Vitocal 250A it fails to generate a list of all DIDs:
$ open3e -c can0 -dev vcal --scanall
reading 0x680, 539 datapoints, please be patient...
Traceback (most recent call last):
  File "/home/pi/.local/bin/open3e", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/home/pi/.local/lib/python3.11/site-packages/open3e/Open3Eclient.py", line 406, in main
    lst = ecu.readAll(args.raw)
          ^^^^^^^^^^^^^^^^^^^^^
  File "/home/pi/.local/lib/python3.11/site-packages/open3e/Open3Eclass.py", line 170, in readAll
    value,idstr = self.readByDid(int(did), raw=raw)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/pi/.local/lib/python3.11/site-packages/open3e/Open3Eclass.py", line 154, in readByDid
    response = self.uds_client.read_data_by_identifier([did])
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/pi/.local/lib/python3.11/site-packages/udsoncan/client.py", line 167, in decorated
    return func(self, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/pi/.local/lib/python3.11/site-packages/udsoncan/client.py", line 466, in read_data_by_identifier
    response = self.send_request(req)
               ^^^^^^^^^^^^^^^^^^^^^^
  File "/home/pi/.local/lib/python3.11/site-packages/udsoncan/client.py", line 2258, in send_request
    raise NegativeResponseException(response)
udsoncan.exceptions.NegativeResponseException: ReadDataByIdentifier service execution returned a negative response ConditionsNotCorrect (0x22)

I ran open3e_depictSystem and all "normal" reads work like they did before. For instance:
$ open3e -c can0 -dev vcal -r 424,426 -v
vcal 424 MixerOneCircuitRoomTemperatureSetpoint {"Comfort": 23.0, "Standard": 21.0, "Reduced": 3.0, "Unknown2": "0000", "Unknown1": 0}
vcal 426 MixerTwoCircuitRoomTemperatureSetpoint {"Comfort": 23.0, "Standard": 21.0, "Reduced": 14.0, "Unknown2": "0000", "Unknown1": 0}
closing 0x680 - bye!

If you interested in the main ecu only, you might use -dev 680. the datapoints_680 gets updated by depict_system.

Thanks!
open3e -c can0 -cnfg devices.json --scanall
Does the job.
But both
open3e -c can0 -dev 680 --scanall
open3e -c can0 -dev 0x680 --scanall

crash with
ModuleNotFoundError: No module named 'open3e.Open3Edatapoints680'
ModuleNotFoundError: No module named 'open3e.Open3Edatapoints0x680'

respectively.

oh, sorry. so you need to do open3e -c can0 -dev _680 --scanall (inclluding the underscore)

ps. more details regarding the -dev issue see here: https://github.com/open3e/open3e/issues/153

fu.., now the .py is missing. I'm in a hurry right now, I will come back later.
It is a problem related to the pip installatin. in earlier times it worked..

sorry, I can't explain since I do not understand, but perhaps you like to follow the dickussion of it here: https://github.com/open3e/open3e/issues/153#issuecomment-2480809317

hi @bomilkar Ronald!
just in terms of cleaning up... -dev Open3Edatapoints_680.py should wotk nowadays - does it for you? if so, I'd like to close the issue!?

I think the workaround was to use open3e  --scanall


text:
Resolve operation-client-interface-status/operational-state service getting failed due to openapi.validation

Fixes #182

Reviewer is @vanithavalluripalli9

Reviewer is @vanithavalluripalli9


text:
Announce Beta feature

We want to start getting feedback from users about the new UI.
Do we want to release that already? :thinking:

Deploy preview for openbuildservice ready!
Built with commit 9d18258c7514565a6dc9c6e708998cfd3c0e770b
https://deploy-preview-202--openbuildservice.netlify.com

 Announce the Beta Link

Do we want to release that already?

No because there is nothing (good enough) yet to try right?

@hennevogel

No because there is nothing (good enough) yet to try right?

there are already quite a lot of new pages. If we want to announce the package page separately we could announce. But I have no strong opinion, we can also wait until package is completely finished.
What should I do with the card then? moving it to block?

there are already quite a lot of new pages.

Quantity != Quality  :-)

What should I do with the card then? moving it to blocked?

Leave it hanging in doing. Blocked means something external blocks it (like people outside the team have to do something and you don't know when they will do it etc.)

@dmarcoux thanks for the review! :wink:

I discussed with @henne that we want the Beta blog post to not be bootstrap specific. I close this and I'll open 2 new PRs with independent blog post using this one as base, one for each of the cards: https://trello.com/c/s2BY2gvC/877-announce-the-beta-link and https://trello.com/c/Y5sAMhua/876-announce-package-show-in-bootstrap

repo: openSUSE/obs-landing


text:
mark cancelled journey in the station board

in the station board we can see, that a train / bus / tram is late or on time, but we can't see the status "cancelled" although it is written in the StopEventResponse:
        <ojp:Service>
          <ojp:OperatingDayRef>2023-03-13</ojp:OperatingDayRef>
          <ojp:JourneyRef>ojp:91005:Y:R:j23:75:7308</ojp:JourneyRef>
          <siri:LineRef>ojp:91005:Y</siri:LineRef>
          <siri:DirectionRef>R</siri:DirectionRef>
          <ojp:Mode>
            <ojp:PtMode>rail</ojp:PtMode>
            <siri:RailSubmode>regionalRail</siri:RailSubmode>
            <ojp:Name>
              <ojp:Text xml:lang="de">Zug</ojp:Text>
            </ojp:Name>
            <ojp:ShortName>
              <ojp:Text xml:lang="de">R</ojp:Text>
            </ojp:ShortName>
          </ojp:Mode>
          <ojp:PublishedLineName>
            <ojp:Text xml:lang="de">R</ojp:Text>
          </ojp:PublishedLineName>
          <ojp:OperatorRef>ojp:11</ojp:OperatorRef>
          <ojp:OriginStopPointRef>8504304</ojp:OriginStopPointRef>
          <ojp:OriginText>
            <ojp:Text xml:lang="de">Sonceboz-Sombeval</ojp:Text>
          </ojp:OriginText>
          <ojp:DestinationStopPointRef>8500105</ojp:DestinationStopPointRef>
          <ojp:DestinationText>
            <ojp:Text xml:lang="de">Moutier</ojp:Text>
          </ojp:DestinationText>
          ### <ojp:Cancelled>true</ojp:Cancelled>
        </ojp:Service>

in the station board we can see, that a train / bus / tram is late or on time, but we can't see the status "cancelled" although it is written in the StopEventResponse:
        <ojp:Service>
          <ojp:OperatingDayRef>2023-03-13</ojp:OperatingDayRef>
          <ojp:JourneyRef>ojp:91005:Y:R:j23:75:7308</ojp:JourneyRef>
          <siri:LineRef>ojp:91005:Y</siri:LineRef>
          <siri:DirectionRef>R</siri:DirectionRef>
          <ojp:Mode>
            <ojp:PtMode>rail</ojp:PtMode>
            <siri:RailSubmode>regionalRail</siri:RailSubmode>
            <ojp:Name>
              <ojp:Text xml:lang="de">Zug</ojp:Text>
            </ojp:Name>
            <ojp:ShortName>
              <ojp:Text xml:lang="de">R</ojp:Text>
            </ojp:ShortName>
          </ojp:Mode>
          <ojp:PublishedLineName>
            <ojp:Text xml:lang="de">R</ojp:Text>
          </ojp:PublishedLineName>
          <ojp:OperatorRef>ojp:11</ojp:OperatorRef>
          <ojp:OriginStopPointRef>8504304</ojp:OriginStopPointRef>
          <ojp:OriginText>
            <ojp:Text xml:lang="de">Sonceboz-Sombeval</ojp:Text>
          </ojp:OriginText>
          <ojp:DestinationStopPointRef>8500105</ojp:DestinationStopPointRef>
          <ojp:DestinationText>
            <ojp:Text xml:lang="de">Moutier</ojp:Text>
          </ojp:DestinationText>
          ### <ojp:Cancelled>true</ojp:Cancelled>
        </ojp:Service>

Deployed to PROD, can be tested with a mock
https://opentdatach.github.io/ojp-demo-app/board?gist=3da967ad348d35b04f667921c9590b6d

repo: openTdataCH/ojp-demo-app-src


text:
handle sparse gradients

This small fix allows using gradient checkpointing even if some gradients are sparse.
For instance, if one uses Embedding layer and requests derivatives w.r.t. embedding weights, tensorflow.gradients would produce gradient as IndexedSlices instead of tensor.
Doing the same with gradient checkpointing results in an error on line
d_xs[j] += d_xs_new[j]

Here, both d_xs[j] += d_xs_new[j] would be tf.IndexedSlices that cannot be added with '+'.
A cheap solution is to manually cast everything to dense gradients if addition is required.
Given enough time, one could also devise a way to add indexed slices sparsely. Alas, i am not given enough time.

Hm I don't seem to have merge rights to this repo, @TimSalimans do you know who could approve the merge?

authors: justheuristic yaroslavvb

repo: openai/gradient-checkpointing


text:
Notebook-Updates

Summary
Briefly describe the changes and the goal of this PR. Make sure the PR title summarizes the changes effectively.
Motivation
Why are these changes necessary? How do they improve the cookbook?
Updated the code to generalize on latest GPT models (GPT-4 series) and leverage search with older and newer models.

For new content
When contributing new content, read through our contribution guidelines, and mark the following action items as completed:

[x] I have added a new entry in registry.yaml (and, optionally, in authors.yaml) so that my content renders on the cookbook website.
[x] I have conducted a self-review of my content based on the contribution guidelines:

[x] Relevance: This content is related to building with OpenAI technologies and is useful to others.
[x] Uniqueness: I have searched for related examples in the OpenAI Cookbook, and verified that my content offers new insights or unique information compared to existing documentation.
[x] Spelling and Grammar: I have checked for spelling or grammatical mistakes.
[x] Clarity: I have done a final read-through and verified that my submission is well-organized and easy to understand.
[x] Correctness: The information I include is correct and all of my code executes successfully.
[x] Completeness: I have explained everything fully, including all necessary references and citations.

We will rate each of these areas on a scale from 1 to 4, and will only accept contributions that score 3 or higher on all areas. Refer to our contribution guidelines for more details.

Updated the notebook with recent models.

repo: openai/openai-cookbook


text:
Consider using hatch as build-backend?

Describe the feature or improvement you're requesting
setup.py + setup.cfg is an outdated way of building Python projects. The configuration can be moved to pyproject.toml for consistency.
hatch is a modern python project management tool. hatch is used by the likes of fastAPI, black, pydantic and others to manage projects.
Additional context
No response

In our v1 beta we've migrated to Rye which uses Rye under the hood.

authors: RobertCraigie ischaojie

repo: openai/openai-python

license: mit


text:
iptables permission denied

Expected behavior
flashgames docker starts and game starts
Actual behavior
initializing container fails with permission error
relevant container is quay.io/openai/universe.flashgames:0.20.25
iptables v1.6.0: can't initialize iptables table `filter': Permission denied (you must be root)
Perhaps iptables or your kernel needs to be upgraded.
Traceback (most recent call last):
File "/app/universe-envs/flashgames/init", line 268, in
sys.exit(main())
File "/app/universe-envs/flashgames/init", line 182, in main
subprocess.check_call(['iptables', '-F'])
File "/usr/lib/python3.5/subprocess.py", line 581, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['iptables', '-F']' returned non-zero exit status 3
Versions
Please include the result of running ...
N/A, this is my Rust driver: https://github.com/andrew-lucker/rust-openai
Running latest docker on Mac OSX

FYI, the docker is started without extra flags such as in
https://github.com/openai/universe/blob/master/universe/runtimes/registration.py#L68

reproducible from command line with
docker run quay.io/openai/universe.flashgames:0.20.25

The extra flags are necessary: --ipc host --cap-add SYS_ADMIN --privileged

OK, that worked. Thank you.

authors: andrew-lucker tlbtlbtlb

repo: openai/universe


text:
Replace regular expressions

to reduce redundancy and improve performance

For performance, use re.compile

For performance, use re.compile

also it's a way to process not only ASCII chars but unicode too

authors: ExtReMLapin eukub

repo: openai/whisper


text:
Introduce more utility replacements to ParamPathVariableResolver

Issue Details
Type of Issue  (check one with "X")
[ ] Bug Report => Please search GitHub for a similar issue or PR before submitting
[X] Feature Request => Please ensure feature is not already in progress
[ ] Support Request => Please do not submit support requests here, instead see: https://discourse.oss.antheminc.com/

Description
As an engineer
I want to have access to more utility resolvers similar to <!#this!>
So that my configs are easier to read and write
Acceptance Criteria
Assume the following sample configuration:
Root.java
@Domain(...)
@Data
public class Root {
    private NestedA nestedA;
}

NestedA.java
@Model
@Data
public class NestedA {
    private NestedB nestedB;

    @Model
    @Data
    public class NestedB {
        private String p1;
        private String p2;
    }
}

Given a @Config decorating a Root.nestedA.nestedB.p1 and executing from a domain entity with refId=1
When the @Config contains a url having "<!#classfile!>/nestedB/p2"
Then the path should resolve to "/client/org/p/root:1/nestedA/nestedB/p2"

Given a @Config decorating a Root.nestedA.nestedB.p1 and executing from a domain entity with refId=1
When the @Config contains a url having "<!#parent!>/p2"
Then the path should resolve to "/client/org/p/root:1/nestedA/nestedB/p2"

Relates to #624 and Potential duplicate of https://anthemopensource.atlassian.net/browse/NIMBUS-318

repo: openanthem/nimbus-core


text:
Enhance validate conditional target paths

Issue Details
Type of Issue  (check one with "X")
[ ] Bug Report => Please search GitHub for a similar issue or PR before submitting
[ ] Feature Request => Please ensure feature is not already in progress
[X] Support Request => Please do not submit support requests here, instead see: https://discourse.oss.antheminc.com/

Current Behavior
There is a framework limitation, there could only be 29 validateConditional paths.
Expected Behavior
System must allow unlimited numbers of validateConditional paths.
How to Reproduce the Issue
Steps to Reproduce

Code Snippet

Environment Details

Nimbus Version:
1.3.2.M2

Browser:
Google Chrome

Extend ValidationGroup

authors: PragneshHadiyel sandeepmantha


text:
Restart playback at the end

If I'm right at the end of the video and hit playback again, it would be nice if we could actually restart playback from the start.
https://user-images.githubusercontent.com/1008395/196646830-ddf8a179-1786-4a61-958c-9f6f79354a8e.mp4
(you want to enable audio if you watch that video)

@lkiesow i would like to contribute to this issue.

Thanks for taking this up.

Hi @RachitGarg-12, since Hacktoberfest is over and my guess is that you picked this up as part of it, do you still plan to work on this now that the event is over?

repo: opencast/opencast-editor


text:
Speed up normalize route

Detailed Description
Current the /v0/GB/solar/gsp/forecast/all with normalize == True takes ~10 seconds. This is to long.
Context
Would be good for FE if ~1 second
Possible Implementation
slow part is the looping in the pydantic model, to normalize data. We could:

Save the data and add a 'normalize' flag. This would double the amount of data in the database, but make for quick reading
Paralize the processing - here. Not sure if setup up parrallel costs would make it speed up
Try to convert pydantic models to flat pandas frames, then operate on one column, then convert back to pydantic models
Add validation method to pydanitc model, use if normalize do this.
Other options ...

I'm not familiar with the code but is there a way to vectorise the normalization? (Maybe that's what converting to pd.DataFrame would achieve?)

On version 0.1.34
normalize = false took 2.77 seconds
normalize= True took 2.87 seconds
So ill close this for now. They can be a case to speed this query up, but this is not to do with normalizing data or not

I'm not familiar with the code but is there a way to vectorise the normalization? (Maybe that's what converting to pd.DataFrame would achieve?)

yea, that would be the aim. Unfortunately the slowest is by the database, probably the thing to do is this - https://github.com/openclimatefix/nowcasting_datamodel/issues/2

authors: JackKelly peterdudfield


text:
Add Vector on Signin and Signup Page

For this task use this vector and place it on signin and signup page in place of the left div which is having a background  colorright now.
The vector is already downloaded in assets folder no need to download it again.
Make sure you place the vector on both signin and signup pages.

claim

Claim

You already have an issue assigned to you @GammaMicrowave  in this repo.

Assigned to @Shubhankit-Pandey

aight

@Shubhankit-Pandey  udpates ? Not a big task ig . Try to close it asap

Good work @Shubhankit-Pandey

repo: opencodeiiita/SaveMyForm-Frontend


text:
Member can submit a request to create a subcollective

Is your feature request related to a problem? Please describe.
We want to make it easy for community members to create a new subcollective for a local group, an affinity group, etc. Yet, to avoid chaos, we think that it would be good for collective admins to approve/reject subcollective creation requests.
Describe the solution you'd like
As a collective member, I can click a "Suggest a new subcollective" button. I'm redirected to a form explaining me the benefits of a subcollective and providing me examples of relevant subcollectives. Then I submit my request, providing:

subcollective name
details (textarea)

As a collective admin, I am notified about the request and I can access a page providing me details about the request, and allowing me to accept/reject the request. This can still be updated later (eg. a collective admin rejects the request, but the admins decide later that it is relevant and should be accepted).
As a collective member, I am notified of the decision. If the subcollective is accepted, I am an admin of this new subcollective.
Describe alternatives you've considered

In the collective About text, provide an email address members can send requests to, and then have admins create subcollectives

Additional context
None for now. Please comment and ping me if you would like to code this feature. I'll be happy to provide additional context.

@xdamman Does this feature make sense? Anything to add?

repo: opencollective/community


text:
Reset multi-currency expense's currencies when changing payout method

Part of #5146
Followup on https://github.com/opencollective/opencollective-frontend/pull/7421#pullrequestreview-872672318
Steps

Submit an expense to a USD collective in EUR
Edit the expense, set up a new payout method in GBP
Go next, the amount is still in EUR while the payout method is in GBP - which is not wrong in itself (the alternative of changing the currency without converting is far worse) but will usually result in a payment failure when paying with transferwise

Expected behavior
When changing the payout method, if expense.currency is not the same as collective.currency, nullify the currency and force the expense submitter to fill it again.

@Betree : I'll try to fix this issue this week if no objections. 🙂

authors: Betree SudharakaP

repo: opencollective/opencollective


text:
Strategy for permanently deleting soft-deleted entries

We have many soft-deleted entries in many tables of our DB (e.g. 250,000 orders). It's additional security, but they take space in the DB and it's unlikely that they will be useful after some time. We should:

Define what can be safely deleted
After what period of time
Create a CRON job for this

I'd suggest we implement this as a daily cron in api/cron/daily/cleanup-deleted-entities.ts. We could start with an MVP like:
const MODEL_RETENTION_PERIODS = {
  [models.UserToken]: '6 months',
  [models.ConnectedAccount]: '1 year',
  [models.Order]: '1 year'
};

const run = () => {
  for (const [model, retentionPeriod] of Object.entries(MODEL_RETENTION_PERIODS)) {
    await model.destroy({
      where: { deletedAt: { [Op.gt]: `NOW() - INTERVAL(${retentionPeriod})` } },
      paranoid: false
    })
  }
}

We have almost 25K accounts that have been soft-deleted for more than three years. Many of them are spammers, so we're willing to keep the records to train robots, but we should ideally move the data in cold storage.
select COUNT(*) from "Collectives" where "deletedAt" < NOW() - INTERVAL '3 years'


text:
Track accounting categories set by the different parties separately

Related to https://github.com/opencollective/opencollective/issues/7028
Track accounting categories set by the submitter, collective admin, and host admin separately. This will:

Help us to understand how many (%) expenses are rightfully filled from the start
Track the % that requires host admin intervention (and where they are)
Help us to implement a better flow where we can adapt depending on whether collective admins have already touched the category

Specs proposal

Track these categories in data (data.accountingCategory -> selectedBySubmitter, selectedByCollectiveAdmin, selectedByHost) by storing a simplified object containing an id, code and name.
Expose them on the GraphQL Expense object, and make sure we gracefully handle missing values since it's not going to be a real SQL relationship

Duplicate of https://github.com/opencollective/opencollective/issues/7090


text:
Fix order of transactions insertion in a transaction group

As part of https://github.com/opencollective/opencollective/issues/7106 we've identified that the order that transactions in a group are inserted into the database could be improved:

This inquiry has also surfaced that there is an issue with the transaction generating sequence: we generate host fee transactions before we generate contribution transactions. This should also be corrected and other transaction generating scenarios should be reviewed to make sure they all have internal logical integrity. One of the drivers for this project is to give users a view "under the hood" so that they can both understand and learn to trust the underlying ledger technology. We need to make sure that things are in order "under the hood."

Trans


text:
image: make layer validation work

Most recently, the validation was broken because the image-spec was
re-vendored but the code handling MediaType validation was not updated.
This change (among others) broke umoci's tests because we run the
validation code to ensure our images are always valid, and the
validation incorrectly flagged our images as invalid.
Fixes: ff477b3a7e85 ("vendor:update")
Signed-off-by: Aleksa Sarai asarai@suse.de

This is also broken inside the image specification, which I'm fixing separately...

Can we please be more careful next time?

This is a dupe of https://github.com/opencontainers/image-tools/pull/108 (though, this PR is correct...)

LGTM

Taking a step back, isn't this already handled by image-spec (which is was why it was broken in two places)?  The DRY path forward seems like it would be dropping this image-tools code completely and using the image-spec validation instead.

image-spec calls that descriptor-type check (see here and here), so MediaTypeManifest.Validate will trigger it.  And image-tools already calls MediaTypeManifest.Validate.  I think the local manifest validation 6 should be “call MediaTypeManifest.Validate and (optionally?) recurse through descendants (because the image-spec validation is intra-blob).  Maintaining parallel intra-blob validation here seems like a waste of effort.

Refer to https://github.com/opencontainers/image-tools/pull/62#issuecomment-263528341. This had better to be done in image spec repo.
cc @stevvooe WDYT?

@wking Sure, but at the moment that code doesn't actually return an error if the validation fails.

On Thu, Feb 09, 2017 at 12:43:56AM -0800, Aleksa Sarai wrote:

Sure, but at the moment that code doesn't actually return an error
if the validation fails.

That's because an unknown type is a SHOULD violation 1, not a MUST
violation, and the image-spec maintainers 2 and image-tools
maintainers (#66) haven't decided how they want to handle those yet.
Assuming we only error on MUST violations (until folks decide how to
handle SHOULD violations), there's no reason to error-out on unknown
types here, so using the image-spec code is fine.
Layer unpacking, on the other hand, should be erroring out on
unknown media types (that's violating the ‘unpackable’ condition I
floated in #66).  We'll want code around here 3, and that code will
have to start checking media types anyway now that both compressed and
uncompressed layers MUST be supported 4.

LGTM

LGTM

authors: coolljt0725 cyphar runcom stevvooe vbatts wking xiekeyang

repo: opencontainers/image-tools


text:
style: dangling paren

Signed-off-by: Vincent Batts vbatts@hashbangbash.com

47bca6848 looks good to me.  Sorry I missed it in 408412ba :/.

LGTM

authors: hqhq vbatts wking

repo: opencontainers/runtime-spec