[BEAM-8575] Removed MAX_TIMESTAMP from testing data

Removed MAX_TIMESTAMP from testing data, because the semantics of these extremum elements are not decided yet.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

Retest this please

R: @angoenka

R: @robertwb

Run Python PreCommit

This looks good to me.

LGTM
You can un-sickbay the tests separately if needed.

Retest this please

Retest this please

This PR fixed BEAM-9003, so I unsickbayed this test.

Run Python Dataflow ValidatesRunner

Run Python Dataflow ValidatesRunner

Run Python Dataflow ValidatesRunner

Retest this please

Run Python PreCommit

Run Python PreCommit

Run Python PreCommit

Run Python PreCommit

Run Python PreCommit

Run PythonLint PreCommit

Run PythonLint PreCommit

Will wait for the tests to pass and merge

Run PythonLint PreCommit


change to centos 7 build

Why did we move "pip3 install -r requirements.txt" from install dependencies to build? (just curious)

trying to match the readme as closely as possible https://github.com/intel/PerfSpect#building-binaries-from-source-code


Fablo recreate fail

Hi,
I'm using Fablo on WSL2 + Docker Desktop.
Each time when I try to recreate Fabric network, I get the following error:
Network target directory is empty
Generating network config
    FABLO_VERSION:      1.1.0
    FABLO_CONFIG:       /mnt/d/Workspace/Blockchain/supply-chain-poc/fablo-config.yaml
    FABLO_NETWORK_ROOT: /mnt/d/Workspace/Blockchain/supply-chain-poc/fablo-target
Validation errors count: 0
Validation warnings count: 0

Used network config: /network/workspace/../../network/fablo-config.json
Fabric version is: 2.4.0
Generating docker-compose network 'fablo_network_202302201052'...
   create fabric-config/crypto-config-orderer.yaml
node:internal/fs/utils:345
    throw err;
    ^
Error: ENOENT: no such file or directory, open '/network/workspace/fabric-config/crypto-config-orderer.yaml'
    at Object.openSync (node:fs:591:3)
    at Object.writeFileSync (node:fs:2212:35)
    at write (/fablo/node_modules/mem-fs-editor/lib/actions/commit.js:15:6)
    at DestroyableTransform._transform (/fablo/node_modules/mem-fs-editor/lib/actions/commit.js:49:7)
    at Transform._read (/fablo/node_modules/mem-fs-editor/node_modules/readable-stream/lib/_stream_transform.js:177:10)
    at Transform._write (/fablo/node_modules/mem-fs-editor/node_modules/readable-stream/lib/_stream_transform.js:164:83)
    at doWrite (/fablo/node_modules/mem-fs-editor/node_modules/readable-stream/lib/_stream_writable.js:409:139)
    at writeOrBuffer (/fablo/node_modules/mem-fs-editor/node_modules/readable-stream/lib/_stream_writable.js:398:5)
    at Writable.write (/fablo/node_modules/mem-fs-editor/node_modules/readable-stream/lib/_stream_writable.js:307:11)
    at DestroyableTransform.ondata (/fablo/node_modules/yeoman-generator/node_modules/readable-stream/lib/_stream_readable.js:681:20) {
  errno: -2,
  syscall: 'open',
  code: 'ENOENT',
  path: '/network/workspace/fabric-config/crypto-config-orderer.yaml'
}`
Node.js v18.3.0

After this error, the only way to make Fablo work is to restart Docker Desktop ( I was trying to remove config/target files + reinitialize, remove docker volumes + particular/all images ), but the error still persists.

./fablo prune seems to work properly ( remove all containers and target folder content - I haven't noticed any "dangling" container after I use this command).
Just tried this one - ./fablo prune && sleep 5 && ./fablo up - didn't help :(
But when I unmounted manually from /mnt/wsl/docker-desktop-bind-mounts, only then it starts to work.
So it seems that you have the right regarding blocking mounted directories.
I'm wondering why after manually removing volumes from the Docker Desktop, the mounts still last.
Btw. thanks for the tip :)

Is network-target the same or child directory of chaincode source? network-target contains docker compose file with chaincode directory mounted as a volume. So you may end up with a situation, when docker compose mounts its parent directory. I guess this might cause some errors with unmount.

network-target ? did you mean fablo-target ? if so, the answer is no - they are in separate locations. can't move chain code to different location (project requirements )
btw. I've tested the same repo code on MacOS - no issue as for now, only on WSL2.

Yes, it should be fablo-target in my previous message. So, if they are in separate locations, I suspect some issues with Docker mounts. But I don't have a solution for that, sorry 😞 Let us know if you find the actual cause, it will help us to improve Fablo.


Fix document splitting in specified format

The current relaton split interface only can parse a RXL/XML file and write to a variation of XML file (RXL / XML) file, but the problem arises when we define yaml as output extension, then it still writes
the XML content, but usages YAML for file name only. This cases to new problems.
So, this commit fixes these issues, so now it will check for the output format first, and if it's different than XML then it will parse the content to that format first and then write it to the new file.
This interface also used to write the collection file in the output directory, which introduced some issues like #41, so this commit also disables that for now.
Another thing, it also updates the build_filename method to remove all of the invalid characters from a file name.

Thank you @abunashir !
Regarding the format and the extension name, I supposed there is a difference. We are currently mixing the two.
What do you think is the best way to resolve it? e.g. YAML can be using yml extension too.

Hi @ronaldtse, Ideally, we should prefer to stick to one regardless of what we pick (based on GitHub the most used one is yml). But, from a technical perspective we should have support for both, so whatever they write it means the same right?

Yup agree?

@abunashir I have released your latest commit as part of my routine gem releases (which I am trying to do fortnightly).

Cool, thanks a lot @opoudjis!


[Frontend][Pytorch] Improve Pytorch frontend for object detection models

Some necessary improvements for pytorch od models.
@zhiics @yongwww @masahi

cc @siju-samuel @t-vi

@kevinthesun Thanks for working on this. Can you split this into multiple PRs? In particular, besides the new op conversion, you made many non trivial changes to existng ops. Without tests for the latter changes, it is hard to tell what they are for.
We can merge the new op conversion first (as they came with tests).

@masahi These changes are mainly for torch vision rcnn models which enhances current features. There is another PR adding some backend stuffs. After that I can add e2e torch vision rcnn tests into this PR  which should cover all changes.

@kevinthesun sounds like you already have mask rcnn working :) can't wait

@masahi Coming soon. :D

If try ... except is necessary, I recommend adding a wrapper function around _infer_value, and isolate try ... except logic there. I see many repeated try ... except

@masahi The problem of creating a try_infer_value API is that it doesn't simplify the codes since we need to do various handling in except block for different ops. We still need to check the output of try_infer_value and have a branching to decide what actions to take.

But we should still know when it is appropriate to run the inference, should we not?
I must admit I'm still troubled by the idea that we don't know beforehand which inputs to process with which method.

But we should still know when it is appropriate to run the inference, should we not?
I must admit I'm still troubled by the idea that we don't know beforehand which inputs to process with which method.
We do this for some ops which have dynamic attributes. When those dynamic attributes are relay Expr, we need to try to infer value to make the generated relay program as static as possible.

E2E tests added. Now waiting for https://github.com/apache/incubator-tvm/pull/6464.

Thanks for the efforts and discussions. @kevinthesun could you please summarize the solutions/decisions to align with @masahi and @t-vi?

@zhiics @masahi @t-vi Sure. One major thing in this PR is the handling for dynamic operators such as slice, arange and topk. These ops have dynamic attribute which affects relay type inference. The methodology here is to try to infer these values to make them as static as possible(Similar in tf parser).
@masahi suggested we can have an API wrap around try except blocks. However, the issue is for this method is for different ops the logic inside try except can be quite different and hard to generate a uniform interface.
@t-vi suggested we can check the input type to see whether we need to do such try except infer_value. Currently we differentiate between relay expr and numerical values. For these dynamic ops, we try to infer value when dynamic attribute is a Relay Expr to see whether it can become a numerical value. For all the subtype under relay Expr, we just call uniform interface of _infer_value to handle them.
Any comments or suggestions?

Is moving to fully dynamic frontend like being done for onnx https://github.com/apache/incubator-tvm/pull/6351 help removing infer_value usage?

Is moving to fully dynamic frontend like being done for onnx #6351 help removing infer_value usage?

While we try to make relay expression as static as possible, a lot of work can still only be done in frontend. For these cases we still need to use _infer_value. This happens a lot for tf/pt od models. For some simple ops such as topk, we can directly use dyn namespace op and eliminate _infer_value.

@kevinthesun I get this error from faster rcnn and mask rcnn. Is this expected?
  File "/mnt/2e797a66-fd2b-44fc-a3ba-24d7d65f2780/projects/dev/tvm/src/te/schedule/schedule_postproc_to_primfunc.cc", line 131
TVMError: Check failed: allow_alloc: Cannot find the Realization point of tensor Tensor(shape=[1], op.name=box_data_length)
During handling of the above exception, another exception occurred:

TVMError: Check failed: allow_alloc: Cannot find the Realization point of tensor Tensor(shape=[1], op.name=box_data_length)
Error during compile function
-----------------------------
#[version = "0.0.5"]
fn (%p0: Tensor[(1, ?, ?), float32], Primitive=1) -> (Tensor[(1), int32], Tensor[(1, ?, ?), float32], Tensor[(1, ?), int32]) {
  vision.get_valid_counts(%p0, meta[relay.attrs.GetValidCountsAttrs][0]) /* ty=(Tensor[(1), int32], Tensor[(1, ?, ?), float32], Tensor[(1, ?), int32]) */
}

@kevinthesun Thanks I'm trying running e2e on my end. How long does it take to compile faster or mask rcnn? I remember hearing TF faster rcnn taking 20 min to compile. If it is too slow, it might not be a good idea to run them on CI...

@zhiics @kevinthesun @masahi
Thank you, @kevinthesun for your summary and all the work in the investigation and your PR.
I think using if isinstance(..., _expr.Expr): would be very much preferable to using exceptions.

I see the uses of try: ... except: ... as using exceptions for regular control flow (because the error case is the one where the old normal logic is applicable and so we should have a clear view when the new logic is applicable and when not) and it would then except on the old cases,
Not using try: ... except: ... for regular control flow seems like good programming fundamentals to me. It would seem odd if TVM as a compiler stack would not strive to follow best practice here.

Neither am I entirely sure whether 1. is contentious or not and to me it would seem that a PR is an odd place to form an opinion on 2. At the same time I see the construct as problematic enough to have a really hard time liking the current state of the PR. It would bring great joy if you could be convinced to move it to if.
I should emphasize that I'm entirely for having the new functions appreciate your @kevinthesun work on this. Thank you!

@zhiics @kevinthesun @masahi
Thank you, @kevinthesun for your summary and all the work in the investigation and your PR.
I think using if isinstance(..., _expr.Expr): would be very much preferable to using exceptions.

I see the uses of try: ... except: ... as using exceptions for regular control flow (because the error case is the one where the old normal logic is applicable and so we should have a clear view when the new logic is applicable and when not) and it would then except on the old cases,
Not using try: ... except: ... for regular control flow seems like good programming fundamentals to me. It would seem odd if TVM as a compiler stack would not strive to follow best practice here.

Neither am I entirely sure whether 1. is contentious or not and to me it would seem that a PR is an odd place to form an opinion on 2. At the same time I see the construct as problematic enough to have a really hard time liking the current state of the PR. It would bring great joy if you could be convinced to move it to if.
I should emphasize that I'm entirely for having the new functions appreciate your @kevinthesun work on this. Thank you!

@t-vi Thanks for your thoughts. To handle dynamic op correctly, we have to use if isinstance(..., _expr.Expr) together with try ... except. Do we have an agreement that in the dynamic ops involved in this PR, try ... except is necessary? Currently there is no other way rather than try _infer_value to get constant attribute. Unfortunately this is not about good programming fundamentals but about functionality. You can see the similar methodology in TensorFlow frontend. We need to do these because tf/pt od models are in the most complicated models which TVM has ever tried to compiled. As @masahi mentioned, we can gradually move these complicated dynamic inference logics to backend while dyn namespace is improved. However, currently these are something necessary to support OD models.

@masahi It looks like certain recent change causes this error. I'm investigating.

I don't actually get why we need try: ... except: ... what case does it not handle that is handled properly by the except part?

Original pt frontend just handles limited cases, mostly static shape/attributes. It is fine we just keep input as it is. For more dynamic models, we need to do some extra work to reduce the dynamism during type inference. For example, there is a chance to reduce output shape of (?, ?, ?) to (1, ?, ?) in a dynamic op. This is necessary otherwise it's hard to ensure we are doing the right thing for backend. That error pointed out by @masahi is exactly the case. The input shape of get_valid_counts should be (1, ?, 5) while somehow recent change makes it (1, ?, ?). get_valid_counts doesn't allow dynamic box data length. This is an example why we need to make the output relay Expr as static as possible and _infer_shape is necessary.

I think I'm slowly starting to understand. But couldn't one have something like e_new = _try_to_make_static(e) that takes an expression, makes it as static as possible and returns the result - which might be e if it cannot be static. Ideally, this would work without going through exceptions, but if we cannot have this, one could implement this with try: ... except: ... . The thing I'm uncomfortable with is having so many places where we do try: ... exept:. (sounds like @masahi suggested this above)

As I have discussed with @masahi, the problem of having a try interface is that there is no common logic between different dynamic ops when dealing with dynamic attributes. We need to take different actions in try/except block depending on the actual op.

@kevinthesun this mighe be related to the error https://github.com/apache/incubator-tvm/pull/6316

But which part raises the exception? infer_value_ or the casting that follows?

@masahi I rolled back topk to still _infer_value. Directly use dyn topk will cause a certain shape dim to be dynamic and cause get_valid_count issue. Compiling pt maskrcnn takes <3 mins, I agree with you that we might just need to test maskrcnn. fastercnn test removed.

But which part raises the exception? infer_value_ or the casting that follows?

It's for _infer_value.

but wouldn't then a pattern of
inferred_val = _try_infer_value(inp)
if inferred_val is not None:
   res = foo(inferred_val)
else:
   res = bar(inp)

work?

@t-vi For now IMO it doesn't bring obvious benefit of adding an extra common api to just wrap try ... except for _infer_value, considering the lack of generalization among different dynamic op handlings. Alsowe shouldn't just limit to pytorch frontend for this topic since in tf frontend we have a lot of such patterns. Probably you can also check tf frontend to see what kind of general logic we can have for such pattern and discuss with community about the potential improvement. After that we can have a more complete solution for this. Sounds like a plan?

@kevinthesun Although having a wrapper api doesn't make the code shorter, I do believe there is a value in isolating such "toxic" programming idiom into one place (e.g. it makes updating easier).
That said, I agree that we can proceed with this code as it is, given that this idiom is (unfortunately) already common in other frontends and such low level detail is not the point of this PR. I can give a try at this issue later, since I want to keep PyTorch frontend clean.

@masahi Yeah. It probably worth a forum discussion thread before we proceed with any solution. In tf frontend, there are even more try .. except blocks which doesn't involve _infer_value(thanks to the complexity of tf frontend :D) I think it would be helpful to discuss overall what kind of style is recommended(or necessary) in tvm frontend. After that, a major refactor can happen for at least tf and pt frontends.

@kevinthesun The maskrcnn test worked for me, great!
But unfortunately under torch 1.6, conversion fails with the following error. Most likely they come from pytorch function that are scripted https://github.com/pytorch/vision/blob/1a04d3c265679e1a508e7cd627006aaa9ef1ccfb/torchvision/models/detection/roi_heads.py#L454. Most of them don't make sense for tracing (like raising an exception).
We need to come back to this problem later when we upgrade our CI.
NotImplementedError: The following operators are not implemented:[
'aten::append',
'aten::tensor',
'aten::dim',
'aten::warn',
'aten::__is__',
'aten::__isnot__',
'prim::RaiseException',
'prim::unchecked_cast',
'aten::IntImplicit',
'aten::empty',
'aten::numel',
'prim::Uninitialized',
'aten::__contains__'
]

@masahi Yeah. Those ops look like coming from scripted model. I believe for pt 1.6 if we tracing the model there are 2 or 3 ops missing.

@masahi Yeah. Those ops look like coming from scripted model. I believe for pt 1.6 if we trace the model there are 2 or 3 ops missing.

To be clear, that list op is coming from tracing mask rcnn model, since mask rcnn is partly scripted, even if we torch.jit.trace on it, we still get partly scripted TorchScript IR. See the link to torchvision code I added above.
For faster rcnn, which is not partly scripted and thus can be traced completely, I get following missing ops with PyTorch 1.6
NotImplementedError: The following operators are not implemented: ['aten::tensor', 'aten::empty', 'aten::numel']

Thanks @kevinthesun for the great work!!
Thanks everyone for review.

https://github.com/pytorch/vision/blob/1a04d3c265679e1a508e7cd627006aaa9ef1ccfb/torchvision/models/detection/roi_heads.py#L454

hi,  are these op  ok now?

@kevinthesun The maskrcnn test worked for me, great!
But unfortunately under torch 1.6, conversion fails with the following error. Most likely they come from pytorch function that are scripted https://github.com/pytorch/vision/blob/1a04d3c265679e1a508e7cd627006aaa9ef1ccfb/torchvision/models/detection/roi_heads.py#L454. Most of them don't make sense for tracing (like raising an exception).
We need to come back to this problem later when we upgrade our CI.
NotImplementedError: The following operators are not implemented:[
'aten::append',
'aten::tensor',
'aten::dim',
'aten::warn',
'aten::__is__',
'aten::__isnot__',
'prim::RaiseException',
'prim::unchecked_cast',
'aten::IntImplicit',
'aten::empty',
'aten::numel',
'prim::Uninitialized',
'aten::__contains__'
]
```hi. are these op ok ? now


