What is state of MIDI take? State of API and what to use right now?

I'm not sure of how things are going with MIDI, especially with MIDI-Take right now. From the one side — I see no clean «that is MIDI» API in medium-level. From the other side, reaper-high builds some docs for helgoboss-midi which look from the first side like a deep dive into the API.
And, if with reaper API itself for the current moment, I've taken a strategy of:

using of reaper-medium
using of as fewer functions as possible. (for example, I've built my own class for TimeLine just to be free of reaper execution)
hold them in separate glue layer of architecture
implement medium-level as soon as I need some functional

But the question of working with MIDI-Take is not small: last time I solved this problem, it took about of a week.
It's not so "technical", as major of functionality of reaper functions. And I can build some code, that would be useless for the community.
And I have feeling, that the problem is already solved, but I can not realize, where and how. Especially, I'm interested of midi-source audio accessor, which sounds for me, came from Python, a bit strange...
In one phrase — how to be with MIDI now?

In general, I add something to reaper-rs whenever I need something new for ReaLearn/Playtime (I don't add anything which I don't need because then it would be untested). Usually, I add it to the medium-level API first with an eye on quality and consistency, and then build a more sloppy high-level API on top of it.
Concerning MIDI: Medium-level API supports enumerating incoming MIDI device messages from an audio hook (Reaper::get_midi_input), sending MIDI to hardware devices from an audio hook (Reaper::get_midi_output), reading and providing MIDI from PCM sources in real-time (PcmSourceTransfer) and whatever MIDI-related function you can find on the Reaper struct.
Looking at MIDI PCM sources and enumerating the contained MIDI events is not something I've needed so far, so you would need to implement it on your own.

OK, I'll loot at it next days and try to make PR. If You have time, please, check my previous two, I want to have feedback if I need to change approach for something.

Hmm. I've checked current typed, and, definitely, there is need for a separate struct for MIDI event in take source. But it also holds standard midi message inside. Example from reapy:
class MIDIEventDict(te.TypedDict):
    ppq: float
    selected: bool
    muted: bool
    cc_shape: CCShapeFlag
    buf: ty.List[int]

And I'm thinking on difference between already implemented midi message and midi message from Take.
What is bothering me — that in midi Take there are a lot of big messages, like Lyrics, Text and Notations (which I make in 100-200 character in length). I don't feel an array as a good type to hold these. But consider vector instead.
Maybe there is a point of making Trait instead of Struct? And implement it for two structs: real-time with arrays and got from take with vectors?

OK, since I really want to get into this functions as short as possible, I will not touch yet /medium/midi.rs, but, instead will build draft module /medium/source_midi.rs. Then we can take a brief look at both and decide how the final implementation should look like.

Yes, it's better. It'll probably take a while until I can take a thorough look at the take stuff.

I was too confused by attempt of making iterator from raw Vec<u8>. So, at first came back to try native Reaper enumerations (e.g. MIDI_GetCC, MIDI_SetCC etc.). Still there are some concerns about of underlying types for midi messages. For the moment I decieded to use just U4 and U7 from helgoboss::midi:
#[derive(Debug)]
pub struct SourceMidiEvent<T> {
    position_in_ppq: PositionInPpq,
    is_selected: bool,
    is_muted: bool,
    event: T,
}
impl<T> SourceMidiEvent<T> {
    pub fn new(position_in_ppq: PositionInPpq, selected: bool, muted: bool, event: T) -> Self {
        Self {
            position_in_ppq,
            is_selected: selected,
            is_muted: muted,
            event,
        }
    }
}

#[derive(Debug)]
pub struct CcEvent {
    pub channel_message: U4,
    pub channel: U4,
    pub cc_num: U7,
    pub value: U7,

Going to make first tests. As I know, in every scripted API (at least, lua and Python) there were a lot of problems using these enumerations. That's why we've made custom iterators on the raw midi source data.

Yes, if you want this to end up in medium-reaper, please use helgoboss-midi types.
You could have a look at reaper_high::Project::tracks() to see how I turn a typical REAPER API enum function into an iterator. I would do the same for iterating over events of a MIDI source. Performance-wise, that's better than putting everything into a vec first because it's done on the fly and you can stop iterating at any time.

After a couple of iterations, I've managed how to get size of midi message: call the function twice, if this is not regular 3-byte message.
But, also, I have profiled arbitrary "FFI" MIDI_GetEvt and MIDI_GetAllEvts. And, yeah, arbitrary single call is already an result of iteration. So, there is no real sense of having these functions in medium-level API, but make an iteration in rust instead.
Profiling results:
[2022-11-12T17:05:36Z DEBUG rea_score_test] SourceMidiEvent { position_in_ppq: PositionInPpq(1200.0), is_selected: false, is_muted: false, event: GenericMessage { size: 3, message: [144, 60, 103] } }
[2022-11-12T17:05:38Z DEBUG rea_score_test] passed with single-access: Some(1.377263539s)
[2022-11-12T17:05:38Z DEBUG rea_score_test] [240, 0, 0, 0, 0, 3, 0, 0, 0, 144, 60, 96, 240, 0, 0, 0, 0, 3, 0, 0, 0, 128, 60, 0, 240, 0, 0, 0, 0, 3, 0, 0, 0, 144, 62, 96, 240, 0, 0, 0, 0, 3, 0, 0, 0, 128, 62, 0, 240, 0, 0, 0, 0, 3, 0, 0, 0, 144, 60, 103, 240, 0, 0, 0, 0, 3, 0, 0, 0, 128, 60, 0, 240, 0, 0, 0, 0, 3, 0, 0, 0, 144, 62, 96, 0, 0, 0, 0, 0, 38, 0, 0, 0, 255, 15, 78, 79, 84, 69, 32, 48, 32, 54, 50, 32, 97, 114, 116, 105, 99, 117, 108, 97, 116, 105, 111, 110, 32, 115, 116, 97, 99, 99, 97, 116, 105, 115, 115, 105, 109, 111, 240, 0, 0, 0, 0, 3, 0, 0, 0, 128, 62, 0, 224, 1, 0, 0, 32, 3, 0, 0, 0, 176, 1, 108, 160, 5, 0, 0, 0, 3, 0, 0, 0, 176, 123, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
[2022-11-12T17:05:38Z DEBUG rea_score_test] 240
[2022-11-12T17:05:38Z DEBUG rea_score_test] passed with collection-access: Some(132.552726ms)

source:
let event = rpr.midi_get_evt(take, 4).expect("should take event");
log::debug!("{:?}", event);
let now = Instant::now();
for _ in 0..(10_i32.pow(6)) {
    let idx = rand::random::<i32>().abs() % 9;
    let event = rpr
        .midi_get_evt(take, idx as u32)
        .expect(&format!("should take event, idx={:?}", idx));
}
log::debug!(
    "passed with single-access: {:?}",
    Instant::now().checked_duration_since(now)
);
//
let events = rpr
    .midi_get_all_events_raw(take, 500)
    .expect("should be vector of msgs");
let event = events.get(4 * 12).unwrap();
log::debug!("{:?}", events);
log::debug!("{:?}", event);
let now = Instant::now();
for _ in 0..(10_i32.pow(5)) {
    let events = rpr
        .midi_get_all_events_raw(take, 200)
        .expect("should be vector of msgs");
    let idx = rand::random::<i32>().abs() % 9;
    let event = events.get(idx as usize).unwrap();
}
log::debug!(
    "passed with collection-access: {:?}",
    Instant::now().checked_duration_since(now)
);

And, I'm sorry for asking in this issue, but I feel separate will be too much for this question.
Now, when medium-level API covers about of 30% of low-level (which I found a bit of optimistic ;) ), the reaper.rs module is already of 8 000 lines in length... So, when the whole API covered, it would be about of 25 000 lines... My VSCode on my working station is already thinking a lot during the navigation... Maybe there is a point of making of some refactoring?
Intuitively, I would separate medium-level Reaper functions in modules with, probably, one global plugincontext or something like this.

Last time I checked it was more like 13%, not 30%. That's also the number I mentioned in the README.
Mmh, medium-level API is intended to be 1:1 with the original REAPER function list. I want to keep it that way. Separation of functions into different groups/structs is usually a subjective matter, so not something that fits to the medium-level API philosophy. Also, having to think (and agree with other contributors) where a function goes before you port it to that API is takes time that could better be spent elsewhere. I actually think, the reason why REAPER's API exists and is so comprehensive is also due to the fact that they don't have to think of perfect API design before adding new functionality. I like that pragmatism.
Concerning performance of the IDE, large files really shouldn't be a problem for a good IDE. Especially if they are as simple as a flat list of functions. Maybe you've set up something wrong. I can't really help in this regard because I use IntellJ Rust, there it's fast at least. Also, I think it wouldn't make a difference. I mean, look at the low-level Reaper struct! It's ten times more large. And you don't get rid of that by slicing up the medium-level API.
However, what you suggest is exactly what I was intending for higher-level APIs (reasonable grouping of functions, improving things, fixing quirks, ...).

I consider reaper_plugin_functions.h as an autogenerated file, that does not represent the structure of the Reaper project itself.. As well, as I understand, the low-level API of your workspace.
But medium-level is something, that should be human-made and human-readable. Even if not talking of speed of IDE navigation, with every 1000 lines of code it will raise the threshold of getting into project, or modification after a brake. It seems to me, that this type of overhead will then take more resources, than navigating through modules. For example, I hardly can find a function I'm working on, when it does not produce error\warning message.
For the moment, I don't see a big issue in semantics of separation, as API is already quite separated by naming conventions.
There're MIDI_* functions, *Proj* functions, *MediaTrack* etc.
So... Maybe, there is a point to consider some separation. And from the user-view with autocomplete it still can be just a function list, being reexported by the parent module.

with every 1000 lines of code it will raise the threshold of getting into project, or modification after a brake. It seems to me, that this type of overhead will then take more resources, than navigating through modules. For example, I hardly can find a function I'm working on, when it does not produce error\warning message.

Can you elaborate? Not sure I understood that.
I don't know if you read the Rust docs of the reaper-medium crate. They go into utmost detail why I have designed it the way it is designed. If not, I encourage you to read it.
TL;DR The medium-level API should reflect the original API as much as possible, that's simply how I defined it. I defined it that way so that people who know ReaScript or the C++ API feel right at home and find stuff quickly. And another reason why I defined it that way, is to avoid exactly this kind of discussion about how things are done ... well, that didn't quite work out ;)
Look, the original REAPER C++ SDK has the same "issue" (which I find to be a non-issue): Every function is top-level, no modularization. The medium API simply inherits that feature.
I can understand your thinking. I also like a good API, nicely modularized. REAPER's original API is not a beauty in terms of API design, even Justin admits that. That's exactly why I - right from the start - envisioned a higher-level API on top of that which has all the freedom to make things right, not just in terms of modularization.
If VSCode has a really bad time with the API and it's clear that this is because of the sheer size of the Reaper struct, then something needs to be done, I agree. But even then, I think it should be done on IDE side. It doesn't have to be slow, as JetBrains IDEs clearly show. I use this API a lot, in really large extensions such as ReaLearn and the Clip Engine and I never felt it's an issue.

Can you elaborate? Not sure I understood that.

When you can not get what is happening in the file, You can not work with it. Beside the Reaper struct there are other types and functions. Also, even with knowledge of what is being put inside the Reaper struct, it is already quite a task to find it. These CamelCase to snake_case translations, free order of functions etc. do not help to find, what you have just modified.
I can not imagine a situation, where scrolling through tens of thousands lines of code is more comfortable, than quick browsing through a dozen of files...

They can't just be top-level module functions.

We can, actually, profile, is there sensitive overhead in usage of global plugin context (like top-level Reaper::get()) in comparison to accessing is as struct field. If this is a matter of under 100ms in a million iterations — why not to use just global state?
As you can see above, some intuitive performance considerations can be not as they seem :)

