View breaks when shadowOffset property is passed to the animate property

Description
When I'm trying to add the shadowOffset style property value to the animate property in MotiView, the view doesn't render anymore. I'm assuming it could be because shadowOffset has an object-based value and that is breaking something under the hood.
Steps to Reproduce
Code
<MotiView
  from={{ opacity: 0 }}
  animate={{
    opacity: 1,
    shadowColor: "#1A2138",
    shadowOffset: {
      width: 0,
      height: 8,
    },
    shadowOpacity: 0.5,
    shadowRadius: 20,
  }}
  style={{
    width: 200,
    height: 400,
    backgroundColor: "aqua",
  }}
/>

Screenshot

Expected Behaviour
Ideally, the shadow should appear as below (when applied to the regular style property).
Code
<MotiView
  from={{ opacity: 0 }}
  animate={{
    opacity: 1,
  }}
  style={{
    width: 200,
    height: 400,
    backgroundColor: "aqua",
    shadowColor: "#1A2138",
    shadowOffset: {
      width: 40,
      height: 40,
    },
    shadowOpacity: 0.5,
    shadowRadius: 20,
  }}
/>

Screenshot

does reanimated support animating this property?

It seems like reanimated doesn't support the shadowOffset property by default (supported props list), but it can be supported by explicitly whitelisting it (Check out this issue on reanimated)
Something like the following:
import Animated from 'react-native-reanimated';
Animated.addWhitelistedUIProps({shadowOffset:true});

const X = () => {
  return <Animated.View
    style={[
      {
        shadowOffset: {
          height: 2
          width: 0,
        },
      },
    ]}
  />
}

does that fix it for moti?

Ahh my bad, apparently the issue I mentioned before is from Reanimated V1. shadowOffset seems to be supported by default in Reanimated V2.
The issue, I think, is occurring when shadowOffset is being used with the animation hooks (withTiming, withSpring, etc). This is because these hooks expect number | string values only, while shadowOffset is an object (reference in Reanimated docs).
Following are a couple of examples of what I'm talking about:
Working Example 1 (without Animation hooks)

Code
import Animated, {
  useAnimatedStyle,
  withTiming,
} from "react-native-reanimated";
import { View } from "react-native";

const App = () => {
  const [shadowFlag, setShadowFlag] = useState(false);

  const AnimatedView = Animated.createAnimatedComponent(View);

  const animatedStyles = useAnimatedStyle(() => {
    return {
      shadowOpacity: withTiming(shadowFlag ? 1 : 0.5, { duration: 200 }),
      shadowOffset: disabled
        ? {
            width: 50,
            height: 50,
          }
        : {
            width: 10,
            height: 10,
          },
    };
  });

  return (
     <>
        <AnimatedView
          style={[
            {
              width: 200,
              height: 200,
              backgroundColor: "aqua",
              shadowColor: "#1A2138",
              shadowRadius: 20,
            },
            animatedStyles,
          ]}
        />

        <Button
          from={{ opacity: 0 }}
          animate={{ opacity: 1 }}
          mt="xl"
          isFullWidth
          transition={{ type: "timing" }}
          onPress={() => setShadowFlag(!shadowFlag)}
        >
          Toggle Shadow
        </Button>
      <>
  );
};

Working Example 2 (with Animation hooks)
When I apply withTiming to the individual properties of shadowOffset, the animation works as expected.

Code
import Animated, {
  useAnimatedStyle,
  withTiming,
} from "react-native-reanimated";
import { View } from "react-native";

const App = () => {
  const [shadowFlag, setShadowFlag] = useState(false);

  const AnimatedView = Animated.createAnimatedComponent(View);

  const animatedStyles = useAnimatedStyle(() => {
    return {
      shadowOpacity: withTiming(shadowFlag ? 1 : 0.5, { duration: 200 }),
      shadowOffset: {
        width: withTiming(shadowFlag ? 50 : 10, { duration: 200 }),
        height: withTiming(shadowFlag ? 50 : 10, { duration: 200 }),
      },
    };
  });

  return (
     <>
        <AnimatedView
          style={[
            {
              width: 200,
              height: 200,
              backgroundColor: "aqua",
              shadowColor: "#1A2138",
              shadowRadius: 20,
            },
            animatedStyles,
          ]}
        />

        <Button
          from={{ opacity: 0 }}
          animate={{ opacity: 1 }}
          mt="xl"
          isFullWidth
          transition={{ type: "timing" }}
          onPress={() => setShadowFlag(!shadowFlag)}
        >
          Toggle Shadow
        </Button>
      <>
  );
};

Example with issues
I get several type errors when I wrap the withTiming hook around the shadowOffset object.

Code
import Animated, {
  useAnimatedStyle,
  withTiming,
} from "react-native-reanimated";
import { View } from "react-native";

const App = () => {
  const [shadowFlag, setShadowFlag] = useState(false);

  const AnimatedView = Animated.createAnimatedComponent(View);

  const animatedStyles = useAnimatedStyle(() => {
    return {
      shadowOpacity: withTiming(shadowFlag ? 1 : 0.5, { duration: 200 }),
      shadowOffset: withTiming(
        disabled
          ? {
              width: 50,
              height: 50,
            }
          : {
              width: 10,
              height: 10,
            },
        {
          duration: 500,
        }
      ),
    };
  });

  return (
     <>
        <AnimatedView
          style={[
            {
              width: 200,
              height: 200,
              backgroundColor: "aqua",
              shadowColor: "#1A2138",
              shadowRadius: 20,
            },
            animatedStyles,
          ]}
        />

        <Button
          from={{ opacity: 0 }}
          animate={{ opacity: 1 }}
          mt="xl"
          isFullWidth
          transition={{ type: "timing" }}
          onPress={() => setShadowFlag(!shadowFlag)}
        >
          Toggle Shadow
        </Button>
      <>
  );
};

Yeah that seems like a fair feature to add if reanimated supports it

I oddly thought I was doing a check for objects inside that function, but I never tested shadows much. I'd review a PR

Awesome, I'll open a PR for this. I'm guessing all the code related to this issue lives inside the use-map-animate-to-style.tsx file.
Could you point me towards a particular part of the flow where this fix should occur? (This particular file is quite hard to decipher)

yeah let me see. i know it can be a bit tough, there's some magic going on in there haha

line 531 is what you want. that basically says, if the value for a given style is an object, then go through and apply final[key] = animation(value), where animation is withTiming/withSpring

Awesome! I'll check that part out. Thanks! 😇

feel free to reference the perf branch if you want to work on this still. going to close for now though.


Fix TextBox arrow key movement.

Cursor couldn't be moved to after last char with right arrow key. Fixes #716.

Ok Iv checked code, and unit tests are there. Also gave a quick check on my PC and looks good. So will merge.


git token is not controlled through gitops

We should use some secret management solution to encrypt it, and commit it along with the rest of the bootstrap

a solution that included a vault integration would be exceptional

I just came to know about Autopilot but I would like to pitch in how we are using ArgoCD in our landscape. We use https://github.com/external-secrets/kubernetes-external-secrets to handle secret management. This means that our secrets are not stored on Git, not even encrypted. Instead they are stored on cloud and it is up to the user how to access manage that.

Another option could be the Secrets Store CSI driver -- https://github.com/kubernetes-sigs/secrets-store-csi-driver -- it has plugins for Vault, and various cloud provider's secret stores (AWS, GCP, Azure).

Why does the  git token, used by autopilot, need to be stored in the gitops repository?
Personally, I would consider the git token to be a discrete service (automation) credential for use by auto-pilot only. ArgoCD doesn't need it, it has it's own mechanism for managing repository credentials.

Not sure what you mean by handling it gitops... it's up to where the pilot CLI runs to provide the secret...  could be on the operator machine (read from env, from stacic config file if the security posture deems that's ok for them). In CI - probably would be provided via project environment variables exposed to CI runners...
If you provide more than one mechanism for how the CLI can consume the credential/config I understand.
I store it in gopass and spawn a temporary argocd-autopilot shell with the credentials included.
§ gopass show apps/argocd-autopilot
apps/argocd-autopilot/
├── git_repo
└── git_token

Makefile:
argocd/pilot/shell:
	gopass env apps/argocd-autopilot zsh


Second backtracking example is comprehensivly wrong?

The second example in the Backtracking section of the Regex page appears to be entirely wrong. I'm referring to the example that starts:

It is worth noting that disabling backtracking will not prevent the engine to try several ways to match the regular expression.

This example provides code that, according to the text, will result in only two iterations (without :ratchet).  Running that code, however, results in 30 iterations.  Additionally, the text incorrectly describes how the match proceeds by saying that it "will match against the rightmost word SQL and go forward from there" – which it won't.  I cannot tell what the example is trying to communicate.  It appears to be ~6 years old; maybe it was documenting old/buggy behavior?  I am inclined to favor deleting this second example entirely rather than trying to salvage it.
However, since it's fairly long and well-written, I thought I'd check if anyone else knows what it's trying to do and/or how to get it to do so.

I can't speak for the rest of the example (yet), but the author misreads the result of the second example entirely and perhaps that confuses the entire answer.
The reason the example cited fails to match is not because there's not a second "SQL" to be matched, but rather because the first SQL that got matched is now in $0 instead of $1.   The author went from these prior examples:
my $string = 'PostgreSQL is an SQL database!';
say $string ~~ /(.+)(SQL) (.+) $1/;      # OUTPUT: «｢PostgreSQL is an SQL｣␤»
say $string ~~ / :r (.+)(SQL) (.+) $1/;  # OUTPUT: «Nil␤»

to this one
my $string = 'PostgreSQL is an SQL database!';
say $string ~~ / (SQL) (.+) $1 /; # OUTPUT: «Nil␤»

and assumes that the failed match in the last one is because of backtracking, or that the first capture grabbed the second SQL, and other incorrect reasoning.
The reason the match fails in this last example is because the (SQL) capture now appears in $0 instead of $1 as it did in the previous examples.  If you correct the backreference everything works as expected, including backtracking:
[0] > my $string = 'PostgreSQL is an SQL database!';
PostgreSQL is an SQL database!
[1] > say $string ~~ / (SQL) (.+) $0 /;
｢SQL is an SQL｣
 0 => ｢SQL｣
 1 => ｢ is an ｣
[1] >

Because of that fundamental misunderstanding, that the $1 in these later examples is now attempting to match the contents of (.+) instead of (SQL), the analysis and interpretation given just doesn't make any sense.
I agree this example needs to be revisited, and likely just removed, because it's just not an accurate description of what's happening in the regex match.  The results have little to do with backtracking ratcheting, and more to do with a pattern that couldn't possibly match with the given input.
Pm

