Desired opening option for dropdownbutton

Is there an existing issue for this?

[X] I have searched the existing issues
[X] I have read the guide to filing a bug

Use case
DropdownButton should have the possibility to open below itself. At the moment this is not an option.
See your own example: https://api.flutter.dev/flutter/material/DropdownButton-class.html
In there the dropdownbutton opens above the button itself.
Proposal
PopupMenuButton has the possibility to change the starting offset. By changing the offset to 40 the PopupMenuButton opens below itself:
 PopupMenuButton(                   offset: const Offset(0, 40),
Please can you add this to DropdownButton as well? And thuse allow Dropdownbutton to open below itself.
It seems that Dropdownbutton2 from pub.dev does open as desired just below the dropdownbutton2 itself. However that is not a flutter package and thus I prefer not to use it in production apps.
https://pub.dev/packages/dropdown_button2

Hi @bochelie1000. This seems to be about DropdownButton being customizable in which there is a currently open issue https://github.com/flutter/flutter/issues/25151, you can upvote and comment on the existing issue. Kindly confirm this suits your case as well.

My question is for a different option however, it is a customization. If it is better to add it to that question than lets do it.

Thanks a lot for filing this issue! Have you tried our M3 MenuAnchor or DropdownMenu? By customizing leadingIcon in DropdownMenu, I think we can set some offset before the leading widget:)

Thanks a lot for filing this issue! Have you tried our M3 MenuAnchor or DropdownMenu? By customizing leadingIcon in DropdownMenu, I think we can set some offset before the leading widget:)

Well, I really needed the DropDownButton because of some functionality which I cant remember now. I tried the DropdownMenu but this could not do what I want. I dont remember if I tried MenuAnchor, but I probably would because I remember trying a lot of things.

Is there any update or workaround on How to achieve this using DropdownMenu?

Only thing I know is that you should use DropdownMenu instead of DropdownButton which this question was orginaly ment for if using Material3.
From what I see DropdownMenu is very nice and does automatically open to the bottom if there is space for it.
It is a pity that their is little feedback on this.
See example at https://api.flutter.dev/flutter/material/DropdownMenu-class.html


WIP: cranelift: omit function prologue and epilogue on x64 if possible

This makes cranelift omit the function prologue and epilogue on the x64 architecture if possible, like it already does for aarch64.
However, this is not quite right yet, because (if I understand correctly) the is_leaf computation is wrong for x64 when SIMD instructions are involved. With this change, this function gives a segfault:
function %swizzle_i8x16(i8x16, i8x16) -> i8x16 {
block0(v0: i8x16, v1: i8x16):
    v2 = swizzle v0, v1
    return v2
}

I think this happens because it generated this assembly:
pushq   %rbp
movq    %rsp, %rbp
paddusb 0x14(%rip), %xmm1
movabsq $0, %r9
callq   *%r9
movq    %rbp, %rsp
popq    %rbp
retq
addb    %al, (%rax)
jo      0x92
jo      0x94
jo      0x96
jo      0x98
jo      0x9a
jo      0x9c
jo      0x9e
jo      0xa0

Note that there's a callq in there, which means that this is not a leaf function, but according to the architecture-independent is_leaf function of FunctionStencil it looks like a leaf function, because that only considers calls in CLIF.
With ssse3 the call disappears and the test passes.
This means that I need some advice on how to proceed. I could try to make the is_leaf function architecture-dependent or conservatively treat (some?) SIMD instructions as calls in general. Or maybe the information that I need is already computed somewhere and I just need to pass that in? Or I could remove this optimization if ssse3 or later is not supported, but that doesn't seem great 😄
This replaces https://github.com/bytecodealliance/wasmtime/pull/5352 and is a follow up of https://github.com/bytecodealliance/wasmtime/pull/2960. I'm not sure why I'm getting to the conclusion that SIMD is the issue, but it wasn't mentioned before. Maybe there are other issues as well. Has the testing setup become more robust in the meantime?

Neat! I was thinking about working on this soon, because the work that Trevor and I have been doing on cleaning up tail calls has fixed some of the issues that would have made this even harder. But it's even cooler to see somebody else tackling this and I would love to see you continue.
One thing I notice is that cranelift/filetests/filetests/isa/x64/simd-lane-access-compile.clif turns on SSSE3, so the case you're running into isn't represented in our compile tests. That would be good to fix.
After deleting has_ssse3 has_sse41 from that file and re-running the filetests with CRANELIFT_TEST_BLESS=1, I see that this call is a lib-call to X86Pshufb.
That's not the only lib-call we may emit on x86; there are also functions implementing floating-point fused multiply-add (FmaF32/64) and various floating-point rounding modes (Ceil/Floor/Nearest/Trunc), for older CPUs without the corresponding instructions.
So this isn't specifically a SIMD issue, and it doesn't apply to most SIMD instructions either. But I'm also not sure where the segfault you saw came from. Off hand, I don't know why omitting a frame pointer would cause a function call to segfault. So more investigation is in order, I think!

After deleting has_ssse3 has_sse41 from that file and re-running the filetests with CRANELIFT_TEST_BLESS=1, I see that this call is a lib-call to X86Pshufb.

Yes, that's what I found too.

That's not the only lib-call we may emit on x86; there are also functions implementing floating-point fused multiply-add (FmaF32/64) and various floating-point rounding modes (Ceil/Floor/Nearest/Trunc), for older CPUs without the corresponding instructions.

My (unsubstantiated) guess is that the X86Pshufb function is more complex than those other lib-calls and therefore causes trouble. Replacing the lib call with a custom function in the final x86 does not seem to cause any trouble, so it's not any call that leads to a segfault.
Is this the code for the libcall? https://github.com/bytecodealliance/wasmtime/blob/d911f4b10fe908bc819a1420482952e44b039db3/crates/wasmtime/src/runtime/vm/libcalls.rs#L736
At the top of that file, it says:

They must only contain basic, raw i32/i64/f32/f64/pointer parameters that are safe to pass across the system ABI.

Maybe part of the problem is that x86pshufb requires __m128i as arguments? Or that it requires bumping some things on the stack while the others don't? I don't really know, I'm just guessing at this point.

From what I remember when I looked into this a year or so ago was that this was an issue with stack alignment. I think that the libcalls expect a 16byte aligned stack on entry (due to ABI) and will use aligned loads and stores on the stack directly.
Take this with a grain of salt, since it has been a while since I last looked at this.

Interesting! @afonso360, do you know of a way that I could check that hypothesis?

I should also note that not all libcalls will come from wasmtime/crates/wasmtime/src/runtime/vm/libcalls.rs. They can be provded by the system's libc or whatever the linker decides, in cases where cranelift isn't used with wasmtime.

Good to know! Thanks!
I wonder if there's some easy way that we can enable this for everything that doesn't involve libcalls? Is there a way to check whether a function will contain libcalls?

Well, I'd check if the code segfaults in a 16byte aligned load inside the libcall that is referencing the stack and that that address ends up being under-aligned (i.e. only aligned to 8 bytes or less).
And additionally the stack at the entrypoint of that libcall was only aligned to 8 (this by itself is an ABI breakage).
You should be able to do this by running the test under gdb/lldb and setting a breakpoint in the libcall function and checking what the stack pointer is, and where it first crashes, etc...
It would also be nice if we had a libcall that didn't use any SSE instructions or referenced the stack, that would be also another clue that our issue was with that, but we don't.

We compute the frame layout after lowering to vcode, so I think we can make the decision about whether this is a leaf function after we've already made all the decisions about whether to use any libcalls. We "just" need to thread that information through correctly somehow.

That sounds reasonable. I'll give that a shot!

Oh, I also wanted to note: Good points, both of you, on stack alignment and vector arguments. I hadn't thought about either of those things and I think together they fully explain this symptom. I want to write down this conclusion for future reference although I don't think either of you need the explanation :grin:
Pushing the return address leaves the stack 8-aligned, and normally pushing the frame pointer would make it 16-aligned again, but we skip that step here. Then, most x86 code can actually tolerate 8-aligned stacks, but moving between MMX registers and memory generally requires 16-alignment, and indeed it looks like Rust/LLVM are producing movdqa instructions with 16-aligned offsets from the stack pointer in this particular libcall.
So that explains why you'd only see problems with this specific call. We still should ensure that all libcalls get the ABI-required stack alignment though, so the plan to have any function with a libcall not be a leaf function is still a good one.

I did in fact need that conclusion 😄 Thanks!

I'm looking at this again and I might need some help. I'm struggling to find where this information should originate from. Is there some struct that can keep track of a boolean or should we scan over the emitted instructions? Or maybe the dfg should also keep track of the libcalls that have been made in addition to the signatures and ext_funcs?
I'm a bit overwhelmed at the moment :)

I'm looking at this again and I might need some help. I'm struggling to find where this information should originate from. Is there some struct that can keep track of a boolean …

Yeah, totally reasonable questions!
I would start by looking at how outgoing_args_size and tail_args_size get computed and used, since those are also properties of the function calls that appear in the current function.
In cranelift/codegen/src/machinst/abi.rs, there are methods on Callee named accumulate_outgoing_args_size and accumulate_tail_args_size. You can look for where these are called. Those are places where, while lowering the body of the function, we found a function call. I don't remember exactly but libcalls should be similar.
Note that if you're using rust-analyzer to navigate, there are some nearby parts of the call-graph that it can't find because they're in macros, so if you hit a point where things seem to be missing you might also want to try just searching for the function's name. Someday I hope to reduce our usage of macros…
Those *_args_size fields are stored on the Callee until Callee::compute_frame_layout is called, and then they're forwarded to the backend's implementation of ABIMachineSpec::compute_frame_layout.
There's another field on Callee that's also forwarded, is_leaf. Maybe the thing to do here is just set that to false if there's any kind of function call, including libcalls.

After a little more investigation: the is_leaf field is currently set by calling FunctionStencil::is_leaf, which tries to guess whether there are function calls or libcalls, and which is not used anywhere else. Let's just delete that method, and compute the true answer during lowering.


feat: add data-admin inside db-dashboard

From: https://github.com/platformatic/platformatic/pull/410

Fixes: https://github.com/platformatic/platformatic/issues/347
This PR makes PR https://github.com/platformatic/platformatic/pull/404 outdated
Could fix issue https://github.com/platformatic/platformatic/issues/346

