Panic on KMeansClassifier::train

I'm not sure quite what could be causing this. I'm attempting to cluster data with 2348 rows and 21 columns. Might be a bug in KMeans, or it might be an issue with my data, but it's just not clear where the error is from this backtrace. It doesn't fail all the time. With a smaller dataset it works just fine.
thread '<main>' panicked at 'Rng.gen_range called with low >= high', /Users/acsmith/.multirust/toolchains/nightly/cargo/registry/src/github.com-88ac128001ac3a9a/rand-0.3.14/src/lib.rs:466
stack backtrace:
   1:        0x10cdffa58 - std::sys::backtrace::tracing::imp::write::h9fb600083204ae7f
   2:        0x10ce02b25 - std::panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::hca543c34f11229ac
   3:        0x10ce0275e - std::panicking::default_hook::hc2c969e7453d080c
   4:        0x10cdf48b6 - std::sys_common::unwind::begin_unwind_inner::h30e12d15ce2b2e25
   5:        0x10cdd64f4 - std::sys_common::unwind::begin_unwind::h65390c63b501d6ed
   6:        0x10cdd7ea0 - _<learning..k_means..KMeansClassifier as learning..UnSupModel<linalg..matrix..Matrix<f64>, linalg..vector..Vector<usize>>>::train::hda9f4aa6ef437a10
   7:        0x10cd9ec4a - phoneme_morpher::run::hfaae9e912c91a493
   8:        0x10cd9c998 - phoneme_morpher::main::h44c66430a6737b02
   9:        0x10ce02352 - std::sys_common::unwind::try::try_fn::h04c0c89e4add6cc4
  10:        0x10cdfee3b - __rust_try
  11:        0x10ce02194 - std::rt::lang_start::h61f4934e780b4dfc
e

Thanks for reporting this - I can't see why this would be happening immediately. It is likely an issue with the way the data is being fed in (the models are currently fairly strict about the format - something which needs improving).
It could be one of the following:

You are setting k (the number of clusters) to 0 (seems unlikely as you said it works sometimes).
Your input data has zero rows (you rule this out in the description above).

