More typescript fixes

Make Event generic and add a callback signature in a few places
There are a lot more places this could be used but it should be non-breaking and just allows for future refinement.
ConstructorOptions for Resource
I can't remember why this one got taken out?
exportKml overload actually works
The catch is that I had to exclude it from prettier until they address https://github.com/prettier/prettier/issues/7724.  The overloads do show up separately in the docs but I think it looks OK that way.
Another stab at making PropertyBag actually work
I pinged https://github.com/jsdoc/jsdoc/issues/1285 for an update.  All the SO questions, etc, that I can find about how to describe something like PropertyBag (a class with its own methods and properties, and also an index signature for "other" properties) say the only option is an intersection type, which JSDoc refuses to support on the basis that it's not part of Closure Compiler.  (The questions actually all say "this is an antipattern, don't do this in the first place" but it's probably too late to change?)
I think the hack I came up with will work for now.  Basically, the class is called PropertyBag so that it gets the right name during generateDocumentation, but for Typescript purposes it's renamed to PropertyBagBase with a regex replace, then a top level type alias is declared using union types.
The one thing I wasn't able to do is figure out how to document in JSDoc that PropertyBag has an index signature.  Is there a more Javascript-y name for "index signature"?  I think I would have called it the "index operator" back before I learned TS, but I can't find anything online using either name.  This isn't a new problem -- the docs have never actually given an example of using e.g. ent.properties.someProperty -- but since I was in there anyway I was looking to improve it.  If you can find the right tag to use, by all means let's add it.

Thanks for the pull request @thw0rted!

:heavy_check_mark: Signed CLA found.
:grey_question: CHANGES.md was not updated.

If this change updates the public API in any way, please add a bullet point to CHANGES.md.

:grey_question: Unit tests were not updated.

Make sure you've updated tests to reflect your changes, added tests for any new code, and ran the code coverage tool.

Reviewers, don't forget to make sure that:

[ ] Cesium Viewer works.
[ ] Works in 2D/CV.
[ ] Works (or fails gracefully) in IE11.

I just noticed that these typings break my build, not because of any changes I made, but because I rebased them on top of master which added the properties defaultDayAlpha and defaultNightAlpha to ImageryProvider but did not add them to the implementations of that interface.  Your interim solution of adding the necessary properties to each implementation fails to catch when a new property is added to the interface but missed in one (or all) of the implementations, unfortunately.
I think in the big PR from last week there was some discussion about why these classes don't use inheritance, but I didn't see any mention of the @extends tag.  As an experiment, I added @extends ImageryProvider to WebMapServiceImageryProvider and it did not appear to immediately explode.  VSCode complains because @extends belongs on a "real" class, not a class-like function, but generateDocumentation and build-ts both seem happy with it.  Would you be OK with adding @extends to all the implementations of ImageryProvider to avoid this problem?

exportKml overload actually works

I'm not sure what you mean by this.  How is it actually broken in master?

I just noticed that these typings break my build, not because of any changes I made, but because I rebased them on top of master which added the properties defaultDayAlpha and defaultNightAlpha to ImageryProvider but did not add them to the implementations of that interface. Your interim solution of adding the necessary properties to each implementation fails to catch when a new property is added to the interface but missed in one (or all) of the implementations, unfortunately.

This is fixed via new smokescreen tests in #8908.  If a new ImageryProvider is added, we'll need to add it to the test, but that is not a common occurrence and should just be part of the review.

It's a little weird that Listener shows up in the JSDoc here as a Type without any further context:

Not the end of the world, but I wonder if we're doing something wrong or if there's a better way.

The key word in the line about exportKml is "overload".  I wrote an overload, which is two doc-blocks with @variant tags "nestled" so that you wind up with *//** between them, but Prettier quietly broke them during commit due to https://github.com/prettier/prettier/issues/7724 so you backed that out.  I put it back along with a Pretty ignorefile entry and it works as an overload again.
Re: Listener showing up as an unreferenced type, would it be clearer if it were simply renamed to something more specific like "EventCallback" or something, and maybe there was a note describing it in the class description?  Alternately, does the AST from the JSDoc parser include a node for generic type parameters that maybe needs to be added to the doc template?  If not, that sounds like an issue to file with jsdoc.

The key word in the line about exportKml is "overload".

Sorry if I'm confused here, but I just don't get why this is needed at all.  From my understanding as it's documented the result can either be exportKmlResultKml or exportKmlResultKmz.  If this is somehow a problem, I think I would rather just declare a single exportKmlResult and have it have all 3 properties.  You can check the existence of the kml or kmz properties to see which was generated.  This is a lot cleaner to me than duplicating the doc here.  I realize I'm a bit green on TS here so if you could help me understand I would appreciate it.

You can document exportKml with {boolean} options.kmz, and return type Promise<result1|result2>, then the consumer has to cast the result even though they know which one they asked for.  In Typescript, you'd solve this with a function overload signature.  Functions can only have one body but any number of signatures, and they're matched in the order declared.
function lookup(key: "strThing"): string;
function lookup(key: "numThing"): number;
function lookup(key: string): string | number | Array { ... }

lookup("strThing"); // types as string
lookup("numThing"); // types as number
lookup("otherThing"); // can't tell at compile time, types as string | number | Array

tsd-jsdoc will emit this but only if you have two "nestled" doc blocks describing the same function.  So I created the double block such that passing options.kmz = true will only return Promise<kmzResult> and if it's false or not specified it will be a KML result.
Basically, it makes the docs a bit bigger but it saves users from having to cast the result. I think this is preferable but I understand it has some drawbacks. (You should see the declaration for document.createElement in the DOM lib file!)  Anyway, feel free to back it out but I thought this was friendlier to consumers.

@thw0rted can you please merge in master, this will bring in the TS smokescreen changes and some other cleanup. Thanks!

I just rebased and am running build-ts and generateDocumentation.  I haven't tried the new smoketests or anything else yet.
Everything seems fine except for my PropertyBag hacks.  As mentioned in the OP, the consensus seems to be that supporting arbitrary properties (index signature) on a class is an antipattern and it's tough to describe properly in TS.  Either you make an any index signature so that the return of an index operation is not type-safe, or you use a union type and make it impossible to actually instantiate the "class" (because it's not just a class anymore) from Typescript.
In my typings, as in this PR, I opted for the latter, because I don't expect end users to make a new PropertyBag() -- more likely it would be new Entity({..., properties: {a: 1, b: true}}).  If I'm right, it's more important for myEnt.properties.someProp to type correctly.  I could totally be missing some common use case, though.
Anyway, I pushed one more commit that "fixes" the smoke test by not actually instantiating a PropertyBag, and instead doing a cast to make TS think an assignment is happening.  If you're happy with this, great, and if not we can back out all the PropertyBag related stuff.

dont know if I'm too late to the party.  Removing some whitespaces in the jsdoc ({ImageryProvider | false} to {ImageryProvider|false} solves this for me. Can we get this in here too? otherwise I'll open another PR

@thw0rted regarding exportKml, even though I agree with you that overloads in real TypeScript would work well here, I'm inclined to agree with Matt that the cost outweighs the benefit in this case. The resulting reference docs are pretty confusing. exportKml shows up twice (including in search results), and it takes a lot of reading to figure out why and what the difference between the two is. And the benefit in client code is relatively small relative to Matt's suggestion of returning a unified ExportKmlResult; it only avoids a single undefined check of the property you expect to be returned.
Perhaps the best design would be to have a separate exportKmz function, even if it's just a one-liner that calls a common implementation. We'd have to add a deprecationWarning on options.kmz and continue to support it for a couple of releases.

Also please mate don't force push. You accidentally clobbered some of my changes. I'll re-add them.

Hi @bkuster,

dont know if I'm too late to the party.  Removing some whitespaces in the jsdoc ({ImageryProvider | false} to {ImageryProvider|false} solves this for me. Can we get this in here too? otherwise I'll open another PR

I don't quite understand why the whitespace would throw off the typings. The generated Cesium.d.ts looks fine to me, and certainly TS itself isn't sensitive to whitespace there. I'm not opposed to that change just for the sake of tidiness, but it could be worth double-checking there isn't something else going on there.

@kring yeah, must have been some freaky thing over my end, all fine now (probably forgot to rebuild the TS after pulling from master or similar), sorry for the noise.

Kevin, sorry about clobbering your changes -- I'm used to working in my own "private" branches where rebase-and-force is a safe workflow.  I need some practice working with a shared upstream!
You're right that the docs are pretty unwieldy for exportKml and the benefit isn't huge.  It would be nice if we had an option for marking one as "don't emit in the regular docs template, but do emit in the TS typings".  Probably not possible?  Maybe it would make sense to update the docs template to ignore anything that has an @variant value other than 1?  I strongly suspect it's not used anywhere else at present.
Re: PropertyBag, I'm going to do a bit more research and see if there's not some way to make a declaration that's a) new-able, b) has strongly-typed methods and explicit properties, and c) also has a strongly typed index signature.  I suspect it isn't, so we'll wind up having to give the index signature an any-type.

Kevin, sorry about clobbering your changes

No worries! :)

It would be nice if we had an option for marking one as "don't emit in the regular docs template, but do emit in the TS typings".

Yeah that'd be cool. Again, though, I'm not really sure it's worth the cycles. Even in the best-case scenario it still forces to maintain duplicated doc, for very minimal benefit.

Thanks again for your contribution @thw0rted!
No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy?
I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

Thanks again for your contribution @thw0rted!
No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy?
I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

Thanks again for your contribution @thw0rted!
No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy?
I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

