fix iterator_input_adapter consuming input before it should

Before this PR iterator_input_adapter was indiscriminately consuming/advancing the input iterator before actually know if it should  on get_character()
Case example:

iterator_input_adapter over a custom input (ex input adapter over a stream) that can yield on iterator advance: even with strict=false the iterator_input_adapter was trying to consume one item more even if the parser or the sax implementation had return false
iterator_input_adapter over a custom input (ex vector) with multiple json chained together even with strict=false the iterator_input_adapter was consuming one char more than it should even if the parser or the sax implementation had return false

This implementation fix the issue, it advance the iterator only if the current has ben already consumed, otherwise it wait the next get_character() to actually advance the iterator

Pull request checklist
Read the Contribution Guidelines for detailed information.

[x]  Changes are described in the pull request
[x]  The test suite compiles and runs without error.
[ ]  Code coverage is 100%. Test cases can be added by editing the test suite.
[x]  The source code is amalgamated; that is, after making changes to the sources in the include/nlohmann directory, run make amalgamate to create the single-header file single_include/nlohmann/json.hpp. The whole process is described here.

Coverage remained the same at 100.0% when pulling 358970e3d0fe543dec46733c153d72c7ff20b2e3 on imwhocodes:iterator_input_adapter_fix into a94430615d8360272151f602b8c9eeb58509ecde on nlohmann:develop.

I assume this is at least somewhat related to this discussion? #3411
Can you construct a unit test that fails with develop and succeeds after your PR? (You should probably add a unit test anyway.)

I assume this is at least somewhat related to this discussion? https://github.com/nlohmann/json/discussions/3411

It could be, I'm going to check later

Can you construct a unit test that fails with develop and succeeds after your PR? (You should probably add a unit test anyway.)

Yes, I was thinking to add some unit-test too after
Should I create another fork of develop, add the test (that will fail), push, then add on that brach the fixes or the fixes should need to stay on this branch/PR?
Thanks

I assume this is at least somewhat related to this discussion? #3411

It could be, I'm going to check later

Can you construct a unit test that fails with develop and succeeds after your PR? (You should probably add a unit test anyway.)

Yes, I was thinking to add some unit-test too after Should I create another fork of develop, add the test (that will fail), push, then add on that brach the fixes or the fixes should need to stay on this branch/PR?

For small things like this you can always use Compiler Explorer.
A starting point: https://godbolt.org/z/c83xMcc77
Note that you can #include http(s) URLs, i.e., use #include <https://raw.githubusercontent.com/nlohmann/json/develop/single_include/nlohmann/json.hpp> for json.hpp from the develop branch.

@falbrechtskirchinger
Here is a link to Compiler Explorer with an example of failure case

@falbrechtskirchinger Here is a link to Compiler Explorer with an example of failure case

Thanks! That demonstrates the issue clearly enough.

@falbrechtskirchinger @nlohmann should be now strict exposed as parameter (defaulted to true) by static basic_json parse( ..... , const bool strict = true) ?

@falbrechtskirchinger @nlohmann should be now strict exposed as parameter (defaulted to true) by static basic_json parse( ..... , const bool strict = true) ?

Does this allow to finally parse JSON lines (https://json.nlohmann.me/features/parsing/json_lines/)?

Does this allow to finally parse JSON lines (https://json.nlohmann.me/features/parsing/json_lines/)?

Sorry can you expand on that? what is not working about json_lines?

@imwhocodes Can you please check the comments?

Just came back from holiday, gonna address in this days

@imwhocodes Is there anything I can do to support this?

@imwhocodes Do you have a test case that demonstrates this error?

@imwhocodes Do you have a test case that demonstrates this error?

See quote below. I can share my test case which fails to reproduce the issue later.

@falbrechtskirchinger Here is a link to Compiler Explorer with an example of failure case
Edit: extended test

Sorry everybody for the delay,
I added simple test case for the fix itself: is almost the same as the one used for the "Compiler Explorer" examples
Thanks for the patience

@imwhocodes I could not independently write a test that would trigger your issue. Guess I should make that available so we can compare and figure out who's right.

@imwhocodes I could not independently write a test that would trigger your issue. Guess I should make that available so we can compare and figure out who's right.
Edit: To be crystal clear: I don't believe there's an issue to fix.

Can you show me your test case?
The situation where the current (not fixed) implementation fail is on an input iterator where the action of reading actually remove from the underlaying buffer, ex:

recv on socket
Arduino Stream
generic input stream

The current (not fixed) implementation of json::details::iterator_input_adapter actually consume from the underlaying buffer one char ahead of the one returned to the upper layer, ending up already consuming one char past the end of the json on when parsing stop
On the link you can see this happening, you can change #define USE_FIX false on the top to see the difference
Here for any question,
Luca

@imwhocodes I could not independently write a test that would trigger your issue. Guess I should make that available so we can compare and figure out who's right.
Edit: To be crystal clear: I don't believe there's an issue to fix.

Can you show me your test case?
The situation where the current (not fixed) implementation fail is on an input iterator where the action of reading actually remove from the underlaying buffer, ex:

Ok, I understand the problem now. It's about advancing the iterator vs. dereferencing it. You can look at my test case in PR #3531. Either way, your fix breaks my use case.
I'll need to look at it a bit closer when I have some spare time, meaning not right now.

@imwhocodes I could not independently write a test that would trigger your issue. Guess I should make that available so we can compare and figure out who's right.
Edit: To be crystal clear: I don't believe there's an issue to fix.

Can you show me your test case?
The situation where the current (not fixed) implementation fail is on an input iterator where the action of reading actually remove from the underlaying buffer, ex:

Ok, I understand the problem now. It's about advancing the iterator vs. dereferencing it. You can look at my test case in PR #3531. Either way, your fix breaks my use case.
I'll need to look at it a bit closer when I have some spare time, meaning not right now.

The logic problem with your test is that you are de-referencing a pointer to the last read char,  and given the fact that you passing strict = true to the sax_parser it is correct that the pointer/iterator point to the last char parsed.
When you deference you iterator again to check where you are you are consuming the same char again (the last parsed by the parser)

@imwhocodes I could not independently write a test that would trigger your issue. Guess I should make that available so we can compare and figure out who's right.
Edit: To be crystal clear: I don't believe there's an issue to fix.

Can you show me your test case?
The situation where the current (not fixed) implementation fail is on an input iterator where the action of reading actually remove from the underlaying buffer, ex:

Ok, I understand the problem now. It's about advancing the iterator vs. dereferencing it. You can look at my test case in PR #3531. Either way, your fix breaks my use case.
I'll need to look at it a bit closer when I have some spare time, meaning not right now.

The logic problem with your test is that you are de-referencing a pointer to the last read char, and given the fact that you passing strict = true to the sax_parser it is correct that the pointer/iterator point to the last char parsed.
When you deference you iterator again to check where you are you are consuming the same char again (the last parsed by the parser)

Dereferencing the same iterator more than once should yield the same value, shouldn't it? After all "iterators are generalized pointers" (to quote the standard) and should have similar semantics.

Here lay the problem, on your test iterator end up were it actually should be, if it would end up one char after the parameter strict = true would be simply broken

I agree, it ends up where it should end up unless I apply this patch. ;-)
Your code can easily be modified to work correctly with the current iterator_input_adapter implementation: https://godbolt.org/z/zvsxvPPs5
Why is the current iterator_input_adapter implementation wrong?
I'm interested in a 4.0 parse() function that returns the iterator where processing stopped. My test uses the proxy_iterator class to achieve this behavior with the current API. Your "fix" breaks both the workaround as well as any (future) proper implementation returning the internal iterator from the iterator_input_adapter. Thoughts?
If there's something to fix, it's maybe in the parser, and I'd argue that with strict = false you can achieve your desired behavior either way.
Also, I can't shake my initial impression of this being an unnecessary pessimization for most users (hopefully negligible thanks to modern branch predictors).

Got it, yes moving the "consumed" logic to the upper layer is a solution too, but beware that this problem (the internally advancing the pointer before consuming) affect the https://json.nlohmann.me/api/basic_json/operator_gtgt/ operator too (but the is another bug too on in)

I'm aware of the operator>> issue and unfortunately, your proposed fix for that has similar problems and breaks existing code.
There're certainly improvements (requiring breaking changes) to be made and I hope 4.0 will do so.
Maybe the operators should avoid strict = true.

I'm aware of the operator>> issue and unfortunately, your proposed fix for that has similar problems and breaks existing code.
There're certainly improvements (requiring breaking changes) to be made and I hope 4.0 will do so.
Maybe the operators should avoid strict = true.

Yes the operator for sure should not use strict, but the underlaying problem that while parsing one char more is consumed remains
Now I'm trying to write an std::istream example but is seem like the input_adapter constructor for that type was market deleted recently
When I was doing my testing before this PR iterating over a std::istream it had the same behaviour of consuming one char more that is should (even if you internally change strict = false  one char more is consumed because the internal pointer advance before it should)
(I have a local branch were I was address that issue too)

@falbrechtskirchinger sorry but this example that you give me is broken too (undefined behaviour)
You are getting the value when you deference the iterator pointer, but the pointer could be already the iterator::end
So technically UB by deferencing end iterator
Here is a failing test for your example, I had to move from std::string to std::vector otherwise there would be the hidden null-terminator of string masking the bug, as you can see the program crashes

I've taken a closer look and even though I'd recommend changes to both operator!= and operator++, the code works just fine with correct JSON input. Did you remove those last few characters on purpose?
...,'u','e','_','B' };

After completing the input as follows the assertion succeedes.
...,'u','e','_','B','"','}' };

And here's the updated code with some improvements to the operators:
https://godbolt.org/z/Ee1Pr3Gse
Possibly still not 100% correct but at least closer.

