Add support for linting git commit message files

This makes possible to lint commit messages
Using gitlint project: https://github.com/jorisroovers/gitlint

Hello,
As I was not familiar to the ALE codebase neither to Vim script, I implemented gitlint integration based on flake8 linter, so maybe there is still some unnecessary code in this patches.
Let me know if there's something I should remove or rearrange..
Thanks

I think you can probably remove the parts of the code relating to running the linter with -m. That's mostly useful for flake8 for running it with different Python versions, which accept different syntax.
You can remove the version checking parts. Replace command_chain with command_callback and just the one callback instead.
You can remove the part which parses Python exceptions probably. That's needed for flake8 as it sometimes throws exceptions for syntax errors and such.
You can remove the old _args fallback, as this is a new linter.

Ok, done. :)
Thanks


Remove json tags from embedded structs

Implements the simpler option proposed in #11 (removing the json tag from the embedded struct, leaving the xml tag as-is) by tweaking the struct2go2.pl script and regenerating all relevant files within the sifxml directory.
Closes #11

Done my own mods instead, but thanks for getting this started!


[Build] Make sure we declare LINUX_STATIC dependencies on Musl.

Everywhere there's a SWIFT_MODULE_DEPENDS_LINUX Glibc, there should be a corresponding SWIFT_MODULE_DEPENDS_LINUX_STATIC Musl.
This usually won't bite us, depending on build order and parallelism, but I hit one of these yesterday so went looking to see if there were any others.
rdar://136208589

Explanation: There are missing dependencies that make the Swift Static SDK build unreliable (because sometimes it might try to build something without having built the Musl module yet, which results in strange errors about missing types or functions).
Risk: Basically none. These only affect the Static SDK build.
Original PR: #76542
Reviewed by: TBC
Resolves: rdar://136208589
Tests: PR testing should prove this doesn't affect anything else. Otherwise, the Static SDK build should be more reliable.

@swift-ci Please test


migrate away from System.[out|err]

Feature Request
Description of Problem:
Common Consensus is to not use the System.err or System.out features to log messages, but to use a logging mechanism of some kind.
When the codebase moves to use a GUI or some other front end, the use of a logger will make it easier to catch the output messages and redirect them.
This will also allow us to have debug log messages which can be turned off via a config file/command line switch.
Potential Solutions:
migrate to use slf4j as a logging abstraction layer and logback or log4j  as the logging backend.
Steps to implement:

[ ] add dependancies to pom.xml files
[ ] add logback.xml or log4j.xml configuration file
[ ] migrate System,err calls to logger.error calls
[ ] migrate System,out calls to logger.info or logger.debug calls
[ ] add command line switch to alter logging verbosity level

Acceptance Criteria:

[ ] no uses of System.out exist in the codebase
[ ] no uses of System.err exist in the codebase

Possible default logback.xml file and Logging.md
Logging.md.txt
logback.xml.txt

Whichever product is selected needs to match the license for this product. Log4j is under an Apache license, logback is under a LGPL license.
Log4j may be best as we are already covered by an Apache license.
We also need to check that any selected will work with java 1.8 without restriction or issue


License cleanup

@juliusv

Ooops, I'm sorry. I wanted to merge the client_ruby one. Wrong tab :(

Still :+1:


Add work-dir option + Allow to use the script standalone

Hey!
This PR fixes the work-dir option which seems just documented and it also allows to use the script as standalone by removing the script name from the args (otherwise the script name is used as command option).

Hmmm, in my case, this works either using standlone script or git command


Crash 1.20.1

1.20.1 server
fabric 0.15.1
Mod 2.0.0 beta 6
Crashed in the nether when looting my grave. items duped and the grave is still there when i come back to the server.
crash-2023-12-29_12.32.03-server.txt

Yeah I think it's the same as #138.

Yes. Just downgrade travelers backpack 1 version and it should work until I update

Thanks, ill downgrade for now.

It now works with latest version of travelers backpack on yigd 2.0.0-beta.7. Files has been pushed and approved on curseforge and modrinth alike


Gitter link needs to be fixed

Documentation Link
https://matplotlib.org/stable/index.html
Problem
The link to gitter is broken in the top banner, which I guess is outdated.
Suggested improvement
This link should be good: https://gitter.im/matplotlib/matplotlib
Originally posted by @stevezhang1999 in https://github.com/matplotlib/matplotlib/issues/26391

This was already fixed by #59; I must have not updated the venv when building the docs.

Actually, we seem to have some kind of inconsistency on the v3.7.x branch. It requires mpl-sphinx-theme~=3.7.0 and pydata-sphinx-theme~=0.12.0. However, mpl-sphinx-theme 3.7.1 (which has this fix) requires pydata-sphinx-theme~=0.13.0, so it can't be installed.

I pushed a direct fix to the docs repo. I'll just have to remember this for 3.7.3 if it happens. 3.8 should be fine since it's been updated to pydata-sphinx-theme~=0.13.0.


⚠ Bofrost.lu has degraded performance

In e230c55, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1740 ms

Resolved: Bofrost.lu performance has improved in 3a9d5b8 after 8 minutes.


How to get multi instances of mixitup on same page

Hi,
index.txt
I tried to set multiple instances of mixitup on the same page based on one of your demo (provided with multifilter extension). I can't manage to get it working. I understand that we have to use the scope in order to do that but it seems it does not works. How can I do that as I have to do it on my project ?
Thanks

I just get the following exemple (which could be in extension zip ;) https://demos.kunkalabs.com/mixitup/multiple-instances-local-control-scoping/
My controls where not in the container this is why the local scope was not working.


[FR] Headers collapsing and highlights

I want to say, this plugin is amazing! But for me it misses two features:

Allow collapsing of headers, because it is a lot of stuff under them;
Allow seeng highlights in outline, it would be extremely useful!

Thank you for your amazing job!

As for the folding of the heading, I would like to consider it, but it would be difficult to do so immediately due to the large amount of modifications that would be required.
One reason is that this plugin is based on Daily Note Outline that I created previously, and the outline elements (heading, link, list, tag) have a flat relationship. There are some UI issues to be considered, such as whether to add a heading collapse button in addition to the existing note collapse button.
As a workaround for now, I would like to implement a function to easily change the level of headings displayed.
It would be nice if highlights could be displayed! However, highlights are not kept as metadata (as far as I know), so it is needed to look up  the full text of all the files to be displayed. Therefore, I am concerned about performance issues. I would like to investigate whether this can be displayed at a realistic speed.
(If there is a plugin or core feature that looks up the highlight location and caches it, that information could be used to speed up the display. If you know of one, please let me know).

It is not a radical solution, but in v0.2.0 you can easily change the level of headings displayed by right-clicking on the H icon.
I hope you will give it a try.

could it be possible to add display specific heading level instead of the heading range in the quick setting of
right click the heading button， this is now in the pop-up setting panel

when we have a lot of tags or links under a certain heading, we tend to click on the space before the heading to hide those, but now it's not working

Thank you for your request!
With regard to heading level, can you give me a specific use for it, would it not work with a change in range?
I understand the need for heading folding. However, to do so would require significant program changes for the reasons I mentioned above, so please hold on for a while.


Relative problem paths don't take cwd into account

From https://github.com/Microsoft/vscode-cpptools/issues/2518
by @galgalesh
Type: LanguageService

Describe the bug

OS and Version: Ubuntu 18.04
VS Code Version:  1.27.1 5944e81f3c46a3938a82c701f96d7a59b074cfdc x64
C/C++ Extension Version: 0.18.1
Other extensions you installed (and if the issue persists after disabling them):
A clear and concise description of what the bug is.

The problemMatcher doesn't take the cwd of a task into account when resolving relative paths.
To Reproduce

Create a task and set the cwd of that task to a different path.
Expected behavior
The problemMatcher resolves relative paths as relative to cwd. If you set the cwd of a task, relative paths will most likely be relative to the cwd, not to the workspaceFolder.
Behavior I get
The problemMatcher resolves relative paths as relative to workspaceFolder
Following is the tasks.json for such a task. The line starting with  "fileLocation" shouldn't be neccisary.
        {
            "label": "build adfgxx",
            "type": "shell",
            "command": "ninja",
            "args": [
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "problemMatcher": {
                "base": "$gcc",
                // The next line shouldn't be needed since it is the same value as `cwd`
                "fileLocation" : ["relative", "${workspaceFolder}/builddir"]
            },
            "options": {
                "cwd": "${workspaceFolder}/builddir",
            }
        }

Additional context

I see the point. The problem is that the cwd in options is for the process we start and the cwd for the problem matcher the current cwd of the VS Code process. But I see that in this constellation it would make sense to treat the cwd the same. But it might be a breaking change since it will change the behavior for exist tasks if we change this. Need to change this with care.

Yup, just running into this as well for CDT's vscode extension. I'd be OK with a new variable of compat is a concern.

Got same problem here. Maybe we need another "cwd" for the problemMatcher specifically?


Fe homework 16

Metric
Value

alert_status
:white_check_mark: OK

bugs
1

code_smells
1

reliability_rating
B (at least 1 Minor Bug)Note: A being best, E being worst

security_rating
A (0 Vulnerabilities)Note: A being best, E being worst

vulnerabilities
0


Horizontal scroll

Nested headers might not work due to height being fixed to 100 but autoHeight enabled, this needs to be tested
Horizontal scroll is broken due to the fact its on comment and needs to be re-created for only scrollLeft
Main grid need to use the onScroll from horizontalScroll handler to detect if scrollLeft is changing also in there, we compare the values

@VeraRibeiro After scroll sync is this issue fixed?


Pydantic V1 support

Is your feature request related to a problem? Please describe.
First of all, I love this library, it's just SO cool!!
I would love to implement it in conjunction with the OS library I am helping to develop (https://github.com/mckinsey/vizro), which still uses Pydantic V1 for the near future...
Describe the solution you'd like
Instructor also work with Pydantic V1 base models
Describe alternatives you've considered
We should upgrade to V2, and eventually we will :) Just cannot do it just yet
I didn't check the source code on whether this is a crazy effort or even feasible, but thought I'd better ask :)!

