add support for all the available equities indexed in Investing.com 🚀🌐

So to extend the usage of the package, the retrieval of all the equities indexed in Investing.com is proposed, as currently investpy just supports spanish equities, which limits its usage since there are a lot of markets available.
📄 So on, some tasks can be defined in order to get to develop this enchancement and so to integrate it with the package:

[x] T01 - Research on which id fields are sent on the GET request to Investing.com

[x] T02 - Retrieve a listing with all the available countries which have equities listed in Investing and define a function to wrap it.

[x] T03 - Extend investpy.equities.retrieve_equities functionallity and test its usage.

[x] T04 - Check if there is any missing data in equities.csv due to connection errors since the scrapping process took too long and made a huge amout of consecutive requests to Investing.com. (Tip: define a function to wrap that check because it can happen again if equities.csv is re-generated.)

[x] T05 - Once equities.csv is generated, add country param to equity retrieval functions since it is a new filtering needed to avoid duplicated equity names in different countries. (Note: this tasks is pretty similar to the one done for ETFs when country filtering was added)

[ ] T06 - Generate the docs and update investpy usage.

Additional tasks will be added to the previous listing if needed in order to complete this issue.

T05 has been solved in ce99e95179a0c143f12d9fbfdbf3171a6da45a92, via adding the country param to retrieval functions as described in the issue and so on, the solution has been also described in the referenced commit.


Shutdown the system properly when opened with GUI

closing the window sends the shutdown command to the system.


stops running in the middle of the execution

My code stops running in the middle ( Windows 10, Bitnami\wampstack-8.0.7-0, Visual Studio ). All breakppoints are removed. I have been checking on different browsers - code stops running in the middle in Opera, Chrome, and Edge.
The code is working in another computer and online debuggers.
I can not reveal the code. What could be the reason for this bug?
I switched to another computer temporary.

What code are you debugging?
How do you know that "the code stops in the middle of the execution"? A screenshot could help.
Please provide reproducible steps.

/needsMoreInfo


⚠ Bofrost.de has degraded performance

In 730d10f, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1716 ms

Resolved: Bofrost.de performance has improved in 4de807b after 6 minutes.


Wrong next-day values & lowest/highest values

Today the prices for tomorrow contains the values of yesterday.
Also after reboot, reload, restart integration, etc.

Could be these values are part of the data retrieved from ENTSO-e, however a sanity check could be used to avoid wrong values here.
Moreover, the lowest/highest values provided by the integration also make use of these values.
Therefore, the lowest value reported by the integration is not the value of tomorrow but a value from yesterday.

time: "2024-11-25 03:00:00+01:00"
price: -0.00109

I see the same issue. Also no update at 2 pm CET with tomorrow's prices.

Yes, same here..


⚠ Bofrost.fr has degraded performance

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

HTTP code: 200
Response time: 909 ms

Resolved: Bofrost.fr performance has improved in cebae04 after 6 minutes.


New icon animation: Saving

Name of icon to be animated as shown in Carbon Icon Library:
Saving

Current state:

Feedback from Mike on this:

Transition looks good. I think general speed of the loader feels right, might try a little slower (in case the context needs it to be less obtrusive)
I'd play with modifying the floppy disk path so it maintains consistent buffer between the circle and checkmark (animating the lines closer/farther away as you transition)

@watsondesign This is looking awesome!  Once you are done refining, lmk and I'll add it to the library and the demo page! 😄

save_icon.zip
@kristastarr Here is the after effects file and the illustrator file for you to begin working

https://github.com/carbon-design-system/icons-motion/pull/247 adds an icon with three states in progress/success/failure and buttons on the demo page to simulate a change in status, so you can see how each state looks.  @watsondesign we can update this with your version once it's finished 😄

I think we can go ahead and close this one! Thank you @kristastarr


Update scalatags to 0.9.2

Updates com.lihaoyi:scalatags from 0.7.0 to 0.9.2.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.lihaoyi", artifactId = "scalatags" } ]

labels: library-update, semver-minor

Codecov Report

Merging #157 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #157   +/-   ##
=======================================
  Coverage   12.96%   12.96%
=======================================
  Files          54       54
  Lines        2168     2168
  Branches       28       28
=======================================
  Hits          281      281
  Misses       1887     1887

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 74c1b5d...8499e3d. Read the comment docs.

Superseded by #208.

Superseded by #208.


Allow calling UnboundedReceiver::try_next after None

Do not panic.
Not-panicking is equally safe, and does not have negative performance
implication.
It is irrelevant for Stream implementation to panic or not (because
Stream behavior is unspecified after None), but panicking in
try_next just complicates the interface: returned Ok(None) is
reasonable assumption to have.
Consider this use case: drain the queue on drop by performing
app-specific cleanup of queued messages.
The obvious implementation would be:
impl Drop for MyReceiverWrapper {
    fn drop(&mut self) {
        while let Ok(Some(m)) self.try_next() {
            cleanup(m);
        }
    }
}

Without this change, I cannot even say for sure how this code need
to be implemented to avoid panicking. E. g. is is_closed enough
or some additional checks need to be performed?

Done.


error trying to configure add on  please advise

