add schema fn

Current Behavior

Currently the CDDL schema for various API types is in ockam_core independent of whether the API type is actually part of ockam_core or any other crate.
Proposed Changes

Allow schema.cddl files to be placed in other crates and merge them when CBOR API validation is needed.
Addresses issue: #3575
Checks

[ ] All commits in this Pull Request are signed and Verified by Github.
[ ] All commits in this Pull Request follow the Ockam commit message convention.
[ ] I accept the Ockam Community Code of Conduct.
[ ] I have accepted the Ockam Contributor License Agreement by adding my Git/Github details in a row at the end of the CONTRIBUTORS.csv file in a separate pull request to the build-trust/ockam-contributors repository.

TODO:

[ ] Implement validate_cbor
[ ] Include serde_cbor::value::Value to be used in validate_cbor instead of &[u8] for validate_cbor_bytes

Hi @twittner
I tried to implement everything more or less as suggested in #3575
A couple of questions:

There are a lot of unwrap() calls at the moment. I am not really familiar with ockam error handling. Where should I propagate these possible errors to?

pub fn schema() -> BasicContext {
    let cddl = parse_cddl(SCHEMA).unwrap();
    let cddl = flatten(&cddl).unwrap();
    BasicContext::new(cddl)
}

Same with:
 for (k, v) in cddl {
        match ctx.rules.entry(k) {
            Entry::Vacant(e) => {
                e.insert(v);
            }
            Entry::Occupied(_e) => {
                todo!()
                // return Err(MyValidationError::Duplicate(e.key().to_string()))
            }
        }
    }
    Ok(ctx)
}

Where should MyValidationError be placed at?

Regarding the cfg tag flag. That is just used for cddl related stuff right? I removed if for now, because it was causing some issues, but I can add it again later. For example the assert_request_match doesn't do anything when the flag is disabled right?

Hi @twittner or anyone else.
Any comment or request for this? Would love to continue with it.

Hi @twittner or anyone else.
Any comment or request for this? Would love to continue with it.

Hey @phillyphil91, I'll be reviewing it shortly, thanks for keeping your interest in this issue!

thanks for the review @adrianbenavides . I will take a look at your comments and try to implement them

Hi @adrianbenavides
I did some rather big changes. Hopefully it's not over-engineered or too complicated for the use case.
I didn't like the idea of defining a fn schema() in multiple files so I only added one in ockam_core::api.
The fn schema() takes a valid cddl schema &str and converts that into a BasicContext.
The fn merged_cddl() takes a reference to a slice of valid cddl schema &strs and basically calls fn schema() on every &str and afterwards merges the X number of cddl schemas and returns the final context or an appropriate error (hopefully).
This means any other crate just needs to import the fn merged_cddl() and provide it with all valid cddl schema &strs it wants to merge. That means for example in ockam_node::api we need to remember to bring in the ockam_core::api::SCHEMA as well. I could of course have that already baked into fn merged_cddl() if we know that it will always be used no matter which other crate adds a cddl schema, but maybe that's not always the case that the core cddl schema is needed.
I provided two tests in core::api to check if fn merged_cddl() works as well as if it returned the appropriate error.
One thing I noticed is that the docs for the Error Kind::AlreadyExists was not correct and just the description from NotFound. I tried to fix that.
TODO imo:

[ ] reactivate #[cfg(feature = "tag")]
[ ] handle remaining unwrap() calls, e.g. in assert_request_match

I did some rather big changes. Hopefully it's not over-engineered or too complicated for the use case.
I didn't like the idea of defining a fn schema() in multiple files so I only added one in ockam_core::api.
The fn schema() takes a valid cddl schema &str and converts that into a BasicContext.
The fn merged_cddl() takes a reference to a slice of valid cddl schema &strs and basically calls fn schema() on every &str and afterwards merges the X number of cddl schemas and returns the final context or an appropriate error (hopefully).

It's looking great, I think the implementation you propose is easy to use and flexible enough for our current use cases.

This means any other crate just needs to import the fn merged_cddl() and provide it with all valid cddl schema &strs it wants to merge. That means for example in ockam_node::api we need to remember to bring in the ockam_core::api::SCHEMA as well. I could of course have that already baked into fn merged_cddl() if we know that it will always be used no matter which other crate adds a cddl schema, but maybe that's not always the case that the core cddl schema is needed.

About this, the ockam_core schema should just contain the first 52 lines (request/response/error/message). The rest is only used at ockam_api. If you do this change, then it would make sense to always load the ockam_core schema.

hey @adrianbenavides
i think almost everything should be covered now. Still not really sure what to do about the #[cfg(feature = "tag")] flag. should this be added to basically everything I created now? Maybe you can give some advice on what to do with that. If there is anything else that needs to be changed still, let me know.

hey @adrianbenavides i think almost everything should be covered now. Still not really sure what to do about the #[cfg(feature = "tag")] flag. should this be added to basically everything I created now?

What I wrote here is still pretty much valid. Note that in the schema.cddl files the tag field is always present, so:

if the tag feature is enabled, then the tag field must be checked
but if it's disabled, the tag field must be skipped

I think the easiest way to approach this is to write some unit tests checking that the validation methods work as expected with and without tag fields (i.e. the assert_request_match and assert_response_match methods).

Also I wasn't sure if the tracing::error! usage that I have now included, makes sense.

They make sense to me. Not sure though if any of those branches should bubble up the error instead of just logging it. Again, I think that writing some tests will clarify this.

I replaced the calls to fn assert_response_match in ockam_api/src/authenticator/direct.rs.
I was wondering it it makes sense to call fn merged_cddl in fn assert_request_match and fn assert_response_match instead of passing it from the outside, because it's really just used in those functions and it would remove the calls to it in the functions that call fn assert_request_match.
Regarding #[cfg(feature = "tag")] I reinstated the flag in both fn assert_request_match and fn assert_response_match.
It should do everything that it did before now.
The question that I still have is that the "type tag" field which is enable by "tag" was not checked before was it? Basically if "tag" was not enabled then fn assert_request_match did nothing (some for the reponse fn).
Maybe I am misunderstanding that it was there before or is something new that needs to be implemented.
As the "type tag" field is marked as optional in the cddl file wouldn't it work without the "tag" flag at all? If the field is there, it will be checked and if not then the rest of the request/response will be checked regardlessly. Maybe I am not correctly understanding cddl notation yet.
Or rather I am wondering if there should be two versions of fn assert_request_match. One that checks the request against the cddl if the tag field is there and one if it's not. but then again... it's optional right now anyways.
Sorry for the confusion around this.

I was wondering it it makes sense to call fn merged_cddl in fn assert_request_match and fn assert_response_match instead of passing it from the outside, because it's really just used in those functions and it would remove the calls to it in the functions that call fn assert_request_match.

Definitely, this could be improved. The core idea behind this PR is to have crate-specific cddl files that can be merged with a base cddl. What would make sense to me then, is to have a statically initialized BasicContext per crate, that is, call the merged_cddl function only once per crate. This can be done with once_cell (here's an example). If you try this, you will have to change the signature of the function so it receives a &BasicContext, and it should be ok since we only need to read it.

The question that I still have is that the "type tag" field which is enable by "tag" was not checked before was it?

It wasn't checking the "tag" field because we didn't implement it. But we want to have that functionality. We can keep that out of the scope and tackle it on a separate PR if that makes more sense, and focus on the cddl files only.

hi @adrianbenavides
the once_cell approach wasn't immediately clear too me. Basically it creates a static heap allocated value that only gets initialized once and every subsequent call to the function returns a Result now that wraps the static reference to the BasicContext and doesn't create a new one?
Regardless of my possibly flawed understanding I think the code is now doing what you suggested. Feel free to review.
Regarding the tag field, i would agree to leave this out of the scope for the PR. Maybe in a subsequent one I can take another look at it.
Thanks

Basically it creates a static heap allocated value that only gets initialized once and every subsequent call to the function returns a Result now that wraps the static reference to the BasicContext and doesn't create a new one?

Exactly that 👍

@phillyphil91 I just wanted to jump in here and say, thank you for continuing to invest time on this pull request.

@phillyphil91 I've rebased develop onto this branch and fixed the merge conflicts.
Before we can merge it, I'd ask you to squash all commits into a single one with a comment that makes the CI happy (you can check the expected format here). Something like refactor(rust): ... would do.
After that, the PR will be ready!

@adrianbenavides I try to embed everything that I did i.e. everything that uses cddl-cat into the tag feature.
I want to avoid having to specicfy the cfg flag many times so I grouped code into mod where possible and applied #[cfg(feature = "tag")] to the entire mod.
I'm not sure if there is an easier way to do this, afaik outside of a function there is not easy way to apply a cfg flag to multiple lines besides the mod approach.
All crates that use cddl-cat now have that crate behind the tag feature in the respective Cargo.toml files. Also when a crate other than core enables the feature, it should also enable it for core.
Since beforehand assert_response_match and assert_request_match didn't really do much or have a body either with the tag feature disabled, I moved the entire function behind the feature, because otherwise I would have problems if only cddl() is behind it. Now the functions are just used when the tag feature is enabled otherwise the code skips them.
I'm not super familiar with the INs and OUTs of Cargo.tomal and conditional compilation yet. So hopefully this approach makes some sense. Let me know if there is something that needs to be changed.

I want to avoid having to specicfy the cfg flag many times so I grouped code into mod where possible and applied #[cfg(feature = "tag")] to the entire mod.
I'm not sure if there is an easier way to do this, afaik outside of a function there is not easy way to apply a cfg flag to multiple lines besides the mod approach.

That's perfect. FYI there is a crate to work around this limitation called cfg-if. Feel free to use it if you you think it can simplify some parts of the code, but it's perfectly fine as it is right now.

All crates that use cddl-cat now have that crate behind the tag feature in the respective Cargo.toml files. Also when a crate other than core enables the feature, it should also enable it for core.
Since beforehand assert_response_match and assert_request_match didn't really do much or have a body either with the tag feature disabled, I moved the entire function behind the feature, because otherwise I would have problems if only cddl() is behind it. Now the functions are just used when the tag feature is enabled otherwise the code skips them.
I'm not super familiar with the INs and OUTs of Cargo.tomal and conditional compilation yet. So hopefully this approach makes some sense. Let me know if there is something that needs to be changed.

The things you mentioned are the important things and I could successfully build the project with and without the tag feature on std, so well done! I'm trying to figure out why it's failing on no-std though. To test this part, you can run the following:
cargo build

# Compile all crates enabling the `tag` feature if available
cargo build --features tag

# Compile a specific crate that uses this flag
cargo build -p ockam_api --features "tag, direct-authenticator"

# Compile the no-std env to see if some `std` dependency was leaked
cargo build -p ockam --no-default-features --features="alloc, no_std, software_vault"

I'm trying to figure out why it's failing on no-std though.

There are some new dependencies that should also be optional because they are only available for std.

ockam_api: once_cell should be optional
ockam_core: serde_cbor should be optional; quickcheck should be declared in the dev-dependencies section
ockam_node: once_cell should be optional

added all your suggestions @adrianbenavides .
Compilation works now for me on std and no-std.
Let me know if there is anything missing

@phillyphil91 we are almost there :-). Can you please rebase your PR and do some renaming on your commits so that they follow the convention? You need to format a file as well. Thanks!