I've taken a closer look and even though I'd recommend changes to both operator!= and operator++, the code works just fine with correct JSON input. Did you remove those last few characters on purpose?
...,'u','e','_','B' };

After completing the input as follows the assertion succeedes.
...,'u','e','_','B','"','}' };

Yes I removed on purpose to show you that on incomplete input your solution is UB
About that:

And here's the updated code with some improvements to the operators: https://godbolt.org/z/Ee1Pr3Gse
Possibly still not 100% correct but at least closer.

This is not valid solution, on a STREAM-like input you don't have empty() or size() function, so you CANNOT know ahead how much data you have left, it is a stream, a flow like of information, not a container

@falbrechtskirchinger sorry but this example that you give me is broken too (undefined behaviour)

Well, this is your code. :-) I assumed you knew that your operator!= was broken. There's more work needed, but I'm confident it's possible.

I'm honestly thinking that you are trolling me, the broken code is taken from your message, with your proposed solution, this message exactly:

Your code can easily be modified to work correctly with the current iterator_input_adapter implementation: https://godbolt.org/z/zvsxvPPs5

I modified the pertinent bits of your code to make the unaltered example work. operator!= is broken in the sense that I can construct two instances of EmulateStream that return an unexpected result for operator!=. You can call that UB if you want.

Code example where you moved the ConsumeChar logic from EmulateStream & operator++() to reference operator*() const
    reference operator*() const {
        if(!consumed) {
            c = ConsumeChar(target);
            consumed = true;
        }
        return c;
    }

And you proposed as solution, solution where end iterator is dereferenced
I still don't see that happening, sorry. iterator_input_adapter does not dereference the end iterator (EmulateStream).

As you can see on my initial test case (here edited to be more clear) the operator!= is not broken and fully working

Yes I removed on purpose to show you that on incomplete input your solution is UB

How? The program is crashing on your assertion, not because the end iterator is dereferenced?

This is not valid solution, on a STREAM-like input you don't have empty() or size() function, so you CANNOT know ahead how much data you have left, it is a stream, a flow like of information, not a container

Well, the iterator_input_adapter needs to know, if it's reached the end…

@falbrechtskirchinger ok lets start fresh:
This is your proposed solution: to obtaining the char value during reference operator*() const but as you can see here this is broken because you can dereference a ::end pointer, to make it clear I changed  str->front() (UB) with str->at(0) (Throw)
This is mine original solution:  to obtaining the char value during EmulateStream & operator++() and then returning it on reference operator*() const, as you can see here, like this you can learn if it underlying stream is finished without the need on non-existent function like empty() or size(), in the example you can see a try/catch to manage end of stream
Said that my solution can work only if the upper layer (the parser) don't try to read one char more than needed, as you can see if on the top line you change #define USE_FIX true this will use current master, and you will notice on the terminal that more char are parsed than what they should

This happen because in current master input_adapter is advanced before actual consuming of the data, so you end up to it pointing one char before the last char read.
If the underlying data is a STREAM which is NOT a container (so you don't either have .size(), .empty() or dereference operator) advancing the iterator mean consuming one char from the stream itself.
If you read the last 2 sentences you can understand where one char is lost

@falbrechtskirchinger ok lets start fresh:
This is your proposed solution: to obtaining the char value during reference operator*() const but as you can see here this is broken because you can dereference a ::end pointer, to make it clear I changed str->front() (UB) with str->at(0) (Throw)

So, I finally reproduced the dereference you were talking about. You're not using the last code I posted, which includes tweaked operator== and operator!= which does avoid the dereference of the end iterator.
This is why we were talking past one another. We were using different code.
Here's the quote with the update:

And here's the updated code with some improvements to the operators: https://godbolt.org/z/Ee1Pr3Gse
Possibly still not 100% correct but at least closer.

@falbrechtskirchinger ok lets start fresh:
This is your proposed solution: to obtaining the char value during reference operator*() const but as you can see here this is broken because you can dereference a ::end pointer, to make it clear I changed str->front() (UB) with str->at(0) (Throw)

So, I finally reproduced the dereference you were talking about. You're not using the last code I posted, which includes tweaked operator== and operator!= which does avoid the dereference of the end iterator.
This is why we were talking past one another. We were using different code.
Here's the quote with the update:

And here's the updated code with some improvements to the operators: https://godbolt.org/z/Ee1Pr3Gse
Possibly still not 100% correct but at least closer.

Yes i have seen the code at https://godbolt.org/z/Ee1Pr3Gse and this is why I'm telling you that it is not valid, if we want this to work with a stream (even simply std::iostream) we can NOT use .empty() or .size() member function because they do NOT exist on a stream like input, is it not a container it is a stream, it can me either open or closed, it has no size

I've read your message.
You're trying to shoehorn a stream into the iterator interface. If you insist on parsing JSON directly from a stream, it's on you to find a way to make it work. My point is that the library code is working as intended and your "fix" breaks other valid code. I'm sorry I didn't catch this right at the beginning.
If you want help with your iterator code for a specific stream API (beyond the contrived examples using std::string and std::vector), open a discussion. I'm happy to help whenever I have time. There's always some mechanism to tell if a stream is at the end. As a last resort, you can try reading from it, but there's probably a better way.
Let me address one more point of your argument directly:

(...) you will notice on the terminal that more char are parsed than what they should if using current master

This happen because in current master input_adapter is advanced before actual consuming of the data, so you end up to it pointing one char before the last char read.

Advancing the iterator to the next character should never be a problem. I'll quote the standard to you again: "Iterators are generalized pointers". They are supposed to follow similar semantics.
Because your implementation reads on the advance, you'll inevitably run into problems. You're violating the expected semantics and complain that the result isn't what you want.
@nlohmann @gregmarr We've reached a stalemate and need someone else to chime in.

I've read your message.
You're trying to shoehorn a stream into the iterator interface. If you insist on parsing JSON directly from a stream, it's on you to find a way to make it work. My point is that the library code is working as intended and your "fix" breaks other valid code. I'm sorry I didn't catch this right at the beginning.
If you want help with your iterator code for a specific stream API (beyond the contrived examples using std::string and std::vector), open a discussion. I'm happy to help whenever I have time. There's always some mechanism to tell if a stream is at the end. As a last resort, you can try reading from it, but there's probably a better way.
Let me address one more point of your argument directly:

(...) you will notice on the terminal that more char are parsed than what they should if using current master

This happen because in current master input_adapter is advanced before actual consuming of the data, so you end up to it pointing one char before the last char read.

Advancing the iterator to the next character should never be a problem. I'll quote the standard to you again: "Iterators are generalized pointers". They are supposed to follow similar semantics. Because your implementation reads on the advance, you'll inevitably run into problems. You're violating the expected semantics and complain that the result isn't what you want.
@nlohmann @gregmarr We've reached a stalemate and need someone else to chime in.

The real scenario problem it is not about knowing if the stream is closed, but it is that on the current input_adapter implementation one char is always read ahead, this mean that if you receive one json on a socket you need the first char of the second to finish parsing the first, and the second one will fail missing it's own first char
IMHO reading on std::advance is the best way, for sure not during deferencing on the custom adapter, I don't see any problem about it, if it is valid you keep running otherwise you return ::end and the parser will manage it
About breaking the API I don't think it is true, all ctest pass correctly and final behaviour is the same for all common function
My idea is it that it is better to have the input_adapter pointing to the last consumed iterator/value so leaving the door open to any stream implementation (and in your proxy_adapter simply do a ++ to get from where start parsing again or whatever) rather than closing it away, at least like this you have both option at your disposal
Giving some context: personally I started using nlohmann::json for the very powerfull combo of the sax_parser with a stream as input, giving me the ability to parse json and msgpack that are bigger than the available ram  with a custom sax_parser keeping only the data which I'm actually interested (and also without any heap allocations, mostly on MCUs)
This is way i keep pushing on it, it is a real (and mostly hidden) killer feature of this library
Anyway let see what @nlohmann @gregmarr think,
Luca

The real scenario problem it is not about knowing if the stream is closed, but it is that on the current input_adapter implementation one char is always read ahead, (...)

You can avoid that with strict = false. See https://godbolt.org/z/Ee1Pr3Gse.

About breaking the API I don't think it is true, all ctest pass correctly and final behaviour is the same for all common function

It's a breaking change and I've demonstrated why. Passing the unit tests does not invalidate that assertion.

My idea is it that it is better to have the input_adapter pointing to the last consumed iterator/value so leaving the door open to any stream implementation (and in your proxy_adapter simply do a ++ to get from where start parsing again or whatever) rather than closing it away, at least like this you have both option at your disposal

You're breaking expected iterator semantics. The past-the-end iterator points past the end because otherwise, we'd have no way to represent an empty range. You're suggestion to "simply do a ++" would not be sound because of this.

Giving some context: personally I started using nlohmann::json for the very powerfull combo of the sax_parser with a stream as input, giving me the ability to parse json and msgpack that are bigger than the available ram with a custom sax_parser keeping only the data which I'm actually interested (and also without any heap allocations, mostly on MCUs) This is way i keep pushing on it, it is a real (and mostly hidden) killer feature of this library

Nothing prevents you from doing that. You can implement your own iterator to behave as you describe. Just don't break iterator semantics for everyone else because it's convenient for one use case out of many.
Any C++ developer, understanding common iterator semantics, can implement your behavior on top of the current implementation without special knowledge about the implementation. Your "fix" changes semantics in a way where that'd no longer be true, as the past-the-end iterator no longer points past the end, but at the end (which is impossible in case of an empty range, creating another problem).
In summary: C++ developers understand iterators, they expect them to follow established rules. The concept of the past-the-end iterator is fundamental, don't mess with that. What you want can be done without modifying the library code.
I rest my case.

I've looked at the discussion, and thought a lot about this, and done some researching, and I'm still not sure if it's possible to "fix" this use case at this level.  I looked at https://en.cppreference.com/w/cpp/iterator/istream_iterator and it seems like it should be possible for the stream iterator itself, rather than the json adapter, to handle this.  However, the EmulateStream in the example seems to do exactly what I expect the stream iterator does.
I don't know how to reconcile the "leaving the iterator pointing at the last thing read" with "the iterator needs to be pointing to the next thing to read in order to start parsing".
On the other hand, there is no visible change as far as the caller of iterator_input_adapter::get_character() is concerned, and that's the only API that class has.
There are two callers of that function.  One has unget() support, and the other doesn't.  Could the real problem be the lack of unget() support in binary_reader.hpp?

@falbrechtskirchinger

Because your implementation reads on the advance, you'll inevitably run into problems. You're violating the expected semantics and complain that the result isn't what you want.

That's what std::istream_iterator does too.
https://en.cppreference.com/w/cpp/iterator/istream_iterator

std::istream_iterator is a single-pass input iterator that reads successive objects of type T from the std::basic_istream object for which it was constructed, by calling the appropriate operator>>. The actual read operation is performed when the iterator is incremented, not when it is dereferenced. The first object is read when the iterator is constructed. Dereferencing only returns a copy of the most recently read object.

The real scenario problem it is not about knowing if the stream is closed, but it is that on the current input_adapter implementation one char is always read ahead, this mean that if you receive one json on a socket you need the first char of the second to finish parsing the first, and the second one will fail missing it's own first char

@falbrechtskirchinger

Because your implementation reads on the advance, you'll inevitably run into problems. You're violating the expected semantics and complain that the result isn't what you want.

That's what std::istream_iterator does too.

The difference being that std::istream_iterator is designed to be an adapter between streams and iterators. iterator_input_adapter is an adapter between the parser interface (i.e., get_character()) and iterators (i.e., NOT streams).
If you want a stream_like_input_adapter, build one, and let's add that. I've no objections to a solution that doesn't break iterator_input_adapter's current behavior.

@falbrechtskirchinger I just went looking through the discussions in this PR for it and couldn't find it. Can you remind me again which case is broken with this change?

See #3548.

Thanks, that makes sense.  I hadn't been considering the underlying iterator surviving beyond the adapter.

@falbrechtskirchinger

Because your implementation reads on the advance, you'll inevitably run into problems. You're violating the expected semantics and complain that the result isn't what you want.

That's what std::istream_iterator does too.

Another thought: Combining an EmulateStream that reads on advance with the proxy_iterator from #3548 should also work. The problem is that since normally you lose access to the iterator, the character that has already been read from the underlying stream is lost.
Once again, there are several (external) solutions to this problem. Ideally, we should work towards making input_adapter part of the public API and allow users to pass an input_adapter to parse() directly.

Is some way I cannot understand why we should preserve an internal behaviour that is not defined by the API, on the other side is possible that people is relaying on that hidden/implicit behaviour
What I'm proposing now is to split input_adapter like this, with the use of some SFINAE and/or std::iterator_traits:

Keep current implementation of input_adapter but mark it as deprecated
If user_iterator is derived from std::forward_iterator use current implementation
If user_iterator is derived from std::istream_iterator use proposed implementation

What do you think about it? @gregmarr @falbrechtskirchinger

Combining an EmulateStream that reads on advance with the proxy_iterator from https://github.com/nlohmann/json/pull/3548 should also work. The problem is that since normally you lose access to the iterator, the character that has already been read from the underlying stream is lost.

I took a stringstream, created an istream_iterator on it, wrapped it in minor modification to the proxy_iterator that takes the iterator type instead of the container type, and that works.  If sax_parse returned the iterator at the end, that would eliminate the need for the proxy_iterator.  Since it doesn't, you need the disposable wrapper so you can keep the istream_iterator that potentially contains the next character around to use it for the next sax_parse.
https://godbolt.org/z/M5cYfbcbW

Combining an EmulateStream that reads on advance with the proxy_iterator from #3548 should also work. The problem is that since normally you lose access to the iterator, the character that has already been read from the underlying stream is lost.

I took a stringstream, created an istream_iterator on it, wrapped it in minor modification to the proxy_iterator that takes the iterator type instead of the container type, and that works. If sax_parse returned the iterator at the end, that would eliminate the need for the proxy_iterator. Since it doesn't, you need the disposable wrapper so you can keep the istream_iterator that potentially contains the next character around to use it for the next sax_parse.
https://godbolt.org/z/M5cYfbcbW

Got it, but now you need to always keep the istream_iterator around in scope, otherwise when it get destructed you lost a char
See https://godbolt.org/z/1f9sGW6cE (btw funny that losing one char make the json still valid but with a different meaning)
Still more convinced that the previously proposed could be a good solution managing all scenario:

Is some way I cannot understand why we should preserve an internal behaviour that is not defined by the API, on the other side is possible that people is relaying on that hidden/implicit behaviour
What I'm proposing now is to split input_adapter like this, with the use of some SFINAE and/or std::iterator_traits:

Keep current implementation of input_adapter but mark it as deprecated
If user_iterator is derived from std::forward_iterator use current implementation
If user_iterator is derived from std::istream_iterator use proposed implementation

What do you think about it? @gregmarr @falbrechtskirchinger

How should we proceed here?

As is, this PR would conflict with #3548. Unless @imwhocodes wants to try another solution, this can be closed.


Default values for variables

It would be great to have the ability to access a default value assigned to a variable.
I would like to contribute if possible, just need some opinions and directions! :)
👍