Yeah, there's no way to go backwards. We use a lot of the newer features

@jxnl One more question that I am wondering: What would be other key differences of instructor vs e.g. using the langchain pydantic output parser.
The main difference visible to me is the retry capability, which can be maybe added to a langchain approach.
I am wondering e.g. what the additional features of V2 are that you are using. Would V2 also be more powerful to parse more complex nested outputs? Or would it be better at using OS models that do not reliable even return a valid JSON?
In our case, we are still thinking of whether it's easier to use langchain (as it support pydantic V1) or upgrade to pydantic V2 to make use of instructor.
Any quick notes would be much appreciated 🙏 !


Fix editor crash when stopping game with F8.

Fix: #37121
before the the while loop ends, the peer was unreferenced, which throws a nullptr access error

Thanks!


states_rebuilder sample

#171 add states_rebuilder sample.

Hey, thanks so much! Giving it a review now :)
Some things I see right off the bat:

Please add your app and yourself as a contributor to the root README and index.html file (the index file gets deployed to fluttersamples.com as a static site)
Please update the codecov and travis yaml files to include this project in the build matrices :)
Please trim down the README in your project a bit to only include high-level information and small code snippets for demonstration, but please avoid copy/pasting all the code into the readme -- it'll be a bit of a burden to maintain in the long run.

What do you think of it now?  It seems like it is ok, isn't it?
How to add the web version?

Yep, looks great! Unfortunately I need to configure the CI using the web interface to publish the web artifact, and I can't configure it using a yaml file, so I'll go ahead and do that.
One last change: could you please add the "web demo" link to the readme and index.html pointing to http://fas_states_rebuilder.codemagic.app/.

Actually looks like I might need to merge this into master before I can configure that setup in the UI! I'll go ahead and merge and add those bits in. Thanks again for the contribution :)

Unfortunately ran into a bug with the CI when it comes to deploying the web version. I've contact the CI company and they're working on a fix!


test(serial): assert output before code

Context: Some mysterious CI fail in the commit https://github.com/hermit-os/uhyve/commit/993b694facfb2866212e3b3f1eab86c45efa5ce1 despite a fix for the presumable cause (a file wasn't removed) here: https://github.com/hermit-os/uhyve/commit/0d9d0f24ba16019c25bd273d7c7218016b9a83b8


How to add additional data to payment request ?

Magento version: 1
Plugin version: 2.14.1
Description
I was using https://github.com/Adyen/adyen-magento/releases/tag/2.13.0.
I relied on :
https://github.com/Adyen/adyen-magento/blob/2.13.0/app/code/community/Adyen/Payment/Model/Adyen/Data/PaymentRequest.php#L312-L316
                // add observer to have option to overrule and or add request data
                Mage::dispatchEvent(
                    'adyen_payment_card_payment_request',
                    array('order' => $order, 'paymentMethod' => $paymentMethod, 'paymentRequest' => $this)
                );

to add additional data (such as riskdata.basket.item from https://docs.adyen.com/api-reference/payments-api/paymentrequest/paymentrequest-additionaldata#basket-content-fields) to be able to trigger risk rule on Adyen side.
I updated to https://github.com/Adyen/adyen-magento/releases/tag/2.14.1.
It seems that the event adyen_payment_card_payment_request is gone since 2.14.0.
https://github.com/Adyen/adyen-magento/pull/993/files#diff-9f51100419c8e5c7060aa2eb0295c381L308-R311
What can be used to perform the addition of additional data with 2.14.1 ?

Hey @aloupfor
I'm not very familiar with the Magento plugin codebase, but I believe you can achieve something similar by hooking into the adyen_payment_prepare_fields event, as found in the link: https://github.com/Adyen/adyen-magento/blob/f3b506c47a28c530dc4ed304f6fd0c947637a2fb/app/code/community/Adyen/Payment/Helper/Payment.php#L265-L271
I hope this helps, but let us know if you have more problems.
Cheers!
Marcos
Adyen

Hi,
Thank you for your help.
The event adyen_payment_prepare_fields is only triggered by HPP and PayByMail so I am not able to do what I aim which is add additional data for credit card payment.
I also sent a message to Adyen support. I told them :

For now, I rewrote Adyen_Payment_Model_Api pasted authorisePayment method in the custom class and added the data before the doRequestJson call here : https://github.com/Adyen/adyen-magento/blob/2.14.1/app/code/community/Adyen/Payment/Model/Api.php#L131
It looks like it is working (but I fear that it might broke if I need to update the module).

Indeed, it might break if you update the module. But we don't plan to release many updates again.
You will probably be safe by just stashing your changes, upgrading the plugin and unstashing after.
Cheers!
Marcos
Adyen

I'm closing this issue due to inactivity.
If you need more help, please open a new issue or contact<EMAIL_ADDRESS>Cheers!
Marcos
Adyen


RFC: integral support for C++ coroutines in the actor system

We need to make our code:

Easier to understand
As bug-free as possible
Serve requests fast on the hot path

Actors allow us to write thread-safe and fast scalable code (in theory), but hand-crafted state machines are error prone in practice. Developers have to write code upside down, which introduces logic errors, memory errors, etc. To maintain sanity intermediary layers (actors) are introduced, then instead of fast shared state lookups actor messages need to be exchanged, which is expensive and increases median latencies, interrupting the hot path multiple times along the way.
While C++ coroutines have atrociously high overhead (compared to normal function calls) they are still orders of magnitude less expensive than actor communication. Unfortunately making them work good with our actor system is not easy:

Previous ydb/library/actors/cppcoro attempt failed, because you had to opt-in into different actor types, such actors are too expensive, and it was an early attempt with a lot of mistakes. Nobody is using it, and shouldn't be using it. It's expensive without much benefit.
A coroactors side-project was a good experimental testbed, but it's again a different ecosystem without any practical uses for YDB.
We need a gradual intergal solution, which we could use sparingly where it makes the most sense.

Compared to fibers C++ coroutines have a disadvantage of function coloring (and co_await of nested calls can be expensive) and unfortunate heap allocations. Ideally we would want a suspendable thread/fiber per event handler (and some way to reuse them), but the stack overhead is huge (64kb is probably the minimum), which we would have to pay for every "live" activity. C++ coroutines allocate from the heap, but only the state which is needed, and hand-crafted state machine state isn't that much smaller anyway. Extra allocations are not a huge problem, since we currently allocate for every event anyway.
What I want is the ability to mark event handlers async, which would allow them to suspend and resume later on the same mailbox/actor when another event is received (or directly since events may often be unnecessary). I'm also a firm believer in structured concurrency, so unlike the current way where actor dies immediately after PassAway(), dropping everything on the floor, it should gracefully tear down all activities and wait until they complete. We would also need a way for these activities to fork/join (possibly even migrate between actors) in a safe way.
Some rough bullet points:

async<void> Handle(TEvSomeRequest::TPtr ev) marks an async handler, it should work with our normal state functions.
Spawn([&]() -> async<void> { ... }); should allow us to spawn new tasks in the current actor, this would basically allocate book-keeping information and start the coroutine body.
co_await WithLocalContinuation<T>([&](TLocalContinuation<T> c) { ... }); should allow coroutines to suspend themselves, resuming later in the same actor. Should be more efficient since it's single-threaded and probably wouldn't need to allocate.
co_await WithContinuation<T>([&](TContinuation<T> c) { ... }); should allow us to pass this continuation to a different actor/thread and resume from there, transparently moving execution back to the actor mailbox under the hood when necessary.
co_await WithTaskGroup<T>([&](TTaskGroup<T>& g) -> async<U> { ... }); should allow activities to fork/join. However since we target actors this could be single-threaded and a lot less heavy weight.
co_await WithActor(actorId, [&]() -> async<T> { ... }); should allow us to safely transfer execution to a different actor (on the same node), and wait for the result. Alternatively co_await TransferTo(actorId); might allow us to transfer until the end of the coroutine, but it might complicate things unnecessarily.
co_await AsyncSleep(...); should integrate with the scheduler, and support cancellation, cancelling underlying events.
async<T> would be a special marker type that cannot be copied or moved, and can only be used directly in co_await or as a value parameter in various functions, making reference arguments safe to use.
async<T> would only allow other async<U> and special blessed types to be awaited (arbitrary awaitables could be wrapped in some way which would make it returns safely, but I'm not sure it's necessary). A given coroutine will start execution in some actor, and will always stay within that actor.
When a new "task" starts it will be owned by some actor (or an event in transit), which will be responsible for destroying it safely. A challenge will be in handling task group forests that split across multiple actors, it would need to propagate cancellation and destroy tasks as they finally join at the root. This could be challenging, but possible. Necessary to handle destructor calls (actor system shutdown), as well as undeliverable transfers (we try to transfer, but the actor doesn't exist, we try to transfer back with an error, but it doesn't exist either).
We need to support cancellation, which could be made simple, since these coroutines are mostly single-threaded and actor based. We would need some signalling across transfers (including atomics, as event signalling is too slow). Notice how cancellation would need to propagate down the tree, each task may have downstream tasks, but they are never added concurrently, and the list of "subscribers" is immutable while the task is waiting. Cross-thread are thread-safe continuations and actor transfers, which are one-to-one links. This must greatly simplify everything, and we wouldn't pay for what we don't use.
The async<T> promise itself MUST be extremely bare-bones, it must always use symmetric transfers, with no conditions or complex logic. The promise would need to have an associated "task", but no state. The compiler must see all the relevant code and it must be as inlinable, optimizable and single-threaded as possible.
As I've seen in coroactors compilers have horrible bugs, but we use clang, and only need to make it work properly with clang.
We would probably need some micro-scheduler in the actor (some local intrusive run list), since many activities might want to activate concurrently, and we would want to reuse event allocations when possible.

Check list:

[ ] Write RFC
[ ] Remove current cppcoro code
[ ] Remove current "event callback" actors in favor of some special event handlers for all actors
[ ] Basic async<T> and local continuations (IActor should forward declare them, otherwise it must be opt-in)
[ ] Basic support for writing async<void> event handlers, i.e. our typical hFunc etc. should just work with them
[ ] Support for actor transfers, to be used in services when they cannot provide response immediately and need to synchronize
[ ] ...

Inspirational videos:

C++ Coroutines at Scale - Implementation Choices at Google - Aaron Jacobs - C++Now 2024
C++ Coroutines and Structured Concurrency in Practice - Dmitry Prokoptsev - CppCon 2024

Tests show that clang completely fails to optimize allocation for nested calls when using non-movable by-value async<T>: https://godbolt.org/z/79MKe1r9c
Probably because it somehow gets confused about lifetime guarantees. Taking it by an r-value reference and destroying in async<T>::~async "fixes" the issue, but the state function is not optimized.

Cancellation
It's important to recognize that cancellation usually implies the result of operation is no longer needed. While the result is not needed (and hence doesn't need to even be produced), from the structured concurrency perspective cancellation still needs to be awaited. Structured concurrency is needed for memory safety, i.e. when references to some memory are handed off to forks (which may or may not be used by different threads) we must await for these forks to finish before we (potentially) free the underlying memory. The memory here means "stack" variables, as well as the IActor instance where coroutine is running/suspended.
I envision two primary ways for tasks to be cancelled. The first is the root task (e.g. a request handler) may cancel itself because the request has been cancelled, which in turn cancels the whole tree rooted there. This is only true for root tasks spawned by the actor, however (either explicitly or implicitly by an async handler), and I'm not really sure how this would really work (except when actor dies). The second and the primary way of cancellation should be a task group. When the lambda passed to WithTaskGroup finishes it should cancel all of its downstream tasks, since their result is no longer awaited. Note that actor task groups will be purely single-threaded, so it implies cancelling their corresponding subtasks and awaiting for their destruction (will happen synchronously most of the time).
Normally cancelling a task is as simple as calling destroy() on its root std::coroutine_handle<>, as my experiments with coroactors have shown this is the only sane method of cleanup, ensuring stack unwind happens in the natural order (root coroutine starts unwinding its stack, which calls destroy() on the inner std::coroutine_handle<>, which starts unwinding its stack and so on). This will give the code a chance to cleanup via RAII, but will not execute any code involved in result production (remember, the result of a cancelled coroutine is no longer needed). This will also happen without exceptions, which is a big plus.
Tasks should have a way to clean up asynchronously however, for example when coroutines send a request to a different actor, and need to properly cancel that and return when that has also cleaned up. I think this could be accomplished using co_await WithAsyncFinally([&]() -> async<T> { /* main body */ }, [&]() -> async<void> { /* async cleanup */ }); for async cleanup (when we really need to make some additional requests and awaits on the cleanup path), and co_await WithAsyncCancel([&]() -> async<T> { /* main body */ }, [&]() { /* called when the task is cancelled */ });. I'm not sure which cancellation order would make the most sense (probably starting from the root and going downstream), but it would be called at most once, before the main body coroutine resumes. After cancellation callback is called the main body coroutine will never resume its normal execution, only cleanup will be possible.
The async cleanup coroutine code is chained after the main body, but wouldn't be affected by that main body cancellation. It may itself be cancelled however, e.g. when actor system shuts down and actors need to be destroyed. This async cleanup should be a rarely used feature however, it would be a mistake to base other features on that. A normal async call chain should wait until it is resumed, but when a cancelled coroutine is resumed is should unwind the stack instead.
A good example of cancellation should be with local continuations. Let's suppose a coroutine suspends on a local continuation, but it's cancelled, when should the stack unwind? The obvious answer should be no sooner than when that local continuation is resumed or abandoned, otherwise it would leave a dangling pointer to some unresumable coroutine. It may also be a good idea to combine local continuations and cancellation, i.e. the cancellation callback should just destroy a previously stashed local continuation object, this would (synchronously?) attempt to resume that coroutine with an error, which would in turn unwind the stack. Note, cancellation cannot happen while the coroutine is running, or while the local continuation callback is running, so there are no races.
An example of cancellation on resume is a proxy object pioneered by hudson-trading's corral. However, instead of ABI hacks it could be some form of allocation-free MakeCoroutineCallback<TCallback> (coroutines may override their operator new and operator delete) where its operator() can return std::coroutine_handle<> for symmetric transfer. Remember, stack unwinding may need to resume some upstream coroutines (async cleanup) which should avoid recursion when possible. This object should also be constrained to the local continuation awaiter, we don't want it to be part of regular coroutines.

