Default color flag depends on stdout being a tty or not

@k4nar :)

Codecov Report

Merging #12 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master    #12   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          11     11
  Lines         475    477    +2
  Branches       87     88    +1
=====================================
+ Hits          475    477    +2

Impacted Files
Coverage Δ

raincoat/init.py
100% <100%> (ø)
:white_check_mark:

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 bc62d2c...d20ebff. Read the comment docs.


Fix some issues with observers

Added this to my sapper project today, and after configuring noticed some issues I hadn't before.
In essence, this now uses svelte's onupdate hook rather than this.observe to watch the configuration, which resolves those issues.
I've pre deleted package-lock.json ;) and preserved the yarn lockfile.
Enjoy!

Thanks again, published under 1.0.1


Issue with k8s.io/docs/reference/access-authn-authz/certificate-signing-requests/

Documentation says
"A CertificateSigningRequest (CSR) resource is used to request that a certificate be signed by a denoted signer".
and
"The CertificateSigningRequest resource type allows a client to ask for an X.509 certificate be issued..."
What is it now ?  "be signed" or "be issued" or do these words denote the same action ?

This is mostly a support request I think.
Issuing and signing a certificate are closely related concepts. We could improve the wording, which would help non-native speakers, folks who are new to this, and folks who are in a hurry - amongst others.
I don't see a case for prioritising that cleanup though.
/sig auth
/priority awaiting-more-evidence
/language en

Maybe if we link to https://en.wikipedia.org/wiki/Certificate_signing_request for context?

I agree with Tim that signing and issuing are closely linked and maybe we could word it better + link it to the Wiki link mentioned above.

/remove-lifecycle rotten

I think this change would be worth having in the docs.
/reopen

/remove-lifecycle rotten

/triage accepted


r Fails

Mac OS Catalina - 10.15.4
While I am able to run c and run the tests, if I run r, I get an error:
$ r configs/js.alltest.apprtc.config.json
fc: event not found: configs/js.alltest.apprtc.config.json

Since I can't run r, I'm assuming this is why Allure shows 0 tests run when running a.

Okay, this turned out to be an app name conflict.  I renamed r to rn and that fixed it.


add docs about cloud-controller-manager

@thockin @luxas @idvoretskyi @jaredbhatti

This change is

LGTM from content.

@wlan0 Since this PR needs a bunch of general grammar, usage, and formatting fixes, would you mind providing maintainers access to edit it? I can fix them pretty quickly and it would save us some back and forth.

@devin-donnelly done

Added two commits for grammar, wording, and usage. Didn't change any technical content.


openSUSE factory Python 2 failure in test_bsddb3.py

After bypassing https://github.com/Nuitka/Nuitka/issues/375, all openSUSE platforms are failing with this minor diff:
[ 3163s] Comparing output of 'test/test_bsddb3.py' using '/usr/bin/python2' with flags silent, remove_output, binary_python_path, recurse_none, original_file, cpython_cache ...
[ 3285s] --- /usr/bin/python2 (stderr)
[ 3285s] +++ nuitka (stderr)
[ 3285s]
[ 3285s] @@ -1,3 +1,3 @@
[ 3285s]
[ 3285s]  Berkeley DB 4.8.30: (December 20, 2018)
[ 3285s] -Test path prefix:  /tmp/z-test_bsddb3-10848
[ 3285s] +Test path prefix:  /tmp/z-test_bsddb3-11005
[ 3285s]
[ 3285s] Error, outputs differed.
[ 3285s] Error exit! 1

However the Intel platforms are failing with
[  573s] Running the CPython 2.7 tests with options '--debug' with python2.7:
[  573s] Run '/usr/bin/python2 ./tests/CPython27/run_all.py search' in '/home/abuild/rpmbuild/BUILD/Nuitka-<IP_ADDRESS>8975414.e336d005'.
[  573s] Using concrete python 2.7.16 on x86_64
[  573s] Comparing output of 'test/test_MimeWriter.py' using '/usr/bin/python2' with flags silent, remove_output, binary_python_path, recurse_none, original_file, cpython_cache ...
....
[ 1045s] Comparing output of 'test/test_bsddb3.py' using '/usr/bin/python2' with flags silent, remove_output, binary_python_path, recurse_none, original_file, cpython_cache ...
[ 1103s] --- /usr/bin/python2 (stderr)
[ 1103s] +++ nuitka (stderr)
[ 1103s]
[ 1103s] @@ -1,3 +1,27 @@
[ 1103s]
[ 1103s]  Berkeley DB 4.8.30: (December 20, 2018)
[ 1103s] -Test path prefix:  /tmp/z-test_bsddb3-9325
[ 1103s] +Test path prefix:  /tmp/z-test_bsddb3-9466
[ 1103s] +Exception in thread reader 1:
[ 1103s] +Traceback (most recent call last):
[ 1103s] +  File "/usr/lib64/python2.7/threading.py", line 801, in __bootstrap_inner
[ 1103s] +    self.run()
[ 1103s] +  File "/usr/lib64/python2.7/threading.py", line 754, in run
[ 1103s] +    self.__target(*self.__args, **self.__kwargs)
[ 1103s] +  File "/usr/lib64/python2.7/bsddb/test/test_thread.py", line 292, in readerThread
[ 1103s] +    rec = dbutils.DeadlockWrap(c.next, max_retries=10)
[ 1103s] +  File "/usr/lib64/python2.7/bsddb/dbutils.py", line 68, in DeadlockWrap
[ 1103s] +    return function(*_args, **_kwargs)
[ 1103s] +DBLockDeadlockError: (-30994, 'DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock')
[ 1103s]
[ 1103s] +Exception in thread reader 3:
[ 1103s] +Traceback (most recent call last):
[ 1103s] +  File "/usr/lib64/python2.7/threading.py", line 801, in __bootstrap_inner
[ 1103s] +    self.run()
[ 1103s] +  File "/usr/lib64/python2.7/threading.py", line 754, in run
[ 1103s] +    self.__target(*self.__args, **self.__kwargs)
[ 1103s] +  File "/usr/lib64/python2.7/bsddb/test/test_thread.py", line 292, in readerThread
[ 1103s] +    rec = dbutils.DeadlockWrap(c.next, max_retries=10)
[ 1103s] +  File "/usr/lib64/python2.7/bsddb/dbutils.py", line 68, in DeadlockWrap
[ 1103s] +    return function(*_args, **_kwargs)
[ 1103s] +DBLockDeadlockError: (-30994, 'DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock')
[ 1103s] +
[ 1103s] +
[ 1103s] Error, outputs differed.
[ 1103s] Error exit! 1

Config at
https://build.opensuse.org/package/show/home:jayvdb:py-bridge/python-Nuitka-factory

Let me remove this test case, it's not really using Nuitka at all and has a bunch of things that would have to be removed, leaving no actual code to be compiled.


Add audit-log-maxbackup setting for openshift-api-server

What this PR does / why we need it:
In order to meet CIS and PCI-DSS compliance, we need to have an audit-log-max backup set to 10 or any appropriate value, we should add this as a default so that no additional configuration is needed after the installation.
Which issue(s) this PR fixes *
Jira #https://issues.redhat.com/browse/OSD-15157
Checklist

[x] Subject and description added to both, commit and PR.
[ ] Relevant issues have been referenced.
[ ] This change includes docs.
[ ] This change includes unit tests.

/approve

thanks! @Vincent056 where can I learn more about "CIS and PCI-DSS compliance" requirements?
/lgtm

/retest-required

thanks! @Vincent056 where can I learn more about "CIS and PCI-DSS compliance" requirements? /lgtm

We have an older benchmark here: https://access.redhat.com/system/files/red_hat_openshift_4_hardening_guide_v1.1_2.pdf
The update to date benchmark can be found in: https://www.cisecurity.org/cis-benchmarks might require registration.


Bypass clipped strings and sliced stacktrace variables

Hi, most of the time I don't have to log long context data. But if a string is longer than 1024 chars, Raven serializes and displays a string with {clipped} at the end, as seen here: https://github.com/getsentry/sentry-php/blob/master/lib/Raven/Serializer.php#L96-L98
Now I do get why this is done. We probably don't want to push (uncontrolled) big amounts of data into Sentry. But in specific case it's quite useful to add a json serialized string to the context array to be able to debug my issue way faster if it ever happens.
Are there any options or workarounds in that case to avoid {clipped} strings? It would be nice to have the possibility in both the context array and in the stacktrace variables to show the full output. As seen in the screenshot below, we need to debug something but the requestBody isn't displayed entirely.

Context array shows {clipped} when strings are >1024 chars
Stacktrace variables show ... ellipsis if string is bigger than +- 512 chars. Sometimes vital debugging information is sliced away unfortunately

Ideally we'd have a good answer here, but its complicated. The problems are this:

All of this data is arbitrary (we dont know whats important)
We have to put limits on the size of data because its expensive to process, store, and render
It'd be very complex to have a way to describe which attributes are higher priority

I'm totally open to ideas, but its just super complex in general.

Yeah totally agree. It would make things way too complex to distinguish data that should be fully logged or not, and people could abuse it. I'll close this issue.