Term matrix feedback, text change

https://github.com/geneontology/amigo/issues/327
Current information:
Enter a list of GO terms to see the co-annotations--the count of shared bioentities to pair-wise terms. Keep in mind that the more you enter the longer the initial startup will be.
If you wish to limit yourself to certain species, etc., use the filters on the left.
Suggest:
Enter a list of GO ID's to see the co-annotations--the count of shared gene products annotated to pairs of terms. Use the taxon filter to limit species.
eg. See numbers of gene products co-annotated to slim cellular process terms:
use this list (GO:0006457 GO:0071852 GO:0006629 GO:0006399 GO:0006259 GO:0000003 GO:0044281 GO:0051276 GO:0000278 GO:0002181 GO:0006810 GO:0007010 GO:0016071
GO:0007005 GO:0006351 GO:0042254 GO:0023052 GO:0006464 GO:0006091
GO:0044262)

+1 to the proposed documentation update
Also, I think this is another case where the full set of facet filters is overkill. Not sure I see a use case for any of the filters other than species.

Agreed,  I was thinking aspect could be useful, but essentially terms are dictated by ID list so no other facet is required. This  change would also probably make
https://github.com/geneontology/amigo/issues/336 a non issue

Closed in #327.


Windows can only POST/GET

Worth mentioning that, on Windows, cURL can only execute POST and GET, the current workaround is:
Adding the following request header
Key: X-HTTP-Method-Override Value: Target method (PUT, PATCH, DELETE)
Remembering that I made a Mega Async REST Wrap, it do uses luajit-request, but only on Windows, as I would need to include another binary for Linux, and it is currently supporting:
Android, Windows, Linux and Web(Love.js), everything with little to no adaptation, (only a .js file when using on Web)
REST-Love