Example of make_coroutine_callback that fully supports allocation elision (no need for custom allocator, as long as the lifetime is provable): https://godbolt.org/z/M19svc3xv

An important discovery, coroutine promises actually take reference to *this in their constructor: https://godbolt.org/z/xWv53PqrP
This is important, since it would allow making async handlers into eager start and eager destroy coroutines. They could then register in the constructor and unregister in the destructor. This would also allow restricting which methods are allowed to be async handlers, i.e. the first argument must be an actor, all other arguments must not be references, etc.

One more idea is that we might not need special callback coroutine for cancellation. Let's suppose the root is wrapped in a special coroutine that does co_await something or co_yield something (without anything else), and destroys the real root coroutine using RAII. In that case there's no difference between calling resume or destroy on this wrapper, and we may cause unwind by resuming this handle instead of the original handler.


Allow for html or markdown within configuration

Text fields that are configured within layers.json, specifically the legend text, should allow for basic formatting so that we can add hyperlinks, and stylize the text itself (bold, italic, etc).

A more ideal solution would be through the popup detailed here https://github.com/WFP-VAM/prism-frontend/issues/172


Support Content-Security-Policy without script-src 'unsafe-inline'

Summary
This PR removes inline scripts which trigger errors when using a CSP without script-src 'unsafe-inline'.
Fixes #5381
Proposed changes in this pull request
This PR does the following:

Converts inline data-carrying scripts (such as CMS.config) into JSON structures.
Modifies scripts to load data from JSON structures.
Moves inline logic scripts to script files, or removes them outright.
Misc minor changes to support the above.
Fixes an unrelated bug in toolbars.js that caused errors (CMS wasn't being imported).

Please note that this does not completely eliminate unsafe-inline from the CSP. Django-CMS uses an external script from jQuery called PEP.js which dynamically generates an inline script block, which violates a CSP without script-src 'unsafe-inline'. This could potentially be fixed in-place, as the script is already forked for a different reason.

There are also two places where the JSON is being built by hand in templates, which may lead to maintenance issues in the future:

cms/toolbar/toolbar_javascript.html
cms/toolbar/plugin.html

The structures should probably be built in the views and passed through json.dumps instead, but I felt it wasn't necessary for this PR.

Coverage remained the same at 79.653% when pulling c11ef35c990a2332b4d182652d1160e16fc84e2f on rspeed:remove-inline-scripts into 6f0cd2eb911fb8bdc12b890751833b650f5f455b on divio:develop.

Coverage remained the same at 79.653% when pulling 3d879b3abc398c86a6739378356abf4eb587eef7 on rspeed:remove-inline-scripts into 6f0cd2eb911fb8bdc12b890751833b650f5f455b on divio:develop.

@vxsx is this still relevant, could you have a look? @rspeed and thank you for the contribution. Would you be able to rebase to develop depending on @vxsx feedback?

still relevant, and looks good apart from conflicts

@rspeed would be great to get the conflicts resolved and we'll merge it into the next release :)

@rspeed we'd be happy to merge your work. Please resolve the conflicts against PR and open it again and I'll make sure someone gets it in. Thank you very much!


list indention style is different from pyyaml

consider the following pyyaml code (try yourself):
import yaml

print yaml.dump(
  {
    "foo": [1, 2, 3]
  },
  default_flow_style=False
)

which outputs
foo:
- 1
- 2
- 3

and the comparable js-yaml counterpart (try yourself):
const yaml = require("js-yaml");

console.log(
  yaml.safeDump({
    foo: [1, 2, 3]
  })
);

which outputs
foo:
  - 1
  - 2
  - 3

You can see that pyyaml doesn't add spaces to lists (because - counts as indention). I know both are valid, but it would be great if we could a similar output as pyyaml (especially as this project started as some kind of fork)?
Changing this line to
writeBlockSequence(state, level - 1, state.dump, compact);

changes the behaviour so it should be possible to add a configuration setting to allow both behaviours.

IMHO this request is specific and there are no big reasons to change output format or add an option. I tend to close it.

IMHO this request is specific and there are no big reasons to change output format or add an option. I tend to close it.

After doing a small evaluation I'm pretty sure most of (many) frameworks are doing what pyyaml does. And shouldn't this library tend to stick to what appears to be standard (i.e. not emitting additional, needless whitespaces)?

Probably, "most of frameworks" just are just binding to libyaml. There are no standard OR recommendations about better output look.
"needless whitespaces" is not good argument, because yaml is about readability, not about size optimizations

You request a breaking change without valuable profit (at least, i could not understand it) - i don't like such balance.

"industry convention" is marketing bullshit bingo slang. I'd suggest to focus on technical arguments instead.
What's wrong with "other libraries and software"?

I'd suggest to focus on technical arguments instead.

The technical argument is interoperability. Other tools make it different. It's absolutely fine to pick the current behaviour as a standard, but what's wrong with adding an optional setting, so the output can be reused with other libraries and platforms that decided to handle this case in a different way?

but what's wrong with adding an optional setting,

Adding "everything possible" make API messy very quickly. Current repo has conservative accept policy.

so the output can be reused with other libraries and platforms that decided to handle this case in a different way?

I'd like to understand, what's wrong right now? Output is valid yaml. Other yaml parser should accept it ok.

Adding "everything possible" make API messy very quickly.

And I do totally agree. But it's not that the proposal is completely messing with the output (let's configure an option to dump XML), but a different behaviour others have adopted.

I'd like to understand, what's wrong right now? Output is valid yaml. Other yaml parser should accept it ok.

My use case (and I can think of others): Some different tool chains work with a YAML content, and

detect changes when they are aren't any (because only whitespace has changed)
YAML files checked in a VCS like git will pollute the history with whitespace changes, complicating to work with actual changes (git blame will refer to whitespace- instead of content changes)

