drivers: Add Atmel SAM family I2C (TWI) driver

Added I2C bus (TWI) driver for Atmel SAM MCU family. Only
I2C Master Mode with 7 bit addressing is currently supported.
Origin: Original
Signed-off-by: Piotr Mienkowski<EMAIL_ADDRESS>

Pinmap/pinmux should be moved to the board rather than reside under the SOC.

@bryan-hunt the pinmux code configures pins as defined by the Atmel SAM SoC family datasheets. It has nothing to do with the specifics of the board implementation/routing. Pins are configured only when the device instance is initialized, otherwise they are not touched.

Yes it does match the SAM3/SAM4S series datasheets where the pinmux is many to one but for the SAMD or SAME series with more conventional pinmuxing the map is many to many so I was recommending the change for convention with the number of other boards already in the zephyr system (e.g. stm32f429i_disc1, arduino_101, frdm_k64f, etc). As I'm working on both the SAM4s Xplained Pro and SAMD21 Xplained Pro ports I'll leave the pinmap where it is in my pull request for the SAM4S and leave the question of convention up to the ARM arch guys.

Good point. If a signal can be routed to more than one pin on the SoC the choice should be made by the board config. This is handled currently by selecting a Kconfig option. E.g. to choose UART1 TXD pin on SAME70 SoC one has to set one of UART_SAM_PORT_1_PIN_TX_PA4, UART_SAM_PORT_1_PIN_TX_PA6, UART_SAM_PORT_1_PIN_TX_PD26 Kconfig options. This has to be ported to DTS. It's still on the TODO list.
By keeping the actual pin muxing code local to SoC we have only one copy of it.

I have change usage of cfg.bits.speed as requested, also updated SAM4S Xplained board documentation adding support for I2C driver.
Could we handle the IRQ, peripheral ID, register addresses data from DTS issue when the config structure generation concept is ready? There are potentially more device drivers which will be affected.

@galak I would like to rework twihs_sam I2C driver but it would create merge conflicts with this one if submitted simultaneously. Could we merge this driver if there are no further issues?

I would like to make the DT changes so its easier to tell what needs to get generated and see what patterns there are as we go down that path.

@galak the thing about IRQ number and register addresses is that we get them all for free from CMSIS header files. Going over DTS is a long way and is error prone; best avoided. However, if we want to generate device configuration data structure fully automatically then indeed DTS seems like the only way to go. The tricky part will be generating pin configuration data. I was asking about the concept because it's not clear to me what is the goal / what we want to achieve.
If we want to auto generate complete device configuration data structure then we also need to include Peripheral ID in DTS. Should I add it?

Yes lets add Peripheral ID to the dts.  The intent is to get DTS to a point that SoC related data (address, irq, pins, clocks, etc) is coming from it, and we can use it to generate.  Which is why I ask to use the DT for the things we have, so we can start flushing out the things missing.

I've yet to see an example for the SAM series where the peripheral id differs from the IRQ number since the peripheral id is used to enable the interrupt. Might I suggest just using the IRQ number unless there is a compelling reason (like an exception to the rule) to add it?

I think its better to introduce the peripheral id separate from the IRQ.  It saves us pain down the line when some SoC breaks the rule or have might have some peripheral with multiple IRQs.

I've prepared requested update. I also added Peripheral ID to the configurations of all the remaining Atmel SAM DTS drivers (as a separate commit).


JavaScript Lib.alert was deprecated.

Main.hx:8: characters 12-21 : Warning : Lib.alert() is deprecated, use Browser.alert() instead

Thanks!


package overrides using a mini module system

Description of changes

Putting a package's configuration options into function arguments in order to expose them via override is a well established pattern but has major issues:

No discoverablilty/documentation of available options
Namespace collisions (calling an option "xorg" would result in callPackage inserting the xorg package set)
Odd syntax and scoping limitations when declaring options (? and no ability to use let bindings)
No type checking
No good error messages
No sane way to transparently communicate breaking changes

But we have a well-established solution to all those problems: The module system.
This is a little thought that came to my mind while thinking about RFC 169:
Why couldn't we just use the module system for configuring packages?
The extent to which this is done here is merely the configuration options that were explicitly exposed by the package before which is similar to how modules are used NixOS; explicit options provided by the package maintainer to customise some specific aspect of the package.
The only limitation I currently see is that it is a bit awkward to compose multiple overrides:
# This is fine
(mlterm.override {
  configuration = {
    gui = {
      wayland = false;
      sdl2 = false;
    };
  };
}).override
  # This requires advanced knowledge of the moule system and overrides
  (prev: {
    configuration = {
      imports = [ prev.configuration ];
      gui.sdl2 = true;
    };
  })

This could however be remedied using a dedicated overrideFeatures function.
As for performance:
Previous:
[atemu@HEPHAISTOS nixpkgs]$ hyperfine --warmup 1 -r 30 'nix-instantiate -A ffmpeg'
Benchmark 1: nix-instantiate -A ffmpeg
  Time (mean ± σ):     716.5 ms ±  13.9 ms    [User: 430.6 ms, System: 143.5 ms]
  Range (min … max):   658.7 ms … 738.2 ms    30 runs

[atemu@HEPHAISTOS nixpkgs]$ hyperfine --warmup 10 -r 30 'nix-instantiate -A mlterm'
Benchmark 1: nix-instantiate -A mlterm
  Time (mean ± σ):     739.5 ms ±  33.0 ms    [User: 445.2 ms, System: 151.8 ms]
  Range (min … max):   688.9 ms … 792.6 ms    30 runs

With modules:
[atemu@HEPHAISTOS nixpkgs]$ hyperfine --warmup 1 -r 30 'nix-instantiate -A ffmpeg'
Benchmark 1: nix-instantiate -A ffmpeg
  Time (mean ± σ):     712.8 ms ±  21.4 ms    [User: 428.8 ms, System: 143.0 ms]
  Range (min … max):   657.3 ms … 748.0 ms    30 runs

[atemu@HEPHAISTOS nixpkgs]$ hyperfine --warmup 10 -r 30 'nix-instantiate -A mlterm'
Benchmark 1: nix-instantiate -A mlterm
  Time (mean ± σ):     740.9 ms ±  35.9 ms    [User: 446.8 ms, System: 152.2 ms]
  Range (min … max):   687.8 ms … 795.2 ms    30 runs

There might be a slight difference here but none that I could measure using runtime.
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.

My thoughts on this draft:
Unfortunately we can't measure the performance impact by adding only a handful of examples.
The performance impact of the module system is bounded by how much you ask it to do.
That means that we don't have to expect the impact of, say, loading NixOS's massive module list, but something very small for small configs like these.
However, that means that for a realistic picture, we need to apply this solution to all packages in ffmpeg's closure, or a known portion for which we get a statistically significant difference.
With the Nixpkgs architecture team, we've looked into applying the module system more broadly. See e.g.

https://github.com/NixOS/nixpkgs/issues/295030