I don't know if anything changed but a bit over a year ago I used luajit-request in a game of mine that also used PUT, DELETE and PATCH and all of those definitely worked, just by passing {method = "PUT"} for args (second argument to send). I am now using Linux, so I can't try it out easily.
Could you make a minimal example that shows the faulty behaviour? (You could send a request to https://httpbin.org/anything and print it, which will also return the method used for the request)

I've just tested right now again and noticed that there was a typo where I passed methd instead of method, and I believe that as it received the data parameter correctly it just transformed into a POST method and by appending those headers I could make it work, sorry for the mismatch


Long mp3 file with peaks

I'm using wavesurfer with this options:
{
      container: document.querySelector("div.wave-container"),
      scrollParent: true,
      fillParent: false,
      hideScrollbar: false,
      cursorWidth: 2,
      waveColor     : '#cccccc',
      progressColor : '#0189BE',
      loaderColor   : 'purple',
      cursorColor   : '#ff0000',
      backend: "MediaElement",
      mediaType: "audio"
}

Then I try to load a long mp3 file (around an hour) and I specify the peaks arra (consequently It's a huge array of about 18000 positions). Then the wavesurfer canvas renders to the needed width with scroll but the wave didn't get printed in the canvas. I debugged the problem and the method drawWave seems to work as expected (makes the lines correctly as far as I can tell).
As a test I tried to load the same array of peaks but with an mp3 file of about 3 minutes and this way the wave does get printed.
Any idea of what could be the problem?

Looks like the same as #47, i.e. canvas size limit.
Try to decrease the number of square pixels on the canvas by setting a lower minPxPerSecond and smaller height.

I tried it and it didn't work. This is weird because I'm updating a webpage that already uses wavesurfer with peaks arrays of this size and works fine, but the version of the wavesurfer used is 9 month old.

Also with a huge waveform it would be necessary to set pixelRatio to 1 so that it doesn't blow Retina up.


Add presence, documentation and tests

This PR introduces presence channels functionality and initial docs&tests attempt
For presence, there are two new client-side methods: presence/0 and presence/1

Ebert has finished reviewing this Pull Request and has found:

9 possible new issues (including those that may have been commented here).
3 fixed issues! 🎉

You can see more details about this review at https://ebertapp.io/github/stepnivlk/pushex/pulls/4.

Ebert has finished reviewing this Pull Request and has found:

2 possible new issues (including those that may have been commented here).
3 fixed issues! 🎉

You can see more details about this review at https://ebertapp.io/github/stepnivlk/pushex/pulls/4.


Could not find any version that matches com.android.support:appcompat-v7:22.0.+.

When I add GreenMatter to my gradle dependencies in Android Studio as described in the wiki, I am getting an error:
Error:A problem occurred configuring project ':app'.

Could not resolve all dependencies for configuration ':app:_debugCompile'.
Could not find any version that matches com.android.support:appcompat-v7:22.0.+.
Searched in the following locations:
https://jcenter.bintray.com/com/android/support/appcompat-v7/maven-metadata.xml
https://jcenter.bintray.com/com/android/support/appcompat-v7/
http://download.crashlytics.com/maven/com/android/support/appcompat-v7/maven-metadata.xml
http://download.crashlytics.com/maven/com/android/support/appcompat-v7/
file:/Users/michi/AndroidStudioProjects/KingBarf copy 2/app/libs/
file:/Users/michi/Downloads/adt-bundle-mac-x86_64-20140702/sdk/extras/android/m2repository/com/android/support/appcompat-v7/maven-metadata.xml
file:/Users/michi/Downloads/adt-bundle-mac-x86_64-20140702/sdk/extras/google/m2repository/com/android/support/appcompat-v7/maven-metadata.xml
file:/Users/michi/Downloads/adt-bundle-mac-x86_64-20140702/sdk/extras/google/m2repository/com/android/support/appcompat-v7/
Required by:
KingBarf copy 2:app:unspecified > com.negusoft.greenmatter:GreenMatter:0.5-alpha
Could not find any version that matches com.android.support:support-v4:22.0.+.
Searched in the following locations:
https://jcenter.bintray.com/com/android/support/support-v4/maven-metadata.xml
https://jcenter.bintray.com/com/android/support/support-v4/
http://download.crashlytics.com/maven/com/android/support/support-v4/maven-metadata.xml
http://download.crashlytics.com/maven/com/android/support/support-v4/
file:/Users/michi/AndroidStudioProjects/KingBarf copy 2/app/libs/
file:/Users/michi/Downloads/adt-bundle-mac-x86_64-20140702/sdk/extras/android/m2repository/com/android/support/support-v4/maven-metadata.xml
file:/Users/michi/Downloads/adt-bundle-mac-x86_64-20140702/sdk/extras/google/m2repository/com/android/support/support-v4/maven-metadata.xml
file:/Users/michi/Downloads/adt-bundle-mac-x86_64-20140702/sdk/extras/google/m2repository/com/android/support/support-v4/
Required by:
KingBarf copy 2:app:unspecified > com.negusoft.greenmatter:GreenMatter:0.5-alpha

Seems a higher version of appcompat is required then available.
Please advice. Thanks.

Sorry, just noticed that v22.0.0 is out already. Will download and test if it works then

Updating SDK Manager to v22.0.0 fixed it


Change source code documentation to English?

Hello great team,
Is there are any plan to change the source code comments and documentation to English as this will make life easier for all, I can help on this if needed.

I doubt so, since the developer is asian (Chinese I think it was?) and will likely prefer to document in his foreign language. Understandable, imho.

@devypt
Yes, we need your help.
If you can help us we will be very grateful !
: )

@devypt I'm in, too


Updating swebench before move && Removing lambda filter for GAIA

This PR contains:

[ X] New features
[ ] Changes to dev-tools e.g. CI config / github tooling
[ ] Docs
[ ] Bug fixes
[ ] Code refactor

What is the current behavior? (You can also link to an open issue here)
This updates SWE-bench in preparation for moving it to inspect_evals. It's a simplification of the image building code, a removal of the unserializable lambda function we use in filter for both swe-bench and GAIA, and also not saving compose files in some hard set path (instead we use platformdirs).
What is the new behavior?
Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
Other information:

Looks like it just needs a run over w/ ruff....


#001 Creating Youtube rendering functionality

[x] Create a logger
[x] create a custom exception.
[x] Youtube file to deal with this module
[x] manual check in jupyter notebook

closing issue

bug resolved clossing the issue


Internal Server Error, TemplateSyntaxError: non-default argument follows default argument

This is with f016820, latest commit on master as of right now (continuation of #345, same environment as that report).
For the "Overview" initial page, I get the top menu, but the content of the page is an "Internal Server Error" message, with the following logged :
[2017-02-01 09:48:39,613] ERROR in app: Exception on / [GET]
Traceback (most recent call last):
File "/home/puppetboard/.local/lib/python2.7/site-packages/flask/app.py", line 1982, in wsgi_app
response = self.full_dispatch_request()
File "/home/puppetboard/.local/lib/python2.7/site-packages/flask/app.py", line 1614, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/home/puppetboard/.local/lib/python2.7/site-packages/flask/app.py", line 1517, in handle_user_exception
reraise(exc_type, exc_value, tb)
File "/home/puppetboard/.local/lib/python2.7/site-packages/flask/app.py", line 1612, in full_dispatch_request
rv = self.dispatch_request()
File "/home/puppetboard/.local/lib/python2.7/site-packages/flask/app.py", line 1598, in dispatch_request
return self.view_functions[rule.endpoint](**req.view_args)
File "/home/puppetboard/.local/lib/python2.7/site-packages/puppetboard/app.py", line 256, in index
current_env=env
File "/home/puppetboard/.local/lib/python2.7/site-packages/flask/templating.py", line 134, in render_template
context, ctx.app)
File "/home/puppetboard/.local/lib/python2.7/site-packages/flask/templating.py", line 116, in _render
rv = template.render(context)
File "/home/puppetboard/.local/lib/python2.7/site-packages/jinja2/environment.py", line 1008, in render
return self.environment.handle_exception(exc_info, True)
File "/home/puppetboard/.local/lib/python2.7/site-packages/jinja2/environment.py", line 780, in handle_exception
reraise(exc_type, exc_value, tb)
File "/home/puppetboard/.local/lib/python2.7/site-packages/puppetboard/templates/_macros.html", line 93, in template
{% macro datatable_init(table_html_id, ajax_url, default_length, length_selector, extra_options=None, columns) -%}
TemplateSyntaxError: non-default argument follows default argument
[pid: 19447|app: 0|req: 16/16] 2001:920:5846:9:e6f5:d26b:8012:2664 () {46 vars in 1064 bytes} [Wed Feb  1 09:48:39 2017] GET / => generated 3311 bytes in 251 msecs (HTTP/1.1 500) 2 headers in 100 bytes (1 switches on core 0)

For the "Nodes" tab, I get a blank page, with a different error logged, but about the same macro file+line :
Traceback (most recent call last):
File "/home/puppetboard/.local/lib/python2.7/site-packages/werkzeug/wsgi.py", line 703, in __next__
return self._next()
File "/home/puppetboard/.local/lib/python2.7/site-packages/werkzeug/wrappers.py", line 81, in _iter_encoded
for item in iterable:
File "/home/puppetboard/.local/lib/python2.7/site-packages/flask/helpers.py", line 130, in generator
for item in gen:
File "/home/puppetboard/.local/lib/python2.7/site-packages/jinja2/environment.py", line 1271, in __next__
return self._next()
File "/home/puppetboard/.local/lib/python2.7/site-packages/jinja2/environment.py", line 1248, in _buffered_generator
c = next(self._gen)
File "/home/puppetboard/.local/lib/python2.7/site-packages/jinja2/environment.py", line 1045, in generate
yield self.environment.handle_exception(exc_info, True)
File "/home/puppetboard/.local/lib/python2.7/site-packages/jinja2/environment.py", line 780, in handle_exception
reraise(exc_type, exc_value, tb)
File "/home/puppetboard/.local/lib/python2.7/site-packages/puppetboard/templates/_macros.html", line 93, in template
{% macro datatable_init(table_html_id, ajax_url, default_length, length_selector, extra_options=None, columns) -%}
jinja2.exceptions.TemplateSyntaxError: non-default argument follows default argument
[pid: 19447|app: 0|req: 17/17] 2001:920:5846:9:e6f5:d26b:8012:2664 () {46 vars in 1074 bytes} [Wed Feb  1 09:49:54 2017] GET /nodes => generated 0 bytes in 150 msecs (HTTP/1.1 200) 1 headers in 59 bytes (0 switches on core 0)

Really strange behavior. My jinja2 version is much more conciliant (2.7.2).
There is already a fix in #341

OK, thanks! Indeed, see http://jinja.pocoo.org/docs/dev/changelog/#version-2-8 with :
"Added a check for default arguments followed by non-default arguments. This change makes {% macro m(x, y=1, z) %}...{% endmacro %} a syntax error. The previous behavior for this code was broken anyway (resulting in the default value being applied to y)"

This has been fixed with the changes pushed from #341.


How do I build time is calculated?

I'd has between build start time and end time during build implement
how do I build time?

You can get the duration of a build via:
 JobWithDetails job = JenkinsServer.getJob("XXX");
 BuildWithDetails details = getLastBuild().details();
 System.out.println ("Duration: " + details.getDuration());

I got it.
but, I get the build time during building start and end.

Maybe I misunderstand you but the duration if the is the time between build start time and build end time ? or to be more accurate:
endTime - startTime

?


As an IBM Client Educator, I want to upload gated content, so that I can share commercial learning material with Clients

Background
IBM Quantum has a number of teams who are creating commercial learning material for clients. This learning material is not open sourced and must be only be accessible to Clients
Goal
Client Educators should be able to upload custom, private learning material and create a syllabi only accessible to Client learners
Acceptance Criteria:

[ ] IBM Client Educators should be able to upload custom learning material, in Jupyter Notebooks format
[ ] All IBM Client Educator content should be inaccessible by default
[ ] Only IBM Client Educators should be able to add this content to syllabi

This repository is no longer maintained. It has been superseded by IBM Quantum Learning.


v1.27.2 security issue for yaml package

Hi, I've been using this library for my project; however, I have encountered a high-severity security issue due to using this library. The identifiers that scanned these issues are:

Gemnasium-1f7a31ba-b314-4a03-8e00-9fb092c9ee61
CVE-2022-3064
GHSA-6q6q-88xp-6f2r

The warning message is: "yaml package for Go can consume excessive amounts of CPU or memory." The description is: "Parsing malicious or large YAML documents can consume excessive amounts of CPU or memory."
By any chance, can we update the library to use a higher version of the yaml package, such as version 2.2.4 or above?
Thanks in advance.

This package doesn't depends on any yaml package. I'm not sure why you receive this warning. The only dependency of this package is xstrings. The package go-assert is only used for testing code.

@huandu  Sure, but the version of go-assert used in this library requires the yaml package (you can check it in the go.sum file). I know this is not a big issue, but by any chance, is it okay if we update the Go version instead? This update also fixes the issue, and I have already tried it in my local branch—it works without any conflicts or issues.

OK. After a few investigation, I understand your concern now. I'll update the go.sum. Thanks for your explanation.

I fix this issue in tag v1.27.3.


python3Packages.dask-expr: fix source hash

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.
cc @GaetanLepage

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 352332

x86_64-linux

:white_check_mark: 12 packages built:

python311Packages.dask-expr
python311Packages.dask-expr.dist
python311Packages.dask-ml
python311Packages.dask-ml.dist
python311Packages.streamz
python311Packages.streamz.dist
python312Packages.dask-expr
python312Packages.dask-expr.dist
python312Packages.dask-ml
python312Packages.dask-ml.dist
python312Packages.streamz
python312Packages.streamz.dist

aarch64-linux

:white_check_mark: 12 packages built:

python311Packages.dask-expr
python311Packages.dask-expr.dist
python311Packages.dask-ml
python311Packages.dask-ml.dist
python311Packages.streamz
python311Packages.streamz.dist
python312Packages.dask-expr
python312Packages.dask-expr.dist
python312Packages.dask-ml
python312Packages.dask-ml.dist
python312Packages.streamz
python312Packages.streamz.dist

x86_64-darwin

:x: 10 packages failed to build:

python311Packages.dask-expr
python311Packages.dask-expr.dist
python311Packages.dask-ml
python311Packages.dask-ml.dist
python311Packages.streamz
python311Packages.streamz.dist
python312Packages.dask-ml
python312Packages.dask-ml.dist
python312Packages.streamz
python312Packages.streamz.dist

:white_check_mark: 2 packages built:

python312Packages.dask-expr
python312Packages.dask-expr.dist

aarch64-darwin

:x: 10 packages failed to build:

python311Packages.dask-expr
python311Packages.dask-expr.dist
python311Packages.dask-ml
python311Packages.dask-ml.dist
python311Packages.streamz
python311Packages.streamz.dist
python312Packages.dask-ml
python312Packages.dask-ml.dist
python312Packages.streamz
python312Packages.streamz.dist

:white_check_mark: 2 packages built:

python312Packages.dask-expr
python312Packages.dask-expr.dist

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 352332

x86_64-linux

:white_check_mark: 12 packages built:

python311Packages.dask-expr
python311Packages.dask-expr.dist
python311Packages.dask-ml
python311Packages.dask-ml.dist
python311Packages.streamz
python311Packages.streamz.dist
python312Packages.dask-expr
python312Packages.dask-expr.dist
python312Packages.dask-ml
python312Packages.dask-ml.dist
python312Packages.streamz
python312Packages.streamz.dist

aarch64-linux

:white_check_mark: 12 packages built:

python311Packages.dask-expr
python311Packages.dask-expr.dist
python311Packages.dask-ml
python311Packages.dask-ml.dist
python311Packages.streamz
python311Packages.streamz.dist
python312Packages.dask-expr
python312Packages.dask-expr.dist
python312Packages.dask-ml
python312Packages.dask-ml.dist
python312Packages.streamz
python312Packages.streamz.dist

x86_64-darwin

:x: 6 packages failed to build:

python311Packages.dask-ml
python311Packages.dask-ml.dist
python311Packages.streamz
python311Packages.streamz.dist
python312Packages.streamz
python312Packages.streamz.dist

:white_check_mark: 6 packages built:

python311Packages.dask-expr
python311Packages.dask-expr.dist
python312Packages.dask-expr
python312Packages.dask-expr.dist
python312Packages.dask-ml
python312Packages.dask-ml.dist

aarch64-darwin

:x: 6 packages failed to build:

python311Packages.dask-ml
python311Packages.dask-ml.dist
python311Packages.streamz
python311Packages.streamz.dist
python312Packages.streamz
python312Packages.streamz.dist

:white_check_mark: 6 packages built:

python311Packages.dask-expr
python311Packages.dask-expr.dist
python312Packages.dask-expr
python312Packages.dask-expr.dist
python312Packages.dask-ml
python312Packages.dask-ml.dist


Update Connections Overview.workbook

PR Checklist

[ ] Explain your changes, so people looking at the PR know what and why, the code changes are the how.

If adding or updating templates:

[ ] post a screenshot of templates and/or gallery changes
[ ] ensure your template has a corresponding gallery entry in the gallery folder
[ ] If you are adding a new template, add your team and template/gallery file(s) to the CODEOWNERS file. CODEOWNERS entries should be teams, not individuals
[ ] ensure all steps have meaningful names
[ ] ensure all parameters and grid columns have display names set so they can be localized
[ ] ensure that parameters id values are unique or they will fail PR validation (parameter ids are used for localization)
[ ] ensure that steps names are unique or they will fail PR validation (step names are used for localization)
[ ] grep /subscription/ and ensure that your parameters don't have any hardcoded resourceIds or they will fail PR validation
[ ] remove fallbackResourceIds and fromTemplateId fields from your template workbook or they will fail PR validation

it work now

@Chakraodba this PR is open, and almost a year old but not merged.  If still applicable needs to be updated and reopened and merged.  (if not, ideally the unmerged branch would also be deleted)


如何调用我们开发的编译器？

我们想集成我们开发的汇编编译器到opensumi，如何调用？我们的编译器已经编译成Windows平台的exe文件，已经可以通过命令行调用执行： C:\compiler.exe  C:\projectsFolder

都可以用插件的方式集成

可以用 task 的方式，OpenSumi 的插件兼容 VSCode  https://code.visualstudio.com/Docs/editor/tasks
使用 Terminal 的方式 https://code.visualstudio.com/api/references/vscode-api createTerminal 接口

我们不想用插件的方式，那会展示在插件列表里面，我们已经实现了在vscode上以插件的形式完成项目代码的编译，我们希望直接集成到opensumi

我们开发了我们自己的MCU，正在寻找IDE框架集成我们的编译器，我们希望完整的定制编译器的功能。正在尝试在opensumi上做相关探索，发现资料和案例很少，定制起来很困难。以下是第一阶段的需求：
IDE Stage 1 OKR
Objective: Successfully develop a customized desktop IDE software based on opensumi（Electron）, and promote it to the market.
Key Result 1: Integrate the assembler compiler and successfully integrate it

Integrate the assembler compiler into our IDE project and test its functionality and stability.
Output the compilation result to the output panel
Output compilation error information to the problem panel

Key Result 2: Assemble project compilation by clicking icons or command panels

Design and develop a user interface(build button) to launch the assembler compiler.
Develop corresponding code to implement project compilation on the UI.
Provide "Build" on the command palette to launch compilation.

Key Result 3: Implement error locating function

Locat Error line based on problems panel information output by the assembler.
Develop UI-related code, so that users can double-click on the error line and automatically jump to the error code line.
Automatically activate the code locating function to locate the error to the correct position in the code, saving users time and effort.
Test and prove the effectiveness and accuracy of the error-locating function.

Key Result 4: Package the IDE tool project into an exe installation file and provide it to customers for use

Set up the process of packaging and publishing the IDE, ensuring the security and reliability of the publishing process.
Publish the installation files according to the specified manner and schedule.
Provide reliable installation documents and support to help customers use the IDE smoothly.

Key Result 5: UI interface conforms to the company's brand identification, including logo, about, etc.

Confirm and understand the company's brand identification principles, such as color range, font, icons, etc.
Revise the UI design according to the company's brand identification principles, including logo, buttons, panels, etc.
Create an "about us" page and modify or update terms and policies based on the company's latest information.

by the way, 基于opensumi定制IDE，需要开发人员具备哪些技能？

@justin2gh 我们提供了一些拓展案例，可以看这里 https://github.com/opensumi/opensumi-module-samples#samples ，看你这里的基础逻辑，其实只需要把执行构建的逻辑封装为一个 Node 层方法即可，可以参考 [Connection Sample](https://github.com/opensumi/opensumi-modue-samples/tree/main/modules/connection) 这个案例。

基于opensumi定制IDE，需要开发人员具备哪些技能？

NodeJS/Typescript/React 开发能力，辅助性的如：VS Code 插件开发经验，依赖注入知识

@erha19 非常感谢，后续开发过程中又问题在来提问。

@erha19 非常感谢，后续开发过程中有问题再来提问。


latttice－1best is not aligned

Hi Yajie
Hope you well
I am very interested to obtain the correctly aligned phone sequence to word. But currently Eesen's lattice-1best.cc can only generate approximate alignment of word and its phone sequence.
for example, the following output from lattice-1best:
0
0   1   21 3.79004,4.6815,1_1_1_1_1_1_1_2_2_2_2_2_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_9_1_1_1_1_1_1_1_1_39_1
1   2   62  0.0800781,0.134042,1_3_1_1_1_1_1_1_1_1_26_1_1_1_1_1_1_1_34_1_1
2   3   57  1.21191,8.98855,1_8_1_1_1_1_1_1_1_1_1_1_10_1_1_3_1_1_1_1_1_1_1_1_1_1_1_34_1_1_1_1_1_8_1_1_1_24_24_24_1_1
3   4   33  0.113281,0.192038,1_5_1_1_1_1_1_1_1_1_1_38_1_1_1_1_1_1_1_1
4   5   60  2.41016,8.13873,1_4_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_10_1_1_32_1_1_1_1_1_1_1_1_8_1_1_1_1_24_24_1_1_37_1_1_1_1_1_1_1_1_1_1_34_1_1_1_1_1_1_1_1_1_1_1_1_31_31_1_1_1_1_1_37_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_10_1_1_1_21_1_1_1_1_1_1_1_1_1_1_1_31_1_1_1_1_1_1_1_1_1_1_1_14_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_12_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1
5   3.00586,0,2
...............
the phone sequences are not exactly aligned to the word ( represent by int).
I am very new to Kaldi and asr. from what I know, there is a kaldi function : lattice-word-align.cc can be used if we want an exact word-to-phoneseq alignment, but that function requires a final.mdl, which ctc doesn't have.
Could you please give me some hints to how to generate exact word-to-phoneseq alginment?
Best

may be this one is a better example:
0
0   1   17  5.14551,2.63603,1_1_1_1_2_2_2_2_2_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_18_1_1_1_14_1_1_1_1_1_1_1_1_34_34_34_1_1_1_1_1_1
1   2   30  3.3584,0.0412467,1_1_25_1_21_1_1_1_1
2   3   57  1.39062,17.1739,1_1_1_1_1_1_1_1_1_1_1_1_1_1_1
3   4   33  0.113281,7.08899,
4   5   60  2.41016,6.8943,26_1_1_1_1_1_1_1_1_1_1_1_1_1_1_9_1_1_1_1_1_1_1_1_1_1_1_1_1_1_34_1_1_1_1_1_1_1_1_1_1_1_1_10_1_1_3_1_1_1_1_1_1_1_1_1_1_1_1_1_23_1_1_32_32_1_1_1_1_1_1_8_1_1_1_1_1_1_41_1_1_5_1_1_1_1_38_1_1_1_1_4_1_1_1_1_1_1_1_1_1_25_1_1_1_1_1_1_1_1_1_32_1_1_1_1_1_1_1_1_34_1_1_1_1_8_1_1_1_1_1_1_1_1_24_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1_1
5   3.00586,0,2_2

You are right, lattice-word-align.cc from Kaldi is not applicable to Eesen. Also, developing such a lattice-word-align utility for Eesen is not straightforward, as the CTC states contain no word boundary information.
@naxingyu probably has more information regarding this?

Hi Yajie
Thank you very much for the quick answer.
can I ask a further question:
given the example above, I can see that although word number 2 and 3 do not have correct phone sequence aligned, but actually they are appeared in the word number 4. I checked a few other un-aligned cases, they all have such phenomenon. Can I assume that the total phone sequence does contain all the word phone sequences, therefor I can use a beamsearch like skill to obtain the correct word-to-phone-alignment?
Thank you very much.
Best

@yajiemiao I think this is quite normal in Eesen. As you said, there is no word boundry information in CTC states. We tried using position dependent blanks to store word boundary information, but it seems harmful to the performance. @xfwu 's assumption that total phone sequence contrains the word sequence should be correct. But I don't thinks you can obtain the word-to-phone-alignment using beam search.

Hi xingyu & yajie
Thank you very much for your reply.
Can I ask another naive question:
I found there are three main steps in latgen-faster.cc
1> decode
2>getbestpath
3>getrawlattice
Could you please explain the relation between these three functions? Especially what's the effect of applying the second step （getbestpath ）?
Thank you very much
Best

Decode() makes sure that you have a valid lattice to GetBestPath() and
GetRawLattice(). In the latgen faster decoder, GetBestPath() and
GetRawLattice() are not funtionally related. You can just remove the
calling of GetRawLattice() if you don't want the state-level lattice, or
remove the GetBestPath() otherwise.
X.
在 2016/6/29 20:59, Xiaofeng Wu 写道:

Hi xingyu & yajie
Thank you very much for your reply.
Can I ask another naive question:
I found there are three main steps in latgen-faster.cc
1> decode
2>getbestpath
3>getrawlattice
Could you please explain the relation between these three functions?
Especially what's the effect of applying the second step （getbestpath ）?
Thank you very much
Best
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/srvk/eesen/issues/63#issuecomment-229348143, or
mute the thread
https://github.com/notifications/unsubscribe/ADKpxABHQksDLcbZejaYy1UhoT7lad0bks5qQmxCgaJpZM4I5B6U.

Thank you very much. Sorry that I am still not fully understand.
Can I assume that GetBestPath() has the same performance as GetRawLattice() + Lattice-1best.cc ?
Best

I would say it is GetRawLattice() + lattice-best-path. But Yajie knows
it better.
X.
在 2016/6/30 9:51, Xiaofeng Wu 写道:

Thank you very much. Sorry that I am still not fully understand.
Can I assume that GetBestPath() has the same performance as
GetRawLattice() + Lattice-1best.cc ?
Best
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/srvk/eesen/issues/63#issuecomment-229538862, or
mute the thread
https://github.com/notifications/unsubscribe/ADKpxP8CSfln7tCPhcyW7qXY6CmQmx5Dks5qQyEGgaJpZM4I5B6U.

@xfwu Yes, your understanding is right, GetBestPath() is simply for generating debugging information, so that you can see some recognition outputs even if you are generating lattices
Applying lattice-best-path to lattices is equivalent to applying GetBestPath() directly, or applying decode-faster

Hi Yajie & Xingyu
What I am currently trying is to decode on a class-based method. I need to run a second decoding to find out the correct phone sequence for the class holder. But given the current lattice-1best output, (or the ShortestPath) it is a little bit tricky.
Because 1) I don't know the exact start point of each word
2) there are phone repeat themselves consecutively. Some represents only one phone, but some represent 2 phones (like the t t in phrases like 'want to' )
Actually to do a DFS search upon the first decode result seemed a not very good idea, afterall, I don't want to run into multiple results.
Apologies for my rookie questions, I still don't understand why CTC can't generate a phone-to-word alignment. Since TLG has been combined, doesn't each word should be output at the beginning of its phone sequence?
Thanks a million
Xiaofeng

