text:
soc_td output table reports incorrect state labels

Referring to the final output (as found in soc_out.dat). The state labels on each line increment sequentially rather than respecting the singlets/triplets actually requested, although the calculated spin-orbit coupling values appear to correctly follow the requested states.
For example, with:
n_s = [4, 4, 4]
n_t = [1, 1, 1]

The output is similar to the following:
sum_soc, <S0|Hso|T1,1,0,-1> (cm-1):        60.74192       42.95102        0.00769       42.95102
sum_soc, <S0|Hso|T2,1,0,-1> (cm-1):        60.74192       42.95102        0.00769       42.95102
sum_soc, <S0|Hso|T3,1,0,-1> (cm-1):        60.74192       42.95102        0.00769       42.95102
sum_soc, <S1|Hso|T1,1,0,-1> (cm-1):         5.85744        4.14184        0.00012        4.14184
sum_soc, <S1|Hso|T2,1,0,-1> (cm-1):         5.85744        4.14184        0.00012        4.14184
sum_soc, <S1|Hso|T3,1,0,-1> (cm-1):         5.85744        4.14184        0.00012        4.14184
sum_soc, <S2|Hso|T1,1,0,-1> (cm-1):         5.85744        4.14184        0.00012        4.14184
sum_soc, <S2|Hso|T2,1,0,-1> (cm-1):         5.85744        4.14184        0.00012        4.14184
sum_soc, <S2|Hso|T3,1,0,-1> (cm-1):         5.85744        4.14184        0.00012        4.14184
sum_soc, <S3|Hso|T1,1,0,-1> (cm-1):         5.85744        4.14184        0.00012        4.14184
sum_soc, <S3|Hso|T2,1,0,-1> (cm-1):         5.85744        4.14184        0.00012        4.14184
sum_soc, <S3|Hso|T3,1,0,-1> (cm-1):         5.85744        4.14184        0.00012        4.14184

While the following would be expected:
sum_soc, <S0|Hso|T1,1,0,-1> (cm-1):        60.74192       42.95102        0.00769       42.95102
sum_soc, <S0|Hso|T1,1,0,-1> (cm-1):        60.74192       42.95102        0.00769       42.95102
sum_soc, <S0|Hso|T1,1,0,-1> (cm-1):        60.74192       42.95102        0.00769       42.95102
sum_soc, <S4|Hso|T1,1,0,-1> (cm-1):         5.85744        4.14184        0.00012        4.14184
sum_soc, <S4|Hso|T1,1,0,-1> (cm-1):         5.85744        4.14184        0.00012        4.14184
sum_soc, <S4|Hso|T1,1,0,-1> (cm-1):         5.85744        4.14184        0.00012        4.14184
sum_soc, <S4|Hso|T1,1,0,-1> (cm-1):         5.85744        4.14184        0.00012        4.14184
sum_soc, <S4|Hso|T1,1,0,-1> (cm-1):         5.85744        4.14184        0.00012        4.14184
sum_soc, <S4|Hso|T1,1,0,-1> (cm-1):         5.85744        4.14184        0.00012        4.14184
sum_soc, <S4|Hso|T1,1,0,-1> (cm-1):         5.85744        4.14184        0.00012        4.14184
sum_soc, <S4|Hso|T1,1,0,-1> (cm-1):         5.85744        4.14184        0.00012        4.14184
sum_soc, <S4|Hso|T1,1,0,-1> (cm-1):         5.85744        4.14184        0.00012        4.14184

This appears to be a bug in the fortran program, soc_td (rather than the python controller), so this would require someone who knows fortran to fix...

The issue fixed by V2 was related but separate to this issue

repo: oliver-s-lee/pysoc


text:
Emojis take three times the size of the regular tag on the same line

by activating the plugin, emojis take the height of about 3x the regular text on the same line in Preview Mode. In Editing mode it behaves as it should. No issues. Currently using Willemstad theme, but same behavior seen with other themes. This issue is different from the one that the images takes most of the screen, although I have also experienced that one.

Hi @aycajr - you can disable twitter emoji using the plugin settings for a quick fix. I will investigate why this is happening with this particular theme when I can.

@aycajr Hiya! Apologies for the late reply - I maintain Willemstad so I'm interested in trying to squash the issue you're having too. Would it be possible to let me know the steps to repro this? I can't seem to reproduce it on my end.

Hi! Any advice how to fix that? @oliveryh

Can I recommend that you use the plugin with Twitter Emoji setting turned off. I've turned this off by default now in v0.4.0
I haven't yet worked out how to reload the app when the settings are changed, but with this setting turned off you shouldn't see the strange behaviour mentioned above.

source: gharchive/issue

authors: aycajr oliveryh tavor118sn tingmelvin

repo: oliveryh/obsidian-emoji-toolbar

license_type: permissive

license_source: github-api


text:
Add a copy to clipboard button in the code section boxes

This is a minor feature request but it is a feature the Refact.ai guys put in their Jetbrains client that I found extremely useful.
All of the code segment boxes have a small copy to clipboard button in the top right had corner of the code window and it copies the contents to the clipboard.
I've seen the feature on a lot of websites so i'm guessing the behaviour is well supported by web browsers or at least easy to implement. It makes using any generated code segements and getting them into an editor very straight forward, and those are the sort of segments you want to cut and paste typically.
This seems like a straight forward feature, and it would greatly enhance the utility of the web-ui when asking it coding style questions.

Hi, Thanks for creating this issue! You should already have the copy code feature when served over either localhost or https!  With #216, Just added a fix to include the copy code button over http as well, so stay tuned!

authors: superversivesf tjbck

repo: ollama-webui/ollama-webui


text:
feat: hope to provide a widescreen display option

Is your feature request related to a problem? Please describe.
On my computer, there is so much white space on the right side of the chat screen that it can look odd, resulting in very little displayable content.
Describe the solution you'd like
Wish full use of screen space, instead of fixed showing part of the area.
Describe alternatives you've considered
If we don't modify the default chat width, perhaps we can provide an additional widescreen option to expand the chat display area on both sides, just like KeepChatGPT.
Additional context
ollama-webui

KeepChatGPT

You can now toggle the fullscreen mode option from Settings > Interface!

Great 😊

Please have a look, Full screen mode looks weird  https://github.com/ollama-webui/ollama-webui/issues/747

authors: tisfeng tjbck


text:
Replaced Ollama´s old .ai TLD with new .com TLD

Not long ago https://ollama.ai switched TLD to https://ollama.com. Adapted this change in code.

I guess .ai is getting expensive these days 😝

LGTM, Thanks!

source: gharchive/pull-request

authors: Arthur2500 justinh-rahb tjbck


text:
API useing

What is the issue?
I have a problem. When I call api/pull of the project, the background displays the following error, and no streaming response such as status is returned, because I want to get the real-time download progress. May I ask why I can download normally if I use the run model command in the servicetime=2024-05-09T10:03:13.104+08:00 level=INFO source=download.go:251 msg="00e1317cbf74 part 36 stalled; retrying. If this persists, press ctrl-c to exit, then 'ollama pull' to find a faster connection." time=2024-05-09T10:03:25.107+08:00 level=INFO source=download.go:251 msg="00e1317cbf74 part 14 stalled; retrying. If this persists, press ctrl-c to exit, then 'ollama pull' to find a faster connection." time=2024-05-09T10:03:35.106+08:00 level=INFO source=download.go:251 msg="00e1317cbf74 part 36 stalled; retrying. If this persists, press ctrl-c to exit, then 'ollama pull' to find a faster connection." [GIN] 2024/05/09 - 10:03:46 | 200 |    35.609442s |       127.0.0.1 | POST     "/api/pull"
OS
Windows
GPU
Nvidia
CPU
Intel
Ollama version
0.1.34

I have just tried again and can download but can not return real-time response, but a one-time stream response after downloading

Hi there, to pull in one request, use stream: false in /api/pull - let me know if that works!

repo: ollama/ollama

license: MIT


text:
somethings wrong with parameters

What is the issue?
/set parameter num_gpu 40
previous update it worked and made my model type faster but now it seems to not
OS
Windows
GPU
Nvidia
CPU
Intel
Ollama version
0.3.11

Server logs will aid in debugging.

sorry im retarded might have used another version as it seems fixed after updating again

authors: realkosmoss rick-github


text:
Feature Request: /embed support of images vector embedddings

It would be great to add support for models that are focused on image (or image+text) vector embeddings !

https://github.com/ollama/ollama/issues/5304

closing as dup #5304

authors: gwpl rick-github


text:
hello, please make changes to the Toolbox, when trying to patch SWDL, metainfo gave an error, thank you, Mst2_RoA_VW_ZR_P0359T, HW 35 Variant 17213, mail Sergey.sherengin@gmail.com

Please list which patching process showed the error (CP, SWAP, SWDL)

Please add your firmware-train like i.e. Mst2_RoA_VW_ZR_P0359T,
Attach the support-dump as .zip file
Go to Tools -> Dump necessary files to SD folder /dump/.../support and zip the support folder

Added in https://github.com/olli991/mib-std2-pq-zr-toolbox/archive/refs/heads/master.zip


text:
Connection not available. ThinQ platform not ready

I cannot connect and I got an error like this.

Can you help me?

This should be fixed with last version released (v0.10.5)

It works fine now. Thank you!

I'm having the same issue.


text:
🛑 MediaNet is down