@phillyphil91 unfortunately the last commit is not going to pass because it is a merge commit. You really need to do a rebase.

And also we have a specific commit message convention that you need to follow: https://github.com/build-trust/.github/blob/main/CONTRIBUTING.md#commit-messages

hi @etorreborre
I'm doing the rebase right now :+1:

Thanks @phillyphil91 I think you just need to modify the commit message now so that there are no capital cases:

split CDDL schema files & merge when cbor api

If you want to keep capitals you need to enclose the words with backticks, like "`CDDL`"

@adrianbenavides just one last check with you since you followed this PR from the start. It is ok to merge now, isn't it?

Hi @adrianbenavides
thanks a lot for all your help on this one. It was a very rewarding issue.
Looking forward to the next one.
Also thanks @etorreborre


Implement StrongParamsHelper to bypass CircleCI error

Closes https://github.com/bullet-train-co/bullet_train-super_scaffolding/issues/75
Related to https://github.com/bullet-train-co/bullet_train-themes-tailwind_css/issues/2
CI=true
The local tests are passing.
However, unfortunately this is related to the CI=true issue, but by directly adding a StrongParamsHelper module and bypassing the BulletTrain::Api module I was able to get the local tests to pass.
Our local tests don't even check for strong_parameters_from_api; it's only when we use CI=true that the tests ever consider checking this portion of the code. I plan on getting more information from CircleCI about this because it's affecting different repositories, so I'll let you know if I find out more soon.
Starter Repo Minitest
If you look at the starter repo minitest here, you'll see it's still failing because include strong_parameters_from_api in the other repositories:

bullet_train-super_scaffolding
bullet_train-api

