Add option to force the AI to ask the user to confirm each change before doing it

Issue
Sometimes it is necessary to supervise each atomic change to the code or to the project configurations. Aider already shows us every atomic change like a diff. It would be great if, when specifically asked by the user, each change would be first shown and vetted by the user and only applied if approved. Something like a “SUPERVISED MODE” to enable when there is the need.
Version and model info
No response

Thanks for trying aider and filing this issue. Right now the recommended approach is just to use /undo to revert a change if you don't like it. Or you can turn off auto commits with --no-auto-commits.

I'm going to close this issue for now, but feel free to add a comment here and I will re-open or file a new issue any time.

Please open this improvement request. I consider it very important to have the option to validate changes before applying them, and that it can be an option that can be enabled or disabled. AI tools are still not entirely accurate and always require human review whenever possible before making a change or accepting a suggestion. @paul-gauthier

@danielorozco06 See my comment above. Is there a reason one of those solutions doesn't work for you?

The suggested approaches of using /undo to revert changes or turning off auto commits with --no-auto-commits are useful. However, I consider it very important to have the option to validate changes before they are applied. This feature would provide an extra layer of assurance, especially given that AI tools are not entirely accurate and always benefit from human review whenever possible. Having a validation step that can be enabled or disabled according to user preference would greatly enhance the usability and reliability of the tool. @paul-gauthier

@paul-gauthier  While using /undo to revert changes or disabling auto commits with --no-auto-commits are useful options, having the ability to validate changes before applying them is very important for several reasons:

Error Prevention: Validating changes beforehand can prevent errors that might not be immediately obvious and could cause issues later.
Time Saving: Reviewing changes before applying them saves time and avoids the tedious process of undoing and correcting errors.
Quality Control: Ensures that changes meet project standards and requirements before implementation.
Risk Reduction: Minimizes the risk of introducing inconsistencies or errors into the code, providing an extra layer of security.
Tool Confidence: Increases user confidence in the tool by giving them more control and peace of mind through pre-validation of changes.

I recommend doing aider --show-diffs. This way you will automatically see unified diffs for each chance as it is applied. If you don't like the diffs, simply type /undo and they will be reverted. I think that addresses all of your points?

Using aider --show-diffs to automatically see unified diffs for each change as it is applied is useful. However, from a user experience (UX) perspective, I believe validating changes before applying them is simpler and more efficient. This approach allows for corrections if necessary and provides greater ease in an iterative process of developer-suggested corrections. Additionally, it will be a feature that can be easily enabled or disabled according to each developer's preference.

Additionally, reviewing changes before applying them reduces cognitive load by eliminating the need to remember and undo incorrect changes.

Additionally, while the /undo command is useful for discarding the last commit, it doesn't fully address scenarios where multiple changes are made consecutively. If a mistake is found after several commits, relying on /undo would require reverting each commit one by one, which can be time-consuming and error-prone. Pre-validating changes allows for immediate corrections, providing a smoother and more efficient workflow.

And the/undocommand is useful for discarding the last commit, it only works if the changes have been committed. If a developer prefers to accumulate several changes before committing, finding an error in any of the changes would require a more complex rollback process.

I completely agree with @danielorozco06 . The unified diffs makes harder to supervise the code changes. A big batch of changes applied all together will make easy to miss errors.
The most productive, secure and effective way to do this is to let the user review and confirm/reject each single modification to the code atomically. That will improve the aider workflow immensely.
I would even go further, and let the user to ask the AI to made slight modifications to each proposed code change, so that, in those cases that the code proposed by the AI is not completely wrong but just slightly wrong and can be fixed changing few things, it would be possible to continue executing the AI planned changes instead of interrupting the workflow.
The ideal would be having 4 options after each proposed atomic change is shown:

APPLY - apply this atomic change as is.
MODIFY - ask the AI to make some modifications to this atomic change and review it again.
SKIP - discard this atomic change and continue with the other planned atomic changes.
STOP - discard this atomic change, stop but keep all the already applied atomic code changes.
REVERT - discard this atomic change, stop and revert to the original code before the sequence started.

IMHO this would be the best way to handle code changes or code generation when they need particular attention. This should be the standard for all AI code copilots.

I agree with the issue, it's pretty important for critical code.

+1 to all of the above. I'll unfortunately discontinue using aider for the simple reason that LLM models can get stuck in a loop.
Now I have 3 commits of it just looping over itself and suddenly my IDE's undo commit functionality isn't working because I have pending changes elsewhere in the file.
 would improve the UX a thousand-fold.

Absolutely needed functionality

I am surprised that the option to approve each change before Aider applies it is not available. I gave Aider a fair try, but as with any AI based tool today, some results are not accurate or completely wrong. While this is expected, the inability to carefully vet each change is not. Undo is not a good solution either, as it makes approval of partial changes cumbersome and error prone, as others already mentioned.
Without this ability, I find that I'm unable to use this tool efficiently, especially on big production code where extra carefulness is needed, and so for me at least, Aider may be a cool tool for demoing what AI can do, but no more than that unfortunately.
The upside is that adding such an option should be easy, if you decide to listen to the feedback that multiple people have given you regarding this gap.


Fix for #42

Hi, @IRus. You should replace yourHomeAssitantLongLivedAccessToken with your real token.

Hi, @IRus. You should replace yourHomeAssitantLongLivedAccessToken with your real token.

Exactly, but README doesn't contain this info, hence this PR

This configuration is not clear for people that runs this container without HACS or supervisor.
See #42

Your opinion is fully noted. We will merge your code soon. Thanks for your PR!


[Docs]: Clarify use cases for pg_basebackup

Is there an existing issue already for your request/idea?

[X] I have searched for an existing issue, and could not find anything. I believe this is a new documentation enhancement to be evaluated.

What problem in the existing documentation this issue aims to solve?
The "Bootstrap from a live cluster" section can be misleading, particularly in the statement:

The primary use case for this method is represented by migrations to CloudNativePG, either from outside Kubernetes or within Kubernetes (e.g., from another operator).

This claim is, in my opinion, overstated. In practice, the "Requirements" section is often overlooked, misunderstood, or not followed, which can lead to challenges. While theoretically possible, successfully importing a database from outside Kubernetes or from another operator via physical replication is quite rare. The process requires many complex factors to align perfectly.
It's worth noting that this section was written when CloudNativePG, at the time a closed-source product within EDB, lacked the import functionality and logical replication was not yet feasible.
Describe what additions need to be done to the documentation
We should rephrase that sentence and clearly scope down the feature.
Describe what pages need to change in the documentation, if any
https://cloudnative-pg.io/documentation/current/bootstrap/#bootstrap-from-another-cluster
Describe what pages need to be removed from the documentation, if any
No response
Additional context
No response
Backport?
Yes
Code of Conduct

[X] I agree to follow this project's Code of Conduct

While theoretically possible, successfully importing a database from outside Kubernetes or from another operator via physical replication is quite rare. The process requires many complex factors to align perfectly.

@gbartolini
Where can I find the requirements to prepare my existing non-cnpg database to migrate using physical replication?


Improve code coverage

Inspect the pytest coverage report for all our public repos and identify missing unittests. We should probably exclude the api generated code from the coverage report.
Related #640 - only the core repo is currently connected to the Codecov website, we need to do the same for other repos.

Hi Mainak, I am new to this but I would like to help out. I am trying to get a pytest coverage report from my fork but I am running into issues with the testing workflow. while running the tests on the GitHub CI I keep getting stuck on "waiting for a runner to pick up this job..." in the build documentation stage. I think it is this portion in the ci.yml
docs_build:
    name: Build Documentation
    needs: [docs-style]
    runs-on: [self-hosted, pyfluent]

Any more information that you could give me would be a huge help. @mkundu1

@Adam-Boutin As of now, the docker images aren't available in forked repos. If you have a local installation of Ansys, you can generate the coverage report by running pytest locally and open htmlcov/index.html in a browser:
pip install -r requirements/requirements_tests.txt
pytest -v -m "fluent_231" --cov=ansys.fluent --cov-report=xml:cov_xml.xml --cov-report=html --cov-config=.coveragerc

Hi Mainak, I am new to this but I would like to help out. I am trying to get a pytest coverage report from my fork but I am running into issues with the testing workflow. while running the tests on the GitHub CI I keep getting stuck on "waiting for a runner to pick up this job..." in the build documentation stage. I think it is this portion in the ci.yml
docs_build:
    name: Build Documentation
    needs: [docs-style]
    runs-on: [self-hosted, pyfluent]

Any more information that you could give me would be a huge help. @mkundu1

Mainak, I think if we allow Adam to create a PR on the repo we could make it work?

Looks like you can create a PR as an external contributor:
https://github.com/pyansys/pyfluent/pull/1370
but we would have to allow the workflow to be run.

Ok, just to make sure I am understanding this right. I would create a branch, make changes to the testing and, post a PR to main. This would create workflow request that once approved would run all the testing and create coverage report?

Yeah that seems to be how it’s working.