Hello, not sure but I guess it would be working properly if the default serializer would be create "correct".  As far as I can see the Raven_Serializer can take two arguments and in the Raven_Client constructor only one is used (https://github.com/getsentry/sentry-php/blob/master/lib/Raven/Client.php#L211). I guess that $this->serializer = new Raven_Serializer($this->mb_detect_order, $this->message_limit); would actually fix the issue.
A simple workaround could be something like this.
$options = ['message_limit' => 0];
$client = new Raven_Client($options);
$clientSerializer = new Raven_Serializer($client->mb_detect_order, $client->message_limit);
$client->setSerializer($clientSerializer);


zsh processes under tmux accumulate, eating CPU

Your Windows build number: (Type ver at a Windows Command Prompt)
Microsoft Windows [Version 10.0.17763.379]

What you're doing and what's happening:
I have zsh as my default shell and I use WSL for web development. I have a shell script to run a tmux session with 5 window panes to set up my web dev environment. I close everything on WSL once I'm done with my web development project for the day. I noticed sometimes my computer lags for some reason then I found out a lot of zsh processes were still running on Window Task Manager even though WSL is closed.

What's wrong / what should be happening instead:
All processes running on WSL should be terminated as soon as I close WSL.

This is likely due to daemon support. We do not terminate instances until the last daemon process goes away.  If you'd like to forcibly terminate your distribution, you can use wslconfig.exe /t .

I've been monitoring the processes on task manager. It seems that there's a new process of zsh that's created for every commands I run on a tmux pane. Sometimes I see 10+ processes of zsh running and it eats the CPU.  Is this normal?

There were two asks in this issue which caused it to go dark. First was terminating the tmux service on the last exit, the behavior of which changed in 17046. That much by-design. The other was "I noticed sometimes my computer lags" which might be a lot like #3503 (or might not). #3503 for its part petered into a discussion thread, and never got closed with any kind of concrete by-design explanation.
Fixing up the title just so there is a landing zone for dupes. I suspect that can't prove that the reason these processes accumulate is going to be arcane, undesirable, but correct. It would take a dive from someone to figure out what exactly is going on here. One thing worth investigating would be why it is eating CPU (as opposed to just RAM). Even if the processes accumulate, they either (a) shouldn't spin or (b) are spinning for a good reason under WSL's model that isn't explained. I can't say which.

I am doing web development using Django (python webserver) and React (using webpack-dev-server). Not sure if this will be helpful for the investigation.

Opposite maybe, because you just added variables to an issue where the OP doesn't even have repro steps. In your previous post, you said: "sometimes I see 10+ processes of zsh running and it eats the CPU". Suspicious pronoun. Do you have 10 zsh processes pegged at (say) 8% each in Process Explorer. Or did you mean I have 10 zsh processes, and also it (my CPU) is pegged at 100% for unknown reasons. Because now I gotta ask.

@xTEddie
"All processes running on WSL should be terminated as soon as I close WSL." This is NOT correct.
Just like @therealkenc said, after 17046, WSL allow background process (e.g. ssh-server, tmux, etc)
So if you just close the windows, these process will not close by design.

Can folks experiencing the "I noticed sometimes my computer lags for some reason" part of the OP give Insider 18362 (or better) a try to see if the problem is variation #3940 aka #3741. Maybe we'll get lucky.

Same issue here. I fired up a few panes in tmux and without doing anything my CPU is being hammered. There is nothing running in the panes.

I have a similar issue when using WSL with the Ubuntu 18.04 LTS distro, zsh, and the new windows terminal. When closing out of shell instances, the zsh process persists and starts spinning up. After using the new windows terminal for a little while (opening and closing new terminal tabs), I have to manually go kill all these zsh processes.

Same as @nicholasRenninger on my WSL with Ubuntu 18.04, 100% CPU with zsh, have to killed them with process manager.
It seems that Zsh is not killed when I close my terminal.

Hello,
It seems I experienced a similar issue with bash (unkillable bash and init process eating CPU until hard reset). I solved it enabling windows 10 virtual machine platform (tutorial) as advised in this post.
It seems to work like a charm now.
Cheers,
D

Hi,
Just had this issue. Multiple processes open, two running at 16% CPU each.
Running WSL Ubuntu (18.04.4), with Zsh within tmux sessions.
Windows 10, build version: 18363.959


Memory layout printout is not right

This is what I get on Linux x86_64 on svt, hvt, and virtio (any of the test unikernels). Tried gcc 5 and 7 on an Ubuntu xenial.
            |      ___|
  __|  _ \  |  _ \ __ \
\__ \ (   | | (   |  ) |
____/\___/ _|\___/____/
Solo5: Memory map: %lu MB addressable:
Solo5:   reserved @ (0x0 - 0x%lx)
Solo5:       text @ (0x%lx - 0x%lx)
Solo5:     rodata @ (0x%lx - 0x%lx)
Solo5:       data @ (0x%lx - 0x%lx)
Solo5:       heap >= 0x%lx < stack < 0x%lx

After reading a bit of bindings/ee_printf.c, it seems that our printf library doesn't support the %ll modifier (so no %llu nor %llx). @adamsteen: is this happening on openbsd as well?

@mato @ricarkol
Sorry about this, I get the same problem.  #318 fixes this for OpenBSD as well.


Owner as a team and a user

Currently there is ability to add to entity owner as a team OR as a user.
Many times, there is owner as a team, but inside the team there is specific user the is responsible for the entity.
So a good solution will be to enable both options on the same entity (and probably in this case, the user can be selected only from the team members).

Apparently such functionality exists:

But currently it works incorrectly. It doesn't display user who is a team owner. I don't understand how it defines a person for a team.

It happens only when you are part of to a team, and then you see yourself as the owner of your assets.
But each user see only it's connected assets on it's OMD view...


Error message when private constant is referenced

The error message when referencing a private constant should be more specific, currently it only reports the constant as undefined which is not correct. The constant is defined, it's just not visible.
private class Foo::Bar
end

Foo::Bar # Error: undefined constant Foo::Bar

Crystal::Path#raise_undefined_constant has a branch for error message "private constant #{private_const} referenced" message, but it seems it doesn't apply here.

Just adding to this, since I just ran in to it; it only happens if the class is namespaced.
private class Foo
end

Foo # this is fine even though it's private

Top level private types are visible inside the file they're defined in.

As mentioned in #13511, the constant is defined in the wrong namespace, so Foo::Bar is truly undefined


feat(metrics): update prompt of context precision

Update prompt of context precision as disscussed in https://github.com/explodinggradients/ragas/issues/365
Here are the results of a test set consisting of 97 medical related Q&A questions (Use GPT4 as evaluator)
context_precision_test.xlsx

human_eval: evaluated by human
ragas_before: evaluated by ragas with only question and context
ragas_update: evaluated by rags with question, gt and context

Subtract the rating scores from the human_eval using ragas_before and ragas_update respectively and get absolute value

mean
std
number of zeros

update - human
0.0676
0.1687
74

before - human
0.1796
0.2884
7

others

The use of<></> is because if the context/answer has multiple fragments, it will cause gpt4 to be unable to effectively determine the text range, reducing accuracy
Although the prompt looks much longer now, it actually only uses 750 tokens (measured by tiktoken), which is acceptable for most LLMs. However, the running time is indeed longer than before
The prompt only tested in the medical related question with gpt4. It might overfit the situation. Maybe we can add a reflection agent like the envolver or filter in the test_generator to generalize different scenarios

@shahules786 I found you have already create a PR https://github.com/explodinggradients/ragas/pull/391 . Sorry for not handling this matter for too long. Please have a look to see if 2 PRs can merge into one

Thank you @yuukidach.  No worries, I'll take a look and see how can we merge both.

First of all, thanks a lot for the great work you have put in. I should have left a note before taking up the issue myself. Apologies.
Overall both of us have solved the problem in a very similar fashion. Some of the differences I can see are that

In #391 I accept either answer/ground_truths. My thought was that for any sample with question and context, it is very easy to generate an answer and evaluate it. Most users will at least have these 3 attributed. Although usage of the answer will be depreciated in context_precision and can be used with the context_utilization metric
Changes in tests and Evaluation mode to handle exception situations

I couldn't think of a way to merge both. Do you have any ideas? Would you be open to pushing your documentation to #391 ?

Also, can we modify context_relevancy in similar way to improve performance? Ie it should use (question, context, answer) triplets to find out how much information (number of sentences/tokens/etc) from given context is used arrive at the answer. This can help users to optimise their chunk size. @yuukidach

Sure @yuukidach .  Regarding prompts, we are refactoring and introducing a new idea of prompt object #388 . Prompts being non-trivial parts of software deserve to be more than just strings.  My view of prompts is to write simple and generalizable instructions that are then followed up with good demonstrations rather than overfitting instructions to a particular model.
Up next, we will also introduce automated prompt language adaptation to allow users to adapt ragas prompts to any target language.   I'll read the paper you shared, thank you.


fix: expired tg link

Someone in the organization created a new invite link to the "TOL: preparazione test" Telegram group, I guess for bot-related purposes, hopefully without time limits...

I think the preview deployment is failing because you need to restore the tokens @toto04 @lorenzocorallo

I think the preview deployment is failing because you need to restore the tokens @toto04 @lorenzocorallo

Updated in this repo. Let me know if there are any others related to TOL that need to be updated too.

@EndBug @lorenzocorallo Although constants.ts has been updated, the about page is okay in dev. only

@EndBug @lorenzocorallo Although constants.ts has been updated, the about page is okay in dev. only

That's expected because prod website (online at tol.polinetwork.org) gets updated only on a new version release

Can anyone @PoliNetworkOrg/tol-admins deploy? I don't have my laptop with me
The steps are:

npm version patch
commit
create the corresponding release on GitHub

Then everything should be automated
Do a quick check because I don't remember if the database gets updated automatically


sync up env setup scripts with latest mizar

[ ] sync up with the latest Mizar runtime (golang)

@jshaofuturewei do we have additional task to do for this? if not, we could move this to CLOSED

@jshaofuturewei do we have additional task to do for this? if not, we could move this to CLOSED

@pdgetrf We don't have other tasks for it now. Please move it to CLOSED. I have not seen any changes from the Mizar team to update python3.7 to python3.9 yet. But it does matter.

@jshaofuturewei do we have additional task to do for this? if not, we could move this to CLOSED

@pdgetrf We don't have other tasks for it now. Please move it to CLOSED. I have not seen any changes from the Mizar team to update python3.7 to python3.9 yet. But it does not matter since the python versions are expected to be consistent.

sounds good!


Text is cutoff in TagSet overflow list

What package(s) are you using?

[x] Carbon for IBM Products (or Carbon for IBM Cloud & Cognitive)
[ ] Legacy/CDAI
[ ] Legacy/Security

Detailed description

Describe in detail the issue you're having.

When using letters like 'p', the line heights cuts off

Is this issue related to a specific component?

<TagSet />

What browser are you working in?

Google chrome

During team scrum today, we investigated and found that there’s border radius from the Carbon tag that is the cause and not line height.


Option to choose input mode

In the first 3 input fields (didLastExpedient, difficulties, doingToday), it's common to write the activities based or on the projects we're working or on the type of activities we made or even based on a mix of both.
For instance:

Generic mode (as it is now):

What I did last workday?
text
Difficulties?
text
What do I plan do today?
text
How am I?
text

Based on projects:

What I did last workday?

projectName1
text
projectName2
text

and so on

Based on type of activities (less common):

What I did last workday?

typeOfActivity (like 'meetings')
text

and so on

Based on projects and type of activities:

What I did last workday?

projectName1
text
typeOfActivity (like 'Meetings')
text

and so on

I wonder if more flexibility into this form idea, would give a better UX.
Maybe adding some kind of option (with toggle button, e.g.) to the side bar (as there is for toggle the theme), leting the user choose if want to write on a generic mode or based on a generic grouping mode.
And when the toggle would be checked by the user, the form schema would be like the item 4 on the list above.
TL;DR:
What if there is a toggle button to subdivide the first 3 input fields?
What do you think about?

Looks good to me! :+1:

What a wonderful suggestion @igorasantos, I really appreciated it! Looking forward to implement this feature as soon as I can. Thank you! :smile:

I'm glad you liked! :smiley:

After 1001 years, I finally finished it :smile:

Before late than never!


Asynchronous call

It will be better to have the choice between asynchronous and synchronous call on the Api :)

1.2 alpha version avaible on NuGet (Pre version).
Please read the 1.2 wiki page : https://github.com/Vtek/PowerBI.Api.Client/wiki/Version-1.2-alpha
A++
Sylvain


[RFE]  Tool for scheduled/conditional profiles

Request description:
Most memory related issues could benefit from having a relevant heap profile provided for them. Unfortunately it is not always easy to take a profile when it could provide valuable information. This may be because memory spikes are unpredictable. This may be because multiple profiles are needed.
Actual behavior:
None.
Expected behavior:
There should be a tool for scheduling these profiles. A bonus would be to added a conditional for only taking the profile when memory reaches a certain threshold. This tool could be a script for setting up a linux cronjob, a chart for deploying a k8s cronjob, or anything else that gets the job done.
Workaround:
Is workararound available and implemented? sort of
What is the workaround: Ask support or customer to take profile. We only get it for one point in time and sometimes it cannot be taken at a time where the data is relevant.

SURE-6228

The original scope of this ticket was to add tooling inside of Rancher itself, but at the moment the plan is to work on improving external tooling, documentation, procedures and guidelines instead - also to keep them applicable to various other products and components, not just Rancher.
I am thus closing this issue for the time being.


rewrite of redux saga

After attempting to rewrite most of the code several times so that it is comprehensible to mere mortals (such as yours truly) I have given up the effort. Mind you not because the concept of redux saga is complicated (it isn't ) but instead because of the time it will take to unwind all the gordian (knotlike)  modularization and cross references it performs internally.
My motivation for this rewrite is because I am trying to make code that i wrote maintainable by other mere mortals and redux saga is the weakest (or most convoluted) link.
The problem is that once you start using redux and redux saga it is all but impossible to remove from one's code base.  This had non trivial consequences when combined with the new version of react router and redux forms.
I have successfully removed redux forms and have rewritten router completely to make it simpler to use, maintain and follow.  (except for the regex matching code which is imported by router anyway) but i do not have time to do the same for saga without some help.
So my question is the following... has there been a rewrite scheduled for this code base?
And if so who is leading it so that I can offer to help?

Could you rephrase your question? Are you saying the redux-saga's internal code is convoluted & hard to follow and you'd like it to be simpler?

Redux-saga itself is somewhat complicated so the code is convoluted too. Things get more complicated that we do not use modern JavaScript (e.g. createTaskIterator) to make redux-saga run in old browsers.
I've write little-saga that simplifies redux-saga a lot, you can read the source code of little-saga and it should be much easier to understand. Hope this will help you understand the saga internals. There are some differences between little-saga and redux-saga, and I list them in the doc (but sadly, all the documentation is in Chinese 😂).

I am trying to be as polite and supportive as possible. I have no idea what
the acceptance rate, bug count or internal reputation of redux saga is at
FB but i have been using it for nearly two years and  it is clear to me
that it, combined with redux implicitly creates a message pump within
javascript.  Anyone who wrote mfc or simple windows c/c++ code has horror
stories about message pumping and trying to debug arcane anomalies. This
puts the burden of clarity on both the end user code and the code that
mandates message pumping.
Here is an example of the problem a reasonably adept programmer could
rewrite most of the 30 or so module of saga into several less modularized
ones that are easier to follow and will be easier to extend.  My guess is
that a good programmer could reduce this 1500 line package to 500 or so
lines of clearly written code that could be understood by simply reading
the code without requiring referencing of external packages or a table of
contents/index to figure out whether obscure terms are functions or
literals or some combination of the two are broken out into separate
modules that require back and forth switching to follow the code.
For example fork and take and takeevery and all the permutations use
literals that look like functions (IO etc) that are created using other
functions (instead of simply hardcoding '@@redux-saga/IO' .  While in
theory such separation is useful in practice, given that the ONLY code that
uses these symbols is redux saga code this is abstraction run amok.
Another good example is the separation of proc.js with runSaga and its
default reference in index.js.  proc is only used with runsaga. Why are
they separated?  why not reduce the total code base by combining these
obviously interdependent modules into one that removes most of the
complexity of formatting and error checking and then calling in to proc
which then performs many of the same tests before calling individual
methods.
This is abstraction and complexity for no useful reason.
Here is another exampe. takevery takelatest etc. all reference the same
modules to build their code. So what is the point of putting each of these
is separate modules. All it does is make the code more complex.  The end
result is that the same modules are imported into ones code base no matter
which options are chosen so why not just consolidate these into a well
formed module with multiple exports?
Here is another one. Abstracting fsmiterator from makeiterator is nothing
short of infuriating. fsmiterator is unnecessary code or is it the
package.json that references another code base that is unnecessary?  or
both?  And wtf is a package.json ' Prepared monorepo structure' ?
Whatever it is it reeks of pompous insecurity.
This is not software. it is a contest by sophomoric imbeciles  to see who
is cleverererer!
On Sat, Aug 18, 2018 at 4:41 PM Mateusz Burzyński<EMAIL_ADDRESS>wrote:

Could you rephrase your question? Are you saying the redux-saga's internal
code is convoluted & hard to follow and you'd like it to be simpler?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/redux-saga/redux-saga/issues/1561#issuecomment-414092895,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AI7J7SHcgaQeSQ0OrukpekiPBnE5R4W1ks5uSKYNgaJpZM4WCwPo
.

It is not that redux saga is hard to understand...
Redux saga is a glorified message pump disguised as generator programming.
The problem is that message pumping is really hard to get right. And
removing it requires a deep understanding of both the message pump software
and the end user software that depends upon it.
The solution therefore is to make the message pump as simple as possible to
use (and remove) from a project. In its present form redux saga does
neither.
One reason why linux is so popular is that it is more reliable and easier
to maintain(than mach or gnu)  because linux is not based upon a message
handling micro kernel.   In theory micro kernels are better but in practice
they have to be implemented by mortals which makes them the communists of
operating systems.
On Sat, Aug 18, 2018 at 11:28 PM shinima<EMAIL_ADDRESS>wrote:

Redux-saga itself is somewhat complicated so the code is convoluted too.
Things get more complicated that we do not use modern JavaScript (e.g.
createTaskIterator
https://github.com/redux-saga/redux-saga/blob/29fbd1b50d7128d3b9e4ff4105ae3b84ed2a2905/packages/core/src/internal/proc.js#L114-L149)
to make redux-saga run in old browsers.
I've write little-saga https://github.com/little-saga/little-saga that
simplifies redux-saga a lot, you can read the source code of little-saga
and it should be much easier to understand. Hope this will help you
understand the saga internals. There are some differences between
little-saga and redux-saga, and I list them in the doc (but sadly, all the
documentation is in Chinese 😂).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/redux-saga/redux-saga/issues/1561#issuecomment-414106828,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AI7J7U2tWyoYgJhoQieMj6a7AdhGJtsBks5uSQWLgaJpZM4WCwPo
.

I have no idea what the acceptance rate, bug count or internal reputation of redux saga is at FB

Not sure why do u mention FB here - this is not FB project, I personally don't know if it's even used anywhere in the FB apps.

combined with redux implicitly creates a message pump within javascript.

Right, but also - javascript itself is a message pump based (referring to the event loop). Also this message pump is imho quite explicit, this is the whole point of redux - to centralize message receiving point (to a reasonable extent) & make order of actions predictable.

Here is an example of the problem a reasonably adept programmer could rewrite most of the 30 or so module of saga into several less modularized ones that are easier to follow and will be easier to extend.

I actually believe this is not a valid accusation, because the whole complex logic is actually located in a single file (proc.js), other files are far easier to understand and you shouldn't need to jump through the codebase that much to understand how the whole thing works, because as mentioned the only thing that needs better understanding is proc.js.

Another good example is the separation of proc.js with runSaga and its default reference in index.js.  proc is only used with runsaga. Why are they separated?

Because actually proc is also used by proc. So the separation here is IMHO completely valid.

why not reduce the total code base by combining these obviously interdependent modules into one that removes most of the complexity of formatting and error checking and then calling in to proc which then performs many of the same tests before calling individual methods.

If you feel they those files are duplicating some efforts, please point me to exact lines - I'd love to improve the lib by removing unnecessary code.

Here is another exampe. takevery takelatest etc. all reference the same modules to build their code. So what is the point of putting each of these is separate modules. All it does is make the code more complex.  The end result is that the same modules are imported into ones code base no matter which options are chosen so why not just consolidate these into a well formed module with multiple exports?

I guess this is a matter of personal tase, but imho having separate files for those makes perfect sense as they are independent from each other and their source code is often easier to read without the surrounding code.

Here is another one. Abstracting fsmiterator from makeiterator is nothing
short of infuriating.

They both are different things, while I agree that maybe their names could be improved the abstraction here makes sense, because we need fsmIterator and if we would have only this one then code calling makeIterator would actually be more convoluted than it is now.

My apologies about the FB comment I just assumed that using the term Redux was copyrighted .
As I said I am willing to rewrite the entire repo with a bit of support from anyone.
For example I have distilled my usage 4 key functions of the repo down to these 4  1 or two line module implementation but for some reason I am not able to cause them to behave as saga does.  If it is a small problem I will submit these as substitutions (with appropriate abstractions) as possible simplification and performance optimizations
Note that i have written them out here in wide form to illuminate what the code is doing.
If anyone can figure out why these do not work (which was the original reason for my post) I would be very appreciative.
(Also to hopefully demonstrate that modularization and abstraction are sometimes overkill. Or be illuminated about what i am missing   )
export const fork       =   (fn, ...args    ) =>(          not yet working                     { ['@@redux-saga/IO'] : true , type : 'FORK'      , payload : getFnCallDesc('fork', fn, args)        } )
export const call       =   (fn, ...args    ) =>(                                              { ['@@redux-saga/IO'] : true , type : 'CALL'      , payload : getFnCallDesc('call', fn, args)        } )
export const put        =   (channel, action) =>(  action === null || action === undefined  ?  { ['@@redux-saga/IO'] : true , type : 'PUT'       , payload : { channel : null    , action : channel } }
                                                                                :  { ['@@redux-saga/IO'] : true , type : 'PUT'       , payload : { channel : channel , action : action  } } )
export const cancelled  = (   ) =>  (                                                          { ['@@redux-saga/IO'] : true , type : 'CANCELLED' , payload : {   } } )

For example I have distilled my usage of a few key functions down to these one ( or two) line module implementations but for some reason I am not able to cause them to behave as saga does. If it is a small problem I will submit these as substitutions (with appropriate abstractions) as possible simplification and performance optimizations

If you need any help with that please reach out to me. I'm happy to help.
The only "convoluted" part of the codebase you have directly mentioned are effect creators - which I don't really agree on. It's super thin abstraction and in the long run makes a code easier to read (at least for me) because you don't have to focus your eyes on repeated returned nested objects - which would span across multiple lines & would cause extra indentation being added. This part of the code is also super stable (because it's so easy) and we just don't have to come back to it very often.
You are mentioning also this:

If anyone can figure out why these do not work (which was the original reason for my post) I would be very appreciative.

But I'm not sure what do you refer to, could you be more precise?

Thanks for the offer of help.
I just want to confirm that my understanding of these functions is correct in that
1 - they ultimately produce a set of messages in the format:
{
'@@redux-saga/IO'  : true
, type :  'FORK'  //  || 'PUT' || 'CALL' ...
, payload : {  channel  : xxx  , action : xxx } // or whatever is returned from getFnCallDesc
}
In other words that  there is no other layer such as passing the message as a function /closure or as an object reference?
Perhaps in the design documents there is a listing of what outputs each of these function calls should produce?
(as an aside i removed the brackets from the  ['@@redux-saga/IO']  because they were unnecessary.(I believe that either way should work with the new syntax but i am not 100% certain.
if I understand these calls and others they should be able to be translated directly in to message literals without all the extra code and abstraction.  Perhaps there is a good reason to abstract the rest of the code base but it seems to me that put, get, takeevery, takelatest, cancel and fork    combined with a simplified  createMiddleware could be its own really simple stand alone repo?
If so i am at your disposal to assist

yes createMiddleware is indeed complex... i was hoping to bite off bits at a time and see if i could make a meaningful subset that mere mortals (such as myself) can follow.
The reason why a separate repo makes sense is that the scope of saga is very broad (or at least broader than my imaginings) and substetting it might reduce the overall complexity by splitting it into two stand alone repos.
My goal is to reduce the difficulty factor in  debugging    redux message stack issues.   This problem is several-fold.
1 - many many messages to trap
2 - the interrupt stack in browsers rarely have user code when these problems occur (they end up mostly in react or redux code   modules)
3 - saga is inherently complex due to the problem it solves
4 - It is hard to figure out what happens betweeen redux, react-readux, react router and redux-saga if you are not intimately familiar with all four.
5 - saga is not even the hardest of these modules to debug... connect in redux  is really, really hard to follow.
I have written many types of software, from control systems,  protocols and compilers to end user full stack apps and when something reaches a level of complexity that it cannot be easily debugged with the available tools it is a warning sign that future maintenance and upgrades will be very hard.
Therefore I am volunteering to (with the help of you and others ) to rewrite a subset so that saga is not the most complex link in the chain.

Have you seen our babel plugin that works with v1-beta? It helps significantly with showing the user code that actually triggered an error.
no I have not... this will help a great deal. I will try it immediately.
re Plan.
I will work on one.
What i propose to do is to attempt to consolidate all of saga into a single very large file and then subset it into the sections that (in theory) would make a useful subset.   I have attempted this several times before by replacing references with either duplicates of the actual functions or memoized literals where possible.  (It is my process for learning how some repos work)
Once i have this  completed I will share it as a working detailed spec to evaluate.
I realize this is not so much of a plan as a bottoms up decon/reconstruction but it really a great mechanism to ensure  we are all on the same page so to speak.
(It is also kind of fun like putting together a giant puzzle!)

This might be one of the most intriguing javascript statements i have ever seen.
I understand that you are destructuring an  array with [context,fn]  = fn
but what does the ; do ?  I have tried it without it an no luck
function getFnCallDesc(meth, fn, args) {  let context = null

             if (is.array(fn)) {      ; [context, fn]    = fn  } // what does this   do
        else if (fn.fn) {             ;({context, fn }   = fn) }
             if (context && is.string(fn) && is.func(context[fn]))   fn = context[fn]
                return { context, fn, args }
}

it doesnt do anything, in this case. It being there Is partially caused by ASI (Automatic Semicolon Insertion). prettier has put it in the code - preventing bugs caused by ASI. Technically it could check previous line to see if this semicolon is needed, but prettier takes a shortcut and always inserts a semicolon at the beginning of possibly vulnerable line. This happens because we are using --no-semi option.
What it prevents? Smth like this:
fn()
[a, b] = c

so it wont try to access returned value from fn call, but rather destructure the c variable

Thank you for precisely highlighting what is confusing.
fn()
[a,b]=c

should destructure the c variable  but it doesn't.  I am confounded why there is an implicit access to the returned value from fn() on the next line?
is it that
"
fn()[a,b]
"
could be interpreted as accessing a possible xxx [a,b] = c  which might do something?  (assuming the return value of fn() is xxx) ?
But any function () with no valid {}   or =>  on the next line should automatically be treated as a stand alone call with the  new line as the  ; equivalent?

Well this exact example is kinda useless, as it will only result in throwing a ReferenceError if you try to run it ("Invalid left-hand side in assignment"), but it's a runtime error and not a parsing error.
Even though I've done some work around babel and I know my fair share about the JS I can't really answer your question in full - reading the language spec is really hard 😉
In general from what I know the code parsing doesn't like to hold too much state (most approaches can only peek at next token), I guess it's mostly because of perf reasons. EDIT:// after thinking about it a little it's probably not rly keeping track of state, but rather about the fact that we shouldn't "revisit" created nodes, parsing is always left to right (without possibility to correct created nodes), so it's not possible (possibly for perf reasons) to i.e. change a node back when the parser could make a conclusion that it would make more sense for it to be something different considering gained knowledge from next tokens/nodes
So coming back to ASI - when the parser gets to fn() and peeks at next symbol which is [ it has to assume what kind of AST node it might produce in this context, having only es5 (no destructuring) in mind and knowing that JS is always backwards compatible it has to assume that this is property access and thus producing MemberExpression (using babel type).
Not sure if this answers your question completely, I'm kinda tired and maybe this was a bit chaotic. If you still have questions about it, please be more precise and tell me which parts of this are confusing so I can help you understand this better. Cheers!

It has been a few years since i have written a lookahead compiler but your answer makes sense.
(And for others that might run into the same issue somewhere else )  the bottom line is that destructuring as a capability of es6 exposes unobvious behavior from js by treating   statement newline  [  ...
f()
[  // other array stuff

as one statement instead of two.
On a related note  I have been trying to rewrite some of your code so that my feeble brain can understand it  more easily and i have come across another interesting syntax usage.
This is your code for throttle... (i will show my changes that are similar for throttle below )
function throttle(delayLength, pattern, worker, ...args) {
  let action, channel

  const yActionChannel = { done: false, value: actionChannel(pattern, buffers.sliding(1)) }
  const yTake = () => ({ done: false, value: take(channel) })
  const yFork = ac => ({ done: false, value: fork(worker, ...args, ac) })
  const yDelay = { done: false, value: delay(delayLength) }

  const setAction = ac => (action = ac)
  const setChannel = ch => (channel = ch)

  return fsmIterator(
    {
      q1() {
        return { nextState: 'q2', effect: yActionChannel, stateUpdater: setChannel }
      },
      q2() {
        return { nextState: 'q3', effect: yTake(), stateUpdater: setAction }
      },
      q3() {
        return { nextState: 'q4', effect: yFork(action) }
      },
      q4() {
        return { nextState: 'q2', effect: yDelay }
      },
    },
    'q1',
    `throttle(${safeName(pattern)}, ${worker.name})`,
  )
}

And here is my interpretation of throttle (using my own layout for clarity of understanding instead of adherence to lint etc.)
 const  throttle = (delayLength, pattern, worker, ...args)=> {  let action, channel
        return fsmIterator(
                {   q1 : ()=>({ nextState: 'q2', effect:   { done: false, value: actionChannel(pattern, buffers.sliding(1)) }  , stateUpdater:  ch => channel = ch      }  )
                ,   q2 : ()=>({ nextState: 'q3', effect:   { done: false, value: take(channel)                              }  , stateUpdater:  ac => action  = ac      }  )
                ,   q3 : ()=>({ nextState: 'q4', effect:   { done: false, value: fork(worker, ...args, ac : action)         }                                           }  )
                ,   q4 : ()=>({ nextState: 'q2', effect:   { done: false, value: delay(delayLength)                         }                                           }  )
                }
                ,  'q1', 'throttle(' +  safeName(pattern) +' , ' +   worker.name +'  ) '   )

}

Other than typo's are these two equivalent or is there something else going on in yours?

If u refer to the object shorthand syntax used for methods there then there is a difference, but one that doesn't affect us anyhow.
Our methods can be bound and yours not (as they are arrow functions). So the this and stuff works differently between them. But as I said - that difference doesn't really matter here.
Other than that we also preserve references to helper functions (stateUpdaters) by hoisting & closing them over, instead of recreating new functions (and thus "pressuring" GC) whenever stateUpdater gets called. Probably doesn't matter either, so kinda whatever - I just got accustomed to preserving references whenever possible.

In small space I agree with you but most developers (such as myself) now have 4k screens.  To use the narrow code layout wastes 95% of the available space on screen. I cannot remember the last time i used a small screen for development. And one can put much more useful content on screen by laying it out as i have.
IMHO the people that advocate using 80 characters per line (ish) and therefore only showing on function call  per screen of real estate are just silly and not to be taken seriously

as i said punch cards are the natural extension of your argument :)
120 columns is fine for 1988 or if efficiency of development is low priority

fully used screen   3x info density (mocked up here ONLY to illustrate my point...  )
(Plus zoom in and out to see if necessary.

I am still dumbfounded that this argument still exists. The earth is not flat, evolution exists in nature but not in how programmers take advantage of available screen real estate?
Go figure!

Well, that is still just your personal preference. Ours is just different 😉A good thing about programming is that you can write in various languages and in various styles so everyone can achieve his/her happiness.

Yes , indeed!
Gulliver's travels did not have a wide-endian vs-narrow-endian  but should have!
/jpr

I don't want to derail the conversation, but I recently adapted redux-saga to be used without redux: https://github.com/neurosnap/cofx
It's not 1:1 parity (e.g. no forking model) but I think covers quite a few common use-cases, especially for node io.

Cool project, nice to see exploration in this area. Just adding a note - redux-saga can be actually used without redux too 😉

Oh nice!  I thought it might be possible. Is there a guide on how to do it
somewhere?
On Tue, Sep 18, 2018 at 6:01 PM Mateusz Burzyński<EMAIL_ADDRESS>wrote:

Cool project, nice to see exploration in this area. Just adding a note -
redux-saga can be actually used without redux too 😉
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/redux-saga/redux-saga/issues/1561#issuecomment-422572003,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB2bjTAe5OichQcm-Q-UIKaYRqcVxN9jks5ucW1JgaJpZM4WCwPo
.

You can check out a working example here - https://codesandbox.io/s/1yq1lx77jq . It's working with current v1-beta.2, to make it work with v0.x you would have to replace channel config option with subscribe (which works slightly differently, but we have it described in the docs - I think).
All options - dispatch, getState & channel are just to handle put, take & select. It should be usable without any config for use cases not needing those 3.

At the risk of exposing my inner bone head. I have been playing around with your new sandbox and it is really cool yet really mysterious as to what it replaces or uniquely provides from a functionality standpoint?
lelet counter = 0
const emitter = new EventEmitter()
const channel = stdChannel()
emitter.on("action", channel.put)

runSaga(({ channel,dispatch: out => { emitter.emit("action", out) } , getState: () =>{ "sample"} }),
  function* () {
    const chan = yield call(() => eventChannel(emit => {
                        const id = setInterval(() =>   emit(counter++) , 1000)
                        return () => clearInterval(id)
                         }))
  while (true) {
    const received =                yield take(chan)
    yield fork(function* () {       yield delay(1000)
                                    yield put({ type: "RECEIPT" })
    })
    const r = yield race({ response: take("*"), timeout: delay(5000) })
    r.response && console.log("  counter = " + counter, r.response)
  }
})

I have rewritten your code to see how i can break it and the above code works.
As far as i can tell it sets a timer then manages a message stack???
I also eliminated as many levels of recursive indirection as possible just to make sure that I understood what the code does.
(I also eliminated the try, finally code because there was a while(true) in between)
Perhaps I should rephrase... I know what it does, I just don't know why?

The code itself on the sandbox is not mine, I just have forked it and made it work with stdChannel, so other than that I won't discuss the logic there.
The difference between eventChannel and stdChannel is that later is unicast (single emit hits a single observer, supports buffering) and the latter is multicast (single emit hits all current observers, doesn't support buffering).
stdChannel is used internally to emit redux actions to a saga runtime, but also can be used to connect any other IO (other than redux) with saga (as the integration layer between redux and the saga is actually very thing and the saga is complete independent of the redux) with { dispatch, getState, channel } config object (used with runSaga API).


Infinite Items

When throwing an egg, and possibly similar items, the egg isn't used and instead can be thrown for infinite chickens.

Fixed in a recent commit. Thanks!


Optimize single line body methods

Kotlin allows for = methods instead of { return.
Example:
func mapToUserItem(user: User) -> UserItem {
    return UserItem(name: user.fullName)
}

Translates to:
fun mapToUserItem(user: User) : UserItem {
    return UserItem(name = user.fullName)
}

But could be:
fun mapToUserItem(user: User)  =
    UserItem(name = user.fullName)

Fixed with e0a49e4138b0a89e7f6a3f448e1d611e5206ff4b


Strictly define order of operations when halting a tree

Motivation
When converting fork to an operation, we changed the way that continuation and failure are reported up the tree to the parent of the operation. Instead of calling the join() method on the parent, we used the general "exit hook" mechanism to control the flow of the program. When a child was created, the parent added shutdown hooks to it that would handle the result of the child finishing and use that to pass control back to the parent.
The problem with this is that if one of your shutdown hooks has the responsibility of running other shutdown hooks, which could cause shutdowns, that run other shutdown hooks, you can zig and zag across different contexts and experience wildly different orders of shutdown and context settlement depending on how a context resolves (success, failure, cancellation, etc..)
In fact, we were observing this behavior, when shutdown hooks were running in different orders, we'd see vastly different results.
What we'd like to see however is a strict reverse-depth-order teardown so that whenever a portion of the tree is de-commissioned, nodes that can have dependencies on prior nodes are de-commissioned first.
For example, in the following tree:
(A,
(B)
(C))
As children, both B, and C can depend on A, and even though B and C are siblings, since C was created later in the computation, it is conceivable that it depends on B. The reverse is not (easily) true. Therefore, the order of destruction we want is C -> B -> A.
Approach
We address this problem by splitting shutdown callbacks into two distinct categories. The first is the original mechanism, added by ensure(), and which now has zero effect on the control flow of the application. The exit hooks added in this way are just a flat list of functions to run a single time when the context is finalized. Each hook in the list only operates within the single context, and is mainly just meant to be added from user-land to control runtime resources.
The second kind of hook is used exclusively for handing off control of the computation from the finalizing context. In other words, "the computation represented by this context is now complete, what happens next?" While exit hooks can be many, there can only be a single continuation hook, and if we think about it, this make sense. Like a normal function, it can do a great many things, call out to a number of other functions, but it can only return to a single place.
In summary, by placing these two callbacks into different worlds, we can guarantee that shutdown hooks are run in a very precise order, and that they cannot (without dedicated nefarious hackery) interfere with the continuation of the computation.
Implementation
This uses the simplest thing that could possibly work: leave the current teardown mechanism as-is, and introduce a single callback to a new context. This callback is aptly name "continue", and is invoked as the very last thing a context ever does.
Now, finalize can only every be invoked a single time, and has a very
strict structure.

record results
halt all children in reverse order
run all exit hooks in reverse order
finalize the promise.
continue.

New Guarantees:

spawn: all spawned child contexts are destroyed before their parent context is finalized. There is no continuation by default, so it just goes away without having any effect on the parent. However, if the parent is halted at any point during its run, it will be halted immediately.
monitor: In addition to spawn guarantees, any failed monitor raises failure in its parent
fork: In addition to monitor guarantees. parent may not continue until completed (though it may spawn more operations).
join: In addition to fork guarantees, parent may not run any operations until joined child is completed.

For further context:
https://github.com/thefrontside/effection.js/issues/70
Open Questions

There is probably a way to model the internal continuations semi-monadically so that we don't have to store state like required   children and waiting  and what not on the context, and so that in   monitor and fork and other control functions, we don't have to   fiddle with that state, but instead allow the control function   itself to somehow pass control to the "next" thing, which naturally   unfolds the computation. If it sounds hand-wavy, it is, but until   that elegant solution is found, we can start with a hackier one.
We will need some way to "re-direct" the continuation of a context   in the case of joining a fork. In other words, if we join a fork,   something else needs to happen when it continues, not what happens when it was originally conceived.

A preview package of this pull request has been released to NPM with the tag strict-teardown-order.
You can try it out by running the following command:
$ npm install effection@strict-teardown-order

or by updating your package.json to:
{
  "effection": "strict-teardown-order"
}

Once the branch associated with this tag is deleted (usually once the PR is merged or closed), it will no longer be available. However, it currently references<EMAIL_ADDRESS>which will be available to install forever.

  Generated by :no_entry_sign: dangerJS against af7dd8f6a7b0dd563d3c4e7ed4a105c34b903a49

A preview package of this pull request has been released to NPM with the tag strict-teardown-order.
You can try it out by running the following command:
$ npm install effection@strict-teardown-order

or by updating your package.json to:
{
  "effection": "strict-teardown-order"
}

Once the branch associated with this tag is deleted (usually once the PR is merged or closed), it will no longer be available. However, it currently references<EMAIL_ADDRESS>which will be available to install forever.

  Generated by :no_entry_sign: dangerJS against e3129b7207ca2117df843755721661dd8b4541d6

🎉🎉🎉 Let's get this merged and upstreamed ASAP


Remove Node_Modules and .DS_Store from Repo

Remove Node_Modules folder and .DS_Store from Repo, because it's not needed.

-- Done --


single-node multi-gpu training never starts

Bug description
Training never starts when using multiple GPUs with the "ddp" strategy. I’ve only tried with 1 node.
My issue is related to #14611 but for him, it seems to work with gloo instead of nccl. Both fail for me.
As suggested by https://github.com/Lightning-AI/lightning/issues/14611#issuecomment-1260102536, I’ve tried a minimal torch.distributed and it works with both gloo and nccl. So the problem does come from lightning.
How to reproduce the bug
$ cat lightning/main.py

import os
from torch import optim, nn, utils, Tensor
from torchvision.datasets import MNIST
from torchvision.transforms import ToTensor
import pytorch_lightning as pl

# define any number of nn.Modules (or use your current ones)
encoder = nn.Sequential(nn.Linear(28 * 28, 64), nn.ReLU(), nn.Linear(64, 3))
decoder = nn.Sequential(nn.Linear(3, 64), nn.ReLU(), nn.Linear(64, 28 * 28))

# define the LightningModule
class LitAutoEncoder(pl.LightningModule):
    def __init__(self, encoder, decoder):
        super().__init__()
        self.encoder = encoder
        self.decoder = decoder

    def training_step(self, batch, batch_idx):
        # training_step defines the train loop.
        # it is independent of forward
        x, y = batch
        x = x.view(x.size(0), -1)
        z = self.encoder(x)
        x_hat = self.decoder(z)
        loss = nn.functional.mse_loss(x_hat, x)
        # Logging to TensorBoard by default
        self.log("train_loss", loss)
        return loss

    def configure_optimizers(self):
        optimizer = optim.Adam(self.parameters(), lr=1e-3)
        return optimizer

# init the autoencoder
autoencoder = LitAutoEncoder(encoder, decoder)
# setup data
dataset = MNIST('/gpfsdsstore/projects/rech/fih/usl47jg/datasets/MNIST', transform=ToTensor())
train_loader = utils.data.DataLoader(dataset)

trainer = pl.Trainer(max_epochs=10, accelerator="gpu", devices=2, strategy="ddp")
trainer.fit(model=autoencoder, train_dataloaders=train_loader)

$ cat 2-v100-32g_20h_distributed-lightning.sh
#!/bin/bash
#SBATCH --nodes=1
#SBATCH --ntasks-per-node=2
#SBATCH --cpus-per-task=10
#SBATCH --gres=gpu:2
#SBATCH -C v100-32g
#SBATCH --hint=nomultithread

source /gpfswork/rech/fih/usl47jg/miniconda3/etc/profile.d/conda.sh
conda activate datasets

# debug
export TORCH_DISTRIBUTED_DEBUG=INFO
export NCCL_DEBUG=INFO

python lightning/main.py

# also tried this but does not work either
# python -m torch.distributed.run --nproc_per_node 2 lightning/main.py

$ sbatch 2-v100-32g_20h_distributed-lightning.sh

Multiprocessing is handled by SLURM.
GPU available: True (cuda), used: True
TPU available: False, using: 0 TPU cores
IPU available: False, using: 0 IPUs
HPU available: False, using: 0 HPUs
Initializing distributed: GLOBAL_RANK: 0, MEMBER: 1/2

# ... and nothing ... stuck for hours...

Environment
I use SLURM.

Lightning:
- pytorch-lightning: 1.7.7
- torch:             1.12.1
- torchaudio:        0.12.1
- torchmetrics:      0.10.0
- torchtext:         0.13.1
- torchvision:       0.13.1

System:
- OS:                Linux
- architecture:
- 64bit
- ELF
- processor:         x86_64
- python:            3.10.4

@PaulLerner Could you please delete #SBATCH --cpus-per-task=10 and try again? If that works, I will add it to #15011
Also please change
python lightning/main.py

to
srun python lightning/main.py

We recently added a troubleshooting section.

Adding srun fixes it, thanks a lot! Sorry, I did not know about this slurm tutorial of yours, I spent a lot of time scrolling through all of the GPUs tutorials :)
To be clear, I did not have to delete #SBATCH --cpus-per-task=10 to fix it.

@PaulLerner Glad you managed to make it work. We're looking into adding more validation around this common user error: https://github.com/Lightning-AI/lightning/issues/10150


Black-box context propagation doesn't work when calling a K8S service

Example Setup
I set up a simple distributed demo application on a single node K8S cluster with kind.
It's based on the docker-compose.yaml in the Beyla repository, but instead of Docker compose I deployed it in Kubernetes. Beyla is deployed as a DaemonSet. The source code can be found on https://github.com/fstab/2024-03-meetup-beyla-demo.
Expected behavior
After reading the excellent Blog post on distributed tracing with Beyla 1.3 I thought distributed tracing might work as my cluster has only a single node.
Actual behavior
It almost worked, but not fully. I saw client spans for the outgoing requests, and I saw server spans for the incoming requests. However, these spans had different trace IDs.
Potential Cause
I suspect this is because the IP addresses don't match:

The client sends a request to a Kubernetes service, so the client span has the service IP as the server.address.
The server span has the node IP as server.address.

I guess somewhere in the middle kube-proxy does its magic and translates the service IP to the pod IP.
Anyway, just guessing, I could be totally wrong.

I believe this should fix it https://github.com/grafana/beyla/pull/698. If you can try that branch, that would be absolutely awesome 😁. I am going to use your example as a test, since I have to add one for this new functionality.
It does require
hostNetwork: true
dnsPolicy: ClusterFirstWithHostNet
as settings. The second is only needed so that we can still use dns for talking to the agent or collector, otherwise hostNetwork makes everything localhost.

I believe this is fixed now, if it still doesn't work we can reopen.


[TUZ-168][WIP] Frontend Support to Enable BYOC

This PR is based on previous built frontend and make changes to the frontend to support BYOC on cuda.
The work is currently in progress, some notes:

tir.erf doesn't support fp16 so need to cast to fp32 in Gelu operator.
Need to use bb.emit before return to make sure later node can get a name hint from previous results.

Our testing script is available here: https://gist.github.com/zxybazh/f6096ab29c3fad1fee1dad2f4c963f34
Co-authored with @vinx13

Closing because the operators are already refactored in the frontend. Note that erf is not working for fp16 so for certrain models we still need the Gelu & BiasGelu casting support.


Extra check before calling method causes problem

I am sure this is reported somewhere but just making sure. I am tsc version:  Version 3.7.2
this works:

but then I add an extra super safety check and it fails unnecssarily:

maybe it's operator/user error, idk

Do not ignore template and provide link to playground. It's hard to read code from screenshots.
Questions should be asked on StackOverflow first

in your case isFunc doesn't have any annotation that will narrow type to function
Playground

@ORESoftware You've contributed a very high quantity of noise to this repo with very little signal at this point. I'm asking you to use other forums to get TypeScript support. You are uniquely in the position of having filed nearly 100 issues without identifying a single actual bug, and this is a system for tracking bugs.

Further use of the issue tracker for support purposes will be considered abuse.


Post Librecat migration cleanup

[ ] investigate export/import errors + 1 publication was not migrated
/vol/share/nsteenla/filtered_files_fixed.jsonl
/vol/share/nsteenla/pubs_with_fixed_sizes.jsonl
[ ] remove old production librecat* indexes, databases, files, rpm

@mietcls @nicolasfranck keeping these for a while longer, used them for inspection only last week

@nics should we keep this around in #1099 or can we start with this?

benign neglect: keep the files


Make RPC Support role Standalone Swift Friendly

Only create support keypair if nova service is present. Only create support security group if neutron service is present.
Fixes #221
(cherry picked from commit e739459a1cd1fc97de103fd92f390b514be61fdd)

In order to minimize impact on QE, I'm going to set this as blocked and push it to Kilo 11.1.0

I am +1 on this.

recheck

Looks like this needs to be rebased before the travis checks will work.
fwiw, I don't know that 'recheck' works on Travis.

I missed this in my initial patch (keys laying around from partially run support_key_pair.yml), but the distribute_auth_key.yml and retrieve_auth_key.yml includes need the same fix applied. I'll put together a new pull request against master for this.

@byronmccollum will you rebase this patch so travis gets a nudge.

This is @mattt416 's pull request.

Whoops! Sorry @byronmccollum
@mattt416 do it!

This was already fixed by https://github.com/rcbops/rpc-openstack/pull/425


feat: builds identity header from host content if missing in metadata

ESSNTL-5248
Secure Coding Practices Checklist Link

https://github.com/RedHatInsights/secure-coding-checklist

Secure Coding Checklist

[ ] Input Validation
[ ] Output Encoding
[ ] Authentication and Password Management
[ ] Session Management
[x] Access Control
[ ] Cryptographic Practices
[ ] Error Handling and Logging
[ ] Data Protection
[ ] Communication Security
[ ] System Configuration
[ ] Database Security
[ ] File Management
[ ] Memory Management
[x] General Coding Practices

Codecov Report
Patch coverage is 100.00% of modified lines.

Files Changed
Coverage

historical_system_profiles/archiver.py
100.00%

:loudspeaker: Thoughts on this report? Let us know!.


question: [Changing out ELMo for Clinical BERT Embeddings]

Hi! I'm trying to use ABSA for clinical notes, and I'm wondering if it would be possible to switch out ELMo for BERT - specifically BERT-Base and BioBERT-finetuned models trained on both all clinical notes and only discharge summaries as per this article.
How hard do you think it would be if you think it's even possible? Thanks!!

Hi @amygeorge
Please see the algorithm description in the documentation, here.
Our model only uses Word2Vec embedding (not ELMo) in the final re-ranking phase.
From documentation:
"4. The last step includes applying an MLP based opinion term re-ranking and polarity estimation algorithm. This step is based on using the word embedding similarities between each acquired term and a set of generic opinion terms as features. A pre-trained model is re-ranking provided."
As I see it, this similarity model cannot work directly with contextual word-embeddings, which encode multiple words.
However, you can try to combine BERT with our algorithm by training it to extract aspects for your task, and feeding them as the aspect lexicon.
Best
Daniel

Thanks @danielkorat
I was under the impression from this documentation that ELMo was being used.
I will look into what I can do by running BERT first and passing them in as aspects.
Thanks for the suggestions!


stable-1.10 backports

Commits backported:
v2: Open log fifo with RDWR instead of WRONLY … ffa090a
qemu: Don't crash if virtiofsd path is non existent … cbfb3a4
virtcontainers: Don't create vfio devices in the guest … 11838d0

/test

Seems that we will need to update to go 1.13.9 as we are hitting this issue:
19:19:42 make[1]: Entering directory '/tmp/jenkins/workspace/kata-containers-tests-cri-containerd-PR/go/src/github.com/containerd/cri'
19:19:42 🇩 _output/integration.test
19:19:42 go test -c github.com/containerd/cri/integration -o _output/integration.test
19:19:44 # github.com/containerd/cri/vendor/k8s.io/apimachinery/pkg/util/errors
19:19:44 vendor/k8s.io/apimachinery/pkg/util/errors/errors.go:99:10: undefined: errors.Is

This failure happens when trying to run the containerd tests (including shimv2).
Tried to search around and seems that the only fix is to update go version.

Travis failed with the dreaded error...
INFO: Building github.com/golangci/golangci-lint
go build -o golangci-lint ./cmd/golangci-lint
go<EMAIL_ADDRESS>invalid pseudo-version: does not match version-control timestamp (2019-02-10T22:04:43Z)

/test

/test


Trying to make editable text field - keeps disappearing.

I created a small "editable field" where if you click on the text, it'll change to a text box which you can then modify.
However, I'm seeing some really strange behavior from hitting "Escape": If I click on the text, and edit the text, and hit "Enter" everything's fine. If I hit "Escape" it appears to delete the last element.
So if I click on the Text, type something and hit "Escape" it deletes div "savedValue". If I do it again, it deletes span "textField".
My intention was obviously to change "Text" back to "_savedValue" if they hit escape. And it seems like it might work, but it keeps deleting the elements.
Any other warnings, caveats, or better ways to do what I'm trying to do appreciated.
Thanks

    @if (_editing)
    {
        <input id="textField" bind="Text" onkeyup="@OnKeyUp" />
    }
    else
    {
        @Text
    }

@_savedValue

@functions{
    [Parameter]
    string Text { get; set; }

    [Parameter]
    private Action<string> TextChanged { get; set; }

    bool _editing = false;

    string _savedValue;

    void OnTextClicked()
    {
        _editing = true;
        _savedValue = Text;
    }

    void OnKeyUp(UIKeyboardEventArgs eventArgs)
    {
        if (eventArgs.Key == "Enter" || eventArgs.Key == "Escape") //This causes the issue
        {
            _editing = false;
        }
    }
}

Further editing and canceling will set
 above the div and remove
 altogether.

I have taken an example provided by @stanac and added Console.WriteLine(eventArgs.Key); at the beginning of OnKeyUp function. Here are my results on Windows 10:

Firefox 61.0.1 - works as expected
Chrome 68.0.3440.84 - crash with the same stack trace as seen above
Edge 16.16299 - initially Esc key doesn't work because eventArgs.Key for Esc key in Firefox and Chrome is equal "Escape" but in Edge it is "Esc". I have changed the line in OnKeyUp to

if (eventArgs.Key == "Enter" || eventArgs.Key == "Escape" || eventArgs.Key == "Esc")

and Edge works as expected.

I have forgotten to say that I have Blazor 0.5.1 and code provided by @stanac was pasted into default Blazor (ASP.NET Core hosted) application.

Mine is also a Blazor ASP.NET Core Hosted app. Also since I posted this and have gotten more controls on the page, it has begun deleting things even when I hit "Enter" - basically turning off the Editable mode seems to have the unexpected effect of not rendering anything at all.
As a workaround I'm going to switch to turning the field visible/invisible with JavaScript, and just call that from the C# code and see how that works.

Realizing that JavaScript can't be isolated to a component, I changed to a CSS hack:
    <input id="textField" bind="Text" onkeyup="@OnKeyUp" type="@TypeOverride" class="@(InputClassOverride + (_editing ? "" : " invisible"))" onblur="@OnBlur" />
    @Text

Ran into the OnInput issue. (Binding to OnInput doesn't work right now without a workaround seen here: https://github.com/aspnet/Blazor/issues/821 )  I need Enter and OnBlur to result in a positive save action, and escape to result in a "cancel" action.
For the sake of anyone trying to figure out how to do this, this code seems to work completely though it's kind of hacky. I switched from changing the Text then reverting to changing the Text property on "save". I don't know if that's 100% necessary, but like I said, everything seems to work here.

    <input id="textField" bind="@_internalText" oninput="(this.dispatchEvent(new CustomEvent('change', { bubbles: true })))" onkeyup="@OnKeyUp" type="@TypeOverride" class="@(InputClassOverride + (_editing ? "" : " invisible"))" onblur="@OnBlur" />
    @Text

@functions{
    [Parameter]
    string Text { get; set; }

    [Parameter]
    string TypeOverride { get; set; } = "text";

    [Parameter]
    private Action<string> TextChanged { get; set; }

    [Parameter]
    string InputClassOverride { get; set; } = "";

    [Parameter]
    string FieldClassOverride { get; set; } = "";

    string _internalText = null;

    bool _editing = false;

    Action _blurAction;

    void OnTextClicked()
    {
        _editing = true;
        _internalText = Text;
        _blurAction = () => { Text = _internalText; _editing = false; };
    }

    void OnBlur()
    {
        _blurAction?.Invoke();
    }

    void OnKeyUp(UIKeyboardEventArgs eventArgs)
    {
        Console.WriteLine("On Key Up: " + eventArgs.Key + " " + _internalText);

        if (eventArgs.Key == "Enter" || eventArgs.Key == "Escape" )
        {
            if (eventArgs.Key == "Enter")
            {
                Text = _internalText;
            }
            _blurAction = null;
            _internalText = null;
            _editing = false;
        }
    }
}


Please remove Office.com from the list of applications included in Of…

…fice 365 Client App
Please remove Office.com from the list of applications included in the Office 365 Client App as we already have included Office Online in the list of included Apps. Office.com is the landing page for Office Online as is Outlook.com the landing page for Exchange Online.

@rrajan82 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Taking conversation internal to Teams.


Updated controller software

Make the code look pretty too

Maybe add lines to 3D pose view

Lines and bezier curver!


Tahoma: Unsupported type of my covers and cover control buttons reversed and stop button not working

Home Assistant release with the issue:

0.64.2
Last working Home Assistant release (if known):
Operating environment (Hass.io/Docker/Windows/etc.):

Hassbian on Raspberry Pi 3 (2.5A Power supply)
Component/platform:

https://www.home-assistant.io/components/tahoma/
Description of problem:
Getting unsupported type of my covers:
Unsupported type io:VerticalExteriorAwningIOComponent for Tahoma device Screen øst
Unsupported type io:HorizontalAwningIOComponent for Tahoma device Markise
Tried to manually adding the "io:HorizontalAwningIOComponent" in the TAHOMA_TYPES in my local installation, it did appear as a cover with arrow buttons up and down and stop button. Arrow buttons work reversed (up is down, down is up), and the stop button is not working.
No position slider or position is shown as well.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
tahoma:
  username: myusername
  password: mypassword

Traceback (if applicable):
Getting a lot of these errors, might be relevant to the problem:

socket.send() raised exception.
21:44 components/websocket_api.py (WARNING)

Additional information:

I am working on a support for the io:VerticalExteriorAwningIOComponent and can add your Horizontal type as well. I have to get the changes tested and committed to my fork repo. Then you could install the changed files to your custom_components folder and test the changes.
It should be ready soon.

Find the changes in the following commit. Let me know how it goes...
Add support for 2 cover types, a smoke detector and a light switch

@pascalsaul I just created a new branch for adding the two AwningIOComponents, including some attributes and icon handling. It would be great, if you could quickly test it with your installation, because I have no HorizontalAwningIOComponent.
The slider is working, but it seems that it is logically inverted, at least for the HorizontalAwningIOComponent. I checked the HA demo cover implementation as well, where it behaves the same.
I'm going to create a PR soon.

I've overwrited those two files  with the ones in the new branch and my results voor the Vertical still ok but for the Horizantal one is worser. It's not working anymore...
The state of the arrow is OK
No slider as you can see
Buttons are reversed and not working anymore

Full overview (everything is closed but the Horizontal is reversed. When I click the black arrows it call cover_open but nothing happens. The connected action should be switched I guess...

I prefer that the button in the interface are reversed because now I'm think the horizontal screen is "open" but it is closed.

I Also have problems adding my vertical and horizontal screens, HASS version 0.74.0:
Unsupported type io:VerticalExteriorAwningIOComponent for Tahoma device Kleine-Slaapkamer
23:36 components/tahoma.py (WARNING)
Unsupported type io:HorizontalAwningIOComponent for Tahoma device Zonnescherm
23:36 components/tahoma.py (WARNING)
Unsupported type io:VerticalExteriorAwningIOComponent for Tahoma device Grote-Slaapkamer
23:36 components/tahoma.py (WARNING)

Don't forget to apply the fix first and copy the files to:/config/custom_components/XXXX/tahoma.py
After that overwrite these with the 2 new files from the new branch. It's not in the production branch yet ;)

For

Buttons are reversed and not working how it should be

please try the following. I added this, because @anaxyd reported:

Arrow buttons work reversed (up is down, down is up)

Replace this code in cover/tahoma.py
    def open_cover(self, **kwargs):
        """Open the cover."""
        if self.tahoma_device.type == 'io:HorizontalAwningIOComponent':
            # The commands open and close seem to be reversed.
            self.apply_action('close')
        else:
            self.apply_action('open')

    def close_cover(self, **kwargs):
        """Close the cover."""
        if self.tahoma_device.type == 'io:HorizontalAwningIOComponent':
            # The commands open and close seem to be reversed.
            self.apply_action('open')
        else:
            self.apply_action('close')

with
    def open_cover(self, **kwargs):
        """Open the cover."""
            self.apply_action('open')

    def close_cover(self, **kwargs):
        """Close the cover."""
            self.apply_action('close')

See: https://github.com/octa22/openhab2-addons/blob/somfytahoma-binding/addons/binding/org.openhab.binding.somfytahoma/src/main/java/org/openhab/binding/somfytahoma/handler/SomfyTahomaAwningHandler.java
It look liks that here is no reversing at all and this implementation works, also with the position.
In this implementation something is still wrong with the position information. Guess that needs to be fixed first.

Did you test the code, where the reversing is removed?
For

No slider as you can see
Position isn't being detected

Please check what is reported in the attributes of your cover and post a screenshot (Developer tools >> State):

current_position: position used by HA, which is used for the slider. If this is missing, you won't have a slider (= 100 - closure).
closure: position reported by the Tahoma API
supported_features: 15 means open, close, set position, stop is supported. 11 means only open, close, stop is supported (because current_position value is not available)

So, do the commands up and down work now correctly, with the reverse code removed?
Can you please enable debug logging with adding the following right after the homeassistant: section
logger:
  default: info
  logs:
    homeassistant.components.tahoma: debug
    homeassistant.components.cover.tahoma: debug

Then restart HA and search in the log for 11032457 (the second part your your device id). The section which I need starts with {'creationTime': and ends with 'uiClass': 'ExteriorScreen'}

I can't use the commands because the arrow is greyed out because of the wrong position state so can't do up and down...
`2018-07-22 12:17:21 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=cover.awning_back, old_state=None, new_state=<state cover.awning_back=open; tahoma_device_id=io://0804-6811-1035/11032457, rssi_level=60.0, open_close=open, status=available, priority_lock_timer=0, friendly_name=awning_back, supported_features=11 @ 2018-07-22T10:17:21.109055+00:00>>
Opened from 85% to 100% with the arrow "down" (I've set with the other app to 85% first)
2018-07-22 12:19:29 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=cover.awning_back, old_state=<state cover.awning_back=open; tahoma_device_id=io://0804-6811-1035/11032457, rssi_level=60.0, open_close=open, status=available, priority_lock_timer=0, friendly_name=awning_back, supported_features=11 @ 2018-07-22T10:17:21.109055+00:00>, new_state=<state cover.awning_back=open; tahoma_device_id=io://0804-6811-1035/11032457, rssi_level=68.0, open_close=open, status=available, priority_lock_timer=0, friendly_name=awning_back, supported_features=11 @ 2018-07-22T10:17:21.109055+00:00>>
`
Look like I'm missing the debug information...

Yes, the debug information is missing. You did not get the information provided by the Tahoma API. You have to set default: debug as well.

Doesn't help... no debug information... Don't you miss those _LOGGER. lines in your code at the right places?
What I do see is that every device does get updates except the awning..
2018-07-22 12:59:38 DEBUG (SyncWorker_8) [custom_components.cover.tahoma] Update shutter_front_right, position: 0
2018-07-22 12:59:38 DEBUG (SyncWorker_7) [custom_components.cover.tahoma] Update shutter_back_left, position: 0
2018-07-22 12:59:39 DEBUG (SyncWorker_4) [custom_components.cover.tahoma] Update screen_front, position: 0
2018-07-22 12:59:39 DEBUG (SyncWorker_9) [custom_components.cover.tahoma] Update shutter_back_right, position: 0
2018-07-22 12:59:39 DEBUG (SyncWorker_0) [custom_components.cover.tahoma] Update shutter_front_left, position: 0

I need the input from the Tahoma API to see what kind of state values are provided by the vertical cover. For that I need a log which looks like this:
{'creationTime':<PHONE_NUMBER>000, 'lastUpdateTime':<PHONE_NUMBER>000, 'label': 'Zimmer Maël', 'deviceURL': 'io://0203-3494-1377/16312571', 'shortcut': False, 'controllableName': 'io:VerticalExteriorAwningIOComponent', 'definition': {'commands': [{'commandName': 'close', 'nparams': 0}, {'commandName': 'delayedStopIdentify', 'nparams': 1}, {'commandName': 'deploy', 'nparams': 0}, {'commandName': 'down', 'nparams': 0}, {'commandName': 'getName', 'nparams': 0}, {'commandName': 'identify', 'nparams': 0}, {'commandName': 'my', 'nparams': 0}, {'commandName': 'open', 'nparams': 0}, {'commandName': 'refreshMemorized1Position', 'nparams': 0}, {'commandName': 'setClosure', 'nparams': 1}, {'commandName': 'setDeployment', 'nparams': 1}, {'commandName': 'setMemorized1Position', 'nparams': 1}, {'commandName': 'setName', 'nparams': 1}, {'commandName': 'setPosition', 'nparams': 1}, {'commandName': 'setSecuredPosition', 'nparams': 1}, {'commandName': 'startIdentify', 'nparams': 0}, {'commandName': 'stop', 'nparams': 0}, {'commandName': 'stopIdentify', 'nparams': 0}, {'commandName': 'undeploy', 'nparams': 0}, {'commandName': 'up', 'nparams': 0}, {'commandName': 'wink', 'nparams': 1}], 'states': [{'type': 'ContinuousState', 'qualifiedName': 'core:ClosureState'}, {'type': 'ContinuousState', 'qualifiedName': 'core:Memorized1PositionState'}, {'type': 'DataState', 'qualifiedName': 'core:NameState'}, {'values': ['closed', 'open'], 'type': 'DiscreteState', 'qualifiedName': 'core:OpenClosedState'}, {'type': 'ContinuousState', 'qualifiedName': 'core:PriorityLockTimerState'}, {'type': 'ContinuousState', 'qualifiedName': 'core:RSSILevelState'}, {'type': 'ContinuousState', 'qualifiedName': 'core:SecuredPositionState'}, {'values': ['available', 'unavailable'], 'type': 'DiscreteState', 'qualifiedName': 'core:StatusState'}, {'values': ['comfortLevel1', 'comfortLevel2', 'comfortLevel3', 'comfortLevel4', 'environmentProtection', 'humanProtection', 'userLevel1', 'userLevel2'], 'type': 'DiscreteState', 'qualifiedName': 'io:PriorityLockLevelState'}, {'values': ['LSC', 'SAAC', 'SFC', 'UPS', 'externalGateway', 'localUser', 'myself', 'rain', 'security', 'temperature', 'timer', 'user', 'wind'], 'type': 'DiscreteState', 'qualifiedName': 'io:PriorityLockOriginatorState'}], 'dataProperties': [{'value': '500', 'qualifiedName': 'core:identifyInterval'}], 'widgetName': 'PositionableScreen', 'uiClass': 'ExteriorScreen', 'qualifiedName': 'io:VerticalExteriorAwningIOComponent', 'type': 'ACTUATOR'}, 'states': [{'name': 'core:NameState', 'type': 3, 'value': 'Zimmer Maël'}, {'name': 'core:PriorityLockTimerState', 'type': 1, 'value': 0}, {'name': 'core:StatusState', 'type': 3, 'value': 'available'}, {'name': 'core:RSSILevelState', 'type': 2, 'value': 32.0}, {'name': 'core:ClosureState', 'type': 1, 'value': 89}, {'name': 'core:OpenClosedState', 'type': 3, 'value': 'open'}], 'attributes': [], 'available': True, 'enabled': True, 'placeOID': '6a8405fb-b14e-4659-b90f-df5fd6262ffc', 'widget': 'PositionableScreen', 'type': 1, 'oid': '922306fe-ba27-468e-928f-7c04edabbbd4', 'uiClass': 'ExteriorScreen'}

Can you please try again? Make sure all three log levels are set to debug and the config file is saved.
Delete the home-assistant.log file and restart HA.

I did that dozens of times but I really don't get the information...
root@docker:/opt/home-assistant# grep creationTime home-assistant.log

Do you have something at all in the log file?
On the HA website, developer tools, Info, hit the circle arrow in the right bottom corner. Do you get some logs?

Log file is full of anything except your line... and a lot of Tahoma stuff

Strange, then I'll have to add some _LOGGER lines to get what I am looking for.

Please add this code:
        for key, val in self.tahoma_device.active_states.items():
            _LOGGER.debug("T-%s: key: %s, value: %s", self._name, key, str(val))

right after:
    def update(self):
        """Update method."""
        self.controller.get_states([self.tahoma_device])

Make sure the indention of 4 spaces is correct. Then post what you get for the horizontal cover.

That's it, we need to use DeploymentState for the horizontal cover. Let me update the code and get you another version.

:) Could you also add a config option to exclude scenes or should I open a new request? A good idea to keep that debug line also in the code for in the future to add new devices?

Open a new request for the config option to exclude scenes, but first look at the discovery-ignore option. It might already be possible:
discovery:
  ignore:
    - plex_mediaserver

To test the vertical cover please add this
        if 'core:DeploymentState' in self.tahoma_device.active_states:
            self._closure = \
                self.tahoma_device.active_states['core:DeploymentState']
        else:
            self._closure = None

right after
        if 'core:ClosureState' in self.tahoma_device.active_states:
            self._closure = \
                self.tahoma_device.active_states['core:ClosureState']
        else:
            self._closure = None

and test what is working as expected

Hold on, the code will not work... at least not for the verticals anymore...

Indeed and you need to add:
        if 'core:DeploymentState' in self.tahoma_device.active_states:
            self._position = 100 - \
                self.tahoma_device.active_states['core:DeploymentState']
            if self._position <= 5:
                self._position = 0
            if self._position >= 95:
                self._position = 100
            self._closed = self._position == 0
        else:
            self._position = None
            if 'core:OpenClosedState' in self.tahoma_device.active_states:
                self._closed = \
                    self.tahoma_device.active_states['core:OpenClosedState']\
                    == 'closed'
            else:
                self._closed = False

Yes, sorry, I changed that part locally already to:
        if self._closure is not None:
            self._position = 100 - self._closure

Is this now working for you as expected? With slider?
If yes, I will clean up the changes and commit an update on my branch, which you could test again.

Yes, slider works with that code :)

@pascalsaul @ameulen01
Can you please test again with the final code in this branch? Just take the two modified files

homeassistant/components/tahoma.py
homeassistant/components/cover/tahoma.py

and copy to:

/config/custom_components/tahoma.py
/config/custom_components/cover/tahoma.py

If all is ok, I will create a pull request to get it into main HA.

Almost but you should reverse somewhere the back-end action on open/close the covers with the awning.
It's fully 'deployed' now and want to close it but it's calling the open cover which should be the close cover.

Done, can you please test again?

HorizontalAwningIOComponent = OK
VerticalExteriorAwningIOComponent = OK
io:RollerShutterGenericIOComponent? = NOT OK (doesn't listen to 'stop')
Oximo IO motors are in my shutters... Where can I find the types back?

Try to add this type to one of these ifs below, in cover/tahoma.py and let me now, which command works. Currently the stopIdentify command is used.
    def stop_cover(self, **kwargs):
        """Stop the cover."""
        if self.tahoma_device.type == \
           'io:RollerShutterWithLowSpeedManagementIOComponent':
            self.apply_action('setPosition', 'secured')
        elif self.tahoma_device.type in \
                ('rts:BlindRTSComponent',
                 'io:ExteriorVenetianBlindIOComponent',
                 'rts:VenetianBlindRTSComponent',
                 'rts:DualCurtainRTSComponent',
                 'rts:ExteriorVenetianBlindRTSComponent',
                 'rts:BlindRTSComponent'):
            self.apply_action('my')
        elif self.tahoma_device.type in \
                ('io:VerticalExteriorAwningIOComponent',
                 'io:HorizontalAwningIOComponent'):
            self.apply_action('stop')
        else:
            self.apply_action('stopIdentify')

The type of the Tahoma device can be found in the debug log, which we tried to get earlier:
'controllableName': 'io:VerticalExteriorAwningIOComponent'

I think your own development environment is different with all the debug information you receive yourself? Which debug command on which line should give me that information...?

I did try it with my production system, but with 0.73 and it worked. I can try it tomorrow again with 0.74. You would need to look for the mentioned line starting with {'creationTime'.
Or you add a _LOGGER line in the stop_cover function to get the type:
 _LOGGER.debug("stop: type %s", self.tahoma_device.type)
Let me know the type and correct command, so that I can add it as well.

Yes, but the line isn't in my debug log... So which DEBUG line in the source should trigger that debug log exactly so I can check it?

That‘s not generated by a _LOGGER line in the cover component file. It must
be somewhere in the source some levels higher.
Why do you still need it if you know the type (io:RollerShutterGeneric...)?

It's easier troubleshooting for me also in the future... ;)
BTW; obstacle detection isn't implemented I see?

I did add the stop action for your io:RollerShutterGeneric... can you test again?
The debug line is printed with print in tahoma_api.py line 148. You can find it in /home-assistant/lib/python3.6/site-packages/tahoma_api/tahoma_api.py

It's actually not a _LOGGER line and you were right with the difference to my development setup. Enabling debug in the configuration does not help.
I guess you would need to get access to the docker shell and start HA somehow manually to get that line, but that's out of scope here.
As well implementation of obstacle detection. Please create another feature request or just start by your self! ;-)

i've added the modified files and it looks like it is working proper for me both horizontal and vertical covers, i will test some more the coming days:

i only receive a error about a binary sensor:
Unable to prepare setup for platform binary_sensor.tahoma: Platform not found.

The binary_sensor platform is not released yet, but already part of my main tahoma.py file. Don't worry about it.

You can create the PR for these fixes so it can be added to the upcoming release!
Yes, I'll create a feature request so somebody can look into it :) I don't mind to develop it but I need some time to dig into HA as developer then and this component and that will cost time to learn ;)

PR created, thank you all for your support with testing!

looks like it is al working oke now, only i think the slider is working in the wrong direction:

Yes, the slider is somehow inverted (blue part shows open part), but it‘s
like that in the cover demo component. That‘s why I did not try to change
it.
Please create a new issue, if you want to have ot changed.

ok, just tried some things, if i change this part:
        if self._closure is not None:
            self._position = 0 + self._closure
            if self._position <= 5:
                self._position = 0
            if self._position >= 95:
                self._position = 100
            self._closed = self._position == 100
        else:
            self._position = None
            if 'core:OpenClosedState' in self.tahoma_device.active_states:
                self._closed = \
                    self.tahoma_device.active_states['core:OpenClosedState']\
                    == 'closed'
            else:
                self._closed = False

and here:
    def set_cover_position(self, **kwargs):
        """Move the cover to a specific position."""
        self.apply_action('setPosition', 0 + kwargs.get(ATTR_POSITION))

instead of '100 - ' i changed it to ' 0 + '
the slider works as expected and the logging is correct. only then the buttons are reversed again and don't know how to fix that. i partially fixed it by ending up adding assumed_state to customize.yaml. only then i don't have the grayed out button based on the cover state.

I tried the same, some time ago. And ended up the same way. I checked how the demo cover is implemented and decided to life with it for now and fix the other issues.
Please search the forum or issues, and enter something new, if not available.


Using Reset Playback Freezes the Program

Describe the bug
Reset playback freezes the system
Steps to Reproduce

Go to Reset Playback on the bottom right of the control panel
Click on the icon and the system hangs...
Note: In both Expert mode and Advanced mode

Expected behaviour
Reset all the slide controls back to "zero" in order to start again
Setup information:

Audio device used for playback: Macbook speakers
Audio transmission interface:
macOS Version: 12.2.1
eqMac Version: Appv1.4.6 with Driver v2.0.5
eqMac UI Version: v3.2.4

Screenshots or Console.app logs
Error file attached
Additional information
log file 031822.txt

Hi, the reset button is for resetting the output not the sliders. And yes, it shouldn't crash the program. This is not reproducible on the latest version of eqMac for me so I am closing this issue now, if you are still encountering this bug, feel free to reopen it and comment on the details. Thanks!