@mcollina

Using the application of our tutorial (the movie app), it's not displaying the quotes:
...
Also the edit field is incorrect, as it's picking up a dropdown:

I think to understood the problem.
I seen the movie-quotes SQLite schema and the table quotes (plural name) has a field named quote (singular name).
So I think that the schema analyzer internally used (by api-platform/admin) detect the field quote as a reference field to a record of the quotes entity, instead of a simple text field.

Here, the problem with api-platform/api-doc-parser.
https://github.com/api-platform/api-doc-parser/blob/895cd81e4208c8c70a7383f65cefc31f1706c353/README.md?plain=1#L57

In order to reference the resources between themselves (embeddeds or relations), the library guesses embeddeds or references from property names.
For instance if a book schema has a reviews property, the library tries to find a Review resource.
If there is, a relation or an embedded between Book and Review resources is made for the reviews field.
The property name can also be like review_id, reviewId, review_ids or reviewIds for references.

https://github.com/api-platform/api-doc-parser/blob/895cd81e4208c8c70a7383f65cefc31f1706c353/src/openapi3/handleJson.ts#L249
  // Guess embeddeds and references from property names
  resources.forEach((resource) => {
    resource.fields?.forEach((field) => {
      const name = inflection.camelize(field.name).replace(/Ids?$/, "");

      const guessedResource = resources.find(
        (res) => res.title === inflection.classify(name)
      );
      if (!guessedResource) {
        return;
      }
      field.maxCardinality = field.type === "array" ? null : 1;
      if (field.type === "object" || field.arrayType === "object") {
        field.embedded = guessedResource;
      } else {
        field.reference = guessedResource;
      }
    });
  });

I think we have two options:

Try sending a PR for the schema analyzer used by api-platform/admin
Write our own schema analyzer with our logic inside platformatic

other ideas?

Rename quote property in another name (quoteText?) within quotes entity 😉

Soo.. how do we move it forward?

Soo.. how do we move it forward?

Option 3 is the best choice ;)
I sent a PR for the tutorial (the movie app):
https://github.com/platformatic/tutorial-movie-quotes-app/pull/16

I think we should aim to support generic schemas, we should not be relying on the name of properties.

I think we should aim to support generic schemas, we should not be relying on the name of properties.

Sure, the option 3 is the best short time-consumed choice, while your thinking is the best functionally choice
... however I ask myself why you do not told me your opinion before. :sweat_smile:
You have to know that we are already analyzing the property names to found relations between the entities.
The behaviour difference between the current 'table-view' (react-admin based version) and next candidate data-admin (api-platform based version) is due to the different analyzer used by react-admin and api-platformatic.
At this point, if we do not want to find relationships by property names, we could:
a) Implement a new json schema (separated from openapi) with all metadata information like entities, fields, relationships and so on.
b) Change the data-admin to use the new json schema in point a) so that it nolonger parser property names in openapi json to detect meta informations.
In my opinion point a) is a cool feature regardless of data-admin requirements.

however I ask myself why you do not told me your opinion before.

I didn't understand what you were proposing. I kept asking clarifying questions until I saw your proposed change.

a) Implement a new json schema (separated from openapi) with all metadata information like entities, fields, relationships and so on.

Hard no. OpenAPI should be enough to express all of this. I think it's a matter to identify what's missing, add it in a way that's consistent with the ecosystem.
Note that API Platform admin has an OpenAPI analyzer that we are not using in this PR.

... OpenAPI should be enough to express all of this. I think it's a matter to identify what's missing, add it in a way that's consistent with the ecosystem.

OpenAPI just misses the entity relationships (attributes like: "primary key", "foreign keys", etc.)
See also here, please:
https://github.com/platformatic/platformatic/pull/384#issuecomment-1326758270

Note that API Platform admin has an OpenAPI analyzer that we are not using in this PR.

Is there also information about relationships?

I think we should aim to support generic schemas, we should not be relying on the name of properties.

I strongly agree with this. If we rely on specific naming then I anticipate developers running into frustrating and hard to debug edge cases.

I would recommend you try https://api-platform.com/docs/admin/components/#openapi, it might be better than our implementation.

I would recommend you try https://api-platform.com/docs/admin/components/#openapi, it might be better than our implementation.

😕
I'm already using api-platform-components in this implementation (data-admin)...
See devDependencies, please.

I did, and I check the code too. You are not using the OpenAPIAdmin class, but rather AdminGuesser: their docs explicitly mention using OpenAPIAdmin.
// App.js
import { OpenApiAdmin, ResourceGuesser } from "@api-platform/admin";

const App = () => (
  <OpenApiAdmin
    entrypoint={entrypoint}
    docEntrypoint={docEntrypoint}
    dataProvider={dataProvider}
    authProvider={authProvider}
   >
     <ResourceGuesser name="books" />
     { /* ... */ }
  </OpenApiAdmin>
);

export default App;

Thanks for the clarification. From their docs:

In order to reference the resources between themselves (embeddeds or relations), the library guesses embeddeds or references from property names. For instance if a book schema has a reviews property, the library tries to find a Review resource. If there is, a relation or an embedded between Book and Review resources is made for the reviews field. The property name can also be like review_id, reviewId, review_ids or reviewIds for references.

I'm not 100% sure what the best path is, but this looks extremely unreliable. My understanding of the OpenApi spec is that a link should be used instead of guessing  the name.
Maybe you should open an issue there to see if they would be ok in a contribution (https://github.com/api-platform/api-doc-parser).

Yes links are already supported here: https://github.com/platformatic/platformatic/blob/main/packages/sql-openapi/lib/entity-to-routes.js.

Still valid, @mcollina ??:)

Yes

this needs to move, I feel.. We should get rid of older CLs/PRs 🙂


Help: BitVector error on simple example.

I've written a very simple example and I'm getting errors. The program below, when run on my machine, gives back: libc++abi: terminating with uncaught exception of type std::out_of_range: BitVector: accessing 0 of 0.
If I change the variable c from the xor (^) of a and b to the and (&) of a and b, then the programs enter deadlock. I am running as $ ./test 0 & ./test 1 where test is the name of the executable.
My guess is that it is user error on my part. Could you help me understand how I am misusing the library?
#include "base/party.h"
#include "protocols/share_wrapper.h"
#include "utility/bit_vector.h"
#include "communication/communication_layer.h"
#include "communication/tcp_transport.h"

using namespace encrypto::motion;

Party MakeParty(size_t my_id, const char **hosts, ushort *ports, size_t len) {
  communication::TcpPartiesConfiguration parties_configuration(len);

  for (size_t party_id = 0; party_id < len; party_id++) {
    std::string host(hosts[party_id]);
    ushort port = ports[party_id];
    parties_configuration.at(party_id) = std::make_pair(std::string(hosts[party_id]), ports[party_id]);
  }

  communication::TcpSetupHelper helper(my_id, parties_configuration);
  auto communication_layer = std::make_unique<communication::CommunicationLayer>(my_id, helper.SetupConnections());
  return Party(std::move(communication_layer));
}

ShareWrapper MakeBoolShare(Party& party, bool share) {
  BitVector share_bv(share);
  std::span input(&share_bv, 1);
  return ShareWrapper(party.SharedIn<MpcProtocol::kBooleanGmw>(input));
}

int main(int argc, char *argv[]) {
  size_t my_id = atoi(argv[1]);
  const char *hosts[2] = { "<IP_ADDRESS>", "<IP_ADDRESS>" };
  ushort ports[2] = { 23000, 23001 };
  Party party = MakeParty(my_id, hosts, ports, 2);
  ShareWrapper a = MakeBoolShare(party, my_id == 0 ? false : true);
  ShareWrapper b = MakeBoolShare(party, my_id == 0 ? false : true);
  ShareWrapper c(a ^ b);

  party.Run();
  party.Finish();

  std::cout << my_id << ": " << c.As<bool>() << std::endl;

  return 0;
}

Okay, after some experimenting it seems like I'm constructing the std::span<BitVector<>> incorrectly when constructing the shares. Not sure how yet though.

Looks like doing BitVector share_bv(1, share); rather than BitVector share_bv(share); has fixed it for me. Perhaps the BitVector constructor for just bool is broken / only meant for internal use?

The thing is, there is no BitVector(bool value) constructor. I think that bool gets promoted to a size_t and this constructor gets called as BitVector(static_caststd::size_t(value), false), so 0 bits in case of value == false (default-initialized as false). Yes, that's quite hard to spot, but I, spontaneously, don't see a good solution. Any suggestions are very welcome.
IIRC, the problem was that by adding an explicit BitVector(bool) constructor, calls to BitVector(std::size_t, bool value = false) don't get implicitly converted from other types, e.g., BitVector(10) would not compile, so you would always need to write BitVector(std::size_t(10)). Thus, I decided to stick to an API more similar to std::vector.