Can you elaborate? Not sure I understood that.

When you can not get what is happening in the file, You can not work with it. Beside the Reaper struct there are other types and functions. Also, even with knowledge of what is being put inside the Reaper struct, it is already quite a task to find it. These CamelCase to snake_case translations, free order of functions etc. do not help to find, what you have just modified.

I'm quite in favour of putting all those extra structs in other files. I also wouldn't have a real problem with distributing the functions to multiple impl Reaper blocks in multiple files as it's not a breaking change for consumers ... although I don't find it very useful and therefore am reluctant to actually do it - unless you show that this simple change would indeed solve your VSCode performance issues. But splitting it into multiple modules, no. Breaking change, no significant benefit, sorry.

I can not imagine a situation, where scrolling through tens of thousands lines of code is more comfortable, than quick browsing through a dozen of files...

I'm pretty sure that's a matter of taste.

They can't just be top-level module functions.

We can, actually, profile, is there sensitive overhead in usage of global plugin context (like top-level Reaper::get()) in comparison to accessing is as struct field. If this is a matter of under 100ms in a million iterations — why not to use just global state?
As you can see above, some intuitive performance considerations can be not as they seem :)

Yes, with a static it can be done, but that would be a quiet major change and deviation of the crate philosophy (again, read the docs if you are interested in the rationale). I'm not worried about the performance of that solution (I use it always with a static in reaper-high). I just don't see the significant benefit of doing that.
To be honest, this discussion doesn't go into a direction I would like to further pursue. You have your views on this, I have mine. This issue is not a showstopper of any kind and there are so many things about reaper-rs that can be discussed/done, which are far more urgent than this. If you seek perfection, we would go on discussing like this for days. And I don't have time for that. reaper-rs is for me not an end in itself, it's my tool for writing ReaLearn and for this it works great so far.
Therefore, let's just leave it at that for now. And if you would like to see the function result structs in separate files, no problem.

I also wouldn't have a real problem with distributing the functions to multiple impl Reaper blocks in multiple files as it's not a breaking change for consumers

Is it really possible? :) Sounds good!
The problem I see, that «every in one place» is the common way of consuming. But it would be hard to maintain, e.g. write this biiig file.
I've carefully red docs.

I also wouldn't have a real problem with distributing the functions to multiple impl Reaper blocks in multiple files as it's not a breaking change for consumers

Is it really possible? :) Sounds good!

Yes. Look at reaper.rs and reaper_simple.rs in reaper_high. Makes use of that Rust feature.

The problem I see, that «every in one place» is the common way of consuming. But it would be hard to maintain, e.g. write this biiig file. I've carefully red docs.

Why? You just look for an empty slot (the space between functions) and "slap" a new function there, done :D

The issue will be resolved with closing of #66


No facades?

Ive just realized all of the facade craftings are disabled, is there a particular reason for that?

ok fixed with update


Support for Suggestions in multi-level commands

Suggestions work for 1 level commands like GET, SET etc, but for multi-level commands like COMMAND LIST, COMMAND INFO etc, we do not have suggestions.
We should add support for this use case, to be consistent and also make those commands discoverable/auto-complete friendly

@arpitbbhayani @JyotinderSingh Folks, I’m working on this issue to enable multi-level autocomplete for commands, as right now it only supports single-level. I’ve been researching possible solutions—do you think it’s best to integrate a library for this, or should we build a custom autocomplete, similar to what we’re currently using for single-level commands?

@Dhroov7 , if we can leverage a lightweight library, that would be great! Please share your research, maybe we can make an informed decision based on it!
if nothing fits, we can always do it from scratch to our needs

@Dhroov7 , do you have some research notes, demos that you wish to share for this ? Or let me know if you are still working on this or not.

@vpsinghg Hey, I couldn't make time for this. Feel free to take this up.


Knowledge about Life of a Transaction Sui

Where can I find more information about the lifecycle of a transaction in Sui, and which folders in this repo should I explore?

Hi @Sotatek-MinhNguyen11
What kind of information would you like to know more about?
Here's some material that might help:

https://www.youtube.com/watch?v=W8dVZQy-dlI
https://docs.sui.io/concepts/sui-architecture/transaction-lifecycle

Also please feel free to ask questions and I will try to direct them to the right folks. Thanks!

Hi @stefan-mysten
You want an explanation of how to implement a transaction life cycle in your code, starting from the client's request to the final response after successful processing.
As i know, the process involves three main steps: distribute, handling, and verify transaction. For each step, how it is handled in code? (including aspects like processing, consensus, and saving data to the database of node,...)


Nested form fields values are not reflected on submit.

Thanks for your reply. Sorry if i misguided you, but model was correct , i want the nested as array.
I am doing something wrong in schema, can you please help?
How to  achieve the same ?
Originally posted by @suraj740 in https://github.com/ngx-formly/ngx-formly/issues/2423#issuecomment-670074471

I'm not sure what do you want to achieve, the easy way is to pass fieldArray to nested without using the button:
{
  "key": "nested",
  type: 'repeat',
  fieldArray: {
    fieldGroup: [
      { "key": "name" },
      ....
    ]
  }
}

In case you want to add a nested field for the current areas_data item https://stackblitz.com/edit/angular-v7rvwf-sf6oxt`

Thanks 😍@aitboudad, ${field.parent.key} this is what i wanted.
Thanks again for your help😊.


Fragment name uppercase-lowecase problem for the generated TS interfaces

I'm using version 0.10.9 , and if I declare a fragment like this:
fragment ICQMessageFragment on RandomTest {
    _id
}

the name of the generated ts interface will be:
export interface IcqMessageFragment

Notice that ICQ turned into Icq
however when I use this fragment on a query, like:
getMessages {
  ...ICQMessageFragment
}

The generated ts interface inside the query will use the original form of the fragment, like this:
 Array<ICQMessageFragment>

And Typescript immediately throws an error that it doesn't find: ICQMessageFragment because it is case-sensitive.

This is maybe related to #72


UX / UI Enhancements

[x] Add border-bottom under the box
[x] Change input border to be same color as searchbox; rgb(207,205,204)
[x] ~Remove the huge whitespace under the component~

@pierluc-ssoucy The whitespace underneath the component is caused by a min-height set on a parent container in the DOM. This is the same style that controls the line height property of the component.

@pierluc-ssoucy For item 3, the whitespace underneath the component is caused by a min-height set on a parent container in the DOM. This is the same style that controls the line height property of the component.

I ended up being able to remove the whitespace by adding some styles to the parent containers as well as adding an observer to re-apply the styles.


Is managed data still needed?

@keenanwoodall Since latest versions of Unity support Mesh.SetVertices, Mesh.SetNormals, etc with native arrays I was wondering if we still need to do this step?
From MeshData.cs:
// Copy the native data into the managed data for efficient transfer into the actual mesh.
DataUtils.CopyNativeDataToManagedData(dynamicManaged, DynamicNative, dataFlags);

I have tried bypassing it and doing this instead and it works fine, I think it might be more efficient since we can skip the managed overhead entirely?
if ((dataFlags & DataFlags.Vertices) != 0)
				DynamicMesh.SetVertices(DynamicNative.VertexBuffer);
			if ((dataFlags & DataFlags.Normals) != 0)
				DynamicMesh.SetNormals(DynamicNative.NormalBuffer);
			if ((dataFlags & DataFlags.Tangents) != 0)
				DynamicMesh.SetTangents(DynamicNative.TangentBuffer);
			if ((dataFlags & DataFlags.UVs) != 0)
				DynamicMesh.SetUVs(0,DynamicNative.UVBuffer);
			if ((dataFlags & DataFlags.Colors) != 0)
				DynamicMesh.SetColors(DynamicNative.ColorBuffer);
...etc...