If we're okay with the bypassing I've implemented here though, then I'll open PRs over there and we can get all of our CircleCI tests passing. I think it'll be beneficial so we can at least get those green checks here on our repos.
Here's the error by the way:
NameError: undefined local variable or method `strong_parameters_from_api' for Account::Platform::AccessTokensController:Class

  include strong_parameters_from_api
          ^^^^^^^^^^^^^^^^^^^^^^^^^^

Closing in favor of #128. Again, the main problem is the entire context of the Bullet Train app isn't present in this package, so there are some classes which CI is trying to eager load which just aren't there. I don't want to have too many PRs open concerning this one, so I think I'll keep my focus on #128 and how we want to address the issue at large.


Add demo page for the new BitChoiceGroup component (#1838)

this closes #1838

@Cyrus-Sushiant plz review

@sajadkardel plz update the PR based on the new comments.
@Cyrus-Sushiant plz follow up on the results of our discussion.

@maryamhdr & @Cyrus-Sushiant
plz re-review new changes


chore: inherit vitest settings from the root

What this PR solves / how to test:
Reorganizes the vitest configuration to actually inherit config from the root of the project.
One of the motivations for this was that I noticed that the runWranglerDev helper (or similar) had a timeout of 9 secs, after which it would print the helpful error messages it had collected, but the tests themselves were timing out after only 5 secs, which meant you never get to see the errors, making it rather awkward to debug.
Rather than go and tweak all the various places that times were being set, I realised we were not using the inheritance mechanism in vitest correctly (i.e. the top level config was never used).
Author has addressed the following:

Tests

[ ] Included
[x] Not necessary because: Just an update to test configuration.

Changeset (Changeset guidelines)

[ ] Included
[x] Not necessary because: Just an update to test configuration.

Associated docs

[ ] Issue(s)/PR(s):
[x] Not necessary because: No external user facing changes.

I wonder if we should change the shared default timeout to something lower (10-20s maybe), then increase the timeouts on a per-project basis as needed. A 50s timeout for all tests seem quite long.

I thought about that when I originally created this shared file a while back. In the good case we never hit a timeout so it makes no difference to the CI runs for happy PRs. In the bad case, tests that use things like runWranglerDev will timeout themselves and then fail before this timeout. So I wasn't too worried about a bad experience here.
Also having a long default timeout is nice for debugging tests.
We could probably drop it to 30s as a compromise? Then if people are finding it a pain we could look to lower it further?

Actually I was going to change the default to 30s and then noticed that the comment says that Windows CI tests often take up to 42s. So I propose we land this and if people find the timeout annoyingly long we revisit.


Environment variables

Should define some default environment variables available to jobs, e.g.

PROMINENCE_CPUS
PROMINENCE_MEMORY
PROMINENCE_JOB_ID

An example use of PROMINENCE_CPUS would be to allow a single-node MPI job to use all the CPUs available, e.g. mpirun -np ${PROMINENCE_CPUS} ...

Done in https://github.com/prominence-eosc/prominence/commit/57942805fac60e2d09323489c0d5db711178f3da (which depends on a RADL update). Multi-node MPI jobs not done yet.


Error: torch_cluster.fps_cuda.fps(x, batch, ratio, random_start)

Pytorch: 1.1.0
pytorch_geometric: latest release
torch-cluster: 1.4.2
When I run this line,
idx = fps(pos, batch, ratio=0.5)  # 512 points
I got error.
  File /home/gupta/lib/python3.6/site-packages/torch_cluster/fps.py", line 48, in fps
    return torch_cluster.fps_cuda.fps(x, batch, ratio, random_start)
RuntimeError: expected backend CUDA and dtype Double but got backend CUDA and dtype Float (compute_types at /opt/conda/conda-bld/pytorch_1556653183467/work/aten/src/ATen/native/TensorIterator.cpp:130)
frame #0: c10::Error::Error(c10::SourceLocation, std::string const&) + 0x45 (0x7f0730e34dc5 in /home/gupta/anaconda3/envs/gupta/lib/python3.6/site-packages/torch/lib/libc10.so)
frame #1: at::TensorIterator::compute_types() + 0x965 (0x7f0731816445 in /home/gupta/anaconda3/envs/gupta/lib/python3.6/site-packages/torch/lib/libcaffe2.so)
frame #2: at::TensorIterator::Builder::build() + 0x40 (0x7f07318185e0 in /home/gupta/anaconda3/envs/gupta/lib/python3.6/site-packages/torch/lib/libcaffe2.so)
frame #3: at::TensorIterator::binary_op(at::Tensor&, at::Tensor const&, at::Tensor const&) + 0x31f (0x7f073181943f in /home/gupta/anaconda3/envs/gupta/lib/python3.6/site-packages/torch/lib/libcaffe2.so)
frame #4: at::native::mul(at::Tensor const&, at::Tensor const&) + 0x183 (0x7f07316a5ec3 in /home/gupta/anaconda3/envs/gupta/lib/python3.6/site-packages/torch/lib/libcaffe2.so)
frame #5: at::TypeDefault::mul(at::Tensor const&, at::Tensor const&) const + 0x5d (0x7f0731addacd in /home/gupta/anaconda3/envs/gupta/lib/python3.6/site-packages/torch/lib/libcaffe2.so)
frame #6: torch::autograd::VariableType::mul(at::Tensor const&, at::Tensor const&) const + 0x649 (0x7f072ea319c9 in /home/gupta/anaconda3/envs/gupta/lib/python3.6/site-packages/torch/lib/libtorch.so.1)
frame #7: at::Tensor::mul(at::Tensor const&) const + 0x61 (0x7f073179db91 in /home/gupta/anaconda3/envs/gupta/lib/python3.6/site-packages/torch/lib/libcaffe2.so)
frame #8: <unknown function> + 0x245b6 (0x7f0716d4f5b6 in /home/gupta/anaconda3/envs/gupta/lib/python3.6/site-packages/torch_cluster/fps_cuda.cpython-36m-x86_64-linux-gnu.so)
frame #9: fps_cuda(at::Tensor, at::Tensor, float, bool) + 0x478 (0x7f0716d51721 in /home/gupta/anaconda3/envs/gupta/lib/python3.6/site-packages/torch_cluster/fps_cuda.cpython-36m-x86_64-linux-gnu.so)
frame #10: fps(at::Tensor, at::Tensor, float, bool) + 0x159 (0x7f0716d43159 in /home/gupta/anaconda3/envs/gupta/lib/python3.6/site-packages/torch_cluster/fps_cuda.cpython-36m-x86_64-linux-gnu.so)
frame #11: <unknown function> + 0x23026 (0x7f0716d4e026 in /home/gupta/anaconda3/envs/gupta/lib/python3.6/site-packages/torch_cluster/fps_cuda.cpython-36m-x86_64-linux-gnu.so)
frame #12: <unknown function> + 0x2324e (0x7f0716d4e24e in /home/gupta/anaconda3/envs/gupta/lib/python3.6/site-packages/torch_cluster/fps_cuda.cpython-36m-x86_64-linux-gnu.so)
frame #13: <unknown function> + 0x2054c (0x7f0716d4b54c in /home/gupta/anaconda3/envs/gupta/lib/python3.6/site-packages/torch_cluster/fps_cuda.cpython-36m-x86_64-linux-gnu.so)
<omitting python frames>
frame #45: __libc_start_main + 0xf0 (0x7f0766750830 in /lib/x86_64-linux-gnu/libc.so.6)

I checked my arguments to that function:
print(pos.type(), batch.type())
torch.cuda.DoubleTensor, torch.cuda.LongTensor

print(pos.shape, batch.shape)
torch.Size([32896, 3]) torch.Size([32896])

Your input shapes and types looks correct. We actually test the fps implementation for all combinations of dtypes and devices, see here, so I am not exactly sure what causes  this issue. Does this work when pos is a float tensor?

This solves the problem, thank you!


@UseFilters() dont work in middleware

When @Middleware throw exception, my own @UserFilters doesnt catch the error, ExceptionsHandler is throw the error.

Hey @silvelo ! Can you give us the code sample ?

@ThomRick Hi I upload a repo with example https://github.com/silvelo/nestexception.
This server example contains two url to test both with fails, one its correct and the other not.
The first url fail in controller and my OwnfilterException catch the error, but the second the error was in middleware and my filterException doesnt catch

Hey @silvelo,
Thanks for reporting the issue. Let's update your @nestjs/core into 3.0.1 version.

Thanks for quick reply .


About Echo implementation

Hi, I really like the project @mvrilo but there's some suggestions that I think could improve the project, between these are:

The echo example could be updated for something like this:

The problem with use a middleware for just show documentation is that overwrites all other endpoints.

Other things that I'm sure that goes well to the package is the json/yaml tags for the structs, more than nothing because normally the HTTP Servers have configuration files and directly set everything in that configuration file sounds good.

Another improvement could be the favicon.ico implementation, in the same way the openapi.yaml is provided in my case.

I don't know if I can open a merge request to make these changes, ready to hear your opinion, me.

Hey @luisnquin, sorry the delay and thanks for reaching out!

The problem with use a middleware for just show documentation is that overwrites all other endpoints.

This sounds like a bug actually, looking at the code the middlewares should be calling the Next method in the end so we don't stop other handlers to be called afterwards. I'll push a fix for that this weekend.

Other things that I'm sure that goes well to the package is the json/yaml tags for the structs, more than nothing because normally the HTTP Servers have configuration files and directly set everything in that configuration file sounds good.

Not sure about this. Are you talking about loading from a config file directly into a Redoc struct?

Another improvement could be the favicon.ico implementation, in the same way the openapi.yaml is provided in my case.

Makes sense. Any thoughts on adding a Favicon field on the Redoc struct for this? Could you open a PR for this?

I just pushed a v0.1.2 fixing the next handlers issue for gin and echo.


Multiple connection between server and clients

add the possibility to connect multiple client to the server and have a server able to save it and exchange with


Create Pull Request Template

Create PR templates by adding the necessary fields:

Related issue.
Short description of the feature/fix
Reproducible path to exhibit the feature or the bug fix.
Short description of the chosen solution.
Other branches or releases will backport the fix if applicable.
Checklist that the contributor must check before merging the PR into develop:

The global feature is completed.
The issue checklist is completed.
The code is unit-tested, and the coverage is above the threshold.
Integration tests (end-to-end tests) are automated and executed.
A new entry in the release notes has been added.
The documentation is updated, or a dedicated issue is created.

/attempt @jrobinAV #2109 please assign me this issue

@sahilborse This is not open for contribution. You can look at issues with "good first issue" or "Help Wanted"


Chinese Translation of learn page

@awvwgk Sir, It seems that in the learn page's chinese translation the myst-markdown format has been misimplemented ( at some places) , Thus I would like to request community members please fix this minor bug in the chinese translation.
We are Grateful for your Contributions in the Translations for the fortran-lang.org site.
Link to learn page translation : https://fortran-lang.github.io/webpage/zh_CN/learn/
Thanks and Regards,
Henil Shalin Panchal
CC @awvwgk

@awvwgk @fortran-lang/i18n-cn I have looked into the CN translations there is a bug in Myst markdown.
Thanks and Regards,
Henil Shalin Panchal

Closing as resolved. Thanks


Added json functionality

https://github.com/brianmhess/cassandra-loader/compare/json...phact:json?expand=1&w=0 for whitespace-less comparison

https://github.com/brianmhess/cassandra-loader/pull/47/files?w=0

make setColumnsMeta to private.   <— done
to change the name to getColumnNames/setColumnNames  <—— done


version 4.3.2 no longer works with React DnD

Describe the bug
React DnD with HTML5 backend enabled components were draggable with version 4.0.3 of this package.  Between 4.0.3 and 4.32, HTML5 drag events no longer seem to work.

Your environment

Version of panzoom - 4.3.2
Browser and browser version - Chrome, Version 86.0.4240.193 (Official Build) (64-bit)

Expected behavior
Ideally, DnD enabled components should work as they did in version 4.0.3.

Components should work with HTML5 dnd
Actual behavior
No dnd events seem to be working.

Steps to reproduce
Probably have to setup a test to show this.  Please LMK if you need me to make sample repo w/ this issue.

Thanks for opening an issue. It's hard to say without looking at the internals of React DnD, but it's likely there are conflicts binding to the same events. You can control this behavior in Panzoom with the handleStartEvent option. Another likely culprit is touchAction, which you can also change, but be sure to test on mobile.
These options should be enough to restore DnD events. Let me know if it doesn't.

Thank you. Will look into those.  I also understand this isn't really a bug, per say, more an FYI.  Once I get some time I'll put together something simple for testing.


feat: specialize Vec (and friends) in cbor encoding

FOR DISCUSSION, depends on https://github.com/sagebind/castaway/pull/2 anyways.
Previously, Box<[u8]> would serialize to a byte string, but Vec<u8> would serialize to an array of bytes. Now, they both serialize to a byte string.
The only downside is that Decode is only implemented on over Vec where T is static. But I see no cases where one could reasonably decode into a non-static type.
I believe the new behavior will more closely match the user's expectation, and it'll definitely perform better.
This is all made possible with the cast macro from the castaway crate that allows for very basic specialization. That magic should be optimized away at compile time.

Interesting, lgtm. maybe time for a changelog as this is a breaking change.

Awesome! And i'll update the changelog and add some tests.
(meant to submit as a draft)

The only downside is that Decode is only implemented on over Vec where T is static. But I see no cases where one could reasonably decode into a non-static type.

Ok, so this is also the case for encode, which is unfortunate. I.e., one can't encode [&someString]. Is this a common case?

While I was working on Serde related things, I stumbled upon what serde_bytes is doing. You would annotate the Vec<u8>. Perhaps we can also introduce some annotation. This would be more boilerplate code, though less magic, like breaking [&someString].
Or we do the reverse and have some annotation for the [&someString] case, which seems way less often used then Vec<u8>.

I think I'm a fan of having things more explicit and less magic and also similarly to what people are used to (Serde). As we are about to move to Serde for de(serializtion) I don't think there is much point of having this. Hence I'm closing it for now.


environment setup has invalid section in yaml and dependency conflicts on Ubuntu 22.04 with CUDA GPU

👋  I'm poking around the yaml to see what the fix is for my machine, not sure if others are running into this. I'm using the latest version of mamba.
# rave at rave-desktop in ~/clay-model on git:main ● [15:10:19]
→ mamba env create --file environment.yml

EnvironmentSectionNotValid: The following section on '/home/rave/clay-model/environment.yml' is invalid and will be ignored:
 - platforms

Channels:
 - conda-forge
Platform: linux-64
Collecting package metadata (repodata.json): done
Solving environment: failed
Channels:
 - conda-forge
Platform: linux-64
Collecting package metadata (repodata.json): done
Solving environment: failed

LibMambaUnsatisfiableError: Encountered problems while solving:
  - package torchgeo-0.5.2-pyhd8ed1ab_0 requires segmentation-models-pytorch >=0.2, but none of the providers can be installed
  - package pylance-0.14.1-py311h6a0c370_0 requires pyarrow >=12,<15.0.1, but none of the providers can be installed

Could not solve for environment specs
The following packages are incompatible
├─ lancedb ~=0.10.2  is installable with the potential options
│  ├─ lancedb 0.10.2 would require
│  │  └─ pylance 0.14.1  with the potential options
│  │     ├─ pylance 0.14.1 would require
│  │     │  └─ pyarrow >=12,<15.0.1  with the potential options
│  │     │     ├─ pyarrow [12.0.0|12.0.1|...|16.1.0] would require
│  │     │     │  └─ python_abi 3.10.* *_cp310, which can be installed;
│  │     │     ├─ pyarrow [12.0.0|12.0.1|...|15.0.0], which can be installed;
│  │     │     ├─ pyarrow [12.0.0|12.0.1|...|16.1.0] would require
│  │     │     │  └─ python_abi 3.8.* *_cp38, which can be installed;
│  │     │     ├─ pyarrow [12.0.0|12.0.1|...|16.1.0] would require
│  │     │     │  └─ python_abi 3.9.* *_cp39, which can be installed;
│  │     │     └─ pyarrow [13.0.0|14.0.0|...|16.1.0] would require
│  │     │        └─ python_abi 3.12.* *_cp312, which can be installed;
│  │     ├─ pylance 0.14.1 would require
│  │     │  └─ python_abi 3.10.* *_cp310, which can be installed;
│  │     ├─ pylance 0.14.1 would require
│  │     │  └─ python_abi 3.12.* *_cp312, which can be installed;
│  │     └─ pylance 0.14.1 would require
│  │        └─ python_abi 3.9.* *_cp39, which can be installed;
│  ├─ lancedb 0.10.2 would require
│  │  └─ python_abi 3.10.* *_cp310, which can be installed;
│  ├─ lancedb 0.10.2 would require
│  │  └─ python_abi 3.12.* *_cp312, which can be installed;
│  └─ lancedb 0.10.2 would require
│     └─ python_abi 3.9.* *_cp39, which can be installed;
├─ pyarrow ~=16.1.0  is installable with the potential options
│  ├─ pyarrow [12.0.0|12.0.1|...|16.1.0], which can be installed (as previously explained);
│  ├─ pyarrow [12.0.0|12.0.1|...|16.1.0], which can be installed (as previously explained);
│  ├─ pyarrow [12.0.0|12.0.1|...|16.1.0], which can be installed (as previously explained);
│  ├─ pyarrow [13.0.0|14.0.0|...|16.1.0], which can be installed (as previously explained);
│  └─ pyarrow 16.1.0 conflicts with any installable versions previously reported;
├─ python ~=3.11.0  is not installable because it requires
│  └─ python_abi 3.11.* *_cp311, which conflicts with any installable versions previously reported;
├─ timm ~=0.9.16  is requested and can be installed;
└─ torchgeo ~=0.5.2  is not installable because it requires
   └─ segmentation-models-pytorch >=0.2  but there are no viable options
      ├─ segmentation-models-pytorch [0.2.0|0.2.1|0.3.0|0.3.1] would require
      │  └─ timm 0.4.12 , which conflicts with any installable versions previously reported;
      ├─ segmentation-models-pytorch 0.3.2 would require
      │  └─ timm 0.6.12 , which conflicts with any installable versions previously reported;
      └─ segmentation-models-pytorch 0.3.3 would require
         └─ timm 0.9.2 , which conflicts with any installable versions previously reported.

I can install from the lockfile successfully following these instructions, might be an upstream issue with mamba or how a dependency specifies it's own dependencies. https://clay-foundation.github.io/model/getting-started/installation.html#advanced

You're hitting into 2 separate dependency solving issues:
LibMambaUnsatisfiableError: Encountered problems while solving:
  - package torchgeo-0.5.2-pyhd8ed1ab_0 requires segmentation-models-pytorch >=0.2, but none of the providers can be installed
  - package pylance-0.14.1-py311h6a0c370_0 requires pyarrow >=12,<15.0.1, but none of the providers can be installed

The first one is because torchgeo depends on smp which has a hard pin on timm=0.9.2 (https://github.com/conda-forge/segmentation-models-pytorch-feedstock/pull/22#discussion_r1511659865). Second one is lancedb=0.10.2 depends on pylance=0.14.1 which has a upper pin on pyarrow<0.15.1.
I've opened a PR to refresh the lockfile at https://github.com/Clay-foundation/model/pull/310. Could you test installing from that branch?

The new lockfile worked for me (macOS).


Custom EditProfile page in multi-tenancy causes Missing required parameter

Package
filament/filament
Package Version
v3.0.91
Laravel Version
v10.30.1
Livewire Version
v3.1.0
PHP Version
PHP 8.2.13
Problem description
When adding a custom EditProfile screen to a panel with multi-tenancy, a missing required tenant parameter causes the tenant registration page to trigger an exception.
Expected behavior
When you visit a panel route without a tenant it should gracefully fail somehow. You can't create a team without a team if you have a custom EditProfile page created within the panel.
Steps to reproduce

Seed the database in the demo repo
Visit http://localhost/app
See the Missing required parameter for [Route: filament.app.pages.edit-profile] [URI: app/{tenant}/edit-profile] [Missing parameter: tenant].

Reproduction repository
https://github.com/johncarter-/filament-demo/tree/issue/tenant-create-edit-profile
Relevant log output
No response

I understand that this is could be considered not necessarily a bug and understand you way want to close it. But i believe it to be important for others to find should they run into the same issue.
The problem lies in having the EditProfile class extend a Filament\Pages\Page when I think it has to extend a Filament\Pages\SimplePage.

You are not extending Filament's EditProfile page, you're extending the base class?

Well I wanted the profile page to use the same layout (nav, etc) and styling as one of my panels, so this seemed the logical choice.
It seems that panel layouts with a null tenant seem to be a no-no - right?

The reason why it's outside of the "tenant" area is because otherwise, a user without tenants wouldnt be able to access their profile, as the sidebar wouldnt be there

Thanks Dan, I'll give that a go. If I have success I'll update this issue. Feel free to close.

Gonna close this as I think that solved the problem for you.


MASTERCARD PARAMETER FILE

How do I determine DE93 from Parameter file using mci_ipm_param_to_csv.

I have not mapped out all the config in the IPM Param files so not sure the specific table that contains the DE field mapping to convert to CSV.
If you know what table, you can provide your own mapping via config. I don't have the MasterCard manuals to hand to check this.

Okay, I found the tables I want  IP0040T1  and IP0075T1. Can you assist on how to use the mci_ipm_param_to_csv? Always getting this error -- requested 4 bytes, got 0 -- exiting. Kindly assist

I will look at this when I have some time. I am available for paid engagements if your request is urgent. Please contact me via email for more details on costs to go down this path. Otherwise, please refrain from posting reminders here. Thanks.

Hi there,
There is not enough information for me to work out what the issue is. The 2 tables you mentioned have config, but I have not updated them for some time.
I am going to add a debug option to the command line utilities so that I can diagnose issues with files without having the files sent to me, but this will take me a little bit of time to put together. It will be available in the next release.
I'll let you know..

Hi @adelosa can you please share a sample config file for the mci_ipm_param_to_csv --config parameter

Config file documentation: https://cardutil.readthedocs.io/en/latest/cli.html#config-file and https://cardutil.readthedocs.io/en/latest/api.html#mci-parameter-tables
Provided default config file: https://github.com/adelosa/cardutil/blob/master/cardutil/config.py
Let me know if you need more details. Please consider contributing your new config file back to the project by attaching it to this issue. I will then update the default config.

Hi Anthony,
Thanks, I have found the config file, I will attach the updated config file
to the issue soon.
Regards,
Collins Baffour.
On Mon, Oct 17, 2022 at 12:03 PM Anthony Delosa @.***>
wrote:

Config file documentation:
https://cardutil.readthedocs.io/en/latest/cli.html#config-file and
https://cardutil.readthedocs.io/en/latest/api.html#mci-parameter-tables
Provided default config file:
https://github.com/adelosa/cardutil/blob/master/cardutil/config.py
Let me know if you need more details. Please consider contributing your
new config file back to the project by attaching it to this issue. I will
then update the default config.
—
Reply to this email directly, view it on GitHub
https://github.com/adelosa/cardutil/issues/8#issuecomment-1280749023,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFRDNPPPVKRHQGXV3LBAKOTWDU573ANCNFSM5Y57CXPQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

Hi Anthony now everything is working fine, can the echo be turned off for mci_ipm_param_to_csv?

I don't know what you mean. Can you provide details of what command paeans and the output you are receiving so I can understand the issue.

This is what I mean when you execute the command below, I don't want the tables to be printed in the console as in the image below:
mci_ipm_param_to_csv --in-encoding latin1 T168OLD --config cardutil.json IP0040T1

What is the contents of cardutil.json?

The updated config file I sent to you
On Fri, 21 Oct 2022, 08:27 Anthony Delosa, @.***> wrote:

What is the contents of cardutil.json?
—
Reply to this email directly, view it on GitHub
https://github.com/adelosa/cardutil/issues/8#issuecomment-1286634513,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFRDNPPOSJ2UWDAJPJ32KDLWEJHWZANCNFSM5Y57CXPQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

OK great - I missed the files you added to GitHub.. Thanks for this. I am adding this to the default config. I have also removed the print of the tables from param reader so you should not see this list unless you are using debug mode.
I will be releasing a new version shortly including the debug, config updates and above print remove.

Awesome, thanks!
On Sat, Oct 22, 2022 at 1:05 AM Anthony Delosa @.***>
wrote:

OK great - I missed the files you added to GitHub.. Thanks for this. I am
adding this to the default config. I have also removed the print of the
tables from param reader so you should not see this list unless you are
using debug mode.
I will be releasing a new version shortly including the debug, config
updates and above print remove.
—
Reply to this email directly, view it on GitHub
https://github.com/adelosa/cardutil/issues/8#issuecomment-1287567604,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFRDNPIQBIOE4NP6C4AZBCTWEM4W7ANCNFSM5Y57CXPQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

Closing as resolved.


Migrate to USWDS 3.0

Use this guide https://designsystem.digital.gov/documentation/migration/
This probably includes doing styling component-locally

Docs site update to sveltekit and migration to deploy using esbuild are done. Just need to go though every component and set up component scoped sass correctly. This will result in more being bundled, but means it won't require pulling in any external dependencies

I'm thinking the component scoped sass doesn't really make sense, since there are a lot of changes folks may want to make to various sass vars.
Also, I found https://github.com/carbon-design-system/sveld which should help simplify maintainability and syncing type files


wrapCC, wrapBintools: correctly cross-compile if buildPlatform != hostPlatform

Description of changes
The wrapper scripts have two main dependencies (aside from cc and bintools which are a given):

The shell used for executing the scripts, known as shell thus far.
expand-response-params, a small C program which requires a wrapped compiler to be built.

Previously, these programs would be essentially taken from/built with the package set used to build the package set that the wrapper itself is a part of (usually buildPackages). This is incorrect, as it only “works” if hostPlatform == buildPlatform (relative to the wrapper) or it will be impossible to execute the dependencies.
This has the consequence that if you e.g. build pkgsCross.aarch64-multiplatform.gcc, it will be impossible to execute the resulting (wrapped) compiler due to exec format errors.
This weird situation stems from the stdenv bootstrapping process where we have the concrete problem that building a shell and C program requires a wrapped C compiler, but we also require these to build the wrapper. The solution is to either do without the dependencies or take them from the previous bootstrapping stage and, ultimately, bootstrapTools. These is sound in this situation since during (initial) stdenv bootstrapping buildPlatform == hostPlatform == targetPlatform. It is, however, incorrect to have this leak into the main package set where cross compilation may happen.
The solution to this problem is to make the wrappers behave correctly in the main package set (taking cross into account) and worry about bootstrapping later. This is exactly what I've done:

Instead of shell which defaults to stdenvNoCC.shell (which is usually equivalent to buildPackages.runtimeShell), we use runtimeShell which is an attribute that exposes the default shell we use on the host platform.
Instead of ad hoc building expand-response-params inline in the wrapper derivation by trying to pull a stdenv out of buildPackages (so that we are effectively using buildPackages.buildPackages.gcc/clang), we just take it as an ordinary input (which works perfectly in the main package set) and let the caller worry about bootstrapping.

In a second step I've reflected these changes in the darwin and linux stdenvs, making sure that no derivation hash changes by inserting extra bootstrapping instructions where necessary. Some of these may actually be unnecessary (i.e. we may be able to build a proper runtimeShell earlier etc.), but this will have to be investigated separately as that would cause a stdenv rebuild.
This change is best reviewed commit by commit.

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[x] 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.05 Release Notes (or backporting 23.05 and 23.11 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

[x] Fits CONTRIBUTING.md.

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

cc @alexandretunstall

I think the pkgs/by-name CI error can be ignored, since I wouldn't want to move expand-response-params out of build-support for now.


Abbreviate instance Show GearHashTable

Calling show on a GearHashTable produces a large amount of output which is seemingly of little use, hence we propose a Show instance that shows a GearHashTable's footprint instead.

I have instead altered the Show instance to only print the name of the constructor.


OSError: sndfile library not found

Hello,
This problem happens in Windows10.
I tried to install the magenta without any error.
Looks like it will be OK.
Then I launch the magenta with
import magenta
I got error:
2019-11-27 18:43:47.490983: I tensorflow/stream_executor/platform/default/dso_loader.cc:44] Successfully opened dynamic library cudart64_100.dll
Traceback (most recent call last):
  File "E:\Users\admin\Anaconda3\envs\AI_Python3.7\lib\site-packages\soundfile.py", line 142, in <module>
    raise OSError('sndfile library not found')
OSError: sndfile library not found

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "e:\program files\magenta\magenta\__init__.py", line 34, in <module>
    import magenta.music.audio_io
  File "e:\program files\magenta\magenta\music\audio_io.py", line 23, in <module>
    import librosa
  File "C:\Users\admin\AppData\Roaming\Python\Python37\site-packages\librosa\__init__.py", line 12, in <module>
    from . import core
  File "C:\Users\admin\AppData\Roaming\Python\Python37\site-packages\librosa\core\__init__.py", line 124, in <module>
    from .audio import *  # pylint: disable=wildcard-import
  File "C:\Users\admin\AppData\Roaming\Python\Python37\site-packages\librosa\core\audio.py", line 10, in <module>
    import soundfile as sf
  File "E:\Users\admin\Anaconda3\envs\AI_Python3.7\lib\site-packages\soundfile.py", line 163, in <module>
    _path, '_soundfile_data', _libname))
OSError: cannot load library 'E:\Users\admin\Anaconda3\envs\AI_Python3.7\lib\site-packages\_soundfile_data\libsndfile64bit.dll': error 0x7e

I install libsndffile via Visual Studio Installation Package:
.\vcpkg.exe install libsndfile:x86-windows-static
Error still exists.
Thus, I want to discuss so that I can find the solution to resolve the problem.
Thanks & Regards!
Jun Yan

This issue only happens on Windows, not on Linux.
I have not found a suitable workaround currently.
Is there any suitable comment?
Thanks & regards!
Jun Yan

Momo, the right way to make it work on windows 10, is by using the linux shell.
Install the ubuntu shell on your windows 10 (https://itsfoss.com/install-bash-on-windows/)
After that, follow the steps on setting up the magenta environment using conda or manual installation (https://github.com/tensorflow/magenta/blob/master/README.md), from the linux shell.
Hope it helps!


Bug Report: i cant "lime rebuild extension-webm"

when i rebuild extension-webm it gives a error saying:
"fatal error LNK1112: machine module type 'x64' conflicts with target machine type 'ARM64'"

lime rebuild extension-webm macos
or linux

still

lime rebuild extension-webm macos
or linux

still got problem

when i rebuild extension-webm it gives a error saying:
"fatal error LNK1112: machine module type 'x64' conflicts with target machine type 'ARM64'"

Hello, I've been having the exact same issue for the past couple days as well with no solution yet. From what I've researched on the issue; The machine module type would be the processing type your CPU runs off of on your device/system and the target type would be the processing type that extension-webm is trying to use. The ARM64 processing type runs on CPUs for mobile devices and x64 is a processing type that runs on CPUs for devices such as desktop PCs These types are unfortunately conflicting and I have no idea as to why. I've also checked my source path for my extension-webm and it creates a WindowsArm64 folder where there should be a Windows64 folder hosting the extension-webm.ndll inside.

when i rebuild extension-webm it gives a error saying:
"fatal error LNK1112: machine module type 'x64' conflicts with target machine type 'ARM64'"

Hello, I've been having the exact same issue for the past couple of days as well with no solution yet. From what I've researched on the issue; The machine module type would be the processing type your CPU runs off of on your device/system and the target type would be the processing type that extension-webm is trying to use. The ARM64 processing type runs on CPUs for mobile devices and x64 or x86-64 is a processing type that runs on CPUs for devices such as desktop PCs. These types are unfortunately conflicting and I have no idea as to why. I've also checked my source path for my extension-webm and it creates a WindowsArm64 folder where there should be a Windows64 folder hosting the extension-webm.ndll inside at least for my Windows x86_64 operating system.

it dosen't have Windows64, i think that's why is not working.

when i rebuild extension-webm it gives a error saying:
"fatal error LNK1112: machine module type 'x64' conflicts with target machine type 'ARM64'"

Okay, delete the .lime folder at C:\Users\Username and delete the WindowsArm64 folder at C:\HaxeToolkit\haxe\lib\extension-webm\git\ndll. After which you can rebuild the extension-webm. If it doesn't work, then make a Windows64 folder in the ndll file and make sure the WindowsArm64 is still deleted. Then copy the .gitignore file into the Windows64 folder from one of the other folders in the ndll file then copy a extension-webm.ndll file from a kade engine executable mod or kade engine itself. After which you can rebuild the extension-webm.


add AppIcon

fixes #12

Since the icon was added to an asset catalog, no changes are necessary to the Xcode project. If you can revert the changes to DittoToolsApp.xcodeproj/project.pbxproj then it will go back to using the swift package in the current branch/dir.

Reversed the changes to the project.pbxproj file. When trying to open the project I get:

Got this error before I made changes to the project file and seeing them again now that I reversed it back.
Don't see any conflict conflict markers. Did cntrl+f and might be missing a bracket somwhere? '{' shows 127 and '}' shows 126

I'll take a look at the project file @texasRanger09

Found the problem. There was a missing end } after a reference to DittoDataBrowser.
/* Begin XCSwiftPackageProductDependency section */
		0E1252B62951114B00BCC55E /* DittoDataBrowser */ = {
			isa = XCSwiftPackageProductDependency;
			package = 0E1252B52951114B00BCC55E /* XCRemoteSwiftPackageReference "DittoSwiftTools" */;
		F87DC47B2988584200899FEC /* DittoDataBrowser */ = {
			isa = XCSwiftPackageProductDependency;
			productName = DittoDataBrowser;
		};

I'll push a fix in a minute

Looks like it was my fault 🙈 Sorry!
https://github.com/getditto/DittoSwiftTools/blob/main/DittoToolsApp/DittoToolsApp.xcodeproj/project.pbxproj#L751-L753

OK, try this update out @texasRanger09

Looks good! thanks


EXEC : error : getaddrinfo ENOENT dc.services.visualstudio.com

Hi there,
I'm unable to build my solution.
The following error:  EXEC : error : getaddrinfo ENOENT dc.services.visualstudio.com appears to be a cause of build failing everytime.
ApplicationInsights:CorrelationIdManager [
EXEC : error : getaddrinfo ENOENT dc.services.visualstudio.com [C:\Solutions\CustomNTONPCFMultiselectLookup\NToNMultiSelect.pcfproj]
at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:71:26)
at GetAddrInfoReqWrap.callbackTrampoline (node:internal/async_hooks:130:17) {
errno: -4058,
code: 'ENOENT',
syscall: 'getaddrinfo',
hostname: 'dc.services.visualstudio.com'
}
]
The issue follows:
[C:\Solutions\CustomNTONPCFMultiselectLookup\NToNMultiSelect.pcfproj]
C:\Users\xxxx.nuget\packages\microsoft.powerapps.msbuild.pcf\1.13.6\build\Microsoft.PowerApps.MSBuild.Pcf.targets(61,5):
error MSB3073: The command "npm run build -- --noColor --buildMode development --o
utDir "C:\Solutions\CustomNTONPCFMultiselectLookup\out\controls" --buildSource MSBuild" exited with code -1.
Connected to org VPN via DirectAccess

Looks like you're trying to use visual studio and this is visual studio code. you will need to file an issue in their repo


Merge similar functionality into generics, remove redundancy

On the Rust side, there are currently a few parts that might potentially be redundant. As it is all still in the early development phase, this might change (so I am not doing larger refactoring yet). Once we move a bit, however, we should be aware that the following things could be merged together or (with some changes) removed:

In the properties module, DynProperty and StatProperty implement similar API, we can probably move it into a separate Property trait.
Manager classes currently implement their own serde (de)serialization - this could probably be avoided using some utilities and serde tags. It might also become obsolete completely, as it seems the (de)serialization will be done through suitable intermediate structs (see data_structs module).
Some of the low-level structs in data_structs module might become redundant (mainly different kinds of properties, and some enums), as their main goal is to allow for simple (de)serialization, and the same could probably be achieved through the use serde tags. This is not the case for the "top-level" structures.

The redundant serialization code for manager classes was removed in #52 and #56. We use the intermediate simplified structs in data_structs module for (de)serialization.


[Feature Request] Mark a position between 2 characters

Context

[X] This issue is not a bug report. (please use a different template for reporting a bug)
[X] This issue is not a duplicate of an existing issue. (please use the search to find existing issues)

Description
I often use markers to underline a part of code (e.g., to invite users to hover on it and see hints). Most of time, we want to underline at least one characters. But sometimes, we may want to underline the position between two characters. For instance, given a formula fg(23,), I want to underline the position between , and ), then hovering on it shows a non-empty argument is expected here.
It seems that the following code in the playground can achieve this more or less.
var ed = monaco.editor.create(document.getElementById("container"), {
    value: "fg(23,)",
    language: "javascript"
});

monaco.editor.setModelMarkers(ed.getModel(), 'test', [{
    startLineNumber: 1,
    startColumn: 7,
    endLineNumber: 1,
    endColumn: 7,
    message: "a non-empty argument is expected here",
    severity: 8
}])

However, setting startColumn same as endColumn does not always do the trick. For instance, I cannot underline the position between ( and 2; setting startColumn: 4, endColumn: 4 does not work.
So does anyone know how to mark a position between 2 characters? We are not limited to underlining, other ways like highlighting are welcomed as well.
(* Link on StackOverflow: https://stackoverflow.com/questions/71617919 *)

I think the marker API highlights the entire word if its span was collapsed and contained in a word:
var ed = monaco.editor.create(document.getElementById("container"), {
    value: "fg(12345,)",
    language: "javascript"
});

monaco.editor.setModelMarkers(ed.getModel(), 'test', [{
    startLineNumber: 1,
    startColumn: 4,
    endLineNumber: 1,
    endColumn: 4,
    message: "a non-empty argument is expected here",
    severity: 8
}])

Maybe you can work around this by not using markers, but rather the decoration API directly.

decoration API

Thank you. I found this sample and IModelDecorationOptions. Could you tell me which element could be used to mark the position between 2 characters?

Here is a working solution: https://stackoverflow.com/a/71667770/702977


How to add USB support?

Love the blog, finished the PS/2 keyboard support.
Also gone through 3rd edition of what you have so far.
I really want to attempt USB support for keyboard but it seems challenging.
Looked at several USB libraries already.
usb-device crate seems to assume that i already have an object of UsbBus,
some examples for micro-controllers seems to get this from HAL crates, i did not find anything for x86 architecture.
Tried to ask around in the rust discord,
Was pointed to xhci, and then from there was told that i needed to initialize PCI.
I don't really know where to continue or what crate to use from here.
Would you be able to point me in the right direction and give an overview of which parts here would need to be implemented by me and which parts i could just take from existing crates?

https://wiki.osdev.org/Pci has a fair bit of information on how to work with PCI.

https://docs.rs/usb-device/latest/usb_device/device/index.html
// Create the device-specific USB peripheral driver. The exact name and arguments are device
// specific, so check the documentation for your device driver crate.
let usb_bus = device_specific_usb::UsbBus::new(...);
Example looks like this from usb_device crate.
Is it possible to pass something in here?
If i have to use pci-types crate then give an example of how i would use it?

Is it possible to pass something in here?

You did have to implement the UsbBus trait yourself I think. I'm not familiar with how USB or the usb_device crates work, so I can't help you with that.

If i have to use pci-types crate then give an example of how i would use it?

This is what Redox OS uses: https://gitlab.redox-os.org/redox-os/drivers/-/blob/master/pcid/src/main.rs?ref_type=heads It is fairly messy IMO and it has to deal with the PCI interfacing running in a different process from the actual PCI drivers.
Hermit may be a better learning source: https://github.com/hermit-os/kernel/blob/main/src/arch/x86_64/kernel/pci.rs

Well USB depends on xHCI, so that needs to be set up first. Here's an example of that.

Did you figure it out in the end? I would also like to learn how USB works/how to implement it


Elytra Superman pose is no longer toggleable in 1.6.3 - 1.6.3a

https://github.com/Wilyicaro/Legacy-Minecraft/assets/39068731/c9d8625b-0b2a-4268-b97b-6c6f03e5a0f2

Fixed in 1.6.3b, thanks for reporting.


Fix etcd endpoints when etcd is in different namespace

Fix the etcd endpoints issue when etcd is in different namespace
as described in https://github.com/kserve/modelmesh-serving/issues/186
The default etcd connection endpoints in quick start and fvt yaml are
changed to be placceholder based, and will be replaced during the
install script run. The etcd secret propagation will no longer assume
that etcd resides in the controller namespace.
Signed-off-by: Chin Huang<EMAIL_ADDRESS>Motivation
Modifications
Result

/lgtm


Prismic routable&sitemapable docs

(I forgot to tell that you should also use the branch name from Linear, that way
the bot adds the link to the issue)


Singleton proxy reference, closes #4

Codecov Report

Merging #9 into master will increase coverage by 0.16%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master      #9      +/-   ##
=========================================
+ Coverage   98.03%   98.2%   +0.16%
=========================================
  Files          16      16
  Lines         407     445      +38
=========================================
+ Hits          399     437      +38
  Misses          8       8

Impacted Files
Coverage Δ

src/spike/singleton.hpp
100% <100%> (ø)
:arrow_up:

tests/spike/test_singleton.cpp
100% <100%> (ø)
:arrow_up:

src/spike/configuration.hpp
100% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


_ready() is not called in controls loaded by plugins

Godot 2.1 rc1 Windows 10 64 bits
I made a scene in order to design a part of my plugin's UI, so I can instance it easily. However I noticed that _ready() is not called at all, making the main script unable to initialize properly.
The doc is showing an example with _enter_tree(), which makes me think that it's intented. But why? _ready() would be as useful in tools as it is in games.

Ooops. Forgot the tool keyword.

Could some sort of warning by Godot be given in cases like this?

@Sslaxx how would Godot know? You could instance things in the scene without actually requiring scripts on them to have the tool keyword. However, if you instance things in the editor it is possible to have a warning.


Terminal's term_kill option is inconsistently used

I identified this issue when working on #11312. I fixed the other identified bugs in #11323, but this one seems a little more hairy and involves some design questions so I didn't want to tackle it for now and just filing an issue for record.
Basically, when you use the term_kill option when using something like :call term_start('zsh', {'term_kill': 'kill'}) (or via term_setkill, the documentation for :h term_setkill states that the terminal windows will automatically be killed when closed, instead of throwing an error (E947). However, this is only true when you try to exit Vim via :qa. If you are just closing the terminal window it will still throw the error or ask for confirmation (when using :confirm) just like a normal terminal window without the term_kill option set.
This is because the only code that respects that option is in term_try_stop_job, which gets called only when you are quitting Vim itself. The function will also try to wait for the terminal job to complete. Other places directly call free_terminal which always use "kill" to kill the job and don't wait. Properly fixing this probably will end up causing a wait whenever you use :q! etc to kill a terminal which is why I didn't want to tackle this for now. It also seems like a more niche use case of terminal. But perhaps the documentation should be updated.

Just for reference this is what :h term_setkill says, which is slightly inaccurate regarding the "close the terminal window in another way" part:
term_setkill({buf}, {how})				*term_setkill()*
		When exiting Vim or trying to close the terminal window in
		another way, {how} defines whether the job in the terminal can
		be stopped.
		When {how} is empty (the default), the job will not be
		stopped, trying to exit will result in |E947|.
		Otherwise, {how} specifies what signal to send to the job.
		See |job_stop()| for the values.

I identified this issue when working on #11312. I fixed the other
identified bugs in #11323, but this one seems a little more hairy and
involves some design questions so I didn't want to tackle it for now
and just filing an issue for record.
Basically, when you use the term_kill option when using something
like :call term_start('zsh', {'term_kill': 'kill'}) (or via
term_setkill, the documentation for :h term_setkill states that
the terminal windows will automatically be killed when closed, instead
of throwing an error (E947). However, this is only true when you try
to exit Vim via :qa. If you are just closing the terminal window it
will still throw the error or ask for confirmation (when using
:confirm) just like a normal terminal window without the term_kill
option set.
This is because the only code that respects that option is in
term_try_stop_job, which gets called only when you are quitting Vim
itself. The function will also try to wait for the terminal job to
complete. Other places directly call free_terminal which always
use "kill" to kill the job and don't wait. Properly fixing this
probably will end up causing a wait whenever you use :q! etc to kill
a terminal which is why I didn't want to tackle this for now. It also
seems like a more niche use case of terminal. But perhaps the
documentation should be updated.

The ":qa" command should behave similarly to using ":q" in every window.
In this case, if we make ":q" behave like what happens with ":qa", would
there be any problem?  We don't want to accidentlly kill a job, but
since that happens with ":qa" anyway, it would be considered
intentional.
--
ARTHUR:  I did say sorry about the `old woman,' but from the behind you
looked--
DENNIS:  What I object to is you automatically treat me like an inferior!
ARTHUR:  Well, I AM king...
The Quest for the Holy Grail (Monty Python)
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