Reducing the scope of module system usage may alleviate the performance issue somewhat, but then the question is whether this is the most effective allocation of our evaluation performance "budget". (I don't have an answer)
By applying the solution to only part of the problem, I feel like we're almost making the situation worse because of the added complexity of having different solutions for what are actually instances of the same problem - package configuration is just parameters, just like dependencies are, or "environment" things like the platforms. Shouldn't they all be discoverable, mergeable, etc?

Obviouslt my question is: how hard will be to teach this to newcomers?

Teach what to newcomers? The module system they likely already use in NixOS?

Yes, given that Nixpkgs is not tied to NixOS.

What part do you expect to be hard to teach to newcomers? From the perspective of a user, they provide an attrset of configuration either way. I don't see how usage of this API would be any harder to understand than the status quo; using a module system requires basically no knowledge of its internal mechanisms.
I'd argue it'd be slightly simpler to use actually because error messages would be a lot easier to understand: "anonymous function at ... called with unexpected argument withFoo" vs. "the option foo does not exist". And that's ignoring the errors you could catch via typecheck instead of incredibly confusing "cannot coerce ... into a string".

What part do you expect to be hard to teach to newcomers?

Any part not well documented, to begin with.
https://nixos.org/manual/nixpkgs/stable/#module-system

Note
This chapter is new and not complete yet. For a gentle introduction to the module system, in the context of NixOS, see Writing NixOS Modules in the NixOS manual.

(bold mine)

I do not see how the developer documentation for setting up a module system would be relevant to users merely using a module system that someone else already set up.
As per my previous comment, no newcomer needs to know about the module system's internal mechanisms in order to configure something with it.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/is-there-a-way-to-get-the-description-of-a-package-rather-than-the-software-it-contains/46742/4

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/need-for-coorinated-enforced-boolean-switch-arguments-in-nixpkgs/48948/5

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/a-sad-state-of-nixpkgs/49397/5

I just noticed that there has been prominent precedent for this in Nixpkgs for many years now: The structured Linux kernel config drv.
It uses much the same pattern as what I "came up" with. (I didn't actively think of the kernel config but it may have subconsciously influenced me.)
Introduced all the way back in 2018 by @teto: https://github.com/NixOS/nixpkgs/pull/42838

Over the past few weeks, I've been chugging away at an expansion on this idea: making full use of the module system and its type system to define all the core aspects of the derivation (configureFlags and buildInputs).
This new design is quite elegant IMHO; utilising the basic building blocks of the module system to massively cut down the complex and repetitive derivation implementation code into simple data that is even conveniently malleable at "runtime" by end-users.
The line count is roughly double but that is mostly data declaration syntax overhead ({ and };s) and the rest is, as mentioned, mostly data rather than code, so I don't think that's bad at all.
I much prefer this over the mess that is the function arguments.
What I especially like is that the packages required for a given feature are now declared in the same place as the feature flag itself. This just feels right to me and also allows for further introspection as you can now programatically figure out which feature pulls in which dependency.
I have not done proper performance testing yet. A quick and dirty test on my laptop showed a significant regression but that was well within the margin of error for a power-limited laptop CPU, so that's hardly conclusive.
This is based on a much older state of ffmpeg, so it's missing a few options that have been added or changed since. I will rebase this in due time but I only care about a working POC for now to fine-tune the design.

Before:
$ hyperfine --warmup 10 -r 30 'nix-instantiate -A ffmpeg-headless'
Benchmark 1: nix-instantiate -A ffmpeg-headless
  Time (mean ± σ):     464.4 ms ±  15.9 ms    [User: 289.1 ms, System: 100.4 ms]
  Range (min … max):   429.5 ms … 486.9 ms    30 runs

$ hyperfine --warmup 10 -r 30 'nix-instantiate -A ffmpeg'
Benchmark 1: nix-instantiate -A ffmpeg
  Time (mean ± σ):     709.7 ms ±  33.3 ms    [User: 450.4 ms, System: 134.3 ms]
  Range (min … max):   649.3 ms … 750.7 ms    30 runs

$ hyperfine --warmup 10 -r 30 'nix-instantiate -A ffmpeg-full'
Benchmark 1: nix-instantiate -A ffmpeg-full
  Time (mean ± σ):     778.4 ms ±  36.8 ms    [User: 472.2 ms, System: 166.5 ms]
  Range (min … max):   710.5 ms … 828.2 ms    30 runs

After:
$ hyperfine --warmup 10 -r 30 'nix-instantiate -A ffmpeg-headless'
Benchmark 1: nix-instantiate -A ffmpeg-headless
  Time (mean ± σ):     484.4 ms ±  19.0 ms    [User: 316.3 ms, System: 92.1 ms]
  Range (min … max):   441.3 ms … 510.0 ms    30 runs

$ hyperfine --warmup 10 -r 30 'nix-instantiate -A ffmpeg'
Benchmark 1: nix-instantiate -A ffmpeg
  Time (mean ± σ):     727.0 ms ±  30.0 ms    [User: 459.6 ms, System: 148.2 ms]
  Range (min … max):   666.8 ms … 774.0 ms    30 runs

$ hyperfine --warmup 10 -r 30 'nix-instantiate -A ffmpeg-full'
Benchmark 1: nix-instantiate -A ffmpeg-full
  Time (mean ± σ):     815.5 ms ±  38.0 ms    [User: 523.3 ms, System: 157.6 ms]
  Range (min … max):   762.0 ms … 884.0 ms    30 runs

There appears to be an effect of about 5% but that only corresponds to ~1σ which isn't really significant, so it's hard to say whether there's an actual negative effect through runtime testing.
Here's the diff of NIX_SHOW_STATS=1 of ffmpeg-full which I expect to show the greatest difference since it contains 3 separate evals of ffmpeg:
│  1 │warning: you did not specify '--add-ro↵ │  1 │warning: you did not specify '--add-ro↵
│    │ot'; the result might be removed by th↵ │    │ot'; the result might be removed by th↵
│    │e garbage collector                     │    │e garbage collector
│  2 │/nix/store/3ykq8wg61ibq7xaxcz8h7ygf08i↵ │  2 │/nix/store/4pwzjp1bb4axh7r8ap3jdp777x0
│    │2l8zi-ffmpeg-full-6.1.1.drv!bin         │    │8a4k1-ffmpeg-full-6.1.1.drv!bin
│  3 │{                                       │  3 │{
│  4 │  "cpuTime": 0.46145400404930115,       │  4 │  "cpuTime": 0.5295500159263611,
│  5 │  "envs": {                             │  5 │  "envs": {
│  6 │    "bytes": 15570136,                  │  6 │    "bytes": 27651016,
│  7 │    "elements": 1173009,                │  7 │    "elements": 2054566,
│  8 │    "number": 773258                    │  8 │    "number": 1401811
│  9 │  },                                    │  9 │  },
│ 10 │  "gc": {                               │ 10 │  "gc": {
│ 11 │    "heapSize": 402915328,              │ 11 │    "heapSize": 402915328,
│ 12 │    "totalBytes": 195629904             │ 12 │    "totalBytes": 253786144
│ 13 │  },                                    │ 13 │  },
│ 14 │  "list": {                             │ 14 │  "list": {
│ 15 │    "bytes": 1935720,                   │ 15 │    "bytes": 3137688,
│ 16 │    "concats": 53881,                   │ 16 │    "concats": 78153,
│ 17 │    "elements": 241965                  │ 17 │    "elements": 392211
│ 18 │  },                                    │ 18 │  },
│ 19 │  "nrAvoided": 931140,                  │ 19 │  "nrAvoided": 1577220,
│ 20 │  "nrFunctionCalls": 693286,            │ 20 │  "nrFunctionCalls": 1228708,
│ 21 │  "nrLookups": 349445,                  │ 21 │  "nrLookups": 755979,
│ 22 │  "nrOpUpdateValuesCopied": 4800101,    │ 22 │  "nrOpUpdateValuesCopied": 5003831,
│ 23 │  "nrOpUpdates": 101294,                │ 23 │  "nrOpUpdates": 137413,
│ 24 │  "nrPrimOpCalls": 392853,              │ 24 │  "nrPrimOpCalls": 615520,
│ 25 │  "nrThunks": 1323307,                  │ 25 │  "nrThunks": 2033500,
│ 26 │  "sets": {                             │ 26 │  "sets": {
│ 27 │    "bytes": 96291744,                  │ 27 │    "bytes": 109203312,
│ 28 │    "elements": 5856951,                │ 28 │    "elements": 6502876,
│ 29 │    "number": 161283                    │ 29 │    "number": 322331
│ 30 │  },                                    │ 30 │  },
│ 31 │  "sizes": {                            │ 31 │  "sizes": {
│ 32 │    "Attr": 16,                         │ 32 │    "Attr": 16,

───────────────────────────────────────────────────────────────────────────────────────┐
• 35: warning: you did not specify '--add-root'; the result might be removed by the ga │
───────────────────────────────────────────────────────────────────────────────────────┘
│ 35 │    "Value": 24                         │ 35 │    "Value": 24
│ 36 │  },                                    │ 36 │  },
│ 37 │  "symbols": {                          │ 37 │  "symbols": {
│ 38 │    "bytes": 432883,                    │ 38 │    "bytes": 432598,
│ 39 │    "number": 41660                     │ 39 │    "number": 41663
│ 40 │  },                                    │ 40 │  },
│ 41 │  "values": {                           │ 41 │  "values": {
│ 42 │    "bytes": 47772936,                  │ 42 │    "bytes": 70875288,
│ 43 │    "number": 1990539                   │ 43 │    "number": 2953137
│ 44 │  }                                     │ 44 │  }
│ 45 │}                                       │ 45 │}

The only thing I take from this is that there are twice as many function calls now.

I don't think we have that many packages that would want to use this module system, hence I don't consider this price as too high for gradual insertion of this feature into Nixpkgs. I'd like to see this getting moved forward by rebasing etc, and see ofborg's checks will be green. I'd also like to practice afterwards in converting Gnuradio's and mpd's different features to use this module system.
I'd also like to discuss how the docs would look like.

I'm confident ofBorgs checks will pass because this evals to the exact same result (modulo order).

I've done a few more cleanups and refactors and I think I'm at a point where I'm quite happy with how the ffmpeg derivation turned out and can't immediately think of anything I'd change about the design anymore.

I'm pretty much on the same page w.r.t. eval time increase. For now, this only really makes sense to do in complex packages such as ffmpeg or Linux. A suspected eval time increase by ~1 standard deviation (10^-2 s) isn't a great cost to pay considering a typical NixOS eval takes 2-3 orders of magnitude longer.
While I'd like better documentation, the status quo is that nothing about package customisation is documented outside of code and its comments which is retained. I'd rather wait until we have a proper place and system coordinated for that at which point it should be trivial to plug ffmpeg's options into that.
What I'd like to discuss more is how to handle the override situation as it's all but intuitive or easy and I can't think of an easy solution. The best I can currently come up with is a dedicated override function (i.e. overrideFeatures).

What I'd like to discuss more is how to handle the override situation as it's all but intuitive or easy and I can't think of an easy solution. The best I can currently come up with is a dedicated override function (i.e. overrideFeatures).

Which would just be a thin wrapper around .override { configuration = ...; }?

While I'd like better documentation, the status quo is that nothing about package customisation is documented outside of code and its comments which is retained. I'd rather wait until we have a proper place and system coordinated for that at which point it should be trivial to plug ffmpeg's options into that.

It doesn't feel like a big deal to me - we have a place already to document how to use Nix expressions of packages, it's just not automatically generated. I agree we don't have to settle now on how exactly to build the workflow of adding these docs automatically, but I'd like to see that it is at least possible to generate some documentation files automatically from these expressions.

Which would just be a thin wrapper around .override { configuration = ...; }?

It'd work as described in the OP.
Though implementing it could be tricky because an override functions' scope is not local to the package.

we have a place already to document how to use Nix expressions of packages

Where? That's news to me.

I'd like to see that it is at least possible to generate some documentation files automatically from these expressions.

This already works for NixOS, I don't see why it wouldn't work here aswell.

This already works for NixOS, I don't see why it wouldn't work here aswell.

I tried it and it's trivial: pkgs.nixosOptionsDoc { inherit (ffmpeg.eval) options; }
What I noticed is that it puts a literal ‹name› where the submodule's name should be in sentences like The dependencies required to enable ‹name› support.. Not sure what's going on there.

Which would just be a thin wrapper around .override { configuration = ...; }?

It'd work as described in the OP.
Though implementing it could be tricky because an override functions' scope is not local to the package.

Hmm OK I see. Now I read in the OP that it is only an issue with multiple overrides? Why would someone need to do that?

It's only an issue with composing overrides indeed but you never know what people might need to do with your derivation.

multiple overrides are definitely a thing in nixos
consider a module which provides a package option watch requires a specific option - and allows the user to further customize options
i don't recall the concrete example to link at the moment but i if you look you will find it

Steam does this for instance:
https://github.com/NixOS/nixpkgs/blob/8c9630d265fa4665bd2ad86e39eadcb930470544/nixos/modules/programs/steam.nix#L45-L65
As you can see, it also needs to take great care of overriding in a composable manner but that's only necessary when composing values of arguments; composing top-level arguments themselves without "deeper" values is trivial.


file associations

📝 Provide a description of the new feature
What is the expected behavior of the proposed feature?  What is the scenario this would be used?

If you'd like to see this feature implemented, add a 👍 reaction to this post.

PowerToys would be the perfect place to create an enhanced default apps feature.  This could allow the user to easily change the default OPEN or EDIT options associated with each file extension.

@melvinmld
thanks for the suggestion.
PowerToys focus on bringing new functionality or very common features that are not already provided by Windows.
Changing file association is already available in Windows 10 and not something that users do on a regular basis.

If you see room for improvement to the current Windows 10 UI, please send your request to the Windows 10 team using the Feedback Hub application.

You are correct is does allow for the basic setting of the OPEN option.  It does not allow the user separately set the EDIT option.
This is something I use when switching between different development languages and tools.
This seems like something for power users (powertoys).
:)
Sent from my T-Mobile 4G LTE Device
-------- Original message --------
From: Enrico Giordani<EMAIL_ADDRESS>Date: 2/5/21 2:21 AM (GMT-05:00)
To: microsoft/PowerToys<EMAIL_ADDRESS>Cc: melvinmld<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [microsoft/PowerToys] file associations (#9495)
@melvinmldhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmelvinmld&data=04|01||d1ce61f7fce44380e2f808d8c9a6ab03|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637481064949426224|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=lHDrUAe2oRSMPu4fRc3qem80vku2qCUls15an1mJHkA%3D&reserved=0
thanks for the suggestion.
PowerToys focus on bringing new functionality or very common features that are not already provided by Windows.
Changing file association is already available in Windows 10 and not something that users do on a regular basis.
[image]https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fuser-images.githubusercontent.com%2F3206696%2F107002151-18419b80-678b-11eb-9e83-21b2e9cc79bb.png&data=04|01||d1ce61f7fce44380e2f808d8c9a6ab03|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637481064949426224|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=m6v%2F9jb5dSly34YWYkuaCsRtTxOcltDApiECaYIbwZw%3D&reserved=0
If you see room for improvement to the current Windows 10 UI, please send your request to the Windows 10 team using the Feedback Hub application.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FPowerToys%2Fissues%2F9495%23issuecomment-773847510&data=04|01||d1ce61f7fce44380e2f808d8c9a6ab03|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637481064949436189|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=4gDeEMJJ9D1oeG88ZKwC2Qq%2FVctzkkD4%2BXYz6E1LAVs%3D&reserved=0, or unsubscribehttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FASXJF3NRXC7FNCULADIGCJ3S5OL73ANCNFSM4XC7DN6Q&data=04|01||d1ce61f7fce44380e2f808d8c9a6ab03|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|637481064949436189|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=2a6r0%2B7xG9IIPTR%2Ftm18dhjDRKTD5IJIsSPZ7jNX4Vg%3D&reserved=0.


aes deadcode

@vogelpi
in  aes_reg_top.sv
  // register busy
  logic reg_busy_sel;
  assign reg_busy = reg_busy_sel | shadow_busy;
  always_comb begin
    reg_busy_sel = '0;
    unique case (1'b1)
      default: begin
        reg_busy_sel  = '0;
      end
    endcase
  end

reg_busy_sel is tied to 0 so the code could be changed to
  assign reg_busy = shadow_busy;

Hey @rasmus-madsen ,
this code is completely auto-generated by regtool depending on the hjson. Should we just exclude this code segment for coverage?


Got same tag for different android toolchains

Hunter calculates same sha1 for my (adjusted) polly toolchains.
The toolchains are named:

android-ndk-r12b-api-21-c++_static-arm64-v8a.cmake
android-ndk-r12b-api-21-c++_shared-arm64-v8a.cmake

and set CMake Variables:

ANDROID_STL c++_static
ANDROID_STL c++_shared

Which will have different behavior in android.toolchain.cmake (different files for linkage)
I can supply more information if needed.

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/37375799-got-same-tag-for-different-android-toolchains?utm_campaign=plugin&utm_content=tracker%2F1032790&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1032790&utm_medium=issues&utm_source=github).

Does compiler flags differs? If yes, can it be detected by some macro (like _CPPLIB_VER)?

I think the only difference is on link time, where it uses either libc++_static.a or libc++_share.so in same path.

Okay, so it's kind of "undetectable" flag. We should add a hint manually to toolchain, see for example:

https://github.com/ruslo/polly/blob/e6f0c41e920af8409ab6db07b9839168452d6bf6/flags/hidden.cmake#L19


Feature/entity dependencies card enhancements

I have extended the EntityHasSubcomponentsCard, EntityDependsOnResourcesCard and EntityDependsOnResourcesCard and EntityTable to supports tableOptions.
i have extended these components in such a way that it does not effect the current implementation just extend it capabilities to support tableOptions
This PR is the implementation for this https://github.com/backstage/backstage/issues/18503

@Rugvip  @benjaminr  @Edje-C @awanlin

This is pretty helpful.
As we scale Backstage adoption, we don't want to scroll down a lot. So from a UX perspective - Pagination and Filtering is a bliss.

Missing Changesets
The following package(s) are changed by this PR but do not have a changeset:

@backstage/plugin-catalog-react
@backstage/plugin-catalog

See CONTRIBUTING.md for more information about how to add changesets.
Changed Packages
Package Name	Package Path	Changeset Bump	Current Version
@backstage/plugin-catalog-react	plugins/catalog-react	none v1.7.1-next.0
@backstage/plugin-catalog	plugins/catalog	none v1.11.3-next.0

@Abhay-soni-developer ☝

@Abhay-soni-developer this will need some changesets :pray:

@benjdlambert  the requested changes  have been done. are we ready to merge this

@benjdlambert  i just merged the feedbacks after that pipeline is failing , can you help me resolve this
as i can not find the reason of failure

The e2e's are failing for a seperate reason - i've just mer7ged this.


Go file issue

can u upload it on github and link it. please (can be done via artifact/releases)

Hi my friend,
can you retry to download? I can download without problems, maybe it was something momentary

Hi my friend,
can you retry to download? I can download without problems, maybe it was something momentary

it is still would be better to use say. github releases

still having the issue for past few days

I can t upload on github because some files are too heavy (25 MB limit)
created a new link: https://gofile.io/d/rs9d8p


Bug: Modal width is always 100%

Info
Right now, our modal width is always set to take up full 100% width no matter what. The maxwidth property we currently have does nothing, as it's only applied on the mobile breakpoint.
Acceptance Criteria:

maxwidth should work as expected and limit the width of the modal to whatever is set

:tada: This issue has been resolved in version 1.16.0-alpha.2 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 4.16.0-alpha.2 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 1.17.0-alpha.1 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 4.17.0-alpha.1 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 1.17.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 2.6.0-alpha.1 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This issue has been resolved in version 2.6.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


ADAFRUIT_GFX_EXTRA needs to be implemented better

https://github.com/2dom/PxMatrix/blob/3ce13fe80681010103fe674c7f53bc4d0e10ead1/PxMatrix.h#L24
This is a handy way to tweak the value during development, but makes it hard to use this library as a user since users don't expect to modify library headers.
One option is to use a static class member with setter function, but this breaks the current usage model since the first place you can modify the value is in setup() which is after construction.
Another option is to add a constructor argument, but the constructor argument list is already getting kind of large. If pruned down, the bare minimum stripped constructor list would be (width, ADAFRUIT_GFX_EXTRA_WIDTH, height). The others could be moved to PxMATRIX.begin() since they're not critical for construction.

Hi...yeah...I suppose to reshuffle the constructor and begin arguments would be the cleanest approach. However it would break backwards compatibility.
I‘m not that familiar with the include behavior. Is it possible to define ADAFRUIT_GFX_EXTRA_WIDTH in the .ino file and only define it in the header if undefined? That would require a minimal change.
Cheers
Dom
Sent from my iPhone

On 23. May 2018, at 03:55, Kinsey Moore<EMAIL_ADDRESS>wrote:
https://github.com/2dom/PxMatrix/blob/3ce13fe80681010103fe674c7f53bc4d0e10ead1/PxMatrix.h#L24
This is a handy way to tweak the value during development, but makes it hard to use this library as a user since users don't expect to modify library headers.
One option is to use a static class member with setter function, but this breaks the current usage model since the first place you can modify the value is in setup() which is after construction.
Another option is to add a constructor argument, but the constructor argument list is already getting kind of large. If pruned down, the bare minimum stripped constructor list would be (width, ADAFRUIT_GFX_EXTRA_WIDTH, height). The others could be moved to PxMATRIX.begin() since they're not critical for construction.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

That would definitely be preferred, but can only be done if this is reworked as a header-only library. This is because if you
#define ADAFRUIT_GFX_EXTRA_WIDTH 10
#include "PxMatrix.h"
the constant is only defined for the copy of PxMatrix.h included from here. The copy of PxMatrix.h included into PxMatrix.cpp doesn't get that constant unless you somehow define it for the whole project (this can be done with the -D flag if using gcc or g++ directly).

Looking at the code, the biggest item that should be addressed is making PxMATRIX_buffer a member of the class instead of a global. This also has the benefit of removing global state which is a boon for someone wanting to run multiple panels on a different microcontroller.

I'm not sure the inline keyword is necessary, but yes to the rest.

Ok ... done. Check out the current master. The default behaviour is now to set ADAFRUIT_GFX_EXTRA_WIDTH to zero. Would that work?

Tested and functional. Thanks!


Generalized Into<AssetSourceId> and Into<AssetPath> Implementations over Lifetime

Objective

Fixes #10478

Solution
Generalised From/Into implementations over &str and Option<&str> for AssetSourceId and AssetPath across all lifetimes, not just static. To maintain access to the 'static-only specialisation, these types (and CowArc) now include an as_static method which will apply the specialisation.
// Snipped from `AssetApp`
fn register_asset_source(
    &mut self,
    id: impl Into<AssetSourceId<'static>>,
    //                          ^^^^^^^
    //                          | as_static is only available for 'static lifetimes
    source: AssetSourceBuilder,
) -> &mut Self {
    let id = id.into().as_static();
    //          ^^^^^^ ^^^^^^^^^
    //          |      | Specialized (internally storing CowArc::Static)
    //          | Generic Into (internally storing CowArc::Borrowed)

    // ...
}

This post-fix specialisation is available here because the actual specialisation performed is only a marker for if/when modification or ownership is required, making the transform a very cheap operation. For cleanliness, I've also added from_static, which wraps this behaviour in a clean shorthand designed to replace from calls.

Changelog

Generalised the following implementations over a generic lifetime:

From<&'static str> for AssetSourceId<'static>
From<Option<&'static str>> for AssetSourceId<'static>
From<&'static str> for AssetPath<'static>
From<&'static Path> for AssetPath<'static>

Added as_static specialisation to:

CowArc
AssetSourceId
AssetPath

Added from_static specialised constructor to:

AssetSourceId
AssetPath

Migration Guide
In areas where these implementations where being used, you can now add from_static in order to get the original specialised implementation which avoids creating an Arc internally.
// Before
let asset_path = AssetPath::from("my/path/to/an/asset.ext");

// After
let asset_path = AssetPath::from_static("my/path/to/an/asset.ext");

To be clear, this is only required if you wish to maintain the performance benefit that came with the specialisation. Existing code is not broken by this change.

Merging once merge conflicts are resolved :)


api: Include host_tag for status API

The host tag is important for understanding why things are queued up.
Signed-off-by: Andy Doan<EMAIL_ADDRESS>

ci-rerun


Missing word in document

There's a typo in the document, or rather a missing word. "Otherwise, you will have to make a copy the disk for each VM you want to create." should be "Otherwise, you will have to make a copy of the disk for each VM you want to create."

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 218c3a24-424f-e928-d0c0-89c8b8349bc8
Version Independent ID: 0ba31a4b-94cf-2b4f-1fbc-29a92fe7d97a
Content: Download a Windows VHD from Azure - Azure Virtual Machines
Content Source: articles/virtual-machines/windows/download-vhd.md
Service: virtual-machines
Sub-service: disks
GitHub Login: @cynthn
Microsoft Alias: cynthn

@JuanKerr Thanks for pointing this out. We will do the doc changes accordingly.

@JuanKerr The document is updated and changes will go live soon.


Main

Purpose
Resolves #2392
Add support for

[x] CSV file in page dir
[x] CSV file in remote URL
[x] Supports any delimiter

Screenshots
If this is a GUI change, try to include screenshots of the change. If not, please delete this section.
Documentation
{{< table src="cars.csv" header=true caption="Table 1"  delimiter=";" >}}

Tag
Default
Alternative

src
Name of a file in the page dir
A direct remote URL to csv

header
true
false won't let the row 0 to be header

delimiter
,
;,/,\t etc.

I could not implement a way to verify if the resource file is available in the page dir and throw an error otherwise

Also forgot to mention that this shortcode fully supports markdown and emoji within the CSV file.
My only problem with this is that the captions are not darkmode friendly.
A future feature could be implementing numbering which already works very nicely in the figure shortcode.

@bevsxyz thanks for your contribution. Feel free to open a separate PR for your dark-mode improvement.


Charge links: (BRS-037) Add/store charge link upon a received charge link request

Synopsis
Once a (Charge)LinkCommand, containing a brand new charge link, is published to the internal ServiceBus, our existing LinkCommandReceiver function must be extended to be able to store the charge link data in the SQL database.
Notes:
The data model for Charge Link has been defined and must be implemented with this story.

Scope:

IN: All charge types can be linked (tariffs, fees and subscription)
OUT: Validations
OUT: Handling/updating any existing charge link data in the database. We are only storing new links.

Acceptance criteria:
1) The data model for Charge Link has been implemented and is part of deployment.
2) Given a LinkCommand event with a brand new valid charge link (new combination of Metering Point ID and ChargeID+Type+Owner) is available in the ServiceBus
When LinkCommandReceiver process the command
Then the Charge Link is stored in the SQL database
(And a LinkCommandAccepted event is still published)
3) Ensure that all charge types can be linked; tariffs, fees and subscriptions.
** TECH NOTE:
Use Domain generated GUID ID values for entities#554
Needs discussion
Should we keep all the relations as they are now? Some of the relations on Charge seem unnecessary to me.
Should we rename ChargeId to better describe it is supplied by the "customer"? It is not unique by itself.
Synopsis
The team wishes to move away from the RowId relation between our models. This is partly because it is cumbersome relying on the database to create the ids, instead, we want to be able to create the whole model with relation ids in code before persisting them.
So now all models should upon creation assign a GUID as its Id. This Id should be used for creating relations toward other tables the model relies on.
Acceptance criteria:

Models upon creation must assign a GUID as Id.
RowId on models is removed from the codebase as well as the database tables.

Bjarke: Thomas Bach suggests that we improve performance by adding a clustered index on a column with a sequence number. His links:
http://www.nullskull.com/a/1504/why-guids-are-not-a-good-idea-for-sql-server-primary-keys.aspx
https://stackoverflow.com/questions/11938044/what-are-the-best-practices-for-using-a-guid-as-a-primary-key-specifically-rega/11938495
https://www.mssqltips.com/sqlservertip/4961/sql-server-insert-performance-for-clustered-indexes-vs-heap-tables/

Tasks

[X] Add SQL model
[X] Add create logic (no unit tests)
[ ] Add create unit tests
[ ] Add actual persistance
[ ] Create story to use domain generated GUID ID values for entities everywhere
[ ] Update ChargeLink data model entity diagram

Clean code tasks

[ ] enddatetime ikke nullable
[ ] Squadron problem med db unit tests
[ ] MeteringPointRepository - dubleret kode - skal fokuseres på aggregate og ingen dublering
[ ] Brug GUID ID alle steder
[ ] Mangler vi nogle uniqueue indexes til at undgå ulovlige charge links? Charges.MeteringPointId, ..
[ ] Fix connection state for dbup metetering point test data
[ ] Organiser efter aggregates?
[ ] Ingen integrationstests => nemt at breake main pga. DI (selvom al kode ellers er korrekt og med 100% coverage)