It's difficult to get (correct) word boundaries because getting phone boundaries is difficult with the existing Eesen framework. In traditional GMM/DNN, if you've got a frame-level state sequence "a_4 a_4 a_5 a_5 a_5 b_1 b_1 b_1", you can immediately tell where the two phones are separated. However, for CTC, you might just get "a a # # # # # # b b b" (# is blank), and have no idea where to separate a and b, as all the blanks in between are not distinguishable. This is why the timing information is potentially wrong, although you do get alignments/timing information for each word.

thank you very much！


Master => develop

Merge latest release back into develop

This change is

Builds ready [545c7bc]builds: chrome, firefox, opera
bundle viz: background, ui, inpage, contentscript, ui-libs, bg-libs, phishing-detect
dep viz: background
all artifacts


Fix "incompatible pointer types" with clang

incompatible pointer types passing 'ssize_t *' (aka 'long *') to parameter of type 'int *'

Thanks!


Clear names for exports

How to categorize this issue?

/area usability
/kind enhancement
/priority 3
What would you like to be added:
For import data it is possible to reference them by their real name and not a hash using the notation "#name". The same should be possible for export data.
Why is this needed:

#-notation has been switched off in the meantime also for imports, so this does not make much sense anymore.
@Diaphteiros : Please add the respective PR.

@In-Ko closed because outdated and/or copied into internal project


A draft proof-of-concept for converging cloudapi and weldr api

The basic idea here is to start by adding blueprint support to cloudapi, the discussion for this can be found here.
This is a really rough poc, but it does actually work, you can submit compose requests to a local socket and it will use the "blueprint" to create it. I only implemented the customizations schema that were the same as a starting point.
Some things to answer:

Should blueprint and cloudapi customizations be exclusive and return an error if both are present?
If not, how to handle merging them. eg. handling duplicate entries like both trying to setup the same user.
Should the cloudapi schema be changed to match the blueprint customization schema?

Schema notes:
Things the same:

Kernel
SSHKey
Timezone
Locale
Services
FDO
Ignition
Directory

Almost the same (name difference):

group vs. groups
repositories vs. custom_repositories

Field differences:

Users
Firewall
Filesystem
OpenSCAP
Files

NOTE: This has no new tests, and CI will most certainly fail. But you can build it with make scratch and submit a sample compose request.
curl -k --unix-socket /run/cloudapi/api.socket --header 'Content-Type: application/json' --data @request-bcl.json  http://localhost/api/image-builder-composer/v2/compose | jq

request-bcl.json:
{
  "blueprint":
{
  "name": "bcl",
  "description": "testing cloudapi",
  "version": "1.0.14",
  "distro": "fedora-39",
  "customizations": {
    "hostname": "minecraft.lan",
    "sshkey": [
      {
        "user": "root",
        "key": "ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAoxHT9SxuP8HpESuWZ3jiBK1o3igUVbfskc17/Nq62Iy9mSbPGbPneJI2Z1vtDP6Yo8QFnMXO8HW/f/sOQt9tgQyF0x9Js+fYlNatNsGIGVcWEAncrimYPsciTitPoUzclK7IRIwHQ0cf2MhVyGB+FAZ+28SOcn9p5FAuPEMHgaSVDGXGoT773OofPze0pj+61oXckzNT531QQLfSCmzNITFzZ31cFC+n+uT5mlIZ6VS253BQ0pj1ULFGrP6h1lMTaOffdFmCMwu+lnOSDJoeT/OXloqWF0lqedyVngWICxzG4lEeoXixM4FxWUus9m0vYVG1v+VP8KxpDYKvmEZ3bQ==<EMAIL_ADDRESS>      }
    ],
    "timezone": {
      "timezone": "PST8PDT",
      "ntpservers": [
        "time.brianlane.com"
      ]
    }
  },
  "packages": [
    {
      "name": "tmux",
      "version": "*"
    },
    {
      "name": "vim-enhanced"
    }
  ]
},
  "customizations": {
    "filesystem": [{
      "mountpoint": "/opt",
      "min_size": 10485760
    }]
  },
  "distribution": "fedora-39",
  "image_requests": [
    {
      "architecture": "x86_64",
      "image_type": "guest-image",
      "upload_options": {
        "local_save": true
      },
      "repositories":
[
  {
    "name": "fedora",
    "metalink": "https://mirrors.fedoraproject.org/metalink?repo=fedora-39&arch=x86_64",
    "gpgkey": "-----BEGIN PGP PUBLIC KEY BLOCK-----\n\nmQINBGLykg8BEADURjKtgQpQNoluifXia+U3FuqGCTQ1w7iTqx1UvNhLX6tb9Qjy\nl/vjl1iXxucrd2JBnrT/21BdtaABhu2hPy7bpcGEkG8MDinAMZBzcyzHcS/JiGHZ\nd/YmMWQUgbDlApbxFSGWiXMgT0Js5QdcywHI5oiCmV0lkZ+khZ4PkVWmk6uZgYWf\nJOG5wp5TDPnoYXlA4CLb6hu2691aDm9b99XYqEjhbeIzS9bFQrdrQzRMKyzLr8NW\ns8Pq2tgyzu8txlWdBXJyAMKldTPstqtygLL9UUdo7CIQQzWqeDbAnv+WdOmiI/hR\netbbwNV+thkLJz0WD90C2L3JEeUJX5Qa4oPvfNLDeCKmJFEFUTCEdm0AYoQDjLJQ\n3d3q9M09thXO/jYM0cSnJDclssLNsNWfjJAerLadLwNnYRuralw7f74QSLYdJAJU\nSFShBlctWKnlhQ7ehockqtgXtWckkqPZZjGiMXwHde9b9Yyi+VqtUQWxSWny+9g9\n6tcoa3AdnmpqSTHQxYajD0EGXJ0z0NXfqxkI0lo8UxzypEBy4sARZ4XhTU73Zwk0\nLGhEUHlfyxXgRs6RRvM2UIoo+gou2M9rn/RWkhuHJNSfgrM0BmIBCjhjwGiS33Qh\nysLDWJMdch8lsu1fTmLEFQrOB93oieOJQ0Ysi5gQY8TOT+oZvVi9pSMJuwARAQAB\ntDFGZWRvcmEgKDM5KSA8ZmVkb3JhLTM5LXByaW1hcnlAZmVkb3JhcHJvamVjdC5v\ncmc+iQJOBBMBCAA4FiEE6PI5lvIyGGQMtEy+dc9axBi450wFAmLykg8CGw8FCwkI\nBwIGFQoJCAsCBBYCAwECHgECF4AACgkQdc9axBi450yd4w//ZtghbZX5KFstOdBS\nrcbBfCK9zmRvzeejzGl6lPKfqwx7OOHYxFlRa9MYLl8QG7Aq6yRRWzzEHiSb0wJw\nWXz5tbkAmV/fpS4wnb3FDArD44u317UAnaU+UlhgK1g62lwI2dGpvTSvohMBMeBY\nB5aBd+sLi3UtiSRM2XhxvxaWwr/oFLjKDukgrPQzeV3F/XdxGhSz/GZUVFVprcrB\nh/dIo4k0Za7YVRhlVM0coOIcKbcjxAK9CCZ8+jtdIh3/BN5zJ0RFMgqSsrWYWeft\nBI3KWLbyMfRwEtp7xSi17WXbRfsSoqwIVgP+RCSaAdVuiYs/GCRsT3ydYcDvutuJ\nYZoE53yczemM/1HZZFI04zI7KBsKm9NFH0o4K2nBWuowBm59iFvWHFpX6em54cq4\n45NwY01FkSQUqntfqCWFSowwFHAZM4gblOikq2B5zHoIntCiJlPGuaJiVSw9ZpEc\n+IEQfmXJjKGSkMbU9tmNfLR9skVQJizMTtoUQ12DWC+14anxnnR2hxnhUDAabV6y\nJ5dGeb/ArmxQj3IMrajdNwjuk9GMeMSSS2EMY8ryOuYwRbFhBOLhGAnmM5OOSUxv\nA4ipWraXDW0bK/wXI7yHMkc6WYrdV3SIXEqJBTp7npimv3JC+exWEbTLcgvV70FP\nX55M9nDtzUSayJuEcfFP2c9KQCE=\n=J4qZ\n-----END PGP PUBLIC KEY BLOCK-----",
    "check_gpg": true
  },
  {
    "name": "updates",
    "metalink": "https://mirrors.fedoraproject.org/metalink?repo=updates-released-f39&arch=x86_64",
    "metadata_expire": "6h",
    "gpgkey": "-----BEGIN PGP PUBLIC KEY BLOCK-----\n\nmQINBGLykg8BEADURjKtgQpQNoluifXia+U3FuqGCTQ1w7iTqx1UvNhLX6tb9Qjy\nl/vjl1iXxucrd2JBnrT/21BdtaABhu2hPy7bpcGEkG8MDinAMZBzcyzHcS/JiGHZ\nd/YmMWQUgbDlApbxFSGWiXMgT0Js5QdcywHI5oiCmV0lkZ+khZ4PkVWmk6uZgYWf\nJOG5wp5TDPnoYXlA4CLb6hu2691aDm9b99XYqEjhbeIzS9bFQrdrQzRMKyzLr8NW\ns8Pq2tgyzu8txlWdBXJyAMKldTPstqtygLL9UUdo7CIQQzWqeDbAnv+WdOmiI/hR\netbbwNV+thkLJz0WD90C2L3JEeUJX5Qa4oPvfNLDeCKmJFEFUTCEdm0AYoQDjLJQ\n3d3q9M09thXO/jYM0cSnJDclssLNsNWfjJAerLadLwNnYRuralw7f74QSLYdJAJU\nSFShBlctWKnlhQ7ehockqtgXtWckkqPZZjGiMXwHde9b9Yyi+VqtUQWxSWny+9g9\n6tcoa3AdnmpqSTHQxYajD0EGXJ0z0NXfqxkI0lo8UxzypEBy4sARZ4XhTU73Zwk0\nLGhEUHlfyxXgRs6RRvM2UIoo+gou2M9rn/RWkhuHJNSfgrM0BmIBCjhjwGiS33Qh\nysLDWJMdch8lsu1fTmLEFQrOB93oieOJQ0Ysi5gQY8TOT+oZvVi9pSMJuwARAQAB\ntDFGZWRvcmEgKDM5KSA8ZmVkb3JhLTM5LXByaW1hcnlAZmVkb3JhcHJvamVjdC5v\ncmc+iQJOBBMBCAA4FiEE6PI5lvIyGGQMtEy+dc9axBi450wFAmLykg8CGw8FCwkI\nBwIGFQoJCAsCBBYCAwECHgECF4AACgkQdc9axBi450yd4w//ZtghbZX5KFstOdBS\nrcbBfCK9zmRvzeejzGl6lPKfqwx7OOHYxFlRa9MYLl8QG7Aq6yRRWzzEHiSb0wJw\nWXz5tbkAmV/fpS4wnb3FDArD44u317UAnaU+UlhgK1g62lwI2dGpvTSvohMBMeBY\nB5aBd+sLi3UtiSRM2XhxvxaWwr/oFLjKDukgrPQzeV3F/XdxGhSz/GZUVFVprcrB\nh/dIo4k0Za7YVRhlVM0coOIcKbcjxAK9CCZ8+jtdIh3/BN5zJ0RFMgqSsrWYWeft\nBI3KWLbyMfRwEtp7xSi17WXbRfsSoqwIVgP+RCSaAdVuiYs/GCRsT3ydYcDvutuJ\nYZoE53yczemM/1HZZFI04zI7KBsKm9NFH0o4K2nBWuowBm59iFvWHFpX6em54cq4\n45NwY01FkSQUqntfqCWFSowwFHAZM4gblOikq2B5zHoIntCiJlPGuaJiVSw9ZpEc\n+IEQfmXJjKGSkMbU9tmNfLR9skVQJizMTtoUQ12DWC+14anxnnR2hxnhUDAabV6y\nJ5dGeb/ArmxQj3IMrajdNwjuk9GMeMSSS2EMY8ryOuYwRbFhBOLhGAnmM5OOSUxv\nA4ipWraXDW0bK/wXI7yHMkc6WYrdV3SIXEqJBTp7npimv3JC+exWEbTLcgvV70FP\nX55M9nDtzUSayJuEcfFP2c9KQCE=\n=J4qZ\n-----END PGP PUBLIC KEY BLOCK-----",
    "check_gpg": true
  },
  {
    "name": "fedora-modular",
    "metalink": "https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64",
    "gpgkey": "-----BEGIN PGP PUBLIC KEY BLOCK-----\n\nmQINBGLykg8BEADURjKtgQpQNoluifXia+U3FuqGCTQ1w7iTqx1UvNhLX6tb9Qjy\nl/vjl1iXxucrd2JBnrT/21BdtaABhu2hPy7bpcGEkG8MDinAMZBzcyzHcS/JiGHZ\nd/YmMWQUgbDlApbxFSGWiXMgT0Js5QdcywHI5oiCmV0lkZ+khZ4PkVWmk6uZgYWf\nJOG5wp5TDPnoYXlA4CLb6hu2691aDm9b99XYqEjhbeIzS9bFQrdrQzRMKyzLr8NW\ns8Pq2tgyzu8txlWdBXJyAMKldTPstqtygLL9UUdo7CIQQzWqeDbAnv+WdOmiI/hR\netbbwNV+thkLJz0WD90C2L3JEeUJX5Qa4oPvfNLDeCKmJFEFUTCEdm0AYoQDjLJQ\n3d3q9M09thXO/jYM0cSnJDclssLNsNWfjJAerLadLwNnYRuralw7f74QSLYdJAJU\nSFShBlctWKnlhQ7ehockqtgXtWckkqPZZjGiMXwHde9b9Yyi+VqtUQWxSWny+9g9\n6tcoa3AdnmpqSTHQxYajD0EGXJ0z0NXfqxkI0lo8UxzypEBy4sARZ4XhTU73Zwk0\nLGhEUHlfyxXgRs6RRvM2UIoo+gou2M9rn/RWkhuHJNSfgrM0BmIBCjhjwGiS33Qh\nysLDWJMdch8lsu1fTmLEFQrOB93oieOJQ0Ysi5gQY8TOT+oZvVi9pSMJuwARAQAB\ntDFGZWRvcmEgKDM5KSA8ZmVkb3JhLTM5LXByaW1hcnlAZmVkb3JhcHJvamVjdC5v\ncmc+iQJOBBMBCAA4FiEE6PI5lvIyGGQMtEy+dc9axBi450wFAmLykg8CGw8FCwkI\nBwIGFQoJCAsCBBYCAwECHgECF4AACgkQdc9axBi450yd4w//ZtghbZX5KFstOdBS\nrcbBfCK9zmRvzeejzGl6lPKfqwx7OOHYxFlRa9MYLl8QG7Aq6yRRWzzEHiSb0wJw\nWXz5tbkAmV/fpS4wnb3FDArD44u317UAnaU+UlhgK1g62lwI2dGpvTSvohMBMeBY\nB5aBd+sLi3UtiSRM2XhxvxaWwr/oFLjKDukgrPQzeV3F/XdxGhSz/GZUVFVprcrB\nh/dIo4k0Za7YVRhlVM0coOIcKbcjxAK9CCZ8+jtdIh3/BN5zJ0RFMgqSsrWYWeft\nBI3KWLbyMfRwEtp7xSi17WXbRfsSoqwIVgP+RCSaAdVuiYs/GCRsT3ydYcDvutuJ\nYZoE53yczemM/1HZZFI04zI7KBsKm9NFH0o4K2nBWuowBm59iFvWHFpX6em54cq4\n45NwY01FkSQUqntfqCWFSowwFHAZM4gblOikq2B5zHoIntCiJlPGuaJiVSw9ZpEc\n+IEQfmXJjKGSkMbU9tmNfLR9skVQJizMTtoUQ12DWC+14anxnnR2hxnhUDAabV6y\nJ5dGeb/ArmxQj3IMrajdNwjuk9GMeMSSS2EMY8ryOuYwRbFhBOLhGAnmM5OOSUxv\nA4ipWraXDW0bK/wXI7yHMkc6WYrdV3SIXEqJBTp7npimv3JC+exWEbTLcgvV70FP\nX55M9nDtzUSayJuEcfFP2c9KQCE=\n=J4qZ\n-----END PGP PUBLIC KEY BLOCK-----",
    "check_gpg": true
  },
  {
    "name": "updates-modular",
    "metalink": "https://mirrors.fedoraproject.org/metalink?repo=updates-released-modular-f39&arch=x86_64",
    "metadata_expire": "6h",
    "gpgkey": "-----BEGIN PGP PUBLIC KEY BLOCK-----\n\nmQINBGLykg8BEADURjKtgQpQNoluifXia+U3FuqGCTQ1w7iTqx1UvNhLX6tb9Qjy\nl/vjl1iXxucrd2JBnrT/21BdtaABhu2hPy7bpcGEkG8MDinAMZBzcyzHcS/JiGHZ\nd/YmMWQUgbDlApbxFSGWiXMgT0Js5QdcywHI5oiCmV0lkZ+khZ4PkVWmk6uZgYWf\nJOG5wp5TDPnoYXlA4CLb6hu2691aDm9b99XYqEjhbeIzS9bFQrdrQzRMKyzLr8NW\ns8Pq2tgyzu8txlWdBXJyAMKldTPstqtygLL9UUdo7CIQQzWqeDbAnv+WdOmiI/hR\netbbwNV+thkLJz0WD90C2L3JEeUJX5Qa4oPvfNLDeCKmJFEFUTCEdm0AYoQDjLJQ\n3d3q9M09thXO/jYM0cSnJDclssLNsNWfjJAerLadLwNnYRuralw7f74QSLYdJAJU\nSFShBlctWKnlhQ7ehockqtgXtWckkqPZZjGiMXwHde9b9Yyi+VqtUQWxSWny+9g9\n6tcoa3AdnmpqSTHQxYajD0EGXJ0z0NXfqxkI0lo8UxzypEBy4sARZ4XhTU73Zwk0\nLGhEUHlfyxXgRs6RRvM2UIoo+gou2M9rn/RWkhuHJNSfgrM0BmIBCjhjwGiS33Qh\nysLDWJMdch8lsu1fTmLEFQrOB93oieOJQ0Ysi5gQY8TOT+oZvVi9pSMJuwARAQAB\ntDFGZWRvcmEgKDM5KSA8ZmVkb3JhLTM5LXByaW1hcnlAZmVkb3JhcHJvamVjdC5v\ncmc+iQJOBBMBCAA4FiEE6PI5lvIyGGQMtEy+dc9axBi450wFAmLykg8CGw8FCwkI\nBwIGFQoJCAsCBBYCAwECHgECF4AACgkQdc9axBi450yd4w//ZtghbZX5KFstOdBS\nrcbBfCK9zmRvzeejzGl6lPKfqwx7OOHYxFlRa9MYLl8QG7Aq6yRRWzzEHiSb0wJw\nWXz5tbkAmV/fpS4wnb3FDArD44u317UAnaU+UlhgK1g62lwI2dGpvTSvohMBMeBY\nB5aBd+sLi3UtiSRM2XhxvxaWwr/oFLjKDukgrPQzeV3F/XdxGhSz/GZUVFVprcrB\nh/dIo4k0Za7YVRhlVM0coOIcKbcjxAK9CCZ8+jtdIh3/BN5zJ0RFMgqSsrWYWeft\nBI3KWLbyMfRwEtp7xSi17WXbRfsSoqwIVgP+RCSaAdVuiYs/GCRsT3ydYcDvutuJ\nYZoE53yczemM/1HZZFI04zI7KBsKm9NFH0o4K2nBWuowBm59iFvWHFpX6em54cq4\n45NwY01FkSQUqntfqCWFSowwFHAZM4gblOikq2B5zHoIntCiJlPGuaJiVSw9ZpEc\n+IEQfmXJjKGSkMbU9tmNfLR9skVQJizMTtoUQ12DWC+14anxnnR2hxnhUDAabV6y\nJ5dGeb/ArmxQj3IMrajdNwjuk9GMeMSSS2EMY8ryOuYwRbFhBOLhGAnmM5OOSUxv\nA4ipWraXDW0bK/wXI7yHMkc6WYrdV3SIXEqJBTp7npimv3JC+exWEbTLcgvV70FP\nX55M9nDtzUSayJuEcfFP2c9KQCE=\n=J4qZ\n-----END PGP PUBLIC KEY BLOCK-----",
    "check_gpg": true
  }
]
    }]
}

When discussing this with @supakeen and @achilleas-k, I've also had the idea of making the conversion a separate route. The flow would be basically:
weldr-client calls POST /blueprints/convert with the weldr blueprint in the request, and gets the cloud API compose request as a response
weldr-clients create a new compose using the request it got in the previous call

I guess that a small advantage is that the main compose route doesn't get more cluttered, and we don't have to think what has a precedence (one of your comments in the current PR) - if the new blueprint structure, or the old stuff.
cc @croissanne

I've also had the idea of making the conversion a separate route.

That's certainly a possibility, but I think it makes things harder. I really don't see any reason for an extra round-trip of the data, which may also grow considerably in size if we start adding files. If you've sent the data, and it has been consumed by the service, it may as well take action and start the compose.
Another alternative is to add another compose endpoint that only takes the full blueprint, and none of the current customizations. I'd prefer that to a 'convert' stage. Especially since, as you can see, on the inside it really is using a blueprint.
But one drawback to that is it will mean more changes to image-builder. With the current layout of this poc the image-builder created customizations don't need to be changed, and a blueprint can be easily added to it as long as things don't conflict. Or we could just return an error if both exist.

I've also had the idea of making the conversion a separate route.

That's certainly a possibility, but I think it makes things harder. I really don't see any reason for an extra round-trip of the data, which may also grow considerably in size if we start adding files. If you've sent the data, and it has been consumed by the service, it may as well take action and start the compose.
Another alternative is to add another compose endpoint that only takes the full blueprint, and none of the current customizations. I'd prefer that to a 'convert' stage. Especially since, as you can see, on the inside it really is using a blueprint. But one drawback to that is it will mean more changes to image-builder. With the current layout of this poc the image-builder created customizations don't need to be changed, and a blueprint can be easily added to it as long as things don't conflict. Or we could just return an error if both exist.

We've spoken about this a bit in the discussion as well but a separate route adds more benefits as it can also be used as a separate linting/checking route and allows (some) shell scripts to get the composerequest separately, store it, and send it out later (something we do in Koji) though they could also 'just submit the blueprint' of course.
The files discussion is indeed another can of worms that's going to greatly increase round-trip times.

Rebased to prevent OCI private key leaking. Apologies :(

I went ahead and made the customizations and blueprints sections mutually exclusive. It will return an error if you try to use both. I think that we should deprecate customizations and move to using the blueprint section for future features. I've also turned on the local listener for cloudapi under /run/cloudapi/api.socket, which doesn't require the hassle of key setup and is protected by the usual filesystem permissions in the same way that the weldr socket is (you have to be a member of the weldr group).
As I see it the goals are to converge on one API, and to maintain support for existing and future blueprints, which this accomplishes. It should be straightforward to add support for this to composer-cli, either with new commands or by detecting support for it by checking for the socket. The biggest change will likely be image-builder, but even that shouldn't be too bad -- customizations is similar enough to the blueprint that it is almost a 1:1 translation.

We could do those things, but then we'd lose strict checking of the blueprint in OpenAPI. I think it's better to keep it matching the actual blueprint schema so that we have easy validation of the json as soon as possible.

We could do those things, but then we'd lose strict checking of the blueprint in OpenAPI. I think it's better to keep it matching the actual blueprint schema so that we have easy validation of the json as soon as possible.

I'd generally agree with this but I can imagine it being frustrating for users of the API to have objects with slightly different keys but are otherwise identical.  Maybe this is fine for the API in composer since only our own projects talk to it realistically though.

I can imagine it being frustrating for users of the API to have objects with slightly different keys

True, but the goal is to eventually get rid of the others and have a single API so there should eventually be no confusion :)


Error: libzmq.so.3: cannot open shared object file: No such file or directory

Hi,everyone,
I just try the example on npm page and got this error.
Does any body had this problem?
ØMQ/4.x with node v0.10.30.
/home/xiquan/node_modules/zmq/node_modules/bindings/bindings.js:83
throw e
^
Error: libzmq.so.3: cannot open shared object file: No such file or directory
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at bindings (/home/xiquan/node_modules/zmq/node_modules/bindings/bindings.js:76:44)
at Object. (/home/xiquan/node_modules/zmq/lib/index.js:6:30)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)

I had the same issue, also on Mint.  Running ldconfig after installing zmq fixed the problem.

I had the same issue on Ubuntu, running ldconfig fixed it.

thanks kranthicu

I had the same issue, but I'm on Centos7 and node.js v4.

I found the way,effective for me, $ export LD_LIBRARY_PATH=/usr/local/lib.

Thanks @zenboss , works for me!

Same issue on Ubuntu 15.10 ... as @si-griffiths suggested ldconfig fixed it.

ldconfig and /usr/local/lib doesn't work for me, on Ubuntu 16.04.

Might need to run npm up first.

You have to install liblas-c3.
sudo aptitude install liblas-c3
on Ubuntu 16.04 you have to add a packages source:
deb http://cz.archive.ubuntu.com/ubuntu xenial main universe
to your /etc/apt/sources.list then update apt-get and you should be able to install it.

For me adding adding /usr/local/bin to  /etc/ld.so.conf and calling sudo ldconfig fixed the error.

Nothing has worked for me.
CentOS and Node 4.x LTS.
Even tried migrating to 6.x LTS to check, but nope.
In my case the libzmq.so.4 doesn't exist, had used yum to install zmq.

Ubuntu 16.04
I also meet such problem. ldconfig and Add Path didn't work for me.

I downloaded "lib64pgm5.2_0-5.2.122-3.mga6.x86_64.rpm" after a lot of searching and this library installed the require libzmq.so.4
This worked for me.

Thank you.
I downloaded the package but didn't work for me.
After I install a few packages
apt-get install libminiupnpc-dev libzmq3-dev libevent-pthreads-2.0.5
It works.


Error while installing JustinLvim config

Installing JustinLvim Neovim configurationmv: rename /tmp/lazyman78082/lunarvim/.config/lvim to /Users/dbragin/.config/nvim-JustinLvim: No such file or directory
cp: /Users/dbragin/.config/nvim-JustinLvim: Not a directory
cp: /tmp/lvim78082/snapshots: unable to copy extended attributes to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /tmp/lvim78082/snapshots: unable to copy ACL to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /Users/dbragin/.config/nvim-JustinLvim: Not a directory
cp: /tmp/lvim78082/utils: unable to copy extended attributes to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /Users/dbragin/.config/nvim-JustinLvim: Not a directory
cp: /tmp/lvim78082/utils/docker: unable to copy extended attributes to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /tmp/lvim78082/utils/docker: unable to copy ACL to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /Users/dbragin/.config/nvim-JustinLvim: Not a directory
cp: /tmp/lvim78082/utils/bin: unable to copy extended attributes to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /tmp/lvim78082/utils/bin: unable to copy ACL to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /Users/dbragin/.config/nvim-JustinLvim: Not a directory
cp: /tmp/lvim78082/utils/ci: unable to copy extended attributes to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /tmp/lvim78082/utils/ci: unable to copy ACL to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /Users/dbragin/.config/nvim-JustinLvim: Not a directory
cp: /tmp/lvim78082/utils/desktop: unable to copy extended attributes to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /Users/dbragin/.config/nvim-JustinLvim: Not a directory
cp: /tmp/lvim78082/utils/desktop/16x16: unable to copy extended attributes to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /tmp/lvim78082/utils/desktop/16x16: unable to copy ACL to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /Users/dbragin/.config/nvim-JustinLvim: Not a directory
cp: /tmp/lvim78082/utils/desktop/64x64: unable to copy extended attributes to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /tmp/lvim78082/utils/desktop/64x64: unable to copy ACL to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /Users/dbragin/.config/nvim-JustinLvim: Not a directory
cp: /tmp/lvim78082/utils/desktop/32x32: unable to copy extended attributes to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /tmp/lvim78082/utils/desktop/32x32: unable to copy ACL to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /Users/dbragin/.config/nvim-JustinLvim: Not a directory
cp: /tmp/lvim78082/utils/desktop/24x24: unable to copy extended attributes to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /tmp/lvim78082/utils/desktop/24x24: unable to copy ACL to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /Users/dbragin/.config/nvim-JustinLvim: Not a directory
cp: /tmp/lvim78082/utils/desktop/22x22: unable to copy extended attributes to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /tmp/lvim78082/utils/desktop/22x22: unable to copy ACL to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /Users/dbragin/.config/nvim-JustinLvim: Not a directory
cp: /tmp/lvim78082/utils/desktop/48x48: unable to copy extended attributes to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /tmp/lvim78082/utils/desktop/48x48: unable to copy ACL to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /tmp/lvim78082/utils/desktop: unable to copy ACL to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /Users/dbragin/.config/nvim-JustinLvim: Not a directory
cp: /tmp/lvim78082/utils/installer: unable to copy extended attributes to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /tmp/lvim78082/utils/installer: unable to copy ACL to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /tmp/lvim78082/utils: unable to copy ACL to /Users/dbragin/.config/nvim-JustinLvim: Operation not permitted
cp: /Users/dbragin/.config/nvim-JustinLvim/lua: Not a directory

Thanks for the heads up. It looks like Justin has deleted his LunarVim config. I will remove it from Lazyman.
In addition, lazyman should check if a repository or subdir in a repo it needs is no longer there and fail more gracefully.

Thanks for your answer! I think you can close this issue :)