that could be useful, the way I'd approach it would be to add tests to parser that has default value and then see whether sourcekitten feeds as those values, if not then you'd need to write manual parsing similar to how we are parsing annotations or typealiases

I first wanted to suggest to support method parameters default values for the sake of the consistency, but than I thought, how exactly that can be used in templates?
Also default property values are not required to be simple literals, so it can be for example a method call or even a complex closure call, how that can be used in a template?

yeah I'm not sure about the use-case here as well, @txaiwieser what were you thinking about?

If we don't hear any reasonable use-case this week then we should probably close this

My use case is related to the one I posted in issue #210. I start Sourcery on a certain class. For certain methods I find in that class I generate new classes. Each class has a property for every parameter of the orginal method. So, e.g., I find a method
func drawButton(showBorder: Bool = true, borderColor: UIColor = .red)
I generate
class MyButton : UIButton {   showBorder : Bool,   borderColor: UIColor ...}
and, naturally, I would like to reuse the original default parameter, e.g.,
class MyButton : UIButton {   showBorder : Bool = true,   borderColor: UIColor = .red ...}

By now I created a workaround by reparsing Sourcery's Method.name and grabbing the information from there. But that really feels like unnecessary overhead.

To comment on ilyapuchka's comment above: I think my usecase would be just the same if the default values would be more complicated like complete closures. But my workaround mentioned above would stop to function. I know by construction of the code I scan with Sourcery that there will be no complex expressions. But in the general case you would have to expose the whole Expression class of the AST to do this, I realize from that comment. So, here are a few remarks with respect to that:

you could just expose the default value as an unstructured string, as - I think - you do in other places as well
if you expose the complete expression structure you could also greatly extend Sourcery in other places. E.g., you could give access to the method bodies as well.


Fix the installation on Mac OS X.

Fix the building process on Mac OS X. Please refers to the commit message of e78352e for details.
Also, I added requirements.txt for simplifying the requirements installation.
Please feel free to let me know if you have any concern regarding to this PR.
Thanks.

Looks nice. Ping @yangarbiter
What's .ropeproject in gitignore though?

Hmm... it's generated by my Vim & Rope, which is a coding style checking
library: https://github.com/python-rope/rope.
If we're not using Rope, I can rebase the commit and remove this line.
Thanks.
SC Lee<EMAIL_ADDRESS>於 2015年12月9日 週三 下午7:53寫道：

Looks nice. Ping @yangarbiter https://github.com/yangarbiter
What's .ropeproject in gitignore though?
—
Reply to this email directly or view it on GitHub
https://github.com/lsc36/libact/pull/5#issuecomment-163199946.

--
Chih-Wei (Bert)

Looks nice! Though I don't have a Mac OS X to test it, but it seems okey for me to merge.

Remove the .ropeproject and I'll merge this. Thanks.

Done.


Check, why mobile score is marked as passed then scored below 80 points

chart's score background are defined by CSS, desktop is set to 80 and mobile is set to 60 at the moment.

why we have 60 on mobile?

There is no particular reason for 60, but I think that we will have different pass scores for mobile and desktop.

Google, not us decides, then score is "passed".
Just replicate "passing" score value from google.


can't build boost 1.75.0 without c++11 because of b2 requires C ++11

Yes, you can. You just need C++11 support to build b2. Once that is done, you can build all the rest of boost with C++03. (Ok, most of boost; some of the libraries require C++11 or 14 or 17)


fix(driver): remove some inconsistencies in our event tables

What type of PR is this?
/kind bug
Any specific area of the project related to this PR?
/area driver-kmod
/area driver-bpf
/area driver-modern-bpf
Does this PR require a change in the driver versions?
What this PR does / why we need it:
Working on #889 we discovered some inconsistencies in our tables, this PR tries to address them:

use specific instrumentation with some syscalls that were wrongly treated as generic. We already had events and fillers for these syscalls but for some reason, we considered them generic :/ More in detail syscalls that changed behavior are:

umount
lstat64
sendv
recv

assign to all unknown events the same name NA
add some forgotten EF_OLD_VERSION flags

Which issue(s) this PR fixes:
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
fix(driver): remove some inconsistencies in our event tables

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Andreagit97
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Andreagit97]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