I think it would need to wait for the job to finish similar to term_try_stop_job for a sec and then force kill. Maybe that could be slightly annoying for :q, but may not be terrible. I could give it a shot.
I do agree that :qa should behave similarly to :q and the consistency should be respected. This way users will know it's intentional and use features accordingly.


AppID is to long

I receive today my app id from solarman and it is to long for the config.json if I validate the config.
The app id has 16 numbers.

That should be resolved by now via #61. This is fixed in the latest version and v0.8.2.
The AppId can now either be 15 or 16 chars.
You can find the whole schema here.


feat: allow specifying env for fetchPipMetadata

This helps for configuring pip with environment variables. See https://github.com/nix-community/dream2nix/discussions/697 for more context.

Thanks I fixed this up and merged it over here: https://github.com/nix-community/dream2nix/pull/726
I'm worried that using callPackage will make it harder to override dependencies. We should go through deps as much as possible.


Make a FontManager

Equivalent of TextureManager but for sf::Font

Done in commit https://github.com/Sygmei/ObEngine/commit/924ad640b2c426682ef55275cc16b359669586d7


Added Lambda to ECS execution role policies

Coverage remained the same at 95.151% when pulling 712481ad4b22feeb38ebd3f95917ababae30f161 on cody-lambda-policy into 263cbbed3c2bf53f2739a8cee324108ccbb503dd on main.