In 642d300, MediaNet (https://medianet-pa.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: MediaNet is back up in 389c9f1.

repo: olmloa/upptime


text:
🛑 MediaNet is down

In 58cb49f, MediaNet (https://medianet-pa.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: MediaNet is back up in d7c473a.


text:
Help page "slowed down"

Firefox 65 x64
The page https://metroui.org.ua/input-material.html stops responding and a message appears asking if you want to block it or wait, since "browser operation is slowed down"
Ty

Thanks, fixed

authors: TorakikiSan olton

repo: olton/Metro-UI-CSS

license: mit

license_source: bigquery


text:
Fixes bug where partial pipelines from abandoned login attempts will be resumed …

…on new login attempts. This can happen with the email backend, which sends data directly to auth:complete, thereby bypassing the call to clean_partial_pipeline in do_auth.
More info:
During testing we ran into an issue with old session data from uncompleted email verifications sticking around while trying to login with other accounts. No matter what data you typed into the form, it would send you to a page saying a verification was sent to the email address inside the session's partial pipeline.
After looking through python-social-auth's code, I thought this was the best place to check that any new data, such as an email, matches what's in the current partial pipeline data; it seemed like the best place since it also verifies the backend names match.
Normally this isn't an issue since do_auth calls clean_partial_pipeline, but the email backend only works when you send data directly to the "complete" handler.

Good idea, thanks!

authors: SeanHayes omab

repo: omab/python-social-auth


text:
Data generation scripts mismatch the description in paper?

Thanks for your interesting work! I really appreciate it and am trying to reuse some datasets you provide. However, I notice that the scripts provided cannot generate datasets matching the description in your paper...
For example, in FEMNIST, the paper claims that there are 359 clients in total after sampling (Table 1), and "For all tasks, we randomly split each local dataset into training (60%), validation (20%) and test (20%) sets." (Section 4).
However, the readme under data/femnist says that I should use the command python generate_data.py --s_frac 0.2 --tr_frac 0.8 --seed 12345, which samples >700 tasks (clients), and each client has 80% data for training and 20% for testing without any validation data.
I guess that I should use something like python generate_data.py --s_frac 0.1 --tr_frac 0.8 --val_frac 0.25 --seed 12345?  (Still it does not match the description in the footnote of page 8 that "subsampled 15% from FEMNIST").
I haven't checked other datasets but seems EMNIST also uses --s_frac 0.2 (instead of 10% as claimed in the footnote) and does not include validation data.
Would you like to clarify how to generate the data used in this paper better? Many thanks!

Thanks for the interesting work! I am also trying to reuse some datasets from this paper and have the same question as @mengcz13.
I checked the EMNIST generated by the README script, which includes 130241/0/32610 samples for train/val/test set respectively, the total number is 20% of EMNIST and the partition ratio is 0.8:0:0.2.
The results mismatch the paper: "For all tasks, we randomly split each local dataset into training (60%), validation (20%) and test (20%) sets." (Section 4)." and "Total samples = 81425 for EMNIST" in Table 1.
Should I continue to use the default scripts to match the paper results of Table 2 and Table3? Could you please clarify how to generate the data used in this paper including all the other datasets? Many thanks!

Hello,
Thank you for the comments. Indeed the README file for the data generation process was not updated and does not match the paper.
For FEMNIST the command should be python generate_data.py --s_frac 0.15 --tr_frac 0.8 --val_frac 0.25 --seed 12345. This will result in 539 instead of 359 reported in the paper (I did a mistake while copying it). I also noticed that I was only reporting the number of the training samples for FEMNIST, while I was reporting the total number samples for other datasets. I will correct this on the camera-ready version.
For EMNIST the command should be python generate_data.py --s_frac 0.1 --tr_frac 0.8 --val_frac 0.25 --seed 12345. It leads to 48824/16274/16327 for train/val/test set respectively. (Note that 48824 + 16274 +16327 = 81425 as reported in Table~1)
I precise that the results in Table~2 are obtained using  the union of training and validation sets. The validation set was used to set the hyper-parameters (see the rebuttal).
I hope this answers your questions. Please let me know if I am missing something or if you notice some other inconsistencies.

authors: mengcz13 omarfoq yxdyc

repo: omarfoq/FedEM


text:
🛑 OME XSD schemas is down

In e3c84b8, OME XSD schemas (http://www.openmicroscopy.org/Schemas) was down:

HTTP code: 0
Response time: 0 ms

Resolved: OME XSD schemas is back up in 49348fd.

repo: ome/upptime


text:
The data.zip link runs into 404 error

Hi,
Thanks for your amazing work! We are currently preparing a new work, attempting to select your work Text2LIVE as a compared baseline. We will cite your paper as soon as ours is published.
While using your code, I found that the link to download data.zip is broken. Loading to the link website simply falls into 404 error. Do you have any alternative links to download data.zip? Looking forwards to your reply. You assistance will significantly help our work.
Best regards

Find a solution: down-load the weights from {another repo](https://github.com/text-video-edit/shape-aware-text-driven-layered-video-editing-release).


text:
Watcher UX: status after deleting IFE

scenario:

bob starts ife
nobody piggybacks, wait for first phase of challenge period to pass
call deleteNonPiggybackedInFlightExit on paymentExitGame contract
bob gets his bond back, ife is cleared, calling process exits confirms that no exits exist in the queue

issue:
status.get still shows the IFE. shouldn't the exit be cleared from the in_flight_exits array?
reference:
"One can call this to release the bond back to its owner and clean up the state of in-flight exit. "
https://github.com/omisego/plasma-contracts/blob/914b6ebf7897826872eb684db40db0081b4d3abb/plasma_framework/docs/integration-docs/integration-doc.md#delete-an-in-flight-exit

Additionally the watcher informs that deleted IFEs can be piggy backed.

Let's track in here pls. I think the gist of this here is tracking deleted state of an IFE which would suppress all the response data about this IFE:

piggyback available
in flight exit
invalid piggybacks
canonicity challenges required

I think this should be tackled in conjunction with #1318 - IFE being deleted should just be modeled explicitly as yet another state of an IFE.

authors: nicholasmueller pdobacz thec00n

repo: omisego/elixir-omg


text:
Watcher does not sync with Eth node

Observed locally and on development env.
To reproduce: Run Watcher, call /status.get and remember last_seen_eth_block_number
Call endpoint again, notice the value does not change.
After Watcher restart it will sync until the current block and won't get newer.
Suspected culprit #772

Issue caused by inappropriate parity configuration. It was run with --no-ws but EthereumClientMonitor listens to web socket events.
After removing above flag, there was log message in parity Blocked connection to WebSockets server with untrusted host: Some("localhost")
It was solved by adding --ws-hosts=all optition.

note after discussions: issue seems 2-fold at first glance:
1/ improve docs/geth & parity invocations/scripts what not to always sport the required flags
2/ figure out why did the inability to open the websocket conn fail tacitly

authors: pdobacz pnowosie


text:
feat: return rich syncing information from /status.get

On a couple of occasions we wished status.get returned richer information about the status the watcher's syncing is in.
Also, such information (like how old is the head of ethereum as seen by the watcher) is security-critical information - we're only secure and able to spend and use the child chain if we're fully up-to-date with ethereum.
So this is a proposition to put more stuff into the status.get response:
iex(30)> ~c(echo '{}' | http POST #{watcher_url}/status.get) |>  :os.cmd() |>  Poison.decode!()
%{
  "data" => %{
    "byzantine_events" => [],
!! NEW !! ===> "contract_addr" => "0x3c651506beb2ce64806f8fcf03522a211de19133",
    "eth_syncing" => false,
    "in_flight_exits" => [],
    "last_mined_child_block_number" => 1000,
    "last_mined_child_block_timestamp" => 1558535130,
!! NEW !! ===> "last_seen_eth_block_number" => 4427041,
!! NEW !! ===> "last_seen_eth_block_timestamp" => 1558535190,
    "last_validated_child_block_number" => 1000, !! NEW !! ===> "last_validated_child_block_timestamp" => 1558535130,
!! NEW !! ===> "services_synced_heights" => [
!! NEW !! ===> %{"height" => 4427041, "service" => "block_getter"},
!! NEW !! ===> %{"height" => 4427029, "service" => "challenges_responds_processor"},
!! NEW !! ===> %{"height" => 4427029, "service" => "competitor_processor"},
!! NEW !! ===> %{"height" => 4427031, "service" => "convenience_deposit_processor"},
!! NEW !! ===> %{"height" => 4427029, "service" => "convenience_exit_processor"},
!! NEW !! ===> %{"height" => 4427031, "service" => "depositor"},
!! NEW !! ===> %{"height" => 4427029, "service" => "exit_challenger"},
!! NEW !! ===> %{"height" => 4427029, "service" => "exit_finalizer"},
!! NEW !! ===> %{"height" => 4427029, "service" => "exit_processor"},
!! NEW !! ===> %{"height" => 4427029, "service" => "ife_exit_finalizer"},
!! NEW !! ===> %{"height" => 4427029, "service" => "in_flight_exit_processor"},
!! NEW !! ===> %{"height" => 4427029, "service" => "piggyback_challenges_processor"},
!! NEW !! ===> %{"height" => 4427029, "service" => "piggyback_processor"},
!! NEW !! ===> %{"height" => 4427041, "service" => "root_chain_height"}
    ]
  },
  "success" => true,
  "version" => "1.0"
}

As a related bonus, some more logs about syncing are now being displayed on application startup

Coverage decreased (-0.09%) to 81.514% when pulling 662e4c4f7b1519991a3b73da2caf0cdd5a115da5 on enrich_status_get_with_syncing_info into ed2e600cd70a9e9c6fe99be57f0ac1c6bdd7fb2a on master.

authors: coveralls pdobacz


text:
Problem: h2o_fatal calls abort() by default and cannot be overridden

Solution: h2o newly supports overriding the h2o_fatal error handler by expanding to a function pointer call. Update the h2o version so that omnigres can take advantage of this recent change.
Also update the h2o_quic_init_context call in omni_httpc, whose prototype was recently changed to include a new argument, whose value in omnigres is now NULL (#211)
I'm not sure if this PR is a solution to #211, since it does not itself overload the h2o_fatal handler, it only makes it possible. This is because the comments of #211 are ambivalent on what the overload should do.

It appears that there's a problem with the change in h2o on macOS/clang:
/Users/runner/_work/omnigres/omnigres/cpm_modules/h2o/4a28805e2ec67783767fc04cf4201af69a683c42/include/h2o/memory.h:187:8: error: '_Noreturn' can only appear on functions
extern H2O_NORETURN void (*h2o__fatal)(const char *file, int line, const char *msg, ...) __attribute__((format(printf, 3, 4)));
       ^
/Users/runner/_work/omnigres/omnigres/cpm_modules/h2o/4a28805e2ec67783767fc04cf4201af69a683c42/include/h2o/memory.h:58:22: note: expanded from macro 'H2O_NORETURN'
#define H2O_NORETURN _Noreturn

Not sure what we can do about that.

authors: mthom yrashk

repo: omnigres/omnigres


text:
Set minimum NumPy to 1.14

For pyarrow 0.11.0 and Python 3.7, the minimum NumPy version is 1.14. Feels like we should do the same, if only to keep an oddball scenario from happening. This will also silence the warning we get during build about no NumPy version being set during build.
https://github.com/apache/arrow/blob/master/python/requirements.txt#L4

Duplicate to #119 at this point

repo: omnisci/pymapd


text:
Update for Nim v0.19.0

Also maybe bump version to 0.6.0?

Might be time to fork this, AFAIK @onecodex aren't maintaining this anymore (but maybe @boydgreenfield can correct me :)).

If you telling me to do it, I'm sorry, but I don't really know how. I mean, I've already forked it, but what next? Should I change url in nim-lang/packages to my fork or what? (I'm really sorry to bother you, but I'm kinda new to contributing to github)

@silent-observer @dom96 Thanks. Merged and pinning a 0.6.0 release!

authors: boydgreenfield dom96 silent-observer

repo: onecodex/nim-bitarray


text:
Non-require idp cert on security implicit disabled

For configuration like:
["security"]=>
  array(8) {
    ["nameIdEncrypted"]=>
    bool(false)
    ["authnRequestsSigned"]=>
    bool(false)
    ["logoutRequestSigned"]=>
    bool(false)
    ["logoutResponseSigned"]=>
    bool(false)
    ["wantMessagesSigned"]=>
    bool(false)
    ["wantAssertionsEncrypted"]=>
    bool(false)
    ["wantAssertionsSigned"]=>
    bool(false)
    ["wantNameIdEncrypted"]=>
    bool(false)
  }

there is no reason to require idp cert.
I have no clue about PHP-SAML. I'm just trying to run SAML in Zabbix and I ran into this potential problem.

In fact you found something, the IdP cert should be required always, toolkit always may validate the signature of the SAML response.

authors: ad-m pitbulk

repo: onelogin/php-saml


text:
PKG -- [FCL-WC] Add notifications for pending WC/RPC requests

Closes #1969
Closes #1979
This PR adds notifications indicating that there is a pending request on the user's mobile wallet.  On mobile, clicking on the notification will open the deeplink to the user's wallet.
Decision to use preact (lightweight ~4kb React implementation) and tailwind was based on maintaining consistency throughout Flow's projects and anticipating future scope (react/react-dom is just too heavy to justify here).  It's definitely overkill and this could have been written with vanilla JavaScript or a lightweight templating engine like lit-html.  It would be very trivial to swap this out for an alternative, so please leave feedback if there are any concerns here.
Mobile Light Mode:

Mobile Dark Mode:

Desktop Light Mode:

Desktop Dark Mode:

It might be nice if the wallet can turn the notifications off if they have their own push notification system they want to use instead.

authors: chasefleming jribbink

repo: onflow/fcl-js


text:
Library on maven central

Hey!
Any reason this is not on Maven central? Importing and maintaining a library not in a central repository is a pain in the ass.
Since this library is linked from the README of PhotoView, I'm sure a lot of people would find this easier to use too. 🙂
Anyway thanks for the project!

+1
Or, even on jitpack?

I think this is depend on Fresco. But Fresco update frequently.
People who like to use this module can easily import it into project and choose Fresco version.
Besides, this module is only support "CENTER" scale type.

@ongakuer I believe it's still possible to choose the Fresco version you want to use by specifying one higher than what the library currently uses. Besides maybe releasing it on a maven/jitpack will bring more people interested in the project that will work on updating Fresco regularly.

Also want to do this -- How about forking it and then creating a library

Well, I will publish soon.

dependencies {
    compile 'com.facebook.fresco:fresco:0.10.0'
    compile 'me.relex:photodraweeview:1.0.0@aar'
}

Thanks a lot @ongakuer !

authors: Bhullnatik milkrun ongakuer xsorifc28

repo: ongakuer/PhotoDraweeView


text:
Fix typo

PR created using https://github.com/tbroadley/github-spellcheck-cli.

Thanks @tbroadley ! Cool tool 👍
And thanks @TalAmuyal and @CrossR for looking at the build - looks like it green now, bringing it in.

authors: bryphe tbroadley

repo: onivim/oni


text:
Program starts halfway between two screens

I have a 3 screen setup; 2 monitors and laptop screen. Onivim continually opens across one monitor and the laptop screen. I've tried all sorts of usual fixes for programs opening offscreen but nothing sticks. Any ideas?
Windows 10 Pro
Lenovo ThinkPad
BenQ monitors
Onivim v 0.5.2007

Hi @nathanjwtx ,
It sounds like we might be persisting incorrect window coordinates - when the window moves, we store the position and size in the %LocalAppData%/Oni2/store folder (for example - mine is C:/Users/Bryan/AppData/Local/Oni2/store - you could try renaming or delete that folder to see if that's the issue.
It'd be interesting to see if it still opens in the wrong spot after doing that.
I'd be curious as well - how are you opening Onivim? Is it via the terminal, or start menu?

Hi @bryphe
I tried deleting the folder as suggested but it still opens as before; half on screen 2 (monitor) and half on screen 1 (laptop).
I am opening it from the Start Menu.

It also doesn't remember the previous app window size.

Let me also chime in on this as well! I have the same issue, but even further, when I maximize Oni it spreads beyond (albeit ever-so-slightly) beyond the screen it's on.  I'm posting here instead of a separate thread since it might be related.
Here is a screen shot. It is a bit difficult to see, but if you look at the edges of Oni you'll see where it spills over onto the other displays.

I get that too. Looks like a thin white line on the edge of the other screen.

Related issue: #1893

authors: Apostolique bryphe lemerchand nathanjwtx


text:
自制谷歌学术hosts

持续维护的hosts项目
https://github.com/googlehosts

在线ping https://www.ipip.net/ping.php

修改hosts  C:\Windows\System32\drivers\etc\hosts

添加直连规则

仅供参考
#scholar
172.217.24.4 scholar.google.com
172.217.24.100 scholar.google.com
172.217.25.68 scholar.google.com
172.217.25.228 scholar.google.com
172.217.24.36 scholar.google.com
216.58.199.4 scholar.google.com
216.58.221.228 scholar.google.com
108.177.97.103 scholar.google.com
216.58.199.4 scholar.google.com
216.58.221.132 scholar.google.com
216.58.200.4 scholar.google.com
172.217.27.132 scholar.google.com
216.58.200.36 scholar.google.com
172.217.25.132 scholar.google.com

部分梯子访问不了谷歌学术，可以自己做一个靠谱的hosts
https://github.com/XX-net/XX-Net/issues/6852
https://github.com/XX-net/XX-Net/issues/6870

@onplus 不会添加直连规则，可否给个教程

@chenzijng
自动切换模式下，点击switchyomega小圆圈，添加条件

把scholar.google.com设置为直接连接后，依然会使用代理啊，然后会弹出Sorry等字样

@ikkyusan123
“设置为直接连接后，依然会使用代理”，没正确设置和使用switchyomega
有没有其他的代理开着？

没有啊

贴一下switchyomega的规则列表截图

和你的截图一样设置的

这个界面截出来

最新可用hosts
172.245.241.129 scholar.google.com
172.245.241.129 scholar.google.com.hk
172.245.241.129 scholar.google.com.tw
172.245.241.129 scholar.googleusercontent.com

authors: AssICan chenzijng ikkyusan123 onplus

repo: onplus/shadowsocks-heroku


text:
Update Kubernetes manifest files for CodeGen

Description
Updated Kubernetes manifest files for CodeGen to reflect latest changes:

upgrade tgi/tgi-gaudi image version

align model with docker version CodeGen

Issues
n/a.
Type of change
List the type of change like below. Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)

Dependencies
n/a.
Tests
Describe the tests that you ran to verify your changes.

In this PR, we don't change any GMC related stuff, so the GMC test should not be launched. I believe that the failure it happens to catch should be covered in another GMC PR.

repo: opea-project/GenAIExamples


text:
The makefile command make images not work

Is this make images out of date? Should we remove it? It could cause some confusion here.
https://github.com/open-cluster-management-io/cluster-proxy/blob/b0c66d3772d692c6b1bd8dc42eaf00f119c501fa/Makefile#L137

/assign @yue9944882

make images is now removed, closing
/close


text:
Update security md to refer to the OCM community security md file.

Signed-off-by: Mike Ng ming@redhat.com

/approve
/lgtm


text:
New repo: addon-contrib

To create a new repo named addon-contrib for hosting the open-telemetry addon which is an outcome of the OSPP summer camp project:
https://summer-ospp.ac.cn/#/org/orgdetail/139c2402-194c-42a0-95e9-ab23885384cb/
/assign @qiujian16

/cc @mikeshng

Should we use the name open-telemetry-addon to better reflect the content of the repo?

I think the intention is to host multiple addons in this repo that are not quite mature yet.

/close

repo: open-cluster-management-io/community


text:
update readme & makefile

Signed-off-by: Yang Le yangle@redhat.com

/assign @qiujian16

repo: open-cluster-management-io/placement


text:
update addon api

Signed-off-by: liuwei liuweixa@redhat.com

/assign @qiujian16

/approve
/lgtm

/retest

/retest

/retest


text:
Review测评指标失真，Qwen被严重低估了

teval.evaluators.review_evaluator.py代码中，根据“:”(英文半角符判断答案)，但是测试样本中的的指令却是“Answer：”（中文全角符）。Qwen1.5-14B-Chat的大多数结果都是"Answer：A"、"Answer：B"、"Answer：C"...这样的。根据下面的代码，截取出来的结果就是“Answer”的第一字符“A”。也就是说Review指标上Qwen1.5-14B-Chat 基本都是A，与事实不符。这样写死的判断代码，测出的结果失真。
代码：
pred_data = pred_data[pred_data.find(":") + 1:]
pred_data = pred_data.strip()
if len(pred_data) > 0 and pred_data[0] in ['A', 'B', 'C', 'D', 'E']:
测试样本指令：“你的输出应遵循以下格式：\n```\nAnswer：[在此处插入你的选择，从A、B、C、D和E中选择。这应该是一个字符。]\”

感谢您指出问题，我们将会在下一版数据中fix这个问题

repo: open-compass/T-Eval


text:
Request Support for VILA

Thanks for open-sourcing the framework
One of the LMMs which has been doing great work and has been iterating their models is VILA : https://github.com/NVlabs/VILA
It would be great to add the support for the same

If its okay I can work on a the PR to integrate the same @junming-yang @kennymckormick ?

Hi, @amitbcp. Thanks for your work to support the VILA model. Please don't hesitate to contact us if you need any help.

Sure will try to wrap it within this week !!

Thanks for your contribution. VILA is supported now!

authors: amitbcp junming-yang

repo: open-compass/VLMEvalKit


text:
Methodology CSS

The methodology section has:

No bottom margin for p tags
No margin-left for li tags

As a result, it looks really bad: https://open-contracting.health/country/paraguay/methodology

cc @VTarnay1

Fixed in https://github.com/open-contracting/covid-19-procurement-explorer-public/pull/306


text:
Register it2.localplayer.dev

Added it2.localplayer.dev using the CLI.

CLA Assistant Lite bot: Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

I have read the CLA Document and I hereby sign the CLA

You can retrigger this bot by commenting recheck in this Pull Request

authors: Mengoya OD-BOT

repo: open-domains/register


text:
Error when loading samples: 'could not broadcast input array from shape (38370304,) into shape (38371328,)'

Hi,
I think something has gone wrong with my data acquisition at some point and a bunch of my files are giving this error when I try and load the samples:
Traceback (most recent call last):
  File "Y:\Behaviour code\2407_July_WT_cohort\Analysis\NAP\July_cohort_scripts\analysis_manager.py", line 36, in __init__
    self.ingest_behaviour_data()
  File "Y:\Behaviour code\2407_July_WT_cohort\Analysis\NAP\July_cohort_scripts\analysis_manager.py", line 83, in ingest_behaviour_data
    self.OEAB_data = process_ADC_Recordings(self.OEAB_folder, self.rig_id)
  File "Y:\Behaviour code\2407_July_WT_cohort\Analysis\NAP\July_cohort_scripts\Preliminary_analysis_scripts\process_ADC_recordings.py", line 28, in __init__
    self.extract_ADC_data()
  File "Y:\Behaviour code\2407_July_WT_cohort\Analysis\NAP\July_cohort_scripts\Preliminary_analysis_scripts\process_ADC_recordings.py", line 36, in extract_ADC_data
    self.samples = self.recording.samples   # raw samples, not in microvolts
  File "C:\Users\Public\.conda\July_cohort\lib\site-packages\open_ephys\analysis\formats\OpenEphysRecording.py", line 92, in samples
    self._load_samples()
  File "C:\Users\Public\.conda\July_cohort\lib\site-packages\open_ephys\analysis\formats\OpenEphysRecording.py", line 200, in _load_samples
    self._samples[:,channel_idx] = samples
ValueError: could not broadcast input array from shape (38370304,) into shape (38371328,)

I am just wondering if this is something that can be fixed to salvage the data? I'm not exactly sure what the issue at the time was, but I was having some issues with the recording buffer overflowing and causing a stop in the recording.
Thanks for any help you can give,
Stefan

Hi,
An overflow can prevent the buffer from flushing completely before closing the file. Assuming that's the only issue, all but the last few ms should be recoverable.
If you can send a link to one of these recordings to pavel@open-ephys.org I can confirm the failure mode and send back a script to load the data.

repo: open-ephys/open-ephys-python-tools


text:
增加多种插件输出格式支持

现在的插件只支持输出 json 数组这一种格式，这在用 shell 编写插件时会比较麻烦，所以增加了几种输出格式的支持。新版本插件支持以下的输出格式(2,3 格式可以混用):

插件整体输出 json 数组
插件一行输出一个 json 对象
插件一行输出一个以空格分隔的监控指标, 可选格式:

metric value
metric tag1=v1,tag2=v2 value
metric tag1=v1,tag2=v2 value timestamp
metric value timestamp

更详细的格式示例参见: modules/agent/plugins/scheduler_test.go

感觉程序自动去判断返回结构可能会有一些坑，例如它意外的正好符合了某种切分机制，但实际上与业务的真实目的不一样。
想跟大家再讨论下。

@MistShi +1 :)

感觉程序自动去判断返回结构可能会有一些坑，例如它意外的正好符合了某种切分机制，但实际上与业务的真实目的不一样。
想跟大家再讨论下。

想到两个方案来避免这样的情况:

需要解析为 metric 输出的纯文本行增加一个前缀，比如: #falcon-metric agent.alive 1
启动插件时打开一个新的 fd，往这个 fd 写入的数据才会使用新的解析方案，该 fd 值可以固定为 3
STDOUT 输出的方式依然兼容，两个输出流的数据都会尝试进行解析

@laiwei @MistShi

authors: MistShi jinxingxing laiwei

repo: open-falcon/falcon-plus


text:
chore: move packaging & isolate service implementations

This PR
Background
This is an attempt to move services and wiring logic to their end usage.
For example,  having runtime package in the core module did not provide any advantage. This package was only used by flagd and contained the logic that binds configurations to service implementations.
Similarly, flagd-proxy exposed sync service, and having that inside the core module seemed out of place.
What's changed
I have moved runtime package to flagd & specific service implementations (flag evaluation and sync service) to their end usage.
Why ?
I considered this to be a pre-requisite for https://github.com/open-feature/flagd/issues/1230. If I attempted to add another sync implementation to the current core module, it would have made the whole packaging confusing (ex:- we have two sync proto implementations, which do not serve the same purpose. One for flagd-proxy and the other for flagd).
After this refactoring, I could add the flagd's sync service, where it serve buf connect and I can locate that within flagd.
Besides, we still have a core module with all the sharables.
Consider the current packaging in the below diagram,

nore - core sync is for flag data sync listeners such as files, K8s ...

Thank you for the reviews @toddbaert @odubajDT @thisthat , I will merge this now :)

repo: open-feature/flagd


text:
chore: bump flagd-testbed version

This PR

bumps the flagd-testbed version

This is outdated so will close

repo: open-feature/go-sdk-contrib


text:
feat: add flag metadata

This PR
Is connected to #437 & completes the implementation of flag metadata spec implementation [1]
The implementation is backed by immutable FlagMetadata. If present, metadata gets propagated from ProviderEvaluation to FlagEvaluationDetails
Tests were added to validate the construction as well as the propagation
[1] - https://github.com/open-feature/spec/commit/74c373e089ad77bf8cac84f3d93c00c945ff3a8a

@Kavindu-Dodan this all looks good to me, except that I'm not sure about throwing on failed retrieval.
This seems like a typical eventuality, not an exceptional one.

@Kavindu-Dodan this all looks good to me, except that I'm not sure about throwing on failed retrieval.
This seems like a typical eventuality, not an exceptional one.

Updated the implementation to avoid exceptions. Instead now we return null for missing key & value type differences , along with debug level log entry

@Kavindu-Dodan I rebased on main and resolved conflicts with @lopitz 's recent PR. I hope you don't mind. This looks good to me, and we have lots of approvals so I'm merging.

authors: Kavindu-Dodan toddbaert

repo: open-feature/java-sdk


text:
Add Network Performance to EC2 Basics

Added one line bullet to EC2 Basics on what Low, Medium, High network performance can mean, based on a Stack Overflow user's benchmarking. I think this is better in EC2 Basics than EC2 Tips, but don'tr have strong feelings if there's disagreement.
Network performance probably needs more coverage, possibly its own section.

LGTM - good addition, thanks @rjhintz!

@max-zanko @ThanosBaskous   Thanks for the quick reviews

authors: ThanosBaskous rjhintz

repo: open-guides/og-aws


text:
Schema description by a human user reported again and again as made by ingestion-bot

Hello!
Affected module
Probably ingestion or OMeta API.
Describe the bug
When a schema is created via a metadata ingestion and then edited by a human user having a description added, this change is reported in notifications each time the metadata ingestion runs, but as if description has been added by ingestion-bot.

When the description is first added, it's reported correctly at once as made by the user.
Later every time it's reported as Added by ingestion bot.
If the user deletes (clears) this description, it's reported at once as Added empty by the user.
Next time the ingestion job runs, it's reported as Deleted byt the ingestion-bot.
Later it's not reported in any way.

Version history of the entity is correct - the description is stated as added once and deleted both times by the user. Checked both on a schema with tables and an empty one. We have a notification for all changes in all entities to email. We use Oracle as the database source. OpenMetadata is version 1.4.2 both the application and the ingestion/apis packages.
To Reproduce

Create a notification to email for all changes in all entity types.
Run a metadata ingestion that would create a schema.
Log in as a human user and add description manually, - you get a notification of added description by the user.
Run the ingestion several times, - you should get a notification of a change by ingestion-bot each time.
Delete the description manually, - you get a notification as added empty description.
Run the ingestion, - you should get a notification as deleted by ingestion-bot only once.

Expected behavior
After adding the description, notification only comes once as added by the user, and not by the bot.
After clearing the description, notification only comes once as deleted by the user, and not by the bot.
Version:

OS: Oracle Linux 8
Python version: 3.9
OpenMetadata version: 1.4.2
OpenMetadata Ingestion package version: 1.4.2.0

Additional context
Airflow 2.6.3
'Bare metal' type of installation. Source is Oracle database.

hi @teabbs , this has been fixed here https://github.com/open-metadata/OpenMetadata/pull/17087

repo: open-metadata/OpenMetadata


text:
Permanent delete option after soft deleting the team is not available.

Affected module
Team
Describe the bug

@aniketkatkar97, Reverify the issue and if it is fixed close this ticket.

@aniketkatkar97 Add Cypress tests for the same


text:
CUDA error: too many resources requested for launch

I want to use OpenPCDet v0.3 on a NVIDIA Jetson TX2 with the following specifications:
Ubuntu 18.04
JetPack 4.4
CUDA 10.2
CuDNN 8.0
Python 3.6.9
pytorch 1.6.0
spconv 1.2.1
All the 3D object detection methods which relies on spconv (SECOND, PartA2 etc.) failed due to a CUDA error RuntimeError: CUDA error: too many resources requested for launch. The other methods, like PointRCNN or PointPillars worked properly. Does anyone know how to solve this issue?
Thanks
Traceback (most recent call last):
  File "extract_bb.py", line 146, in <module>
    main()
  File "extract_bb.py", line 116, in main
    pred_dicts, _ = model.forward(data_dict)
  File "/home/nvidia/MTh_meyj/Software/OpenPCDet/pcdet/models/detectors/voxel_rcnn.py", line 11, in forward
    batch_dict = cur_module(batch_dict)
  File "/home/nvidia/.local/lib/python3.6/site-packages/torch/nn/modules/module.py", line 722, in _call_impl
    result = self.forward(*input, **kwargs)
  File "/home/nvidia/MTh_meyj/Software/OpenPCDet/pcdet/models/backbones_3d/spconv_backbone.py", line 147, in forward
    x = self.conv_input(input_sp_tensor)
  File "/home/nvidia/.local/lib/python3.6/site-packages/torch/nn/modules/module.py", line 722, in _call_impl
    result = self.forward(*input, **kwargs)
  File "/home/nvidia/.local/lib/python3.6/site-packages/spconv/modules.py", line 134, in forward
    input = module(input)
  File "/home/nvidia/.local/lib/python3.6/site-packages/torch/nn/modules/module.py", line 722, in _call_impl
    result = self.forward(*input, **kwargs)
  File "/home/nvidia/.local/lib/python3.6/site-packages/spconv/conv.py", line 199, in forward
    outids.shape[0], self.algo)
  File "/home/nvidia/.local/lib/python3.6/site-packages/spconv/functional.py", line 94, in forward
    algo=algo)
  File "/home/nvidia/.local/lib/python3.6/site-packages/spconv/ops.py", line 120, in indice_conv
    int(inverse), int(subm), algo)
RuntimeError: CUDA error: too many resources requested for launch

For the solution, see this Issue.
https://github.com/traveller59/spconv/issues/362

repo: open-mmlab/OpenPCDet


text:
SpCL Train_step的问题

您好，想问下您这里id是否代表label.还想问下ind代表什么.
麻烦您啦!

你好，id代表label，ind代表该image在dataset里的位置（index）

repo: open-mmlab/OpenUnReID


text:
semantic branch of HTC

Hi. My understanding is that when doing evaluation/test, semantic branch is ignored in terms of IOU and accuracy calculation. Only in the training process it contributes to the loss calculation. Is it right?

Yes.

authors: Shi-Xiaoyu ZwwWayne

repo: open-mmlab/mmdetection


text:
is mmdetection memory management inefficient?

I tried to port retinaface (https://github.com/biubug6/Pytorch_Retinaface) to mmdetection.
with GTX-1080 Ti * 4,  I can only set samples_per_gpu to 6 when training with mmdetection.
However, in the same network, I can set samples_per_gpu to 32 when training with the original retinaface.
is the memory management in mmdetection inefficient?

Hi @twmht, I'm not familiar with retinaface and I'm sorry I cann't give you useful suggestions yet.

authors: twmht v-qjqs


text:
RuntimeError: operation does not have an identity.

Describe the bug
I have trained the DetectorRS model for a while , but during the time , it happened "RuntimeError: operation does not have an identity.".
Reproduction
Before i met this error, I was running this command :"nohup python tools/train.py ./configs/detectors/detectors_htc_r50_1x_coco.py --work-dir ./detectors_train_test_res"
I haven not modified your code, and the dataset is coco2017.
environment
sys.platform: linux
Python: 3.7.10 (default, Feb 26 2021, 18:47:35) [GCC 7.3.0]
CUDA available: True
GPU 0: GeForce RTX 2080 Ti
GPU 1: GeForce RTX 2060 SUPER
CUDA_HOME: /usr/local/cuda
NVCC: Cuda compilation tools, release 10.0, V10.0.130
GCC: gcc (Ubuntu 7.5.0-6ubuntu2) 7.5.0
PyTorch: 1.7.1
PyTorch compiling details: PyTorch built with:

GCC 7.3
C++ Version: 201402
Intel(R) oneAPI Math Kernel Library Version 2021.2-Product Build 20210312 for Intel(R) 64 architecture applications
Intel(R) MKL-DNN v1.6.0 (Git Hash 5ef631a030a6f73131c77892041042805a06064f)
OpenMP 201511 (a.k.a. OpenMP 4.5)
NNPACK is enabled
CPU capability usage: AVX2
CUDA Runtime 11.0
NVCC architecture flags: -gencode;arch=compute_37,code=sm_37;-gencode;arch=compute_50,code=sm_50;-gencode;arch=compute_60,code=sm_60;-gencode;arch=compute_61,code=sm_61;-gencode;arch=compute_70,code=sm_70;-gencode;arch=compute_75,code=sm_75;-gencode;arch=compute_80,code=sm_80;-gencode;arch=compute_37,code=compute_37
CuDNN 8.0.5
Magma 2.5.2
Build settings: BLAS=MKL, BUILD_TYPE=Release, CXX_FLAGS= -Wno-deprecated -fvisibility-inlines-hidden -DUSE_PTHREADPOOL -fopenmp -DNDEBUG -DUSE_FBGEMM -DUSE_QNNPACK -DUSE_PYTORCH_QNNPACK -DUSE_XNNPACK -DUSE_VULKAN_WRAPPER -O2 -fPIC -Wno-narrowing -Wall -Wextra -Werror=return-type -Wno-missing-field-initializers -Wno-type-limits -Wno-array-bounds -Wno-unknown-pragmas -Wno-sign-compare -Wno-unused-parameter -Wno-unused-variable -Wno-unused-function -Wno-unused-result -Wno-unused-local-typedefs -Wno-strict-overflow -Wno-strict-aliasing -Wno-error=deprecated-declarations -Wno-stringop-overflow -Wno-psabi -Wno-error=pedantic -Wno-error=redundant-decls -Wno-error=old-style-cast -fdiagnostics-color=always -faligned-new -Wno-unused-but-set-variable -Wno-maybe-uninitialized -fno-math-errno -fno-trapping-math -Werror=format -Wno-stringop-overflow, PERF_WITH_AVX=1, PERF_WITH_AVX2=1, PERF_WITH_AVX512=1, USE_CUDA=ON, USE_EXCEPTION_PTR=1, USE_GFLAGS=OFF, USE_GLOG=OFF, USE_MKL=ON, USE_MKLDNN=ON, USE_MPI=OFF, USE_NCCL=ON, USE_NNPACK=ON, USE_OPENMP=ON,

TorchVision: 0.8.2
OpenCV: 4.5.2
MMCV: 1.3.3
MMCV Compiler: GCC 7.3
MMCV CUDA Compiler: 11.0
MMDetection: 2.13.0+a8c681d
Error traceback
Traceback (most recent call last):
File "tools/train.py", line 188, in
main()
File "tools/train.py", line 184, in main
meta=meta)
File "/home/ubuntu/Desktop/work/Users/smellycat/mmdetection/mmdet/apis/train.py", line 170, in train_detector
runner.run(data_loaders, cfg.workflow)
File "/home/ubuntu/anaconda3/envs/open-mmlab/lib/python3.7/site-packages/mmcv/runner/epoch_based_runner.py", line 125, in run
epoch_runner(data_loaders[i], **kwargs)
File "/home/ubuntu/anaconda3/envs/open-mmlab/lib/python3.7/site-packages/mmcv/runner/epoch_based_runner.py", line 50, in train
self.run_iter(data_batch, train_mode=True, **kwargs)
File "/home/ubuntu/anaconda3/envs/open-mmlab/lib/python3.7/site-packages/mmcv/runner/epoch_based_runner.py", line 30, in run_iter
**kwargs)
File "/home/ubuntu/anaconda3/envs/open-mmlab/lib/python3.7/site-packages/mmcv/parallel/data_parallel.py", line 67, in train_step
return self.module.train_step(*inputs[0], **kwargs[0])
File "/home/ubuntu/Desktop/work/Users/smellycat/mmdetection/mmdet/models/detectors/base.py", line 237, in train_step
losses = self(**data)
File "/home/ubuntu/anaconda3/envs/open-mmlab/lib/python3.7/site-packages/torch/nn/modules/module.py", line 727, in _call_impl
result = self.forward(*input, **kwargs)
File "/home/ubuntu/anaconda3/envs/open-mmlab/lib/python3.7/site-packages/mmcv/runner/fp16_utils.py", line 95, in new_func
return old_func(*args, **kwargs)
File "/home/ubuntu/Desktop/work/Users/smellycat/mmdetection/mmdet/models/detectors/base.py", line 171, in forward
return self.forward_train(img, img_metas, **kwargs)
File "/home/ubuntu/Desktop/work/Users/smellycat/mmdetection/mmdet/models/detectors/two_stage.py", line 135, in forward_train
proposal_cfg=proposal_cfg)
File "/home/ubuntu/Desktop/work/Users/smellycat/mmdetection/mmdet/models/dense_heads/base_dense_head.py", line 58, in forward_train
proposal_list = self.get_bboxes(*outs, img_metas, cfg=proposal_cfg)
File "/home/ubuntu/anaconda3/envs/open-mmlab/lib/python3.7/site-packages/mmcv/runner/fp16_utils.py", line 182, in new_func
return old_func(*args, **kwargs)
File "/home/ubuntu/Desktop/work/Users/smellycat/mmdetection/mmdet/models/dense_heads/anchor_head.py", line 580, in get_bboxes
scale_factors, cfg, rescale)
File "/home/ubuntu/Desktop/work/Users/smellycat/mmdetection/mmdet/models/dense_heads/rpn_head.py", line 185, in _get_bboxes
cfg.nms)
File "/home/ubuntu/anaconda3/envs/open-mmlab/lib/python3.7/site-packages/mmcv/ops/nms.py", line 268, in batched_nms
max_coordinate = boxes.max()
RuntimeError: operation does not have an identity.
what should I do if I want to continue running ? please tell me more details (I am totally a newbie:(
thank you!

This error seems boxes value is empty.

@SmellyBear333
What command or script did you run?
Did you make any modifications on the code or config? Did you understand what you have modified?
What dataset did you use?

@SmellyBear333
What command or script did you run?
Did you make any modifications on the code or config? Did you understand what you have modified?
What dataset did you use?

I ran this command:nohup python tools/train.py ./configs/detectors/detectors_htc_r50_1x_coco.py --work-dir ./detectors_train_test_res"
I have not modified your code, and the dataset is coco2017.(the one contains stuffthingmaps)

This error seems boxes value is empty.

yes,so yesterday i tried to modified the 155 lines "nms=dict(type='nms', iou_threshold=0.7)," into "nms=dict(type='nms', iou_threshold=0.4),",which in the "mmdetection/configs/htc/htc.without_semantic_r50_fpn_1x_coco.py" . then it continue running for about 20hours,but today in the morning, it say "RuntimeError: operation does not have an identity."again and it stopped again :(

It seems the same error, you can refer to #5211

It seems the same error, you can refer to #5211

Thanks for your advise! then what could i do before @hhaAndroid fixed it in the DetectoRS ?

@SmellyBear333
What command or script did you run?
Did you make any modifications on the code or config? Did you understand what you have modified?
What dataset did you use?

oh,sorry I fogot that I modified the configs "lr=0.02"into"lr=0.01",which is in the "mmdetection/configs/base/schedules/schedule_1x.py".
and I modified "samples_per_gpu=2,workers_per_gpu=2" into"samples_per_gpu=1,workers_per_gpu=1",which is in the line 32 and 33 in "configs/base/datasets/coco_detection.py".
These modification just for take down the batchsize and learning rate to match.
Looking forward to your reply ! Thank u !

@SmellyBear333 maybe you can upgrade MMDetection and MMCV first. I think that we have already fixed this bug.

@SmellyBear333 maybe you can upgrade MMDetection and MMCV first. I think that we have already fixed this bug.
I git pull the latest mmdetection code , and I trained again ,but in this morning ,it turns out "RuntimeError: operation does not have an identity."again.maybe @hhaAndroid have not fixed this bug . pleaseeeee help me get out of this Error :( thanks a lot

@SmellyBear333 maybe you can upgrade MMDetection and MMCV first. I think that we have already fixed this bug.

I git pull the latest mmdetection code , and I trained again ,but in this morning ,it turns out "RuntimeError: operation does not have an identity."again.maybe @hhaAndroid have not fixed this bug . pleaseeeee help me get out of this Error :( thanks a lot

Please make sure you have updated MMdet and MMCV

Please make sure you have updated MMdet and MMCV

According to running the command"python mmdet/utils/collect_env.py",my MMdet version is 2.13.0+a8c681d and my MMCV version is 1.3.3.
Are these the latest versions ? If not, How could I update them ?


text:
在mmdetection中怎样以一定概率使用mosic

我希望用上mosaic，但是不希望全部数据都用它，而是希望以一定概率来决定是否使用该操作，请问有简单的实现方式吗？

I want to use mosaic, but I don't want to use it for all data, but I want to decide whether to use this operation with a certain probability. Is there a simple way to implement it?


text:
the rotation bug in visualization

Hi, when I running the demo
python demo/pcd_demo.py demo/data/kitti/kitti_000008.bin configs/second/hv_second_secfpn_6x8_80e_kitti-3d-car.py checkpoints/hv_second_secfpn_6x8_80e_kitti-3d-car_20200620_230238-393f000c.pth,
I found that the predicted 3d bboxes are not matched with original points

In addition, I tried to vis the detection results with meshlab by adding point.obj and pred.obj files. I just wondering that whether the results are matched? Because the bboxes seem donot contain reasonable car shape ...

https://github.com/open-mmlab/mmdetection3d/issues/1287#issuecomment-1184239720
The same issue

Duplicate with #1287 . We will discuss it here and try to fix it ASAP.

authors: SakuraRiven Tai-Wang


text:
[Feature] added indices option for KittiMetric to evaluate on a subset

Motivation
Evaluating on a subset of the Kitti Dataset
Modification

Added indices parameter to KittiMetric and evaluated only using those indices
Note: I haven't modified any of the other metrics since they seem to be loading data differently and I am not entirely sure whether that feature is required for other dataset
Note: the corresponding dataloader should be set with the same indices for the code to work as expected

Use cases (Optional)
Debugging, overfitting on x examples and only using a subset for evaluation in general.
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.
The documentation has been modified accordingly, like docstring or example tutorials.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Hi @wessam611,
We'd like to express our appreciation for your valuable contributions to the mmdetection3d. Your efforts have significantly aided in enhancing the project's quality.
It is our pleasure to invite you to join our community thorugh Discord_Special Interest Group (SIG) channel. This is a great place to share your experiences, discuss ideas, and connect with other like-minded people. To become a part of the SIG channel, send a message to the moderator, OpenMMLab, briefly introduce yourself and mention your open-source contributions in the #introductions channel. Our team will gladly facilitate your entry. We eagerly await your presence. Please follow this link to join us: https://discord.gg/UjgXkPWNqA.
If you're on WeChat, we'd also love for you to join our community there. Just add our assistant using the WeChat ID: openmmlabwx. When sending the friend request, remember to include the remark "mmsig + Github ID".
Thanks again for your awesome contribution, and we're excited to have you as part of our community!


text:
OpTestOpenBMC.py: increase wait_bmc() timeout

Swift systems are taking more than 10 minutes between poweroff/poweron.
Increase the timeout to 15 minutes.
Signed-off-by: Klaus Heinrich Kiwi klaus@linux.vnet.ibm.com

Swift systems are taking more than 10 minutes between poweroff/poweron.
Increase the timeout to 15 minutes.

If it takes more than 10mins then something is really wrong! Have you figureout who is taking so much time? Host side -OR- BMC?
-Vasant

Swift systems are taking more than 10 minutes between poweroff/poweron.
Increase the timeout to 15 minutes.

If it takes more than 10mins then something is really wrong! Have you figureout who is taking so much time? Host side -OR- BMC?
-Vasant

New ZZ systems are just slow to boot.

Swift systems are taking more than 10 minutes between poweroff/poweron.
Increase the timeout to 15 minutes.

If it takes more than 10mins then something is really wrong! Have you figureout who is taking so much time? Host side -OR- BMC?

I admit that was a rushed fix I committed, it looked sufficiently harmless, but looks like we need to investigate more..
If we look at an instance where the issue at hand happens (https://hostboot-jenkins.swg-devops.com/job/Hostboot/job/OpenPower/job/HW/job/p9-test-param/3102/) you'll see in the console:
[  239.130316] mlx5_core 0001:15:00.0: mlx5_enter_error_state:128:(pid 1): end
[  241.208017] reboot: Power down
[  411.088160588,5] OPAL: Shutdown request type 0x0...
2020-06-08 20:11:25,697:op-test.common.OpTestSystem:run_POWERING_OFF:INFO:System is in standby/Soft-off state
2020-06-08 20:21:29,653:op-test.common.OpTestOpenBMC:wait_bmc:WARNING:We timed out waiting for "/xyz/openbmc_project/state/host0", we waited 10 minutes for "xyz.openbmc_project.State.Host.HostState.Running"
2020-06-08 20:21:29,653:op-test.common.OpTestSystem:run_IPLing:WARNING:OpTestSystem UNABLE TO REACH PETITBOOT or we missed it - "Something happened with the HTTP Server.  Review the following for more details
Message="HTTP problem getting "/xyz/openbmc_project/state/host0", we waited 10 minutes for "xyz.openbmc_project.State.Host.HostState.Running""", increasing ipl_watermark for loop_max to 101, will re-IPL for another try
2020-06-08 20:21:30,883:op-test.common.OpTestSystem:run_POWERING_OFF:INFO:System is in standby/Soft-off state
^M~.

--== Welcome to Hostboot hostboot-site_local-hostboot-OP_v2.5-21-g71210df/hbicore.bin ==--

Which apparently indicates that the host never came back after 2020-06-08 20:11:25,697:op-test.common.OpTestSystem:run_POWERING_OFF:INFO:System is in standby/Soft-off state (there's no console output), and after 10 minutes it times out and re-tries the IPL (shutdown, power-on)
If we look at the BMC journalctl (https://hostboot-jenkins.swg-devops.com/job/Hostboot/job/OpenPower/job/HW/job/p9-test-param/3102/artifact/op-test/test-reports/hostboot_test_suite_report/test-run-hostboot/op-test-openbmc-journal.Mon_Jun__8_20%3A45%3A30_2020/view/) around the same time (BMC uses UTC, so 5 hours ahead) we can see the request to shutdown:
Jun 09 01:11:25 swift25 phosphor-chassis-state-manager[252]: Change to Chassis Requested Power State
Jun 09 01:11:25 swift25 phosphor-host-state-manager[424]: Host State transaction request

According to @geissonator, we're looking for Received signal that host is running in the journalctl that would indicate that we setting "/xyz/openbmc_project/state/host0" to "xyz.openbmc_project.State.Host.HostState.Running" (the information we're looking for).
However, that message apparently never comes back until we time-out and re-trigger the IPL (Jun 09 01:21:29 swift25 phosphor-chassis-state-manager[252]: Change to Chassis Requested Power State) for which we then see the host recycling and the 'host is running' message appearing almost immediately Jun 09 01:21:38 swift25 phosphor-host-state-manager[424]: Received signal that host is running
@geissonator as I mentioned in Slack, there seems to be a lot of failures, occ timeouts and all between the events above - perhaps op-test is right and the host never came up?
I'm pasting the relevant journalctl below:
Jun 09 01:11:25 swift25 phosphor-chassis-state-manager[252]: Change to Chassis Requested Power State
Jun 09 01:11:25 swift25 phosphor-host-state-manager[424]: Host State transaction request
Jun 09 01:11:26 swift25 systemd[1]: Starting Soft power off of the host...
Jun 09 01:11:26 swift25 systemd[1]: Starting OpenPOWER OCC Active Disable...
Jun 09 01:11:26 swift25 systemd[1]: Started Power is off to chassis0.
Jun 09 01:11:26 swift25 phosphor-host-state-manager[424]: Host State transaction request
Jun 09 01:11:27 swift25 phosphor-softpoweroff[23815]: Timeout on host attention, continue with power down
Jun 09 01:11:28 swift25 systemd[1]: xyz.openbmc_project.Ipmi.Internal.SoftPowerOff.service: Succeeded.
Jun 09 01:11:28 swift25 systemd[1]: Stopped Soft power off of the host.
Jun 09 01:11:28 swift25 systemd[1]: op-occ-disable@0.service: Succeeded.
Jun 09 01:11:28 swift25 systemd[1]: Stopped OpenPOWER OCC Active Disable.
Jun 09 01:11:28 swift25 systemd[1]: Stopped target Stop Host0.
Jun 09 01:11:28 swift25 systemd[1]: Starting Reset host reboot counter...
Jun 09 01:11:29 swift25 systemd[1]: Starting Updates symlinks for active PNOR version...
Jun 09 01:11:29 swift25 systemd[1]: Stopped target Power0 Host Off.
Jun 09 01:11:29 swift25 systemd[1]: Stopped target Chassis0 (Power Off).
Jun 09 01:11:29 swift25 systemd[1]: Starting mapper subtree-remove /xyz/openbmc_project/software:xyz.openbmc_project.Software.ActivationBlocksTransition...
Jun 09 01:11:29 swift25 systemd[1]: Starting Wait for Power0 to turn on...
Jun 09 01:11:29 swift25 systemd[1]: Started Phosphor GPIO checkstop monitor.
Jun 09 01:11:29 swift25 systemd[1]: Starting Witherspoon Fan Watchdog Reset...
Jun 09 01:11:29 swift25 systemd[1]: Starting Enable the clearing of the Volatile PNOR partitions in host0...
Jun 09 01:11:29 swift25 systemd[1]: Stopping Power is off to chassis0...
Jun 09 01:11:30 swift25 systemd[1]: Starting Assert power_on LED...
Jun 09 01:11:30 swift25 systemd[1]: Stopped target Power0 Off.
Jun 09 01:11:30 swift25 systemd[1]: op-power-stop@0.service: Succeeded.
Jun 09 01:11:30 swift25 systemd[1]: Stopped Stop Power0.
Jun 09 01:11:30 swift25 systemd[1]: obmc-led-group-stop@power_on.service: Succeeded.
Jun 09 01:11:30 swift25 systemd[1]: Stopped Assert power_on LED.
Jun 09 01:11:30 swift25 systemd[1]: Started Phosphor poweron watchdog.
Jun 09 01:11:30 swift25 systemd[1]: Starting Enable the AVS bus on VRMs...
Jun 09 01:11:30 swift25 phosphor-watchdog[23838]: Action Targets:
Jun 09 01:11:30 swift25 phosphor-watchdog[23838]:   xyz.openbmc_project.State.Watchdog.Action.PowerCycle -> obmc-host-timeout@0.target
Jun 09 01:11:30 swift25 phosphor-watchdog[23838]:   xyz.openbmc_project.State.Watchdog.Action.HardReset -> obmc-host-timeout@0.target
Jun 09 01:11:30 swift25 phosphor-watchdog[23838]:   xyz.openbmc_project.State.Watchdog.Action.PowerOff -> obmc-host-timeout@0.target
Jun 09 01:11:31 swift25 systemd[1]: op-powered-off@0.service: Succeeded.
Jun 09 01:11:31 swift25 systemd[1]: Stopped Power is off to chassis0.
Jun 09 01:11:31 swift25 systemd[1]: obmc-flash-bios-updatesymlinks.service: Succeeded.
Jun 09 01:11:31 swift25 systemd[1]: Started Updates symlinks for active PNOR version.
Jun 09 01:11:31 swift25 systemd[1]: Started mapper subtree-remove /xyz/openbmc_project/software:xyz.openbmc_project.Software.ActivationBlocksTransition.
Jun 09 01:11:31 swift25 systemd[1]: Started Witherspoon Fan Watchdog Reset.
Jun 09 01:11:31 swift25 systemd[1]: obmc-flash-bios-enable-clearvolatile@0.service: Succeeded.
Jun 09 01:11:31 swift25 systemd[1]: Started Enable the clearing of the Volatile PNOR partitions in host0.
Jun 09 01:11:31 swift25 systemd[1]: Started Assert power_on LED.
Jun 09 01:11:31 swift25 systemd[1]: Started Enable the AVS bus on VRMs.
Jun 09 01:11:31 swift25 systemd[1]: mapper-subtree-remove@-xyz-openbmc\x5fproject-software\x3Axyz.openbmc_project.Software.ActivationBlocksTransition.service: Succeeded.
Jun 09 01:11:31 swift25 phosphor-host-state-manager[424]: Received signal that host is off
Jun 09 01:11:31 swift25 phosphor-host-state-manager[424]: Change to Host State
Jun 09 01:11:31 swift25 systemd[1]: phosphor-reset-host-reboot-attempts@0.service: Succeeded.
Jun 09 01:11:31 swift25 systemd[1]: Started Reset host reboot counter.
Jun 09 01:11:31 swift25 phosphor-chassis-state-manager[252]: Received signal that power OFF is complete
Jun 09 01:11:31 swift25 phosphor-chassis-state-manager[252]: Change to Chassis Power State
Jun 09 01:11:31 swift25 systemd[1]: Starting Clear the Volatile PNOR partitions in host0 if Enabled...
Jun 09 01:11:31 swift25 systemd[1]: Starting Reload mboxd during power on...
Jun 09 01:11:31 swift25 systemd[1]: op-wait-power-off@0.service: Succeeded.
Jun 09 01:11:31 swift25 systemd[1]: Stopped Wait for Power0 to turn off.
Jun 09 01:11:31 swift25 systemd[1]: Stopped target Power0 Off (Pre).
Jun 09 01:11:31 swift25 systemd[1]: Stopped target Host0 (Stopped).
Jun 09 01:11:31 swift25 systemd[1]: Stopped target Host0 (Stopping).
Jun 09 01:11:31 swift25 systemd[1]: Stopped target Stop Host0 (Pre).
Jun 09 01:11:32 swift25 systemd[1]: obmc-flash-bios-check-clearvolatile@0.service: Succeeded.
Jun 09 01:11:32 swift25 systemd[1]: Started Clear the Volatile PNOR partitions in host0 if Enabled.
Jun 09 01:11:33 swift25 ipmid[385]: Command in process, no attention
Jun 09 01:11:33 swift25 mboxctl[23854]: Reset: Success
Jun 09 01:11:33 swift25 systemd[1]: Started Reload mboxd during power on.
Jun 09 01:11:33 swift25 systemd[1]: Reached target Power0 On (Pre).
Jun 09 01:11:33 swift25 systemd[1]: Started Power Supply Input History SYNC.
Jun 09 01:11:33 swift25 systemd[1]: Starting Start Power0...
Jun 09 01:11:33 swift25 systemd[1]: power-supply-sync.service: Succeeded.
Jun 09 01:11:34 swift25 power_control.exe[145]: PowerControl: setting power up SOFTWARE_PGOOD to 1
Jun 09 01:11:34 swift25 power_control.exe[145]: PowerControl: setting power up BMC_POWER_UP to 1
Jun 09 01:11:34 swift25 systemd[1]: Started Start Power0.
Jun 09 01:11:34 swift25 systemd[1]: Starting Power Sequencer Power-on Monitor...
Jun 09 01:11:34 swift25 power_control.exe[145]: PowerControl: pgood: 1, setting reset BMC_CP0_RESET_N to 1
Jun 09 01:11:34 swift25 systemd[1]: Started Wait for Power0 to turn on.
Jun 09 01:11:34 swift25 systemd[1]: pseq-monitor-pgood.service: Succeeded.
Jun 09 01:11:34 swift25 systemd[1]: Started Power Sequencer Power-on Monitor.
Jun 09 01:11:34 swift25 systemd[1]: Reached target Power0 On.
Jun 09 01:11:34 swift25 systemd[1]: Reached target Power0 (On).
Jun 09 01:11:34 swift25 systemd[1]: Started Power Sequencer Runtime Monitor.
Jun 09 01:11:34 swift25 systemd[1]: Starting Scan FSI devices...
Jun 09 01:11:34 swift25 systemd[1]: Starting Perform power workarounds on VRMs after PGOOD is up...
Jun 09 01:11:34 swift25 systemd[1]: Started Perform power workarounds on VRMs after PGOOD is up.
Jun 09 01:11:35 swift25 kernel: occ-hwmon occ-hwmon.1: host is not ready
Jun 09 01:11:35 swift25 kernel: occ-hwmon occ-hwmon.2: host is not ready
Jun 09 01:11:35 swift25 systemd[1]: Started Scan FSI devices.
Jun 09 01:11:35 swift25 systemd[1]: Condition check resulted in OpenPOWER OCC Active Enable for host 0 being skipped.
Jun 09 01:11:35 swift25 systemd[1]: Starting Applies user CFAM register overrides from file...
Jun 09 01:11:36 swift25 systemd[1]: Started Applies user CFAM register overrides from file.
Jun 09 01:11:36 swift25 systemd[1]: Reached target Start Host0 (Pre).
Jun 09 01:11:36 swift25 systemd[1]: Starting Start host0 SBE...
Jun 09 01:11:36 swift25 openpower-proc-control[23878]: Running P9 procedure startHost
Jun 09 01:11:36 swift25 openpower-proc-control[23878]: Setting SBE seeprom side to 0
Jun 09 01:11:36 swift25 systemd[1]: Started Start host0 SBE.
Jun 09 01:11:36 swift25 systemd[1]: Reached target Host0 (Starting).
Jun 09 01:11:36 swift25 systemd[1]: Reached target Host0 (Started).
Jun 09 01:11:36 swift25 systemd[1]: Starting Start the Open Power Host Control NMI service...
Jun 09 01:11:36 swift25 systemd[1]: Starting Start Watchdog0...
Jun 09 01:11:37 swift25 phosphor-watchdog[23838]: watchdog: enabled and started
Jun 09 01:11:37 swift25 systemd[1]: Started Start the Open Power Host Control NMI service.
Jun 09 01:11:37 swift25 systemd[1]: Started Start Watchdog0.
Jun 09 01:11:48 swift25 ipmid[385]: No Object has implemented the interface
Jun 09 01:11:48 swift25 ipmid[385]: The operation failed internally.
Jun 09 01:11:48 swift25 ipmid[385]: Failed in set ACPI system property
Jun 09 01:11:48 swift25 power_control.exe[145]: BootProgress: xyz.openbmc_project.State.Boot.Progress.ProgressStages.MotherboardInit
Jun 09 01:11:52 swift25 ipmid[385]: Unable to find FRUID in generated list
Jun 09 01:11:52 swift25 ipmid[385]: Error updating inventory.
Jun 09 01:11:52 swift25 ipmid[385]: Unable to find FRUID in generated list
Jun 09 01:11:52 swift25 ipmid[385]: Error updating inventory.
Jun 09 01:11:52 swift25 ipmid[385]: Unable to find FRUID in generated list
Jun 09 01:11:52 swift25 ipmid[385]: Error updating inventory.
Jun 09 01:11:52 swift25 ipmid[385]: Unable to find FRUID in generated list
Jun 09 01:11:52 swift25 ipmid[385]: Error updating inventory.
Jun 09 01:11:52 swift25 ipmid[385]: Unable to find FRUID in generated list
Jun 09 01:11:52 swift25 ipmid[385]: Error updating inventory.
Jun 09 01:11:53 swift25 ipmid[385]: Invalid entry in byte-0
Jun 09 01:11:53 swift25 ipmid[385]: Failed to validate common header
Jun 09 01:11:53 swift25 ipmid[385]: Invalid entry in byte-0
Jun 09 01:11:53 swift25 ipmid[385]: Failed to validate common header
Jun 09 01:11:53 swift25 ipmid[385]: Invalid entry in byte-0
Jun 09 01:11:53 swift25 ipmid[385]: Failed to validate common header
Jun 09 01:11:53 swift25 ipmid[385]: Invalid entry in byte-0
Jun 09 01:11:53 swift25 ipmid[385]: Failed to validate common header
Jun 09 01:11:53 swift25 ipmid[385]: Invalid entry in byte-0
Jun 09 01:11:53 swift25 ipmid[385]: Failed to validate common header
Jun 09 01:11:53 swift25 ipmid[385]: Invalid entry in byte-0
Jun 09 01:11:53 swift25 ipmid[385]: Failed to validate common header
Jun 09 01:11:53 swift25 ipmid[385]: Invalid entry in byte-0
Jun 09 01:11:53 swift25 ipmid[385]: Failed to validate common header
Jun 09 01:11:53 swift25 ipmid[385]: Invalid entry in byte-0
Jun 09 01:11:53 swift25 ipmid[385]: Failed to validate common header
Jun 09 01:11:53 swift25 ipmid[385]: Invalid entry in byte-0
Jun 09 01:11:53 swift25 ipmid[385]: Failed to validate common header
Jun 09 01:11:53 swift25 ipmid[385]: Invalid entry in byte-0
Jun 09 01:11:53 swift25 ipmid[385]: Failed to validate common header
Jun 09 01:11:53 swift25 ipmid[385]: Invalid entry in byte-0
Jun 09 01:11:53 swift25 ipmid[385]: Failed to validate common header
Jun 09 01:11:53 swift25 ipmid[385]: Invalid entry in byte-0
Jun 09 01:11:53 swift25 ipmid[385]: Failed to validate common header
Jun 09 01:11:53 swift25 ipmid[385]: Invalid entry in byte-0
Jun 09 01:11:53 swift25 ipmid[385]: Failed to validate common header
Jun 09 01:11:53 swift25 ipmid[385]: Invalid entry in byte-0
Jun 09 01:11:53 swift25 ipmid[385]: Failed to validate common header
Jun 09 01:11:53 swift25 ipmid[385]: Invalid entry in byte-0
Jun 09 01:11:53 swift25 ipmid[385]: Failed to validate common header
Jun 09 01:11:53 swift25 ipmid[385]: Invalid entry in byte-0
Jun 09 01:11:53 swift25 ipmid[385]: Failed to validate common header
Jun 09 01:11:53 swift25 ipmid[385]: Invalid entry in byte-0
Jun 09 01:11:53 swift25 ipmid[385]: Failed to validate common header
Jun 09 01:11:53 swift25 ipmid[385]: Invalid entry in byte-0
Jun 09 01:11:53 swift25 ipmid[385]: Failed to validate common header
Jun 09 01:13:00 swift25 power_control.exe[145]: BootProgress: xyz.openbmc_project.State.Boot.Progress.ProgressStages.OSStart
Jun 09 01:13:09 swift25 kernel: occ-hwmon occ-hwmon.1: OCC found, code level: op_occ_200417a
Jun 09 01:13:10 swift25 kernel: occ-hwmon occ-hwmon.2: OCC found, code level: op_occ_200417a
Jun 09 01:13:10 swift25 systemd[1]: Started Phosphor Hwmon Poller.
Jun 09 01:13:11 swift25 systemd[1]: Started Phosphor Hwmon Poller.
Jun 09 01:13:15 swift25 ipmid[385]: Command in process, no attention
Jun 09 01:13:15 swift25 ipmid[385]: No Object has implemented the interface
Jun 09 01:13:15 swift25 ipmid[385]: The operation failed internally.
Jun 09 01:13:15 swift25 ipmid[385]: Failed in set ACPI system property
Jun 09 01:13:32 swift25 phosphor-watchdog[23838]: watchdog: disabled
Jun 09 01:13:41 swift25 ipmid[385]: Unsupported parameter
Jun 09 01:13:41 swift25 ipmid[385]: getHostNetworkData failed for get_sys_boot_options.
Jun 09 01:13:41 swift25 ipmid[385]: Unsupported parameter
Jun 09 01:13:41 swift25 ipmid[385]: getHostNetworkData failed for get_sys_boot_options.
Jun 09 01:16:56 swift25 psu-monitor[391]: Failed to read sysfs file
Jun 09 01:16:56 swift25 psu-monitor[391]: Failed to read from the device. This can be used by any application that gets a failure reading from a device. It is up to the implementation on how to react to this error based on the use-case. Refer to the interface specification that references this for additional information.
Jun 09 01:16:57 swift25 psu-monitor[391]: Noncontiguous INPUT_HISTORY sequence ID found. Clearing old entries
Jun 09 01:21:29 swift25 phosphor-chassis-state-manager[252]: Change to Chassis Requested Power State
Jun 09 01:21:30 swift25 phosphor-host-state-manager[424]: Host State transaction request
Jun 09 01:21:31 swift25 systemd[1]: Starting Soft power off of the host...
Jun 09 01:21:31 swift25 systemd[1]: Stopping Phosphor poweron watchdog...
Jun 09 01:21:31 swift25 systemd[1]: Stopping Phosphor GPIO checkstop monitor...
Jun 09 01:21:31 swift25 systemd[1]: Stopping Start the Open Power Host Control NMI service...
Jun 09 01:21:31 swift25 systemd[1]: witherspoon-reset-fan-watchdog.service: Succeeded.
Jun 09 01:21:31 swift25 systemd[1]: Stopped Witherspoon Fan Watchdog Reset.
Jun 09 01:21:31 swift25 systemd[1]: obmc-enable-host-watchdog@0.service: Succeeded.
Jun 09 01:21:31 swift25 systemd[1]: Stopped Start Watchdog0.
Jun 09 01:21:31 swift25 phosphor-host-state-manager[424]: Host State transaction request
Jun 09 01:21:31 swift25 systemd[1]: Starting OpenPOWER OCC Active Disable...
Jun 09 01:21:31 swift25 systemd[1]: Starting Assert power_on LED...
Jun 09 01:21:31 swift25 phosphor-softpoweroff[23893]: Timer started waiting for host to shutdown
Jun 09 01:21:31 swift25 systemd[1]: phosphor-gpio-monitor@checkstop.service: Main process exited, code=killed, status=15/TERM
Jun 09 01:21:31 swift25 systemd[1]: phosphor-gpio-monitor@checkstop.service: Succeeded.
Jun 09 01:21:31 swift25 systemd[1]: Stopped Phosphor GPIO checkstop monitor.
Jun 09 01:21:32 swift25 systemd[1]: phosphor-watchdog@poweron.service: Main process exited, code=killed, status=15/TERM
Jun 09 01:21:32 swift25 systemd[1]: phosphor-watchdog@poweron.service: Succeeded.
Jun 09 01:21:32 swift25 systemd[1]: Stopped Phosphor poweron watchdog.
Jun 09 01:21:32 swift25 ipmid[385]: Unsupported parameter
Jun 09 01:21:32 swift25 ipmid[385]: getHostNetworkData failed for get_sys_boot_options.
Jun 09 01:21:32 swift25 systemd[1]: xyz.openbmc_project.Control.Host.NMI.service: Main process exited, code=killed, status=15/TERM
Jun 09 01:21:32 swift25 systemd[1]: xyz.openbmc_project.Control.Host.NMI.service: Succeeded.
Jun 09 01:21:32 swift25 systemd[1]: Stopped Start the Open Power Host Control NMI service.
Jun 09 01:21:32 swift25 systemd[1]: op-occ-disable@0.service: Succeeded.
Jun 09 01:21:32 swift25 systemd[1]: Started OpenPOWER OCC Active Disable.
Jun 09 01:21:32 swift25 systemd[1]: Started Assert power_on LED.
Jun 09 01:21:33 swift25 systemd[1]: xyz.openbmc_project.Hwmon@-devices-platform-gpio\x2dfsi-fsi0-slave@00\x2d\x2d00-00\x2d\x2d00\x2d\x2d00\x2d\x2d06-sbefifo1\x2ddev0-occ\x2dhwmon.1.service: Succeeded.
Jun 09 01:21:33 swift25 systemd[1]: xyz.openbmc_project.Hwmon@-devices-platform-gpio\x2dfsi-fsi0-slave@00\x2d\x2d00-00\x2d\x2d00\x2d\x2d00\x2d\x2d0a-fsi1-slave@01\x2d\x2d00-01\x2d\x2d01\x2d\x2d00\x2d\x2d06-sbefifo2\x2ddev0-occ\x2dhwmon.2.service: Succeeded.
Jun 09 01:21:33 swift25 systemd[1]: Starting Reset host reboot counter...
Jun 09 01:21:33 swift25 systemd[1]: Started Phosphor poweron watchdog.
Jun 09 01:21:33 swift25 systemd[1]: Starting Updates symlinks for active PNOR version...
Jun 09 01:21:34 swift25 systemd[1]: Starting mapper subtree-remove /xyz/openbmc_project/software:xyz.openbmc_project.Software.ActivationBlocksTransition...
Jun 09 01:21:34 swift25 systemd[1]: Started Phosphor GPIO checkstop monitor.
Jun 09 01:21:34 swift25 phosphor-watchdog[23909]: Action Targets:
Jun 09 01:21:34 swift25 phosphor-watchdog[23909]:   xyz.openbmc_project.State.Watchdog.Action.PowerCycle -> obmc-host-timeout@0.target
Jun 09 01:21:34 swift25 phosphor-watchdog[23909]:   xyz.openbmc_project.State.Watchdog.Action.HardReset -> obmc-host-timeout@0.target
Jun 09 01:21:34 swift25 phosphor-watchdog[23909]:   xyz.openbmc_project.State.Watchdog.Action.PowerOff -> obmc-host-timeout@0.target
Jun 09 01:21:34 swift25 systemd[1]: Stopped target Chassis0 (Powered Off).
Jun 09 01:21:34 swift25 systemd[1]: Starting Witherspoon Fan Watchdog Reset...
Jun 09 01:21:34 swift25 systemd[1]: Starting Enable the clearing of the Volatile PNOR partitions in host0...
Jun 09 01:21:34 swift25 systemd[1]: obmc-led-group-stop@power_on.service: Succeeded.
Jun 09 01:21:34 swift25 systemd[1]: Stopped Assert power_on LED.
Jun 09 01:21:35 swift25 systemd[1]: xyz.openbmc_project.Ipmi.Internal.SoftPowerOff.service: Main process exited, code=killed, status=15/TERM
Jun 09 01:21:35 swift25 systemd[1]: xyz.openbmc_project.Ipmi.Internal.SoftPowerOff.service: Failed with result 'signal'.
Jun 09 01:21:35 swift25 systemd[1]: Stopped Soft power off of the host.
Jun 09 01:21:35 swift25 systemd[1]: phosphor-reset-host-reboot-attempts@0.service: Succeeded.
Jun 09 01:21:35 swift25 systemd[1]: Started Reset host reboot counter.
Jun 09 01:21:35 swift25 systemd[1]: obmc-flash-bios-updatesymlinks.service: Succeeded.
Jun 09 01:21:35 swift25 systemd[1]: Started Updates symlinks for active PNOR version.
Jun 09 01:21:35 swift25 systemd[1]: Started mapper subtree-remove /xyz/openbmc_project/software:xyz.openbmc_project.Software.ActivationBlocksTransition.
Jun 09 01:21:35 swift25 systemd[1]: Started Witherspoon Fan Watchdog Reset.
Jun 09 01:21:35 swift25 systemd[1]: obmc-flash-bios-enable-clearvolatile@0.service: Succeeded.
Jun 09 01:21:35 swift25 systemd[1]: Started Enable the clearing of the Volatile PNOR partitions in host0.
Jun 09 01:21:35 swift25 systemd[1]: mapper-subtree-remove@-xyz-openbmc\x5fproject-software\x3Axyz.openbmc_project.Software.ActivationBlocksTransition.service: Succeeded.
Jun 09 01:21:36 swift25 phosphor-host-state-manager[424]: Received signal that host is off
Jun 09 01:21:36 swift25 phosphor-host-state-manager[424]: Change to Host State
Jun 09 01:21:36 swift25 phosphor-chassis-state-manager[252]: Received signal that power OFF is complete
Jun 09 01:21:36 swift25 phosphor-chassis-state-manager[252]: Change to Chassis Power State
Jun 09 01:21:36 swift25 systemd[1]: Starting Clear the Volatile PNOR partitions in host0 if Enabled...
Jun 09 01:21:36 swift25 systemd[1]: Started Power Supply Input History SYNC.
Jun 09 01:21:36 swift25 systemd[1]: Starting Power Sequencer Power-on Monitor...
Jun 09 01:21:36 swift25 systemd[1]: Started Phosphor Fan Control Initialization.
Jun 09 01:21:36 swift25 systemd[1]: Condition check resulted in OpenPOWER OCC Active Enable for host 0 being skipped.
Jun 09 01:21:36 swift25 systemd[1]: Started Phosphor Fan Monitor Initialization.
Jun 09 01:21:36 swift25 systemd[1]: Started Phosphor Fan Presence Tach Daemon.
Jun 09 01:21:37 swift25 obmc-flash-bios[23922]: Clear /var/lib/phosphor-software-manager/pnor/rw/HB_VOLATILE
Jun 09 01:21:37 swift25 phosphor-fan-control[23925]: Uncaught DBus service lookup failure exception
Jun 09 01:21:37 swift25 systemd[1]: obmc-flash-bios-check-clearvolatile@0.service: Succeeded.
Jun 09 01:21:37 swift25 systemd[1]: Started Clear the Volatile PNOR partitions in host0 if Enabled.
Jun 09 01:21:37 swift25 phosphor-fan-presence-tach[23928]: Unable to read fan tach sensor.
Jun 09 01:21:37 swift25 systemd[1]: power-supply-sync.service: Succeeded.
Jun 09 01:21:37 swift25 phosphor-fan-presence-tach[23928]: Unable to read fan tach sensor.
Jun 09 01:21:37 swift25 systemd[1]: pseq-monitor-pgood.service: Succeeded.
Jun 09 01:21:37 swift25 phosphor-fan-presence-tach[23928]: Unable to read fan tach sensor.
Jun 09 01:21:37 swift25 phosphor-fan-presence-tach[23928]: Unable to read fan tach sensor.
Jun 09 01:21:37 swift25 systemd[1]: Started Power Sequencer Power-on Monitor.
Jun 09 01:21:37 swift25 systemd[1]: phosphor-fan-control-init@0.service: Main process exited, code=exited, status=1/FAILURE
Jun 09 01:21:37 swift25 systemd[1]: phosphor-fan-control-init@0.service: Failed with result 'exit-code'.
Jun 09 01:21:37 swift25 systemd[1]: phosphor-fan-monitor-init@0.service: Succeeded.
Jun 09 01:21:37 swift25 systemd[1]: Reached target Chassis0 (Power On).
Jun 09 01:21:38 swift25 systemd[1]: Starting Start the Open Power Host Control NMI service...
Jun 09 01:21:38 swift25 systemd[1]: Starting Start Watchdog0...
Jun 09 01:21:38 swift25 phosphor-chassis-state-manager[252]: Received signal that power ON is complete
Jun 09 01:21:38 swift25 phosphor-chassis-state-manager[252]: Change to Chassis Power State
Jun 09 01:21:38 swift25 systemd[1]: Started Start the Open Power Host Control NMI service.
Jun 09 01:21:38 swift25 phosphor-watchdog[23909]: watchdog: enabled and started
Jun 09 01:21:38 swift25 systemd[1]: Started Start Watchdog0.
Jun 09 01:21:38 swift25 systemd[1]: Reached target Start Host0 Minimum.
Jun 09 01:21:38 swift25 systemd[1]: Reached target Start Host0.
Jun 09 01:21:38 swift25 phosphor-host-state-manager[424]: Received signal that host is running
Jun 09 01:21:38 swift25 phosphor-host-state-manager[424]: Change to Host State

authors: hegdevasant klauskiwi oohal

repo: open-power/op-test


text:
Reduce noise made by lifts

As reported in https://github.com/open-rmf/rmf_ros2/issues/315 the simulated lifts make a lot of noise (terminal printout) since some recent updates to lift request behavior. There is no issue with the functionality, but the excessive printouts may be confusing or distracting for users. This PR eliminates the excess noise for any lifts that are not being actively used.
There will still be periodic terminal output while a lift is being used by a robot, but that's less likely to cause concern for users.

I believe this should already be addressed in the ECS refactor, the file this targets doesn't exist anymore and running the hotel world shows no printouts from the lift plugin when the lift is not being used, i.e. I tried to request a lift to L2 and got the following log (relevant messages are from rmf_simulation_lift_manager):
[lift_supervisor-12] [INFO] [1734665436.464387902] [rmf_lift_supervisor]: [lift_panel_session] Received adapter lift request to [L2] with request type [1]
[lift_supervisor-12] [INFO] [1734665436.759614437] [rmf_lift_supervisor]: [] Published lift request to [L2] from lift supervisor
[gz-20] [INFO] [1734665436.768310697] [rmf_simulation_lift_manager]: Lift [Lift2] requested at level [L2]
[lift_supervisor-12] [INFO] [1734665436.769411497] [rmf_lift_supervisor]: [lift_panel_session] Published lift request to [L2] from lift supervisor
[lift_supervisor-12] [INFO] [1734665437.763659541] [rmf_lift_supervisor]: [lift_panel_session] Published lift request to [L2] from lift supervisor
[lift_supervisor-12] [INFO] [1734665438.769102245] [rmf_lift_supervisor]: [lift_panel_session] Published lift request to [L2] from lift supervisor
[lift_supervisor-12] [INFO] [1734665439.772357190] [rmf_lift_supervisor]: [lift_panel_session] Published lift request to [L2] from lift supervisor
[lift_supervisor-12] [INFO] [1734665439.782063609] [rmf_lift_supervisor]: [lift_panel_session] Published lift request to [L2] from lift supervisor
[lift_supervisor-12] [INFO] [1734665440.776469414] [rmf_lift_supervisor]: [lift_panel_session] Published lift request to [L2] from lift supervisor
[lift_supervisor-12] [INFO] [1734665441.780808487] [rmf_lift_supervisor]: [lift_panel_session] Published lift request to [L2] from lift supervisor
[lift_supervisor-12] [INFO] [1734665442.744617462] [rmf_lift_supervisor]: [lift_panel_session] Published lift request to [L2] from lift supervisor
[lift_supervisor-12] [INFO] [1734665442.784630802] [rmf_lift_supervisor]: [lift_panel_session] Published lift request to [L2] from lift supervisor
[lift_supervisor-12] [INFO] [1734665442.794037331] [rmf_lift_supervisor]: [lift_panel_session] Published lift request to [L2] from lift supervisor
[lift_supervisor-12] [INFO] [1734665443.788713666] [rmf_lift_supervisor]: [lift_panel_session] Published lift request to [L2] from lift supervisor
[lift_supervisor-12] [INFO] [1734665444.792880380] [rmf_lift_supervisor]: [lift_panel_session] Published lift request to [L2] from lift supervisor
[lift_supervisor-12] [INFO] [1734665445.799136144] [rmf_lift_supervisor]: [lift_panel_session] Published lift request to [L2] from lift supervisor
[lift_supervisor-12] [INFO] [1734665446.803605458] [rmf_lift_supervisor]: [lift_panel_session] Published lift request to [L2] from lift supervisor
[schedule_visualizer_node-4] [INFO] [1734665446.825902927] [schedule_data_node]: Requesting new schedule update because update timed out
[schedule_visualizer_node-4] [INFO] [1734665446.825965418] [schedule_data_node]: [rmf_traffic_ros2::MirrorManager::request_update] Requesting changes for query ID [1] since version [15]
[fleet_adapter-17] [INFO] [1734665446.826165367] [tinyRobot_fleet_adapter]: Requesting new schedule update because update timed out
[fleet_adapter-17] [INFO] [1734665446.826212938] [tinyRobot_fleet_adapter]: [rmf_traffic_ros2::MirrorManager::request_update] Requesting changes for query ID [1] since version [15]
[fleet_adapter-15] [INFO] [1734665446.826218327] [cleanerBotA_fleet_adapter]: Requesting new schedule update because update timed out
[fleet_adapter-15] [INFO] [1734665446.826273958] [cleanerBotA_fleet_adapter]: [rmf_traffic_ros2::MirrorManager::request_update] Requesting changes for query ID [1] since version [15]
[fleet_adapter-19] [INFO] [1734665446.826374987] [deliveryRobot_fleet_adapter]: Requesting new schedule update because update timed out
[fleet_adapter-19] [INFO] [1734665446.826417967] [deliveryRobot_fleet_adapter]: [rmf_traffic_ros2::MirrorManager::request_update] Requesting changes for query ID [1] since version [15]
[lift_supervisor-12] [INFO] [1734665447.807930112] [rmf_lift_supervisor]: [lift_panel_session] Published lift request to [L2] from lift supervisor
[lift_supervisor-12] [INFO] [1734665448.564542470] [rmf_lift_supervisor]: [lift_panel_session] Published lift request to [L2] from lift supervisor
[lift_supervisor-12] [INFO] [1734665448.816196956] [rmf_lift_supervisor]: [lift_panel_session] Published lift request to [L2] from lift supervisor
[lift_supervisor-12] [INFO] [1734665449.820532970] [rmf_lift_supervisor]: [lift_panel_session] Published lift request to [L2] from lift supervisor
[lift_supervisor-12] [INFO] [1734665450.824759414] [rmf_lift_supervisor]: [lift_panel_session] Published lift request to [L2] from lift supervisor
[lift_supervisor-12] [INFO] [1734665451.830285308] [rmf_lift_supervisor]: [lift_panel_session] Published lift request to [L2] from lift supervisor
[lift_supervisor-12] [INFO] [1734665452.836176092] [rmf_lift_supervisor]: [lift_panel_session] Published lift request to [L2] from lift supervisor
[lift_supervisor-12] [INFO] [1734665453.838904976] [rmf_lift_supervisor]: [lift_panel_session] Published lift request to [L2] from lift supervisor
[lift_supervisor-12] [INFO] [1734665453.839304996] [rmf_lift_supervisor]: [lift_panel_session] Received adapter lift request to [L2] with request type [0]
[lift_supervisor-12] [INFO] [1734665453.839352336] [rmf_lift_supervisor]: [lift_panel_session] Published end lift session from lift supervisor
[gz-20] [INFO] [1734665453.858667696] [rmf_simulation_lift_manager]: Lift [Lift2] requested at level [L2]

authors: luca-della-vedova mxgrey


text:
Feature: update 100 days of OSS banner

Type of feature
🍕 Feature
Current behavior
N/A
Suggested solution
Update the Banner on the "Highlights" page to include information on Workspaces.
Title: Track your project with Workspaces!
Content: Setup your Workspace to get you and your team access to information about PRs, Issues and contributors for all your repositories.
Image:

Additional context
No response
Code of Conduct

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

Contributing Docs

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

Look at what @brandonroberts did for the new workspace CTA that redirects you to log in if you aren't logged in.

authors: isabensusan nickytonline

repo: open-sauced/app


text:
Make preset configurable

A very small addition to allow the preset option value to be configurable.
It would probably be good to check for a pint.json at the root and use that preset value, if it exists.

Sorry! Got this too late (already pushed and publishing new release with extra config)
Thanks anyways for the PR!! 🔥

repo: open-southeners/vscode-laravel-pint


text:
The CI build is too long

What happened?
Description
The current CI build takes too long to complete (on average 90 minutes or so).
This issue captures the ongoing efforts to get the build under a given threshold.
Please upvote this issue with :+1: if you'd like to see this effort be prioritized. Patches welcome!
Steps to Reproduce
Run a build for a pull request against the repository.
Expected Result
The build takes under 30 minutes to run.
Actual Result
The build takes 90 minutes to run.
eBPF Collector version
latest
Environment information
No response
eBPF Collector configuration
No response
Log output
No response
Additional context
No response

Some possibilities brainstormed include:

getting larger (and/or dedicated) GitHub runners
enabling build caching (ccache, build-env ~/.gradle cache)
making the builds and tests more parallel

authors: atoulme jimwsplk

repo: open-telemetry/opentelemetry-ebpf


text:
Issue with 3.11.5 mysql2 span not being generated

What version of OpenTelemetry are you using?
0.54.0 (latest)
What version of Node are you using?
v22.10.0
What did you do?
Set up an express server to make a call to a dummy nonexistant database using mysql2:
import mysql from 'mysql2';
const connection = mysql.createConnection({
host: process.env.DB_HOST,
user: process.env.DB_USER,
password: process.env.DB_PASSWORD
});
connection.query(
'CREATE DATABASE IF NOT EXISTS db',
(err, results) => {
if (err) {
console.error('Error creating database:', err);
return;
}
console.log('Database created successfully');
}
);
Ran using version 3.11.4, db span exists and gets populated:

Ran using version 3.11.5, no db span:

What did you expect to see?
DB span to populate in newest mysql2 version
What did you see instead?
No span running on the latest mysql2 version and latest otel js version.
Additional context
Related issue: https://github.com/aws-observability/aws-otel-js-instrumentation/issues/127

huh, weird - I though this was fixed in #2579

@liustve thanks for reaching out - assigning P2 (incomplete or missing telemetry).

Hi @liustve
I've tried to reproduce the issue with no luck in this small project. For both versions of mysql2 (3.11.4 & 3.11.5) the instrumentation gets the db statement.
When you mention the version 0.54.0 (latest) which package are you referring to? I?m asking because there are several packages involved in the tracing setup.
this is the list of dependencies of the project
npm ls
otel-js-contrib-2590@1.0.0 /Users/david/Documents/repos/dl/otel-js-contrib-2590
├── @opentelemetry/api@1.9.0
├── @opentelemetry/instrumentation-http@0.56.0
├── @opentelemetry/instrumentation-mysql2@0.44.0
├── @opentelemetry/instrumentation@0.56.0
├── @opentelemetry/sdk-trace-base@1.29.0
├── @opentelemetry/sdk-trace-node@1.29.0
├── @opentelemetry/semantic-conventions@1.28.0
├── @types/node@18.18.14
├── mysql2@3.11.5
├── ts-node@10.9.2
└── typescript@4.4.4

could yo give me some directions on hot to reproduce the issue?

Hi David, the package that I was using for this issue is v0.54.0:
https://www.npmjs.com/package/@opentelemetry/auto-instrumentations-node
The instrumentation I was using for mysql2 matches your version (0.44.0).
Would it be possible to set up sometime to do a live debugging sometime next week?
Thanks!

authors: david-luna liustve pichlermarc

repo: open-telemetry/opentelemetry-js-contrib


text:
Version 0.35.1 of @opentelemetry/sdk-node broke http instrumentation

What happened?
Steps to Reproduce
Using this monitoring.js file:
/**
 * Autoinstrument node.js express app and export to prometheus
 */
const api = require('@opentelemetry/api');
const opentelemetry = require('@opentelemetry/sdk-node');
const { PrometheusExporter } = require('@opentelemetry/exporter-prometheus');
const { HttpInstrumentation } = require('@opentelemetry/instrumentation-http');

const pPort = PrometheusExporter.DEFAULT_OPTIONS.port;
const pEndpoint = PrometheusExporter.DEFAULT_OPTIONS.endpoint;

const prometheusExporter = new PrometheusExporter(
    { preventServerStart: false, prefix: 'ghost' },
    () => { console.log(`>>>> Prometheus scrape endpoint: http://localhost:${pPort}${pEndpoint}`); }
);

const sdk = new opentelemetry.NodeSDK({
    metricReader: prometheusExporter,

    instrumentations: [ new HttpInstrumentation() ]
});

sdk.start().then(() => {
    console.log('>>>> OpenTelemetry SDK started');
}).catch(err => {
    console.log('ERROR starting OpenTelemetry SDK. Shutting down', err);
    process.exit(1);
});

process.on("SIGTERM", () => {
  sdk
    .shutdown()
    .then(
      () => console.log('>>>> SDK shut down successfully'),
      (err) => console.log('>>>> Error shutting down SDK', err)
    )
    .finally(() => process.exit(0));
});

with this package.json dependencies:
  "dependencies": {
    "@opentelemetry/api": "1.4.0",
    "@opentelemetry/instrumentation-http": "0.35.1",
    "@opentelemetry/exporter-prometheus": "0.35.1",
    "@opentelemetry/sdk-node": "0.35.0",
    "express": "4.18.2"
  },

Standing up a simple Express application that just
require('./monitoring.js') and calling it on the metrics endpoint http://localhost:9464/metrics correctly shows the http metrics:
...
# HELP ghost_http_server_duration measures the duration of the inbound HTTP requests
# UNIT ghost_http_server_duration ms
# TYPE ghost_http_server_duration histogram
# HELP ghost_http_client_duration measures the duration of the outbound HTTP requests
# UNIT ghost_http_client_duration ms
# TYPE ghost_http_client_duration histogram
...

and calling the Express app correctly produces time series.
Updating the version of @opentelemetry/sdk-node to 0.35.1 breaks the http instrumentation: standing up the Express app and calling on the metrics endpoints http://localhost:9464/metrics does not report http metrics definition anymore and calling the Express app does not produces time series.
Expected Result
New version does not break http instrumentation.
Actual Result
New version 0.35.1 breaks http instrumentation.
Additional Details
OpenTelemetry Setup Code
/**
 * Autoinstrument node.js express app and export to prometheus
 */
const api = require('@opentelemetry/api');
const opentelemetry = require('@opentelemetry/sdk-node');
const { PrometheusExporter } = require('@opentelemetry/exporter-prometheus');
const { HttpInstrumentation } = require('@opentelemetry/instrumentation-http');

const pPort = PrometheusExporter.DEFAULT_OPTIONS.port;
const pEndpoint = PrometheusExporter.DEFAULT_OPTIONS.endpoint;

const prometheusExporter = new PrometheusExporter(
    { preventServerStart: false, prefix: 'ghost' },
    () => { console.log(`>>>> Prometheus scrape endpoint: http://localhost:${pPort}${pEndpoint}`); }
);

const sdk = new opentelemetry.NodeSDK({
    metricReader: prometheusExporter,

    instrumentations: [ new HttpInstrumentation() ]
});

sdk.start().then(() => {
    console.log('>>>> OpenTelemetry SDK started');
}).catch(err => {
    console.log('ERROR starting OpenTelemetry SDK. Shutting down', err);
    process.exit(1);
});

process.on("SIGTERM", () => {
  sdk
    .shutdown()
    .then(
      () => console.log('>>>> SDK shut down successfully'),
      (err) => console.log('>>>> Error shutting down SDK', err)
    )
    .finally(() => process.exit(0));
});

package.json
{
  "name": "echo-server",
  "version": "1.0.0",
  "main": "app.js",
  "dependencies": {
    "@opentelemetry/api": "1.4.0",
    "@opentelemetry/instrumentation-http": "0.35.1",
    "@opentelemetry/exporter-prometheus": "0.35.1",
    "@opentelemetry/sdk-node": "0.35.0",
    "express": "4.18.2"
  }
}

Relevant log output
No response

I was able to reproduce this, it looks like this problem was introduced with 0.35.1 via #3502. Now that we're registering the instrumentations early, the MeterProvider used by the instrumentations is a NoopMeterProvider and all metrics get dropped. :slightly_frowning_face:
We may either have to revert the changes made in #3502 or provide a workaround that sets the MeterProvider on all instrumentations after initialization in NodeSDK.start() finishes. I'll open a PR for that tomorrow. :slightly_smiling_face:
I also created an issue aiming for a long-term fix here #3622

authors: mkrudele pichlermarc

repo: open-telemetry/opentelemetry-js


text:
deps: update typescript to latest

Update typescript to latest. I'm going to try to use a tool like downlevel-dts to publish types compatible with older versions of typescript

I'm going to try to use a tool like downlevel-dts to publish types compatible with older versions of typescript

Are you going to work on this in this PR?

I'm going to try to use a tool like downlevel-dts to publish types compatible with older versions of typescript

Are you going to work on this in this PR?

Yes I had a local draft but I'll push so you can see #3166

authors: dyladan legendecas


text:
Change OTEL_METRICS_EXPORTER env variable default from none to otlp

Will fix Issue #475 by changing the default value for the OTEL_METRICS_EXPORTER from none to otlp.

A new PR #478 was made to track this issue as well as fix other environment variable defaults and so the discussion shall continue there.  This PR will now be closed.

repo: open-telemetry/opentelemetry-lambda


text:
Relocate a few internal/collector/* packages

Move packages that are only used by tail sampling processor to processor/tailsampling instead of internal/collector.

Codecov Report

Merging #238 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #238   +/-   ##
=======================================
  Coverage   73.44%   73.44%
=======================================
  Files         112      112
  Lines        6516     6516
=======================================
  Hits         4786     4786
  Misses       1489     1489
  Partials      241      241

Impacted Files
Coverage Δ

processor/tailsampling/idbatcher/id_batcher.go
100% <ø> (ø)

processor/queued/queued_processor.go
47.61% <ø> (ø)
:arrow_up:

...ocessor/tailsampling/sampling/string_tag_filter.go
0% <ø> (ø)

processor/metrics.go
0% <ø> (ø)

processor/tailsampling/sampling/rate_limiting.go
0% <ø> (ø)

...cessor/tailsampling/sampling/numeric_tag_filter.go
0% <ø> (ø)

processor/nodebatcher/metrics.go
0% <ø> (ø)
:arrow_up:

service/telemetry.go
72.97% <ø> (ø)
:arrow_up:

processor/nodebatcher/node_batcher.go
93.83% <ø> (ø)
:arrow_up:

processor/tailsampling/sampling/always_sample.go
0% <ø> (ø)

... and 1 more

Continue to review full report at Codecov.

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

repo: open-telemetry/opentelemetry-service