Removed JustinLvim. Closing.


Update PlayerUtil.class.php

Into database there isn't a table named FLEETS_EVENT but FLEET_EVENT

Hello,
you are totaly wrong. you need to read the code correctly before pulling files :)
'FLEETS_EVENT'		=> DB_PREFIX.'fleet_event',

Ops. Sorry mate.
My error.

:)


feat: support CSV format in sql HTTP API

I hereby agree to the terms of the GreptimeDB CLA
What's changed and what's your intention?
This closes #577.
It's still a draft to demonstrate what we will implement. I don't fix test but you can preview the manner with:
$ cargo run -- standalone start
$ curl -i -X POST \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'sql=SELECT 1, 42&format=csv' \
http://localhost:4000/v1/sql\?db\=public
HTTP/1.1 200 OK
content-type: text/csv; charset=utf-8
content-length: 5
date: Mon, 01 Jan 2024 01:39:16 GMT

1,42
$ curl -i -X POST \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'sql=show tables&format=csv' \
http://localhost:4000/v1/sql\?db\=public
HTTP/1.1 200 OK
content-type: text/csv; charset=utf-8
content-length: 10
date: Mon, 01 Jan 2024 01:38:59 GMT

"numbers"

I'll comment some code ideas inline.
Checklist

[ ]  I have written the necessary rustdoc comments.
[x]  I have added the necessary unit tests and integration tests.
[ ]  This PR does not require documentation updates.