Updating column type for report settings

Issue #: https://github.com/bcgov/met-public/issues/
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the met-public license (Apache 2.0).

Codecov Report

Merging #2298 (deb2f5a) into main (f9c3e79) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #2298   +/-   ##
=======================================
  Coverage   68.58%   68.58%
=======================================
  Files         472      472
  Lines       15580    15580
  Branches     1188     1188
=======================================
  Hits        10685    10685
  Misses       4689     4689
  Partials      206      206

Flag
Coverage Δ

metapi
76.77% <100.00%> (ø)

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

Files
Coverage Δ

met-api/src/met_api/models/report_setting.py
79.06% <100.00%> (ø)


Issues with custom versions table names in 4.0.0.beta.2

Occasionally In normal development environment, and regularly using spring it seems that PaperTrail 4.0.0.beta.2 looses track of the proper table name for version models. I have many version models in my rather large application. Each with its own table and custom class. PaperTraill::Version has been modified with  self.abstract_class = true and is only used as such. Since upgrading to 4.0.0.beta.2 if I reload the application from the console with reload! things go haywire. The fact that reload! can consistently reproduce the issue points some to why spring just wont work at all. This seems to be some type of preload/autoload issue. I'm pretty sure this would not manifest in production environments where code is not reloaded, but I could be wrong. Here is an example of the problem in action:
$ be rails console                                                                  ✹
Loading development environment (Rails 3.2.21)
[1] pry(main)> StoryTagVersion.count
   (0.3ms)  SELECT COUNT(*) FROM `dk4_dev_versions`.`story_tag_versions`