I can now speak for more of the example.  My observation that the later examples use $1 where a match against (SQL) (in $0) was intended remains true, but I now see where the analysis given is incorrect.
For the code that appears after "It is worth noting that disabling backtracking...", it appears that the author is trying to set up an example where :r doesn't prevent backtracking.  The first part is to show results for a regex that doesn't have :r and try to explain it, but the explanation is wrong and that sets an incorrect stage for what follows.
For the code
my $string = 'PostgreSQL is an SQL database!';
say $string ~~ / (SQL) (.+) $1 /; # OUTPUT: «Nil␤»

the author attributes the the match to "there's no specification for a character before the word SQL", but it's actually the $1 that is controlling things here.  The match proceeds by finding and capturing the SQL of "PostgreSQL" into $0, then captures the remainder of the string (" is an SQL database!") into $1.  When the author writes "Since there is no repetition of SQL remaining", they are misinterpeting the result.  The $1 is going to attempt to match the (.+) capture that is in $1, not the (SQL) capture that is in $0.
Since there's no remaining string left to match, the attempt to match $1 (" is an SQL database!") fails and the $1 backtracks one character to try again.  This keeps happening without any match (the string isn't duplicated anywhere), so ultimately the (.+) capture fails and the regex backtracks to where the first SQL was captured in $0.
Unanchored regexes using the slash delimiters have an implicit .*? at the beginning.  When the match fails with the $0 set to the first SQL (in "PostgreSQL"), the implicit .*? backtracks until it has consumed all of the characters up to the second instance of SQL in the string.  The author claims the regex gets there because of "no specification for a character before the SQL", but that's misleading.  It's really that the first SQL failed to complete a match and so now we've backtracked to the second one. Once this second (standalone) instance of SQL is placed in $0, the regex again matches the remainder of the string (" database!") into $1 and attempts to find a second copy to match against.  This fails again, backtracking the $1 capture one character at a time down to nothing, at which point it fails this iteration of the regex.  The unanchored search at the beginning of the string against scans for another SQL and not finding one fails the match.
I don't know how the author got the claimed output when show-captures is used.  It should have shown repeated iterations with the $1 capture getting progressively smaller until the match backtracks on SQL and then ultimately fails.  This is what OP claims happened for them, and when I try it I also get 30 iterations, exactly as OP claims.  I think the author of this section must have had some other error somewhere that caused them to get the output they wrote in the documentation.
Now, having set up this example (and incorrectly interpreted how the machine processed it), the author then tries the same example adding a :r modifier, sees the same output, and claims that it shows that backtracking still occurs.  There is indeed some backtracking going on, but the result is in fact very different and not at all what the author concludes.
With the :r modifier added the regex becomes
my $string = 'PostgreSQL is an SQL database!';
say $string ~~ / :r (SQL) (.+) $1 /; # OUTPUT: «Nil␤»

If we run this code we get two iterations instead of 30, just one for each time that (SQL) is matched in the string.  Note that this shows that backtracking indeed does modify the backtracking, because instead of 30 iterations we now have 2.  The (.+) capture no longer tries all possibilities -- it grabs as many characters as it can and sends it on to the next component to match, with no backtracking.
But, I hear people saying "if it immediately fails and :r prevents backtracking, why are there two iterations?  Shouldn't there be just one?"
Remember that implicit .*? at the beginning of an unanchored regex match?  The :r flag doesn't apply to that implicit search -- it still backtracks.  So, after the match with $0 matching the first SQL fails, it backtracks until $0 matches the second SQL in the string.  When that try fails (with no backtracking), there are no more SQLs left and the overall match fails.
So, the :r to prevent backtracking is in fact changing things, but the author didn't see it.  The failed match without :r results in 30 invocations of show-captures, while the one with :r results in 2.  Yes, there's some backtracking that takes place with :r in the regex... in this case it's the implicit .*? of the regex that backtracks as it isn't affected by the :r flag.
Beyond that, the :ratchet modifier doesn't actually mean "no backtracking anywhere" -- it just means that quantifiers and alternatives will work until the first time they succeed, at which point they discard any remaining alternatives to try.  The :ratchet just acts as if a : is placed after any quantifier, alternative, or subrule that doesn't have its own modifier to force backtracking.
If you want to fail an unanchored regex on the first time it matches SQL and not backtrack to try additional instances, I believe the way to do that is by using <!> in an alternative to fail a match altogether.  I'm rusty on my regex notation, and I can't find <!> in the docs, so hopefully someone can confirm or correct this.
At any rate, if the point of the latter part of that section is to point out that unanchored regexes will still backtrack on the initial string position when searching for a match... it's probably easier to just say that directly and not try to demonstrate it with an example.  (Much less an incorrectly presented and interpreted one.)
Hope this helps,
Pm

I was incorrect about <!> failing a match altogether, all it does is cause the current regex match path to fail (forcing the engine to start any available backtracking).
The syntax I'm remembering is the triple-colon :::, which appears in roast but all of the tests seem to be marked "skip" as NYI. for rakudo.  With the colon, a regex would be able to fail with something like
$string ~~ / (SQL) ::: (.*) $0 /

which means that once the regex matches SQL, you complete a match or fail without trying a later instance of SQL in the string.  Again, roast suggests this is NYI in rakudo, and attempting to use it in a regex also gives a  NYI error message.
Pm


webapp install and start without error but when I open the address with error

I solved the problem to change  file 'babel.config.js' .
original:
  ignore: [
    /[\\\/]core-js/,
    /webpack[\\\/]buildin/
  ],

change to:
  ignore: [
    /\bcore-js\b/,
    /webpack[\\\/]buildin/
  ],

my development environment is windows7


Listing doesn't display label or namespace characters wrapped in angle brackets