If neither of those are true it seems likely it is a bug (or at least a data-dependent issue I'd like to try and detect at run time). I'll try to figure it out - if you're happy to share the data that may help too!

This error should only occur within the initialization phase. I'm assuming that you're using KMeans++ (the default scheme). You could try using forgy or random partition instead to see if it fixes the panic.
I'll keep trying to find the bug in the mean time.

Here's the kmeans feature vector that's crashing. (Take off the .txt extension. That's just to trick github into accepting it.)
Looks like there quite a bit of -inf and NaN values in there. Not sure how that happened, but that's obviously my problem to fix. So it seems like it's not a bug, but just bad values...and it seems like a waste to check every f64 value, so perhaps just add this to the list of things that might go wrong.
kmeans_features.csv.txt

That does seem to be the cause of the error. As you say there is not much we can do about this at the model level (at least without some significant changes). I think a fairly easy way to improve the errors would be to have the initialization return Results - that should give us more detailed error reports.
We can also test for this particular error by checking that the distance sum mentioned above is_normal. If not we can assume something went wrong with the data.
I'll keep this issue open to track how he handle this.

@andrewcsmith after a long delay I finally got round to this. I have a PR open ( #83 ).
There is some other stuff included but it addresses the issues discussed here (partly). If you have the time to check it out that would be awesome. I know it's been a while so don't feel compelled!


ComboBox don't respond click in a flyout of CommandBar

Describe the bug
I have a ComboBox in a CommandBar. CommandBar will collapse the content that cannot be displayed when the width is insufficient. Now I have a narrow window and the ComboBox is collapsed into the secondary menu. When the ComboBox is in the flyout of the secondary menu, it can be clicked to pop up the candidate items, but the selection cannot be responded normally.

Steps to reproduce the bug
<CommandBar Grid.Column="1" Margin="16,0,0,0" DefaultLabelPosition="Right">
    <CommandBar.Content>
        <!-- Try to fill the CommandBar -->
        <TextBox Width="1000"/>
    </CommandBar.Content>

    <AppBarElementContainer>
        <ComboBox ItemsSource="{Binding SomeList, Mode=OneWay}" SelectedItem="{Binding SomeList.CurrentItem, Mode=TwoWay}"/>
    </AppBarElementContainer>
</CommandBar>

Expected behavior
ComboBox's SelectedItem can be properly set in the flyout
Screenshots

NuGet package version
WinUI 3 - Windows App SDK 1.6.3: 1.6.241114003
Windows version
Windows Insider Build (xxxxx), Windows 11 (22H2): Build 22621
Additional context
Insider 26120
Windows 11 24H2 (26100)

@qhy040404 I could reproduce your issue from your provided code.  To fix this, you will need to update your AppBarElementContainer to allow focus on interaction. This will allow you to interact with your ComboBox when it's displayed in the flyout.   <AppBarElementContainer AllowFocusOnInteraction="True">

Thanks a q. It works.


Qa

Coverage decreased (-0.02%) to 85.698% when pulling 260ff0fe50025f345c48a25f8b3e4b80df79ca00 on qa into 4e2591827d343a36d1e8d8306cbb9e85a49f9355 on master.

Coverage decreased (-0.05%) to 85.666% when pulling 260ff0fe50025f345c48a25f8b3e4b80df79ca00 on qa into 4e2591827d343a36d1e8d8306cbb9e85a49f9355 on master.


Conntrack output field copy operations + fix duplicates

This PR brings copyFirst and copyLast operations for connection tracking OutputFields in order to be able to keep first flow direction informations as:
			OutputFields: []api.OutputField{
...
				{
					Name:      "FlowDirection",
					Operation: "copyFirst",
				},
				{
					Name:      "IfDirection",
					Operation: "copyFirst",
				},
				{
					Name:      "AgentIP",
					Operation: "copyFirst",
				},
			},

Also fix duplicates bypasing these on top of Extract loop that can generate multiple connection events

added duplicates fix testing https://github.com/netobserv/flowlogs-pipeline/pull/413/commits/015cea3a56d83ec6d58cc38894dd291eff8153bf

Thanks @jpinsonneau ! I'm very impressed by how quickly you understand the code and came up with a solution. Your approach to add the copy operations seems the most straight forward to me. Even though, I wonder whether there is a clean and simple way to integrate copiers and aggregators into the same interface...

Thanks @ronensc ! If it's fine for you we can merge the following maps:
	aggFields         map[string]float64
	cpFields          map[string]interface{}

and find a new name like transformer for all the outputFields manipulations

I'm fine with merging the maps.
I think "first" and "last" operations can be thought of as kinds of aggregation like in many SQL DBs.
So we don't have to come up with a new term.

Regarding the MoveToX(), when I discussed this with @eranra, we had concerns that it would be too costly in terms of CPU...
Hm... Alternatively, we could maintain a queue of the connections that got FIN and set them with smaller expiry timeout.

Yeah that was also part of my concerns. Should we duplicate the multiOrderedMap in groupType of connectionStore as:
type groupType struct {
	scheduling api.ConnTrackSchedulingGroup
	runningMom *utils.MultiOrderedMap
	expiredMom *utils.MultiOrderedMap
	labelValue string
}

tested https://github.com/netobserv/flowlogs-pipeline/pull/413/commits/34e0453b2835a5c62cec9544384d801ffe4dc66a on my cluster and works fine :+1:

Addressed all the feedbacks and rebased https://github.com/netobserv/flowlogs-pipeline/pull/413/commits/d3a20967d866f26aa7a19b65012732d9a5e5f679

Rebased following https://github.com/netobserv/flowlogs-pipeline/pull/421

/approve


[SPARK-50432] Remove workaround for THRIFT-4805

What changes were proposed in this pull request?

Remove workaround for THRIFT-4805 in log4j2 configuration files.
Why are the changes needed?

SPARK-47018 upgrades Thrift 0.16, and THRIFT-4805 was fixed in Thrift 0.13.
Does this PR introduce any user-facing change?

Affects default logs a little.
The existing logging filter rules use a regex to filter out the noisy logs caused by THRIFT-4805, while other problems may also produce similar logs and silently be dropped, this change restores that.
How was this patch tested?

Review.
Was this patch authored or co-authored using generative AI tooling?

No.

cc @yaooqinn @wangyum

What is the label for this PR?

@LuciferYang I'm not sure how it should be classified, maybe "Deployment"?

Maybe [BUILD] is ok too


fix: graphql examples front-end error

The urql library api has changed causing the graphql examples to error when running the front-end.
Instead of calling createClient, the urql client must now be invoked with new Client.  Additionally, new client params are required. The new syntax is:
import { Provider as UrqlProvider, Client, cacheExchange, fetchExchange } from "urql";
…
const urql = new Client({
  url: import.meta.env.VITE_GRAPHQL_URL,
  exchanges: [cacheExchange, fetchExchange],
});

This PR updates the examples with these changes.

@tyrauber Thanks for this! The examples/ files are generated from this one https://github.com/serverless-stack/sst/pull/2763/files#diff-a8049fd7e222e99eca959f0b0fc45fb59cc089c8b9176580c3d8007541fa861d. So we can remove those. Can you remove them from the PR and I'll merge them and generate the examples.

Also which version of urql is causing this? I need to upgrade another repo to this.

Hey @jayair, No problem. Happy to help wherever I can.  I think the version is correct, just the examples and tutorials contain the old syntax.  I am seeing 4.0.0 everywhere in the repo, and that is the latest release. I think just updating the examples and the tutorials to the new syntax should be enough.
If the examples are autogenerated, I think you can actually close this PR, no?

Yeah I think what happened is that the examples got generated with the newer version but the tutorial was still using the older one. I'll update it.
Thanks for bringing it up!


maintainers: add GPG key fingerprint for user kevincox

Description of changes

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.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

[ ] Fits CONTRIBUTING.md.

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

I would also keep attributes sorted alphabetically.

Every other keys = in the file is the last attribute. I think it is best to match the convention.

Conformity also has benefits navigating the codebase. I don't think that a small PR to add some data is the place to discuss changing a convention. If we want to change a convention is makes sense to do that independently of any data change and to do it all at once so that consistency is maintained. So I think we should merge this according to the existing convention and we can discuss changing the convention separately on its own merits.

I appreciate your points on conformity and the timing for discussing convention changes. My suggestion for alphabetical sorting aimed at consistency, not changing conventions. It's been a common practice in my reviews for clarity and hasn't been an issue sop far.
I respect your stance. Let's keep this PR aligned with your ideas, and we can discuss any potential changes in a separate conversation.
However, I'll pass on merging this PR to maintain objectivity. Looking forward to continuing our collaboration and discussions on improving nixpkgs.


Standardize option names

Motivation
Compression and iteration options have varied quite a bit over the years - this PR standardizes them into a single common structure (dictionaries compression_options and iterator_options) used within the tools and data interfaces. Those dictionaries contain all the information needed for someone to specify what type of compression/iteration to use. They consistent of two primary key/value pairs: method (the old compression or iterator_type) and method_options (the old compression_opts and iterator_opts).
A follow-up PR deals with docstrings, so don't focus on that here. This PR is just about the code itself; deprecation warnings and aliasing the inputs to the new standard.
How to test the behavior?
Tests have been adjusted to reflect any changes in behavior, though for the most part is back-compatible until final deprecation and removal of the arguments.
Checklist

[X] Have you thoroughly read our Developer Guide?
[X] Have you ensured the PR description clearly describes the problem and solutions?
[X] Have you checked to ensure that there aren't other open or previously closed Pull Requests for the same change?
[X] If this PR fixes an issue, is the first line of the PR description fix #XXX where XXX is the issue number?
[X] Did you update the CHANGLOG.md file on your branch to describe your changes?

Would this support dynamically loaded filters?

Would this support dynamically loaded filters?

It would at least support whatever we previously supported through our other options. I can't say entirely for sure b/c we don't test it and I haven't tried to.
If it isn't currently supported, this framework at least could very well allow it (at least I don't see why not): the method would be the filter from hdf5plugin and method_options are potentially whatever key/value pairs it takes.
Discussion also applies to the future support for a Zarr backend, where the method could well be an actual numcodecs class to be passed into the ZarrDataIO.

I think I prefer the format of having compression_type and compression_options as separate arguments. Maybe we could change compression_opts to compression_kwargs for consistency with other places

@h-mayorquin @weiglszonja As primary users of the NeuroConv package, what are your opinions about this from any of the times you've had to specify these types of options in your conversions?

For reference, also tracked down the original suggestion for the *_options structure to this PR with @h-mayorquin: https://github.com/catalystneuro/neuroconv/pull/116, though I'm sure we also had in-person discussion on the topic.

I think I prefer the format of having compression_type and compression_options as separate arguments.

The main point against that is as @h-mayorquin points out, the code smell of too many parameters.
I'd want to follow a similar structure for data interface stub_options as well - if we used separate arguments as you suggestion then each run_conversion call would have 6 pairwise inter-dependent arguments as opposed to just 3 that enforce a common nesting structure.

I think this is simpler for the user and nested dicts are more difficult to communicate ...

We're already utilizing such argument structure across this specific project (source_data, metadata, conversion_options), so if anything it would be more consistent with the API design of NeuroConv, and so long as it's well-documented it's not that much harder to communicate as opposed to having inter-dependent arguments.
I'd say it is also easier to communicate via YAML specifications since both linked arguments would be under the same heading
Example (a)
compression_options:
  method: gzip
  method_options: 4
iterator_options:
  method: v2
  method_options:
    buffer_gb: 5.0

as opposed to example (b)
compression_type: gzip
compression_options: 4
iterator_type: v2
iterator_options:
  buffer_gb: 5.0

which additionally allows for the possibility of scrambling these options, which could lead to hard-to-debug things like
conversion_options:
  SomeInterface:
    compression_options: 4
    iterator_options:
      buffer_gb: 5.0
    some_other_options: ...
    ...
    compression_type: gzip
    even_more_options: ...
    ...
    iterator_type: v1  # would actually cause an error, but can you easily see how to fix it?

whereas in (a) the dependent arguments remain intentionally linked and cannot be disentangled.

...and validate.

After looking into Pydantic more I don't actually think it would be difficult to setup validation for this using Pydantic schemas for the common options. That's even aside from discussions about the JSON side of it.

My personal vote goes for the simplification.
I find function signatures with a lot of arguments distracting and more intimidating at first glance. I also like keeping things semantically organized so everything related to compression is in one object (in this case a dict called compression_options) and everything related to iterative write in one object.  At an abstract level, I think this last preference can be defened by appealing to code cohesion or invoking the "code smell" of too many parameters. From a practical stand-point I feel that is easier to make changes and document with fewer keywords.
I think that some of the @bendichter concerns above can be solved by not nesting . Juse use a  one level dictionary  with the following structure: compression_options=dict(method="method_name",  **method_kwargs). To be explicit, we should use:
compression_options=dict(method="zip", gzip_level=8) instead of compression_options=dict(method="zip", method_options=dict(gzip_level=8)).

Just use a one level dictionary with the following structure: compression_options=dict(method="method_name",  **method_kwargs)

Hm... That might just work (and might even play nicer with validation), good idea!
I'll play around with it in a splinter PR from this base

Kind of parallel to the central point but a good point to discuss now that @bendichter as mentioned dynamic filters and the following:

. Maybe we could change compression_opts to compression_kwargs for consistency with other places and other APIs

The wrapper H5DataIO has a compression_opts arguments already (that only works for gzip right now). We might want to have a different name for our argument at the level of neuroconv as there are things we want to modify (.e.g the allow_plugin_filters for dynamic filters for example) that are not properly conversion_opts. If we don't go for the simplification proposed here by @CodyCBakerPhD at least we should do as @bendichter suggests and go for compression_kwargs.

Finally, a lot of the arguments that I made above focus more on the perspective of maintance but we are also making a library that should be simple and usable.
I feel that modifying iterative write and compression strategies is an advance use of our library. We don't want our users to have to modify this most of the time. From that perspective, I am not too concerned about using a dictionary vs a flat sructure (passing just all the arguments at the top level).  However, what if they want, what would be easier for them? Given that this is difficult to answer empirically maybe at least we can follow some standard way of doing this by other libraries. Unortunately, there is not a lot of consitency in the scientific stack. Some relevant examples:
Scipy favors the current design in their optimize module. That is, their functions take a name (the strategy) and a set of arguments corresponding to them as a different keyword.
Scikit-learn module on the Gaussian Process  uses the "all information in one object" design. They define a kernel with all the relevant arguments and pass that object.
Pandas uses a very similar strategy to what @CodyCBakerPhD is proposing here for their to_csv function for handling compression options but use more of a flat passing of parameters in their to_sql function.
I really don't know what is better from a usability perspective, scientists tend to use flat inputs in their scripts in my experience (spikeinterface looks like that) where the top level function just takes all the arguments of everything in a flat way. I guess we definitley don't want to go there.

We should support this:
https://pynwb.readthedocs.io/en/stable/tutorials/advanced_io/h5dataio.html#dynamically-loaded-filters

@h-mayorquin I agree, given the downstream APIs, it makes sense to keep it as compression_opts.

that only works for gzip right now

Is that true? It shouldn't be. See PyNWB docs on DLFs.
This naming convention is also used by hdf5plugin:

They define a kernel with all the relevant arguments and pass that object. They use the strategy of one object.

I'd prefer this to a large dictionary. Classes have machinery for communicating and validating available args.

Pandas uses a very similar strategy to what @CodyCBakerPhD is proposing here for their to_csv function for handling compression options (one object strategy for compression)

Not really, compression takes a flat dict, not a nested dict.

Not really, compression takes a flat dict, not a nested dict.

I'm fine with a flat dict, too. I think he means its similar in how its a single argument that is a dict instead of unpacking each key-value pair in that dict as additional arguments

I'm fine with a flat dict, too. I think he means its similar in how its a single argument that is a dict instead of unpacking each key-value pair in that dict as additional arguments

well no one is advocating for that

Pandas uses a very similar strategy to what @CodyCBakerPhD is proposing here for their to_csv function for handling compression options (one object strategy for compression)

Not really, compression takes a flat dict, not a nested dict.

I was constrating pandas strategy to handle compression to the one that we have right now in neuroconv and the one that they have in scipy.optimze.
In Pandas they have:
compression={'method': 'gzip', 'compresslevel': 1, 'mtime': 1}.

That is, the function uses a single dictionary that has both the method name and the parameters instead of having both the method (compression) name and the arguments (compresion_opts) as different parameters of the function.

I like "compression" and "compression_opts". This is how it is done in: PyNWB, HDMF, hdf5plugin, and h5py.

They define a kernel with all the relevant arguments and pass that object. They use the strategy of one object.

I'd prefer this to a nested dict. Classes have machinery for communicating and validating available args.

@bendichter
I think at this point neither @CodyCBakerPhD or me want a nested dictionary. The strategies that I was constrating were the one where both compression and  compression_opts are used as separate keywords (as current neuroconv and scipy.optimize do) vs passing everything in a single object as a single keyword (in the examples above, scikit-learn does it with a class and pandas with a flat dict). That is, one vs two arguments for the specification of the compression strategies.
Ideally, I would like this to be a single object called whose esponsability is to instantiate the HFDataIO appropiately (the name of the keyword does not matter). The reason being, as you mention in the quote above, is that you can implement checks and relationships between the parameters in a coheisve way However, because this is more work and because most of those checks are done at the hdmf level I was fine with settling with a flat dict (which is like a very primitive data class in this context) but still a single object. That way if more checks are needed in our side or the definition of the strategy becomes more complex  we only need to change the dict for a class instead of changing both compression and compression_opts for an object.

I like "compression" and "compression_opts". This is how it is done in: PyNWB, HDMF, hdf5plugin, and h5py.
Fair enough, keeping consistency with the other libraries in our ecosystem is an important argument.

I like "compression" and "compression_opts". This is how it is done in: PyNWB, HDMF, hdf5plugin, and h5py.

We alias many arguments from upstream packages for enhanced user readability (in particular, expanding things like _opts into _options for less confusion over abbreviations), such as the file_path alias from neo/SI filename, path, and nwbfile_path alias from PyNWB path and h5py name. Point being, upstream argument names aren't always the best and consistency with those isn't something we tend to worry about since NeuroConv is intended to be the most user-friendly downstream tool (maybe one day, with the GUI, the only tool anyone has to use).
Two further points below, which count as separate issues but would be heavily influenced by these decisions...

Generalizing this to be compatible with Zarr compression
Another point to how even that choice of names is going to break down once we add Zarr support to NeuroConv (impending per request #202) - though there isn't much documentation for the ZarrDataIO yet, judging from its usage in the tests and its docval it doesn't look like it follows the same argument conventions (compressor: bool or Codec instead of compression: bool or str or hdf5plugin.Filter).
It also doesn't seem to allow options outside of the Codec object, which instead of that fancy dict casting instead must retrieve config via
from numcodecs import Blosc

compressor = Blosc(cname='zstd', clevel=3, shuffle=Blosc.BITSHUFFLE)
compressor.get_config()
>>> {'id': 'blosc', 'cname': 'zstd', 'clevel': 3, 'shuffle': 2, 'blocksize': 0}

which takes us back to the single-argument flat-dictionary approach that @h-mayorquin and I now support in favor; the aliasing for these cases would be compression_options["method"] == compressor.get_config()["id"] for Zarr and
compression_options["method"] == dict(hdf5plugin.SomeFilter)["compression"] for HDF5.
Now, the discussion about how to handle extra **method_options requires some more thought here. First, enabling dynamically loaded filters for NeuroConv can be done even on main by simply setting allow_plugin_filters=True by default, which I hope shouldn't harm anything even if the user never wants to use anything other than default. But that would allow them to pass either the compression=filter_id + compression_opts=dict(hdf5plugin.SomeFilter)["compression_opts"] or compression=hdf5plugin.SomeFilter directly if using NeuroConv via the API.

YAML representation of compression options
Another thing to think about as we make efforts to make things more and more YAML compatible in line with the upcoming GUI project, that second dynamically loaded filter usage  wouldn't be possible. It would also be annoying to ask the user to look up the integer ID for the filter, so we're already looking at doing some kind of aliasing on our end for convenience.
That is, what could work right now on main if we make that small aforementioned change, the following would work in YAML
conversion_options:
  SomeInterface:
    compression: 307
    compression_opts: 4

but it's rather unreadable. (What type of filter is that? What is the option name and what does a value of 4 mean?)
Though note this too would break if you wanted to specify more than one compression_opts (such as  the tuple that comes out of dict(hdf5plugin.SomeFilter)["compression_opts"] without adding some extra YAML machinery due to YAML difficulty in parsing Python tuples.
My point is it would be far more convenient to design this in one of two other ways
(i)
compression_options:  # this could also sit at a global level in the YAML if done this way
  method: gzip
  level: 4

whose keys beyond method are dynamically passed, or
(ii)
the original suggestion, whose first level is static and only the method_options level changes for each method
compression_options:  # this could also sit at a global level in the YAML if done this way
  method: blosc
  method_options:  # not required for all `method`s
    cname: zstd
    clevel: 3  # note we could do either 'clevel' or 'level' for consistency
    shuffle: Bit  # Small alias from the Enum classes for this, which is BITSHUFFLE

which now that I look at it again does actually have an additional benefit of allowing separate specification of another compression-related field, the Zarr filters which could be specified like
compression_options:  # this could also sit at a global level in the YAML if done this way
  filter: Delta
  filter_options:  # OK, not many filters have extra options (at least ones that we might want to suggest people use) but still possible
    ...
  method: blosc  # Note extra small aliasing for Zarr capitalization
  method_options:  # not required for all `method`s
    cname: blosclz
    clevel: 4
    shuffle: byte  # Small alias from the Enum classes for this, which is BYTESHUFFLE

I think at this point neither @CodyCBakerPhD or me want a nested dictionary.

I may be rethinking that w.r.t. the Zarr compression filters actually - they would get passed into the DataIO but they are also separate entities from the compression method itself. See bottom of part 2 of above post for YAML detailing.
What I absolutely would not want as we go forward into that case, is to add more and more arguments to the outer level of conversion_options. Like, I would not want compression, compression_opts, filter, filter_opts.
Another important thing to remember is this entire discussion isn't just about standardizing compression options, but also iterator options and soon after 'stub' options, which all follow this similar pattern. It's inflates our arguments to have stub, stub_options, compression, compression_opts, iterator_type, iterator_opts, filter, filter_opts. Seems much nicer, even safer as per points of https://github.com/catalystneuro/neuroconv/pull/272#issuecomment-1370154477 to keep each pair contained in a respective object.

@CodyCBakerPhD yes, I did not see your last point when I wrote, if you want to mantain the hierarchical structure in yaml then you needed the same in the signature.

Another point to how even that choice of names is going to break down once we add Zarr support to NeuroConv (impending per request https://github.com/catalystneuro/neuroconv/issues/202) - though there isn't much documentation for the ZarrDataIO yet, judging from its usage in the tests and its docval it doesn't look like it follows the same argument conventions (compressor: bool or Codec instead of compression: bool or str or hdf5plugin.Filter).

Yep, maybe the ZarrDataIO  shows that we are trying to follow the specific signature of H5DataIO too much, on the other hand, maybe ZarrDataIO should be similar to H5DataIO? not sure.

First, enabling dynamically loaded filters for NeuroConv can be done even on main by simply setting allow_plugin_filters=True by default,

Can't we just make allow_plugin_filters=True when compression (or compression_method) is one of the the ids ( blosc, bitshuffle, bzip2, FCIDECOMP, lz4, ZFP, zstd)?

Can't we just make allow_plugin_filters=True when compression (or compression_method) is one of the the ids ( blosc, bitshuffle, bzip2, FCIDECOMP, lz4, ZFP, zstd)?

It appears from the HDMF code that allow_plugin_filters isn't even used if the argument is a string and is one of the defaults that don't require hdf5plugin (note h5py_filters.encode=('gzip', 'lzf', 'shuffle', 'fletcher32', 'scaleoffset')) so it seems we could set it true without loss of generality. Otherwise, if anything, I'd flip it to True if it's not in the default offerings, which I mostly point out as it is at least conceptually possible that they could add additional filters to hdf5plugin in the future (or there could even be custom plugins like the ones holding up #222 and #221: https://github.com/catalystneuro/neuroconv/actions/runs/3830900364/jobs/6519358809) so it might be annoying for us to support a static list.
There also seem to be other more nuanced sets of conditions for whether or not the H5DataIO can actually use the filter beyond that point, so I say we may as well offload that logic to HDMF.


Installation failures.

I am trying to get bark up and running inside a fresh Ubuntu 18.04 vagrant box.
I think you should mention the
pip install virtualenv==16.0.0

In the FAQ about Python.h not found. Searching closed issues shouldn't be necessary for a
vanilla build.
Any how the thing ( bazel test //...) now fails here:
ERROR: /home/vagrant/bark/modules/models/behavior/motion_primitives/BUILD:1:1: C++ compilation of rule '//modules/models/behavior/motion_primitives:motion_primitives' failed (Exit 1) gcc failed: error executing command /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer '-std=c++0x' -MD -MF ... (remaining 412 argument(s) skipped)
Use --sandbox_debug to see verbose messages from the sandbox
In file included from ./modules/world/objects/agent.hpp:14:0,
                 from ./modules/world/world.hpp:19,
                 from ./modules/models/behavior/longitudinal_acceleration/longitudinal_acceleration.hpp:11,
                 from ./modules/models/behavior/idm/idm_classic.hpp:13,
                 from ./modules/models/behavior/idm/idm_lane_tracking.hpp:12,
                 from ./modules/models/behavior/motion_primitives/primitives.hpp:12,
                 from ./modules/models/behavior/motion_primitives/macro_actions.hpp:11,
                 from modules/models/behavior/motion_primitives/macro_actions.cpp:7:
./modules/world/goal_definition/goal_definition.hpp: In member function 'virtual const Polygon& modules::world::goal_definition::GoalDefinition::GetShape() const':
./modules/world/goal_definition/goal_definition.hpp:29:65: warning: no return statement in function returning non-void [-Wreturn-type]
     virtual const modules::geometry::Polygon& GetShape() const {}
                                                                 ^
In file included from ./modules/models/behavior/motion_primitives/macro_actions.hpp:11:0,
                 from modules/models/behavior/motion_primitives/macro_actions.cpp:7:
./modules/models/behavior/motion_primitives/primitives.hpp: In constructor 'modules::models::behavior::primitives::Primitive::Primitive(const ParamsPtr&, const DynamicModelPtr&)':
./modules/models/behavior/motion_primitives/primitives.hpp:51:19: warning: 'modules::models::behavior::primitives::Primitive::dynamic_model_' will be initialized after [-Wreorder]
   DynamicModelPtr dynamic_model_;
                   ^~~~~~~~~~~~~~
./modules/models/behavior/motion_primitives/primitives.hpp:50:9: warning:   'float modules::models::behavior::primitives::Primitive::integration_time_delta_' [-Wreorder]
   float integration_time_delta_;
         ^~~~~~~~~~~~~~~~~~~~~~~
./modules/models/behavior/motion_primitives/primitives.hpp:33:12: warning:   when initialized here [-Wreorder]
   explicit Primitive(const commons::ParamsPtr& params,
            ^~~~~~~~~
virtual memory exhausted: Cannot allocate memory
INFO: Elapsed time: 118.796s, Critical Path: 21.23s
INFO: 81 processes: 81 linux-sandbox.

Hi Ian,
we added the remark on the virtualenv version to installation instructions. Thanks, for the notice.
Your failure "virtual memory exhausted: Cannot allocate memory" has not come up yet during our builds. Likely, it has something to do with the vagrant box build.
1st Option: Reduce the number of parallel bazel build jobs with "bazel test //... --jobs=1". However, for the long run, long build times will be annoying
2nd Option: How is the swap space in the vagrant box configured? Try to set it to a reasonable amount.
Best
Julian

#316 Updated install.md

Gosh I didn't even see the memory exhaustion in amongst all the other chaff.
I was using 4GB of RAM, but with limiting the jobs to 1 it went through fine.
I will boost the RAM to 8GB and see if that helps.
Executed 44 out of 44 tests: 44 tests pass.
INFO: Build completed successfully, 430 total actions

With 8GB all the tests complete, and all but one pass.
//modules/benchmark/tests:py_benchmark_runner_tests                      FAILED in 10.2s
  /home/vagrant/.cache/bazel/_bazel_vagrant/b31675c09bcf797303603580e7679a6f/execroot/bark_project/bazel-out/k8-fastbuild/testlogs/modules/benchmark/tests/py_benchmark_runner_tests/test.log

Executed 44 out of 44 tests: 43 tests pass and 1 fails locally.

The log of the last test also has complaints that indicate memory issues.
So I will try again with 16GB.

16GB is a charm
Executed 44 out of 44 tests: 44 tests pass.

Okay, perfect. Then, I can close the issue for now?

Sure close it. Thanks for your help.
Sent from my iPhone

On Mar 18, 2020, at 7:06 AM, Julian Bernhard<EMAIL_ADDRESS>wrote:

Okay, perfect. Then, I can close the issue for now?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


psutil error when I am import from super_gradients.training import dataloaders

🐛 Describe the bug
When I am import dataloader from supergradient I am geeting this error:
Traceback (most recent call last):
File "/lustreFS/data/deepcamera/aloizou/HARESS/YOLO-NAS/train.py", line 16, in
from super_gradients.training import dataloaders
File "/trinity/home/aloizou/data/aloizou/miniconda3/envs/yolo_nas_env_test/lib/python3.10/site-packages/super_gradients/init.py", line 4, in
from super_gradients.training import losses, utils, datasets_utils, DataAugmentation, Trainer, KDTrainer, QATTrainer
File "/trinity/home/aloizou/data/aloizou/miniconda3/envs/yolo_nas_env_test/lib/python3.10/site-packages/super_gradients/training/init.py", line 2, in
import super_gradients.training.utils.distributed_training_utils as distributed_training_utils
File "/trinity/home/aloizou/data/aloizou/miniconda3/envs/yolo_nas_env_test/lib/python3.10/site-packages/super_gradients/training/utils/init.py", line 13, in
from super_gradients.training.utils.early_stopping import EarlyStop
File "/trinity/home/aloizou/data/aloizou/miniconda3/envs/yolo_nas_env_test/lib/python3.10/site-packages/super_gradients/training/utils/early_stopping.py", line 1, in
from super_gradients.training.utils.callbacks import PhaseCallback, Phase, PhaseContext
File "/trinity/home/aloizou/data/aloizou/miniconda3/envs/yolo_nas_env_test/lib/python3.10/site-packages/super_gradients/training/utils/callbacks/init.py", line 2, in
from super_gradients.training.utils.callbacks.callbacks import (
File "/trinity/home/aloizou/data/aloizou/miniconda3/envs/yolo_nas_env_test/lib/python3.10/site-packages/super_gradients/training/utils/callbacks/callbacks.py", line 29, in
from super_gradients.common.sg_loggers.time_units import GlobalBatchStepNumber, EpochNumber
File "/trinity/home/aloizou/data/aloizou/miniconda3/envs/yolo_nas_env_test/lib/python3.10/site-packages/super_gradients/common/sg_loggers/init.py", line 1, in
from super_gradients.common.sg_loggers.base_sg_logger import BaseSGLogger
File "/trinity/home/aloizou/data/aloizou/miniconda3/envs/yolo_nas_env_test/lib/python3.10/site-packages/super_gradients/common/sg_loggers/base_sg_logger.py", line 20, in
from super_gradients.common.environment.monitoring import SystemMonitor
File "/trinity/home/aloizou/data/aloizou/miniconda3/envs/yolo_nas_env_test/lib/python3.10/site-packages/super_gradients/common/environment/monitoring/init.py", line 1, in
from super_gradients.common.environment.monitoring.monitoring import SystemMonitor
File "/trinity/home/aloizou/data/aloizou/miniconda3/envs/yolo_nas_env_test/lib/python3.10/site-packages/super_gradients/common/environment/monitoring/monitoring.py", line 5, in
from super_gradients.common.environment.monitoring import disk, virtual_memory, network, cpu, gpu
File "/trinity/home/aloizou/data/aloizou/miniconda3/envs/yolo_nas_env_test/lib/python3.10/site-packages/super_gradients/common/environment/monitoring/disk.py", line 5, in
buffer_io_read_bytes = psutil.disk_io_counters().read_bytes
AttributeError: 'NoneType' object has no attribute 'read_bytes'
I tried also to remove it and install the latest version and I am still getting this error.
I am using a HPC for the training with TrinityX operating system
Versions
Collecting environment information...
PyTorch version: 2.1.0+cu121
Is debug build: False
CUDA used to build PyTorch: 12.1
ROCM used to build PyTorch: N/A
OS: Rocky Linux 8.5 (Green Obsidian) (x86_64)
GCC version: (GCC) 11.3.0
Clang version: Could not collect
CMake version: Could not collect
Libc version: glibc-2.28
Python version: 3.10.13 (main, Sep 11 2023, 13:44:35) [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-4.18.0-348.23.1.el8_5.x86_64-x86_64-with-glibc2.28
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True
CPU:
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              64
On-line CPU(s) list: 0-63
Thread(s) per core:  2
Core(s) per socket:  16
Socket(s):           2
NUMA node(s):        8
Vendor ID:           AuthenticAMD
CPU family:          25
Model:               1
Model name:          AMD EPYC 7313 16-Core Processor
Stepping:            1
CPU MHz:             3000.000
CPU max MHz:         3729.4919
CPU min MHz:         1500.0000
BogoMIPS:            6000.55
Virtualization:      AMD-V
L1d cache:           32K
L1i cache:           32K
L2 cache:            512K
L3 cache:            32768K
NUMA node0 CPU(s):   0-3,32-35
NUMA node1 CPU(s):   4-7,36-39
NUMA node2 CPU(s):   8-11,40-43
NUMA node3 CPU(s):   12-15,44-47
NUMA node4 CPU(s):   16-19,48-51
NUMA node5 CPU(s):   20-23,52-55
NUMA node6 CPU(s):   24-27,56-59
NUMA node7 CPU(s):   28-31,60-63
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 invpcid_single hw_pstate ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 invpcid cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr wbnoinvd amd_ppin arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold v_vmsave_vmload vgif v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid overflow_recov succor smca sme sev sev_es
Versions of relevant libraries:
[pip3] numpy==1.23.0
[pip3] onnx==1.13.0
[pip3] onnx-simplifier==0.4.35
[pip3] onnxruntime==1.15.1
[pip3] torch==2.1.0
[pip3] torchmetrics==0.8.0
[pip3] torchvision==0.16.0
[pip3] triton==2.1.0
[conda] numpy                     1.23.0                   pypi_0    pypi
[conda] torch                     2.1.0                    pypi_0    pypi
[conda] torchmetrics              0.8.0                    pypi_0    pypi
[conda] torchvision               0.16.0                   pypi_0    pypi
[conda] triton                    2.1.0                    pypi_0    pypi

Can you please run pip freeze and post it here? Looks like some psutil versions are not broken.
Possible duplicate: https://github.com/Deci-AI/super-gradients/issues/1247

Hello,
I did it and i am getting the same error again.

pip freeze is not meant to fix the problem. This command prints versions of all installed packages that help up understand what psutil version you have and from there figure out the fix

@aloizo03 I will assume it's a duplicate of https://github.com/Deci-AI/super-gradients/issues/1247
If you have can run pip freeze feel free to post it here, and we will see if it's really a duplicate or not.


Set up CORS

Coverage decreased (-2.0%) to 88.679% when pulling 351939386dfac58c52171d2ffee3fcae7af67fea on cors into 7aa37fc5b5c89c9fe1f2e7cd3de3037dfb5f658e on master.


Add debug messages

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

2 of 4 (50.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.3%) to 79.607%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/fis/core/ingest.py
2
4
50.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.3%

Covered Lines:
324

Relevant Lines:
407

💛  - Coveralls


FractionalOffset RTL

This satisfies the invariants we described in https://github.com/flutter/flutter/issues/11357
cc @abarth
It's too late for me to determine if this solution is idiotic or inspired, so I'll leave that up to you.

Discussed in person trying to create a center-based Alignment class instead.


Hacktoberfest 19

I have worked on tree traversal and Fibonacci.
I have read the guidelines but not able to understand how all of this works.

Hey! Thanks for contributing. It would be great if you could add issue number in your description.
Thanks

Issue #92 Tree traversal in python

Issue #93 Fibonacci in python


Types and "New" Objects

I'm confused about types and about creating objects and the "Hello, World" example.
import org.eolang.printed;
import org.eolang.string;
cli(
  printed(
    string("Hello, world!")
  )
)

If string is the name of the object (see comments here) how does the compiler know what type it is?
And the same question for cli and printed.

It would appear that the compiler would know the type based on the Type definition in org.eolang.string. string("Hello, world!") is a call to the object's constructor.

So there's already an object called string?
So is this also a valid program?
import org.eolang.printed;
import org.eolang.string;
cli(
  printed(
    string
  )
)

What would it do?

That would not be a valid program. You have to construct a string object before using it. You construct an object by naming the type of object and passing in any constructor args.
string("Bond, James Bond") is equivalent to "James Bond" or new String("James Bond") in Java.
cli(printed(string(""))) would be legal.
cli(printed(string("Hello, world!"))) would be legal.
cli(printed(string())) would not be legal. (no input args. objects always encapsulate something)
cli(printed(string)) would not be legal. (no string is being constructed)

"You construct an object by naming the type of object and passing in any constructor args."
But isn't the type String? (See comment here.)
(Sorry. I'm probably missing something.)

That might just be a Typo. I don't know whether it will ultimately be stringor String, or if both will work like in C#.

"@pa9ey I think String is a type and string is a name of the object."
How can that be a typo?

So the idea currently is, we have no classes.
You can create an object and you can copy a pre-existing one.
But, interestingly, this commit got rid of the copy keyword from the Hello, World example.
This reminds me of a previous conversation we had about getting rid of the new keyword.
If we want to get rid of new then it's no good replacing it with copy.
So I'm still thinking about how to make this work with the Hello, World example...

@pa9ey have you seen this syntax here?
What do you think about it?

@mdbs99 Yes, I have. I took a good look at it before I wrote some of my recent stuff.
Right now I'm not a huge fan of it, if I'm honest. It seems too cluttered and wordy. I want to be able to compose new objects (networks of objects) in a simple, readable, un-noisy style. (That's my feeling. Though I recognise I might be being naive.)
I'm not pretending that that's an easy or practical thing to do, or that I understand how you would do it. It's just something I'd like to aim for.

I'm imagining (again, perhaps naively) something like this:
var whatIWant = Thingamajig(
   Whatsit(
      Oojama("flip"),
      Thingama("bob")
   ),
   Doodah()
).Start("the magic");

Now if you imagine that, but with nice domain-y names rather than silliness, it's something like what I'm hoping for.
You can actually get this kind of thing in C++ if you create everything on the stack. But of course that's Class-based syntax...

@mdbs99 Sorry, I realise now I might be missing your point. My example just ignores all the "mess", which is hidden away in Class definitions somewhere. And we're obviously supposed to be doing away with those...
Maybe I'm just not a fan of the prototype idea yet. :grimacing:

@pa9ey nothing was defined yet. Just ideas.

@pa9ey I like the explanation given by @SilasReinagel above. We have types, which are literally Java interfaces -- this is clear. And we have objects, which can be created or copied. To create an object we have to define its body. To copy an object we have to use another object with different constructor arguments. Maybe I have to submit a pull request with this explanation and we'll discuss?

@yegor256 sounds good to me. Submit the explanation.

@yegor256 I think I'm slowly catching up. :)
So I guess it's true then that cli(printed(string)) is not valid. Correct?
That must be because string isn't an object in exactly the same sense as the object that is constructed by calling string("blah") is an object. string must be some sort of "template" that produces objects of that type. But this sounds very like the definition of a class, which is maybe why I was getting confused.
Could you say that string is an object of type Foo, and sending the constructor "message" to string produces an object of type String (whose implementation has been defined in the string object)?

@pa9ey not really. string is an object with, say, "Hello, world!" inside (or an empty string). You can use it directly or you can copy it. Make sense?

Oh boy, I'm confused. :grinning:
So this would be a valid program?
import org.eolang.printed;
import org.eolang.string;
cli(
  printed(string)
)

That's what I suggested originally, but @SilasReinagel said it wouldn't be and I thought you had agreed with him so I was trying to come up with other possibilities.
Anyway, I think my very first comment (with the edit) is now accurate.

@pa9ey yes, it's a valid code, however in our current syntax it will look like:
cli:
  printed:
    string

And it will print an empty string to console.
This one will print something else:
cli:
  printed:
    string:
      "Hello, world!"

What was your question again? :)

@yegor256 I think that's answered it now. :)
But the original point, which may have got a bit lost :smile:, was just an attempt to understand the Hello, world example. The last piece of the puzzle is that the cli object is presumably just always there and doesn't need importing.
I'll maybe submit a pull request to update the syntax and maybe add a bit of explanation.

@pa9ey take a look here.

string is valid, and empty string.
string("Hello world!") should be not valid, but string already created. string is immutable.
("Hello world") from string anonymous object? :)
@yegor256 you can explain this example? How define cli, printed, string? This is another syntax. :)
cli:
  printed:
    string:
      "Hello, world!"

@DronMDF

string is the name of an object, presumably of type String, that has been created in org.eolang.
The fact that we're passing in an argument means that we're actually constructing a new object by copying the existing one.
In a similar way printed is already exists as an object.
I think cli just automatically exists and doesn't need importing. (It also automatically executes itself.)

@pa9ey @DronMDF @mdbs99 check README and this 		2c95e8a

@yegor256 Nice! Really seeing the shape of it now. It might take me a while to get comfortable with all of it and I'm very intrigued to see if, practically, some of those ideas will work, but it's certainly something to get your teeth into.
And I've got a feeling you'll have this all up and running before I've fully worked out how to use GitHub... :sweat_smile:


Typescript Definitions?

Hey there,
would love to have some official typescript definitions for steemconnect :)

Me too


feat(smt): add smt crate

Description
Added the Sparse Merkle Tree (SMT) implementation in Rust.

Related Issue(s)
Closes: #8

Other information

Please do let me know if anything can be improved.

Checklist

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my code
[x] I have commented my code, particularly in hard-to-understand areas
[x] My changes generate no new warnings
[x] I have run yarn format and yarn compile without getting any errors
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes

Additional Questions

Need to add actual hash functions to test?

@0xjei Thanks for the review! As for the comment on using generics, do I implement it now or wait for further comments?

@0xjei Thanks for the review! As for the comment on using generics, do I implement it now or wait for further comments?

No need to implement it now.
Let's merge. @cedoor we need your approval too.
@curryrasul can make post merge comments. If necessary we ll implement other requests for changes later.
Thanks @waddaboo

@sripwoud thanks. Ready to be merged 👍🏽


Regen

Very sorry but I can't build it on my linux because my packages are too old. I can check it this evening though.

It's failing because the code got some new "extern crate" but the Cargo.toml was not updated. However those crates are actually not used, so shouldn't be there to begin with.
Also this update is "breaking" the versions in build.rs and Cargo.toml. It is removing some version features, which are there for consistency (everything has features for the major versions, 1.0, 1.2, 1.4, etc, independent of whether API was added or not... to make it simpler for users to select their required version without having to think/check).

I'll clean this PR this evening then. :)

Updated, sorry for the delay. There is still an issue remaining for the debug generation in gir (for cases like [c_int; 64], no Debug...).

This issue should be fixed by https://github.com/rust-lang/rust/pull/46445.

@sdroege: Fixed and updated.

See the warnings in the travis build. The ones I listed were only some of the many :)
https://travis-ci.org/sdroege/gstreamer-sys/jobs/310871268#L533
https://travis-ci.org/sdroege/gstreamer-sys/jobs/310871268#L541
https://travis-ci.org/sdroege/gstreamer-sys/jobs/310871268#L643

@sdroege: How come you see unused crates? I don't have any warnings or anything. :-/

I don't know why there's no warning, but nothing of those crates is used anywhere :)

That's so strange. (I updated btw.)

🎊


[Feature]: fibernewrelic - Update fiber.go for distribute tracing

create http.header from fiber context
assign  key Header when call SetWebRequest

@flukhiper thx for the effort
can you pls add some unittests for this change?

@flukhiper friendly ping

@flukhiper friendly ping


Where can i buy some namecoin? BitYep.com or Bitfinex?

I want keep some coins.Thanks!

Doesn't seem to have anything to do with Namecoin-Legacy.  See the Exchanges page on the website for this info.


2D samples to use GetCurrentviewpoint instead of MapView.Extent

@anttikajanus Could you please review the branch relating to this issue macca400/GetCurrentVP

Changes merged


feat: add ATLANTIS_EXECUTABLE_NAME and ATLANTIS_SILENCE_NO_PROJECTS envs.

what

Adding already available Atlantis flags to be used within helm deployments.

Adding ATLANTIS_EXECUTABLE_NAME  and ATLANTIS_SILENCE_NO_PROJECTS
why

These environments variables should be added as optional once they are available options for Atlantis.

tests

[x] I have tested my changes by deploying locally.

references

Atlantis official doc with this flags/envs.

@weslleycamilo can you bump the miner version, please? Thanks for the contribution

@weslleycamilo could you bump the version please? Thanks.


Update DWRandom.podspec

Going to merge this once I can get the linter to pass correctly, cocoapods needs to be configured to only use UIKit on iOS projects so this doesn't fail.


⚠ Bofrost.es has degraded performance

In f6df145, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1471 ms

Resolved: Bofrost.es performance has improved in 85a6d61 after 6 minutes.


Inconsistent Timer API

Describe the bug
Inconsistent Timer API. _txe_timer_change checks for system state, while other timer functions do not.
https://github.com/azure-rtos/threadx/blob/4e62226eeaf870827facbeef40bd1767db5cf9f0/common/src/txe_timer_change.c#L110
To Reproduce
Call _txe_timer_change  within  tx_application_define(). It will return TX_CALLER_ERROR
Expected behavior
It is possible to call _txe_timer_change  within tx_application_define() with success.
Impact
Inconsistent Timer API
Logs and console output
Not needed. Trivial to understand and reproduce.

Hi @OortJacek, please see the documentation for tx_timer_change here: https://learn.microsoft.com/en-us/azure/rtos/threadx/chapter4#tx_timer_change
Note that tx_timer_change is not allowed to be called from initialization (i.e. tx_application_define). I'm not sure why it can't be called from initialization, as it does work with some minor modifications to txe_timer_change. You can build with TX_DISABLE_ERROR_CHECKING defined (described here: https://learn.microsoft.com/en-us/azure/rtos/threadx/chapter2#detailed-configuration-options). This will allow you to call tx_timer_change from initialization.

Hi @goldscott

I'm not sure why it can't be called from initialization, as it does work with some minor modifications to txe_timer_change
That is why I'm asking to change the txe_timer_change as this constraint seems like a bug (legacy leftover).

Currently, I apply a patch that comments out this if statement, and it works fine, because why wouldn't it?

@goldscott Any further thoughts? Do you think it is possible to fix this unnecessary check?

Hi @OortJacek - we are looking into it. I'll reopen this ticket.


Fix GlobalExceptionHandler warning

Fix "Call to 'printStackTrace()' should probably be replaced with more robust logging" warning

Thanks for the PR


crash when I open my captured rdc file

Description
Crash when opening the RDC file I captured.
The place where the crash occurred is the following code：
Serialise_glPointParameteri（...）
{
...
if(IsReplayingAndReading())
{
GL.glPointParameteri(pname, param);///crash here
}
}
According to the stack information,It is replay “glPatchParameteriEXT“，then to Serialise_glPointParameteri.
The source code is：
case GLChunk::glPatchParameteriEXT:
case GLChunk::glPatchParameteriOES:
case GLChunk::glPointParameteri: return Serialise_glPointParameteri(ser, eGL_NONE, 0);
why glPatchParameteriEXT return Serialise_glPointParameteri(ser, eGL_NONE, 0);？
Instead of  Serialise_glPatchParameteri？
Steps to reproduce
open the rdc file I captured.(The rdc file contain "glPatchParameteriEXT" API)
Environment

RenderDoc version: Nightly builds  v1.x branch @ 9d3e4dc5, 2020-02-20
Operating System: android
Graphics API: gles

I don't see any link to the rdc file mentioned in your repro steps, please provide it so that your steps to reproduce can be followed.

You can just check in file "gl_driver.cpp" :
"case GLChunk::glPatchParameteriEXT:
case GLChunk::glPatchParameteriOES:
case GLChunk::glPointParameteri: return Serialise_glPointParameteri(ser, eGL_NONE, 0);"
Is it reasonable？
or need to be changed to
“case GLChunk::glPatchParameteriEXT:
case GLChunk::glPatchParameteriOES:
return Serialise_glPatchParameteri(ser, eGL_NONE, 0);
case GLChunk::glPointParameteri: return Serialise_glPointParameteri(ser, eGL_NONE, 0);“
I'm confused why you wrote that。

Your steps to reproduce say "open the rdc file I captured." but I don't have that capture file so I can't do that.
If you're reporting a bug please provide steps that I can follow to reproduce the problem so it can be investigated, if that happens when opening a capture file then please share the capture file.

You can just check in file "gl_driver.cpp" :
"case GLChunk::glPatchParameteriEXT:
case GLChunk::glPatchParameteriOES:
case GLChunk::glPointParameteri: return Serialise_glPointParameteri(ser, eGL_NONE, 0);"
Is it reasonable？
or need to be changed to
“case GLChunk::glPatchParameteriEXT:
case GLChunk::glPatchParameteriOES:
return Serialise_glPatchParameteri(ser, eGL_NONE, 0);
case GLChunk::glPointParameteri: return Serialise_glPointParameteri(ser, eGL_NONE, 0);“
I'm confused why you wrote that。

I also confused about there.I think it's a bug.

If you're encountering a crash then please provide a clear explanation of what the problem is and reproducible steps I can follow to replicate the crash and investigate the bug.

Closing this issue due to lack of repro steps and inactivity.


SEO-Friendly HTML Output

Since image text cannot be seen by search engines, I think a useful feature would be the ability to output SEO-friendly HTML for embedding the generated image.
If you agree, please assign me to the Issue and I will implement this. 😃
Feature Description
Passing an html=True param to img methods will output a .txt file containing an <img> tag. The title and alt properties will be generated using the text from header and para, respectively.
Example
from nider.models import Content
from nider.models import Header
from nider.models import Linkback
from nider.models import Paragraph
from nider.models import Image

header = Header('Your super interesting title!')
para = Paragraph('Lorem ipsum dolor sit amet.')
linkback = Linkback('foo.com | @username')
content = Content(para, header, linkback, padding=60)

img = Image(content, fullpath='result.png')

img.draw_on_bg('#212121', html=True)

Output
result.png
result.txt

result.txt
<img src="result.png" alt="Lorem ipsum dolor sit amet." title="Your super interesting title!" />

Hello! Thanks for sharing your ideas.
I thought about this for some time and that's what I have to say:

There is no need for generating a separate .txt file. Anyway user will later need to parse it in order to get the string.
Generating a full <img> tag is definitely not what someone will use:

You can't provide a correct src because it always will be relevant to the machine.
You almost always want to add some classes to <img> tags.

What would be cool to do is to add behavior that would add title and description attributes to the Image model, where Image.title = Header.text and Image.description = Paragraph.text so that later anyone can create their own <img> tags without worrying abou title and alt.

That’s a much better idea! I’d be happy to give it a go.
On Aug 12, 2017, 1:12 PM -0500, Vladyslav Ovchynnykov<EMAIL_ADDRESS>wrote:

Hello! Thanks for sharing your ideas.
I thought about this for some time and that's what I have to say:
• There is no need for generating a separate .txt file. Anyway user will later need to parse it in order to get the string.
• Generating a full  tag is definitely not what someone will use:
• You can't provide a correct src because it always will be relevant to the machine.
• You almost always want to add some classes to <img> tags.

What would be cool to do is to add behavior that would add title and description attributes to the Image model, where Image.title = Header.text and Image.description = Paragraph.text so that later anyone can create their own  tags without worrying abou title and alt.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Sure, you can give it a try. Waiting to see your pull request!

As an aside, incorporating alt text helps screen reader users like me! Untagged text-based images are not good for us, because the content of those images is completely inaccessible (aside from OCR, which is severely hit and miss)


Please provide an option to turn down the cloud drive

My daily work does not require cloud storage, so I uninstalled OneDrive. Please provide an option to close the cloud drive. Thanks.

They usually don't show up if there is no cloud drives installed

Merging with #3912


Support built-in variables

Some snippets from friendly-snippets rely on some built-in variables to be provided to work. For instance, the date snippet expands to ${CURRENT_YEAR}-${CURRENT_MONTH}-${CURRENT_DATE}. These used to work with LuaSnip as it provides those variables, but they don't work with nvim-snippets.
For reference, the list of variables VSCode supports is here: https://code.visualstudio.com/docs/editor/userdefinedsnippets#_variables

Hmm, never mind. This should be handled directly by vim.snippet.expand() but from what I can tell, it only recognises the TM_XYZ variables, not the other ones such as CURRENT_DATE 😞

Two important ones defined by the VSCode spec are $CLIPBOARD and $LINECOMMENT, which are included in a lot of snippets.

$UUID also maybe? I can't seem to expand the uuid snippet, whereas Luasnip cmp source expands it correctly.

I think they could simply be inserted before passing the snippet to vim.snippet.expand?

I wondered the same thing, but after looking at the code, I don't see any explicit call to vim.snippet.expand. Am I missing something obvious?

I wondered the same thing, but after looking at the code, I don't see any explicit call to vim.snippet.expand. Am I missing something obvious?
Yeah, I was confused too... I think the way it works is via the nvim-cmp source, which returns the snippets as LSP snippets, which neovim's LSP code now knows how to expand using vim.snippet.expand(). I could be wrong though 🤷🏻

From what I can tell, the built-in vars are defined here in luasnip: https://github.com/L3MON4D3/LuaSnip/blob/master/lua/luasnip/util/_builtin_vars.lua

Looking at the snippet.lua source code, TM_SELECTED_TEXT is also currently not supported since the builtin snippet code only works in insert mode.

Variables are handled by vim.snippet.
Someone should create a PR in core for https://github.com/neovim/neovim/blob/master/runtime/lua/vim/snippet.lua#L24

Looks straightforward, I can make a PR later today

Looks straightforward, I can make a PR later today

Right now, vim.snippet doesn't support TM_SELECTED_TEXT because (as the comment says), -- Snippets are expanded in insert mode only, so there's no selection.
I don't understand that. Can't a snippet begin by hitting <Tab> in select mode? In any case, it may be worth trying to get support for TM_SELECTED_TEXT into vim.snippet.

this seems already have been rejected by neovim sometime ago, is there a way to implement it here? https://github.com/neovim/neovim/pull/27375

One other thing worth noting: after a little trial and error, vim.snippet does not seem to support things like this: ${1:$TM_FILENAME_BASE}. As a result, even for variables that vim.snippet supports, some of the snippets in friendly-snippets will be broken.

Looking at https://github.com/L3MON4D3/LuaSnip/blob/master/lua/luasnip/util/_builtin_vars.lua I should be able to bring that logic over and do something similar. So I would handle expanding variables in the plugin prior to expanding the snippet with vim.snippet.

I have made a PR to neovim core, adding all the missing variables from the VSCode spec: https://github.com/neovim/neovim/pull/28949. (The PR only covers the missing variables, it does not deal with cases like ${1:$TM_FILENAME_BASE}.)
Haven't made a PR to core yet, so anyone with more experience is welcome to take a look whether I got everything right.
In the meantime, you can manually path the resolve_variables function with the updated function from my PR, if you want to have support for the missing variables right now.

Well, turns out the VSCode snippet spec differs from the LSP snippet spec, which is why those variables will not be included in core 😔 https://github.com/neovim/neovim/pull/28949#issuecomment-2127997756
I guess porting over the Luasnip logic as suggested by @garymjr is the way to go then

Initial variables support has been added in #21. There's few variables I still need to figure out how to support, but this covers a majority of them.

Remaining variables should all be covered in #22. I'll leave this issue open for now as a place to discuss any possible regressions or missing variables.

@garymjr This is terrific—thanks!
I see one missing variable, but it is kind of an edge case. At the moment, you don't handle TM_SELECTED_TEXT.
Technically, vim.snippet supports this variable, but their implementation is effectively a no-op. I explain this in too much detail in an earlier comment, but basically vim.snippet always returns an empty string or a default variable if one is given. There's no attempt to use the currently selected text for the body of the snippet.
If you want to see other versions, LuaSnip seems to handle this variable in util/select.lua, and nvim-snippy in snippy/shared.lua.

@garymjr thank you!
One issue I noticed is that the variable expansion only works when using ${LINE_COMMENT}, but not when using $LINE_COMMENT. At least in the VSCode spec, both are valid

At least in the VSCode spec, both are valid

In the overall LSP spec as well: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#variables

With #26 I'm now using the same logic as vim to parse snippets so both "$" and "${}" should be getting matched now. Also #27 adds support for TM_SELECTED_TEXT variable. I tried to match the logic of luasnip as close as possible, but since we're not handing the actual expansion of the snippet I had to handle it slightly different. Let me know if you see any issues with it.

works like a charm!
I think a minor issue left is that $CLIPBOARD uses the " register and not the + register. I personally think the latter is preferable, as one use case of $CLIPBOARD is to enter things copypasted from outside vim (such as a URL copied from the browser).

Regarding $CLIPBOARD maybe vim.v.register could be used, which by default is set to " unless clipboard = unnamedplus is used from the user in which case the + will be used instead.

I ended up going with @dpetka2001's idea and used vim.v.register to determine which register to use for $CLIPBOARD. I think this should get variable support in a good state. Unless anyone sees any remaining issues with variables I'll close this issue as completed.

Snippets like the following don't seem to expand properly for me: ${1:${TM_SELECTED_TEXT:text}}.
The problem here, I think, is that if the built-in variable is the default text for a tab stop, and the built-in variable itself has default text, then neither the built-in variable or its default text is used. Instead, the tab stop is empty (as if there were no defaults).
I think that this is a valid snippet, but I'm not sure whether the built-in vim.snippet supports nested defaults like this yet (or whether it will ever?). In any case, I discovered the problem in one of my own snippets, but I took the example from the LaTeX snippets in friendly-snippets. There don't seem to be a ton of examples like that in friendly-snippets, but there are definitely some in latex.json and asciidoc.json.

@telemachus this should be fixed in #34

@garymjr Thanks, but I think it's not quite there. If you have a snippet body like this: ${1:${TM_SELECTED_TEXT:hello}} ${2:cruel} ${3:world} !$0, the returned item seems to still have an extra : at the front and } at the end. In other words, the result of your utils.expand_vars looks like this: ${1::hello}} ${2:cruel} ${3:world} !$0.
Sorry that this is all such a pain. (It's annoying that we have to semi-parse snippets before giving them to vim.snippet.expand to parse again.) I can try to look at this in the next few days or over the weekend.

@garymjr I looked more closely at #34. The problem is the gsub call here:
local function resolve_variable(input, name, replacement)
	return input:gsub("%$[{]?(" .. name .. ")[}]?", replacement)
end

Sometimes replacement is an empty string. (For example, TM_SELECTED_TEXT and TM_FILENAME{_BASE} can be empty.) If the replacement is empty, then an original like ${1:${TM_SELECTED_TEXT:hello}} becomes ${1::hello}}.
The problem is somewhat complicated. You have to do different things depending on whether the replacement string is empty or not. Also, as I mentioned above, vim.snippet doesn't currently seem to support things like ${1:${TM_FILENAME:placeholder}}. You may want to revert #34 and wait to see how vim.snippet develops.
If you want to try something more complex, let me know.

Agreed. Thanks for digging into this some more as well. I'm currently working on a better solution, but it's requiring me to walk through the parsed parts to determine the action I should perform. This means I need to walk through each placeholder and rebuilding the snippet at the end to retain all the expected tabstops.

Right: I looked at this over the weekend, and...it's a pain. Here's about as far as I got.

Things like $TM_SELECTED_TEXT or ${1:$TM_SELECTED_TEXT} are easy. You just replace $TM_SELECTED_TEXT with its replacement string. (If the replacement string is empty, so be it.)
Things like ${1:${TM_SELECTED_TEXT:default}} are not easy. First, you have to figure out what would replace TM_SELECTED_TEXT. If the replacement is an empty string, then you want to promote the inner default to the default for the whole tabstop. (I.e., ${1:${TM_SELECTED_TEXT:default}} should become ${1:default}.) If the replacement is not an empty string, then you want to make that the simple default for the tabstop. (I.e., ${1:${TM_SELECTED_TEXT:default}} should become ${1:whatever}—assuming that TM_SELECTED_TEXT is whatever.)

But it's around at this point that you realize you almost need to write an entire snippets parser only to hand the resolved text to vim.snippets.expand—which will immediately start parsing the snippets again. I wish that Neovim core would consider something like this pull request. Snippet plugins that build on top of vim.snippet need access to some sort of callback to get at values as vim.snippet parses them.

@garymjr I think that according to the LSP spec and neovim's roadmap, vim.snippet.expand should already support things like ${1:${TM_FILENAME:placeholder}}. So I opened an issue for that. You may want to wait to see how that goes.
https://github.com/neovim/neovim/issues/29169


[T4A2][T15-A1]Zhou Fanyi

ready for review

@fanyiii
Some comments added. Please ack & close the PR after reading comments.


Add a toolbar button for cancelling deployment

Currently, when a cloud deployment is selected in the servers tree and is executing, there is no toolbar button to cancel it.
With #581 resolved, the user can cancel the deployment via the server disconnect button, but that require navigating up the tree to the server, away from the deployment node, which is not intuitive.

Since we were unable to find an elegant way to implement this with the available plugin APIs, we're putting this on hold.


Unexpected flight termination

Describe the bug
We were flying a mission with our coaxial octocopter, v1.10.1. Suddenly the motors were stopped and the copter fell from 120m altitude. I have been looking the reason at the logs but did not found anything yet. Could any body help here. Could be a problem with the firmware?
To Reproduce
Nothing special. In mission mode all the motors stopped and automatically from mission mode, freefall not detected, to position mode.
Log Files and Screenshots
The logs are available here.
https://review.px4.io/plot_app?log=44fcd17a-694d-431e-a02f-74c51f8d3cda
Drone (please complete the following information):
Coaxial Octocopter, Pixhawk 4, Here+ 2.
Additional context
We implemented some changes on the original v1.10.1. We are testing a dual redundant smart battery. Therefore we have changed the original smbus driver.
Anyway the copter has been flying around some time with this battery, I really do not know what happened here.

Sorry to read that.
The vehicle did disarm in-flight, while still in mission (shortly before switching to position mode), but I do not see why. It's not RC, not landed and no vehicle command.

Hi @bkueng,
thanks for your help. It saw in the logs, the vehicle enter in the maybe landed and landed condition but no frefall detected.
I had several ideas but none of them could explain this.

CPU overloaded, could this be? There is a peak just before everything happened.
Could be vibrations?

Could be this?
https://github.com/PX4/Firmware/issues/11683

Are all those CUV or apparently "undervoltage protection" warnings expected?
It's first disarming, then detecting landed

Why is there no disarm message? 🤔 :

@kuiskas Do your changes contain anything in commander and maybe arming_state_transition(... , vehicle_status_s::ARMING_STATE_STANDBY, ...); ? Just to rule it out.

Hi thank you all for you help here.
here there is a log from 2 days before the crash, with the same setup:
https://review.px4.io/plot_app?log=77a28b5c-f171-4f2c-8fc3-a98fa2beadf6
Later that day I flew a mission without problems. But I had the SD_LOG parameter set to from boot until disarm.
The CUV it is expected, it is a glitch in the smbus communication.  It means cell undervoltage detected.
From Commander we did not changed anything.
Normally when landed and disarm we just get:

Another thing we changed. The max number  of task in nuttx.
In our setup we were using 4 mavlink instances. USB instance + 3 for telemetry and peripherie. So we increased the max number of task to 64 as in the newer firmware.
We did this because neither mavlink shell console nor the logger were working when this nunmber was 32 task. We had in total 33 task running.

Could the logger be wrong and the disarm occurred after the landing state?
Any clue why is not detected a freefall?


Web build (experimental)

With version 4.0 Isar is getting back web support. What if...
Based in #184.
Issues at the moment:

[ ] can't make http request on firefox because of CORS something something
[ ] on chromium only the favicon check fails, it is possible to login
[ ] Isar watcher are not working on web (because of the lack of persistence?) so the app is just crashing on /

TODO

[x] build and deploy on github pages
[x] add a BIG warning about the experimental nature of this build with bells and whistle on the login screen

Deprecated by #233


Adds initial version of an init command

Will currently install a Roc "base" from Github

We need to write some documentation on how the command works and how a "base" is structured in the future.

Exitcodes can be discussed. I think we need to be 100% sure on how file deletes are handled before merging. Prompting user with y/n is probably the best.
Otherwise looks like a good start, loving the github integration :)

Now handles all of the files in a temp directory before they finally are moved to the current working directory. This means that there will not be any issues in relation to file deletions.


Feat/183(404 error page)

showing the error page base on the page status code  and error message

@SOSJ001 can we also add a link to home page when we get an error?
it's not too urgent so no stress

LGTM!!

What's does this mean 😄?
I have no idea


Add Support for Alpha Formats

Unfortunately, I think this feature is a bit too complex for video-rs. I requires a lot of custom handling throughout to make it work. It would be great if there were some ergonomic way of supporting more pixel formats both for decoding and encoding, and if there's a design that works, then implementing this would be easier.

Unfortunately, I think this feature is a bit too complex for video-rs. I requires a lot of custom handling throughout to make it work. It would be great if there were some ergonomic way of supporting more pixel formats both for decoding and encoding, and if there's a design that works, then implementing this would be easier.

So I agree that it'd be nicer to have a robust method for handling encode / decode formats, but I disagree that this PR is adding much more complexity to the existing approach. Conceptually, it's just extending the existing hard-coded format so it doesn't throw away a channel of useful data where applicable, and would be no more difficult to replace with a well thought out pixel format selection design at a later stage.
That said, I can see where you're coming from with wanting to hold off - there's always overhead with reviewing, testing, releasing, etc. I'll probably end up switching directly to the ffmpeg bindings, as I'll likely need more flexibility than this library is likely to be able to provide in the future.

So I agree that it'd be nicer to have a robust method for handling encode / decode formats, but I disagree that this PR is adding much more complexity to the existing approach. Conceptually, it's just extending the existing hard-coded format so it doesn't throw away a channel of useful data where applicable, and would be no more difficult to replace with a well thought out pixel format selection design at a later stage.

I think most of the complexity is in the unexpected changes to pixel format in many places without the user knowing. I agree the PR itself is not problematic, it's just there's no way to do this correctly due to the hardcoded pixel format currently.

That said, I can see where you're coming from with wanting to hold off - there's always overhead with reviewing, testing, releasing, etc. I'll probably end up switching directly to the ffmpeg bindings, as I'll likely need more flexibility than this library is likely to be able to provide in the future.

Yeah that makes sense. The aim of this library is mostly for simple use cases and there's a lot abstraction


AxiosResponse Inside AxiosResponse

This is maybe an error on my side.
But for some reason the result type of trigger is an AxiosResponse inside an AxiosResponse.
export function UserAuthForm({ className, ...props }: UserAuthFormProps) {
    const { trigger, isMutating } = useLoginForAccessTokenAuthPostRequest();

    const form = useForm<z.infer<typeof formSchema>>({
        resolver: zodResolver(formSchema),
        defaultValues: {
            username: "",
            password: "",
        },
    });

    async function onSubmit(values: z.infer<typeof formSchema>) {
        try {
            // According to the types this is a AxiosResponse<AxiosResponse<Token, any>, any> | undefined
            // But it is actually a AxiosResponse<Token, any> | undefined
            const result = await trigger({ body: { username: values.username, password: values.password } });

            if (!result) {
                throw new Error("No response");
            }
            console.dir(result);
            console.dir(result.data);
            // This does not work because the types are wrong
            const { access_token } = result.data.data;

This is my openAPI.json if you want to try
openAPI.txt

You may used wrong useMutationRequest function, the type returned by trigger should be controlled by useMutationRequest function, you can refer to example folder to get more details.


virtual scroll

Can I support virtual scrolling? Or is there a virtual scrolling plug-in recommended for use together,

This one looks pretty good: https://github.com/p-baleine/vue-draggable-virtual-scroll-list

This one looks pretty good: https://github.com/p-baleine/vue-draggable-virtual-scroll-list

sadly it's not for vue3

still no virtual scrolling added?


[#541] Integrate the Twitter Jetpack Compose Rules Detekt plugin

closes #541
What happened 👀

Added the compose-rules detekt plugin
Updated detekt-config.yml
Added kotlinx.collections.immutable dependency and updated UI lists to use ImmutableList

Insight 📝

As the Twitter compose-rules detekt plugin seems abandoned, we should instead use a forked version from one of the original maintainers which is being actively worked on 🙏🏻
Because compose treats all instances of Collection (i.e., List, Set, etc.) as unstable, we should update all UI usages of collections to use their ImmutableX counterpart to reduce unnecessary recomposition.

Reference: https://medium.com/androiddevelopers/jetpack-compose-stability-explained-79c10db270c8

We have added ignoreAnnotated: [ 'Preview' ] to the MagicNumber rule as preview composables typically contain hard-coded values and we don't want these to be flagged 👀

Proof Of Work 📹
With incorrect composable name (homeScreenContent), public @Preview and unstable lists:
ryanconway@Ryans-MacBook-Pro-13-2020-Nimble template-compose % detekt

> Task :detekt
.....................................................

53 kotlin files were analyzed.
/Users/ryanconway/Projects/Nimble/android-templates/template-compose/app/src/main/java/co/nimblehq/template/compose/ui/screens/home/HomeScreen.kt:41:13: Composable functions that return Unit should start with an uppercase letter.
They are considered declarative entities that can be either present or absent in a composition and therefore follow the naming rules for classes.

See https://mrmans0n.github.io/compose-rules/rules/#naming-composable-functions-properly for more information. [ComposableNaming]
/Users/ryanconway/Projects/Nimble/android-templates/template-compose/app/src/main/java/co/nimblehq/template/compose/ui/screens/home/HomeScreen.kt:62:5: Composables annotated with @Preview that are used only for previewing the UI should not be public.

See https://mrmans0n.github.io/compose-rules/rules/#preview-composables-should-not-be-public for more information. [PreviewPublic]
/Users/ryanconway/Projects/Nimble/android-templates/template-compose/app/src/main/java/co/nimblehq/template/compose/ui/screens/home/HomeScreen.kt:43:15: The Compose Compiler cannot infer the stability of a parameter if a List<UiModel> is used in it, even if the item type is stable.
You should use Kotlinx Immutable Collections instead: `uiModels: ImmutableList<UiModel>` or create an `@Immutable` wrapper for this class: `@Immutable data class UiModelsList(val items: List<UiModel>)`

See https://mrmans0n.github.io/compose-rules/rules/#avoid-using-unstable-collections for more information. [UnstableCollections]

/Users/ryanconway/Projects/Nimble/android-templates/template-compose/app/src/main/java/co/nimblehq/template/compose/ui/screens/home/HomeScreen.kt - 35min debt
        ComposableNaming - [Composable functions that return Unit should start with an uppercase letter. The(...)] at /Users/ryanconway/Projects/Nimble/android-templates/template-compose/app/src/main/java/co/nimblehq/template/compose/ui/screens/home/HomeScreen.kt:41:13
        PreviewPublic - [Composables annotated with @Preview that are used only for previewing the UI sho(...)] at /Users/ryanconway/Projects/Nimble/android-templates/template-compose/app/src/main/java/co/nimblehq/template/compose/ui/screens/home/HomeScreen.kt:62:5
        UnstableCollections - [The Compose Compiler cannot infer the stability of a parameter if a List<UiModel(...)] at /Users/ryanconway/Projects/Nimble/android-templates/template-compose/app/src/main/java/co/nimblehq/template/compose/ui/screens/home/HomeScreen.kt:43:15

Overall debt: 35min

Compose - 35min debt
        ComposableNaming - [Composable functions that return Unit should start with an uppercase letter. The(...)] at /Users/ryanconway/Projects/Nimble/android-templates/template-compose/app/src/main/java/co/nimblehq/template/compose/ui/screens/home/HomeScreen.kt:41:13
        PreviewPublic - [Composables annotated with @Preview that are used only for previewing the UI sho(...)] at /Users/ryanconway/Projects/Nimble/android-templates/template-compose/app/src/main/java/co/nimblehq/template/compose/ui/screens/home/HomeScreen.kt:62:5
        UnstableCollections - [The Compose Compiler cannot infer the stability of a parameter if a List<UiModel(...)] at /Users/ryanconway/Projects/Nimble/android-templates/template-compose/app/src/main/java/co/nimblehq/template/compose/ui/screens/home/HomeScreen.kt:43:15

Overall debt: 35min

Complexity Report:
        - 1,201 lines of code (loc)
        - 915 source lines of code (sloc)
        - 544 logical lines of code (lloc)
        - 22 comment lines of code (cloc)
        - 86 cyclomatic complexity (mcc)
        - 19 cognitive complexity
        - 3 number of total code smells
        - 2% comment source ratio
        - 158 mcc per 1,000 lloc
        - 5 code smells per 1,000 lloc

Project Statistics:
        - number of properties: 145
        - number of functions: 53
        - number of classes: 32
        - number of packages: 23
        - number of kt files: 53

Successfully generated Checkstyle XML report at /Users/ryanconway/Projects/Nimble/android-templates/template-compose/build/reports/detekt/detekt.xml
Successfully generated plain text report at /Users/ryanconway/Projects/Nimble/android-templates/template-compose/build/reports/detekt/detekt.txt
Successfully generated HTML report at /Users/ryanconway/Projects/Nimble/android-templates/template-compose/build/reports/detekt/detekt.html
Successfully generated SARIF: a standard format for the output of static analysis tools at /Users/ryanconway/Projects/Nimble/android-templates/template-compose/build/reports/detekt/detekt.sarif
Successfully generated Markdown report at /Users/ryanconway/Projects/Nimble/android-templates/template-compose/build/reports/detekt/detekt.md

BUILD SUCCESSFUL in 15s
5 actionable tasks: 1 executed, 4 up-to-date

With fixes applied:
ryanconway@Ryans-MacBook-Pro-13-2020-Nimble template-compose % detekt

> Task :detekt
.....................................................

53 kotlin files were analyzed.
Complexity Report:
        - 1,203 lines of code (loc)
        - 917 source lines of code (sloc)
        - 544 logical lines of code (lloc)
        - 22 comment lines of code (cloc)
        - 86 cyclomatic complexity (mcc)
        - 19 cognitive complexity
        - 0 number of total code smells
        - 2% comment source ratio
        - 158 mcc per 1,000 lloc
        - 0 code smells per 1,000 lloc

Project Statistics:
        - number of properties: 145
        - number of functions: 53
        - number of classes: 32
        - number of packages: 23
        - number of kt files: 53

Successfully generated Checkstyle XML report at /Users/ryanconway/Projects/Nimble/android-templates/template-compose/build/reports/detekt/detekt.xml
Successfully generated plain text report at /Users/ryanconway/Projects/Nimble/android-templates/template-compose/build/reports/detekt/detekt.txt
Successfully generated HTML report at /Users/ryanconway/Projects/Nimble/android-templates/template-compose/build/reports/detekt/detekt.html
Successfully generated SARIF: a standard format for the output of static analysis tools at /Users/ryanconway/Projects/Nimble/android-templates/template-compose/build/reports/detekt/detekt.sarif
Successfully generated Markdown report at /Users/ryanconway/Projects/Nimble/android-templates/template-compose/build/reports/detekt/detekt.md

BUILD SUCCESSFUL in 2s
5 actionable tasks: 1 executed, 4 up-to-date

Don't we need to apply these changes to sample @ryan-conway ?

@ryan-conway Conflict 😶🌫

IMO, the unstable list should be handled in another PR instead. This PR is about to update the Jetpack Compose Rule. 🤔 Please correct me if I'm wrong. 🙇🏻

Don't we need to apply these changes to sample @ryan-conway ?

@kaungkhantsoe Updated in bfda1aa

IMO, the unstable list should be handled in another PR instead. This PR is about to update the Jetpack Compose Rule. 🤔 Please correct me if I'm wrong. 🙇🏻

@lydiasama That's a fair point, but since these are new rules introduced in this task it made sense to me to handle them here as well instead of opening another task, what do you think? 🤔


Change structure of pvi PV

At the moment we have a structure like:
$ pvget -v BL45P-MO-PANDA-01:TTLOUT1:PVI
BL45P-MO-PANDA-01:TTLOUT1:PVI structure
    structure record
        structure _options
            boolean atomic true
    structure pvi
        structure label
            string rw BL45P-MO-PANDA-01:TTLOUT1:LABEL
        structure val
            string rw BL45P-MO-PANDA-01:TTLOUT1:VAL
        structure val_delay
            string rw BL45P-MO-PANDA-01:TTLOUT1:VAL:DELAY

Which is very different from the underlying records:
$ pvget -v BL45P-MO-PANDA-01:TTLOUT1:VAL
BL45P-MO-PANDA-01:TTLOUT1:VAL epics:nt/NTScalar:1.0
    string value ZERO
    alarm_t alarm
        int severity 0
        int status 0
        string message
    time_t timeStamp 2024-06-08 15:34:04.600
        long secondsPastEpoch<PHONE_NUMBER>
        int nanoseconds 600281953
        int userTag 0
    structure display
        string description TTL output value

It would be nicer to have value, alarm and timeStamp, and give it a structure ID. I suggest we do this:
$ pvget -v BL45P-MO-PANDA-01:TTLOUT1:PVI
BL45P-MO-PANDA-01:TTLOUT1:PVI epics:nt/NTPVI:1.0
    structure value
        structure label
            string rw BL45P-MO-PANDA-01:TTLOUT1:LABEL
        structure val
            string rw BL45P-MO-PANDA-01:TTLOUT1:VAL
        structure val_delay
            string rw BL45P-MO-PANDA-01:TTLOUT1:VAL:DELAY
    alarm_t alarm
        int severity 0
        int status 0
        string message
    time_t timeStamp 2024-06-08 15:34:04.600
        long secondsPastEpoch<PHONE_NUMBER>
        int nanoseconds 600281953
        int userTag 0
    structure display
        string description PVs making up Interface for TTLOUT1

This would require:

Some structure to get the metadata into the root. Something like this when the first call to add_pvi_info_to_record happens:

        pvi_pv = f"{block}:PVI"
        description = builder.StringOut(
            pvi_pv + ":DESCRIPTION",
            initial_value=f"PVs making up Interface for {block}",
        )
        description.add_info(
            "Q:group",
            {
                pvi_pv: {
                    "+id": "epics:nt/NTPVI:1.0",
                    "display.description": {"+type": "plain", "+channel": "VAL"},
                    "": {"+type": "meta", "+channel": "VAL"}
                }
            },
        )

https://github.com/PandABlocks/PandABlocks-ioc/blob/8e25d64cc97cfbf242a84c6ccbe600a39ed41c41/src/pandablocks_ioc/_pvi.py#L63 to start with value. not pvi.

To be done after the June experiment is finished


Deleting last view referencing a buffer should delete the buffer

Ensure that a buffer is deleted when the last view referencing it is deleted.  This is the current design, and unit tests exist to make sure this is happening, but some of the code paths that result in Group deletion may not properly exercise this.  There are two separate functions: destroyView() and a destroyViewAndData(): Group::~Group() only calls the first one.
Add tests as appropriate and clarify the Doxygen (and if necessary the Sphinx docs).

Before acting on this issue, I would like to have a little more discussion.
Is "delete Buffer when deleting last attached View" the right design?
We can create (unattached) Buffers and fill them with data, then create Views and describe the Buffers.  This issue would seem to forbid the converse, forbidding to return to a Buffer with no Views attached.  Increasingly, it seems to me that destroying a View is orthogonal to destroying a Buffer.
An excerpt from group.rst in the Sphinx docs, which seem to reflect conscious design choice: to separate destroying Views and Groups:

Destroy Views
^^^^^^^^^^^^^^

Destroy View with given id (child), or name/path (View in the Group or some
descendant Group), and leave View data intact.
Destroy all Views in the Group, and leave their data intact.
Destroy View with given id, or name/path, and destroy their data.
Destroy all Views in the Group and destroy their data

I do think there are important cases when destroying a view is orthogonal to destroying the data.
I think the surprise in this case was someone wanting to make sure (or receive an error message if its not possible) that buffers were cleaned up when deleting a group.
Not sure what to suggest. Is the hole that we don't have a Group level: destroyGroupAndData()  that descends to child data?

@agcapps @cyrush I recently added a new section to the docs that should help clarify the design choices and behavior: https://axom.readthedocs.io/en/develop/axom/sidre/docs/sphinx/data_vs_metadata.html
Also, I added an issue to address @cyrush 's last comment: https://github.com/LLNL/axom/issues/674
After that is done, will that resolve this issue?

Addressed with additional methods and documentation.


Incorrect week number for weekly notes when using 'WW' format

Having default format for weekly notes gggg-[W]ww creates a new weekly note with correct name: 2022-W51.
However if I change the format to gggg-[W]WW , I'm getting a note with name 2022-W49, whereas in settings the current syntax is displayed correctly in both cases.

Obsidian 1.0.3

Oh my goodness that is the problem with my weekly notes. I figured there was something worng with the calender extention. Changed my weekly notes format to YYYY/MM_MMM/YYYY-[W]ww and now they work as expected. Not sure why but I had YYYY/MM_MMM/YYYY-[W]W previously, but I just tested it and the capital W or WW does not output the correct week, both w and ww work as expected.

Thanks for pointing this out! I was having a hard time figuring out why the calendar visual and templates were also not lining up. Using local week numbering [w] instead of ISO week numbering [W] in the templates matches what the calendar visual shows.


README.md: add CI coverage

Signed-off-by: zhangjinpeng1987<EMAIL_ADDRESS>

duplicated with https://github.com/tikv/agatedb/pull/147


Fidel Scrollbar

Implement the following scrollbar:

This is currently blocked by https://github.com/flutter/flutter/issues/80370

I just published a new version (1.9.0) that improves the fidelity of the scrollbar. Now, only the arrows are missing. There currently no way to use widgets in the scrollbar, and there aren't the leading and trailing properties.
This is still blocked by the issue mentioned above.

About Win UI 3.0 scrollbar, this issue is still blocked by https://github.com/flutter/flutter/issues/80370 and https://github.com/flutter/flutter/issues/97876