Ok, finally, i understand possible use case.
IMHO, your request is not about spaces, but about making output look like libyaml. Can you guarantee, that array spaces is the only difference? It would be strange to have later additional requests about new options for quotes etc.
From the other hand, wouldn't it be better to use native libyaml wrapper for your [specific?] needs? There are should be some.

I require this feature.
The yaml that yaml.safeDump is outputting does not let me set the array syntax to the space-less indentation method, causing there to be incorrect git diffs for a bunch of yamls that are being parsed, modified, and re-output using the tool.
It is not too much to request that there be an option for this functionality. Perhaps if I get some time, I'll submit a PR.

I agree with @puzrin though, in that:
This issue should be called "Cannot specify optional indentation of array elements", this issue shouldn't have anything to do with pyyaml.

I have a PR open here: #461

@thewilli @puzrin Now that #461 has landed, it's possible that we can close this issue?


Duplicate Images

I am trying to create a food dataset. However, when I try to scrape from Bing using this library, I am getting a lot of duplicate images. Please assist.
Thank you

My first attempt to filter out duplicates would be to subtract two possible duplicated images and check if the difference is close to zero.

I'm getting the same. Downloaded 10000 pictures and 9789 of them were duplicates. Is this a nature of Bing image search, or particular to this downloader?

When I scrape 100 photos, after the first 85 to 90 images, they start to repeat, and the rest are all duplicates.
When I scrape 500 photos, there also seem to be a lot of duplicates :( Other than this it works great, so I really hope this issue can get fixed.

When I scrape 100 photos, after the first 85 to 90 images, they start to repeat, and the rest are all duplicates.
When I scrape 500 photos, there also seem to be a lot of duplicates :( Other than this it works great, so I really hope this issue can get fixed.

Ya I also faced same issue it was due to how its programed i.e there is no next page in bing so instead first=pagecounter -> do first len of total url visited
also added ignore duplicates if same url is already visited
i will also pull the code or you can visit https://github.com/AbhiDhariwal/bing_image_downloader

I successfully avoided duplicated images with the following code. But now it will search forever.  So  yeah,
maybe we need a next button for more images.
`
self.duplicates = set()
def save_image(self, link, file_path):
    request = urllib.request.Request(link, None, self.headers)
    image = urllib.request.urlopen(request, timeout=self.timeout).read()

    if not imghdr.what(None, image) or image in self.duplicates:
        print('[Error]Invalid image, not saving {}\n'.format(link))
        raise
    else:
        self.duplicates.add(image)

    with open(file_path, 'wb') as f:
        f.write(image)

`

Remove duplicates PR#20

Bumping this as an issue. The fix above looks like it works and would be great if merged. Thanks!

Please close this issue


Fixed the employee count validation to show the errors and fixed limit

Only the latest year has limit of 2, it is otherwise 1
Also fixed errors, they weren't displaying before

:+1:


Revert "Integrate python-lint into validation tests"

Reverts apple/swift#8238

@swift-ci Please test

@hughbe Sorry, I will have to revert this PR due to test failure. Please see apple/swift#8238 for more detail.

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - dd9c81c9656b328cdafc08c7d9df12867be4c989
Test requested by - @shahmishal

Build failed
Jenkins build - Swift Test OS X Platform
Git Commit - dd9c81c9656b328cdafc08c7d9df12867be4c989
Test requested by - @shahmishal


Running on GPU - memory error

Hi there,
Have you run your workflow on GPUs? If so, could you share package versions and any code revisions?
We have tried on Titan X and Tesla K80 GPUs (both x4 GPUs). Unfortunately we get the following error:
F tensorflow/stream_executor/lib/statusor.cc:34] Attempting to fetch value instead of handling error Internal: failed initializing StreamExecutor for CUDA device ordinal 1: Internal: failed call to cuDevicePrimaryCtxRetain: CUDA_ERROR_OUT_OF_MEMORY: out of memory; total memory reported:

We have tried using tensorflow-gpu versions 2.0, 2.1, 2.2 & 2,4 via conda. We are also restricting TF memory allocation and allowing dynamic allocation - see code below.
import tensorflow as tf
#Limit initial GPU memory allocation
tf.config.gpu.set_per_process_memory_fraction(0.1)
#tf.compat.v1.GPUOptions(per_process_gpu_memory_fraction=0.4)
#Dynamic GPU memory allocation approach 1
cfg = tf.ConfigProto()
cfg.gpu_options.allow_growth = True
with tf.Session(config=cfg) as sess:
    train_k_folds(train_k_folds_config)

Any pointers would be appreciated.

Hi @SFrav,
We do typically run the code on a single GPU with 16GB RAM (on EC2 instances). Did you modify perhaps the batch_size in the config file? It should stay to 1 if I remember, otherwise it might try parallelizing over EOPatches.
I can provide you the versions of our working environment if needed.

We have tested and recently run this code successfully without any modification on TF 2.4 and newer, so should work for you as well.
Are you trying to train or run inference?
Both losses and metrics are initiliased in our training code here, so it might be something else. Could you try using only the accuracy metric and see if there is any difference?
For inference the metrics are computed separately, and the compilation can be left without arguments, as shown here.

@devisperessutti, this error occurs at the training stage.
I just tried excluding the mean IoU metric but it still gives the same error. We get this error using the Tesla K80. The original error is still thrown when using a Titan X.
Out of curiosity, what's the processing speed-up from using a GPU as opposed to CPUs?

This is the TF versions we are using
tensorflow                         2.6.2
tensorflow-addons                  0.14.0
tensorflow-estimator               2.6.0

on an NVIDIA T4 GPU with CUDA 10.1. I would give a try with this versions just for reference, although should work with other TF versions compatible with your GPU driver/CUDA version.
Did you perhaps modify the size of the patchlets? I would have thought you could fit more than one sample into 12GB of GPU RAM.
Comparison between CPU and GPU depends on GPU specs (number of flops), but I'd say roughly an order of magnitude faster. If you wanted to try on a couple of samples to test the code it is feasible to run on CPU though, but for training on large number of samples it would take a very long time.
Hope this helps.

Very helpful. Thank you.
No progress yet, but I'll keep experimenting and post again when it's working.


Fixes #161, some bugs with non-8000 port

Makes it so if you specify a different NEXT_BACKEND_GLOBAL_PORT in docker_up.sh, those changes carry through the appropriate places in the docker-compose.yml file.
One thing is to note is that one has to manually set the NEXT_BACKEND_GLOBAL_PORT environment variable when launching an experiment (still defaults to 8000), since presumably that it is in a new environment.  We could fix this by making a separate setup.sh or config.sh script that sets all the environment variables, which docker_up.sh and experiment_triplet.py, etc. could then source...

Hold off on merging this until we discuss #161...

We also need to hold off merging because of #154 in which we delete experiment_triplet.py and move to a new endpoint for initializing the examples.
From the files changed I can't tell what happens when NEXT_BACKEND_GLOBAL_PORT isn't defined in docker_up.sh. It looks like if the environment variable isn't defined the browser will try to render localhost:.

Right didn't think about that... if not defined in docker_up.sh, next.constants will still grab the default localhost:8000 but docker-compose.yml will be all effed up.

This is out of date and conflicts with #166. closing


Consider reverting the FunctionNaming defaults after 1.18.0-RC1

This PR removed the default ignoreAnnotated for the FunctionNaming: #3892
  FunctionNaming:
    active: true
    excludes: ['**/test/**', '**/androidTest/**', '**/commonTest/**', '**/jvmTest/**', '**/jsTest/**', '**/iosTest/**']
    functionPattern: '([a-z][a-zA-Z0-9]*)|(`.*`)'
    excludeClassPattern: '$^'
    ignoreOverridden: true
+   ignoreAnnotated: ['Composable']
-   ignoreAnnotated: []

This causes all our Compose functions to be reported for FunctionNaming. I would consider reverting this default configuration.
Since the PR was addressing the LongMethod rule, I am not sure why the FunctionNaming defaults were changed.

Since the PR was addressing the LongMethod rule, I am not sure why the FunctionNaming defaults were changed.

It feels like this slipped through the PR review. We had a discussion about similar values here #3894 but we haven't came to a conclusion yet.
Therefore I vote for reverting the line change you highlighted (feel free to open a PR 🙏 ).

I think we shouldn’t have such opinionated framework related defaults.

Therefore I vote for reverting the line change you highlighted

This didn't slip through the review. The change was done on purpose due to the fact that detekt should not have framework related defaults.

I think both perspectives are fine. I agree that detekt should not be too opinionated.
But then the changelog should inform the consumers about such changes/removals. Otherwise if you rely on buildUponDefaultConfig this can be frustrating.

Thanks for the feedback regarding the improvements in the changelog. We will take note.

This didn't slip through the review. The change was done on purpose due to the fact that detekt should not have framework related defaults.

Agree, but that specific line change was outside the scope of the mentioned PR.
If we agree on making Detekt more "framework-agnostic" then we should also cleanup those lines:
https://github.com/detekt/detekt/blob/2a9bbd0e2df302a6cf2005956c18939e4b53e80c/detekt-core/src/main/resources/default-detekt-config.yml#L634-L635
https://github.com/detekt/detekt/blob/2a9bbd0e2df302a6cf2005956c18939e4b53e80c/detekt-core/src/main/resources/default-detekt-config.yml#L727-L728
Plus do it in a separate PR so that it will be clear for users why we did this change.

If we agree on making Detekt more "framework-agnostic" then we should also cleanup those lines:

good catch!

I guess #3894 is a good place to discuss about this topic. It seems my "issue" is basically a changelog improvement (since I didn't knew about the move to more "framework-agnostic" defaults).
Will add my thoughts about this in the discussion.


Bug in datamanager Column class

Hi,
I have narrowed down an extra space on this line that causes the filter to not be created when using this to create or update views.

Thank you very much for your report. It's fixed now.


Show symbols only shows tags for current directory

When using Show symbols (multi) it seems as if the package only searches in tags for files in the current directory ie. in the directory where the file currently being shown in the editor is located. I had expected all tags within the project being searched.
I thought this might be due to a faulty ctags installation or incomplete .tags file, but as far as I can tell my .tags file contains data from the entire project.
Is this a design decision, known limitation or bug?

hmm, just made a test project, imported files, added an empty .tags file to the top of the project, and hit ctrl+t, ctrl+r
and the scanner walked the full project tree
maby adding module, info and install as php files under user file extensions will help ?

Well, since i know you're on OSX, are you using the ctags from OSX or installed from homebrew.
For my installation i need the ctags from homebrew and remove/rename the one build into OSX.

I'm using homebrew. I'm having trouble getting OSX to use the version under /usr/local/bin/ so I'm using the same approach as in #15. My ctags command is:
/usr/local/bin/ctags -R -f .tags --langmap=php:.engine.inc.module.theme.install.php  --php-kinds=cdfi
As menioned above, my .tags file contains tags for the entire project including PHP files with Drupalesque extensions but the CTags package only displays tags from the current folder.
Example
Given the following project structure:
dirA
 |- file1.php (contains function11() and function12())
 |- file2.inc (contains function 21() and function 22())
 |- dirB
    |- file3.php (contains function31() and function 32())
    |- file4.module (contains function41() and function 42())

If I'm editing file1.php and hit show symbols (multi) I'm shown function11(), function12(), function21() and function22().
If I'm editing file3.php and hit show symbols (multi) I'm shown function31(), function32(), function41() and function42().
In both these cases I'd expect to be shown all defined functions.


20200827 - meeting

Just an hour hanging out and talking about DAT stuff.
:point_right: Post a comment in this github issue with any topics you'd like to cover this week
:alarm_clock: Time: 27 Aug 2020, 18:00 GMT
:link: https://zoom.us/j/181036238 (Native)
:link: https://zoom.us/wc/join/181036238?pwd= (Web)

Timezone
Date/Time

Buenos Aires
27 Aug, 3 PM

Toronto
27 Aug, 2 PM

New York
27 Aug, 2 PM

Los Angeles
27 Aug, 11 AM

Berlin
27 Aug, 8 PM

Or in your local time: https://www.timeanddate.com/worldclock/fixedtime.html?msg=Dat+Comm-Comm+Meeting+2020-08-27&iso=20200827T18&p1=1440&ah=1

Update: @telamon is going to tell us about hyperdex 🎉 🆒

Hyperdomain status
Dat DNS (TXT record and /.well-known still valid?)
dat:// vs hyper:// switch-over progress (are both valid or just hyper?)
If I update a mounted hyperdrive while the main drive is offline, will the mount replicate the updates to other peers (I haven't tried this out yet, wondering if it works in theory


docs: Storage region should be specified

For those who select bucket region should describe region in the s3 api

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Sync with master will fix this.


fix gradient plugin for static prefixer

I've used the static prefixer for my project, and It works greate for most time right now, since my project is only running on mobile platforms. However the transformed result for gradient is not working, because the old vendor style is not quite the same as the standard writing.
So I found the plugin for gradient is just to add vendor prefixes to the given gradient values. The browser will not accept that, and the showing result is quit opposite for vendors version (See the test cases you'll know what I mean) and the standard version. So I add some converting including the direction change and the angle recalculation, and more test cases too.

Can you also fix that for the dynamic version? I'd like to keep both in sync and won't add different prefixing behavior just to one :P

Sure, I'll have a look into that : )

@MrRaindrop Is this something you're still going to help us with? Otherwise I will close the PR

Is this something that could be reopened and merged? There are several existing differences been static and dynamic versions of this library. If maintaining both is a burden, have you considered dropping the dynamic approach. It's not clear to me that there are any benefits to using it

Do we really need syntax compatibility fixes nowadays? If so Im more than happy to reopen and merge that, but it looks like a huge overhead to me.


兼容json字符串到对象的转换 并且会在序列化时输出json字符串

详情见JsonTest
使用只需在需要的字段上加上JSONString注解
目前只支持 集合和普通对象

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.scvzerng seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


CCM-5670: Add linting rules

Description

Adds linting rules
Disables linting rules where appropriate
Fixes npm audit vulnerabilities
Fixes linting errors

Context

Type of changes

[x] Refactoring (non-breaking change)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would change existing functionality)
[ ] Bug fix (non-breaking change which fixes an issue)

Checklist

[ ] I am familiar with the contributing guidelines
[x] I have followed the code style of the project
[ ] I have added tests to cover my changes
[ ] I have updated the documentation accordingly
[ ] This PR is a result of pair or mob programming

Sensitive Information Declaration
To ensure the utmost confidentiality and protect your and others privacy, we kindly ask you to NOT including PII (Personal Identifiable Information) / PID (Personal Identifiable Data) or any other sensitive data in this PR (Pull Request) and the codebase changes. We will remove any PR that do contain any sensitive information. We really appreciate your cooperation in this matter.

[x] I confirm that neither PII/PID nor sensitive data are included in this PR and the codebase changes.

I was going to approve but I don't have permission it seems


Add receive & send multipart API

Closes #55

Codecov Report

Merging #69 into master will decrease coverage by 9.25%.
The diff coverage is 16.66%.

@@             Coverage Diff             @@
##            master      #69      +/-   ##
===========================================
- Coverage   100.00%   90.74%   -9.26%
===========================================
  Files           22       23       +1
  Lines           98      108      +10
===========================================
  Hits            98       98
- Misses           0       10      +10

Flag
Coverage Δ

#unittests
90.74% <16.66%> (-9.26%)
:arrow_down:

Impacted Files
Coverage Δ

core/src/main/scala/io/fmq/frame/Frame.scala
0.00% <0.00%> (ø)

.../src/main/scala/io/fmq/socket/ConsumerSocket.scala
55.55% <0.00%> (-44.45%)
:arrow_down:

.../src/main/scala/io/fmq/socket/ProducerSocket.scala
57.14% <40.00%> (-42.86%)
:arrow_down:

Continue to review full report at Codecov.

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


Log closed connections without any response

What this PR does:
HTTP Server closes connections early if client fails to send complete HTTP Request within timeout. To help troubleshooting such attempts, this PR adds option -server.http-log-closed-connections-without-response-enabled, which enables logging of closed connections to HTTP server that received no response. First 512 bytes read from connection is also logged (while removing credentials from Authorization header).
Checklist

[x] Tests updated
[x] CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]

This makes sense, but I'm not sure how it would be used in a production environment.
Is the zero response listener something we would always enable or just turn on when we see that there's a lot of slow connections getting closed? For the second use case this makes a lot of sense since you typically don't get the user/tenant info at the gateway level and have to do backtracking via IP addresses at the LB.

I would propose to always enable it in environments where HTTP server is directly exposed to the internet (eg. when using AWS NLB), especially when also configuring shorter HTTP header read timeout. It could help us to make some type of currently-ignored connections more visible, and troubleshoot possible customer problems.


[Frontend] Add abort_request endpoint to OpenAI API server

This PR add an abort_request endpoint to the OpenAI API server. When building an application on top of this API, it is useful to be able to abort a request in order to avoid generating useless tokens if they are not needed anymore

 PR Checklist (Click to Expand)
Thank you for your contribution to vLLM! Before submitting the pull request, please ensure the PR meets the following criteria. This helps vLLM maintain the code quality and improve the efficiency of the review process.
PR Title and Classification
Only specific types of PRs will be reviewed. The PR title is prefixed appropriately to indicate the type of change. Please use one of the following:

[Bugfix] for bug fixes.
[CI/Build] for build or continuous integration improvements.
[Doc] for documentation fixes and improvements.
[Model] for adding a new model or improving an existing model. Model name should appear in the title.
[Frontend] For changes on the vLLM frontend (e.g., OpenAI API server, LLM class, etc.)
[Kernel] for changes affecting CUDA kernels or other compute kernels.
[Core] for changes in the core vLLM logic (e.g., LLMEngine, AsyncLLMEngine, Scheduler, etc.)
[Hardware][Vendor] for hardware-specific changes. Vendor name should appear in the prefix (e.g., [Hardware][AMD]).
[Misc] for PRs that do not fit the above categories. Please use this sparingly.

Note: If the PR spans more than one category, please include all relevant prefixes.
Code Quality
The PR need to meet the following code quality standards:

We adhere to Google Python style guide and Google C++ style guide.
Pass all linter checks. Please use format.sh to format your code.
The code need to be well-documented to ensure future contributors can easily understand the code.
Include sufficient tests to ensure the project to stay correct and robust. This includes both unit tests and integration tests.
Please add documentation to docs/source/ if the PR modifies the user-facing behaviors of vLLM. It helps vLLM user understand and utilize the new features or changes.

Notes for Large Changes
Please keep the changes as concise as possible. For major architectural changes (>500 LOC excluding kernel/data/config/test), we would expect a GitHub issue (RFC) discussing the technical design and justification. Otherwise, we will tag it with rfc-required and might not go through the PR.
What to Expect for the Reviews
The goal of the vLLM team is to be a transparent reviewing machine. We would like to make the review process transparent and efficient and make sure no contributor feel confused or frustrated. However, the vLLM team is small, so we need to prioritize some PRs over others. Here is what you can expect from the review process:

 After the PR is submitted, the PR will be assigned to a reviewer. Every reviewer will pick up the PRs based on their expertise and availability.
 After the PR is assigned, the reviewer will provide status update every 2-3 days. If the PR is not reviewed within 7 days, please feel free to ping the reviewer or the vLLM team.
 After the review, the reviewer will put an  action-required label on the PR if there are changes required. The contributor should address the comments and ping the reviewer to re-review the PR.
 Please respond to all comments within a reasonable time frame. If a comment isn't clear or you disagree with a suggestion, feel free to ask for clarification or discuss the suggestion.

Thank You
 Finally, thank you for taking the time to read these guidelines and for your interest in contributing to vLLM. Your contributions make vLLM a great tool for everyone!

does openai client has this api endpoint?

@gsolard requests are cancelled from the client side by closing the connection. This should abort processing of the corresponding request on the client side. It doesn't make sense to have an out-of-band endpoint for this.

This should abort processing

It turns out this wasn't always the case, have opened https://github.com/vllm-project/vllm/pull/7111 to fix this.


CLI: add FLYWAY_EXTRA_ARGS

Add environment variable FLYWAY_EXTRA_ARGS, need it to support SSL from CLI.
Close #2788.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

No need in this change, JAVA_ARGS works fine, see example in #2788.


shattered-pixel-dungeon: fix crash on startup

This also affects the shattered-pixel-dungeon variants/mods.
Fixes #273261
Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

@fgaz can this also be backported to nixos-unstable?

-unstable channels come directly from master, no need for backports. It will reach the channel as soon as it's unblocked.


Extend component controller tests

I'm also fixing the status update while I'm doing this.

https://github.com/open-component-model/ocm-k8s-toolkit/pull/31


Wrong filename with jet_taggers_hists()

When saving the jet tagger histograms with the jet_taggers_hists() helper function, the files are saved with a wrong label if the coll=JetGood is passed with name=None:
**jet_taggers_hists(coll="JetGood", fields=["btagDeepFlavB", "btagDeepFlavCvL", "btagDeepFlavCvB"], pos=0),
The output files are saved as:
None_btagDeepFlavB_1_2018_semilep.png
None_btagDeepFlavB_2_2018_semilep.png
None_btagDeepFlavB_3_2018_semilep.png
None_btagDeepFlavB_4_2018_semilep.png
None_btagDeepFlavB_5_2018_semilep.png

Expected behaviour: instead of "None", the "JetGood" collection name is expected to appear in the file name.

Solved in #261


Conditionals: Allow access to pipeline resources

Expected Behavior
Condition containers should have access to the resources themselves e.g a fileExists condition to check if a file exists in a git repo.
Additional Info
The resources that the condition needs have to be explicitly specified so that we do not needlessly initialize all resources for each condition check. Based on design in #27

/assign


timezones

This will fix #111 and #96 by adding a timezone field to promises. We will continue to automatically guess the timezone based on the IP the request comes from, but now it can be changed. Solidifying this concept makes showing the promise in the user's timezone much easier to reason about and implement.
Note: Eventually (?) the user will set a timezone in their profile, and all promises they create will default to that. Rules and hierarchy can get sorted out at that point, also.

Counterargument: Store all times as unixtime and then the Promise itself doesn't care about timezone. Chris is right that in the user table we may want a default timezone for better parsing of deadlines. And the Promise edit UI could possibly let you specify a timezone, but that's just in the UI and doesn't imply a timezone field in the Promise object. In the meantime it seems to work well to get this from the browser. Namely, the edit form for a Promise seems to get the timezone right.
I think the more immediate solution to the ugliness of showing times in US eastern is to just show countdowns instead of date/times. Or maybe that's silly since presumably it's not that hard to use the browser's timezone everywhere, but I might kinda like countdowns better anyway.

this is somewhat mitigated by https://github.com/beeminder/iwill/pull/153

aha, i just remember one of the reasons i had for wanted a promise to have a timezone... google calendar

@dreeves seems like the reasons i had for wanting to do this are all moot now, so i'm closing it


ci: increase docs deploy timeout

This PR configures a custom github actions to deploy github pages documentation, in order to increase timeout

Codecov Report
Base: 85.20% // Head: 85.20% // No change to project coverage :thumbsup:

Coverage data is based on head (5640e8c) compared to base (b18f5da).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #968   +/-   ##
=======================================
  Coverage   85.20%   85.20%
=======================================
  Files         155      155
  Lines        8050     8050
=======================================
  Hits         6859     6859
  Misses       1191     1191

Flag
Coverage Δ

docarray
85.20% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Fix ES indexing query skipping property groups

1. Why is this change necessary?
The ES property query relies on the order in which property groups are returned, property groups will be skipped if they are not returned in strictly ascending order.
2. What does this change do, exactly?
Explicitly sets the order.
6. Checklist

[ ] I have written tests and verified that they fail without my change
[X] I have squashed any insignificant commits
[ ] This change has comments for package types, values, functions, and non-obvious lines of code
[X] I have read the contribution requirements and fulfil them.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

thanks for your contribution @Nevay   👍🎉💙


Make mobile great again

New formatting for mobile view:

show code sections if they have a comment
show preview sections if they have a comment
hide sections with empty docs
show single column view for screen < 1024px
various formatting fixes for samples

This required changing lots of samples to add an empty comment
after the introduction. The intro is usually not associated to a
code blocks and otherwise the first html tags will be shown after
introduction.

Current version can be seen here.
@adewale @kul3r4 @juliantoledo PTAL
What doesn't work yet is showing code blocks spanning multiple separate tags, e.g.:
  <!--
    Import the libraries.
  -->
  <script async custom-element="amp-instagram" src="https://cdn.ampproject.org/v0/amp-instagram-0.1.js"></script>
  <script async custom-element="amp-vine" src="https://cdn.ampproject.org/v0/amp-vine-0.1.js"></script>
  <script async custom-element="amp-youtube" src="https://cdn.ampproject.org/v0/amp-youtube-0.1.js"></script>
  <script async custom-element="amp-vimeo" src="https://cdn.ampproject.org/v0/amp-vimeo-0.1.js"></script>
...

will only show the first line of the imports. In this case it would make more sense to show all imports.
    Import the libraries.
  <script async custom-element="amp-instagram" src="https://cdn.ampproject.org/v0/amp-instagram-0.1.js"></script>

To solve this we would need an explicit way to define doc comment spans :-/ , e.g.:
  <!--
    Import the libraries.
  -->
<!--BEGIN-->
  <script async custom-element="amp-instagram" src="https://cdn.ampproject.org/v0/amp-instagram-0.1.js"></script>
  <script async custom-element="amp-vine" src="https://cdn.ampproject.org/v0/amp-vine-0.1.js"></script>
  <script async custom-element="amp-youtube" src="https://cdn.ampproject.org/v0/amp-youtube-0.1.js"></script>
  <script async custom-element="amp-vimeo" src="https://cdn.ampproject.org/v0/amp-vimeo-0.1.js"></script>
<!--END-->

LGTM expect that I couldn't work out how to get a preview of the page without the code.

Hi, I was going through all the samples and  I noticed that https://amp-by-example-staging.appspot.com/advanced/long_list_of_amp-instagram_embeds/ does not work.

@adewale we haven't enabled the preview for all samples, IMO it only works well for more complex samples. The lack of consistency might be a problem though.
@kul3r4 good find. The algorithm doesn't cover this scenario. A preview is only shown for sections with a comment. This usually works well. Except for examples were the preview is important, but not the code as in this case. Any ideas how we could handle these?

Have been playing around with the mobile layout:

toolbar
FAB for Preview (does this make sense on desktop? )

What do you think?

I've created two new samples versions for desktop and mobile:

desktop
mobile

What do you think?

@kul3r4 @juliantoledo PTAL
I've updated the PR with a fix for the long list of instagram embeds. I solved it using a simple hack:
 <!--   -->
  <amp-instagram
      data-shortcode="BAb2gbSRJaM"
      width="1"
      height="1"
      layout="responsive">
  </amp-instagram>

The HTML space character makes sure that the code section + preview section is generated even if there is no doc. It's a hack, but I'd be fine with it as long as it stays an exception.
I've deployed this version to staging:
https://amp-by-example-staging.appspot.com/advanced/long_list_of_amp-instagram_embeds/

Please add a comment to the <!--   --> so that people know why it's there.
I'm, personally, not a fan of FABs especially on desktop where it's much harder to hit the target area. Can we find another solution?

Hi, thanks for fixing the example.
Regarding the preview button, what about rolling out to production and measuring via amp-analytics, if it gets clicked?

I don't see the toolbars, I guess that is still not in here.
I still find it a bit confusing on mobile and the white space makes the page too big. What about using MD cards?

I removed the header design changes from this PR and will create another one for them. This PR only fixes the content of the mobile site + adds a FAB for the preview for the mobile version.
@adewale I've added a comment for the hack (had to misuse metadata for this).
@juliantoledo which whitespace is too big? Where do you want to use cards?

The white space between the element and the code:
https://goo.gl/photos/fRyzk8mVUVb3odXa7
If it is not too difficult, we could group the code with the element it generates on a card. That would make clear which code belongs to what element.

It think it works good enough for most samples. The instagram one is an exception because the empty comment hack generates more whitespace - I don't see a way around that at the moment.
Putting both on cards is not trivial as they are contained in different div blocks.

LGTM
Cool, we can revisit later if we see the need somewhere else.

Thanks for the feedback everyone!


BuildAndStyleAChartWithSwiftChartsFramework: Value of type 'some ChartContent' has no member 'blendMode'

I was trying to follow the article that includes the below line of code.
Seems that it doesn’t compile with Xcode 14b5 :(
https://github.com/NilCoalescing/SwiftUI-Code-Examples/blob/be5ffae4f4e4df4c50f86e20bc79789225817ef4/BuildAndStyleAChartWithSwiftChartsFramework/SimpleBabyChart.swift#L43
I get:
Value of type 'some ChartContent' has no member 'blendMode'

I couldn’t find anything in the Xcode or iOS release notes about a change in this API.

@Brett-Best  thank you for spotting this. Looks like the api changed in the recent beta release, this can be resolved by moving the .bendMode modifier up inside the foregroundStyle so that it is now applied directly to the LinearGradient.
.foregroundStyle(
    LinearGradient(
       gradient: Gradient (
           colors: [
               .indigo.opacity(0.05),
               .purple.opacity(0.5)
            ]
       ),
       startPoint: .top,
       endPoint: .bottom
    ).blendMode(.darken)
)

Ah nice, wasn’t sure if that was producing the same result, thanks! 😊


wiki

Apologies if this is not the correct place to write this. I tried to set this project up as per the wiki. which I followed to the letter using two VMs, one for NC and one for LO. The NC side went without a problem, but the LO I cannot connect to. The wiki says that:
"The file loolwsd.xml in that directory is the main config file....
Edit it to your liking...."
Is it necessary to edit anything in this file straight out of the box? I cannot connect to the LibreOffice Online admin dashboard using an adapted form of the URL in the wiki (from another machine on the same network). http://<IP_ADDRESS>:9980/loleaflet/dist/admin/admin.html
I installed lynx on my VM and tried:
http://localhost:9980/loleaflet/dist/admin/admin.html
but no dice.
Is there something really obvious that I'm doing wrong? The message I'm getting in the browser is "<IP_ADDRESS> refused to connect." I tried setting SSL to false in the xml but this didn't help.
Last few lines of the docker log:
online_1  | wsd-00015-00016 2019-06-15 11:52:22.586204 [ prisoner_poll ] TRC  Poll completed with 0 live polls max (5000ms)(timedout)| ./net/Socket.hpp:521
online_1  | wsd-00015-00016 2019-06-15 11:52:22.586279 [ prisoner_poll ] TRC  Poll start| ./net/Socket.hpp:511

This is most peculiar. Further to my last post, I installed telnet on the same VM that hosts LO. When I try:
telnet localhost 9980
it says connection closed (immediately).
I looked at the iptables for a hint, but nothing obvious though I'm not an expert on this and there does seem to be a fair bit of dropping packets. It looks to my untrained eye that the docker has its own ip address (<IP_ADDRESS>) which I can ping from the VM but telnet fails to connect. As does lynx (both on the same VM)
I'm opening this issue because an out-of-the-box install fails to work. This could be me, or it could be a general problem... I would be very grateful for any help.

Can you provide your full logs (in a pastebin, or as attachment)?

Well, this is embarrassing(!) - although you'll be very happy to learn that the issue was of my own causing.
I was running both NC & LO in separate VMs which I clone from a debian9 (installed) image. Your suggestion about the logs made me think, so I found them and inspected them. One line that jumped out at me was 'out of memory' - and I realised the VMs only have 256MB each... I fixed that problem by upping the RAM to 2GB in LO. NC runs fine with 256MB. I am monitoring both in the VM manager so that the docker RAM figures are properly accounted for. LO tops out at 1674MB with a document open. However, this still didn't fix the problem so I had another look at the log - 'no space on volume' - the basic image only has 4GB. 8GB is the minimum I found that works for LO. Once I had those problems solved, it worked fine.
So I apologise for wasting your time.
However, I would make the following humble suggestion as tips for other experimenters: add resource requirements to the wiki:
NC disk 2GB / RAM 256MB min
LO disk 8GB / RAM 2GB min
Thanks.

Good to hear you solved it :)

However, I would make the following humble suggestion as tips for other experimenters: add resource requirements to the wiki

Good idea, could you maybe add that to README.md via a pull request?


Update signed private key to support proofs

I would prefer to convert this into a oneof, but I can't confirm with certainty that this will work across all languages. I need to use the generate method of SignedPrivateKey to create send keys, for now I'll modify that method to serialize in both formats.

Can you explain the necessity of this change in more detail?

but I can't confirm with certainty that this will work across all languages.

Which languages are there concerns around? What is the source of the potential incompatibility?

SignedPrivateKeys are not in in the SDK's at this time. Does this change how the problem should be approached at all?

Do we need to change SignedPrivateKey at all or can we create a new SendKey type? For backwards compatibility (V3 -> V2), we can just take the SendKey's SignedPublicKeyV2 fields and massage them into a SignedPublicKey. The constructed SignedPublicKey can be used in message headers, invites, etc

There's already a good amount of duplication between SignedPrivateKey and PrivateKey.
There is currently this nice mapping between protos and typescript classes right now, one Typescript class to implement one proto message. A change like this kind of commits us to shoving all SendKey private key logic into SignedPrivateKey going forward. It'll live side by side with all the old code. Not necessarily a bad approach but things could get messy versus a completely separate class.
From what I'm reading we need generate to create new SendKey private material. The problem is that this returns a SignedPrivateKey (old) type with an old SignedPublicKey? One approach is to have a SendKeyPrivate class that extends SignedPrivateKey and just wraps generate and does some shuffling to create a SignedPublicKeyV2 from the SignedPublicKey.

I can see them here: https://github.com/xmtp/xmtp-js/blob/8cae820b247a2bf7663c277c2d3a2e03f02493b4/src/crypto/PrivateKey.ts#L28.

I should have been more precise. No clients are generating SignedPrivateKeyBundles, and to my knowledge they are not persisted on the network at all. This is the last step of the SignedKey migration path is to enable users to generate these keyTypes. From a lens of backwards compatibility, I'm not sure the existing keyType needs to be supported.

I don't think there is anything different about a send key private key compared to any other private key.

Once full deployed SendKeyBundles cannot be used where SignedPrivateKeyBundles can. So having some ability for clients to discern between them will be needed -- thought its can occur during key discovery via topics

Dumb question: why can't SendKey be serialized with an AssociationProof if there isn't a SignedPublicKeyV2 in the SignedPrivateKey? I know you have a link I just can't find it off the top of my head.
I think this confusion is why I'm trying to push for having new types for anything related to the SendKey effort as much as possible. If we need to worry about legacy, we can just stick those bytes from the new protos into the old format

Where in the flow are sendKey-PrivateKeys being serialized? My understanding was that SendKeys were largely ephemeral.
If they are not materialized and the intention is to convert the Public and private components into the legacy types if needed. I'm confused as to why there is a need for changes to the stored PrivateKey.

I don't think I fully understand the coupling. Could you give the me the TL;DR again? Basically, gotta disprove my current thinking which is:
[v2 clients] (could be locked today) <--- conversion code ---> [v3 clients, with all new proto types for signedpublic and signedprivate keys]


nixbox 18.09 not on Vagrant Cloud

see here: https://app.vagrantup.com/nixos

I ran into this as well, after using the instructions in the README, specifically: vagrant init nixos/nixos-18.09-x86_64 then vagrant up.
The solution, for now, seems to be to downgrade to one that is available: nixos/nixos-18.03-x86_64

The main reason is that Hashicorp has stopped offering CI builders and other CIs don't support VirtualBox. On top of that I don't have VirtualBox installed on my system anymore.

Does anyone know of a CI that offers support for VirtualBox?

@zimbatm I have VirtualBox installed on my system, and I wouldn't mind supporting this effort for future versions of NixOS as well.
Let me know what's involved in publishing these images to the https://app.vagrantup.com/nixos repo.

Thanks for the offer @gurjeet. The best way forward would be to generate the images using Nix instead. Once that is done it will be possible to push them using the CI directly.
The image would include the vagrant.nix nixos module and output a vmdk file, which is then wrapped in a .tar.gz with the metadata packed with it. The package format is described over here: https://www.vagrantup.com/docs/boxes/format.html

I just made a PR, hopefully it will be a bit clearer: https://github.com/nix-community/nixos-generators/pull/22
If that works, then we can deprecate this project and then create a new one to periodically publish the Vagrant boxes

@zimbatm I'm new to NixOS in general, and haven't used nix-generators before. How should I test your patch to that repo.
I am on macOS 10.13.6, and have nix(-darwin) installed. I have cloned the nixis-generators repo, and in that directory executing./nixos-generate --list shows vagrant as one of the formats.
The next step is to provide a configuration.nix to specify the NixOS derivation I need. I don't see a suitable one on my macOS. Can you please suggest which one I should use.

Yes that's a good start.
The principle for testing would be to run ./nixos-generate -f vagrant, get the .box image and try to start it with vagrant somehow (I think vagrant import is needed to import the box). This will fail because the format is probably wrong.
Once you have that test phase working, download one of the original .box files, unpack it with tar and look at the differences. The metadata file needs to be completed, the .ova file name needs to be fixed I guess. Then open formats/vagrant.nix and fix the build instructions to match that.
If that's too much low-level for you, ping me on IRC and I can walk you through it a bit more.

@zimbatm serait-il possible d'enlever le postprocessor "vagrant-cloud" des fichiers json puisqu'apparemment cela ne sert plus à rien ? Si ok je peux pousser un tel changement.

sounds good @PierreR

fixed in dfc1beca4bef917756f2c9f2a7a7a4abdfbcfa47

@zimbatm you also want to remove the vagrant box post-processors ? It was useful for me to create a vagrant box compatible with virtualbox.
FWIW I don't use this post-processors with vmware because AFAIK there is no good free vagrant plugin for vmware.

The project is about creating vagrant boxes and adds all the cruft necessary for that to work like the vagrant users, a bunch of system packages... If all you want is to generate a VM image then it's probably better to use the nixos-generators project.

The project is about creating vagrant boxes

I was just trying to point it out that dfc1bec is removing the creation of such a box

woops, reverted. I don't see the vagrant-cloud post-processor

The command you suggested fails with the following error. I had a look at the patch before running the command, and the contents of formats/vagrant.nix seem to imply that the nixos-generate command needs to be executed on a Linux system.
$ ./nixos-generate -f vagrant
error: assertion failed at /nix/store/v6aja9ar864688529ayznix8mvv3ih10-nixpkgs-19.09pre184256.5b7e3718ee3/nixpkgs/pkgs/os-specific/linux/kernel/generic.nix:56:1
(use '--show-trace' to show detailed location information)

Oh right, the project doesn't cross-compile right now, it has to be executed on a linux machine

Does anyone want to try out https://github.com/nix-community/nixos-generators/pull/50 ? You will have to also checkout nixpkgs to the associated PR and then build the .box file

@zimbatm, I'd like to try that PR, but it's not clear to me how to do it. Is it enough to clone your nixos-generators fork?

Clone https://github.com/nix-community/nixos-generators/pull/50 and https://github.com/NixOS/nixpkgs/pull/76071
Then in the nixos-generators, override the configuration.nix to
{ config, lib, pkgs, modulesPath, ... }:
{
  documentation.man.enable = false;
  documentation.nixos.enable = false;
  sound.enable = false;
}

Finally run ./nixos-generators -I nixpkgs=../path/to/nixpkgs-clone -f vagrant-virtualbox`.
At the end if should give you a vbox file that you can import into virtualbox and try out.

I'm getting this error
./nixos-generate -I nixpkgs=../nixpkgs/ -f vagrant-virtualbox
error: attribute 'vagrantVirtualbox' in selection path 'config.system.build.vagrantVirtualbox' not found

thanks, fixed in https://github.com/NixOS/nixpkgs/pull/76071/commits/686125dbf9e1b5e933d3e74a7843bd9b1939d272
You will need a Linux remote builder to produce a compatible image. Do you know how to set that up?

Do you mean I can only run the command on Linux? I could do it in a VM, if that's possible.

You can run the command on macOS if you have a Linux remote builder machine setup. You will have to add ./nixos-generate -I nixpkgs=../nixpkgs/ -f vagrant-virtualbox --system linux-x86_64.
Or run it in a VM that works too.

I tried building inside a NixOS VM managed with VirtualBox and I got this error:
WARNING: Image format was not specified for 'nixos.raw' and probing guessed raw.
         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
         Specify the 'raw' format explicitly to remove the restrictions.
qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory
builder for '/nix/store/jpnka8baajbkkazqpqd40v7sxzy0g65s-nixos-ova-20.03.git.686125d-x86_64-linux.drv' failed with exit code 1
cannot build derivation '/nix/store/q76pbx6gfmhv976kw1gppy9nrxyar0xk-virtualbox-vagrant.box.drv': 1 dependencies couldn't be built
error: build of '/nix/store/q76pbx6gfmhv976kw1gppy9nrxyar0xk-virtualbox-vagrant.box.drv' failed

I think that's because the VM is managed by VirtualBox.
Next, I tried on a DigitalOcean instance running Ubuntu. I got this error:
error: a 'x86_64-linux' with features {kvm} is required to build '/nix/store/jpnka8baajbkkazqpqd40v7sxzy0g65s-nixos-ova-20.03.git.686125d-x86_64-linux.drv', but I am a 'x86_64-linux' with features {benchmark, big-parallel, nixos-test}

I'm afraid there are going to be many rounds to trial.
For the first issue, I think giving more RAM to the VirtualBox VM should solve it.
The second issue is because the Nix relies on KVM to build the image. Most hosting providers don't allow nested virtualization. I know Google Cloud or Azure do propose that option.

I published a version of the image over here: https://app.vagrantup.com/nixos/boxes/nixos-20.03-test
Virtualbox seems to be broken on NixOS at the moment so I am not able to test it unfortunately.

I get this error when running vagrant up on Windows 10 and latest VirtualBox.
Everything works with 18.03 image.
Vagrantfile: https://gist.github.com/filalex77/dc3305055a3990494778177f7059effe#file-vagrantfile

> vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'nixos/nixos-20.03-test'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'nixos/nixos-20.03-test' version '0.0.1' is up to date...
==> default: Setting the name of the VM: holochain-vagrant_default_1586268793281_37112
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: <IP_ADDRESS>:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default:
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
    default: The guest additions on this VM do not match the installed version of
    default: VirtualBox! In most cases this is fine, but in rare cases it can
    default: shared folder errors, please make sure the guest additions within the
    default: virtual machine match the version of VirtualBox you have installed on
    default: your host and reload your VM.
    default:
    default: Guest Additions Version: 6.0.14
    default: VirtualBox Version: 6.1
==> default: Mounting shared folders...
    default: /vagrant => C:/Users/brightone/holochain-vagrant
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

mkdir -p /vagrant

Stdout from the command:

Stderr from the command:

From what I can tell, the command mkdir -p /vagrant failed. I would log into the VM and see if that directory exists. I don't know what it means, if it does though.

The directory doesn't actually exist, yes. In vagrant ssh, sudo asks for root password, which I do not have...

That's strange. It shouldn't ask for your password, because it should normally log in with an SSH key. What does vagrant ssh-config show?

What does vagrant ssh-config show?

> vagrant ssh-config
Host default
  HostName <IP_ADDRESS>
  User vagrant
  Port 2222
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile C:/Users/brightone/holochain-vagrant/.vagrant/machines/default/virtualbox/private_key
  IdentitiesOnly yes
  LogLevel FATAL

Strange. I tried your Vagrantfile now and I got the same error about mkdir -p /vagrant. From what I can tell, it's running the command without sudo and failing with permission denied.
Also, I realized I misunderstood what you said about sudo.
The user should have passwordless sudo, but the machine wasn't built that way. I think your only option at this point is to build your own machine with the tools in this repo. I did it in the past and it was straightforward.

The nixos/nixos-20.03-test on Vagrant Cloud didn’t work for me. I got this error message during vagrant up phase:
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["startvm", "d5e91f69-bba7-4b13-a7b6-d7796e21e052", "--type", "headless"]

Stderr: VBoxManage: error: Implementation of the USB 2.0 controller not found!
VBoxManage: error: Because the USB 2.0 controller state is part of the saved VM state, the VM cannot be started. To fix this problem, either install the 'Oracle VM VirtualBox Extension Pack' or disable USB 2.0 support in the VM settings.
VBoxManage: error: Note! This error could also mean that an incompatible version of the 'Oracle VM VirtualBox Extension Pack' is installed (VERR_NOT_FOUND)
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ConsoleWrap, interface IConsole

and the machine is powered off. Fortunately current master branch works (I built it with Packer myself).

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/building-openstack-images-and-development-vms-from-a-macos-host/9522/1

Crossposting from the PR on nixpkgs: https://github.com/NixOS/nixpkgs/pull/76071#issuecomment-711420610
The VBoxManage step failure can be worked around by letting vagrant create the VM, error out with that message, and then using the UUID in VBoxManage modifyvm [the uuid] --usb off. Booting should get further.
 Set the NixOS options ‘security.sudo.configFile’
# or ‘security.sudo.extraRules’ instead.

# Keep SSH_AUTH_SOCK so that pam_ssh_agent_auth.so can do its magic.

Defaults:root,%wheel env_keep+=TERMINFO_DIRS
Defaults:root,%wheel env_keep+=TERMINFO

The sudoers format is powerful and I may not be interpreting it correctly, but I think the line %wheel ALL=(ALL) NOPASSWD: ALL, SETENV: ALL is being superseded by %wheel	ALL=(ALL:ALL)	SETENV: ALL later in the file.
Fortunately there is now an option, security.sudo.wheelNeedsPassword = false;, that covers that.


Cegep-lanaudiere

Add domain for cegep-lanaudiere.qc.ca for teachers and change school name for the "etu" subdomain (new school name)

@Padreik Thank you for the update! Pull request merged.


Transition code examples to Python 3

The Scipy examples and tutorials currently contain a number of examples that won't run on Python 3.
It could make sense to just move all of them to Python 3 syntax, and enforce this by running the REFGUIDE_CHECK on travis on Python3 instead of Python2.

+1 from me.

+1 from me.
On 3 May 2017 at 05:56, Eric Larson<EMAIL_ADDRESS>wrote:

+1 from me.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/scipy/scipy/issues/7366#issuecomment-298743405, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAq51gxr_s7qskNZHTWAb_3lA0VVFv-1ks5r14p5gaJpZM4NOlmA
.

--

Dr. Andrew Nelson

+1

Is the easiest way to do this by changing travis REFGUIDE check to python 3, seeing what fails, and fixing that?

@andyfaff that's how I would test it from the CI end. But locally you should be able to reproduce the errors yourself by setting up a Python3 env and running the check. (I'm not sure what the command is, so I'd look it up in .travis.yml.)

Fixed in #7653


Triggers that use a keycode with ⎋ appear as '5' instead.

If I set a trigger to ⌥⎋ it appears as ⌥5 in the interface, and I can only invoke it with ⌥5.
Seems like ESC and 5 are getting mixed up somehow.
This apparently also affects the 'Command Window with Selection' trigger, which was overhauled in v1.0.0.
More info at the end of: #2651

Same is also true for 'tab' appears as '0'.
Fixed in the latest QS fork of NDHotkeyEvent

Looks good!

Thanks for the confirmation!


support a one-shot scheduler

Sometimes, we need adding a scheduler to do something like transferring leader for a region, after the operator is finished, we should remove the scheduler to avoid it working but doing nothing forever.
We can add a one-shot scheduler, after the scheduler generates an operator and the operator is finished, we should remove the scheduler from the coordinator directly. Then we can refactor #483
We can also add a timeout for the scheduler too.

We don't need a scheduler to do this, we can just add operators.

can we add operator dynamically through API now?

or remove the operator


Fresh Install Error for Vendor Publish

I got this error when i do php artisan vendor publish
  [League\Flysystem\FileNotFoundException]
  File not found at path: 016_07_29_171118_create_chatter_categories_table.php

I manually copy paste the file in the vendor to database to fix this...
but i hope this would be fix for laravel 5.3

I can not recreate this error, might have been solved.


Analysis server provides private completion suggestions it shouldn't

Cause of https://github.com/dart-code/dart-code/issues/721 (screen shots there show this problem in action).
in library.dart:
library library_sample;

class Foo {
  final int bar;
  const Foo(this.bar);
}

class _FooPrivate {
  final int bar2;
  const _FooPrivate(this.bar2);
}

in main.dart:
import 'library.dart' as lib;

void main() {
  var foo1 = new lib.Foo(1); // OK, and offered as completion suggestion

  var foo2 = new lib._FooPrivate(2); // error, offered as completion suggestion for 'lib.'
                                     // but shouldn't be
}

the new lib._FooPrivate(2) triggers an error in analyzer (I initially reported that it caused a warning, but now I'm seeing an error - perhaps due to an upgrade in Dart sdk/analyzer between observations), but _FooPrivate is offered up as a completion suggestion by the analysis server.
Expected behavior is that it doesn't show the private class in suggestions.
I initially thought this was related to #32300, but on further investigation it seems like a separate issue.

I can't repro - is this still an issue?

Doesn't seem to be anymore.  Closing!


API v1: make host permissions more explicit for the new API version

In the chrome and opera manifest files, update the wildcard entry of the catalog API from https://api.creativecommons.engineering/* to https://api.creativecommons.engineering/v1/*.

Blocked for now.

@makkoncept can I start working on this issue

@Blackcipher101 According to the updated Contribution guidelines linked in the projects CONTRIBUTING.md, you don't have to ask for permission to work on an issue marked as good first issue. After making sure that no one is working on it, just comment on the issue that you are working on it.