Refer to a related PR or issue link (optional)

cc @killme2008 @fengjiachun @MichaelScofield

@MichaelScofield PTAL

@fengjiachun thanks for your comments. I'll continue the direction described above and for all other refactor and test work.

CI passed. Please take another look @fengjiachun @MichaelScofield


[cmocka] Initial port for cmocka

This adds an initial port for cmocka.
cmocka is "an elegant unit testing framework for C with support for mock objects. It only requires the standard C library, works on a range of computing platforms (including embedded) and with different compilers."
Home: https://cmocka.org/
Git: git://git.cryptomilk.org/projects/cmocka.git
Releases: https://cmocka.org/files/
Fixes #4728

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

I'm going to close this PR because we're trying to close outstanding PRs (so that we're better able to respond to incoming PRs and those that have languished). I'm happy to take a look at this as soon as the CLA is signed -- just open another PR! 😄


Remove cursor style for Draw interactions on touch screens

Is your feature request related to a problem? Please describe.
Let's say I create a point draw interaction with a darkblue circle as style. On a desktop, this works fine, when I move my cursor, I can see the darkblue circle next to my cursor, indicating that I am about to draw a point on the map.
However, when drawing on a touch screen, every time I pan or zoom on the map, it shows the darkblue circle where I last touched the screen. I haven't drawn the point yet, it's just the hover effect that is visible on the map. This is very confusing for users, because they think they have already placed the point, when in fact they haven't.
This is currently messing with the mobile friendliness of my application 😞 . So many thanks in advance to take this into consideration!
Describe the solution you'd like
For touch screens (pointer:coarse), there should not be a style applied to the cursor when hovering, because hovering doesn't exist on touch screens.

You can do this with a custom style function:
    if ('ontouchstart' in window) {
      const originalStyleFn = draw.getOverlay().getStyle();
      let drawing = false;
      draw.getOverlay().setStyle(function (feature, resolution) {
        return drawing ? originalStyleFn(feature, resolution) : null;
      });
      draw.on('drawstart', function () {
        drawing = true;
      });
      draw.on(['drawend', 'drawabort'], function () {
        drawing = false;
      });
    }

const originalStyleFn = draw.getOverlay().getStyle();

Thanks! Something like this seems to work indeed. I feel like this should be default behavior though, but it's fine for now!


Text is printed with wrong colors

draw.io 8.4.8 installed from .deb
Ubuntu 16.04.4 LTS

Create a blank diagram
Add a rectangle, set background color to blue and text to white
Type any text in the rectangle
Print with "Print to file"

The text will be gray in the resulting PDF.

I have the same problem with Chrome on Windows 10. I think it is the browser that is changing the colors, but I haven't found a workaround yet. Anyone that can tell us how to get around this problem?

This is probably a feature, not a bug. Workaround: Tick "Background graphics" under More settings, Options in Chrome's print dialog.

I'm guessing they are trying to avoid white text on white background.

I understand why Chrome does this. I don't understand why draw.io does not prevent it from happening.

Printing is implemented in the browser, not draw.io. I'm looking at this workaround, but it doesn't seem to solve the problem.

Ah yes, that link helped. This will be fixed in the next release. Thanks again!

Great, thanks!


Speclens

I think the analysis for this project is done for now and will be finished in the spring. I was hoping to merge it now so I can provide a link to the code in my report.

You're right, there were two files that were unnecessary so I removed both. I never added a .gitignore to this directory, just modified the top-level .gitignore to ignore some larger files I had in my working directory. I also added a readme so that I can remember what each file does when I revisit (or anyone else visits) this repo.


[Github] fix: ensure sequential indexes for ConfigurationService arrays

1. Why is this change necessary?
When a plugin defines a config.xml with elements using <flag> these elements are removed if the feature flag is not enabled. This could lead to a JavaScript error when opening the Plugin configuration in the Shopware Administration.
It happens because if a configuration element is removed the resulting PHP array is non-sequentially indexed and when using json_encode this results in an Object instead of an Array. The Administration then tries to call the JavaScript Array method every on an Object which throws an Error.
2. What does this change do, exactly?
Ensure /api/_action/system-config/schema?domain=SwagExamplePlugin.config returns an Array on top-level and for $.elements. In a special scenario it could've returned an Object instead.
3. Describe each step to reproduce the issue or behaviour.

Create a plugin
Add a src/Resources/config/config.xml file with the following contents:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="https://raw.githubusercontent.com/shopware/platform/master/src/Core/System/SystemConfig/Schema/config.xsd">
    <card>
        <title>Features</title>
        <title lang="de-DE">Funktionen</title>

        <input-field type="bool">
            <name>feature1</name>
            Feature 1
            Funktion 1
            <defaultValue>false</defaultValue>
            <flag>CUSTOM_FEATURE_1</flag>
        </input-field>

        <input-field type="bool">
            <name>feature2</name>
            Feature 2
            Funktion 2
            <defaultValue>false</defaultValue>
            <flag>CUSTOM_FEATURE_2</flag>
        </input-field>

        <input-field type="bool">
            <name>feature3</name>
            Feature 3
            Funktion 3
            <defaultValue>false</defaultValue>
            <flag>CUSTOM_FEATURE_3</flag>
        </input-field>
    </card>
</config>

Add a src/Resources/config/packages/feature.yaml containing

shopware:
  feature:
    flags:
      - name: CUSTOM_FEATURE_1
        default: false
        major: false
        description: "Feature 1"

      - name: CUSTOM_FEATURE_2
        default: false
        major: false
        description: "Feature 2"

      - name: CUSTOM_FEATURE_3
        default: false
        major: false
        description: "Feature 3"

Add the following to the .env.local file:

CUSTOM_FEATURE_3=1

Install and activate the Plugin
Go to the Plugin configuration page in the Administration

If you use watch mode for the administration you will see an JavaScript error with the following message TypeError: this.config.elements.every is not a function. This happens because we got the response below:
[
  {
    "title": {
      "en-GB": "Features",
      "de-DE": "Funktionen"
    },
    "name": null,
    "elements": {
      "2": {
        "name": "SwagExamplePlugin.config.feature3",
        "type": "bool",
        "config": {
          "label": {
            "en-GB": "Feature 3",
            "de-DE": "Funktion 3"
          },
          "flag": "CUSTOM_FEATURE_3"
        }
      }
    }
  }
]

This happens because usually we have the following PHP array structure:
$elements = [
  0 => [ "name" => "SwagExamplePlugin.config.feature1"],
  1 => [ "name" => "SwagExamplePlugin.config.feature2"],
  2 => [ "name" => "SwagExamplePlugin.config.feature3"],
]

When using json_encode we will get a JSON Array. But as soon as the PHP array has non-sequential indexes, which happens by calling unset($elements[0]) and/or unset($elements[1]) because these features are disabled, we get back an Object.
The actual error then happens when trying to call the Array method .every on the Object card.elements on line 118:
https://github.com/shopware/shopware/blob/6713786e59bf04336403e65eea0137807d30f76b/src/Administration/Resources/app/administration/src/module/sw-settings/component/sw-system-config/index.js#L115-L126
4. Please link to the relevant issues (if any).
5. Checklist

[x] I have rebased my changes to remove merge conflicts
[ ] I have written tests and verified that they fail without my change
[x] I have created a changelog file with all necessary information about my changes
[ ] I have written or adjusted the documentation according to my changes
[x] This change has comments for package types, values, functions, and non-obvious lines of code
[x] I have read the contribution requirements and fulfil them.

🤖[deprecated] Generated by Copilot at 91b4945
This pull request fixes a bug that caused JSON encoding errors when using feature flags in plugin configuration. It changes the ConfigurationService class to reorder the indexes of the configuration arrays and adds a changelog entry for the fix.

🤖[deprecated] Generated by Copilot at 91b4945

Add a changelog entry for the fix (link)
Modify the getConfiguration method of the ConfigurationService class to ensure sequential indexes in the returned arrays (link)

Use the private helper method enforceSequentialIndexes to reorder the indexes of the arrays recursively (link)
Prevent JSON encoding errors when using feature flags in plugin configuration (link)

Imported from Github. Please see: https://github.com/shopware/shopware/pull/3442

[public] Automated response: This issue is linked to the internal issue https://shopware.atlassian.net/browse/NEXT-33717.
[created from NEXT-33717, comment 486026]


Vote for Distribution API

Would love to have to tie to Dependency Track and be able to block the pipeline if the analysis fails on DT

Thanks for the suggestion @Otodontidae. Integrating Dependency Track is near the top of the roadmap. I will keep you up to date with its progress.

Hey @Otodontidae
Support to send a SBOM to a downstream Dependency Track server has been added as of the 1.5.0 release.
`

step:
name: Process sBOM
script:
# the build directory is owned by root but the pipe runs as the bitbucket-user
# change the permission to allow the pipe to write to the build directory
- chmod 777 build
- pipe: docker://ccideas/sbom-utilities-pipe:1.5.0
variables:
SEND_SBOM_TO_DTRACK: 'true'
DTRACK_URL: ${DTRACK_URL}
DTRACK_PROJECT_ID: ${DTRACK_PROJECT_ID}
DTRACK_API_KEY: ${DTRACK_API_KEY}
`

This initial implementation uses the /v1/bom PUT API to send a single SBOM via a Project ID & Team API Key
If you have any feedback or issues with this implementation please let me know & open a new issue on the project. Closing this for now


Add Skaffolder Logo

From skaffolder.com
https://skaffolder.com/img/logo/sk-nero.svg
https://skaffolder.com/img/logo/sk-bianco.svg
https://skaffolder.com/img/logo/skaffolder_logo-nero.svg
https://skaffolder.com/img/logo/skaffolder_logo-bianco.svg

Added in c122ccfcfdb15d9958a85696ff2460ac3b01f8ca
Thanks


[SPARK-47318][CORE][3.4] Adds HKDF round to AuthEngine key derivation to follow standard KEX practices

What changes were proposed in this pull request?
Backport of SPARK-47318 to v3.4.0
This change adds an additional pass through a key derivation function (KDF) to the key exchange protocol in AuthEngine. Currently, it uses the shared secret from a bespoke key negotiation protocol directly. This is an encoded X coordinate on the X25519 curve. It is atypical and not recommended to use that coordinate directly as a key, but rather to pass it to an KDF.
Note, Spark now supports TLS for RPC calls. It is preferable to use that rather than the bespoke AES RPC encryption implemented by AuthEngine and TransportCipher.
Why are the changes needed?
This follows best practices of key negotiation protocols. The encoded X coordinate is not guaranteed to be uniformly distributed over the 32-byte key space. Rather, we pass it through a HKDF function to map it uniformly to a 16-byte key space.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Exiting tests under:
build/sbt "network-common/test:testOnly"
Specifically:
build/sbt "network-common/test:testOnly org.apache.spark.network.crypto.AuthEngineSuite"
build/sbt "network-common/test:testOnly org.apache.spark.network.crypto.AuthIntegrationSuite"
Was this patch authored or co-authored using generative AI tooling?
No.

Btw, if #46014 can cleanly apply to 3.4 branch as well, we dont need this PR. Also, same query as https://github.com/apache/spark/pull/46014/files#r1561562093 applies here as well

Yes, I think 46014 applies cleanly here. Happy to close this PR if we can merge that to multiple branches.

To @mridulm , I prefer to pass CI. :)