while however keeping the overloaded event name "umount" to not break Falco rules and stay consistent with the "accept" case which points to both accept, accept4 syscalls.
Btw this is something we can consider to break, but this would need to be timed with a breaking Falco release and we can discuss if Falco 0.35 should be the one. Personally would vote to break and refactor it down the road, so that Falco rules always have to use the exact syscall names, but from my perspective it does not need to happen now.

@incertum What I like to better understand is whether the flags are actually consumed in the upper stack. I did a grep in libs, falco, rules, and did not find any consumer. Maybe, the break comes finally down to just re-define the event definition and have an event w/o flags for it while introducing the umount2 with the existing filler implementation.

Btw this is something we can consider to break, but this would need to be timed with a breaking Falco release and we can discuss if Falco 0.35 should be the one. Personally would vote to break and refactor it down the road, so that Falco rules always have to use the exact syscall names, but from my perspective it does not need to happen now.

I definitely agree with that, we definitely need to address all these issues one time for all. Here https://github.com/falcosecurity/libs/issues/911 i've tracked all the inconsistencies we have found right now...
Not sure what is the best way to address them... I already have another branch to address some of them and changes are not just a few lines probably so probably I would merge these fixes and then iterate over them, WDYT? (just for visibility this is the branch https://github.com/falcosecurity/libs/compare/master...Andreagit97:support_missing_syscalls?expand=1)

@incertum What I like to better understand is whether the flags are actually consumed in the upper stack. I did a grep in libs, falco, rules, and did not find any consumer. Maybe, the break comes finally down to just re-define the event definition and have an event w/o flags for it while introducing the umount2 with the existing filler implementation.

I didn't catch which flags we are talking about here... btw yes agree with you that we need to redefine it, not sure if we want to do that here

@incertum What I like to better understand is whether the flags are actually consumed in the upper stack. I did a grep in libs, falco, rules, and did not find any consumer. Maybe, the break comes finally down to just re-define the event definition and have an event w/o flags for it while introducing the umount2 with the existing filler implementation.

Correct Falco has no upstream rule atm that uses umount as evt.type, when I once checked it wasn't working, but that was a good time ago, probably before we introduced umount2? I think requiring umount2 in Falco rules is a good choice, but it's a big breaking paradigm change in general that goes beyond umount and also applies to other cases, so would say everyone should be on board with this, especially the Falco repo maintainers and it wouldn't be a change for this PR.
Decision for this PR seems to be: Do we want to keep umount as generic syscall or go with the change proposed here plus @hbrueckner as you pointed out finalize the complete change so we wrap it up? Would be fine either way as it seems the old umount is not relevant on most systems, but for completeness wanted to bring it up. @Andreagit97 feel free to make a call.

Btw this is something we can consider to break, but this would need to be timed with a breaking Falco release and we can discuss if Falco 0.35 should be the one. Personally would vote to break and refactor it down the road, so that Falco rules always have to use the exact syscall names, but from my perspective it does not need to happen now.

I definitely agree with that, we need to address all these issues one time for all. Here #911 i've tracked all the inconsistencies we have found right now... Not sure what is the best way to address them... I already have another branch to address some of them and changes are not just a few lines probably so probably I would merge these fixes and then iterate over them, WDYT? (just for visibility this is the branch https://github.com/falcosecurity/libs/compare/master...Andreagit97:support_missing_syscalls?expand=1)

Very much on board, love it, as said above @jasondellaluce and other Falco repo maintainers should definitely be on board with it given the broader end user implications.

/milestone 0.11.0

Given so, my personal take would be to prefer fixing these all together instead of one-by-one and add a clear notice in the release changelog.

The only issue in doing a one-shot is that the PR would be huge, this branch https://github.com/falcosecurity/libs/compare/master...Andreagit97:support_missing_syscalls?expand=1 addresses just 4 of them and it is already huge :/ (there are also some tests inside)

Now, since in 0.35.0 we are breaking-revisiting the whole syscall selection and adaptiveness notions, I think 0.35.0 would a good candidate for this kind of breaking changes too (but I'm open to also postpone it if someone is not onboard).

Agree with this, since we are working on all those tables refactors and breaking changes this seems the right moment to address them

cc @falcosecurity/libs-maintainers for visibility.

@jasondellaluce and @Andreagit97 leaving another comment to re-iterate that I would be all for implementing all these changes for Falco 0.35, afterwards we should stabilize :) Therefore, explicitly approving to require each system call (including variants) to be called by the official syscall string name in the Falco rules.
Re pre-release timing for testing, let's finish the umount refactor here in this PR, but keep the shared umount event name for both umount and umount2 for now, after that we should bump libs in Falco so we can move forward with testing. Then we start the breaking change libs refactors?

I've pushed 2 new commits:

the first one creates a new event pair for umount syscall -> PPME_SYSCALL_UMOUNT_1_E/X. With this commit, umount2 syscall is still associated with the old event pair and the event name is "umount"
the second one creates a new event pair also for umount2 syscall -> PPME_SYSCALL_UMOUNT2_E/X. This second commit should solve our issues with "umount family" syscalls.

and i have to rebase :(

rebased :)

Re pre-release timing for testing, let's finish the umount refactor here in this PR, but keep the shared umount event name for both umount and umount2 for now, after that we should bump libs in Falco so we can move forward with testing. Then we start the breaking change libs refactors?

Not sure why we want to keep the single name umount since we have to address also this before the final release :thinking: BTW I left it as a last commit in this way we can use the previous commit to bump libs in Falco

Not sure why we want to keep the single name umount since we have to address also this before the final release thinking BTW I left it as a last commit in this way we can use the previous commit to bump libs in Falco

Because of the way we currently resolve Falco rules evt.type strings to syscalls etc, hence also why all the tests are failing. See https://github.com/falcosecurity/libs/pull/936#discussion_r1127104066

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Andreagit97, incertum
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Andreagit97,incertum]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: 1dcd7fea5b32a867124e96275c1379ebfd8ae0f1

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Andreagit97, incertum, jasondellaluce
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Andreagit97,incertum,jasondellaluce]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Sync master with live

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/Consume-Packages/Reinstalling-and-Updating-Packages.md
:white_check_mark:Succeeded

docs/Guides/Create-Cross-Platform-Packages.md
:white_check_mark:Succeeded

docs/Schema/nuspec.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Release v0.7.6

/cc @zekisherif, @faern, I know the both of you were waiting on this.

New version is released.

:+1:


Update CUB version in the cmake build.

yeah, I think a push will be better, there are more fixes we want externally.


Workflow errors tab

Tab out whole left pane, tab out just the connection table?

No, this will be implemented as popup messages next to an error gutter that will appear when a workflow has errors


Upgrade expat to version 2.4.1

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

[x] The toolchain has been rebuilt successfully (or no changes were made to it)
[x] The toolchain/worker package manifests are up-to-date
[x] Any updated packages successfully build (or no packages were changed)
[x] Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
[x] All package sources are available
[x] cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/tools/cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
[x] LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/data/licenses.json, ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
[x] All source files have up-to-date hashes in the *.signatures.json files
[x] sudo make go-tidy-all and sudo make go-test-coverage pass
[x] Documentation has been updated to match any changes to the build system
[x] Ready to merge

Summary

What does the PR accomplish, why was it needed?
Upgrade expat version to fix CVE-2019-15903
Change Log

Upgrade expat package version to 2.4.1

Does this affect the toolchain?

NO
Associated issues

Links to CVEs

https://nvd.nist.gov/vuln/detail/CVE-2019-15903

Test Methodology

Build in local machine