Removing this clean code task as it appears to probably not be worth the effort according to talk with @dstsyst about using integrationtests more intensively and actually spinning up function while executing XUnit unit tests (both localhost and in pipeline). Besides the assumed solution would be based on similar test in market role domain which happens to only test the actual configuration of the DI container but not whether all necessary dependencies has actually been configured (e.g. those from the function endpoints).

[ ] Ingen integrationstests => nemt at breake main pga. DI (selvom al kode ellers er korrekt og med 100% coverage) (@BjarkeMeier)

Testing in progress
Env: T
Commit:  dcae461

AC1: Charge Links data model implemented and deployed:

AC2: Using MP ID<PHONE_NUMBER>00000005) to create charge links:

Create tariff link (tariff: 334-tariff):
CorrelationID: 9bcc1dbe-0929-47c1-9754-f283a81f1115
No EndDate provided in CIM XML-
Stored with correct StartDate + EndDate:

ChargeLinkCreated integration event:
{
  "ChargeLinkId": "09116efa-f417-41d4-995f-9363bf25cbdc",
  "MeteringPointId": "571313180000000005",
  "ChargeId": "334-tariff",
  "ChargeType": 3,
  "ChargeOwner": "8100000000030",
  "ChargeLinkPeriod": {
    "StartDateTime": {
      "Seconds":<PHONE_NUMBER>,
      "Nanos": 0
    },
    "EndDateTime": {
      "Seconds":<PHONE_NUMBER>99,
      "Nanos": 0
    },
    "Factor": 1
  }
}

Create fee link
Create sub link


Add delete dashboard button