Sweet, I just have a few more questions if that is ok. I am unable to create a branch from the pyfluent main. Will I need permissions to do this?
( https://github.com/pyansys/pyfluent/actions/runs/4200562282 )
From here I can get the cov_xml.xml file. Does this show a break down of  the testing coverage where a hit="0" would be a line that is not covered by the test?
<class name="setup_for_fluent.py" filename="/home/ansys/actions-runner/_work/_tool/Python/3.9.12/x64/lib/python3.9/site-packages/ansys/fluent/core/utils/setup_for_fluent.py" complexity="0" line-rate="0.2" branch-rate="0">
					<methods/>
					<lines>
						<line number="1" hits="1"/>
						<line number="2" hits="1"/>
						<line number="5" hits="1"/>
						<line number="8" hits="0"/>
						<line number="9" hits="0"/>
						<line number="10" hits="0"/>
						<line number="11" hits="0"/>
						<line number="12" hits="0"/>
						<line number="13" hits="0"/>
						<line number="14" hits="0"/>
						<line number="16" hits="0"/>
						<line number="17" hits="0"/>
						<line number="19" hits="0"/>
						<line number="20" hits="0"/>
						<line number="22" hits="0"/>
					</lines>
				</class>

@dnwillia I tried the same in past. But the PR from my forked repo fails at the docker login step. The PAT from my personal account doesn't work.
We can add Adam as a contributor of the pyfluent repo.

@Adam-Boutin That's correct about the cov_xml.xml file. The html report will have the actual source lines, but it is not uploaded as artifact. I'll merge a change so that the html coverage is uploaded.

@Adam-Boutin Just added you as a contributor, now you'll be able to create branch/PR directly in the main pyfluent repo.

@dnwillia I tried the same in past. But the PR from my forked repo fails at the docker login step. The PAT from my personal account doesn't work.
We can add Adam as a contributor of the pyfluent repo.

OK cool.  I had never actually tried it before so thanks for setting Adam up.


Remove hard dependency on pinax teams (continued)

Is this PR complete? Does it replace #913?

Thanks @regiov !


Gradle 5 does not pick annotation processor from project dependency

My project has subprojects that are generating different artifacts. Among those, the subproject of interest are

model - contains annotations that will be used in other sub-projects
model-processor - contains annotation processor that generates sources for any class found with the annotations from model subproject
consumer - contains classes annotated with annotations from model subproject that should be accompanied by sources generated by annotation processor from model-processor subproject.

The build.gradle for consumer sub-project looks like
description = ''
dependencies {
    annotationProcessor project(':model-processor')

    compile project(':model')
}

Expected Behavior

I expect to find the generated sources under consumer/build/generated/source/apt/main
Current Behavior

I am not getting the files generated under consumer/build/generated/source/apt/main with the Gradle 5.0. I do get the annotation processor to work with the same build script and Gradle 4.10.2.
Context

I am trying to switch to Gradle 5 from Gradle 4.10.2 where the generation works. If I cannot get the annotation processor to work, I cannot migrate.
Steps to Reproduce (for bugs)

Clone https://github.com/ishaigor/annotation-processor-sample
Follow the steps in README
Your Environment

Build scan URL:
https://gradle.com/s/sremu47v5j5kk - non working 5.0
https://gradle.com/s/5pa5eu7fsrnic - working 4.10.2

@big-guy, @oehme, @marcphilipp, I updated the description with the link to the sample that demonstrates the issue. Is there anything else needed in addition to the sample and the build scans?

Thank you for looking into the issue, one annotation processor was not declared: com.google.auto.service. Pushed correction out.

@ishaigor can tell more how you fixed your issue? I have the same and upgrading auto-service didn't help.

Take a look at https://github.com/ishaigor/annotation-processor-sample/commit/d7645914b9f53a5f350c7098973f3554c48e75d8#diff-366f42343748f0d02147a45a53a2cf62 @radzio

I have multiple annotations in my project from lombok, slf4j, spring etc. And I created a new annotation and a processor for it. When I register this processor, all the other annotations start throwing compile errors. Is there anything specific I have to do to add to the existing list of processors.

@swathistudyblue You need to add the other processors as dependencies to the annotationProcessor configuration as well.

Upgrading auto-service didn't help for me as well. Fighting build system instead of doing useful work :(

Have the same issue, @oradkovsky  have you managed to fix it. PS. All files are generated and placed in the $buildDir/generated/sources/annotationProcessor/java/main even the Intelijia Idea see those generated java files, but still, when I try to extend my class with a generated one, gradle can not find it.


Comments highlighting / parsing

Hi,
The following issue occurs with neovim, i can't speak for other editors.
We have issues when using this form of comments <%       # Some comment %> instead of this form <%# Some comment %>
If we pass on the comment line every following lines are seens as a comment (See picture below)

We tried to tweak to the parser to handle this case by changing the _hash_comment function like so :
_hash_comment: ($) => seq(/<%[\s]*#/, prec.left(seq(repeat($._code), "%>"))),

Parsing tests do work fine with this function, even with changed cases to reflect the change but highlights one do not :
Error in query file "highlights.scm"
Caused by:
    Query error at 11:4. Invalid node type

We are willing to make a Pull request to change this behavior once it works we are just looking for some hints or direction to solve the problem.

I can't reproduce this in Helix so I think this may be an issue with the nvim-treesitter queries or the version of the parser it is using.
That error comes from this line in the queries: once _hash_comment no longer uses a literal "<%#" token, tree-sitter's query analysis will say that the <%# node is not a valid node type to query for.
I think that adding extra space at the beginning is not a robust fix though - I suspect that the same problem would happen if you had comments after code like <%= gettext(..) # comment %>.

The problem is clearly with nvim-treetsitter or i would think so ; I tried to use helix queries or even the one provided here, elixir code is simply not highlighted anymore.
I am gonna dig more and get more informations. Thank you for you input.
Paul-H

Is this related? Also on Neovim.

To me it is, the colorisation has various problem but nvim-treesitter uses its own set of queries and even some that are not here so... To be honest i don't know how to approach this right now and every attempts i have made have been unsuccessful.

The difference between <%# and <% # is how they are parsed: the first version is a HEEx comment, while the second version is a HEEx directive. HEEx directives allow for interpolation of arbitrary Elixir code into your HEEx code. In other words, <%# a comment %> is parsed and highlighted using just the HEEx grammar, while <% # a comment %> is parsed and highlighted using both the HEEx grammar and the Elixir grammar.
Each editor that uses tree-sitter defines its own set of captures and highlighting logic. Given this is not reproducible in Helix, I think this is an issue specific to nvim-treesitter and not with tree-sitter-heex itself.
@paulhenri I suggest opening an issue in nvim-treesitter as that is likely where the fix will have to be made.

As an aside, is it worth it to move to Helix for Phoenix development? Thanks.

I can't reproduce those highlighting bugs in Helix @SichangHe. I think that neovim might be behind on the version of this parser or there might be something odd happening with the injection queries.
I'm definitely biased since I work on Helix but I think it's a nice choice for working in an Elixir and/or Phoenix codebase. I believe it should be possible to highlight these snippets correctly in nvim too though.

I am also having this issue.
As a workaround, I currently use the following syntax for HEEx comments: <%!-- some comment --%>


thread panic at shutdown of short-lived executable

the following is printed to stderr sometimes when using reqwest in a short-lived program:
thread 'reqwest-internal-sync-core' panicked at 'cannot access stderr during shutdown', src/libcore/option.rs

I'm using reqwest 0.7.2 and Rust 1.19.0.
Still working on debugging, but I figured I'd file a ticket early just in case it was a known issue.

The application that triggers this makes a Client and makes a single HTTP request on it.
Tail of an instance that did print that error:
DEBUG:tokio_core::reactor: loop process - 1 events, Duration { secs: 0, nanos: 506264 }
DEBUG:tokio_core::reactor: loop poll - Duration { secs: 0, nanos: 16755 }
DEBUG:tokio_core::reactor: loop time - Instant { t:<PHONE_NUMBER>36544 }
DEBUG:tokio_core::reactor: consuming notification queue
DEBUG:tokio_core::reactor: scheduling direction for: 0
DEBUG:tokio_core::reactor: blocking
DEBUG:tokio_proto::streaming::pipeline::advanced: write in body done
INFO:hyper::http::response: Response::new "HTTP/1.1 200 OK"
DEBUG:hyper::http::response: Response::new headers=<redacted>
INFO:reqwest::async_impl::response: Response: '200 OK' for <redacted>
DEBUG:tokio_core::reactor: loop process - 2 events, Duration { secs: 0, nanos: 338098 }
DEBUG:tokio_core::reactor: loop poll - Duration { secs: 0, nanos: 15402 }
DEBUG:tokio_core::reactor: loop time - Instant { t:<PHONE_NUMBER>00694 }
DEBUG:tokio_core::reactor: loop process - 0 events, Duration { secs: 0, nanos: 15243 }
DEBUG:tokio_core::reactor: loop poll - Duration { secs: 0, nanos: 3037857 }
thread 'reqwest-internal-sync-core' panicked at 'cannot access stderr during shutdown', src/libcore/option.rs

Tail of an instance that did not print that error:
DEBUG:tokio_core::reactor: loop process - 1 events, Duration { secs: 0, nanos: 515224 }
DEBUG:tokio_core::reactor: loop poll - Duration { secs: 0, nanos: 16953 }
DEBUG:tokio_core::reactor: loop time - Instant { t:<PHONE_NUMBER>24022 }
DEBUG:tokio_core::reactor: consuming notification queue
DEBUG:tokio_core::reactor: scheduling direction for: 0
DEBUG:tokio_core::reactor: blocking
DEBUG:tokio_proto::streaming::pipeline::advanced: write in body done
INFO:hyper::http::response: Response::new "HTTP/1.1 200 OK"
DEBUG:hyper::http::response: Response::new headers=<redacted>
INFO:reqwest::async_impl::response: Response: '200 OK' for <redacted>
DEBUG:tokio_core::reactor: loop process - 2 events, Duration { secs: 0, nanos: 353304 }
DEBUG:tokio_core::reactor: loop poll - Duration { secs: 0, nanos: 14370 }
DEBUG:tokio_core::reactor: loop time - Instant { t:<PHONE_NUMBER>01683 }
DEBUG:tokio_core::reactor: loop process - 0 events, Duration { secs: 0, nanos: 13878 }
DEBUG:tokio_core::reactor: loop poll - Duration { secs: 0, nanos: 2578030 }
DEBUG:tokio_core::reactor: loop time - Instant { t:<PHONE_NUMBER>99080 }

It seems suspicious to me that Client doesn't join on the JoinHandle of its internal thread in its Drop...

Interesting. Do you drop the Client and Response immediately?

I put up a small reproducing example at https://github.com/Roguelazer/reqwest_panic_demo
If you build it an then run RUST_LOG=debug ./target/debug/reqwest_test then it will panic on exit some of the time.

My theory is that the background thread is trying to log (which, when using env_logger, writes to stderr), and since it's not joined on (it becomes a daemon thread when the Client is dropped), that log sometimes triggers this panic.
I still think that joining on the background thread when the Client is dropped is probably the correct thing to do (the client shouldn't really continue living in that background thread for all eternity, and I think it's better for responses to become unreadable after their client is dropped than for them to use a zombie thread). I'll push up a branch to demo what that might look like.

The thing is that you can clone the Client, so as to be able to send one to multiple threads. If one of those clones dropped, it shouldn't join on that executor thread.
Likewise, something like reqwest::get() will make a Client, get a Response, and return it. With the Client dropped, it shouldn't have joined on that child thread. A user could want to just read from the one response...
Does it only happen when you have RUST_LOG set? Once all of the internal senders have been dropped, that child thread should start to shutdown.

The example I did (#187) uses Arc::try_unwrap to only join when the last Client is being shut down. It's not quite correct (it'll deadlock if you drop a client while you still have an open response object that has a KeepCoreThreadAlive) in it.
It'll happen if you have //any// logger installed which isn't safe to use after main has finished.
Thinking about it overnight, here's another proposal: instead of passing around a Sender in the KeepCoreThreadAlive struct (used by responses to keep the background thread open), what if we just passed around an Arc<ClientHandle>. That way, when the last clone of that Arc was dropped, we would know that there were really no outstanding consumers and we could join on the background thread.

#188 implements that approach

This was fixed in #188, thanks!


Handle multi-factor authentication

When multi-authentication is enabled for a given user, this script fails with:
{ error: 'interaction_required',
  error_description: 'AADSTS50076: Due to a configuration change made by your administrator,
  or because you moved to a new location, you must use multi-factor authentication to access
  \'00000002-0000-0000-c000-000000000000\'...',
  error_codes: [ 50076 ],
  ...
}

Thanks for even looking into this back in the day. With Azure Active Directory authentication for Linux in preview (which handles MFA) this entire thing is not needed anymore. Thanks!

See also:

https://github.com/CyberNinjas/pam_aad
https://github.com/CyberNinjas/libnss_aad


Rework StripePy IO

Harmonize input-output operations performed on the .hdf5 generated by stripepy call.

Codecov Report
Attention: Patch coverage is 18.02575% with 191 lines in your changes missing coverage. Please review.

Project coverage is 18.09%. Comparing base (390fbe7) to head (43a13c8).

Files with missing lines
Patch %
Lines

src/stripepy/IO.py
24.67%
116 Missing :warning:

src/stripepy/stripepy.py
5.97%
63 Missing :warning:

src/stripepy/cli/call.py
0.00%
11 Missing :warning:

src/stripepy/utils/finders.py
0.00%
1 Missing :warning:

:exclamation:  There is a different number of reports uploaded between BASE (390fbe7) and HEAD (43a13c8). Click for more details.
HEAD has 28 uploads less than BASE

Flag
BASE (390fbe7)
HEAD (43a13c8)

tests
unit
python-3.9

tests
unit
python-3.12

tests
unit
python-3.10

tests
unit
python-3.11

tests
unit
python-3.13

tests
integration
python-3.11

tests
integration
python-3.13

tests
integration
python-3.10

tests
integration
python-3.9

tests
integration
python-3.12

Additional details and impacted files
@@             Coverage Diff             @@
##             main      #71       +/-   ##
===========================================
- Coverage   60.08%   18.09%   -42.00%
===========================================
  Files          17       17
  Lines        1591     1708      +117
===========================================
- Hits          956      309      -647
- Misses        635     1399      +764

Flag
Coverage Δ

[tests
integration
python-3.10](https://app.codecov.io/gh/paulsengroup/StripePy/pull/71/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=paulsengroup)

[tests
integration
python-3.11](https://app.codecov.io/gh/paulsengroup/StripePy/pull/71/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=paulsengroup)

[tests
integration
python-3.12](https://app.codecov.io/gh/paulsengroup/StripePy/pull/71/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=paulsengroup)

[tests
integration
python-3.13](https://app.codecov.io/gh/paulsengroup/StripePy/pull/71/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=paulsengroup)

[tests
integration
python-3.9](https://app.codecov.io/gh/paulsengroup/StripePy/pull/71/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=paulsengroup)

[tests
unit
python-3.10](https://app.codecov.io/gh/paulsengroup/StripePy/pull/71/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=paulsengroup)

[tests
unit
python-3.11](https://app.codecov.io/gh/paulsengroup/StripePy/pull/71/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=paulsengroup)

[tests
unit
python-3.12](https://app.codecov.io/gh/paulsengroup/StripePy/pull/71/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=paulsengroup)

[tests
unit
python-3.13](https://app.codecov.io/gh/paulsengroup/StripePy/pull/71/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=paulsengroup)

[tests
unit
python-3.9](https://app.codecov.io/gh/paulsengroup/StripePy/pull/71/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=paulsengroup)

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


add contributors

@all-contributors please add @donavon for infrastructure, tests, examples, examples, ideas, infra, maintenance, review, tool, test, and code

@allcontributors[bot] please add @crosscompile for ideas, review


Icestone doesn't do anything

According to the aether wiki, it originally froze water into ice that touches it (?)

There was a suggestion by @Dragonoidzero to have it apply freezing to adjacent enemies

With the new conditional system, this should be plausible as a 1.7 or 1.8 feature

Icestone has been removed entirely, closing


Table/TableRow should not be a shadow root

Shadow root indicates that node can be a parent for "regular" rich text content so it only makes sense for TableCellNode be a shadow root, while table and table row should be regular elements

1 failed
[chromium] › packages/lexical-playground/tests/e***e/Tables.spec.mjs:1463:3 › Tables › Insert column before (with selected cell with rowspan > 1)

Huh, very interesting 👀 I can help look into this tomorrow if you want

Will need more adjustments here, With this change you can forward delete table cell-by-cell, which breaks tables cell structure.


refactor!: used setters and getters for motorSpeed

Description
Removes setMotorSpeed and getMotorSpeed from RevoluteJoint, PrismaticJoint and WheelJoint in favour of dart's setters and getters.
The following snippet illustrates the API change.
joint.setMotorSpeed(2); // OLD
joint.motorSpeed = 2; // NEW

joint.getMotorSpeed(); // OLD
joint.motorSpeed; / NEW

Checklist

[X] The title of my PR starts with a Conventional Commit prefix (fix:, feat:, docs: etc).
[X] I have read the Contributor Guide and followed the process outlined for submitting PRs.
[X] I have updated/added tests for ALL new/updated/fixed functionality.
[X] I have updated/added relevant documentation in docs and added dartdoc comments with ///.
[ ] I have updated/added relevant examples in examples.

Breaking Change

[X] Yes, this is a breaking change.
[ ] No, this is not a breaking change.

Related Issues

@spydon , CI/CD seems to be failing. Updated #47 to fix this.


`on_headers_complete': Twitter::Error::Unauthorized

Hi Guys,
I'm using gem twitter, the REST part is working incredibly well
However coming to the Streaming part and calling for example users or sample
I get this error :
`on_headers_complete': Twitter::Error::Unauthorized
I have add a callback adress but nothing change.
Do you have any idea of what I can do ?
Thanks

+1

@ESSEC69
figured it out?


Is it possible to use repeaters outside Block Editor?

I'm a little confused about the usage of repeaters.
In the docs under the form fields section I see the following example:
<a17-fieldset title="Videos" id="videos" :open="true">
    @formField('repeater', ['type' => 'video'])
</a17-fieldset>

This seems to use the repeaters without the Block Editor, but I can't figure out how to make it work, where should video template stuff go? And would the content be saved on a specific column on the model's table?
Any help appreciated, Thanks.

Hi @amrnn,
Yes, the repeater could be used outside of the Block Editor. However, different from using it as a block, we have to create a module for it in this case.
Take the code snippet in your comment as example, let's assume you are working on an module named "Post", after declaring the formField in view, you will want to create a corresponding "video" module using the command php artisan twill:module videos, following the command line instructions to define the module routes and migrate the databases.
Next, what we are going to do is to define the one-to-many relationships between the original module[ex. Post] and repeater module [ex. Video]. Make a new migration to create an new column post_id in videos table, migrate it, declare the hasMany relationship in App\Models\Post:
    public function video()     {         return $this->hasMany(\App\Models\Video::class);     }
Now, go to the repository of the module which you are working on, in this case, maybe PostRepository.php, include the HanldeRepeater trait from A17\Twill\Repositories\Behaviors\HandleRepeaters, and override the afterSave and getFormField method with following:
    public function afterSave($object, $fields)     {         $this->updateRepeater($object, $fields, 'video', 'Video');         parent::afterSave($object, $fields);     }
    public function getFormFields($object)     {         $fields = parent::getFormFields($object);         $fields = $this->getFormFieldsForRepeater($object, $fields, 'video', 'Video');         return $fields;     }
Checkout more details about the custom form method in documentation
there still have some tricky parts I didn't addressed out here,  but the repeater as static content should be able to work. I would suggest to read the source code if you met problems while doing this, but let me know if you have further questions, I'm always happy to help!

Hey @yanhao-li, thanks for the instructions.
I was going to try digging into the source code since the docs seem to be missing some details but I wanted to make sure it was possible to achieve what I'm asking for first.
I will try to get this working now and see what I get, thanks again.

Hi I'm trying to create a repeater field as above, but store the data in a serialized field, rather than a related model?
I have the need for a repeater field (address lines), however the use case doesn't require a seperate table for the related data. I've managed to save the serialized data correctly in the DB using the prepareFieldsBeforeSave function in my repository, but I can't seem to format it correctly when loading the fields again to edit after save.
I'm currently using:
$fields['repeaters']['addressline'] = unserialize($object->address);
in the getFormFields function, but it doesnt work

Hi I'm trying to create a repeater field as above, but store the data in a serialized field, rather than a related model?

Any chance you can share this code ?

Hi @arkid I have it working as follows:
First set up casting for the field in your model which allows easily saving the array as json:
//Return JSON data as an array
protected $casts = [
	'address' => 'array'
];

The in your module repository to format the data for the form:
public function getFormFields($object) {
    if (isset($fields['address']) && !empty($fields['address'])) {
	$fields = $this->getJsonRepeater($fields, 'addressline', 'address');
    }
}

this is the getJsonRepeater function:
public function getJsonRepeater($fields, $repeaterName, $serializedData) {
		$repeater_items = $fields[$serializedData]; //JSON converted to array using $casts in Model
		$repeatersConfig = config('twill.block_editor.repeaters');

		foreach($repeater_items as $index => $repeater_item) {
			$id = $repeater_item['id'] ?? $index;

			$repeaters[] = [
                              'id' => $id,
                              'type' => $repeatersConfig[$repeaterName]['component'],
                              'title' => $repeatersConfig[$repeaterName]['title'],
			];

			$repeater_fields = array_except($repeater_item, ['id', 'medias', 'browsers', 'blocks']);

			foreach($repeater_fields as $index => $repeater_field) {
				$repeater_data[] = [
					'name' => 'blocks[' . $id . '][' . $index . ']',
					'value' => $repeater_field
				];
			}
		}

		$fields['repeaters'][$repeaterName] = $repeaters;
                 $fields['repeaterFields'][$repeaterName] = $repeater_data;
		return $fields;
}

Then when saving the data, use this function to assign the data from the repeater to the db field which gets json encoded by the casts functionality above:
public function prepareFieldsBeforeSave($object, $fields) {
        if (isset($fields['repeaters']['addressline'])) {
		$fields['address'] = $fields['repeaters']['addressline'];
	}

        return parent::prepareFieldsBeforeSave($object, $fields);
}

This might not work 100% for your use case but should point you in the right direction

Thanks for this @Riaan-ZA , the problem I have is confusion on how views need to be configured.  I have this setup in the view of the master module...
@section('fieldsets')
    <a17-fieldset title="Room Configuration" id="rates" :open="true">
        @formField('repeater', ['type' => 'rate'])
    </a17-fieldset>
@stop

And that makes the rates field appear fine, but when I click the add new row button it appears but its empty, just a blank space with no field inputs.
Where is the direction of the fields that appear inside the repeater?  In another view file and what is the naming/location convention for this?

Yes exactly @Riaan-ZA its this repeater block/view I haven't done as I don't know where it goes/what to call it.    To clarify, I am trying to create the repeater outside of the general block system although I understand it still needs to work with blocks somehow due to how Twill works.

@yanhao-li do you know if runnin the npm twill build command is actually required if you are only using a repeater outside of the full block infrastructure in your twill project ?   I'm somewhat confused about the requirement for this step.   It's clear I need to run the twill:blocks command after any changes to my blocks but on this npm command I'm not sure.  Do you have a second to clarify ?

Hey @arkid ,
That's correct, you have to run npm run twill-build after every time you made change to the Twill's admin UI assets, or you could easily using npm run twill-dev to watch the file changes and hot reload code automatically.

Regards to your questions,

I'm new to vue and I'm not really sure what this command and the npm one are doing so my running of these commands has been somewhat arbitrary.

php artisan twill:blocks is used for converting the blade block to Vue component.
npm run twill-build is used for compiling the Vue components we just generated.

As for the problem that you met, could you please check out the common error in documentation and make sure you did everything right?
Additional to that, I'm not sure which version of Twill are you using, but there is a known issue in 1.2.0 which may cause the same problem as you met, in that case, you will need to update the twill-copy-blocks in package.json to the following:
 "twill-copy-blocks": "npm run twill-clean-blocks && mkdir -p resources/assets/js/blocks/ && mkdir -p vendor/area17/twill/frontend/js/components/blocks/customs/ && cp -R resources/assets/js/blocks/* vendor/area17/twill/frontend/js/components/blocks/customs/."

Checkout the discussion here:
https://github.com/area17/twill/issues/151

Thanks so much for taking the time to clarify this clearly @yanhao-li ;)

How does the foreign key column get populated? I'm getting this error on save Field 'resource_container_id' doesn't have a default value  not sure what I'm missing, followed all the instructions here.

just incase anyone out there is as much of a goof as me, I forgot to add the foreignkey to my fillables on the repeater module


Upgrade to ts-morph.

I was getting some compilation errors with TypeScript 3.5.1 before I updated ts-simple-ast (ts-morph) version. Should it be done here perhaps?

Yes, i had this issue too. Please open a PR.


'People' list doesn't list self under 'Participants not in a room'

I was trying to use this just to confirm where I was on the platform. I would have expected to see myself listed or perhaps the label "Other participants (not in a room)" instead.

Jon fixed a bug today that might help with this.  Please comment here if you observe it again.

This is still happening, @jon-bell

(Crista was also active then...)

I did not do anything to fix this yet

This might have been fixed by Crista yesterday, but let's keep an eye out for it.

I no longer face this issue.


Polishing the API

I am working towards freezing the public API for a 1.0.x release. Some issues for discussion:

The Mount API currently accepts FUSE command line arguments. Perhaps this should be changed.
From @advanderveer:

The question would be if we want to present the reference C implementation to Go via this "lazy/high level" function? It makes a lot of assumptions about the environment and arguments, e.g the first argument must be the program name, and --options will output some help text here, It installs signal handlers etc.

There is currently no mechanism to request any of the capabilities advertised during fuse_operations::init. [FIXED - see SetCapCaseInsensitive and SetCapReaddirPlus. We can add more capabilities if desired.]

The fuse_operations::lock operation is not currently supported.

The FileSystemInterface.Getxattr method had a very clunky interface. This was streamlined in commit cf3eb1bb806b198cb07b00c16d328f3557230798.

Any other issues.

Commit f053f0474078692e930f38dd89d9287007171a5e adds SetCapCaseInsensitive and SetCapReaddirPlus methods to FileSystemHost. The same mechanism can be used to add additional fuse_operations::init capabilities if desired.

As far as my use in rclone is concerned I don't think you've left anything out of importance.  I can see CapCaseInsensitive being useful - thanks.
I like the fact that you've left the API very close the the C API and that kind of means that you've done your job!
Some gophers might be upset by the errc being integers and not a error type.  However I think you've made the right choice - you can't return a general purpose go error back to FUSE so why pretend that you can?  You'd just end up translating it to EIO and then having nowhere to log the error message.
However I think you should write a bit of docs explaining that errors are returned in the first int returned by the fs methods.  You've explained that these should be -fuse.Exxx errors which is good.  Not all gophers will be familiar with that style of C/kernel error return.
How do you implement ReaddirPlus in the fuse filesystem? I couldn't see any callback methods in  f053f04 ?
I haven't finished implementing cgofuse in rclone yet, but I can report the basic functionality is working (listing files, read and write) so :+1: from me!

How do you implement ReaddirPlus in the fuse filesystem? I couldn't see any callback methods in f053f04 ?

Normally FUSE only cares for the st_mode and st_ino fields of struct stat during a readdir. This is not documented in the high-level FUSE API, but it is documented in the low-level one.
[In fact in the high-level API the st_ino field is also ignored unless you use -ouse_ino from the command line.]
In FUSE 3.0 they added a "readdir-plus" capability. Unfortunately the way they added it is incompatible with the FUSE 2.x series which are in widespread use. Cgofuse is currently based on FUSE 2.8, so I could not just use the FUSE 3.0 "readdir-plus".
Readdir-plus is nice to have, but not essential on UNIX. After all readdir(3) which is the API that most programs use does not have any way of accessing informat
On Windows

I have yet to work with the actual file system interface but it is unclear to me why FileSystemHost.Mount() mount has to receive the os.Args of the calling program. Maybe it just requires documentation or maybe a type that specifically describes mount arguments instead of an opaque []string?

@advanderveer wrote:

I have yet to work with the actual file system interface but it is unclear to me why FileSystemHost.Mount() mount has to receive the os.Args of the calling program. Maybe it just requires documentation or maybe a type that specifically describes mount arguments instead of an opaque []string?

These are the actual command line arguments passed to the file system (perhaps augmented by the Mount caller). See this link for some quick documentation.
But I agree with you that this needs to be better documented or perhaps even improve the API itself.

Thanks for explaining that - that makes sense.

Thanks for the link! If I understand it correctly the Mount() delegates to the FUSE reference implementation on OSX/Linux which happens to have (according to the documentations) a "lazy" way of initializing the file system which we use: fuse_main.
The question would be if we want to present the reference C implementation to Go via this "lazy/high level" function? It makes a lot of assumptions about the environment and arguments, e.g the first argument must be the program name, and --options will output some help text here, It installs signal handlers etc.
A lower-level init function of the FUSE reference implementation may be more suitable but I'm not able to find it from the docs alone so maybe it doesn't exist.

@advanderveer wrote:

The question would be if we want to present the reference C implementation to Go via this "lazy/high level" function? It makes a lot of assumptions about the environment and arguments, e.g the first argument must be the program name, and --options will output some help text here, It installs signal handlers etc.

I agree with your assessment. Having a command line interface to Mount is not the best idea. I did struggle with that decision as well. Let me explain the reasons I chose this approach. I am happy to consider alternative interfaces.
The FUSE 2.x series does not have a clean interface into the FUSE loop.  For maximum flexibility one may want to rewrite fuse_loop, I have had to do this with a single-threaded but fully asynchronous file system that uses the lowlevel FUSE API.
Unfortunately rewriting fuse_main has certain drawbacks the most important of which is that it is not straight forward to do in a cross-platform way (and even harder to do from cgo as I found out when I briefly attempted this experiment).
So the easiest and most stable way to enter the FUSE loop is fuse_main (real symbol name fuse_main_real). Fuse_main accepts command line arguments and I had to find a way to work with them:
$GOPATH/bin/hellofs -h
usage: /home/billziss/Projects/go/bin/hellofs mountpoint [options]

general options:
    -o opt,[opt...]        mount options
    -h   --help            print help
    -V   --version         print version

FUSE options:
    -d   -o debug          enable debug output (implies -f)
    -f                     foreground operation
    -s                     disable multi-threaded operation
...

So I considered providing an interface such as:
func (*FileSystemHost) Mount(mountpoint string, opts []string) bool

Or even:
type FileSystemConfig struct {
    // ...
}
func (*FileSystemHost) Mount(mountpoint string, config *FileSystemConfig) bool

In the end I chose not to do this, because of the following reasons:

Most file systems actually benefit from the default command line handling in FUSE. It is quite powerful and allows setting a variety of options. I find it especially useful as a file system developer, because I can change the behavior of my file system dramatically just by adding/removing a few options (e.g. attr_timeout).

The file system would have to do its own command line parsing simply to fill the FileSystemConfig struct. Mount would then take the FileSystemConfig and create new FUSE specific command line arguments out of them. For most file systems this sounds like a lot of unnecessary work simply to create the illusion of a nicer interface into Mount. For the few that would benefit from hiding the default FUSE option handling, they can still do their own command line parsing and feed an unrelated command line to Mount.

A lower-level init function of the FUSE reference implementation may be more suitable but I'm not able to find it from the docs alone so maybe it doesn't exist.

Unfortunately it does not exit. We would have to write our own fuse_main_real or simulate it by rewriting command line arguments as discussed above.

NOTE: the signal handling as being "added" by libfuse under fuse_main() probably doesn't work for Go applications as one would expect: https://godoc.org/os/signal#hdr-Go_programs_that_use_cgo_or_SWIG

Good catch.

Windows: we have already discussed the implications in a different thread.
OSX/Linux: luckily the FUSE layer is smart enough to not set a signal handler if one already exists. So it should not touch any of the signals that Go cares about: fuse_signals.c

I wrote:

func (*FileSystemHost) Mount(mountpoint string, opts []string) bool

Actually this interface would simplify the Mount code, which currently has to extract the mount point in order to support Unmount. It would also resolve an issue with some of the help being printed twice when using the -h option.
Is it an interesting compromise or does it just feel artificial?

I think that no abstraction is better then a leaky abstraction. As you adequately wrote down there doesn't seem to be a suitable set of arguments we can offer in this layer that makes thing more clear. That is Ok, we will simply need to make sure what the Mount() and Unmount() does for the different implementations below. Something like this:
//Mount will ask the platform specific FUSE implementation to mount the file system. On Windows arguments are passed to WinFSP <Link to docs here>. On other platforms (Linux/OSX) the arguments are passed to the libfuse reference implementations: <link to docs here>.
func (*FileSystemHost) Mount(mountpoint string, opts []string) bool {...}

@advanderveer wrote:

//Mount will ask the platform specific FUSE implementation to mount the file system. On Windows > arguments are passed to WinFSP <Link to docs here>. On other platforms (Linux/OSX) the arguments are passed to the libfuse reference implementations: <link to docs here>.
func (*FileSystemHost) Mount(mountpoint string, opts []string) bool {...}

Agree on clarifying the documentation re: Mount.
Just to be clear: The Mount interface is currently:
func (*FileSystemHost) Mount(args []string) bool

Would you also prefer to have it changed to?
func (*FileSystemHost) Mount(mountpoint string, opts []string) bool

I am happy with such a change. @ncw since you have rclone cmount already working based on cgofuse, do you have an opinion?

Yes that sounds fine to me.

I like func (*FileSystemHost) Mount(mountpoint string, opts []string) bool as well

Thanks. I will see if I can get that change in tonight.

Commit 47171f33a7d75a211e7a36454ae28a4144819676 changes Mount as per our discussion. This is currently in the Mount branch, but I will merge into master tomorrow.
The Mount documentation follows.

func (*FileSystemHost) Mount
func (host *FileSystemHost) Mount(mountpoint string, opts []string) bool

Mount mounts a file system on the given mountpoint with the mount options in opts.
Many of the mount options in opts are specific to the underlying FUSE implementation. Some of the common options include:
-h   --help            print help
-V   --version         print FUSE version
-d   -o debug          enable FUSE debug output
-s                     disable multi-threaded operation

Please refer to the individual FUSE implementation documentation for additional options.
It is allowed for the mountpoint to be the empty string ("") in which case opts is assumed to contain the mountpoint. It is also allowed for opts to be nil, although in this case the mountpoint must be non-empty.
The file system is considered mounted only after its Init() method has been called and before its Destroy() method has been called.

BTW, the last wart that I would like to tackle is the fuse_operations::lock operation. I have punted on this, because most file systems are happy with the default kernel support and because WinFsp does not send kernel file lock requests to the user mode (it handles them entirely in kernel mode).
I think it is still worthwhile to fix this last wart in cgofuse. I will look at this later tonight and come back with a proposal. I am happy to hear yours of course too.

I spent some time looking at fuse_operations::lock and how to add it to cgofuse. I am going to punt on this at this time. The reasons are:

The fuse_operations::lock operation is currently only supported on Linux FUSE. OSXFUSE and WinFsp-FUSE do not support passing file locking operations to user mode (they satisfy them in kernel mode). [This means that file locking will work for processes on the same machine, but it will not work for processes on different machines.]

Recent versions of FUSE have also added fuse_operations::flock for BSD style locking. This further complicates matters.

Implementing file locking support correctly in cgofuse means that we would have to cater for the lock_owner field in fuse_file_info. This needs to be passed as an argument in a number of operations. The FUSE docs suggest that only fuse_operations::lock and fuse_operations::release need to worry about this field. From my experience with implementing locking support for WinFsp, I would expect that read and write operations also need to worry about locking. [NOTE: Linux FUSE may only support advisory locking which may explain why read, write are not mentioned.] Because of this uncertainty I am disinclined to change the current API in any significant way to accommodate functionality that only works in one platform.

Although I understand file locking and have implemented it at the kernel level in WinFsp I do not understand all the nuances about how it works on Linux FUSE. I therefore prefer to punt on this until someone more knowledgable on the subject comes along with information or a pull request.

So I am ready to freeze the cgofuse API. However I want to ensure that introducing locking into the API at a later stage would not be problematic. I believe it should not be for the following reasons:

Although I am new to Go it looks to me that the versioning issues with interfaces that exist on other platforms do not exist in Go, primarily because of the recompilation and static linking requirements. Therefore it should be easy to add a Lock method when the need arises.

If we need to pass the lock_owner field to operations like Release or Read or Write we can introduce a Getlockowner function that uses thread local storage to communicate this information to those file systems that care.

I think punting on lock is fine.  I can't think of a FUSE fs which uses that feature.

Although I am new to Go it looks to me that the versioning issues with interfaces that exist on other platforms do not exist in Go, primarily because of the recompilation and static linking requirements. Therefore it should be easy to add a Lock method when the need arises.

That is correct yes.

If we need to pass the lock_owner field to operations like Release or Read or Write we can introduce a Getlockowner function that uses thread local storage to communicate this information to those file systems that care.

Not sure how well Go deals with thread local storage.  It is probably OK in this specific case where you are calling back from a C thread and but in general go routines move around between threads in arbitrary ways.  There is always runtime.LockOSThread.
My understanding of how threading works with cgo is as follows

go calls C function - this must obviously stay on the same thread

the runtime marks this thread as locked
if it runs for too long the runtime starts a new thread

some time later C calls back to go

this must be in the same thread

I don't know whether if you did a time.Sleep() for instance in the goroutine called from C whether your goroutine could be rescheduled on a different thread - I doubt it as that would mess up the return to C

I think basically because everything is callbacks with cgofuse I think we don't have to worry about the thread local storage not working or call runtime.LockOSThread.

File locking on linux leaves a bitter taste for many (as you probably read) so I think it is already to skip this for now. As you indicate, one could always add something like a LockableFilesystem interface in the future, e.g:
type LockableFilesystemInterface interface{
       FileSystemInterface
       Lock(...)
       Release(...)
}

Thank you both for the feedback. I will tag cgofuse as v1.0 in a few minutes.
@ncw wrote:

Not sure how well Go deals with thread local storage. It is probably OK in this specific case where you are calling back from a C thread and but in general go routines move around between threads in arbitrary ways. There is always runtime.LockOSThread.

Thanks for this write up. It confirms my own understanding. I note that the current API already uses thread local storage (implicitly) in Getcontext (which uses fuse_get_context).
@advanderveer wrote:

File locking on linux leaves a bitter taste for many (as you probably read) so I think it is alright to skip this for now. As you indicate, one could always add something like a LockableFilesystem interface in the future.

Thanks for the Linux locking pointers and the LockableFilesystem suggestion. I do agree that POSIX locking is a mess and believe that Windows got this one right.

Cgofuse is tagged as v1.0 and all tests pass.
The API is now FROZEN. Breaking API changes will receive a major version update (2.0). Incremental API changes will receive a minor version update (1.x).

Hooray! :-)  Congratulations on a really good package.

@ncw thanks. Thanks for also showing me the Go way on multiple occasions :)


Invite @dyz2102 to write a blog about his ResumeHack chatbot thoughs

@dyz2102 is the founder of WonderCV.com, which is a fantastic tool for people to make their resume more professional.  They got 100,000 register users in 6 months without any promotion budget. Just a few days ago, they passed the Y Combination interview in California and get Y Combination Startup offer. I met him on Y Combination pre-meetup in Beijing and found he has joined in Wechaty Developers' Home in a very early period and trying to use chatbot to manage user resume in a convenient way.
So I'd like to invite him to share his resume chatbot thoughts, how he met wechaty and anything he would like to share about data growth and startup.
Thanks, @dyz2102 !

ping @dyz2102 ：）

Thanks for your post! Could you please cross-post it to the https://blog.chatie.io/, so that we can make it easier for the Wechaty developers?
You can read put your post in this repo _post folder and add a pull request, like this: https://github.com/Chatie/blog/blob/master/_posts/2018-07-12-wechaty-new-release-version-0.18.md
Thanks so much!

ping @dyz2102 ：）

ping @dyz2102

I'm going to close this issue because it had delayed too long.
Please let me know by leaving a reply if you want to write it and I would like to reopen it for you.

@dyz2102 You have already written a very good start of the article, and it will become a great blog post after you refine it and create your pull request!

kindly ping @dyz2102
Happy New Year 2021!
Could you please format your draft in the previous issue comment into a Pull Request so that we can publish your article on our blog website?

kindly ping @dyz2102
Happy New Year 2021!
Could you please format your draft in the previous issue comment into a Pull Request so that we can publish your article on our blog website?


Bug where the world flips and blocks disappear?

I keep running into a bug as soon as I run out of my spawn area where the world will flip and tiles will start disappearing completely and I fall into the void, can anyone help? I've tried restarting the game and the server itself, but nothing's worked so far.

Weird, I have never encountered such a thing before. Would it be possible to record some video footage of it when it occurs and send it here?

I could try to record something, yes, let me see what I can do.

There are a few other bugs that occur, like the world I'm in being the only one I can travel to and some textures being missing. Couldn't seem to record a video, but this is what happens.

I have actually experienced this before when I attempted to inject a DLL during runtime. No idea what exactly triggered it, though. I suppose one thing you could try is verifying Deepworld's game file integrity through Steam and see if perhaps any files are corrupted/modified and are causing issues. The logs you mentioned are harmless warnings and are unrelated, so don't worry about those.
As for your other issue, if your current world is the only one available then that is simply the only one that exists.

Alright, thanks, I'll try that. Thanks for your time!

No problem, let me know if your issue persists or if you have any others,

I ran the verification check and it found that 2 files were missing/corrupted, but it seems to be working now. Thanks again.

I should mention that one of those 2 repaired files is the patched Assembly-CSharp.dll which has now been undone by Steam.
Not an issue if you're only playing locally, but should you ever want to play on a non-local server then make sure to patch the client again.


Documentation Issue :

Please change code in Usage section to have it working
Currently it says fake.add_provider(MarketDataProvider())
it should be fake.add_provider(MarketDataProvider)

Fixed, thanks!


[Feature] Remove restriction on the number of records.

This PR removes restrictions on the number of records that can be defined in a program.
The current implementation allows users to define up to two records.

Opening this PR to start discussion on this change.
Is there anything else that needs to be done to support multiple records?


Non Loopback Port

Hello, I am having an issue using any IP other than <IP_ADDRESS>. When I use the IP of my local machine I do not get any response.  I also turned off all firewalls to check if that was the issue but that didn't help. I also am on subnet of <IP_ADDRESS> if that makes any difference. Lastly I also am using Postman to test the API if that is a problem
I used your static route test as a template the this is the only line I changed:
Server s = new Server("<IP_ADDRESS>", 8082, false, DefaultRoute);
Any clarity would be much appreciated!
Thank you for your time,
Ethan

Hi Ethan, a few questions for you.  1) are you running as a standard user or elevated/administrator?  2) are you running on Windows, Linux, or Mac?  3) are you using .NET Framework or .NET Core?  There should be zero issue with Postman or the subnet you've described.  The HTTP HOST header has to match whatever is defined in the Server as instantiated, so http://<IP_ADDRESS>:8082 should work.  Cheers, Joel

I am just running it as a standard user
Windows, .NET Framework
I also noticed the isListening is always false is there anything that could cause that?

I just checked if I launch the release .exe as administrator it will work! However I am curious as to why this limitation exists..


Lf menu

Added a menu, colors, and a material design theme as a starting point for the redesign.
Pull also includes updates to libraries to latest versions.
Will attempt to refactor SelectBuyFlowActivity to a more general template, but wanted to push this up as a starting point for review.

@lukefrancis any reason this is closed now?

@samtstern The pull request would have added the changes to Master, but we don't want to do that, since that would create an app breaking change.
I'll keep the lf-menu branch as a feature branch, and create pull requests for it.


Unslot fine tunes no longer work out of the box with GPT4ALL as of update 3.5 and 3.5.1 .... 3.4.2 still working.

Now, use the model-unsloth.gguf file or model-unsloth-Q4_K_M.gguf file in llama.cpp or a UI based system like GPT4All. You can install GPT4All by going here.
That statement as of GPT4ALL 3.5 and 3.5.1 is false.
Most models do not LOAD OR INFERENCE out of the box -- you need to make a new JINJA PROMPT for each model. No generic. And from what I can tell the Jinja prompt used by COLAB KAGGLE et all will not line up ... they have a non-standard dialect.
So yeah.
Could I suggest LMSTUDIO instead?

Now, use the model-unsloth.gguf file or model-unsloth-Q4_K_M.gguf file in llama.cpp or a UI based system like GPT4All. You can install GPT4All by going here.
That statement as of GPT4ALL 3.5 and 3.5.1 is false.
Most models do not LOAD OR INFERENCE out of the box -- you need to make a new JINJA PROMPT for each model. No generic. And from what I can tell the Jinja prompt used by COLAB KAGGLE et all will not line up ... they have a non-standard dialect.
So yeah.
Could I suggest LMSTUDIO instead?

So basically you're saying any model fine-tuned with Unsloth doesn't work with GPT4ALL anymore? Yes, could you try it with llama.cpp or lmstudio and see if it works? Thank you!

The DEFAULT TEMPLATE does not work with GPT4ALL 3.5-3.6+ ...
Yeah they work with OLLAM, LLSTUDIO and ANYTHINGLLM.  In fact they work with EVERY OTHER GUI except GPT4ALL 3.5-3.6 versions.
GPT4ALL is having issues getting THEIR OWN curated models to work with their new 'prompt templates'.
The ONE given by COLAB ... When you convert from LLM to GGUG and push to HG ... WILL NOT WORK by default. Something about a 'unique implementation' that is VERY UNDOCUMENTED: IDK ... I just know that 3.4.2 you drop the model into the 'model folder' ... it works.
3.5 + = it does not.
That has not changed with the newest update ... as of LAST NIGHT.
None of my side loaded models except a MISTRAL 3 Instruct will load or get a correct template -- if they do 'load' they INFERENCE like speed addicts ... NO prompt control at ALL.
Broke is the word.
USE LM STUDIO.

Now, use the model-unsloth.gguf file or model-unsloth-Q4_K_M.gguf file in llama.cpp or a UI based system like GPT4All. You can install GPT4All by going here.
That statement as of GPT4ALL 3.5 and 3.5.1 is false.
Most models do not LOAD OR INFERENCE out of the box -- you need to make a new JINJA PROMPT for each model. No generic. And from what I can tell the Jinja prompt used by COLAB KAGGLE et all will not line up ... they have a non-standard dialect.
So yeah.
Could I suggest LMSTUDIO instead?

So basically you're saying any model fine-tuned with Unsloth doesn't work with GPT4ALL anymore? Yes, could you try it with llama.cpp or lmstudio and see if it works? Thank you!

Not to be snarky -- but go download SAY DOLPHIN from Hartman .... Install 3.6.1 ... It won't work out of the box like it used to do.
And that is 99% of the side loads folk do will have this same result now.
It is not the MODELS it is a TEMPLATE ISSUE caused by GPT4ALL making a WILLFUL CHOICE.


Usupported config option 'db'

Hello,
I tried to compose the app on an Amazon Linux. I got the following error:
Unsupported config option for services service: 'db'
Are there any prerequisites that I missed?
Thanks

Hello,
Sorry. I was on the wrong docker-compose version.
Closed


Odd behavior with analysis 0.4.1

I’m having trouble getting a minimal repro for this issue.
Starting with this repo: https://github.com/ronglums/PyCon2019Booth then fix cell 10 to say “from sklearn.model_selection import  train_test_split”.

If I execute the first 6 code cells and then gather a slice for the 6th cell, only get one line of code: “del df[‘skin’]. Shouldn’t I get cells 1 & 2 as well?
If I execute to code cell 15 and then gather that, the code I get includes code cell 5 (“check(df)”), but otherwise seems good. In particular, cell 11 (which is just two print statements) isn’t included.
If I execute the rest of the notebook and gather the final cell (#27) I end up with the print-only cells that were not included in step 2.

If there’s an easier way to demonstrate this to you, let me know.

I noticed the existing extension doesn't allow the user to gather cells like in step #1 above. Perhaps we need to use the same criteria?

I see, for output you only allow gathering of output that has HTML. I don't think that's a necessary criteria though, is it?


Fixes incorrect links to API documentation

These are absolute links, so we need to remove the ".md" extension so they work properly.

PR passes checklist.


Attach JAR file to GitHub release

Would it be possible to attach the JAR file output by the build process to each corresponding release?
You provide great instructions for building the JAR on your own :) , but it would be easier to consume this plugin via automation if I could point to a public GitHub release to download the JAR. Below is a link to an example release on an example plugin that shows what I am talking about.
https://github.com/cvtienhoven/graylog-plugin-aggregates/releases/tag/2.4.0

@asmith60 I struggled a bit with Travis but now it should work as expected and you can download a jar from the releases page.


Draft new release after PR #1

Hello again,
Can you please draft a new release because of PR #1
Thanks!

Done, now it 0.5.0.
Also, i'm going to fully release it as v1.0.0 after some code review, very soon.

thanks!


Im not able to get the phone number.

Expected behaviour
Tell us what should happen.
Actual behaviour
Tell us what happens instead. Provide a log message if relevant
I'm seeing this behaviour on
Remove this hint: these checkboxes can be checked like this: [x]

[ ] iOS device
[ ] iOS simulator
[x] Android device
[ ] Android emulator

I am using

[x] cordova
[x] ionic
[ ] PhoneGap
[ ] PhoneGap Developer App
[ ] Intel XDK
[ ] Intel App Preview
[ ] Telerik
[ ] Other:

Hardware models
Example: Samsung Galaxy S6, iPhone 6s
OS versions
Example: Android 4.4.2, iOS 9.2
I've checked these

[x] It happens on a fresh Cordova CLI project as well.
[ ] I'm waiting for deviceready to fire.
[ ] My JavaScript has no errors (window.onerror catches nothing).
[ ] I'm using the latest cordova library, Android SDK, Xcode, etc.

So how can we reproduce this?
Provide the used components versions (cordova, ionic, etc).
Provide the steps to reproduce the issue.
Provide files, sources if available.

check #50


operator.KubeCuster support?

Hi!
When I try to use the new KubeCluster implementation (from the operator module and not the one from the classic module) as follow:
@flow(task_runner=DaskTaskRunner(
    cluster_class="dask_kubernetes.operator.kubecluster.kubecluster.KubeCluster"
))
def test_flow():
    ...

I got the following error:
03:16:41.206 | INFO    | prefect.engine - Created flow run 'mauve-tuna' for flow 'test-flow'
03:16:41.207 | INFO    | prefect.task_runner.dask - Creating a new Dask cluster with `dask_kubernetes.operator.kubecluster.kubecluster.KubeCluster`
03:17:24.025 | ERROR   | Flow run 'mauve-tuna' - Crash detected! Execution was interrupted by an unexpected exception.
Traceback (most recent call last):
  File "/home/john/projects/venv/lib/python3.8/site-packages/anyio/_core/_eventloop.py", line 70, in run
    return asynclib.run(func, *args, **backend_options)
  File "/home/john/projects/venv/lib/python3.8/site-packages/anyio/_backends/_asyncio.py", line 292, in run
    return native_run(wrapper(), debug=debug)
  File "/home/john/.pyenv/versions/3.8.13/lib/python3.8/asyncio/runners.py", line 44, in run
    return loop.run_until_complete(main)
  File "/home/john/.pyenv/versions/3.8.13/lib/python3.8/asyncio/base_events.py", line 616, in run_until_complete
    return future.result()
  File "/home/john/projects/venv/lib/python3.8/site-packages/anyio/_backends/_asyncio.py", line 287, in wrapper
    return await func(*args)
  File "/home/john/projects/venv/lib/python3.8/site-packages/prefect/client/orion.py", line 82, in with_injected_client
    return await fn(*args, **kwargs)
  File "/home/john/projects/venv/lib/python3.8/site-packages/prefect/engine.py", line 232, in create_then_begin_flow_run
    state = await begin_flow_run(
  File "/home/john/projects/venv/lib/python3.8/site-packages/prefect/engine.py", line 360, in begin_flow_run
    flow_run_context.task_runner = await stack.enter_async_context(
  File "/home/john/.pyenv/versions/3.8.13/lib/python3.8/contextlib.py", line 568, in enter_async_context
    result = await _cm_type.__aenter__(cm)
  File "/home/john/.pyenv/versions/3.8.13/lib/python3.8/contextlib.py", line 171, in __aenter__
    return await self.gen.__anext__()
  File "/home/john/projects/venv/lib/python3.8/site-packages/prefect/task_runners.py", line 166, in start
    self._started = False
  File "/home/john/.pyenv/versions/3.8.13/lib/python3.8/contextlib.py", line 679, in __aexit__
    raise exc_details[1]
  File "/home/john/.pyenv/versions/3.8.13/lib/python3.8/contextlib.py", line 662, in __aexit__
    cb_suppress = await cb(*exc_details)
  File "/home/john/projects/venv/lib/python3.8/site-packages/distributed/deploy/cluster.py", line 537, in __aexit__
    await f
  File "/home/john/projects/venv/lib/python3.8/site-packages/dask_kubernetes/operator/kubecluster/kubecluster.py", line 540, in _close
    await custom_objects_api.delete_namespaced_custom_object(
  File "/home/john/projects/venv/lib/python3.8/site-packages/kubernetes_asyncio/client/api_client.py", line 185, in __call_api
    response_data = await self.request(
  File "/home/john/projects/venv/lib/python3.8/site-packages/kubernetes_asyncio/client/rest.py", line 220, in DELETE
    return (await self.request("DELETE", url,
  File "/home/john/projects/venv/lib/python3.8/site-packages/kubernetes_asyncio/client/rest.py", line 177, in request
    r = await self.pool_manager.request(**args)
  File "/home/john/projects/venv/lib/python3.8/site-packages/aiohttp/client.py", line 508, in _request
    req = self._request_class(
  File "/home/john/projects/venv/lib/python3.8/site-packages/aiohttp/client_reqrep.py", line 305, in __init__
    self.update_host(url)
  File "/home/john/projects/venv/lib/python3.8/site-packages/aiohttp/client_reqrep.py", line 364, in update_host
    raise InvalidURL(url)
aiohttp.client_exceptions.InvalidURL: /apis/kubernetes.dask.org/v1/namespaces/prefect/daskclusters/dask-john-5d3b8ba4-4
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/home/john/projects/venv/lib/python3.8/site-packages/dask_kubernetes/operator/kubecluster/kubecluster.py", line 848, in reap_clusters
    loop = asyncio.get_event_loop()
  File "/home/john/.pyenv/versions/3.8.13/lib/python3.8/asyncio/events.py", line 639, in get_event_loop
    raise RuntimeError('There is no current event loop in thread %r.'
RuntimeError: There is no current event loop in thread 'MainThread'.

Process finished with exit code 1

It seems the DaskTaskRunner tries to close the cluster before starting it.
Is this new class supported yet by prefect? If yes, do you have a working example?

It seems to error on:
aiohttp.client_exceptions.InvalidURL: /apis/kubernetes.dask.org/v1/namespaces/prefect/daskclusters/dask-john-5d3b8ba4-4
Can you double check if this URL is valid?

Hi @ahuang11 ! Thanks for your response.
This URL is indeed invalid because it corresponds to the "future" dask cluster not created yet. The id here dask-john-5d3b8ba4-4 is different each flow run and no corresponding Dask cluster is created.
I did some tests and found out that this line is responsible for the close trigger because this error is raised:
Traceback (most recent call last):
  File "/home/john/projects/github.com/lunit-io/research-cs-data-pipeline/venv/lib/python3.8/site-packages/anyio/_core/_eventloop.py", line 70, in run
    return asynclib.run(func, *args, **backend_options)
  File "/home/john/projects/github.com/lunit-io/research-cs-data-pipeline/venv/lib/python3.8/site-packages/anyio/_backends/_asyncio.py", line 292, in run
    return native_run(wrapper(), debug=debug)
  File "/home/john/.pyenv/versions/3.8.13/lib/python3.8/asyncio/runners.py", line 44, in run
    return loop.run_until_complete(main)
  File "/home/john/.pyenv/versions/3.8.13/lib/python3.8/asyncio/base_events.py", line 616, in run_until_complete
    return future.result()
  File "/home/john/projects/github.com/lunit-io/research-cs-data-pipeline/venv/lib/python3.8/site-packages/anyio/_backends/_asyncio.py", line 287, in wrapper
    return await func(*args)
  File "/home/john/projects/github.com/lunit-io/research-cs-data-pipeline/venv/lib/python3.8/site-packages/prefect/client/orion.py", line 82, in with_injected_client
    return await fn(*args, **kwargs)
  File "/home/john/projects/github.com/lunit-io/research-cs-data-pipeline/venv/lib/python3.8/site-packages/prefect/engine.py", line 232, in create_then_begin_flow_run
    state = await begin_flow_run(
  File "/home/john/projects/github.com/lunit-io/research-cs-data-pipeline/venv/lib/python3.8/site-packages/prefect/engine.py", line 360, in begin_flow_run
    flow_run_context.task_runner = await stack.enter_async_context(
  File "/home/john/.pyenv/versions/3.8.13/lib/python3.8/contextlib.py", line 568, in enter_async_context
    result = await _cm_type.__aenter__(cm)
  File "/home/john/.pyenv/versions/3.8.13/lib/python3.8/contextlib.py", line 171, in __aenter__
    return await self.gen.__anext__()
  File "/home/john/projects/github.com/lunit-io/research-cs-data-pipeline/venv/lib/python3.8/site-packages/prefect/task_runners.py", line 161, in start
    await self._start(exit_stack)
  File "/home/john/projects/github.com/lunit-io/research-cs-data-pipeline/venv/lib/python3.8/site-packages/prefect_dask/task_runners.py", line 308, in _start
    raise e
  File "/home/john/projects/github.com/lunit-io/research-cs-data-pipeline/venv/lib/python3.8/site-packages/prefect_dask/task_runners.py", line 301, in _start
    self._client = await exit_stack.enter_async_context(
  File "/home/john/.pyenv/versions/3.8.13/lib/python3.8/contextlib.py", line 568, in enter_async_context
    result = await _cm_type.__aenter__(cm)
  File "/home/john/projects/github.com/lunit-io/research-cs-data-pipeline/venv/lib/python3.8/site-packages/distributed/client.py", line 1398, in __aenter__
    await self
  File "/home/john/projects/github.com/lunit-io/research-cs-data-pipeline/venv/lib/python3.8/site-packages/distributed/client.py", line 1213, in _start
    await self._ensure_connected(timeout=timeout)
  File "/home/john/projects/github.com/lunit-io/research-cs-data-pipeline/venv/lib/python3.8/site-packages/distributed/client.py", line 1276, in _ensure_connected
    comm = await connect(
  File "/home/john/projects/github.com/lunit-io/research-cs-data-pipeline/venv/lib/python3.8/site-packages/distributed/comm/core.py", line 291, in connect
    comm = await asyncio.wait_for(
  File "/home/john/.pyenv/versions/3.8.13/lib/python3.8/asyncio/tasks.py", line 494, in wait_for
    return fut.result()
  File "/home/john/projects/github.com/lunit-io/research-cs-data-pipeline/venv/lib/python3.8/site-packages/distributed/comm/tcp.py", line 487, in connect
    ip, port = parse_host_port(address)
  File "/home/john/projects/github.com/lunit-io/research-cs-data-pipeline/venv/lib/python3.8/site-packages/distributed/comm/addressing.py", line 95, in parse_host_port
    port = _default()
  File "/home/john/projects/github.com/lunit-io/research-cs-data-pipeline/venv/lib/python3.8/site-packages/distributed/comm/addressing.py", line 73, in _default
    raise ValueError(f"missing port number in address {address!r}")
ValueError: missing port number in address '<Not Connected>'

My guess is the cluster passed to the client is '<Not Connected>' because the _start method of operator.KubeCluster is not called somehow when this line is called in the DaskTaskRunner.
With classic.KubeCluster, the _start method is called before creating the client.

When I try this with self.cluster_class as operator.KubeCluster:
async with self.cluster_class(asynchronous=True, **self.cluster_kwargs) as cluster:
    print(cluster.status)
    print(cluster.scheduler_address)

It outputs:
Status.created
<Not Connected>

and the _start method is not called. It is called when using the classic.KubeCluster.
Maybe it's unrelated but the classic.KubeCluster inherits distributed.deploy.SpecCluster (the call to _start seems to be done in here) and the operator.KubeCluster inherits from distributed.deploy.Cluster.

Yes, it seems like it doesn't get started; only gets "created"
https://docs.dask.org/en/stable/_modules/distributed/deploy/cluster.html
    async def __aenter__(self):
        await self
        return self

Maybe you can call "dask_kubernetes.operator.kubecluster.kubecluster.KubeCluster" outside of Prefect, e.g.
cluster = dask_kubernetes.operator.kubecluster.kubecluster.KubeCluster()
cluster.start()

@flow(address=cluster)
...

If that worked for you, maybe we can add a warning about manually starting the cluster here under an if self._cluster.status != "started"

We can add a warning or call the _start method directly if the status is not running, what do you think?
I made it work with the following updates after this line:
from distributed.core import Status
import asyncio
...
            self._connect_to = self._cluster = await exit_stack.enter_async_context(
                self.cluster_class(asynchronous=True, **self.cluster_kwargs)
            )

            # If used with the operator implementation of KubeCluster, the cluster is not automatically started
            if self._cluster.status is not Status.running:
                await self._cluster._start()

            if self.adapt_kwargs:
                # Depending on the cluster type (Cluster or SpecCluster), adapt returns a future or not
                adapt_response = self._cluster.adapt(**self.adapt_kwargs)
                if asyncio.isfuture(adapt_response):
                    await adapt_response
...

Let me know if you want me to create a PR!

I think this could work, my only concern is that once this cluster is started, it won't be closed (unlike the async exit context), but I would appreciate a PR!

Actually I think they handle the cluster cleanup with this method.
The only problem is that, when used with prefect, we got the following error:
Traceback (most recent call last):
  File "/home/john/projects/venv/lib/python3.8/site-packages/dask_kubernetes/operator/kubecluster/kubecluster.py", line 845, in reap_clusters
    loop = asyncio.get_event_loop()
  File "/home/john/.pyenv/versions/3.8.13/lib/python3.8/asyncio/events.py", line 639, in get_event_loop
    raise RuntimeError('There is no current event loop in thread %r.'
RuntimeError: There is no current event loop in thread 'MainThread'.

It seems this line can't get the current event loop when used with prefect. If you have a workaround, I am all ears!
On a side note, their dask-kubernetes-operator pod already cleanup the clusters properly so it's maybe not necessary.

Can you provide an example of how reap_cluster is called? Is it called automatically or do we have to invoke it manually?

With the error

RuntimeError: There is no current event loop in thread 'MainThread'.

Where in Prefect's code is this code being called? We run several event loops and there is often one present.

Can you provide an example of how reap_cluster is called? Is it called automatically or do we have to invoke it manually?
Where in Prefect's code is this code being called? We run several event loops and there is often one present.

I think this reap_cluster method is not called directly by prefect or prefect_dask but instead automatically on-exit with the help of the @atexit.register annotation here. When debugging, the asyncio loop gets closed before reaching this code. Maybe the dask_kubernetes package should support closed loop?
I created a draft PR with the _start and adapt calls handled for theoperator.KubeCluster implementation. I still need to add tests and maybe warnings as suggested. With the example in the PR, the flow is executed properly on an ephemeral clustr with 1 worker and the cluster is cleaned up by the dask-kubernetes-operator pod but I obviously still hit the There is no current event loop in thread 'MainThread'. error.

That's awesome, TIL about the atexit decorator!
Thanks for making the PR too. Maybe we can wrap that logic you have and replace self.cluster_class under our custom contextmanager that handles closing and starting, e.g.
@asynccontextmanager
async def _cluster_start(self):
    cluster = self.cluster_class(asynchronous=True, **self.cluster_kwargs)
    # If used with the operator implementation of KubeCluster,
    # the cluster is not automatically started
    if self._cluster.status.value != "running":
        await self._cluster._start()
    if self.adapt_kwargs:
        # Depending on the cluster type (Cluster or SpecCluster),
        # adapt should or shouldn't be awaited
        adapt_response = self._cluster.adapt(**self.adapt_kwargs)
        if iscoroutine(adapt_response):
            await adapt_response
    yield cluster
    cluster.close()

Sure, I'll add it and add some tests.

Regarding the atexit issue — I've got an old open pull request in distributed to fix it https://github.com/dask/distributed/pull/5471


Adding changing widget interface option

Everything is said in the title. Thanks.

You mean this option?


Provide link to create discussion for those not wanting to grant permissions

As a alternative to #314 i was thinking if giscus could provide a “don’t login - just open discussion directly” here giscus would create the discussion if needed and redirect to GitHub avoiding need to grant giscus.app permissions.
Wdyt?

I'll consider it, but this should be an opt-in feature and probably configured from giscus.json rather than the <script> tag.

Makes sense to me!

I think this would be very helpful and opt-in is fine, as I feel like several people in this space might balk and step away at seeing the 'Act on your behalf' Github permission they have to give the app. I've added two concepts on how to possibly specify this below (an implementation would do one of the two, probably not both):

My favorite would be the "comment directly on Github" text within the testarea placeholder text to have a hyperlink to the Github discussion instead, but I didn't figure out how to add a link in the 5 minutes I spent making this. The additional button could also work, but I don't like it as much and think styling could be improved.

Just came here to +1 -- the permissions being requested ("Act on your behalf") are far too broad for a user to safely accept. Providing a deep link into the correct discussions on github.com would work great and meet needs for a large fraction of users.
My personal take is this should be on by default and opt-out -- or at least, if it isn't... I'd like to understand the reasons against.

Bumping this after trying giscus out. This seems like an odd issue to have because the exact demographic that isn't likely to want to use solutions like Disqus is not going to want to provide such far-reaching permissions as "act on your behalf" so they can comment on a blog post. Ideally, users could be given a link to comment directly on the discussion on GitHub rather than doing so via the blog page, thus bypassing the requirement to give any app permissions.


「取底除」might not work as expected

This simple test did not work as expected:
吾嘗觀「「算經」」之書。方悟「取底除」之義。
吾有二言。曰「「取底除 test: 」」。施「取底除」於四千於四。書之。
The generated function call might have failed:
取底除(4000)(4);
See no output from the online IDE (snippet site has the same result):

This might have caused a few functions in Li Fa failed?

Hi @kaiyuan01 ,
Sorry 取底除 is a new addition to the standard library that is not available on the online IDE yet. You can uncheck the box "Hide Imported Code" and see what is actually being imported.
I just rebuilt the site and now this function should work. However, there are still a couple of problems with your code:

Since you only specified one string literal after 吾有二言, it should be 吾有一言 instead.
Since 取底除 is an object, so you can't just print it like that. You'll have to print the 商 and 餘 fields separately, at least for now, until we implement a new printing mechanism.
Avoid using keywords in English when Chinese counterparts are readily available.

Thanks!

Still nothing came up.

@kaiyuan01 Your browser is caching the old page.
Here is a tutorial on how to clear cache for popular browsers: https://kb.iu.edu/d/ahic .
Thanks


Release Google.Cloud.Tasks.V2Beta3 version 3.0.0-beta02

Changes in this release:
New features

Enable REST transport in C# (commit 6ce3faf)

Created release for Google.Cloud.Tasks.V2Beta3-3.0.0-beta02


Add Mine Treasure

https://modrinth.com/datapack/mine-treasure

allows for more possible loot without having to expand the borders again

Additional/alternative sources of loot is nice, but given the description of the mod,

In Mine Treasure there are over 100+ custom items, as well as over 200+ advancements added to the game and many new ways to make every biome-type feel more special.

adding this much extra "loot" is a bit excessive of a change. Not to mention how a great deal of the custom items are "Super enchanted gear!" and potion effect sources. In general, it is balanced around the fact that "it is balanced because it is really rare," which isn't balanced at all. Not to mention the trigger for getting the loot is just mining stone-based blocks.
Here are some of the egregious examples

Better than Netherite gear.
Spawn Eggs, including: Iron Golems, Pillagers, Wither Skeletons
Spawners
Sculk Shriekers
Reinforced Deepslate
Infinite Fuel crafting stations (Smoker, Brewing stand, etc.)
Dragon Egg
Nether Star


Direct node to appropriate source location

Update package.json to reference the correct source file for  consumption. This is probably a holdover from a previous version of the module which did not include lodash functions in the result bundle.
Resolve #7.

Hey! This looks good to me :)
Can you add a commit and a git tag bumping the version in the package.json?
npm version minor should do it.

Version number is bumped, thanks @Couto!


Extra newline when copying line with 3-byte UTF-8 character on the edge

Windows Terminal version (or Windows build number)
10.0.19043.1348, 1.12.2931.0
Other Software
Ubuntu 21.04 in WSL
Steps to reproduce

Open tab with some WSL distro, shouldn't matter which.

Create python3 file with the following content:

import os
import sys
cols = os.get_terminal_size().columns
sys.stdout.buffer.write(b'a'*(cols-1))
sys.stdout.buffer.write(b'\xea\xb0\x9c')

Run it:

python3 1.py

Copy output with the mouse and paste to some editor.

Expected Behavior
There should be only single line of text.
Actual Behavior
There're two lines of text, see screenshots.

The problem doesn't appear if that 3-byte symbol is not on the edge of the line. Also 2-byte symbols work fine too.

Hmm. Doesn't repro in conhost. So this is probably a conpty wrapping bug. Probably related to #5800 in some way I don't fully know yet. Thanks for the minimal repro!

Doesn't repro in conhost.

For me, the line does wrap in conhost -- using WSL 1, Ubuntu 20.04, and Python 3.8.10. It doesn't matter whether it's written with separate calls, or all at once, e.g. _ = sys.stdout.buffer.write(b'a' * (cols - 1) + b'\xea\xb0\x9c'). GNOME Terminal in native Linux also wraps the line -- as it should, I think.
It's the same with the Windows version. Python 3.6+ uses io._WindowsConsoleIO for console files, which hard codes UTF-8 as the text encoding. Internally it uses the console's UTF-16 API (i.e. ReadConsoleW(), WriteConsoleW()).  The bytes string b'\xea\xb0\x9c' gets decoded as UTF-8 to U+AC1C (HANGUL SYLLABLE GAE). This character has [W]ide East Asian width, so normally it displays in two columns.
Isn't it up to the application to determine how many columns a line is likely to require, based on the width of each character? For example:
>>> from unicodedata import east_asian_width
>>> s = 'a' * 79 + '\uAC1C'
>>> sum({'F':2, 'W':2}.get(east_asian_width(c), 1) for c in s)
81

GNOME Terminal in native Linux also wraps the line -- as it should, I think.

The problem is not the line wrapping, it's the extra newline when I copy the output to the clipboard.
This problem doesn't happen with two-byte symbols, e.g.:
sys.stdout.buffer.write(b'a'*(cols-1))
sys.stdout.buffer.write('тест'.encode('utf-8'))

Works fine in this case too:
sys.stdout.buffer.write(b'a'*(cols-2))
sys.stdout.buffer.write(b'\xea\xb0\x9c')
sys.stdout.buffer.write(b'\xea\xb0\x9c')

It seems be related to the fact that there's only 1 column left on the current line but the character takes 2 columns.

The problem is not the line wrapping, it's the extra newline when I copy the output to the clipboard.

Sorry, I misunderstood that the problem was the newline itself in the output. I see now that it shouldn't be there and normally isn't, except when a wide glyph is wrapped at the edge.
To me, the following example more clearly emphasizes that the character is known to be a wide glyph that prints in two columns (hence dividing the column count by 2), and that it's expected to wrap in the terminal by one character. The bug is just that the terminal adds a line-feed (LF) character where it wraps the line for display.
>>> print('\uac1c' * (os.get_terminal_size().columns // 2 + 1))
개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개
개

The above output copied from the terminal should not have the LF before the last "개" character.
Now that I know what I'm looking for, I see that conhost in Windows 10 and 11 is also wrong, but in a different way. For example:
>>> print('\uac1c' * (os.get_terminal_size().columns // 2 + 1))
개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개개 개

That's an ASCII space (0x20) inserted where the line was wrapped for display. It's not present when the line wrap occurs on a single-column character.

Thanks for clarification, I modified issue's title accordingly.

I updated my last comment to use the same screen sizes in Windows Terminal and conhost, and also two show that the bug only occurs for me when the number of columns in the terminal is odd, which causes a wide glyph to straddle the edge.


Remove deprecated equals usage in ST_Equals

OGCGeometry#equals is deprecated in the latest ESRI library. We can use Equals method instead.
See: OGCGeometry#Equals

I think ST_Equals is the expected function (≠ ST_Contains).

Oops, I updated the title of PR. Thanks.

That's a mess. Please add quals(Object) and equals(OGCGeometry) to src/modernizer/violations.xml

@findepi Sorry, I'm not familiar with what Modernizer does. What should I add in violations.xml?

@findepi Please correct me if my example is wrong.
    <violation>
        <name>com/esri/core/geometry/ogc/OGCGeometry.equals:(Lcom/esri/core/geometry/ogc/OGCGeometry;)Z</name>
        <version>1.6</version>
        <comment>Prefer OGCGeometry.Equals(OGCGeometry)</comment>
    </violation>

    <violation>
        <name>com/esri/core/geometry/ogc/OGCGeometry.equals:(Ljava/lang/Object;)Z</name>
        <version>1.6</version>
        <comment>Prefer OGCGeometry.Equals(OGCGeometry)</comment>
    </violation>

[INFO] --- modernizer-maven-plugin:1.7.1:modernizer (modernizer) @ presto-geospatial ---
[ERROR] /presto/presto-geospatial/src/main/java/io/prestosql/plugin/geospatial/GeoFunctions.java:1273: Prefer OGCGeometry.Equals(OGCGeometry)

@ebyhr confirming


Text input field for survey questionnaire

Design text input field component to be used for survey

already done in designs done by @mattschabel @rejuvinatez
But isidoras version is here for ref: https://www.figma.com/file/g7Vh9sgZyXFABSUEwF5ujK/MyHealthConnect?node-id=830%3A1230&t=7pFnH21GkkBOBsjY-4