text:
[website] datathinking.org/principles

be clear
be specific

e.g. end of a highway vs end of a road; being more clear of the semantics and diction with which you communicate a problem statement (OK, sorry! We changed our mind and we'd rather receive bounding boxes for the ends of a street in the jpg images. Can you please revise this?)

write it down

recognize it's hard to assess:

how you feel
what you want to do

there are many factors at play, and tools like chatgpt can help you receive rapid feedback on which stage of the process you are at.
for example, are you clarifying a research question? identifying an unmet need in a population of stakeholders? designing a user interface to meet a need using artificial intelligence?
then:

see the available tools
tricks from google:

"plt" -matplotlib "point cloud" "annotat*"

feel, ask, do, think
thinking:

reflect, revise
find alternative tools (ask chatgpt, lean on code examples, etc)
respect how you feel (frustrated, impatient, giving up on a project, going in circles), and go back to asking for help, advocating for yourself
understand incentives (e.g. not being able to install dependencies, being blocked on VPN and limited in access, bureaucracy in getting and understanding data)
try to revise the research question (e.g. instead of cars, ends of roads or annotation pipelines) in hopes that existing solutions may generalize to yours

OK, sorry! We changed our mind and we'd rather receive bounding boxes for the ends of a street in the jpg images. Can you please revise this?
claude:
That is a quite different task! For street segmentation and finding end points, you'll want a semantic segmentation model rather than an object detector.
Here is an example using PyTorch and a pretrained segmentation model (DeepLabV3):
model = torch.hub.load('pytorch/vision:v0.10.0', 'deeplabv3_resnet101', pretrained=True)
model.eval()
img = torch.rand(3, 800, 1200)  # sample input image
output = model(img)
Get pixel predictions - each value is a class ID
predictions = output['out'].argmax(1)
Find endpoints where road class transitions to non-road
endpoints = []
for row in range(predictions.shape[1]):
for col in range(predictions.shape[2] - 1):
if predictions[0, row, col] != predictions[0, row, col + 1]:
endpoints.append((row, col))  # (y, x) coordinate
print(endpoints)  # e.g. [(223, 562), (401, 1103), ...]
So the endpoints list will contain (y, x) coords for all the spots where the road ends.
Again, you'd feed an actual street image into img, and the rest would be largely the same. Let me know if you have any other questions!

follow the money, follow the data, follow the status (kissinger, openai, etc)
understand incentives, behavioral economics, psychology, and ethnography to understand provenance in-context
parsimoniony:

if it doesn't work for me, it won't work for them
if it doesn't work here, it won't work there
focus on edge cases to ensure data thinking artefacts are simple

focus on low latency: balance compute with performance
validate with computers and humans
math before code
be clear, be specific, write it down.
self-monitoring for behavior change.
feel, ask, think, do
start with the math
visualizations: visualize early, visualize often
style: be fancy, principled, aesthetic. axes; ismael's.
great data thinkers steal.
data: FAIR
tech: use simplest tools that are most composable and most open source and most accessible worldwide.

if it's too complicated, make it simpler (mindshare). the market doesn't reward waiting.

have one source of ground truth and understand its provenance, governance, and metadata. look at it often and reflect on what unknown unknowns you may be missing.

Articulate things clearly.
Articulate status games, optics, and incentives that drive data and drive thinking clearly.

Teach someone to see the impact of your actions and principles on others (prespcriptive vs descriptive)(

focus on etymology in naming a la websters. / jsumers


text:
Pad the edges of the inventory so it fits on mobile

Sometimes when rendering in Chrome on small screens, the edges of the inventory get cut off. I can add some extra blank space to the inventory edges (on the outside) so it fits better.

This was fixed with https://github.com/onefrankguy/dewdrop-farm/commit/8f9eb6610593e8e3f6cb90489cf41575b57593f2.

source: gharchive/issue

repo: onefrankguy/dewdrop-farm

license: MIT

license_type: permissive

license_source: github-api


text:
Checking if messages should be signed before validating signed content.

'No Signature found. SAML Response rejected' was being thrown when 'wantMessagesSigned' was set to false.

Closing this until I can give it some propper attention.

source: gharchive/pull-request

repo: onelogin/php-saml

license: mit

license_source: bigquery


text:
feat: upgrade argo to 2.12.4

What this PR does:
Which issue(s) this PR fixes:

Fixes onepanelio/core#
Special notes for your reviewer:
Checklist
Please check if applies

[ ] I have added/updated relevant unit tests
[ ] I have added/updated relevant documentation

Required

[x] I accept to release these changes under the Apache 2.0 License

@Vafilor have a conflict here - also we updated manifests to 2.12.5 just in case we need to change anything here.

@Vafilor have a conflict here - also we updated manifests to 2.12.5 just in case we need to change anything here.

authors: Vafilor rushtehrani

repo: onepanelio/core


text:
Return statusCode from ImageDownloader callback if failures occur

I'd like to differentiate between 404's (image doesn't exist) and auth / server exceptions.
One option:
NSError(domain: KingfisherErrorDomain, code: KingfisherError.NotModified.rawValue, userInfo: ["statusCode": ...])

+1 This would be a great addition

Basically implemented in #346

authors: mrstone onevcat stephenvisser

repo: onevcat/Kingfisher


text:
这个library支持.ico吗？

请问作者，这个库现在支持.ico吗？我尝试着加载.ico图标，但是报了10000错误。我用的Kingfisher的版本是2.1.0。

从 2.2.1 开始支持。https://github.com/onevcat/Kingfisher/pull/278

authors: iDalink onevcat


text:
Fix 'initializer for conditional binding must have Optional type…' error

When building under the swift-5.8 development snapshot dated 2/9/2023, I get this error:
…/SourcePackages/checkouts/Kingfisher/Sources/SwiftUI/KFImageRenderer.swift:48:63: error: initializer for conditional binding must have Optional type, not 'AnyView'
                    if let placeholder = context.placeholder, let view = placeholder(binder.progress) {
                                                              ^          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This PR fixes that, seems to work for both Xcode 14.2 (5.7?) and Swift 5.8 toolchains. Should be applied to 7.6 branch as well as master.

LGTM! Not sure why I wrote this before.
Thank you for this!

Yeah, I don't know why the compiler even allows it!

Builds fine for me in Xcode 14.3b2 using the 7.6.2 version.

@cbunge3 Can you try to confirm that you are using the latest commit (sometimes maybe you need to reset the SPM cache or clean the derived folder, etc) and make sure to perform a clean before build.

X code Version 14.3 beta 3 (14E5215g)
Swift 5
Kingfisher 7.6.2
the issue was disappear after the app's build folder  in ~/Library/Developer/Xcode/DerivedData/  deleted

I have a same compiler error， Xcode version is 14.3  (14E222b)

I've a same error...  KFImageRenderer.swift:48:63 Initializer for conditional binding must have Optional type, not 'AnyView' after Xcode update to Version 14.3 (14E222b)

I have same error on the Xcode 14.3.

The related changes were already released as a part of 7.6.1. Any one encountering this please try to upgrade to the latest version.
(If you are using a package manager, make sure to either do a repo update or/and cache clearing to make sure to get the latest versions)

The related changes were already released as a part of 7.6.1. Any one encountering this please try to upgrade to the latest version.
(If you are using a package manager, make sure to either do a repo update or/and cache clearing to make sure to get the latest versions)

Thanks a lot. The 7.6.1 version solves my issue.

I'm experiencing this very same issue with the version 7.6.2 of Kingfisher after updating XCode to 14.3 stable.

The same shit was with Xcode 14.3. Was solved when Kingfisher was updated to 7.6.2 version.

authors: JetForMe MatHeartGaming OzanBG antonyfrolov argiad epodkorytov jackywpy onevcat


text:
Latest Docker Image does not work with CLI

Steps to repro:

flow emulator
docker run ghcr.io/onflow/fcl-dev-wallet:latest

The docker run seems to work fine, and yields : ready - started pm server 0.0.0.0:8701, url: http://localhost:8701
But running curl http://localhost:8701, yields not found.
Our only suspicion for why this is the case, is because we believe that the keys that our emulator-account is using are different than the keys that are in the config files in the latest image. But, this is surprising because running the docker command above gives a successful "ready" result.
We would greatly appreciate some help with getting this working!

hey @samwise2, I think you need to expose port with docker.
https://docs.docker.com/config/containers/container-networking/

Awesome, thanks @bluesign that worked! Can we get the README updated with:
docker run -p -p 8701:8701 ghcr.io/onflow/fcl-dev-wallet:latest so that people don't run into this in the future?

Or at least some comment on this

@samwise2 sure I think Flow Team will see the issue and they will update. Just incase I am tagging @10thfloor

Great, thanks

Looks like this has been addressed.

authors: bluesign justinbarry samwise2

repo: onflow/fcl-dev-wallet


text:
Refactor backend

Refactor backend implementation following the steps:

move emulator related functionality to emulator instead of backend ( there is no difference there )
emulator with go-sdk types can service flowkit and other consumers
we can rename the backend to something more meaningful, and use flow-go types there. ( as rest API and grpc API directly using that ) maybe backend can be 'adapter' ( adapting emulator to grpc and rest API )

cc @bluesign

@sideninja  I started this, but a few things came up to clear up.

Emulator has mixed usage of flow-go and go-sdk types ( especially block is flow-go typed ) I think this is because go-sdk doesn't have good block representation.
storage backend is using flow-go types.

This complicates the problem a bit, any ideas?

I feel that flow-emulator should be using native flow-go types all around the codebase (like it already does for most) and then we should have a package that would accept and return go-sdk types that can be used by codebases importing that directly.
I feel the backend could be refactored into blockchain, since a lot of things are already part of it, and they can use flow-go types. Then we could have an adapter layer that would consume and produce go-sdk types that would just wrap the blockchain interface.
But honestly this is really quick idea, I would have to dig more to have a better plan.

I feel that flow-emulator should be using native flow-go types all around the codebase (like it already does for most)

This part I agree 100%, go-sdk types are more like API response mapped. Not possible to extend them without confusing people.

I feel the backend could be refactored into blockchain, since a lot of things are already part of it, and they can use flow-go types.

Yeah as long as we use flow-go it is all good there.

we should have a package that would accept and return go-sdk types that can be used by codebases importing that directly.

This would be nice, but not sure, if it creates some limits for future. Imagine:

Let's say block, and when we expose emulator we wanted to expose View[0] from Block
we cannot add View to go-sdk.Block, then we would confuse people using it as AN client ( they will complain View is coming empty etc )

I think go-sdk types are a bit dead end to be honest for this reason. But I will do the flow-go type and blockchain-backend merge as a start.
[0]: View I gave as an example, maybe there is View in go-sdk Block, I don't recall now.

I think go-sdk types are a bit dead end to be honest for this reason.

The thing I worry is that there's a lot of added functionality Go SDK can support on their types, like build transactions, signing etc (that's not part of flow-go types and probably never will be) so if we want to make Go SDK easy to use it will probably have to have it's own types and somehow then those types needs to work with flow-emulator and other networks. We could possibly make that work in go-sdk too. Not sure yet.

@sideninja, I take another stab at this, and this time I think it is good.
Basically:

blockchain: flow-go types
adapter with blockchain: grpc and rest serving
backend with blockchain: go-sdk types interface  ( we can move this to go-sdk too )

What is missing:

logging ( where we should put the logging, adapter level seems the logical choice )
I think emulator has some missing info recently added, like blockID for transactionResult etc ( need to add at storage level )

@sideninja  I did this finally but there is a new problem here.
I made 2 adapters (sdk, grpc) working on Emulator interface ( Blockchain is our implementation )
Everything was good till I come to tests, as we moved a lot of stuff around, almost all tests have to be rewritten, but more than that, I think logic of the tests also have to change.
I need a bit guidance here about how to write the tests. Mock emulator then test? It seems a bit pointless, considering we have test for convert. I mean SDK layer is basically wrapping call to emulator, converting inputs and outputs. But I am a bit testing noob.
Also I need I think some deep-compare library if I mock emulator, ( I give let's say flow block, it will convert to sdk block, then I need to again convert it to flow block, but those objects are not comparable afaik )

@bluesign do you have a link so I can check the code to give better advice?

ah sorry @sideninja, I pushed now to https://github.com/bluesign/flow-emulator/tree/reorgBackend

@sideninja I need little help here with how to make testing.

I think this is a good approach. What specifically you need help with testing (sorry for late reply).

No worries @sideninja. Main problem I had was almost all tests has to rewritten.
Also for example some tests were seemed redundant; for example: if we have some function wrapper for emulator function, such as: get input, convert input, call emulator function, convert result, return result. When we have test for convert functions and emulator, it seems no sense to test this, but on the other hand it seems we should test this anyway.
In general I am a bit clueless how to write tests after refactor. ( probably need to rewrite most )

I think adapters should be tested by using a mocked version of the emulator, it should only test whether it adapts to the expected type, using the emulator mock to just return a simple type.
The emulator tests should mostly be reused from the transactions_test, script_test, account_test. I believe they should work by just replacing blockchain with emulator type and making sure correct types are used.
For generating emulator mocks in case of adapter tests you can use the https://github.com/vektra/mockery and you can use Go SDK for creating SDK types https://github.com/onflow/flow-go-sdk/blob/master/test/entities.go
For Flow Go types you can use fixtures here https://github.com/onflow/flow-go/blob/master/utils/unittest/fixtures.go
Let me know more specifically how I can help here.

thanks @sideninja, I will jump into this, I think I have some understanding now, I think better I ask for advice when some situation arises.

ok after 5 hours, I ended up with something as a starter: https://github.com/bluesign/flow-emulator/tree/reOrg
Missing adapter tests; SDK adapter test I somehow sandwiched into old blockchain tests. I felt like they should be ok but not sure. Coverage seems to increase 5-6%. ( I will dig into it )

I think that looks good generally. Blockchain tests were integration tests even before anyway. I would add unit tests on the adapter tho, especially the access by mocking the blockchain out (by the newly defined interface).

authors: bluesign sideninja

repo: onflow/flow-emulator


text:
bump flow-go version

Closes #???
Description

bump version to 683adb0b166b6c59097e831b672eb4b0bf964cd8
fix backward-incompatible change to NewScriptEnvironment function

For contributor use:

[x] Targeted PR against master branch
[ ] Linked to GitHub issue with discussion and accepted design OR link to spec that describes this work
[ ] Code follows the standards mentioned here
[ ] Updated relevant documentation
[ ] Re-reviewed Files changed in the GitHub PR explorer
[ ] Added appropriate labels

Codecov Report

Merging #311 (d41e201) into master (c09dfcb) will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #311      +/-   ##
==========================================
+ Coverage   49.06%   49.07%   +0.01%
==========================================
  Files          27       27
  Lines        3194     3195       +1
==========================================
+ Hits         1567     1568       +1
  Misses       1496     1496
  Partials      131      131

Flag
Coverage Δ

unittests
49.07% <100.00%> (+0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

blockchain.go
73.24% <100.00%> (+0.03%)
:arrow_up:

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

authors: codecov-commenter jordanschalm


text:
[due June 20] set up deployment logistics for the new doc site

Heroku vs fly.io ? TBD

Fly.io & redis setup for staging and prod.

authors: kerrywei srinjoyc


text:
ViewPager is not working for (androidx.viewpager.widget.ViewPager)

Android refactored import android.support.v4.view.ViewPager to androidx.viewpager.widget.ViewPager
So we can't use it anymore.
Will you fix your CircleIndicator.java?
If so, please change it ASAP.
Best regards,
Josh

Sorry, androidx is still in beta version.
You can fork this project and change it.

Now it is live

authors: Khosbayar hmedat ongakuer

repo: ongakuer/CircleIndicator


text:
[WIP] #943 - Split bundle via async imports

This is the first part of an improvement in startup time. Today, we need the browser to load the entire large bundle.js before it can start rendering.
This change leverages the async import functionality, along with webpack's ability to chunk along the async boundaries, such that we can kick start some operations and parallelize the loading.
This is a first step, but helps to improve loading.

There may be some duplication across bundles - should look at incorporating the CommonChunksPlugin as well.

@bryphe may or may not be relevant to what your trying to do here or potentially a rabbit hole, though seemed worth mentioning a new js bundler called Parcel it simplifies a lot of what webpack does through painful configuration and endless plugins, it supports TS and Less

Ah ya, interesting! It does look easy and straightforward.
I'm wondering too if we can just avoid making bundles altogether - just point Electron to the output index.js. This would save us a lot of compile time, and might actually be more efficient in terms of loading. The version of Node that Electron has today unfortunately doesn't support the import method, but once Electron 2 is out, it might be worth profiling w/o any bundler.

There’s also electron-link that might help with improving startup time.

electron-link is a node module that takes a JavaScript file (typically the entry point of an application) and a list of modules that need to be required lazily (see Atom's build scripts for an example). Then, starting from that file, it traverses the entire require graph and replaces all the forbidden require calls in each file with a function that will be called at runtime. The output is a single script containing the code for all the modules reachable from the entry point. This file can be then supplied to mksnapshot to generate a snapshot blob.

Thanks for the pointer, @bruchmann ! We're tracking leveraging v8 snapshots in #381 , just added some context there - electron-link looks like it would be very helpful for that.

authors: Akin909 bruchmann bryphe

repo: onivim/oni


text:
Explorer: Add right-click context menu

We should have a context menu to make it easier to interact with the file tree, allowing operations like:

Rename file / folder
Delete file / folder
Create file / folder

+1
I was struggling to figure how to delete a file.
I only know how to create files in vim :(

We should have a context menu to make it easier to interact with the file tree, allowing operations like:

Rename file / folder
Delete file / folder
Create file / folder

@bryphe In mean time adding some information in the docs would be useful?
https://onivim.github.io/docs/using-onivim/working-with-files

+1 looking for how to create a file :)

+1 looking for how to create a file :)

I was expecting dd to delete the currently selected file, i to enter insert mode to change it's name, etc etc

authors: bryphe chinwobble dfroger guledali snoblenet


text:
Try to manual install but every time I got this error

error unable to fetch esy-fzy@github:bryphe/esy-fzy#301dbf6:
source: github:bryphe/esy-fzy#301dbf6
error:
error: command failed: 'git' 'clone' 'https://github.com/bryphe/esy-fzy.git' '/home/user/oni2/_esy/default/tmp/esy-0795a3'
stderr:
Cloning into '/home/user/oni2/_esy/default/tmp/esy-0795a3'...
fatal: unable to access 'https://github.com/bryphe/esy-fzy.git/': Could not resolve host: github.com
                                                          stdout:

                                                            fetching dist: github:bryphe/esy-fzy#301dbf6

error: installation error
fetching esy-fzy@github:bryphe/esy-fzy#301dbf6
esy: exiting due to errors above

Can you try with -vvv (verbose flag) try the command manually. Have you updated esy (I recall a similar error before) ? Try this version : Et7f3/reason-fzy#26efb82d45ec8846c6bf8b072c1eccd31a7457ce (master + a small patch)


text:
Fix #608: Input: Home / End / Insert buttons aren't working

My attempt to Fix #608.
I have not been able to test the INSERT key because I'm not sure how to simulate it on my mac 😆

Looks great @tatchi , thank you!
I tested 'Insert' on Windows with your changes - worked perfectly 😄

authors: bryphe tatchi


text:
fetch

Uploading explain-git-with-d3-master1.zip…

fetch

fetch


text:
Parallel code for quantization

Added a parallel scheme for reduction (min & max) of a tensor to a single scalar.
the scheme is as follows
for(t=0..TNUM) { // parallel for TNUM threads
  reduce min max for chance input[lb...ub] into min & max[t] where lb=t * chunk, ub=min(UB, (t+1)* chunk
}
reduce min & max[0...TNUM] into min_scalar and max_scalar

Now input is flattened to one 1D. If the dim[0] of flattened input is runtime, then chunk = dim[0]/TNUM is also runtime.
Then in the reduce min max inside the parallel region, we compute the lb = t * chunk where both are runtime. This is not affine (affine is only affine under the multiplication of a dim with a literal constant).
Thus we need a reduce SIMD that works with SCF as well as the normal Krnl.
For this, I needed to further simplify the Dialect builder so that they are more uniform, added a MemRefBuilder load and store (because we don't want krnl constructs inside the Dialect/MLIR sub directory).
I then added a simdIterateIE and simdReduceIE that works with an templated builder for the loops (Krnl or SCF) and scalar mem operations (Krnl or MemRef).
All of the simd code gen in elementwise and reduce uses this new scheme, except for one in Reduce.cpp which needs the unrolling of VL outer loop iteration so as to use the VL to VL reduction scheme necessary on machines (such as Z for floating point) that have no horizontal SIMD reduction operation.
Note that the new SIMD support works with arbitrary array length, by generating SIMD code for most loop iterations, followed by a small loop for the trip-count % VL leftover iterations.

Speedup achieved
old vs new-simd (sequential) ~ 1.4-1.7x depending on shape size & static/dynamic shape
old vs new-simd-paralllel ~ 3.2-4x depending on shape size  & static/dynamic shape

Jenkins Linux ppc64le Build #14518 [push] Parallel code for quanti... started at 13:14

Jenkins Linux amd64 Build #15488 [push] Parallel code for quanti... started at 12:03

Jenkins Linux s390x Build #15495 [push] Parallel code for quanti... started at 13:03

Jenkins Linux amd64 Build #15488 [push] Parallel code for quanti... passed after 1 hr 30 min

Jenkins Linux s390x Build #15495 [push] Parallel code for quanti... passed after 2 hr 9 min

Jenkins Linux ppc64le Build #14518 [push] Parallel code for quanti... passed after 2 hr 22 min

authors: AlexandreEichenberger jenkins-droid

repo: onnx/onnx-mlir


text:
Feature request: LogManagerFactory.DefaultConfiguration.AllTargets

It would be nice to have a method like
LogManagerFactory.DefaultConfiguration.AllTargets
which would basically NLog's method for internal GetTargets; or perhaps event having that as public.
Reason: I would like to gracefully flush all logs at shutdown; so it makes sense to find all the targets from configuration and issuing flush command one at a time to ensure no multiple writing problems.
PS: For Mono, suggested profile to use is 158;

This exists on the LoggingConfiguration as GetTargets()

authors: onovotny topsites

repo: onovotny/MetroLog


text:
trying take redeemable ont. Fale

trying take redeemable ont. Fale.
Please input gasLimit=>20000 and gas Price=> 2500 ??? where??? no settings here

Download latest version OWallet - problem is gone.

repo: ontio/OWallet


text:
Add Apache Beam.

It's a new Apache incubation project for Google Dataflows and more.

Thank you, @onurakpolat !

repo: onurakpolat/awesome-bigdata


text:
🛑 Pagure.io is down

In 729c01a, Pagure.io (https://pagure.io/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Pagure.io is back up in 807462b after 23 minutes.

repo: onuralpszr/uptime


text:
TableSet key typing could be moved into MappedSequence

This would allow for column name and row name typing, which would in turn make Transpose possible again

This is a very complicated refactor for nebulous benefits. Not for 1.0.

I'm not sure what the hell I meant by this but it sounds crazy. Closing.

repo: onyxfish/agate


text:
Fix release name

Releases should be named with featctl instead of oomstore

@wfxr can we close this?

@YikSanChan yes

authors: YikSanChan wfxr

repo: oom-ai/oomstore


text:
llm-faqgen: Fix python module version conflict issue

Description
Fix compatibility issue between latest langserve 0.3.0 and langchain 0.1.16.
Issues
#700
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.

PR #704 seems to have a more complete fix

repo: opea-project/GenAIComps


text:
Upgrade terraform to 1.0.0

Overview
A terraform upgrade was necessary for a desired feature surfaced from work in another PR in the parent issue.
Connects #1998
Notes
This was a multi-step upgrade that involved jumping through multiple versions to minimize the amount of code changes necessary at each step. Due to the nature of the upgrade, the terraform code was applied at each step, so code covered by this PR is currently in place on the OSH staging environment.
Testing Instructions
This code is currently deployed to staging, so testing should be done as a verification of the changes.

ensure that jenkins completed successfully
review the console output in jenkins to verify that nothing was changed that affects the functioning of the site
navigate the staging site to ensure correct functionality
submit a list to ensure that submitted lists are processing correctly.

Checklist

[ ] fixup! commits have been squashed
[ ] CI passes after rebase
[ ] CHANGELOG.md updated with summary of features or fixes, following Keep a Changelog guidelines
[x] This PR is targeted at the correct branch (develop vs. ogr/develop)
[ ] If this PR applies to both OAR and OGR a companion PR has been created

a warning in the terraform upgrade flagged these five variables in the .tfvars file because they're defined, but not used anywhere. We've commented out the 5 relevant lines for now:
tile_ecs_desired_count
tile_ecs_deployment_min_percent
tile_ecs_deployment_max_percent
tile_fargate_cpu
tile_fargate_memory

I believe that the tile_ variables were related to this experimental PR that was never put into production https://github.com/open-apparel-registry/open-apparel-registry/pull/1107

I changed the title of the PR to Upgrade terraform to 1.1.9 to more accurately reflect the upgrade.

authors: jwalgran nanotubing


text:
added policies

Signed-off-by: Christian Stark cstark@cstark.muc.csb

please delay with review as I plan to add more

/hold

authors: ch-stark gparvin


text:
Remediate Vulnerabilities [WIP]

https://github.com/open-cluster-management/backlog/issues/4420

Closing as stale

repo: open-cluster-management/search-operator


text:
add docker config to serve UI from curator express server

I tried doing this using the existing docker files for both curator API and UI but didn't manage to compose them nicely.
Having another dockerfile at the curator/ directory level makes that trivial.
I added a prod/ directory similar to the dev/ one to run the stack.
I didn't use another override like docker-compose.prod.yml as we can't "remove" services from the template (the curatorui service and mongo will be gone from prod compose setup).
Right now it still has the mongo image so I could test e2e but we should change that to talk to our atlas instance (I'm asking Kelly for creds).
One last change is to only setup the react proxy if REACT_APP_PROXY_URL is specified, it's unused in prod anyway.

 Tune docker images for production serving

As per Slack discussion, this is ready for review.

repo: open-covid-data/healthmap-gdo-temp


text:
feat: migrate flagd startup argument to sources flag

Prerequisite
Release of flagd 0.4.6
This PR
Fixes #389
This PR migrate flagd side-car startup arguments from uri (flagd start --uri <sync-source>) to sources (flagd start --sources <sync-source>).
More on the new sources based configuration options [1]
With this option, I have introduced the grpc sync option to OFO and other grpc sync-provider options.
follow-up
Discussion - type SourceConfig can be referred from OFO dependency and avoid duplication at flagd
[1] - https://github.com/open-feature/flagd/blob/main/docs/configuration/configuration.md

Thanks for circling back to this after the related flagd changes. I tried to find something to be improved but I can't 😅 . LGTM.

Thank you :)

repo: open-feature/open-feature-operator


text:
Add batch_size to create_dataloader

@youngdjn mentioned that it would be helpful to control the batch size, especially when we want to fully utilize the GPU. This should be a pretty easy addition to create_data_loader but may require some attention downstream to properly handle batches of length greater than one.

Completed in pull request #31


text:
Build placeholder pages for Phase 2B YFF site

Homepage

[x] home/v2.njk, with url of /v2/
[x] Move /index.njk to home/v1.njk with url of /

Create new pages with no content (this page left intentionally blank):

[x] dashboard/index.njk

[x] dashboard/qlfs/index.njk
[x] dashboard/neet/index.njk
[x] dashboard/economics/index.njk

[x] projects/cff/index.njk
[x] projects/toolkit.njk (should this be projects, or tools?)
[x] topic/index.njk

Yes - this is all good - I've moved the toolkit/ folder out of projects/cff/ where it looked like it was added by mistake.

repo: open-innovations/yff-data


text:
Log fixes

This patchset fixes some misc issues in the log code.

This looks good.

authors: lxbsz mikechristie

repo: open-iscsi/tcmu-runner


text:
glfs: add writesame support

This will invoke zerro fill API due to there has no truely write
same routine yet. Since the writesame emulator in tcmur will do
the same, so it shouldn't be a problem of this.
Signed-off-by: Xiubo Li xiubli@redhat.com

@mikechristie @pkalever @bgly
Updated it, please review.
2018-11-14 10:59:53.261 2258 [DEBUG_SCSI_CMD] tcmu_print_cdb_info:1219 glfs/block0: 93 0 0 0 0 0 0 0 0 0 0 0 28 0 0 0
2018-11-14 10:59:53.261 2258 [DEBUG] handle_writesame_check:673 glfs/block0: Start lba: 0, number of lba: 10240, last lba: 10239
2018-11-14 10:59:53.261 2258 [WARN] tcmu_glfs_writesame:764 glfs/block0: Received none zeroed data, will fall back to writesame emulator instead.
2018-11-14 10:59:53.261 2258 [DEBUG] handle_writesame_check:673 glfs/block0: Start lba: 0, number of lba: 10240, last lba: 10239
2018-11-14 10:59:53.265 2258 [DEBUG] handle_writesame:759 glfs/block0: First lba: 0, write lbas: 2048
2018-11-14 10:59:53.336 2258 [DEBUG] handle_writesame_cbk:611 glfs/block0: Next lba: 2048, write lbas: 2048
2018-11-14 10:59:53.377 2258 [DEBUG] handle_writesame_cbk:611 glfs/block0: Next lba: 4096, write lbas: 2048
2018-11-14 10:59:53.401 2258 [DEBUG] handle_writesame_cbk:611 glfs/block0: Next lba: 6144, write lbas: 2048
2018-11-14 10:59:53.424 2258 [DEBUG] handle_writesame_cbk:606 glfs/block0: Last lba: 8192, write lbas: 2048
2018-11-14 10:59:53.449 2258 [DEBUG_SCSI_CMD] tcmu_print_cdb_info:1219 glfs/block0: 0 0 0 0 0 0
2018-11-14 10:59:53.450 2258 [DEBUG_SCSI_CMD] tcmu_print_cdb_info:1219 glfs/block0: 9e 10 0 0 0 0 0 0 0 0 0 0 0 20 0 0


text:
No character display limit for column description

There should be a minimum set of characters to display. For the rest of the content, there should be 'show more' or other similar pointers. cc @shahsank3t @harshach
https://user-images.githubusercontent.com/83201188/148343076-88f465ee-f40f-4881-87b2-d55e75edac16.mov

Can the row be expanded like an accordion when one clicks show more?
I wonder if this works for showing more details such as the Data Quality results for columns

repo: open-metadata/OpenMetadata


text:
When I run "python test.py --xxx", I got CUDA problem.

Hi! Thanks for your excellent work!
When I run "python test.py --cfg_file cfgs/kitti_models/pv_rcnn.yaml --batch_size 4 --ckpt pv_rcnn_8369.pth", I got CUDA problem, details as follows.
my first enviroments are:

cuda=10.0
pytorch=1.1 (I have tried to change to 1.2 or ohther versions, but I got same problem)
spconv=1.0

then I got problem: RuntimeError: CUDA error: invalid argument, as #69
INFO  *************** EPOCH 8369 EVALUATION *****************
eval:   0%|                                             | 0/943 [00:00<?, ?it/s]Traceback (most recent call last):
  File "test.py", line 190, in <module>
    main()
  File "test.py", line 186, in main
    eval_single_ckpt(model, test_loader, args, eval_output_dir, logger, epoch_id, dist_test=dist_test)
  File "test.py", line 61, in eval_single_ckpt
    result_dir=eval_output_dir, save_to_file=args.save_to_file
  File "/home/ease/Documents/OpenLidarPerceptron/tools/eval_utils/eval_utils.py", line 57, in eval_one_epoch
    pred_dicts, ret_dict = model(batch_dict)
  File "/home/ease/anaconda3/envs/siammask/lib/python3.7/site-packages/torch/nn/modules/module.py", line 493, in __call__
    result = self.forward(*input, **kwargs)
  File "/home/ease/Documents/OpenLidarPerceptron/pcdet/models/detectors/pv_rcnn.py", line 11, in forward
    batch_dict = cur_module(batch_dict)
  File "/home/ease/anaconda3/envs/siammask/lib/python3.7/site-packages/torch/nn/modules/module.py", line 493, in __call__
    result = self.forward(*input, **kwargs)
  File "/home/ease/Documents/OpenLidarPerceptron/pcdet/models/backbones_3d/spconv_backbone.py", line 99, in forward
    x = self.conv_input(input_sp_tensor)
  File "/home/ease/anaconda3/envs/siammask/lib/python3.7/site-packages/torch/nn/modules/module.py", line 493, in __call__
    result = self.forward(*input, **kwargs)
  File "/home/ease/anaconda3/envs/siammask/lib/python3.7/site-packages/spconv/modules.py", line 127, in forward
    input.features = module(input.features)
  File "/home/ease/anaconda3/envs/siammask/lib/python3.7/site-packages/torch/nn/modules/module.py", line 493, in __call__
    result = self.forward(*input, **kwargs)
  File "/home/ease/anaconda3/envs/siammask/lib/python3.7/site-packages/torch/nn/modules/activation.py", line 99, in forward
    return F.relu(input, inplace=self.inplace)
  File "/home/ease/anaconda3/envs/siammask/lib/python3.7/site-packages/torch/nn/functional.py", line 943, in relu
    result = torch.relu(input)
RuntimeError: CUDA error: invalid argument
eval:   0%|                                             | 0/943 [00:01<?, ?it/s]

Then I read other ideas about the spconv version, futher changed my enviroments:

cuda=10.0
pytorch=1.4
spconv=1.1

and I got problem assert block_filtering is False AssertionError, as #21
INFO  *************** EPOCH 7940 EVALUATION *****************
eval:   0%|                                             | 0/943 [00:00<?, ?it/s]Traceback (most recent call last):
  File "test.py", line 190, in <module>
    main()
  File "test.py", line 186, in main
    eval_single_ckpt(model, test_loader, args, eval_output_dir, logger, epoch_id, dist_test=dist_test)
  File "test.py", line 61, in eval_single_ckpt
    result_dir=eval_output_dir, save_to_file=args.save_to_file
  File "/home/ease/Documents/OpenLidarPerceptron/tools/eval_utils/eval_utils.py", line 54, in eval_one_epoch
    for i, batch_dict in enumerate(dataloader):
  File "/home/ease/anaconda3/envs/siammask/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 345, in __next__
    data = self._next_data()
  File "/home/ease/anaconda3/envs/siammask/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 856, in _next_data
    return self._process_data(data)
  File "/home/ease/anaconda3/envs/siammask/lib/python3.7/site-packages/torch/utils/data/dataloader.py", line 881, in _process_data
    data.reraise()
  File "/home/ease/anaconda3/envs/siammask/lib/python3.7/site-packages/torch/_utils.py", line 394, in reraise
    raise self.exc_type(msg)
AssertionError: Caught AssertionError in DataLoader worker process 0.
Original Traceback (most recent call last):
  File "/home/ease/anaconda3/envs/siammask/lib/python3.7/site-packages/torch/utils/data/_utils/worker.py", line 178, in _worker_loop
    data = fetcher.fetch(index)
  File "/home/ease/anaconda3/envs/siammask/lib/python3.7/site-packages/torch/utils/data/_utils/fetch.py", line 44, in fetch
    data = [self.dataset[idx] for idx in possibly_batched_index]
  File "/home/ease/anaconda3/envs/siammask/lib/python3.7/site-packages/torch/utils/data/_utils/fetch.py", line 44, in <listcomp>
    data = [self.dataset[idx] for idx in possibly_batched_index]
  File "/home/ease/Documents/OpenLidarPerceptron/pcdet/datasets/kitti/kitti_dataset.py", line 372, in __getitem__
    data_dict = self.prepare_data(data_dict=input_dict)
  File "/home/ease/Documents/OpenLidarPerceptron/pcdet/datasets/dataset.py", line 131, in prepare_data
    data_dict=data_dict
  File "/home/ease/Documents/OpenLidarPerceptron/pcdet/datasets/processor/data_processor.py", line 78, in forward
    data_dict = cur_processor(data_dict=data_dict)
  File "/home/ease/Documents/OpenLidarPerceptron/pcdet/datasets/processor/data_processor.py", line 56, in transform_points_to_voxels
    voxels, coordinates, num_points = voxel_generator.generate(points)
  File "/home/ease/anaconda3/envs/siammask/lib/python3.7/site-packages/spconv/utils/__init__.py", line 164, in generate
    or self._max_voxels, self._full_mean)
  File "/home/ease/anaconda3/envs/siammask/lib/python3.7/site-packages/spconv/utils/__init__.py", line 65, in points_to_voxel
    assert block_filtering is False
AssertionError
eval:   0%|                                             | 0/943 [00:00<?, ?it/s]

Now, I am confused with the configuration, can you give me some suggestions? Thanks!

This repo only support spconv 1.0, and currently this repo doesn't support spconv 1.1 since it costs more GPU memory than spconv 1.0.
The PyTorch version should be 1.1 or 1.2.
I guess perhaps there is something wrong in your installation of spconv.
Maybe you could step by step to check the status of tensor in x = self.conv_input(input_sp_tensor) in spconv_backbone.py

maybe this thread can help

Thanks for your both help, finally solved the problem.
I wonder it remains error cache in my previous enviroment, then I just create a new conda enviroment followed with #72 step by step, finally fixed it.
Thanks again!

repo: open-mmlab/OpenPCDet


text:
fix bug for 'TypeError: argument of type 'method' is not iterable'

When I run 'mim install mmdet', I got this:
ERROR: Exception:
Traceback (most recent call last):
  File "/root/anaconda3/envs/pytorch/lib/python3.11/site-packages/pip/_internal/cli/base_command.py", line 169, in exc_logging_wrapper
    status = run_func(*args)
             ^^^^^^^^^^^^^^^
  File "/root/anaconda3/envs/pytorch/lib/python3.11/site-packages/pip/_internal/cli/req_command.py", line 248, in wrapper
    return func(self, options, args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/anaconda3/envs/pytorch/lib/python3.11/site-packages/pip/_internal/commands/install.py", line 377, in run
    requirement_set = resolver.resolve(
                      ^^^^^^^^^^^^^^^^^
  File "/root/anaconda3/envs/pytorch/lib/python3.11/site-packages/pip/_internal/resolution/resolvelib/resolver.py", line 92, in resolve
    result = self._result = resolver.resolve(
                            ^^^^^^^^^^^^^^^^^
  File "/root/anaconda3/envs/pytorch/lib/python3.11/site-packages/pip/_vendor/resolvelib/resolvers.py", line 546, in resolve
    state = resolution.resolve(requirements, max_rounds=max_rounds)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/anaconda3/envs/pytorch/lib/python3.11/site-packages/pip/_vendor/resolvelib/resolvers.py", line 427, in resolve
    failure_causes = self._attempt_to_pin_criterion(name)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/anaconda3/envs/pytorch/lib/python3.11/site-packages/pip/_vendor/resolvelib/resolvers.py", line 239, in _attempt_to_pin_criterion
    criteria = self._get_updated_criteria(candidate)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/anaconda3/envs/pytorch/lib/python3.11/site-packages/pip/_vendor/resolvelib/resolvers.py", line 229, in _get_updated_criteria
    for requirement in self._p.get_dependencies(candidate=candidate):
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/anaconda3/envs/pytorch/lib/python3.11/site-packages/pip/_internal/resolution/resolvelib/provider.py", line 244, in get_dependencies
    return [r for r in candidate.iter_dependencies(with_requires) if r is not None]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/anaconda3/envs/pytorch/lib/python3.11/site-packages/pip/_internal/resolution/resolvelib/provider.py", line 244, in <listcomp>
    return [r for r in candidate.iter_dependencies(with_requires) if r is not None]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/anaconda3/envs/pytorch/lib/python3.11/site-packages/pip/_internal/resolution/resolvelib/candidates.py", line 241, in iter_dependencies
    requires = self.dist.iter_dependencies() if with_requires else ()
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/anaconda3/envs/pytorch/lib/python3.11/site-packages/mim/commands/install.py", line 247, in patched_iter_dependencies
    if 'mim' in self.iter_provided_extras:
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: argument of type 'method' is not iterable

Then I found a type bug in 'path/to/mim/commands/install.py' line 247:
change
if 'mim' in self.iter_provided_extras:

to
if 'mim' in str(self.iter_provided_extras):

Then it works for me.

same error for me. I'll create a pr for this

authors: danielhonies wangpinzhi

repo: open-mmlab/mim


text:
Install Denseflow failed. CMake Error: Parse error in cache file ../CMakeCache.txt on line 313. Offending entry: /*

Environment: Opencv-2.4.13, cuda-8.0, cmake-3.8, gcc-5.4, ffmpeg-4.2.1
When I execute make -j, it comes out that
CMake Error: Parse error in cache file mypath/dense_flow/build/CMakeCache.txt on line 313. Offending entry: /*
CMake Error: Parse error in cache file mypath/dense_flow/build/CMakeCache.txt on line 314. Offending entry: zipconf.h -- platform specific include file
CMake Error: Parse error in cache file mypath/dense_flow/build/CMakeCache.txt on line 316. Offending entry: This file was generated automatically by CMake
CMake Error: Parse error in cache file mypath/dense_flow/build/CMakeCache.txt on line 317. Offending entry: based on ../cmake-zipconf.h.in.
CMake Error: Parse error in cache file mypath/dense_flow/build/CMakeCache.txt on line 318. Offending entry: /
CMake Error: Parse error in cache file mypath/dense_flow/build/CMakeCache.txt on line 325. Offending entry: / #undef ZIP_STATIC */
CMake Error: Parse error in cache file mypath/dense_flow/build/CMakeCache.txt on line 333. Offending entry: typedef int8_t zip_int8_t;
CMake Error: Parse error in cache file mypath/dense_flow/build/CMakeCache.txt on line 334. Offending entry: typedef uint8_t zip_uint8_t;
CMake Error: Parse error in cache file mypath/dense_flow/build/CMakeCache.txt on line 335. Offending entry: typedef int16_t zip_int16_t;
CMake Error: Parse error in cache file mypath/dense_flow/build/CMakeCache.txt on line 336. Offending entry: typedef uint16_t zip_uint16_t;
CMake Error: Parse error in cache file mypath/dense_flow/build/CMakeCache.txt on line 337. Offending entry: typedef int32_t zip_int32_t;
CMake Error: Parse error in cache file mypath/dense_flow/build/CMakeCache.txt on line 338. Offending entry: typedef uint32_t zip_uint32_t;
CMake Error: Parse error in cache file mypath/dense_flow/build/CMakeCache.txt on line 339. Offending entry: typedef int64_t zip_int64_t;
CMake Error: Parse error in cache file
mypath/dense_flow/build/CMakeCache.txt on line 340. Offending entry: typedef uint64_t zip_uint64_t;
-- Boost version: 1.53.0
-- Found the following Boost libraries:
--   python
-- Configuring incomplete, errors occurred!
See also "mypath/dense_flow/build/CMakeFiles/CMakeOutput.log".
See also "mypath/dense_flow/build/CMakeFiles/CMakeError.log".
Anyone came across with the same error with me?

We recommend using our new version of denseflow, which is more efficient and easy to install. You can use setup to easily install all requirements(Thanks @innerlee for the contribution).

authors: kennymckormick spyflying

repo: open-mmlab/mmaction


text:
GPU memory unbalanced when training

I have encountered the problem of gpu memory imbalance when I train images containing a large number of objects (about 50 ~ 600).  I also referred to the solution of https://github.com/open-mmlab/mmdetection/issues/2665 to limit the size of box and specify the parameter gpu_assign_thr to 300, but it does not work in some cases, and it will greatly reduce the speed. Are there any other solutions, and other suggestions? Thanks!

You may reduce gpu_assign_thr and trade off between speed and memory, or use a GPU with larger memory if there are too many gts.

You may reduce gpu_assign_thr and trade off between speed and memory, or use a GPU with larger memory if there are too many gts.

Thanks for your reply. In fact, through further experiments, I found that the cause of OOM is that when the input image is too large, the number of anchor boxes (bboxes) increases significantly, which makes the matrix : [gt_bboxes, bboxes] in bbox_overlaps too large. Compared to put the calculations on the CPU, I tried to put all calculations in assign function on a separate GPU, but the speed is still unacceptable. In addition to adjusting anchor-related parameters, are there any other optimization methods? Thanks!

authors: BubbleSai hellock

repo: open-mmlab/mmdetection


text:
How to choose the soft_nms method 'Linear' or 'Gaussian'

How to choose the soft_nms method 'Linear' or 'Gaussian'?

Add method='gaussian' in the config. See here for supported arguments.

SO if do not add method='gaussian' , is using linear？


text:
Add augmentations which only transform image (e.g. Sharpness, Equalize, Color) in process.

This PR implements augmentations which only transform image (e.g. Sharpness, Equalize, Color) in process.

@v-qjqs
There is conflict now. Please resolve the conflict.

authors: v-qjqs xvjiarui


text:
visualization failed on headless server

Thanks for your error report and we appreciate it a lot.
Checklist

I have searched related issues but cannot get the expected help.
The bug has not been fixed in the latest version.

Describe the bug
visualization failed on headless server
Reproduction

What command or script did you run?

python3 demo/pcd_demo.py \
  demo/data/kitti/000008.bin"  \
  configs/pointpillars/pointpillars_hv_secfpn_8xb6-160e_kitti-3d-car.py \
  hv_pointpillars_secfpn_6x8_160e_kitti-3d-car_20220331_134606-d42d15ed.pth

Did you make any modifications on the code or config? Did you understand what you have modified?
No
What dataset did you use?

Environment

Please run python mmdet3d/utils/collect_env.py to collect necessary environment information and paste it here.

sys.platform: linux
Python: 3.8.13 (default, Mar 28 2022, 11:38:47) [GCC 7.5.0]
CUDA available: True
numpy_random_seed: 2147483648
GPU 0: NVIDIA GeForce RTX 3090
CUDA_HOME: /usr/local/cuda
NVCC: Cuda compilation tools, release 11.3, V11.3.109
GCC: gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
PyTorch: 1.10.0+cu113
PyTorch compiling details: PyTorch built with:
  - GCC 7.3
  - C++ Version: 201402
  - Intel(R) Math Kernel Library Version 2020.0.0 Product Build 20191122 for Intel(R) 64 architecture applications
  - Intel(R) MKL-DNN v2.2.3 (Git Hash 7336ca9f055cf1bfa13efb658fe15dc9b41f0740)
  - OpenMP 201511 (a.k.a. OpenMP 4.5)
  - LAPACK is enabled (usually provided by MKL)
  - NNPACK is enabled
  - CPU capability usage: AVX512
  - CUDA Runtime 11.3
  - 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_70,code=sm_70;-gencode;arch=compute_75,code=sm_75;-gencode;arch=compute_80,code=sm_80;-gencode;arch=compute_86,code=sm_86
  - CuDNN 8.2
  - Magma 2.5.2
  - Build settings: BLAS_INFO=mkl, BUILD_TYPE=Release, CUDA_VERSION=11.3, CUDNN_VERSION=8.2.0, CXX_COMPILER=/opt/rh/devtoolset-7/root/usr/bin/c++, CXX_FLAGS= -Wno-deprecated -fvisibility-inlines-hidden -DUSE_PTHREADPOOL -fopenmp -DNDEBUG -DUSE_KINETO -DUSE_FBGEMM -DUSE_QNNPACK -DUSE_PYTORCH_QNNPACK -DUSE_XNNPACK -DSYMBOLICATE_MOBILE_DEBUG_HANDLE -DEDGE_PROFILER_USE_KINETO -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, LAPACK_INFO=mkl, PERF_WITH_AVX=1, PERF_WITH_AVX2=1, PERF_WITH_AVX512=1, TORCH_VERSION=1.10.0, USE_CUDA=ON, USE_CUDNN=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.11.0+cu113
OpenCV: 4.5.5
MMEngine: 0.7.2
MMDetection: 3.0.0
MMDetection3D: 1.1.0+47e56e1
spconv2.0: False

You may add addition that may be helpful for locating the problem, such as

How you installed PyTorch [e.g., pip, conda, source]
Other environment variables that may be related (such as $PATH, $LD_LIBRARY_PATH, $PYTHONPATH, etc.)

Error traceback
If applicable, paste the error trackback here.
[Open3D WARNING] GLFW Error: X11: The DISPLAY environment variable is missing
[Open3D WARNING] Failed to initialize GLFW
Traceback (most recent call last):
  File "demo/pcd_demo.py", line 64, in <module>
    main(args)
  File "demo/pcd_demo.py", line 50, in main
    visualizer.add_datasample(
  File "/opt/conda/envs/torch1.10.0/lib/python3.8/site-packages/mmengine/dist/utils.py", line 360, in wrapper
    return func(*args, **kwargs)
  File "/root/workspace/mmdetection3d/mmdet3d/visualization/local_visualizer.py", line 754, in add_datasample
    pred_data_3d = self._draw_instances_3d(data_input,
  File "/root/workspace/mmdetection3d/mmdet3d/visualization/local_visualizer.py", line 575, in _draw_instances_3d
    self.set_points(points, pcd_mode=2)
  File "/opt/conda/envs/torch1.10.0/lib/python3.8/site-packages/mmengine/dist/utils.py", line 360, in wrapper
    return func(*args, **kwargs)
  File "/root/workspace/mmdetection3d/mmdet3d/visualization/local_visualizer.py", line 197, in set_points
    self.o3d_vis.get_render_option().point_size = points_size
AttributeError: 'NoneType' object has no attribute 'point_size'

Bug fix
If you have already identified the reason, you can provide the information here. If you are willing to create a PR to fix it, please also leave a comment here and that would be much appreciated!

This bug is caused by the X display server missing on your server. It has been fixed on the latest dev-1.x.

Great. But when do we merge dev-1.x to main branch?

It's about two weeks later.


text:
Does the inconsistent order of normalized channels and image channels affect the results of the self-supervised models?

Hi @fangyixiao18 @Jiahao000 @XiaohangZhan @xieenze @YuanLiuuuuuu
As reported in this issue, BGR used in pretraining but RGB used in downstream tasks.
However, I found another mistake that in the configs, the order of the values for normalization are also wrong. e.g., in moco v2, the order of mean and std are follow RGB, while the image read order is BGR by default.
Does the inconsistent order of normalized channels and image channels affect the results of the self-supervised models? If so, do we need to re-train all the self-supervised models with correct normalization?

Yes, this bug will affect the performance of the model, but the impact is marginal. Currently, we are re-training all these models in MMSelfSup and will release all updated checkpoints as soon as possible.

Yes, this bug will affect the performance of the model, but the impact is marginal. Currently, we are re-training all these models in MMSelfSup and will release all updated checkpoints as soon as possible.

Glad to know that. Will all future versions of mmselfsup follow the channel read order of RGB? I noticed that the default setting in mmcv is BGR

Glad to know that. Will all future versions of mmselfsup follow the channel read order of RGB? (even using mmcv transforms instead of torchvision) I noticed that the default setting in mmcv is BGR
Yes，we will follow the channel read order of RGB. As you mentioned, the config files of MMDet or MMSeg are using RGB to train the models, we will keep the consistency with other projects.

authors: YuanLiuuuuuu fangyixiao18 mitming

repo: open-mmlab/mmselfsup


text:
solve memory leak by limited implementation

Thanks for your contribution and we appreciate it a lot. The following instructions would make your pull request more healthy and more easily get feedback. If you do not understand some items, don't worry, just make the pull request and seek help from maintainers.
Motivation
Solve the memory leak when loading ImageNet-21k, however, this implementation is limited since cannot load the labels. But the key to solve this issue is change python.list into np.string. For more details please refer to https://github.com/open-mmlab/mmselfsup/issues/217
This modify works for me on ImageNet-21k with many algorithms, which reduce the memory consume by a large margin and avoid the memory leak under standard 8-gpu machine.
Modification
Please briefly describe what modification is made in this PR.
BC-breaking (Optional)
Does the modification introduce changes that break the backward compatibility of the downstream repositories?
If so, please describe how it breaks the compatibility and how the downstream projects should modify their code to keep compatibility with this PR.
Use cases (Optional)
If this PR introduces a new feature, it is better to list some use cases here and update the documentation.
Checklist
Before PR:

[ ] Pre-commit or other linting tools are used to fix the potential lint issues.
[ ] Bug fixes are fully covered by unit tests, the case that causes the bug should be added in the unit tests.
[ ] The modification is covered by complete unit tests. If not, please add more unit test to ensure the correctness.
[ ] The documentation has been modified accordingly, like docstring or example tutorials.

After PR:

[ ] If the modification has potential influence on downstream or other related projects, this PR should be tested with those projects, like MMDet or MMSeg.
[ ] CLA has been signed and all committers have signed the CLA in this PR.

Thank you for your contribution！We plan to address this PR in our next released version.

Thank you for your contribution！We plan to address this PR in our next released version.

Glad to know that

We have already created a new branch, dev_v0.8.0, for next released version. Please re-submit a PR to merge all your modifications to that branch as soon as possible. Thanks a lot !

We have already created a new branch, dev_v0.8.0, for next released version. Please re-submit a PR to merge all your modifications to that branch as soon as possible. Thanks a lot !

@YuanLiuuuuuu  Sorry for the delay, please check it

authors: YuanLiuuuuuu mitming


text:
[SIDE-2283] Add development Webpack configuration

This PR:

Adds a webpack development configuration that includes caching, no uglifying, and omits node_modules from builds.
Updates the readme with this, as well as moving parts of the readme around to better structure the content.

With caching, skipping babel on node_modules, minification off:
 SMP  ⏱
General output time took 2.77 secs

 SMP  ⏱  Plugins
BannerPlugin took 0.001 secs

 SMP  ⏱  Loaders
babel-loader, and
ts-loader took 1.6 secs
  module count = 1
modules with no loaders took 0.797 secs
  module count = 541
babel-loader took 0.263 secs
  module count = 15

Do you think it will be helpful to update selfTestLoop to use: config.development?

authors: RusGraf richseviora

repo: open-olive/loop-development-kit


text:
VPD Caching broken on multiple socket, single CVPD systems (Barreleye)

Found a bug with the VPD caching:
In fsipres.C, hostboot loops through the all targets and processes VPD cache.  If the CPU or Centaur is not present, it essentially invalidates the PNOR cache for that MVPD/CVPD.  It does this based on FSI HW detect.  If the CPU or Centaur  is present, it will load VPD cache from hardware.      Since there is only 1 physical VPD, if anything is not present, it will invalidate VPD Cache.  This is a bug.  Barreleye hit this bug because it is the only 2 socket system we have with a single VPD chip for all Centaurs.
Here is current (failing) sequence:

CPU0/Centaurs -> present -> VPD cache is loaded
CPU1/Centaurs -> not present -> VPD cache is invalidated
VPD cache is needed but has been invalidated

@dcrowell77 and I brainstormed a couple of solutions --

Simple hack to reverse order of presence detection from CPU X -> CPU 0.  Not sure about any side effects, but this works because CPU 0 always has to be present

The algorithm is using the FSI presence detect to qualify if VPD is even possible to read.  In this case the singular copy of the VPD is behind the CPU (not the centaur).   Fix would be to update the presence detect  code for centaurs to take into account which target actually has the I2C master that reads the VPD and use that to determine if VPD is reachable. This is likely the proper fix, and what this issue was opened for.

Dean, is this resolved?

authors: sannerd williamspatrick

repo: open-power/hostboot


text:
oqsx_key_fromdata returns success when no private and public are provided

Hey!
I've been playing with oqs provider. I noticed that in oqsx_key_fromdata that if the user screws up and doesn't provide a priv and does not provide a pub OSSL_PARAM, that success is returned. Would it make more sense to only return 1 if something was successfully imported?

Thanks for the report @Martyrshot . For this function, indeed, it's not sensible to return OK if both parameters are missing. Please feel free to check whether #296 fixes the issue in your eyes. This is mostly due to the fact that this function is used throughout the provider and sets necessary logic for private only, public only, or complete key pairs.
In general, though, if a user is calling a function without parameters properly set thus leading to a no-operation is not something the provider needs (or IMO sensibly ought) to report: The resultant behaviour (of incorrectly called param getters and setters) will become (more) obvious (to the user) later -- then at the actual operation. As an example, should it be considered an error to not pass a bit length param to a key gen initialization? I don't think so: Rationale: A wrong size parameter passed as parameter to a key gen context creation generally cannot be detected as an error (unlike a completely missing parameter). Both user mistakes will become obvious(ly understandable to the user) at the actual key gen operation, though.

authors: Martyrshot baentsch

repo: open-quantum-safe/oqs-provider


text:
dashboard: Gray or different colored trajectory when robot is performing an operation

Feature request
Status
Soft-blocked on open-rmf/rmf_task#39. We can go ahead and implement this based on the current task definitions, but we need a different strategy when the new task system is merged, because it supports dynamic task types so we cannot pin a color to a task types as it is with the current proposal.
Description

In order make it more visible to users  from just the map, that a robot has started performing a task or operation, for example Docking, Cleaning, or when it has completed its job and returned to normal navigation.
Implementation considerations

The task that the robot is performing can be inferred from RobotMode, which should trigger a color change in the trajectory.

How would this work with the new task system, which supports dynamic tasks types?

Thanks, that is a very good point! I'll bring this up during the upcoming Task Working Group discussion

This requires perform_action or custom operation trajectories to be added to the schedule, with that in mind, I don't believe we are able to support this

authors: aaronchongth koonpeng

repo: open-rmf/rmf-web


text:
Update README.md

Update docs
Update basic rmf installation. will soon require to cherry-pick instructions from the original doc here, to create a comprehensive guide.

Apologize for the multiple force-push as all past commits required sign-off.

repo: open-rmf/rmf


text:
fix: remove local time option from user settings

What type of PR is this? (check all applicable)

[ ] 🍕 Feature
[x] 🐛 Bug Fix
[ ] 📝 Documentation Update
[ ] 🎨 Style
[ ] 🧑💻 Code Refactor
[ ] 🔥 Performance Improvements
[ ] ✅ Test
[ ] 🤖 Build
[ ] 🔁 CI
[ ] 📦 Chore (Release)
[ ] ⏩ Revert

Description
This PR removes display local time check option from user's settings as it does nothing

Related Tickets & Documents
Fixes #946

Mobile & Desktop Screenshots/Recordings

Added tests?

[ ] 👍 yes
[x] 🙅 no, because they aren't needed
[ ] 🙋 no, because I need help

Added to documentation?

[ ] 📜 README.md
[ ] 📓 docs.opensauced.pizza
[ ] 🍕 dev.to/opensauced
[ ] 📕 storybook
[x] 🙅 no documentation needed

[optional] Are there any post-deployment tasks we need to perform?
[optional] What gif best describes this PR or how it makes you feel?

@OgDev-01 @bdougie we are currently using this setting here
https://github.com/open-sauced/insights/blob/beta/components/molecules/ContributorProfileInfo/contributor-profile-info.tsx#L76
That needs to be updated also if we're no longer using this setting

@OgDev-01 @bdougie we are currently using this setting here

If the setting is being used in the UI, it doesn't seem to be not working as intended. Can you confirm @OgDev-01. This was the report from Steven, we may have jumped to a conclusion to remove the feature rather than fix it.

I just confirmed that the value is being used in the user profile. Just a minor issue with the checkbox because its default value is not populated from the user's data but a local state variable. So when a user updates their profile to show the date and reloads the page, the checkbox remains unchecked even if the settings have been updated

The displayLocalTime value is derived from a local useState variable and i think that's what needs fixing

Option added back and now reflects users previously saved value by defauilt

authors: OgDev-01 bdougie brandonroberts

repo: open-sauced/insights


text:
chore(main): release core-js 0.0.2-experimental

:robot: I have created a release beep boop
0.0.2-experimental (2024-11-03)
✨ New Features

core-js: updated cicd (d4ac1f6)
core-js: updated the history interface (d026ccc)
expanded core (fa5d4eb)
setting up core-js (d0baef6)
updated core interface (fba7271)
updated core interface (8d60a91)
updated core interface (2c87b17)
updated core interface required interface (cd92204)
updated organization (830ca46)
updating core-js provider (5529aae)

🐛 Bug Fixes

linting is fixed (9b48035)
linting is fixed (f531955)
release process fixed (0617fde)
test cases fixed (6ffc8ea)
testing build (f1b0772)
unsubscribe (408dd00)
updated jest types, added few test in core-js (dce0a18)

🧹 Chore

deps: update dependency @testing-library/jest-dom to v6.6.3 (7000d12)
release: 1.10.0 [skip ci] (c801187)
release: 1.11.0 [skip ci] (abf0434)
release: 1.12.0 [skip ci] (ff62d63)
release: 1.13.0 [skip ci] (04794d6)
release: 1.14.0 [skip ci] (a522885)
release: 1.5.0 [skip ci] (0b4636a)
release: 1.5.1 [skip ci] (44b838e)
release: 1.8.0 [skip ci] (d3371d0)
release: 1.9.0 [skip ci] (a15479c)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/open-socket/js-sdk/releases/tag/core-js-v0.0.2-experimental :sunflower:

repo: open-socket/js-sdk


text:
profile

Name: Jina Lee
GitHub: @wlsk5882
Twitter: @wlsk5882

Completed Courses
Name of the Section

Course
Files

Course Name
link

Please, could you use this link in order to sign up!
Thank you.

@wlsk5882 please, move your comment to #145 and close this issue. :+1: :smiley:

@jbhum @maicoqb ty!

authors: ericdouglas jbhum maicoqb wlsk5882

repo: open-source-society/computer-science


text:
Add action to ensure dist is up to date

Failure example

can we wait to merge this until after the cherry-picks are merged? (#15)

can we wait to merge this until after the cherry-picks are merged? (#15)

sure

authors: dyladan trask

repo: open-telemetry/assign-reviewers-action


text:
Semantic Conventions and release strategy

The Semantic Conventions spec introduced a significant breaking change (opinion) to the HTTP Tracing spec's span name conventions in v1.18, along with a number of other breaking changes in v1.20. This was recognized as a disruptive change for endusers by several maintainer groups and the spec wg decided that the languages should hold off on implementing that version until the http section of the semantic conventions spec was marked stable. This evolved into a broader migration plan for semantic convention adoption choices by end users across the entire spec.
~Open question~ on the http span name issue.
Resolution: HTTP span names are included in the "should not change until HTTP conventions stabilized" plan. Clarified in this open PR
Summary of the determinations that have come out of these plans:

Libraries should implement and respect the OTEL_SEMCONV_STABILITY_OPT_IN env var
v1.20 is generally considered as the start of this stable/unstable cutoff for a number of attributes.
SHOULD NOT change the version of the HTTP or networking attributes that they emit until the HTTP semantic conventions are marked stable (HTTP stabilization will include stabilization of a core set of networking attributes which are also used in HTTP instrumentations). (My understang - This should therefore supersede stable/unstable status for those attributes)
For a user opting into http/dup, where a conflict exists between stable/unstable, the stable version should be emitted.
SHOULD maintain (security patching at a minimum) the existing major version for at least six months after it starts emitting both sets of attributes.
SHOULD drop the environment variable in the next major version (stable next major version SHOULD NOT be released prior to October 1, 2023).

Reference the following resources for any questions when dealing with semantic convention updates:

https://github.com/open-telemetry/opentelemetry-specification
CNCF Slack #otel-semantic-conventions-wg channel

This raises some open questions:

Should we:

make an effort to release each semantic convention version so these changes are incremental and which a user could override?
continue to just do sporadic semcon library releases and add deprecation notices over a period of time? Incremental vs rip off the band-aid before something is marked stable

How do we track stable vs unstable attributes? Introduce a map in semconv that tracks the statuses that can be referenced by libraries?
How do we address the security patching requirement? Branch from the tag which needs the patch and publish?

https://github.com/open-telemetry/semantic-conventions/pull/278 has been merged to clarify confusion on breaking changes.


text:
Support custom exporting directly with pdata structures

Currently the controller converts telemetry data into OTel data using the go.opentelemetry.io/otel/sdk/trace package. This is inefficient given we transport this data as ptrace.Traces and rigid (it does not allow user customization).
Instead, we should allow customization of the data handling. The Instrumentation type can accept implementations of a Handler interface that is designed to handle telemetry data.
This should include useful default handlers. We should provide ways for users to easily export directly with pdata (i.e. a collector).
Proof of concept

cc @RonFed


text:
[opentelemetry-collector] Add conditional to override mounting ConfigMap

Hi all,
Sample from templates below show current requirements to have configuration mounted using the well defined naming schema needs configMap.create to be set to true.
    volumeMounts:
      {{- if .Values.configMap.create }}
      - mountPath: /conf
        name: {{ include "opentelemetry-collector.lowercase_chartname" . }}-configmap
      {{- end }}
volumes:
  {{- if .Values.configMap.create }}
  - name: {{ include "opentelemetry-collector.lowercase_chartname" . }}-configmap
    configMap:
      name: {{ include "opentelemetry-collector.fullname" . }}{{ .configmapSuffix }}
      items:
        - key: relay
          path: relay.yaml
  {{- end }}

In the scenario where opentelemetry-collector is deployed as a subchart with a custom configuration, users will need to specify the name of the custom configuration using the extraVolumes and extraVolumeMounts fields. This process can be streamlined by enabling conditional override capability.
For instance, we can enable override via configMap.mount and couple it with configMap.create using an OR condition. This approach will facilitate mounting the configuration using the existing naming convention if:

configMap.create is set to true
configMap.mount is set to true
both options set to true

Potential Solution
    volumeMounts:
      {{- if or .Values.configMap.create .Values.configMap.mount }}
      - mountPath: /conf
        name: {{ include "opentelemetry-collector.lowercase_chartname" . }}-configmap
      {{- end }}
volumes:
  {{- if or .Values.configMap.create .Values.configMap.mount }}
  - name: {{ include "opentelemetry-collector.lowercase_chartname" . }}-configmap
    configMap:
      name: {{ include "opentelemetry-collector.fullname" . }}{{ .configmapSuffix }}
      items:
        - key: relay
          path: relay.yaml
  {{- end }}

@chunter0 What's confusing to me is that the name of the confmap/mount isn't change based on whether "create" or "mount" is used. When would a user use "mount" instead of "create"? It seems they do the same thing.
Can you provide a subchart example where this feature would be used?

Mount isn't coupled with creation of the ConfigMap because as a user we would like to own the template in the parent chart for ConfigMap creation.
Current
As a user we're currently using the naming schema and have to get the ConfigMap mounted using extraVolumes. This is sub-optimal because this has to be specified in the parent chart and the data type is an array. If a user of the parent wants to specify another volume they will have to pass in their volumes as well as the parent chart defaults.
Parent Chart
apiVersion: v2
dependencies:
- alias: telemetryCollector
  condition: telemetryCollector.enabled
  name: opentelemetry-collector
  repository: https://open-telemetry.github.io/opentelemetry-helm-charts
  version: 0.74.0
name: parent

This example is how the parent mounts the config under the well known naming schema
extraVolumes:
- name: telemetry-configmap
  configMap:
    name: {{ telemetryCollector.fullnameOverride }}-config
    items:
      - key: relay
        path: relay.yaml

Another example if a user of the parent chart wants to add another volume, as we can see from the values below they would need to redefine the entire extraVolumes field to avoid removing the parent chart ConfigMap
extraVolumes:
- name: telemetry-configmap
  configMap:
    name: {{ telemetryCollector.fullnameOverride }}-config
    items:
      - key: relay
        path: relay.yaml
- name: user-defined

@TylerHelmuth

So this is a situation when using the chart as a subchart AND supplying your own configuration file with the same name as the one the collector would have created? So instead of
configMap:
  create: false
extraVolumes:
- name: telemetry-configmap
  configMap:
    name: {{ telemetryCollector.fullnameOverride }}-config
    items:
      - key: relay
        path: relay.yaml

you'd do
configMap:
  create: false
  mount: true

Exactly @TylerHelmuth

@chunter0 ok I'm understanding now. This feels ok to add, but potentially confusing.  We'll want to add comments to the section that make it very clear how this field should be used.

IMO this feels brittle – it requires the parent to name the configmap exactly what the subchart expects for its naming convention. I think it would be cleaner if you instead provided something like existingName: "somrandomcm" which would control this feature. This would let the user specify a name and mount the configmap simultaneously.

@jaronoff97 You're thinking instead of having a boolean control this behavior you'd want something like this
configMap:
  existingName: "some-name"

And the chart templates mount based off that field?

yes, that's what I had in mind – it allows the user some more flexibility in terms of their naming conventions while achieving the same goal.

@jaronoff97 I like that approach

How does this this look

yep just commented, sorry was out on vacation.


text:
Update release lifecycle to support Conventional Commit, Release Please and automatic CHANGELOG

For ref: https://github.com/google-github-actions/release-please-action

Hi @TylerHelmuth,
I've noticed a discrepancy in the release notes under opentelemetry-collector-0.72.0. The content states "Full Changelog: opentelemetry-operator-0.39.2...opentelemetry-collector-0.72.0" and mentions both the operator and collector charts. Typically, release notes are specific to one project. Is this expected? I suspect something might be slightly off.
Side Note: I'm working on a collector chart distro project and adding a similar feature to support an ongoing CHANGELOG and release notes feature (#923). We would like to invest, help develop, and adopt the functionality in this project where possible so we can incorporate it into our distro. We can create or follow new GH issues as needed.
Thank you!

@jvoravong Good catch, I was not expecting that behavior. I will reopen this issue and investigate more tomorrow.

Looking into this, the expected behavior for the github action is to generate "Full Changelog: opentelemetry-operator-0.39.2...opentelemetry-collector-0.72.0" since that is the exact changes between releases.  The same behavior is happening in the prometheus helm chart repo: https://github.com/prometheus-community/helm-charts/releases/tag/kube-prometheus-stack-51.3.0.  Since every chart change is a release, comparing the differences between releases will always be an accurate way to show the files that changed for the release.
I am curious about using chloggen, but I view that as a potential improvement.  I am going to close this issue again, but please open a new issue if you'd like to continue the discussion of how to incorporate chloggen for the 3 charts.

authors: TylerHelmuth jvoravong pragmaticivan


text:
Add source map files to builds

Related to:

https://github.com/open-telemetry/opentelemetry-js/pull/2488
https://github.com/open-telemetry/opentelemetry-js/issues/1887

Looking to remove all of the warnings about missing source maps

Hopefully this is correct
rm -rf build
npm run compile

# Generate All files
du -hs build/*

# Generate only specific files
find build/esm \( -name '*.js' -o -name '*.js.map' -o -name '*.d.ts' \) -exec du -ch {} +
find build/src \( -name '*.js' -o -name '*.js.map' -o -name '*.d.ts' \) -exec du -ch {} +

ESM

Tool
Before
After

All files
856K
900K

Only js, js.map, d.ts
628K
672K

CommonJS

Tool
Before
After

All Files
840K
884K

Only js, js.map, d.ts
632K
676K

NPM Pack(npm pack)

Size Type
Before
After

Packed
58.1kB
81.1 kB

Unpacked
377 kB
595.6 kB

cc @MSNev i'm not that familiar with the browser tooling, do you find it acceptable ?

repo: open-telemetry/opentelemetry-js-api


text:
chore: release main

:robot: I have created a release beep boop
@opentelemetry/auto-instrumentations-node: 0.36.2
Dependencies

The following workspace dependencies were updated

dependencies

@opentelemetry/instrumentation-aws-lambda bumped from ^0.34.1 to ^0.35.0

instrumentation-aws-lambda: 0.35.0
0.35.0 (2023-02-08)
Features

instrumentation-lambda: Flush MeterProvider at end of handler (#1370) (096129c)

Bug Fixes

instrumentation/aws-lambda: Ensure callback is only called once (#1384) (d822f75)

resource-detector-gcp: 0.28.0
0.28.0 (2023-02-08)
Features

detector-gcp: collect hostname resource attribute from GCP Metadata API (#1364) (33c57cc)

This PR was generated with Release Please. See documentation.

I can't "request changes" on my own PR but this is being held by request of @Aneurysm9

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/resource-detector-gcp-v0.28.0 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/auto-instrumentations-node-v0.36.2 :sunflower:

:robot: Release is at https://github.com/open-telemetry/opentelemetry-js-contrib/releases/tag/instrumentation-aws-lambda-v0.35.0 :sunflower:

repo: open-telemetry/opentelemetry-js-contrib


text:
test(api): longer timeout for API tree-shaking tests

Which problem is this PR solving?
I noticed that sometimes the tree-shaking tests time out when I switched to a different machine recently - some people have told me that some test times out when they run it but I was never able to figure out which tests it was.
On my new machine it happens every once in a while, and it's always the tree-shaking tests. So I'm changing the timeout to 5 seconds (form previously 2) - if it happens to take longer than that in the future I'll have to investigate it more closely.

(skipping changelog since this is just modifying tests)

repo: open-telemetry/opentelemetry-js


text:
fix clang-format installation

the dev image had broken because clang-format-18 was no longer available. switching to clang-format seems to work, and upgrade to debian bookworm for good measure.

For LLVM repository, the llvm-toolchain-bookworm dist is confusingly the "bleeding edge" dist that contains the last build of the current development version that does not have a stable release yet. Since 18 got a stable release a few days ago, the bleeding edge switched to 19.
However, it can be changed to llvm-toolchain-bookworm-18 instead to keep using 18 (which is now stable). Using a specific version in format script should guarantee that the result is the same, otherwise it can be run either on host or outdated/different containers that use a different version.

authors: agoallikmaa brettmc


text:
Fix flaky TestCreateTraceExporter

The ocagent Stop method takes into account the state of its connection to report error or not. The test is about creating and stopping the exporter so standing up a receiver ensures that ocagent stops happens cleanly.
One could argue that ocagent Stop should only return errors if it couldn't properly stop but the test should not depend on its behavior.
Fixes #59

Codecov Report

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

@@           Coverage Diff           @@
##           master     #106   +/-   ##
=======================================
  Coverage   69.77%   69.77%
=======================================
  Files         101      101
  Lines        6392     6392
=======================================
  Hits         4460     4460
  Misses       1698     1698
  Partials      234      234

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 1ce4809...8e315d0. Read the comment docs.

authors: codecov-io pjanotti

repo: open-telemetry/opentelemetry-service


text:
[kubernetes] Add docs for k8sclusterreceiver

Adds documentation for the k8sclusterreceiver component.
Related to https://github.com/open-telemetry/opentelemetry.io/issues/3005
For the sake of working these in parallel im going to start opening multiple and always adding the new ones as low in the file as I can.  If there is a better way to organize I'll rearrange when they are all in.

If there is a better way to organize I'll rearrange when they are all in.

I'm starting to wonder if maybe these make sense as separate files altogether. I'm not entirely convinced yet, but that might be something we do. But I think we can tackle that kind of IA work separately.

I thought about separate files, but considering we'll have some other collector files for k8s specific collector stuff I opted to compress them into one for now.
I think once all the information is written they'll be ample opportunity for organization.

I think once all the information is written they'll be ample opportunity for organization.

Yep, agreed. First order of business is to get it all in, then we'll figure out if there's a better way to organize it.

authors: TylerHelmuth cartermp


text:
[CI] Use Perl Core module JSON::PP

Closes #3187
Contributes to #3122
Switches to using the core Perl module JSON::PP instead of JSON
I tested this on GitPod (which doesn't have the JSON module installed by default), and it works.
@julianocosta89 - if you still have issues, I'll find another solution.

Thanks @chalin 🤩

I'm on my mobile ATM, but I can take a look tomorrow if that's fine.

Added the error message here: https://github.com/open-telemetry/opentelemetry.io/issues/3187#issuecomment-1681608127


text:
Adapt messaging examples/tables

Fixes #1465
Changes
The mermaid diagrams and the tables use different terms/names for things, which may cause confusion for end-users. This PR attempts to make them a bit more clear.
Merge requirement checklist

[x] CONTRIBUTING.md guidelines followed.
[x] Change log entry added, according to the guidelines in When to add a changelog entry.

If your PR does not need a change log, start the PR title with [chore]

[ ] schema-next.yaml updated with changes to existing conventions.

This looks great!
We have a few more examples in Kafka and GCP PubSub files and it'd be great to update them too.

Good find! I updated those with the same "style".

repo: open-telemetry/semantic-conventions


text:
gRPC responses for equivalent HTTP 4xx or 5xx responses should be returned as an error instead of response object in OK status

Version information
v0.2.1
Describe the bug
Different response types for HTTP API maps to different protobuf messages with error code in the name of the message.
All those responses are returned only during gRPC OK.
What this implies is, even after doing a check for err != nil post gRPC API call, users have to further check for errors inside response messages. This also complicates the retrieval of actual usable response.
Solution is to return all error responses as err from gRPC API call. More details TBD.
To Reproduce
	request := otg.SetConfigRequest{Config: config.Msg()}
	ctx, cancelFunc := context.WithTimeout(context.Background(), api.grpc.requestTimeout)
	defer cancelFunc()
	resp, err := api.grpcClient.SetConfig(ctx, &request)
	if err != nil {
		return nil, err
	}
	if resp.GetStatusCode_200() != nil {
		return NewResponseWarning().SetMsg(resp.GetStatusCode_200()), nil
	}
	if resp.GetStatusCode_400() != nil {
		data, _ := yaml.Marshal(resp.GetStatusCode_400())
		return nil, fmt.Errorf(string(data))
	}
	if resp.GetStatusCode_500() != nil {
		data, _ := yaml.Marshal(resp.GetStatusCode_500())
		return nil, fmt.Errorf(string(data))
	}

Expected behavior
	request := otg.SetConfigRequest{Config: config.Msg()}
	ctx, cancelFunc := context.WithTimeout(context.Background(), api.grpc.requestTimeout)
	defer cancelFunc()
	resp, err := api.grpcClient.SetConfig(ctx, &request)

        // should include error responses defined for http 4xx or 5xx codes
	if err != nil {
		return nil, err
	}

Originally reported by @robshakir @marcushines

For reference: https://cloud.google.com/apis/design/errors

Notes from high level discussion about the possible solution:

Constraining API response schema

Today, open-api allows users to specify different response schemas for different HTTP status codes.
We might look into possibility of constraining responses to two kinds, Ok response and Error response
Ok response may have different schema based on URL + method and must be provided by author. Only 200 status code shall be supported - TBD ?
Error response MUST be same for all API calls (URL + method)
Error response MUST be provided by author and contain certain minimum attributes (e.g. StatusCode, Messages, etc.)
These constraints shall be validated by openapiart

Changes in generated SDK for gRPC

The generated struct for Error response will automatically be provided with Error() method in order to implement error interface in Go
The server will essentially work with Error struct to fill in all the possible details. Upon returning the error, Error() method would serialize the message into readable and parsable string.
Upon reception of error on client side, it can be easily passed along. If further inspection is needed, it can be de-serialized into Error struct
The status code used would be FAILED_PRECONDITION for validation errors and INTERNAL for application errors.

From user's POV, following would be the workflow for API calls:res, err := api.SetConfig(config)
if err != nil {
    // simply pass it along to parent func
    return err
    // or inspect the error further
    errObj := api.NewError(err)
    fmt.Println(errObj.StatusCode())
    fmt.Println(errObj.Messages())
}

// use response - it won't be nested anymore
fmt.Println(res.Warnings())

@ajbalogh @alakendu FYI

Proposal

repo: open-traffic-generator/openapiart


text:
Sdk logging

Supports logging for go and python sdk

Covered by https://github.com/open-traffic-generator/openapiart/pull/422

authors: ashutshkumr dipendughosh


text:
Error: Uncaught TypeError: Class constructor LitElement cannot be invoked without 'new' when using karma-esm with tsc

Hi, I'm sorry if this is not the place for this kind of problem, but after thinking about it for a while I couldn't think of a better place where i might get an answer.
I'm working on a lit-element based project and was pointed towards testing it with your testing umbrella project open-wc/testing. I've set up a fairly basic configuration on top of the default one that you guys provide It can be seen below:
const { createDefaultConfig } = require('@open-wc/testing-karma');
const deepmerge = require('deepmerge');

module.exports = config => {
  config.set(
    deepmerge(createDefaultConfig(config), {
      files: [
        { pattern: config.grep ? config.grep : './ui/static/dist/**/*.spec.js', type: 'module' },
      ],
      esm: {
        nodeResolve: true,
        customBabelConfig: {
          plugins: [
              ['css-modules-transform', { extensions: ['.css', '.scss', '.less'] }],
          ],
      },
      },
    }),
  );
  return config;
};

Now my project is written in typescript so i used the tsc command just like you guys suggested here:
the exact command i typed in to test this is :
tsc -p ./ --outdir ui/static/dist --module ES2020
and my tsconfig file looks like:
{
  "exclude": [
    "./node_modules/*"
  ],
  "include": [
    "./**/*.ts",
  ],
  "compilerOptions": {
    "target": "es5",
    "module": "commonjs",
    "checkJs": false,
    "allowJs": true,
    "rootDir": "./",
    "strict": false,
    "noImplicitAny": false,
    "strictNullChecks": false,
    "strictFunctionTypes": false,
    "strictPropertyInitialization": false,
    "noImplicitThis": false,
    "alwaysStrict": false,
    "moduleResolution": "node",
    "allowSyntheticDefaultImports": true,
    "esModuleInterop": true,
    "experimentalDecorators": true,
    "forceConsistentCasingInFileNames": true,
    "baseUrl": "./",
    "paths": {
      "common/*": [
          "./ui/static/ui/common/*"
      ],
      "loginui/*": [
        "./ui/static/ui/loginui/*"
      ]
    }
  }
}

the compiling part seems to go just fine, but as soon as i run:
karma start --coverage
It gives me the error described in the title (the tests do run, they just fail because of this error). I had this same problem when running the code I'm trying to test in the browser but i fixed that by telling webpack to exclude all node_modules except lit-element. From my understanding this works because the bundle will include the compiled version of lit-element, but my compiled files generated by tsc simply refer to the package as its present in my node_modules folder.
How can i fix this?

Sorry for the late response here. It looks like you are compiling to es5, this requires loading the custom elements es5 adapter because of the way typescript compiles away classes. Babel does work though.
I don't recommend running tests with es5, since that's only needed for IE11 now. Browsers support much higher versions.

repo: open-wc/open-wc


text:
feat: MinXcmFee from storage

Allows you to store the MinXcmFee in storage. The advantage of this is that no runtime upgrade is required when you want to update this value. Usage for existing consumers is unchanged, other than having to provide type WeightInfo = (); now. To opt in into fetching the value from storage, users can use type MinXcmFee = XTokens;.

why do you need to make a new trait?

It's not absolutely necessary, but the alternative is to implement GetByKey on the Pallet<T> which felt not so clean to me. But I'm happy to change that if you prefer.

It is possible to achieve your goal without any code changes here. Checkout what we did at Acala https://github.com/AcalaNetwork/Acala/blob/783feaa7094f4ce16acd04e5313f7c3977d8ba6e/runtime/karura/src/xcm_config.rs#L313 https://github.com/AcalaNetwork/Acala/blob/783feaa7094f4ce16acd04e5313f7c3977d8ba6e/modules/xcm-interface/src/lib.rs
we could have a new pallet in ORML to handle XCM fee configuration our xcm-interface pallet include bunch Acala specific code but it is possible to spend bit more time to make it generic and resuable

I realize that there are workarounds possible, like putting the storage in other pallets. However, to me it made most sense to incorporate this into the xtokens pallet itself - I didn't want to add another pallet just for this one storage item. Having it inside XTokens itself is cleaner imo - it's easier for people to opt into it and it keeps everything a bit more tidy

It's not absolutely necessary, but the alternative is to implement GetByKey on the Pallet which felt not so clean to me. But I'm happy to change that if you prefer.

We usually have a new struct and have GetByKey implemented on the new struct

I think a generic XCM fee pallet will make sense that is able to store fee for various different operations. In future, I do believe parachains will want to support different kinds of xcm operations and that usually requires different amount of fee & weights

I think a generic XCM fee pallet will make sense that is able to store fee for various different operations. In future, I do believe parachains will want to support different kinds of xcm operations and that usually requires different amount of fee & weights

Could you clarify what you mean with different kinds of xcm operations? Do you mean messages that are being sent by pallets other than xtokens?
What kind of interface would you like to see on a generic XCM fee pallet?

Yes other than xtokens. For example, we could have the orml-xcm implements the method to open/accept hrmp channel.
The interface could be something similar to xcm-interface, just generalize it to be able to define the XcmInterfaceOperation in the runtime


text:
Easily create Litellm modelfiles via the web UI and not only Ollama

Is your feature request related to a problem? Please describe.
When I try to create a model file with a model that is store not on the ollama server but on the litellm server in my openwebui configuartion files, the oepn webui interface try to download it "pull model manifest: Get "https://ollama.com/token?nonce=PVU8K_tursrhgMstjAboFw&scope=repository%3Alibrary%2Fmixtral-8x7b%3Apull&service=ollama.com&ts=1714223332": EOF"
i do confirm the litellm model is accessible through the open webui
in my case I am using litellm > vllm > mixtral 8x7b
Describe the solution you'd like
It should be possible to create a model file for a model accessible through the litellm server.

Duplicate #665

authors: flefevre tjbck

repo: open-webui/open-webui


text:
Update Serbian translation

Description
I've used the main branch as the base initially so I've missed some strings in the dev branch. Rebased on dev and updated the translation.

Changelog Entry
Changed

Updated the Serbian translation

Thanks!

authors: kostich tjbck


text:
Use "group" instead of "directory"

In the standard "group" and "directory" are used interchangeably. It would make things clearer if only one or the other was used and "group" makes more sense than "directory".
@ax3l: Please put this in the project 1.1 queue.

Thanks for the report!
Actually, only used to refer to /. The term "directory" is currently used three times in exactly that formulation:

root directory (path /)

when referring to /.
I agree that we can also call this immediately
root group (path /)
.

repo: openPMD/openPMD-standard


text:
Remove useless replacement in conftest.sh

Not sure exactly what you are trying to accomplish here:
    if [ "$ARCH" = "i386" -o "$ARCH" = "x86_64" ]; then
        if [ -d "$SOURCES/arch/x86" ]; then
            KERNEL_ARCH="x86"
        fi
    fi

In your idea this should make the test x86 test run on all architectures?

This is partly a prehistorical change.
Index: nvidia-gfx.changes
===================================================================
--- nvidia-gfx.changes (revision 51)
+++ nvidia-gfx.changes (revision 52)
@@ -1,4 +1,9 @@
 -------------------------------------------------------------------
+Tue May 21 09:10:07 UTC 2013 - sndirsch@suse.com
+
+- arch is "x86" with 3.9 kernels
+
+-------------------------------------------------------------------
 Thu Apr  4 10:25:22 UTC 2013 - sndirsch@suse.com

 - kmp-post.sh: Ensure that the updates directory exists
Index: nvidia-gfx.spec
===================================================================
--- nvidia-gfx.spec (revision 51)
+++ nvidia-gfx.spec (revision 52)
@@ -161,6 +161,7 @@
 rm *.orig
 popd
 mkdir obj
+sed -i -e 's,-o "$ARCH" = "x86_64",-o "$ARCH" = "x86_64" -o "$ARCH" = "x86",' source/*/conftest.sh

 %build
 export EXTRA_CFLAGS='-DVERSION=\"%version\"'

But then I added later:
commit 1c8f0fefe49be586f990d9a29c83d3b6a99b6f13
Author: Stefan Dirsch <sndirsch@suse.de>
Date:   Tue Oct 31 13:02:19 2023 +0100

    first try to fix kernel module build on aarch64

diff --git a/kmp-post.sh b/kmp-post.sh
index ba4a1a7..5af997c 100644
--- a/kmp-post.sh
+++ b/kmp-post.sh
@@ -10,6 +10,9 @@ arch=i386
 %ifarch x86_64
 arch=x86_64
 %endif
+%ifarch aarch64
+arch=aarch64
+%endif
 flavor=%1
 #export CONCURRENCY_LEVEL=nproc && \
 #export JOBS=${CONCURRENCY_LEVEL} && \
diff --git a/kmp-trigger.sh b/kmp-trigger.sh
index f84267a..0b70ca0 100644
--- a/kmp-trigger.sh
+++ b/kmp-trigger.sh
@@ -9,6 +9,9 @@ arch=i386
 %ifarch x86_64
 arch=x86_64
 %endif
+%ifarch aarch64
+arch=aarch64
+%endif
 flavor=%1
 #export CONCURRENCY_LEVEL=nproc && \
 #export JOBS=${CONCURRENCY_LEVEL} && \
diff --git a/nvidia-driver-G06.changes b/nvidia-driver-G06.changes
index 08ed0c0..fb27245 100644
--- a/nvidia-driver-G06.changes
+++ b/nvidia-driver-G06.changes
@@ -1,3 +1,8 @@
+-------------------------------------------------------------------
+Tue Apr 18 14:13:30 UTC 2023 - Stefan Dirsch <sndirsch@suse.com>
+
+- first try to fix kernel module build on aarch64
+
 -------------------------------------------------------------------
 Thu Mar 30 11:04:35 UTC 2023 - Stefan Dirsch <sndirsch@suse.com>

diff --git a/nvidia-driver-G06.spec b/nvidia-driver-G06.spec
index 681b9b6..fce9e7a 100644
--- a/nvidia-driver-G06.spec
+++ b/nvidia-driver-G06.spec
@@ -213,7 +213,7 @@ pushd %_sourcedir
 ln -sv %pci_id_file pci_ids-%{version}_k%{kbuildver}
 popd
 mkdir obj
-sed -i -e 's,-o "$ARCH" = "x86_64",-o "$ARCH" = "x86_64" -o "$ARCH" = "x86",' source/*/conftest.sh
+sed -i -e 's,-o "$ARCH" = "x86_64",-o "$ARCH" = "x86_64" -o "$ARCH" = "x86" -o "$ARCH" = "aarch64",' source/*/conftest.sh

 %build
 echo "*** sle_version: 0%{?sle_version} ***"

We no longer build against %ix86 and I verified that the build against aarch64 still works without that sed maninpulation of conftest.sh, for whatever it was ever used/needed for.

authors: scaronni sndirsch

license: Unlicense