Thanks for clarifying!
It might be nice for others to have some documentation of how to use the BitVector constructor(s) more readily available. I figured it out by looking at the definition of ToInput, specifically this line: https://github.com/encryptogroup/MOTION/blob/master/src/motioncore/utility/bit_vector.cpp#L1099.
Perhaps there's a use of the BitVector(size_t, bool) constructor elsewhere which you can use as documentation for newcomers? I looked in https://github.com/encryptogroup/MOTION/blob/master/src/test/test_bgmw.cpp briefly but nothing stuck out. Understandably, all the inputs being constructed are > 1 bit.
Is there a test (perhaps in https://github.com/encryptogroup/MOTION/blob/master/src/test/test_bgmw.cpp) which uses BitVector(size_t, bool) constructor?
If so, it might be nice for newcomers to explicitly link to it


Added the function remove_unordered to the LocalVector container.

Added function remove_unordered to LocalVector.
Sometimes you don't need to keep the vector's order, so you can just remove the item by swapping the item you need to remove with the last one. With remove_unordered it's possible to avoid the extra copies that the remove function does to maintain the original insertion order.

Totally agree to adding this, just a couple of small things:

I'm wondering whether remove_fast is the best name? I don't really have an ideal name, but also think worth considering is:
remove_unsorted (or remove_unordered) to emphasise the difference from a standard remove?

This could be easier when reading in terms of finding bugs, because you can instantly mentally check whether these conditions are being violated, and also useful for newbies to understand what an existing bit of code is doing. remove_fast tells us very little, and could even lead to misguided attempts to replace remove with remove_fast.
On the flip side the alternative name doesn't emphasise that it is faster, this would have to be mentioned in the documentation / comments.

For simple pod types especially, could it be better to omit the if check before doing the swap? Worst case, assigning a simple small type to itself costs very little. Whereas doing the if check every time in a tight loop could be expensive. Being a template you could also have a compile time switch for this depending on the sizeof the structure etc.

I agree and I think that remove_unordered is the best solution.

For simple pod types especially, could it be better to omit the if check before doing the swap? Worst case, assigning a simple small type to itself costs very little. Whereas doing the if check every time in a tight loop could be expensive. Being a template you could also have a compile time switch for this depending on the sizeof the structure etc.

I don't think it would make any difference. The code into the IF is so little that the entire statement is likely to enter into the CPU cache, so the produced jump is so little that is not going to improve or change performances. Also, is super easy for the compiler understand the pattern and so cache the call statements in the correct way.

Renamed

Note that unit tests can also be written to cover the new functionality, although there's no tests written for LocalVector in the first place. 😕
See Unit testing documentation for instructions, if you wish.
It's also possible to write stress tests, to demonstrate the efficiency of the new method when comparing with the existing remove (when running tests with --test --duration).

This is a good idea, to be honest. I'll add it yes.

@Xrayez I've added the unit LocalVector test, let me know.

@Xrayez I've added the unit LocalVector test, let me know.

Done

Done

Thanks!

Thanks!


Report QA: Confirm assets via WhoIs service

💡 Summary
A secondary check/script is needed to validate data feeds which include a list of a customer's assets. A "net-range validation process" or "whois" check is needed to filter bad assets.
Motivation and context
This improves the quality of the report through validation and cuts down on any speculative data included in the reports.
Implementation notes
Please provide details for implementation, such as:

Define Solution

Acceptance criteria
How do we know when this work is done?

[ ] IP Addresses should be pulled from the CyHy database instead of LG to identify IP Addresses that are valid for the particular agency.
[ ] The team should be able to perform asset checks on a regular basis to determine if the current IP addresses on record with CyHy are valid.

@schmelz21
Im including all cidr noted ip blocks. Also rolling in the LG ip addresses(one time basis) will check the ip's whenever the scans run in the future.

WHOIS data service has been in use and merged into develop(unsure of PR#).


Aeron Java API - Publisher always gets BACK_PRESSURED error after ~500k messages

I have a Publisher and Subscriber application using Aeron Java API on a Windows box.
They establish a communication via aeron:ipc protocol.
The Publisher keeps sending messages onto the channel successfully.
After ~500k messages, BACK_PRESSURED error is returned and the Publisher is not able to sent any more messages. Every attempt afterwards will return a BACK_PRESSURED error.
The Subscriber is able to receive all the messages using the BusySpinIdleStrategy():
    final IdleStrategy idleStrategy = new BusySpinIdleStrategy();
    (new Thread(new Runnable() {
        public void run() {
            while (connection.isOn()) {
                idleStrategy.idle(subscription.poll(fragmentHandler, 100));
            }
        }
    })).start();

The FragmentHandler simply gets the message bytes and does nothing:
    final FragmentHandler fragmentHandler = new FragmentAssembler(new FragmentHandler() {
        public void onFragment(DirectBuffer buffer, int offset, int length, Header header) {
            try {
                final byte[] data = new byte[length];
                buffer.getBytes(offset, data);
                //Do nothing
            } catch(Exception e) {}
        }
    });

It seems the messages sent over the channel remain in there and prevents the Publisher to push new data.
Am I missing something?

There might be a few things going on here, without seeing your entire code its hard to know what exactly is wrong.

Do you have another subscription to the same stream? if you're not polling this subscription or it isn't making progress then you might get back pressured.

If you receive a back pressure message at your publisher then you need to retry that operation.  Does it eventually publish a message or is it just blocked?

Hi, Richard.
Thanks for the input. At a closer look, I do have multiple subscriptions on the same stream, by mistake,
and this was creating the BACK_PRESSURE at Publisher side.
Thanks for your help!

Happy to be of help.


keepwn: 0.1 -> 0.3

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for keepwn is: Tool to automate KeePass discovery and secret extraction
meta.homepage for keepwn is: https://github.com/Orange-Cyberdefense/KeePwn
meta.changelog for keepwn is: https://github.com/Orange-Cyberdefense/KeePwn/releases/tag/0.3
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.3 with grep in /nix/store/25nqcjw4s56s8yhq3y0rxbh9f896sqxk-keepwn-0.3
found 0.3 in filename of file in /nix/store/25nqcjw4s56s8yhq3y0rxbh9f896sqxk-keepwn-0.3

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
keepwn

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/25nqcjw4s56s8yhq3y0rxbh9f896sqxk-keepwn-0.3 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A keepwn https://github.com/r-ryantm/nixpkgs/archive/04b74986cd766a51440d9480a8d47eec7df0502c.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/04b74986cd766a51440d9480a8d47eec7df0502c#keepwn

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/25nqcjw4s56s8yhq3y0rxbh9f896sqxk-keepwn-0.3
ls -la /nix/store/25nqcjw4s56s8yhq3y0rxbh9f896sqxk-keepwn-0.3/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

keepwn

Maintainer pings
cc @fabaff for testing.

Result of nixpkgs-review pr 281944 run on x86_64-linux 1

2 packages built:

keepwn
keepwn.dist


Support load more in Table and List component

Closes https://github.com/carbon-design-system/carbon-addons-iot-react/issues/2773
Summary

Support load more for Table and List

Change List (commits, features, bugs, etc)

table component update
list component update
test update

Acceptance Test (how to verify the PR)

Try storybook load more for Table and List

Regression Test (how to make sure this PR doesn't break old functionality)

Make sure all the existing functionality still works.

Things to look for during review

[ ] Make sure all references to iot or bx class prefix is using the prefix variable
[ ] (React) All major areas have a data-testid attribute. New test ids should have test written to ensure they are not changed or removed.
[ ] UI should be checked in RTL mode to ensure the proper handling of layout and text.
[ ] All strings should be translatable.
[ ] The code should pass a11y scans (The storybook a11y knob should show no violations). New components should have a11y test written.
[ ] Unit test should be written and should have a coverage of 90% or higher in all areas.
[ ] All components should be passing visual regression test. For new styles or components either a visual regression test should be written for all permutations or the base image updated.
[ ] Changes or new components should either write new or update existing documentation.
[ ] PR should link and close out an existing issue

@JordanWSmith15 I'm assuming this is coming from a PAL design. have you see the design, does it make sense?

I have not seen this in PAL. @dianatran18 is out on leave, but I don't have a problem with it in the case of hierarchical data tables that expand to show child rows. Lazy loading as you scroll would not really work in that scenario, nor having multiple pagination bars. All I would ask is that this feature should be hidden/unavailable UNLESS hierarchy/child rows are present.

I'd like to see the stateful table example doing a bit more... loading rows, showing those rows and the effect it has on scrolling, and showing the loading row on more than just one level of hiearchy

* The full scenario of actually loading data implemented for the Table stories as well, not just the List.

This. With stateful table selected on "Type" prop, I want to see the full behavior.  in https://deploy-preview-2745--carbon-addons-iot-react.netlify.app/?path=/story/1-watson-iot-table-table--row-expansion-and-load-more

@stuckless Are you ok with these changes? I think @JordanWSmith15 has signed off on the design and @bjornalm and @cgirani have worked out a lot of details.

@davidicus if @JordanWSmith15 is good, then I'm good.


Improve XML Formatter

The current XML formatter is a bit messy. It should be rewritten to include more edge cases to avoid messing with CDATA formatting and attribute contents.
Also, the current formatter will take elements that should normally appear like this: <XmlElement></XmlElement> and put a line break between the two tags. This shouldn't happen and should be corrected.

Bumping this to next milestone as I'm already behind due to the holidays.

Should the formatter be self-written? Or is pulling in an external lib considerable?

@rdoubleui The formatter can be an external library provided it allows for tab size configuration.

The formatter has been re-implemented in the vNext branch (eb43a46). This also resolves issue #11. The formatter code is based on the pretty-data XML formatter, but cleaned up and rewritten as TypeScript.

PR #12


Updated Readme.md with config for librarian puppet

see https://github.com/mhahn/vagrant-librarian-puppet/commit/be8311fc9f6f1c1e063fe7d3231418351e05d6ae#commitcomment-10382948

fixes #31

Thanks :smile:

sorry about this!!


Allow for multiple applications to share a Redis DB

Implements #400
Adds the ability to set a key_prefix which will be prepended to all Redis keys. This allows multiple applications to keep their schedules in the same Redis database without clobbering each other.
This change does not affect the runtime of the RSpec suite, but allows for the use case mentioned. Doing the first two commits without the last one would allow for monkey patches, but if we could do the whole thing that would be great.

@marcelolx added.

Also heads up that the link to the commit message style guide on CONTRIBUTING.md is broken

Thanks @TALlama! I'll look into updating the contributing guide.
Added the PR to my list to review, as soon as I have time I'll take a final look

Thanks @TALlama! I have to fix the CI to run the tests, but from what I remember the last time it did pass, so probably nothing is broken.
Thank you for your patience!


Feature Name
Adding Ensemble MethodsVisualizations
Feature Description
Introduce ensemble methods such as bagging, boosting, and stacking. These techniques combine multiple models to improve performance, increase robustness, and reduce the risk of overfitting.
Bagging: This technique trains multiple instances of the same model on different subsets of the training data, usually through bootstrapping. The final prediction is made by averaging (for regression) or voting (for classification).
Boosting: This sequential ensemble technique focuses on correcting errors made by previous models. Each new model is trained on the residuals of the combined ensemble's predictions, leading to improved performance.
Stacking: This method combines different models (which could be of varying types) and uses a meta-learner to make the final prediction based on the outputs of the base models.
Motivation
Ensemble methods are widely recognized for their ability to enhance model accuracy and reliability. By implementing these techniques, users will have access to more powerful modeling strategies that can significantly improve predictive performance on complex datasets.
Implementation Suggestions (Optional)
No response
Feature Type
New Algorithm
Does this feature require additional resources?

[X] Additional Documentation
[ ] Third-Party Libraries
[ ] UI/UX Design
[ ] Other

References (Optional)
No response

please assign this issue to me @ajay-dhangar


Release artifacts-spec-1.0.0-DRAFT1

Proposing we release artifacts-spec-1.0.0-DRAFT1 as we have completed the milestone. Release process is defined here.
High level deliverables as as follows:

[x] Decide on main commit for release - https://github.com/oras-project/artifacts-spec/commit/eecc5d95bcee4741b8d28125e3817a456b76627d
[ ] Cut branch artifacts-spec-1.0.0-DRAFT1 based on agreed upon main commit
[ ] Cut an artifacts-spec-1.0.0-DRAFT1 tag
[ ] Update README.md

/cc @SteveLasker @michaelb990 @justincormack @sajayantony
Can the maintainers please respond with a +1 comment once you are in favor of cutting this release.

Will provide a release commit on the main branch once https://github.com/oras-project/artifacts-spec/pull/39 lands

LGTM, +1

LGTM  once #39 is merged in.

#39 is now merged, with a link fix as a result of #35.
draf1 candidate: https://github.com/oras-project/artifacts-spec/commit/c2172a9848af285bba6af2ca9c30a06515b008a9

+1

LGTM

LGTM

draf1 candidate: c2172a9

Going with Steve's recommended main commit  based on the merge of #39 - Commit https://github.com/oras-project/artifacts-spec/commit/c2172a9848af285bba6af2ca9c30a06515b008a9

Updating with the latest commit for draft.1:  https://github.com/oras-project/artifacts-spec/commit/eecc5d95bcee4741b8d28125e3817a456b76627d

agreed to cut a branch & tag named: 1.0.0-draft.1 after the milestone.


Export detail for school groups

This PR allows detail for school groups to be exported.
While I was there, I switched out all use of select(&:incomplete?) and select(&:complete?) on school onboardings for new .incomplete and .complete scopes that should be much more efficient.
I put the school export code in it's own service as it didn't feel right to fill up the model or controller with it. Hope this is ok!
Also be aware that when breaking down onboarding counts by school type, that most onboardings don't have an associated school and therefore don't have a school type either - so for example, a school group may show 3 schools onboarding in total but when being broken down by school type, have 0 for each (see example here): school-groups-2022-10-21t15-58-45z.csv

Looks good @urbanwide. Having a separate CSV seems sensible to me and :+1: on the new scope :)


Document node problem detector

This is a Feature Request
What would you like to be added

Mention the node problem detector under addons.
Add reference documentation for the addon.
(Optionally) reword the existing task-style documentation

Why is this needed:
node problem detector is (seems to be) a useful addon, however it is not particularly discoverable and the existing documentation focuses on deployment tasks..

/priority backlog
/kind feature


Jockey Pack

Ride a Horse to victory with the Jockey pack, which specializes in playing and drawing as many cards as possible in a single turn!
Also tweaked a few of my other cards.

Midnight Strike 12-card damage to 36(48). Too easy to trivialize a fight.
Like Clockwork cost down to 0, Block down to 4(6). Too strong when played, not fun enough to play.

Fixed a bug that would cause Enough Talk and Conglaturation to trigger if they were possible in the previous combat's final turn.
Added visual effects and sound effects when you trigger Ripped Pecs' Synergy. (same as angery champ)

Gonna save this for the next release.


[BUG] Continuity Errors Count skyrocketing when two TSP instances with same multicast address output (but different ports) are running on same network

Hi @lelegard
I thought I opened a bug ticket mistakenly earlier on today, therefore I closed it.
But it seems I actually have found a bug, so I am re-opening one. Please see below the explanations.
Bug description:
Continuity Errors Count skyrocketing when two TSP instances with same multicast address output (but different ports) are running on same network

When two TSP instances with the same multicast output (but different ports obviously) are running on the same network, the number of Continuity Errors are skyrocketing. We will call these instances TSP1 and TSP2.
If only TS1 is launched, not a single CC error is detected.
Likewise, if only TS2 is launched, not a single CC error is detected either.
However, as soon as both TSP1 and TSP2 are running at the same time, the Continuity Errors Count skyrocket like crazy, from the very first second the two TSP process run concurrently.

How to reproduce:
Equipment involved to easily reproduce the problem:

One MPEG2-TS playout/streamer, aka "sender",  with one physical Ethernet ports used as TS output. We will call it NIC1.
One Linux server with two different physical Ethernet ports used as TS inputs/outputs. We will call them NIC1 and NIC2.
Connection will involve a switch: Playout-NIC1 to Switch. Switch to TSDuck-NIC1, and Switch to TSDuck-NIC2.

TSP1
tsp --verbose --bitrate 50000000 --initial-input-packets 7 --max-input-packets 7 --max-flushed-packets 7 -I ip <IP_ADDRESS>:11111 -l <IP_ADDRESS> -O ip <IP_ADDRESS>:4001 -l <IP_ADDRESS> --packet-burst 7 --enforce-burst

TSP2
tsp --verbose --bitrate 50000000 --initial-input-packets 7 --max-input-packets 7 --max-flushed-packets 7 -I ip <IP_ADDRESS>:11111 -l <IP_ADDRESS> -O ip <IP_ADDRESS>:4002 -l <IP_ADDRESS> --packet-burst 7 --enforce-burst

Edit1: I have located the bug. It seems it's related to the same multicast address output, in my case <IP_ADDRESS>. If for one of the TSP plugin, I'm using a different multicast output address, the number of CC errors will not be rising anymore and will simply be = 0. Example: TSP1 with <IP_ADDRESS> and TSP2 with <IP_ADDRESS> works.
Expected behavior:
The number of CC errors must remain = 0, even if two instances of TSP are running at the same time on the same network, with the same multicast output address (but obviously a different port).
Errors and logs:
No error with the above command. But using Dektec, TSReader and TSDuck with continuity plugin will show a rising CC errors, as follows:
* continuity: packet index: 31,167, PID: 0x026C, missing 7 packets
* continuity: packet index: 31,199, PID: 0x026C, missing 10 packets
* continuity: packet index: 31,200, PID: 0x02D0, missing 9 packets
* continuity: packet index: 31,220, PID: 0x026C, missing 12 packets
* continuity: packet index: 31,221, PID: 0x02D0, missing 13 packets
* continuity: packet index: 31,248, PID: 0x02D0, missing 5 packets
* continuity: packet index: 31,249, PID: 0x026C, missing 6 packets
* continuity: packet index: 31,291, PID: 0x026C, missing 6 packets
* continuity: packet index: 31,292, PID: 0x02D0, missing 6 packets
* continuity: packet index: 31,346, PID: 0x026C, missing 15 packets
* continuity: packet index: 31,402, PID: 0x026C, missing 6 packets
* continuity: packet index: 31,403, PID: 0x02D0, missing 7 packets
* continuity: packet index: 31,437, PID: 0x026C, missing 9 packets
* continuity: packet index: 31,438, PID: 0x02D0, missing 9 packets
* continuity: packet index: 31,459, PID: 0x026C, missing 13 packets
* continuity: packet index: 31,460, PID: 0x02D0, missing 13 packets
* continuity: packet index: 31,472, PID: 0x02D0, missing 12 packets

Environment:

OS: Linux
OS version: CentOS 7.9
TSDuck full version: 3.29-2627
Installation type: Official binary

Additional information:

But using Dektec, TSReader and TSDuck with continuity plugin will show a rising CC errors, as follows:

You did not explain what you measured. CC errors on which stream? Using which command on which system on the network?
The way you explain the problem, it looks like the two streams from <IP_ADDRESS>:4001 and <IP_ADDRESS>:4002 are getting mixed while they are in fact two different transport streams. Is it possible that what you read to evaluate CC errors is in fact a mixture of all packets on address <IP_ADDRESS>, ports 4001 and 4002 mixed?

Hi @lelegard
Sorry for missing important details. I'm measuring the CC errors at the output of each TSP processes:

CC errors at the output of TSP1: <IP_ADDRESS>:4001
CC errors at the output of TSP2: <IP_ADDRESS>:4002

The way you explain the problem, it looks like the two streams from <IP_ADDRESS>:4001 and <IP_ADDRESS>:4002 are getting mixed while they are in fact two different transport streams.

Indeed, that's also what I believe based on my findings.

Is it possible that what you read to evaluate CC errors is in fact a mixture of all packets on address <IP_ADDRESS>, ports 4001 and 4002 mixed?

No, or at least, the command I'm using is also taking into account the port, as follows:
TSP1
tsp --verbose --bitrate 50000000 -I ip <IP_ADDRESS>:4001 -l <IP_ADDRESS> -P continuity -O drop
TSP2
tsp --verbose --bitrate 50000000 -I ip <IP_ADDRESS>:4002 -l <IP_ADDRESS> -P continuity -O drop
If TSP1 runs alone, no issue. If TSP2 runs alone, no issue either. But if both runs together, there is a conflict.
Is it possible that something is wrong with the way the multicast:port output address is handled by TSP output plugin?

But you mentioned that you noticed the same CC error when checking with TSReader or Dektec software. Is this really the case?

Yes, it is the case so I am still thinking about a TSDuck Output plugin issue.

On the same receiver system? If yes, this must be a system issue rather than a TSDuck issue.

No, on 3 different systems that have nothing to do with the two equipment used for my test:

Dektec Stream Xpert on a Windows Server
TS Reader on a Windows 10 Laptop
TSP plugin with a CentOS 8.4 Server

Would you be able to look into this matter as it is impossible to always maintain a different multicast address as the users are not always communicating together?

Yes, it is the case so I am still thinking about a TSDuck Output plugin issue.

I would be quite surprised if that would be the case. You will need to produce strong evidences to convince me. Since the two output processes use distinct local addresses, you should be able to use Wireshark to check if all output packets on each interface have the right port, meaning 4001 on <IP_ADDRESS> and 4002 on <IP_ADDRESS>.
That being said, <IP_ADDRESS> and <IP_ADDRESS> are on the same subnet. Why did you configure two interfaces of the same system on the same subnet? Mixing that with multicast routing is clearly looking for trouble. One hypothesis is that the Linux system duplicates all packets from the two streams on each interface when the two interfaces are used in multicasting. Since the two interfaces are on the same subnet, the net result is that all packets are duplicated. You should be able to confirm that or not using wireshark.

Would you be able to look into this matter

No I can't. This is your network configuration, a bit unusual. You need to do some network investigations on this configuration.
It would be interesting to use only one output interface and see if the problem is the same.

as it is impossible to always maintain a different multicast address as the users are not always communicating together?

I do not see the relationship between "impossible to always maintain a different multicast address" and "the users are not always communicating together". Usual large telco multicast networks (live TV for instance) use different multicast addresses for different transport streams.

Hi @lelegard
Thanks, I will check with Wireshark tomorrow.
In the meantime, I have tried with one interface only (Using .153 and stopped .154).
The problem is still happening: no CC errors when only one TSP is running, a lot of CC errors when two TSP are running.
My commands are:
TSP1
tsp --verbose --bitrate 50000000 --initial-input-packets 7 --max-input-packets 7 --max-flushed-packets 7 -I ip <IP_ADDRESS>:11111 -l <IP_ADDRESS> -O ip <IP_ADDRESS>:4001 -l <IP_ADDRESS> --packet-burst 7 --enforce-burst
TSP2
tsp --verbose --bitrate 50000000 --initial-input-packets 7 --max-input-packets 7 --max-flushed-packets 7 -I ip <IP_ADDRESS>:11111 -l <IP_ADDRESS> -O ip <IP_ADDRESS>:4002 -l <IP_ADDRESS> --packet-burst 7 --enforce-burst
The CC errors check commands are:
TSP1
tsp --verbose --bitrate 50000000 -I ip <IP_ADDRESS>:4001 -l <IP_ADDRESS> -P continuity -O drop
TSP2
tsp --verbose --bitrate 50000000 -I ip <IP_ADDRESS>:4002 -l <IP_ADDRESS> -P continuity -O drop
Output is:
* continuity: packet index: 1,253, PID: 0x02D0, missing 12 packets
* continuity: packet index: 1,254, PID: 0x026C, missing 13 packets
* continuity: packet index: 1,281, PID: 0x026C, missing 6 packets
* continuity: packet index: 1,282, PID: 0x02D0, missing 6 packets
* continuity: packet index: 1,288, PID: 0x02D0, missing 7 packets
* continuity: packet index: 1,289, PID: 0x026C, missing 6 packets
* continuity: packet index: 1,295, PID: 0x02D0, missing 6 packets
* continuity: packet index: 1,296, PID: 0x026C, missing 7 packets
* continuity: packet index: 1,302, PID: 0x02D0, missing 6 packets
* continuity: packet index: 1,304, PID: 0x026C, missing 7 packets
* continuity: packet index: 1,316, PID: 0x026C, missing 3 packets
* continuity: packet index: 1,317, PID: 0x02D0, missing 3 packets
* continuity: packet index: 1,323, PID: 0x026C, missing 9 packets

To me, there is still a wrong multicast management by TSP which is not able to make the difference between two independent multicast address+ports and outputs both multicast as one, by aggregating the ports linked to the same address.

Hi,
My two cents:

One possibility is a Linux system issue with multicast handling. It is well-known that using the same multicast address / distinct ports for distinct streams is looking for troubles depending on the operating system. Similarly, having the same port / distinct addresses may confuse clients if they need to receive both streams. Since I work with Linux, macOS and Windows interchangeably and all of them have their own specific issues and limitations regarding multicast, I cannot really remember what does not work well where.

From my experience, reading/writing in Linux sharing the same multicast address even with different ports has an unexpected behaviour: the processes receive all packets addressed to this address despite the port used.
Please @moving-digital could you test this?

From an external device, write a valid MPEG-TS stream to the multicast address <IP_ADDRESS>:4001
From a different external device, write a second MPEG-TS to the multicast address  <IP_ADDRESS>:4002
From a third Linux device, read the stream <IP_ADDRESS>:4001 with VLC and/or FFmpeg.
Do the same with a fourth Linux device with the stream <IP_ADDRESS>:4002.

Until here, if your network is right configured, you will see the streams without any error. Then:

Check another time in the same Linux device, running two instances of VLC or FFmpeg reading one from <IP_ADDRESS>:4001 and the other from <IP_ADDRESS>:4002. You see errors?

Hi @lelegard  @lars18th
Thank you both for your comments! So I have tried the below, with a total of 3 equipment:

MPEG-TS streamer to the multicast address <IP_ADDRESS>:4001
MPEG-TS streamer to the multicast address <IP_ADDRESS>:4002
Player on Windows 10 Laptop, using VLC, Dektec StreamXpert and TS Reader

The 3 equipment are connected to the same switch, so are on the same network.
When I run two instances of VLC, Dektec StreamXpert or TS Reader, not a single CC error is detected. Yet, the same multicast address is used. Only the port is different.
So, I'm still confused as the issue (CC Errors skyrocketing) only happens when the same multicast address is used on the very same streaming server.

From my experience, reading/writing in Linux sharing the same multicast address even with different ports has an unexpected behaviour: the processes receive all packets addressed to this address despite the port used.

This seems to be in-line with what Thierry is sharing too. However in the test I just performed, there is no issue on the receiving end, as the players are able to play each stream properly without being confused by the fact that two different equipment are sending two different MPEG2-TS stream in the same network, with the same address.

Hi
I investigated a bit more, and something is still puzzling me.
My streamer 1 uses the below TSP command:
tsp --verbose --bitrate 10000000 --initial-input-packets 7 --max-input-packets 7 --max-flushed-packets 7 -I file file1.ts -i -P regulate -O ip <IP_ADDRESS>:11111 -l <IP_ADDRESS> --packet-burst 7 --enforce-burst
My streamer 2 uses the below one:
tsp --verbose --bitrate 10000000 --initial-input-packets 7 --max-input-packets 7 --max-flushed-packets 7 -I file file2.ts -i -P regulate -O ip <IP_ADDRESS>:11111 -l <IP_ADDRESS> --packet-burst 7 --enforce-burst
In this case, both streamers are using different netmasks:

Streamer 1: <IP_ADDRESS>
Streamer 2: <IP_ADDRESS>

Then, I've set up a receiving instance of TSP on one server able to listen to both streams, with the below command:
When listening to <IP_ADDRESS>:4001 on <IP_ADDRESS> network:
tsp --verbose --bitrate 30000000 --add-input-stuffing 1/10 --initial-input-packets 7 --max-input-packets 7 --max-flushed-packets 7 -I ip <IP_ADDRESS>:11111 -l <IP_ADDRESS> --buffer-size 212992 -P zap 1 -P filter --negate --pid 0x1FFF -O ip <IP_ADDRESS>:4001 -l <IP_ADDRESS> --packet-burst 7 --enforce-burst
But I will get warnings and most importantly the zap plugin will never stop toggling between the two streams, meaning the zap plugin is not able to correctly listen on one given physical network interface only:

ip: joining multicast group <IP_ADDRESS>:11111 from local address <IP_ADDRESS>
ip: initial input bitrate is 33,000,000 b/s
Warning: ip: detected multiple sources for the same destination <IP_ADDRESS>:11111 with potentially distinct streams
Warning: ip: detected source: <IP_ADDRESS>:55751
Warning: ip: detected source: <IP_ADDRESS>:60473
pmt: found service id 0x0001 (1), PMT PID is 0x1000 (4096)
pmt: PMT version 0 modified
spliceinject: found service id 0x0001 (1), PMT PID is 0x1000 (4096)
zap: found service id 0x0001, PMT PID is 0x1000
zap: found service id 0x0001, PMT PID is 0x0020
zap: found service id 0x0001, PMT PID is 0x1000
zap: found service id 0x0001, PMT PID is 0x0020
zap: found service id 0x0001, PMT PID is 0x1000
zap: found service id 0x0001, PMT PID is 0x0020
zap: found service id 0x0001, PMT PID is 0x1000

Windows and Linux work differently with multicast. Could you try to receive with VLC on Linux?
On Linux, when receiving multicast, the local socket is bound to the multicast address, not to the local interface address. The local interface address is just used to send the join multicast group request. This is different on Windows, the socket is bound to the local interface.
To compare TSDuck vs. another receiver, please run the two applications one after the other on the same system.

Hi @lelegard @lars18th
You guys just rock ! I've done many experiments today, and I can confirm that the issue was due to the fact that I was trying to read the very same multicast address:port from two independent physical Ethernet ports (in my case <IP_ADDRESS>:11111).
As soon as I changed the port, everything got fixed.
So what can be concluded is that using the very same multicast address on different physical Ethernet ports does not cause any issue on Linux if the port is different.
However, as soon as both the address and port are identical and used in at least two physical interfaces, it will create a conflict, even if these two interfaces do not even have the same subnet at all.
Once again, thank you so much !!!

Hi @moving-digital ,

So what can be concluded is that using the very same multicast address on different physical Ethernet ports does not cause any issue on Linux if the port is different. However, as soon as both the address and port are identical and used in at least two physical interfaces, it will create a conflict, even if these two interfaces do not even have the same subnet at all.

That's because the binding is done to an address, and not to an interface. In case you bind to the interface and the multicast address, then perhaps the problem doesn't appears.
I'm glad you've fixed your problem.
Regards.

In case you bind to the interface and the multicast address,

How would you do that ?

Hi @lars18th

That's because the binding is done to an address, and not to an interface. In case you bind to the interface and the multicast address, then perhaps the problem doesn't appears.
I'm glad you've fixed your problem. Regards.

I wouldn't say "fixed but "found a workaround"

In case you bind to the interface and the multicast address,

How would you do that ?

Hi @lelegard
I'm sure you already have, but I found these 2 or 3 interesting links on Google :
https://www.reddit.com/r/networking/comments/7nketv/proper_use_of_bind_for_multicast_receive_on_linux/
https://stackoverflow.com/questions/10692956/what-does-it-mean-to-bind-a-multicast-udp-socket/14613620

I'm sure you already have, but I found these two interesting links on Google which should help you find out how to use bind() for our matter

They just repeat what I already mentioned and what is already implemented in TSDuck: on Linux, the socket shall be bound to the multicast address, not the local address. And, if needed, the join group is sent on the local interface.
The first link also mentions:

Having multiple multicast groups that use the same port is a suboptimal design for the exact situation you've found yourself in: it makes it hard to filter the traffic to just what you want if another application on the same machine is also listening to traffic that shares the same port. It's generally best to avoid sharing either multicast group or port across different logical channels.

Which is what you did and what we advised to not do...


how to update tuyagateway from this addon?

When is tuyagateway new version how to update tuyagateway from this addon?

If you rebuild the add-on it will always pull the latest version of the gateway software from GitHub. I will add that to the docs.

Fixed in 0.5 release.


[chore] Add clock to utils

Moving this from core into common.
Companion PR: https://github.com/smartcontractkit/chainlink/pull/12027

Is there another package that would make more sense? We've been trying to dissolve package utils since it is an anti-pattern

@jmank88 I could move it to a faketime package in ./pkg? Or into utils/tests?

pkg/clock ?


Release 2.0.25

[x] Create release.

[x] Pull latest master.
For the sinopia_editor only (sinopia_indexing_pipeline does not need to update the version number in the package.json file):

[x] Check out a branch and update the version in package.json
[x] npm i to regenerate package-lock.json (see note below)
[x] npm publish to publish the version to npm registry.
[x] Commit change to branch and push; create PR for version bump.  (You can't push directly to master, since it's a protected branch).
[x] Once PR is merged, publish a new release with a version like v1.0.2 and wait for Circleci to complete building and pushing docker images.

[x] AWS Images for supporting projects - the Sinopia stack requires
a number of other projects to run successfully both locally and on AWS. If any of
these projects changed between tagged releases, you will need to update and tag the
latest image on Dockerhub along with corresponding update to Terraform with the tagged
release.

Sinopia ACL https://github.com/LD4P/sinopia_acl

Download the latest image `docker pull ld4p/sinopia_acl:latest
Create a tagged version docker tag ld4p/sinopia_acl:latest ld4p/sinopia_acl:{version}
Push new tagged version docker push ld4p/sinopia_acl:{version}
Update Terraform with the new tagged version and create PR

[x] Sinopia Indexing Pipeline https://github.com/LD4P/sinopia_indexing_pipeline

[x] Published new release v1.0.22 and wait for Circleci to complete building and pushing docker images.

[x] Sinopia Exporter https://github.com/LD4P/sinopia_exporter

[x] Publish a new release version like v1.0.21 and wait for Circleci to complete building and pushing docker images.

Sinopia Profile Editor https://github.com/LD4P/sinopia_profile_editor

Publish a new release with a version like v1.0.2 and wait for Circleci to complete building and pushing docker images.

[x] Deploy to staging

[x] Follow instructions for pushing a release to staging. Make sure to update versions to Sinopia Editor, Sinopia Indexing Pipeline, and Sinopia Exporter.
[x] Submit a new terraform PR.

NOTE: if package-lock.json has links to unsecured http:// registries, try
deleting package-lock.json, remove the node modules rm -rf ./node_modules,
run npm cache clean --force, and then run npm i --prefer-online

Deployed to stage, PR up in Terraform for production


blob gc feature for fscache with inuse and cull

We should implement these to avoid too many unused cachefiles.
also see, https://github.com/lostjeffle/demand-read-cachefilesd/blob/main/test/test13-daemon.c

@nan1994 @imeoer
please help discuss these interfaces in order to make the gc functionality work.

It is also discussed in https://github.com/containerd/nydus-snapshotter/pull/262


[osg libraw openexr jasper] Dont block arm64-osx

Describe the pull request

What does your PR fix?
Fixes arm64-osx targets for osg, libraw, openexr and jasper. In a recent QT PR I blocked some of these targets accidently. This PR correctly represents what each port supports.

libraw does support compiling for arm64 but not uwp because of a dependency on CreateFile and other API's
openexr does not support arm because of some intel intrinsic used
osg does not support compiling for uwp but does support arm on other platforms like osx
jasper does not support compiling for uwp

Which triplets are supported/not supported? Have you updated the CI baseline?

various

Does your PR follow the maintainer guide?

yes

If you have added/updated a port: Have you run ./vcpkg x-add-version --all and committed the result?

yes
If you are still working on the PR, open it as a Draft: https://github.blog/2019-02-14-introducing-draft-pull-requests/

cc @cenit @dg0yt for review this PR.


Add post title to share button text in article.

When clicking share button on each article, we are now seeing only the permalink URL.

Maybe we want something like this.
text = $this.attr('data-text'),
......
'',

Agree. If you could submit the pull request, I would merge the change.


Typehints should be implemented

ref https://github.com/python/typeshed/pull/10485#issuecomment-1643745094
(Any contributions welcome, it's not needed to cover everything in one pull request)

Sure


Add community coordination implementations(consul and redis) on README

this fixes #108

@hseeberger Thank you for elaboration!  I corrected points which you pointed out and pushed.

Great! Thanks a lot for your contribution(s)!


should b64_buf_realloc be thread safe?

buffer.c solved a problem that I was having with reallocs when doing a stress test, I'm not sure what the problem was, but it doesn't happen anymore 👍. So, I was looking at the implementation, and I believe that we may have problems when dealing with multhread application.
The buffer control variable is in a global context, which can cause problems between threads generating base64 at the same time and need different buffer sizes.
I thought if it would be interesting if the variable bufc stayed in the scope of the method, or, the buffer was a struct that would contain the information from the buffer.
I believe the simplest implementation would be something like:
int b64_buf_malloc(char * buf);
char* b64_buf_realloc(unsigned char* ptr, size_t size, int * buf_size);

Or
typedef struct buffer {
    char * ptr;
    int bufc;
} buffer_t;

buffer_t * b64_buf_malloc();
void b64_buf_realloc(buffer_t * buffer , size_t size);

I can act on it if it is an acceptable solution.

@yuridiniz yeah go for it! I think I'd like to come back to this sometime in the near future and make this API enforce the caller to allocate memory. This should help those who want to manage their own memory (arenas, pools, etc), reuse contiguous memory available to them, or manage boundaries and locks for memory pointers this library may read from or write to


repo: create CI check to ensure .ipynb under /examples can run on Google Colab

nice. and there should be some quick "pragma" to opt-out in the notebook if it can't be used on google collab.


Undocumented control ports

ALO has LV2 control ports for:

Togge loops 1-6
Audio threshold
MIDI base note
Setting quantity of bars to loop
Click audio level
Wet / dry mix
Enable
Reset mode
Instant Loops

The last two are not documented. What do these do?

Hi @riban-bw - thanks for raising this. The features are documented the mod-gui
https://github.com/devcurmudgeon/alo/blob/master/source/alo.lv2/alo.ttl
Am I right in thinking you were expecting to find something in the readme? if so I'll update it

Thanks, I will read that. Yes it would be good to see this in the readme which describes the other controls.


Fix EFR unit tests

Problem
EFR32 device side unit tests are failing.
Change overview

Fix use of IPv4 when using IPv6 only.
Remove tests which are failing to compile.

Testing

Built the tests and ran on EFR32, all 277 tests pass.

@saurabhst ?


Protocols section complete rewrite

:warning: depends on #89
Description
Complete rewrite of https://docs.kuzzle.io/plugins-reference/protocols/

protocols now have their dedicated section
the previous document lacked many explanations, or relied too much on the plugins documentation (plugins and protocols diverged a lot and are now very different)
many exposed constructors and helpers in the protocols context were undocumented

How to review
Using the netlify preview is the best way to review this PR, because of the very extensive rewrite.

 Snippets tests reports   SDK Version Tests overview      v6                           :heavy_check_mark:                            v5                                   :heavy_minus_sign:                    v1                           :heavy_check_mark:                            v1                           :heavy_check_mark:                            v1                           :heavy_check_mark:

@Aschen > arguments descriptions have been updated to our new formalism

@etrousset > applied your suggestions

@scottinet There is some conflicts

@Aschen > fixed


test refactor

I refactored @sambarluc's test into one single test, which mysteriously is now passing on my machine. I want to see the result on travis.

@sambarluc: here the test is failing only on python 2 and only with swap_dims=True.
https://travis-ci.org/xgcm/xmitgcm/jobs/289577976
It is passing for python 3 (now that we don't try to swap dims on llc grids), as I suggested in my final comment in #53.
Do you know how to check out this PR? Can you see if the test passes on your machine?

Not really sure on how to checkout the pr, I'm really getting lost with the complexity of git.
In any case, I suspect the test may now be insufficient, probably we should try printing the time axis?

I actually added the tests with the print, but I am not even sure of where they are. It takes devotion to learn git.

Don't worry, your git is fine! I simplified your four tests functions into one single function with parametrize that does everything the original tests do (except try to call swap_dims with llc geometry).

https://help.github.com/articles/checking-out-pull-requests-locally/

Should have been more specific: I cannot seem to be able to find out what I should use as PR ID!

git checkout -b rabernat-refactor_ref_date_tests master
git pull https://github.com/rabernat/xmitgcm.git refactor_ref_date_tests

Thanks.
It's definitely failing here:
xmitgcm/test/test_mds_store.py::test_tload_with_ref_date_grid[internal_wave-True] FAILED
xmitgcm/test/test_mds_store.py::test_tload_with_ref_date_grid[internal_wave-False] PASSED
xmitgcm/test/test_mds_store.py::test_tload_with_ref_date_swap[internal_wave-True] FAILED
xmitgcm/test/test_mds_store.py::test_tload_with_ref_date_swap[internal_wave-False] PASSED
xmitgcm/test/test_mds_store.py::test_open_with_ref_date_grid[internal_wave-True] FAILED
xmitgcm/test/test_mds_store.py::test_open_with_ref_date_grid[internal_wave-False] PASSED
xmitgcm/test/test_mds_store.py::test_open_with_ref_date_swap[internal_wave-True] FAILED
xmitgcm/test/test_mds_store.py::test_open_with_ref_date_swap[internal_wave-False] PASSED
xmitgcm/test/test_mds_store.py::test_date_parsing[global_oce_llc90] PASSED
xmitgcm/test/test_mds_store.py::test_tload_with_ref_date_grid[global_oce_llc90-True] PASSED
xmitgcm/test/test_mds_store.py::test_tload_with_ref_date_grid[global_oce_llc90-False] PASSED
xmitgcm/test/test_mds_store.py::test_tload_with_ref_date_swap[global_oce_llc90-True] FAILED
xmitgcm/test/test_mds_store.py::test_tload_with_ref_date_swap[global_oce_llc90-False] PASSED
xmitgcm/test/test_mds_store.py::test_open_with_ref_date_grid[global_oce_llc90-True] PASSED
xmitgcm/test/test_mds_store.py::test_open_with_ref_date_grid[global_oce_llc90-False] PASSED
xmitgcm/test/test_mds_store.py::test_open_with_ref_date_swap[global_oce_llc90-True] FAILED
xmitgcm/test/test_mds_store.py::test_open_with_ref_date_swap[global_oce_llc90-False] PASSED

I guess this means we are hitting some corner case related to small version differences?

You have not actually checkout out this branch, because the test output doesn't look right. On my branch, I see the following:
xmitgcm/test/test_mds_store.py::test_ref_date[internal_wave-True-True-True] PASSED
xmitgcm/test/test_mds_store.py::test_ref_date[internal_wave-True-True-False] PASSED
xmitgcm/test/test_mds_store.py::test_ref_date[internal_wave-False-True-True] PASSED
xmitgcm/test/test_mds_store.py::test_ref_date[internal_wave-False-True-False] PASSED
xmitgcm/test/test_mds_store.py::test_ref_date[internal_wave-False-False-True] PASSED
xmitgcm/test/test_mds_store.py::test_ref_date[internal_wave-False-False-False] PASSED
xmitgcm/test/test_mds_store.py::test_ref_date[global_oce_llc90-True-True-True] SKIPPED
xmitgcm/test/test_mds_store.py::test_ref_date[global_oce_llc90-True-True-False] SKIPPED
xmitgcm/test/test_mds_store.py::test_ref_date[global_oce_llc90-False-True-True] PASSED
xmitgcm/test/test_mds_store.py::test_ref_date[global_oce_llc90-False-True-False] PASSED
xmitgcm/test/test_mds_store.py::test_ref_date[global_oce_llc90-False-False-True] PASSED
xmitgcm/test/test_mds_store.py::test_ref_date[global_oce_llc90-False-False-False] PASSED

Strange, because I used the commands you sent me, and this looks right to me:
cimatori@ecolpc18:xmitgcm_sambarluc$ git status
On branch rabernat-refactor_ref_date_tests
nothing to commit, working directory clean

I have no idea. I keep seeing things I don't understand on my fork. I suspect I messed up something at some point, but have no clue of what, nor on how to fix it.  I checked that the test is indeed your refactored version:
xmitgcm/test/test_mds_store.py::test_ref_date[internal_wave-True-True-True] FAILED
xmitgcm/test/test_mds_store.py::test_ref_date[internal_wave-True-True-False] FAILED
xmitgcm/test/test_mds_store.py::test_ref_date[internal_wave-False-True-True] PASSED
xmitgcm/test/test_mds_store.py::test_ref_date[internal_wave-False-True-False] PASSED
xmitgcm/test/test_mds_store.py::test_ref_date[internal_wave-False-False-True] PASSED
xmitgcm/test/test_mds_store.py::test_ref_date[internal_wave-False-False-False] PASSED

So, it fails with swap_dims=True only also here, even if it's python 3.6. Since I have an environment with 2.7 too, I checked and it fails in the same way there too.

Hi, I'm re-emerging from some stuff I had to do. Any news on this?

I have not worked on it yet, and I doubt I will have much time soon. I think you are in a better position than me to fix this issue! Just dig in and you will probably find the solution!

I'll try, I just wanted to check, thanks!

I'm going to merge this so we have the new tests in place.

Codecov Report

Merging #54 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #54   +/-   ##
=======================================
  Coverage   91.94%   91.94%
=======================================
  Files           4        4
  Lines         608      608
  Branches      134      134
=======================================
  Hits          559      559
  Misses         32       32
  Partials       17       17

Continue to review full report at Codecov.

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

Didn't have the time yet to really look into the issue, it's a bit obscure to me.

After another round of updates of my conda installation, the problem disappeared. Both in the test suite and in normal use. Embarrassingly enough, I did not track all the updates, but I can find out what was changed if you think it is necessary. Otherwise, I would say it was definitely some upstream issue, now fixed.

I would suggest to close the issue, but keep the tests for future reference.


wso2sp-worker is CrashLoopBackOff

pod's log:
kubectl logs -p wso2sp-worker-7fb486767-48ltt -n vick-system
/home/wso2carbon/wso2sp-4.3.0/bin/worker.sh: 65: /home/wso2carbon/wso2sp-4.3.0/bin/worker.sh: /home/wso2carbon/wso2sp-4.3.0/wso2/worker/bin/carbon.sh: not found

Hi @tongsrv,
Can you explain the steps you followed?

We use this script - system\scripts\kubeadm\kubeadm-setup.sh


src: 1.32 -> 1.33

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.

Closing https://github.com/NixOS/nixpkgs/pull/278430

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/3210


wrong cursor style for dropdown entries

It seems like all dropdown entries have "text selection" cursor, because we are using an  anchor tag without setting the href attribute.
They should have "cursor:pointer".

It should be probably fixed in generic list component


test: mark //test/integration:protocol_integration_test as flaky.

Addresses #10180.
Signed-off-by: Piotr Sikora<EMAIL_ADDRESS>

Can we try to debug the issue a bit before marking flaky? This is why I didn't want to add this flag in the first place. cc @lizan @alyssawilk

From what I understand, most (if not all) the time it's from ManyRequestTrailersRejected H/2 downstream, H/1 upstream. It somehow seemed like we were hitting unparented connections and I need to move around the waits, I can try to deflake.
I tested 5000 times, but I don't trust myself. Can you verify this diff and see if the flake appears for you?
diff --git a/test/integration/protocol_integration_test.cc b/test/integration/protocol_integration_test.cc
index 76d8363e8..08b23539c 100644
--- a/test/integration/protocol_integration_test.cc
+++ b/test/integration/protocol_integration_test.cc
@@ -988,6 +988,7 @@ TEST_P(DownstreamProtocolIntegrationTest, ManyRequestTrailersRejected) {

   initialize();
   codec_client_ = makeHttpConnection(lookupPort("http"));
+  fake_upstreams_[0]->set_allow_unexpected_disconnects(true);
   auto encoder_decoder = codec_client_->startRequest(default_request_headers_);
   request_encoder_ = &encoder_decoder.first;
   auto response = std::move(encoder_decoder.second);
@@ -998,12 +999,15 @@ TEST_P(DownstreamProtocolIntegrationTest, ManyRequestTrailersRejected) {
   // TODO(asraa): we shouldn't need this unexpected disconnect, but some tests hit unparented
   // connections without it. Likely need to reconsider whether the waits/closes should be on
   // client or upstream.
-  fake_upstreams_[0]->set_allow_unexpected_disconnects(true);
-  ASSERT_TRUE(fake_upstreams_[0]->waitForHttpConnection(*dispatcher_, fake_upstream_connection_));
-  response->waitForReset();
-  ASSERT_TRUE(fake_upstream_connection_->close());
-  ASSERT_TRUE(fake_upstream_connection_->waitForDisconnect());
-}
+  if (downstream_protocol_ == Http::CodecClient::Type::HTTP1) {
+    codec_client_->waitForDisconnect();
+    EXPECT_TRUE(response->complete());
+    EXPECT_EQ("431", response->headers().Status()->value().getStringView());
+  } else {
+    response->waitForReset();
+    codec_client_->close();
+  }
+} // namespace Envoy

 TEST_P(DownstreamProtocolIntegrationTest, ManyRequestTrailersAccepted) {
   // Set header (and trailer) count limit to 200.

Piotr, can you give Asra's patch a try?


Space name errors not being displayed to user

After the Space name constraints that came with https://github.com/brimsec/zq/pull/853, I tested out the user experience of what happens if I tried to violate those constraints, such as:

Attempting to rename a Space to one that already exists
Attempting to rename a Space to include invalid characters

As shown in the attached video, in both cases the app silently fails to process the rename. The error message that zqd floated shows up in DevTools but is not seen by the user. Surely it would be helpful to the user to have seen it so they can understand what they did wrong.
Repro.zip

@mattnibs what kind of message should we say other than "Invalid space name". Should we specify what characters are not allowed?

fyi, we broadened the allowed characters: https://github.com/brimsec/zq/issues/937 , so perhaps something like "Space names can't contain / or non-printable characters"? I removed a more descriptive error message a few days ago during the discussion, but we could put it back & let Brim just forward that on to the user.


example: otel-wrapper-shim.sh + symlinks to trace nodejs builds

I should start by saying that this project has been super-helpful to me at work. It fits with the unix philosophy beautifully and makes it easy to use distributed systems debugging tools for buildsystems.
I wrote something similar to the attached script at work, and managed to shave about 30s our build process (mostly by tweaking which build steps were run concurrently).
I've not actually tried using it for instrumenting C build systems, but that might be an interesting experiment.
I would also like to try installing an opentelemetry collector into github actions, and running everything using this shim. If anyone tries it, please report back ;-).
If people find it useful, it may be that this functionality could be included in the main otel-cli binary (if it detects that it's been symlinked into $PATH with a name other than otel-cli).

Oh, cool idea! I'm gonna think about the built-in symlink idea.
I'll likely merge this PR as-is, and then noodle on how to do the symlink detection safely in otel-cli itself.


feature[next]: Make gtfn cache path configurable

Description to follow

Also, changing the interface from explicitly stating the desire for a cache that does or doesn't stick around after the run (and get in the way of debugging) to passing a path and implicitly determining the lifetime by where that path is on the FS could be seen as a usability degradation.

Superseeded by #1438


Return records parsed into proper objects instead of hashes

ASAP pls

Hey, I don't think I will be changing this soon, to be honest… My focus right now is on performance - the websocket library I've used was struggling to keep up with the stream on some days with more traffic. I'm working on a new version with a different library on the faye branch, and then I want to optimize it some more.
Just adding some records built from JSON would be easy, but I don't know yet how to do it "right" in a way that I will be happy with. Ideally it should be somehow building record classes from the "lexicon" definitions to make it more universal. But how much of the lexicon should I cover? How to name the records? To what degree should it be automatic? Should this be in a separate library? Should I share the code with other Ruby libraries for AtProto? I was thinking about this just yesterday, but I don't have answers right now and it's not a priority. And I don't want to add a new quickly done API now and change it later.
If you want a more friendly API right now with accessing properties using dots instead of [''], you can use e.g. the Mash thing from Hashie https://github.com/hashie/hashie#mash, or do something like this using OpenStruct:
JSON.parse(op.raw_record, object_class: OpenStruct)

This builds a nested OpenStruct from JSON which can then let you do something like: record.embed.image.alt.


docs: user registration

Further to discussion on discord.
The docs should be clearer about:

user registration in general, and
preventing registration of random users but allowing specific ones.

What is the registration? if

Woodpecker does not have its own user registry

well what you could call "registed users" is stored in "users" table ... but that only contain data witch is synced with the forge

updated ... see https://woodpecker-ci-woodpecker-pr-1925.surge.sh/docs/administration/server-config#user-registration
@lonix1 do you have more input to it?
just push to your branch ontop :)

thanks - that should help beginners :)


App displays waiting for smesher response for a long time while node is already syncing and api responsive.

It can take more than 30 minutes to show synced but in some cases even after 50 minutes - there's no status.
Repro easily on os x with 0.0.7

Quit synced app
Wait 20 minutes or more
Start app again

Happening to me too, on Windows, from time to time

We have an emergency patch for this that is verified to fix this problem. Please install 0.0.7 again and it should be fixed.

This is still happening for me on the latest build

For me as well. @IlyaVi @antonlerner - please prioritize investigating this - it is not clear if this is a node or an app specific issue. In my tests, the node is synced but without full app logs it is hard to say what api responses it is getting from the node that may cause it to get stuck in this state. I currently can't get the app on one of my nodes to go blue, no matter what I try and how many times I restart it. This issue makes the app quite unusable.
0.0.7 OS X.

fixed in app release 0.0.8


Calling esp_wifi_set_country_code("US", true) returns ESP_ERR_WIFI_NOT_STARTED

Environment

Module or chip used: ESP32-WROOM-32D
IDF version: v5.0-dev-4723-g30e8f19f5a
Build System: idf.py
Compiler version: xtensa-esp32-elf-gcc (crosstool-NG esp-2022r1-RC1) 11.2.0
Operating System: Linux
Power Supply: USB

Problem Description
Exactly the same code works in v4.3 and v4.4.
But it returns ESP_ERR_WIFI_NOT_STARTED when compile with master tree.
So I think this is a regression.

I ran into this as well, and then changed the order of calls in my wifi setup, now calling esp_wifi_start first, and then esp_wifi_set_country_code, and it's now working for me.   It's definitely a change from 4.4, and I think at least warrants a note in the migration guide.
But logically speaking, it seems like one ought to be able to set the country code before esp_wifi_start; that way there isn't a possible window where the (possibly incorrect) default country code configuration is in use.

Hi @AxelLin @davidzuhn
Sorry for that, it's a breaking changes. This api now only can be used after wifi start.
We need to update related docs in migration guide.
Thanks.

@MaxwellAlan
It's a BUG rather than breaking change.
If you cannot set country code before esp_wifi_start, it means you have a small window that can violate regulatory before calling esp_wifi_set_country_code.

Hi @davidzuhn  @AxelLin The default country is "01" (world safe mode) , it will not violate regulatory before calling esp_wifi_set_country_code.

Hi @davidzuhn @AxelLin The default country is "01" (world safe mode) , it will not violate regulatory before calling esp_wifi_set_country_code.

Now you got another issue:
Calling esp_wifi_get_country_code() before esp_wifi_start always returns "US" rather than "01" in my test.
Besides, what's the reason to keep this BREAKAGE?
What's the problem to allow setting country code before esp_wifi_start?
Remember that people may compile the same application code with different IDF versions.
And you are forcing people to change application code.
IMHO, you should fix it if there is no good reason for the API breakage.

Hi @davidzuhn @AxelLin The default country is "01" (world safe mode) , it will not violate regulatory before calling esp_wifi_set_country_code.

On the second though, I think above comment is wrong.
If country code is "01", you cannot set channel 13/14(in JP).
So you must allow setting country code first before calling esp_wifi_start().

@MaxwellAlan @mhdong
I did not hit error if calling esp_wifi_set_country_code() before esp_wifi_start() in v4.3 and v4.4.
But now I found there are backport fixes regarding country code for v4.3 and v4.4.
So what's exactly fixed for v4.x branches?


Add docs section for global special values.

Fixes #178
I tried to create meaningful examples which showcase how the values/functions work.

I found __dirname  to not work, though.

I found __dirname  to not work, though.

Changed everything according to your suggestions. Thanks!

Ok, as discussed with @ryyppy, I split the section up into cards for the syntax widget instead.

Awesome. Thanks!


 I was looking to convert this for Atom, but can't technically publish under MIT without your having licensed it.
MIT would be as follows:
MIT License

Copyright (c) 2015 <copyright holders>

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Done.  I put it under the ISC license, just because I like the simplicity.  Seems to say the same thing as MIT, in fewer words.
If you specifically need an MIT license for whatever reason, I could be convinced to switch; I'd just want to understand why.

Nope, that'll do nicely.
The converted package is over here. It works beautifully. Thanks for your work! :)


Add documentation for Plan members.

The members of
pub enum Plan {
    /* members */
}

don't have any documentation, and to the extent that they (or their descendants) are the public surface of the query language, they should explain what they each do. I'm happy to take a stab at that!
I have a related goal of making each of them into struct types, and attempting to have each of them implement a trait that corresponds to create_inputs and implement_plan, so that we can break apart i. the set of query operators from ii. the implementation of each query operator. With your blessing, I can take a swing at that at the same time.

Sounds good! But I think we shouldn't even consider create_inputs part of the contract. As you mention in #9 (I'll get back on that) that should be a separate concern entirely, together with a nice way of accessing globally named collection traces.
I'm also hoping that only Lookup, Entity, HasAttr, etc.. will be required to hook-up a different data model, without affecting the implementation of the other operators, so maybe those should all be defined together within a single trait.

Landed in 8d09de282deb5126ba1cda286a006ea6319a282c


React-native-windows throws error: [@RNC/AsyncStorage]: NativeModule: AsyncStorage is null.

I'm getting this issue after experimenting with npx react-native run-windows, running on Version 0.62.preview-10. Having the latest version of AsyncStorage installed and getting the error:
Error: [@RNC/AsyncStorage]: NativeModule: AsyncStorage is null,

Also when I perform react-native link as suggested, I get this
info Linking "@react-native-community/async-storage" iOS dependency
info iOS module "@react-native-community/async-storage" has been successfully linked
info Linking "@react-native-community/async-storage" Android dependency
info Android module "@react-native-community/async-storage" has been successfully linked
Not mentioning the windows platform whatsoever. I feel like I'm doing some general mistake somehow. Can please someone help?
I also downgraded to the stable react-native-windows version 0.61.5 to see if it was an issue with the latest 0.62 preview

For Windows, go for manual linking guide

After following the manual linking guide, building fails with the error "Build failed with message undefined. Check your build configuration."
I added the package to the solution and made the changes as stated in the linkin guide like so:

Alright. I've learned now, that I need to build once through Visual Studio before I can use react-native run-windows through the terminal.


Mouse wheel support regression?

Version 2<IP_ADDRESS>, pushed out over the past couple of days. Mouse wheel support has regressed. The thin scroll bar moves up and down but the glyphs remain stationary. I can move the mouse pointer to the scroll bar; it widens, and I can drag to scroll.
This is under Windows 10 1809, which I upgraded a couple of days ago. Very similar to Issue #30 as originally reported..
Arrow keys do work.

This issue is still present sometimes in v2<IP_ADDRESS> in Windows version 1909


Large file hangs on writing to irods?

service has been "writing to irods" for 20 minutes.  iRODS says 0 bytes written
/ebrc/workspaces/lz:
  qawrkspuser       0 ebrcResc;wrkspReplResc;wrkspS1Resc            0 2020-06-26.11:44 & dataset_u221741260_t1593184179961_p38.tgz

This is confirmed working, however there is still a logging problem, will open a new issue.


Customise JENKINS_HOME

Is it possible to change the value of JENKINS_HOME as i would like that be on dedicate volume rather then root volume

I was looking for the same option and small addition to the file tasks/settings.yml did the trick. I've added this snippet for setting jenkins home directory
- name: Set Jenkins Home directory
  lineinfile:
    backrefs: yes
    dest: "{{ jenkins_init_file }}"
    regexp: '^JENKINS_HOME='
    line: 'JENKINS_HOME={{ jenkins_home }}'
   register: jenkins_config

It is basically same principle as task with name "Set HTTP port in Jenkins config".

Thanks, will try this
On 19 July 2016 at 13:11, Miroslav Beka<EMAIL_ADDRESS>wrote:

I was looking for the same option and small addition to the file
tasks/settings.yml did the trick. I've added this snippet for setting
jenkins home directory

name: Set Jenkins Home directory
lineinfile:
backrefs: yes
dest: "{{ jenkins_init_file }}"
regexp: '^JENKINS_HOME='
line: 'JENKINS_HOME={{ jenkins_home }}'
register: jenkins_config

It is basically same principle as task with name "Set HTTP port in Jenkins
config".
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/geerlingguy/ansible-role-jenkins/issues/68#issuecomment-233613215,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADh8xYuZriEjecIiOWY80J9bKJ0BVrNgks5qXL7zgaJpZM4JPdwu
.

But keep in mind that there are many hard coded paths to default jenkins home /var/lib/jenkins so don't forget to replace all of these paths with your {{ jenkins_home }}

Yep replaced all with variable


error: unknown start of token: \u{ff0c}

use rscx::html;

pub fn t1() {
    html! {
        <h1> 你好， 世界 </h1>
    };
}

https://www.htmlsymbols.xyz/unicode/U+FF0C
hello, I can't add a "Chinese comma" to a Chinese sentence, build failed.
the same as "。"

Hey, thanks for trying rscx and taking the time to report this!
The solution is to wrap your content in quotes, like a string:
use rscx::html;

pub fn t1() {
    html! {
        <h1>" 你好， 世界 "</h1>
    };
}

This is also valid for emojis.
This behaviour comes from https://github.com/rs-tml/rstml, the underlying crate I'm using to parse the RSX syntax :)