support for auto pulling gdocs

The purpose of this pull request is to add support for the export of specified Google docs as .docx files into the /_word directory prior to the call to the word2post.sh script. This enables users to store their blog posts securely in Drive and then automatically pull them on build. Note that these documents needs to be publicly available in order for this to work. However, since the goal is to publish on a fastpage, I don't think this should raise concerns for users.
There are two additions in this request:

The _action_files/gdocs2word.py script which uses the request lib to pull down documents through a download link.

A gdoc_ids.json file that holds ids of the document that one wants to include.
Users simply need to add docs, e.g.

{
    "gdoc_ids": [
        "1d1N-2j56BVRVXOFPRlJRdgictahCVMGmklRtYRVGD1E"
    ]
}

Document titles are automatically retrieved from the request header.

That's it

That's it

@Peter-Rambeck could you clarify? This enables users to conveniently write in Google Docs. This is in addition to .docx which is already supported.

Sorry, it's dummy comment as comments was somehow required to proceed.

Sorry, it's dummy comment as comments was somehow required to proceed.

No worries. Feedback encouraged.

NB: I am writing this comment on all open issues and PRs
Thank you for opening this PR, and I'm really sorry I haven't gotten around to reviewing it.  All of my time has been focused on nbdev.   In the new version of nbdev, we knew that we wanted to include blogging rather than it being a separate project.  We realized that Quarto, which the new version of nbdev is built on, is much better than fastpages.    Rather than keep this project going, we are recommending that people migrate to Quarto as we think that will be more powerful for users and is a much better tool for blogging.
I've written a detailed migration guide with some tools that will hopefully make the process of switching much easier.  Overall I think it will be worth it for users.
My apologies again for not getting to this issue sooner.  Will close this PR with this PR https://github.com/fastai/fastpages/pull/657, where we are letting people know that we are deprecating this project.  Thanks again for your support and for using fastpages!  🙇🏽


Email field become blank after saving the inventory.

Framework Version: 0.1.2
Test Steps:

Create a inventory and save it.
Now edit the inventory.

Cannot reproduce this bug.

Framework Version: 0.1.4
Fixed


IOexception

https://www.reddit.com/r/DataHoarder/comments/1g4342q/comment/ls2hv18/

I'm having a lot of issues trying to get this going on Windows.
First UV didn't work to install it (something about Torch version). Switched to pipx install method. It hung on installing librariesent or something? (it's off the buffer now). Tried to install again, said it was installed. I ran --help and it worked but it took 20 seconds for it to return anything.
Ran one of the examples (specifying output and video url) to see if it worked and it just spit out a ton of YoutubeDL errors and I kinda gave up.

https://www.reddit.com/r/DataHoarder/comments/1g4342q/comment/lsfz2py/

This is Win 10, but had similar issues on Win 11.
I did not have ffmpeg specified in path, so I added it. That meant the output could work (without specifying a file).
I ran into trouble trying to specify an output file. Tried full path, relative path, just the filename, in single and double quotes, forward slashes and back slashes, leading slash/no leading slash and could not get anything to work.
Here's the output for one try, for what it's worth. It was always the same IOexception: https://i.imgur.com/J9dFHtj.png
What finally worked is simply specifying output in the usual way, i.e. command > file.txt.
I see you've taken Windows install instructions off the github. If you happen to add them back, hopefully this info is useful for when dummies like me try to install your stuff. You could also add instructions to activate the venv, which would be helpful to someone unfamiliar with newer versions of python.

Fixed in https://github.com/shun-liang/yt2doc/releases/tag/0.2.6


Redis db is not set before resolving a connection promise

I've written a test in __tests__/core/connection.js that currently fails
test('will select redis db before returning connection', async () => {
    let connectionDetails = specHelper.cleanConnectionDetails()
    connectionDetails.database = 9
    let connection = new NodeResque.Connection(connectionDetails)
    await connection.connect()
    expect(connection.redis.options.db).toBe(connectionDetails.database)
    connection.end()
  })

Test output:
Expected value to be:
      9
    Received:
      0

That looks scary!  However, I don't think that ioredis "options" works the way we think it does.  Try the following:
const ioredis = require('ioredis')
const conn = new ioredis()
conn.options.db // =0; conn.options always contains the *initial* connection options
conn.select(1)
conn.options.db // =0; still 0 even though we changed DBs

conn.condition.select // = 1; this seems to contain the DB I'm connected to.

// I'm still not convinced, how can we confirm what DB I'm connected to?
conn.flushall() // !!! CAREFUL !!!
conn.set('key', 1)

/*
...
# Keyspace
db1:keys=1,expires=0,avg_ttl=0 // I wrote to DB one!
...
*/

The workaround I currently have is to add the options object to the connection config.
i.e.
host: RESQUE_HOST,
port: parseInt(RESQUE_PORT, 10),
-database: parseInt(RESQUE_DB, 10),
+options: {
+  db: parseInt(RESQUE_DB, 10),
+},

this will do the db select before the promise is resolved.
I dug a little bit into ioredis. There is no good way of looking up what db you're currently connected to.
.options.db is stored locally upon instantiation
.condition.select is stored locally and is changed when .select() is called
The main issue is, .select(1) returns a promise, so .condition.select could be 1, but the server hasn't switched over the db yet.
In lib/connection.js:27 connect() returns before this.listeners.connect is called on line 43.
In my project, I was using NodeResque.Queue() to grab the names of the queues and NodeResque.MultiWorker() to create the workers. Even though I was using the same config (database: 9) for both. I was getting the queue names from DB 0 and registering the workers on DB 9.

Would you mind submitting a PR with a version of your changes, only if the redis package used is ioredis?  If we can choose the DB at connection time, we should!

Sure! I'll work on it tonight, should be a small change.


Remove npm modules: grunticon, svgmin, volo & curl

No longer needed and grunticon is pretty "heavy" module to ask others to install.

Looks harmless enough, checked out PR and it ran fine... after i blew out node_modules/ and did did a fresh npm install.
I do not believe it's related, but I'd prefer another person with more node experience try this as well.
Perhaps @tweettypography or @swilliamset  ?

@swilliamset says to merge, so i shall.

Fixes #1102.


APT source whitelist request for ubuntu-elisp PPA

This replaces travis-ci/travis-ci#3802.
The original text by @lunaryorn follows

The PPA is at ppa:ubuntu-elisp/ppa.  It provides snapshot builds of GNU Emacs' trunk, which many Emacs packages use to test against Emacs trunk to be prepared for the next major release of GNU Emacs.

:+1:

Please consider merging this, it replaces ppa:cassou/emacs which is deprecated and should not be supported.


[kueuectl] Add resume ClusterQueue command

What would you like to be added:
Add resume ClusterQueue command on kueuectl.
Why is this needed:
To resumes admission inside the specified ClusterQueue.
Design details https://github.com/kubernetes-sigs/kueue/tree/main/keps/2076-kueuectl#resume-clusterqueue.
Completion requirements:
This enhancement requires the following artifacts:

[ ] Design doc
[ ] API change
[x] Docs update

The artifacts should be linked in subsequent comments.

/close


⚠ Bofrost.fr has degraded performance

In 89f1906, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1068 ms

Resolved: Bofrost.fr performance has improved in aa8f68b after 13 minutes.


pulsar golang error

when client connect pulsar broker:
Describe the bug
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::bad_function_call> >'
  what():  call to empty boost::function

OS: ubuntu16.04
golang: 1.11

@chowyu08 any more context about this issue?


qa: fix F401 (unused import)

Not importing pkg_resources should be beneficial with regard to
startup performance.

Codecov Report

Merging #336 into master will decrease coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #336      +/-   ##
==========================================
- Coverage   93.69%   93.69%   -0.01%
==========================================
  Files         133      133
  Lines        4158     4155       -3
  Branches      417      417
==========================================
- Hits         3896     3893       -3
  Misses        167      167
  Partials       95       95

Coverage decreased (-0.003%) to 95.86% when pulling a1b8ae6bcc59b8202c5ad5a376c667601852295e on blueyed:fix-F401 into 9a239b20be279324ced3b34ed71f84a63edfd4fb on Kuniwak:master.


[Chore] Bump version to 3.10.0

Sorry @nimblehq/android-chapter, I just realized that it should be 3.11.0
I forgot to update the version in the code for the previous release 🙇
I'll make a note to find a way to auto-create a PR for bumping the version, after a release 💭


Behavior of anchor tag on v0.10.x

Describe the bug
When migrating to v0.10.x, realized that the achor tag  doesn't have the same behavior as on v0.9.x. It's not doing a server call as expected. Seems like  is just working as .
For example, I was counting on a GET request Logout to do a logout on the server.
Your Example Website or App

Steps to Reproduce the Bug or Issue
Create and click an  tag
Expected behavior
Expected  tag to do a server call
Screenshots or Videos
No response
Platform

OS: Linux
Browser: Chromium
Version: 119.0.6045.199

Additional context
No response

Try Logout or see explicitLinks in README


feat(chrome_extension): Add DOM changes to Database (Pipe -> Write)

Add DOM changes to Database (Pipe -> Write)
What kind of change does this PR introduce?
This PR has the Chrome Extension Working which logs document's Outer HTML and Inner HTML.

Summary

Checklist

[ ] My code follows the style guidelines of OpenAdapt
[ ] I have performed a self-review of my code
[ ] If applicable, I have added tests to prove my fix is functional/effective
[ ] I have linted my code locally prior to submission
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation (e.g. README.md, requirements.txt)
[ ] New and existing unit tests pass locally with my changes

How can your code be run and tested?

Other information

Some Notes regarding Chrome Extension: _https://docs.google.com/presentation/d/106AXW3sBe7-7E-zIggnMnaUKUXWAj_aAuSxBspTDcGk/edit?usp=sharing_

Blocker Error in backgroud.js service-worker console:

I have tested the namepipe library in different ways:

try bidirectional (duplex) binary pipe (simulatneuosly writing and reading)

From this I learnt that, it needs to use open (<piep.path>) got the client (pong.py) to get the access to the pipe.

