text:
Which JS SDK should be used in manual instrumentation docs?

The manual instrumentation docs today use sdk-trace-base: https://opentelemetry.io/docs/instrumentation/js/instrumentation/
This is helpful insofar as the code here is useful both in Node and in the browser.
However, sdk-trace-base doesn't propagate context, and so creating nested spans is kind of awful: https://opentelemetry.io/docs/instrumentation/js/instrumentation/#create-nested-spans
Contrast this with when using the Node SDK (code is from a basic express app):
function doot() {
    tracer.startActiveSpan('doot', span => {
        console.log('doot');
        span.end();
    });
}

app.get('/', (_req, _res) => {
    tracer.startActiveSpan('toot', span => {
        _res.send("toot");
        doot();
        span.end();
    })
});

No needing to set the current span in context, get the new context, and use that awful overload to create a nested span. Just creating a span like any other language automatically gives you that parent-child relationship. Nice!
But not everyone reading this document is going to be a Node developer, so the code to initialize tracing, such that you can just use the OTel APIs happily, is not applicable for everyone.
My proposal would be to create this content twice on this page: https://opentelemetry.io/docs/instrumentation/js/instrumentation/#initializing-a-tracer
One for node, and one for browser JS. This could be as tabbed content, although we may want to use tabs later on to show JS vs. TS code. I'm fine with whatever folks think works best. But mainly, I'd like to not document the hard way to create nested spans.
@open-telemetry/javascript-approvers what do you think?

Let's split them out. I think it'd make sense to actually break node and browser into separate files entirely?

So I think that the majority of content can stay the same for both SDKs, including nested spans. Both propagate context (at least within the same process!) and so creating nested spans is easy peasy.
Maybe this can be the layout?
Initialize tracing
words
Node.js
words and code sample
Browser
words and code sample
Create spans
...
etc.
And then maybe a separate doc or section about when you're using neither, which requires you to manually put spans into context if you want a parent-child relationship.

I was reading the docs, which state:

Don't bother using startActiveSpan because it won't do this for you.
and looking into why ended up here as the issue which prompted this addition to the docs.

Why doesn't startActiveSpan work?  It seems to call the same methods as the example in the docs calls manually.

Not quite - startActiveSpan does not set the parent span in the active context. And since sdk-trace-base doesn't propagate context, the span created by it will be a sibling rather than a child of whatever the active span was prior to calling startActiveSpan. I suppose if you were to use it in conjunction with api.context.with you could get it to be a child span? I haven't tried, but my gut feel is that what's written today is easier for people who are in a more niche scenario where they aren't in a Node or Web context.

api.context.with is what startActiveSpan does though:
https://github.com/open-telemetry/opentelemetry-js/blob/3290b25d0a1f28ad0df7efd30ed3ff15dc1c2189/packages/opentelemetry-sdk-trace-base/src/Tracer.ts#L224-L228
It also does api.trace.setSpan(parentContext, span), where parentContext is api.context.active() if one wasn't passed into startActiveSpan, which is what the docs say to do.
Full disclosure, I haven't used the API at all, I'm just browsing the documentation at this point, so I very definitely might be overlooking something 😅

I think what you're missing is the subtlety in the API calls -- startActiveSpan doesn't explicitly set the parent span as active; it creates a new span and sets it as the active one. That's not normally an issue because in the Node and Web SDKs, the parent is already set as the active span.

authors: austinlparker cartermp dharesign


text:
Humans of OTel: KubeCon NA 2024

Humans of OTel interviews for KubeCon NA 2024:

[x] Identify interviewees
[x] Finalize questions
[x] Schedule interviews
[x] Conduct interviews - @avillela, @reese-lee (setup done by Henrik Rexed)
[ ] Edit video - Henrik Rexed, @avillela
[ ] Post video to OTel YouTube channel - @avillela
[ ] Socialize video on OTel socials - @avillela or @reese-lee
[ ] Socialize video on CNCF Slack - TBD
[ ] Write blog post summary of video - @avillela

OTel Observatory schedule

Interviewees:

Question list:

What's your name and what do you do?
How did you get involved with OpenTelemetry? What made you contribute to the project?
What part of OpenTelemetry are you involved in?
What does Observability mean to you?
What does OpenTelemetry mean to you?
What's your favourite signal?

Sign-up sheet here

PR for blog post
YouTube Video