Describe the bug
In the Listing window, if a label or namespace contains more than 10 characters wrapped in angle brackets, the content of the angle brackets is not shown (as if it didn't exist).
For example, <12345678901>::<12345678901> will display as simply <>::<>.
This seems to only happen if more than ten characters are inside the angle brackets, and doesn't affect characters outside the angle brackets. Screenshots are all performed using numeric names but the characters inside the angle brackets seem irrelevant (happens if all characters are letters).
I have tested other types of brackets ((), {} and []) and this behavior is only exhibited with angle brackets.
To Reproduce
Steps to reproduce the behavior:

Import any program (tested on ELFs loaded with custom loader, and standard PE]
Create a label containing more than 10 characters in angle brackets, such as <12345678901>
See that the label is displayed as <>

Expected behavior
The label displays as <12345678901>
Screenshots
With 10 or less characters in the angle brackets, everything functions properly.

Adding a character to the name (11 in total) makes the angle brackets' content disappear in the listing.

Identical behavior with the namespace (the Symbol Tree is not affected)

Identical behavior when both are combined.

A more convoluted example, showing that characters outside angle brackets aren't affected.

Matching pairs of angle brackets are also not displayed (i.e. the outermost pair's content is hidden)

Extreme case of this idea.

When mismatching pairs are present, the mismatching characters are treated as any other and displayed properly.

Environment:

OS: Windows 10 Pro 22H2 build 19045.2965
Java Version: 17.0.7
Ghidra Version: 10.3
Ghidra Origin: official GitHub distro

This is intended behaviour - see 8bb02c4. It seems this can be disabled in Edit -> Tool Options -> Listing Fields -> Template Display options.


Add grafana chart

Adding grafana to the helm package too. Some dashboards inspired by our internal ones
Towards giantswarm/giantswarm#4534

Can't review it really. Can you post a screenshot of the dashboard in action?

Ups I have just realized I moved all in a chart folder for convention and it meant a lot of changes.
I added here some dashboards

Merging here, feel free to drop a comment if you something wrong


Added one main index file

Added one main file which connects all the applications from one single file.
This can be helpful in deployment.
And also Styled with css.

Added an application of todo-list @gantavyamalviya.
Pls tell why you marked this pr as invalid?


update license deps

This one should be correct :-)

Changes seem unproblematic, let's wait for CI to be green.


Security: Update Apple B2C Certificate

Update Apple B2C Certificate

Updated 2023-08-20. Fingers crossed.


Where is the file /fsdet/data/

As the title, I can't find the file /fsdet/data... I hope you can update it, thanks.

Done.
Close the issue if your problem is solved, thx.

thank you very much
------------------ 原始邮件 ------------------
发件人:                                                                                "MegviiDetection/FSCE"                                                                                @.>;
发送时间: 2021年3月19日(星期五) 下午5:52
@.>;
<EMAIL_ADDRESS>主题: Re: [MegviiDetection/FSCE] Where is the file /fsdet/data/ (#2)
Done.
Close the issue if your problem is solved, thx.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Done.
Close the issue if your problem is solved, thx.

this version still don't contain fsdet/data, can I use the fsdet/data folder from  FsDet https://github.com/ucbdrive/few-shot-object-detection?

Sorry for the inconvenience. The problem will be fixed shortly today.
And if you want, you can use fsdet/data folder from FsDet, but you might need to debug some import errors.

@chengyu0910  We have already uploaded the missing file.


CORS error

Even though I'm using CORS: true, I'm having a CORS error.
html2canvas(document.getElementById("page-preview"), {useCORS: true, allowTaint: true}).then(canvas => {
var imgData = canvas.toDataURL('image/png');
console.log('Report Image URL: '+ imgData);
var doc = new jsPDF({
orientation: layout,
unit: 'mm',
format: [pdf_width, pdf_height]
})
    doc.addImage(imgData, 'PNG', 0, 0);
    window.open(doc.output('bloburl'));
    window.postMessage({key: "hr:printPdfGenerated"});
});

Could you help me? @MrRio

All resources (e.g. image URLs) inside your HTML need to be accessible from JavaScript under CORS policies. It's the browser that's blocking these requests. Setting useCORS: true will not "magically" circumvent the browser restrictions.


mark initializers

This introduces a concept of a mark “initializer” which is allowed to redefine the mark’s (possibly faceted) index and channels, and by extension, the plot’s scales. The mark’s initialize option is a function that is passed the facets and channels returned previously by mark.initialize, and returns an object which may specify new facets and channels. This PR includes an example of implementing hexbins as an initializer. This is a refinement of the previous design of “layouts” #648 #711 #713 #740 #775; I wanted to move away from the term “layout” since it implies position whilst initializers are more generic. But I am open to going back to “layout” or other alternatives.
Building on #799, this also makes a few improvements to internal APIs:

mark.initialize now returns a {facets, channels} object rather than {index, channels} (like transforms).
channels are now represented as an object e.g. {x: {value}} rather than an array ["x", {value}].

While it is possible to call mark.initialize externally and hence this could be considered a backwards-incompatible change, this method is undocumented so I think it is acceptable to make this change. Also, it is now more convenient for debugging.
TODO:

[x] Throw an error if initializers define new positional (x and y) scaled channels? Not going to worry about it.
[x] When initializers return new scaled channels, merge with existing scaled channels when reconstructing scales.
[x] Add hexagon symbol.
[x] Decide on the definition of radius for hexagons.
[x] Add hexgrid decoration mark.
[x] Add circle and hexagon dot shorthand.
[x] Implement the hexbin transform as an initializer (including support for faceting).
[x] Implement the filter option for the hexbin transform (to show empty hexbins)? Not now.
[ ] Implement implicit group by z in the hexbin transform? #810
[ ] Implement sorting of hexbins? #810
[ ] Is radius the right name of the option that controls hexbin size? binWidth? #810
[ ] Inline and optimize the implementation of d3-hexbin #810
[ ] Implement the dodge transform as an initializer. #809
[ ] Add documentation. #819
[ ] Add tests. #810
[ ] Allow composition/chaining of initializers? #818

#795 for the radius of hexagons

#804 tries to implement hexbin as an options transform (adding an initializer)

I have a question re: "inline and optimize binning"; is the idea to salvage the code in the previous PR, or to optimize d3-hexbin?https://github.com/observablehq/plot/blob/352d08670b8dfda49f60f5595d079a7b9808399c/src/layouts/hexbin.js#L14
Still on the todo-list

"filter: null" (not actually a filter, it means we'll have to actively enumerate the centers)
z

Ready:

#808
#809

Browsed a base of synonyms, here are a few words that could replace layout:
design, layout, encoding/encode, variation/variant, derivation, profile, blueprint, organization, plan, outline, formation, pattern, construction, structure, disposition, makeup, skeleton, anatomy, architecture, stencil, markings, mold, cast, stamp, arrangement/arrange.
In bold a few of the ones that could "work".

For the hexbin radius, another name could be the step (ie distance between neighboring hex centers); however in that case it should be sqrt(3) times the current radius. But it might be easier to explain!

For composition of initializers, see #818

I've added refs to several pull-requests in the original description.

I'm very excited about initializers – they open up a really large design space for marks.
With Fil's help I've been experimenting with porting my density plot library to Plot (current iteration here), which requires the use of initializers since, like Fil's heatmap mark, the color scale depends upon the bin values.

The scatterplots work great (including faceting, which is really useful!), but I've noticed there is a fairly steep performance penalty (~10x slowdown for 1M points) to the Plot mark implementation versus the original.
I haven't investigated very deeply yet but it seems that a substantial part of the performance gap has to do with the fact that Plot materializes the array of bin colors and that these are represented as strings. I did some basic caching to avoid unneeded d3.rgb calls, but more could be done if the mark was allowed to be fully in contol of invoking the color scale.
Outside of Plot, it would be possible to only require three intermediate representations to build a density scatterplot: 1. The original data array, 2. The dense bin counts array, and 3. The dense canvas image data array (a Uint8ClampedArray of length 4 times the number of bins).
I'm not familiar with Plot internals so don't have any specific suggestions, but hope that the density plot might serve as a useful example of what's possible with initializers and where perf concerns might start to creep in.
Note on measurement: My performance analysis was based on scrubbing the slider back and forth in the density mark notebook and comparing timings to the original density scatterplot notebook. The original design could also be optimized further, but I tried to apply some basic performance-oriented design techniques when working on it.

I haven't investigated very deeply yet but it seems that a substantial part of the performance gap has to do with the fact that Plot materializes the array of bin colors and that these are represented as strings. I did some basic caching to avoid unneeded d3.rgb calls, but more could be done if the mark was allowed to be fully in contol of invoking the color scale.

Would it be possible to add some caching to d3-scale (or on top of d3-scale) to make this faster? Or maybe we could make quantize color scales extra fast?

Good question, but I don't have an answer right now since I did some very cursory investigation only. In fact, I was curious and dialed down the numberof bins, which reduces the size of the derived data to a 10×10 array of bins.
Here's the profile for plotting 2 million points in 100 buckets, which takes 1.35 seconds:

The bottommost orange bars are GCs:

I haven't been able to get clicking on source line numbers to work in the Chrome dev tools so I'm not sure what code path this is using (neither importing Plot from the heatmap notebook nor attaching the file and requiring it works), but here are some definitions I think are involved:
function coerceArray(array, coerce, type = Array) {
  if (array !== undefined) return type.from(array, coerce);
}

presumably called from the big switch statement in Scale for the linear scale, though I'm not sure what the allocations are:
options = coerceType(channels, options, coerceNumber, Float64Array);

function coerceNumber(x) {
  return x == null ? NaN : +x;
}

This change significantly improves the runtime of the range call.
The other performance bottleneck right now is coerceType which is called  from Scale on (I believe) this line.

I've built this branch locally (merged with main) and the speed gains from #861 and #862 are very noticeable:
https://observablehq.com/d/53181fe069c3f6ca (from ~700ms to ~300ms).

I have extensively reviewed (and amended) this PR and plan on merging tomorrow. If anyone wishes to make any final words before I merge please speak now! :pray:

We should probably draw the axes on top? Although the grid lines should still be underneath…

draw the axes on top?

This should be a generic issue (in my view the axes should be displayed on top of areas and below lines… which is neither top nor bottom). Also you should be able to use clip: true in this example?

I’ve reverted the default sort by descending r for the hexbin transform because it feels like it should be handled more appropriately at the dot mark level, or possibly at the generic mark level. And in a sense it is already by the basic sort transform, but that isn’t supported after an initializer, and maybe we want to have default sorting for dots, too.


DllNotFoundException: sqlite3 on Android 6.0 (but on 5.x works ok)

Apparently on Nexus 5 Android 6.0 it gives an error of DllNotFoundException: sqlite3, but on other androids it works ok. Any known fixes for this ?

Nope. I didn't have the chance to test it on Android 6.0. You mean the same apk works ok in different Android versions?

Yup. Same apk, on 6.0 doesn't work, on 4.x or 5.x works ok. The exact error is this:

Ok. I'll have a look at it when I have time and let you know what I find.

I've tested with the Android emulator running Android 6 and seems to be working.

Could you test the example for Android? If you provide me your email I can send you the test.apk

@andreimavenhut I've finally replicated the issue using ARM architecture. I'll let you know what I find.

@andreimavenhut I solved the issue. Download the latest plugin folder and it should be working now.
I've tested both with ARM and x86 architecture and seem to be working ok.
Let me know if it's not working for you.
Best regards,
Roberto.

I just tested on a real device. It's fixed. Thanks :+1:

Cool! :+1:


Plot average TS over time

Hi, I would like to see a graph showing me the average request_time during the different hours of the day.
For example: my website had 2 seconds average request time on Monday at 9am, but then performance worsened at 4pm. How do I see this graph? As far as I understand, the "Time Distribution" graph only shows the number of hits and visitors over time, but not the avg request time.

Honestly, I'm surprised that there is no such functionality in here. This would be really, really useful.


Add pep8 checking to Travis

To prevent pep8 problems from being missed in PRs.
This ignores the line-length check (code E501).

@adampbeardsley @dannyjacobs @jpober I'm of two minds about whether to push for this PR to be merged or not. Partly I wanted to figure out if I could do it and I had just spent some time cleaning up some stuff that had been merged in previous PRs. What do you all think?

I don't have a strong opinion.  We've decided the code should be pep8 compliant, but maybe it shouldn't come at the expense of an increased bar for participation in the project.  That said, it's not that onerous to get right either.

But how does it actually work? Does the Travis build just fail if all lights are not green? Or is there a service like Coveralls that tracks our pep8-edness?

Travis fails on any pep8 miss, but if you look at the Travis log it lists all the problematic line numbers. The fact that this PR is passing Travis means we don't have any problems currently.

I can also go either way. Definitely useful, and maybe we need a little extra push to get people to stay compliant. Typically @bhazelton is the hero that goes through and fixes things, so if this makes her life easier, I think we should implement it.

Ok, I'm going to merge it. If we find it annoying we can always take it out.


Please upload Requirement file

Hello Thanks for making this open  . Could you please upload requirement file with this . I have tried to run this but getting errors , potentialy due to mismathced versions of the libraries I am using . It will help if you could please upload the requirements file .
Thanks

I'm really busy these days. I'll finish it this week asap. Thanks

What are the versions of gym library and tianshou library
thanks


1.5 Support join hint

Subtask of https://github.com/opensearch-project/sql/issues/2913

Duplicates https://github.com/opensearch-project/sql/issues/2924


why not using port mapping

hi, i wonder why the openpai not using docker port mapping cmd to prevent port collition ,or deppend on k8s to do multi user isolation, i am not understand how to write port range or what that exactly mean in webportal

thanks scarlett2018 and fanyangCS,  i mean if not using port mapping then why should user input port range because node manager can  auto detect which ports be used by user's docker on host network

port mapping or k8s virtual network might slow down the network performance. Distributed jobs require the access to host network to achieve high performance training, thus openpai enables the use of host network by default, which may lead to port conflicts (e.g., ssh).
If you have multiple NICs, it is possible to enable k8s virtual network or docker port mapping for network traffic that does not require high performance.

thanks fanyangCS,  I finally have a very reasonable answer from you to tell our users that port conflicts is very small uneasy  compared with high performance, In fact in our china telecom the most difficult to choose docker cloud platform production is the low performance of virtual switch network plugin , and  every node be gateway surely process more network flow  than one  network gatway .
But i still do not understand how to write port range in webportal, i know maybe this is a hadoop problem and i should read your code in framworklaucher, but  i will be very glad if u give our your advise.
and we will deploy openpai on 30 nvidia p40 from our experience of using openpai stable for 3 months.
thanks! openpai is bravio

Here's the config spec, e.g.,
If you want to use port 3000 and 3001, you can write
{
    "label": "port_alias",
    "beginAt": 3000,
    "portNumber": 2
}

then the system will allocate those two ports to you if they are not in use, otherwise the job will fail.
If you do not care about the port number, just want 2 ports, you can change the beginAt field to "beginAt": 0, the allocated ports can be get in environment variable PAI_PORT_LIST_$taskRole_$taskIndex_$portLabel.

thank u abuccts  very much, indeed the best way is user's code in docker to  use  PAI_PORT_LIST_$taskRole_$taskIndex_$portLabel  this environment variable to indicate what port number
can listen to to  avoid port conflict in that node,
and if not using such way, users want to directly indicate their specific ports ,this could cause job fail after they submit job, and ,i think it could be a better solution to tell user th!eir port have been used when they input port range in webportal, ou,i am wrong,the system can schedule port on free port node.
i think i have understand your system design. and frankly speeking, why user need to listen specific port if they just want to train their models and not for modal serving .
thanks abuccts thanks !

For distributed training, each container needs ports to communicate through Ethernet or InfiniBand.
Here is an example.

thanks abuccts very very much, your link is the best senario of understanding port  variables to coordinate distributed traing ,thank u very very much !


Add Cert_5_3_10_AddressQuery.py to XFAIL list.

Expect failure introduced with #641.

Current coverage is 64.21% (diff: 100%)

Merging #650 into master will decrease coverage by 1.54%

@@             master       #650   diff @@
==========================================
  Files            95         98      +3
  Lines         12851      14329   +1478
  Methods        1789       1968    +179
  Messages          0          0
  Branches       1496       1684    +188
==========================================
+ Hits           8450       9201    +751
- Misses         3952       4596    +644
- Partials        449        532     +83

Powered by Codecov. Last update c063ec1...119dc95


used compiler ignored from compile_commands.json?

I use g++ for building because clang still miss features of C++23 that I want to use (especially the u8"" string literals that are ackward in C++20 but fixed in C++23, but my installed clang don't provide <filesystem>  header and then clangd generate lot of errors )
my concern is that in compile_commands.json  g++ is clearly specified, so clangd should use gcc's headers but seems to use clang's header and library
$ cat ../compile_commands.json
[
{
  "directory": "SomePath/build",
  "command": "/usr/bin/g++ -DBOOST_SYSTEM_DYN_LINK -DBOOST_SYSTEM_NO_LIB -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_NO_LIB -ISomePath/3rdParties/sha256 -std=c++23 -o CMakeFiles/synctegrity.dir/main.cpp.o -c SomePath/main.cpp",
  "file": "SomePath/main.cpp"
},
{
  "directory": "SomePath/build",
  "command": "/usr/bin/g++ -DBOOST_SYSTEM_DYN_LINK -DBOOST_SYSTEM_NO_LIB -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_NO_LIB -ISomePath/3rdParties/sha256 -std=c++23 -o CMakeFiles/synctegrity.dir/Conf.cpp.o -c SomePath/Conf.cpp",
  "file": "SomePath/Conf.cpp"
},
....

CocDebug output
../main.cpp|1 col 1 error| [clang drv_invalid_value] Invalid value 'c++23' in '-std=c++23' [E]
../main.cpp|8 col 10-30 error| [clang expected_namespace_name] In included file: expected namespace name [E]
../main.cpp|19 col 23-25 error| [clang undeclared_var_use] Use of undeclared identifier 'fs' [E]
../main.cpp|32 col 18-20 error| [clang undeclared_var_use] Use of undeclared identifier 'fs' [E]
../main.cpp|38 col 13-15 error| [clang undeclared_var_use] Use of undeclared identifier 'fs' [E]
../main.cpp|43 col 18-20 error| [clang undeclared_var_use] Use of undeclared identifier 'fs' [E]
../main.cpp|51 col 5-7 error| [clang undeclared_var_use] Use of undeclared identifier 'fs' [E]
../main.cpp|71 col 9-11 error| [clang undeclared_var_use] Use of undeclared identifier 'fs' [E]
../main.cpp|73 col 13-15 error| [clang undeclared_var_use] Use of undeclared identifier 'fs' [E]
../main.cpp|1 col 1 info| [clang note_drv_use_standard] Use 'gnu++2b' for 'Working draft for ISO C++ 2023 DIS with GNU extensions' standard [I]
../main.cpp|1 col 1 info| [clang note_drv_use_standard] Use 'c++2b' for 'Working draft for ISO C++ 2023 DIS' standard [I]
../main.cpp|1 col 1 info| [clang note_drv_use_standard] Use 'gnu++20' for 'ISO C++ 2020 DIS with GNU extensions' standard [I]
../main.cpp|1 col 1 info| [clang note_drv_use_standard] Use 'c++20' for 'ISO C++ 2020 DIS' standard [I]
../main.cpp|1 col 1 info| [clang note_drv_use_standard] Use 'gnu++17' for 'ISO C++ 2017 with amendments and GNU extensions' standard [I]
../main.cpp|1 col 1 info| [clang note_drv_use_standard] Use 'c++17' for 'ISO C++ 2017 with amendments' standard [I]
../main.cpp|1 col 1 info| [clang note_drv_use_standard] Use 'gnu++14' for 'ISO C++ 2014 with amendments and GNU extensions' standard [I]
../main.cpp|1 col 1 info| [clang note_drv_use_standard] Use 'c++14' for 'ISO C++ 2014 with amendments' standard [I]
../main.cpp|1 col 1 info| [clang note_drv_use_standard] Use 'gnu++11' for 'ISO C++ 2011 with amendments and GNU extensions' standard [I]
../main.cpp|1 col 1 info| [clang note_drv_use_standard] Use 'c++11' for 'ISO C++ 2011 with amendments' standard [I]
../main.cpp|1 col 1 info| [clang note_drv_use_standard] Use 'gnu++98' or 'gnu++03' for 'ISO C++ 1998 with amendments and GNU extensions' standard [I]
../main.cpp|1 col 1 info| [clang note_drv_use_standard] Use 'c++98' or 'c++03' for 'ISO C++ 1998 with amendments' standard [I]

but as we can see in the compile_commands.json generated by cmake, there is -std=c++23 and no c++23... so I don't understand the first error.... and others errors are normal since I set in CMakeLists.txt
set(CMAKE_CXX_STANDARD 23)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF) # -std=c++11 instead of -std=gnu++11
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

second line error is generated by the following code
#include <filesystem>
namespace fs = std::filesystem;

and the reason given by clangd is
use of undeclared identifier 'std' (ccls 2)
 ─────────────────────────────────────────────────────────────
Use of undeclared identifier 'std' (clang undeclared_var_use)

ok.... clangd don't reconized std namespace????
System information
$ clangd --version
clangd version 15.0.6
Features: linux
Platform: x86_64-pc-linux-gnu
Editor/LSP plugin:
coc-vim + coc-clangd plugin
Operating system:
linux-gentoo

Per https://clang.llvm.org/cxx_status.html#cxx23, clang does not support the -std=c++23 flag yet; try -std=c++2b instead.

but I use G++ as a compiler (due to some experimental features not yet
supported by clang), gcc don't support c++2b flag but support c++23...
Le mer. 28 déc. 2022 à 04:03, Nathan Ridge @.***> a
écrit :

Per https://clang.llvm.org/cxx_status.html#cxx23, clang does not support
the -std=c++23 flag yet; try -std=c++2b instead.
—
Reply to this email directly, view it on GitHub
https://github.com/clangd/clangd/issues/1438#issuecomment-1366332568,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJUDLRHBV3UM5OICEROJHXTWPOUY3ANCNFSM6AAAAAATI5WIP4
.
You are receiving this because you authored the thread.Message ID:
@.***>

Right, I understand, but clangd uses clang's front-end to process your code, so it's limited to supporting those options which clang supports.

@jlmxyz, you can use clangd's config file to remove -std=c++23 and add -std=c++2b, like so:
CompileFlags:
  Remove:
  - '-std=c++23'
  Add:
  - '-std=c++2b'

@jlmxyz, you can use clangd's config file to remove -std=c++23 and add -std=c++2b, like so:
CompileFlags:
  Remove:
  - '-std=c++23'
  Add:
  - '-std=c++2b'

Nice!!! this seems to did the trick! I wonder if clangd can't implement some default flag translation....

this did the trick to remove errors in CocDebug but I have strange error reported in sources
for exemple
unknown type name 'char8_t' (ccls 2)
but in https://clang.llvm.org/cxx_status.html#cxx20 we can see that char8_t is supported since Clang 7 and my version is Clang 15...
$ clang --version
clang version 15.0.6
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm/15/bin
Configuration file: /etc/clang/clang.cfg

same I've error Namespace alias decl 'fs' is unused  in following code
#include <filesystem>
namespace fs = std::filesystem;

#include "FileFilter.hpp"

extern const std::string cDirMetadataPath;

struct tConf
{
    fs::path Orig;
    fs::path Dest;
    bool recursive;
    int verboseLvl;
    FileFilter Filter;
};

namespace alias don't seems to be a feature introduced in a C++ revision... and fs namespace alias is used in tConf definition....

for exemple
unknown type name 'char8_t' (ccls 2)

@jlmxyz, why does it say "ccls 2"? Are you running ccls in parallel with clangd?

;) my bad.... I had a remain of ccls try that wasn't cleaned....
I fixed it, updated everything, this made the char8_t error disappeared but not the namespace error... but 2 errors reported in tConf struct about fs namespace disappeared also... the only error that remain is on line 2 where the namespace alias is decl (and clang report it as unused...)

Can you attach clangd logs from an editing session where you get that remaining error?

same I've error Namespace alias decl 'fs' is unused  in following code

This diagnostic seems to come from clang-tidy's misc-unused-alias-decl.

Can you attach clangd logs from an editing session where you get that remaining error?

here is the output I get from when I open the file that contain the namespace error (by the way the info given in https://clangd.llvm.org/installation don't works... since it's for another vim plugin...)
:CocCommand workspace.showOutput
I[20:55:00.075] <-- textDocument/definition(98)
I[20:55:00.076] --> reply:textDocument/definition(98) 1 ms
I[20:55:00.076] --> textDocument/clangd.fileStatus
I[20:55:00.104] <-- textDocument/didOpen
I[20:55:00.106] ASTWorker building file /home/jlm/crypt/Devel/projets/synctegrity/Conf.hpp version 1 with command inferred from /home/jlm/crypt/Devel/projets/synctegrity/main.cpp
[/home/jlm/crypt/Devel/projets/synctegrity/build]
/usr/x86_64-pc-linux-gnu/gcc-bin/12/c++ --driver-mode=g++ -DBOOST_SYSTEM_DYN_LINK -DBOOST_SYSTEM_NO_LIB -DBOOST_THREAD_DYN_LINK -DBOOST_THREAD_NO_LIB -I/home/jlm/crypt/Devel/projets/synctegrity/3rdParties/sha256 -c -resource-dir=/usr/lib/llvm/15/bin/../../../../lib/clang/15.0.6 -std=c++2b -- /home/jlm/crypt/Devel/projets/synctegrity/Conf.hpp
I[20:55:00.108] --> textDocument/clangd.fileStatus
I[20:55:00.222] <-- textDocument/inlayHint(99)
I[20:55:00.305] <-- textDocument/documentLink(100)
I[20:55:00.435] <-- textDocument/documentHighlight(101)
I[20:55:00.435] <-- $/cancelRequest
I[20:55:00.435] <-- textDocument/documentHighlight(102)
I[20:55:00.736] <-- $/cancelRequest
I[20:55:01.052] --> workspace/semanticTokens/refresh(7)
I[20:55:01.052] --> textDocument/clangd.fileStatus
I[20:55:01.053] <-- reply(7)
I[20:55:01.114] --> textDocument/publishDiagnostics
I[20:55:01.114] --> reply:textDocument/inlayHint(99) 892 ms
I[20:55:01.114] --> reply:textDocument/documentLink(100) 808 ms
I[20:55:01.114] --> reply:textDocument/documentHighlight(101) 679 ms, error: Task was cancelled.
I[20:55:01.114] --> reply:textDocument/documentHighlight(102) 678 ms, error: Task was cancelled.
I[20:55:01.114] --> textDocument/clangd.fileStatus
[Error - 20:55:01.116] Sending request textDocument/documentHighlight failed.
  Message: Request cancelled
  Code: -32800
[Error - 20:55:01.116] Sending request textDocument/documentHighlight failed.
  Message: Request cancelled
  Code: -32800

by the way the info given in https://clangd.llvm.org/troubleshooting#gathering-logs don't works... since it's for another vim plugin...

Yeah, there are quite a few LSP plugins for vim. If you're familiar with one that's not currently documented on the "Getting started" page, documentation patches are welcome! (The source of that page is at https://github.com/llvm/clangd-www/blob/main/installation.md#editor-plugins).

here is the output I get from when I open the file that contain the namespace error

I forgot to mention to add --log=verbose to the clangd command line to give us more useful logs, and also to share the contents of any relevant header files like FileFilter.hpp.
However, now that I take a look at the code in this comment again, I'm going to venture a guess that FileFilter.hpp also contains namespace fs = std::filesystem;, because in that case, I can reproduce the warning that you get.
Note that this warning also occurs when running clang-tidy on the command line, so it's not an issue specifiic to clangd; rather, it's a bug in the clang-tidy checker.
A workaround for the bug is to move the namespace fs = std::filesystem; below the #include "FileFilter.hpp". I would actually recommend doing this anyways for performance reasons, because clangd considers the file's "preamble" (the part whose AST it re-uses rather than re-parsing after each change to the file) to end at the first non-preprocessor declaration. So, in this case, FileFilter.hpp (and any other #includes you might place below the namespace-alias) will not be part of the preamble and will be re-parsed on each file change, degrading performance.

Note that this warning also occurs when running clang-tidy on the command line, so it's not an issue specifiic to clangd; rather, it's a bug in the clang-tidy checker.

Filed upstream as https://github.com/llvm/llvm-project/issues/59907

I would like to re-open the issue, for some reason, it seems that gcc's includes path are not used....
in another project, embedded platformio, clangd don't find some standard includes, like  or stdlib.h
I tried to manually add the includes path given by echo | /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-gcc -E -Wp,-v -
but it seems that this command don't provide all the path searched
ignoring duplicate directory "/home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/../../lib/gcc/arm-none-eabi/9.2.1/include"
ignoring nonexistent directory "/home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../arm-none-eabi/usr/local/include"
ignoring duplicate directory "/home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/../../lib/gcc/arm-none-eabi/9.2.1/include-fixed"
ignoring duplicate directory "/home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/../../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include"
ignoring duplicate directory "/home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../arm-none-eabi/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/include
 /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/include-fixed
 /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include
End of search list.

however, when I search the gcc path for stdlib I get
/home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/arm-none-eabi/include/ssp/stdlib.h
/home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/arm-none-eabi/include/stdlib.h
/home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/arm-none-eabi/include/machine/stdlib.h
/home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/arm-none-eabi/include/c++/9.2.1/tr1/stdlib.h
/home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/arm-none-eabi/include/c++/9.2.1/stdlib.h
/home/xxx/.platformio/packages/toolchain-atmelavr/avr/include/stdlib.h
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
the compile_command.json contains commands like this one :
{
        "command": "/home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-gcc -o .pioenvs/BTT_S42B_V2/FrameworkArduinoVariant/PeripheralPins.c.o -c -std=gnu11 -fmax-errors=5 -g -ggdb -Wall -Ofast -Os -mcpu=cortex-m3 -mthumb -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -DPLATFORMIO=60105 -DSTM32F103xB -DSTM32F1 -DSTM32F1xx -DARDUINO=10808 -DARDUINO_ARCH_STM32 -DARDUINO_GENERIC_F103CBTX -DBOARD_NAME=\\\"GENERIC_F103CBTX\\\" -DHAL_UART_MODULE_ENABLED -DUSE_FULL_LL_DRIVER -DVARIANT_H=\\\"variant_generic.h\\\" -Isrc/config -Isrc/lib/eXoCAN -Isrc/software -Isrc/hardware -Isrc/main -I/home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/avr -I/home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/stm32 -I/home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/stm32/LL -I/home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/stm32/usb -I/home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/stm32/OpenAMP -I/home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/stm32/usb/hid -I/home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/stm32/usb/cdc -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Drivers/STM32F1xx_HAL_Driver/Inc -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Drivers/STM32F1xx_HAL_Driver/Src -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/STM32F1xx -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Middlewares/ST/STM32_USB_Device_Library/Core/Inc -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Middlewares/ST/STM32_USB_Device_Library/Core/Src -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Middlewares/OpenAMP -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Middlewares/OpenAMP/open-amp/lib/include -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Middlewares/OpenAMP/libmetal/lib/include -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Middlewares/OpenAMP/virtual_driver -I/home/xxx/.platformio/packages/framework-cmsis/CMSIS/Core/Include -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Drivers/CMSIS/Device/ST/STM32F1xx/Include -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Drivers/CMSIS/Device/ST/STM32F1xx/Source/Templates/gcc -I/home/xxx/.platformio/packages/framework-cmsis/CMSIS/DSP/Include -I/home/xxx/.platformio/packages/framework-cmsis/CMSIS/DSP/PrivateInclude -I/home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino -I/home/xxx/.platformio/packages/framework-arduinoststm32/variants/STM32F1xx/F103C8T_F103CB\\(T-U\\) /home/xxx/.platformio/packages/framework-arduinoststm32/variants/STM32F1xx/F103C8T_F103CB(T-U)/PeripheralPins.c",
        "directory": "/home/xxx/crypt/Devel/3Dprinter/Intellistep-clean",
        "file": "/home/xxx/.platformio/packages/framework-arduinoststm32/variants/STM32F1xx/F103C8T_F103CB(T-U)/PeripheralPins.c"
    },

and for some reason, the compilation does succeed.... so the files are found...

<memory> is a C++ header, and the command you ran only lists C header paths.
I take it, then, that your project contains C++ source files as well as C source files.
For the C++ source files, do their entries in the compile_commands.json use arm-none-eabi-g++ (instead of arm-none-eabi-gcc), or alternatively contain -x c++ as an argument?
Are you using --query-driver, and is its argument a pattern that matches both the -gcc and -g++ executable paths?
If you're able to provide a complete set of clangd logs, taken with --log=verbose, for an editing session in which you start the editor and open a file containing the unresolved include, that would make it easiest to diagnose the issue.

for c++ file the arm-none-eabi-g++ is used
I read the docs, I saw about the --query-driver, but didn't understood how/where I should use it... can I set it inside .clangd  file at source top level? or shall I set it in :CocConfig? the latter is worst case, because I don't know the default settings  coc-clangd use and is not portable accross env (usable with CoC but not vscode....)
same for --log=verbose... should be REALLY nice if I could set the option in .clangd file....

ok, I managed to find a way to make it work :
{
    "clangd.arguments": ["--query-driver=/**/arm-none-eabi*", "--log=verbose"]
}

with query driver, the include path are correcly found...
this solution isn't "portable" but works with coc-clangd... I would have prefered to be able to set it inside .clangd file... so that every dev env that rely on clangd would have been fixed....

by the way... there miss some doc into https://releases.llvm.org/10.0.0/tools/clang/tools/extra/docs/clangd/Configuration.html#configuration on how to use the --query-driver.... (ie that ** will replace any path and that we can use * for word globing...)

I found a way to get trace log (using https://github.com/neoclide/coc.nvim/wiki/Debug-language-server)
clangd-trace.log
here is an extract... so it seems that .clangd file is correctly parsed, same for --* command lines options.... so I'm really puzzled... why if the -D are passed to compiler, clangd create errors?!?
V[19:01:24.634] System include extraction: target extracted: "arm-none-eabi"
V[19:01:24.634] System include extraction: adding  /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include/c++/9.2.1
V[19:01:24.634] System include extraction: adding  /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include/c++/9.2.1/arm-none-eabi
V[19:01:24.634] System include extraction: adding  /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include/c++/9.2.1/backward
V[19:01:24.634] System include extraction: adding  /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/include
V[19:01:24.634] System include extraction: adding  /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/include-fixed
V[19:01:24.634] System include extraction: adding  /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include
I[19:01:24.634] System includes extractor: successfully executed /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-g++
	got includes: "/home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include/c++/9.2.1, /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include/c++/9.2.1/arm-none-eabi, /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include/c++/9.2.1/backward, /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/include, /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/include-fixed, /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include"
	got target: "arm-none-eabi"
I[19:01:24.634] ASTWorker building file /home/xxx/crypt/Devel/3Dprinter/Intellistep-clean/src/software/parser.cpp version 1 with command
[/home/xxx/crypt/Devel/3Dprinter/Intellistep-clean]
/home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-g++ --target=arm-none-eabi --driver-mode=g++ -o .pioenvs/BTT_S42B_V2/src/software/parser.cpp.o -c -std=c++11 -std=gnu++14 -fno-threadsafe-statics -fno-rtti -fno-exceptions -fno-use-cxa-atexit -fmax-errors=5 -g -ggdb -Wall -Ofast -Os -mcpu=cortex-m3 -mthumb -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -DPLATFORMIO=60105 -DSTM32F103xB -DSTM32F1 -DSTM32F1xx -DARDUINO=10808 -DARDUINO_ARCH_STM32 -DARDUINO_GENERIC_F103CBTX "-DBOARD_NAME=\"GENERIC_F103CBTX\"" -DHAL_UART_MODULE_ENABLED -DUSE_FULL_LL_DRIVER "-DVARIANT_H=\"variant_generic.h\"" -Isrc -I.piolibdeps/BTT_S42B_V2/CircularBuffer -Isrc/config -Isrc/lib/eXoCAN -Isrc/software -Isrc/hardware -Isrc/main -I/home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/avr -I/home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/stm32 -I/home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/stm32/LL -I/home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/stm32/usb -I/home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/stm32/OpenAMP -I/home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/stm32/usb/hid -I/home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/stm32/usb/cdc -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Drivers/STM32F1xx_HAL_Driver/Inc -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Drivers/STM32F1xx_HAL_Driver/Src -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/STM32F1xx -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Middlewares/ST/STM32_USB_Device_Library/Core/Inc -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Middlewares/ST/STM32_USB_Device_Library/Core/Src -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Middlewares/OpenAMP -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Middlewares/OpenAMP/open-amp/lib/include -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Middlewares/OpenAMP/libmetal/lib/include -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Middlewares/OpenAMP/virtual_driver -I/home/xxx/.platformio/packages/framework-cmsis/CMSIS/Core/Include -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Drivers/CMSIS/Device/ST/STM32F1xx/Include -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Drivers/CMSIS/Device/ST/STM32F1xx/Source/Templates/gcc -I/home/xxx/.platformio/packages/framework-cmsis/CMSIS/DSP/Include -I/home/xxx/.platformio/packages/framework-cmsis/CMSIS/DSP/PrivateInclude -I/home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino -I/home/xxx/.platformio/packages/framework-arduinoststm32/variants/STM32F1xx/F103C8T_F103CB(T-U) -isystem /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include/c++/9.2.1 -isystem /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include/c++/9.2.1/arm-none-eabi -isystem /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include/c++/9.2.1/backward -isystem /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/include -isystem /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/include-fixed -isystem /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include -DGCC_VERSION=90201 -D__SOFTFP__=1 -D__VFP_FP__=1 -resource-dir=/usr/lib/llvm/15/bin/../../../../lib/clang/15.0.7 -- /home/xxx/crypt/Devel/3Dprinter/Intellistep-clean/src/software/parser.cpp
V[19:01:24.635] Ignored diagnostic. argument unused during compilation: '-fmax-errors=5'
V[19:01:24.635] Ignored diagnostic. argument unused during compilation: '--param max-inline-insns-single=500'
V[19:01:24.636] Driver produced command: cc1 -cc1 -triple thumbv7m-none-unknown-eabi -fsyntax-only -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name parser.cpp -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -fno-verbose-asm -mconstructor-aliases -nostdsysteminc -target-cpu cortex-m3 -target-feature +soft-float-abi -target-feature -crc -target-feature -dsp -target-feature -mve -target-feature -ras -target-feature -sb -target-feature -i8mm -target-feature -lob -target-feature -cdecp0 -target-feature -cdecp1 -target-feature -cdecp2 -target-feature -cdecp3 -target-feature -cdecp4 -target-feature -cdecp5 -target-feature -cdecp6 -target-feature -cdecp7 -target-feature -pacbti -target-feature -hwdiv-arm -target-feature +hwdiv -target-feature -vfp2 -target-feature -vfp2sp -target-feature -vfp3 -target-feature -vfp3d16 -target-feature -vfp3d16sp -target-feature -vfp3sp -target-feature -fp16 -target-feature -vfp4 -target-feature -vfp4d16 -target-feature -vfp4d16sp -target-feature -vfp4sp -target-feature -fp-armv8 -target-feature -fp-armv8d16 -target-feature -fp-armv8d16sp -target-feature -fp-armv8sp -target-feature -fullfp16 -target-feature -fp64 -target-feature -d32 -target-feature -neon -target-feature -dotprod -target-feature -fp16fml -target-feature -bf16 -target-feature -mve.fp -target-feature -fpregs -target-feature -crypto -target-feature -sha2 -target-feature -aes -target-feature +strict-align -target-abi aapcs -mfloat-abi soft -Wunaligned-access -fallow-half-arguments-and-returns -mllvm -treat-scalable-fixed-error-as-warning -debug-info-kind=constructor -dwarf-version=5 -debugger-tuning=gdb -ffunction-sections -fdata-sections -fcoverage-compilation-dir=/home/xxx/crypt/Devel/3Dprinter/Intellistep-clean -resource-dir /usr/lib/llvm/15/bin/../../../../lib/clang/15.0.7 -include /usr/include/gentoo/fortify.h -isystem /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include/c++/9.2.1 -isystem /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include/c++/9.2.1/arm-none-eabi -isystem /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include/c++/9.2.1/backward -isystem /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/include -isystem /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/include-fixed -isystem /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/include -D PLATFORMIO=60105 -D STM32F103xB -D STM32F1 -D STM32F1xx -D ARDUINO=10808 -D ARDUINO_ARCH_STM32 -D ARDUINO_GENERIC_F103CBTX -D "BOARD_NAME=\"GENERIC_F103CBTX\"" -D HAL_UART_MODULE_ENABLED -D USE_FULL_LL_DRIVER -D "VARIANT_H=\"variant_generic.h\"" -I src -I .piolibdeps/BTT_S42B_V2/CircularBuffer -I src/config -I src/lib/eXoCAN -I src/software -I src/hardware -I src/main -I /home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/avr -I /home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/stm32 -I /home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/stm32/LL -I /home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/stm32/usb -I /home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/stm32/OpenAMP -I /home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/stm32/usb/hid -I /home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/stm32/usb/cdc -I /home/xxx/.platformio/packages/framework-arduinoststm32/system/Drivers/STM32F1xx_HAL_Driver/Inc -I /home/xxx/.platformio/packages/framework-arduinoststm32/system/Drivers/STM32F1xx_HAL_Driver/Src -I /home/xxx/.platformio/packages/framework-arduinoststm32/system/STM32F1xx -I /home/xxx/.platformio/packages/framework-arduinoststm32/system/Middlewares/ST/STM32_USB_Device_Library/Core/Inc -I /home/xxx/.platformio/packages/framework-arduinoststm32/system/Middlewares/ST/STM32_USB_Device_Library/Core/Src -I /home/xxx/.platformio/packages/framework-arduinoststm32/system/Middlewares/OpenAMP -I /home/xxx/.platformio/packages/framework-arduinoststm32/system/Middlewares/OpenAMP/open-amp/lib/include -I /home/xxx/.platformio/packages/framework-arduinoststm32/system/Middlewares/OpenAMP/libmetal/lib/include -I /home/xxx/.platformio/packages/framework-arduinoststm32/system/Middlewares/OpenAMP/virtual_driver -I /home/xxx/.platformio/packages/framework-cmsis/CMSIS/Core/Include -I /home/xxx/.platformio/packages/framework-arduinoststm32/system/Drivers/CMSIS/Device/ST/STM32F1xx/Include -I /home/xxx/.platformio/packages/framework-arduinoststm32/system/Drivers/CMSIS/Device/ST/STM32F1xx/Source/Templates/gcc -I /home/xxx/.platformio/packages/framework-cmsis/CMSIS/DSP/Include -I /home/xxx/.platformio/packages/framework-cmsis/CMSIS/DSP/PrivateInclude -I /home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino -I /home/xxx/.platformio/packages/framework-arduinoststm32/variants/STM32F1xx/F103C8T_F103CB(T-U) -D GCC_VERSION=90201 -D __SOFTFP__=1 -D __VFP_FP__=1 -internal-isystem /usr/lib/llvm/15/bin/../../../../lib/clang/15.0.7/include -internal-isystem /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/../lib/clang-runtimes/arm-none-eabi/include -Os -Wall -std=gnu++14 -fdeprecated-macro -fdebug-compilation-dir=/home/xxx/crypt/Devel/3Dprinter/Intellistep-clean -ferror-limit 19 -stack-protector 2 -fno-rtti -fno-signed-char -fno-use-cxa-atexit -fgnuc-version=4.2.1 -fno-threadsafe-statics -vectorize-loops -vectorize-slp -no-round-trip-args -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -x c++ /home/xxx/crypt/Devel/3Dprinter/Intellistep-clean/src/software/parser.cpp
I[19:01:24.636] --> textDocument/clangd.fileStatus
V[19:01:24.636] >>> {"jsonrpc":"2.0","method":"textDocument/clangd.fileStatus","params":{"state":"parsing includes, running Update","uri":"file:///home/xxx/crypt/Devel/3Dprinter/Intellistep-clean/src/software/parser.cpp"}}

V[19:01:24.636] Building first preamble for /home/xxx/crypt/Devel/3Dprinter/Intellistep-clean/src/software/parser.cpp version 1
[Trace - 19:01:24.637] Received notification 'textDocument/clangd.fileStatus'.
Params: {
    "state": "parsing includes, running Update",
    "uri": "file:///home/xxx/crypt/Devel/3Dprinter/Intellistep-clean/src/software/parser.cpp"
}

with query driver, the include path are correcly found... this solution isn't "portable" but works with coc-clangd... I would have prefered to be able to set it inside .clangd file... so that every dev env that rely on clangd would have been fixed....

FWIW, the reason for requiring --query-driver to be configured outside of .clangd is security: it gives clangd permission to execute a file whose path is specified in another project metadata file (compile_commands.json), so it could be a potential vector for malicious code execution in an untrusted project.
(The practical impact of this depends on the editor; in vscode, clangd arguments can be specified in .vscode/settings.json which may also be checked in, so it makes no difference.)
There is some discussion about making --query-driver easier to use in https://github.com/clangd/clangd/issues/539.

by the way... there miss some doc into https://releases.llvm.org/10.0.0/tools/clang/tools/extra/docs/clangd/Configuration.html#configuration on how to use the --query-driver.... (ie that ** will replace any path and that we can use * for word globing...)

There is some description in clangd --help, but I agree that the details of the glob syntax could use more detailed documentation; https://github.com/llvm/llvm-project/issues/56623 is on file for this.

here is an extract... so it seems that .clangd file is correctly parsed, same for --* command lines options.... so I'm really puzzled... why if the -D are passed to compiler, clangd create errors?!?

It's hard to say without also seeing the errors, and the source code that triggers the errors.
But one thing to keep in mind is that .clangd files are scoped to the directory that contains them, so a -D flag specified in /project/.clangd will be applied when opening /project/source.cpp, but not when opening /system/header.hpp.

the error is simple :  "GCC version 6.3 or higher is required"
because clangd thinks it should select the #error "GCC version 6.3 or higher is required" line...
there is then 2 behavior error of clangd :

headers can be configured (this is the aim of #defines : having some features with one project and anothers with anothers, in particular with templates, and this is why libraries provide pkgconfig or similar mecanism to retrieve the flags they where compiled with) here the headers are out of source tree, but shall be parsed with defines => this is shown by the -DGCC_VERSION=90201 in .clangd that don't pass the #if GCC_VERSION < 60300 in library's header
the builtin defines of compiler aren't correctly guessed : although the used compiler is a gcc one, none of the builtin defines of the compiler are used (__GNUC__, __GNUC_MINOR__,  __GNUC_PATCHLEVEL__, __SOFTFP__, __VFP_FP__ and so on that are given by arm-none-eabi-gcc -dM -E - < /dev/null) => this is shown by the fact that the #define GCC_VERSION in source should have generated a correct GCC_VERSION since all defines are provided by compiler's builtin , even if not provided by custom .clangd

about --query-driver : I read the thread (will post a comment there) but there could be a simple approach :  if the executable match a *gcc *clangd *cc *c++ ... and so one (there aren't a lot of compilers, intel, gcc, clang... and anyway, you have to adapt to compiler specificities like -dM -E to get builtin defines, even if compilers tends to be more and more interchangeable) then treat it as the corresponding compiler (*gcc -> gcc...)

headers can be configured (this is the aim of #defines : having some features with one project and anothers with anothers, in particular with templates, and this is why libraries provide pkgconfig or similar mecanism to retrieve the flags they where compiled with) here the headers are out of source tree, but shall be parsed with defines => this is shown by the -DGCC_VERSION=90201 in .clangd that don't pass the #if GCC_VERSION < 60300 in library's header

If the header is outside of the source tree, then the .clangd in the source tree will not apply to it (it's scoped to the directory).
You could use a user config file to specify flags to apply to the directory containing the headers:
If:
  PathMatch: /path/to/headers/.*

CompileFlags:
  Add: -DSOMETHING

the builtin defines of compiler aren't correctly guessed : although the used compiler is a gcc one, none of the builtin defines of the compiler are used (__GNUC__, __GNUC_MINOR__,  __GNUC_PATCHLEVEL__, __SOFTFP__, __VFP_FP__ and so on that are given by arm-none-eabi-gcc -dM -E - < /dev/null) => this is shown by the fact that the #define GCC_VERSION in source should have generated a correct GCC_VERSION since all defines are provided by compiler's builtin , even if not provided by custom .clangd

Clangd doesn't have a mechanism for extracting built-in macros (see #533 for some discussion about this).
It should define the correct target-specific macros based on its own support for that target, but things like __GNUC__ will indeed not be part of that, so if those are important they need to be overridden using .clangd. (But it's worth noting that if those are important, the code is already not portable between gcc and clang to begin with.)

:-1:  really, you're serious!?! a user config file isn't portable, all people that will works on the project will fall in the same issue... what do you do if you works on more than 1 project?!
:-1:  also for not using the compiler built in defines...
I can't even do a shared .clangd in source tree that add -include compiler_flags.h that I can generate with
	rm -f compiler_defines.h
	for comp in $$(cat  compile_commands.json  | grep -E "\"command\": \"[^[:space:]]* -o" | sed 's:"command"\: "::g; s:-o.*::g' | sort | uniq); do \
		$${comp} -dM -E - < /dev/null >>  compiler_defines.h; \
	done

really... clangd and languages server did facilitate things a lot... but not supporting so basic dev... I'm not even developping a hyper akward app/lib with out of the box build system... just doing what 99.9999999% of C/C++ projects do : use library, get CGLAGS and CXXFLAGS using pkgconfig like mecanism.... and want to have the compiler supported? what do you do if a lib have some code if built with CLANG and another if build with GCC? clangd will provide stupid hints...
what the point of creating a SCOPPED .clangd? just the pleasure of adding a functionality that will create issues and having to reply to threads like this? there isn't even a security concern... this is just ill st***d feature that don't even match the reality of what occurs when the file is compiled....

The reason project config (.clangd) files are currently scoped to the directory containing them is that clangd doesn't currently have a notion of a "workspace" (which in turn is because it needs to support editors like vim which don't have a notion of a workspace).
So when opening a file at some path /a/b/c/file.cpp, the only mechanisms available to clangd to discover config files that it should apply are:

project config files, which are searched for in /a/b/c/, /a/b/, and /a
the user config file, searched for in ~/.config/clangd/config.yaml or similar

I completely agree that it would be super useful for it to also apply:

"workspace config file" at /current/workspace/.clangd because /current/workspace is the currently open workspace

but like I said, unfortunately the "currently open workspace" is not a piece of state that clangd currently tracks.
I would love for clangd to start doing that (for editors that support such a notion), and such a mechanism has been proposed as a "strong workspace mode" here.
But in the meantime, user config files seem like the next best workaround.

what do you do if you works on more than 1 project?

Clangd config files can contain multiple fragments separated by ---, and the contents of a fragment limited to certain paths with If:. So you can put something like this in the user config:
If:
  PathMatch: /some/path/for/project1/.*

CompileFlags:
  Add: /* flags relevant for project 1 */

---

If:
  PathMatch: /some/path/for/project2/.*

CompileFlags:
  Add: /* flags relevant for project 2 */

I do agree this is more of a workaround than a proper solution.

what I don´t get is that for me, clangd use compile_commands.json to work, without this file, which is a kind of "project"/"workspace". This is the top level file that is required... using this file location, you get the .clangd config file if I correctly understood. So in fact we have
compile_commands.json
      |-> file1.c
      |        |-> header1.h
      |        |-> header2.h
      |        |         |-> /system/header3.h
      |        |         |-> header4.h
      |        |         |         |-> outofspace/header5.h
      |        |-> somewhereElse/header6.h
      |-> file2.c
      |        |-> ...
      |-> file3.cpp
      |        |-> ...
      |-> file4.c
      |        |-> ...
      |-> ...
.clangd

so, it's a recursive scheme...
what I don't get is that you HAVE TO get the top level sources files (or project sources if you prefer) and that you already apply .clangd on it... so there is no problem "linking" source<->conf
you also HAVE TO find the header dependencies of a source file... so you have a [ "file1.c", "header1.h", "header2.h", "/system/header3.h", "header4.h", "outofspace/header5.h", "somewhereElse/header6.h" ] file list... where the files lies is NO  INTEREST, they can be a system header, a file stored in a user directory, a file stored on a network share, a file stored in another user shared directory... it's no interest...
BUT for some reason, you decide to apply not the same rule within the list... the reason you give is that they can be out of project's sources... but... why? there is no security reason....
taking an example :
$(CC) $(CFLAGS) -M source.c will give all source dependencies (this works with gcc, you have, I guess, a similar behavior)
as I said, clangd CAN'T work without compile_commands.json, so anything that can't be found by dependency tree of this file, is simply "out of interest"
ex : a line in compile_commands.json like
    {
        "command": "/home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-g++ -o .pioenvs/BTT_S42B_V2/src/software/commandsQueue.cpp.o -c -std=c++11 -std=gnu++14 -fno-threadsafe-statics -fno-rtti -fno-exceptions -fno-use-cxa-atexit -fmax-errors=5 -g -ggdb -Wall -Ofast -Os -mcpu=cortex-m3 -mthumb -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -DPLATFORMIO=60105 -DSTM32F103xB -DSTM32F1 -DSTM32F1xx -DARDUINO=10808 -DARDUINO_ARCH_STM32 -DARDUINO_GENERIC_F103CBTX -DBOARD_NAME=\\\"GENERIC_F103CBTX\\\" -DHAL_UART_MODULE_ENABLED -DUSE_FULL_LL_DRIVER -DVARIANT_H=\\\"variant_generic.h\\\" -Isrc -I.piolibdeps/BTT_S42B_V2/CircularBuffer -Isrc/config -Isrc/lib/eXoCAN -Isrc/software -Isrc/hardware -Isrc/main -I/home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/avr -I/home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/stm32 -I/home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/stm32/LL -I/home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/stm32/usb -I/home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/stm32/OpenAMP -I/home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/stm32/usb/hid -I/home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino/stm32/usb/cdc -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Drivers/STM32F1xx_HAL_Driver/Inc -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Drivers/STM32F1xx_HAL_Driver/Src -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/STM32F1xx -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Middlewares/ST/STM32_USB_Device_Library/Core/Inc -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Middlewares/ST/STM32_USB_Device_Library/Core/Src -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Middlewares/OpenAMP -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Middlewares/OpenAMP/open-amp/lib/include -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Middlewares/OpenAMP/libmetal/lib/include -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Middlewares/OpenAMP/virtual_driver -I/home/xxx/.platformio/packages/framework-cmsis/CMSIS/Core/Include -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Drivers/CMSIS/Device/ST/STM32F1xx/Include -I/home/xxx/.platformio/packages/framework-arduinoststm32/system/Drivers/CMSIS/Device/ST/STM32F1xx/Source/Templates/gcc -I/home/xxx/.platformio/packages/framework-cmsis/CMSIS/DSP/Include -I/home/xxx/.platformio/packages/framework-cmsis/CMSIS/DSP/PrivateInclude -I/home/xxx/.platformio/packages/framework-arduinoststm32/cores/arduino -I/home/xxx/.platformio/packages/framework-arduinoststm32/variants/STM32F1xx/F103C8T_F103CB\\(T-U\\) src/software/commandsQueue.cpp",
        "directory": "/home/xxx/crypt/Devel/3Dprinter/Intellistep-clean",
        "file": "/home/xxx/crypt/Devel/3Dprinter/Intellistep-clean/src/software/commandsQueue.cpp"
    },

gives
commandsQueue.o: src/software/commandsQueue.cpp \
 src/software/commandsQueue.h src/hardware/position.h \
 /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/lib/gcc/arm-none-eabi/9.2.1/include/stdint.h \
 /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/arm-none-eabi/include/stdint.h \
 /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/arm-none-eabi/include/machine/_default_types.h \
 /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/arm-none-eabi/include/sys/features.h \
 /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/arm-none-eabi/include/_newlib_version.h \
 /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/arm-none-eabi/include/sys/_intsup.h \
 /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/arm-none-eabi/include/sys/_stdint.h \
 src/config/config.h src/software/macros.h src/config/config_adv.h \
 src/config/pins.h src/software/sanityCheck.h

so, I don't have to have a "project file" or "editors like vim which don't have a notion of a workspace" in fact, I don't have to care anything about what dev env the user use... just have to

parse compile_commands.json,
ask the compiler the dependencies, add them to the source list, link Compile flags to it
parse the file according to Compile flag
move to next entry in commands.json, and redo the process

every single file listed in the previous list have to be processed using the
/home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-g++ -o .pioenvs/BTT_S42B_V2/src/software/commandsQueue.cpp.o -c -std=c++11 -std=gnu++14 -fno-threadsafe-statics -fno-rtti -fno-exceptions -fno-use-cxa-atexit -fmax-errors=5 -g -ggdb -Wall -Ofast -Os -mcpu=cortex-m3 -mthumb -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -DPLATFORMIO=60105 -DSTM32F103xB -DSTM32F1 -DSTM32F1xx -DARDUINO=10808 -DARDUINO_ARCH_STM32 -DARDUINO_GENERIC_F103CBTX -DBOARD_NAME=\\\"GENERIC_F103CBTX\\\" -DHAL_UART_MODULE_ENABLED -DUSE_FULL_LL_DRIVER -DVARIANT_H=\\\"variant_generic.h\\\"

which is the command of compile_commands.json, stripped of -Ientries, since they already where resolved by the $(CC) $(CFLAGS) -M source.c
simple solution that don't have to care about the editor, implement support for a "project file", works with vscode, vim, emacs, eclipse, bordland c++, delphi (oups, this isn't C/C++ language) or  editor, dev-env, project manager, build system (scons, Cmake, gnu-make....)

Note that compile_commands.json also has the same "scope" problem as .clangd -- it's found by looking in ancestor directories of the file you're opening.
(Except that for compile_commands.json, clangd supports the --compile-commands-dir command-line argument to override it, which allows you to achieve workspace semantics if you can specify your clangd arguments per workspace, e.g. in vscode by specifying "clangd.arguments" in workspace settings. Having a similar command-line flag for config files would already be nice, and that's been suggested in #845 / #1336.)

ok now I get how it seems to work...
when a file is opened, you go up the tree, without caring if a clangd instance is run... and try to find a compile_commands or a .clangd....
in fact it's not something like

at start of clangd, get the compile_commands.json
on other file opening, apply what we previously found.

but more

on each file to parse, try to find a compile_commands.json, else apply dummy flags that won't fit the project, but don't care...

if fact opening /usr/include/stdint.h from a project.cpp is the same as opening /usr/include/stdint.h from anywhere... and even your solution of user clang configuration file per project with PathMatch, don't work in fact, since /usr/include PathMatch will be in several project (same PathMatch  /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/arm-none-eabi/include/ in my case will match every project that have a arm based target... so in my case about 10 projects... and having clangd apply the same rule to all projects)
why don't you provide the editor plugin an environment variable to set the compile_commands.json path? the editor plugin know the first file opened, so the project... or a --compile-commands-path  so can call clangd with some context?!?

why don't you provide the editor plugin an environment variable to set the compile_commands.json path? the editor plugin know the first file opened, so the project... or a --compile-commands-path so can call clangd with some context?!?

That would be more or less how the "strong workspace mode" that I mentioned would operate.
(My specific suggestion made here was for the workspace path to be communicated using the rootUri parameter of the LSP initialize request, but that's kind of a detail.)

you should have a look at the attached log into https://github.com/clangd/clangd/issues/1438#issuecomment-1433520673

[Trace - 19:01:24.592] Sending request 'initialize - (0)'.
Params: {
    "processId": 22996,
    "rootPath": "/home/xxx/crypt/Devel/3Dprinter/Intellistep-clean",
    "rootUri": "file:///home/xxx/crypt/Devel/3Dprinter/Intellistep-clean",

=> seems that you wish is already fulfilled... so, the issue is in clangd, not in editor extension (that do well the job)
=> that leave the question : why is not .clangd applied to the source, since you have the path to look for this file provided by coc-clangd ?
=> if .clangd would be applied on each source into the workspace, even if the file is outsite de rootPath, then a compiler build in defines header can be added using this file to workaround the fact that you don't get compiler build-ins...

Yes, "strong workspace mode" needs implementation in clangd.
I'm glad to hear that coc-clangd already provides the rootUri and will be able to benefit from it (assuming this implementation approach is chosen).

well too bad that not even "weak workspace mode" is not implemented...
I've done some investigation on my side
I forced the --compile-commands-dir= on clangd when run through coc-clangd
25988 ?        Ssl    0:45 gvim src/software/Lists.h SHELL=/bin/bash WINDOWID=0 COLORTERM=truecolor CSF_MDTVTexturesDirectory=/usr/share/opencascade/resources/Textures XDG_CONFIG_DIRS=/etc/xdg LESS=-R -M --shift 5 JDK_HOME=/opt/oracle-jdk-bin-<IP_ADDRESS>/ CONFIG_PRO
26002 ?        Ssl    2:56  \_ node --no-warnings /home/jlm/crypt/conf/vim/.vim/plugged/coc.nvim/build/index.js SHELL=/bin/bash WINDOWID=0 COLORTERM=truecolor CSF_MDTVTexturesDirectory=/usr/share/opencascade/resources/Textures XDG_CONFIG_DIRS=/etc/xdg LESS=-R -M -
26018 ?        Sl     0:03      \_ /usr/lib/llvm/15/bin/clangd --query-driver=/**/arm-none-eabi* --log=verbose --enable-config --compile-commands-dir=/home/jlm/crypt/Devel/3Dprinter/Intellistep-clean SHELL=/bin/bash WINDOWID=0 COLORTERM=truecolor CSF_MDTVTexturesD

so now, clangd has no excuse to not knowing where to search for compile database and .clangd file... BUT looking the communication log :  when opening a file, if the file is not in the compile-commands-dir, .clangd is not applied... so, even if clangd is aware where to find the files, there is a design choice (that is not a technical choice) to distinguish the way the source inside the source tree and outside the source tree are parsed...
design choice that is against the way compiler do works...
the only "workaround" I found is to generate a include with compiler definition and force in compile_commands.json to include the compiler definition...
compile_commands.json ::
	pio run -t compile_commands.json
	rm -f compiler_defines.h
	for comp in $$(cat  compile_commands.json  | grep -E "\"command\": \"[^[:space:]]* -o" | sed 's:"command"\: "::g; s:-o.*::g' | sort | uniq); do \
		$${comp} -dM -E - < /dev/null >>  compiler_defines.h; \
	done
	sed -i "s:.cpp\",:.cpp -include $${PWD}/compiler_defines.h\",:" compile_commands.json
	sed -i "s:.c\",:.c -include $${PWD}/compiler_defines.h\",:" compile_commands.json

this is ugly... but fixed some issues.. not all issues sadely... for example I've a source that depends only on #include <memory>, this is the ONLY include.... and clangd reports
V[22:17:53.238] Dropped diagnostic: /home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/arm-none-eabi/include/c++/9.2.1/memory: in included file: redefinition of parameter 'restrict' in <memory>
but

[Trace - 22:42:37.915] Received notification 'textDocument/publishDiagnostics'.
Params: {
    "diagnostics": [
        {
            "code": "param_redefinition",
            "message": "In included file: redefinition of parameter 'restrict'",
            "range": {
                "end": {
                    "character": 10,
                    "line": 3
                },
                "start": {
                    "character": 9,
                    "line": 3
                }
            },
            "relatedInformation": [
                {
                    "location": {
                        "range": {
                            "end": {
                                "character": 68,
                                "line": 90
                            },
                            "start": {
                                "character": 58,
                                "line": 90
                            }
                        },
                        "uri": "file:///home/xxx/.platformio/packages/toolchain-gccarmnoneeabi/arm-none-eabi/include/wchar.h"
                    },
                    "message": "Error occurred here"
                }
            ],
            "severity": 1,
            "source": "clang"
        },
        {
            "code": "fatal_too_many_errors",
            "message": "Too many errors emitted, stopping now",
            "range": {
                "end": {
                    "character": 0,
                    "line": 0
                },
                "start": {
                    "character": 0,
                    "line": 0
                }
            },
            "relatedInformation": [],
            "severity": 1,
            "source": "clang"
        }
    ],
    "uri": "file:///home/xxx/crypt/Devel/3Dprinter/Intellistep-clean/src/software/Lists.h",
    "version": 1
}

=> first, it miss the location of the previous definition to be a usefull diagnostic, but this likely seems to be a coc-clangd issue...
=> seconds, don't even know the line.... (same)
=> third, the diagnotics are ignored when parsing the <memory>  but reported when parsing the file that #include <memory>
and seems that I found another bug in parsing .clangd file :
CompileFlags:   Add: [ "-include compiler_defines.h" ]
also tried
CompileFlags:   Add: [ -include compiler_defines.h ]
but what is added on the command line is  -include " compiler_defines.h" note the extra space....
so... there is a workaround... but it's highly ugly... having to modify the compile_commands.json is not something desirable, because it might break other tools...

and about the restrict.... this is caused by the
size_t	mbrlen (const char *__restrict, size_t, mbstate_t *__restrict);
https://en.wikipedia.org/wiki/Restrict => normaly this is supported by clang....

and seems that I found another bug in parsing .clangd file : CompileFlags: Add: [ "-include compiler_defines.h" ] also tried CompileFlags: Add: [ -include compiler_defines.h ] but what is added on the command line is  -include " compiler_defines.h" note the extra space....

This is working as intended, if a bit counterintuitive.
When you run clang on the command line, the shell breaks the commands into individual arguments, we can think of it as a vector<string>.
If you write clang -include compiler_defines.h, that becomes ["clang", "-include", "compiler_defines.h"].
If you write clang "-include compiler_defines.h", that becomes ["clang", "-include compiler_defines.h"]. The interpretation of this inside the clang driver is that every character after the flag, including the space, is part of the argument to the flag.
When processing CompilerFlags: Add:, the list inside the [] is appended to this vector<string>.
So if you write Add: [-include compiler_defines.h], then "-include compiler_defines.h" is added as a single argument, and you get the same semantics as if you had quoted it as "-include compiler_defines.h" on the command line.
To get it to be parsed as two arguments, you can write Add: [-include, compiler_defines.h].

having to modify the compile_commands.json is not something desirable, because it might break other tools...

In one project that I work on, our build system generates a special compile_commands.json for clangd's consumption. It's placed in <project>/build/clangd/compiler_commands.json, and we point clangd to it using --compile-commands-dir.

closed as a related to #907 and #533 since there is the workaround described into #533 (comment)


Add concurrency mechanics

Now one can add mutex or limited parallelism to theis datasources
var count1 = 0
val get = getDataSource<Unit, Int> { count1++ }.parallelism(1)
val get2 = getDataSource<Unit, Int> { count1++ }.mutex()

Pull Request Test Coverage Report for Build #20

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build #19:
0.0%

Covered Lines:
227

Relevant Lines:
227

💛  - Coveralls


openjdk: 1.8.0_265 -> 1.8.0_272

Motivation for this change
Things done

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

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

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

sh-4.4# result/bin/java -version
openjdk version "1.8.0_272"
OpenJDK Runtime Environment (build 1.8.0_272-b10)
OpenJDK 64-Bit Server VM (build 25.272-b10, mixed mode)

[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

/cc @NeQuissimus

/cc @Ma27

/marvin opt-in
/status needs_merger

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/hash-mismatch-building-jre-on-release-20-09/9898/2

sha256 hashes get wrong

We know. Have a look at previous mentioned discourse thread.


Allow endpoint security to be disabled

This requires compliments https://github.com/infinispan/infinispan-images/issues/16
We should then allow the following yaml to be configured to disable auth on specifc endpoints:
endpoints:
  hotrod:
    auth: true | false
    enabled: true
  rest:
    auth: true | false
    enabled: true

@ryanemerson , I have tried to disable auth with this config, but the server still requires authentication.
Minimal reproducible configuration:
Infinispan: 11.0.3.Final
Do not pass IDENTITIES_PATH, USER and PASS variables
infinispan.yaml:
...
endpoints:
  hotrod:
    auth: false
    enabled: true
    qop: auth
    serverName: infinispan
  rest:
    auth: false
    enabled: true
...

Then curl -iv infinispan:11222/rest/v2/caches: HTTP/1.1 401 Unauthorized
When using auto-generated credentials from this setup, the request authenticated.

@dev-e Unfortunately this is due to the way the security-realm is configured on the endpoints. https://github.com/infinispan/infinispan-images/issues/88 tracks this issue.


 As you can see my partial view needs some viewmodel data (which is not a primitive type), which I pass in. And that breaks the serializer.
Others have reported this problem as well. The suggestion there was to only use primitive types for such an argument. But I can't do that because that partial view (the donut hole) is a form which is expecting various viewmodel data.
How do I handle this problem?

What I've done, is instead of making the entire partial a donut hole, I've made only the unique part of it a donut hole. So instead of the view calling the child action, it calls the partial, which calls the child action.
Works perfectly.