Try ping.py for 'wt' and pong.py 'rt': (both use  NPopen)
This time in pong.py it gives the following error:

    self._pipe = win32pipe.CreateNamedPipe(
pywintypes.error: (5, 'CreateNamedPipe', 'Access is denied.')

This means that ping can NOT access the pipe when the other process is using.

Update: resolved using sockets

Closed in favor of https://github.com/OpenAdaptAI/OpenAdapt/pull/364


Ways to mark a method which promises to throw on a null argument

Our overarching design direction is to capture nullness data through types alone, and have those types work as analogously to base types as possible.
This gives us most of what we need, but a few things are missing.
One is: if a method actually promises it will not complete normally upon null input (or maybe more specifically promises to throw NPE?), that is valuable knowledge to capture somehow, and our current annotations don't provide for it.
Oddly, all four combinations are valid between this and @Nullable itself. Some methods like Double.valueOf could make this promise for a non-nullable parameter. But our friends checkNotNull and the like want to make this promise for a nullable parameter!
A checker can use this information. Particularly, for the checkNotNull case, it would then be able to "learn" that the type of a variable becomes non-nullable below the place where it was passed to that method. This is the main motivating case I think.
I believe that the various worries some of us had about checkNotNull being nullable can be addressed this way instead (and it will be nullable).

As a note, the way NullAway handles this is to support a subset of JetBrains's @Contract annotations. In particular:
@Contract("null -> fail")
public Object checkNotNull(@Nullable Object o) {...}

I imagine there will be some hesitancy to make JSpecify dependent on something like JetBrains's @Contract, particularly since even in NullAway we handle only a subset of its contract specifications. But, at the same time, I want to note that contracts over nullness are generally useful, beyond "if the Nth argument is null, method fails".
For example, we regularly see usage of the following specs:
@Contract("!null -> !null") // Usually for methods that return their argument after operating on it.
@Contract("null -> true") // This can be understood as implying arg != null when `false`... e.g. Strings.isEmpty(...)
@Contract("null -> false") // Converse of the above (implies arg != null when `true`).

Wonder if we want something like @ThrowsOnNull(arg#N) here (for minimality), or something more general along the lines of these @Contract annotations (to cover more common use cases).

Good point about @Contract vs. individual annotations.
I'm going to predict that @kevinb9n will propose keeping this thread focused on the question of whether "promise to throw NPE" is a requirement, with the discussion of the "API" in a separate issue. Maybe we should start that thread now, along with other threads for the other possible requirements. Kevin?
(For searchability: In CF terminology, we're talking about (part of) @EnsuresNonNull. A possible future thread could cover @EnsuresNonNullIf. Yet another possible future thread could cover the fact that CF lets those annotations tell you about other methods, as in "if hasFoo() returns true, then getFoo() returns non-null." And there's already a thread about @PolyNull, including some thoughts that I should flesh out someday about why I lean toward a separate annotation over a @Contract annotation for that.)

If this is two separate questions:
a) Should there be a JSpecify mechanism to mark a method as throwing an exception when passed null, even though @Nullable is the accepted argument type at compile time?
and
b) What should that mechanism look like?
Then my take on (a) is unambiguously that there should be. Tools already have different ways to handle this case, showing that it matters in practice, and it does happen at the interface between clients and libraries, which suggests that we might want a uniform way to handle it across tools. Certainly not a 1.0/MVP requirement, but seems well within scope of JSpecify.
My take on (b) is less clear. NullAway uses @Contract primarily for this purpose. I like @Contract("null -> fail") over @EnsuresNonNull("#1") mostly on account of it being more readable as documentation (the second option requires you to reason "the method must guarantee the argument is non-null on successful termination, Java passes arguments by reference, ergo the only option left to the method to implement the semantics is to terminate with an exception if the argument is null on method entry"; the first can be read "if passed null, this method fails"). Also, as mentioned above, the pre/post syntax of @Contract can cover a few other cases with static checking (thought I think all those listed could also be covered by a version of @EnsuresNonNullIf that allows for result to be an enum of FALSE, TRUE, NULL, NONNULL instead of just a boolean).
On the other hand, NullAway does implement a version of @EnsuresNonNull and @RequiresNonNull for fields, since the JetBrains @Contract strings make it harder to implement per/post conditions on fields. We have given some thought to having a generalized version of @Contract that covers both arguments and fields, and we lean towards it being contract-like because of the readability argument above, but we could switch over to ensures/requires style if it can cover the @Contract("!null -> !null") case too, which we have found extremely common.

I think it's probably fair to treat the @Contract mini-language as a "bridge too far" for this project for the foreseeable future. That could change, say, if two different tool owners start pushing that plan forward of their own motivations.
Of course every checker should be absolutely free to respect any other @Contract annotation it wants to, putting that information together with what it learns from JSpecify annotations. I think that is what winning looks like. (There are limits; analysis should only refine types, not go the other direction, so once any source determines something to be non-null there probably shouldn't be a way to say no cancel that.)

Could it possibly be worth even adding to non-nullable arguments (Double.valueOf(s))? Knowing the method can be trusted to do a runtime check could be theoretically worth something, but it changes the situation drastically if this is going to start popping up everywhere. And it would be dodgy to put this on a non-final or @Override method.

It seems like this might be too special-case to worry about, but I do think a lot of teams have cloned versions of something like Guava Preconditions (hey, even I know it would be silly to depend on Guava for only that), so a checker could never hard code them all, and those methods end up having a lot of usages so the benefits would multiply.

(I believe this annotation does not want to dictate what exception type has to be thrown. All that matters is that the method will not complete normally in that case.)

My 2¢:

It's valuable for a tool to support some form of contracts as it improves the fidelity of the analysis and its UX.  Our internal tool supports JetBrains' @Contract annotation. We actually went as far as adding a small specialized SMT solver which handles @Contract and other kinds of inference problems.
Would it be great to have a unified contract definition language that would work both for Java and Kotlin (unfortunately, @Contract doesn't work in Kotlin)? Yes!
Should we make some contracts relating nullness and runtime behaviour a part of JSpecify spec? Hm... not that obvious.

Types cover some aspects of run-time behaviour but not all. Exceptions in Java are the norm so potentially all methods can throw and the question of the return type of the method is orthogonal to the question of whether the method will actually return the value at all.
The information that "the method throws on null" is probably of the main interest in the implementation code and probably with regards to flow sensitive type refinements. As far as I remember the original focus of JSpecify was on the API surface.
Where do we draw the line between what types of "contract" we want to make first-class citizen and what won't make the cut? Is it only checkNotNull types of contract? How about checkState? How about Objects.null/nonNull - when combined with conditionals they also provide important information?

I guess, for me the main question is: do we feel that the presence of this marker annotation is essential for completeness of JSpecify's basic nullness semantics?
I can say that in out internal code the number of methods that actually require a contract like checkNotNull is a rounding error, so I'm not really sure whether it should be a part of JSpecify's core package.

The information that "the method throws on null" is probably of the main interest in the implementation code and probably with regards to flow sensitive type refinements. As far as I remember the original focus of JSpecify was on the API surface.

Well, yes and no. Annotations you put in your file only to benefit that file itself have less need to be standardized. It is annoying when you and your teammate prefer different tools, but you could at least just agree on one. Annotations you put in your file for the benefit of dependent files (which basically is why we're talking about the APIs) are different and you do need a standardized answer.
If checkNotNull-type methods in released libraries were a really common thing then this would justify why we need a resolution to this issue. But, they probably shouldn't be, so maybe we can just pass around a hardcoded config file to each other.

Where do we draw the line between what types of "contract" we want to make first-class citizen and what won't make the cut? Is it only checkNotNull types of contract? How about checkState? How about Objects.null/nonNull - when combined with conditionals they also provide important information?

Indeed.  Annotations seem to make it easier to just go one by one.
Maybe "drawing the line" is like this?: if at least two different tool owners feel motivated enough to add/support the annotation themselves, then better standardize it?

I guess, for me the main question is: do we feel that the presence of this marker annotation is essential for completeness of JSpecify's basic nullness semantics?

Yeah I do think this question is why it's been labeled post-1.0.

I can say that in out internal code the number of methods that actually require a contract like checkNotNull is a rounding error, so I'm not really sure whether it should be a part of JSpecify's core package.

(As noted above, maybe the value scales with the # of calls to those methods though. Except that the most popular such methods would be the ones checkers are hardcoding anyway.)

Except that the most popular such methods would be the ones checkers are hardcoding anyway

Yes. I guess the TL;DR: of my comment is that: since people usually don't roll out their own checkNotNull (IOW there's a small number of existing methods), checkers hard-code support for these, and the semantics is really straightforward here (= no divergence between checkers), I struggle to see the added value of standardising this one annotation.
On the other hand, if we do end up standardising whatever @FailOnNull annotation we come up with (an imaginary example below):
public <T extends Object> T checkNotNull(@FailOnNull @Nullable T)

Supporting it will take us a couple LOCs, so no big deal. But also I don't think it'll allow us to remove any of the hard-coded configs we already have; at least in the foreseeable future.

Makes sense and imho this is the right way to think.
I think leaving this open but tagged Post-1.0 seems appropriate. We could further have distinct labels for "core nullness" vs "non-core nullness" or something, but for now, seems good.
(I sometimes comment on non-1.0 issues but I do spend most of my "what to do next" time looking at a 1.0 view.)
When it comes to eliminating hard coding, just for the remaining hardcoded lists to "feel like they have an expiration date" would be a good state to reach, even if a very distant one.

(nothing exciting here; just cross-referencing discussions and recording a false start in my thinking)

I believe this annotation does not want to dictate what exception type has to be thrown.

https://github.com/jspecify/jspecify/issues/309#issuecomment-1301198808 is a reminder that there's at least one family of common methods that throw something other than NullPointerException in this case. (I'm pretty sure that something Charset-related does, too.)
I want to say that the Checker Framework does dataflow based on specific exception types. But after all of 30 seconds of thought, I'm not sure that it could actually benefit from knowing the specific type of exception that is thrown in case of a null argument:
Suppose that an argument foo has a @Nullable type and that a method call bar(foo) is known to throw SomeException when its parameter is null. That still doesn't prove anything about foo inside a catch (SomeException e) block or inside any other catch block. (And inside the try, we already know it's non-null after the call, regardless of what type would have been thrown.) If we knew that a method could throw SomeException if and only if a parameter were null, then we might be able to get somewhere. But I would expect the value of that additional information to be minimal, and it might well be more than offset by people who use that annotation when "if and only if" does not hold.

Given the amount of time it takes to annotate a library for nullness, and given that we'd ideally want the annotation discussed here to be enforced by tools, and given the amount of noise it would introduce to put @MethodThrowsIfNull on a ton of parameters (or the inconsistency if we don't use it everywhere it makes sense)[*], I explicitly do not want to advocate for designing this anytime soon. But I do want to make a note while it's on my mind:
One of the challenges we're facing now is how to update Kotlin code that would fail to compile after we add nullness information. For example, once Kotlin knows that a method parameter has a non-nullable type, it won't let us pass nullable values anymore. The obvious solution is to add !! to each such argument. But that preserves behavior only if the method was going to throw NPE (or if the argument is never null in practice). And while that's very often the case, it's not the case if someone declares a SettableFuture<Foo> and then tries to call set(null) on it: The right solution there isn't to write set(null!!) but rather to change to SettableFuture<Foo?>.
Anyway, my point here is that it would be convenient if our tooling knew that set(null) would not trigger an immediate NPE but that (say) ImmutableList.of(null) would.
[*] We could make the annotation burden less bad by having a @NullMarked-style "defaulting" annotation. But that leads to get more design questions: Presumably the annotation applies all non-nullable parameters... and presumably there's a way to override it for individual parameters that don't follow the class's usual behavior.... Do we end up with a system of 4 annotations just for this purpose? But I'm really not trying to design this now, just trying to note that the design would be non-trivial.

@cpovirk I can't speak to Kotlin, but don't think the majority of Java projects would need to write this annotation at all; they could rely on standard nullability annotations. But I agree with kevinb9n that:

A checker can use this information. Particularly, for the checkNotNull case, it would then be able to "learn" that the type of a variable becomes non-nullable below the place where it was passed to that method. This is the main motivating case I think."

I think annotating the Java standard library and the most-used utility libraries like Apache Commons, Guava, etc. would provide 99% of the potential value of this annotation. Applications and non-utility libraries wouldn't have to annotate their APIs with it, but would still benefit from consuming libraries that do.

@Mooninaut is right that a good portion of the checkNotNull in the world are hard coded in some systems and for good reason.
For example in Eclipse:
@Nullable Object o = ...;
Objects.requireNonNull(o); // no assignment back to o
out.println(o.toString()); // Eclipse and most know that o is now nonnull.

Ditto for assert.
But if you write your own requireNonNull it does not work (well unless you do assignment back).
For other use cases I'm not sure I understand other than general bug prevention which seems out of scope for JSpecify.

I agree that most of the value is tied up in recognizing very common methods like Objects.requireNonNull so that examples like https://github.com/jspecify/jspecify/issues/226#issuecomment-1674839970 work.
After that, the next most important thing is likely the ability to specify that com.mycompany.Checks.throwIfNull should be treated similarly. (As discussed above, this ability already exists in NullAway and in the Checker Framework. We might not have yet mentioned the similar Kotlin feature, contracts, which I believe is still experimental.) I don't personally have a feel for exactly how important that is: Even if you need 3 different tools to recognize your com.mycompany.Checks.throwIfNull method, it's still not necessarily intolerable to have to write 3 different annotations on it, given how rarely this comes up in comparison to annotations like @Nullable. Plus, it's worth remembering that mere annotations are unlikely to handle cases like assertThat(foo).isNotNull() or checkState(foo != null), and so there may always be a place for hard-coding of particular APIs and call patterns.
The alternative use case that I was discussing in https://github.com/jspecify/jspecify/issues/226#issuecomment-1650287729 would have some value to the migration we're currently doing. But it's likely that we can get a lot of the value there by hard-coding specific APIs, too. Now, if we envision a future world in which lots of people need to automatically update lots of Kotlin code to "suppress" its nullness errors, then there might be more cause for an annotation for that use case. But it's possible that we can still get most of the value from hard-coding, and we may be able to get some of the remaining value from analyzing the source code or bytecode of the methods to identify those that obviously throw NPE for a null input.

I can't decide if this is tangental or relevant as I'm less familiar with this area but many of the checkNotNull / requireNonNull vary on annotations so I guess I see value here on that regard.
See checker unlike most others has Objects.requireNonNull as a @NonNull parameter. The idea being that it is just an extra check like an assert. This is partly because checker wants to avoid NPE a little too aggressive in my opinion as you might just be replacing NPE with some other exception.
I and I think many others use requireNonNull as a casting mechanism as it is more or less the only builtin JDK option for doing something like that. I think Checkers argument is very valid though. (btw IIRC the jspecify jdk is annotated @Nullable for this).
I guess what I'm getting at or realizing is that there or more use cases and interpretations of these kinds of methods:

casting - edge or boundaries... it could be null and we want to fail with the most obvious exception (we also want the checker to move on and be happy... sort of like removing the parameters from a generic). One argument against these guys is they should not be throwing NPE.
asserting - It should be nonnull and you are just doing defensive programming. The argument against these guys is unlike range checks in arrays nullity can be proven at compile time.
contractual - you might even be expected to catch the NPE or some other exception

The last one I consider pretty fringe. I guess my question is what group is under discussion here for say google's (insert other ... I don't know kotlin that well)?
My repeating concern of JSpecify and in general is consensus on annotating libraries because arguably even JSpecify could make requireNonNull @NonNull.