=> 1
[2] pry(main)> reload!
Reloading...
   (0.5ms)  SELECT DATABASE() as db
   (0.4ms)  SELECT DATABASE() as db
   (0.5ms)  SELECT DATABASE() as db
   (0.4ms)  SELECT DATABASE() as db
   (0.4ms)  SELECT DATABASE() as db
   (0.3ms)  SELECT DATABASE() as db
=> true
[3] pry(main)> StoryTagVersion.count
ActiveRecord::StatementInvalid: Mysql2::Error: Table 'dk4_dev_versions.versions' doesn't exist: SHOW FULL FIELDS FROM `versions`
from .bundle/bundle/ruby/1.9.1/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:245:in `query

This issue pretty much breaks my test suite since it reloads code (like pretty much all rails test suites). It runs fine for a while then everything starts failing due to the same type of exception as above.

See #483, I think that person may have more insight

Interesting. I'm not using the PaperTrail::Rails::Engine.eager_load! statement as I am in rails 3.2 and the docs claim that it is not needed unless rails >= 4.0. I'm going to try a few more things and report back. Thanks for the info.

Using 3.0.6 we did not explicitly use self.table_name in the version model definitions. Doing so made all my tests work again, but does not fix issues reload! or spring.

Actually, what the docs are trying to say is that the PaperTrail::Rails::Engine.eager_load! statement is needed for PaperTrail version 4.x, but not for version 3.x. The version of ActiveRecord / Rails being used is not relevant with regards to that.  So have you tried putting that statement at the top of your custom initializer?

I have the same issue.
beta2 with rails 4.2.0 but for me having self.table_name in my version models does not fix the issue.
The issue persists itself when modifying some code that force a reload in the dev environment.
So start server -> works -> save app/controllers/application_controller.rb -> reload -> does not work anymore

I think this is a duplicate of https://github.com/airblade/paper_trail/pull/492 and others like it.  We have addressed this issue by asking people to stop using an initializer.  We've found that initializers aren't compatible with reload!.  The new recommendation is given in the readme, and was added to the readme by https://github.com/airblade/paper_trail/pull/557.


chore: Add a test workflow

This is the first PR in a series to migrate CI jobs from GitLab CI to GitHub Actions.
Checks run:

Unit tests (tests/core, tests/cookiecutters) on all supported Python versions
External tests (tests/external). Requires setting up secrets.
Doctests
Lint

For unit and external tests, coverage is computed and later combined and uploaded to Codecov in the coverage job.
This PR also adds dependabot updates for Python tools used in CI (poetry, pip) and third-party GitHub actions.
Closes #680

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@050f604). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #679   +/-   ##
=======================================
  Coverage        ?   85.18%
=======================================
  Files           ?       34
  Lines           ?     3361
  Branches        ?        0
=======================================
  Hits            ?     2863
  Misses          ?      498
  Partials        ?        0

Continue to review full report at Codecov.

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

Do I need to take some action for that?

@aaronsteers yup, any secrets used in the GitLab CI job should be copied to https://github.com/meltano/sdk/settings/secrets/actions

Do I need to take some action for that?

@aaronsteers yup, any secrets used in the GitLab CI job should be copied to https://github.com/meltano/sdk/settings/secrets/actions

Secrets are now created as organization secrets, shared with this repo and present at the link above.
I've temporarily removed the external item from the matrix so this can pass.
@edgarrmondragon - can we merge for now and handle the follow-up in #683 ?

@aaronsteers

can we merge for now and handle the follow-up in https://github.com/meltano/sdk/issues/683 ?

Sure 👍


yara-python match causes segmentation fault

I used the actual sources and compiled them on 3.8.0-34-generic Linux 32bit.
Checking a process with yara succeeds while checking the same process using the python module causes a segmentation fault.
I used the same rule set in both cases. Both processes are started as root.
Am I doing something wrong?

Closing because it's a very old issue. Please re-open if still valid.


Update colors for iOS 13.

Updated to use adaptive colors for Dark Mode in iOS 13. Feel free to suggest changes.

Tries to fix #407

Hi! Please, update code with last commit.
Also remove Carthage changes.

@chrischute Please, update with last commit from master branch b66a18c67baeb0f1db68c2865ca3a29de3790951
And rename Compat to something with full word. Or you can rename it with yp prefix, for example ypBlackColor .

@chrischute Thanks a ton for tackling such a much needed feature 👏 . I'll take care of the changes mentioned by @NikKovIos :)


torch-activate?

I seem to be missing torch-activate from my /bin directory

you mean, from ~/torch/install/bin?  Its normally because youre' missing checkarg and env or similar.  Anyway, the contents can be something like https://github.com/ASAPPinc/distro/blob/barebones-install/bat/torch-activate

I'm trying to follow the instructions listed here https://github.com/hughperkins/cltorch
and it mentions I need to have torch-activate (but I see in your distro I only use that if I have a non standard terminal)

nm, I see it.  I guess I didn't run ./install.sh

Ok.  To be honest, you should probably reinstall the standard distro, ie https://github.com/torch/distro.git

(though if cltorch works with the slimmed down distro, that would be interesting information.  I made that distro for non-gpu, cpu-only training though; never tested it on any form of gpu.  probably will work though.  I think)


spark: Provide a ParentRunFacet using spark.sql.execution.parent property

In the recent support for Databricks' Synapse connector (#452), lineage is truncated due to the way the Databricks connector is written when a Synapse table is the output destination.
There are two separate run ids being reported during a normal execution.

Run Id 1 comes from the execution start and displays the correct lineage
Run Id 2 comes from the job start and job end events in Spark

Reports the correct inputs
Reports a user defined staging location as the output

The individual job start events do provide a property called spark.sql.execution.parent which links Run Id 2 to Run Id 1. In this case, the value in spark.sql.execution.parent is the execution id of the parent spark sql execution start event.
Ideally, we would be able to use the ParentRunFacet to link these two run ids and correctly represent the lineage.
I would like to propose that this property should be detected and a ParentRunFacet should be added to the OpenLineage payload that refers to this parent run id.

Hey, @wjohnson, this would be fantastic! Do you have a link or reference to source code that shows this property being set? I don't see any reference to it in the Spark source code. Is it an Azure-specific setting? Or is it Databricks-specific? I'd love to know the specifics of when we can use this property.

Hey, @wjohnson, this would be fantastic! Do you have a link or reference to source code that shows this property being set? I don't see any reference to it in the Spark source code. Is it an Azure-specific setting? Or is it Databricks-specific? I'd love to know the specifics of when we can use this property.

@collado-mike I dug around too and I cannot find this in the particular jar that Databricks is using to write the Synapse tables. I'm guessing it's buried somewhere in the proprietary code of Databricks' spark?  If that's the case, I could add this to the Databricks environment facet as a stopgap for US but it won't help pursue a general solution for all of spark.

I'm investigating how I might add this for JUST Databricks and I'm a bit stuck.
I've put together a sample of what I want to accomplish and I can get it to generate the ParentRunFacet on #707 with a hard coded UUID and parent job name but I could use some help thinking about how to go from execution id to RunId and Parent Job Name when I'm in the SparkSqlExecutionContext.
@collado-mike  and @mobuchowski  if you had a cycle or two, I'd appreciate any thoughts.

If the parent job manages to set up property that child jobs are able to read, maybe we could just write runId the same way? Would be great to understand how it's being set.

@wjohnson is this issue still relevant?


Linking issues on Ubuntu 20 for cthulhu

🐛 Bug
import cthulhubindings fails with error ImportError: cthulhubindings.cpython-36m-x86_64-linux-gnu.so: undefined symbol: shm_unlink
To Reproduce
Steps to reproduce the behavior:

Installed labgraph on Ubuntu 20, with base install of Python 3.6 (from ppa:deadsnakes/ppa)
python3.6 -m labgraph.examples.simple_viz
ImportError: /usr/local/lib/python3.6/dist-packages/labgraph-1.0.0-py3.6-linux-x86_64.egg/cthulhubindings.cpython-36m-x86_64-linux-gnu.so: undefined symbol: shm_unlink

The test suite also fails (all errors) as import cthulhubindings fails
Expected behavior
works
Environment
 - LabGraph Version (e.g., 1.0): 1.0.0
 - OS (e.g., Linux/Mac/Windows): Ubuntu 20.04.2 LTS
 - Python version: 3.6.14 from `ppa:deadsnakes/ppa`
 - Any other relevant information: N/A

Additional context
It looks like the issue is in linking the relevant realtime libraries. I see in the buck config -lrt used in exported_linker_flags, but it doesn't look like it's picking it up. Is there a way to increase the verbosity of the buck outputs to be able to see the flags it passes to g++? I looked through the buck logs but nothing jumped out.

Thanks, Patrick, for reporting this issue. Pypi currently does not support Ubuntu. One alternative is to try to use another system. In the meanwhile, a cross-platform Pypi solution will be explored. We will keep you updated.

I agree it would be convenient to install from PyPI. I'm building from source though, cloning from the git repo and compiling using buck version 577c273d9746e42769e5dbb7bb5a092ba3ec82c2.

Also curious - what is the fundamental limitation keeping this from running on python versions other than 3.6?  If it's the cthulhu bindings, I'd be quite eager for a pure-python fork of this project with Cthulhu stripped out.  It's an incredibly performant messaging library, but I get the feeling that a ZMQ backend would be more than sufficient for 90% of users.

Thank you, patrickmineault and patrickmineault for your feedback! We have included this issue in the todo list of LabGraph. Alternatively, a potential easy fix could be by switching to clang++.

Hi patrickmineault, the recent update could help address your Ubuntu-related issue. You could either run Dockerfile.Ubuntu or follow the instructions in the Dockerfile. I'm going to create some instructions on running Dockerfile shortly. Feel free to come back to this issue again should you encounter further issues using LabGraph. Thank you for helping us create the 1st issue in LabGraph!

Hi griffinmilsap, I will create an FAQ session containing this topic and hope you could come back and help us discuss more on this topic.

I'm going to close this issue for now. If have more questions, feel free to reopen this issue or create a new issue.

Are there any further instructions on how to correct the above issue when compiling from source on Ubuntu 18 / 20?
Referenced issue:
ImportError: /usr/local/lib/python3.6/dist-packages/labgraph-1.0.0-py3.6-linux-x86_64.egg/cthulhubindings.cpython-36m-x86_64-linux-gnu.so: undefined symbol: shm_unlink

An example on usage in Ubuntu can be found here: https://github.com/facebookresearch/labgraph/blob/main/Dockerfile.Ubuntu

Are there any further instructions on how to correct the above issue when compiling from source on Ubuntu 18 / 20?
Referenced issue: ImportError: /usr/local/lib/python3.6/dist-packages/labgraph-1.0.0-py3.6-linux-x86_64.egg/cthulhubindings.cpython-36m-x86_64-linux-gnu.so: undefined symbol: shm_unlink

An example on usage in Ubuntu can be found here: https://github.com/facebookresearch/labgraph/blob/main/Dockerfile.Ubuntu

I am attempting to build from source (with python3.9) rather than installing the PyPi package. After running python3 setup.py install within my conda env, it appears that everything is built correctly and installed, but upon importing into python, I get the following error:
Python 3.9.7 (default, Sep 16 2021, 13:09:58)
[GCC 7.5.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import labgraph
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/peranpl1/Documents/repos/labgraph/labgraph/__init__.py", line 56, in <module>
    from .events import (
  File "/home/peranpl1/Documents/repos/labgraph/labgraph/events/__init__.py", line 17, in <module>
    from .event_generator import (
  File "/home/peranpl1/Documents/repos/labgraph/labgraph/events/event_generator.py", line 9, in <module>
    from ..graphs.topic import Topic
  File "/home/peranpl1/Documents/repos/labgraph/labgraph/graphs/__init__.py", line 24, in <module>
    from .config import Config
  File "/home/peranpl1/Documents/repos/labgraph/labgraph/graphs/config.py", line 8, in <module>
    from ..messages.message import Field, Message
  File "/home/peranpl1/Documents/repos/labgraph/labgraph/messages/__init__.py", line 18, in <module>
    from .message import Message, TimestampedMessage
  File "/home/peranpl1/Documents/repos/labgraph/labgraph/messages/message.py", line 15, in <module>
    from .._cthulhu.bindings import (
  File "/home/peranpl1/Documents/repos/labgraph/labgraph/_cthulhu/bindings.py", line 24, in <module>
    import cthulhubindings  # noqa: E402
ImportError: /home/peranpl1/miniconda/envs/lg-3.9/lib/python3.9/site-packages/cthulhubindings.cpython-39-x86_64-linux-gnu.so: undefined symbol: shm_unlink

The Dockerfile you linked is installing from PyPI rather than building from source.
Thanks for the help!

I am attempting to build from source (with python3.9) rather than installing the PyPi package. After running python3 setup.py install within my conda env, it appears that everything is built correctly and installed, but upon importing into python, I get the following error:
Python 3.9.7 (default, Sep 16 2021, 13:09:58)
[GCC 7.5.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import labgraph
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/peranpl1/Documents/repos/labgraph/labgraph/__init__.py", line 56, in <module>
    from .events import (
  File "/home/peranpl1/Documents/repos/labgraph/labgraph/events/__init__.py", line 17, in <module>
    from .event_generator import (
  File "/home/peranpl1/Documents/repos/labgraph/labgraph/events/event_generator.py", line 9, in <module>
    from ..graphs.topic import Topic
  File "/home/peranpl1/Documents/repos/labgraph/labgraph/graphs/__init__.py", line 24, in <module>
    from .config import Config
  File "/home/peranpl1/Documents/repos/labgraph/labgraph/graphs/config.py", line 8, in <module>
    from ..messages.message import Field, Message
  File "/home/peranpl1/Documents/repos/labgraph/labgraph/messages/__init__.py", line 18, in <module>
    from .message import Message, TimestampedMessage
  File "/home/peranpl1/Documents/repos/labgraph/labgraph/messages/message.py", line 15, in <module>
    from .._cthulhu.bindings import (
  File "/home/peranpl1/Documents/repos/labgraph/labgraph/_cthulhu/bindings.py", line 24, in <module>
    import cthulhubindings  # noqa: E402
ImportError: /home/peranpl1/miniconda/envs/lg-3.9/lib/python3.9/site-packages/cthulhubindings.cpython-39-x86_64-linux-gnu.so: undefined symbol: shm_unlink

The Dockerfile you linked is installing from PyPI rather than building from source.
Thanks for the help!

The reason for this error is that the pybinding is not cross-platform supported. For a quick start of using the LabGraph in Ubuntu, I would recommend using pypi. Alternatively, I will find some time in the future supporting additional linux environments (e.g. via pypi, build from source and conda). If you are interested in getting some hands-on for pybindings, you could use the following docker files as reference in Centos and Ubuntu. C++ and python bindings may need to be modified and please be aware that this build from source may not be trivial.

Thanks, I'll take a look at that.

I had a similar error in a different library and this was the most relevant search result.
For me, the problem turned out to be that Cython was finding the shm_unlink symbol during linking and at runtime in Ubuntu 22.04, but only during linking (not at runtime) in Ubuntu 20.04. My guess is that a dependency exposes this symbol (transitively) in jammy but not focal.
Anyway, I simply added "rt" to my list in setup(ext_modules=[Extension(..., libraries=[..., "rt"])], ...) in setup.py and now it works.
If this problem persists in labgraph then this might be a hint. I don't know how Buck works and I couldn't figure out where dependencies are listed so I can't help anymore than that.


LoRA issue "not in the list of present adapters: set()"

Using CogVideoX-5b-I2V, latest repo tip, latest tip of ComfyUI, and latest version of diffusers. LoraSelect node connected to (Down)load CogVideo Model node.
Error:
2024-11-21T12:14:44.812171 - [{'path': 'C:\\Comfy\\models\\CogVideo\\loras\\ExVideo-CogVideoX-LoRA-129f-v1.safetensors', 'strength': 1.0, 'name': 'ExVideo-CogVideoX-LoRA-129f-v1', 'fuse_lora': True}]2024-11-21T12:14:44.813704 -
2024-11-21T12:14:53.439639 - Merging rank 64 LoRA weights from C:\Comfy\models\CogVideo\loras\ExVideo-CogVideoX-LoRA-129f-v1.safetensors with strength 1.0
2024-11-21T12:14:53.450858 - !!! Exception during processing !!! Adapter name(s) {'C:\\Comfy\\models\\CogVideo\\loras\\ExVideo-CogVideoX-LoRA-129f-v1'} not in the list of present adapters: set().
2024-11-21T12:14:53.452894 - Traceback (most recent call last):
  File "C:\Comfy\execution.py", line 323, in execute
    output_data, output_ui, has_subgraph = get_output_data(obj, input_data_all, execution_block_cb=execution_block_cb, pre_execute_cb=pre_execute_cb)
                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Comfy\execution.py", line 198, in get_output_data
    return_values = _map_node_over_list(obj, input_data_all, obj.FUNCTION, allow_interrupt=True, execution_block_cb=execution_block_cb, pre_execute_cb=pre_execute_cb)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Comfy\execution.py", line 169, in _map_node_over_list
    process_inputs(input_dict, i)
  File "C:\Comfy\execution.py", line 158, in process_inputs
    results.append(getattr(obj, func)(**inputs))
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Comfy\custom_nodes\ComfyUI-CogVideoXWrapper\model_loading.py", line 274, in loadmodel
    pipe.set_adapters(adapter_list, adapter_weights=adapter_weights)
  File "C:\Comfy\venv\Lib\site-packages\diffusers\loaders\lora_base.py", line 539, in set_adapters
    raise ValueError(
ValueError: Adapter name(s) {'C:\\Comfy\\models\\CogVideo\\loras\\ExVideo-CogVideoX-LoRA-129f-v1'} not in the list of present adapters: set().

Seems specific to that LoRA, doesn't want to load with the diffusers lora loading code for some reason...

Yeah looks like their example (https://huggingface.co/ECNU-CILab/ExVideo-CogVideoX-LoRA-129f-v1) is using diffsynth:
https://github.com/modelscope/DiffSynth-Studio?tab=readme-ov-file
I don't see diffusers in their requirements, and skimming their model loading code (https://github.com/modelscope/DiffSynth-Studio/blob/main/diffsynth/models/model_manager.py#L365) I don't see it either. Maybe it's implicitly being called downstream by another library, not sure.

Yeah looks like their example (https://huggingface.co/ECNU-CILab/ExVideo-CogVideoX-LoRA-129f-v1) is using diffsynth:
https://github.com/modelscope/DiffSynth-Studio?tab=readme-ov-file
I don't see diffusers in their requirements, and skimming their model loading code (https://github.com/modelscope/DiffSynth-Studio/blob/main/diffsynth/models/model_manager.py#L365) I don't see it either. Maybe it's implicitly being called downstream by another library, not sure.

I'm pretty sure I had this one working at one point, before I moved to the diffusers LoRA loading... it was more manual merging method I used, maybe need to dig that back up.

@kijai how can be those LoRAs applied? I tried different ways to load and connect ExVideo lora into I2V workflow, but nodes just not connecting. Aren't those normal LoRAs and require special care or opposite way CogVideo nodes are special so require some "special" LoRA node to use? What can be connected to that input?

The ExVideo lora is different and currently not compatible.


1.6.1 CRJ encoder 6: NAV1 same as encoder5: COM1

Yes, it is intended - long press on given encoder activates COM for 5th encoder and NAV for 6th, then you can rotate it to select frequency. Short press switches between whole and fraction.


socket time out in pipeline, again

https://github.com/cypress-io/github-action#wait-on-with-nodejs-18


Suggestion: make swift generated classes KVO compliant

I'm not sure what the scope of this would be but it would be very useful to make the generated model classes work with KVO. Things like Cocoa Bindings on MacOS and observers would then "just work" with Apollo.

The generated types are Swift structs, not classes, so I'm afraid that won't work with KVO. You can use watchQuery to get notified of any updates to the data of a query however.


webpay Package guzzle/guzzle is abandoned

The install command below causes an error.
$ composer require webpay/webpay
"Package guzzle/guzzle is abandoned, you should avoid using it. Use guzzlehttp/guzzle instead.".
And this also causes
Fatal error:  Uncaught Guzzle\Common\Exception\RuntimeException: The PHP cURL extension must be installed to use Guzzle. in /var/www/html/xxxxxx/vendor/guzzle/guzzle/src/Guzzle/Http/Client.php:72
How do I solve it?

Thank you for bug reporting.
The first warning is webpay/webpay's problem. We must update dependencies. We need time to do that, but meanwhile, you may be able to use the current release.
The second problem is of your server machine. Your PHP install does not include cURL extension.
I cannot advice because there is no information about OS, version, etc. Google will help a lot. https://www.google.co.jp/search?q=The+PHP+cURL+extension+must+be+installed+to+use+Guzzle.&oq=The+PHP+cURL+extension+must+be+installed+to+use+Guzzle.&aqs=chrome..69i57j0l3.255j0j7&sourceid=chrome&ie=UTF-8
Because the problem is on your environment, I am sorry but we will not provide further help about this.

Thank you for your response.
I understand what I should do.


Back-End: Create Risks

Models, controllers and services

Created Risk model, service, requests, controller and repository.


Possible relax of License and Contributors constraints

1 The default repository stub has two licenses:

W3C Software and Document License -- for all reports
W3C 3-clause BSD License -- for Test Suites

It turns out, pull request constraints in the "awesome list of awesomes" in the sindresorhus/awesome repo has these license statements, which prevents us from adding this repository to the "awesomes" list after its completion:

We strongly recommend the CC0 license, but any Creative Commons license will work.
A code license like MIT, BSD, Apache, GPL, etc, is not acceptable. Neither are WTFPL and Unlicense.

Is it possible to do all of this for this repository?

To dump BSD for Test Suites, because there will be no Test Suites or any other source code?
To use for the Readme file, Issues and Pull requests CC0 license or any other of CC license instead of W3C Software and Document License?

2 There is another constraint in w3c-cg/awesome-semantic-shapes (if I understand it correctly) that a pull request author(s) should be strictly from the SHACL Community Group.
It is different from typical process in "awesomes" community where anyone could propose a pull request, but maintainers desides what to accept.

@ianbjacobs and @pchampin I am all for it!
Awesome lists are built collaboratively: people submit PRs.
Especially people who made something and want to advertise it in the list.
Asking them to sign contributor agreements will just turn them off.
This repo is "special" as w3c repos go: there's no spec here, just a crowd-sourced list of resources.
(PS: Ian, I cannot assign, would it be possible to allow me to?)

The SHACL CG is "chartered" to publish specifications. Therefore we expect to continue to ask for organizational licensing commitments for people joining the group.
If you want to accept contributions to this particular repo by non-participants, that is probably ok as long as that information does not go into a specification.

@ianbjacobs This is a crowd-sourced list of resources, it won't go into the specification.

@VladimirAlexiev, you can ask people to submit PRs to this repo, then, without requiring them to sign the CLA.
@dontcallmedom, can you work with me to configure the repo so that the IPR checks don't happen?

I've removed the IPR bot from this repo


Keyboard covers textfield

On iOS 11 there's an issue where keyboard covers the textfield where user can enter their explanation. Due to that, it is not possible to send score. Tapping on "edit score" pushes score view up like it should be when keyboard is visible, only now the keyboard is dismissed.

Hi @KatrinLomp we'll take a look at this and send a fix as soon as we can

Hi @KatrinLomp we've tested in different devices and with the latest version of iOS 11.0.3 and haven't been able to reproduce this bug.
Can you give us more context of how/when this happened?

I was using iPhone 6 plus with iOS 11.0.2. Also tried some simulators with 11.0.1 version. I tried to debug a bit and it seems, that userInfo[UIKeyboardFrameBeginUserInfoKey] gives 0 for height on my version. That's why it's broken. This appears to be common problem:
https://stackoverflow.com/questions/45689664/ios-11-keyboard-height-is-returning-0-in-keyboard-notification
I will update my phone to 11.0.3 and see if I can still reproduce it.

I can still reproduce it on iOS 11.0.3. I'm not sure what could be different in our code, but the cause seems clear to me. Changing UIKeyboardFrameBeginUserInfoKey with UIKeyboardFrameEndUserInfoKey will fix the issue. I have tested it on my device.

Hi @KatrinLomp we've released a new version with the fix. You can check the changes here
Thank you for your patience!


Add k8s 1.12, remove k8s 1.8

What's current status?

@AkihiroSuda I'm back from a vacation, working on this one. Will fix it in a day or two. Sorry for delay.


improve documentation on the derivatives

This was pointed out at the last bids-matlab meeting: there is no content regarding BIDS derivatives in the starter-kit.
This seems like an URGENT low hanging fruit.

Here's some content: https://hackmd.io/@effigies/bids-derivatives-readme

Here's some content: https://hackmd.io/@effigies/bids-derivatives-readme

Thanks @effigies
OK if I grab the derivative part of that and reinject it the wiki?
Similarly, some of the BIDS app part could go and supplement our BIDS app FAQ.

Thanks @effigies
OK if I grab the derivative part of that and reinject it the wiki?
Similarly, some of the BIDS app part could go and supplement our BIDS app FAQ.

Feel free to use any text verbatim, if it's useful.

Feel free to use any text verbatim, if it's useful.

Did  a "wild" copy paste of the core of that hackmd in the starter kit wiki.
Will refine it gradually. Hope this is OK.

Did  a "wild" copy paste of the core of that hackmd in the starter kit wiki.
Will refine it gradually. Hope this is OK.

closing this for now: the info is in the wiki