Sorry to be away from this for so long.  I just rebased back to master (I did check here first to make sure I wouldn't clobber anybody!) and am going to see if I can rework this, possibly into multiple PRs.

@mramato  I know it's been a while but if you can take a look at this, I backed out all the changes that I think were controversial or unwanted, so you're basically left with generic Properties and Events, with default type values that should mean that it's transparent to consumers.

Thanks again for your contribution @thw0rted!
No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy?
I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

FYI I just rebased this on current master so it should be ready to go, if anybody has time to look at it.  (Not like we've got anything else going on these days, eh? :-/ )

@thw0rted sorry we haven't been able to get back to this.  We've been swamped lately, but will try to review this soon

Thanks again for your contribution @thw0rted!
No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy?
I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

Thanks again for your contribution @thw0rted!
No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy?
I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

Thanks again for your contribution @thw0rted!
No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy?
I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

Thanks again for your contribution @thw0rted!
No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy?
I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

Thanks again for your contribution @thw0rted!
No one has commented on this pull request in 90 days. Maintainers, can you review, merge or close to keep things tidy?
I'm going to re-bump this in 90 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

Thanks again for your contribution @thw0rted!
No one has commented on this pull request in 90 days. Maintainers, can you review, merge or close to keep things tidy?
I'm going to re-bump this in 90 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

Thanks again for your contribution @thw0rted!
No one has commented on this pull request in 90 days. Maintainers, can you review, merge or close to keep things tidy?
I'm going to re-bump this in 90 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

I just created a new PR, #10292, which has all the important changes from here without any of e.g. Promise<xyz> -> Promise.<xyz> -- those were a holdover from the when.js days.  @sanjeetsuhag maybe you could take a look at that one if you have time?  I believe it addresses all the comments from above, the only outstanding thing would be that it adds three TODO comments.  It would be up to you whether they should be a new issue, passed to a team member to answer, or handed back to me to finish before closing out the PR.

@thw0rted Can we close this in favor of https://github.com/CesiumGS/cesium/pull/10292#pullrequestreview-941173274? Even closed, this PR will still exist for the sake of documenting discussion.

Fine by me.  I'll try to take a look at your comments over there today -- thanks for taking the time to look it over!


ctrl + click on google chrome doesn't work

Version
1.9.1
Test Case
https://jsfiddle.net/Luktwrdm/54/
Steps to reproduce
Open project in google chrom.
Ctrl click the trigger component
Expected Behavior
The Context menu opens
Actual Behavior
No Context menu open
Possible fix
In ContextMenuTrigger.js>handleContextClick. Remove if statement checking that event.button === this.props.mousebutton. Replace with this.props.mousebutton === 2. This should fix the problem because in chrome a ctrl click event.button is 0 not 2.

see #339


make _run_serve_loop a context manager

A user was asking for something that essentially requires running modal serve in a more programmatic way, and also get app info back.
I realize it's pretty tricky given the current client code, but with some minor refactoring it shouldn't be too hard. This also lets us unify the interface between running and serving to some extent.

This isn't the full set of changes, but given how complex this code is, I prefer to merge it piece by piece


Enhancement add cliEntraAppId and cliEntraAppTenant configurations settings for cli config commands

As discussed in this thread https://github.com/pnp/cli-microsoft365/pull/5985#issuecomment-2071660832
The aim of the task is to add the cliEntraAppId and cliEntraAppTenant options to the list of available settings for: cli config get , cli config list , cli config reset , cli config set.
Later the new options will be utilized in cli app add command.
The importance of the app ID setting would be as follows:

CLIMICROSOFT365_ENTRAAPPID
CLIMICROSOFT365_AADAPPID (obsolete)
cliEntraAppId  (new setting option)
the default one

The importance of the tenant setting would be as follows:

CLIMICROSOFT365_TENANT
cliEntraAppTenant (new setting option)
"common"

We should use the new config options wherever we refer to config.cliEntraAppId. I suggest that the value configured in the CLI takes precedence over env var (so the order for the app ID is 3, 1, 2, 4 and tenant 2, 1, 3)

ok, noted. You can assign me to this task since I've already made some research at this topic.

Currently, all our config settings are not tenant-bound. If we implement this, it will clash when switching connections (when switching to another tenant). I'm wondering if this is problematic here.

Hi, @milanholemans Isn't it similar to using the 'CLI MICROSOFT365 TENANT' option?
Perhaps it's a helpful clue. There's a distinction when a user sets 'CLI MICROSOFT365 TENANT' parameter themselves and encounters an issue, versus when issues arise from setting it the 'supported way' in background, using cli app add (as mentioned in the task).

Yes, but CLIMICROSOFT365_TENANT is an environment variable.
If we introduce this both as an environment variable and config setting, I don't see the point anymore why we still support it as environment variable.

Hi @milanholemans, The new configuration setting will be only used for cli app add to assign the newly created app for CLI purposes.
I agree that it would be best to use only one environment or configuration setting, but if I'm not mistaken, there's no possibility to assign environment settings from the code.
If you're referring only to the cliEntraAppTenant option, perhaps we can remove it. When we create a new app with cli app add, it's created under the current tenant scope, so maybe we don't need to set the tenant in the configuration settings.
But to summarize, we have a few options to choose from:

Simply don't add these configuration options and inform a user after running cli app add to set the configuration themselves using CLIMICROSOFT365_ENTRAAPPID and CLIMICROSOFT365_TENANT.
Add only one configuration option, cliEntraAppId, and assume that the tenant configuration is correct.
Add both options as described at the beginning.

What do you think @milanholemans ?

I have no idea whether or not you can update an environment variable to be honest. I'm just a bit concerned that we are creating now 2 paths to achieve the same thing, which I don't really like. In my humble opinion, we should either get rid of the env variables or just not set the app ID and tenant ID of the new app registration at all. Currently, I'm leaning towards the latter.

@milanholemans  I suppose removing environment variables is no longer an option since they are currently being used by users.
Ok, I believe the solution for cli app add would be to provide a message in the documentation on how to set environment variables. Not a perfect solution, but it won't cause any harm or confusion.
@waldekmastykarz Would it be ok?

@milanholemans I suppose removing environment variables is no longer an option since they are currently being used by users.

If needed, we can remove them in the next major release.
Have you tried setting an environment variable like we do here?
https://github.com/pnp/cli-microsoft365/blob/5f64790018ed556fb9244a42a8a1d359239c86ae/src/appInsights.ts#L3-L5
Or is this not something persistent?

@milanholemans Exactly, I have tried the same approach:

Unfortunately, the result is as follows.

In debugging, I can see that this value is assigned correctly, but perhaps it is valid only during the execution.

Node.js docs confirm this indeed.

The process core module of Node.js provides the env property which hosts all the environment variables that were set at the moment the process was started.

Hi @milanholemans, Should we then move in the direction of removing the environmental options CLIMICROSOFT365_ENTRAAPPID, CLIMICROSOFT365_AADAPPID, and CLIMICROSOFT365_TENANT, and replace them with cliEntraAppId and cliEntraAppTenant configuration options, to be set by cli config set, as you mentioned in one of the previous messages?

Let's wait for a second opinion of @waldekmastykarz or another @pnp/cli-for-microsoft-365-maintainers.

You can't update an env var from Node.js. You can only change its value for the current (your own) process, but when you restart it, it's reverted to its previous value. The only way to set it permanently, would be to update the correct value in shell rc file/registry, etc. which I don't think we should do.
Env vars are convenient in CI/CD scenarios, where they're easier to set than running CLI's configuration commands. On the other hand, for regular use, it's likely easier to use a command to set things up, than to have to dig in your profile to configure an env var.
While it seems like two ways to do the same thing, I'd say there's something to say for keeping both of them, because they're meant to support different use cases.

Hi @mkm17 , due to unforeseen recent developments regarding the PnP Management Shell app (https://www.youtube.com/watch?v=VNgc4k_gCT0), we are forced to change our approach. Unfortunately, this means that we have to close this issue in favor of PR https://github.com/pnp/cli-microsoft365/pull/6260, where our new approach is being implemented. We hope for your understanding.

Hi @milanholemans, do we also need still PR #5985? If the change in #6260 allows setting the appId and tenantId, I can update #5985 to enable users to create a custom Entra app.

Good catch @mkm17. I don't know what our stance is for that change. I think it still might come in handy. What do you think @waldekmastykarz?

#6260 indeed allows you to configure app ID and tenant (but also cert and its properties), so it would duplicate the functionality. @mkm17 sorry this happened. Would you be willing to have a look at 6260 to see if we cover everything that you contributed?

Good point! I've adjusted the code, extracting the portion for creating the Entra app into utils. If we're to reuse it in cli app add, we'd copy the relevant calls (resolveApis, createApp, grantAdminConsent), which all are in this function https://github.com/pnp/cli-microsoft365/pull/6260/files#diff-68345dab9b38ebb710ac76370c645344d0d283745787b5f12c05a8e295e47252R336


Decoding url instead of file?

Hi there,
I'm just trying to work out how to get this module to look directly a vector tile source rather than a local file
So for example this works
var data = fs.readFileSync(__dirname + '/data/25.Pbf');
var tile = new VectorTile(new Protobuf(data));

but this does not
var tile = new VectorTile(new Protobuf('http://localhost:7777/countries/tiles/5/17/25.pbf'));

I gather it's to do with making the xhr request properly, is anyone able to provide any sample code for how to easily do this in node?
Thanks in advance,
Rowan

See https://github.com/mapbox/tile-reduce/blob/master/src/remote.js for an example.

Thanks @mourner , fyi am looking at making a vector tiles desktop app with electron for exploring local mbtiles files


Catching and throwing Throwable?

Hello,
first of all. Thanks for this great library.
This is more a question than an issue.
Why do you throw and catch Throwable instead of Exception? For example in Try  or CheckedFunctionX?
What is the purpose behind it? Fatal errors are anyway rethrown in the class Failure?
Kind regards,
Robert Winkler

Hi,
thank you for the question!
For example, a StackOverflowError is considered ad recoverable (see here).
It is interesting, that Scala considered StackOverflowError in 2.10.x as non-fatal (see here) and in 2.11.x as fatal (see here).
However, in general it would be too restrictive only considering Exception ad non-fatal. 3rd party frameworks may invent their own exceptions extending Throwable or may even throw Errors as recoverable exceptions (which is not recommended - but they do!).
I think, this is the best way to go but I'm always open for new ideas!!
Greets,
Daniel

I agree with the reporter that catching Error/Throwable in library code
should be avoided.
If other libraries abuse the meaning of Error then it's their own problem.
I'd let the application decide whether to try to recover from
Error/CustomThrowable.
On May 26, 2015 6:11 PM, "Daniel Dietrich"<EMAIL_ADDRESS>wrote:

Hi,
thank you for the question!
For example, a StackOverflowError is considered ad recoverable (see here
https://github.com/javaslang/javaslang/blob/master/src/main/java/javaslang/control/Failure.java#L211
).
It is interesting, that Scala considered StackOverflowError in 2.10.x as
non-fatal (see here
http://www.scala-lang.org/api/2.10.4/index.html#scala.util.control.NonFatal%24)
and in 2.11.x as fatal (see here
http://www.scala-lang.org/api/2.11.5/index.html#scala.util.control.NonFatal%24
).
However, in general it would be too restrictive only considering Exception
ad non-fatal. 3rd party frameworks may invent their own exceptions
extending Throwable or may even throw Errors as recoverable exceptions
(which is not recommended - but they do!).
I think, this is the best way to go but I'm always open for new ideas!!
Greets,
Daniel
—
Reply to this email directly or view it on GitHub
https://github.com/javaslang/javaslang/issues/273#issuecomment-105558977
.

So how about making a type parameter of the particular subtype of throwable
the function may throw?
On Tue, May 26, 2015 at 6:18 PM, Martin Grigorov<EMAIL_ADDRESS>wrote:

I agree with the reporter that catching Error/Throwable in library code
should be avoided.
If other libraries abuse the meaning of Error then it's their own problem.
I'd let the application decide whether to try to recover from
Error/CustomThrowable.
On May 26, 2015 6:11 PM, "Daniel Dietrich"<EMAIL_ADDRESS>wrote:

Hi,
thank you for the question!
For example, a StackOverflowError is considered ad recoverable (see here
<
https://github.com/javaslang/javaslang/blob/master/src/main/java/javaslang/control/Failure.java#L211
).
It is interesting, that Scala considered StackOverflowError in 2.10.x as
non-fatal (see here
<
http://www.scala-lang.org/api/2.10.4/index.html#scala.util.control.NonFatal%24
)
and in 2.11.x as fatal (see here
<
http://www.scala-lang.org/api/2.11.5/index.html#scala.util.control.NonFatal%24
).
However, in general it would be too restrictive only considering
Exception
ad non-fatal. 3rd party frameworks may invent their own exceptions
extending Throwable or may even throw Errors as recoverable exceptions
(which is not recommended - but they do!).
I think, this is the best way to go but I'm always open for new ideas!!
Greets,
Daniel
—
Reply to this email directly or view it on GitHub
<
https://github.com/javaslang/javaslang/issues/273#issuecomment-105558977>

.

—
Reply to this email directly or view it on GitHub
https://github.com/javaslang/javaslang/issues/273#issuecomment-105586238
.

@martin-g

If other libraries abuse the meaning of Error then it's their own problem.

Yes, right. This is a violation of the contract of the Error class.

I'd let the application decide whether to try to recover from Error/CustomThrowable.

This aligns well with the suggestion of @jbgi:

So how about making a type parameter of the particular subtype of throwable the function may throw?

When composing multiple Try's, e.g. via flatMap, it is not possible for Java to calculate correct type bounds for the exception. This is especially the case because Throwable etc. are no interfaces (otherwise we could have used intersection types X1 & X2).
@jbgi: There are two problem with using a type parameter for the exception (see capitalized comments). Any ideas?
@FunctionalInterface
interface CheckedSupplier<R, X extends Throwable> {
    R get() throws X;
}

@FunctionalInterface
interface CheckedRunnable<R, X extends Throwable> {
    void run() throws X;
}

public interface Try<T, X extends Throwable> {

    static <T, X extends Throwable> Try<T, X> of(CheckedSupplier<T, X> supplier) {
        try {
            return new Success<>(supplier.get());
        } catch (X t) { // <===== CANNOT CATCH TYPE PARAMETERS
            return new Failure<>(t);
        }
    }

    // INTERSECTION TYPE DOES NOT WORK =======v
    default <Y extends Exception> Try<Void, X & Y> andThen(CheckedRunnable<Y> runnable) {
        return flatMap(ignored -> Try.run(runnable));
    }
}

So, @RobWin, you made a good point with your question!

I've slept one night over it and already had thoughts on it a year ago.
I think, we can't add a specific exceptions type because

the type gets lost when chaining the first effect, e.g. myTry.flatMap(e -> Try.of(() -> ...)). myTry may be of AException. If the inner Try.of throws a BException we have two cases:

myTry is a Success, then the whole result is a Failure of BException
myTry is a Failure, then the whole result is a Failure of AException

An Error may be non-fatal. For example it is common practice for servers to log such exceptions, i.e. Try.of(() -> ...).onFailure(x -> LOG.ERROR("oh noes!", x)).map(e -> ...).get()

There may be a HairyException extends Throwable

A good practice would be to match the exception, as shown in the docs at http://javaslang.com:
final A result = Try.of(this::bunchOfWork)
    .recover(Match
        .caze((Exception_1 e) -> ...)
        .caze((Exception_2 e) -> ...)
        .caze((Exception_n e) -> ...))
    .orElse(other);

Therefore I think, we will stay with Throwable.

Ok. Thx for the explanation.

@jbgi do you agree?

@danieldietrich I think CheckFunction could be parametrized without Try taking advantage of it (still catching throwable).
also to address the original comment, maybe there could an alternate Try.of method that catch only non fatal exceptions (as per https://github.com/scala/scala/blob/2.12.x/src/library/scala/util/control/NonFatal.scala).

@jbgi Thanks, that helped!

I think CheckFunction could be parametrized without Try taking advantage of it

I will take a look at it...

also to address the original comment, maybe there could an alternate Try.of method that catch only non fatal exceptions

This is already the default behavior. But looking at the code I think it can be optimized, e.g. throwing the original Error instead of the Fatal wrapper, if the exception if fatal.
public interface Try {
    static <T> Try<T> of(CheckedSupplier<T> supplier) {
        try {
            return new Success<>(supplier.get());
        } catch (Throwable t) {
            return new Failure<>(t);
        }
    }
}

public class Failure<T> implements Try<T> {
    public Failure(Throwable t) {
        Objects.requireNonNull(t, "Throwable is null");
        final Cause cause = Cause.of(t);
        if (cause.isFatal()) {
            throw cause;
        } else {
            this.cause = (NonFatal) cause;
        }
    }
}

public static abstract class Cause extends RuntimeException {
    public static Cause of(Throwable t) {
        Objects.requireNonNull(t, "Throwable is null");
        if (t instanceof Cause) {
            return (Cause) t;
        }
        final boolean isFatal = (t instanceof VirtualMachineError && !(t instanceof StackOverflowError))
                || t instanceof ThreadDeath
                || t instanceof InterruptedException
                || t instanceof LinkageError;
        return isFatal ? new Fatal(t) : new NonFatal(t);
    }
}

Yes. This looks better :)


#187 Iterator is a wrong concept for Fork.route()

For  #187

created interface Opt
created decorator Opt.Holder
created Opt.Empty
replaced Iterator<> to Opt<> in route()  for all  implementations of Fork

@dmzaytsev Many thanks, I will find someone to review it before we merge

@pinaf it's yours, please review

@dmzaytsev Holder only takes 1 element. Do you believe there is the possibility of needing more elements?

@dmzaytsev good job! 2 minor comments and 1 question.

@pinaf I did use the interface prototype from the task #187
interface Opt<T> {
  T get();
  boolean has();
}

I think it will be used only one element.
In a sense, this interface is an analogue  Guava Optional

@dmzaytsev OK, I think I undertand it now. The user of Fork.route should only have no object or 1 object. That's why iterator was wrong. Is this a correct interpretation @yegor256 ?

@pinaf thank you for comments.
I fixed it
looks at the changes please

@rultor merge

@rultor merge

@pinaf Thanks for your request. @yegor256 Please confirm this.

@dmzaytsev two comments from me above

@yegor256 thanks for your comments
take a look the changes

@rultor try to merge

@rultor try to merge

@yegor256 OK, I'll try to merge now. You can check the progress of the merge here

@yegor256 seems some problems occur with Rultor yegor256/rultor#840

@rultor try to merge

@yegor256 Oops, I failed. You can see the full log here (spent 39min)
Generation complete.
+ export LC_ALL=en_US.UTF-8
+ LC_ALL=en_US.UTF-8
+ export LANG=en_US.UTF-8
+ LANG=en_US.UTF-8
+ export LANGUAGE=en_US.UTF-8
+ LANGUAGE=en_US.UTF-8
+ sudo gem install --no-rdoc --no-ri pdd
Building native extensions.  This could take a while...
Building native extensions.  This could take a while...

ruby-filemagic-0.6.1 [2014-08-19]:

* Account for options passed to FileMagic.fm (issue #7 reported by Adam
  Wróbel).

Successfully installed nokogiri-1.6.5
Successfully installed ruby-filemagic-0.6.1
Successfully installed rake-10.4.2
Successfully installed pdd-0.14
4 gems installed
++ curl -K ../curl-appveyor.cfg --data '{accountName: '\''yegor256'\'', projectSlug: '\''takes'\'', pullRequestId: '\''188'\''}' https://ci.appveyor.com/api/builds
++ jq -r .version
+ version=661
+ true
++ curl -K ../curl-appveyor.cfg https://ci.appveyor.com/api/projects/yegor256/takes/build/661
++ jq -r .build.status
waiting for AppVeyor build 661: queued
+ status=queued
+ '[' queued == null ']'
+ '[' queued == success ']'
+ '[' queued == failed ']'
+ echo 'waiting for AppVeyor build 661: queued'
+ sleep 5s
+ true
++ curl -K ../curl-appveyor.cfg https://ci.appveyor.com/api/projects/yegor256/takes/build/661
++ jq -r .build.status
+ status=queued
+ '[' queued == null ']'
+ '[' queued == success ']'
+ '[' queued == failed ']'
+ echo 'waiting for AppVeyor build 661: queued'
+ sleep 5s
waiting for AppVeyor build 661: queued
+ true
++ curl -K ../curl-appveyor.cfg https://ci.appveyor.com/api/projects/yegor256/takes/build/661
++ jq -r .build.status
+ status=queued
+ '[' queued == null ']'
+ '[' queued == success ']'
+ '[' queued == failed ']'
+ echo 'waiting for AppVeyor build 661: queued'
+ sleep 5s
waiting for AppVeyor build 661: queued
+ true
++ curl -K ../curl-appveyor.cfg https://ci.appveyor.com/api/projects/yegor256/takes/build/661
++ jq -r .build.status
+ status=
time="2015-04-20T08:32:12+02:00" level="fatal" msg="Error response from daemon: engine is shutdown"

@rultor merge again

@rultor merge again

@dmzaytsev Thanks for your request. @yegor256 Please confirm this.

@rultor merge

@rultor merge

@rultor merge

@yegor256 OK, I'll try to merge now. You can check the progress of the merge here

@rultor merge

@yegor256 Done! FYI, the full log is here (took me 19min)

@rultor merge

@dmzaytsev Thanks for your request. @yegor256 Please confirm this.

@elenavolokhova please, review this task for compliance with our quality rules

@rultor deploy

@rultor deploy

@davvd OK, I'll try to deploy now. You can check the progress here

@rultor deploy

@davvd Oops, I failed. You can see the full log here (spent 5min)
+ '[' running == success ']'
+ '[' running == failed ']'
+ echo 'waiting for AppVeyor build 716: running'
waiting for AppVeyor build 716: running
+ sleep 5s
+ true
++ curl -K ../curl-appveyor.cfg https://ci.appveyor.com/api/projects/yegor256/takes/build/716
++ jq -r .build.status
+ status=running
+ '[' running == null ']'
+ '[' running == success ']'
+ '[' running == failed ']'
+ echo 'waiting for AppVeyor build 716: running'
+ sleep 5s
waiting for AppVeyor build 716: running
+ true
++ curl -K ../curl-appveyor.cfg https://ci.appveyor.com/api/projects/yegor256/takes/build/716
++ jq -r .build.status
+ status=running
+ '[' running == null ']'
+ '[' running == success ']'
+ '[' running == failed ']'
+ echo 'waiting for AppVeyor build 716: running'
+ sleep 5s
waiting for AppVeyor build 716: running
+ true
++ curl -K ../curl-appveyor.cfg https://ci.appveyor.com/api/projects/yegor256/takes/build/716
++ jq -r .build.status
+ status=running
+ '[' running == null ']'
+ '[' running == success ']'
+ '[' running == failed ']'
+ echo 'waiting for AppVeyor build 716: running'
+ sleep 5s
waiting for AppVeyor build 716: running
+ true
++ curl -K ../curl-appveyor.cfg https://ci.appveyor.com/api/projects/yegor256/takes/build/716
++ jq -r .build.status
+ status=running
+ '[' running == null ']'
+ '[' running == success ']'
+ '[' running == failed ']'
+ echo 'waiting for AppVeyor build 716: running'
+ sleep 5s
waiting for AppVeyor build 716: running
+ true
++ curl -K ../curl-appveyor.cfg https://ci.appveyor.com/api/projects/yegor256/takes/build/716
++ jq -r .build.status
+ status=running
+ '[' running == null ']'
+ '[' running == success ']'
+ '[' running == failed ']'
waiting for AppVeyor build 716: running
+ echo 'waiting for AppVeyor build 716: running'
+ sleep 5s
+ true
++ curl -K ../curl-appveyor.cfg https://ci.appveyor.com/api/projects/yegor256/takes/build/716
++ jq -r .build.status
+ status=

@davvd This ticket looks good. Thanks, All!

@davvd This ticket looks good. Thanks All!

@elenavolokhova thanks, got it, great to see high-quality tickets here

@pinaf 10 mins was added to the account of @elenavolokhova (for QA review), in transaction 56014233. I just added 19 mins to your account, many thanks for your contribution.. AP-56N43257F8755032Y spent here. you're getting extra minutes here (c=4). +19 added to your rating, current score is: +7863


Problem building influxdb-cxx

Not sure if this is a good place to ask this, but I am looking for some help.
I'm following the documentation at:
https://www.influxdata.com/blog/getting-started-c-influxdb/
Here is the current error(s) I am getting when trying to build influxdb-cxx:
gerald@dev02:~/Projects/influxdb-cxx/build$ cmake -Dcpr_DIR=/home/gerald/Projects/cpr -DCPR_INCLUDE_DIR=/usr/local/include/cpr/include -D INFLUXCXX_TESTING:BOOL=OFF ..
-- ~~~ influxdb-cxx v0.7.1 ~~~
-- Build Type : RelWithDebInfo
-- Boost support : ON
-- Unit Tests : OFF
-- System Tests : ON
-- Found CPR: /usr/local/lib/libcpr.so
-- Configuring done
CMake Error at src/CMakeLists.txt:43 (add_library):
Target "InfluxDB" links to target "cpr::cpr" but the target was not found.
Perhaps a find_package() call is missing for an IMPORTED target, or an
ALIAS target is missing?
CMake Error at src/CMakeLists.txt:43 (add_library):
Target "InfluxDB" links to target "cpr::cpr" but the target was not found.
Perhaps a find_package() call is missing for an IMPORTED target, or an
ALIAS target is missing?
CMake Error at src/CMakeLists.txt:30 (add_library):
Target "InfluxDB-Core" links to target "cpr::cpr" but the target was not
found.  Perhaps a find_package() call is missing for an IMPORTED target, or
an ALIAS target is missing?
CMake Error at src/CMakeLists.txt:25 (add_library):
Target "InfluxDB-Internal" links to target "cpr::cpr" but the target was
not found.  Perhaps a find_package() call is missing for an IMPORTED
target, or an ALIAS target is missing?
-- Generating done
CMake Generate step failed.  Build files cannot be regenerated correctly.
I started trying to do this on Rocky Linux 9 and with some trouble ended up getting to the same point I am getting now. Thinking maybe it was the distro I was using, I swapped to a fresh install of ubuntu 20.04 LTS (as that's what the documentation/tutorial was using) and gave it another shot with similar results.
I'm not familiar with cmake at all but based on the error messages it appears to be a linking error of some sort.
For reference here are the versions of cmake and gcc that is being used:
cmake version 3.16.3
gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)
Procedure used to install/build cpr (no errors I could see)
git clone https://github.com/whoshuu/cpr.git
cd cpr
mkdir build && cd build
cmake ..
make
sudo make install
I've tried various different values for cpr_DIR and CPR_INCLUDE_DIR and even omitting them with no success, though it does not appear they should be required from the documentation/instructions Ive followed)
I've tried deleting everything in the build directory and re-running the command also with no success.
Any help would be appreciated. If this is not the ideal place to ask on this, please point me in the right direction if possible and I'll be on my way.

Hmm, gave that a try and no change.
Eventually this will be built on RHEL in a production environment so I'm not quite sure Conan will/can be available as what can be installed is usually locked down a bit.
gerald@dev02:~/Projects/influxdb-cxx/build$ cmake .. -DCPR_USE_SYSTEM_CURL=ON
-- ~~~ influxdb-cxx v0.7.1 ~~~
-- Build Type : RelWithDebInfo
-- Boost support : ON
-- Unit Tests : OFF
-- System Tests : ON
-- Configuring done
CMake Error at src/CMakeLists.txt:43 (add_library):
Target "InfluxDB" links to target "cpr::cpr" but the target was not found.
Perhaps a find_package() call is missing for an IMPORTED target, or an
ALIAS target is missing?
CMake Error at src/CMakeLists.txt:43 (add_library):
Target "InfluxDB" links to target "cpr::cpr" but the target was not found.
Perhaps a find_package() call is missing for an IMPORTED target, or an
ALIAS target is missing?
CMake Error at src/CMakeLists.txt:30 (add_library):
Target "InfluxDB-Core" links to target "cpr::cpr" but the target was not
found.  Perhaps a find_package() call is missing for an IMPORTED target, or
an ALIAS target is missing?
CMake Error at src/CMakeLists.txt:25 (add_library):
Target "InfluxDB-Internal" links to target "cpr::cpr" but the target was
not found.  Perhaps a find_package() call is missing for an IMPORTED
target, or an ALIAS target is missing?
-- Generating done
CMake Generate step failed.  Build files cannot be regenerated correctly.
gerald@dev02:~/Projects/influxdb-cxx/build$

CPR_USE_SYSTEM_CURL is needed for building cpr (not influxdb-cxx). Doing a make install of cpr should list some CMake files then.

Gave that a shot and here's what I am seeing. A quick google search turned up few other posts on the net about it but I didn't see a solid resolution. I'll dig a little more.
Not quite sure why it says it found curl 7.80.0
gerald@dev02:~/Projects/cpr/build$ cmake ..
-- Detecting SSL backend...
-- SSL auto detect: Using OpenSSL.
-- Could NOT find CURL (missing: HTTP) (found version "7.80.0")
-- Could NOT find CURL (missing: HTTP) (found version "7.80.0")
CMake Error at CMakeLists.txt:193 (message):
Curl not found on this system.  To use the built-in version set
CPR_USE_SYSTEM_CURL to OFF.
-- Configuring incomplete, errors occurred!
See also "/home/gerald/Projects/cpr/build/CMakeFiles/CMakeOutput.log".
gerald@dev02:~/Projects/cpr/build$
gerald@dev02:~/Projects/cpr/build$
gerald@dev02:~/Projects/cpr/build$ curl
curl: try 'curl --help' or 'curl --manual' for more information
gerald@dev02:~/Projects/cpr/build$ curl --version
curl 7.68.0 (x86_64-pc-linux-gnu) libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11.zlib-ng brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3
Release-Date: 2020-01-08
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS brotli GSS-API HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets
gerald@dev02:~/Projects/cpr/build$ curl-config --protocols
HTTP
HTTPS
gerald@dev02:~/Projects/cpr/build$ which curl
/usr/bin/curl

Some distros like RHEL split dev and main packages, do have former installed?
I'd suggest you file an issue at the cpr project though, they have more expertise in this subject.

@K9Megahertz I have made a reproducer script for another issue; can you check it on your system?

Currently not running any of this on a RHEL system, was planned to run on that in future. Although, this might not be needed now. Current system is Ubuntu 20.04 LTS, I did try it on Rocky Linux and got similar/same errors.
Yeah , perhaps reaching out the cpr team would be good.
I'll give the reproducer script a try and let you know how it goes.

Hello,
I also have a problem with the installation: After "sudo make install" the following error message appears: make: *** No rule to make target 'install'.  Stop.
I also followed the instructions at the following link:
https://www.influxdata.com/blog/getting-started-c-influxdb/

@harfas89 this looks like a different problem, could file a separate issue? Please include more infos to reproduce the problem.

I'm just realizing that the instructions at .https://www.influxdata.com/blog/getting-started-c-influxdb/ differ slightly from the instructions here on github. there the step "cmake .." before the "sudo make install" is not provided.
But after the following instructions it worked:
mkdir build && cd build
cmake ..
sudo make install

I'm running into a similar issue, but getting blocked at a different point in the cpr install process. I just wanted to point out that cpr 1.9.x doesn't seem to support  CPR_USE_SYSTEM_CURL=ON, so if that's required you may want to specify cpr 1.10.x+ in the README.

cpr 1.9.x supports  CPR_USE_SYSTEM_CURL: https://github.com/libcpr/cpr/blob/a814567a98ab0ff70224ac9e37d71839c0738544/CMakeLists.txt#L40

Thanks for the correction on that, when I use -DCPR_USE_SYSTEM_CURL it doesn't show in the cmake options, and says it's unused at the end, so I used the -DCPR_FORCE_USE_SYSTEM_CURL option as well, which gets me to where I am in this issue here: https://github.com/libcpr/cpr/issues/933 with the missing system.h file
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    CPR_USE_SYSTEM_CURL

@offa my issues are on rhel7/8, and I've created 2 tickets on the cpr repo for them since I didn't think they were an issue on your side and didn't want to hijack this issue. The one linked above for rhel7, and this one for 8: https://github.com/libcpr/cpr/issues/932

I'm suddenly having a similar problem. A few weeks ago, I installed this library on an almost identical system (Ubuntu 22.04) and got it to work, but not this time.
I built cpr as described:
$ cd cpr/build
$ cmake ..
-- Detecting SSL backend...
-- SSL auto detect: Using OpenSSL.
-- Curl 7.81.0 found on this system.
-- Configuring done
-- Generating done
-- Build files have been written to: /home/dji/cpr/build

$ sudo make install
Consolidate compiler generated dependencies of target cpr
[100%] Built target cpr
Install the project...
-- Install configuration: "Release"
-- Up-to-date: /usr/local/lib/libcpr.so.1.11.0
-- Up-to-date: /usr/local/lib/libcpr.so.1
-- Up-to-date: /usr/local/lib/libcpr.so
-- Up-to-date: /usr/local/lib/cmake/cpr/cprTargets.cmake
-- Up-to-date: /usr/local/lib/cmake/cpr/cprTargets-release.cmake
-- Up-to-date: /usr/local/lib/cmake/cpr/cprConfig.cmake
-- Up-to-date: /usr/local/lib/cmake/cpr/cprConfigVersion.cmake
-- Up-to-date: /usr/local/include/cpr
-- Up-to-date: /usr/local/include/cpr/verbose.h
-- Up-to-date: /usr/local/include/cpr/session.h
-- Up-to-date: /usr/local/include/cpr/local_port_range.h
-- Up-to-date: /usr/local/include/cpr/error.h
-- Up-to-date: /usr/local/include/cpr/multiperform.h
-- Up-to-date: /usr/local/include/cpr/filesystem.h
-- Up-to-date: /usr/local/include/cpr/status_codes.h
-- Up-to-date: /usr/local/include/cpr/timeout.h
-- Up-to-date: /usr/local/include/cpr/range.h
-- Up-to-date: /usr/local/include/cpr/cert_info.h
-- Up-to-date: /usr/local/include/cpr/singleton.h
-- Up-to-date: /usr/local/include/cpr/callback.h
-- Up-to-date: /usr/local/include/cpr/proxies.h
-- Up-to-date: /usr/local/include/cpr/async.h
-- Up-to-date: /usr/local/include/cpr/curlholder.h
-- Up-to-date: /usr/local/include/cpr/response.h
-- Up-to-date: /usr/local/include/cpr/file.h
-- Up-to-date: /usr/local/include/cpr/body.h
-- Up-to-date: /usr/local/include/cpr/curl_container.h
-- Up-to-date: /usr/local/include/cpr/threadpool.h
-- Up-to-date: /usr/local/include/cpr/cookies.h
-- Up-to-date: /usr/local/include/cpr/proxyauth.h
-- Up-to-date: /usr/local/include/cpr/auth.h
-- Up-to-date: /usr/local/include/cpr/api.h
-- Up-to-date: /usr/local/include/cpr/low_speed.h
-- Up-to-date: /usr/local/include/cpr/unix_socket.h
-- Up-to-date: /usr/local/include/cpr/curlmultiholder.h
-- Up-to-date: /usr/local/include/cpr/payload.h
-- Up-to-date: /usr/local/include/cpr/util.h
-- Up-to-date: /usr/local/include/cpr/cprtypes.h
-- Up-to-date: /usr/local/include/cpr/multipart.h
-- Up-to-date: /usr/local/include/cpr/connect_timeout.h
-- Up-to-date: /usr/local/include/cpr/interceptor.h
-- Up-to-date: /usr/local/include/cpr/interface.h
-- Up-to-date: /usr/local/include/cpr/ssl_ctx.h
-- Up-to-date: /usr/local/include/cpr/buffer.h
-- Up-to-date: /usr/local/include/cpr/bearer.h
-- Up-to-date: /usr/local/include/cpr/redirect.h
-- Up-to-date: /usr/local/include/cpr/reserve_size.h
-- Up-to-date: /usr/local/include/cpr/limit_rate.h
-- Up-to-date: /usr/local/include/cpr/resolve.h
-- Up-to-date: /usr/local/include/cpr/user_agent.h
-- Up-to-date: /usr/local/include/cpr/local_port.h
-- Up-to-date: /usr/local/include/cpr/http_version.h
-- Up-to-date: /usr/local/include/cpr/accept_encoding.h
-- Up-to-date: /usr/local/include/cpr/parameters.h
-- Up-to-date: /usr/local/include/cpr/cpr.h
-- Up-to-date: /usr/local/include/cpr/async_wrapper.h
-- Up-to-date: /usr/local/include/cpr/ssl_options.h
-- Up-to-date: /usr/local/include/cpr
-- Up-to-date: /usr/local/include/cpr/cprver.h

But when I try to build influxdb-cxx, I get the following:
$ cd influxdb-cxx/build
$ cmake .. -DINFLUXDXX_TESTING=OFF -DCPR_INCLUDE_DIR=/usr/local/include/cpr -Dcpr_DIR=/home/dji/cpr
-- ~~~ influxdb-cxx v0.7.1 ~~~
-- Build Type : RelWithDebInfo
-- Boost support : ON
-- Unit Tests : OFF
-- System Tests : ON
CMake Warning (dev) at /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
  The package name passed to `find_package_handle_standard_args` (CPR) does
  not match the name of the calling package (cpr).  This can lead to problems
  in calling code that expects `find_package` result variables (e.g.,
  `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  /home/dji/cpr/cpr-config.cmake:21 (find_package_handle_standard_args)
  CMakeLists.txt:85 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found CPR: /usr/local/lib/libcpr.so
-- Configuring done
CMake Error at src/CMakeLists.txt:43 (add_library):
  Target "InfluxDB" links to target "cpr::cpr" but the target was not found.
  Perhaps a find_package() call is missing for an IMPORTED target, or an
  ALIAS target is missing?

CMake Error at src/CMakeLists.txt:25 (add_library):
  Target "InfluxDB-Internal" links to target "cpr::cpr" but the target was
  not found.  Perhaps a find_package() call is missing for an IMPORTED
  target, or an ALIAS target is missing?

CMake Error at src/CMakeLists.txt:30 (add_library):
  Target "InfluxDB-Core" links to target "cpr::cpr" but the target was not
  found.  Perhaps a find_package() call is missing for an IMPORTED target, or
  an ALIAS target is missing?

-- Generating done
CMake Generate step failed.  Build files cannot be regenerated correctly.

@Lithimlin Could you give these steps a try?

Could you give these steps a try?

Since it said "to reproduce the issue", I didn't see it as a solution when I first read it.
I just tried it, but I do still get an error:
[...]
+ cmake -DInfluxDB_DIR=/tmp/ifdbcxx_repro/deps/lib/cmake/InfluxDB/ -Dcpr_DIR=/tmp/ifdbcxx_repro/deps/lib/cmake/cpr/ ..
-- The CXX compiler identification is GNU 11.4.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found CURL: /usr/lib/aarch64-linux-gnu/libcurl.so (found version "7.81.0")
-- Looking for C++ include pthread.h
-- Looking for C++ include pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- InfluxDB 0.7.1 found
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/ifdbcxx_repro/influxdb-cxx/test_package/build
+ cmake --build . -j
[ 50%] Building CXX object CMakeFiles/test_package.dir/example.cpp.o
[100%] Linking CXX executable test_package
[100%] Built target test_package
+ ./test_package
./test_package: error while loading shared libraries: libcpr.so.1: cannot open shared object file: No such file or directory

Gonna try to investigate that a bit now. It's further than I've gotten before.

Tried setting the CPR_INCLUDE_DIR variable to where the .so file is located, but it seems like it's not used:
CMake Warning:
  Manually-specified variables were not used by the project:

    CPR_INCLUDE_DIR

I also turned on boost.
the test_package can still not find the .so file.

Ah, reading further in the comments of the linked post, running ldconfig helped with the test script. Gonna try for the actual installation now.
Perhaps including that script as an install script might be a good move.

I am at the same stages as @Lithimlin.

Perhaps including that script as an install script might be a good move.

You mean calling ldconfig as part of eg. make install? I don't think this is a good idea. It would require root permission for every installation (even to a local directory), is highly system depended and is a change to the complete system. Also it needs to be called after the installation of cpr which isn't necessary done at the same time.
@ramizlateralus So calling ldconf solves the issue?

There's an issue on the cpr side as well: https://github.com/libcpr/cpr/issues/928

It would require root permission for every installation (even to a local directory), is highly system depended and is a change to the complete system.

That's actually a good point.
Though mentioning it in the README may be a good choice then.

Though mentioning it in the README may be a good choice then.

:+1:

Reading back on my original comment I realized that's not actually what I meant.
I meant including the install script in the repo may be good to give people who want to install everything an easier time.

I'm afraid there's no single button solution. There are too many build options and ways to install.

@offa Hi, yes, i am using Ubuntu 22.04.
I found a way out in downloading influxdb-cxx client not the latest version, but version 0.6.7
https://github.com/offa/influxdb-cxx/releases/tag/v0.6.7
In the guide on the official website, we download automatically the latest version that requires cpr. Version 0.6.7 uses curl (if I'm not confusing anything).I'll report the results later.
@Lithimlin

Obviously, it worked. I was able to build the influxdb-cxx library version 0.6.7 as shown in the guide.
If we talk about the latest version(0.7.1) - not everything is so clear. I don't have much time and experience to try to solve the problem with the latest version, but I'm sure it's easy to fix.

Version 0.6.7 uses curl (if I'm not confusing anything)

That's correct. < 0.7.0 uses curl, but >= 0.7.0 uses cpr.

What issues are open here?

Hi,
I read above and building with CPR on Ubuntu 22.04 fails for me.
cmake -DINFLUXDXX_TESTING=OFF -DCPR_INCLUDE_DIR=/usr/local/include/cpr -Dcpr_DIR=/home/adallolio/Desktop/influxdb-cxx/cpr/ ..
-- ~~~ influxdb-cxx v0.7.1 ~~~
-- Build Type : RelWithDebInfo
-- Boost support : ON
-- Unit Tests : OFF
-- System Tests : ON
CMake Warning (dev) at /usr/share/cmake-3.27/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
The package name passed to find_package_handle_standard_args (CPR) does
not match the name of the calling package (cpr).  This can lead to problems
in calling code that expects find_package result variables (e.g.,
_FOUND) to follow a certain pattern.
Call Stack (most recent call first):
cpr/cpr-config.cmake:21 (find_package_handle_standard_args)
CMakeLists.txt:85 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.
-- Configuring done (0.0s)
CMake Error at src/CMakeLists.txt:27 (target_link_libraries):
Target "InfluxDB-Internal" links to:
cpr::cpr

but the target was not found.  Possible reasons include:
* There is a typo in the target name.
* A find_package call is missing for an IMPORTED target.
* An ALIAS target is missing.

CMake Error at src/CMakeLists.txt:40 (target_link_libraries):
Target "InfluxDB-Core" links to:
cpr::cpr

but the target was not found.  Possible reasons include:
* There is a typo in the target name.
* A find_package call is missing for an IMPORTED target.
* An ALIAS target is missing.

CMake Error at src/CMakeLists.txt:83 (target_link_libraries):
Target "InfluxDB" links to:
cpr::cpr

but the target was not found.  Possible reasons include:
* There is a typo in the target name.
* A find_package call is missing for an IMPORTED target.
* An ALIAS target is missing.

-- Generating done (0.0s)
CMake Generate step failed.  Build files cannot be regenerated correctly.
Then I tried v0.6.7 and also that fails:
cmake ..
-- The CXX compiler identification is GNU 11.4.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- ~~~ influxdb-cxx v0.6.7 ~~~
-- Build Type : RelWithDebInfo
-- Boost support : ON
-- Unit Tests : ON
-- System Tests : ON
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Found CURL: /usr/local/lib/cmake/CURL/CURLConfig.cmake (found version "7.80.0")
-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.74.0/BoostConfig.cmake (found version "1.74.0") found components: system
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success
CMake Error at test/CMakeLists.txt:2 (find_package):
By not providing "FindCatch2.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Catch2", but
CMake did not find one.
Could not find a package configuration file provided by "Catch2" with any
of the following names:
Catch2Config.cmake
catch2-config.cmake

Add the installation prefix of "Catch2" to CMAKE_PREFIX_PATH or set
"Catch2_DIR" to a directory containing one of the above files.  If "Catch2"
provides a separate development package or SDK, be sure it has been
installed.
Any hint, @offa ? Preferably I would like to compile the most recent version.
Thanks!

I read above and building with CPR on Ubuntu 22.04 fails for me.

Did you build CPR with CPR_USE_SYSTEM_CURL enabled?

Then I tried v0.6.7 and also that fails:

You have to provide Catch2 if tests are enabled. Either disable testing – if that's ok for your use case, or provide Catch2.
Let me know if you have further issues.

Hi @offa, sorry to bother you again, but, I believe this is what I am doing.
cmake -DINFLUXDXX_TESTING=OFF -DCPR_USE_SYSTEM_CURL=ON -DCPR_INCLUDE_DIR=/usr/local/include/cpr -Dcpr_DIR=/home/influxdb-cxx/cpr/ ..
Still I get the warning:
CMake Warning (dev) at /usr/share/cmake-3.27/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
The package name passed to find_package_handle_standard_args (CPR) does
not match the name of the calling package (cpr).  This can lead to problems
in calling code that expects find_package result variables (e.g.,
_FOUND) to follow a certain pattern.
Call Stack (most recent call first):
cpr/cpr-config.cmake:21 (find_package_handle_standard_args)
CMakeLists.txt:85 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.
And then the error:
CMake Error at test/CMakeLists.txt:2 (find_package):
By not providing "FindCatch2.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Catch2", but
CMake did not find one.
Could not find a package configuration file provided by "Catch2" with any
of the following names:
Catch2Config.cmake
catch2-config.cmake

Add the installation prefix of "Catch2" to CMAKE_PREFIX_PATH or set
"Catch2_DIR" to a directory containing one of the above files.  If "Catch2"
provides a separate development package or SDK, be sure it has been
installed.

Hi @offa, did you read my previous message? The first command :)
I am using -DCPR_USE_SYSTEM_CURL=ON

I had the same issue when executing the command: cmake -DINFLUXCXX_TESTING=OFF -DCPR_INCLUDE_DIR=/usr/local/include/ ..
And I went to the influxdb-cxx-master/src/CMakeLists.txt file and I replaced the "cpr::cpr" for "cpr". This is because they use an alias in the cpr-master/cpr/CMakeLists.txt and maybe it causes this error. Try it if it works for you too :)

Hi @offa,
I have run the test script from the link you provided. Everything seem to build properly but it library does not seem to be found when running the test script.
`+ BASE_PATH=/tmp/ifdbcxx_repro

rm -rf /tmp/ifdbcxx_repro
mkdir -p /tmp/ifdbcxx_repro
cd /tmp/ifdbcxx_repro
git clone --depth=1 -b 1.10.4 https://github.com/libcpr/cpr.git
Cloning into 'cpr'...
remote: Enumerating objects: 189, done.
remote: Counting objects: 100% (189/189), done.
remote: Compressing objects: 100% (178/178), done.
remote: Total 189 (delta 21), reused 79 (delta 5), pack-reused 0
Receiving objects: 100% (189/189), 153.87 KiB | 2.37 MiB/s, done.
Resolving deltas: 100% (21/21), done.
Note: switching to '2553fc41450301cd09a9271c8d2c3e0cf3546b73'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c
Or undo this operation with:
git switch -
Turn off this advice by setting config variable advice.detachedHead to false

mkdir -p cpr/build
cd cpr/build
cmake -DCPR_USE_SYSTEM_CURL=ON -DCMAKE_INSTALL_PREFIX=/tmp/ifdbcxx_repro/deps ..

-- Detecting SSL backend...
-- Found OpenSSL: /usr/lib/x86_64-linux-gnu/libcrypto.so (found version "3.0.2")
-- SSL auto detect: Using OpenSSL.
-- Found CURL: /usr/lib/x86_64-linux-gnu/libcurl.so (found version "7.81.0") found components: HTTP HTTPS
-- Curl 7.81.0 found on this system.

Resolving deltas: 100% (19/19), done.
mkdir -p influxdb-cxx/build
cd influxdb-cxx/build
cmake -DINFLUXCXX_TESTING=OFF -DINFLUXCXX_WITH_BOOST=OFF -Dcpr_DIR=/tmp/ifdbcxx_repro/deps/lib/cmake/cpr/ -DCMAKE_INSTALL_PREFIX=/tmp/ifdbcxx_repro/deps ..
-- The CXX compiler identification is GNU 11.4.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- ~~~ influxdb-cxx v0.7.1 ~~~
-- Build Type : RelWithDebInfo
-- Boost support : OFF
-- Unit Tests : OFF
-- System Tests : ON
-- Looking for C++ include pthread.h
-- Looking for C++ include pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Found CURL: /usr/lib/x86_64-linux-gnu/libcurl.so (found version "7.81.0")
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/ifdbcxx_repro/influxdb-cxx/build
cmake --build . -j
[ 12%] Building CXX object src/CMakeFiles/InfluxDB-Core.dir/InfluxDBFactory.cxx.o
[ 62%] Building CXX object src/CMakeFiles/InfluxDB-Internal.dir/LineProtocol.cxx.o
[ 62%] Building CXX object src/CMakeFiles/InfluxDB-Internal.dir/HTTP.cxx.o
[ 75%] Building CXX object src/CMakeFiles/InfluxDB-BoostSupport.dir/NoBoostSupport.cxx.o
[ 75%] Building CXX object src/CMakeFiles/InfluxDB-Core.dir/Point.cxx.o
[ 75%] Building CXX object src/CMakeFiles/InfluxDB-Core.dir/InfluxDB.cxx.o
[ 87%] Building CXX object src/CMakeFiles/InfluxDB-Core.dir/Proxy.cxx.o
[ 87%] Built target InfluxDB-BoostSupport
[ 87%] Built target InfluxDB-Core
[ 87%] Built target InfluxDB-Internal
[100%] Linking CXX shared library libInfluxDB.so
[100%] Built target InfluxDB
cmake --build . --target install
Consolidate compiler generated dependencies of target InfluxDB-BoostSupport
[ 12%] Built target InfluxDB-BoostSupport
Consolidate compiler generated dependencies of target InfluxDB-Internal
[ 37%] Built target InfluxDB-Internal
Consolidate compiler generated dependencies of target InfluxDB-Core
[ 87%] Built target InfluxDB-Core
[100%] Built target InfluxDB
Install the project...
-- Install configuration: "RelWithDebInfo"
-- Installing: /tmp/ifdbcxx_repro/deps/lib/libInfluxDB.so.1.0.0
-- Installing: /tmp/ifdbcxx_repro/deps/lib/libInfluxDB.so.1
-- Set runtime path of "/tmp/ifdbcxx_repro/deps/lib/libInfluxDB.so.1.0.0" to ""
-- Installing: /tmp/ifdbcxx_repro/deps/lib/libInfluxDB.so
-- Up-to-date: /tmp/ifdbcxx_repro/deps/include
-- Installing: /tmp/ifdbcxx_repro/deps/include/InfluxDBFactory.h
-- Installing: /tmp/ifdbcxx_repro/deps/include/InfluxDB.h
-- Installing: /tmp/ifdbcxx_repro/deps/include/Point.h
-- Installing: /tmp/ifdbcxx_repro/deps/include/InfluxDBException.h
-- Installing: /tmp/ifdbcxx_repro/deps/include/Proxy.h
-- Installing: /tmp/ifdbcxx_repro/deps/include/Transport.h
-- Installing: /tmp/ifdbcxx_repro/deps/include/influxdb_export.h
-- Installing: /tmp/ifdbcxx_repro/deps/lib/cmake/InfluxDB/InfluxDBTargets.cmake
-- Installing: /tmp/ifdbcxx_repro/deps/lib/cmake/InfluxDB/InfluxDBTargets-relwithdebinfo.cmake
-- Installing: /tmp/ifdbcxx_repro/deps/lib/cmake/InfluxDB/InfluxDBConfig.cmake
-- Installing: /tmp/ifdbcxx_repro/deps/lib/cmake/InfluxDB/InfluxDBConfigVersion.cmake
cd /tmp/ifdbcxx_repro/influxdb-cxx/test_package
mkdir build
cd build
cmake -DInfluxDB_DIR=/tmp/ifdbcxx_repro/deps/lib/cmake/InfluxDB/ -Dcpr_DIR=/tmp/ifdbcxx_repro/deps/lib/cmake/cpr/ ..
-- The CXX compiler identification is GNU 11.4.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found CURL: /usr/lib/x86_64-linux-gnu/libcurl.so (found version "7.81.0")
-- Looking for C++ include pthread.h
-- Looking for C++ include pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- InfluxDB 0.7.1 found
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/ifdbcxx_repro/influxdb-cxx/test_package/build
cmake --build . -j
[ 50%] Building CXX object CMakeFiles/test_package.dir/example.cpp.o
[100%] Linking CXX executable test_package
[100%] Built target test_package
./test_package
./test_package: error while loading shared libraries: libcpr.so.1: cannot open shared object file: No such file or directory`

In the test script I have added
sudo ldconfig "${BASE_PATH}/deps/lib"
right after
cmake -DCPR_USE_SYSTEM_CURL=ON -DCMAKE_INSTALL_PREFIX="${BASE_PATH}/deps" .. cmake --build . -j cmake --build . --target install
and it seemed to work? Not sure.
`

BASE_PATH=/tmp/ifdbcxx_repro
rm -rf /tmp/ifdbcxx_repro
mkdir -p /tmp/ifdbcxx_repro
cd /tmp/ifdbcxx_repro
git clone --depth=1 -b 1.10.4 https://github.com/libcpr/cpr.git
Cloning into 'cpr'...
remote: Enumerating objects: 189, done.
remote: Counting objects: 100% (189/189), done.
remote: Compressing objects: 100% (177/177), done.
remote: Total 189 (delta 21), reused 84 (delta 6), pack-reused 0
Receiving objects: 100% (189/189), 153.16 KiB | 2.51 MiB/s, done.
Resolving deltas: 100% (21/21), done.
Note: switching to '2553fc41450301cd09a9271c8d2c3e0cf3546b73'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c
Or undo this operation with:
git switch -
Turn off this advice by setting config variable advice.detachedHead to false

mkdir -p cpr/build
cd cpr/build
cmake -DCPR_USE_SYSTEM_CURL=ON -DCMAKE_INSTALL_PREFIX=/tmp/ifdbcxx_repro/deps ..

-- Detecting SSL backend...
-- Found OpenSSL: /usr/lib/x86_64-linux-gnu/libcrypto.so (found version "3.0.2")
-- SSL auto detect: Using OpenSSL.
-- Found CURL: /usr/lib/x86_64-linux-gnu/libcurl.so (found version "7.81.0") found components: HTTP HTTPS
-- Curl 7.81.0 found on this system.

Resolving deltas: 100% (19/19), done.
mkdir -p influxdb-cxx/build
cd influxdb-cxx/build
cmake -DINFLUXCXX_TESTING=OFF -DINFLUXCXX_WITH_BOOST=OFF -Dcpr_DIR=/tmp/ifdbcxx_repro/deps/lib/cmake/cpr/ -DCMAKE_INSTALL_PREFIX=/tmp/ifdbcxx_repro/deps ..
-- The CXX compiler identification is GNU 11.4.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- ~~~ influxdb-cxx v0.7.1 ~~~
-- Build Type : RelWithDebInfo
-- Boost support : OFF
-- Unit Tests : OFF
-- System Tests : ON
-- Looking for C++ include pthread.h
-- Looking for C++ include pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Found CURL: /usr/lib/x86_64-linux-gnu/libcurl.so (found version "7.81.0")
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/ifdbcxx_repro/influxdb-cxx/build
cmake --build . -j
[ 12%] Building CXX object src/CMakeFiles/InfluxDB-Internal.dir/HTTP.cxx.o
[ 25%] Building CXX object src/CMakeFiles/InfluxDB-BoostSupport.dir/NoBoostSupport.cxx.o
[ 37%] Building CXX object src/CMakeFiles/InfluxDB-Internal.dir/LineProtocol.cxx.o
[ 62%] Building CXX object src/CMakeFiles/InfluxDB-Core.dir/Point.cxx.o
[ 62%] Building CXX object src/CMakeFiles/InfluxDB-Core.dir/InfluxDB.cxx.o
[ 75%] Building CXX object src/CMakeFiles/InfluxDB-Core.dir/InfluxDBFactory.cxx.o
[ 87%] Building CXX object src/CMakeFiles/InfluxDB-Core.dir/Proxy.cxx.o
[ 87%] Built target InfluxDB-BoostSupport
[ 87%] Built target InfluxDB-Core
[ 87%] Built target InfluxDB-Internal
[100%] Linking CXX shared library libInfluxDB.so
[100%] Built target InfluxDB
cmake --build . --target install
Consolidate compiler generated dependencies of target InfluxDB-BoostSupport
[ 12%] Built target InfluxDB-BoostSupport
Consolidate compiler generated dependencies of target InfluxDB-Internal
[ 37%] Built target InfluxDB-Internal
Consolidate compiler generated dependencies of target InfluxDB-Core
[ 87%] Built target InfluxDB-Core
[100%] Built target InfluxDB
Install the project...
-- Install configuration: "RelWithDebInfo"
-- Installing: /tmp/ifdbcxx_repro/deps/lib/libInfluxDB.so.1.0.0
-- Installing: /tmp/ifdbcxx_repro/deps/lib/libInfluxDB.so.1
-- Set runtime path of "/tmp/ifdbcxx_repro/deps/lib/libInfluxDB.so.1.0.0" to ""
-- Installing: /tmp/ifdbcxx_repro/deps/lib/libInfluxDB.so
-- Up-to-date: /tmp/ifdbcxx_repro/deps/include
-- Installing: /tmp/ifdbcxx_repro/deps/include/InfluxDBFactory.h
-- Installing: /tmp/ifdbcxx_repro/deps/include/InfluxDB.h
-- Installing: /tmp/ifdbcxx_repro/deps/include/Point.h
-- Installing: /tmp/ifdbcxx_repro/deps/include/InfluxDBException.h
-- Installing: /tmp/ifdbcxx_repro/deps/include/Proxy.h
-- Installing: /tmp/ifdbcxx_repro/deps/include/Transport.h
-- Installing: /tmp/ifdbcxx_repro/deps/include/influxdb_export.h
-- Installing: /tmp/ifdbcxx_repro/deps/lib/cmake/InfluxDB/InfluxDBTargets.cmake
-- Installing: /tmp/ifdbcxx_repro/deps/lib/cmake/InfluxDB/InfluxDBTargets-relwithdebinfo.cmake
-- Installing: /tmp/ifdbcxx_repro/deps/lib/cmake/InfluxDB/InfluxDBConfig.cmake
-- Installing: /tmp/ifdbcxx_repro/deps/lib/cmake/InfluxDB/InfluxDBConfigVersion.cmake
cd /tmp/ifdbcxx_repro/influxdb-cxx/test_package
mkdir build
cd build
cmake -DInfluxDB_DIR=/tmp/ifdbcxx_repro/deps/lib/cmake/InfluxDB/ -Dcpr_DIR=/tmp/ifdbcxx_repro/deps/lib/cmake/cpr/ ..
-- The CXX compiler identification is GNU 11.4.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found CURL: /usr/lib/x86_64-linux-gnu/libcurl.so (found version "7.81.0")
-- Looking for C++ include pthread.h
-- Looking for C++ include pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- InfluxDB 0.7.1 found
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/ifdbcxx_repro/influxdb-cxx/test_package/build
cmake --build . -j
[ 50%] Building CXX object CMakeFiles/test_package.dir/example.cpp.o
[100%] Linking CXX executable test_package
[100%] Built target test_package
./test_package
`

and it seemed to work? Not sure.

Yes, it worked :+1:. Some systems (eg. Ubuntu) need a invocation of ldconfig.

I'm closing here as the original issue been resolved and related information are added to the readme. Feel free to open a new issue or reopen if the problems still occur.


Server crash (with Tinkers)

Hi,
I opened a issue at tinker's Github, because with only Tic + Mantle and Ex Nihilo (version from today) + Forgelin -> a Server can't start = server crash.
The crash -> https://pastebin.com/9F6zb2M1
Tinker's Page -> https://github.com/SlimeKnights/TinkersConstruct/issues/3746
Versions:

Minecraft: 1.12.2
Forge: 2808 and 2810
Mantle-1.12-<IP_ADDRESS>
TConstruct-1.12.2-<IP_ADDRESS>
Foregelin: Forgelin-1.8.2
ExNihilo: exnihilocreatio-1.12-0.3.3

Edit: KnightMiner answered, that this issue is on your side.
(Ps: I don't know, whether this crash comes from you or Tinker's, thats why I open 1 issue at your page and Tinker's page.^^)

Fixed I think and uploaded a new version to curse. Thank you for reporting.

Ty

@SirLyle
https://pastebin.com/za5RZ3rX
1  other error.

See Issue #148 for this new crash.

Ah okay, Ty²


Improve Windows compatibility

Added a method to acquire the session history on windows. It doesn't get the history, and also doesn't check to see if the user has a HISTFILE environment variable. But I don't know if any windows user actually has one for CMD.
This won't work if invoked through PowerShell though, because PS uses the history command.
🙏

I don't really understand the point. It gets only the session history, but not permanent history? However, the session history is nothing as we're spawning the terminal. Can you please elaborate?

I know it doesn't get a persistent history, but getting the session's history is also a common use case (I imagine). Otherwise, if a HISTFILE env variable is set, that file should be used - because there are tools out there which persist CMD history across sessions.
Otherwise, a session history use case would be:
$ git clone https://github.com/sindresorhus/shell-history.git && alert

Where alert is an alias to node C:\\alert.js (for example), alert.js can read the session's history to make a toast notification with "git completed!" as the title.
I hope that makes more sense.

but getting the session's history is also a common use case (I imagine).

But does it actually get the history of the whole session? Like commands executed before shell-history was running.

Please always run npm test locally before committing.

The special Windows behavior (of only getting the session history) needs to be documented.

Please always run npm test locally before committing.

I tried running the tests but it just isn't working. First, there are issues because eslint-plugin-ava causes an undefined TypeError to throw, because that's how it's made. I did a clean install on WSL (which defeats the purpose of the test) which failed anyway because of the previous issue.
I then decided to skip the whole xo process (because none of Node12(Win), Node12(Linux) or Node14(Linux)) worked.
Calling node_modules/.bin/ava (both the sh and cmd variants on Win and WSL) didn't work because test.js uses ES6 syntax, which I'm not compatible with apparently...
At the end of the day, I converted test.js to Node's require syntax, called node_modules/.bin/ava and magic almost happened - I gave the test a name, and then it worked with 1 test passed.
I didn't plan on giving you my life story on trying to run XO and Ava, so sorry about that! 😅

The special Windows behavior (of only getting the session history) needs to be documented.

Doneskies.
Send feedback! 🎉

I then decided to skip the whole xo process (because none of Node12(Win), Node12(Linux) or Node14(Linux)) worked.

XO works fine on all those setups. This is a problem with your setup. But you can look at the lint failures in the Travis output and fix manually.

https://github.com/sindresorhus/shell-history/pull/5#discussion_r502087899 is not resolved. Please read my comment again. I think it's quite clear.

I don't know how to turn that into a "test" per se, but it's a visual tester I guess...

Then that should be explained.

Off-topic, but what's the benefit over toString if its default behaviour is to encode to utf8?)

No technical benefit in this case. But it's more readable to declare it upfront. It does matter when it comes to streams though, as it might end up splitting Unicode characters incorrectly.

Please spend some more time perfecting this pull request.

Bump


Git gutters don't show on filenames that have changed case

VSCode Version: 1.47.3 91899dcef7b8110878ea59626991a18c8a6a1b3e
OS Version: MacOS 10.14.6

Steps to Reproduce:
1. Initialize a git repository~
2. Add a capitalized filename, e.g. Counter.jsx
3. Commit the file
4. Make some changes in the file and save
The file will show as modified in the explorer, but the changes are not shown in the gutter. If you follow the same step but with a lowercase filename instead, the modifications will appear in the gutter. This is problematic for React projects where uppercase filenames are not uncommon.
Edit: See my modified instructions below
This issue was already brought up in #48714 and closed by 375411e, but the issue still occurs. I'm opening this new issue since the old one is locked.

Does this issue occur when all extensions are disabled?: Yes

So, the same steps with a counter.jsx works just fine?
Can you show me the entire contents of Git: Show Git Output, as you run through both scenarios: with uppercase and with lowercase?

In testing this I realize the steps I originally shared are incorrect, and the issue is more complex that I thought. It is not an issue with Uppercase files specifically, rather it has to do with changing case more generally. Specifically, it seems to happen when VSCode creates the original file, as I couldn't recreate it with a simple list of shell commands.
Here are a new list of steps that I have verified to recreate the issue, along with the output you requested:

Create a new project and open in VSCode

mkdir project && cd project
git init
code .

In the VSCode "Explorer" create a new file called "counter.jsx" with some content:

// counter.jsx
let foo;

In the VSCode terminal, commit the file to git

git add .
git commit -m "Initial commit"

Note that if you make edits to counter.jsx at this point, they will show in the gutter.

Close the open file. In the VSCode terminal, rename the file (with git) and commit the change

git mv counter.jsx Counter.jsx
git commit -m "Rename"

Click "Refresh" in the VSCode "Explorer" to see the changed filename

Now when you edit Counter.jsx, the changes don't show in the gutter.
You can follow the same steps using an originally uppercase filename that is renamed to lowercase to achieve the same results.
Here is the content of Git: Show Git Output after following the steps described here:

Click to view contents

Looking for git in: /usr/local/bin/git
Using git 2.27.0 from /usr/local/bin/git
> git rev-parse --show-toplevel
> git rev-parse --git-dir
Open repository: /Users/matt/src/temp/project
> git status -z -u
> git symbolic-ref --short HEAD
> git rev-parse master
fatal: ambiguous argument 'master': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git  [...] -- [...]'
> git for-each-ref --sort -committerdate --format %(refname) %(objectname)
> git remote --verbose
> git config --get commit.template
> git check-ignore -v -z --stdin
> git show --textconv :Other.jsx
> git ls-files --stage -- /Users/matt/src/temp/project/Other.jsx
> git config --global user.email
> git config --global user.name
> git status -z -u
> git symbolic-ref --short HEAD
> git rev-parse master
fatal: ambiguous argument 'master': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git  [...] -- [...]'
> git for-each-ref --sort -committerdate --format %(refname) %(objectname)
> git remote --verbose
> git config --get commit.template
> git check-ignore -v -z --stdin
> git show --textconv :counter.jsx
> git ls-files --stage -- /Users/matt/src/temp/project/counter.jsx
> git check-ignore -v -z --stdin
> git status -z -u
> git symbolic-ref --short HEAD
> git rev-parse master
fatal: ambiguous argument 'master': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git  [...] -- [...]'
> git for-each-ref --sort -committerdate --format %(refname) %(objectname)
> git remote --verbose
> git config --get commit.template
> git status -z -u
> git symbolic-ref --short HEAD
> git rev-parse master
fatal: ambiguous argument 'master': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git  [...] -- [...]'
> git for-each-ref --sort -committerdate --format %(refname) %(objectname)
> git remote --verbose
> git config --get commit.template
> git ls-files --stage -- /Users/matt/src/temp/project/counter.jsx
> git cat-file -s 7866c251d5ac36aaa11acd0c9a754538525cfe30
> git show --textconv :counter.jsx
> git status -z -u
> git symbolic-ref --short HEAD
> git rev-parse master
> git rev-parse --symbolic-full-name master@{u}
fatal: no upstream configured for branch 'master'
> git for-each-ref --sort -committerdate --format %(refname) %(objectname)
> git remote --verbose
> git config --get commit.template
> git status -z -u
> git symbolic-ref --short HEAD
> git rev-parse master
> git rev-parse --symbolic-full-name master@{u}
fatal: no upstream configured for branch 'master'
> git for-each-ref --sort -committerdate --format %(refname) %(objectname)
> git remote --verbose
> git config --get commit.template
> git show --textconv :counter.jsx
> git ls-files --stage -- /Users/matt/src/temp/project/counter.jsx
> git status -z -u
> git symbolic-ref --short HEAD
> git rev-parse master
> git rev-parse --symbolic-full-name master@{u}
fatal: no upstream configured for branch 'master'
> git for-each-ref --sort -committerdate --format %(refname) %(objectname)
> git remote --verbose
> git config --get commit.template

Now when you edit Counter.jsx, the changes don't show in the gutter.

Can you try the same steps but rename the file to something else like counter-2.jsx. Do the changes appear in the gutter then?

Yes, if you rename it to something with the same case like counter-new.jsx then the changes appear in the gutter. Also, in that case there is no need to refresh the explorer to see the changed file name.

@mattrossman , @joaomoreno
This issue looks related to issue#100763. Basically, vscode doesn't recognise the change in filename case.
try
mv filename.js Filename.js // vscode File explorar and filename of tab won't reflect the change
mv filename.js fileName.js //vscode File explorar and filename of tab won't reflect the change
mv filename.js abc.js // vscode File explorar and filename of tab both recognise the change and update itself

That could be the reason why git gutter does not recognise the change.

Same Issue, but file name weren't changed
It fixes itself if you clone the repo again from remote

It fixes itself if you clone the repo again from remote

@mattrossman Can you confirm this?

I'm not sure what you want me to do, I'm not using a remote in my example so it's not clear when I should be pushing or cloning. @Oran seems to be having a different issue from me since they did not change filenames.

@bpasero Here's another tough pickle for you. These are the steps: https://github.com/microsoft/vscode/issues/103444#issuecomment-666541057
What happens is: once the workbench knows about counter.jsx, it creates an editor model for it. When that file is renamed to Counter.jsx, and even after closing all text editors, upon opening the Counter.jsx text editor, its model still holds a reference to a URI which lists the lowercase variant of the file. Here's where SCM reads it and where this bug surfaces:
https://github.com/microsoft/vscode/blob/56adc7d930ad862c90f82964bb3f618d342ba177/src/vs/workbench/contrib/scm/browser/dirtydiffDecorator.ts#L1179-L1179
The bug surfaces since git is case sensitive, despite Windows being case insensitive.
More notes:

If you leave the file open and reload, the bug remains: the lowercase URI still lingers on.
You can only get rid of the bug by closing the editor and reloading. Upon opening it again, the feature works.

This is a consequence of using IUriIdentityService for text models. Once this service is used to create a URI it will stay until you restart the app. We would need some way to invalidate cached URI maybe based on file events or other things to solve this properly.

We would need some way to invalidate cached URI maybe based on file events or other things to solve this properly.

Unsure - rename is happening on a case-insensitive file system and therefore the path (in the sense of identity) isn't changing. @joaomoreno can you make your cache aware of uri identify rules? You can use IUriIdentityService#extUri and ResourceMap with the "right" toKey function

I thought the issue here was that git itself is case-sensitive, even on Windows and we rely on git to do its work. I am not sure we get a hook into git's rules of how to compare paths.

Exactly, @bpasero points to the right pickle. Git has a case sensitivity setting but this is a user configuration, we shouldn't really mess with it.

Well, I guess the uri identity service won't help you then because it doesn't know what the actual representation is. If the git is so sensitive then I am afraid that you need to resolve the true casing before interacting with git.

I was able to fix a file that had this problem by modifying the workspace state database.
By modifying memento/workbench.parts.editor, memento/workbench.editors.files.textFileEditor and codelens/cache2 to have the correct case on the filename.
While I wouldn't recommend editing the workspace state database, I am just saying it to help the developers to fix this bug.

relative to other closed threads that poke around with this issue from various angles, this seems like the place at this point.
Just wanted to share a related scenario so dev can appreciate relevance and get a sense of justification to address...
Whereas IIS servers are case insensitive, Unix webservers typically are not.
I have some ooold web pages, that were hosted on IIS servers (privately in homes initially, then on public MS/IIS based hosters) for years... recently on moving them to GitHub pages hosting, lots of stuff 'broke' (404s) in the process.
Reason being, the underlying servers on GitHub pages are not hosted via IIS on Windows which is case insensitive (same for NameCheap shared hosting requiring respect for explicit casing). In attempting to fixup the filenames (or foldernames) to match href's to those files, when using rename in the VSCode Explorer pane against the git repo... while the change appears in that VSCode pane, it (just changing an uppercase letter to lower for example in an otherwise unchanged filename) doesn't commit up to GitHub.
This thread also touches on some of the underlying issues.
A good workaround more/less highlighted in that thread (they achieve this slightly differently with git command line as seen in detail in that thread)  which works well in the VSCode GUI is as follows:
-1. rename file Name.jpg to name1.jpg <the desired casing propagates because of the additional char being a recognized change)
-2. commit removed file Name.jpg, and name1.jpg
-3. rename file name1.jpg to name.jpg
-4. commit change made in step3
(note: if you don't commit in #2, and just stage the change, and then stage the change in #3... then try to commit the 2 stages changes... you'll find the 2nd staging just nulls out your attempts to make any change and there's nothing to commit).
Thus, a vote of support for VSCode to recognize/support casing mods of an otherwise unchanged file or folder name be considered as a P3/'Nice to have' item, since non-explicit casing of folders or filenames used in URLs hosted on non-IIS servers results in 404 errors.

Please see a fix here: https://stackoverflow.com/a/11183844/518153

I'd just like to point out the bug also stretches to the built-in diff view. If you open that, select a range, right click and use "Stage selected ranges", it gets staged in git as a new file that has the original casing, with the additions from the selected range as its only content.
While that original-case file is staged, the gutters do show up in the editor for the new-case file. Trying to stage something again in the diff view appends the additions from that range to the original-casing file.
It also creates an entry for the original-case file in the unstaged changes list. Viewing the diff of this shows it as the whole file being an addition, except for the range originally marked for staging.
Unstaging the original-case file in its entirety makes everything go back to the same state as before the first stage action, in which the file is shown only once in the changes window, and the gutters are not visible.

Does it act different if case sensitivity is enabled for the directory? Can be done on NTFS and ReFS / Dev Drive.

About Dev Drive: https://aka.ms/DevDrive
About case sensitivity: https://learn.microsoft.com/en-us/windows/wsl/case-sensitivity
Enable (CMD or PowerShell as admin): fsutil.exe file setCaseSensitiveInfo <path> enable
Check: fsutil.exe file queryCaseSensitiveInfo <path>