Adds a delete button for removing a dashboard (I just picked a "-" icon, let me know if you'd prefer a different style @rsnyman)
Adds a delete dash modal
On delete the user is taken to the empty dashboard state

OK pushed those changes and updated the screenshots to reflect them.


Document how to get the project building and running

It's not intuitive for a new developer/modder to get the program imported, building and running. We need documentation.

I think the first screenshot at https://github.com/Cardshifter/Cardshifter/wiki/2--Running-the-application is showing the wrong working directory, I believe it should be in extra-resources

You're right, I'll fix that tonight. Should be .../Cardshifter/extra-resources right?

This has been documented pretty well:
1- Getting started with development
2- Running the application

Documentation about branches has been added in wiki: Branches (Git)


Overlay supports repositioning upon resize / scroll

As of now, overlays only position themselves once (and when told to reposition through the OverlayRef).
This issue tracks overlays being able to automatically reposition themselves when scrolling or resize.

Any ETA on this?

@jelbourn almost all components that use overlay look broken because this doesn't work.. it seems like a pretty high priority thing to me. Do you want to work on this internally, or I can try and make a PR?

@fxck This is something we plan to work on- I have a specific approach in mind.

and do you have it written down somewhere? @jelbourn

@jelbourn this is such a pain in the ass.. can you please share what you have in mind so I can give it a shot?
Is it what's in https://docs.google.com/document/d/1jSMjkKSdzbQa2cuCeSFpzFAwDHr7xY4eqsXkfF6MeqA/preview or something else entirely?

It's mostly what's in the doc.
@crisbeto has been exploring the "disable scrolling" option in #1971 and @andrewseguin is already working on the repositioning.

Stumbled upon this issue because I am trying to figure out why the MdDialog is position:static (changing to absolute fixes it...kind of). The overlay is on top of the dialog and the dialog is full width of the page (no width is declared in my config). Is this broken or do I need to do something to get it to work? I can fix it by adding display:flex and height: 100% to the .md-global-overlay-wrapper, but not sure if that is the correct way to go about it.

Try clearing your node_modules @mycarrysun. There have been a few similar issues after the latest release.

Hmm strange, it worked though! Thanks @crisbeto

@jelbourn for example if menu is open indeed scroll is disabled. But only if you using mouse roller. But there are other options to scroll. For example by pressing up, down, pageUp, pageDown, home and end keys.

#2703 adds this for tooltip. Once that is in, subsequent PRs can add this to menu and select.

Hi @jelbourn, any update on this issue? It's been 2 months now. Thanks!

This issue is now replaced by #4093

@jelbourn You mentioned this issue is replace by 4093, which is "Overlay-based components should handle page scroll gracefully." I'm sure you're right, but I'm not understanding what to do to handle resize events (since this closed issue is called "Overlay supports repositioning upon resize / scroll"). Would you clarify for those like myself who were searching the internet for how to handle problems in angular cdk overlay when the user resizes the window? For example, I see a CloseScrollStrategy that will close the overlay as soon as the user starts scrolling. Is there such a thing for resize, like a CloseResizeStrategy? Or some other way to approach that problem?

There isn't anything that does resize automatically; we don't consider it to be as core of a use-case. The Material Design team did some user studies at some point and found that the only people who really resize their browser windows are web developers.

Okay, well I'll probably use @HostListener('window:resize') or fromEvent and in the callback do overlay.dispose();


Fix for multiple users

This PR will solve issue #325
Install NVM4W at a shared location
All users of a PC should be able to use NVM4W when it has been installed.
Current version installs the NVM files in a sub-directory of the current logged in user. This sub-directory is not accessible for other users when logged in.

@coreybutler Do you have time for a CR?

@coreybutler gentle ping 😃

Sorry for massive delays.
NVM4W follows the same pattern npm does, which is a per user install. User-specific installs are necessary to prevent global node module conflicts. When one user logs in and runs npm install -g<EMAIL_ADDRESS>and another user logs in to run npm install -g<EMAIL_ADDRESS>the original is overwritten.


Add support for AC2A

I run a Bluetti AC2A power station and i would be very happy, if this device could be integrated.
AC2A.zip
Regards Matthias

@lgb-this  try https://github.com/ftrueck/bluetti_mqtt/pull/4

merged into this repo, thanks for the work.


Besides, this is a nice gentle entry into committing against Pion. :smile:
The original code.
	if atomic.LoadInt32(&pubCount) == 0 {
		atomic.AddInt32(&pubCount, 1)

I believe the intent is to only allow a single publisher to be created. Which is what will usually occur, but under the right [very rare] conditions, this can be violated, so while this is a low-probability race condition, it is possible.
To achieve what I think was intended, we need:
	if atomic.AddInt32(&pubCount, 1) == 1 {

Reference issue
No issue filed. Just PR to fix tiny

Nice catch, thanks @cameronelliott :D

Merged as ea3ce4dd345b1e1fc496d1c487e47848c0f06f48

The atomic stuff is easy to mess up, I wish it wasn't as sharp coming from mutex life.
I don't think I am super strong with concurrent programming in general, but getting better hopefully :D

Your work is amazing. Period.


fennel-ls: init at 0.1.0

Description of changes
Add package fennel-ls
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

Also, I think you need to rename the commit to fennel-ls: init at 0.1.0, to be consistent with the commit conventions

@yisraeldov Maybe also rename this PR's title to "fennel-ls: init at 0.1.0"?

Could you move the commits around and rebase a bit to make it look like this? It's important that you add yourself to the maintainer list in the commit before the commit with the package.
It might be a good idea to mark the PR as draft if you're unsure if you've rebased correctly. A wrong rebase can lead to pinging a lot of people.
maintainers: add yisraeldov
fennel-ls: init at 0.1.0

@yisraeldov Looks like you accidentally pulled in an extra commit during the rebase.

@yisraeldov Looks like you accidentally pulled in an extra commit during the rebase.

You are right, thanks, fixed

Feel free to mark your PR as ready for review again, since the rebase went smooth :+1:


fix(hesai): set PTP lock offset on sensor configuration

PR Type

Improvement
Bug Fix

Related Links

TIER IV INTERNAL LINK - corresponding sensing inquiry

Description

This PR adds support for the SET_PTP_LOCK_OFFSET and GET_PTP_LOCK_OFFSET PTC commands.
In the inquiry linked above, it was observed that not explicitly setting PTP lock offset sometimes causes the value to reset to 1 us on at least OT128. While this is likely a sensor firmware bug, being able to set this offset from within Nebula should improve usability, and should eliminate the need to use Hesai's web interface or desktop GUI.
PR Author should check the checkboxes below when creating the PR.

[ ] Assign PR to reviewer

Checklist for the PR Reviewer
Reviewers should check the checkboxes below before approval.

[ ] Commits are properly organized and messages are according to the guideline
[ ] (Optional) Unit tests have been written for new behavior
[ ] PR title describes the changes

Post-Review Checklist for the PR Author
PR Author should check the checkboxes below before merging.

[ ] All open points are addressed and tracked via issues or tickets

CI Checks

Build and test for PR: Required to pass before the merge.

Evaluation

Sensor Model
Works?

OT128
:green_circle:

Here is a demo of OT128:
https://github.com/user-attachments/assets/4145746e-ca97-48f9-a66c-cf98b7d5ba91
It has been confirmed that by restarting Nebula, for a brief moment, the setting can revert to the old value (Hesai firmware bug or PTC documentation inaccurate). With this PR, it is immediately set to the desired value again.

Restricting this feature to only affect OT128 and QT128, as other sensors have been found to not support it (maybe a firmware update would change that).
Sadly, the current architecture for sensor configurations in Nebula forces us to add the parameter to ALL Hesai sensors, even if without any effect.


Interop Client Naming Conventions

Tiny change. Fixed naming conventions in test.proto:
UnimplementedMethod --> UnimplementedCall

Had to make these changes in a different pull request so docker would compile. I will just close this one.

Actually, in the interest of splitting up pull requests by topic and language, it makes more sense to leave this one here. Sorry for the confusion.

Assigned Eric because he checked over the original PR, #8234


Workloads lacks specifying constituent Resource version: suggest change to gem5 Resources JSON schema.

The current workloads lack the specification of resource versions for the resources they contain. This issue arises when attempting to retrieve a specified resource from the workload. In this scenario, the system automatically resorts to using the latest resource version that is compatible with the installed gem5 version. However, this behavior is not the intended one. Ideally, a workload should explicitly define the precise version of the resource it requires.
This situation can also lead to complications when multiple data sources contain resources required by a workload. Instead of adhering to the resource version specified in the workload, the "obtain resource" function retrieves the latest compatible version from all available data sources. This behavior diverges from the intended outcome.
The current workload structure is as follows:
{
    "category": "workload",
    "id": "x86-matrix-multiply-omp-100-8-looppoint-region-7",
    "description": "A workload which loads a Looppoint JSON file for the 'x86-matrix-multiply-omp' binary with inputs '100' and '8' and runs region 7 via a checkpoint.",
    "function": "set_se_looppoint_workload",
    "resources": {
        "binary": "x86-matrix-multiply-omp",
        "looppoint": "x86-matrix-multiply-omp-100-8-looppoint",
        "checkpoint": "x86-matrix-multiply-omp-100-8-looppoint-checkpoint-region-7"
    },
    "additional_params": {
        "region_id": "7"
    },
    "architecture": "X86",
    "size": 0,
    "tags": [],
    "code_examples": [],
    "license": "",
    "author": [],
    "source_url": "",
    "resource_version": "1.0.0",
    "gem5_versions": [
        "23.0"
    ],
    "example_usage": "Workload(\"x86-matrix-multiply-omp-100-8-looppoint-region-7\")"
}

The new change would be to change the resources field to obtain_resources. The obtain_resources field would be a dictionary that has a category of resource for example "binary" as key and a dictionary containing resource id and version as value.
The above resource will look as follows with the new changes:
{
    "category": "workload",
    "id": "x86-matrix-multiply-omp-100-8-looppoint-region-7",
    "description": "A workload which loads a Looppoint JSON file for the 'x86-matrix-multiply-omp' binary with inputs '100' and '8' and runs region 7 via a checkpoint.",
    "function": "set_se_looppoint_workload",
    "obtain_resources": {
        "binary": {
             "id": "x86-matrix-multiply-omp",
             "resource_version": "1.0.0"
         }
        "looppoint":{
             "id": "x86-matrix-multiply-omp-100-8-looppoint",
             "resource_version": "1.0.0"
         }
        "checkpoint": {
             "id": "x86-matrix-multiply-omp-100-8-looppoint-checkpoint-region-7",
             "resource_version": "1.0.0"
         }
    },
    "additional_params": {
        "region_id": "7"
    },
    "architecture": "X86",
    "size": 0,
    "tags": [],
    "code_examples": [],
    "license": "",
    "author": [],
    "source_url": "",
    "resource_version": "2.0.0",
    "gem5_versions": [
        "23.1"
    ],
    "example_usage": "Workload(\"x86-matrix-multiply-omp-100-8-looppoint-region-7\")"
}

This change will add a new version for all resources and this new version will be compatible with gem5 version 23.1 and onwards.
Incorporating this new change would necessitate an update to the resources schema. As modifications accumulate within resources, maintaining a universally applicable schema becomes progressively intricate. To address this challenge, a pragmatic approach could involve maintaining distinct schemas tailored to different gem5 versions. Subsequently, a validation script could be developed, leveraging the gem5_versions attribute of each resource to ensure alignment with the appropriate schema. This approach would contribute to a more streamlined and manageable system as gem5 evolves.

Todos:

[ ] Figure out where to store schemas for older versions, and how will they be accessed.

[ ] Figure out how validation of multiple schemas works with MongoDB.

[ ] Create an updated schema for the new gem5 version.

[ ] Add workload changes to the schema.

[ ] Write scripts that can update all existing workloads to new versions following any changes in dependent resources or an update to the schema.

[ ] Update all workloads to a new version following the schema change.

[ ] Update stdlib implementation of workload to reflect the changes.

Going to add some notes in here:

Todos:

[ ]  Figure out where to store schemas for older versions, and how will they be accessed.
[ ]  Figure out how validation of multiple schemas works with MongoDB.
[ ]  Create an updated schema for the new gem5 version.
[ ]  Add workload changes to the schema.
[ ]  Write scripts that can update all existing workloads to new versions following any changes in dependent resources or an update to the schema.

I don't understand this one. Do you mean create new versions of existing workloads to conform to the new schema design?

[ ]  Update all workloads to a new version following the schema change.

This is essentially part of the "Write scripts that can update all existing workloads " task, right? These new workloads should be for v23.1, right?
What I do think needs to be an explicit step is the the updating of the non-Workload resources to state they are compatible with v23.1

[ ]  Update stdlib implementation of workload to reflect the changes.

I think this step needs to be done at the same time as we add the new data conforming to the new schema. If we uddate gem5 before then it'll try to access resources it doesn't have compatibility with, but if we update the data first the gem5 binary can't parse the data in the new format... it's a bit annoying. There me be an awkward overlap here when the data is updated, breaking develop for people, and then you get your PR merged.

I don't understand this one. Do you mean create new versions of existing workloads to conform to the new schema design?

Yes, but also the script that updates a workload version when a dependent resource is updated.

This is essentially part of the "Write scripts that can update all existing workloads " task, right? These new workloads should be for v23.1, right?

Yes, but I separated them because it seemed like two different steps, one is to create scripts and then update.

What I do think needs to be an explicit step is the updating of the non-Workload resources to state they are compatible with v23.1

Do you mean that when a workload is updated to be compatible with the new gem5 version, it updates its dependent resources as well?
If the same resource and version are compatible with the new gem5 version we just append to the list of gem5_versions in JSON, so should that also happen recursively, that is if a new gem5 version is added to a resource then it also gets added to the corresponding workload? If that is the case then we would need to directly write to the database.

This issue does somewhat relate to Discussion #201. Please engage in this discussion to ensure we do this right.


Unable to extract uploader id

[x] I'm reporting a broken site support issue
[x] I've verified that I'm running youtube-dl version 2021.12.17
[x] I've checked that all provided URLs are alive and playable in a browser
[x] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[x] I've searched the bugtracker for similar bug reports including closed ones
[x] I've read bugs section in FAQ

Verbose log
youtube-dl https://www.youtube.com/watch?v=B2uYX9dXQR4 --verbose
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['https://www.youtube.com/watch?v=B2uYX9dXQR4', '--verbose']
[debug] Encodings: locale UTF-8, fs utf-8, out utf-8, pref UTF-8
[debug] youtube-dl version 2021.12.17
[debug] Git HEAD: 17c872fb5
[debug] Python version 3.10.9 (CPython) - macOS-13.0.1-arm64-arm-64bit
[debug] exe versions: ffmpeg 5.1.2, ffprobe 5.1.2, rtmpdump 2.4
[debug] Proxy map: {}
[youtube] B2uYX9dXQR4: Downloading webpage
ERROR: Unable to extract uploader id; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
  File "/opt/homebrew/Cellar/youtube-dl/2021.12.17/libexec/lib/python3.10/site-packages/youtube_dl/YoutubeDL.py", line 815, in wrapper
    return func(self, *args, **kwargs)
  File "/opt/homebrew/Cellar/youtube-dl/2021.12.17/libexec/lib/python3.10/site-packages/youtube_dl/YoutubeDL.py", line 836, in __extract_info
    ie_result = ie.extract(url)
  File "/opt/homebrew/Cellar/youtube-dl/2021.12.17/libexec/lib/python3.10/site-packages/youtube_dl/extractor/common.py", line 534, in extract
    ie_result = self._real_extract(url)
  File "/opt/homebrew/Cellar/youtube-dl/2021.12.17/libexec/lib/python3.10/site-packages/youtube_dl/extractor/youtube.py", line 1794, in _real_extract
    'uploader_id': self._search_regex(r'/(?:channel|user)/([^/?&#]+)', owner_profile_url, 'uploader id') if owner_profile_url else None,
  File "/opt/homebrew/Cellar/youtube-dl/2021.12.17/libexec/lib/python3.10/site-packages/youtube_dl/extractor/common.py", line 1012, in _search_regex
    raise RegexNotFoundError('Unable to extract %s' % _name)
youtube_dl.utils.RegexNotFoundError: Unable to extract uploader id; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.

Description

I am having issues downloading this video. I tried VPN but that didn't work.

I have same problem with that

Same issue here

Same issue, same log.

Same issue, says to update but I already am on the latest version, waiting for an answer ASAP

#30839


Fails to render in 2018.1.3f1 or above

Hey there,
I just came across this project and wanted to give this a try. I haven't found exactly why, but the shader (or how the texture is managed on the plain) seems to fail.

I did not investigate much but I'm noting this here 👍 It's possible it fails on the 2017 versions too.

For the record, changes to shader files during the import are the following:
diff --git a/Assets/Snowprint/Shaders/SnowGroundShader.shader b/Assets/Snowprint/Shaders/SnowGroundShader.shader
index 6d73cb4..d720cbf 100644
--- a/Assets/Snowprint/Shaders/SnowGroundShader.shader
+++ b/Assets/Snowprint/Shaders/SnowGroundShader.shader
@@ -1,4 +1,6 @@
-<U+FEFF>Shader "Custom/snow_ground"
+<U+FEFF>// Upgrade NOTE: replaced 'mul(UNITY_MATRIX_MVP,*)' with 'UnityObjectToClipPos(*)'
+
+Shader "Custom/snow_ground"
 {
        Properties
        {
@@ -313,7 +315,7 @@
                                for(int i = 0; i < 3; i++)
                                {
                                        //apply model view projection
-                                       o[i].vertex = mul(UNITY_MATRIX_MVP,input[i].vertex);
+                                       o[i].vertex = UnityObjectToClipPos(input[i].vertex);
                                        o[i].uv = input[i].uv;
                                        o[i].detailuv =input[i].detailuv * discardFactor;
                                        o[i].tspace0 = input[i].tspace0;
diff --git a/Assets/Snowprint/Shaders/Sprites-Distance.shader b/Assets/Snowprint/Shaders/Sprites-Distance.shader
index 5cad0e1..d0dbbb3 100644
--- a/Assets/Snowprint/Shaders/Sprites-Distance.shader
+++ b/Assets/Snowprint/Shaders/Sprites-Distance.shader
@@ -1,3 +1,5 @@
+// Upgrade NOTE: replaced 'mul(UNITY_MATRIX_MVP,*)' with 'UnityObjectToClipPos(*)'
+
 Shader "Sprites/Distance"
 {
        Properties
@@ -58,7 +60,7 @@ Shader "Sprites/Distance"
                        v2f vert(appdata_t IN)
                        {
                                v2f OUT;
-                               OUT.vertex = mul(UNITY_MATRIX_MVP, IN.vertex);
+                               OUT.vertex = UnityObjectToClipPos(IN.vertex);
                                OUT.texcoord = IN.texcoord;
                                OUT.color = IN.color;
                                return OUT;

Found in youtube's comments:

On MacOS, I'm not running under DirectX, so it makes sense.

Hi, thank you. I'm sorry I am recently lacking of time working on this, but I'll look into the issues as soon as I can. I'm not familiar with Metal, but as far as I know, it should also support tessellation.


Artifact uploads do not have proper content-encoding metadata set

Summary
The default behavior for uploading artifacts is to first tar and gzip them. For uploads to S3, the content-encoding is not properly detected when the filename ends with .tgz. This is because Go's built-in mapping table is rather basic.
Argo's S3  PutFile
Minio's FPutObject
As such, .tgz files are being tagged with the wrong Content-Encoding: "application/octet-stream" instead.
The issue can likely be solved by adding mailcap as part of the argoexec-base image in the Dockerfile to bring in /etc/mime.types. It adds 84kb to the image size though.
What version are you running?
3.2.8
Diagnostics

Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.

Could be achieved by copying the file from the argoexec-builder stage in the Dockerfile?

Could be achieved by copying the file from the argoexec-builder stage in the Dockerfile?

Ah yes, Debian has the media-types package that can be installed to get /etc/mime.types. Then we should be good to copy from the argoexec-build stage into the final argoexec image.

Would you like to submit a PR for it?

@whynowy I've created a PR https://github.com/argoproj/argo-workflows/pull/8171 for this. It turns out that the base golang:1.17 image already contains the /etc/mime.types file as @alexec suggested, so there is no need to add extra packages 👍


Aggregate dev

In this PR we restructure the example analysis for the fourth step in the pipeline, aggregating data to the single-cell level. This follows the precedents set in previous merges of example analysis, which deviates from previous approaches in dev, such as here: https://github.com/lukebfunk/OpticalPooledScreens/commit/d94d93e6162c76e34e02b16fd69b19e90b545def
Notes:
There are major differences to previous commits in dev, nominally, that there is no example data provided. However, all code for aggregate is in a separate file, that was not pulled from Firesnake.
@roshankern This is ready for review!

@mat10d It looks like there are some merge conflicts for this PR. Are you able to address before I review so it is clear which code I should review? Alternatively, I can review the code on the aggregate_dev branch with the assumption that this is the correct code.

My fault, I didn't see those merge conflicts. Should be good now.

I just noticed there is no readme file for this module. That would definitely be helpful to newcomers (and myself) trying to understand what this module does and how!

I just noticed there is no readme file for the aggregate module. That would definitely be helpful to newcomers (and myself) trying to understand what this module does and how!

Added the readme!


TypeError: Object function Object() { [native code] } has no method 'assign'

Hi,
I was trying to use cross-env, and had the following TypeError: (edited the folder for privacy reasons)
><EMAIL_ADDRESS>watch-js /parent_project_folder/static/js
> cross-env NODE_ENV=production watchify --extension=.jsx --extension=.js src/app.jsx -o build/build.js --debug --verbose

/parent_project_folder/static/js/node_modules/cross-env/dist/index.js:58
  var envVars = Object.assign({}, process.env);
                       ^
TypeError: Object function Object() { [native code] } has no method 'assign'
    at getCommandArgsAndEnvVars (/parent_project_folder/static/js/node_modules/cross-env/dist/index.js:58:24)
    at crossEnv (/parent_project_folder/static/js/node_modules/cross-env/dist/index.js:22:35)
    at Object.<anonymous> (/parent_project_folder/static/js/node_modules/cross-env/bin/cross-env.js:3:19)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)
    at startup (node.js:119:16)
    at node.js:929:3
npm ERR! weird error 8
npm ERR! not ok code 0

When running npm run watch-js  I was trying to check if I correctly set the NODE_ENV variable to production, but got this error instead.
Debugging information:
$ node --version
v0.10.36

$ npm --version
1.3.6

Here's the package.json. I think that some of the devDependencies are not actually being used, in particular all babel, because I did not found a .babelrc file
    },
    "scripts": {
      "start": "npm run build && serve .",
      "build": "npm run build-js",
      "watch": "node server.js",
      "test": "npm run lint -s && npm run build",
      "build-js": "browserify --extension=.jsx --extension=.js src/app.jsx | uglifyjs > build/build.js",
      "watch-js": "cross-env NODE_ENV=production watchify --extension=.jsx --extension=.js src/app.jsx -o build/build.js --debug --verbose",
      "lint-eslint": "eslint .",
      "lint-jscs": "jscs .",
      "lint": "npm run lint-eslint && npm run lint-jscs"
    },
    "license": "MIT",
    "bugs": {
      "url": "https://github.com/mgonto/react-browserify-spa-seed/issues"
    },
    "homepage": "https://github.com/mgonto/react-browserify-spa-seed",
    "dependencies": {
      "bootstrap": "^3.3.0",
      "flux": "^2.0.1",
      "jwt-decode": "^1.1.0",
      "react": "^0.13",
      "react-addons": "*",
      "react-bootstrap": "",
      "react-chosen": "^0.3.8",
      "react-intl": "~1.2.0",
      "react-mixin": "^1.1.0",
      "react-router": "^0.13.2",
      "reqwest": "^1.1.5",
      "when": "^3.7.2",
      "underscore": "~1.8.3",
      "cross-env": "~3.1.3"
    },
    "devDependencies": {
      "babelify": "^6.1.0",
      "browser-sync": "^2.1.6",
      "browserify": "^8.0.3",
      "clean-css": "^3.1.9",
      "eslint": "^0.14.1",
      "rework": "^1.0.1",
      "rework-npm": "^1.0.0",
      "rework-npm-cli": "^0.1.1",
      "serve": "^1.4.0",
      "uglify-js": "^2.4.15",
      "watchify": "^2.1.1",
      "babel": "~6.5.2",
      "webpack-bundle-tracker": "0.0.93",
      "webpack": "~1.13.3",
      "babel-core": "~6.18.2",
      "babel-loader": "~6.2.7",
      "babel-preset-es2015": "~6.18.0",
      "babel-preset-react": "~6.16.0",
      "webpack-dev-server": "~1.16.2",
      "babel-plugin-transform-object-rest-spread": "~6.19.0"
    }

Sorry, cross-env dropped support for older versions of node a while ago. You can install an older version if you like.


Adapt to current rust-geo

This should allow to use rust-gdal with a current version of rust-geo :)

bors r+


druid.coordinator.merge.on broken for segments indexed to s3 deep storage with credentials at s3n

Hey,
on druid 0.10.1, I was using hadoop index tasks for a few years with :
InputSpec.inputPath = s3n://s3Id:s3Key@bucket/path

Even though the security part is not present in s3 deep storage descriptor.json, the merge and append tasks induced by druid.coordinator.merge.on are failing because the whole string s3Id:s3Key@bucket is considered bucket name in these tasks, this is the relevant part of errors from logs :
S3DataSegmentPusher - Pushing S3Object [
key=path/2017-10-08T00:00:00.000Z_2017-10-12T00:00:00.000Z/2017-11-02T17:51:52.862Z/0/index.zip,
bucket=s3Id:s3Key@bucket,
lastModified=null,
dataInputStream=null,
Metadata=....
]

To fix this, S3DataSegmentPusher would have to take this into consideration ...
I have no idea where it takes the s3Id:s3Key@bucket from, it must be somewhere in cache or mysql, because it is not in deep s3 storage afaik.

Ok, I think I know how to shake it off, I use :
druid/_common/common.runtime.properties:druid.storage.bucket=s3Id:s3Key@bucket

for hadoop indexing tasks because they have sometimes failed in previous releases if it was just part of tunningConfig or druid/_common/core-site.xml

Solved ^^


🚀 [FEATURE]: Change the position of Search bar in the Documentation Page

👀 Background
The current search bar/box in the documentation page is small and and quite hard to find/notice (i think), and the wording may sound off a little bit. This may lead to potential user or even current user that use RestQA feel annoyed, because they can't navigate the documentation page easily with help the search bar
✌ What is the actual behavior?
As you can see below, the search bar/box located at the right below side on your screen, crumpled and small

🕵♀ How to reproduce the current behavior?
No response
🤞 What is the expected behavior?
So I proposed to redesign the search bar/box in the documentation page, make it stand out and little bigger. It may helps people use the function and solve problems faster
😎 Proposed solution.
Like this one

🙏 Would you be willing to submit a PR?
None
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Love it! 🫶

@developerHet Interested by this challenge ?

hello I have added a PR regarding the issue. #379
please review it and give a feedback

The search bar specification is 530 width, 40 height and also make it centered.

Done 😄


Add the ability to specify terraform-pipeline starting execution workspace directory

Currently, we have the TerraformDirectoryPlugin which allows terraform-pipeline to do this:
TerraformDirectoryPlugin.withDirectory("app1/terraform").init()

terraform <command> app1/terraform
...

What i would like terraform-pipeline to support:
TerraformStartingDirectoryPlugin.withDirectory("appQ/terraform").init()

cd appQ/terraform
terraform <command> .

This is important with monolithic pipeline repo's where the .terraform-version flat file is only read from the root of the project tree when using the TerraformDirectoryPlugin.

Seems like a good UseCase.  In thinking through this, we'll have to be careful about how other TerraformCommandPlugins interact with this new UseCase.    What you're looking for is a separate shell step.

I don't know that TerraformDirectoryPlugin is so inappropriately named for this UseCase.  I wonder if it could offer both behaviors with the same plugin?
TerraformDirectoryPlugin.withDirectory("app1/terraform").init()

vs
TerraformDirectoryPlugin.withStartDirectory("app1/terraform").init()

or something like
TerraformDirectoryPlugin.withDirectory("app1/terraform").withCdCommand().init()

I like option one.
Extend TerraformDirectoryPlugin to support the withStartDirectory method

Note: Change in terraform 0.14 and 0.15 related to subdirectories.  https://www.terraform.io/docs/cli/commands/plan.html#passing-a-different-configuration-directory

bump

This is officially needed on terraform 0.15 and later.

Yeah, I went to use tf 1.0.1 and was hit with this issue.


integrate the liquid clustering macros

resolves #
docs dbt-labs/docs.getdbt.com/#

Problem

Solution

Checklist

[ ] I have read the contributing guide and understand what's expected of me
[ ] I have run this code in development and it appears to resolve the stated issue
[ ] This PR includes tests, or tests are not required/relevant for this PR
[ ] This PR has no interface changes (e.g. macros, cli, logs, json artifacts, config files, adapter interface, etc) or this PR has already received feedback and approval from Product or DX

question , why did you prepare this PR with support-python-model-session-submission-method as target branch ?

question , why did you prepare this PR with support-python-model-session-submission-method as target branch ?

@matanmichaely  - this is a private feature that I don't think we will ever merge to the original dbt-spark - I had to branch out from that branch to review only the delta


pop.mismatched-brackets

.hc 0.5.3;
; <>
pop.mismatched-brackets
# <>
; {}
pop.mismatched-brackets
# {}
; []
pop.mismatched-brackets
# []
; () # no error

Either get rid of the error, or understand its cause.


update movement manager

update movement manager

Coverage decreased (-0.02%) to 78.071% when pulling<PHONE_NUMBER>db1aecec7dd778e7ca463f2f079c65 on adityahenanda:dev into fd64494722296980dcd54ee0dc4fe906cebb4046 on danliris:dev.


updated weight function

Updated the weight function to allow for correct extrapolation even if all datapoints are outside the kernel limits.

Cool updates, I think we can use LOESS instead of KNN for different applications already.


Revert SQLite to allow side by side

https://spockle.atlassian.net/browse/DUI3-313

https://github.com/specklesystems/speckle-sharp-sdk/pull/48


security.json isn't exported to Zookeeper

security.json isn't exported to Zookeeper because the logic if [ ${#ZK_SECURITY_JSON} -lt 3 ] here is always false because of the log4j entries. In my example below, it's 345 even when it's empty.
solr@dev-solrcloud-0:/tmp$ ZK_SECURITY_JSON=$(/opt/solr/server/scripts/cloud-scripts/zkcli.sh -zkhost dev-solrcloud-zookeeper-0.dev-solrcloud-zookeeper-headless.solr.svc.cluster.local:2181,dev-solrcloud-zookeeper-1.dev-solrcloud-zookeeper-headless.solr.svc.cluster.local:2181,dev-solrcloud-zookeeper-2.dev-solrcloud-zookeeper-headless.solr.svc.cluster.local:2181/ -cmd get /security.json); echo "${ZK_SECURITY_JSON}"
2022-12-13 17:02:20.232 INFO  (main) [   ] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
2022-12-13 17:02:20.331 INFO  (zkConnectionManagerCallback-2-thread-1) [   ] o.a.s.c.c.ConnectionManager zkClient has connected
2022-12-13 17:02:20.331 INFO  (main) [   ] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
{}
solr@dev-solrcloud-0:/tmp$ ZK_SECURITY_JSON=$(/opt/solr/server/scripts/cloud-scripts/zkcli.sh -zkhost dev-solrcloud-zookeeper-0.dev-solrcloud-zookeeper-headless.solr.svc.cluster.local:2181,dev-solrcloud-zookeeper-1.dev-solrcloud-zookeeper-headless.solr.svc.cluster.local:2181,dev-solrcloud-zookeeper-2.dev-solrcloud-zookeeper-headless.solr.svc.cluster.local:2181/ -cmd get /security.json); echo "${#ZK_SECURITY_JSON}"
345

Setting custom log configuration doesn't help either because the env var and configmap volume don't get included in the init container.
configMapOptions:
  providedConfigMap: custom-solr-xml

Currently using the v0.6.0 of solr and solr-operator helm charts.

Thanks for reporting this!
So looking at the log4j file that the script uses, it should be appending to std_err, which I hope would not get put into the variable...
Can you provide the Solr image version you are using?

Hi. I believe it was 8.4.0. My colleague @yauhen-vastraknutau-epam can confirm. This is the latest version supported by the version of an app we use (https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB0227897). He worked around it by upgraded the image temporarily to v9.0 to allow zookeeper to configure correctly and then reverted to the v8 image.

Yep, we stick to Solr 8.4.0 but I found that if I deploy 9.x it did security bootstrapping and I was able to downgrade Solr to 8.4.0 after this. Tried before 8.8.1 - didn't work as well.

It looks like Sitecore supports 8.11.2, and there is a workaround for users that need that lower Solr version. I'm going to close this for now.


Initial implementation of the doc api database.

Issue #: /bcgov/entity#22275
Description of changes:

Instructions and script for creating the document service docs database.
Dev instance created in the GCP BCR Common Dev project.

Adding Patrick as an merging approver.

@doug-lovett To follow up on the brainstorming/pre-grooming we just had, would we store documentId -> documents as a one to many relationship?
Seemed like there is something there to ponder, if there isn't a consolidated pdf until the point of archiving.


Create a Tech Zone demo video for Azure quickstart implementation

Azure ARO quickstart and standard videos uploaded to Box,
https://ibm.ent.box.com/folder/157619710614


api/spi: Change transceive functions signature

Instead of NULL terminated buffer arrays, let's add a parameter for each
that tells the number of spi_buf in it.
It adds a little bit more complexity in driver's side (spi_context.h)
but not on user side (bufer one has to take care of providing the NULL
pointer at the end of the array, now he requires to give the count).
This will saves a significant amount of bytes in more complex setup than
the current dumb spi driver sample.
Signed-off-by: Tomasz Bursztyka<EMAIL_ADDRESS>

Agree, ARRAY_SIZE() is more obvious, but I still hope readers do read the API to know which parameter is supposed to be.


Added dark mode

Completed #12
Do check preview and suggest changes if any

Looks good to me. Great job 🎉


how to get the number of steps in the account?

I'm trying to display to the user how many steps they have left in their account .
any suggestion on how to get this?

@alinabel, I think this is the same issue as #23
It is not currently possible using this repository, but we are working on it.
Thanks!


Remove coded JVM heap options, rely on _JAVA_OPTIONS

Modified xml from using coded -Xms -Xmx values to relying on _JAVA_OPTIONS environment variable.
Increased version number.

Entry in tool_destinations.yaml would now look like:
mz_to_sqlite:     cores: 2     env:         _JAVA_OPTIONS: -Xms20G -Xmx20G     mem: 22

Thanks - I should RTFM!
On Wed, Jul 8, 2020 at 8:46 AM Björn Grüning<EMAIL_ADDRESS>wrote:

@bgruening commented on this pull request.
In tools/mz_to_sqlite/mz_to_sqlite.xml
https://github.com/galaxyproteomics/tools-galaxyp/pull/473#discussion_r451556208
:

@@ -1,4 +1,4 @@
-
+

We have some recommendations here:
https://galaxy-iuc-standards.readthedocs.io/en/latest/best_practices/tool_xml.html#tool-versions
The main version should reflect the underlying tool version, to make it
less confusing and improve the communication with the admin.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/galaxyproteomics/tools-galaxyp/pull/473#discussion_r451556208,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB3MESUXY6OLO4ZGM4RLXVLR2R2DBANCNFSM4OURT4XA
.

--
Thomas McGowan
Software Developer | Minnesota Supercomputer Institute | msi.umn.edu
University of Minnesota | umn.edu
<EMAIL_ADDRESS>|<PHONE_NUMBER>

Merci!


fix: removed reflect metadata

reflect metadata is not playing nice with esbuild so removing it for a while

Coverage report

St.:grey_question:
Category
Percentage
Covered / Total

🟢
Statements
100%
61/61

🟢
Branches
100%
11/11

🟢
Functions
100%
1/1

🟢
Lines
100%
61/61

Test suite run success
6 tests passing in 1 suite.
Report generated by 🧪jest coverage report action from a1bbd92bd2c18935608a7386ef14dbcaa19af234


Performance benchmark + SUT Output not shown

When using the Point file (with a quadratic problem) as input for a simulator and tester pair,
Point.txt
Note: Used txt extension since github doesn't support txs extension ;-)
I noticed that (and see screen shots)

Input to both SUT and SIM is not immediately printed.
Quiescence is observed yet fault is not immediately concluded.
This example might help to improve performance of TorXakis: Clear that evaluation is done via smt solver!

It is hard for me to see what is the problem and expected behavior. Is the problem that (in the second screenshot) the output of the simulator does not appear in the tester window?


Prepare url_launcher for the Link widget

Description

[THIS] Prepare url_launcher for the Link widget.
[COMPLETE] [web] Implement Link for web (https://github.com/flutter/plugins/pull/3155).
[COMING] Implement Link for native platforms (link TBD).
[COMING] Update url_launcher example to show usage of Links (link TBD).

The design has been discussed in:

https://flutter.dev/go/link-widget
https://flutter.dev/go/link-widget-2

Issues:

https://github.com/flutter/flutter/issues/59690
https://github.com/flutter/flutter/issues/44865
https://github.com/flutter/flutter/issues/54281

This needs to be reverted. It's causing build failures.
https://github.com/flutter/flutter/issues/68545

Closing the loop here: Mouad published the fix for the build issue. Apologies for the breakage! /cc @Mravuri96


[BUG] Realtime data error in log

Describe the bug
Two major(?) errors in log though everything seems to be working?
Account type

[x ] Installer
[ ] DIY / DHZ
[ ] Home Owner (This integration is not (fully) functional with a home owner account!)

Envoy

[x ] Metered with CTs installed

[ ] Metered without CTs

[ ] Standard

FW version: D7.6.175

Amount of micro inverters connected: 14

Home Assistant

Version: 2023.8.1

Additional context
Deze fout is ontstaan door een aangepaste integratie.

Logger: custom_components.enphase_envoy.envoy_reader
Source: custom_components/enphase_envoy/envoy_reader.py:1084
Integration: Enphase Envoy (Installer) (documentation, issues)
First occurred: 09:25:52 (5 occurrences)
Last logged: 09:36:25
----------------------------------------------------
Stopped reading realtime data
Relevant snippet of Home Assistant error log.
Deze fout is ontstaan door een aangepaste integratie.

Logger: custom_components.enphase_envoy.envoy_reader
Source: custom_components/enphase_envoy/envoy_reader.py:1061
Integration: Enphase Envoy (Installer) (documentation, issues)
First occurred: 09:25:52 (5 occurrences)
Last logged: 09:36:25

Realtime data error:
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/anyio/streams/tls.py", line 131, in _call_sslobject_method
    result = func(*args)
             ^^^^^^^^^^^
  File "/usr/local/lib/python3.11/ssl.py", line 921, in read
    v = self._sslobj.read(len)
        ^^^^^^^^^^^^^^^^^^^^^^
ssl.SSLWantReadError: The operation did not complete (read) (_ssl.c:2576)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/httpcore/_backends/anyio.py", line 34, in read
    return await self._stream.receive(max_bytes=max_bytes)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/anyio/streams/tls.py", line 196, in receive
    data = await self._call_sslobject_method(self._ssl_object.read, max_bytes)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/anyio/streams/tls.py", line 138, in _call_sslobject_method
    data = await self.transport_stream.receive()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/anyio/_backends/_asyncio.py", line 1203, in receive
    await self._protocol.read_event.wait()
  File "/usr/local/lib/python3.11/asyncio/locks.py", line 213, in wait
    await fut
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/httpcore/_exceptions.py", line 10, in map_exceptions
    yield
  File "/usr/local/lib/python3.11/site-packages/httpcore/_backends/anyio.py", line 32, in read
    with anyio.fail_after(timeout):
  File "/usr/local/lib/python3.11/site-packages/anyio/_core/_tasks.py", line 119, in __exit__
    raise TimeoutError
TimeoutError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/httpx/_transports/default.py", line 60, in map_httpcore_exceptions
    yield
  File "/usr/local/lib/python3.11/site-packages/httpx/_transports/default.py", line 239, in __aiter__
    async for part in self._httpcore_stream:
  File "/usr/local/lib/python3.11/site-packages/httpcore/_async/connection_pool.py", line 347, in __aiter__
    async for part in self._stream:
  File "/usr/local/lib/python3.11/site-packages/httpcore/_async/http11.py", line 325, in __aiter__
    raise exc
  File "/usr/local/lib/python3.11/site-packages/httpcore/_async/http11.py", line 317, in __aiter__
    async for chunk in self._connection._receive_response_body(**kwargs):
  File "/usr/local/lib/python3.11/site-packages/httpcore/_async/http11.py", line 186, in _receive_response_body
    event = await self._receive_event(timeout=timeout)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/httpcore/_async/http11.py", line 200, in _receive_event
    data = await self._network_stream.read(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/httpcore/_backends/anyio.py", line 31, in read
    with map_exceptions(exc_map):
  File "/usr/local/lib/python3.11/contextlib.py", line 155, in __exit__
    self.gen.throw(typ, value, traceback)
  File "/usr/local/lib/python3.11/site-packages/httpcore/_exceptions.py", line 14, in map_exceptions
    raise to_exc(exc) from exc
httpcore.ReadTimeout

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/config/custom_components/enphase_envoy/envoy_reader.py", line 1061, in stream_reader
    async for chunk in response.aiter_text():
  File "/usr/local/lib/python3.11/site-packages/httpx/_models.py", line 948, in aiter_text
    async for byte_content in self.aiter_bytes():
  File "/usr/local/lib/python3.11/site-packages/httpx/_models.py", line 927, in aiter_bytes
    async for raw_bytes in self.aiter_raw():
  File "/usr/local/lib/python3.11/site-packages/httpx/_models.py", line 985, in aiter_raw
    async for raw_stream_bytes in self.stream:
  File "/usr/local/lib/python3.11/site-packages/httpx/_client.py", line 146, in __aiter__
    async for chunk in self._stream:
  File "/usr/local/lib/python3.11/site-packages/httpx/_transports/default.py", line 238, in __aiter__
    with map_httpcore_exceptions():
  File "/usr/local/lib/python3.11/contextlib.py", line 155, in __exit__
    self.gen.throw(typ, value, traceback)
  File "/usr/local/lib/python3.11/site-packages/httpx/_transports/default.py", line 77, in map_httpcore_exceptions
    raise mapped_exc(message) from exc
httpx.ReadTimeout

Is your Envoy connected via Wifi or cable? This could be a bad/slow connection to the Envoy.

It is connected via cable. I noticed the slow connection, just don't understand why it is slow. The cable goes directly from the Envoy into the router, no issues with my internet connection. Can it be a faulty Envoy?

Usually a power cycle of the Envoy will fix the slow response.

I did a powercycle 2 days ago because the integration could not be installed. After the power cycle it worked perfect. So it looks like my Envoy gets slow after a few days. Did a power cycle just now and keep monitoring it. Thanks for the reply so far!

After the power cycle the integration fails to start now :(

Try to disable the realtime data in the configuration. And see if that improves things.

Duplicate of #83


[native assets] Add dynamic linking integration test for dart

We want to support dylibs being dynamically linked to other dylibs in native assets:

https://github.com/dart-lang/native/issues/190

We have a working PR for Flutter:

https://github.com/flutter/flutter/pull/153054

But it's not working in Dart standalone out of the box either.

Using the same builder hook setup as with Flutter but with standalone Dart, the linked library can never be found. I've tested dart run, dart test and dart build, always with the same result. I'm going to work on https://github.com/dart-lang/native/issues/1419, but I would prefer landing this PR first and coming back later to update the tests.
@dcharkes If you have any idea what differences between embedders could cause loading the linked library to fail with standalone Dart, that would be very helpful for https://github.com/dart-lang/native/issues/1419.

Originally posted by @blaugold in https://github.com/flutter/flutter/pull/153054#pullrequestreview-2233514300
We should add a similar integration test as in the Flutter PR with dylibs being dynamically linked to each other in pkg/dartdev/test/native_assets/build_test.dart and friends. (We could have the integration test project itself live on dart-lang/native instead of checking it in to the Dart SDK like we do with many other tests in pkg/dartdev/test/native_assets/.)

@dcharkes If you have any idea what differences between embedders could cause loading the linked library to fail with standalone Dart, that would be very helpful for https://github.com/dart-lang/native/issues/1419.

A Flutter app has it's include path / rpath set. A Dart .exe from dart build exe might not have that set yet. (Users using FFI have simply been using dlopen calls with full paths until now. And that's what native assets use under the hood as well currently.)
When doing dart run and dart test the executable is dart.exe in the Dart SDK. So that also doesn't have an include path / rpath. Maybe we can somehow provide that as an environment variable? Or maybe ensuring we run from the right working directory might help. This one might be slightly more tricky to get right than for dart build exe.


Script doesn't work in generator-webapp.

Hello. When I'm trying to use gumshoe in scaffold generator-webapp it doesn't work.
Uncaught TypeError: Cannot read property 'window' of undefined
Uncaught ReferenceError: gumshoe is not defined
When I load script from CDN everything works fine. And everything works when I doesn't use generator-webapp, just static files.
What can cause that error?
 In several cases I reference window, but with the UMD wrapper (which allows the script to work in things like Webpack), it should be root. I'll push a fix later today. Sorry about that!

I must use BOWER, and vendor.js in that scaffold!
Now everything works fine.

Oh all good. You helped me find a bug I didn't know existed. Thanks!
https://github.com/cferdinandi/gumshoe/pull/55


Scaffolding RBAC when go and helm apis are specified in the project

Problem:
When using create api command with both helm and go plugin, the roles.yaml in config/ directory is rewritten. However, the other rbac manifests which specify the permissions to view and edit the custom object is present. This requires an additional step of modifying the rbac manually and applying it to the cluster.
Possible solution:
Scaffold roles for each APIs in separate files and apply them in the cluster.

We can have roles.yaml for go api, and have a separate Kustomize file that has rbac for helm api.


Implement memory writing on Linux

ridiculous diff counts because of reports

Coverage decreased (-3.6%) to 81.0% when pulling b9bfa874d3ab663b23083b05441d13f355477bca on memwrite-linux into 7278c5b792c9c475bc969690b1eccf8bac6ce999 on master.


Slow image loading

I transfered a folder with many images from my pc to the internal storage of my device.

Aves spend a few minutes loading the images.

They do not appear at all for several minutes, or they appear but cataloguing/locating takes several minutes?
They should appear soon after the Media Store detects them. Otherwise it's a bug.

Cataloguing/locating takes several minutes.

Ah then, it's normal. Well, "locating" especially because it's reverse-geolocating all the pictures that have coordinates. Usually that involves a Google Play service and online communication. The app is usable even without this step, but you don't get to search by "country" and "place".
Given that Simple gallery pro basically just lists the Media Store content without extra effort to detect file properties and mitigate the Media Store limitations, the comparison does not make sense.
That said, some people are confused by the fact that this background analysis done by Aves is shown in the app bar. They think leaving the app will break or discard the analysis, etc. I will change the way it's presented to look like a service decoupled from the app itself. I'll also make the "locating" pass optional.

Forgot to add: I think the "locating" stopped every time I closed the app, which means it has to start over again several times. This resulted in making it feel even longer.


Update - Code Improvement

Code Improvement

Redesigning project directory and file names ✔
Code Improvement ✔
Executable scripts and notebooks ❓
Update README ❓


Why are we manually manipulating the DOM instead of using bindings?

Here, for instance: https://github.com/angular/angular.io/blob/master/public/resources/js/site.js#L75-L117
This code is really hard to understand. Taking better advantage of Angular's data binding would help a lot, and would let us easily drop the jQuery dependency.

My new branch gets rid of all of this.
On Mon, May 4, 2015 at 4:24 PM, Brian Ford<EMAIL_ADDRESS>wrote:

Here, for instance:
https://github.com/angular/angular.io/blob/master/public/resources/js/site.js#L75-L117
This code is really hard to understand. Taking better advantage of
Angular's data binding would help a lot, and would let us easily drop the
jQuery dependency.
—
Reply to this email directly or view it on GitHub
https://github.com/angular/angular.io/issues/87.

I'm closing this for now, the branch I shared should get rid of everything and remove all jquery dependancies. I'll tag you on the review for that branch.