Jul 26 10:04:27 volvo2mqtt [106] - INFO: Starting volvo2mqtt version v1.9.4
Jul 26 10:04:27 volvo2mqtt [106] - INFO: Starting login with OTP
Traceback (most recent call last):
File "/usr/lib/python3.12/urllib/request.py", line 1344, in do_open
h.request(req.get_method(), req.selector, req.data, headers,
File "/usr/lib/python3.12/http/client.py", line 1336, in request
self._send_request(method, url, body, headers, encode_chunked)
File "/usr/lib/python3.12/http/client.py", line 1382, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
File "/usr/lib/python3.12/http/client.py", line 1331, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
File "/usr/lib/python3.12/http/client.py", line 1091, in _send_output
self.send(msg)
File "/usr/lib/python3.12/http/client.py", line 1035, in send
self.connect()
File "/usr/lib/python3.12/http/client.py", line 1470, in connect
super().connect()
File "/usr/lib/python3.12/http/client.py", line 1001, in connect
self.sock = self._create_connection(
^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/socket.py", line 828, in create_connection
for res in getaddrinfo(host, port, 0, SOCK_STREAM):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/socket.py", line 963, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
socket.gaierror: [Errno -3] Try again
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/volvoAAOS2mqtt/main.py", line 15, in
authorize()
File "/volvoAAOS2mqtt/volvo.py", line 51, in authorize
"User-Agent": "vca-android/" + util.get_volvo_app_version(),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/volvoAAOS2mqtt/util.py", line 34, in get_volvo_app_version
result = app(
^^^^
File "/usr/lib/python3.12/site-packages/google_play_scraper/features/app.py", line 15, in app
dom = get(url)
^^^^^^^^
File "/usr/lib/python3.12/site-packages/google_play_scraper/utils/request.py", line 48, in get
return _urlopen(url)
^^^^^^^^^^^^^
File "/usr/lib/python3.12/site-packages/google_play_scraper/utils/request.py", line 17, in _urlopen
resp = urlopen(obj)
^^^^^^^^^^^^
File "/usr/lib/python3.12/urllib/request.py", line 215, in urlopen
return opener.open(url, data, timeout)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/urllib/request.py", line 515, in open
response = self._open(req, data)
^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/urllib/request.py", line 532, in _open
result = self._call_chain(self.handle_open, protocol, protocol +
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/urllib/request.py", line 492, in _call_chain
result = func(*args)
^^^^^^^^^^^
File "/usr/lib/python3.12/urllib/request.py", line 1392, in https_open
return self.do_open(http.client.HTTPSConnection, req,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/urllib/request.py", line 1347, in do_open
raise URLError(err)
urllib.error.URLError: <urlopen error [Errno -3] Try again>
s6-rc: info: service legacy-services: stopping
s6-rc: info: service legacy-services successfully stopped
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped

Your home assistant seems to have no Internet access or the API isn't reachable from your network.


[FEATURE] Verify scanner working when project sites are being scanned

Not received this ask anymore since a long time, so removing this from the backlog

Not received this ask anymore since a long time, so removing this from the backlog


Self-author Underline

Have you checked that your issue isn't already filed?

[X] I read through FAQ and searched through the past issues, none of which addressed my issue.
[X] Yes, I have checked that this issue isn't already filed.

Bug description
Automaic underline for self as author in publications not working. Logic is in bib.liquid
How to reproduce the bug
NA
Error messages and logs
The error message you got, with the full traceback if available. Please paste it between these triple backticks.

What operating system are you using?
Mac
Where are you seeing the problem on?
Deployed site
More info
No response

I am dumb.


Simplify testing and configuration setup

Rather than generating test files at configure time and packaging a ton of unneeded code in inc/, just have the tests hard coded and pick which to run based on if XS is being used.

Hi Graham,
how do say politely "This was exactly not the way I decided to go when designing configuration & test phase". I appreciate your patch but for the moment I'd like to let it aside until a common understanding of the motivation of the original setup has been reached.
This is not a reject of the contribution - if you're interested to improve at this point - what would help more is someone who helps discussion open issues I try to satisfy with my approach.

Can you explain why you prefer your approach?

Yes, I can.
Because of the size - it'll be a longer answer.
First - see the RT's #75672, #93207 and alike. Those are symptom's I try to fix.
The first one shall be fixed by filling check_produce_loadable_xs_build with  code which tries to load an intermediately built XS module when host == target  and tries to nm/parseelf (as a result from deeper discussion with Merijn and Leon) when host != target.
Also - like at the RT #102885 issue I experimented with checks guessing the supported sv_setsv* opportunitities before finding a suitable solution without configure time checks.
While I know the C::AC part is slightly overengineered - it starts where the proposed can_xs() ends. It allowes add more checks - eg. one for determining UV_MAX, IV_MIN and IV_MAX on testers machine and allow a rewrite of the test in https://github.com/perl5-utils/List-MoreUtils/blob/master/t/lib/LMU/Test/Functions.pm#L1312 using precomputed and surely being integer numbers. I didn't go this approach because I'm fighting with myself to create a Machine::Integer::Constants instead and recommenting that for the test (sounding board needed!).
The same arguments as for the check are for the tests. I want the tests fail when a condition in configure is detected - and not skip. The reason is (an admitted unreflected because of just a wand to discuss it with) eg. RT #85257. The idea is born from experience in dbi area (dbi, DBD::DBM, DBD::File, SQL::Statement, DBD::CSV, DBD::sys ...).
It needs the same reflection the configure stage might need - but with an open mind for the maintainer requirements who has background in deep low level code (see https://github.com/rehsack/meta-jens/blob/master/conf/machine/curie.conf or https://github.com/rehsack/meta-jens/tree/master/classes) and high level hit's him occasionally, not regulary ;)
Similar as kentl argues for Gentoo packaging - my experiences at pkgsrc packaging (which runs for 16+ platforms) is a strong lack in toolchain supporting clear customizable results. C::AC fills that gap with the same way of control to packagers as autotools do for Shell (ac_cv_* environment variables) and more in that direction. Packaging bitbake recipes for Yocto and problems with Params::Validate and Socket6 encourage me that the idea behind the approach is sane (even if the implementation is ... unreflected).

Jens, in this particular case, though, it looks like Config::AutoConf::LMU and the Tumble are only generating XS/pure-perl variants.  Is that correct?
Is the "design difference" that you're using the C::AC/Tumble approach because you expect more variations in the future and you want the infrastructure in place now for those future variations?
If so, then the debates about the approach should center on the cost/benefit of having it now versus the cost/benefit of holding off until it's actually needed (and the likelihood of needing such variants in the future).
Because otherwise, the generated test approach seems like complete overkill for the actual files  generated currently.

@dagolden - No, it's not correct - that is what remained in public after I cleaned up. But misbehavior of EU::MM makes me torn to add some extra's soon (bikeshedding and sounding boards needed).
There is one check done in check_produce_loadable_xs_build (or better: place-holded) which is intended to be filled as soon as the technology is safely available - the one preventing tickets as #75672 (load errors). There's a little more with type definitions - but as said, I'm unsure and to many tuits.
Regarding the tests - at the very moment I agree that it's overengineered but reduce them to a static set with one check at config is "underengineered" - I wanted at Berlin discuss the ExtUtils::MakeMaker::Extensions approach or learn more about Module::Install or whatever to have a balance between dynamically add variants but ship them pregenerated.
The hint @haarg gave with dynamically fill tests list is valid and should be discussed whether there're likely (not possible) dynamic tests (RT#93207) we cannot pregenerate or not.

I added some explaning doc with dcc1a93 - I hope with the explanation above and the doc most questions are answered. If not - don't hesitate to ask or tell me what's missing or unclear.

Let me try to translate this.
I think @rehsack's point boils down to "I want this to be as close as possible to what I consider correct, at any costs", and that @haarg's and @dagolden's point is "this cost is not reasonable, isn't there a cheaper way to achieve this, and if not should we do this at all".

This to decide is to early in the distribution evolving process.

This to decide is to early in the distribution evolving process.

Can you please clarify what you mean with that? In particular, what are you referring to with "This"

It's the same this you refer to. I explained the details above - is there something particular what in unclear?

When everything is said and no open questions need further discussion, I'd like to close this PR.

Did you mean "the test generation process is too young for such cost/benefit question"?

Am 04.05.2015 um 18:02 schrieb Leon Timmermans<EMAIL_ADDRESS>Did you mean "the test generation process is too young for such cost/benefit question"?

I mean, the test generation, the configure stage, the complete process.
No one invested time reflecting details in that process - I described what causes myself deciding for both solutions I currently use and where I think it's over-engineered and where I think it requires more research.
None of the referred tickets are really solved - so all need more research and infrastructure improvements.
For the time being, I think no user is harmed by the bundles. Contributors have a very rampant learning curve.
But who contributes code? David heavily contributes thoughts for algorithms, names, documentation - and didn't complain about the complexity (maybe because it doesn't matter for some shots).
Cheers
Jens Rehsack -<EMAIL_ADDRESS>

For the time being, I think no user is harmed by the bundles.

This line of thinking is appealing, yet fundamentally misguided. Moreover the bundling isn't the real problem here.
The reality is you simply don't know, and more importantly have no practical way to know how much issues you are creating at the installation endpoints by generating 80 LoC utilising ~10,000 LoC (either bundled or installed at configure-time). This (as of yet) unjustified complexity is what the PR is about.

If it's too young to be critiqued yet, then surely it's also too young to be used in an infrastructure level distribution like List::MoreUtils.
I appreciate your desire to experiment with better solutions in this space, but you shouldn't be doing that on a dist that's this heavily embedded in applications' dep chains.

Am 04.05.2015 um 19:59 schrieb Peter Rabbitson<EMAIL_ADDRESS>For the time being, I think no user is harmed by the bundles.
This line of thinking is appealing, yet fundamentally misguided. Moreover the bundling isn't the real problem here.
The reality is you simply don't know, and more importantly have no practical way to know how much issues you are creating at the installation endpoints by generating 80 LoC utilising ~10,000 LoC (either bundled or installed at configure-time). This (as of yet) unjustified complexity is what the PR is about.

Neither you know how the 80 lines of wrong code harms users (or more precisely: you tend to ignore that).
However - the C::AC bundle is smaller that 3k LoC, T::WV+D::T is clear need being wiped out - but not in a dumb way but in a smart way.
Cheers
Jens Rehsack -<EMAIL_ADDRESS>

Neither you know how the 80 lines of wrong code harms users (or more precisely: you tend to ignore that).

I never denied that I have no idea what you mean by wrong code. Moreover I am evidently not the only one who can not grok your explanation of why you need user-side test generation. The situation is doubly-perplexing given that methods of doing it 99.9% correctly with minimal amount of user-side moving parts is a long-solved problem.

However - the C::AC bundle is smaller that 3k LoC

Still utterly missing (or deliberately ignoring) the actual problem...

Am 04.05.2015 um 20:19 schrieb shadowcat-mst<EMAIL_ADDRESS>If it's too young to be critiqued yet, then surely it's also too young to be used in an infrastructure level distribution like List::MoreUtils.

Sounds to me like you want to misunderstand what I wrote.

I appreciate your desire to experiment with better solutions in this space, but you shouldn't be doing that on a dist that's this heavily embedded in applications' dep chains.

I'm sorry when I reply to an unreflected answer to my explanations always the same way: Please dig deeper into the problems I'm trying to solve and discuss on that level. Whenever the shot is a one- or two-sentence platitude, what kind of answer is expected?
C::AC is not young. T::WV/D::T is - and I'm happy to discuss ways to eliminate it. Discussing means speaking about design before implementation, having a strategy and listening to all open issues need to be resolved when touching the stuff.
IIRC we negotiated to have an hour during FOSDEM developing some strategy how to get rid of T::WV in LMU - but unfortunately we didn't manage it.
Cheers
Jens Rehsack -<EMAIL_ADDRESS>

Am 04.05.2015 um 20:35 schrieb Peter Rabbitson<EMAIL_ADDRESS>
Neither you know how the 80 lines of wrong code harms users (or more precisely: you tend to ignore that).

I never denied that I have no idea what you mean by wrong code.

So when - after several explanations - (vou) don't understand what I mean by /wrong code/ - and no questions rwrt. the explanation is coming back but rhetoric claims wrt. overly-complex starting again and again, what conclusion is the one I have to extract?

Moreover I am evidently not the only one who can not grok your explanation of why you need user-side test generation. The situation is doubly-perplexing given that methods of doing it 99.9% correctly with minimal amount of user-side moving parts is a long-solved problem.

Can you provide the calculation for the 99.9%?

However - the C::AC bundle is smaller that 3k LoC

Still utterly missing (or deliberately ignoring) the actual problem...

Reviewing the patch, it's a big part of the original problem and I've not seen before this reply a reduction to user-side test generation (which is wrong, it doesn't generate test, it generate test endpoints). Please explain the actual problem.
So - beside the offending rhetoric - what's (with https://rt.cpan.org/Public/Bug/Display.html?id=102885, distribution splitting and test sharing without manual copy of code!) a reasonable way to have the test endpoints generated in deployed tarball? With the picture I have of the final result of rework, there is no generated test endpoint at all.
However - respecting the "form follows function" guideline - I intend to postpone the infrastructural cleanup after discussing lacking features and requirements. While this step in in progress, explain why reducing infrastructure capabilities before knowing about all requirements of the distribution is reasonable.

@rehsack Please concentrate on the proposed PR (which is merely 214 lines to review):

How does this PR reduce functionality (what makes it less robust than what you have now)
How does it relate to https://rt.cpan.org/Ticket/Display.html?id=102885

So far you have not addresses either of these questions.

I commented that very long in https://github.com/perl5-utils/List-MoreUtils/pull/9#issuecomment-88810202.

I reread the entire comment just now. From that comment the only currently relevant part is this:

The first one shall be fixed by filling check_produce_loadable_xs_build with code which tries to load an intermediately built XS module when host == target and tries to nm/parseelf (as a result from deeper discussion with Merijn and Leon) when host != target.

It is addressed in a less verbose manner by https://metacpan.org/source/LEONT/ExtUtils-HasCompiler-0.002/lib/ExtUtils/HasCompiler.pm#L107 (this is work in progress, but already on par with C::AC).
As far as I can see the rest of your comment no longer applies (there are no further configure-time checks the module requires). This the question - if the PR is amended with use of EU::HasCompiler - does it address all the practical issues (leaving the political aside)?

Am 05.05.2015 um 09:41 schrieb Peter Rabbitson<EMAIL_ADDRESS>I reread the entire comment just now. From that comment the only currently relevant part is this:

That was much to fast with checking the cited PR's and the follow-up's, but ...

The first one shall be fixed by filling check_produce_loadable_xs_build with code which tries to load an intermediately built XS module when host == target and tries to nm/parseelf (as a result from deeper discussion with Merijn and Leon) when host != target.

It is addressed in a less verbose manner by https://metacpan.org/source/LEONT/ExtUtils-HasCompiler-0.002/lib/ExtUtils/HasCompiler.pm#L107 (this is work in progress, but already on par with C::AC).
As far as I can see the rest of your comment no longer applies (there are no further configure-time checks the module requires). This the question - if the PR is amended with use of EU::HasCompiler - does it address all the practical issues (leaving the political aside)?

$Config::Config{cc} is not political wrong, it's technical wrong. can_xs() will succeed even with completely different(*) header files than the running configure stage, will succeed without proving linking or loading, ignores cross-compiling and is completely manual code copying in case of fixes and enhancements.
*) different in "belongs to another perl"

That was much to fast with checking the cited PR's and the follow-up's, but ...

I was already re-reading the PRs to make sure I am not missing anything before your "look here".

...can_xs() will succeed...

I wasn't talking about can_xs(), I was asking you about can_compile_loadable_object()
Can we focus on that please?

Am 05.05.2015 um 09:54 schrieb Peter Rabbitson<EMAIL_ADDRESS>That was much to fast with checking the cited PR's and the follow-up's, but ...
I was already re-reading the PRs to make sure I am not missing anything before your "look here".
...can_xs() will succeed...
I wasn't talking about can_xs(), I was asking you about can_compile_loadable_object()
Can we focus on that please?

Sure, I misunderstood it. I had several discusses with @leont about that (one longer face to face meeting at FOSDEM with Tux, nine and FROGGS) and he agreed to summarize the state of the work for review. There it stucks at the moment.
Even if there is another external module proving a better "HasCompiler" - it doesn't answer the can_xs (which is one of the goals of C::AC). Due TIMTOWTDI ....
There are likely several configure time checks remaining (needs research):

PadWalking
MAX/MIN Integer values

and maybe more (we're currently discussing harmonizing iterator- and partitioning functions).
As far as I can currently see, with some extra effort it will be possible to move all test endpoint generation to author side (this is one of the major results from using D::T/T::WV in LMU I discussed with Tim - but there were no tuits meanwhile ...). Anyway - concentrating on features before will make us sure and not best-guessing.
Cheers
Jens Rehsack -<EMAIL_ADDRESS>

Am 05.05.2015 um 09:41 schrieb Peter Rabbitson<EMAIL_ADDRESS>I reread the entire comment just now. From that comment the only currently relevant part is this:
The first one shall be fixed by filling check_produce_loadable_xs_build with code which tries to load an intermediately built XS module when host == target and tries to nm/parseelf (as a result from deeper discussion with Merijn and Leon) when host != target.
It is addressed in a less verbose manner by https://metacpan.org/source/LEONT/ExtUtils-HasCompiler-0.002/lib/ExtUtils/HasCompiler.pm#L107 (this is work in progress, but already on par with C::AC).

Where is this $config coming from: https://metacpan.org/source/LEONT/ExtUtils-HasCompiler-0.002/lib/ExtUtils/HasCompiler.pm#L118 ?
ExtUtils::Config looks like a wrapper around Config.pm ...
If the ExtUtils::Config is intended to be a container for several checkers as C::AC could be, I don't understand how it can reduce complexity. Maybe it's more a question of control?
The compiler support is kind-of vague (from code review of mentioned 214 lines) and can be broken easily when relying on distributed sstate-cache builds in several large package builders...

I had several discusses with @leont about that (one longer face to face meeting at FOSDEM with Tux, nine and FROGGS) and he agreed to summarize the state of the work for review. There it stucks at the moment.

I was unexpectedly busy before Berlin, and then suddenly you weren't there, hence that kind of fell through.

If the ExtUtils::Config is intended to be a container for several checkers as C::AC could be, I don't understand how it can reduce complexity.

It's meant to allow one to override Config values, as the real thing is read-only.

The compiler support is kind-of vague (from code review of mentioned 214 lines) and can be broken easily when relying on distributed sstate-cache builds in several large package builders...

It's young, if something about it is broken in some circumstance please file an issue, I'm sure it can easily be solved.

Am 05.05.2015 um 13:49 schrieb Leon Timmermans<EMAIL_ADDRESS>I had several discusses with @leont about that (one longer face to face meeting at FOSDEM with Tux, nine and FROGGS) and he agreed to summarize the state of the work for review. There it stucks at the moment.
I was unexpectedly busy before Berlin, and then suddenly you weren't there, hence that kind of fell through.

The entire PR and the discussion about it and the russian front against it are much older than qah2015 ...
It started before qah2014 - and the personal level it reaches again and again ...

If the ExtUtils::Config is intended to be a container for several checkers as C::AC could be, I don't understand how it can reduce complexity.
It's meant to allow one to override Config values, as the real thing is read-only.

Than it's not enough for being a probe result backend (cc, cflags, includes, ... are probe results - similar to HAVE_STDINT_H, or which limits.h to include (sys/limits.h, limits.h, etc.) ...)

The compiler support is kind-of vague (from code review of mentioned 214 lines) and can be broken easily when relying on distributed sstate-cache builds in several large package builders...
It's young, if something about it is broken in some circumstance please file an issue, I'm sure it can easily be solved.

None of that was meant as an affront - I know these. It was meant to enlighten Peter, because he asked.
Very likely over summer we find some tuits to improve. When you're not that busy anymore - we could start the discussions about probes and portability issues we talked about on FOSDEM. Maybe hangout or so - just to avoid new flame wars while working ...

...with some extra effort it will be possible to move all test endpoint generation to author side...

@rehsack The above quote is entirely what this ticket is about. What you end up doing during make dist does not really concern anyone in this thread (as far as I can tell). This is also the answer to your latest question https://github.com/perl5-utils/List-MoreUtils/pull/9#issuecomment-98753300: the PR can be considered resolved when .t -generation at configure/build time disappears.
Everything else is secondary.

Am 05.05.2015 um 14:33 schrieb Peter Rabbitson<EMAIL_ADDRESS>...with some extra effort it will be possible to move all test endpoint generation to author side...
@rehsack The above quote is entirely what this ticket is about.

The code speaks another language. The change could be much smaller in that case - and this is probably something (keeping the D::T infrastructure for that) which could be done in near future.

What you end up doing during make dist does not really concern anyone in this thread (as far as I can tell). This is also the answer to your latest question #9 (comment): the PR can be considered resolved when .t -generation at configure/build time disappears.

I disagree - this PR is about configuration stage complexity in general.
We could break this topic of and solve it separately. I'm not sure whether Data::Tumbler needs enhancements for that (@timbunce, are you interested and available to discuss that?), but it's very likely. It's not a no-brainer, but very less heavy than questioning "configuration stage complexity in general".

Moreover I am evidently not the only one who can not grok your explanation of why you need user-side test generation. The situation is doubly-perplexing given that methods of doing it 99.9% correctly with minimal amount of user-side moving parts is a long-solved problem.

I'm afraid I have to agree. When none of @haarg, @dagolden, me, @ribasushi or @shadowcat-mst understand why this is a good idea, you're either not explaining yourself clearly or it isn't a good idea.

Moreover I am evidently not the only one who can not grok your explanation of why you need user-side test generation. The situation is doubly-perplexing given that methods of doing it 99.9% correctly with minimal amount of user-side moving parts is a long-solved problem.

I'm afraid I have to agree. When none of @haarg, @dagolden, me, @ribasushi or @shadowcat-mst understand why this is a good idea, you're either not explaining yourself clearly or it isn't a good idea.

I seriously thought I made clear that this specific part has been picked for improving before FOSDEM between @shadowcat-mst and me - but unfortunately we didn't manage the session. So - there're requirements to be fulfilled while turning the tests in author side preparation - but the question if is answered with "yes" several month ago. The question whether it was a good idea has been asked, too (without integer overflow bug in mind - because of use-case ...) - and must be answered with "yes".
Since we don't have a lmu-workers@ - all those negotiations are between individuals. OTOH - I see the responses regarding to AnyData2 on dbi-dev@ - Mailing lists prevent responsibility (being taken by individuals) ...

The code speaks another language. The change could be much smaller in that case - and this is probably something (keeping the D::T infrastructure for that) which could be done in near future.

Das halte ich für eine Fehlinterpretation. Niemand ausser dir weiss, wie und wozu du D::T auf der Maintainer-Seite verwenden willst, und deshalb wirst du auch von niemandem einen Patch bekommen, der deine Anforderungen für Maintainer-Erzeugung von Tests – unter Verwendung von D::T – umsetzt. Daher ist die Entfernung von D::T hier auch nicht als Ablehnung von D::T zu verstehen, sondern nur als Ablehnung des Einsatzes von D::T in der Weise, wie du es eingesetzt hast, nämlich auf Seiten des installierenden Benutzers.
(Dein English ist leider schwer – und teilweise gar nicht – zu verstehen, selbst für mich als Fast-Deutsch-Muttersprachler und fliessendem Englisch-Sprecher.  Ich wurde gebeten, ein bisschen Vermittlung zu versuchen. Am besten antwortest du auf Deutsch und ich versuche, dich dann auf Englisch wiederzugeben.)

English: I consider this a misreading. No one besides you knows how and what for you want to use D::T on the authoring side, so you’re not going to receive any patches that implement your requirements for the authoring side (based on D::T). Therefore the removal of D::T in this patch is not to be understood as opposition to D::T as such, but only as opposition to its use in the form you actually used it, namely, at install time on the user end.
(Unfortunately your English is hard – and sometimes impossible – to understand, even for me as both an effectively-native German speaker and fluent English speaker. That doesn’t particularly help the communication efforts. I was asked to try to mediate a little. Preferably answer in German and I’ll try to recount you in English.)

Ich bedanke mich vielmals für Deine Moderation.    Allerdings erfasse ich tatsächlich nicht jede Nuance im englischen.
Wie auch immer - sollte das Thema "Vermeidung von Test-Generierung beim Endbenutzer" sein, ist mein Übersetzer kaputt. Bei mir kam in der vorgehenden Debatte im IRC und auch in den anfänglichen Diskussionen an: "dynamic_configuration is bad at all. Your use of it is even worse. Because noone understands your code, the approach in unperlish."

At first I thank you very much for your moderation. I appreciate the opprtunity to answer in German - and put the english translation below as you did. Doing so might result in getting some hints to make my English less hard.
As said - the discussion isn't new. I'm torn whether my interpretion is really a misreading - or the evolution of the thread caused a misunderstanding. For sure, I don't get any nuance in english sentences.
However - if the topic is "Avoidance of user-side test generation", my translator is broken. I read in the preceded debate on IRC and the initial discussion: "dynamic_configuration is bad at all. Your use of it is even worse. Because noone understands your code, the approach is unperlish."
The fact that the test-generation at end-users should be removed anyway, because I prefer the split of the List::MoreUtils::XS into a separate distribution - and because of being very constructive help (being sounding-boards) at preceeding discussions from @dagolden and @shadowcat-mst, causes lack of understanding for the vehemence of the debate at all.

This PR is specifically to achieve "avoidance of user-side test generation".
Our entire upset here is centered on the giant inc/ for user-side test generation.
That has been the primary complaint ever since you started doing that.

I think that your own self-translation gets the point across, but let me give another translation of that:

Thank you very much for your mediation. I will gladly answer in German – and follow it with the English translation, as you did. Then maybe I can swipe a few tips for English too. :)
As I said – this is not a new discussion. So I’m not so sure that my interpretation is a misreading – or that the progression caused the misreading. However, I do indeed not grasp every nuance in English.
Anyhow – should the subject really be “avoiding test generation on the user side”, then my translator is broken. What I got from the previous debate on IRC and also the initial discussion was: “dynamic_configuration is bad at all. Your use of it is even worse. Because noone understands your code, the approach in unperlish.”
The fact that I already wanted to move away from test generation on the user side anyway, because I wish to split List::MoreUtils from List::MoreUtil::XS – which, after a lot of consideration from @dagolden and @shadowcast-mst, I no longer see a need for, makes the vehemence of the debate even less understandable to me.

This PR is specifically to achieve "avoidance of user-side test generation".

Ich glaube ich bin im falschen Film! Der initiale Patch räumt alles weg - jeden Probe, jedes Konzept - und ersetzt es durch 70% Code aus der eigenen Code-Basis. Klassisches NIH. Die Überschrift ist "Vereinfachung der ... Konfiguration". https://github.com/perl5-utils/List-MoreUtils/pull/9#issuecomment-98786543 sagt, wie ich den PR verstehe. Da schreibe ich noch, das ich denke, das inc/ niemanden wirklich stört, was mir @shadowcat-mst auch am 30. April 2014 01:34 in "Future of LMU - Open Points" bestätigte. Und danach stand das irgendwie nie mehr zur Debatte. https://github.com/perl5-utils/List-MoreUtils/pull/9#issuecomment-98797573 geht genau gegen inc/ vor - und nun geht's plötzlich nur um "Vermeidung von Test-Generierung beim End-User"? Mal abgesehen vom kontextfreien https://github.com/perl5-utils/List-MoreUtils/pull/9#issuecomment-98802915 - der meta-physiche Probleme aufgrund der hohen App-Abhängigkeiten anprangert.

I guess I'm in the wrong movie! The intial patch removes everything of my configure stage - any probe, any concept - and replaces it by code from self-maintained code-base. Classic NIH. The Title is "Simplify ... configuration setup". https://github.com/perl5-utils/List-MoreUtils/pull/9#issuecomment-98786543 explains explicitely how I understand the PR - and that I think no end-user is bothered by inc/, what I got told by mst on April 30th, 2014 01:34 in "Future of LMU - Open Points". After that small clarification, the point (inc/ as such) wasn't discussed again. OTOH, https://github.com/perl5-utils/List-MoreUtils/pull/9#issuecomment-98797573 blames inc/ in general. Not bundling in general, but many LoC's in inc/ (how to distinguish that could be one of the minreadings). But now we're from beginning on talking about "avoidance of user-side test generation"? Beside of https://github.com/perl5-utils/List-MoreUtils/pull/9#issuecomment-98802915 - which continues "this, it" context free blaming of meta-physics related issues because of deep in-depth chain.

Our entire upset here is centered on the giant inc/ for user-side test generation.

  29 inc/Config/AutoConf/LMU.pm
 856 inc/inc_Capture-Tiny/Capture/Tiny.pm
3733 inc/inc_Config-AutoConf/Config/AutoConf.pm
 341 inc/inc_Data-Tumbler/Data/Tumbler.pm
  26 inc/inc_JSON-PP/JSON/PP/Boolean.pm
 173 inc/inc_JSON-PP/JSON/PP/Compat5006.pm
2795 inc/inc_JSON-PP/JSON/PP.pm
 129 inc/inc_Module-Pluggable/Devel/InnerPackage.pm
 425 inc/inc_Module-Pluggable/Module/Pluggable/Object.pm
 462 inc/inc_Module-Pluggable/Module/Pluggable.pm
 299 inc/inc_Test-WriteVariants/Test/WriteVariants/Context.pm
 621 inc/inc_Test-WriteVariants/Test/WriteVariants.pm
 147 inc/latest/private.pm
   8 inc/latest.pm
 157 inc/Tumble.pm

10201 total
The biggest two are JSON::PP and Config::AutoConf. While the first one is a core module in later perl's, the second one seems to be out of scope. What are we talking about?

That has been the primary complaint ever since you started doing that.

Ich mag ganz ehrlich nicht meine Zeit mit solchem Kinderkram vertrödeln. Das Thema selbst ist durch - der Thread ist offensichtlich komplett anders gelaufen als gemeint. Öffnet ein RT "Avoidance of user-side test generation" - schreibt rein, was Euch zu exakt diesem Thema auf der Seele brennt, und dann brauche ich 1-2 Freiwillige, die die Anforderungen (keine Code-Duplizierung, keine manuellen Aktionen, Trennung von Distributionen, Einbindung der Überlauf-Checks, ...) mit mir durchgehen und Ideen sammeln, wie man das sinnvoll lösen kann. Muss auch nicht sein, dann liegt's im Zweifel so lang rum, bis mir was einfällt.

Here I wait for translation by @ap (even if I don't see @ap as pure translator).

English:

This PR is specifically to achieve "avoidance of user-side test generation".

That’s some parallel universe stuff! The initial patch blows everything away – every probe, every concept of it – and replaces it with code of which 70% is from the local code base. Classic NIH. The subject is “Simplify … configuration setup”. https://github.com/perl5-utils/List-MoreUtils/pull/9#issuecomment-98786543 gives my understanding of the PR. I even wrote there that I think that inc/ doesn’t really bother anyone, which @shadowcat-mst confirmed to me in "Future of LMU - Open Points" on April 30, 2014 at 01:34. Thereafter it was never brought up again. https://github.com/perl5-utils/List-MoreUtils/pull/9#issuecomment-98797573 is precisely aimed against inc/ – and now it’s suddenly all just about “avoiding user-side test generation”? Aside from the context-less https://github.com/perl5-utils/List-MoreUtils/pull/9#issuecomment-98802915 – which warns of metaphysical problems due to heavy app dependencies.

Our entire upset here is centered on the giant inc/ for user-side test generation.

   29 inc/Config/AutoConf/LMU.pm
  856 inc/inc_Capture-Tiny/Capture/Tiny.pm
 3733 inc/inc_Config-AutoConf/Config/AutoConf.pm
  341 inc/inc_Data-Tumbler/Data/Tumbler.pm
   26 inc/inc_JSON-PP/JSON/PP/Boolean.pm
  173 inc/inc_JSON-PP/JSON/PP/Compat5006.pm
 2795 inc/inc_JSON-PP/JSON/PP.pm
  129 inc/inc_Module-Pluggable/Devel/InnerPackage.pm
  425 inc/inc_Module-Pluggable/Module/Pluggable/Object.pm
  462 inc/inc_Module-Pluggable/Module/Pluggable.pm
  299 inc/inc_Test-WriteVariants/Test/WriteVariants/Context.pm
  621 inc/inc_Test-WriteVariants/Test/WriteVariants.pm
  147 inc/latest/private.pm
    8 inc/latest.pm
  157 inc/Tumble.pm
10201 total

The biggest two are JSON::PP and Config::AutoConf. While the first one is a core module in later perl's, the second one seems to be out of scope. What are we talking about?

That has been the primary complaint ever since you started doing that.

Honestly I have no desire to waste my time with such childish stuff. The topic itself is over – the thread evidently went completely different from how it was meant. Open an RT “Avoidance of user-side test generation”, put down what actually is weighing so heavily on you, and then I’ll need a volunteer or two to go through the requirements with me (no code duplication, no manual action, separation of distributions, integration of overflow checks, etc) and collect ideas for how to solve those sensibly. Though even that isn’t necessary, worst case it’ll have to sit around until I come up with something myself.

Here I wait for translation by @ap (even if I don't see @ap as pure translator).

Habe ich deine Antwort in meiner Übersetzung irgendwie verfälscht?
Did I distort your reply in any way in my translation?

On Tue, May 05, 2015 at 12:30:24PM -0700, Aristotle Pagaltzis wrote:

English:

This PR is specifically to achieve "avoidance of user-side test generation".

That’s some parallel universe stuff! The initial patch blows everything away – every probe, every concept of it – and replaces it with code of which 70% is from the local code base. Classic NIH.

Those can_xs, can_cc subroutines are not NIH, they're the de facto standard
that's used widely across low level CPAN stuff.
They've already been well tested.
You're the one reinventing the wheel here, and until it's a properly stable
wheel, I don't believe it belongs in LMU.
--
Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue
http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/
Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN
commercial support, training and consultancy packages could help your team.

German:
Diese can_xs, can_cc, etc Subroutinen sind kein NIH, sondern der de-facto-Standard – sie kommen in ebendieser Form weithin innerhalb low-level CPAN-Kram zum Einsatz.
Sie sind schon gut getestet.
Du bist derjenige, der hier das Rad neu erfindet – und bis es ein ordentlich stabiles
neues Rad ist, gehört es nach meinem Dafürhalten nicht in LMU.

Ich habe mir das angesehen und brauche keine halbe Stunde (siehe https://github.com/perl5-utils/List-MoreUtils/pull/9#issuecomment-98985992) um mehere Problempunkte aufzuzeigen. Ich habe in kleiner Runde diese Codeschnippsel bereits kritisiert. Da Du diese Punkte weder aufgreifst noch @ribasushi 's ExtUtils::HaveCompiler Review-Anfrage kommentierst, sehe ich nicht, was Dich außer der nicht-Verwendung der deiner Meinung nach korrekten Lösung, stört.
 (Don't use compiler wrappers who fix broken arguments, add missing rpath etc.).

English:
I looked at it and it didn’t take me half an hour (see https://github.com/perl5-utils/List-MoreUtils/pull/9#issuecomment-98985992) to point out several problems. In a closer circle I have criticised those snippets before. Since you neither address those points nor comment on @ribasushi’s request for ExtUtils::HaveCompiler review, I don’t see what bugs you, aside from the non-use of what you consider the correct solution.
Many of these problems with the code, I have already run into – and rather than work on the code there are only suggestions for how to prevent running into its problems. (Don't use compiler wrappers who fix broken arguments, add missing rpath etc.)
I’m sorry, but “well tested” means nothing if the tests do not cover certain use cases (possibly inherently).

Alright, let's try this again.
I would rather use something widely used that means that it will be broken in the exact same way as most of the rest of my low level dependencies in the case that it is broken, than something completely new and under-tested with completely unknown failure modes.
This is systems level work. The principle of least surprise is important.
If you think that your approach will, once it's actually been tested enough to be considered stable, be better, that's a good reason to continue working on it.
But not in List::MoreUtils. For List::MoreUtils we need to be conservative, or you need to put a big warning in the POD saying "unstable, do not rely on this for enterprise-level production stability guarantees" and I need to move most of my distributions to depending on something that is conservative.
If I wanted things replaced every other week with untested new ideas, I could go write node.js for a living.

German:
Also gut, noch mal von vorn.
Mir ist es lieber, etwas zu weithin verwendetes zu nehmen, das dadurch in genau der gleichen Art defekt ist wie der Rest meiner low-level-Abhängigkeiten, als etwas brandneues und unzureichend getestetes mit vollständig unbekanntem Ausfallverhalten.
[Das lasse ich mal Englisch, da schwer zu übersetzen. / I’ll leave this in English because it’s hard to translate.]
This is systems level work. The principle of least surprise is important.

Aber nicht innerhalb von List::MoreUtils.
Wenn ich meinen Krempel im Wochentakt durch neue nicht getestete Ideen ersetzt haben wollte, könnte ich meinen Lebensunterhalt auch mit node.js bestreiten.

Mir ist es lieber, etwas weithin verwendetes zu nehmen, das dadurch in genau der gleichen Art defekt ist wie der Rest meiner low-level-Abhängigkeiten, als etwas brandneues und unzureichend getestetes mit vollständig unbekanntem Ausfallverhalten.

Und das steht Dir natürlich frei. Da für mich eine Architektur aus den 1990'er Jahren, eine erste Perl-Implementierung von 2005 und die aktuelle Lösung von 2012 nicht wirklich brandneu ist, bin ich da etwas befremded bezüglich der beweisfreien Aburteilung. Aber da ist scheinbar jeder anders - es sei Dir unbenommen, Deine Distributionen mit bekannten Fehlern in der Infrastruktur auszustatten.
Es ist nicht wahr, das auf System-Ebene das Prinzip der geringesten Überraschung an erster Stelle steht, an erster Stelle steht insbesondere auf der System-Ebene die (Daten-)Integrität und Zuverlässigkeit. Es scheint mir, Du interpretierst Zuverlässigkeit in der Art "Ich kann mich darauf verlassen, das ein Prozess immer auf die gleiche Art und Weise fehlschlägt" anstatt "Ich kann mich darauf verlassen, das ein Prozess funktioniert". Ich halte diese Interpretation für fahrlässig.
Ich denke nicht nur, das mein Ansatz irgendwann einmal ausreichend getestet sein wird, ich denke, das er das ist.
 Wir reden aber über Infrastruktur, und zwar auf der Ebene Konfigurationsphase. Bitte hör auf, hier Ebenen zu vermischen!
Wenn Du mit meiner Art der Distributionspflege nicht einverstanden bist, darfst Du gern wirklich Zeit investieren und wir diskutieren viele Details aus.

Wenn ich meinen Krempel im Wochentakt durch neue nicht getestete Ideen ersetzt haben wollte, könnte ich meinen Lebensunterhalt auch mit node.js bestreiten.

Der ganze Thread ist voll von diesen Provokationen. Bitte bleib sachlich.

I looked at it and it didn’t take me half an hour (see #9 (comment)) to point out several problems. In a closer circle I have criticised those snippets before.

You keep saying there are issues with other solutions, but does your solution really fix it? Today? Config::AutoConf is based on ExtUtils::CBuilder, which IME isn't more likely to do something sensible than what @haarg proposed. AFAICT, nothing takes things like cross-compilation much into account today. Or am I mistaken?

English:

I would rather use something widely used that means that it will be broken in the exact same way as most of the rest of my low level dependencies in the case that it is broken, than something completely new and under-tested with completely unknown failure modes.

And of course you are free to do that. To me, a design from the ’90s with a first implementation in Perl in 2005 and the current solution from 2012 is not in fact completely new, therefore I am a little taken aback by the proofless dismissal. But apparently everyone is different in that respect – of course you ought to be at liberty to equip your distributions with known flaws in their infrastructure.
It’s not true that the principle of least surprise has primacy in systems level work, what comes first is (data) integrity and reliability. It seems to me that you interpret reliability as in “I can rely on a process always failing in the same way” rather than “I can rely on a process working”. I consider this interpretation negligent.
I do not merely think that my approach will eventually be sufficiently tested, I think that it is.
The configuration phase has no influence on the stability of the code itself – though I reserve the right to fix or optimise the code too – naturally not without dev releases. But we are talking about infrastructure, and specifically at the level of the configuration phase. Please stop mixing up the levels!
If you do not agree with my way of distribution maintainership, you are welcome to invest time properly and we can thrash out the details.

If I wanted things replaced every other week with untested new ideas, I could go write node.js for a living.

The entire thread is full of these provocations. Please stay objective.

German:

Ich habe mir das angesehen und brauche keine halbe Stunde (siehe https://github.com/perl5-utils/List-MoreUtils/pull/9#issuecomment-98985992) um mehere Problempunkte aufzuzeigen. Ich habe in kleiner Runde diese Codeschnippsel bereits kritisiert.

Du redest ständig von Problemen mit anderen Lösungen, aber korrigiert deine Lösung diese wirklich? Hier und heute? Config::AutoConfig basiert auf ExtUtils::CBuilder, welches meiner Erfahrung nach keine höhere Wahrscheinlichkeit zeigt, etwas Sinnvolles zu tun als der Vorschlag von @haarg. Soweit ich beurteilen kann werden Dinge wie Cross-Kompilierung von nichts Verfügbarem grossartig berücksichtigt.
Liege ich da falsch?

Du redest ständig von Problemen mit anderen Lösungen, aber korrigiert deine Lösung diese wirklich?

Die meisten, jedoch nicht alle.

Soweit ich beurteilen kann werden Dinge wie Cross-Kompilierung von nichts Verfügbarem grossartig berücksichtigt.
Liege ich da falsch?

Ja. Siehe https://metacpan.org/source/REHSACK/Unix-Statgrab-0.107/inc/Config/AutoConf/SG.pm und https://github.com/rehsack/meta-cpan/tree/master/recipes-sysutils/unix-statgrab-perl.
Um das alles mal zu zeigen, wollte ich ja mit meiner Build-Workstation zum QAH kommen - mir ist durchaus bewusst, das die meisten TPG Hacker eher im Rechenzentrums-Umfeld arbeiten.

English:

You keep saying there are issues with other solutions, but does your solution really fix it?

Most of them, though not all.

AFAICT, nothing takes things like cross-compilation much into account today. Or am I mistaken?

You are. See https://metacpan.org/source/REHSACK/Unix-Statgrab-0.107/inc/Config/AutoConf/SG.pm and https://github.com/rehsack/meta-cpan/tree/master/recipes-sysutils/unix-statgrab-perl.
Showing all of this stuff was the reason I wanted to bring along my build workstation to the QAH – I am well aware that most TPG hackers work in more of a data center environment.

You keep saying there are issues with other solutions, but does your solution really fix it?

That's exactly the question we've been asking of you all along, and 'really fix it' won't be proven until you use it for a year or two in a non-critical distribution.
In the meantime, how about letting LMU be stable while you prove that your solution really does fix it?

German:

Du redest ständig von Problemen mit anderen Lösungen, aber korrigiert deine Lösung diese wirklich?

Wie wäre es für die Zwischenzeit damit, LMU stabil sein zu lassen, während du den Praxisbeweis deiner Lösung erbringst?

Du redest ständig von Problemen mit anderen Lösungen, aber korrigiert deine Lösung diese wirklich?

Ich habe diese Frage bereits beantwortet.  Und zwar nicht nur in Distributionen von mir, eine Suche im Herbst ergab 28 Benutzer, die C::AC aktiv verwenden.

Wie wäre es für die Zwischenzeit damit, LMU stabil sein zu lassen, während du den Praxisbeweis deiner Lösung erbringst?

Hier vermischt Du C::AC und D::T - das erstere ist stabil, das letztere hat sich noch nicht bestätigt.
Das ist - so wie ich das jedenfalls sehe - auch meine Haltung den ganzen Thread über.
Ich bin im übrigen auch gern bereit, ein bis zwei Einführungs-Workshops zu C::AC zu geben. Ich kann durchaus verstehen, das sich Hirnknoten bilden, wenn man das reviewed.

Ich würde gern noch etwas hinzufügen (@ap: Kann eingefügt werden, ich wollte nur einer etwaigen laufenden Übersetzung nicht reinschießen).
Für den Fall, das Du meinst, die Lösung sollte für mehr als ein Jahr von der TPG beobachtet werden, bevor ... - ich habe in Kiew dazu einen Vortrag gehalten, das ist auch etwas her. Die Aufmerksamkeit auf etwas ungewolltes zu lenken, ist bei sturen Genies unglaublich schwer - und ggf. müssen diese dann mit anderen Formen der Beweisführung leben.  Selbst dann verfügt meine Lösung über einen nicht zu unterschätzenden Vorteil: jede Probe wird mit Ergebnis geloggt. Wenn also Makefile.PL aussteigt, bekommen wir ein log, in dem drin steht, was und in >90% der Fälle auch warum etwas fehlschlug. Und da wir nun doch etwas vor der aktuell massenhaft eingesetzten Lösung sind - sind das gleich zwei Vorteile.

From @rehsack:

You keep saying there are issues with other solutions, but does your solution really fix it?

That's exactly the question we've been asking of you all along, and 'really fix it' won't be proven until you use it for a year or two in a non-critical distribution (as it wouldn't if said fix was my idea too).

I have already answered that. And the fix has been in use in some non-critical distributions for significantly longer than a year, in order to be proven. And that’s not just in my own distributions: a search I did in autumn turned up 28 active users of C::AC.

In the meantime, how about letting LMU be stable while you prove that your solution really does fix it?

Now you are confusing C::AC with D::T – the former is stable, the latter is not yet proven.
And that has – in my own perception – been my stance for the entire duration of this thread.
Incidentally I am entirely willing to give one or two introductory workshops about C::AC. I can well understand that it’s a brain twister to review.

More from @rehsack:
In case you mean the solution should be monitored by TPG for more than a year, before [etc] – I gave a talk in Kiev regarding that (even that has been a while). Turning the attention to something unwanted is incredibly difficult [for/with?] stubborn geniuses – so they may have to live with other forms of proof. I am currently noticing that with ShareDir and the like as well.
Even if it’s arseholish on some level – if nothing happens in such matters for over half a year and after multiple requests, the feedback window is quite simply closed.
Re “really fix” – let’s just assume for the sake of discussion that my solution went no further than the widely used one. Even then my solution possesses an advantage that is not to be sneezed at: every probe plus result is logged. So when a Makefile.PL aborts, we get a lot that says what failed and in >90% of cases also says why. And since in fact we are ahead of the widely used solution – that actually makes two advantages.

IMO there are two intertwined but different issues at play here. I suspect it may be helpful to split the them.
The first is that of configure-phase test generation. I think there's broad consensus that that is better moved to the dist-building phase. I think there is less agreement on what priority this has and whose responsibility it is to do this. For some this is dangerous and needs to be fixed urgently, for Sno I think that's a "go ahead, but other requirements must be taken care of". This is the main topic in this ticket.
The second is issue is how to do the compilation checking. This got entwined because currently it is part of the configure-phase test generation, but does not necessarily have to be. I suspect this belongs in a separate ticket.

Von @Leont:
Meiner Meinung nach sind hier zwei verflochtene aber unterschiedliche Aspekte in Spiel. Ich vermute dass es hilfreich wäre, sie getrennt zu betrachten.
Das erste Thema ist die Test-Erzeugung in der Configure-Phase. Ich denke dass weitgehender Konsens besteht, dass das in die Distributions-Bau-Phase verschoben werden sollte. Ich glaube dass es weniger Einigkeit darüber gibt, welche Priorität das hat und wessen Verantwortung es ist. Einige halten es für gefahrenträchtig und umgehend zu beheben, während Sno’s Haltung eher nach »immer zu, aber andere Anforderungen müssen erfüllt werden« neigt. Das ist das Hauptthema in diesem Ticket.
Das zweite Thema ist, wie der Compile-Test funktionieren soll. Das hat sich hier eingewoben, weil es gegenwärtig Teil der Test-Erzeugung in der Configure-Phase ist, was aber nicht notwendigerweise so sein muss. Ich vermute dass das eher in ein anderes Ticket gehört.

@ap: You've done a splendid job translating this train-wreck of a conversation. I think at this point the intents of all parties are crystal clear, and there is no room for subtlety. Hence the thread should switch to english, so that the significant effort of translation is not necessary.
Not that there is much left to say.

The very most important part from @ap's job was the removal of the pressure. He did it by doing an impressive job in translating - but the intents of all parties are clear as few days ago - at least to me ...
So from my perspective, the effort of @ap was the transporting my intension to everyone else.
Dunno whether you want miss that kind of support.
@leont - generating the currently used test endpoints on developer side is more or less a no-brainer. This can easily be done (even if sane authoring implementation needs a little bit more than copy some files and never touch them  again) - and I would do if one opens a ticket and explains the priority (all I read is a bad mood because of that - and I received some offers for bikeshedding which never comes - so I postponed the work because I assumed everything is ok).
My impression is still that most of the thread is more about mood than about hard facts.

My impression has been that at the time I started, there was significant miscommunication on both sides. At this point the major confusion seems sorted out.

That's true - and I've learned a lot about how nice and beautiful english language could be. Thanks a lot for mediation and enlightening.
@rest - what about 91f51ea ? When this makes some of you happy - I'm fine with it.

Commenting on the "Sandbox" part of 91f51eae6a33177 (only): it does solve the issue of user-side test generation. The only note to add is that across CPAN the generically used name for "Sandbox" is maint/ (or something equally descriptive).
I am opening a different issue for the other problem as per https://github.com/perl5-utils/List-MoreUtils/pull/9#issuecomment-100223044.
For anyone interested please refer to: https://github.com/perl5-utils/List-MoreUtils/issues/11

Well - @Tux uses sandbox and his kind of giving guidance is much more timtoady and encouraging than ignoring and forcing.

Looks fine to me.

I think this PR is a bit deprecated now. I processed L::MU as intended and left out weird tests.
Please feel free to optimize the recent head.


FEATURE: Player improvements

Is your feature request related to a problem? Please describe.

Player does not show remaining time
Player does not allow scrubbing to specific points in the song
Player does not allow completely stopping a song

Describe the solution you'd like

Add remaining time which updates in real time
Add a slider to scrub through the song
Add a button to stop the song

Describe alternatives you've considered

Screenshots

Some music player from Linux
Importance

[ ] High
[x] Medium
[ ] Low

This functionality is purely front end


HTTP with this options -> Thermostat with switch "ON" / "OFF" , get Temperature and set Temperature

Today i had time for playing with homebridge. Now it's running with http commands. What missing by http files is the thermostat with switch "ON" / "OFF" , get Temperature and set Temperature. Is here a User there have a http-file with this options? I looked the HomeMaticThermo.js, but i not understand this :(.
Thank for your help.

Hi,
the mapping of the homekit datatypes matter. Homekit knows heating, cooling, auto and off as an integer value 0..3. In my tests all these modes had to be defined for getting a working accesory.
Homematic knows Auto Mode, Manu Mode (Off in my settings) as boolean and control mode as integer. I mapped auto and heating to auto(homematic) and other homekit states to off (114-118). The homematic states kind of depend on each other.
So if you only want On / Off states you should map the homekit types to your Solution in an own shim. The Homematic.. Functions are designed for the structure of the homematic xml-api (calls, responses handled with substr). Not the professional way but working :)

My idea was to do this over IFTTT. The beauty would be, that there is a whole lot of thermostats already supported by IFTTT, plus you can optionally pass up to 3 variables i.e. temperature values.
The http would go to:
https://maker.ifttt.com/trigger/{event}/with/key/{secret}
event could be livingroom_set_temp
and pass a json:
{ "value1" : "something", "value2" : "goes", "value3" : "here" }
config.json could even contain the essential information like secret, and event

Sorry for the late answer. I have my own "http thermostat" created from the source "HomeMatic Thermo". Thanks for the help!
Greeting Patcher

do you mind publishing it?

@luc-ass: What for a Version of Homebridge have you installed?
-> Old = Without Plugins
-> New = With Plugins


gc_worker: Check need_gc before getting snapshot

Signed-off-by: MyonKeminta<EMAIL_ADDRESS>
What have you changed?
Previously need_gc is checked after getting snapshot and creating MvccReader. Getting snapshot  will wake up hibernating regions. If the region doesn't need to GC, then it's a waste to wake up all regions.
This PR gets the Region's range before getting snapshot, and access RocksDB directly to check MvccProperties whether the region can be skipped. So for most idle regions, we can determine that it can be skipped before getting snapshot.
What is the type of the changes?

Improvement (a change which is an improvement to an existing feature)

How is the PR tested?

[x] Unit test
[ ] Integration test
[x] Manual test (add detailed scripts or steps below)
[ ] No code

This PR's changes is contained in  Green GC test branch (#6138), The effect of this PR can be shown in the Green GC's  test results.

(Left: master; right: green-gc)
Each GC causes two peaks to heartbeat, where the first one is caused by ResolveLocks and the second one is caused by GC keys. The reduction of the second peak comes from this PR's changes.
Does this PR affect documentation (docs) or should it be mentioned in the release notes?
No
Does this PR affect tidb-ansible?
No

Because the key range of uninitialized region is ["", ""), it will overwrite the valid region info.
https://github.com/tikv/tikv/blob/29bf2ac8f72f737f17988889b2cbfb2eb5e1e010/src/raftstore/coprocessor/region_info_accessor.rs#L167-L182

Please be careful about cmd/src/server.rs. I was confused after refactorying...

@youjiali1995 @sticnarf PTAL again thanks!

@sticnarf PTAL again thanks

/merge


Remove basic_metrics dependency on CLEVA optional dependencies

Previously, basic_metrics imported cleva_harms_metrics, which imported the optional dependency jieba. This prevented the helm-run from working without crfm-helm[cleva] installed.

Just a comment, I know this is for Chinese but the ChineseTokenizer is actually very general and could maybe used in some basic tests. Why not rename it to something like SimpleTokenizer or some other name that illustrates that it does not do anything fancy just because it is chinese.

It's mainly to clarify that is it only used by Chinese - if we start using this for other languages, then we should rename it to CharacterTokenizer.


How to use it outside vue instance ?

i want to show notification with this plugin every error request in axios interceptor ?
Axios interceptors
axios.interceptors.response.use((response) => {
  return response
}, function (error) {
  console.log('Error Axios Hanlder', error.response)
  this.$notify({
    group: 'foo',
    title: 'Important message',
    text: 'Hello user! This is a notification!'
  })
  return Promise.reject(error)
})

Error
Uncaught (in promise) TypeError: __WEBPACK_IMPORTED_MODULE_2_vue__.default.$notify is not a function
    at eval (index.js?2848:10)
    at <anonymous>

There is the same question about vuex, look in FAQ labels

Hi, i have the same problem, did you manage to solve the issue ??

I know this is old and closed, but figured I'd add my 2 cents.  I had a similar case in which I passed "this" into the .js module and then assigned it to a variable called context then called context.$notify() and worked great.

Anyone managed to call it in axios response interceptor??

It worked for me:
On main.js
import axios from '@/utiles/axios'

Vue.prototype.$axios = axios
Vue.use(Notifications)

const vueInstace = new Vue({
  router,
  store,
  render: h => h(App),
}).$mount('#app')

axios.app = vueInstace

On axios.js
axios.interceptors.response.use(response => response, (error) => {
  if (error.response.status === 422) {
    axios.app.$notify({ type: 'error', text: 'Validation error text.' })
  }
  return Promise.reject(error)
})


fix(doc): problematic polling operation for lro delete

Currently in the offical guide, the same polling operation is shared by all lro operations, which could cause problems for some emitters since the lro metadata contains value which doesn't fit for lro delete. See https://github.com/Azure/autorest.csharp/issues/4827
This commit will create a separate polling operation which fits lro delete. The same definition is already available in https://github.com/Azure/typespec-azure/blob/955fc9534c2f7153d45c9fbe5743baa0c104d803/packages/samples/specs/data-plane/trait-versioning/main.tsp#L72-L77

No changes needing a change description found.


I want host a bot with the api but...

i cant install the drivers, some alternative?

the host is squarecloud

If you have a CMD or a terminal just enter "playwright install", if you cant then just contact the hosting service, it's not kramcat's fault, it's playwright


Issue with Appium Methods in Java Flutter Finder

I tried to use usual Appium methods like isEnabled() and isDisplayed() in my Flutter app automation project using Java and the Java Flutter Finder library. However, these methods are giving me a Java terminal error:
org.openqa.selenium.UnsupportedCommandException: {"value":{"error":"unknown method","message":"Method has not yet been implemented","stacktrace":"NotYetImplementedError: Method has not yet been implemented
It seems that these methods are not yet implemented in the Java Flutter Finder library. Could you please provide guidance on how to proceed or if there are any workarounds for this issue? Thank you.

I'll check


[RN] Images in mobile doesn't correspond with Admin

The same case in UIKit
The object 'Кафедральный собор Святого Архангела Михаила' in Admin has 0 images
In mobile app there're 1 image and 1 grey plug image

The issue isn't reproduced on production (RN).
Seems that this is due to migration of images from prod to dev. (broken image)
When I update images, the issue disappeared.


Implement std::error::Error for Error

So that the usage of bitcoinconsensus::Error is more ergonomic for downstream users implement std::error::Error.

On review before merging I realised this breaks no-std by adding a hard dependency on std, I'll look into adding a std feature like we do elsewhere in the stack?

Force push contain newly added feature gating. Please re-review.

I guess I need to figure out how to make submodules work, so that I can test this repo locally :/.
Or maybe we could just convert to subtrees .... but maybe I'm opening a can of worms there.


Add slash command integration

Might require different types of inputs that should be released by the time that Discord itself requires slash commands to be used for bots

Moved priority to high, as Discord requires the read message intent for the bot to work currently. Slash commands can handle all of the data that we have currently.
The implementation of the community bot should be similar to the one of the clientside bot.

on this


Date validation breaks, maybe because of ActiveAdmin datepicker

Using Ruby 2.3.1, Rails 4.2.6, ActiveValidators 4.0.0
I have a PressRelease model that has a datetime field, released_at. When using ActiveAdmin's datepicker, my date validation (that looks like this : )
class PressRelease < ActiveRecord::Base
  validates :released_at, presence: true, date: { before: lambda { Time.now }, after: lambda { 50.years.ago } }
end

breaks and throws an ArgumentError : wrong number of arguments (given 1, expected 0).
I also use the URL validation, no problem with this one.
Full trace :
trace.txt

This error comes from your before: and after: lambdas.
Using a lambda means that any the number of arguments you've specified is enforced with an exception.
The date validator passes an argument to these when it calls them, which is what's causing your error.
To fix the error, change your lambdas to procs to ignore the argument silently.

The documentation in the README would then be the issue here :
class Article
  validates :slug,            :slug => true
  validates :expiration_date, :date => {
                                          :after => lambda { Time.now },
                                          :before => lambda { Time.now + 1.year }
                                        }
end


Added Cloud Commander to real world uses

Cloud Commander uses xterm as an embedded terminal which can be additionally installed and enabled (with help of gritty).

Can be opened with Shift + ~ and closed with Shift + Esc.

Coverage remained the same at 67.971% when pulling 44cfb2dc87b02948e7e3d565796fd9ccc91b8739 on coderaiser:patch-1 into 045f361b0d4173085eac4bd957ef416e95f101d8 on sourcelair:master.

Thanks @coderaiser, looks cool :smiley:


Attached Video Viewer

Pull request checklist:

[ ] CHANGELOG.md was updated, if applicable

Description
I have been experimenting with including an internal / attached video player which would be docked alongside the chat. This would allow for a pretty seamless viewing and chatting experience if possible. I have gone and done a quick demo of what this could look like and it seems to only be a few modifications so far.
Originally I stumbled upon the StreamLinkerino project, but I want to make it a more first class feature. Here is an example screenshot of what I have so far:

What works:

Clicking the "three dots" menu option in the split opens a second window
This window will then stream via streamlink and the mpv player
Switching between tabs will change the stream to match

My current issues:

Non-hacky storage of variables / widget (where would I store these variables?)
How to "attach / dock" this second window to the chat so it resizes and min/maximized with the main window (how to handle the layout?)
Volume control (probably not very likely with how the stream is attached to the qt window)

Any suggestions or comments on directions would be most welcomed. Thanks again for the great project.
Edit: You can try out the preliminary builds here:
https://github.com/goldbattle/chatterino2/actions/runs/867344185

* Switching between tabs will change the stream to match

This sounds really bad for proxy and offline chatters, who chat in other channels while watching streams. Also what will it do if you have 2 or more channels in a tab. Which one will it open? The first one?

If the tab is a non-live stream, the stream will still be the last live stream a person clicks on.
Then if a user clicks on another live stream then it will switch.
I should make this a toggle in the settings to disable auto switch.
The original motivation was to clearly keep the video in sync with what chat you seeing.

I will re-open a new PR after I make some more changes and experiment a bit more.
Sorry for the notifications.

I created another non-draft PR here, sorry to those that got the extra ping in this one.
https://github.com/Chatterino/chatterino2/pull/2854


clarified of and anyone in Protocols API guide

To see the specific tasks where the Asana app for GitHub is being used, see below:

https://app.asana.com/0/0/1205533584577330

addresses #735


Specify build configuration for test target

I'm looking for a way to change the build configuration of the test target as by default it's going to be the Debug.
targets:
  Apple:
    type: framework
    platform: iOS
    sources:
      - Apple
    scheme:
      gatherCoverageData: true
      testTargets:
        - name: AppleTests
          parallelizable: true
          randomExecutionOrder: true

So this will generate an Apple scheme automatically but the config of the test target it's going to be Debug but I would like to have Test. I tried to override this scheme in a schemes section but it seems that I cannot name it in the same way.
Is there any way to change the build configuration or do I need to create a new scheme?

Literally just found the solution. I had to remove the scheme so it won't automatically generate it.
targets:
  Apple:
    type: framework
    platform: iOS
    sources:
      - Apple
schemes:
  Apple:
    build:
      targets:
        Apple: all
        AppleTests: [test]
    test:
      config: Test
      targets:
        - name: AppleTests

Literally just found the solution. I had to remove the scheme so it won't automatically generate it.
targets:
  Apple:
    type: framework
    platform: iOS
    sources:
      - Apple
schemes:
  Apple:
    build:
      targets:
        Apple: all
        AppleTests: [test]
    test:
      config: Test
      targets:
        - name: AppleTests


Refs #34118 -- Added Python 3.12 to classifiers and tox.ini, and doc'd Python 3.12 compatibility in Django 4.2.x.

buildbot, test on oracle.

Great 😃

Thanks y'all for reviews :rocket:


Tabnine has a high CPU usage. (after edit big-file)

please complete the following information:

OS version: 	win 10
Editor: 	intelij
Editor version:	2022.3.1
Programming language: 	java
TabNine extension version: 1.0.6
Engine version (could be located within Tabnine Hub):  4.4.276-48

Issue Details:
Hi!
I have a problem with TabNine having a high CPU usage.
It's never been like this before, but I've recently modified a single file that's about 100mb. After this, the problem is observed, is this behavior related to the tabnine model? Then I want to keep using the model after cleaning it. (Please tell me how!)
Anyway, the problem only happens when tabnine tries to recommend a word.
Thx :)

gz#22766(related to Zendesk ticket #22766)

@chhs2131
Our Local model indeed consumes a lot of CPU. Try using the Cloud model instead of the Local model. See here how to do that.


Allow multiple deletions using wildcard

This will allow multiple deletions on a single call to the del() method. So we can use
     cache.del('home.page.*')

instead of
     cache.del('home.page.0');
     cache.del('home.page.1');

The new method is still compatible with the old one.

Hey Amauri, thanks for the PR! I'll merge it right now. I'll write a test for it too. I'll probably modify it a bit so it does not query the keys command if there is no wildcard, something like:
var hasWildcard = redisKey.indexOf('*') >= 0;

if ( hasWildcard ) {
  // Your method with calling keys first
}
else {
 // The regular way - no wildcard
}

Like this we save memory if there is no wildcard. I'll let you know when I'll publish it to NPM, Thanks again!

OK I have published it to NPM under v0.1.7. Thanks for the PR!

Yes, I didn't think much on optimization because the del() method won't be called so often comparated to the get(), but you are right, we can save a query if we do like you said. :)


 component does not remove

Describe the bug
<mj-text> component does not remove <mj-raw> tags from it's parsing
To Reproduce
Steps to reproduce the behavior:

Using the MJML 'try it out live' tool on the mjml website.

Create a template using this code ( or visit https://mjml.io/try-it-live/BJ7ByVcJS )

<mjml>
  <mj-body>
    <mj-section>
      <mj-column>
        <mj-text>Hello <mj-raw>{{ world }}</mj-raw></mj-text>
      </mj-column>
    </mj-section>
  </mj-body>
</mjml>

Inspect the {{ world }} element and see that  still persists

Expected behavior
While I understand the functionality of <mj-text> is to deliver items that are put into in their raw format, I do not believe <mj-raw> should be outputted in any scenario.
This, in my opinion should be an inert component which is always stripped and preserves it's content
MJML environment:

Currently windows but no belief it will behave different on others
MJML Version 4.3.0
All

While I appreciate the reply in #1482 it doesn't really come across as an answer asks Why though?.
Sure it leaves it in there and that is currently the functionality of <mj-text> but this functionality doesn't feel to be correct.
Leaving <mj-raw> inside of the <mj-text> element seems to provide no benefit and just feels like a forgotten artifact that should just be removed as in all other cases
Providing my specific use-case may provide light on why:
Using the gulp-mjml project, I am 'auto-escaping' all my templating language elements with <mj-raw>
This means anything that looks like:
{{ = <mj-raw> {{
}} = }} </mj-raw>
{% = <mj-raw> {%
%} = %} </mj-raw>
While this is obviously specfic to me and my use-case I believe the point still stands.

Because mj-text node & other content node doesn't need to be parsed. The more we "clean" or parse the content the less flexible content tag becomes. Weird bugs appeared in the past where content had encoding issue, or output issue, those were fixed by just stopping to parse anything in content tag.

I am facing a similar situation and it looks like this is a feature not a bug :P . @rhyswfbowles : Can you please share your gulp file? Will save me some to write the whole thing myself.
To mjml team, perhaps add this to the documentation, that when mj-raw is inside text it will not be parsed.


Fix assets window crash

This fixes #167. The reason is that using the search bar changes the size of the underlying TreeViewItem list, resulting in an out-of-bounds access error if a high-index asset was selected before that. There's a check for that now, but for robustness, I also made it so that whenever the search bar is used, the selection is cleared.

Also, since I was in the ion Assets Window code anyways, I found a fix for #220 that I just pushed :blush:

Looks good, thanks!

I updated the changelog in main to mention the two issues fixed.


[Traefik Plugin Catalog] Plugin Analyzer has detected a problem.

The plugin was not imported into Traefik Plugin Catalog.
Cause:
failed to run the plugin with Yaegi: failed to eval `CreateConfig` function: 1:28: undefined: traefik_rpthandler

Traefik Plugin Analyzer will restart when you will close this issue.
If you believe there is a problem with the Analyzer or this issue is the result of a false positive, please contact us.

I changed the package name


Missing a couple of i915 modifiers

To be specific:
pub const DRM_FOURCC_I915_Yf_TILED: u64 =<PHONE_NUMBER>7927939;
pub const DRM_FOURCC_I915_Yf_TILED_CCS: u64 =<PHONE_NUMBER>7927941;

I tried regenerating the bindings locally but that didn't change anything. They are defined at https://github.com/torvalds/linux/blob/d615b5416f8a1afeb82d13b238f8152c572d59c0/include/uapi/drm/drm_fourcc.h#L497-L530

It looks like the regex for I915 modiefiers expects uppercase A-Z at:
https://github.com/danielzfranklin/drm-fourcc-rs/blob/7b9f80060ffd4b35cd236437e65a17fb517d163c/build.rs#L91
whereas these names contain a lowercase f. Should be trivial to adjust.

That works! Opened https://github.com/danielzfranklin/drm-fourcc-rs/pull/11


Issue with caret position when using suffix

Hi,
I have found issue when using react-format-number with suffix property.
If you select all the text in input (including suffix) and start typing we get unexpected behavior:

First key press (number) is visually ignored.
Field is not cleared, but caret appears after first character in the input field

I made little example in CodePen where you can test this behavior: https://codepen.io/anon/pen/XVLzyV

My bad. Thanks.


Fix container name issues on Azure

Codecov Report

Merging #105 into master will increase coverage by 0.01%.
The diff coverage is 93.33%.

@@            Coverage Diff             @@
##           master     #105      +/-   ##
==========================================
+ Coverage   91.39%   91.41%   +0.01%
==========================================
  Files          21       21
  Lines         837      850      +13
==========================================
+ Hits          765      777      +12
- Misses         72       73       +1

Impacted Files
Coverage Δ

opwen_email_server/services/auth.py
100% <100%> (ø)
:arrow_up:

opwen_email_server/actions.py
96.22% <100%> (ø)
:arrow_up:

opwen_email_server/services/storage.py
97.02% <75%> (-0.45%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 51865bd...02a53bd. Read the comment docs.


ENG-2185: home page redesign and quickstarts landing page

Description

home page redesign and quickstarts landing page

Testing required outside of automated testing?

[x] Not Applicable

Screenshots (if appropriate):

Rollback / Rollforward Procedure

[x] Roll Forward
[ ] Roll Back

Reviewer Checklist

[ ] Description of Change
[ ] Description of outside testing if applicable.
[ ] Description of Roll Forward / Backward Procedure
[ ] Documentation updated for Change

getting a weird issue where the icons aren't appearing on the quickstart home page. wondering if this is just a me problem or if others can reproduce this issue

:tada: This PR is included in version 1.4.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


DOCS: Docs not found on website.

The requested URL was not found on the server.
Maybe one could add a temporary static file for the same

was this a /docs route?

I'm probing it


It downloads some empty subtitles

Describe the bug
When you download certain series that have true closed captions like The Wrong Way to Use Healing Magic and Frieren: Beyond Journey's End, it downloads 2 en-US  (CC) which one is empty and the other contains subtitles.
To Reproduce
Steps / command to reproduce the behavior:
$ crunchy archive -a ja-JP -a en-US -s en-US -s fr-FR -m audio --include-chapters https://www.crunchyroll.com/series/GG5H5XQX4/frieren-beyond-journeys-end

You open a video player such as VLC and under Subtitle > Sub Track we see two en-US (CC) - [English]
To even make sure that one of those English CC is empty, use the ffprobe command you will get the metadata for the empty subtitle has a duration of 0.
...

Expected behavior
There shouldn't be two CC subtitles with one of them empty or both contains
Screenshots
If applicable, add screenshots to help explain your problem.
Showing VLC found two English streams for English dub

Crunchyroll has two English subtitles/Closed Captions for the dub version

Open the inspector and we see that it loaded a VTT file containing the closed captions.

Client (please complete the following information):

OS: EndevourOS (Arch Linux based)
Version 3.5.2 (74aaed 2024-04-24)

Additional context
I found that Crunchyroll started to add true Closed Captions in English to certain anime series such as Frieren, but the format is not in plain text nor ASS, but in VTT which we can see in the last screenshot. The issue it cause is when I need to seperate all the streams so that I can add a subtitle language that Crunchyroll doesn't provid, I can't merge them back together using ffmpeg, because the files are corrupted with a text or binary codec stream that ffmpeg doesn't support. And I can't get rid of that codec in the mp4 video even if I re-encode it.
I tested on other series like Goblin Slayer Season 1 I downloaded yesterday and there is no issue, but it doesn't have the VTT closed captions. This is why I think the issue I am having comes from that empty subtitle.
The solution may be to download it in the right codec format (VTT) or check the duration that returns 0 and ignore it.

The subtitles were already downloaded as A .ass and .vtt (hence the two CC subtitle streams). But FFmpeg had problems with the subtitles being in different formats, internally converted vtt to ass, but this didn't went well and removed all dialogs. It got fixed in v3.6.0

Thank you! It worked well.


Simplify immutable TrainingArgs fix using dataclasses.replace

Related: #676
Hello!
Pull Request overview

Use built-in fix for immutable dataclass rather than the workaround.

Details
dataclasses has a little known replace function, which creates a new object of the same type as the first argument, but replacing fields with the values from the kwargs.
So,
args_dict = args.to_dict()
args_dict["remove_unused_columns"] = False

new_args = TrainingArguments(
    **args_dict,
)

args = new_args

becomes equivalent to
args = replace(args, remove_unused_columns=False)

See also https://github.com/tomaarsen/SpanMarkerNER/pull/27 where I implement the same.
cc: @younesbelkada for implementing the original fix

Tom Aarsen

My favourite kind of PRs 😄

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


Storage instance can't be re-used after some errors

Have you read the FAQ and checked for duplicate open issues?
Yes
What version of Shaka Player are you using?
master
Can you reproduce the issue with our latest release version?
yes
Can you reproduce the issue with the latest code from master?
yes
Are you using the demo app or your own custom app?
demo
What browser and OS are you using?
N/A
What are the manifest and license server URIs?
N/A
What did you do?
It appears that there are paths through Storage.store() which never revert storeInProgress_ to false. If you try to store a live stream, it appears as though you'll never be able to use that Storage instance again. Same if manifest parsing fails. :-(

This flag may be obsoleted by #1432 (Support multiple concurrent store() operations on the same Storage instance) in which we would have to remove this flag.  It's not clear what else is needed other than removing the flag.


question: how to add right icons in vscode.treeItem ？

I want to know how to add the right icons in vscode.treeItem
This is the effect shown in the picture below

Would you mind giving me a vscode example or vscode API related Implementation Documentation Link

I have found how to add it by https://code.visualstudio.com/api/extension-guides/tree-view


Warning after opening modal once

Hi,
I'm following your tutorial about how to implement a custom transition between views and everything is working fine, but after I close the ModalView and then try to open it again, this message is shown on my console:
Warning: Attempt to present <InteractiveModal.ModalViewController: 0x7feffaf0c390>  on <InteractiveModal.ViewController: 0x7feffaf0a070> which is already presenting <InteractiveModal.ModalViewController: 0x7feffae0d4b0>
After that, the modal isn't being opened anymore.
Can you please tell me what I should do to solve that?
Thanks,
Renan.

@renanstig Thanks for providing detailed warning info regarding this issue. I'm not actively working on iOS tutorials at the moment. But if there's anyone seeing this that has any ideas, feel free to chime in!


Computation for perceptual speed Index

Parvez Ahammad (https://github.com/pahammad) and Karan Kumar (https://github.com/kakumar)

Just a few minor notes but generally looks good.
There are at least 2 different ways to calculate the perceptual SI that I'd like to experiment with:

Calculate ssim versus the end frame (what was implemented here)
Calculate SSIM for each frame relative to the next.  Sum up the total of all changes and use the aggregate change to any point as the visual completeness.

#2 has a few interesting benefits:
a) It is constantly increasing
b) The relative SSIM between any 2 frames can be stored and SI can be calculated between any two arbitrary points.


Renamed "mus" parameter to "cluster_centers"

Should I close this pull request and start fresh?

no need, you can just keep on doing your fix in this PR


fix: stub for Table.transformColumn

Summary of Changes
Allow the callback of Table.transformColumn to return null.

:tada: This PR is included in version 0.13.0 :tada:
The release is available on:

npm package (@latest dist-tag)
npm package (@latest dist-tag)
v0.13.0
GitHub release

Your semantic-release bot :package::rocket:


export image to disk?

local.ERROR: Call to undefined method FFMpeg\Media\Frame::export() {"exception":"[object] (Symfony\\Component\\Debug\\Exception\\FatalThrowableError(code: 0): Call to undefined method FFMpeg\\Media\\Frame::export() at D:\\wamp\\www\\Bankrolla\\app\\Jobs\\ConvertVideoForStreaming.php:62)
Im trying to save file to defined disk. for local development it stores in local, but for live it stores to s3
but it is not accepting the disk.
$media = FFMpeg::fromDisk('public')
            ->open($path)->frame(\FFMpeg\Coordinate\TimeCode::fromSeconds(11))
            ->export()->toDisk('public')
->save('786_thumbnail.jpg');

what can be the problem here?

Check out the README, there's documentation about exporting a frame.


enh: schema updates to improve checks

These schema updates are being used both to fix missing elements in the schema (like schemaKey) but also to handle asset metadata being discussed in this PR: https://github.com/dandi/dandi-cli/pull/644

@yarikoptic - Equipment is added as an entity that was used in a Session rather than as an Agent. This will get more complicated with self-driving equipment, but for the moment most equipment are passive and therefore have no agency.

@yarikoptic - this should be good to go for now. how do i create a release?

If all works, just add release and minor or major or patch label and click merge. I added labels, you click merge? ;-)

The question though - do we want to release or stage more changes into it?

do we want to release or stage more changes into it?

this will help use it in the API server. also this schema change will require schema version updates on both the UI and the API.
we will likely need to do a mini-migration for some dandiset metadata. actually, let me add a migrate function to this. probably will need refinement over time.

I wouldn't bother with migration ATM. We still should be able to reextract and upload (since they don't mutate ATM ;-))

realized that i wasn't paying attention to the dandi namespace, so had conflicts between roletypes and top level items (Software, EthicsApprovals). also changed Open to OpenAccess and added a dandiset metadata migration function.
for assets we would mint new metadata, but dandiset metadata also needs to be migrated alongside schema change on the server. so after this is merged, we do need to do the updates simultaneously.
wouldn't mind some eyes looking at the changes before we merge.

@yarikoptic - this should be ready now.

@jwodder, @yarikoptic  - i created a new access token for our bot user for this repo and set the secret with it.

lost in comments:  I did add release label awhile back, but then I thought I saw a comment from you @satra that we might not want to release just right away so I disabled releasing schemata with #11 in favor of @jwodder working out a proper release support according to #2 .  So -- what is your desire -- to have it released asap upon merge?

yes this releases schema 0.4.0 so should happen on release of this library. so merge -> release library -> release schema. the last two go hand in hand.

closes #14, #16


Unable to resource inject CamelContext

As evidenced in some of the examples, @Resource injection of Camel contexts is not working.
Likely that I broke this in https://github.com/wildfly-extras/wildfly-camel/commit/3a3d6413ae40d083d771fde9175948a5509f0a1b. If I revert this, everything seems to work fine.

Does not work:
@Resource(mappedName= "java:jboss/camel/context/foo")

Does not work:
@Resource(lookup= "java:jboss/camel/context/foo")

Does work:
@Resource(name= "java:jboss/camel/context/foo")

Which explains why the Spring archetype test case has managed to stay working:
https://github.com/wildfly-extras/wildfly-camel/blob/master/archetypes/archetype-spring/src/main/resources/archetype-resources/src/main/java/MyServlet.java#L37


Scale Drift optimization

I have tested the estimated trajectory compared to the ground-truth data using
[https://github.com/uzh-rpg/rpg_trajectory_evaluation] analysis tool before and after the modification of the code and I have noticed that the scale drift err has increased as described in the attached files

Thanks! Do you remember which commits you were comparing?

I have compared between "d00b5af6f7aabd85dcb2cbab0a908722b203da4f" and "aca75f72a0aa1f7af688b6c49f0d4ef2dc704d20"


Implementation of MongoDB hub

A module which will be executed in a different process (different OS thread), and which will be listening MQTT messages in order to prepare the data for our MongoDB persistence layer at our servers.

Implemented as a Python thread, checking reliability and performance.


noWrap doesnt do anything

I am having troubles cutting off the side images. Is there something I am doing wrong?
My Code:
this.map = L.map('mainMap').setView([0, 0], 1)
L.tileLayer('http://<IP_ADDRESS>:8081/{z}/{x}/{y}.png', {
   minZoom: 1,
   maxZoom: 3,
   noWrap: true
}).addTo(this.map)

Result:

Question on stackoverflow: https://stackoverflow.com/questions/45206085/nowwrap-not-working-in-leafletjs

Figured it out, sorry. NoWrap works, the background was not set.