I promoted the video on CNCF Slack (#otel-sig-end-user and #otel-announcements) and on all the OTel socials ✅
@avillela Do you want to close this after the blog post PR has been merged, or close now?

source: gharchive/issue

authors: avillela reese-lee

repo: open-telemetry/sig-end-user

license_type: permissive

license_source: github-api


text:
信号灯安装区域筛选结果不符合输入

Describe the bug
To Reproduce
Steps to reproduce the behavior:

进入信号灯设备页面
安装区域选择江宁区
筛选结果有鼓楼区

Expected behavior
A clear and concise description of what you expected to happen.
筛选结果全部是江宁区
Screenshots
If applicable, add screenshots to help explain your problem.

Log Information
If applicable, add more detailed log information to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

已解决
https://github.com/open-v2x/dandelion/pull/169/


text:
AIO installation slow since download zip too large

Describe the bug
AIO installation slow since download zip too large, we only need 68k however download 68M
To Reproduce
Steps to reproduce the behavior:
```console
[root@openv2x-test-master ~]# du -sh master.zip
68M	master.zip

[root@openv2x-test-master ~]# cd docs-master/
[root@openv2x-test-master docs-master]# ls
dprint.json  LICENSE  README.md  src
[root@openv2x-test-master docs-master]# cd src/
[root@openv2x-test-master src]# ls
deploy                                    v2x-algorithm.md                      v2x_developer_guide.md
images                                    v2x-algorithm-Sensor-Data-Sharing.md  v2x_developer_guide-zh_CN.md
install.sh                                v2x-algorithm-Smooth.md               v2x_pull_request_standard-zh_CN.md
v2x-algorithm-Collision-Warning.md        v2x-architectural-design.md           v2x-quick-install.md
v2x-algorithm-Complement.md               v2x_basic_components.md               v2x-quick-start.md
v2x-algorithm-Cooperative-Lane-Change.md  v2x_coding_standard.md                v2x_rse_simulator_instruction.md
v2x-algorithm-Do-Not-Pass-Warning.md      v2x_contribution.md                   v2x_standard_system.md
v2x-algorithm-Fusion.md                   v2x_contribution-zh_CN.md             v2x-user-manual.md

[root@openv2x-test-master src]# du -sh deploy
68K	deploy
[root@openv2x-test-master src]#

Expected behavior
N/A
Screenshots
N/A
Log Information
N/A
Desktop (please complete the following information):

Version: master

Additional context
N/A

A new repo named auto-installer was created to obtain OpenV2X installation scripts. https://github.com/open-v2x/auto-installer

authors: FrankGTY wu-wenxiang


text:
Check /core-model-1-4:control-construct testcases should avoid check of operation key

Problem Description:
Check /core-model-1-4:control-construct testcases should avoid check of operation key .
If we are running security mechanism there is a high chance that operation-key are not constant . So for testcases of Check /core-model-1-4:control-construct in test suite we should avoid operation-key comparison

Assertion Failure Details :
Acceptance::/v1/remove-operation-client-from-link::Forwardings triggered?/LinkChangeNotification::Expected ExecutionAndTraceLog/v1/list-records-of-flow

repo: openBackhaul/ApplicationLayerTopology


text:
Bequeath-your-data-and-die needs to return 400 incase of wrong input and not 204

Bequeath-your-data-and-die service will process the request ,  if the "application-name" in the request-body matches the "http-server-interface-capability/application-name".
This functionality is working fine.
But, incase of wrong "application-name" , the service should return 400 (BAD_REQUEST from client) and not 204(as its not processing the service)
Change required :
server/controllers/individualServices.js need to include response code "responseCodeEnum.code.BAD_REQUEST;" to support sending this response incase of unacceptable application-name.

Based on #98, this issue is no longer valid, as the check should be removed.

authors: DanaSunal PrathibaJee

repo: openBackhaul/ExecutionAndTraceLog


text:
How to change the path of classifier.pt and model.pt?

is it just like the code Improved Diffusion? add a parameter named OPENAI_LOGDIR?
Can anyone help? Thank you very much.

Here
You can replace the path as:path=osp.join(yourPath,...)

repo: openai/guided-diffusion

license: MIT


text:
Easy way to get a context window for a model

Confirm this is a feature request for the Python library and not the underlying OpenAI API.

[X] This is a feature request for the Python library

Describe the feature or improvement you're requesting
The current version of openai-python (v1.3.7) does not contain any method to get the size of context window for a model used for a chat completion. It might cause some overload or underutilization of a model.
Definitely, some model names are clear enough (like gpt-4-32k) but the majority of them must be manually checked using the correspondent tables at https://platform.openai.com/docs/models.
It would be great to fix this inconsistency by any or all of these measures:

Include the size of the context window in the name of each model.
Improve the model object (https://platform.openai.com/docs/api-reference/models/object) by adding the size of context window.

Additional context
No response

Thanks for the suggestion!
This sounds like a feature request for the underlying OpenAI API (specifically, the models endpoints) and not the Python library, so I'm going to go ahead and close this issue.
Would you mind reposting at community.openai.com?

authors: Sciencealone rattrayalex

repo: openai/openai-python

license: mit

license_source: bigquery


text:
[BUILD] Fix Triton build for Apple silicon macOS. (#3443)

Linux and macOS use different processor/ISA string identifiers for their ARM64 variants. So the macOS build was falling thru in cmake config, then later trying to link against x86 libraries and failing to find them in the LLVM libraries bundle for macOS-ARM.

Are you sure about it? I noticed that both mapped to aarch64
https://github.com/openai/triton/blob/dca2d07c4c2bb0344f3ee8aeebd9fe6882b2f266/python/setup.py#L214

Are you sure about it? I noticed that both mapped to aarch64
https://github.com/openai/triton/blob/dca2d07c4c2bb0344f3ee8aeebd9fe6882b2f266/python/setup.py#L214

hi @Jokeren Thanks for the review. Yes I am sure. You are correct that they are explicitly re-mapped there. Note the local scope though. That mapping is used to piece together the name of the LLVM libraries tarball, and variant of NVIDIA binaries to be downloaded. That logic works correctly and it's correctly downloading 'aarch64' library files for macOS in this case. That's the core of the bug, the build setup downloads aarch64 libs, then searches for x86 libs to link against later on and can't find them.
'CMAKE_SYSTEM_PROCESSOR' is not set explicitly anywhere in the Triton codebase. It is generally only explicitly set when cross-compiling. When natively compiling, it is the same value as 'CMAKE_HOST_SYSTEM_PROCESSOR' (per cmake documentation), which is set by cmake from identifying the host system's platform architecture, and not explicitly set anywhere in Triton codebase either.
The key callout from CMAKE_HOST_SYSTEM_PROCESSOR:

macOS Platforms
The value of uname -m is used by default.
On Apple Silicon hosts, the architecture printed by uname -m may vary based on CMake's own architecture and that of the invoking process tree.

Output from my Mac:

% uname -m
arm64

I encountered similar errors. Let me check what's going on since it worked without editing cmakelist.

OK, I traversed back the git history, it might be one of the PRs I made for linux aarch64 that broke the build.
Happy the merge the PR. Thanks!

source: gharchive/pull-request

authors: Jokeren fkouteib

repo: openai/triton


text:
[AMD] Search backend for ld.lld before /opt/rocm

Required for triton wheels as part of ROCm-pytorch's migration to use upstream triton.
In https://github.com/pytorch/pytorch/pull/121801 we package libraries and ld.lld into third_party/amd/backend. This change will look for the linker in third_party/amd/backend/llvm/bin before looking out to /opt/rocm

cc: @zhanglx13 @jayfurmanek


text:
Change iOSxdripreader to Spike

Changed iOSxdripreader to Spike since iOSxdripreader is not maintained anymore.

@philipgo I just made a similar fix as a part of a larger PR for that page. Is it alright to just add the link you provided for Spike so that I don't have to rework my whole PR? Also, if you have a minute to review mine and make sure it's all set it would be appreciated.

Of course, I will review yours in a few hours!

repo: openaps/docs


text:
Rename max_iob.json to preferences.json

First step. I think this is the best way to start introducing more configuration into the profile (e.g. things like disable_neutral_temps).

👍
We'll also need to update https://github.com/openaps/oref0/blob/dev/bin/oref0-mint-max-iob.sh#L12 and the openaps/docs: https://github.com/openaps/docs/search?q=max_iob

Yep, I'll fix the docs once this ships. Just fixed oref0-mint-max-iob and one other reference.

authors: mddub scottleibrand


text:
Fix oref0 setup existing prefs

This address the failure identified at https://gitter.im/openaps/oref0?at=5bc4c006e65a634336e248c4

I have not had a chance to test this yet, but I believe it will solve the referenced issue with a clean install.

Scott - I'd vote for merging (and reverting only if bad problems appear) as it appears maybe at least two users in the last few hours could have benefited.  But I defer to your leadership. Thx.

this breaks on a freshly installed rig, because jessie has jq 1.4 that has no slurpfile. see
https://gitter.im/openaps/oref0?at=5c24b0f492cf4d2242001be8

authors: PieterGit jpcunningh mhaeberli


text:
Validate type property

Type properties have some special rules above basic properties, but at the basic level they are just a primitive property of type IRI.

they can be optional
they usually accept many values
all values must be valid IRIs when expanded out of the OB context.

+1

authors: mgylling ottonomy

repo: openbadges/badgecheck


text:
Audio echo and vibriating cursor in Firefox

When opening editor.opencast.org in Firefox, I'm currently hearing the audio echo. Furthermore, the scrubber is jumping back and forth vigorously.

Since this is not happening anymore, I am inclined to write this off as a once-off problem.

repo: opencast/opencast-editor


text:
editing series 'subjects' via api fails

Describe the bug
When updating the metadata of a series via External API:
If I try to update the field 'subjects', the api responds with a weird error msg:
Not Found: Cannot find a metadata field with id 'subjects' from event with id '8e981748-69b1-4f8e-9839-8ebd2f2a9364' and the metadata type 'dublincore/series'.
Without the 'subjects' field, everything works fine.
Here's what the request looks like:
URL: https://cast.studer-raimann.ch/api/series/8e981748-69b1-4f8e-9839-8ebd2f2a9364/metadata?type=dublincore%2Fseries
Method: PUT
Body: [metadata] => [{"id":"contributor","value":["root user"]},{"id":"creator","value":["Opencast"]},{"id":"description","value":"asdasd123"},{"id":"subjects","value":["asdf"]},{"id":"title","value":"6: series 1.0.1"}]
Or via Curl:
curl --request PUT
--url 'https://cast.studer-raimann.ch/api/series/8e981748-69b1-4f8e-9839-8ebd2f2a9364/metadata?type=dublincore%2Fseries'
--header 'Authorization: Basic AUTH_CODE'
--header 'Content-Type: multipart/form-data; boundary=---011000010111000001101001'
--form 'metadata=[{"id":"contributor","value":["root user"]},{"id":"creator","value":["Opencast"]},{"id":"description","value":"asdasd123"},{"id":"subjects","value":["asdf"]},{"id":"title","value":"6: series 1.0.1"}]'
Environment Information
Opencast 10.3.0 - a750fa8 - built on 2021-11-05

The issue here seems to be that the corresponding GET endpoint returns the field 'subjects', but the PUT endpoint expects the field 'subject'. I would consider the latter the correct naming as per dublincore definition, so the issue probably lies somewhere within the GET endpoint

Have you tried to upgrade to OC11? I wonder if the issue has gone with the consolidation with the admin-UI's index.
I'm watching this ticket since our site also uses subject field for both episode and series metadata. We currently use the Series Service endpoint API, directly, to update series metadata, and a custom OC module for event metadata, so we are not running into this problem.

authors: Arnei karendolan theodortruffer

repo: opencast/opencast


text:
Create output video visualizations

Add creating video visualizations with the output from SatFlow models, possibly overlaying the cloud mask as well. The main idea is for the HuggingFace Spaces visualization (https://huggingface.co/spaces/openclimatefix/MetNet) so that we can have interactive widgets showing off the models we are training!
@peterdudfield Would the visualizations you've been making work for making videos?

Yea I'm sure we can do something
I was essentially just using - https://plotly.com/python/animations/
Let me know how I could help

For some not very clean code - https://github.com/openclimatefix/nowcasting_dataset/blob/main/notebooks/2021-08-26/video.py

Okay, great, thanks! I'll start looking through it

Love this idea!  And thanks loads for jumping in, @peterdudfield!

authors: JackKelly jacobbieker peterdudfield

repo: openclimatefix/satflow


text:
Task3

Issue: #4
Completed Task 3
Commands
sudo -i
sudo chmod +x run.sh
Screenshot
https://drive.google.com/file/d/15XKl46gtJ7979G_Yp-zthkzx9Dy9xbEv/view?usp=sharing

Hey @PriyamJChakrabarty
Thanks for opening this PR 🚀. Mentor will review your pull request soon and till then, keep contributing and stay calm.
Thanks for contributing in OpenCode'24 ✨✨!

Hey @PriyamJChakrabarty
Your PR has been merged 🥳🥳 and you have earned 10 points.
Thanks for contributing in OpenCode'24 ✨✨

authors: Opencodeiiita-Bot PriyamJChakrabarty


text:
Dockered Postgres support

Hey, the set-up is pretty straightforward, but I really have trouble with requiring the user to run Postgres locally.
Assumptions:

Default Postgres instance doesn't requires password.
Default Postgres instance user is called postgres.

I did test and it worked locally with my setup.

Fixed and rebased.

Will merge in https://github.com/opencollective/opencollective-api/pull/2000

authors: kewitz znarf

repo: opencollective/opencollective-api


text:
Fix ci-trigger Cloud Build service name

The build https://github.com/openconfig/featureprofiles/runs/15034045050 failed to deploy. This was the first time a change was made that triggered a rebuild of the service.  It failed because the service name is actually featureprofiles-ci-trigger not ci-trigger.

Pull Request Functional Test Report for #1895 / 869eeb825d11739c415a4bcb0a92d46cd2a085b8
No tests identified for validation.
Help

authors: OpenConfigBot bstoll

repo: openconfig/featureprofiles


text:
kne instead of kne_cli

Hi @marcushines @alexmasi
This proposal is to retire usage of kne_cli as a binary name of a kne CLI in favor of just kne.
From my experience, and what seems to be in line with opinionated cli guidelines, a good CLI name must be short, consice and easy to type -  https://clig.dev/#naming.
kne in that regard is better than kne_cli as it is 4 chars shorter, doesn't force you to use SHIFT and is as expressive in what it does.
I know this might be a bit too intrusive, but I am afraid if we don't do this early on, it might be harder to change it in the future.
I will leave a few inline comments over the certain code lines which I feel deserve a bit of explanatoin

Pull Request Test Coverage Report for Build 2723121201

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 53.896%

Totals

Change from base Build 2721051779:
0.0%

Covered Lines:
1916

Relevant Lines:
3555

💛  - Coveralls

authors: coveralls hellt

repo: openconfig/kne


text:
update incorrect email in MAINTAINERS

Fixes: #213
Signed-off-by: Zhou Hao zhouhao@cn.fujitsu.com

LGTM

LGTM.

authors: cyphar q384566678 xiekeyang

repo: opencontainers/image-tools


text:
[功能问题]目前是否支持AppendECFile

您好，
我的项目中有大量的日志型的数据需要存储，所以希望使用AppendECFile的数据组织形式创建Curve集群，不知当前的版本是否能够支持？
期待回答。

目前还不支持，EC方案初稿已完成设计，但开发由于人手问题，目前delay中，完成时间不确定。

对于日志型的数据存储，一般推荐使用elasticsearch或者clickhouse这类存储系统来解决，curvefs可以作为此类存储系统的冷数据存储服务来达成降本提效的效果。可以参考这篇文章：https://zhuanlan.zhihu.com/p/598332479

authors: aspirer zzjzhijun

repo: opencurve/curveadm


text:
where to get mobilenet-ssd in OpenVINO format

Hi,
I'm using OpenVINO 2019 R2 version which could not be upgraded now, and I can get the mobilenet-ssd in caffe format (mobilenet-ssd.caffemodel  and mobilenet-ssd.prototxt) via downloader.py with command line:
python3 downloader.py  --name mobilenet-ssd  -o /mypath/ --num_attempts 5   --cache_dir /work/tmp/omzcache/
Then I tried to convert the caffe model into OpenVINO format with mo.py (part of openvino 2019 r2 release), but failed, see error message below.
Is there an openvino 2019 r2 format that I can download directly? thanks.
(the command line options are referenced from https://github.com/opencv/open_model_zoo/blob/2019_R2/tools/downloader/list_topologies.yml#L388)
yguo18@yguo18-skl-u1604:/work/ml/openvino_work/dldt/model-optimizer$ python mo.py --framework=caffe --data_type=FP32 --input_shape=[1,3,300,300] --input=data --mean_values=data[127.5,127.5,127.5] --scale_values=data[127.50223128904757] --output=/work/media/mediastack/gva/benchmark/models/object_detection/common/mobilenet-ssd/ --input_model=/work/media/mediastack/gva/benchmark/models/object_detection/common/mobilenet-ssd/caffe/mobilenet-ssd.caffemodel --input_proto=/work/media/mediastack/gva/benchmark/models/object_detection/common/mobilenet-ssd/caffe/mobilenet-ssd.prototxt
Model Optimizer arguments:
Common parameters:
- Path to the Input Model:      /work/media/mediastack/gva/benchmark/models/object_detection/common/mobilenet-ssd/caffe/mobilenet-ssd.caffemodel
- Path for generated IR:        /work/ml/openvino_work/dldt/model-optimizer/.
- IR output name:       mobilenet-ssd
- Log level:    ERROR
- Batch:        Not specified, inherited from the model
- Input layers:         data
- Output layers:        /work/media/mediastack/gva/benchmark/models/object_detection/common/mobilenet-ssd/
- Input shapes:         [1,3,300,300]
- Mean values:  data[127.5,127.5,127.5]
- Scale values:         data[127.50223128904757]
- Scale factor:         Not specified
- Precision of IR:      FP32
- Enable fusing:        True
- Enable grouped convolutions fusing:   True
- Move mean values to preprocess section:       False
- Reverse input channels:       False
Caffe specific parameters:
- Path to Python Caffe* parser generated from caffe.proto:      mo/front/caffe/proto
- Enable resnet optimization:   True
- Path to the Input prototxt:   /work/media/mediastack/gva/benchmark/models/object_detection/common/mobilenet-ssd/caffe/mobilenet-ssd.prototxt
- Path to CustomLayersMapping.xml:      Default
- Path to a mean file:  Not specified
- Offsets for a mean file:      Not specified
Model Optimizer version:        unknown version
[ ERROR ]  -------------------------------------------------
[ ERROR ]  ----------------- INTERNAL ERROR ----------------
[ ERROR ]  Unexpected exception happened.
[ ERROR ]  Please contact Model Optimizer developers and forward the following information:
[ ERROR ]  'Graph' object has no attribute 'node'
[ ERROR ]  Traceback (most recent call last):
File "/work/ml/openvino_work/dldt/model-optimizer/mo/main.py", line 302, in main
return driver(argv)
File "/work/ml/openvino_work/dldt/model-optimizer/mo/main.py", line 261, in driver
custom_layers_mapping_path=custom_layers_mapping_path)
File "/work/ml/openvino_work/dldt/model-optimizer/mo/pipeline/caffe.py", line 63, in driver
graph, original_shapes = loader.caffe_pb_to_nx(proto, model)
File "/work/ml/openvino_work/dldt/model-optimizer/mo/front/caffe/loader.py", line 252, in caffe_pb_to_nx
kind='op')
File "/work/ml/openvino_work/dldt/model-optimizer/mo/graph/graph.py", line 499, in add_node
node.update_node()
File "/work/ml/openvino_work/dldt/model-optimizer/mo/graph/graph.py", line 464, in update_node
in_ports_count = self.in_ports_count if self.has_valid('in_ports_count') else None
File "/work/ml/openvino_work/dldt/model-optimizer/mo/graph/graph.py", line 155, in has_valid
return self.has(k) and not self.graph.node[self.node][k] is None
File "/work/ml/openvino_work/dldt/model-optimizer/mo/graph/graph.py", line 152, in has
return k in self.graph.node[self.node]
AttributeError: 'Graph' object has no attribute 'node'
[ ERROR ]  ---------------- END OF BUG REPORT --------------
[ ERROR ]  -------------------------------------------------

Hi @guoyejun,
It is not model downloader problem by itself, probably it is problem in installed dependecies version for Model Optimazer.
Which networkx version do you use?

@guoyejun I think solution described here can help you https://github.com/opencv/dldt/issues/294

thanks @eaidova . It is resovled.
and I want to generate int8 model, so add --data_type int8, but met the following issue.
mo.py: error: argument --data_type: invalid choice: 'int8' (choose from 'FP16', 'FP32', 'half', 'float')
could you share how to generate int8 model? thanks.

@guoyejun  conversion to int8 is more complicated operation than switching between fp32 -> fp16, required some estimation to perform this operation with minimal accuracy drop.
There is another tool in openvino2019.2 which help to do it - calibration_tool
http://docs.openvinotoolkit.org/2019_R2/_inference_engine_tools_calibration_tool_README.html

thanks @eaidova . It is resovled.
and I want to generate int8 model, so add --data_type int8, but met the following issue.
mo.py: error: argument --data_type: invalid choice: 'int8' (choose from 'FP16', 'FP32', 'half', 'float')
could you share how to generate int8 model? thanks.

You may want to see this to use the ca

thanks @eaidova . It is resovled.
and I want to generate int8 model, so add --data_type int8, but met the following issue.
mo.py: error: argument --data_type: invalid choice: 'int8' (choose from 'FP16', 'FP32', 'half', 'float')
could you share how to generate int8 model? thanks.

The mo.py currently does not support int8. You need to use the calibration tool mentioned by eaidova to perform the int8 quantization. You can use the simplified mode to estimate the performance first and use the standard mode for real application.

thanks

authors: cocokale eaidova guoyejun


text:
[RHOAIENG-7794]: Use different colors for the ROC curve legend

https://issues.redhat.com/browse/RHOAIENG-7794
Description

Previously in pipelines compare runs we would compare many ROC curves in one graph by using different shades of blue, but per the PF recommendation we should instead be corresponding each run with one of the available base colors.
Before

After

How Has This Been Tested?

Compare runs that have all metrics. Use the following pipeline
Pipeline metrics-visualization-pipeline.yaml.zip
Test Impact

N/A, color change only
Request review criteria:

Self checklist (all need to be checked):

[x] The developer has manually tested the changes and verified that the changes work
[x] Commits have been squashed into descriptive, self-contained units of work (e.g. 'WIP' and 'Implements feedback' style messages have been removed)
[x] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[x] The developer has added tests or explained why testing cannot be added (unit or cypress tests for related changes)

If you have UI changes:

[x] Included any necessary screenshots or gifs if it was a UI change.
[x] Included tags to the UX team if it was a UI/UX change (find relevant UX in the SMEs section).

After the PR is posted & before it merges:

[x] The developer has tested their solution on a cluster by using the image produced by the PR to main

/lgtm

waiting on 1 more review @jenny-s51

/approve

repo: opendatahub-io/odh-dashboard


text:
RoutingResources Controller Refactor

Problem Description

Fixes #231.
Solution
Replaces DAO usage with OpenDCS DAI implementations.
how you tested the change
Unit tests included.
Where the following done:

[ ] Tests. Check all that apply:

[x] Unit tests created or modified that run during ant test.
[ ] Integration tests created or modified that run during integration testing
(Formerly called regression tests.)
[ ] Test procedure descriptions for manual testing

[ ] Was relevant documentation updated?
[ ] Were relevant config element (e.g. XML data) updated as appropriate

If you aren't sure leave unchecked and we will help guide you to want needs changing where.

A few OpenDCS methods may need updated/implemented to complete this task


text:
为什么collector_env和evaluator_env的pid相同

[ ] I have marked all applicable categories:

[ ] exception-raising bug
[ ] RL algorithm bug
[ ] system worker bug
[ ] system utils bug
[ ] code design/refactor
[x] documentation request
[ ] new feature request

[ ] I have visited the readme and doc
[ ] I have searched through the issue tracker and pr tracker
[x] I have mentioned version numbers, operating system and environment, where applicable:

import ding, torch, sys
print(ding.__version__, torch.__version__, sys.version, sys.platform)
v0.4.3 1.12.1+cu116 3.9.7 (default, Sep 16 2021, 16:59:28) [MSC v.1916 64 bit (AMD64)] win32

我用serial_pipeline生成的环境，为什么collector_env和evaluator_env的pid相同？
代码和上一个issue的代码一样：
https://github.com/jaried/study_di
2022-10-10 23:26:52 - PID: 14576
2022-10-10 23:27:14 - PID: 14576

你这里的配置使用的是base，换成subprocess就是多个进程了。一般来说，base是伪的多进程，用来调试代码；调通没问题之后，就用subprocess来实际运行。

我改成    env_manager=dict(type='subprocess'),
仍然是同一个进程
2022-10-11 14:42:07 - PID: 16296
2022-10-11 14:44:56 - PID: 16296

我在我本机运行了你提供的代码（改了一小点代码，不过不影响结论），我这边用subprocess是能跑的，而且PID也不同，如下图所示：

我的环境是：
import ding, torch, sys
print(ding.__version__, torch.__version__, sys.version, sys.platform)
v0.4.3 1.8.0 3.8.5 (default, Sep  4 2020, 02:22:02)
[Clang 10.0.0 ] darwin

所以看起来可能是windows相关的问题，你是只有这一种系统环境吗？

我的ubuntu cuda有点问题，用cpu模式运行了一下，还是同样的pid
import ding, torch, sys
print(ding.__version__, torch.__version__, sys.version, sys.platform)
v0.4.3 1.12.1+cu116 3.9.13 (main, Aug 25 2022, 23:26:10)
[GCC 11.2.0] linux

我这边在 centos 服务器上运行了一下，也是没问题的。。。运行截图如下：

相关库版本信息是：
```python
>>> import ding, torch, sys
>>> print(ding.__version__, torch.__version__, sys.version, sys.platform)
v0.4.3 1.10.0+cu102 3.6.8 (default, Nov 16 2020, 16:55:22)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-44)] linux
```
难道是运行代码有些地方不一致？我把我实际跑的你的仓库代码放到这里了，你可以运行下看看，直接python3 -u option_masac_config.py

我用您的代码运行了一下，是正常的。
但是我比较代码没发现哪不同。我自己再找找原因吧。谢谢您的回答。

repo: opendilab/DI-engine


text:
Add CI for e2e

Description of changes:
Set up CI for e2e.
Basic workflow:

Start ES docker with AD installed
Check out Kibana and set up node to bootstrap
Start local kibana and run E2E test against it

Latest E2E run history is here: https://github.com/opendistro-for-elasticsearch/anomaly-detection-kibana-plugin/pull/203
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

How about we change this to just run on pushes to master for now so we can merge and start using cypress?

How about we change this to just run on pushes to master for now so we can merge and start using cypress?

Totally agree. No clear reply yet. We don't need to wait for the decision. Can add PR triggered test workflow later.

How about we change this to just run on pushes to master for now so we can merge and start using cypress?

Sure. I will use private repo and change to only run it on pushes to master.

Will verify the change after this is merged

authors: ohltyler yizheliu-amazon ylwu-amzn


text:
importC get - Error: asm statement is assumed to use the GC in pico-sdk API

Hi @adamdruppe,
Project: https://github.com/kassane/rp2040-dlang
ldc2: works
opend-ldc2: get errors [see build-output].
Note: betterC disabled and no moduleinfo by default.

build-output
[6/71] Generating _dcode.o
FAILED: _dcode.o /home/kassane/rp2040-dlang/build/_dcode.o
cd /home/kassane/rp2040-dlang/build && /home/kassane/toolchains/opend-latest-linux-x86_64/bin/ldc2 -i -c -preview=all -Xcc=-fshort-enums --verrors-context --boundscheck=on --allinst --linkonce-templates -mtriple=arm-unknown-unknown-eabi -mcpu=cortex-m0 -O --fno-moduleinfo --float-abi=soft -of=/home/kassane/rp2040-dlang/build/_dcode.o -Xcc=-DLIB_PICO_STDLIB=1 -Xcc=-DPICO_BOARD="pico" -Xcc=-DPICO_NO_HARDWARE=0 -Xcc=-DPICO_ON_DEVICE=1 -Xcc=-DPICO_BUILD=1 -Xcc=-DPICO_RP2040=1 -Xcc=-DPICO_32BIT=1 -Xcc=-DLIB_PICO_PLATFORM=1 -Xcc=-DLIB_PICO_PLATFORM_COMPILER=1 -Xcc=-DLIB_PICO_PLATFORM_PANIC=1 -Xcc=-DLIB_PICO_PLATFORM_SECTIONS=1 -Xcc=-DLIB_PICO_SYNC=1 -Xcc=-DLIB_PICO_SYNC_SEM=1 -Xcc=-DLIB_PICO_SYNC_MUTEX=1 -Xcc=-DLIB_PICO_SYNC_CRITICAL_SECTION=1 -Xcc=-DLIB_PICO_TIME=1 -Xcc=-DLIB_PICO_UTIL=1 -Xcc=-DLIB_PICO_TIME_ADAPTER=1 -Xcc=-DLIB_PICO_RUNTIME=1 -Xcc=-DLIB_PICO_RUNTIME_INIT=1 -Xcc=-DLIB_PICO_BIT_OPS=1 -Xcc=-DLIB_PICO_DIVIDER=1 -Xcc=-DLIB_PICO_DOUBLE=1 -Xcc=-DLIB_PICO_INT64_OPS=1 -Xcc=-DLIB_PICO_FLOAT=1 -Xcc=-DLIB_PICO_MALLOC=1 -Xcc=-DLIB_PICO_MEM_OPS=1 -Xcc=-DLIB_PICO_ATOMIC=1 -Xcc=-DLIB_PICO_CXX_OPTIONS=1 -Xcc=-DPICO_CXX_ENABLE_EXCEPTIONS=0 -Xcc=-DLIB_PICO_STANDARD_BINARY_INFO=1 -Xcc=-DLIB_PICO_STANDARD_LINK=1 -Xcc=-DPICO_NO_FLASH=0 -Xcc=-DPICO_USE_BLOCKED_RAM=0 -Xcc=-DPICO_COPY_TO_RAM=0 -Xcc=-DPICO_CMAKE_BUILD_TYPE="Release" -Xcc=-DLIB_PICO_PRINTF=1 -Xcc=-DLIB_PICO_CRT0=1 -Xcc=-DLIB_PICO_CLIB_INTERFACE=1 -Xcc=-DLIB_PICO_NEWLIB_INTERFACE=1 -Xcc=-DLIB_PICO_STDIO=1 $( echo '/home/kassane/embedded/pico-sdk/src/common/pico_stdlib_headers/include;/home/kassane/embedded/pico-sdk/src/rp2_common/hardware_gpio/include;/home/kassane/embedded/pico-sdk/src/common/pico_base_headers/include;/home/kassane/rp2040-dlang/build/generated/pico_base;/home/kassane/embedded/pico-sdk/src/boards/include;/home/kassane/embedded/pico-sdk/src/rp2040/pico_platform/include;/home/kassane/embedded/pico-sdk/src/rp2040/hardware_regs/include;/home/kassane/embedded/pico-sdk/src/rp2_common/hardware_base/include;/home/kassane/embedded/pico-sdk/src/rp2_common/pico_platform_compiler/include;/home/kassane/embedded/pico-sdk/src/rp2_common/pico_platform_panic/include;/home/kassane/embedded/pico-sdk/src/rp2_common/pico_platform_sections/include;/home/kassane/embedded/pico-sdk/src/rp2040/hardware_structs/include;/home/kassane/embedded/pico-sdk/src/common/hardware_claim/include;/home/kassane/embedded/pico-sdk/src/rp2_common/hardware_sync/include;/home/kassane/embedded/pico-sdk/src/rp2_common/hardware_sync_spin_lock/include;/home/kassane/embedded/pico-sdk/src/rp2_common/hardware_irq/include;/home/kassane/embedded/pico-sdk/src/rp2_common/hardware_uart/include;/home/kassane/embedded/pico-sdk/src/rp2_common/hardware_resets/include;/home/kassane/embedded/pico-sdk/src/rp2_common/hardware_clocks/include;/home/kassane/embedded/pico-sdk/src/rp2_common/hardware_pll/include;/home/kassane/embedded/pico-sdk/src/rp2_common/hardware_vreg/include;/home/kassane/embedded/pico-sdk/src/rp2_common/hardware_watchdog/include;/home/kassane/embedded/pico-sdk/src/rp2_common/hardware_ticks/include;/home/kassane/embedded/pico-sdk/src/rp2_common/hardware_xosc/include;/home/kassane/embedded/pico-sdk/src/rp2_common/hardware_divider/include;/home/kassane/embedded/pico-sdk/src/common/pico_time/include;/home/kassane/embedded/pico-sdk/src/rp2_common/hardware_timer/include;/home/kassane/embedded/pico-sdk/src/common/pico_sync/include;/home/kassane/embedded/pico-sdk/src/common/pico_util/include;/home/kassane/embedded/pico-sdk/src/rp2_common/pico_time_adapter/include;/home/kassane/embedded/pico-sdk/src/rp2_common/pico_runtime/include;/home/kassane/embedded/pico-sdk/src/rp2_common/pico_runtime_init/include;/home/kassane/embedded/pico-sdk/src/common/pico_bit_ops_headers/include;/home/kassane/embedded/pico-sdk/src/common/pico_divider_headers/include;/home/kassane/embedded/pico-sdk/src/rp2_common/pico_double/include;/home/kassane/embedded/pico-sdk/src/rp2_common/pico_float/include;/home/kassane/embedded/pico-sdk/src/rp2_common/pico_malloc/include;/home/kassane/embedded/pico-sdk/src/rp2_common/pico_atomic/include;/home/kassane/embedded/pico-sdk/src/common/pico_binary_info/include;/home/kassane/embedded/pico-sdk/src/rp2_common/pico_printf/include;/home/kassane/embedded/pico-sdk/src/rp2_common/pico_stdio/include;/home/kassane/embedded/pico-sdk/src/rp2_common/pico_stdio_uart/include;/home/kassane/embedded/pico-sdk/src/rp2_common/pico_bootrom/include;/home/kassane/embedded/pico-sdk/src/common/boot_picoboot_headers/include;/home/kassane/embedded/pico-sdk/src/rp2_common/hardware_boot_lock/include;/home/kassane/embedded/pico-sdk/src/rp2_common/pico_int64_ops/include;/home/kassane/embedded/pico-sdk/src/rp2_common/pico_mem_ops/include;/home/kassane/embedded/pico-sdk/src/rp2040/boot_stage2/include;/home/kassane/embedded/pico-sdk/src/common/boot_picobin_headers/include' | tr ';' '\n' | sed -e 's/\(.*\)/-P-I\1/g' ) $( echo '/home/kassane/work_nuttx/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/lib/gcc/arm-none-eabi/13.2.1/include /home/kassane/work_nuttx/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/lib/gcc/arm-none-eabi/13.2.1/include-fixed /home/kassane/work_nuttx/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/arm-none-eabi/include' | tr ' ' '\n' | sed -e 's/\(.*\)/-P-I\1/g' ) /home/kassane/rp2040-dlang/sample/app.d -I/home/kassane/rp2040-dlang/source
In file included from <command-line>:
/home/kassane/toolchains/opend-latest-linux-x86_64/bin/../import/importc.h:96:8: warning: undefining "__has_feature"
   96 | #undef __has_feature
      |        ^~~~~~~~~~~~~
/home/kassane/toolchains/opend-latest-linux-x86_64/bin/../import/importc.h:99:8: warning: undefining "__has_extension"
   99 | #undef __has_extension
      |        ^~~~~~~~~~~~~~~
In file included from /home/kassane/embedded/pico-sdk/src/rp2_common/pico_platform_compiler/include/pico/platform/compiler.h:23,
                 from /home/kassane/embedded/pico-sdk/src/rp2040/pico_platform/include/pico/platform.h:23,
                 from /home/kassane/embedded/pico-sdk/src/common/pico_base_headers/include/pico.h:35,
                 from /home/kassane/embedded/pico-sdk/src/common/pico_stdlib_headers/include/pico/stdlib.h:10,
                 from /home/kassane/rp2040-dlang/source/pico/sdk.c:18:
/home/kassane/work_nuttx/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/arm-none-eabi/include/sys/cdefs.h:390:9: warning: "__fastcall" redefined
  390 | #define __fastcall      __attribute__((__fastcall__))
      |         ^~~~~~~~~~
/home/kassane/toolchains/opend-latest-linux-x86_64/bin/../import/importc.h:49:9: note: this is the location of the previous definition
   49 | #define __fastcall
      |         ^~~~~~~~~~
/home/kassane/work_nuttx/arm-gnu-toolchain-13.2.Rel1-x86_64-arm-none-eabi/arm-none-eabi/include/sys/cdefs.h:421:9: warning: "__restrict" redefined
  421 | #define __restrict      restrict
      |         ^~~~~~~~~~
/home/kassane/toolchains/opend-latest-linux-x86_64/bin/../import/importc.h:21:9: note: this is the location of the previous definition
   21 | #define __restrict
      |         ^~~~~~~~~~
/home/kassane/rp2040-dlang/source/pico/package.d(33): Deprecation: from file sdk.c should be imported with 'import sdk;'
public import pico.sdk;
              ^
/home/kassane/embedded/pico-sdk/src/rp2_common/pico_platform_compiler/include/pico/platform/compiler.h(172): Error: `asm` statement is assumed to use the GC - mark it with `@nogc` if it does not
    pico_default_asm_volatile ("" : : : "memory");
    ^
/home/kassane/embedded/pico-sdk/src/rp2_common/pico_platform_compiler/include/pico/platform/compiler.h(172): Error: `asm` statement is assumed to throw - mark it with `nothrow` if it does not
    pico_default_asm_volatile ("" : : : "memory");
    ^
/home/kassane/embedded/pico-sdk/src/rp2040/pico_platform/include/pico/platform.h(104): Error: implicit string concatenation is error-prone and disallowed in D
/home/kassane/embedded/pico-sdk/src/rp2040/pico_platform/include/pico/platform.h(104):        Use the explicit syntax instead (concatenating literals is `@nogc`): "1: subs %0, #3\n" ~ "bcs 1b\n"
/home/kassane/embedded/pico-sdk/src/rp2040/pico_platform/include/pico/platform.h(104): Error: `asm` statement is assumed to use the GC - mark it with `@nogc` if it does not
    pico_default_asm_volatile(
    ^
/home/kassane/embedded/pico-sdk/src/rp2040/pico_platform/include/pico/platform.h(104): Error: `asm` statement is assumed to throw - mark it with `nothrow` if it does not
    pico_default_asm_volatile(
    ^
/home/kassane/embedded/pico-sdk/src/rp2040/pico_platform/include/pico/platform.h(126): Error: `asm` statement is assumed to use the GC - mark it with `@nogc` if it does not
    pico_default_asm_volatile ("bkpt #0" : : : "memory");
    ^
/home/kassane/embedded/pico-sdk/src/rp2040/pico_platform/include/pico/platform.h(126): Error: `asm` statement is assumed to throw - mark it with `nothrow` if it does not
    pico_default_asm_volatile ("bkpt #0" : : : "memory");
    ^
/home/kassane/embedded/pico-sdk/src/rp2040/pico_platform/include/pico/platform.h(153): Error: `asm` statement is assumed to use the GC - mark it with `@nogc` if it does not
    pico_default_asm_volatile ( "mrs %0, ipsr" : "=l" (exception));
    ^
/home/kassane/embedded/pico-sdk/src/rp2040/pico_platform/include/pico/platform.h(153): Error: `asm` statement is assumed to throw - mark it with `nothrow` if it does not
    pico_default_asm_volatile ( "mrs %0, ipsr" : "=l" (exception));
    ^
/home/kassane/embedded/pico-sdk/src/rp2040/pico_platform/include/pico/platform.h(191): Error: `asm` statement is assumed to use the GC - mark it with `@nogc` if it does not
pico_default_asm ("muls %0, %1"     : "+l" (a) : "l" (b) : "cc");
^
/home/kassane/embedded/pico-sdk/src/rp2040/pico_platform/include/pico/platform.h(191): Error: `asm` statement is assumed to throw - mark it with `nothrow` if it does not
pico_default_asm ("muls %0, %1"     : "+l" (a) : "l" (b) : "cc");
^
/home/kassane/embedded/pico-sdk/src/rp2_common/hardware_timer/include/hardware/timer.h(322): Error: shift by 32 is outside the range `0..31`
    uint32_t hi_target = (uint32_t)(target >> 32u);
                                    ^
/home/kassane/embedded/pico-sdk/src/common/pico_time/include/pico/time.h(73): Error: shift by 32 is outside the range `0..31`
    if (us >> 32u) {
        ^
[7/71] Performing configure step for 'picotoolBuild'

How do I add @nogc to generated files?
like, this https://github.com/dlang/dmd/pull/16820 (TODO: v2.111.0)
Expected
No errors!!
Preview on wasm32 - wokwi simulator

running blinkly from RP2040-dlang

hmmm why is that an error at all?

but that linked commit is present in opend https://github.com/opendlang/opend/blob/master/changelog/dmd.importc-pragma-stc.dd so you should be able to do the same thing here as upstream
just like.... i don't know why it cares about nogc/nothrow to begin with. are you using those attributes or are they happening automatically somehow?

are you using those attributes or are they happening automatically somehow?

The nothrow and @nogc attributes are used only in the my  bindings implementation itself, not in sdk.c, called by package.d.
The strangest thing is that you get an error even in betterC mode too.
The PR mentioned above is not yet being implemented in ldc2-upstream (nightly), so the attributes are not applicable on importC.
Based on this error shown it doesn't show my code, just pico-sdk API.

idk i tried cloning your project and didn't get far
CMake Error at /home/me/test/suffering/pico-sdk/cmake/preload/toolchains/util/find_compiler.cmake:29 (message):
Compiler 'arm-none-eabi-gcc' not found, you can specify search path with
"PICO_TOOLCHAIN_PATH".
and yes the folder name is what im experiencing lol.
but like you said it does work out of the box with upstream ldc?

well, i made an exceedingly reduced case after grepping your code for nogc:
// pain.c
#pragma attribute(push, nogc, nothrow)

void foo(void) {
        asm { nop; }
}

That alone is enough to trigger it and it is because that pragma attribute thing is there. Once you make a function nogc, its innards are checked against that too, including asm things... which the compiler can't understand, hence why the error says "assumed".
This works upstream because they either haven't implemented or haven't released their new feature yet - once they do, your code will fail to compile there too.
So now indeed the question is: how to make those asm blocks pass this test? In D, you just write asm @nogc {}....... that's illegal C but importC accepted it! weird. it did not accept nothrow though so you probably can't macro your way out of this.
One possibility would be to hack up the importC asm to assume it is nogc/nothrow. It might be lying but is probably close enough. So basically simply disable that error here.
You can also consider getting rid of that pragma. But I think silencing the error is reasonable.

I'll push that hack up to master, new builds should be available in about half an hour to download with it implemented. If you use upstream you might want to suggest something similar to them - they're just way behind on release schedule but i cherry picked that pragma attribute thing from them so the same thing will happen there eventually. (though why use upstream when you can use opend!)

CMake Error at /home/me/test/suffering/pico-sdk/cmake/preload/toolchains/util/find_compiler.cmake:29 (message):
Compiler 'arm-none-eabi-gcc' not found, you can specify search path with
"PICO_TOOLCHAIN_PATH".

ARM-toolchain not found in system env:PATH.

but like you said it does work out of the box with upstream ldc?

ldc2-upstream :heavy_check_mark:  works in my tests and CI-improvements (opend added - :x:)
https://github.com/kassane/rp2040-dlang/actions/runs/11860734213
I also tried using ldc2-1.36.x to build the project, but I did not get the same error as with opend-ldc2.
If the default safe mode is interfering with importC, I don't know for sure. Is it possible?

I select an isolated test from the pico-sdk api. I got the same error in ldc2-upstream and opend-ldc2.

importedC code
code: https://github.com/raspberrypi/pico-sdk/blob/efe2103f9b28458a1615ff096054479743ade236/src/rp2040/pico_platform/include/pico/platform.h#L104
// #pragma attribute(push, nogc, nothrow)
#include <stdint.h>

#ifdef __ARM_ARCH_ISA_THUMB
#define pico_default_asm(...) __asm(".syntax unified\n" __VA_ARGS__)
#define pico_default_asm_volatile(...)                                         \
  __asm volatile(".syntax unified\n" __VA_ARGS__)
#define pico_default_asm_goto(...) __asm goto(".syntax unified\n" __VA_ARGS__)
#else
#define pico_default_asm(...) __asm(__VA_ARGS__)
#define pico_default_asm_volatile(...) __asm volatile(__VA_ARGS__)
#define pico_default_asm_goto(...) __asm goto(__VA_ARGS__)
#endif

static inline void busy_wait_at_least_cycles(uint32_t minimum_cycles) {
  pico_default_asm_volatile("1: subs %0, #3\n"
                            "bcs 1b\n"
                            : "+l"(minimum_cycles)
                            :
                            : "cc", "memory");
}
// #pragma attribute(pop)

output
$ ldc2 -o- -H test.c -mtriple=arm-unknown-unknown-eabi -mcpu=cortex-m0plus --verrors-context -betterC
In file included from <command-line>:
/home/kassane/toolchains/opend-latest-linux-x86_64/bin/../import/importc.h:96:8: warning: undefining "__has_feature"
   96 | #undef __has_feature
      |        ^~~~~~~~~~~~~
/home/kassane/toolchains/opend-latest-linux-x86_64/bin/../import/importc.h:99:8: warning: undefining "__has_extension"
   99 | #undef __has_extension
      |        ^~~~~~~~~~~~~~~
test.c(17): Error: implicit string concatenation is error-prone and disallowed in D
  pico_default_asm_volatile("1: subs %0, #3\n"
                                  ^
test.c(17):        Use the explicit syntax instead (concatenating literals is `@nogc`): "1: subs %0, #3\n" ~ "bcs 1b\n"

Is it possible to solve this problem in ImportC?

importc is such a mistake, geeze, needs special cases all over the place to handle these. (importc works by adding a bunch of if(c_file) {} stuff to the D parser, so by default, it assumes C and D are the same language)
But yeah, can add a special case to allow this too, it needs to check if is c file, skip that check. Surprised upstream hasn't encountered that yet.

Well golly, it works in dmd but not ldc. I thought this kind of thing was handled in the shared code!

OK, have a fix. Awfully late tonight so i can't fix the other thing, but i'll push this asm fix up to master for you: https://github.com/opendlang/opend/commit/1ba84c3ffda9648971ac857d741a524a7eb779d6
so once it rebuilds the CI thing you should have an update you can test again (takes about 30 mins from writing this). let me know if it works
im 45 mins late for bed and g2g let's hope it all builds automatically lol

importedC code

Works, if:
- #pragma attribute(push, nogc, nothrow)
+ #pragma attribute(push, nogc)

nothrow emit error:
test.c(16): Error: `asm` statement is assumed to throw - mark it with `nothrow` if it does not
  pico_default_asm_volatile("1: subs %0, #3\n"
  ^

rp2040-dlang build. Now there are fewer errors!
/home/kassane/rp2040-dlang/source/pico/package.d(33): Deprecation: from file sdk.c should be imported with 'import sdk;'
public import pico.sdk;
              ^
/home/kassane/swift-embedded-examples/pico-blink-sdk/pico-sdk/src/rp2_common/hardware_timer/include/hardware/timer.h(322): Error: shift by 32 is outside the range `0..31`
    uint32_t hi_target = (uint32_t)(target >> 32u);
                                    ^
/home/kassane/swift-embedded-examples/pico-blink-sdk/pico-sdk/src/common/pico_time/include/pico/time.h(73): Error: shift by 32 is outside the range `0..31`
    if (us >> 32u) {
        ^

It said it shifted by 32 on a 32 bit input, which is illegal. (that's undefined behavior on the x86 cpu, idk about arm). the operator itself works but not with that number
im assuming target is supposed to be 64 bit there...

Anyway, the Issue's main objective has been solved.
I'll see how I can make it work with shifted bits.
Thanks @adamdruppe!

since it is inline the error message points here: https://github.com/raspberrypi/pico-sdk/blob/efe2103f9b28458a1615ff096054479743ade236/src/rp2_common/hardware_timer/include/hardware/timer.h#L320
but yeah it says uint64_t.
and it works in an isolated test.....
#include<stdint.h>

void foo() {
        uint64_t t;
        uint32_t x = t >> 32u;
}

joy.

so that nothrow thing i can do the same as nogc, that's an easy little hack i'll do on my next push
but this shift thing is probably something different.... you might want to check the type after including the file to see what uint64_t became. maybe some macro mess up redefined that as a 32 bit int. or maybe it is a C int that is supposed to be 64 bit but translated to a D int that isn't. see if you can find that and let me know
i don't have the gcc arm toolchain so harder to do myself outside of isolated samples.

On C's side it just emits warnings and compiles normally.
https://gcc.godbolt.org/z/Knj3vcPsa

preprocess result w/ the mtriple:
typedef long long unsigned int uint64_t;

without it:
typedef unsigned long int __uint64_t;
typedef __uint64_t uint64_t;

certainly looks like both are supposed tobe 64 bit but maybe importc gets broken with the other order

yeah D makes a lot of things errors that C leaves as warnings. since it is undefined behavior on the cpu level you don't want it regardless. im sure int64_t is meant to be 64 bits but importc in the d compiler is making it 32.

I think it is not forwarding the target to the preprocessor. So it is using the preprocessor definitions for a 64 bit host despite this being a 32 bit target.

I suggest you open this uint64_t thing upstream ldc. I'm out of time and maybe they'll have ideas
pico.c
#include<stdint.h>

        uint64_t t = 44;

void foo() {
        uint32_t x = (uint32_t)(t >> 32u);
}

build cmd
ldc2 -o- -mtriple=arm-unknown-unknown-eabi pico.c
pico.c(7): Error: shift by 32 is outside the range `0..31`

got your asm nothrow thing hacked in, will be pushed on next update to master.

got your asm nothrow thing hacked in, will be pushed on next update to master.

Amazing! I'll test it.

live on master now so you can redownload the ci release

live on master now so you can redownload the ci release

https://github.com/kassane/rp2040-dlang/actions/runs/11918158583/job/33214932308

hmmmmmm maybe i missed a spot... idk will have to try reducing the test case again

authors: adamdruppe kassane

repo: opendlang/opend


text:
Wire up welcome page with dataverse file info

use dv-file endpoint to get DV file info after login, show details on the Welcome page

Changes for this issue are complete.  We will need to update the welcome page again when the endpoint for retrieving file details is ready. (Right now, this is using the data returned from createDataverseFile but that is only available immediately after the POST to the server.

repo: opendp/opendp-ux


text:
chore(mayastor): remove code to create metadata index on "MayaMeta" partition

Do not create a metadata index on the "MayaMeta" partition for persisting
state of each child, as this information is now stored in etcd.

bors try

bors try

bors try

bors merge

repo: openebs/Mayastor


text:
Develop to Release Fixes

Add missing submodules update.

I've also played with auto-merging but that's a bit more complicated because we've got a min num of 2 reviewers..

bors merge

repo: openebs/mayastor-extensions


text:
feat: Open edX app theming capability improvements

How we can update the theme:-
Steps to be followed:-

Create a resource directory that needs to be customized i.e., Fonts and Resources.

Path: core/src/{directory_name}/res/
Add only those resources that need to be customized i.e, logo, symbols or icons
Place the font.xml file in the src/{directory_name}/res/font directory, alongside the font files.

Update the resource path from core/build.gradle.sourceSets {
   {enviorment_name} {
        res.srcDirs = ['src/{directory_name}/res']
    }
}

Update the Colors.kt according to the desired colors.

Pre-requisite:-

We need to move colors codes from theme.kt to a separate Colors.kt as per material design recommendations. We can also follow the naming conventions suggested by the Material Design 3.
We should specify fonts for the application rather than relying on the device's default fonts, and it's essential to update the font references in Type.kt.

It's advisable to include certain default fonts within the codebase.

PS: As we are going for new architecture we should migrate to Material.io 3.

Looks good to me 👍.
It's a draft. Should we merge or expect more in this PR?

Looks good to me 👍. It's a draft. Should we merge or expect more in this PR?

we can merge it now. 🚀

repo: openedx/openedx-app-android


text:
[BD-46] chore: increase sleep time between merge attempts in analyze dependents action

Description
Include a description of your changes here, along with a link to any relevant Jira tickets and/or Github issues.
Deploy Preview
Include a direct link to your changes in this PR's deploy preview here (e.g., a specific component page).
Merge Checklist

[ ] If your update includes visual changes, have they been reviewed by a designer? Send them a link to the Netlify deploy preview, if applicable.
[ ] Does your change adhere to the documented style conventions?
[ ] Do any prop types have missing descriptions in the Props API tables in the documentation site (check deploy preview)?
[ ] Were your changes tested using all available themes (see theme switcher in the header of the deploy preview, under the "Settings" icon)?
[ ] Were your changes tested in the example app?
[ ] Is there adequate test coverage for your changes?
[ ] Consider whether this change needs to reviewed/QA'ed for accessibility (a11y). If so, please add wittjeff and adamstankiewicz as reviewers on this PR.

Post-merge Checklist

[ ] Verify your changes were released to NPM at the expected version.
[ ] If you'd like, share your contribution in #show-and-tell.
[ ] 🎉 🙌 Celebrate! Thanks for your contribution.

Thanks for the pull request, @viktorrusakov!  Please note that it may take us up to several weeks or months to complete a review and merge your PR.
Feel free to add as much of the following information to the ticket as you can:

supporting documentation
Open edX discussion forum threads
timeline information ("this must be merged by XX date", and why that is)
partner information ("this is a course on edx.org")
any other information that can help Product understand the context for the PR

All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here.
Please let us know once your PR is ready for our review and all tests are green.

@viktorrusakov 🎉 Your pull request was merged!  Please take a moment  to answer a two question survey so we can improve your experience in the future.

:tada: This PR is included in version 22.0.0-alpha.8 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

repo: openedx/paragon


text:
Alternative for money.js - Cashify

Hi everyone!
I recently created Cashify - Lightweight currency conversion library, successor of money.js 💸
I created this package, because money.js:

is not maintained (last commit was ~5 years ago)
has over 20 issues open
does not support TypeScript
has implicit globals
does not have any unit tests

Why you should use Cashify?

Simple API
0 dependencies
Actively maintained
Well tested
100% coverage
Easy migration from money.js
Written in TypeScript

Thanks for mentioning it here

Hey @xxczaki Even Cashify.js isn't active since last 3 years. last commit is 3 years ago

authors: alx-andru surapuramakhil xxczaki


text:
JVM never receives SIGTERM (shutdownhook never called)

Expected Behaviour
I would expect the JVM to receive SIGTERM and then terminate.
I am running a HTTP4S scala webserver in this project:
https://github.com/hejfelix/fp-exercises-and-grading/blob/master/http4s_faas/openfaas/Dockerfile
Current Behaviour
JVM never shuts down before docker container is killed
Possible Solution
Not sure, it seems like watchdog is not forwarding the shutdown hook?
Steps to Reproduce (for bugs)
Add a shutdown hook to any function running in http mode
Context
I want to be able to clean up resources, e.g. database connections, unfinished operations, etc.
Your Environment
Running on docker swarm on my macbook pro
Client: Docker Engine - Community
 Version:           18.09.0-ce-beta1
 API version:       1.39
 Go version:        go1.10.4
 Git commit:        78a6bdb
 Built:             Thu Sep  6 22:41:53 2018
 OS/Arch:           darwin/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.0-ce-beta1
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       78a6bdb
  Built:            Thu Sep  6 22:49:35 2018
  OS/Arch:          linux/amd64
  Experimental:     true

Hi thanks for the question. You get a graceful shutdown period built-in. This gives any HTTP requests a grace period to shut down (you should be able to read about this in the readme)
The period is connected to write_timeout which I see you may not be specifying correctly at present. A Golang duration is needed i.e. 20s.

Derek add label: question

What I'm thinking about is a hook whenever a container is taken out of commission (e.g. scale to 0, function removed, etc.). Having a warm JVM means that collecting/releasing resources on each invocation seems a bit silly, so it would be nice to know when the resources MUST be released.

Are you saying it does indeed forward SIGTERM to the fprocess?

Hi @hejfelix I would be curious as to what Lambda, Google Functions or Azure Functions do in this scenario. If they do pass on SIGTERM then we should investigate it.
Alex

Kubernetes has a rather complicated shutdown procedure regarding health-checks which does not make things easy. cc @LucasRoesler @stefanprodan

My experience with AWS Lambda was that there was no shutdown hook. This essentially meant that I wasted a lot of time acquiring and releasing resources on every invocation. This defeats the purpose of having a warm function.

There are a couple of things that happen during shutdown in a k8s pod

the Pod is marked as terminated/deleted, this also removes it from various Endpoints and Services in k8s
the preStopHook is executed, this allows the Pod to respond to and customize the stop behavior.  But ... this is not something we support configuration of
SIGTERM is sent to the Pod
when the grace period expires, SIGKILL is sent.  The grace period defaults to 30 seconds and can be customized on the Pod spec via terminationGracePeriodSeconds

By far the simplest thing we could do is to listen for and send the SIGTERM to the child process.   Which should already be happening (this is the relevant chunk of code that sends the TERM to the  fprocess in http mode)
In short, a quick review of the code looks like it is trying to send the TERM signal to the fprocess, in this case the JVM.

Interesting -- I am running on docker swarm in all my tests so far. Is that supposed to behave the same way? I guess I'm struggling to find a way to verify that my shutdown hook is run since nothing appears in docker service logs after node is taken down. Any ideas?

Probably the simplest way to verify it is to send a message somewhere, e.g. to RequestBin .  If you are certain that your shutdown hook runs on SIGTERM and If you don't get a message, then that means you didn't get a SIGTERM

Right, so I'm not getting any shutdown hook. This is my scala code:
  Runtime.getRuntime().addShutdownHook(new Thread(){
    override def run(): Unit = Source.fromURL(s"http://requestbin.fullcontact.com/wrh63owr/SHUTDOWN_HOOK_SUCK_IT_LAMBDA_${Random.nextInt}").toList
  } )

Im starting to believe the problem occurs because my web framework is not reacting to sigterm. Will investigate now and return.

authors: LucasRoesler alexellis hejfelix

repo: openfaas-incubator/of-watchdog


text:
Added issue and pr github template.

Signed-off-by: Umesh Yadav umesh4257@gmail.com
I have added github issue and pr template for this repo.
I have added a new optional field which ask which issue it fixes. Previously I came across so many issue which were open even though the pr for them got merged so to address that concern I am adding that.
cc/ @alexellis

LGTM

repo: openfaas/serverless-openfaas


text:
fixed: legacy word-wrapped TextFields would sometimes leave an extra empty line below

disclaimer: I just pushed buttons and this worked (fixed my test cases, and did not break any text not displaying the bug). I actually have no idea what I'm doing.

Thanks! Just cherry-picked the commit :smile:

xD (I don't know how to make git not messy! D:)

This might help :smile:
http://stackoverflow.com/questions/8134960/how-to-revert-master-branch-to-upstream

Cheers :]
So.. Turns out this "fix" is actually wrong. It was a higher-level problem with another library and this only masked the problem :( This change is actually incorrect (hey, I did include a disclaimer!)
Could this be reverted? Sorry! (now I've made more mess)

authors: ProPuke jgranick

repo: openfl/lime


text:
FIXES linker flags for RPi Debian Wheezy and Jessie

Adds missing -L/opt/vc/lib and -lbcm_host linker flags that are needed for linking GLES on the Raspberry Pi running Debian Wheezy or Jessie.
Together with 2 extra defines in sdl/includes/config/rpi/sdl_config.h
#define HAVE_LIBUDEV_H 1
#define SDL_VIDEO_DRIVER_RPI 1
this is the minimum requirement to be able to compile lime with gles2 and device input support on Raspberry Pi running Wheeze or Jessie

Seems like I did something wrong with the sdl-submodule..
closing this pull-request


text:
OpenFoodFacts keeps stopping

OFF version 2.9.8 from FDroid.
Android 7.1.2

During opening I get the error "OpenFoodFacts has stopped", after clicking "Open app again" I get "OpenFoodFacts keeps stopping".
How can I get any logs to help you?

Do you use the app in Polish, by any chance ?

I have English language set systemwide, but I use it in Poland.

What about the app itself. English ?

If you're unfamiliar with logging, you can install Android Studio, connect your device with a USB Cord, and look for the error.

Enable usb debugging
https://developer.android.com/studio/debug/dev-options
2.Look for the Logcat tab at the bottom of Android Studio after installing it, filter on Errors. Filter on "openfood" and you should see the error.

Damn, sorry @teolemon , totally forgot about this. Do you still need logs?

It is fixed, and you can update from master if you want. I don't need logs anymore :-)
Thanks for the vigilance and follow up 👍

fixed

authors: kujaw teolemon

repo: openfoodfacts/openfoodfacts-androidapp


text:
Switch to a more standard day mode

According to today's testers (#193) and if we follow the design proposal (#164), we need to change the colors, mainly the primary color.
That's a good thing, because using white as the primary color as we currently do is a pain in the neck. The standards are to use a strong color as the primary color, where everything is written in white, and there are loopholes: many times we need to explicitly specify: "for this widget, use this color" (if we don't specify the color, it's white on white).
Working on it...

That is a good idea, what would be considered as the primary color. As @stephanegigandet already suggested, a blue might fit. However, I think we shouldn't use this as a background, otherwise the app could look a bit childish.

My job here: put blue[500], and remove all the confusing "white/black" fixes we had to add.
Later, we'll think about the correct color.

Fixed by #201.

repo: openfoodfacts/smooth-app


text:
fix: fixed safearea issue

What

In the image cropper, the Send image button is below the nav bar.
Fixed this by wrap the widget in the safearea.

Screenshot
Before:

After:

Fixes bug(s)

Fixes:  #4366

Codecov Report

Merging #4379 (090f5c6) into develop (6d9df88) will decrease coverage by 0.01%.
The diff coverage is 0.00%.

@@             Coverage Diff             @@
##           develop    #4379      +/-   ##
===========================================
- Coverage    10.31%   10.31%   -0.01%
===========================================
  Files          293      293
  Lines        14704    14705       +1
===========================================
  Hits          1517     1517
- Misses       13187    13188       +1

Files Changed
Coverage Δ

packages/smooth_app/lib/pages/crop_page.dart
0.00% <0.00%> (ø)

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


text:
Build packaged version of toolkits with all dependencies included

This will be important for our supporters who are not able to conda install from online sources, and is thus high-priority.
Also summarize this process at https://github.com/choderalab/software-development

So far, I'm seeing two ways to do this.

conda constructor, which seems to do exactly what we want, but I'm a bit concerned by the lack of stars and the last commit being >1 month ago.
Manually packaging all dependencies and running an offline conda install upon delivery, as described here

I'm leaning toward option 1, and I'll talk to MolSSI this afternoon about it and post notes here.
==========
We'll also need to figure out an infrastructure to perform/host these builds.
It'll probably be something like

add "run constructor" to the deployment process checklist (Or could we bundle this with our eventual integration test framework? So travis would try to conda install the toolkit, run the tests, and then run constructor and push out the constructored packages)
add an openforcefield.org page pointing to a data store where the files are hosted

Notes from meeting with Psi4 devs
(Thanks @loriab!)
Psi4 uses conda constructor
Overall documentation for their release process is here: http://psicode.org/psi4manual/master/manage_release.html#build-psi4conda-set

Build code lives here: https://github.com/psi4/psi4meta/tree/master/conda-recipes/constructor-cutter-unified

Platforms/pythons to build for are defined here: https://github.com/psi4/psi4meta/blob/master/conda-recipes/constructor-cutter-unified/cookiecutter/cookiecutter.json-v1.3
There will be trouble with noarch dependencies (of which we have several), but they may be added manually, as shown at https://github.com/conda/constructor/issues/86#issuecomment-358895352
You can set the resulting environment to have a specific channel priority (we’ll need to set conda-forge and maybe omnia over default if users might do subsequent installs)
If we wanted to also ship optional dependencies (that are available, but not installed by default) we could include packages in a “local/offline” channel. Users could later install optional dependencies from this local channel. (may be useful for supercomputer users, or if there’s a dependency clash)
We can decide whether to ship with raw package data, or just with the packages installed into the environment

Build code runs: On a dedicated linux build machine at Georgia tech.

I’m not sure if we want to do these using a physical machine, or delegate it to Travis.
Compatibility: Linux can build for mac and linux, but a windows machine would be required to build for windows

The output of the constructor gets uploaded to a file server at Georgia tech
The psi4 website then has a PR opened to point “latest” to a new version

Example update PR: https://github.com/psi4/psicode-hugo-website/pull/6
Resulting download page: https://admiring-tesla-08529a.netlify.com/installs/v13/

It's possible we could use something like CircleCI that stores build artifacts in a separate openforcefield-constructor repo that just builds and packages for releases.

This is now complete -- The installer build system is at: https://github.com/openforcefield/toolkit-installer-constructor
Instructions have been tied into the Standard Release Process: https://github.com/openforcefield/openforcefield/issues/286
Installers of the most recent version have been quietly added to the assets list for the 0.4.1 release: https://github.com/openforcefield/openforcefield/releases/tag/0.4.1

authors: j-wags jchodera

repo: openforcefield/openforcefield


text:
Fix undefined stereo crash

Fixes #72. The test feels a little sloppy. The dataset could be pulled out into a fixture like the other test_from_qcarchive_dataset or possibly even combined with that test if you want. I thought about just adding this record into small_qcsubmit_collection too but kept it separate for now.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 90.59%. Comparing base (ce588da) to head (d899d5b).

Additional details and impacted files

authors: codecov-commenter ntBre

repo: openforcefield/yammbs


text:
Error in the class change recipe

The error as attached raises when running the class change recipe. It happens when you click the done button after specifying the images and legend. Tried with Chrome and FireFox still the same issue.

Teo

After understanding the required data (categorical data such as a landcover classification) for this recipe, I have been able to run it with no errors. Thank you @cdanielw for the support. I am closing this issue :)

repo: openforis/sepal


text:
Additional video metrics

Purpose
In the last LA workshop, it has been asked to add various metrics.
Proposal

[x] number of downloads

Don't forget the CHANGELOG!

authors: jmaupetit quitterie-lcs

repo: openfun/potsie


text:
Iss45

Within openghg_inversions, pm.math has been replaced with pytensor.tensor and pm.stats has been replaced with arviz. This is to close issue #45

This was replaced by another PR


text:
render관련 고도화 기능

개요
현재 decapod는 다음의 과정을 거쳐서 실제 배포함

site에 맞는 value 작성 (decapod-site-yaml)
랜더링 과정 (render.sh 또는 docker 명령, github-action 등을 토대로 최종 manifest 생성)
이를 다시 git에 올림
argo-workflow에  해당 repo.를 지정 후 pull (prepare-job)
argo-workflow에서 app별 적용

이 과정에서 2,3,4는 사용자에게 별다른 효용을 주지 않는 것으로 이를 동시에 수행하는 workflow를 작성하여 제공한다면 편의가 증대될 것임
개선방향 제안

사용자는 decapod-site-yaml을 folk하여 site 특화 값을 지정
argo-workflow에서 해당 repo.를 지정 후 prepare-job 수행
argo-workflow에서 app별 적용

개선 방향에 대한 정리가 좀 더 명확해야 할 듯 합니다.
현재 수행되는 단계를 A로 표현하고 개선 방향에 대한 단계를 T로 표현하면, (1) A1~A3 단계를 T1으로 하고 (2) T1, T2를 동시에 수행하는 workflow를 추가하는 2가지를 말씀하시는 것으로 이해하면 될까요?

개선 방향에 대한 정리가 좀 더 명확해야 할 듯 합니다.
현재 수행되는 단계를 A로 표현하고 개선 방향에 대한 단계를 T로 표현하면, (1) A1~A3 단계를 T1으로 하고 (2) T1, T2를 동시에 수행하는 workflow를 추가하는 2가지를 말씀하시는 것으로 이해하면 될까요?

위에 정리해 둔것처럼 1~5의 원 과정에서 2,3,4를 합쳐서 만들자는 내용입니다.

위에 정리해 둔것처럼 1~5의 원 과정에서 2,3,4를 합쳐서 만들자는 내용입니다.

제안주신 내용으로 진행하게 되면 변경되는 사항은 아래와 같습니다.

decapod-site-yaml에서 output folder가 삭제됨
decapod-site-yaml의 directory 구조 개편
APP/site/dev/ --> APP/dev/
decapod-site-yaml의 github action에서 render는 실행(최소한의 validation을 위해) 그러나 output을 commit 하지 않음
decapod-flow의 prepare-manifest에 render 추가

가장 큰 차이점은 output manifest가 git repo에서 삭제되어도 validation은 할 수 있고, 최종 output의 값을 볼 수는 없음 인데
저는 사용자가 output manifest를 볼 니즈가 없다면 이대로 진행하면 될 것 같습니다.

제안주신 내용으로 진행하게 되면 변경되는 사항은 아래와 같습니다.

decapod-site-yaml에서 output folder가 삭제됨
decapod-site-yaml의 directory 구조 개편
APP/site/dev/ --> APP/dev/
decapod-site-yaml의 github action에서 render는 실행(최소한의 validation을 위해) 그러나 output을 commit 하지 않음
decapod-flow의 prepare-manifest에 render 추가

가장 큰 차이점은 output manifest가 git repo에서 삭제되어도 validation은 할 수 있고, 최종 output의 값을 볼 수는 없음 인데
저는 사용자가 output manifest를 볼 니즈가 없다면 이대로 진행하면 될 것 같습니다.

사용자가 decapod-site-yaml 에서 소스를 clone 해서 output folder 에 생성되는 최종 결과물과 동일한 결과물을 얻을 수 있고, 이 방법을 문서로 설명한다면,  2, 3, 4 번의 과정을 workflow 에 넣자는 의견에 찬성합니다.
전제 조건은, 삭제하기 전에 decapod-site-yaml 설명 문서에 로컬에서 output folder 결과물을 생성하는 방법을 먼저 올린 후에 작업이 진행이 됐으면 좋겠습니다.

사용자가 decapod-site-yaml 에서 소스를 clone 해서 output folder 에 생성되는 최종 결과물과 동일한 결과물을 얻을 수 있고, 이 방법을 문서로 설명한다면,  2, 3, 4 번의 과정을 workflow 에 넣자는 의견에 찬성합니다.
전제 조건은, 삭제하기 전에 decapod-site-yaml 설명 문서에 로컬에서 output folder 결과물을 생성하는 방법을 먼저 올린 후에 작업이 진행이 됐으면 좋겠습니다.

사용자가 decapod-site-yaml 에서 소스를 clone 해서 output folder 에 생성되는 최종 결과물과 동일한 결과물을 얻을 수 있고, 이 방법을 문서로 설명한다면, 2, 3, 4 번의 과정을 workflow 에 넣자는 의견에 찬성합니다.
전제 조건은, 삭제하기 전에 decapod-site-yaml 설명 문서에 로컬에서 output folder 결과물을 생성하는 방법을 먼저 올린 후에 작업이 진행이 됐으면 좋겠습니다.

로컬에서는 render.sh을 통해 테스트할 수 있습니다. 이 방법에 대한 문서화(가이드)는 필요합니다.

사용자가 decapod-site-yaml 에서 소스를 clone 해서 output folder 에 생성되는 최종 결과물과 동일한 결과물을 얻을 수 있고, 이 방법을 문서로 설명한다면, 2, 3, 4 번의 과정을 workflow 에 넣자는 의견에 찬성합니다.
전제 조건은, 삭제하기 전에 decapod-site-yaml 설명 문서에 로컬에서 output folder 결과물을 생성하는 방법을 먼저 올린 후에 작업이 진행이 됐으면 좋겠습니다.

로컬에서는 render.sh을 통해 테스트할 수 있습니다. 이 방법에 대한 문서화(가이드)는 필요합니다.

해당 논의는 decapod-site-yaml이 더 적합해보여 옮기도록 하겠습니다.

해당 논의는 decapod-site-yaml이 더 적합해보여 옮기도록 하겠습니다.

authors: intelliguy jabbukka seungkyua zugwan

repo: openinfradev/decapod-base-yaml


text:
讨论下 Kraken 下的 xhr 是否还需要遵循跨域的安全策略？

https://github.com/openkraken/kraken/blob/286396a0f2f706a040926f55fc9dede428548181/bridge/polyfill/src/xhr.ts#L26-L47
bridge 中关于 xhr 的一个 polyfill 是 copy 自 web 浏览器的实现的，但是 Kraken 本质上是 Dart 发起的 native request，不再有跨域限制，个人以为这一段 polyfill 中的 forbiddenHeaders 是可以直接删掉的。

嗯，我个人觉得同源策略在 kraken 不需要

authors: airingursb andycall

repo: openkraken/kraken


text:
Add image loading events to image sources

This follows up on #3248 and adds support for image based sources as well.

Looks good to me, please merge.

authors: ahocevar bartvde


text:
Style clone function doesn't copy the renderer function

I find this:
The new style options don't have a renderer property.
https://github.com/openlayers/openlayers/blob/1a952e7a41a030791780af6086ca4ad91e30e6f0/src/ol/style/Style.js#L213-L226

Someone correct me if I'm wrong, but wouldn't this require a deep copy of the renderer property?
The obvious solution, of course, would be to just add renderer: this.getRenderer() ? this.getRenderer() : undefined, into the properties of the new Style, but that would create issues because it would only pass the renderer function by reference.
To properly clone the renderer function, I think a deep copy of the renderer function object would be needed.  Core JavaScript doesn't provide a good way of creating a deep copy of an object that contains functions, so a true solution would require either a custom deep copy function to be added to OpenLayers, or the use of a third-party library that provides a deep copy function.  A third-party library would add another dependency, since I don't believe any of the current OpenLayers dependencies provide deep copy functions.

I've wondered before whether a deep copy of a function is necessary.If a function is defined and used according to the standard specification, there is no need for a deep copy.I understand that many circumstances need to be considered for the convenience of deep copy of the function. In this case, I suggest some supplementary instructions on style.clone in the API documentation to make it clear that no copy will be carried out for the renderer function.

There seems to be no attempt to deep clone functions in the library.  If geometry is a function there is also no deep clone.  The style of a feature is not deep cloned, regardless of whether it is a function.

In that case, taking a cue from how clone() handles the geometry property, we should be able to do renderer: this.getRenderer() to get the same kind of copy as geometry would get if it were a function.
Would that be an appropriate fix for this issue, or would it be better to leave clone() as is and simply state in the API that the renderer function is not copied?

I created PR #11893 to move the issue forward.

I created PR #11893 to move the issue forward.

authors: changqingom mike-000 mjjurkoic

repo: openlayers/openlayers


text:
Trying to fix CI

Looks like recent versions of Puppeteer do not work with node 14, which is what CircleCI is using now. This pull request fixes the CI, which is broken for all new pull requests since some time yesterday.

It looks like a bug in node that affected puppeteer has been fixed https://github.com/nodejs/node/pull/32968.  No reason to rush it, but it may be safe to upgrade again.  See also https://github.com/puppeteer/puppeteer/issues/5719.

@tschaub Done already by @dependabot, in #11002.

#11002 brought in puppeteer@3.0.2, which only logged an error in Node 14.  It looks like #11032 will bring in puppeteer@3.0.4, which is the version that works with Node 14.1 and doesn't log a warning (see puppeteer/puppeteer#5816).

authors: ahocevar tschaub


text:
New tile source for the WMTS example

Fixes #12767
The demographics service has been withdrawn from https://services.arcgisonline.com/arcgis/rest/services/  Alternative demographics sources are either slow, basic or require a subscription, so I have replaced it with a geology overlay for the same region.

Thanks for finding an alternative, @mike-000


text:
scale firefox and chrome

Increase number of firefox and chrome
Related to https://github.com/openmicroscopy/devspace/pull/88

LGTM.

authors: jburel joshmoore

repo: openmicroscopy/ansible-role-devspace


text:
Remove ome-demoserver playbook from the allowed failures list

See https://github.com/openmicroscopy/prod-playbooks/pull/11#issuecomment-347582513
This should increase the strictness of the demo playbook by failing Travis if the syntax is invalid.

👍  - looks good. I have to learn how to interpret travis output for the 541 upgrades PRs - I didn't think it was doing anything.

Thanks @kennethgillen. Merging and the Travis output parsing can be discussed if the builds turn red.

authors: kennethgillen sbesson

repo: openmicroscopy/prod-playbooks


text:
Dataset for new batch of molecular structures

I have a small batch of molecular structures that I would like to run through the psi4 protocol here (no MD or relaxation needed), so that I can generate a new dataset in the same format as the rest of SPICE. Is there a script around to do that? I have the structures in one extended xyz file.

Hi @JoshRackers, here is one dataset submission directory on how the input hdf5 file was processed using openff-qcsubmit and computed using qcfractal server hosted by MolSSI (you can set up your own server, some tutorials here).

Thanks! Let me make sure I have this correct:

I run a version of the Jupyter notebook from your first link to produce a "dataset" like this: [https://github.com/openforcefield/qca-dataset-submission/blob/master/submissions/2021-11-15-QMDataset-DES-monomers-single-points/dataset.json.bz2]  In this example, I see that the molecule structures are read in in an hdf5 file. Is this the only file type supported?
I submit that that "dataset" file to a qcfractal server. I can do this either on my own server if I set up qcfractal there or submit directly to the MOLSSI resource.

Is that right?

Is this the only file type supported?

It can take smiles, or sdf files, or openff molecules as well.

I submit that that "dataset" file to a qcfractal server. I can do this either on my own server if I set up qcfractal there or submit directly to the MOLSSI resource.

Yeah, that's right. To submit to MolSSI server you may need credentials (tagging @bennybp @dotsdl), and compute managers to do the calculations.
If you are not calculating in 1000's then another easy way is to parallelize a qcengine compute energy call with dask or multiprocessing, here is a single point energy calculation
from qcelemental.models import AtomicInput, Molecule, DriverEnum
from qcelemental.models.common_models import Model
from qcengine import compute

def main():
    qcmol = Molecule.from_data(
        """
    0 1
    H            0.856507560196     0.771327307016     0.559729319002
    O            0.121036132436     0.684379466849    -0.035268035646
    O           -0.121036132436    -0.684379466849    -0.035268035646
    H           -0.856507560196    -0.771327307016     0.559729319002
    """
    )

    print(qcmol)
    result = compute(
        input_data=AtomicInput(
            molecule=qcmol,
            driver=DriverEnum.gradient,
            model=Model(
                method="wb97m-d3bj",
                basis="def2-tzvppd",
                keywords={
                    "wcombine": False,
                    "implicit_solvent": "null",
                    "store_wavefunction": "none",
                    "maxiter": 200,
                    "scf_properties": [
                        "dipole",
                        "quadrupole",
                        "wiberg_lowdin_indices",
                        "mayer_indices",
                        "mbis_charges",
                    ],
                },
            ),
        ),
        program="psi4",
        local_options={"ncores": 8, "jobs_per_node": 1, "scratch_directory": "/tmp/"},
    )
    breakpoint()
    print("Energy:", result.properties.scf_total_energy)
    print("Gradient:", result.properties.scf_total_gradient)
    print("Dipole moment:", result.properties.scf_dipole_moment)

if __name__ == "__main__":
    main()

I think from_string() can take xyz as well. I didn't get all the scf_properties I asked it to calculate, might be something wrong there, other than that this should work.

It would be good to add this to the documentation.  A few people have told me they'd like to generate their own data to use along with SPICE.  For example, could we provide a Psi4 input file that shows exactly what settings to use?

I agree that providing an input file template would really be helpful.  For running the single point calculations, the template would actually be sufficient because there's many ways to execute Psi4 in an embarrassingly parallel way; @pavankum had a great suggestion but I also like to use Work Queue for parallelization.
Also, I think that if the script for generating the structures could be shared, it would be helpful for future contributors to generate data that has more consistency with as what's already in SPICE.  In terms of the quality of the final fitted potential, I think the procedure for generating structures has a huge impact and may be as important as choosing the right level of theory.

Here is a sample template for psi4
memory 180 gb
psi4_io.set_default_path("/tmp")

molecule sample{
0 1
S    2.14115412    3.34483413    5.83118474
S    3.93694189    2.43268204    2.54786115
C    0.25443274    6.03087160    4.89660178
C    6.63161588    4.52659328    2.59640792
H   -0.85733096    6.62095777    6.5580485
H   -1.06142141    5.53854171    3.35689051
H    1.42978575    7.63740400    4.27843445
H    6.06683372    6.53232955    2.5450074
H    7.81091820    4.21108460    4.28587972
H    7.77333187    4.11376355    0.90211747
--
1 1
Li   1.41761583   -6.70427585    5.96771769
units bohr
symmetry c1
noreorient
nocom
}

set {
 wcombine false
 }

props = ['DIPOLE', 'QUADRUPOLE', 'WIBERG_LOWDIN_INDICES', 'MAYER_INDICES']
gradient('wB97M-D3(BJ)/def2-TZVPPD', properties=props)
clean()

Equivalent input via qcengine
import numpy as np
import psi4
import json

json_data = {'driver': 'gradient',
 'extras': {'_qcfractal_tags': {'keywords': '32', 'program': 'psi4'}},
 'id': '100346221',
 'keywords': {'maxiter': 200,
              'scf_properties': ['dipole', 'quadrupole', 'wiberg_lowdin_indices', 'mayer_indices'],
              'wcombine': False},
 'model': {'basis': 'def2-tzvppd', 'method': 'wb97m-d3bj'},
 'molecule': {'connectivity': [[0, 1, 1.0], [0, 2, 1.0], [1, 3, 1.0], [2, 4, 1.0], [2, 5, 1.0], [2, 6, 1.0],
                               [3, 7, 1.0], [3, 8, 1.0], [3, 9, 1.0]],
              'extras': {'canonical_isomeric_explicit_hydrogen_mapped_smiles': '[H:5][C:3]([H:6])([H:7])[S:1][S:2][C:4]([H:8])([H:9])[H:10].[Li+:11]'},
              'fix_com': True,
              'fix_orientation': True,
              'fix_symmetry': 'c1',
              'fragment_charges': [0.0, 1.0],
              'fragments': [[0, 1, 2, 3, 4, 5, 6, 7, 8, 9], [10]],
              'geometry': [2.14115412, 3.34483413, 5.83118474, 3.93694189, 2.43268204, 2.54786115, 0.25443274,
                           6.0308716, 4.89660178, 6.63161588, 4.52659328, 2.59640792, -0.85733096, 6.62095777,
                           6.5580485, -1.06142141, 5.53854171, 3.35689051, 1.42978575, 7.637404, 4.27843445, 6.06683372,
                           6.53232955, 2.5450074, 7.8109182, 4.2110846, 4.28587972, 7.77333187, 4.11376355, 0.90211747,
                           1.41761583, -6.70427585, 5.96771769],
              'id': '91096659',
              'identifiers': {'molecular_formula': 'C2H6LiS2',
                              'molecule_hash': '2481d82ffb6de16461d032bbe6355ee2fbe13dc8'},
              'molecular_charge': 1.0,
              'molecular_multiplicity': 1,
              'name': 'C2H6LiS2',
              'provenance': {'creator': 'QCElemental',
                             'routine': 'qcelemental.molparse.from_schema',
                             'version': 'v0.22.0'},
              'schema_name': 'qcschema_molecule',
              'schema_version': 2,
              'symbols': ['S', 'S', 'C', 'C', 'H', 'H', 'H', 'H', 'H', 'H', 'Li'],
              'validated': True},
 'protocols': {'wavefunction': 'none'},
 'provenance': {'creator': 'QCElemental', 'routine': 'qcelemental.models.results', 'version': 'v0.24.0'},
 'schema_name': 'qcschema_input',
 'schema_version': 1}

psi4.set_num_threads(40)
psi4.set_memory('180 GB')
json_ret = psi4.schema_wrapper.run_qcschema(json_data)
print(json_ret.stdout)
with open('output_'+json_data['id']+'.out', 'w') as f:
    f.write(json_ret.stdout)

All the scripts used to generate conformations are in this repository.  For example, here is the script for PubChem molecules.
@pavankum thanks for the example files.  I'll put together some documentation based on them.

authors: JoshRackers leeping pavankum peastman

repo: openmm/spice-dataset


text:
JJP Stewart March update:

readmo.F90: Allow "PDB(text)" to also indicate that the geometry is in PDB format.
big_swap.F90: Allow numbers after a quoted string to be handled correctly.
getgeo.F90: When converting to XYZ coordinates, delete all connectivity, including when dummy atoms are present.
geo_ref.F90: Allow a GEO_REF to refer to SELF even when the data-set used GEO_DAT.
wrtkey.F90: New keyword NEWPDB converts PDB format into the modern PDB version, version 3.
pdbout.F90: Allow the first atom in a PDB file to be a dummy atom.
geochk.F90: Allow for dummy atoms when adding or deleting hydrogen atoms.
geochk.F90: Suppress print of PDB geometry until after atoms are resequenced.
PDB3.F90: Construct label that complies with the PDB-3.n format for hydrogen atoms.

Codecov Report

Merging #21 (e7f520e) into main (e01e015) will decrease coverage by 0.16%.
The diff coverage is 10.29%.

@@            Coverage Diff             @@
##             main      #21      +/-   ##
==========================================
- Coverage   68.41%   68.25%   -0.17%
==========================================
  Files         328      330       +2
  Lines       71377    71585     +208
==========================================
+ Hits        48836    48857      +21
- Misses      22541    22728     +187

Impacted Files
Coverage Δ

src/chemistry/PDB3.F90
0.00% <0.00%> (ø)

src/run_mopac.F90
77.90% <0.00%> (+0.03%)
:arrow_up:

src/input/geo_ref.F90
64.40% <23.07%> (-0.61%)
:arrow_down:

src/input/wrtkey.F90
64.03% <25.00%> (-0.23%)
:arrow_down:

src/chemistry/geochk.F90
83.11% <90.90%> (+0.22%)
:arrow_up:

src/chemistry/geochk_bits_1.F90
76.37% <100.00%> (+0.03%)
:arrow_up:

src/input/getgeo.F90
55.55% <100.00%> (ø)

src/input/readmo.F90
54.57% <100.00%> (ø)

src/output/pdbout.F90
88.37% <100.00%> (+0.02%)
:arrow_up:

src/reactions/big_swap.F90
85.25% <100.00%> (+0.04%)
:arrow_up:

... and 24 more

Continue to review full report at Codecov.

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

authors: codecov-commenter godotalgorithm

repo: openmopac/mopac


text:
adding cell2location method (3 options)

This PR adds cell2location for the spatial decomposition task, in particular 3 options to use the methods:

cell2location - cell2locations with default normalisation regularisation parameter detection_alpha
cell2location_detection_alpha_200 -  cell2locations with normalisation regularisation parameter detection_alpha=200. See paragraph about detection_alpha for explanation.
cell2location_amortised - cell2location which used an amortising neural network to approximate the posterior distribution of cell abundance (loc and scales), rather than estimating the per-location abundance of each cell type directly.

Submission type

[x] This submission adds a new method

Testing

[x] This submission was written on a forked copy of SingleCellOpenProblems
[x] GitHub Actions "Run Benchmark" tests are passing on this base branch of this pull
request (include link to passed test: https://github.com/vitkl/openproblems/actions/runs/2901621720)
[x] If this pull request is not ready for review (including passing the "Run
Benchmark" tests), I will open this PR as a draft (click on the down arrow next to the
"Create Pull Request" button)

Submission guidelines

[x] This submission follows the guidelines in our
Contributing document
[x] I have checked to ensure there aren't other open Pull Requests for the
same update/change

PR review checklist
This PR will be evaluated on the basis of the following checks:

[x] The latest version of master is merged and tested
[x] The methods/metrics are imported to __init__.py and were tested in the pipeline
[x] Method and metric decorators are annotated with paper title, year, author, code
version, and date
[ ] The README gives an outline of the methods, metrics and datasets in the folder

The methods/metrics are imported to init.py and were tested in the pipeline

This does not need to be explicitly added, right?

The methods/metrics are imported to init.py and were tested in the pipeline

This does not need to be explicitly added, right?

It does need to be added explicitly added, otherwise the test framework does not know which functions are methods.

Moving to draft until tests pass

Actually one question - should the method return proportions or is adata.obsm["proportions_pred"] normalised by sum per observation in the metrics workflow?

I see, I need to see the results of the workflow to check that there are no misleading differences.

Lets merge.

authors: scottgigante-immunai vitkl

repo: openproblems-bio/openproblems


text:
A604204973640971 swiftsure procedure

Add model forwarding imports
Depends on:

https://github.com/openprocurement/openprocurement.api/pull/314

Coverage remained the same at 52.857% when pulling 52d70e1a7d9bf0a3c2fd88028373227f219fef1c on Scandie:a604204973640971_swiftsure_procedure into 73a2efd72addd6aed9a43f219b4d3869cd980119 on openprocurement:master.

authors: Scandie coveralls


text:
Error on type alias for function type

The following test:
    @Test
    void typeAliasForFunctionType() {
        rewriteRun(
          kotlin(
            """
              typealias Action = (String) -> Unit
              """
          )
        );
    }

results in the following exception:
java.lang.ClassCastException: class org.openrewrite.kotlin.tree.K$FunctionType cannot be cast to class org.openrewrite.java.tree.Expression (org.openrewrite.kotlin.tree.K$FunctionType and org.openrewrite.java.tree.Expression are in unnamed module of loader 'app')
	at org.openrewrite.kotlin.internal.KotlinParserVisitor.visitTypeAlias(KotlinParserVisitor.kt:2831)
	at org.openrewrite.kotlin.internal.KotlinParserVisitor.visitElement0(KotlinParserVisitor.kt:4588)
	at org.openrewrite.kotlin.internal.KotlinParserVisitor.visitElement(KotlinParserVisitor.kt:4524)
	at org.openrewrite.kotlin.internal.KotlinParserVisitor.visitFile(KotlinParserVisitor.kt:166)
	at org.openrewrite.kotlin.KotlinParser.lambda$parseInputs$3(KotlinParser.java:176)

We currently map a typealias to a variable declaration with an "empty" name, the alias as the type, and the aliased type as the initializer. The last bit is also where it goes wrong, because a K.FunctionType is a TypeTree, but not an Expression. Instead of using a variable declaration we should probably add a new K.TypeAlias statement type.
@traceyyoshima What are your thoughts on this?

Please note that https://github.com/openrewrite/rewrite-kotlin/commit/a880c6da45e033ee2a120941279dbfb49fe80170 now fixes the parsing side, but I think the LST is still suboptimal here.

Fixed in PSI parser

authors: knutwannheden traceyyoshima

repo: openrewrite/rewrite-kotlin


text:
Parse troublesome Yaml with new workaround in workaround for underying parser bug

What's changed?
Prevent IndexOutOfBoundsException with new workaround for issues in the underlying YamlParser events.
What's your motivation?
Received reports about failures with a particular Yaml snippet; with this exact snippet you hit the new conditional.
Even if you change strings in the Yaml snippet, you will not hit the new conditional; Fun times to be had tracing that down.
Have you considered any alternatives or workarounds?
Ideally we report this upstream and see it resolved there.
Any additional context
The earlier workaround was introduced in these two commits to work around bugs with the underlying Yaml parser we use.

https://github.com/openrewrite/rewrite/pull/4178
https://github.com/openrewrite/rewrite/pull/4187

@pdulich you might enjoy this one; a very specific Yaml snippet managed to trigger a bug in the workaround for the parser bug you discovered earlier. Those parser events sure seem off at times.

Thanks for the report. I already know the cause.
There are many other problems with the parser. Therefore, I'm completely rewriting it.
In the meantime I can push a bugfix for this issue.

Thanks a lot! This PR already adds a minimal workaround that might cause the least amount of conflicts; are you ok with me merging this in the meantime or do you see another quick option?

Oh haha. Sorry. I'm at work and only had a quick look on your comment. I didn't realize that this is a PR and not an issue.
If I remember correctly, the real bugfix is to replace getIndex() by getPointer().

Ah perfect, trying that now; passed locally with just that replacement, thanks!

There are many other problems with the parser. Therefore, I'm completely rewriting it.

Could you tell us a bit more about your plans here? It can at times be challenging to review large sweeping changes, as much as the effort you'd put in might be appreciated. Just want to be sure we don't end up with a PR that's hard to see through.

authors: pdulich timtebeek

repo: openrewrite/rewrite


text:
[Feature]: Publish to Conda

Describe the feature you want to add
add associated GitHub action to publish to conda(like PyPI auto-upload)
Describe your proposed solution
No response
Describe alternatives you've considered, if relevant
No response
Additional context
No response

Hi Sadra, could you please do this task?
@sadrasabouri

I will soon add the anaconda token to the repositories secrets.

I will soon add the anaconda token to the repositories secrets.

Hi Sadra, could you please do this task? @sadrasabouri

Yes, sure. I self-assign it.

I will soon add the anaconda token to the repositories secrets.

Let me know when you added it then I will start.

@sepandhaghighi can you start to work on this? it is crucial for this release.

I was waiting for you to add an anaconda token to the repository secret and update this thread. As mentioned in the latest message.

Oh shit, sorry Sadra, sure!

@sadrasabouri
Anaconda Token is added as a single repository secret.
Go ahead man.

authors: AHReccese sadrasabouri

repo: openscilab/pymilo