If not then there is separate optimization I'd like to propose/implement that will be faster than MemCpy (see bottom of this page if curious: https://jacksondunstan.com/articles/4713 where CopyFromFast and CopyToFast is discussed)
Just want to get some thoughts on this in case I'm missing something, otherwise I'm thinking about stripping out the managed data stuff and submitting a pull request!

Preprocessor stuff has been added to it uses managed data before 2019.3
I made a test fbx with submeshes to see how it breaks and realized it wasn't going to break because no deformer (that I've made) marks the triangles as changed in the data flags so it never gets copied.
I removed the data flags check so it always copies the triangles and the result was the first material being applied to the entire mesh since it was treated as one submesh. Was that how it broke for you, or did it do something else? Did you have a custom deformer that was modifying the triangles? I'm curious what caused the break.
I tried changing the code that sets the indices to this
if ((dataFlags & DataFlags.Triangles) != 0)
{
	for (int i = 0; i < to.subMeshCount; i++)
	{
		var submesh = to.GetSubMesh(i);
		to.SetIndices
		(
			indices: 			from.IndexBuffer,
			indicesStart: 		submesh.indexStart,
			indicesLength: 	submesh.indexCount,
			topology: 		submesh.topology,
			submesh: 		i,
			calculateBounds: 	false,
			baseVertex: 		submesh.baseVertex
		);
	}
}

it's on develop and it seems to work as well 👍

No custom deformers involved.
Materials were fine just all submeshes were straight up missing, except for the very first 0 index submesh.
Thanks, I will get to testing this very soon! If it breaks again I will try get you a repro case or something.


Haskell builder: Use $abi/$libname as --libsubdir

Motivation for this change
This is an attempt on https://github.com/NixOS/nixpkgs/issues/40128. I should definitely take a look at the second point of Edwards answer: -rpath for linux. Maybe some could help me there. --ghc-option doesn't support path templates like $abi or $libname.
/cc @shlevy @grahamc
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[x] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

@peti Please see @ezyang comment on the matter https://github.com/NixOS/nixpkgs/issues/40128#issuecomment-398093198.

@Peti does it make sense? $pkgid does not identify a package uniquely (basically it is pure coincidence that it worked before). Especially one that uses backpack. The combination of $abi and $libname however does.
@ezyang or @hvr might give a more thorough answer.

@alexbiehl Does the change work? :) Naively I'd expect this could cause more thrashing in Nix, because the default generated values for these are not very stable.

@ezyang Yes it works! It will definitely trash the haskell libs in you nix store. But I haven't experience any others yet.

@ezyang Can you expand on the thrashing a bit? Is this likely to be a source of impurities between otherwise  identical nix builds on different machines or something?

@peti Can you review @ezyang's assessment and let us know if this is a decent path forward or not?

@alexbiehl We've been actively using this for a while, right?

@shlevy correct.

We rely on ghcWithPackages for our nix-shells

Merged into haskell-updates


Some undefined reference (in core), when try to cross-compile to riscv64

Before reporting an issue please first check the
troubleshooting guide. If
the issue you're encountering is not solved thereby please state the following in your bugreport:

Operating system
Host is Ubuntu 20.04, and the target is the buildroot of K510.
The way you installed OpenCV: package, official binary distribution, manual compilation, etc.
manual compilation by buildroot and K510 SDK
OpenCV version
4.5.2
rustc version (rustc --version)
rustc 1.70.0 (90c541806 2023-05-31)
Attach the full output of the following command from your project directory:opencv = { version = "0.82.1", features = ["clang-runtime", "videoio", "imgcodecs", "imgproc"], default-features = false }

normal cargo build and get error:
note: /usr/lib/gcc-cross/riscv64-linux-gnu/9/../../../../riscv64-linux-gnu/bin/ld: /raid/qinka/shanan/hardware/shutter/target/riscv64gc-unknown-linux-gnu/debug/deps/libopencv-ab144aa9f0a7fc24.rlib(20b4ec68d6611b0d-core.o): in function `.LEHB4400':
          /raid/qinka/shanan/hardware/shutter/target/riscv64gc-unknown-linux-gnu/debug/build/opencv-f4ef7480ce9f72fa/out/core.cpp:6215: undefined reference to `cv::SparseMatConstIterator::operator--()'
          /usr/lib/gcc-cross/riscv64-linux-gnu/9/../../../../riscv64-linux-gnu/bin/ld: /raid/qinka/shanan/hardware/shutter/target/riscv64gc-unknown-linux-gnu/debug/deps/libopencv-ab144aa9f0a7fc24.rlib(20b4ec68d6611b0d-core.o): in function `.LEHE5244':
          /raid/qinka/shanan/hardware/shutter/target/riscv64gc-unknown-linux-gnu/debug/build/opencv-f4ef7480ce9f72fa/out/core.cpp:7696: undefined reference to `cv::_OutputArray::_OutputArray(std::vector<cv::cuda::GpuMat, std::allocator<cv::cuda::GpuMat> > const&)'
          collect2: error: ld returned 1 exit status

  = note: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
  = note: use the `-l` flag to specify native libraries to link
  = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)

I "destroyed" the condition of https://github.com/twistedfall/opencv-rust/blob/5c6f76bace2ba19a3f25a8120cefc36fef0a1c3a/binding-generator/src/settings.rs#L535C46-L536 , and then, it's ok.

Thanks for the investigation, I will incorporate this change in the next release!

@Qinka Hi I am having the same problem. How did you "destory" it? thanks!

Sorry for the long wait, but this is now included in 0.85.0 (kudos to @fzyzcjy!)


Is there has any way that I can disable Index Routes

I am use this plugin with vite-plugin-md.
And I want to generate the correct link with markdown syntax.
For example, I have two markdown file:
/src/test.md
[other](./other/index.md) # this will generate a link => other

/src/other/index.md
[test](../test.md) # this will generate a link => test

And I want the vite-plugin-pages can generate path with index.
Thanks  for bring the awesome plugin.

I found onRoutesGenerated hook work perfect for me.


Parameter newVersion is not working with version 2.14.0

mvn --settings **** -f common/pom.xml build-helper:parse-version versions:set -DnewVersion=2.0.0
[INFO] Processing change of common:1.0.0 -> 2.0.0
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for common 1.0.0
replace with the new version is not working

please retest with 2.14.1


Docker Dev workflow is broken (apple M1)

https://github.com/restarone/violet_rails/issues/402

@Pralish any documentation on why this is the fix? Havnt tested yet obv

@donrestarone , Found the fix on stackoverflow.
https://stackoverflow.com/questions/70963924/unable-to-load-nokogiri-in-docker-container-on-m1-mac


Python compatibility

I want to know if autoflip is compatible with python

AutoFlip is now C++ only. But, you can write python code to execute the binary via subprocess. We did this to the yt8m example already: https://github.com/google/mediapipe/blob/master/mediapipe/examples/desktop/youtube8m/viewer/server.py#L155
In the meanwhile, we are working on a project to bring MediaPipe to the Python world.

Can you elaborate on how this can be done specifically for autoflip?

AutoFlip is now C++ only. But, you can write python code to execute the binary via subprocess. We did this to the yt8m example already: https://github.com/google/mediapipe/blob/master/mediapipe/examples/desktop/youtube8m/viewer/server.py#L155
In the meanwhile, we are working on a project to bring MediaPipe to the Python world.

@jiuqiant is there any update on this? how can we implement this in python?

is there any update of Autoflip on python


docs: make ServerBuilder type public

Closes #1.

Do we want to bump the version for such a small change? My sense is https://github.com/penumbra-zone/tower-abci/pull/25 will make it in soon, so rebasing that on top of this post-merge would be the shortest path.

Already addressed as part of @erwanor's changes in #25, see https://github.com/penumbra-zone/tower-abci/pull/25/files#diff-b1a35a68f14e696205874893c07fd24fdb88882b47c23cc0e0c80a30c7d53759R16


Support podtemplates

Description
Adds support for podtemplates
Type of change

[x] New feature :sparkles:

How Has This Been Tested?

[x] has a pod template that it parses and fixes correctly

Checklist:

[x] I have :tophat: my changes (A 🎩 specifically includes pulling down changes, setting them up, and manually testing the changed features and potential side effects to make sure nothing is broken)
[x] I have performed a self-review of my own code
[ ] I have made corresponding changes to the documentation
[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
[x] The test coverage did not decrease

Thank you for the test and the review @genevieveluyt


Labels with Nested Inputs: label-has-for

When turned on, this rule incorrectly shows errors for the following code snippet.
<label>
  <input type="checkbox" />
  Option
</label>

The errors are correct. You need to both nest, and for-ID link, to get full a11y coverage of all assistive devices.

The spec states that nesting as demonstrated has the same effect as using the for attribute. What's the benefit of adding the attribute in this case?

@jacobp100 Not every device follows the spec. Some 95% of devices work with nesting alone, a different 95% work with for-ID linking alone - the only way to cover 100% is to do both. Accessibility is about 100% coverage, so nothing short of that is "good enough".

I don't know if it is the good place to ask, but where can I contribute code to make that 95% be 100% ?

@CyrilWork nowhere, unless you have a time machine - the comparison would be asking how you could make IE 9 support flexbox, as an example.

I will think about it


[Event Hubs] Getting dependency issue in @azure/event-hubs with angular 7

Hi,
We have the same issue when using Angular 7 with the @azure/event-hubs:1.0.8 dependency.

WARNING in ./node_modules/ms-rest/lib/serviceClient.js 441:19-43
Critical dependency: the request of a dependency is an expression

ERROR in ./node_modules/adal-node/lib/cache-driver.js
Module not found: Error: Can't resolve 'crypto' in 'C:\Users\mbarbin\Documents\Azure_IA\azure-mastermind-visualization\node_modules\adal-node\lib'
ERROR in ./node_modules/aws-sign2/index.js
Module not found: Error: Can't resolve 'crypto' in 'C:\Users\mbarbin\Documents\Azure_IA\azure-mastermind-visualization\node_modules\aws-sign2'
ERROR in ./node_modules/aws4/aws4.js
......
......
......

/cc @bterlson @ramya-rao-a

Original issue https://github.com/Azure/azure-sdk-for-node/issues/4536

We need to review if this is still an issue given all the changes to core-amqp/identity.

Running into similar issues trying to use Event Hub from a React application. Is there any good alternatives if it was built assuming the NodeJS?

We've fixed issues with bundling event-hubs for browsers in version 5.0.1. Closing this issue, but feel free to open a new one if still facing issues bundling the SDK.


Upgrade thrift to 0.12

The latest stable release of Thrift is 0.12.0 (released on 2019-JAN-04).
https://thrift.apache.org/download
I don't know what all has changed since I can't find release notes but upgrading should be looked into for 2.0 and 1.9.  This JIRA filter is the best I can come up with for issues.

Fixed in #1004


docs: :memo: rename function to create_default_package_properties

Description
This renames create_properties_object to create_default_package_properties because it seemed more descriptive.
Reviewer Focus

This PR needs a quick review.
Checklist

[x] Added or updated tests
[x] Tests passed locally
[x] Linted and formatted code
[x] Build passed locally
[x] Updated documentation

@martonvago thanks for splitting them :relaxed:


fix addrVgpr naming for atomic GSU

Fixing inconsistent naming

@cgmillette The 2 gfx900 pipelines will never finish; the 2 failed hipclang-4.1 pipelines are no longer relevant because we've switched over to compute-rocm-dkms-no-npi-hipclang and all active Tensile pipelines passed.


cannot install "Eufy Security WS Addon"

my HASS simply does not allow me to install the latest Eufy Security WS Add-on :

When I go to the add-on store, I can only see a very old version of the add-on, v0.9.2 :

It's clearly not installed, but I don't want that, I want to remove it, so I can add the new Add-on v1.1. But I can't remove it, it says there are not repositories :

When I try to add the latest add-on from : https://github.com/fuatakgun/eufy_security_addon :

I restart HASS, but still I keep seeing the old  one, not the new :

I tried using the old v0.9.2, but it's clearly not accepted by EUFY cloud anymore :

I am a quite experienced HASS user, but it seems like I am going in circles. I just cannot get the proper version of the add-on installed.

Same with me

by removing the EUFY Security integration in HACS, I was able to re-install v1.1, but the old one still resides next to the new. And I do have problems signing in 👍

My problems signing in might be related to this or not, as there are several issues after EUFY changed it's cloud access (see other threads)

Everyone, please uninstall previous version of addon, install the new version 1.3.0. It is very important to uninstall it because we need to get rid of previous login data which is not compatible anymore.
After installing and starting the add-on with new version, enable the integration. I jave confirmed that p2p, rtsp, motion detection are working fine.
This is about to fix login issues but not about missing thumbnails, so please set your expectations

Everyone, please uninstall previous version of addon, install the new version 1.3.0. It is very important to uninstall it because we need to get rid of previous login data which is not compatible anymore.
After installing and starting the add-on with new version, enable the integration. I jave confirmed that p2p, rtsp, motion detection are working fine.
This is about to fix login issues but not about missing thumbnails, so please set your expectations

That is exactly the problem. I can uninstall the v1.1, but cannot get rid of the v0.9. It does not show up in the add-on repository. So there must be a way manually delete it, but how ?

You somehow have it locally, not from GitHub, but it would not impact do not worry.
Local add-ons are coming from local folder of your home assistant server, i am mot controlling it.
As an experienced user, you can check this: https://developers.home-assistant.io/docs/add-ons/tutorial/


Doesn’t appear in status bar

I think the app is supposed to be controllable via the status bar. I don’t get anything there on Catalina.

Yeah, I'm having the same issue on Big Sur. For me it looks like AppleScript is just broken in Big Sur so I can't recreate. I'll test in Catalina later next week.

This is the problem I think: https://www.electronjs.org/docs/faq#my-apps-tray-disappeared-after-a-few-minutes
I changed it on my fork and the problem was gone.

Yep I saw. I'll merge the PR but I won't be able to build the app until I resolve the AppleScript issue.


tech stack, repo & infrastructure

My final project consists of backend API, frontend app and common libraries that I can transfer across projects.
Decisions

monorepo to have all backend project, frontend project and component library all in the same repo. I decided to use nx to setup monorepo for all the different pieces of the project.
MERN stack (MongoDB, Express, React and Node). Typescript is the programming language that I would use in the project. For the blog, I am going to need S3 to store images in a post but for the blog post text, I need to investigate whether I use MongoDB or DynamoDB or S3.
aws to host the website.

aws required services:

Staging and Production environments where each has its own resources such as Route53, S3 (bucket for website static files and another bucket for storing blog post images), DynamoDB  (for storing blog post text).
To deploy the code, I can either use CloudFormation or Elastic BeanStalk. Both are free to use. The latter is easier to use than the former. However, I think that the server does not need core features provided by EBS such as autoscaling, load balancer. I am going to use CloudFormation instead with its templates to apply the idea of Infrastructure as Code.

aws security considerations:

Database/S3/EC2 resources need to be secured. One way for doing that is mentioned in Security FAQ:

You can use Amazon VPC to provision a private, isolated section of your application in a virtual network that you define. This virtual network can be made private through specific security group rules, network ACLs, and custom route tables. You can also easily control what other incoming traffic, such as SSH, is delivered or not to your application servers by changing the EC2 security group settings.


Run mypy and pylint as separate jobs

Run Pylint and MyPy as separate jobs when running CI.

Can one of the admins verify this patch?


Add source notice to Detailed Instructions

Add a notice/mention to Detailed Instructions for authors (of mainly local tasks) to specify what imagery/data layers or other sources mappers should preferably(/could) use.

There's already two solutions for this:

Challenge authors can pre-set the imagery layer to show by default, and even provide their own custom tile server
The challenge description and task instructions are free form fields where the challenge author can include this information.

Many authors forget to do 2. when they want to suggest multiple layers -they may or may not still do 1.-. Including a mention of this somewhere would be helpful. Especially for areas with DEMs etc. (sometimes not in iD) which mappers may not know of.


Survey Sign form stuck at loading

Software and hardware versions
Survey development
Nexus 6P with Android 6.0.1
Problem description
Sign form gets stuck at loading screen
Steps to reproduce the problem

Open Sign from Tables
Add Row
Press Next, Press Back, Press Next

Expected behavior
Doesn't get stuck.
Other information

Fixed


Update scalafmt-core to 2.4.0

Updates org.scalameta:scalafmt-core from 2.3.2 to 2.4.0.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scalameta", artifactId = "scalafmt-core" } ]

labels: library-update, semver-minor

I tried to run scalafmt but it fails:
[error] /home/ross/src/http4s/client/src/test/scala/org/http4s/client/middleware/RetrySpec.scala:86: error: identifier expected but if found
[error]             if (attempts >= 2) None
[error]             ^: /home/ross/src/http4s/client/src/test/scala/org/http4s/client/middleware/RetrySpec.scala
[error] /home/ross/src/http4s/ember-client/src/main/scala/org/http4s/ember/client/EmberClientBuilder.scala:92: error: ) expected but ( found
[error]               .requestKeyToSocketWithKey[F](
[error]                                            ^: /home/ross/src/http4s/ember-client/src/main/scala/org/http4s/ember/client/EmberClientBuilder.scala
[error] (client / Test / scalafmt) /home/ross/src/http4s/client/src/test/scala/org/http4s/client/middleware/RetrySpec.scala:86: error: identifier expected but if found
[error]             if (attempts >= 2) None
[error]             ^: /home/ross/src/http4s/client/src/test/scala/org/http4s/client/middleware/RetrySpec.scala
[error] (ember-client / Compile / scalafmt) /home/ross/src/http4s/ember-client/src/main/scala/org/http4s/ember/client/EmberClientBuilder.scala:92: error: ) expected but ( found
[error]               .requestKeyToSocketWithKey[F](
[error]                                            ^: /home/ross/src/http4s/ember-client/src/main/scala/org/http4s/ember/client/EmberClientBuilder.scala

Superseded by #3205.


are options global?

Hello!
I must say, you have made remarkable progress with this project in such a short time! 👍
I have a query regarding the new options. Are they global, i.e. applicable for every user? Or does each user have their own set of options? For instance, if I set a new prompt for myself, will every other user see this new prompt or only I will be able to see it?
Best regards
Kamil

Thanks!
The options in the config file are global, and the options you set in the chats are only for the current chat tab.
If you are in a private chat, you can consider that the options are your personal preference.
But if you run the set command in the group chat tabs, that means you config the bot's behaviour for the group.
:)


Feature request (?): ability to set the app session length

Hi,
Following MixPanel docs for Native SDKs, it is possible to adjust the app session length.
However, how could we do this up for a React Native app? Following source code of this lib and its doc, it doesn't seem possible.
Thanks in advance for any help on the topic.

I'd really like this one, too. 10s by default is much too longer for a minimum session length for our app; it's designed for people to quickly check small amounts of information.

Any updates/insights on this? 10s is too long for our case as well.

bump - the current time does not work so I need to recraft the app_session event from zero, this is a basic setting that should exist.


encrypt udp traffic

Use aes-256-cbc to encrypt the UDP messages.

[ ]  bot side implementation
[x] esp side implementation

Bot side needs to load the key from env file


Add zone type for Google CloudDNS

I'm trying to implement cert-manager + external-dns and faced issue. I have 2 zones for one domain: one public and one internal. Public zone is needed for Letsencrypt DNS validation. Internal zone is where services live. I configured external-dns with domain filter and seems like it's creating private records in public zone, which is not compatible with GCE internal DNS resolution.
Is it possible to add the same option as for AWS (--aws-zone-type) but for Google DNS?
Of course this can be workarounded by --zone-id-filter, but it would be good to have more portable and elegant option like we have for AWS provider.

Hi @njuettner,
I am new to Kubernetes external dns. I would like to pick this issue up. It would be good if you could provide me some pointers to get started with.
Cheers,
Vishlesh

@vishleshpatel I hope I can help you but what do you exactly need? We're not using ExternalDNS in GCloud, we are more focused on AWS.
The PR https://github.com/kubernetes-incubator/external-dns/pull/329 was merged to  filter for private and public hosted zones in AWS related.


Research a data-attribute approach to passing translations to component JavaScript

What
Research into how a data-attribute based approach to passing translations for strings in our component JavaScript would work. This might be in isolation and/or alongside another approach, like passing a translations object through initAll() at the point of initialising.
We want to know if this approach feels feasible (even if it may be untidy, in terms of a lot of data attributes), or if it's a non-starter.
Why
We're unsure if our current planned approach for passing translations to our component JavaScript will work well for all our users.
We want to know if there are any technical limitations or strong downsides to a data-attributes approach that would mean it's not appropriate for our use case (even if working alongside our current planned approach)
Assumptions

That service teams may prefer to pass in translations via Nunjucks macros / data attributes
That we want to abstract away what strings are in JS and which are in the HTML/template, so users don't need to know the difference

Timebox

1 day
We should review progress after this period of time has elapsed, even if the spike has not been 'completed'
Who is working on this?

Spike lead: @domoscargin
Spike buddy: @vanitabarrett
Questions to answer

[x] Are there any technical limitations to having many data attributes on a HTML element, e.g: a cap on the number of attributes, the length of attributes, content within attributes?
[x] Would it play nicely alongside our current approach (passing a translations object at point of initialising), if we wanted to give people two ways of passing translations? How would we set priorities if both were set?
[x] Are there any downsides to this approach, other than it makes the code pretty 'ugly', that might make us want to rule this out?

Done when

You may find it helpful to refer to our expected outcomes of spikes.

[x] Questions have been answered or we have a clearer idea of whether this is a potential approach - I don't think we need to know for sure whether we'll use this, as that will also come from community feedback on our current approach, but we should know whether it's at all feasible
[x] Findings have been reviewed and agreed with at least one other person
[ ] Findings have been shared, e.g: via a write-up on the ticket, at a show & tell or team meeting

Immediate issues that come to mind that warrant investigation:

Strings that contain quotation marks—these would likely need to be escaped or encoded in the data-* attribute.
Strings that contain embedded HTML—most frequently for visually-hidden text.

It might also be worth investigating the feasability of using encoded JSON, to allow for non-string data structures within the data-* attribute. This might let us cut down on the extreme cases of components having dozens of i18n data-* attributes.

It might also be worth investigating the feasability of using encoded JSON, to allow for non-string data structures within the data-* attribute.

Bootstrap are experimenting with this: https://getbootstrap.com/docs/5.2/getting-started/javascript/#data-attributes
It looks like all their data attributes can now house JSON values.

Technical limitations
Element attributes length and count:
HTML5
An attribute value is a string. Except where otherwise specified, attribute values on HTML elements may be any string value, including the empty string, and there is no restriction on what text can be specified in such attribute values
Every HTML element may have any number of custom data attributes specified, with any value.
https://jsbin.com/wikulamuni/3/edit?html,js,output This script works fine in Chrome with an attribute value length of 10 million+ characters.
HTML4
HTML4 allows 60 attributes with a total of 65536 characters per tag.
Attribute values restricted characters
Attribute values are a mixture of text and character references, except with the additional restriction that the text cannot contain an ambiguous ampersand.
Other limitations

IE 10 and below do not support dataset (we currently use getAttribute() in various places).
Performance of reading data-* attributes compared to storing the data in regular JS objects is poor (though extremely unlikely to ever be an issue).
In Firefox 49.0.2 (and perhaps earlier/later versions) data attributes that exceed 1022 characters will not be ready by Javascript (EcmaScript 4).

Implementation
I have a spike branch here: https://github.com/alphagov/govuk-frontend/compare/bk-spike-i18n-data-attributes
I think this is non-breaking after the i18n stuff has been added, so wouldn't necessarily have to be targetted for the next major release change.
getOptions
I've added a getOptions function tocommon.mjs. This function gathers and prioritises options in the following order:

params passed in programmatically during initialisation
params derived from data attributes
default params

It's in a very rough state (see comments in the file), but works for the minimal example...
example
I've added an example using the Accordion. I've pasted the HTML and added data attributes (Nunjucks macros would simply take params and use them as data attributes internally).
Further work
On this spike

I'd like to add a bunch of test cases, testing both the behaviour of attribute values mentioned on this issue, and the order of precedence for config options.
Would be nice to get this working with the Character count as well
Consider other approaches

If implemented

Investigate the namespacing of data attributes (eg: data-govuk-foo) to avoid clashes with anything else using data attributes.
Decide on naming conventions for data attributes - what do we do in cases where a simple attribute key->value to get transformed into a more complex object (the i18n attributes, for example, need to get put into { i18n.translations }). Do we investigate defining specific separators etc? Or handle all of that magically on our side? Or simplify our config?
Create (a) slick getOptions function/s that handle/s transformation and precedence
Implement on each component that needs it
[stretch] Investigate creating a component base class which other components extend from, which would contain the logic for creating component config options

Thanks @domoscargin,
I think the first two in the order of precedence should be reversed. data-* attributes are scoped to a single instance of a component; whereas the others are wider in scope. The more 'targeted' the configuration method, the higher precedence it feels like it should be.
It doesn't seem like there are likely we'll hit any technical restrictions that affect the use of data-*, except for potentially IE10, unless we opt not to release this feature after the initial internationalisation release.
I like the idea of having an inherited base class that includes this and other programatic API work. It feels like a more scalable way to handle it going forwards.
I'm still curious as to how this may handle features such as embedded HTML or nested JSON.
Good work so far! Interested to see where it goes.

data-* attributes are scoped to a single instance of a component; whereas the others are wider in scope.

I agree with this, but was wavering because the proposal includes programmatic initialisation of an individual component. I considered somehow making the priority individual programmatic component -> data attributes -> initAll -> default, but splitting out the programmatic options like that seems like a recipe for confusion.

Thanks for the really clear write-up @domoscargin , great work 👍 The general gist I'm getting is that there's no real technical limitations that would stop us from doing this, so it may come down to other things, primarily if it's what users need/find useful, how we'd document it (especially if it sits alongside the existing approach for passing translations).
I agree with @querkmachine on the specificity order - I think my assumption was the reversed order, with data attributes taking priority (thinking of them a bit like inline styles or our override classes), but that's an implementation detail we can get into if we're thinking of going with this approach.
I don't think it's worth getting too in depth until we know it's something we're going to do (and we'll need to wait for our user feedback before making any decisions, I think), but probably worth having a quick play around with the things Kim has mentioned:

strings with quotation marks
strings with HTML
does using JSON objects make this easier?

I thought I'd try out the JSON approach in a separate branch here
➡ View spike branch here
Note: The first 2 commits have slightly different approaches: one a bit more prescriptive on what params you can pass in, one just accepting a generic translations object. The actual logic doesn't differ much between the two.
Seems technically feasible to implement, but I wonder if it fully resolves the issue of a user needing to understand where a string is used. It still partly separates out the JavaScript strings from the Nunjucks strings, so while it feels easier because it's all in one place, you'd still probably need to consult the macro documentation to understand what goes where.
It also might feel weird to anyone using the HTML versions, because adding JSON into a data attribute isn't something you do very often.
Having said that, I do quite like it as an alternative to our existing approach, because it feels nicer to have it all in one place.

Thanks for this, @vanitabarrett!
So it seems like, in terms of the questions we're asking on this spike:

there are no big technical limitations that can't be overcome. ✅

We'd probably need some guidance on getting JSON into the right shape to be used in an attribute (ie: wrap it in single quotes, or escape/encode it, or use Nunjucks templating).

It works in conjunction with our current approach. ✅

I still think we'd need to consider priority in the case of inidividually initialised components vs data attributes, but that's an implementation detail.

There are some downsides ✅

Separates Nunjucks and JavaScript strings so user has to figure out where things go
JSON in data attributes isn't very common
Need to make sure the JSON plays nicely as an attribute string

I think these comments are pretty easy to follow, so we could ask folks to glance at it and then call this done, or I could write up a summary?

@domoscargin I think that's probably a good summary in itself!
Worth noting that "Separates Nunjucks and JavaScript strings so user has to figure out where things go" only really applies if going with the approach where a user passes in a JSON object for translations. It wouldn't be the case if we separated out each individual translation string into it's own macro param, although that has it's own downside where you may have a lot of data-attributes on the component.

Had a little play with an alternative approach to passing the JSON, by sticking it in an inline <script type="application/json"> within the module. The main advantage I can think of is that we can output it unescaped, which makes it slightly easier to debug? I don't think there's much in it TBH, but thought it was worth sharing:
https://github.com/alphagov/govuk-frontend/compare/vbs-spike-i18n-data-json...ob-spike-i18n-data-json-inline-script?expand=1
(Spikes on spikes on spikes at this point?)

We have decided we're going to go with a data-attribute approach for passing translations, alongside the currently proposed JS approach. I'm going to close this spike and write up some new cards for doing the work.


Bump package versions, remove deprecated dependency 'dependency-tree-81'

The dependency dependency-tree-81 was including an old version of typescript.
This bumps dependencies of all the packages and changes dependency-tree-81 to dependency-tree. Confirmed to be working

Thanks @jonluca!
I created this tree-81 because dependency-tree were not supported at the time.
Is the latest version of dependency-tree compatible with the latest version of TypeScript?

Yes, it's on TypeScript 5
https://github.com/dependents/node-dependency-tree/blob/main/package.json
Everything seems to be working with these bumped versions locally for me, so I think it's all good

With a brand new project with the esbuild template for both renderer and main?
If so, this should be good. I will test it when I can!


List all external deps and their versions in the README

qemu, FWTS and SCT appear to be missing from the table

The SCT has been integrated into the edk-test repository. The FWTS used here has been integrated into Buildroot, and the version of FWTS being used is V23.03.00. will update into README.md, Thanks for all the comments!
fwts -v
fwts, Version V23.03.00, 2023-03-27 04:12:10

fixed in 16ea3e1


any request error takes down the whole database

Describe the issue
We use dynalite in CI. An annoying number of times, the database server (which is used by several tests) crashes with ECONNRESET, making the rest of the tests fail.
I believe this is because of the throw in this line.
Could that throw err be changed to something like console.log(err)? I don't understand nodejs http servers enough to know if that is an appropriate solution.
Steps to reproduce
Sadly, I don't have a concise repro for this at the moment.
Expected behavior
A client resetting a connection should not take down the whole server.

That seems reasonable to me, although I'd def love to get feedback from other Dynalite users on that change.

So, I've been test running a patched version with the console.error(err) instead of the throw err in there for a while now on our CI and the results are:

The ECONNRESET error no longer takes down the whole db and subsequent tests are fine
It doesn't fully solve the problem we have where dynalite just becomes unresponsive for a while. This is most likely not a dynalite issue but some problem with our CI setup/test suite.

I still think changing that line is a worthwhile thing to do, but sadly it wasn't the magical silver bullet we were hoping for :D


Multiuse invites followup

(reviewing in PMs, to be updated)

Thanks @hackerkid! I pushed some updates, so you'll need to fetch before doing further work.
Tim:
normal flow

click "generate invite link" link

click "generate invite link" button

These feel a bit messy, and we will probably want to do some refactoring of the multi-use invite codebase to make it less structurally messy.  But this looks correct to me.
I merged all but the last commit.  For that one:

auth: Fix broken multiuse invite auth2 flow. needs a test, and also I think only works for the GitHub backend; see how these arguments are passed through send_oauth_request_to_google to fix that.

(Marking this PR as a blocker to make sure we deal with it)

@hackerkid is this ready for another review?

@timabbott Yup. Sorry for not mentioning here. I only PMed in group chat.

As a general rule, if you're going to do something in one place, always do it in the PR, at least for me -- when reading chat, I work under the assumption that any PRs that need me attention will also have a comment in GitHub requesting review :)

I edited a few comments and merged this; thanks @hackerkid!
@HarshitOnGitHub FYI as this will merge conflict with your changes; I think it should be a simple rebase, though, since we're still just deleting the legacy Google auth code.

@shubhamdhama @hackerkid The footer of the modal (with the button to generate invite link) doesn't look great in the night mode. It's probably just a css fix for the modal. Would one of you be able to fix it?

Quite so!  Posted in chat.zulip.org.  (I think as a general note, opening a new issue with a link is a process more guaranteed to result in things getting fixed quickly, since that way it's advertised to everyone in a persistent way)

Sure, will keep that in mind in future.


Add support for time types without seconds

Previously, if you try to use this guesser with a Time field without seconds, this fails because it doesn't take the withSeconds parameter into consideration.
Now, this will add input_format = 'H:i' if withoutSeconds = true.
I cannot see where the tests are for this, so have not written one, but please advise if there is somewhere I can add one.

Thanks for your Pull Request! We love contributions.
However, you should instead open your PR on the main repository:
https://github.com/symfony/symfony
This repository is what we call a "subtree split": a read-only subset of that main repository.
We're looking forward to your PR there!


Create healthcheck as part of project creation.

Fixes #2541
Bundle and profile to install are defined in the service config.
Summary
Provide a brief overview of the changes and the issue being addressed.
Explain the rationale and any background necessary for understanding the changes.
List dependencies required by this change, if any.
Fixes #(related issue)
Change Type
Mark the type of change your PR introduces:

[ ] Bug fix (resolves an issue without affecting existing features)
[x] Feature (adds new functionality without breaking changes)
[ ] Breaking change (may impact existing functionalities or require documentation updates)
[ ] Documentation (updates or additions to documentation)
[ ] Refactoring or test improvements (no bug fixes or new functionality)

Testing
Outline how the changes were tested, including steps to reproduce and any relevant configurations.
Attach screenshots if helpful.
Review Checklist:

[x] Reviewed my own code for quality and clarity.
[x] Added comments to complex or tricky code sections.
[ ] Updated any affected documentation.
[x] Included tests that validate the fix or feature.
[x] Checked that related changes are merged.

coverage: 47.873% (+0.1%) from 47.775%
when pulling e650a0fe2c08e3c3b6eec74e7c31eaf47e6534c4 on wire-up-healthcheck
into 3ac5c7ee10f1aa4b8185bf3baf51ef064863303d on main.

Sorry to come in late on the naming; it's not urgent to rename, just to be clear.


docs: Add docs.eurie.io to the showcase

I've added docs.eurie.io to the showcase.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

Hello @iktakahiro,
thank you for adding your website to the showcase of Hugo. I've merged your contribution as  2ea22a4.
The website should be updated within the next minutes.
Cheers,
Digitalcraftsman


Build fails with Error: attribute does not have a number assigned

When building Openssl 1.1.1d for Linux targets, we get failures with the result:
Error: attribute does not have a number assigned
Not sure what changed since 1.1.1c which causes this problem.

configure works:
./Configure no-unit-test no-zlib shared no-dso enable-rc5 no-async linux-generic32

Configuring OpenSSL version 1.1.1d (0x1010104fL) for linux-generic32
Using os-specific seed configuration
Creating configdata.pm
Creating Makefile

and make fails on the end with this lines:

arm-linux-gnueabihf-gcc  -Iinclude -pthread -Wa,--noexecstack -fPIC -g1 -O2 -D_FILE_OFFSET_BITS=64 -U_FORTIFY_SOURCE -fno-omit-frame-pointer -I.. -I/Users/cs/Development/Libs/zlib/linux32arm -DNDEBUG -fPIC -g1 -O2 -D_FILE_OFFSET_BITS=64 -U_FORTIFY_SOURCE -fno-omit-frame-pointer -I.. -I/Users/cs/Development/Libs/zlib/linux32arm -MMD -MF test/lhash_test.d.tmp -MT test/lhash_test.o -c -o test/lhash_test.o test/lhash_test.c
arm-linux-gnueabihf-gcc  -Iinclude -pthread -Wa,--noexecstack -fPIC -g1 -O2 -D_FILE_OFFSET_BITS=64 -U_FORTIFY_SOURCE -fno-omit-frame-pointer -I.. -I/Users/cs/Development/Libs/zlib/linux32arm -DNDEBUG -fPIC -g1 -O2 -D_FILE_OFFSET_BITS=64 -U_FORTIFY_SOURCE -fno-omit-frame-pointer -I.. -I/Users/cs/Development/Libs/zlib/linux32arm -MMD -MF test/md2test.d.tmp -MT test/md2test.o -c -o test/md2test.o test/md2test.c
arm-linux-gnueabihf-gcc  -I. -Iinclude -pthread -Wa,--noexecstack -fPIC -g1 -O2 -D_FILE_OFFSET_BITS=64 -U_FORTIFY_SOURCE -fno-omit-frame-pointer -I.. -I/Users/cs/Development/Libs/zlib/linux32arm -DNDEBUG -fPIC -g1 -O2 -D_FILE_OFFSET_BITS=64 -U_FORTIFY_SOURCE -fno-omit-frame-pointer -I.. -I/Users/cs/Development/Libs/zlib/linux32arm -MMD -MF test/mdc2_internal_test.d.tmp -MT test/mdc2_internal_test.o -c -o test/mdc2_internal_test.o test/mdc2_internal_test.c
Error: attribute does not have a number assigned

We see this error with cross compiling Linux ARM on Mac as well as native compiling Linux on 32 and 64-bit machines.

Error is generated by mkdef.pl in line 1203.
I'll try and comment out the die and see if it builds. No idea why no number is assigned here.

Looks like it builds with the two lines commented out.

  	if (!defined($nums{$s})) {
  		# die "Error: $s does not have a number assigned2\n"
  		# 	if(!$do_update);
  	} else {

No idea whether this has consequences...

Are you sure you are using a proper version of perl?
There's no reason that should happen.  Consider wiping your build tree and starting over.

Well, one computer is 5.10.1, one is 5.14.2 and one is 5.18.4 on the perl command line tool.
I would not expect perl to be the reason.

So perhaps try the second thing I mentioned.  Start with a completely fresh copy of the sources.

This is confusing. It now works and I can't find the difference between the one which didn't worked.

I just tried the same cross-compilation target on my Linux 64-bit machine with the same Configure params as you. Compilation was successful.

Today I run again into this with 1.1.1h. Strange.


Enum and attribute bugs/features

I've fixed a bug related to attributes - the LAttr token wasn't recognized as the beginning of a declaration which would cause declarations preceded by an attribute to be missed, and I've brought the enum functionality in-line (I think) with the grammar, adding enum typing ("representation") and member values.
This partially resolves #22 - I'm not sure what would be the best way to proceed, from the state of this branch, to resolve values for unassigned enum members, but I'm presently of the opinion that that doesn't belong in this parser?

Closing in favor of #39


Update to RC.5

Update package.json, and underlying files to support RC5.
This includes updating angular-cli to the web pack version.

Apologies! Typed this in the wrong tab.


GF_latin_core list does not match latin_unique-glyphs.nam

Observed behaviour
Submitting a font to Google Fonts, it passes the Font Bakery test (has all the glyphs in const GF_latin_core from constants.py) but does not include some glyphs mentioned in latin_unique-glyphs.nam - which seems to be the required list for submitting to Google Fonts
Expected behaviour
If latin_unique-glyphs.nam is the source of truth, GF_latin_core list should match.  Based on a very quick eyeball comparison of the two lists, there are at least three missing glyphs from GF_latin_core
0x2122  ™ TRADE MARK SIGN
0x2191  ↑ UPWARDS ARROW
0x2193  ↓ DOWNWARDS ARROW

I'm transferring and reopening this as there are bigger issues it covers than the narrower one that Felipe fixed in fontbakery


removing filters from doubleClickCallback to allow users to update text on arrowAnnotateTool

Please check if the PR fulfills these requirements

[x] The commit message follows our guidelines
[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
removing filters from doubleClickCallback to allow users to update text on arrowAnnotateTool

What is the current behavior? (You can also link to an open issue here)
It is not possible to update the text

What is the new behavior (if this is a feature change)?
now it is possible to update the text

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
No

:tada: This PR is included in version 3.18.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


@Getter annotation functions not recognised in latest Android Studio preview (1.3 Preview 5)

As of Android Studio preview 1.3, methods generated with @Getter and @Setter annotations are not recognised. This could be due to the recent changes under the hood for IntelliJ (C++/C support from Clion) which I think is based off IntelliJ 14.2?

Can you verify it with last plugin version (0.9.5) please?

Apologies for the delay. This appears to be fixed in the latest combination of Android Studio AI-141.2090522 and Lombok plugin <IP_ADDRESS>


fix panic during conflict resolution

Steve's KBFS was in a crash loop. He said he revoked a device hours ago. I think this is the correct fix for the crash as shown in the log, but I'm not sure if it'd crash somewhere afterwards.
Log send: https://keybase.io/_/admin/logdump_viewer?39510239#acad1c98d3388ec687e99b1c

Thanks for looking into this!  I prefer not to use SafeType on the client side, because it would hide exactly these kind of problems.
The problem seems to be that's there's a createOp in the set of merged ops coming from the server, and the op.finalPath never gets set in that case.
In this case, I think a better fix is to do this:
if p.FolderBranch.Tlf == tlf.NullID {
    return false
}

in this function: https://github.com/keybase/kbfs/blob/76a8bafb605d7227df72f2d55d7afdec7b4c0b3b/libkbfs/path.go#L98-L107
The best fix is probably to make sure that op.finalPath is always set, even for merged ops.  Or at least that op.finalPath.FolderBranch is set.  But that would be a bit more involved and probably not worth it.

Sounds good; thanks!


Model:  TaxonNameRelationship - add cached_is_synonym

We make a lot of queries that reference the constant TAXON_NAME_RELATIONSHIP_NAMES_SYNONYM in the where of taxon_name_relationships. Alternatively we could set a cached field boolean on TaxonNameRelationship, index that using our set_cached pattern, and run the queries against that boolean.
Pros:

Much shorter, and likely somewhat faster(?!), queries.

Cons:

Any cache can get out of sync, we'd have to have maintence tasks to rebuild, inevitably, at some time.

Note that an identical argument can be made for TaxonNameClassification, if we move forward on this one, do that one too.

I like to work with variable. From time to time we add additional classes in both TN relationships and classifications. Most of those are automatically added to the TAXON_NAME_RELATIONSHIP_NAMES_SYNONYM. In different places we use different variables, some of them are strict "synonyms" only. In other places are all invalid relationships, in some other places are misspelling relationships.

Points well taken @proceps, this is the Cons bit.  The only real reason this approch is justified is for performance reasons (and I suppose making the logs prettier, but that is very minor). So, we'd have to do some benchmarking.


Updating QuickStart

so that it reflects the readme in the RackHD repo

Needs a rebase.

I'm too git-dumb to figure out how to handle the conflicts....tried both command line and Github Desktop methods...really opaque process....

Leaving soon, but will try a rebase tomorrow....

I started trying it out, but there was more of a change diff than I felt I could resolve accurately.

@bossidy a decent guide here: http://www.git-scm.com/book/en/v2/Git-Branching-Rebasing

happy to help with any questions, hit me up on slack.

Thanks for the info Ben.


feat(manifest): node workspace package dependency updates

Introduces the concept of a "plugin" that can run after release-please
has generated changes but before the PR is created.
In order to support plugin releaser-post-processing (before submitting
the PR) we want to provide the whole contents of the changed file to the
plugin.

@chingor13

Can you add an expected usage example for this feature

I can add documentation on how to use this for sure. I wanted to get it out for some initial feedback first though in case it needs to change significantly before writing up a doc
Yes, the "plugin" exists in the release-please repo (currently just the one: src/plugins/node-workspace.ts
In the real world I've used this for our looker-open-source/sdk-codegen release PR. Here the node-workspace plugin correctly updated all our intra-monorepo-package-dependencies and added corresponding changelog entries.
@bcoe I think I've covered your initial around of feedback (mostly converting to snapshots).

@chingor13 I added a section to the manifest docs

thanks for landing this @bcoe
Are there any docs on local/branch testing release-please changes in the action? I want to test the dynamic importing of plugins in the action and make changes if needed


AttributeError: 'result' object has no attribute 'id'

Traceback (most recent call last):
File "/Users/Tyler/Desktop/cookie/env/lib/python2.7/site-packages/flask/app.py", line 1836, in call
return self.wsgi_app(environ, start_response)
File "/Users/Tyler/Desktop/cookie/env/lib/python2.7/site-packages/flask/app.py", line 1820, in wsgi_app
response = self.make_response(self.handle_exception(e))
File "/Users/Tyler/Desktop/cookie/env/lib/python2.7/site-packages/flask/app.py", line 1403, in handle_exception
reraise(exc_type, exc_value, tb)
File "/Users/Tyler/Desktop/cookie/env/lib/python2.7/site-packages/flask/app.py", line 1817, in wsgi_app
response = self.full_dispatch_request()
File "/Users/Tyler/Desktop/cookie/env/lib/python2.7/site-packages/flask/app.py", line 1477, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/Users/Tyler/Desktop/cookie/env/lib/python2.7/site-packages/flask/app.py", line 1381, in handle_user_exception
reraise(exc_type, exc_value, tb)
File "/Users/Tyler/Desktop/cookie/env/lib/python2.7/site-packages/flask/app.py", line 1475, in full_dispatch_request
rv = self.dispatch_request()
File "/Users/Tyler/Desktop/cookie/env/lib/python2.7/site-packages/flask_debugtoolbar/init.py", line 124, in dispatch_request
return view_func(**req.view_args)
File "/Users/Tyler/Desktop/cookie/env/lib/python2.7/site-packages/flask_login.py", line 758, in decorated_view
return func(args, **kwargs)
File "/Users/Tyler/Desktop/cookie/env/lib/python2.7/site-packages/flask_security/decorators.py", line 194, in decorated_view
return fn(args, **kwargs)
File "/Users/Tyler/Desktop/cookie/recruit_app/recruit_app/recruit/views.py", line 49, in application_queue
recruiter_queue = HrApplication.query.whoosh_search('' + str(search_form.search.data) + '').paginate(page, current_app.config['MAX_NUMBER_PER_PAGE'], False)
File "/Users/Tyler/Desktop/cookie/env/lib/python2.7/site-packages/flask_sqlalchemy/init.py", line 440, in paginate
total = self.order_by(None).count()
File "/Users/Tyler/Desktop/cookie/env/lib/python2.7/site-packages/sqlalchemy/orm/query.py", line 2734, in count
return self.from_self(col).scalar()
File "/Users/Tyler/Desktop/cookie/env/lib/python2.7/site-packages/sqlalchemy/orm/query.py", line 2513, in scalar
ret = self.one()
File "/Users/Tyler/Desktop/cookie/env/lib/python2.7/site-packages/sqlalchemy/orm/query.py", line 2482, in one
ret = list(self)
File "/Users/Tyler/Desktop/cookie/env/lib/python2.7/site-packages/flask_whooshalchemy.py", line 75, in iter
self._primary_key_name))], row))
AttributeError: 'result' object has no attribute 'id'
relevant models found at https://github.com/tyler274/Recruitment-App/blob/master/recruit_app/user/models.py

probably caused by issue #14


Can't find cascaded parent element with ID: TblPrTran!

Hi everyone!
I'm having a problem with cascading field
Actually I have created module called PurchaseOrder where I use foreign key of PurchaseRequisition table i.e.  PrId (Below file contains screenshot of that)

Now i want to update my Items   from detail section on selection of Perticular PrId And I use cascading for that

But it shows error

I also refer #968 but couldn't find any solution........please help!!

Cascaded element must be in same form, before the editor.


Refactor to support alternate project file and copy to location for testing credentials

[ ] @BDHernand For this file https://github.com/IBM-Swift/BluePic/blob/setup_travis/.travis.yml, let's have the all the logic that pertains to iOS inside the conditional for OS X.

@BDHernand  Just reviewed the changes. Let’s do this to simplify the logic:

Let’s start by refactoring again the BluePic-Testing-Credentials repo and get rid of the parent BluePic folder. In other words, the BluePic-Server, BluePic-iOS, etc. folders should all be peers and exist at the root level of the repo.

Let’s make the build_package.sh script accept only 3 parameters:

branch - This will go away but keeping it for now so you don’t have to deal with the PRs at the moment (this is one simply stays as is).
projectBuildDir - This will be the path to the main directory of the project (i.e. $TRAVIS_BUILD_DIR)
credentialsDir - This is the full path to the credentials repo for the project.
For Kitura-CouchDB, this is -> $TRAVIS_BUILD_DIR/Kitura-TestingCredentials/Kitura-CouchDB. For BluePic, this is => $TRAVIS_BUILD_DIR/BluePic-Testing-Credentials.

Note there is no need for alternate_project_folder or alternate_copy_location parameters. Also, note that we are removing build_dir as a parameter; we no longer need it. build_dir is only used to invoke install_swift_binaries.sh. Hence, let’s simply do this now:
source ${projectFolder}/Package-Builder/${osName}/install_swift_binaries.sh $projectFolder

In build_package.sh, we will also need these minor changes:

# Copy test credentials for project if available
if [ -e "${credentialsDir}" ]; then
   echo ">> Found folder with test credentials."
   # Copy test credentials over
   echo ">> copying ${credentialsDir} to ${projectBuildDir}"
   cp -RP ${credentialsDir}/* ${projectBuildDir}
else
   echo ">> No folder found with test credentials."
fi

I think that's it. I may have overlooked something; if you find that's the case, let's chat tomorrow and we will adjust the above accordingly.

@rolivieri lets chats about this once you get in.  BTW I ran Kitura-Couch DB against my branch and it worked fine with my new changes

@rolivieri put in the new changes.  Running Kitura-CouchDB against it now.  Mac on BluePic is failing... started the mac build again.  Looks like a collision or something.. code looks clean

@BDHernand Can you make sure we use the variable names defined above:
projectBuildDir  and credentialsDir?  These new names match the new meaning we are now giving to these variables. Thanks.


How can I install it?

I need to use it with x64dbg. However I'm green. Do I need to compile it?

You don't need to compile if you don't want to, just grab the compiled version
https://github.com/ThunderCls/xHotSpots/releases

Hi, ThunderCls.
I copy the xHotSpots.dp32 to x64dbg/release/x32/plugins/ directory, but then the x32dbg is crashed.
I tryed lots of x64dbg version.
Could you give a help?

You need to have .NET libs installed in your system for this plugin to work. Did you check on those?. Also make sure you are using the plugin in a fresh/updated and with no other plugins x64dbg version


Publisher module create 2 different subscriptions with one config

Recently, we encountered a problem that affected our production system. At some point in time, we started receiving duplicated OPC UA messages. The difference of messages we received is only 100ms and a big gap of sequence number:

When I check the publisher module logs, I saw that the module created 2 subscriptions with for the same endpoint, same DataWriterId as shown here

This is the diagnostic log of these 2 subscriptions:
[2024-09-20 08:59:13.738 INF Microsoft.Azure.IIoT.OpcUa.Edge.Publisher.Engine.DataFlowProcessingEngine]
  DIAGNOSTICS INFORMATION for          : opc.tcp://<IP_ADDRESS>:4840/_C68C2A04_opc.tcp://<IP_ADDRESS>:4840
  # Ingestion duration                 :    00:02:59:59 (dd:hh:mm:ss)
  # Ingress DataChanges (from OPC)     :            969 (All time ~0.09/s; 00 in last 60s ~0/s)
  # Ingress ValueChanges (from OPC)    :          7,980 (All time ~0.74/s; 00 in last 60s ~0/s)
  # Ingress BatchBlock buffer size     :              0
  # Encoding Block input/output size   :              0 | 0
  # Encoder Notifications processed    :          7,908
  # Encoder Notifications dropped      :              0
  # Encoder IoT Messages processed     :            968
  # Encoder avg Notifications/Message  :              8
  # Encoder avg IoT Message body size  :          4,944 (2%)
  # Encoder avg IoT Chunk (4 KB) usage :            1.2
  # Estimated IoT Chunks (4 KB) per day:         15,488
  # Outgress Batch Block buffer size   :              0
  # Outgress input buffer count        :              0
  # Outgress input buffer dropped      :              0
  # Outgress IoT message count         :            968 (0.09/s)
  # Connection retries                 :              0
  # Opc endpoint connected?            :           True
  # Monitored Opc nodes succeeded count:             72
  # Monitored Opc nodes failed count   :              0

[2024-09-20 08:58:50.555 INF Microsoft.Azure.IIoT.OpcUa.Edge.Publisher.Engine.DataFlowProcessingEngine]
  DIAGNOSTICS INFORMATION for          : opc.tcp://<IP_ADDRESS>:4840/_C68C2A04_opc.tcp://<IP_ADDRESS>:4840
  # Ingestion duration                 :    00:00:55:00 (dd:hh:mm:ss)
  # Ingress DataChanges (from OPC)     :            169 (All time ~0.05/s; 00 in last 60s ~0/s)
  # Ingress ValueChanges (from OPC)    :          1,372 (All time ~0.42/s; 00 in last 60s ~0/s)
  # Ingress BatchBlock buffer size     :              0
  # Encoding Block input/output size   :              0 | 0
  # Encoder Notifications processed    :          1,372
  # Encoder Notifications dropped      :              0
  # Encoder IoT Messages processed     :            169
  # Encoder avg Notifications/Message  :              8
  # Encoder avg IoT Message body size  :          4,909 (2%)
  # Encoder avg IoT Chunk (4 KB) usage :            1.2
  # Estimated IoT Chunks (4 KB) per day:          8,849
  # Outgress Batch Block buffer size   :              0
  # Outgress input buffer count        :              0
  # Outgress input buffer dropped      :              0
  # Outgress IoT message count         :            169 (0.05/s)
  # Connection retries                 :              0
  # Opc endpoint connected?            :           True
  # Monitored Opc nodes succeeded count:             72
  # Monitored Opc nodes failed count   :              0

Enclosed here are full logs file at the time problem happened and the configuration saved in CosmosDb:
cosmosDb.txt
FITS4U_GW_6201_publisher_Logs.txt

Publisher module: v2.8.6 in Orchestrated mode

Unfortunately 2.8 and in particular orchestrated Mode are no longer supported. Please see https://github.com/Azure/Industrial-IoT?tab=readme-ov-file#supported-releases-and-support-policy for more info.  The latest version is 2.9.11.


Implemented more API complete container listing

This PR extends the container listing API documented in https://docs.docker.com/engine/api/v1.35/#operation/ContainerList.
All parameters except limit are now supported, especially size and filters.

Pull Request Test Coverage Report for Build 576

34 of 46 (73.91%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.9%) to 89.683%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/main/java/com/amihaiemil/docker/ListedContainers.java
31
43
72.09%

Totals

Change from base Build 575:
-0.9%

Covered Lines:
878

Relevant Lines:
979

💛  - Coveralls

@amihaiemil Is test coverage for contributed code a hard requirement?
I just fixed some tests to reflect the new code structure with ListedContainers.

This pull request #315 is assigned to @paulodamaso/z, here is why; the budget is 15 minutes, see §4; please, read §27 and when you decide to accept the changes, inform @amihaiemil/z (the architect) right in this ticket; if you decide that this PR should not be accepted ever, also inform the architect; this blog post will help you understand what is expected from a code reviewer; there will be a monetary reward for this job

@milux @paulodamaso Whatever the implementation details are, it doesn't matter as long as we can agree on the interfaces and class encapsulation.
Maybe @milux will provide more PRs, so we can adjust implementation details on the go.
@milux As guidelines, whenever you want to provide a PR, open an Issue about it first, so we can discuss there your ideas before you make a PR, it will be easier.

@amihaiemil I totally agree, however, you may want to update your README to reflect this, because it now says If you would like to contribute, just open an issue or a PR., which AFAIK doesn't reflect this organizational philosophy. :wink:

What's missing for merge? Test coverage? Anything else?

@milux @paulodamaso Guys, you seem to be having a long conversation I am honestly a bit lazy to follow. Just agree on the interface and details of implementation can be fixed later.
@milux About Decorator: we do use Decorator extensively. We believe Decorator is the most important pattern in OOP. We are actually practicing a more or less novel kind of OOP, called "Elegant Objects": https://www.elegantobjects.org/
I'm not sure what you guys are discussing about a Filtered pattern, but here is an example of such a Filtered class: https://amihaiemil.com/2018/11/10/an-extension-to-telldontask.html
Thanks,
Mihai

@milux And anyway, I remember I have already implemented some Filtering in the library, somewhere. Is it not possible to follow that same pattern?
If you are following that same pattern, then it's ok :) I would just ask you to not decrease Test Coverage :D

@milux And anyway, I remember I have already implemented some Filtering in the library, somewhere. Is it not possible to follow that same pattern?
If you are following that same pattern, then it's ok :) I would just ask you to not decrease Test Coverage :D

I am following the exact same pattern, it's not a decorator pattern, and I still believe that it's the best way how in can be done in terms of code design.

@milux @amihaiemil Please take a look at the comments

Please see above, your comments somehow got duplicated as far as I can tell, and I commented above.

@milux If it's the same pattern, it's fine. Just please don't decrease test coverage. Is it possible or too complicated? :D
@paulodamaso Let this one to me please :D

@milux If it's the same pattern, it's fine. Just please don't decrease test coverage. Is it possible or too complicated?

Fun fact: It's exactly what you described in https://amihaiemil.com/2018/11/10/an-extension-to-telldontask.html, and I don't get how @paulodamaso wants to apply the decorator pattern here, see above. I really don't want to be rude to anybody, but to me the suggestion just doesn't make any sense. Maybe @paulodamaso and I are simply talking at cross purposes...
Regarding the test coverage: Agreed, working on it...

@amihaiemil Unit tests implemented, overall coverage has increased. :smile:
Ready for merge?

Just got the last LOC covered as well, commit is on the way...

@milux Don'ty worry about being rude, you aren't. Just for clarifying the idea about decorators. I was thinking in something like this:

@milux Vielen Dank!
However, Rultor has problems still. I am trying to fix the issue as soon as possible so we can release 0.0.11. See the latest opened Issue for the progress...

Job was finished in 29 hours, bonus for fast delivery is possible (see §36)

Order was finished: +20 point(s) just awarded to @paulodamaso/z

Payment to ARC for a closed pull request, as in §28: +10 point(s) just awarded to @amihaiemil/z