Merged to branch-3.4 for Apache Spark 3.4.3.

Thanks @dongjoon-hyun !

Thank you, @mridulm .


basic tests

@henrypinkard seems like start_headless isn't working on CI. Any ideas why?

mac tests are failing because the java location detection in pycro doesn't work with how it gets set up there.
windows because the timeout isn't actually configurable: https://github.com/micro-manager/pycro-manager/issues/386#issuecomment-1071274231

actually they are failing because the latest released pycromanager version is broken

mac tests are failing because the java location detection in pycro doesn't work with how it gets set up there.

Yeah I think probably the best solution is java being added to mac installer.
https://github.com/micro-manager/micro-manager/issues/1402
But I'm not sure how to make this robust in the mean time. Maybe just worth disabling for now on Mac

windows because the timeout isn't actually configurable: https://github.com/micro-manager/pycro-manager/issues/386#issuecomment-1071274231

Fixed https://github.com/micro-manager/pycro-manager/pull/389

actually they are failing because the latest released pycromanager version is broken

Any idea why?

also I suspec the hanging is due to some lingering subprocesses or not closing the bridge (https://github.com/micro-manager/pycro-manager/issues/390)

ahhhh oh no
pymmc+ does nto convert to snake case, but pycromanager does. so we have issues like this:
    def test_for_smoke():
        mm_app_path = Path(find_micromanager())
        start_headless(
            str(mm_app_path), str(mm_app_path / "MMConfig_demo.cfg"), timeout=5000
        )
        core = pycroCorePlus()
>       core.snapImage()
E       AttributeError: 'mmcorej_CMMCore' object has no attribute 'snapImage'

that will need to worked out.

also I suspec the hanging is due to some lingering subprocesses or not closing the bridge (micro-manager/pycro-manager#390)

Yeah that makes sense. Is it possible to just call quit() after the test in python, so that the process closes, which should auto clean up the java headless process?

pymmc+ does nto convert to snake case, but pycromanager does. so we have issues like this:

you can do Bridge(convert_camel_case=False) or Core(convert_camel_case=False)

I think this check is not correct:
        if not os.path.isfile(java_loc):
>           raise Exception(java_loc + ' does not exist')

because that checks relative to the python working directory, not whereever java is actually installed.

Do you know what the correct call is?

Do you know what the correct call is?

I would just remove that check. Calling java in the subprocess should find the right thing. You can check the return value of the subprocess to check if it failed.

Yeah that makes sense. Is it possible to just call quit() after the test in python, so that the process closes, which should auto clean up the java headless process?

I don't think so. Because quit only makes sense in the context of an interactive repl. Better would be to have a mechnism in pycromanager to kill the subprocess and then do something like this pytest fixture: https://til.simonwillison.net/pytest/subprocess-server

you can do Bridge(convert_camel_case=False) or Core(convert_camel_case=False)

That's great, but I'm suspicious that it will fail becuase start_headless doesn't pass core args all the way through and then this code:
https://github.com/micro-manager/pycro-manager/blob/f8d62a935d8cb156306f994fdd7df556be6f62f5/pycromanager/bridge.py#L227-L235 will (I think) grab the core/bridge instance that start_headless created

merging for local development

I messed around with it some more, and have come to the conclusions that it is...confusing.
If you switch around the module resolution order, __init__ gets called as expected.
But the pycromanager Core object is quite weird, because its not statically declared, and is created by a factory method:
https://github.com/micro-manager/pycro-manager/blob/d9f34fe10a761863ae2443c43c251d8d2c23b95a/pycromanager/java_classes.py#L59
So there's additional weird stuff like the pycromanager Core object not having having the __init__ you might expect, and instead you would need to call:
# pycroCore().__init__(convert_camel_case=False)
bridge = zmqBridge(convert_camel_case=False)
bridge._construct_java_object("mmcorej.CMMCore")

Unless you have other ideas, I'm pretty stumped with this, and I think it would be easier to pursue creating something more explicit. I also still haven't quite wrapped by head around why we're making pycroCore and mmcorepyplus at the same level. Shouldn't mmcorepyplus sit above either pycrocore or mmcorepy, so that it can dispatch its wrapper methods to each one?
lmk what you think we should try next.


Invalid geometry on double click

If I activate draw mode with selfIntersection set to false, then double clicking on the map over the last added vertex creates a new point which produces a self-intersecting shape. After that, you cannot finish your geometry, because it is not valid.
See this fiddle for an example: https://jsfiddle.net/ny7jbv5t/9/
Start drawing a polygon and at one point double click on your last vertex. Then try to finish your edit, which should fail.

@ka7eh double click will create two vertexes on top of each other. What would you expect on double click to happen?

When selfIntersection is set to false, it should not create the second vertex, because it's an invalid geometry.

true, I will check this

@tim-salabim good thought. Afaik those identical vertices need to be at the first and last index of the coords array while in this scenario, they're the last and second to last 🤔  It's so weird.

@codeofsumit why you not check if latlng from the last (first-click) vertex is equal to the second-click vertex?
In Draw.Line._createVertex():
if(!this.options.allowSelfIntersection
    && latlng.equals(this._layer.getLatLngs()[this._layer.getLatLngs().length-1])){
      return;
}

Fixed in Release:  2.7.0


Add null handling for all arguments

Make sure to error for each required argument if null

checking for numeric types does the trick

Actually need to add for pointer function checking X


apt repo does not exist for 3.10.0

Since you dropped support for many boards from 4.0.0 on, it would be very nice if you added the apt repo for 3.10.0 that is missing:
https://repo.radeon.com/rocm/apt/3.10.0

Thanks @staticdev for reaching out.
Request you to use https://repo.radeon.com/rocm/apt/3.10/ for 3.10 space.
Thank you.


Cadence HiFi 5 NN Library:

Integrated the relu and relu6 optimized kernels.
BUG=integrate HiFi 5 optimized kernels

@advaitjain

Closing old PR. Let's reopen if needed.


Unable to initialize worker storage directory does not lead to Alluxio quiting

Alluxio Version:
2.5.0-3
Describe the bug
I have a multi-tiered storage defined as:
# Set alluxio.worker.ramdisk.size in config
alluxio.worker.tieredstore.levels=2
alluxio.worker.tieredstore.level0.alias=MEM
alluxio.worker.tieredstore.level0.dirs.path=/mnt/tmpfs
alluxio.worker.tieredstore.level0.dirs.mediumtype=MEM
# Set alluxio.worker.tieredstore.level0.dirs.quota in config
alluxio.worker.tieredstore.level1.alias=HDD
alluxio.worker.tieredstore.level1.dirs.path=/mnt/hdd-cache
alluxio.worker.tieredstore.level1.dirs.mediumtype=HDD

However, it seems like my tmpfs was setup incorrectly (by me, not Alluxio). Due to this incorrect setup Alluxio was not able to initialize the level 0 storage. In worker logs this popped up:
2021-06-24 05:30:57,382 ERROR DefaultStorageTier - Unable to initialize storage directory at /mnt/tmpfs/alluxioworker: Failed to create folder /mnt/tmpfs/alluxioworker

However, this was already happing in our system for a while, and we did not notice because Alluxio still continued to work.
Expected behavior
I would have expected Alluxio to error when setting up, instead of just printing an error to the log.
Or alternatively, it would be nice to have some kind of "robust" option that we can set in the Alluxio config, that makes sure that Alluxio fails to start when any errors are found.
Urgency
Minor

I took a look at the code, looks like all the "failed to initialize storage" will be added to "mLostStorage" but we didn't stop the worker process from coming up.
The following command can help diagnose the issue earlier
./bin/alluxio fsadmin doctor storage

For more information, please take a look at https://docs.alluxio.io/os/user/stable/en/operation/Admin-CLI.html#doctor
I do feel that it's worth to not start the AlluxioWorker when failed to initialize, what's your thoughts @ggezer

I didn't know about docker, I'll look into that to ensure my setup is correct in the meantime. Thanks!

For elasticity, I'd prefer workers to start in the face of individual disk failures.
However, we might be more verbose and loud about such failures via logging/webUI warning etc.


added list item count

added list item count.
As with space vs tabs even after explicitly using the option to "Convert Indentation to spaces" in sublime text3 it still some how using tabs it don't know why?
And when I tried to create new pull request for second "bugfix" commit it automatically merges it with this one please help

Make sure you have this option enabled when opening the files