Another thing: please make sure to check whether the packages that depend on this package need to be rebuilt (I think python3's xml module might need a rebuild).

expat is already a 2.4.6.  Closing this PR


fonttools crashes on MFEKglif-produced .glif files because they contain <lib />

To be clear, I'm the principal author and maintainer of MFEK/glif.
But I don't view this as a bug in my software.
Traceback (most recent call last):
  File "/home/fred/Workspace/MFEKglif/./glif2svg.py", line 50, in <module>
    glifLib.readGlyphFromString(f.read(), glyph, ptsp)
  File "/home/fred/.local/lib/python3.9/site-packages/fonttools-4.19.2.dev0-py3.9.egg/fontTools/ufoLib/glifLib.py", line 650, in readGlyphFromString
    _readGlyphFromTree(
  File "/home/fred/.local/lib/python3.9/site-packages/fonttools-4.19.2.dev0-py3.9.egg/fontTools/ufoLib/glifLib.py", line 1031, in _readGlyphFromTree
    readGlyphFromTree(
  File "/home/fred/.local/lib/python3.9/site-packages/fonttools-4.19.2.dev0-py3.9.egg/fontTools/ufoLib/glifLib.py", line 1159, in _readGlyphFromTreeFormat2
    _readLib(glyphObject, element, validate)
  File "/home/fred/.local/lib/python3.9/site-packages/fonttools-4.19.2.dev0-py3.9.egg/fontTools/ufoLib/glifLib.py", line 1202, in _readLib
    assert len(lib) == 1
AssertionError

Glyph:
<?xml version="1.0" encoding="UTF-8"?>
<glyph format="2" name="space">
  <advance width="1282" />
  <unicode hex="20" />
  <anchor x="631" name="Anchor-0" y="1048" />
  <lib />
</glyph>

The empty <lib/> should be OK. This also means fontmake can't understand MFEKglif-produced glyphs. I think fonttools should be more tolerant of empty <lib/>'s.

I'm not sure why that assertion that lib element is not empty and has some children is there in the first place, it seems to be like that since forever, see git blame
https://github.com/fonttools/fonttools/commit/a2895df22f5d9a4d4b15c20b8009cce14d258b8b#diff-f8c8b522f847849ae3baa115ec6618fb0abec0c8bbfd5488fa33d16538b61a31R931
Does the UFO spec say something about it?
I'd be ok with relaxing that.

FWIW the ufoNormalizer seem to accept such empty lib elements in GLIF -- it just drops them
https://github.com/unified-font-object/ufoNormalizer/blob/783ec1479ed35f26a9992cb18927f1902207b0af/src/ufonormalizer/__init__.py#L817-L818

Spec says:
lib must have one child element that is structure as a dictionary formatted as an XML Property List.

But that doesn't sound right or XML-conformant to me?

I see that. So the spec wants you to have an inner <dict/> element inside your empty lib. It expects one, I'm afraid. So you either remove the whole parent lib element if its dict element is empty or you keep it but leave the first-only dict (empty) child in, along with the parent lib. You can raise the issue at the UFO spec repository if you like.

XML-conformant to me?

it's not about XML conformancy here, but UFO's, which can define whatever XML elements should be required or not.

as I said, i'd be fine with relaxing this, a hard crash is no better than a silent skip, as there's no much one can do with such an empty lib. But it'd be also advisable to relax the wording of the spec itself. Can you work on some PRs to both ufo-spec and fonttools?

Yup, can do. And XML conformance should matter because <?xml version="1.0" encoding="UTF-8"?>.

UFO is built on top of XML but it is free to say "this element is required", "this other element needs to have exactly one child of this kind" etc. So it is not about XML conformance.

:man_shrugging: OK.

Sorry but -- why can't you simply modify your tool to not emit that empty <lib/>?

I think I shouldn't have to. Obviously I can. Actually, I'm going to be writing my own XML with an  root in a comment after the lib, because a lot of tools freak out if they see an element they don't recognize, but don't care about comments.

it's definitely simpler to fix one tool than change the spec (which could potentially require to change all other implementations). Unless there's a good reason for the change.

It's more correct IMO to allow it though. Besides, binaries of this tool are floating around out there. The normalizer understands it, so this must've come up before? Maybe that's a reach. Anyway, I think my spec change is right, so...

The normalizer removes it as a cleanup, so I'm not sure I'd go so far as to say it means that it's per the spec. Currently I'm tending toward @anthrotype's opinion that it's much easier to change one tool than the spec and then need to test/change a variety of things.

Also: changing the spec to fit a tool that didn't conform to the spec isn't a great precedence to set, even if the author of the tool didn't think that the spec was right/made sense (as an example: the cascading effects of allowing a hyphen in glyph names which still comes up).

If one of my users had opened this, would your opinion be different? Out of curiosity alone.
By the way, just wrote this fontTools-related thing, not sure who to tell: https://github.com/ctrlcctrlv/glif2svg

No, if a user had opened it I would say "talk to the author the the tool, fontTools is throwing this error because the UFO doesn't follow the spec".
Still thinking about this, also want others to weigh in over on the UFO issue, sorry for bifurcating the discussion in two places.

Well, conversion of MFEK .glif files are already known by me to require normalization (I call it reconciliation). See:
https://github.com/MFEK/docs/blob/master/doc/Layers.md
I don't plan on using the  at all longterm, my stuff will go in my  comment, and I'll just copy whatever  is there, so really this is just my opinion on the spec.

If I understand what you're saying; instead of having a MFEK key in the lib dict, you're just going to use a comment? That both defeats the purpose of having the lib and that no other tool will be able to read/understand MFEK data in a UFO. Is there a reason you don't want to use the lib?

Well no other tool should be able to understand my private MFEK dict without going to the trouble of knowing I exist. So, that's fine with me. It's possible I'll stick some things I think are important for other tools to keep around in <lib/>. And also I might implement some of the other <lib/> pseudo-standards, like the way Runebender stores Hyperbeziers. Or some of the color-related ones.
And the reason I'm going with the comment is because fontTools doesn't like elements under the root it doesn't recognize, crashes if <MFEK> is present under <glyph>. I don't like that <lib> is a plist, I want to store XML. Guess I could do it as a string keyed like org.MFEK.dict, but my partner on this project also preferred the comment in our discussion to that, it's not as ugly.

@ctrlcctrlv to be clear: no tool is expected to understand a MFEK key in the lib, but it is required to preserve that key and not mess with the data. Putting things into comments won't guarantee that when the UFO is opened by another tool the data you had put into comments will be preserved. Nothing would/could do anything with the MFEK key unless it knew about the MFEK and could read your data based on your documentation of it.
Of course your tool can do whatever it wants, but I really, really, really recommend not hacking the UFO format with no-specified things. If the format isn't working for your tool, I'd suggest that you make your own tool specific format and have a UFO export for interchange with other tools (fontmake, font tools, other editors, command line things, etc).
People will see a UFO file and rightly assume that it functions well without normalization, open it in something other than MFEK and get unexpected results. In other words, please don't make a tool that makes nonstandard UFOs, it's bad for everyone.


tensor.new doesn't work well if not enable dynamic shapes mode

This is the 1/N issue found from https://github.com/facebookresearch/torchdynamo/issues/156.
Problem:

Failed test example: test_DingKe_pytorch_workplace.py:BinaryTanh
Error:  IndexError: too many indices for tensor of dimension 1

Minimal code to reproduce:
def fn(x):
   return x.new(x.size())

with torchdynamo.optimize(my_compiler):
    y = fn(torch.rand((3, 2)))
    print(y.size())

The above code's output is:

Correct result torch.Size([3, 2]) if enable dynamic shapes.
Incorrect result torch.Size([2]) if don't enable dynamic shapes.

However, it works well in pytorch:

def fn(x):
   return x.new(x.size())

y = fn(torch.rand((3, 2)))
print(y.size())

The above code outputs correct result: torch.Size([3, 2]).

Proposed solutions & discussions:

It seems tensor.repeat and tensor.nonzero function raise unimplemented if not enable dynamic shapes mode, we can have similar handling for tensor.new.

It will break one test case test_reformer_sorting, as we compare the result between torchdynamo and native pytorch, need to skip this check if we go with this way.

It works well on pytorch, so I suspect OutputGraph which extends from fx.Tracer has bug when encountering torch.Size. I manually create a proxy for torch.Size and insert it into the graph can fix this error, but it's definitely not the right solution. I just bring this observation here to provide more details. Or are there bugs at fx.Tracer side when handling tensor.new?

Do you have any suggestion on this issue? @jansel

This reads like just a bug.
In static shape mode x.size() should return the constant (3,2). So I'd expect this to do the same thing as x.new((3,2)), if it doesn't, we should figure out why that is the case.

Update: more evidence shows it may be a bug in fx.Tracer. I wrote down the bellow code to simulate the result after torchdynamo calling fx.Tracer.create_proxy at here:
import torch.fx

class MyTracer(torch.fx.Tracer):
    def __init__(self):
        super(MyTracer, self).__init__()
        self.graph = torch.fx.Graph()

tracer1 = MyTracer()
input_x_node = tracer1.create_proxy("placeholder", "x", (), {}, type_expr=torch.Tensor)
result_node = tracer1.create_proxy("call_method", "new", (input_x_node, torch.Size((3, 2))), {})
tracer1.create_node("output", "output", (tracer1.create_arg(result_node),), {})

root = torch.nn.Module()
gm = torch.fx.GraphModule(root, tracer1.graph)
gm.recompile()
print(gm)
print(gm(torch.rand([3, 2])))

The output is:
GraphModule()

def forward(self, x : torch.Tensor):
    new = x.new((3, 2));  x = None
    return new

tensor([3., 2.])

So fx.Tracer recognizes torch.Size type as tuple, passes tuple (3, 2) as argument and finally generates a new tensor([3., 2.]) rather than a tensor with size (3, 2).
As I'm new to fx.Tracer, feel free to correct me if I'm wrong.

I think the root of the problem is:
>>> torch.tensor([]).new((2,3))
tensor([2., 3.])
>>> torch.tensor([]).new(torch.Size((2,3)))
tensor([[-6.7989e-06,  3.0757e-41, -3.5433e-04],
        [ 3.0757e-41,  1.1210e-43,  0.0000e+00]])
>>>

torch.Tensor.new acts differently with a Size input versus a tuple input.
Size/Tuple are usually interchangeable.
As a workaround, I'd suggest detecting calls to x.new(s) with a torch.Size arg, and just rewriting them to:
torch.empty(s, dtype=x.dtype, device=x.device, ...)

Tensor.new is deprecated anyway.


[Bug]: When only having the permission to change a single table, a new table can be created by importing

ODC version
odc431
OB version

What happened?

What did you expect to happen?
Only with database change permission can files be imported into the database
How can we reproduce it (as minimally and precisely as possible)?
Enable change permission for a table in the database and then import a table into this database
Anything else we need to know?
No response

pass


Feature/erlang breaks the world

If this build goes through, this should close out https://github.com/sensu/sensu-ansible/issues/180
Short version: Erlang 21.X was released and is not support yet by RabbitMQ, this re-configures apt distro's to use pinning to prevent them from upgrading as they install from Erlang Solutions. This isn't an issue for yum distro's as they use the Zero dep RPM's from RabbitMQ directly. This change also updates the yum distro's to use Erlang 20.3.X to match apt distro's per http://www.rabbitmq.com/which-erlang.html#unsupported versions and cleans up a lot of logic across everything.

Alright, I've been doing some local testing, the latest commits should work (I hope...)
I've had to disable the tests for amazonlinux from blocking the build as currently, detection for AmazonLinux 2 is broken resulting in:
/opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/platforms/detect/helpers/os_linux.rb:16:in `redhatish_version': undefined method `[]' for nil:NilClass (NoMethodError)
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/platforms/detect/specifications/os.rb:194:in `block in load'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/platforms/detect/scanner.rb:46:in `instance_eval'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/platforms/detect/scanner.rb:46:in `block in scan_children'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/platforms/detect/scanner.rb:45:in `each'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/platforms/detect/scanner.rb:45:in `scan_children'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/platforms/detect/scanner.rb:60:in `scan_family_children'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/platforms/detect/scanner.rb:51:in `block in scan_children'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/platforms/detect/scanner.rb:45:in `each'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/platforms/detect/scanner.rb:45:in `scan_children'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/platforms/detect/scanner.rb:60:in `scan_family_children'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/platforms/detect/scanner.rb:51:in `block in scan_children'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/platforms/detect/scanner.rb:45:in `each'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/platforms/detect/scanner.rb:45:in `scan_children'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/platforms/detect/scanner.rb:60:in `scan_family_children'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/platforms/detect/scanner.rb:51:in `block in scan_children'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/platforms/detect/scanner.rb:45:in `each'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/platforms/detect/scanner.rb:45:in `scan_children'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/platforms/detect/scanner.rb:33:in `block in scan'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/platforms/detect/scanner.rb:27:in `each'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/platforms/detect/scanner.rb:27:in `scan'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/platforms/detect.rb:9:in `scan'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/plugins/base_connection.rb:100:in `platform'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/transports/local.rb:46:in `select_runner'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/transports/local.rb:27:in `initialize'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/transports/local.rb:17:in `new'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/train-1.4.15/lib/train/transports/local.rb:17:in `connection'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/inspec-2.2.16/lib/inspec/backend.rb:51:in `create'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/inspec-2.2.16/lib/inspec/runner.rb:67:in `configure_transport'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/inspec-2.2.16/lib/inspec/runner.rb:59:in `initialize'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/inspec-2.2.16/lib/inspec/cli.rb:165:in `new'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/inspec-2.2.16/lib/inspec/cli.rb:165:in `exec'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/thor-0.20.0/lib/thor/command.rb:27:in `run'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/thor-0.20.0/lib/thor/invocation.rb:126:in `invoke_command'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/thor-0.20.0/lib/thor.rb:387:in `dispatch'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/thor-0.20.0/lib/thor/base.rb:466:in `start'
	from /opt/inspec/embedded/lib/ruby/gems/2.4.0/gems/inspec-2.2.16/bin/inspec:12:in `<top (required)>'
	from /opt/inspec/bin/inspec:137:in `load'
	from /opt/inspec/bin/inspec:137:in `<main>'

Already fixed in https://github.com/inspec/train/pull/312 but, train v 1.4.16 has the fix so, we need https://github.com/inspec/inspec/blob/master/inspec.gemspec#L29 to be bumped and another Inspec release before those will pass. (https://github.com/inspec/train/compare/v1.4.15...v1.4.16)
I think it's sane to not block on Amazonlinux build failures for the time being to fix the role to no longer have RabbitMQ installations break on Debian based systems.

bingo, we're all set here, merging!


Fixes around workload ports

generate port name differently to support "duplicates" cross port
types
generate dnsName for the port if not specified
cleanup services if the port no longer exists

https://github.com/rancher/rancher/issues/11761
https://github.com/rancher/rancher/issues/12546

@zionwu could you give it a review, and see if anything is missing based on existing bugs/stuff you've debugged.

LGTM


AttachContainer usage

Hello! I’d like to create a reusable component based on Select2 that decorates the dropdown adapter with AttachContainer. I still want to be able to use options like multiple, minimumResultsForSearch, closeOnSelect etc. So I need to reuse the logic that adds all necessary decorators depending on the options.
My current solution is to copy this chunk of code into my component
https://github.com/select2/select2/blob/4.0.0/src/js/select2/defaults.js#L145-L185
and change one line of code in it (AttachBody vs. AttachContainer).
https://github.com/select2/select2/blob/4.0.0/src/js/select2/defaults.js#L183
This seems tedious, I’d rather reuse the code from Select2, but I don’t see a way to use that function without committing to the AttachBody decorator as well. Any ideas how to simplify this on my side or in the Select2 codebase?
Thanks for your library and thanks for your time. :smiley:

How about making AttachBody/AttachContainer configurable? This would make this common task easier.

+1 from me for the suggestion to make this configurable. The current way of getting Select2 to use AttachContainer is an absolute PITA - excuse my French (and really not very well documented, if you ask me).

+1 for having an option.
I had to copy all those lines as well just because search wasn't working inside a modal. And there is the fact that is not a best practice to import inner files of a library.

This really needs to be addressed in a simple manner. A simple option to attach to itself would be best. Something like...
$('select').select2({
  dropdownParent: "self"
});


Fix missing env var in tests

Fix missing env var in tests

/hold
Being tested by https://github.com/openshift-knative/eventing-kafka-broker/pull/381

@aliok any update?

/unhold


Use Cookiecutter

Cookiecutter is a project for easily defining project templates. A cool idea would be to have a version of this template that is a cookie-cutter.

I'm going to veto this idea for the time being. It seems like a lot of work for just a small project.


deleting a route from APIRouter

There are some scenarios in which someone may need to delete a route from APIRouter. For example, you may use a third-party library that provides a router for you. But you do not want to use all of the provided endpoints. In this case, it is useful to remove some of the endpoints

Thank you @sobhansaf! 🍰
I haven't seen a use case like this... I would think it would make more sense for the creator of the router to provide multiple routers so that users can include the functionality they want, or a way to customize the router, not at the FastAPI level... as it would add more complexity in handling and understanding when is a router and all its routes included or not.
Given that, I'll pass on this one, but thanks for the effort! ☕


Improve development experience

See individual commits.

I'm not entirely opposed to this change, but in the past I decided intentionally against it so I can end up with different .lock files for insta and cargo-insta due to different MSRV support.

end up with different .lock files for insta and cargo-insta due to different MSRV support.

FWIW for dependencies that are only part of cargo-insta, having the crates as a workspace won't affect MSRVs. We do this in PRQL, where the CLI can be on latest but the library follows debian.
(but maybe the dependencies are overlapping...)
I do think a workspace is a much nicer development experience.

@mitsuhiko I don't quite understand the concern. Wouldn't the .lock file only be published for cargo-insta, not for insta? That's my understanding of the usual convention.

@mitsuhiko I don't quite understand the concern. Wouldn't the .lock file only be published for cargo-insta, not for insta? That's my understanding of the usual convention.

There is only a single Cargo.lock file for a workspace. Unless I'm really mistaken — currently the cargo-insta/Cargo.lock file does nothing. And we should remove it.

That's right. I removed it. But my point was that the Cargo.lock should not be published with the insta library, only the cargo-insta CLI.

Ah, I see what you mean now. Indeed this change means that the versioning restrictions that apply to insta will also apply to cargo-insta.

Ugh, this changed the current directory when the integration tests run, and they are not resilient to this. I'll wait for #412 to land first.

Ah, I see what you mean now. Indeed this change means that the versioning restrictions that apply to insta will also apply to cargo-insta.

Yes cool. Still a big fan of the change!
Do you think we can still get 1.61 tests to pass?

Yeah, they were passing before I split out #412.

FWIW I would prefer a workspace as well. I think the way it could be accomplished might be with manually maintaining a secondary Cargo.lock file and move it over in the tests. I am doing something similar for a Cargo.lock.msrv file in some libraries. Eg.: https://github.com/mitsuhiko/similar

Re the MSRV — FWIW in PRQL we use cargo msrv verify in our CI, which verifies that that the package is valid with its specified MSRV (e.g. here).
It allows different MSRVs by crate.
Relative to maintaining another Cargo.lock.msrv, it requires another dev dependency, but it has worked quite well for us over the past year.

Alright I've abandoned the virtual manifest for now. Instead I added cargo-insta and its integration tests to the root manifest workspace.

At long last this is green.

Validated: the lock file is handled correctly by cargo package.

That won't work here because MSRV is 1.51 but the tests also need to run against 1.61.

FYI this isn't how cargo msrv works — check out the PRQL workflows if you're interested to learn more.
Thanks for this PR!


Added preventOpenDuplicates global option.

The option prevents toasts that are currently open from having duplicates.
Also fixed typo in documentation: extendedTimeOut.
The current preventDuplicates option does not suit my needs. For example, if I displayed a toast after a request error and it timed out, I want the toast to be displayed again if it reoccurs.

Thanks, I will take a look soon.

I merged it, it was a lovely patch.

Great! Thank you.

Re-checking it, I opened #96 .
Is there any reason you created yet another way to track opened toasts? There is a toasts array already.
I will clean up that.

That was intended. The toasts array preserve the order and the object is just an efficient way to check if the toast exists. It could be replaced, but I really don't like the idea of looping an array every time. Of course that for most use cases, the normal amount of open toasts is very small.


nan value as output instead of an area

Code Sample, a copy-pastable example if possible
from pyproj import Geod
from shapely.geometry import Polygon
from shapely.ops import orient

value = [
    (49.16848657161892, -122.4927565020954),
    (49.17145542056141, -122.44026815784645),
    (49.168944059578955, -122.42223809616848),
    (49.18182618668267, -122.42070673842014),
    (49.18901155779426, -122.40938116907655),
    (49.19333350498177, -122.41092556489616),
    (49.19754283081477, -122.4063781772052),
    (49.20350953892491, -122.38609910402336),
    (49.21439468669444, -122.36070237276812),
    (49.222360646955416, -122.35469638902534),
    (49.22411415726248, -122.35687285265936),
    (49.22498357252119, -122.35828854882728),
    (49.226469956724024, -122.35790244987238),
    (49.22832086322251, -122.35635805405282),
    (49.22936323360339, -122.35609949522244),
    (49.22913888972668, -122.35764389104204),
    (49.22773671741685, -122.35871638813896),
    (49.226739672517496, -122.36025878439766),
    (49.22010672437924, -122.38006780577793),
    (49.21996732086788, -122.38057257126464),
    (49.21999536911368, -122.39299208764706),
    (49.21992686126862, -122.4036494466543),
    (49.21891709518424, -122.40613785636424),
    (49.21888904632648, -122.4073390531128),
    (49.219562214519144, -122.40965564684215),
    (49.2199548917306, -122.41051364451972),
    (49.22074023679359, -122.4168628273335),
    (49.22121704735026, -122.421925013631),
    (49.22035066674655, -122.42482694635817),
    (49.21995799267972, -122.43289212452709),
    (49.22046285876402, -122.5120853101642),
    (49.219966402618745, -122.55650262699096),
    (49.255967240082846, -122.55753222420404),
    (49.256303572742965, -122.59614211969338),
    (49.27154824650424, -122.59648531876442),
    (49.3008416630168, -122.59480957171624),
    (49.300169602582415, -122.6655085803457),
    (49.29456874254022, -122.66036059428048),
    (49.28941538916121, -122.6675677747718),
    (49.288389695754155, -122.68427714208296),
    (49.27998615908695, -122.6956027114265),
    (49.25981182761499, -122.7177390515071),
    (49.25420638251272, -122.72099944268174),
    (49.241760018963866, -122.73953219251663),
    (49.227520721395656, -122.77317064879188),
    (49.22633007199472, -122.7634995116452),
    (49.21729887187899, -122.75397573742444),
    (49.20512626699452, -122.70094375077176),
    (49.19625956267232, -122.6707422325223),
    (49.19968297235687, -122.65383967827474),
    (49.210563761916895, -122.62311572400029),
    (49.21028322521899, -122.60552677161068),
    (49.19894821132008, -122.58853841759532),
    (49.1876984184996, -122.58114408968196),
    (49.16741121321411, -122.52297464048324),
]

polygon = Polygon(value)
geod = Geod(ellps="WGS84")
poly_area, poly_perimeter = geod.geometry_area_perimeter(orient(polygon))

print(poly_area)

Problem description
poly_area is nan shouldn't this be an actual area in square metres?
Expected Output
poly_area should not be nan
Environment Information

Output from: pyproj -v

pyproj info:
    pyproj: 3.1.0
      PROJ: 8.0.1
  data dir: /usr/local/lib/python3.9/site-packages/pyproj/proj_dir/share/proj
user_data_dir: /Users/username/Library/Application Support/proj

System:
    python: 3.9.5 (default, Jun 16 2021, 16:03:56)  [Clang 10.0.0 (clang-1<IP_ADDRESS>)]
executable<EMAIL_ADDRESS>   machine: macOS-10.16-x86_64-i386-64bit

Python deps:
   certifi: 2021.05.30
       pip: 21.1.1
setuptools: 56.0.0
    Cython: None

Installation method
pip
Related Stack Overflow Question
Question

@pythonuser00, the order of the points should be (longitude, latitude). However, your points appear to be swapped in this example.

Swapping the order around:
lat, lon = zip(*value)
polygon = Polygon(zip(lon, lat))

I get this area:
182881770.25141057

Hopefully this gets you where you need to be.


no maintainers?

This project seems to be dead.
Does anyone know of a similiar library that has active developers?

bump.
In need of a reliable way to connect to MariaDB with NoSQL features.

We need more developers who program instead of marrying and caring for children)


remove noqa comments in gluonts/mx/__init__ by adding __all__

Issue #, if available:
Mentioned in a comment in https://github.com/awslabs/gluon-ts/pull/1592
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Please tag this pr with at least one of these labels to make our release process faster: BREAKING, new feature, bug fix, other change, dev setup

@jaheba am I missing something? Seems not to work with __all__ and without the comments

Not sure why the docs workflow is complaining.


Added Encryption solution in Java, Finbonacci Modified in Python , Recursive Digit sum in Python , Flatland Space stations in Java.

Description

LGM SOC'21 contribution.
Added solution of Encryption in Java.
Added solution of Fibonacci Modified in Python.
Added solution of Recursive Digit sum in Python.
Added solution of Flatland space stations in Java.

Fixes #314 , #316 , #319 , #312
Replace issue_no with the issue number which is fixed in this PR
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update
[ ] Documentation Update

Checklist:

[x] My code follows the style guidelines(Clean Code) of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have created a helpful and easy to understand README.md
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests/screenshots(if any) that prove my fix is effective or that my feature works

@rajeshkumar2024 make separate PRs

@Amit366 ok sir.


404 is being displayed when entering see more results in search

Wrong project selected, new issue https://app.zenhub.com/workspaces/engagement--discovery-62fb8ae74edf133b98679e91/issues/gh/decentraland/landing/176


Helm 3.5.2 is adding additional semver validation for chart versions compared to 3.5.2

Output of helm version:
version.BuildInfo{Version:"v3.5.2", GitCommit:"167aac70832d3a384f65f9745335e9fb40169dc2", GitTreeState:"dirty", GoVersion:"go1.15.7"}

Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.5", GitCommit:"e6503f8d8f769ace2f338794c914a96fc335df0f", GitTreeState:"clean", BuildDate:"2020-06-26T03:47:41Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"windows/amd64"}
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.6", GitCommit:"c7c4f6ce84bf8535a782b67465807651a4bd649b", GitTreeState:"clean", BuildDate:"2021-01-18T09:49:05Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.): AKS
Running helm dep up or helm package ... using v 3.5.2 v 3.5.1 now validates chart versions differently. Some older existing charts have <IP_ADDRESS> for example and fail. Others are said to be invalid but are skipped which is written to stderr and causes scripts to fail.
$ helm dep up
Hang tight while we grab the latest from your chart repositories...
index.go:339: skipping loading invalid entry for chart "couchbase-operator" "2.0.2-01" from https://couchbase-partners.github.io/helm-charts/: validation: chart.metadata.version "2.0.2-01" is invalid
index.go:339: skipping loading invalid entry for chart "couchbase-operator" "2.0.1-001" from https://couchbase-partners.github.io/helm-charts/: validation: chart.metadata.version "2.0.1-001" is invalid

Hi @lapellaniz. This is expected as part of the security advisory shared last week with the release. See https://github.com/helm/helm/security/advisories/GHSA-c38g-469g-cmgx for more information.

See also https://github.com/helm/helm/issues/9342.

@lapellaniz This is something we talked about while working on the security advisory.
Helm has always said the version MUST be semver. This is the chart version. For application versions there is the appVersion property that can be any format.
2.0.2-01 and 2.0.1-001 are not valid semantic versions. In the section on of the spec on prereleases it says:

Numeric identifiers MUST NOT include leading zeroes.

The documented grammar does not allow for a leading 0, either.

Closing issue as per the documented standard.


data science project

Description
In this mini data science project I have used EDA and Support Vector classifier

PR accepted @Deepanshu0810
Successfully merged to HacktoberFest_22 repo.
🚀🚀👍


docs(api): begin work on stats json documentation

Add page to document the output of...
webpack --profile --json > compilation-stats.json

We still need to go through and fill in the blanks before this can be merged.
Resolves #491
cc @dmitriid @walfly

@sokra should be ready for another pass. I filled in some other bits as well and removed all the question marks you didn't touch on (assumed those points were ok). Let me know if there's anything else that needs updating.
@walfly @dmitriid any thoughts? This probably isn't perfect 👌  but it should be a good start for us to build on... if anything else arises we can tackle it with more targeted prs/issues.

This is absolutely wonderful. Thank you!

Ok even though I don't think all the descriptions are perfect, I'm going to merge as this is definitely a step up from no documentation. @sokra @walfly @dmitriid please submit prs or issues with any clarifications or improvements (or add suggestions here).


Arrays with only one element is converted into a string

When passing an TemplateObject to the Format-AzTemplate the following happens
Arrays with only one element is converted into a string when running Format-AzTemplate. This will create dependsOn with a string value, and not an Array with one string element.
I suspect that this is because the Property is being piped (and therefore converted to string by poweshell) to the sortProperties scriptBlock.
 in.$propName | & $MyInvocation.MyCommand.ScriptBlock @recurseSplat

Created following work around.
                        # If the object had that property                         if ($Recurse -and ($in.$propName -is [Array]) -and ($in.$propName.count -gt 1)) {                              $newPropValue = $in.$propName | & $MyInvocation.MyCommand.ScriptBlock @recurseSplat                         }                         else {                             $newPropValue = $in.$propName                         }

#222


[WIP] fix macOS & iOS libs

Will fix #93

I really appreciate this. It'll be really-really great to ship it.

Well, the last commt is blocking the install of ipa with AltStore, there is a missing Info.plist that I need to create, but I have no idea how...
Also, I had to fix the build for the arm64 simulator, whose platform is not the right one set... (https://bogo.wtf/arm64-to-sim-dylibs.html)
Finally, since the last macOS update, I can no longer run Flutter in dev mode on my iPhone…
I've never seen a platform as crappy as Apple. The worst engineers on the planet!
I'm so close to leaving the Apple ecosystem, any action, any dev takes 100 times more time than on Linux!

Ok, now media_kit_libs_ios_video and media_kit_libs_macos_video use a .xcframework instead of libraries.
This allows two things:

iOS: respects the following App Store rule:

Dynamic libraries outside of a framework bundle, which typically have the file extension .dylib, are not supported on iOS, watchOS, or tvOS, except for the system Swift libraries provided by Xcode.

iOS: allows xcode to select the correct framework depending on the selected device: real (arm64) or simulator (arm64 & x86_64)

I need two tests:

@JulienDev: Can you check if this fixes the publication to the App Store?
@HankG: Can you check if this fixes the simulator version under Apple Silicon?

Thx.

There is a problem with the signature of the libs included in the framework, I have to create as many frameworks as there are libs, that should solve the problem.

From Discord: @JulienDev no longer has an error when uploading to the App Store, he is waiting for a review 🙂

@birros do you think this may fix my problem?
The build on Macos and iOS I told you on discord

@birros do you think this may fix my problem?

I don't think it's related.

@birros this pr fixed compilation on macos on my side,while nothing changed on ios

I can give you compilation logs or something else for a mac with a M2 chip if you need

For all those who have difficulty building for iOS: https://stackoverflow.com/questions/75901592/after-upgrading-to-xcode-14-3-while-trying-to-archive-a-flutter-app-i-get-com/75911207#75911207

Now that I've been able to test all the configurations and the iOS App Store release looks good, I'm going to move the logic into birros/libmpv-build, within 24 hours it should be done.

Recap:

migrated the repo responsible for building libmpv for macOS & iOS to the new media-kit organization
replaced the use of .dylib by .xcframework

fix mpv loading in arm64 simulator
fix #93

update the minimum version of macOS to 11.0

This new architecture does not fix #98, because it is not related.


Clarification about the fastlane integrations

I have a doubt kindly clarify,
While running the command 'fastlane ios beta", it shows the log as below mentioned.
My doubt is this will upload the app to Appstore or not. Because it showing as "Successfully uploaded package to iTunes Connect. It might take a few minutes until it's visible online."
iTunes Transporter successfully finished its job
 ---------------------------------------------------------------------------------------------------------------
 --- Successfully uploaded package to iTunes Connect. It might take a few minutes until it's visible online. ---

 Successfully exported and compressed dSYM file
 Successfully exported and signed the ipa file:
 ----------------------------------
 --- Step: upload_to_testflight ---
 ----------------------------------
Login to iTunes Connect
 Login successful
 Ready to upload new build to TestFlight
 Going to upload updated app to iTunes Connect
This might take a few minutes. Please don't interrupt the script.
 iTunes Transporter successfully finished its job
---------------------------------------------------------------------------------------------------------------
 --- Successfully uploaded package to iTunes Connect. It might take a few minutes until it's visible online. ---
 ---------------------------------------------------------------------------------------------------------------
 Successfully uploaded the new binary to iTunes Connect

✅ fastlane environment ✅
Stack
| Key                         | Value                                       |
| --------------------------- | ------------------------------------------- |
| OS                          | 10.12.6                                     |
| Ruby                        | 2.5.1                                       |
| Bundler?                    | true                                        |
| Git                         | git version 2.14.3            |
| Installation Source         | ~/.rvm/gems/ruby-2.5.1/bin/fastlane         |
| Host                        | Mac OS X 10.12.6 (16G29)                    |
| Ruby Lib Dir                | ~/.rvm/rubies/ruby-2.5.1/lib                |
| OpenSSL Version             | OpenSSL 1.1.0h  27 Mar 2018                 |
| Is contained                | false                                       |
| Is homebrew                 | false                                       |
| Is installed via Fabric.app | false                                       |
| Xcode Path                  | /Applications/Xcode.app/Contents/Developer/ |
| Xcode Version               | 9.2                                         |

System Locale
| Variable | Value       |   |
| -------- | ----------- | - |
| LANG     | en_US.UTF-8 | ✅ |
| LC_ALL   | en_US.UTF-8 | ✅ |
| LANGUAGE |             |   |

fastlane files:
fastlane gems

Gem
Version
Update-Status

fastlane
2.95.0
✅ Up-To-Date

Loaded fastlane plugins:
No plugins Loaded
Loaded gems
| Gem                       | Version      |
| ------------------------- | ------------ |
| did_you_mean              | 1.2.0        |
| executable-hooks          | 1.4.2        |
| bundler-unload            | 1.0.2        |
| rubygems-bundler          | 1.4.4        |
| bundler                   | 1.16.1       |
| CFPropertyList            | 3.0.0        |
| public_suffix             | 2.0.5        |
| addressable               | 2.5.2        |
| atomos                    | 0.1.2        |
| babosa                    | 1.0.2        |
| claide                    | 1.0.2        |
| colored                   | 1.2          |
| colored2                  | 3.1.2        |
| highline                  | 1.7.10       |
| commander-fastlane        | 4.4.6        |
| declarative               | 0.0.10       |
| declarative-option        | 0.1.0        |
| unf_ext                   | <IP_ADDRESS>      |
| unf                       | 0.1.4        |
| domain_name               | 0.5.20180417 |
| dotenv                    | 2.4.0        |
| emoji_regex               | 0.1.1        |
| excon                     | 0.62.0       |
| multipart-post            | 2.0.0        |
| faraday                   | 0.15.1       |
| http-cookie               | 1.0.3        |
| faraday-cookie_jar        | 0.0.6        |
| faraday_middleware        | 0.12.2       |
| fastimage                 | 2.1.3        |
| gh_inspector              | 1.1.3        |
| jwt                       | 2.1.0        |
| little-plugger            | 1.1.4        |
| multi_json                | 1.13.1       |
| logging                   | 2.2.2        |
| memoist                   | 0.16.0       |
| os                        | 0.9.6        |
| signet                    | 0.8.1        |
| googleauth                | 0.6.2        |
| httpclient                | 2.8.3        |
| mime-types-data           | 3.2016.0521  |
| mime-types                | 3.1          |
| uber                      | 0.1.0        |
| representable             | 3.0.4        |
| retriable                 | 3.1.1        |
| google-api-client         | 0.13.6       |
| json                      | 2.1.0        |
| mini_magick               | 4.5.1        |
| multi_xml                 | 0.6.0        |
| plist                     | 3.4.0        |
| rubyzip                   | 1.2.1        |
| security                  | 0.1.3        |
| naturally                 | 2.1.0        |
| simctl                    | 1.6.4        |
| slack-notifier            | 2.3.2        |
| terminal-notifier         | 1.8.0        |
| unicode-display_width     | 1.3.2        |
| terminal-table            | 1.8.0        |
| tty-screen                | 0.6.4        |
| tty-cursor                | 0.5.0        |
| tty-spinner               | 0.8.0        |
| word_wrap                 | 1.0.0        |
| nanaimo                   | 0.2.5        |
| xcodeproj                 | 1.5.8        |
| rouge                     | 2.0.7        |
| xcpretty                  | 0.2.8        |
| xcpretty-travis-formatter | 1.0.0        |
</details>

@nihp Thanks for using fastlane! The app will upload to iTunesConnect and will take some time to show since iTunesConnect needs to process that app first. I am closing this as there is no issue described here.


Comparison to LMQL

Thanks for the comparison table. LMQL would be another addition to there.

included in readme now

Awesome, thanks!


Add new rebus

Summary of Changes

Added a new rebus

Pull Request Test Coverage Report for Build 24

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

Totals

Change from base Build 23:
0.0%

Covered Lines:
87

Relevant Lines:
99

💛  - Coveralls


Add more speakers sponsors

Fixes #95 #94 #96
What happened
Ass the following speaker sponsors: Ascenda Loyalty, Blackmill and Saeloun.
Insight
This is the second batch of speaker sponsors.
Proof Of Work
Small Screens

Medium Screens

Large Screens

Looking good, thanks!
On 14 Jul 2019 15:21 +1000, Olivier Robert<EMAIL_ADDRESS>wrote:

Fixes #95 #94 #96
What happened
Ass the following speaker sponsors: Ascenda Loyalty, Blackmill and Saeloun.
Insight
This is the second batch of speaker sponsors.
Proof Of Work
Small Screens
Medium Screens
Large Screens
You can view, comment on, or merge this pull request online at:
https://github.com/bangkokrb/rubyconfth/pull/98
Commit Summary
• Add speaker sponsor "Ascenda Loyalty"
• Add speaker sponsor "Saeloun"
• Add speaker sponsor "Blackmill"
File Changes
• M _data/sponsors.yml (11)
• A assets/images/pages/home/sponsors/logo-ascenda.jpg (0)
• A assets/images/pages/home/sponsors/logo-blackmill.jpg (0)
• A assets/images/pages/home/sponsors/logo-saeloun.jpg (0)
Patch Links:
• https://github.com/bangkokrb/rubyconfth/pull/98.patch
• https://github.com/bangkokrb/rubyconfth/pull/98.diff
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub, or mute the thread.


Added several public servers with Tor Hidden Service

Added creep.im, jabber-germany.de, suchat.org, tchncs.de and trashserver.net. All of them have a Tor Hidden Service.
I am maintaining a human-readable list at: Public XMPP servers with Tor Hidden Service. I'll open new pull requests whenever a new server is added.
A big thanks to all XMPP server admins who to set up and maintain an hidden service.

Awesome! We don't support captcha yet but it will be useful to have if we eventually support it. Do you have any more information about the server operators? We want to make sure there's some level of trust if we're encouraging users to use these options.

3 out of those 5 servers do not require captcha: jabber-germany.de, tchncs.de and trashserver.net. Perhaps you can start with those.
I do not personally know any of the server operators. Though, I have contacted them to ask if they could set up a Tor Hidden Service and they were all very helpful and expedited.
All servers scored grade A in IM Observatory ranking. They have been running for a few years and support a couple hundred of users each. Furthermore, unlike the servers currently on your list, all these  servers support the latest XEPs (e.g. MAM, HTTP Upload, etc.). Besides being a proof that admins take care to update their software, it is also a great plus if/when ChatSecure supports OMEMO.
I believe this shows the operators are serious and reliable. Still, if you have some additional questions, please try to contact them directly. They can all be easily reached through the contact information on their respective websites.

Now that I've activated the server capabilities viewer and warning if your server doesn't support push, I need to update the list asap. Another big problem is that Dukgo is shutting down on May 7 and we need a good list of servers for people to migrate.