I don't know if this will serve as much of an answer, but maybe it gives you an idea of where at least one person's head is.
I've found it clarifying to have multiple nullness analyzers in mind. (I think I've heard it said that you don't have a standard unless you have multiple implementations :)) Google uses a few in different places, but the ones I'm most familiar with are the Checker Framework and Kotlin.
One thing that's stuck out to me about Kotlin is the idea that nullness-augmented types can be made to be "real runtime types": If you have a Kotlin function that declares a non-null parameter, then the Kotlin compiler will automatically insert a runtime check at the beginning of that method's implementation, throwing NullPointerException if it sees null. (Compare to how the JVM will give you a ClassCastException if you manage to sneak the wrong kind of object into a method parameter.) As a result, if you want Java's requireNonNull to be able to throw a NullPointerException with the message you provided (instead of the automatic NPE with a generic message), or if you want JUnit's assertNotNull to be able to actually throw an AssertionError (instead of the automatic NPE), then you'd need to declare the parameter as having a nullable type—if it were written in Kotlin, or if you applied bytecode rewriting to add automatic null checks to Java (as at least one plugin does), or if a future version of Java were to insert such checks for any built-in nullness support it might have. (And even today, Kotlin makes it very difficult to pass null even to a Java method that it annotated as not allowing it.)
(Given that, and given a few historical discussions (which include discussion of your "casting" use case), I'm comfortable stating that requireNonNull will keep the @Nullable annotation that we currently have on it.)
Compare also similar cases in which null is not always safe, like Collection.contains(null). The Checker Framework philosophy is to make the parameters as non-nullable to avoid NPE; the Kotlin philosophy is to make them as nullable so that you can pass null in the cases in which you need to. (This would probably fit into your group 1, including the part about how they arguably shouldn't throw NPE at all.)
And yes, group 3 is pretty weird—things like "This Comparator should throw NPE so that code like AbstractSet.equals can catch it."
One way to support both tools better is to support https://github.com/jspecify/jspecify/issues/113 in the future. Then we could say that a method like Collection.contains has a @Nullable type but might still throw if you pass null, and tools can respond accordingly.

(more on some of those topics in https://github.com/jspecify/jspecify/wiki/nullness-borderline-cases and in the nullness design FAQ under "How are we supposed to eradicate NullPointerExceptions if even a method with all nullable parameters is still allowed to throw it?.")

Dumping one other note for the future:
Caveats:

This is a different use case.
We hope that we can continue to address that use case in a different way for a long time.
We still don't know whether we'll ever add the annotation under discussion here.

One unfortunate fact about the Java Collections API is that sometimes we have methods like Collection.contains(@Nullable Object e), for which many implementations tolerate null inputs (including by returning false if the implementation doesn't support nulls) but some throw NullPointerException. Our approach to that so far has been to annotate Collection.contains as above but to annotate overrides of that method as @Nullable or not to express whether they throw an exception or not.
(IIRC, there is another complication here, which is that some implementations don't override all the relevant methods themselves, so there is sometimes no method for us to annotate. Oh, and plus, users often declare a field or local variable to hold a general type, like Collection or List, rather than the specific one with the more precise annotations (though there are exceptions, like ConcurrentMap). But setting that aside....)
This works because, even though checkers are likely to produce errors for an override contains([@NonNull] Object e), users can suppress those. (Or they can just not use a nullness checker on that code.)
(Hmm, I'm suddenly remembering that there was also a philosophical discussion about all this :))
But we can imagine cases in which a language might be stricter about such things. If so, we'd really like for the superclass and subclass to agree. And "clearly" they need to agree on @Nullable.
But then users of the null-rejecting subclasses get no protection against NPEs.
So what if we were to annotate them as contains(@ThrowsOnNull @Nullable Object e)?
But would that even help most users? If we expect users to want to pass nullable values to other methods that are annotated in the same way (like checkNotNull), then it's unlikely that users will want to see errors for such calls. And thus they still won't get errors for dangerous calls to contains.
So I think this goes nowhere. But I wanted to write it down while it was fresh in my mind.

@cpovirk That leads to the question of when you hit diminishing returns on finer and finer-grained single-purpose annotations and increasing returns on @Contract (or something like it).

@cpovirk I wonder when we hit diminishing returns on finer and finer-grained single-purpose annotations and increasing returns on @Contract (or something like it).

#454
There may be stuff about this I couldn't find to link in. Didn't find an existing issue dedicated to it.

Current decision: This feature is not required for JSpecify 1.0.
Proposal for 1.0: Finalize the current decision. If you agree, please add a thumbs-up emoji (👍) to this comment. If you disagree, please add a thumbs-down emoji (👎) to this comment and briefly explain your disagreement. Please only add a thumbs-down if you feel you can make a strong case why this decision will be materially worse for users or tool providers than an alternative.


gRPC support

Ran into some issues. Will work on this once tonic updates axum to 0.7, which will align axum to the version we use, which should allow us to do router.into_router() to convert a tonic router to an axum router.

This is likely going to require some minor API changes. Moving to 0.3 milestone

TBD if using router.into_router() is a good/correct approach. It might be good in order to share middleware, but I’m not sure if there are any downsides.


NP Large tensor tests batch 5

Batch 5 of large tensor tests.

Can you also paste the run log of these tests ? I have left few comments regarding reducing no. of variables to reduce memory used

Thanks for reviewing!


fix: add flex-wrap to breadcrumb list

Summary
Add a flex-wrap to the breadcrumb ol
Type

Bug

Summarise concisely:
What is expected?
on mobile device, the breadcrumb should be wrapped gracefully
Relevant logs and/or screenshots

Page
Before
After

url

The CI is failing also cause the snapshots are not up to date also, you can run pnpm run test:unit -u and push the generated file 😄

Everything is green @rachidBensaid I'm merging your PR 😄


OperationFuture: use exponential backoff in polling schedule

Also consider an initial wait period that is relative to the size of the input (would be API-specific).

Exponential backoff is important for the speech API.  Our long-running operations can be very long running (potentially > 1 hour) so it is very inefficient to poll 1s per second.  We have quotas for abuse preventation and polling thousands of times will cause quota issues for users.

Marking as blocking beta for Speech.

Oh, we don't have the specific API labels in gax-java. Oh well.

.NET has the same issue - our LRO polling is constant-delay, which feels appropriate to me. The default delay is once every 10 seconds, across the board - it's possible that we should work out a way of letting each service specify a default.
Exponential backoffs typically have upper bounds, and I'd expect to reach that upper bound pretty quickly for speech - polling once per minute would mean only polling 60 times for an hour-long operation, which doesn't seem unreasonable to me... whereas a truly-exponential backoff could easily end up keeping the user waiting for half an hour longer than necessary.
Basically, I think we could do with more discussion of this, ideally thinking about other LROs beyond speech, too.

It is reasonable to poll once per minute if the operation is about 1 hour. But it would be wasteful if the operation is longer (e.g. 10 hours). It looks reasonable to use constant delay as default for LRO (10 seconds interval sounds reasonable to me). To support cases such as Speech which requires exponential delay, we can add some gapic config fields to allow these APIs specify the default (exponential delay, upper bound).

It's still not clear to me that Speech really requires an exponential delay - and any exponential delay is likely to have an upper bound anyway. Exponential delays are much more complicated to explain to users, and I really don't see the benefit.
The cost of polling once a minute (the rate I suggest for speech, with other APIs being different) is very small compared with what I'd expect the compute cost of the actual LRO to be.

Worth noting that the current linear delay can have a custom minimum, multiplier, and maximum; it would be pretty easy to set a one or two minute maximum for Speech. (The default is 30 seconds, incidentally, which is not horrifically unreasonable for a one hour LRO.)

Fixed interval polling is probably OK as long as you don't poll more than once a minute.

Given that fixed interval polling is ok, I'm removing off the blocking label.

This should be fixed by: https://github.com/googleapis/gax-java/pull/195
Close this issue for now. Feel free to reopen if we need exponential backoff in the furture.

Reopening, as exponential backoff with a cap would still provide value for shorter requests.

Completed


Graceful termination

We had some asyncio handlers on signals to do a graceful termination. In the current state however they cause the worker to purely ignore signals as asyncio cannot stop a running sync galp step, even if it is pure python. Removing them allows simple (ungraceful) termination, although the problem would resurface with compiled tasks that never yield back to the interpreter. Most of our use cases are numpy programs with many yield points however so it is not as urgent.
In general we cannot rely on a step doing any kind of cooperation. So the safest way is probably to run steps in separate threads, this way the main thread would have a chance to stay responsive to signals (and galp messages at the same time) during a step. This makes running steps harder since we now have to handle non-cooperative mt with the main thread, so we keep it for later.
Finally, we do not yet really use graceful termination. A use case would be to notify peers that we are quitting (e.g. the worker should tell the broker it's quitting and to remove it from the list of available workers, else the messages would simply be lost), but for now we have not started implementing any of that, so we'll do with ungraceful termination.

Replaced with #96, we're actually moving the other direction: on signals we may have to kill the worker if it's waiting in subpython code, so it's the other way around: the worker should be safe to kill at any point and never require any clean-up.


Accessing slider elements

As mentioned in #69 I need to make the slider WCAG 2.0 Level A compliant.
Unfortunately the slider allows tabbing with a keyboard through slides that are not visible on the screen, which breaks the Meaningful Sequence requirement. Therefore I would like to hook into the $EVT_PARK event and perform the following operations:

On all a elements of each slide set tabindex=-1 so that they cannot be focussed with the keyboard
On all a elements in the current slide set tabindex=0 so they can be focussed with the keyboard

The event passes in slideIndex but I can't find a way to access the slide DOM elements themselves. Either the current slide passed into this event, or a way of accessing something like _SlideElmts would work. Note I am using the non-jQuery version.
Is there a way to do this?

            function SliderParkEventHandler(slideIndex, fromIndex) {
                var slideElement = document.getElementById("slide_" + slideIndex);
                var anchorElements = document.getElementsByTagName("A");

                for (var i = 0; i < anchorElements.length; i++) {
                    anchorElements[i].setAttribute("tabIndex", 1);
                }
            }

            jssor_slider1.$On($JssorSlider$.$EVT_PARK, SliderParkEventHandler);

Thanks for that great code snippet. I wasn't setting IDs on the slide elements so my brain wasn't working in that way but now I can see your point. Unfortunately i've applied your approach and still have problems.
In the below code snippet I set all anchors to have tabindex=-1, then update all anchors in the current slide element to have tabindex=0. The former works correctly but the latter does nothing, all anchors stay with tabindex=-1. I've tried in IE and Firefox with two different approaches (you can see one of them commented). Hopefully I've made some dumb mistake that will be obvious to you. I have some concerns that it will work as there seems to be a copy of the slider elements in the DOM so therefore the IDs are not unique - maybe it is picking up the wrong one? Anyway, I value your advice:
aquanetSlider.$On($JssorSlider$.$EVT_PARK, function (slideIndex) {
	var anchorElements,
		slideElement,
		anchorIndex,
		anchorElement;

	console.log('PARK: slideIndex=' + slideIndex);

	anchorElements = aquanetSlider.$Elmt.getElementsByTagName("a");
	console.log('Number of anchorElements: ' + anchorElements.length);
	for (anchorIndex = 0; anchorIndex < anchorElements.length; anchorIndex++) {
		console.log('setting tabindex of anchor with index ' + anchorIndex + ' to -1');
		anchorElement = anchorElements[anchorIndex];
//    		anchorElement.removeAttribute("tabIndex");
//    		anchorElement.setAttribute("tabIndex", "-1");
anchorElement.tabIndex = -1;
	}

	slideElement = document.getElementById("aquanet-slider-slide-" + slideIndex);
	anchorElements = slideElement.getElementsByTagName("a");
	console.log('Number of anchorElements: ' + anchorElements.length);
	for (anchorIndex = 0; anchorIndex < anchorElements.length; anchorIndex++) {
		console.log('setting tabindex of anchor with index ' + anchorIndex + ' in slideIndex ' + slideIndex + ' to 0');
		anchorElement = anchorElements[anchorIndex];
//    		anchorElement.removeAttribute("tabIndex");
//    		anchorElement.setAttribute("tabIndex", "0");
anchorElement.tabIndex = 0;
	}
});
```javascript

I tested on ie, firefox and chrome. It works OK.


[incubator/hoverfly]: Add Openshift Route Creation for Admin & Proxy Interfaces

Is this a new chart
No
What this PR does / why we need it:
This adds the ability to create Openshift routes for the Hoverfly admin and proxy interfaces
Which issue this PR fixes
N/A
Special notes for your reviewer:
N/A
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

cc/ @tommysitu

LGTM

/ok-to-test

/approved

/lgtm

/approve

Just FYI...
Openshift has a support for Ingress objects, too.
Openshift will just convert the object to a route internally which remove the requirement to maintain an ingress object and an openshift route object at the same time.
https://docs.openshift.com/container-platform/3.11/architecture/networking/routes.html#architecture-routes-support-for-ingress


api post for handling data type payloads, e.i. Virtual Data Source and Virtual File System

Created a new method in async_handler to process the posts that are list independed. Not batching is required and the data argument is of type any. Usefull for virtual data source and file source endpoints where the payload is just a string of jsonl, newline delimited objects.

Thanks @ignaszewskir!

Can you please add the comment you posted above as a comment to the new async method that you created so that it helps us remember why we created this one when we take a look at the code in a few months' time?
Since you submitted your PR, the PR that covers returning the full job details for async methods has been accepted. Can you please adjust the code for your new async method to return the job details instead of the boolean value?

Let me know if you have any questions.

@diethard-at-alation Hey Diethard. I have made the changes you recommended. Please verify and approve.


Specifying templateFiles on the RenderTemplate call

Hi
I am running the helm_basic_example_template_test. Works fine. But if I do not specify any templateFiles on the RenderTemplate call, then the test fails. If no templateFiles are specified I would expect all templates to be rendered.
output := helm.RenderTemplate(t, options, helmChartPath, releaseName, []string{})
var deployment appsv1.Deployment
helm.UnmarshalK8SYaml(t, output, &deployment)
require.Equal(t, namespaceName, deployment.Namespace)

This returns the following. It's as though the deployment variable is not getting set.
minimal_pod_template_test.go:65:
        Error Trace:    minimal_pod_template_test.go:65
        Error:          Not equal:
                        expected: "medieval-fm1fsj"
                        actual  : ""

Should it be possible to render all templates?
Thanks

Unfortunately, this doesn't work because the yaml library we are using (ghodss/yaml) doesn't support unmarshaling multiple objects. Supposedly go-yaml has better support for this, but I am not sure how that works (e.g., does it try each object against the schema? what if there are multiple? does it return the first match?).
I think we need a bit of design work here to figure out the API for unmarshaling when helm returns multiple rendered objects. The ideal interface is probably something like:
func UnmarshalK8SObjectsToYAML(t *testing.T, renderedBytes []bytes, objectMap map[string]interface{})

where objectMap is a map from resource name to the actual object to render to. Then, the implementation should do two passes to unmarshal:

For each document, grab the name metadata field and see if the key exists in objectMap.
If the key does not exist, skip the document.
If the key does exist, unmarshal to the object pointer value for that key.

I've gotten this working with a bit of code from the kube libraries and goyaml
templates := []string{
	"templates/pachd/storage-secret.yaml",
	"templates/pachd/deployment.yaml",
}
output := helm.RenderTemplate(t, options, helmChartPath, "blah", templates)

files, err := splitYAML(output)

if err != nil {
	t.Fatal(err)
}

decodedKubeObjects := []interface{}{}

decode := scheme.Codecs.UniversalDeserializer().Decode

for _, f := range files {
	obj, _, err := decode([]byte(f), nil, nil)
	if err != nil {
		t.Fatal(err)
	}
	decodedKubeObjects = append(decodedKubeObjects, obj)

}

for _, f := range decodedKubeObjects {
	fmt.Printf("%#v\n\n", f)
}


support for CREATE / ALTER GIT REPOSITORY

Use Cases or Problem Statement
Adding support for CREATE / ALTER GIT REPOSITORY
CREATE GIT REPOSITORY
ALTER GIT REPOSITORY
Category
category:resource
Object type(s)
No response
Proposal
No response
How much impact is this issue causing?
Medium
Additional Information
No response
Would you like to implement a fix?

[ ] Yeah, I'll take it 😎

Hey @olg200492. Thanks for reaching out to us.
We are currently focusing on supporting the GA features on our road to V1 of the provider. You can check the details here: https://github.com/Snowflake-Labs/terraform-provider-snowflake/blob/main/ROADMAP.md#05052024-roadmap-overview.
We have recently refreshed our contribution guidelines (announced here: https://github.com/Snowflake-Labs/terraform-provider-snowflake/discussions/2756) and we will welcome a contribution.
For now, you can use https://registry.terraform.io/providers/Snowflake-Labs/snowflake/latest/docs/resources/unsafe_execute as a temporary workaround (please read the docs first).


ArgumentException: An item with the same key has already been added.

Hi,
I'm getting this error very often with the latest release.
We can't release our app like this because there is no way to catch that exception.
System.Exception: TaskSchedulerOnUnobservedTaskException ---> System.AggregateException: A Task's exception(s) were not observed either by Waiting on the Task or accessing its Exception property. As a result, the unobserved exception was rethrown by the finalizer thread. ---> System.ArgumentException: An item with the same key has already been added.
  at System.ThrowHelper.ThrowArgumentException (ExceptionResource resource) [0x0000b] in <filename unknown>:0
  at System.Collections.Generic.Dictionary`2[TKey,TValue].Insert (System.Collections.Generic.TKey key, System.Collections.Generic.TValue value, Boolean add) [0x0008e] in <filename unknown>:0
  at System.Collections.Generic.Dictionary`2[TKey,TValue].Add (System.Collections.Generic.TKey key, System.Collections.Generic.TValue value) [0x00000] in <filename unknown>:0
  at FFImageLoading.Work.WorkScheduler+<QueueTaskAsync>d__25.MoveNext () [0x000ab] in <filename unknown>:0
--- End of stack trace from previous location where exception was thrown ---
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in <filename unknown>:0
  at FFImageLoading.Work.WorkScheduler+<QueueTaskAsync>d__25.MoveNext () [0x002bc] in <filename unknown>:0
  --- End of inner exception stack trace ---
---> (Inner Exception #0) System.ArgumentException: An item with the same key has already been added.
  at System.ThrowHelper.ThrowArgumentException (ExceptionResource resource) [0x0000b] in <filename unknown>:0
  at System.Collections.Generic.Dictionary`2[TKey,TValue].Insert (System.Collections.Generic.TKey key, System.Collections.Generic.TValue value, Boolean add) [0x0008e] in <filename unknown>:0
  at System.Collections.Generic.Dictionary`2[TKey,TValue].Add (System.Collections.Generic.TKey key, System.Collections.Generic.TValue value) [0x00000] in <filename unknown>:0
  at FFImageLoading.Work.WorkScheduler+<QueueTaskAsync>d__25.MoveNext () [0x000ab] in <filename unknown>:0
--- End of stack trace from previous location where exception was thrown ---
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in <filename unknown>:0
  at FFImageLoading.Work.WorkScheduler+<QueueTaskAsync>d__25.MoveNext () [0x002bc] in <filename unknown>:0 <---

  --- End of inner exception stack trace ---

Thanks

@tobiasschulz Thanks for reporting this issue.
It's already fixed in git, we plan to deliver a hotfix soon. Sorry for this regression.

Ok thank you!

Hi @tobiasschulz  , it's already fixed. Just download 2.1.2 nuget.


custom styling not available

Is there any way to style the checkbox.? I need to add custom style when the checkbox is in indeterminate state.?

Custom styling is available. I've exposed className and style to the input component as props.
https://github.com/jchiam/react-three-state-checkbox/blob/master/src/Checkbox.tsx#L16-L17

but I could not change the background color of the checkbox can you guide me on this.?

You may want to try reading up on this.
https://stackoverflow.com/questions/4148499/how-to-style-a-checkbox-using-css


fix(harper-ls): change filename to -msvc from -gnu

Describe your changes
We've added some additional language support and changed our target compiler architecture. This PR fixes the broken filename and highlights this language support.

@williamboman is there anything I need to do to get this merged? I've got users who need this as soon as possible.

Just wanted to nudge again to see if there's anything I can do to get this merged @williamboman or @chrisgrieser

@elijah-potter Looks good to me, I've been using this package spec in my personal config (manually added) already: https://github.com/chrisgrieser/.config/blob/main/nvim/personal-mason-registry/packages/harper-ls/package.yaml
I think this PR not being merged isn't due to the changes, but simply due to the maintainer not being available. There are 150+ open PRs, after all. Unfortunately, I am just an occasional contributor and do not have the rights to merge anything in this repo (otherwise, I'd have done so already).

@chrisgrieser is see. That makes sense. Hopefully he sees this soon :crossed_fingers:. We've got a lot of improvements that I can't push out yet because of this.

We've got a lot of improvements that I can't push out yet because of this.

@elijah-potter If this is about a new release, then you can still go for it. People can still install harper-ls manually or via a personal mason registry (like I do). As I harper-user I am looking forward to some improvements myself 😋

Any update on this? Why doesn't the Renovate bot pick up the update from harper-ls? 🤔


Mysql Chinese messy code.

When I read a Chinese string  from mysql database I got a messy code æ˜µç§° è¯¦ç»†åœ°å.
this is my database table:
CREATE TABLE user (
    id bigint AUTO_INCREMENT,
...
    nickname varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT '' COMMENT 'The nickname',
...
) ENGINE = InnoDB
DEFAULT CHARSET = utf8mb4
COLLATE = utf8mb4_unicode_ci COMMENT 'user table';

and this is my database connect string:
DataSource: root:123@tcp(localhost:3306)/dbname?charset=utf8mb4&parseTime=True&collation=utf8mb4_unicode_ci

How to fix it? Thanks!

I think you set the table and column to ensure that the data is UTF-8, but we can try setting the database below.
ALTER DATABASE <dbname> CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Thank you @POABOB! Very strange, I have set the charset to utf8mb4 and collation to utf8mb4_unicode_ci for both of the Database and data table.  But still cannot get the correct Chinese string. Maybe there have something wrong with the version of my go-sql-driver, golang or go-zero.

The reason for this problem is that I did not set the character-set when importing data from *.sql file using the mysql command line tool, so the string in the utf8 encoding sql file had been imported into database as an incorrect format.


Added myself as a maintainer for translation

I have added myself (@mdrahiem) as a maintainer for telugu translation.

@tesseralis @ashr81 Please check and merge this PR so that I can get started. Thanks.


JSON build fails for C++ cmake

What is the issue you have?
I suspect recent changes in the library broke building JSON for C++. It worked up until a couple days ago.
I have added a code snipped of the fail below.

Please describe the steps to reproduce the issue.

Can you provide a small but working code example?

```
Downloading https://github.com/nlohmann/json/archive/HEAD.tar.gz
-- [download 100% complete]
-- The CXX compiler identification is Clang 13.0.0
-- Check for working CXX compiler: /opt/rocm/llvm/bin/clang++
-- Check for working CXX compiler: /opt/rocm/llvm/bin/clang++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Using the single-header code from /tmp/cget-16-46-27-gKybD-1/download/json-6d8d043adde8c95589f6e65e1fe228cb1f0d8419/single_include/
-- Found Git: /usr/bin/git (found version "2.17.1")
-- Operating system: Linux-4.15.0-163-generic; Distributor ID:	Ubuntu; Description:	Ubuntu 18.04.6 LTS; Release:	18.04; Codename:	bionic; Linux 9e0027017371 4.15.0-163-generic #171-Ubuntu SMP Fri Nov 5 11:55:11 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
-- Compiler: AMD clang version 13.0.0 (https://github.com/RadeonOpenCompute/llvm-project roc-4.5.0 21422 e2489b0d7ede612d6586c61728db321047833ed8); Target: x86_64-unknown-linux-gnu; Thread model: posix; InstalledDir: /opt/rocm/llvm/bin
-- Configuring done
-- Generating done
CMake Warning:
Manually-specified variables were not used by the project:
CGET_CMAKE_ORIGINAL_SOURCE_FILE

-- Build files have been written to: /tmp/cget-16-46-27-gKybD-1/build
Scanning dependencies of target doctest_main
[  0%] Building CXX object test/CMakeFiles/doctest_main.dir/src/unit.cpp.o
[  0%] Built target doctest_main
Scanning dependencies of target test-wstring
[  1%] Building CXX object test/CMakeFiles/test-wstring.dir/src/unit-wstring.cpp.o
Scanning dependencies of target test-ordered_map
Scanning dependencies of target test-regression2
Scanning dependencies of target test-unicode1
Scanning dependencies of target test-element_access2
Scanning dependencies of target test-allocator
Scanning dependencies of target test-serialization
Scanning dependencies of target test-items
Scanning dependencies of target test-diagnostics
Scanning dependencies of target test-readme
Scanning dependencies of target test-assert_macro
Scanning dependencies of target test-deserialization
Scanning dependencies of target test-disabled_exceptions
Scanning dependencies of target test-msgpack
Scanning dependencies of target test-algorithms
Scanning dependencies of target test-hash
Scanning dependencies of target test-alt-string
Scanning dependencies of target test-element_access1
Scanning dependencies of target test-testsuites
Scanning dependencies of target test-class_iterator
Scanning dependencies of target test-cbor
Scanning dependencies of target test-constructor1
Scanning dependencies of target test-constructor2
Scanning dependencies of target test-regression2_cpp17
Scanning dependencies of target test-conversions
Scanning dependencies of target test-conversions_cpp17
Scanning dependencies of target test-udt_macro
Scanning dependencies of target test-convenience
Scanning dependencies of target test-modifiers
Scanning dependencies of target test-unicode5
Scanning dependencies of target test-pointer_access
Scanning dependencies of target test-ordered_json
Scanning dependencies of target test-noexcept
Scanning dependencies of target test-to_chars
Scanning dependencies of target test-class_const_iterator
Scanning dependencies of target test-items_cpp17
Scanning dependencies of target test-reference_access
Scanning dependencies of target test-comparison
Scanning dependencies of target test-ubjson
Scanning dependencies of target test-bson
Scanning dependencies of target test-byte_container_with_subtype
Scanning dependencies of target test-capacity
Scanning dependencies of target test-class_lexer
Scanning dependencies of target test-regression1
Scanning dependencies of target test-udt
Scanning dependencies of target test-json_patch
Scanning dependencies of target test-user_defined_input
Scanning dependencies of target test-iterators2
Scanning dependencies of target test-unicode3
[  4%] Building CXX object test/CMakeFiles/test-regression2.dir/src/unit-regression2.cpp.o
[  4%] Building CXX object test/CMakeFiles/test-ordered_map.dir/src/unit-ordered_map.cpp.o
Scanning dependencies of target test-class_parser
Scanning dependencies of target test-regression1_cpp17
[  5%] Building CXX object test/CMakeFiles/test-allocator.dir/src/unit-allocator.cpp.o
[  6%] Building CXX object test/CMakeFiles/test-element_access2.dir/src/unit-element_access2.cpp.o
Scanning dependencies of target test-unicode2
[  9%] Building CXX object test/CMakeFiles/test-deserialization.dir/src/unit-deserialization.cpp.o
[  9%] Building CXX object test/CMakeFiles/test-class_iterator.dir/src/unit-class_iterator.cpp.o
[  7%] Building CXX object test/CMakeFiles/test-readme.dir/src/unit-readme.cpp.o
[  9%] Building CXX object test/CMakeFiles/test-serialization.dir/src/unit-serialization.cpp.o
[ 10%] Building CXX object test/CMakeFiles/test-constructor1.dir/src/unit-constructor1.cpp.o
[ 10%] Building CXX object test/CMakeFiles/test-regression2_cpp17.dir/src/unit-regression2.cpp.o
[ 11%] Building CXX object test/CMakeFiles/test-alt-string.dir/src/unit-alt-string.cpp.o
Scanning dependencies of target test-meta
[ 12%] Building CXX object test/CMakeFiles/test-algorithms.dir/src/unit-algorithms.cpp.o
[ 13%] Building CXX object test/CMakeFiles/test-hash.dir/src/unit-hash.cpp.o
[ 16%] Building CXX object test/CMakeFiles/test-element_access1.dir/src/unit-element_access1.cpp.o
[ 16%] Building CXX object test/CMakeFiles/test-items.dir/src/unit-items.cpp.o
[ 16%] Building CXX object test/CMakeFiles/test-disabled_exceptions.dir/src/unit-disabled_exceptions.cpp.o
Scanning dependencies of target test-iterators1
Scanning dependencies of target test-inspection
Scanning dependencies of target test-concepts
[ 17%] Building CXX object test/CMakeFiles/test-conversions.dir/src/unit-conversions.cpp.o
[ 17%] Building CXX object test/CMakeFiles/test-constructor2.dir/src/unit-constructor2.cpp.o
Scanning dependencies of target test-large_json
Scanning dependencies of target test-merge_patch
Scanning dependencies of target test-json_pointer
Scanning dependencies of target test-unicode4
[ 18%] Building CXX object test/CMakeFiles/test-diagnostics.dir/src/unit-diagnostics.cpp.o
[ 18%] Building CXX object test/CMakeFiles/test-conversions_cpp17.dir/src/unit-conversions.cpp.o
[ 19%] Building CXX object test/CMakeFiles/test-assert_macro.dir/src/unit-assert_macro.cpp.o
[ 20%] Building CXX object test/CMakeFiles/test-msgpack.dir/src/unit-msgpack.cpp.o
[ 20%] Building CXX object test/CMakeFiles/test-cbor.dir/src/unit-cbor.cpp.o
[ 21%] Building CXX object test/CMakeFiles/test-testsuites.dir/src/unit-testsuites.cpp.o
[ 22%] Building CXX object test/CMakeFiles/test-unicode1.dir/src/unit-unicode1.cpp.o
[ 22%] Building CXX object test/CMakeFiles/test-unicode5.dir/src/unit-unicode5.cpp.o
[ 23%] Building CXX object test/CMakeFiles/test-user_defined_input.dir/src/unit-user_defined_input.cpp.o
[ 23%] Building CXX object test/CMakeFiles/test-regression1.dir/src/unit-regression1.cpp.o
[ 23%] Building CXX object test/CMakeFiles/test-modifiers.dir/src/unit-modifiers.cpp.o
[ 25%] Building CXX object test/CMakeFiles/test-pointer_access.dir/src/unit-pointer_access.cpp.o
[ 24%] Building CXX object test/CMakeFiles/test-udt_macro.dir/src/unit-udt_macro.cpp.o
[ 26%] Building CXX object test/CMakeFiles/test-ordered_json.dir/src/unit-ordered_json.cpp.o
[ 27%] Building CXX object test/CMakeFiles/test-items_cpp17.dir/src/unit-items.cpp.o
[ 28%] Building CXX object test/CMakeFiles/test-regression1_cpp17.dir/src/unit-regression1.cpp.o
[ 29%] Building CXX object test/CMakeFiles/test-bson.dir/src/unit-bson.cpp.o
[ 30%] Building CXX object test/CMakeFiles/test-noexcept.dir/src/unit-noexcept.cpp.o
[ 31%] Building CXX object test/CMakeFiles/test-class_parser.dir/src/unit-class_parser.cpp.o
[ 32%] Building CXX object test/CMakeFiles/test-meta.dir/src/unit-meta.cpp.o
[ 32%] Building CXX object test/CMakeFiles/test-unicode2.dir/src/unit-unicode2.cpp.o
[ 33%] Building CXX object test/CMakeFiles/test-byte_container_with_subtype.dir/src/unit-byte_container_with_subtype.cpp.o
[ 34%] Building CXX object test/CMakeFiles/test-class_lexer.dir/src/unit-class_lexer.cpp.o
[ 34%] Building CXX object test/CMakeFiles/test-json_pointer.dir/src/unit-json_pointer.cpp.o
[ 35%] Building CXX object test/CMakeFiles/test-reference_access.dir/src/unit-reference_access.cpp.o
[ 36%] Building CXX object test/CMakeFiles/test-class_const_iterator.dir/src/unit-class_const_iterator.cpp.o
[ 41%] Building CXX object test/CMakeFiles/test-convenience.dir/src/unit-convenience.cpp.o
[ 42%] Building CXX object test/CMakeFiles/test-comparison.dir/src/unit-comparison.cpp.o
[ 41%] Building CXX object test/CMakeFiles/test-unicode3.dir/src/unit-unicode3.cpp.o
[ 41%] Building CXX object test/CMakeFiles/test-udt.dir/src/unit-udt.cpp.o
[ 41%] Building CXX object test/CMakeFiles/test-to_chars.dir/src/unit-to_chars.cpp.o
[ 42%] Building CXX object test/CMakeFiles/test-ubjson.dir/src/unit-ubjson.cpp.o
[ 43%] Building CXX object test/CMakeFiles/test-large_json.dir/src/unit-large_json.cpp.o
[ 43%] Building CXX object test/CMakeFiles/test-merge_patch.dir/src/unit-merge_patch.cpp.o
[ 44%] Building CXX object test/CMakeFiles/test-json_patch.dir/src/unit-json_patch.cpp.o
[ 45%] Building CXX object test/CMakeFiles/test-iterators1.dir/src/unit-iterators1.cpp.o
[ 46%] Building CXX object test/CMakeFiles/test-capacity.dir/src/unit-capacity.cpp.o
[ 47%] Building CXX object test/CMakeFiles/test-unicode4.dir/src/unit-unicode4.cpp.o
[ 48%] Building CXX object test/CMakeFiles/test-concepts.dir/src/unit-concepts.cpp.o
[ 50%] Building CXX object test/CMakeFiles/test-iterators2.dir/src/unit-iterators2.cpp.o
[ 50%] Building CXX object test/CMakeFiles/test-inspection.dir/src/unit-inspection.cpp.o
[ 50%] Linking CXX executable test-noexcept
[ 50%] Built target test-noexcept
[ 51%] Linking CXX executable test-byte_container_with_subtype
[ 52%] Linking CXX executable test-assert_macro
[ 53%] Linking CXX executable test-class_lexer
[ 53%] Built target test-byte_container_with_subtype
[ 54%] Linking CXX executable test-large_json
[ 54%] Built target test-assert_macro
[ 54%] Built target test-class_lexer
[ 54%] Built target test-large_json
[ 55%] Linking CXX executable test-to_chars
[ 56%] Linking CXX executable test-ordered_map
[ 56%] Built target test-to_chars
[ 57%] Linking CXX executable test-unicode4
[ 58%] Linking CXX executable test-wstring
[ 58%] Built target test-ordered_map
[ 58%] Built target test-unicode4
[ 58%] Built target test-wstring
[ 59%] Linking CXX executable test-concepts
[ 60%] Linking CXX executable test-convenience
[ 61%] Linking CXX executable test-disabled_exceptions
[ 62%] Linking CXX executable test-unicode2
[ 62%] Built target test-concepts
[ 62%] Built target test-disabled_exceptions
[ 62%] Built target test-convenience
[ 62%] Built target test-unicode2
[ 63%] Linking CXX executable test-unicode3
[ 63%] Linking CXX executable test-constructor2
[ 63%] Built target test-unicode3
[ 63%] Built target test-constructor2
[ 64%] Linking CXX executable test-capacity
[ 65%] Linking CXX executable test-unicode1
[ 65%] Built target test-capacity
[ 66%] Linking CXX executable test-unicode5
[ 66%] Built target test-unicode1
[ 66%] Built target test-unicode5
[ 67%] Linking CXX executable test-class_iterator
[ 67%] Built target test-class_iterator
[ 68%] Linking CXX executable test-hash
[ 69%] Linking CXX executable test-class_const_iterator
[ 70%] Linking CXX executable test-diagnostics
[ 70%] Built target test-hash
[ 71%] Linking CXX executable test-user_defined_input
[ 71%] Built target test-class_const_iterator
[ 71%] Built target test-diagnostics
[ 71%] Linking CXX executable test-allocator
[ 71%] Built target test-user_defined_input
[ 71%] Linking CXX executable test-items
[ 72%] Linking CXX executable test-merge_patch
[ 72%] Built target test-allocator
[ 73%] Linking CXX executable test-reference_access
[ 73%] Built target test-items
[ 74%] Linking CXX executable test-serialization
[ 74%] Built target test-merge_patch
[ 74%] Built target test-reference_access
[ 75%] Linking CXX executable test-meta
[ 75%] Built target test-serialization
[ 76%] Linking CXX executable test-algorithms
[ 76%] Built target test-meta
[ 76%] Built target test-algorithms
[ 77%] Linking CXX executable test-alt-string
[ 77%] Linking CXX executable test-testsuites
[ 77%] Built target test-alt-string
[ 78%] Linking CXX executable test-ordered_json
[ 78%] Built target test-testsuites
[ 78%] Linking CXX executable test-pointer_access
[ 78%] Built target test-ordered_json
[ 78%] Built target test-pointer_access
[ 79%] Linking CXX executable test-inspection
[ 79%] Linking CXX executable test-comparison
[ 80%] Linking CXX executable test-json_pointer
[ 80%] Built target test-inspection
[ 80%] Built target test-comparison
[ 81%] Linking CXX executable test-iterators1
[ 81%] Built target test-json_pointer
[ 81%] Built target test-iterators1
[ 81%] Linking CXX executable test-iterators2
[ 83%] Linking CXX executable test-items_cpp17
[ 83%] Linking CXX executable test-json_patch
[ 84%] Linking CXX executable test-element_access1
[ 85%] Linking CXX executable test-udt_macro
[ 86%] Linking CXX executable test-modifiers
[ 86%] Built target test-modifiers
[ 86%] Built target test-element_access1
[ 86%] Built target test-items_cpp17
[ 86%] Built target test-udt_macro
[ 86%] Built target test-iterators2
[ 86%] Built target test-json_patch
[ 87%] Linking CXX executable test-class_parser
[ 87%] Linking CXX executable test-bson
[ 87%] Linking CXX executable test-element_access2
[ 87%] Built target test-class_parser
[ 87%] Built target test-bson
[ 87%] Built target test-element_access2
[ 88%] Linking CXX executable test-readme
[ 88%] Built target test-readme
[ 89%] Linking CXX executable test-msgpack
[ 89%] Built target test-msgpack
[ 90%] Linking CXX executable test-ubjson
[ 90%] Built target test-ubjson
[ 90%] Linking CXX executable test-udt
[ 90%] Built target test-udt
[ 91%] Linking CXX executable test-cbor
[ 91%] Built target test-cbor
[ 92%] Linking CXX executable test-constructor1
[ 92%] Built target test-constructor1
[ 93%] Linking CXX executable test-regression2
[ 93%] Built target test-regression2
[ 94%] Linking CXX executable test-deserialization
[ 94%] Built target test-deserialization
[ 95%] Linking CXX executable test-conversions
[ 96%] Linking CXX executable test-regression2_cpp17
ld.lld: error: undefined symbol: std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()

referenced by unit-regression2.cpp

          CMakeFiles/test-regression2_cpp17.dir/src/unit-regression2.cpp.o:(std::experimental::filesystem::v1::__cxx11::path::path<char [14], std::experimental::filesystem::v1::__cxx11::path>(char const (&) [14]))

referenced by unit-regression2.cpp

          CMakeFiles/test-regression2_cpp17.dir/src/unit-regression2.cpp.o:(std::experimental::filesystem::v1::__cxx11::path::path<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::experimental::filesystem::v1::__cxx11::path>(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&))

referenced by unit-regression2.cpp

          CMakeFiles/test-regression2_cpp17.dir/src/unit-regression2.cpp.o:(std::experimental::filesystem::v1::__cxx11::path::clear())

ld.lld: error: undefined symbol: std::experimental::filesystem::v1::__cxx11::path::compare(std::experimental::filesystem::v1::__cxx11::path const&) const

referenced by unit-regression2.cpp

          CMakeFiles/test-regression2_cpp17.dir/src/unit-regression2.cpp.o:(std::experimental::filesystem::v1::__cxx11::operator==(std::experimental::filesystem::v1::__cxx11::path const&, std::experimental::filesystem::v1::__cxx11::path const&))

clang-13: error: linker command failed with exit code 1 (use -v to see invocation)
test/CMakeFiles/test-regression2_cpp17.dir/build.make:85: recipe for target 'test/test-regression2_cpp17' failed
make[2]: *** [test/test-regression2_cpp17] Error 1
make[1]: *** [test/CMakeFiles/test-regression2_cpp17.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
CMakeFiles/Makefile2:2065: recipe for target 'test/CMakeFiles/test-regression2_cpp17.dir/all' failed
[ 96%] Built target test-conversions
[ 97%] Linking CXX executable test-conversions_cpp17
[ 97%] Built target test-conversions_cpp17
[ 98%] Linking CXX executable test-regression1
[ 98%] Built target test-regression1
[100%] Linking CXX executable test-regression1_cpp17
[100%] Built target test-regression1_cpp17
Makefile:140: recipe for target 'all' failed
make: *** [all] Error 2
CMake Error at /usr/local/share/cmake/cmakeget/CMakeGet.cmake:142 (message):
Process failed: /usr/bin/cmake --build /tmp/cget-16-46-27-gKybD-1/build
--config Release -- -j 128
Call Stack (most recent call first):
/usr/local/share/cmake/cmakeget/CMakeGet.cmake:199 (cget_exec)
/usr/local/share/cmake/cmakeget/CMakeGet.cmake:401 (cget_install_dir)
/usr/local/share/cmake/cmakeget/CMakeGet.cmake:461 (cmake_get)
install_deps.cmake:90 (cmake_get_from)
</summary>
<!-- Please understand that we cannot analyze and debug large code bases. -->

#### What is the expected behavior?

<!-- Tell us what should happen -->

#### And what is the actual behavior instead?

<!-- Tell us what happens instead. -->

#### Which compiler and operating system are you using?

<!-- Include as many relevant details about the environment you experienced the bug in. -->
<!-- Make sure you use a supported compiler, see https://github.com/nlohmann/json#supported-compilers. -->

- Compiler: ___
- Operating system: ___

#### Which version of the library did you use?

<!-- Please add an `x` to the respective line. -->

- [ ] latest release version 3.10.5
- [ ] other release - please state the version: ___
- [ ] the `develop` branch

#### If you experience a compilation error: can you [compile and run the unit tests](https://github.com/nlohmann/json#execute-unit-tests)?

- [ ] yes
- [ ] no - please copy/paste the error message below

It seems that the compiler does not support std::filesystem, or we do not properly detect the support.
Just to make sure: can you please check the latest release 3.10.5?

It seems that the compiler does not support std::filesystem, or we do not properly detect the support.
Just to make sure: can you please check the latest release 3.10.5?

We are using clang 13 and this has std::filesystem support since I believe version 9.
I specified version 3.10.5 and the same error persists.

We use Clang 13 in the CI without issues. 🤔
The error mention
std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()

which makes no sense if the compiler has filesystem support. We use the following preprocessor checks:
        #if defined(__cpp_lib_filesystem)
            #define JSON_HAS_FILESYSTEM 1
        #elif defined(__cpp_lib_experimental_filesystem)
            #define JSON_HAS_EXPERIMENTAL_FILESYSTEM 1
        #elif !defined(__has_include)
            #define JSON_HAS_EXPERIMENTAL_FILESYSTEM 1
        #elif __has_include(<filesystem>)
            #define JSON_HAS_FILESYSTEM 1
        #elif __has_include(<experimental/filesystem>)
            #define JSON_HAS_EXPERIMENTAL_FILESYSTEM 1
        #endif

#ifndef JSON_HAS_EXPERIMENTAL_FILESYSTEM
    #define JSON_HAS_EXPERIMENTAL_FILESYSTEM 0
#endif

#ifndef JSON_HAS_FILESYSTEM
    #define JSON_HAS_FILESYSTEM 0
#endif

Can you please execute this with your compiler in C++17 mode and check which values are set for JSON_HAS_FILESYSTEM and JSON_HAS_EXPERIMENTAL_FILESYSTEM?

Hello,
I do not think this error comes from json.
Your error mentions std::experimental::filesystem which as far as I know, was the pre-standard implementation. With the following code:
#include <experimental/filesystem>
#include <iostream>

int main(int ac, char **av)
{
    std::experimental::filesystem::path p(".");
    std::experimental::filesystem::path p2("..");

    std::cout << p.compare(p2) << std::endl;
}

I get the following errors:
➜  TestClang clang++-13 main.cpp -std=c++17
/usr/bin/ld: /tmp/main-13e873.o: in function `main':
main.cpp:(.text+0x42): undefined reference to `std::experimental::filesystem::v1::__cxx11::path::compare(std::experimental::filesystem::v1::__cxx11::path const&) const'
/usr/bin/ld: /tmp/main-13e873.o: in function `std::experimental::filesystem::v1::__cxx11::path::path<char [2], std::experimental::filesystem::v1::__cxx11::path>(char const (&) [2])':
main.cpp:(.text._ZNSt12experimental10filesystem2v17__cxx114pathC2IA2_cS3_EERKT_[_ZNSt12experimental10filesystem2v17__cxx114pathC2IA2_cS3_EERKT_]+0x55): undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()'
/usr/bin/ld: /tmp/main-13e873.o: in function `std::experimental::filesystem::v1::__cxx11::path::path<char [3], std::experimental::filesystem::v1::__cxx11::path>(char const (&) [3])':
main.cpp:(.text._ZNSt12experimental10filesystem2v17__cxx114pathC2IA3_cS3_EERKT_[_ZNSt12experimental10filesystem2v17__cxx114pathC2IA3_cS3_EERKT_]+0x55): undefined reference to `std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()'
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Replacing std::experimental::filesystem with std::filesystem compiles with no issue.
Do you happen to use experimental/filesystem in your code by any chance ?

Can you please check the code from https://github.com/nlohmann/json/issues/3256#issuecomment-1007730993 and post what is detected for your compiler?

  #if defined(__cpp_lib_filesystem)
            #define JSON_HAS_FILESYSTEM 1
        #elif defined(__cpp_lib_experimental_filesystem)
            #define JSON_HAS_EXPERIMENTAL_FILESYSTEM 1
        #elif !defined(__has_include)
            #define JSON_HAS_EXPERIMENTAL_FILESYSTEM 1
        #elif __has_include(<filesystem>)
            #define JSON_HAS_FILESYSTEM 1
        #elif __has_include(<experimental/filesystem>)
            #define JSON_HAS_EXPERIMENTAL_FILESYSTEM 1
        #endif

I ran @NicolasIRAGNE  code, here is the result:
JSON_HAS_EXPERIMENATL_FILESYSTEM is 1
JSON_HAS_FILESYSTEM is 0
clang version 13.0.0 (https://github.com/RadeonOpenCompute/llvm-project roc-4.3.0 21295 f2943f684437d2c1143a56e418d29fc6b3314072)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/rocm/llvm/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.5.0
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
Found HIP installation: /opt/rocm, version 4.3.21300-5bbc51d8
"/opt/rocm-4.3.0/llvm/bin/clang-13" -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all --mrelax-relocations -disable-free -disable-llvm-verifier -discard-value-names -main-file-name test.cpp -mrelocation-model static -mframe-pointer=all -fmath-errno -fno-rounding-math -mconstructor-aliases -munwind-tables -target-cpu x86-64 -tune-cpu generic -fno-split-dwarf-inlining -debugger-tuning=gdb -v -resource-dir /opt/rocm-4.3.0/llvm/lib/clang/13.0.0 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/x86_64-linux-gnu/c++/7.5.0 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/x86_64-linux-gnu/c++/7.5.0 -internal-isystem /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/backward -internal-isystem /usr/local/include -internal-isystem /opt/rocm-4.3.0/llvm/lib/clang/13.0.0/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -Wall -std=c++17 -fdeprecated-macro -fdebug-compilation-dir=/home/fpadmin -ferror-limit 19 -fgnuc-version=4.2.1 -fcxx-exceptions -fexceptions -fcolor-diagnostics -faddrsig -o /tmp/test-f9b375.o -x c++ test.cpp
clang -cc1 version 13.0.0 based upon LLVM 13.0.0git default target x86_64-unknown-linux-gnu
ignoring nonexistent directory "/include"
ignoring duplicate directory "/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/x86_64-linux-gnu/c++/7.5.0"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0
/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/x86_64-linux-gnu/c++/7.5.0
/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/backward
/usr/local/include
/opt/rocm-4.3.0/llvm/lib/clang/13.0.0/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
test.cpp:28:9: warning: JSON_HAS_EXPERIMENATL_F: 1 [-W#pragma-messages]
#pragma message "JSON_HAS_EXPERIMENATL_F: " XSTR(JSON_HAS_EXPERIMENTAL_FILESYSTEM)
^
test.cpp:29:9: warning: JSON_HAS_FILESYSTEM: 0 [-W#pragma-messages]
#pragma message "JSON_HAS_FILESYSTEM: " XSTR(JSON_HAS_FILESYSTEM)
^
2 warnings generated.
"/opt/rocm/llvm/bin/ld.lld" -z relro --hash-style=gnu --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/7.5.0/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/7.5.0 -L/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../x86_64-linux-gnu -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../.. -L/opt/rocm-4.3.0/llvm/bin/../lib -L/lib -L/usr/lib /tmp/test-f9b375.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/7.5.0/crtend.o /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../x86_64-linux-gnu/crtn.o
ld.lld: error: undefined symbol: std::experimental::filesystem::v1::__cxx11::path::compare(std::experimental::filesystem::v1::__cxx11::path const&) const

referenced by test.cpp
/tmp/test-f9b375.o:(main)

ld.lld: error: undefined symbol: std::experimental::filesystem::v1::__cxx11::path::_M_split_cmpts()

referenced by test.cpp
/tmp/test-f9b375.o:(std::experimental::filesystem::v1::__cxx11::path::path<char [2], std::experimental::filesystem::v1::__cxx11::path>(char const (&) [2]))
referenced by test.cpp
/tmp/test-f9b375.o:(std::experimental::filesystem::v1::__cxx11::path::path<char [3], std::experimental::filesystem::v1::__cxx11::path>(char const (&) [3]))
clang-13: error: linker command failed with exit code 1 (use -v to see invocation)

Looks like it's somehow using the GCC standard library instead of libc++.
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0
/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/x86_64-linux-gnu/c++/7.5.0
/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/backward

Looks like it's somehow using the GCC 7.5.0 standard library instead of libc++.
#include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0 /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/x86_64-linux-gnu/c++/7.5.0 /usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/backward

I think that is OK. I was able to run this code by adding the '-lstdc++fs'

So the library correctly detected that the used libc++ only supports <experimental/filesystem>, but the CMake files for the test suite compilation did not link stdc++fs, because it expected the compiler did not need it. Right?

So the library correctly detected that the used libc++ only supports <experimental/filesystem>, but the CMake files for the test suite compilation did not link stdc++fs, because it expected the compiler did not need it. Right?

That is correct, the library correctly detected the experimental/filesystem :). Please feel free to close this issue and thank you for helping out.

Thanks!

Unrelated maybe... But I had a strange issue when building release (x64) build in VS2022 v17.1.2 using c++20 (I'm playing with modules). Same project builds in Debug x64.
This is the error:
error LNK2001: unresolved external symbol "bool __cdecl std::filesystem::operator==(class std::filesystem::_Path_iterator<template-type-parameter-1'> const &,class std::filesystem::_Path_iterator<template-type-parameter-1'> const &)" (??8filesystem@std@@YA_NAEBV?$_Path_iterator@$RBAAB@@01@0@Z)
I finally solved this by adding in json.hpp at line 54:
#define JSON_HAS_CPP_14
FYI - I have tried countless things before posting here. Including removing any code using std::filesystem. Nlohmann json is the only library using std::filesystem in my project, that's why I suspected a problem in the json code. I just though I should mention this in case others are having the same problem. But it would be nice to find a solution of course.


pa-applet doesnt start with the system

I have to start it manualy in the terminal, how can i make it start automatically? im using arch linux.

This isn't a support channel, sorry.


Make #747 happy: Add LIST functionality for z/OS JES subsystem

Issue #747: Please read (especially at the end) or in the Wiki: here
Added FtpZOSListRealm.Jes2.
Added the capability to parse this realm.
Needed to add a listing option to deter GetListing(...) from switching to Image, we need this process to stay in ASCII.

Released!
https://www.nuget.org/packages/FluentFTP/41.0.0


ru_RU (Russian) translation for the "mergeManyFeatures.js"

Added translation for 2 lessons: mergeManyFeatures and Tracking

Woo awesome! Thanks as always

Done, without errors.
[gh-pages 4c80f0b] rebuild for prod
 4 files changed, 188 insertions(+), 17 deletions(-)
 rename build/{bundle.min.480af676.js => bundle.min.e4b74152.js} (85%)
Counting objects: 13, done.
Delta compression using up to 4 threads.

should be pushed!


Don't work in Sketch 39.1

Hi!
I run the plugin, it don't work in Sketch 39.1.
Log on Console.app
8/11/16 23:28:25.112 RandomColor (Sketch Plugin)[24534]: ReferenceError: Can't find variable: context.
Plugin “script”, line 32:
»     var selection = context.selection

Thank you!

same problem

Hi,
Me to facing the same problem.
Could you please update it as soon as possible.

Have this problem too with version 41.2

Same opera with 42 👎

Hmm, let me figure out.

Any news on this issue?

Now works with sketch4+


Renaming this project? Please give me your vote ...

Before I chose the name WinBox I made some search, but probably not good enough. I've never heard about the router manufacture which uses the same name for one of their toolkit. Personally I'm totally fine with it. But there was another naming candidate for this window manager called "Scalebox" which I did not picked.
Which one would you choose:

are you fine with the current name?
do you prefer the name "Scalebox"?
do you have another suggestion?

Thanks a lot.

window.js

I actively dislike Scalebox.
I'm fine with the current name despite the conflict... though I'd offer a few suggestions: WebWindow, Aperture, Subview.  I see @FishOrBear 's suggestion of window.js, and that's not bad, but I tend to think there's too many *.js projects already, so for me it wouldn't be my first choice.

"winbox" it is a nice name!

searching "winbox.js" immediately brings up the github pages site... maybe we should use that!

how about js-winbox.js or winbox-js.js

@andisfar why we need two js

window.js on npm is already taken
So is WindowJS on GitHub
I wouldn't choose that. I personally like the current name.

I contact the npm support and asking for the window.js package name. They had answered me that they actually work on a new policy, so I have to wait. But the chances are low, because another policy did not allow similar names of existing packages and there is also a package name "window" which will be blocking the "window.js" package name by sure.
I will keep that name. I read some negative responses about the naming, and I just wand to check if I can something improve. But it looks that isn't a really big problem with the current name.
Thanks a lot!


URGENT: Legislative Reports section in footer

We are being asked to post various Legislative Reports our website. It is my understanding that we have created hidden pages where these reports where posted in the past (example: 2020-2022 ODI Legislative Report)
Are we able to add a section to our website footer to host multiple report types? I think we can create a page similar to what EDD is doing for reports .. see https://edd.ca.gov/en/about_edd/edd_legislative_reports/
Ideally we would like to show and archive reports when appropriate at a given time.
Timeline to completion: As soon as we can as these are mandated requests from our parent agency

Waiting on final draft of  Finance Leadership Accountability report (the one in question) that is supposed to be online by 4/28.

Barb

Please follow similar format as https://cannabis.ca.gov/about-us/legislative-reports/ for this 1st iteration. No need to post PDF, will post as text only

Incidentally, the White House recently released this piece through the Office of the Federal Chief Information Officer.

HTML provides numerous advantages (e.g., easier to make accessible, friendlier to assistive technology, more dynamic and responsive, easier to maintain). When developing information for the web, agencies should default to creating and publishing content in an HTML format in lieu of publishing content in other electronic document formats that are designed for printing or preserving and protecting the content and layout of the document (e.g., PDF and DOCX formats). An agency should develop online content in a non-HTML format only if necessitated by a specific user need.

😄

@m-sullivan7 @zakiya @jbum
SLAA Meeting notes:
Overview: report state leadership accountability act (SLAA)

Goes to the Department of Finance for review
Transparency requirement in case DOF looks for report and/or asks us for it.
Report needs to post within 5 days of DOF notice, we received this last week, deadline is today.
DOF will host PDF version of report on their website and also publish to State Library
Legal is OOO today and we need to publish per DOF requirement.
SLAA needs to be followed up with a implementation plan. (Due 6/30/24)

SLAA report - Due by 4/28

[ ] Currently a PDF document, about 10 page doc --   OK to post as text only page on site
[ ] SLAA report attached: 7504 Office of Data and Innovation.pdf
[ ] publish as a hidden page similar to 2020-2022 ODI Legislative Report

Posting to ODI website
Plan A: DUE TODAY 4/25 per DOF requirement

[ ] Publish as a hidden page similar to 2020-2022 ODI Legislative Report
[ ] Pull text from 7504 Office of Data and Innovation.pdf (SLAA) and format in alignment with ODI website style

Plan B: Due by end of week - If we are asked to make public facing by legal

[ ] Create a link in footer named Legislative Reports
[ ] List SLAA and July 1, 2020-July 1, 2022 reports by year (layout similar to https://cannabis.ca.gov/about-us/legislative-reports/)

Quick clarification on "Publish as a hidden page": the 2020-2022 legislative report is hidden from search engines. (I might have stated otherwise previously.) Do we want to hide this page from search engines as well?

@m-sullivan7 no need to hide from search engines since it will be published on other State sites aswell in PDF format

One more question: is there a Google Doc version I can reference? This will help me make sure that I get the heading levels correct. (Copying and pasting would be faster and simpler from a Google Doc too.)

Is there any work to do on this, or can we call this complete?

Notes from 4/29 meeting with Becky on reports and website development for required reports

SLAA report (https://innovation.ca.gov/2023-leadership-accountability-report/) -- need to be on site
Ledge report - No requirement to be posted, goes to judicial
Data strategy report- No requirement to be posted, goes to judicial

QUESTIONS

Should all reports be searchable site wide?
Should we post all reports on the website?
If we post we need to ensure they are accessible from the start, what is the plan for remediation for past reports
If we have a strategic reason to post other reports, how should we approach?
How do we show the different report types?
Where should does this section reside within IA?

@m-sullivan7 @zakiya
We received the green light to get the Legislative Reports page added to the site.
Please see below for build details:

[ ] Create a link in footer named Legislative Reports
[ ] List SLAA and July 1, 2020-July 1, 2022 reports by year (layout similar to https://cannabis.ca.gov/about-us/legislative-reports/)
[ ] We need to have SLAA, the Data Strategy, and Leg Report on the website

Completion deadline: May 7, 2024

On it. 🙂
A few follow ups:

Can I unhide the 2022 legislative report from search engines?
Can I get a link to the data strategy?

In the meantime, here's a preview of what the footer will look like. The Reports page is live, but not the update to the footer.

I spoke with Barb (magic of in-office work) and she said the data strategy should be available tomorrow. She will get it to me tomorrow. She has also shared the preview with Sam and Becki.

@jbum Not urgent, but in moving the reports around, we may need to look again at our breadcrumb links as part of launching this information architecture. I think you did a one-off fix in Projects for the case studies. We have the same need for pages that sit under Reports (potentially up to 2 levels of needed links, as seen in the first screenshot).

This also applies to job postings too. (See the lack of a link for Join us.)

Happy to spin this into another issue, but thought I'd mention here for now.

Yes, I'll fix when I add the redirects.
On Fri, May 3, 2024 at 1:50 PM Michael Sullivan @.***>
wrote:

@jbum https://github.com/jbum Not urgent, but in moving the reports
around, we may need to look again at our breadcrumb links as part of
launching this information architecture. I think you did a one-off fix in
Projects for the case studies. We have the same need for pages that sit
under Reports (potentially up to 2 levels of needed links, as seen in
the first screenshot).
image.png (view on web)
https://github.com/cagov/innovation.ca.gov/assets/69169190/9c4f8b97-b89f-46d9-b7ee-ba915cfc5a0f
This also applies to job postings too. (See the lack of a link for Join
us.)
image.png (view on web)
https://github.com/cagov/innovation.ca.gov/assets/69169190/cb5313ce-5e34-4716-ac63-a4af23dbeb51
Happy to spin this into another issue, but thought I'd mention here for
now.
—
Reply to this email directly, view it on GitHub
https://github.com/cagov/innovation.ca.gov/issues/290#issuecomment-2093744984,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACGJ2OHIKYXPYPAZ5P62WDZAP2DFAVCNFSM6AAAAABGN7IVDCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJTG42DIOJYGQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

@YeseniaGtz Checking in on this since I heard we have a May 7 publication due date. If the Reports draft content is good, I can launch this now and add the data strategy report when it's ready.

Reports published in the footer.


orderBy accepts QueryBuilder

close #3489

I have no idea, but integration test sometimes fails.

@HurSungYun Could you also update TS types and documentation?

Thanks!