__anext__ should be able to return &PyAny

Currently __anext__ expects IterANextOutput<_, _>, which can be only converted from Option<T1> or IterANextOutput<T2, T3> where all Ts implement IntoPy<PyObject>. But __anext__ frequently returns an awaitable, and whether the result is going to be Yield or Return is up to the awaitable and not __anext__ itself.
Searching for the existing __anext__ implementations from GitHub confirms this issue, and everyone seems to come up with their own workaround (I also had one):

https://github.com/Gelbpunkt/zangy/blob/a00fb19a62d2f2446c73d0c66999983c22b58627/src/pool.rs#L1373
https://github.com/apache/incubator-opendal/blob/2d4c14437328bdf2bb96de8395f833777e777a55/bindings/python/src/asyncio.rs#L351
https://github.com/hydro-project/hydroflow/blob/28f7c69cd73f0556b5ac2688105417d4ce0e8d08/hydro_cli/src/lib.rs#L414-L422
https://github.com/awslabs/smithy-rs/blob/79ead4884c206f1c41eacb5e61feab2a96c06173/rust-runtime/aws-smithy-http-server-python/src/types.rs#L489

Therefore ideally we should allow any T (that implements IntoPy<PyObject> as above), but that impl will conflict with both existing impls. While the impl for IterANextOutput<_, _> can be merged into IntoPyCallbackOutput and so is redundant, the impl for Option<T> cannot be removed because (Rust) None should be converted to PyStopAsyncIteration, not (Python) None. So the only possibility would be an autoref specialization.
On the other hand the value of forcing IterANextOutput<_, _> from __anext__ seems unclear. Assuming the last __anext__ did return some awaitable and it yielded some value, the awaitable might or might not know that the iteration has stopped---both possibilities are plausible. The current design is only suitable if the stop is already known. Probably __anext__ should not restrict return types and we should just make IterANextOutput implement IntoPy, ditching the Option<T> case (with a proper documentation of course).

On the other hand the value of forcing IterANextOutput<_, _> from anext seems unclear. Assuming the last anext did return some awaitable and it yielded some value, the awaitable might or might not know that the iteration has stopped---both possibilities are plausible. The current design is only suitable if the stop is already known. Probably anext should not restrict return types and we should just make IterANextOutput implement IntoPy, ditching the Option case (with a proper documentation of course).

While I am sympathetic to the simplicity of that approach, the resulting backwards incompatibility (silently compiling existing code to do something different) and the inconsistency between handling of __next__ and __anext__ appear to be significant downsides.
As an alternative, what do you think of adding a third enum variant to IterANextOutput which is basically passed to Python untouched? Something like IterANextOutput::Deferred(PyObject)?

Agreed there is a backwards compatibility hazard here. It should be noted that the design of __anext__ intentionally mirrors __next__, however I'm open to concluding that was incorrect.
I think if we wanted to expand to allow T: IntoPy<PyObject> we could potentially use autoref specialization inside the generated code to first work out a "converter" and then use that type to drive the conversion.

(It's worth noting in the past these methods were limited by the design of the #[pyproto] traits. With those removed we do have new design space here.)

I think if we wanted to expand to allow T: IntoPy we could potentially use autoref specialization inside the generated code to first work out a "converter" and then use that type to drive the conversion.

While technically possible, I think this might end up hard to explain, especially if we use to keep the Option special case and it will behave differently from "normal" #[pyfunction]s while the code looks the same. Then, the existing Option-layer on top of the IterANextOuput requirement is also not particularly straight-forward IMHO.
I guess in the end this is also a conflict between making the handling of __anext__ more idiomatic w.r.t. Rust (fixing the types or at least traits but providing conversions) versus Python (making this work automatically based on the inferred programmer intent). (There is a dusty closet in my mind where the trait-based protocols continue to be mourned for being what I would want the definition of the protocols to look like.)

While I am sympathetic to the simplicity of that approach, the resulting backwards incompatibility (silently compiling existing code to do something different) and the inconsistency between handling of __next__ and __anext__ appear to be significant downsides.

I agree that existing code should work identically as much as possible. The consistency, however, is nothing if it makes everyone to work around the quote-unquote consistent interface. I was surprised to learn that PyO3 does have a test for __anext__, which was the only code I've ever seen that fits to this design.
If we can agree that this is a real issue and desirable to fix, I believe my initial suggestion to use an autoref specialization is indeed fully backward compatible:

We reserve rights to change the expansion of proc-macros as long as documented inputs continue to work as advertised. In fact we don't even guarantee the exact behavioral compatibility either.
Therefore we are relatively free to change the internal implementation of #[pyclass]. While it is not necessary in this case, we are also safe to alter IntoPyCallbackOutput which was never publicly documented.
IntoPyCallbackOutput was never implemented for general T anyway, so using the autoref specialization to allow general T doesn't change existing code (which return types should go straight to IntoPyCallbackOutput). The autoref specialization would be unusable if that T was from type parameters, but we don't allow them.

As an alternative, what do you think of adding a third enum variant to IterANextOutput which is basically passed to Python untouched? Something like IterANextOutput::Defer(PyObject)?

In comparison this is technically a breaking change because IterANextOutput is publicly documented.

While technically possible, I think [the autoref specialization] might end up hard to explain, especially if we use to keep the Option special case and it will behave differently from "normal" #[pyfunction]s while the code looks the same.

Isn't this already true for __iter__? The only difference is that we don't return a coroutine for __iter__.

Then, the existing Option-layer on top of the IterANextOutput requirement is also not particularly straight-forward IMHO.

If a specialization magic is not your taste (I can relate), you can also specially treat Option and IterANextOutput return types. Proc-macros already recognize the exact ident Option, and IterANextOutput is specific enough that we can do the same. It's easy to explain: everything works like ordinary functions, except for two cases which are different to be consistent with __iter__.

In comparison this is technically a breaking change because IterANextOutput is publicly documented.

Yes, this is breaking a change. The enum is not just publicly documented but also not marked as #[non_exhaustive]. But it it easy to explain, to use and should be effectively backwards compatible. I do admit that this solution would untypical for PyO3 though which tends to be rather Pythonic insofar as it does gravitate different kinds of magic when it improves the ergonomics of the common case.

Isn't this already true for iter? The only difference is that we don't return a coroutine for iter.

I am at a loss to which behaviour you refer to exactly? Do you mean __next__ handling Option via impl<T> IntoPyCallbackOutput<PyIterNextOutput> for Option<T>?
If so, then my problem is not just that the existing protocol is complicated, but that I think we are discussing adding an additional twist on top of that.
The current contract is:

Return type of __(a)next__ has to be Iter(A)NextOutput.
Or Option<T> which is transformed into PyIterANextOutput in a way that is distinct from how Option<T> is turned into PyObject.

But now we extend the contract of __anext__ with:

Or T if it isn't Option<T> which bypasses the above and is turned into PyObject as usual.

Personally, I would prefer to avoid adding another layer to this altogether, hence the suggestion of the explicit option to add IterANextOutput::Defer. This would still create a difference between __next__ and __anext__, but it would give us a way to explicitly encode that difference in the type system and would produce call sites that were somewhat self-documenting. Ideally, I would even want to enforce that IterANextOutput::Defer produces an awaitable but I do not see how we could do that statically without pulling in something that bridges Future with Python's async I/O.
(If we do add the third option, using autoref specialization is fine IMHO and I would actually prefer to matching on type names.)
((If we are back to the drawing, I could even imagine copying Python's way of doing things, i.e. we always return T turned into PyObject as usual. If iteration is finished, we do panic_any(StopIteration) and our trampoline turns this into PyStopIteration. We do have to catch panics in any case so I don't think this would be a performance issue. But I think using unwinding for control flow is a big foot gun in Rust, e.g. most issues with unsafe code come from unexpected unwinding while some invariant is not yet reconstituted.))

(Of course, adding IterANextOutput::Defer and the special handing for T which isn't Option<T> are not exclusive.)

To add some context as to why I think specialization (whatever mechanism is used to implement it) is difficult to explain here: I think that specialization should be used when it does not need explanation at all, i.e. when the special case it captures is only special w.r.t. the quality of implementation (e.g. efficiency) but not w.r.t. the observable effects.

Do you mean __next__ handling Option via impl<T> IntoPyCallbackOutput<PyIterNextOutput> for Option<T>?

Oops, yes, I meant to say __next__ and not __iter__. Your understanding is correct.

If we do add the third option, using autoref specialization is fine IMHO and I would actually prefer that to matching on type names.

Ah, that makes sense. So you want to make the result of specialization visible from the type, without necessary removing that specialization. I'm okay with that. (I'm also not particularly into specialization, but I do feel proc-macros are already quite magical and specialization doesn't change that much ;-)

I could even imagine copying Python's way of doing things, i.e. we always return T turned into PyObject as usual. If iteration is finished, we do panic_any(StopIteration) and our trampoline turns this into PyStopIteration.

I think most workarounds (for __anext__) already issue PyStopAsyncIteration by themselves, so this might be workable. But the existing code will still expect Option<T> to work.

So, to recap the interim conclusion as I understand:

The current signature of __anext__ is less than helpful.
The autoref specialization, by its own, doesn't break existing code.
The specialization in general is hard to explain so types should strive to self-explain them. We can afford a slight backward incompatibility for that.

I believe these are enough to pinpoint what to do next. Please let me know if not.

I believe these are enough to pinpoint what to do next. Please let me know if not.

While I understand that this might be frustrating, I think we are still exploring the design space for now.
If we do decide to include specialization for T-but-not-Option<T> in the final design, we could push that also into a 0.19.x maintenance release, but I don't think we have reached a consensus for that final design yet. Personally, I would also like to here more want other maintainers think before committing the project on any direction.

Rereading PEP 492 it seems to be that __anext__ is defined as returning an awaitable, in which case I am tempted to argue that PyO3's current design is fundamentally wrong. We could go so far as to say that the awaitable is always responsible for raising StopAsyncIteration.
This would also map to the StreamExt traits next() method returning impl Future<Item = Option<T>>, which we could plausibly support in the future if we had #1632.
Presumably this would be the eventual goal of what we'd want to get to, where PyO3 can package the future into an awaitable automatically.
So, the question becomes how do we get there, and avoid breaking users along the way? If we required __anext__ to return a future (i.e. be async), I think that would be sufficiently breaking. However we probably want users to also return Python awaitables without any overhead.

Rereading PEP 492 it seems to be that anext is defined as returning an awaitable, in which case I am tempted to argue that PyO3's current design is fundamentally wrong. We could go so far as to say that the awaitable is always responsible for raising StopAsyncIteration.

Indeed in that case our design is wrong. Additionally, the example collected in the OP would all fit this pattern. Does anybody know any example where the contract intended by our current API is actually used?
If that is not the case, I would say that there is little point in caring about backwards compatibility, especially since Some(Future) would be equivalent to return Future under the normal IntoPyCallbackOutput rules?
If I understand this correctly, there would be no point in keeping IterANextOutput around at all?
(While we are here and discuss this, when Iter(A)NextOutput was originally designed, was there any discussion of just using PyResult instead and make the Rust code return PyStop(Async)Iteration as the above linked futures already do?)

It looks like the original optionality to __anext__ was added in #35. I expanded on it with the PyIter [A]NextOutput enums in #997. I vaguely recall at the time being puzzled by the optionality but also trusted it has been built correctly. I don't think either thought process was written down unfortunately. 😁

If that is not the case, I would say that there is little point in caring about backwards compatibility, especially since Some(Future) would be equivalent to return Future under the normal IntoPyCallbackOutput rules?

I mostly agree with the caveat that None should probably be checked for and a deprecation warning emitted with a backwards-compatibility path in the macro. Then after a couple of versions we remove that and returning None from __anext__ would become a bug.
Agreed IterANextOutput can be removed, I think even before the backwards compatibility path.
For IterNextOutput, the translation from a Rust iterator to a Python one seems reasonably well fitted. But maybe this could be removed and an alternative convenience added by a similar idea to #3195 with automatic or opt-in iter = true option to #[pyclass]?

For IterNextOutput, the translation from a Rust iterator to a Python one seems reasonably well fitted. But maybe this could be removed and an alternative convenience added by a similar idea to https://github.com/PyO3/pyo3/pull/3195 with automatic or opt-in iter = true option to #[pyclass]?

I think with today's PyO3 I would expect __iter__ to return anything as well and use PyResult<T> to "throw" a "StopIterationException" following the normal IntoPyCallbackOutput rules, i.e. mirror the Python approach but Rustify the error handling.
#[pyclass(iter = true)] could then be a convenience layer on top. I don't think I would want to have this without an escape hatch as implementing __iter__ could do tricks like slf: Py<Self> and I may not want my type to be a Rust iterator.

For IterNextOutput, the translation from a Rust iterator to a Python one seems reasonably well fitted. But maybe this could be removed and an alternative convenience added by a similar idea to #3195 with automatic or opt-in iter = true option to #[pyclass]?

I think with today's PyO3 I would expect __iter__ to return anything as well and use PyResult<T> to "throw" a "StopIterationException" following the normal IntoPyCallbackOutput rules, i.e. mirror the Python approach but Rustify the error handling.
#[pyclass(iter = true)] could then be a convenience layer on top. I don't think I would want to have this without an escape hatch as implementing __iter__ could do tricks like slf: Py<Self> and I may not want my type to be a Rust iterator.

Adding in here from #3202 - would this approach still not conflict when users return error types though? If the value is caught within IntoPyCallbackOutput, then theres still no way to pass errors from Rust into Python (if this approach is being understood correctly.
Py03 is blending two separate protocol implementations into one protocol, when they should be different:

Generators yielding values on each call to __iter__ or __next__ (current handling implements this, but forces a yield to get this behaviour & defaults to None)
i) Issues: yielding None at the end of the generator overwrites the value from generator ::Return
Iterators yielding values via StopIteration
ii) Issues: The return value is obfuscated through the generator yield. E.g. users are forced to return a value into StopIteration, bypassing any other errors the user wants to raise at runtime.

The two conflict with eachother, and it looks like Py03 is currently merging the logic for them both which leads to inappropriate handling at runtime (#3202). As well, adding a convenience layer is useful, but as you alluded to this would obfuscate the actual procedure being implemented. From a user perspective, the IterNextOutput is perfect for encapsulating that logic, but falls short due to having no escape when an error needs to raised to the Python interpreter from rust. I'd propose having some GenOutputXX and IterOutputXX, where gen allows for passing via Yield as a return value, and iter implements the protocol for re-escaping a generator until StopIteration is raised by Return. As a final encapsulation, both would also require :Err or similar, which would raise a PyErr directly to the runtime (not StopIteration, an actual error)

Adding in here from https://github.com/PyO3/pyo3/pull/3202 - would this approach still not conflict when users return error types though? If the value is caught within IntoPyCallbackOutput, then theres still no way to pass errors from Rust into Python (if this approach is being understood correctly.

Using the usual PyResult implementation of IntoPyCallbackOutput, you can return exception objects via the Ok variant and raise exceptions via the Err variant, e.g.
#[pyfn(m)]
fn foo(py: Python<'_>) -> PyResult<PyObject> {
    let err = pyo3::exceptions::PyRuntimeError::new_err("foo");
    Ok(err.into_py(py))
}

#[pyfn(m)]
fn bar() -> PyResult<PyObject> {
    let err = pyo3::exceptions::PyRuntimeError::new_err("bar");
    Err(err)
}

will make test tests
def test_foo():
    err = foo()
    assert type(err) == RuntimeError
    assert "foo" in str(err)

def test_bar():
    with pytest.raises(RuntimeError, match = "bar"):
        bar()

pass.

As a note for discussion here, tp_iternext is allowed to return NULL without setting a StopIteration value when the return does not need to carry a value.
https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_iternext


Add support for exported resource mocks

Like what you have done with the fact mocks, but with exported resources.
This feature would kick arse.

What is still impossible, as far as I can tell, is to test the collection operator, ie. that the correct subset of exported resources are realized in your catalog.
If I read the code correctly, it is impossible to check whether collect works, since the <<| |>> collect code (LLCOLLECT)  requires storeconfigs to be enabled to do any work at all.  This in turn requires a working puppetdb-terminus.
I did manage to hack together a matcher for the exported property, and with that I could verify that my collect statement worked by using <| |> (LCOLLECT) instead (yes, this collects both @ and @@).  Ie., my resources would be be visible in the catalog using the normal generic_contain, and I could use my .exported() matcher to verify the origin of this resource.
This is hardly a usable workaround, but it may point in a possible direction for implementation.


Unrug Liquidity V2 contract

Description
Finish and test the Unrug liquidity contract V2.
We can split this issue into a few ones.

[ ] Verify old state and impl of the Unrug and add it too the Unrug Liq fork.
[ ] Create token
[ ] Add liquidity Ekubo (CORE_ONLY issue, check the launchpad one and modify it without the launch params and using Inputs of lp to launch.
[ ] Check Jediswap Liquidity (issue with contract address not deployed on Mainnet, maybe verify block.id used etc
[ ] Finish StarkdeFi launch with inputs
[ ] Add Lock position manager to the contract

Hi, can I work on this?
ETA - 3 days.


Add missing dependency pyusb to pyproject.toml

pyproject.toml was missing the dependency 'pyusb' which is required for the usbtmc backend:
Traceback (most recent call last):
  File "test.py", line 22, in <module>
    from pyscpi import usbtmc
  File "<snip>/venv/lib/python3.10/site-packages/pyscpi/usbtmc.py", line 27, in <module>
    import usb.core
ModuleNotFoundError: No module named 'usb'

which was fixed by pip3 install pyusb.

@hannesweisbach Thanks for raising this. pyusb is not a dependency of this library. The backends are the user's choice. For example, if you use ethernet, then you don't have to install any additional libraries. I should make this clear in the readme. The reason why it doesn't install everything is that Python packages are chaotic, and they could get stuck during installation, especially on nicher systems. So, it remains the user's responsibility to ensure that backends are installed properly.

Oh, I see. Does it make sense to have backend-dependencies as optional depenencies ("extras")?
[project.optional-dependencies]
usb = ["pyusb"]
visa = ["pyvisa", "somethingelse"]
plotting = ["matplotlib"]

Then the user can chose how to install pyscpi and its dependencies:
pip3 install pyscpi               # install with no dependencies
pip3 install pyscpi[usb]          # install with dependencies for the USB backend
pip3 install pyscpi[usb,plotting] # install with dependencies for USB + plotting

Additionally pyproject.toml  can serve as a reference for the dependencies for various backends for users who want or need to install dependencies themselves.

Okay, an optional dependency like pip3 install pyscpi[usb, visa] would make sense. Plotting is the choice of the user.
usb = ["pyusb"]
visa = ["pyvisa"]

feel free to update the PR.


[enhancement] Fix the warnings reported by goreportcard.com

Now our code does not follow golang style well, it has gofmt and golint errors: https://goreportcard.com/report/github.com/kubeflow/tf-operator
Please help us to fix them. This issue is open for new contributors and it will help you to get involved in the development of our project :)

I will start working on it. I'll let you when done.

@AK-ayush 👌 Just go ahead

@gaocegege I have fixed some warnings. I have generated pull request #396 just to make sure that nothing is broken till now.

Close by #486

It seems that there still be some errors, so I reopen it and welcome to fix errors.


Error: failed to run custom build command for svm-rs-builds v0.4.1

Component
Other (please describe)
Have you ensured that all of these are up to date?

[X] Foundry
[ ] Foundryup

What version of Foundry are you on?
None
What command(s) is the bug in?
cargo install --git https://github.com/foundry-rs/foundry --profile local --locked forge cast chisel anvil
Operating System
macOS (Apple Silicon)
Describe the bug
Hi, Foundry team,
I tried to run the installation command for Foundry as specified by the documentation here, but along the installation, I am halted by these errors
error: failed to run custom build command for `svm-rs-builds v0.4.1`

Caused by:
  process didn't exit successfully: `/var/folders/9y/7pvvqjtj3fn0f_6byhnthpb00000gn/T/cargo-installP6KkcD/local/build/svm-rs-builds-16b2c39459d8fa2c/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at /Users/fps/.cargo/registry/src/index.crates.io-6f17d22bba15001f/svm-rs-builds-0.4.1/build.rs:140:46:
  Failed to fetch releases: ReqwestError(reqwest::Error { kind: Request, url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("github.com")), port: None, path: "/alloy-rs/solc-builds/raw/e4b80d33bc4d015b2fc3583e217fbf248b2014e1/macosx/aarch64/list.json", query: None, fragment: None }, source: TimedOut })
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: failed to compile `forge v0.2.0 (https://github.com/foundry-rs/foundry#bdc04c27)`, intermediate artifacts can be found at `/var/folders/9y/7pvvqjtj3fn0f_6byhnthpb00000gn/T/cargo-installeFycfc`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.
error: failed to compile `cast v0.2.0 (https://github.com/foundry-rs/foundry#bdc04c27)`, intermediate artifacts can be found at `/var/folders/9y/7pvvqjtj3fn0f_6byhnthpb00000gn/T/cargo-installjdoogW`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.
error: failed to compile `chisel v0.2.0 (https://github.com/foundry-rs/foundry#bdc04c27)`, intermediate artifacts can be found at `/var/folders/9y/7pvvqjtj3fn0f_6byhnthpb00000gn/T/cargo-install4V8ZhX`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.
error: failed to compile `anvil v0.2.0 (https://github.com/foundry-rs/foundry#bdc04c27)`, intermediate artifacts can be found at `/var/folders/9y/7pvvqjtj3fn0f_6byhnthpb00000gn/T/cargo-installP6KkcD`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.
     Summary Failed to install forge, cast, chisel, anvil (see error(s) above).
error: some crates failed to install

The command I ran was cargo install --git https://github.com/foundry-rs/foundry --profile local --locked forge cast chisel anvil.
These same errors persist when I try to build from a local copy of the GitHub repo.
How do I go about this? This issue has been recorded in #4037 previously, but there was no specified solution.
Thank you.

I solved it, I used a VPN, installed Foundryup and ran it.


Make an example notebook/script that analyzes molecule dataset coverage

It should take as input a large number of molecules in various formats (SDF, SMILES, MOL2 if OETK is available) and return useful info about if any of the molecules would not have been parameterizable.
NOTE: It is not necessary to generate openMM systems for these molecules, so we don't have to perform charge generation
A stretch goal would be that companies with proprietary molecule datasets could use this tool locally and easily report missing coverage, without releasing the whole molecule of interest.

I'd also had a related thing where I wanted to add visualization of where parameters are missing via highlighting on 2D structures. Some of Caitlin's earlier examples had highlighting depictions and I can dig these up if this is something we want in your notebook (otherwise I'll save it for when I get around to adding this myself).

Also, I'd done something rather similar to what you're proposing to work through a bunch of eMolecules molecules which fail to minimize with SMIRNOFF. It's not elegant, but I'm providing below:

Noteboook I was using
List of molecules which fail (many because of parameter coverage issues)

problem_smiles.txt
check_molecules.ipynb.zip


Will you port AccountsSettingsPane Class to WinUI ?

https://docs.microsoft.com/en-us/uwp/api/Windows.UI.ApplicationSettings.AccountsSettingsPane?view=winrt-19041

@MikeHillberg Do you know what this is?

@StephenLPeters, it is a modal dialog designed to exhibit accounts retrieved from a provider. e.g.
await WebAuthenticationCoreManager.FindAccountProviderAsync("https://login.microsoft.com", "consumers");

I'd imagine the API will remain the same; it will be up to the owners of the UI that the API triggers (which is not the xaml team) to decide whether to move the UI to WinUI 3 or not.

@asklar frankly, no idea. It is however an old element introduced in Windows 10.0.10240.0.


add device not possible

Hi,
I installed the adapter without problem.
But I is not possible to add a device...
The save button is gray and inactive and there is no button for a second device.

Hi Speedymk1!
You need to scroll down until you see an empty line with a '+' as the first item, then click on the '+' to add another empty line.


Reading level edits: Innovation Community of Practice

The PAR widget rates the Innovation Community of Practice page at grade 9 reading level (Hemingway rates it at 8). Our goal is to have grade 6 reading level content.
This issue is to explore what grade 6 content looks like and whether that content is acceptable.
Google Doc for drafting

Hayley has provided a first round of feedback. Waiting on review of second edits to respond to her comment.

Hayley did a first review and provided feedback. Waiting for second review of response edits.

Edits published.


Visual Studio 2019 Start Page

In the page "What's new in Visual Studio 2019", there is a section titled "New start window".
In previous version of Visual Studio it was possible to create customized start pages. Is this feature still available? If so, what resources are available to create one?
Thank you.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: dd6ebefd-fcc0-7e65-6450-c5908dbb61f8
Version Independent ID: 83656699-f59b-5c22-94ad-bb2c8d58b2ae
Content: What's new in Visual Studio 2019
Content Source: docs/ide/whats-new-visual-studio-2019.md
Product: visual-studio-dev16
GitHub Login: @TerryGLee
Microsoft Alias: tglee

@kmarois The Start page does not exist in Visual Studio 2019, so it cannot be customized. Are you asking whether the start window can be customized? If so, I think the answer to that is currently "no".

Actually the Start Page command in the main toolbar, which has always been hidden by default, is still working. You can also use toolbar customize settings to place it wherever you want.
Not sure if they will remove this altogether in the future, and this won't make it show up automatically when you start. But for now it is still there.

@DL444 You are not incorrect :) However, the Start Page command may be removed at any point in the future so you shouldn't count on it always being there. If you feel strongly about keeping the Start Page, please upvote this suggestion on Developer Community.


After cash out, active bets is displaying wrong data in place of cash out button

Rather than 'Loss: $0.00', after cashout it should show the cashed out amount. Red for a loss, Green for a profit

looks right. closing


Mobile version no logo and menu.

An iPhone it looks like:

@patrys I checked using the tool in Xcode and the error only occurs in iOS 10.x
I will try to find this bug...


Remove prefer_equal_for_default_values from the recommended.yaml set

Now that the package requires SDK ^3.0.0, this lint does nothing since it's not reported by the Dart 3 SDK, which instead reports the deprecated_colon_for_default_value diagnostic for 2.12-2.19 language versions.
\cc @pq @devoncarew

If we make the SDK requirement for that lint be ^3.0.0, then it's definitely not needed.
If the same version of the lints package can be used by older SDKs, then it might be worth retaining, as long as we're sure that the lint doesn't cause double-reports in SDKs where the analyzer warns itself. (I guess that when the analyzer knows that it reports useing :, it can also know to ignore this lint.)

Removal approved.


How to insert a space at the head of line?

eg,
你好！

to
    你好！

You can use the no-break space character.
{nbsp}{nbsp}你好！

or the zero-width character followed by the space character:
{zwsp}{sp}{zwsp}{sp}你好！

However, both of these solutions lack proper semantics. Perhaps a verse would be a better option?
[verse]
  你好！

@mojavelinux Thanks at first, i use {emsp}{emsp} instead because i use chinese.
[verse] not meet my need, because it case all break line has two spaces, but i just need the first has two spaces.
Thanks for you great work again, i can use this instead of GitBook now :-)


Allow manifest rebuild to loop up to 100 times

Ninja generators that bootstrap themselves with Ninja may need
to rebuild build.ninja multiple times.  Replace the 2 cycle loop
with a 100 cycle loop, and print the pass number each time it
restarts.
As discussed in https://groups.google.com/forum/#!searchin/ninja-build/jamie/ninja-build/YHOpOIS3FSo/ProjUh-DUxkJ

Thanks! Couple nits, else looks good.

Done


Log in failed

$ uva-tool -login
Input username: username
Input password: password
Remember? [y/n] y
Log in failed

https://github.com/arafat-hasan/uva-tool/blob/master/src/uva-tool.cpp#L333
Solution: Change uva.onlinejudge.org to onlinejudge.org.

Very sorry for the late reply. I just noticed after your pull request today, did not notice before.
Some issue has been raised for lack of maintenance and my remissness. I was planning to fix them for many days, but could not make time. Hopefully, I will be able to fix them soon.
Your work has been great!

Thanks!
I should inform you that I've not looked at the url for uhunt.onlinejudge.org. I think it's worth to take a look at that and verify that hunt-feature still works in uva-tool.

Yes, the Hunt feature is not working, your concern is definite. I think, there are some problems, possibly other than URL. I will take care of it, asap.


Fix#375

Description
This PR fixes #375
Notes for Reviewers
replaced the Layer5 logo with the Service Mesh Performance logo
Signed commits

[x] Yes, I signed my commits.

this PR fixes #375


Give constants a type

Right now it's not easy to tell that UNSPEC/TCPv4/etc are AddressFamilyAndProtocol. Somethign like this would help:
const (
	UNSPEC      AddressFamilyAndProtocol = '\x00'
	TCPv4       AddressFamilyAndProtocol = '\x11'
	…
)

Makes sense. Please, go ahead and open a PR! Glad to review.


Allow components to be styled using classnames

Environment

Tech
Version

material-ui-pickers
1.0.0-rc.11

material-ui
1.3.1

React
16.3.1

Browser
All

Platform
All

Steps to reproduce

Try to override the styles of picker components (e.g. https://github.com/dmtrKovalenko/material-ui-pickers/blob/develop/lib/src/DatePicker/Calendar.jsx)
Find that these components can only be styled using a MaterialUI theme

Expected behavior
As well as allowing users to style components using themes, material-ui allows users to pass in classnames which can be used to override the styles of components (see https://github.com/mui-org/material-ui/blob/master/packages/material-ui/src/Button/Button.d.ts). This is extremely beneficial for stacks which aren't using themes.
Actual behavior
Picker components can only be styled using a MaterialUI theme.

I am not promise that it will be implemented so any help is totally appreciated

I see that the components have a name defined: https://github.com/dmtrKovalenko/material-ui-pickers/blob/bdd7c1de801809a7798c55316a250cb9845e5fd2/lib/src/TimePicker/components/Clock.tsx#L172. You should get this feature for free when you upgrade to v4.0.0-beta.0. It was implemented in  https://github.com/mui-org/material-ui/pull/15140.

@oliviertassinari it will leverage displayName?

@dmtrKovalenko It uses the style sheet name. This value should already be unique in the theme.overrides scope.

@oliviertassinari ohh, I got what you mean :)
But I suppose this issue is mostly related to providing the prop classnames. But we differently need to create an example which will show how to override styles with global classnames :)

Rereading the issue description, it seems that people are interested in having an API where they can provide a classes prop to each nested component. Right now, their only option is to use theme.overrides. Tomorrow they will be able to use the global class name scope. So, my bad. You won't get this feature for free. We still have to manually forward the props.

Any update on this? Would be really great to have a classes prop

I think that we are good on this one. In v5, we are pushing global class names and the components prop to inject custom styled-components.


[Linux] During scrolling exam screen turns black

Hi
As per title. I was in the middle of an exam or quiz whatever that function is called and when I was scrolling with my bluetooth mouse I was getting black screen covering exam area and I had to reenter every single answer. I was getting that black screen constantly when scrolling. At one point I was getting back every 2 or 3 minutes and my answers were saving.
Thank you for time

@merczan, Please share more details on this. Is it something related to Teams?
Please share screenshot if it is possible.

Hey, sorry for taking so long I needed footage to show you what is happening. Yes, it is on linux and it is happening on your official app release.
Here is a link with a video for you to download, expires in 7 days or after 1 download.
https://send.firefox.com/download/7997ef1ca053f25c/#F2H5R8KB79H9as6515
Soft installed on newest ubuntu 20.04 LTS

When I do nothing or scroll with side bar manually it works but when I use m scroll wheel it just shows a black screen and I have to rejoin the test.

Provided link is expired.

https://vimeo.com/417510745

@merczan - Sorry, i missed out your response. We are checking it

@merczan, are you still facing this problem?


New exception message is confusing

Regression test TestCRUDModulesDb  is failing in nightly regression

public void testXQueryModuleCRUDXmlFileNegative() {

    DatabaseClient client = DatabaseClientFactory.newClient("localhost", 8011, "rest-admin", "x", Authentication.DIGEST);

    // get a manager
    ExtensionLibrariesManager libsMgr = client.newServerConfigManager().newExtensionLibrariesManager();

    String Path = "/foo/my/path/to/my/module.xqy";
    FileHandle f = new FileHandle(new File("src/test/java/com/marklogic/javaclient/data/all_well.xml")).withFormat(Format.XML);

    // write XQuery file to the modules database
    try{
    libsMgr.write(Path, f);
    }catch(ResourceNotFoundException e){
        assertEquals("Negative test Passed as","Local message: Could not write resource at /foo/my/path/to/my/module.xqy. Server Message: /v1/foo/my/path/to/my/module.xqy" , e.getMessage());
    }
    // delete it
    try{
        libsMgr.delete(Path);
    }catch(Exception e){
        assertEquals("", "Local message: Could not delete resource at /foo/my/path/to/my/module.xqy. Server Message: /v1/foo/my/path/to/my/module.xqy", e.getMessage());
    }

}

Actual:
Local message: Could not write resource at /foo/my/path/to/my/module.xqy. Server Message: Request failed. Error body not received from server

@srinathgit can you verify that this test is no longer failing?  I'm guessing this issue has just lingerred unnecessarily.

Assigning the case to @georgeajit

@sammefford The same (confusing) exception is still being thrown "Local message: Could not write resource at /foo/my/path/to/my/module.xqy. Server Message: Request failed. Error body not received from server". But the test has been changed as below and so it passess
@Test
public void testXQueryModuleCRUDXmlFileNegative() throws KeyManagementException, NoSuchAlgorithmException, IOException {

	DatabaseClient client = getDatabaseClient("rest-admin", "x", Authentication.DIGEST);

	// get a manager
	ExtensionLibrariesManager libsMgr = client.newServerConfigManager().newExtensionLibrariesManager();

	String Path = "/foo/my/path/to/my/module.xqy";
	FileHandle f = new FileHandle(new File("src/test/java/com/marklogic/client/functionaltest/data/all_well.xml")).withFormat(Format.XML);

	// write XQuery file to the modules database
	try{
	libsMgr.write(Path, f);
	}catch(ResourceNotFoundException e){
		//Issue 210 logged for meaningful error
		assertEquals("Local message: Could not write resource at /foo/my/path/to/my/module.xqy. Server Message: Request failed. Error body not received from server" , e.getMessage());
	}
	// delete it
	try{
		libsMgr.delete(Path);
	}catch(Exception e){
		assertEquals("", "Local message: Could not delete resource at /foo/my/path/to/my/module.xqy. Server Message: Request failed. Error body not received from server", e.getMessage());
	}

}

The test has been modified with new exception message


WelcomeActivity bypasses tutorial entirely

Almost didn't catch this one... but WelcomeActivity bypasses the tutorial completely in the pre-release master branch (API 24, Galaxy S7), it brings you straight to the login screen. I don't think the folks at WMF and Commons are going to be too happy with that, even if it is more convenient from a UX point of view.
Oddly, even reverting https://github.com/misaochan/apps-android-commons/commit/0713ed9e12c3e535a887337164da7b5dc60541b2 does not solve the issue, but I don't see any other commits that could have caused it based on the "Blame" view of the repo. This change has definitely only been introduced recently, as I tried downloading directly from Google Play and it works with that.
@maskaravivek @veyndan any thoughts?

If you log the result of prefs.getBoolean("firstrun", true)) after uninstalling the application, you will notice that the value is actually false where in fact you'd expect it to be true. This is because as of Marshmallow, a backup of the SharedPreferences occurs unless android:allowBackup is explicitly set to false in the AndroidManifest.xml as the default is true (docs).
If you clear all the data associated with the package name, it should be as if there is no back up, i.e. run adb shell pm clear fr.free.nrw.commons in the terminal. Now you should see the WelcomeActivity on start up.
I wouldn't consider this a bug and I would say that such a result is desired as you probably don't want the onboarding process again after uninstalling and then installing and you probably want to keep other preferences e.g. the theme preferences. However such a discussion would be a separate issue if it warrants a discussion.

After doing a bit more digging into this, apparently we can explicitly say which SharedPreferences we want to backup using android:fullBackupContent in <application>. The docs for this can be found here.

Thanks @veyndan ! I think we definitely want to allow backup for theme preferences etc for convenience. I'm not sure whether we want the tutorial to be re-displayed after each fresh install/update or not... I suppose if they have already read it once then it shouldn't matter too much, but if the tutorial is updated or they come back again after a long hiatus, it might be a good idea to have a refresher?

Regardless, since this is not a byproduct of the recent changes, I'll push this release first, and then we can discuss this at our leisure. :)


Chats and Tribes are slow to load on Android

Task
In general, performance for loading chats and tribes takes a little while on Android

Chats list load
Logic to load chats list is in the init of the ChatListViewModel. There we are querying to get all contacts and chats (depending on the dashboard tab the user is in), then processing them and building the array of DashboardChat objects which will be finally set on chatViewStateContainer which will be collected on ChatListAdapter to build the recycler view. During this process we are iterating through contacts and chats in many situations and querying db on each iteration to get last messages, invites, etc.
One thing that could be changed to improve performance is removing those queries done in each iteration and make just one query before the iteration, saving the results in a map, then just getting the right object on each iteration from the map.
Example of this:
https://github.com/stakwork/sphinx-kotlin/blob/11a576dbb6e84a743d43311a5b2a3b962e415a25/sphinx/screens/dashboard/dashboard/src/main/java/chat/sphinx/dashboard/ui/ChatListViewModel.kt#L140
Other than that sometimes the chats list takes a few seconds to show up, and there might be other causes for this issue.
Chat messages load
Android users also reported some delay when entering a chat before the messages show up.
The logic to load and show messages in a chat is in the screenInit method of ChatViewModel. We are querying db to get last 100 messages and after a delay we are loading 1000 messages and start listening to any change on those using distinctUntilChanged. Once messages are queried we are calling getMessageHolderViewStateList to get the list of MessageHolderViewState which is finally set on messageHolderViewStateFlow to be collected on MessageListAdapter and used to build the recycler items


TextAlignment has no effect on text alignment, only controls justification for multi-line texts

Unlike CSS text-align which aligns the text inside a box and justify it, in Bevy the alignment of text is based on the concept of anchors. One can build a similar result to CSS text-align based on anchors and a parent node, but by default the anchor itself does the alignment.
The TextAlignment property actually controls the justifying of multi-line text only.

It has no effect on single-line text, which is a major difference with CSS
For multi-line texts, it aligns all-but-the-longest lines inside the horizontal space defined by the longest line.

It's arguable the name TextAlignment is suited, due to confusion with CSS and general meaning of "align" which for UI actually move elements to the left/right, whereas here the text as a whole never moves (some parts of it do, but the bounds are unaffected).
To make things more confusing, the documentation talks about changes to bounds, but text alignment has no effect on the text bounds, sine all "alignment" is done within the computed bounds derived from the max line length and number of lines.
Proposed actions

A minima, fix docs to not talk about bounds
Call out the major difference with CSS text-align
I'd personally be for a rename of that type to avoid confusion.

To clarify, are we talking about Text2d or text in the UI?

I tested with Text2dBundle. Although that's part of the issue: I'm well unable to tell what "text in the UI" is and how it's different from Text2d. We shouldn't have multiple text behaviors.

I believe this was fixed by #10854. Please reopen if I'm wrong.


How to convert the contact pairs into cool?

Hi,
My data file is like this format:
chr21 28000001 28030000 chr21 28030001 28060000<PHONE_NUMBER>15523
chr21 28000001 28030000 chr21 28060001 28090000 1174.46200449397
chr21 28000001 28030000 chr21 28090001 28120000<PHONE_NUMBER>63159
chr21 28000001 28030000 chr21 28120001 28150000 1087.62401591727
chr21 28000001 28030000 chr21 28150001 28180000<PHONE_NUMBER>70359
chr21 28000001 28030000 chr21 28180001 28210000<PHONE_NUMBER>39214
I used the command:
cooler cload pairs -c1 1 -p1 2 -c2 4 -p2 5 hg38.chrom.sizes:30000 IMR90_chr21-28-30Mb.txt out3180.cool
cooler zoomify --blance out3180.cool
higlass-manage ingest ~/Documents/HiC/zhuang/hic/out3180.mcool
But the higlass show a black figure. It seems that all value is 0.
I also tried to use another command but failed:
cooler load -f bg2 hg38.chrom.sizes:30000 IMR90_chr21-28-30Mb.txt mycooler.cool
File "pandas/_libs/parsers.pyx", line 1156, in pandas._libs.parsers.TextReader._convert_tokens
TypeError: Cannot cast array from dtype('float64') to dtype('int64') according to the rule 'safe'
Is there any error in my command?
Thanks.

cooler cload pairs aggregates each pairs record as a single count. Your input looks like a binned matrix, not pairs, right?
In that case you want to use cooler load. The input format is "2D bedGraph"-style, so use -f bg2. Additionally, your start coordinates are one-based so you should also pass --one-based and your values are floating point, so you should also pass --field count:dtype=float. Not having this last one is probably the source of the error you got.

Thanks nvictus. Yes, it's matrix file not pairs. I got the right results under your suggestions.
But the  --field command shows errors:
cooler load -f bg2 --field count:dtype=float --one-based --count-as-float hg38.chrom.sizes:30000 IMR90_chr21-28-30Mb_3180_.txt mycooler.cool
Usage: cooler load [OPTIONS] BINS_PATH PIXELS_PATH COOL_PATH
Error: Invalid value: Expected '--field {name},{number}' or '--field {name},{number},{dtype}'; got 'count:dtype=float'
Another change:
cooler load -f bg2 --field {count},{6},{float} --one-based --count-as-float hg38.chrom.sizes:30000 IMR90_chr21-28-30Mb_3180_.txt mycooler.cool
Traceback (most recent call last):
File "/usr/local/bin/cooler", line 11, in
sys.exit(cli())
File "/usr/local/lib/python3.7/site-packages/click/core.py", line 722, in call
return self.main(*args, **kwargs)
File "/usr/local/lib/python3.7/site-packages/click/core.py", line 697, in main
rv = self.invoke(ctx)
File "/usr/local/lib/python3.7/site-packages/click/core.py", line 1066, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/local/lib/python3.7/site-packages/click/core.py", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/local/lib/python3.7/site-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
File "/usr/local/lib/python3.7/site-packages/cooler/cli/load.py", line 267, in load
extra_fields = _parse_field_params(field)
File "/usr/local/lib/python3.7/site-packages/cooler/cli/load.py", line 36, in _parse_field_params
if number < 0:
UnboundLocalError: local variable 'number' referenced before assignment
I tried to simplify the command as following. It works:
cooler load -f bg2  --one-based --count-as-float hg38.chrom.sizes:30000 IMR90_chr21-28-30Mb_3180_.txt mycooler.cool
cooler zoomify --balance mycooler.cool
higlass-manage ingest ~/Documents/HiC/mycooler.cool

Ah, you must be using a 0.7 version? The syntax for the --field option changed in the latest version.
The {} braces were meant to symbolize placeholder names... it might have worked if you omitted them: --field count,7,float (the field numbers are specified as one-based). In any case, --count-as-float works too.

oh, yes, my version is cooler, version 0.7.10. I thought the docker will update it to the newest version.
Thanks.


Blood mist affix imported as Stunt duration D4Build

build: https://d4builds.gg/builds/ef414fbd-81cd-49d1-9c8d-4938b278e2ee/?var=0

And inherent affix still didn't import from d4build, last update <IP_ADDRESS>

The Resistance to all elements only works when it's included:

Maxroll:

Will have to check what is happening with the Blood mist affix.
Probably because the extra text d4builds uses to describe the tempered affixes.

Did some tests. Both inherent and tempered will not always work for d4builds because of the different affix descriptions they use.
That will cost some more time to get that working again.

Owner

Alright thanks !

I think I found most of the issues, got a few questions thought.
Do you know how this one looks ingame?
Diablo 4 Companion:
Golem Cooldown Reduction (Necromancer Only)
d4builds:
[16 - 25%] Golem Active Cooldown Reduction (Necromancer Efficiency - Resource)
With or without the active part?
And the second one, in the build you linked there is a strange tempered affix on the pants.

Looks like two different affixes merged together? However the Blight Slow Potency does not exist in my data.

The first answer looks like that:

And for the second, there is this:

I think it will work good enough to find Golem Active Cooldown Reduction instead of Golem Cooldown Reduction.
But will need to look into that later why my text is different.

And for the second, there is this:

So a bug on d4builds then? Looks like the added the whole temper manual instead of a single affix.

But then I'll still need to find that Blight Slow Potency affix. Although I'm sure I have added all tempered affixes I could find in the data.

Found it, it's one of those affixes that is saved differently in the data. There are about 30+ more affixes like that. Still need to figure out how to get those.
So the next update will fix most of your issues but the Blight Slow Potency will have to wait.

With v<IP_ADDRESS> you will be able to import the tempered affixes.
Blight Slow Potency will follow later.

With v<IP_ADDRESS> you will be able to import the tempered affixes. Blight Slow Potency will follow later.

Thanks sir, i have see also like 3 different affix that was bad imported, i don't remember them all but i know one is on this build:
Weapons is importing Attack speed at tempered affix, but it's MINION attack speed.
And for the others i have to check if i can remember, but yeah there was more bad imported, i let you know

Edit: Minion attack speed got fixed in the last version, will let you know if i find wrong values, thanks for the update!

No problem, let me know when you find any.
For the ef414fbd-81cd-49d1-9c8d-4938b278e2ee build the only one left is the Blight Slow Potency.

they changed icon of greater affix, and all greater affix aren't recognized anymore with diablo companion

Fixed that this morning for all the 1080p and 1440p system presets. Should work again if you update the system preset under settings.

Alright thanks sir i didn't updated i thought it was automatically done.
I have a pretty nice suggestion, i don't know if it would be possible but:
It would be great if we can set different affix for Ring 1 and Ring 2, same for all different weapons from barbarian, because we need 4 different weapons but affix is show same for all

You could try to do that by using different colors for the affixes.

Added the missing Blight Slow Potency as well. Will be available in the next release.


[build] Remove deprecated gradle convetion usage

For more context, we can see https://docs.gradle.org/8.2/userguide/upgrading_version_8.html#java_convention_deprecation

@nizhikov could you please take a look?

@kallestenflo Could you please take a look?

@kallestenflo Could you please take a look?

@kallestenflo Could you please take a look?

@kallestenflo Could you please take a look?

@kallestenflo Could you please take a look?

@kallestenflo Could you please take a look?


debugging bluebird promises

Can vscode debug node code allowing one to step through promises without setting breakpoints? This is similar to clicking "Async" in the chome debug tools as described in this question.
http://stackoverflow.com/questions/32767721/how-to-step-through-debugger-with-promises

This is currently not supported. @weinand fyi

This is now possible (it might help to enable the "smartStep" feature).


Debugger with aws-lambda-rie

When running the config below with the debugger enabled I get the following error:
could not launch process: could not open debug info - debuggee must not be built with 'go run' or -ldflags='-s -w', which strip debug info

If I run it with debug disabled, it builds and works correctly. I was using a simple hello world main. Is there a way to have debugging with rie?
Thanks
name: relay
output_binary: /usr/local/bin/aws-lambda-rie /var/task/main
build_command: go build -o /var/task/main
build_dir: /src
run_command: '{{.output_binary}}'
runtime_image: golang:1.20.4
debugger_enabled: true
debugger_port: 40000
expose_ports:
  - "8080:8080"
networks: []
environment: []
pre_run_commands:
  - mkdir -p /var/task
  - curl -sLo /tmp/aws-lambda-rie https://github.com/aws/aws-lambda-runtime-interface-emulator/releases/latest/download/aws-lambda-rie && mv /tmp/aws-lambda-rie /usr/local/bin/aws-lambda-rie && chmod +x /usr/local/bin/aws-lambda-rie

Hi @pixie79,
I believe the issue is that the aws-lambda-rie executable was built without the debug symbols as suggested by the message you attached.
It acts like a proxy for simulating the AWS lambda infrastructure when testing your function.
I actually wrote a small blog post regarding using aws-lambda-rie and gebug you can take a look:
https://moshe-beladev-mb.medium.com/debug-aws-lambda-functions-with-gebug-bc643788c247

Hi,
Thanks, that was the blog post I was following and where I downloaded the aws-lambda-rie from so I guess the main project no longer includes the debug symbols. Is there any other option?
Regards
Mark

Actually I re-checked it and it looks like the the configuration I used back-then was also without debugger:
name: lambdagebug
output_binary: /usr/local/bin/aws-lambda-rie /var/task/main
build_command: go build -o /var/task/main
build_dir: /src
run_command: '{{.output_binary}}'
runtime_image: golang:1.15.2
debugger_enabled: false
debugger_port: 0
expose_ports:
- 8080:8080
networks: []
environment: []
pre_run_commands:
- curl -sLo /tmp/aws-lambda-rie https://github.com/aws/aws-lambda-runtime-interface-emulator/releases/latest/download/aws-lambda-rie && mv /tmp/aws-lambda-rie /usr/local/bin/aws-lambda-rie && chmod +x /usr/local/bin/aws-lambda-rie

which is makes sense as it's not so common to release an official binary with the debug symbols.
Unfortunately, not sure any standard way using delve and regular Go application will work for you the way you are looking for.
But, you can use Gebug for live reload (dynamically edit you Go code and it will automatically build and run your latest changes).
Hope you will find it useful for your needs 🙏


Add partnership propositions

Landed in https://github.com/metarhia/metarhia.com/commit/6eb9e513aae1d306729fa5ada033942e739c066d

Landed in https://github.com/metarhia/metarhia.com/commit/6eb9e513aae1d306729fa5ada033942e739c066d


Added friend picker suggested response type

More info can be found at:
https://dev.kik.com/#/docs/messaging#friend-picker-response-object

looks good to me :+1:


Add a license

This is the standard Apache 2.0 license.
We'd like to use this bundle for highlighting assembly code on github.com using the new syntax highlighter we've been developing. Would you be willing to add a license? Thanks!

@amorrow It would really help if you could add a license on your repository :yellow_heart:

:+1:  any license would do, but no license, means no license ;)


stats: Shared scopes phase 1, changes scope APIs to use ScopeSharedPtr, leaving ScopePtr alias behind

Commit Message: To support an algorithmic solution to a long burst of CPU on admin /stats with a large # clusters, we need to hold scopes in shared pointers. This PR makes that change and updates the usage within stats to reference scopes as ScopeSharedPtr rather than ScopePtr, and adds enable_shared_from_this as a Scope super-class so existing APIs that pass Scope& don't need to change.
This leaves behind a ScopePtr alias to ScopeSharedPtr temporarily to (a) make this PR be reviewable and (b) avoid breaking other repos that may reference ScopePtr. It will be easier to submit this PR first, then a external repos can rename their references, and we can do a follow-up PR that removes ScopePtr to avoid longer term confusion. That PR would like like https://github.com/envoyproxy/envoy/pull/19790 which has 90 changed files in addition to the semantic change. Once this is merged, that PR will just be a strict rename and will be a lot easier to review.
This PR blocks #19693 which implements the admin change requiring holding onto a shared scope ptr.
Additional Description:
Risk Level: low
Testing: //test/...
Docs Changes: n/a
Release Notes: n/a
Platform Specific Features: n/a

/retest

The main doubt I have is that can the scopes be held by the admin page indefinitely, or is there a timeout mechanism? If the scopes live through several xDS updates, there is the possibility of Envoy OOMing.

This is a very insightful point! Let's dive in.
I don't think in practice this is a problem assuming requests have server-enforced timeouts. At the end of any request the shared_ptrs will be released. But it would be good to see if that's actually true.
Note we trust admin clients (a malicious one could just send /quitquitquit) but a broken admin client could just read the first chunk from a /stats request and then leave the connection open and start a new one. Note also that won't leak scopes quickly because it will just bump ref-counts on scopes that are held anyway in the configuration. The concern would be if xDS updates the config and drops the scope, held alive only by an in-progress admin request.
In the end I think it's request timeouts that prevent this from being a problem.

Also that's not an issue for this PR which is not changing the Admin behavior at all.

This is a very insightful point! Let's dive in.
I don't think in practice this is a problem assuming requests have server-enforced timeouts. At the end of any request the shared_ptrs will be released. But it would be good to see if that's actually true.
Note we trust admin clients (a malicious one could just send /quitquitquit) but a broken admin client could just read the first chunk from a /stats request and then leave the connection open and start a new one. Note also that won't leak scopes quickly because it will just bump ref-counts on scopes that are held anyway in the configuration. The concern would be if xDS updates the config and drops the scope, held alive only by an in-progress admin request.
In the end I think it's request timeouts that prevent this from being a problem.

Thanks, that was my only concern.
LGTM

Thanks Pradeep
@ggreenway can you take a look?

@ggreenway will you be able to take a look sometime? Or shall I re-assign?

At the moment scopes don't reference other scopes so I'm not seeing where the circular reference would come from.
But @pradeepcrao also pointed out that we might hold onto shared_ptr<scope> keeping it alive longer if there is a long-running admin operation. But I think that scopes appearing/disappearing a lot slower than even a long admin request.

/retest

/retest


[BE]. Add appVersion to route /api/version

For test - which version was deployed

GET https://filecoin.tools/api/version
{
    version: "0.1.16",
    appVersion: "0.1.18"
}

All stuff on
https://wallaby.filecoin.tools/
https://calibration.filecoin.tools/
https://filecoin.tools/


Warnings mangle variables

There's got a bug in lib/Raven/Stacktrace.php on line 181. Specifically, in this loop:
$args = array();
foreach ($frame['args'] as $i => $arg) {
    if (isset($params[$i])) {
        // Assign the argument by the parameter name
        if (is_array($arg)) {
            foreach ($arg as $key => $value) {
                if (is_string($value) || is_numeric($value)) {
                    $arg[$key] = substr($value, 0, $frame_arg_limit);
                }
            }
        }
        $args[$params[$i]->name] = $arg;
    } else {
        $args['param'.$i] = $arg;
    }
}

If $arg is a &reference then $arg[$key] = substr(...) will mutate the original variable.
We had a very difficult to trace bug in our software where when a warning was triggered, a random global variable would be truncated to 1024 chars. Took us a long time to track it back to here.
One potential fix is to clone the frame args first:
foreach (clone $frame['args'] as $i => $arg) {

Thanks for pointing this out. Clone doesn't quite work, but I have at least a test that reproduces this behavior in some scenarios, so I'll see what we can do.

@mnpenner PR attached, let me know if you think thats sufficient

@dcramer Thank you for the quick fix! We're going to test against changeset cd04e761c77cb06a25f31daa9eb3ec7a733e402a to make sure it works for our specific scenario. Code looks like it should work.

:+1: once you verify it resolves your issue we'll get it merged + tagged

@dcramer Yup. We just tested it. Works like a charm. Thank you very much!


Removed CSI_LOGLEVEL env var from driver DaemonSet

Pull request checklist

Pull request type

Please check the type of change your PR introduces:

[ ] Bugfix
[ ] Feature Enhancement
[ ] Test Automation
[x] Code Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Community Operator listing
[ ] Other (please describe):

What is the current behavior?

What is the new behavior?

How risky is this change?

[x] Small, isolated change
[ ] Medium, requires regression testing
[ ] Large, requires functional and regression testing

There is another code block using this env var CSI_LOGLEVEL, Ghanshyam is checking if that can also be removed without impacting sidecar logs. @ghanshyam-11 , please mark the PR ready for review after the analysis and most likely with removal of that code block too.

Compared the env vars on the Driver daemonset and sidecar deployments before and after removing the unused code and found out that env vars in both cases were same.


ENH: remove noprefix.h, change code appropriately

It seems SciPy is still old NumPy names, and including a header that redefines the old names to the new ones. This PR removes the header and adjusts the code accordingly.

xref PR numpy/numpy#12475 to warn this header should go away in NumPy 1.17, and
numpy/numpy#12402 to actually remove the header

Thanks @mattip, LGTM.
@tylerjereddy despite the build error on the first commit, I think this would be relatively safe to put into 1.2.0rc2 if that's still possible (not sure how far you are with that). Could be quite useful, even if this header doesn't go away in 1.17 but say in 1.18.

All green, in it goes. Thanks Matti!

Hmm, it does look like it. Puzzling that CI here passes but wheel builds don't. Yeah, makes sense to revert then in 1.2.x and sort this out after - this PR is not a blocker. I probably should have known better than suggest to include this ....

Hopefully someday we can unify the CIs or at least reduce their dissonance for the most part.
Now I realize why it would have been useful not to squash!

Reverted for 1.2.x in gh-9572.

Hopefully someday we can unify the CIs or at least reduce their dissonance for the most part.

That would be nice. For now I'll open an issue and see if I can figure out what was going on.

Can you link to the wheel failures or the wheel commands that resulted in failures?

That's in the issue, gh-9574. Don't worry too much about this one for now though. Should disappear when my open PR on dropping older NumPy versions is merged.


Plugin is reported as unresponsive in Home app

It looks like the plugin may be failing to load altogether:
[1/7/2023, 1:15:35 PM] Homebridge v1.6.0 (HAP v0.11.0) (Rise Garden) is running on port 30130.

/homebridge/node_modules/homebridge-rise-garden/node_modules/axios/lib/core/AxiosError.js:89
  AxiosError.call(axiosError, error.message, code, config, request, response);
             ^
Error: connect ETIMEDOUT <IP_ADDRESS>:443
    at Function.AxiosError.from (/homebridge/node_modules/homebridge-rise-garden/node_modules/axios/lib/core/AxiosError.js:89:14)
    at RedirectableRequest.handleRequestError (/homebridge/node_modules/homebridge-rise-garden/node_modules/axios/lib/adapters/http.js:526:25)
    at RedirectableRequest.emit (node:events:390:28)
    at ClientRequest.eventHandlers.<computed> (/homebridge/node_modules/homebridge-rise-garden/node_modules/follow-redirects/index.js:14:24)
    at ClientRequest.emit (node:events:390:28)
    at TLSSocket.socketErrorListener (node:_http_client:447:9)
    at TLSSocket.emit (node:events:390:28)
    at emitErrorNT (node:internal/streams/destroy:157:8)
    at emitErrorCloseNT (node:internal/streams/destroy:122:3)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)

axios was recently updated in https://github.com/viamin/homebridge-rise-garden/pull/55 so that is a possible culprit.

There's also this error which hits about 10 seconds before the one in the description:
[1/7/2023, 1:15:24 PM] Homebridge v1.6.0 (HAP v0.11.0) (Rise Garden) is running on port 30130.

/homebridge/node_modules/homebridge-rise-garden/node_modules/axios/lib/core/AxiosError.js:89
  AxiosError.call(axiosError, error.message, code, config, request, response);
             ^
Error: Hostname/IP does not match certificate's altnames: Host: prod-api.risegds.com. is not in the cert's altnames: DNS:exfoasaplatform.com, DNS:*.exfoasaplatform.com
    at Function.AxiosError.from (/homebridge/node_modules/homebridge-rise-garden/node_modules/axios/lib/core/AxiosError.js:89:14)
    at RedirectableRequest.handleRequestError (/homebridge/node_modules/homebridge-rise-garden/node_modules/axios/lib/adapters/http.js:526:25)
    at RedirectableRequest.emit (node:events:390:28)
    at ClientRequest.eventHandlers.<computed> (/homebridge/node_modules/homebridge-rise-garden/node_modules/follow-redirects/index.js:14:24)
    at ClientRequest.emit (node:events:390:28)
    at TLSSocket.socketErrorListener (node:_http_client:447:9)
    at TLSSocket.emit (node:events:390:28)
    at emitErrorNT (node:internal/streams/destroy:157:8)
    at emitErrorCloseNT (node:internal/streams/destroy:122:3)

Maybe a change on Rise's end

It's intermittent, so maybe it was an issue with the servers. An expired certificate?


license issue - org doesn't support Mozilla Public License :-(

Hi,
I was trying to implement your amazing package, but I've run into a bit of problem internally with the license.
It looks like we don't support the Mozilla Public License, and that's turning out to be a real blocker for me :-(
I think I would have more luck using your package internally if the license were one of these:

Apache 2.0 License
BSD "2-clause" or "Simplified" License
BSD "3-clause" License
MIT License
Code Project Open License 1.02
Microsoft Public or "Permissive" License
PostgreSQL License
Scala License
zlib/libpng License
ISC
WTFPL (slightly offensive)
Public Domain Dedication
The Unlicense
Creative Commons Attribution License (but NOT other Creative Commons licenses such as ShareAlike and Noncommercial)

Any help or consideration you could offer would be appreciated! I'd love to have the ability to use your package here at LinkedIn!

John

#1

Hi @thejohnbackes
I'd really like to make you (and everyone) able to use this tool, and I don't have any problem in changing the license of this npm package (e.g. into an Apache 2.0 or MIT or BSD License).
I'm not a lawyer, but I'm wondering:
how the MPL-2.0 can introduce such a licensing issue?
especially if the software itself is not "linked together to another project sources" (in other words "is not used as a library") but only used as an external executable that produce an output (the flow coverage report) from a bunch of source files (the external project sources), at least ideally, this kind of usage shouldn't introduce any licenses compatibility issues
(e.g. GCC itself is licensed as GPLv3, but nevertheless you can build software with it that is not covered by the same license, even proprietary software, if you are using it as the command line compiling tool, while you have to use a compatible license if you are building a new compiler of top of it).

I get what you're saying and that seems to make sense. the problem is more
that we have a specific list of licenses that are white listed (for npm
specifically). our system checks their existence before putting them into
the private npm repository. #bigcompanyproblems
On Thu, Jan 19, 2017 at 2:45 AM Luca Greco<EMAIL_ADDRESS>wrote:

Hi @thejohnbackes https://github.com/thejohnbackes
I'd really like to make you (and everyone) able to use this tool, and I
don't have any problem in changing the license of this npm package (e.g.
into an Apache 2.0 or MIT or BSD License).
I'm not a lawyer, but I'm wondering:
how the MPL-2.0 can introduce such a licensing issue?
especially if the software itself is not "linked together to another
project sources" (in other words "is not used as a library") but only used
as an external executable that produce an output (the flow coverage report)
from a bunch of source files (the external project sources), at least
ideally, this kind of usage shouldn't introduce any licenses compatibility
issues
(e.g. GCC itself is licensed as GPLv3, but nevertheless you can build
software with it that is not covered by the same license, even proprietary
software, if you are using it as the command line compiling tool, while you
have to use a compatible license if you are building a new compiler of top
of it).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rpl/flow-coverage-report/issues/19#issuecomment-273741588,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AM94FJKV8iZWveW5Snqwe4MFNWqVNRfnks5rTz7jgaJpZM4Le3J-
.

@thejohnbackes hehehe, the machines are already taking over :-)
anyway, I understand and, at least if no one of the existent users have any specific issue with the new license, I'm going to change it to MIT in the next released version.

@rpl that's good news! thanks for the help, Luca!

@thejohnbackes I've just merged #23 which changes the license of the flow-coverage-report npm package into MIT, and it has been released on npm as flow-coverage-report v.0.3.0.

Amazing, thanks Luca!
On Thu, Jan 26, 2017 at 8:03 AM Luca Greco<EMAIL_ADDRESS>wrote:

@thejohnbackes https://github.com/thejohnbackes I've just merged #23
https://github.com/rpl/flow-coverage-report/pull/23 which changes the
license of the flow-coverage-report npm package into MIT, and it has been
released on npm as flow-coverage-report v.0.3.0.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rpl/flow-coverage-report/issues/19#issuecomment-275427462,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AM94FI8Y7qtXY-ZMv474mdeEQXfzhnzKks5rWMO0gaJpZM4Le3J-
.


Run PassManager in SyntaxHandler only on top-level circuit

Currently, the SyntaxHandler generates code for kernels which runs runs
the PassManager after every kernel invocation, even when there is a
parent kernel. Avoid this by running the PassManager only when
optimize_only || is_callable.
Update the code used for compute-action blocks as well, because they
were also triggering the original issue.
Fixes #196

Testing:

Original program from #196 works now

This contrived compute-action example also works now (before it triggered the same error as #196):
__qpu__ void cascadingCNOT(qreg q) {
    compute {
        X(q);
    } action {
        Y(q);
        Y(q);
    }

    for (std::size_t i = 1; i < q.size(); i++) {
        CNOT(q[i-1], q[i]);
    }
}

__qpu__ void ghz(qreg q) {
    H(q[0]);
    cascadingCNOT(q);
    Measure(q);
}

int main() {
    set_verbose(true);
    set_shots(8);

    auto q = qalloc(10);
    ghz(q);
    q.print();
}

Good catch! The fixes look good and make sense to me.
Thanks, Austin!

For reference, I think this issue is coming from the legacy logic of having early escape in the destructor with the disable_destructor flag.
OS << "if (disable_destructor) {return;}\n";

Along the way, we may have not kept this logic consistent.
I think this fix is a good one since it moves the pass manager execution to the same conditional block with quantum::submit.


Add support for application/octet-stream content types

www.amazon.com uses this content type,

Few examples of sites using this content type:

https://www.realtor.com
https://nike.com

Few examples of sites using this content type:

https://www.realtor.com
https://nike.com


[Feature] Notebooks and Collections of Notes

Problem
Organise a collection of notes into a notebook or subnotebook for sharing
Solution
Support collections and sub-collections of notes.

I'm taking a look at this.

A collection of notes is a category in this system.


[Feature Request] Interface for writing Foxx service with language other than javascript

My Environment

ArangoDB Version:        3.3.16

Description
I want to have a way to build ArangoDB Service without Foxx.
It is painful writing complicated codes in Javascript; if there was an interface that allows the use of language designed for backend programming, like Go lang, it would be a great favour.
I tried to figure this out by reading the arangodb codes, but I couldn't figure out.

Hi,
I just discussed this with our product manager, and this is not going to happen.
If you like to draw inspiration from our foxx implementation and re-implement it in another language, feel free to browse the source for inspiration and ask questions.
Closing as "won't fix"


Changes on the _chip_id

This is an attempt to solve #8.
When troubleshooting this, I found two solutions, first is removing the @property and using the _chip_id as a normal function.
However this solutions works better as we do not need to change the logic. I found that the problem was when trying to write .
This solve also the problem of resetting the device with the sensor connected as mention in the Adafruit earning guide.
As I cannot figure out why this work, please test, and feel free to reject this PR if this solution is not desired
I test this on
Adafruit CircuitPython 6.2.0-beta.3-188-g05ed179e1 on 2021-03-15; Adafruit Feather RP2040 with rp2040

Before PR:
Adafruit CircuitPython 6.2.0 on 2021-04-05; Adafruit MagTag with ESP32S2
>>> import board
>>> import adafruit_shtc3
>>> i2c = board.I2C()
>>> shtc3 = adafruit_shtc3.SHTC3(i2c)
>>> shtc3._chip_id
2119
>>> dir(shtc3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "adafruit_shtc3.py", line 112, in _chip_id
  File "adafruit_shtc3.py", line 112, in _chip_id
OSError: [Errno 19] Unsupported operation

After PR:
Adafruit CircuitPython 6.2.0 on 2021-04-05; Adafruit MagTag with ESP32S2
>>> import board
>>> import adafruit_shtc3
>>> i2c = board.I2C()
>>> shtc3 = adafruit_shtc3.SHTC3(i2c)
>>> shtc3._chip_id
2119
>>> dir(shtc3)
['__class__', '__dict__', '__init__', '__module__', '__qualname__', 'i2c_device', 'reset', 'temperature', '_buffer', 'low_power', 'sleeping', '_chip_id', '_write_command', '_cached_sleep', '_low_power', 'relative_humidity', 'measurements', '_crc8']

oof i feel like its risky to reset the chip when asking for the ID - the right thing to do is not let folks call _chip_id? we could remove the funciton

@anecdata Thank you for testing :)
@ladyada agree with you, we could just remove it, but as you can see in
https://github.com/adafruit/Adafruit_CircuitPython_SHTC3/blob/9a15caf3e26f0487ce031ee7b80a3d9872c3991e/adafruit_shtc3.py#L120
We already reset the sensor to get the ID number and verify that is in the I2C bus in the class constructor that is how I arrive to this proposal, but I could change the PR to remove the _chip_id function. Let me know. and thanks :)

yeah we should just move the chip id grabber into the init code

will do Thanks

This is my interpretation of the requested changes.  Resetting the board with the sensor still work, open the possibility to remove the red warning in the learning guide. (to be tested by the person that made that guide)
Adafruit CircuitPython 6.2.0-beta.3-188-g05ed179e1 on 2021-03-15; Adafruit Feather RP2040 with rp2040
>>> import time
>>> import busio
>>> import board
>>> import adafruit_shtc3
>>>
>>> i2c = busio.I2C(board.SCL, board.SDA)
>>> sht = adafruit_shtc3.SHTC3(i2c)
>>>
>>> dir(sht)
['__class__', '__dict__', '__init__', '__module__', '__qualname__', 'i2c_device', 'reset', 'temperature', '_buffer', 'low_power', 'sleeping', '_chip_id', '_get_chip_id', '_write_command', '_cached_sleep', '_low_power', 'relative_humidity', 'measurements', '_crc8']
>>>

Also tested with the simpletest
Adafruit CircuitPython 6.2.0-beta.3-188-g05ed179e1 on 2021-03-15; Adafruit Feather RP2040 with rp2040
>>> import shtc3_simpletest
Temperature: 25.1 C
Humidity: 43.7 %

Temperature: 25.2 C
Humidity: 43.7 %

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "shtc3_simpletest.py", line 17, in <module>
KeyboardInterrupt:
>>>

However one last thing, not getting the device id as @anecdata
I am getting
>>> sht._chip_id
2183

maybe try printing it in hex?

you are right, 🤦🏼 , I changed the logic to get the right chip identifier.
Adafruit CircuitPython 6.2.0-beta.3-188-g05ed179e1 on 2021-03-15; Adafruit Feather RP2040 with rp2040
>>> import time
>>> import busio
>>> import board
>>> import adafruit_shtc3
>>>
>>> i2c = busio.I2C(board.SCL, board.SDA)
>>> sht = adafruit_shtc3.SHTC3(i2c)
>>>
>>> sht._chip_id
2055
>>>

2055 = _SHTC3_CHIP_ID = 0x807
https://github.com/adafruit/Adafruit_CircuitPython_SHTC3/blob/9a15caf3e26f0487ce031ee7b80a3d9872c3991e/adafruit_shtc3.py#L77


Does not accept files obtained with gibmacOS

The CC Clover throws an error, when it tries to build a USB from a macOS installer that was downloaded and build with gibmacOS.
Tried with
Ventura 13.0.1 (22A400)
Big Sur 11.7.1 (20G918)
Monterey 12.6.1 (21G217)

SIP is not disable I think

It is:
~ % csrutil status
System Integrity Protection status: disabled.

in which version of macOS are you trying this?

10.15.7 (19H1615)

You can not create a macOS 11, 12 , 13 on Catalina; Apple not permited this
Here no Issue on Ventura 13 with this program

Ahhh! Thanks!


SDK: supported versions of Ruby

What versions/implementations of Ruby should we support?

MRI 2.5.0 and newer? In general, N-1?
JRuby?
Graal/Truffle?

In MRI case probably same as in https://www.ruby-lang.org/en/downloads/branches/ normal maintenance, maybe security maintenance as well. Don't really see a point supporting versions that are not supported by the ruby-core team.

+1 for normal maintenance for MRI

+1 for security maintenance for MRI. For JRuby and Grall, let's consider them later since they already have the capability of running java code from Ruby
https://github.com/oracle/truffleruby/blob/master/doc/user/jruby-migration.md#using-java-from-ruby
https://github.com/jruby/jruby/wiki/CallingJavaFromJRuby

Shopify has a need to support both JRuby and TruffleRuby. The former is already targeted by CI. I’ll add TruffleRuby as well.

We've enabled CI for JRuby, TruffleRuby, and MRI 2.4 - 2.6. This is currently run for Shopify PRs. Running for everyone is gated on #77. Closing this, though, since we've covered all the bases for now.

With respect,  this is a bad policy that actively harms the ruby and open telemetry ecosystems, and makes it massively harder to do the due diligence required for updates and maintenance of legacy projects that you are explicating saying here you want to support upgrades to.


liblrs: add more members and split admin

Yes, that's enough. The problem is that your team hasn't been created yet, since the PR hasn't been merged. So GitHub warns you that a team in your CODEOWNERS doesn't exist (yet).


#163383192 Add functionality to filter and search for articles

What does this PR do?

Allow a user filter for articles based on article title, tags and author username.
Allow user search using keywords.

How should this be manually tested?

Download and install postman onto you're local machine
Open postman
Then visit the route https://ah-backend-summer-stagin-pr-37.herokuapp.com/api/v1/articles/?<param>=<search_text> <param> can be author, title, tag <search_text> the text you want to search or filter basing on to filter for articles or https://ah-backend-summer-stagin-pr-37.herokuapp.com/api/v1/articles/?search=<search_text> to search for articles using GET.

What are the relevant pivotal tracker stories?
#163383192

@oma0256 , please resolve the merge conflicts


Removed All Test button as it was only used for debugging.

Already addressed in https://github.com/ECE-493-Group-20/ZenZone/pull/96


Tracking issue for the procedure framework

This is the tracking issue for the procedure framework.
Steps

[x] RFC #836
[x] PoC: procedure-api
[ ] Standalone procedure

[x] Procedure API #904
[x] ProcedureStore #927
[x] Framework for local ProcedureManager #946
[x] Procedure execution #953
[x] Recover procedures from ProcedureStore #981
[x] Provide a way to watch a procedure #1043
[x] Add an error variant RetryLater for recoverable failure. (The default variant External always aborts the procedure.) #1058
[ ] Max retry times #1095
[ ] Provide a way to get the execution error of a procedure #1062
[ ] Remove metadata of procedure from memory after specific TTL
[ ] Cancellation and shutdown

[ ] Procedure for creating a standalone table

[x] Refactor CreateTableRequest to make it more convenient to serialize/deserialize #1018
[x] Implement procedure to create table on mito engine #1035
[x] Implement procedure to create table in table-procedure #1040
[x] Integrate procedure manager and create table procedure to datanode #1040
[ ] More test cases for each step

[ ] Procedure for altering a standalone table

[ ] Implement procedure to alter table on mito engine
[ ] Implement procedure to alter table in table-procedure

[ ] Procedure for dropping a standalone table
[ ] Procedure for other DDLs
[ ] Distributed procedure
[ ] Procedure for creating a distributed table
[ ] Procedure for dropping a distributed table
[ ] Procedure for altering a distributed table

Reference

#403 Maybe we can port some codes from this PR if we want to store the execution state to object stores
#275 The original tracking issue for altering table schema

We also need to change the API of the table engine to use TableId to locate the table since if we restart the node while renaming a table, the catalog might still use the old name to open a table.

Hi, It seems like we need to introduce an asynchronous schema changing pattern (like Google did in F1). It’s attractive to me. Do we have any planning?

It's planned. But I think we should implement distributed procedure framework first. Do you have interesting on that? @WenyXu

It's planned. But I think we should implement distributed procedure framework first. Do you have interesting on that? @WenyXu

Cool, let me write an RFC draft

asynchronous schema changing pattern (like Google did in F1)

A little similar but not the same thing. We don't have transactions and don't plan to provide isolation during schema changing.
To learn more about procedure, please refer to our RFC and HBase's document

I find out that most procedures need a prepare state, maybe we can add a prepare method to the procedure trait.


API Endpoints for forks

Adds the following endpoints:

GET /repos/:user/:repo/forks: List a repository's fork
POST /repos/:user/:repo/forks: Fork a repository

See also https://github.com/go-gitea/go-sdk/pull/30

It seems this pr will resolve #477

You have to govendor update code.gitea.io/sdk and not directly change the codes under vendor/

@lunny Sorry, was waiting for https://github.com/go-gitea/go-sdk/pull/30 to get merged. Fixed.

@ethantkoenig still missing the vendor/vendor.json-file :)

@lunny @bkcsoft vendor/vendor.json updated.

LGTM

LGTM


What load balancing algorithm is used?

If you look at the source code
https://github.com/meteorhacks/cluster/blob/0301735346f93a7fb0e4f623c03203468c462561/lib/server/worker_pool.js
under WorkerPool.prototype.pickWorker = function(){...}
It's based on Math.random();
Please correct me if I am wrong

I think that might just be picking a worker at random.
I have a feeling they would use least connections from what I've read in
other meteorhacks articles, but I only just glanced at the source code, so
I could also most definitely be wrong.
On 7 Aug 2015 12:24, "aunz"<EMAIL_ADDRESS>wrote:

If you look at the source code
https://github.com/meteorhacks/cluster/blob/0301735346f93a7fb0e4f623c03203468c462561/lib/server/worker_pool.js
under WorkerPool.prototype.pickWorker = function(){...}
It's based on Math.random();
Please correct me if I am wrong
—
Reply to this email directly or view it on GitHub
https://github.com/meteorhacks/cluster/issues/80#issuecomment-128651123.

Default is round robin but other algorithms are on the way.
It was mentioned in the demo video.

Thanks. That's interesting
On 9 Aug 2015 18:31, "Xychun"<EMAIL_ADDRESS>wrote:

Default is round robin but other algorithms are on the way.
It was mentioned in the demo video.
—
Reply to this email directly or view it on GitHub
https://github.com/meteorhacks/cluster/issues/80#issuecomment-129199155.


Allow filtered updates of packages matching a regex

Especially useful for situations like "update all packages that start with my organisations prefix"

do you have a small sample for this? Then I could add a regression test

Of course.
Given dependency file:
source https://nuget.org/api/v2

nuget Castle.Windsor
nuget NUnit
nuget Microsoft.AspNet.WebApi.SelfHost

Then:
paket update nuget Microsoft.* --filter should update AspNet
paket update nuget [MN].* --filter will update NUnit and AspNet but leave Castle.Windsor untouched.
Without the --filter flag, package names are treated as exact matches.

My code obviously rules :)

Mind pushing that test to my master branch? I'll add it to the pull request.

Ah, ok - I'll grab it.

https://github.com/fsprojects/Paket/commit/40ecd395cb512ea62cf9647d11d66bd0b431ff90

you need to run build.cmd runintegrationtests since we don't execute that target during standard build

Should having working unit and integration tests now

Could also please write one or two samples in the docs of the update command?

@forki crap. Push to wrong remote by mistake. Sorry.

/me goes off to change default push repository

no worries ;-)


363 create use project data provider hook

This change is

src/renderer/components/run-basic-checks-dialog/run-basic-checks-tab.component.tsx line 93 at r2 (raw file):

    useMemo(() => {
      return async () =>
        project === undefined ? 'No current project' : project.getVerse(new VerseRef('MAT 4:1'));

I believe this was recently changed to getVerseUSFM.

src/renderer/components/run-basic-checks-dialog/run-basic-checks-tab.component.tsx line 88 at r2 (raw file):

  const project = useProjectDataProvider<'ParatextStandard'>(currentProjectId);
  logger.info(``);

Is this an accidental leftover from debugging?


Error when I try to add a new users in UAA

Hi, I am trying to create an user using this documentation:
https://github.com/cloudfoundry/uaa/blob/master/docs/UAA-APIs.rst#create-a-user-post-users
and I have just created a method to do it:
Users.prototype.add = function (token_type, access_token) {
    "use strict";

    var url = this.UAA_API_URL + "/Users";

    console.log(url);
    var options = {
        method: 'POST',
        url: url,
        headers: {
            Accept: 'application/json',
            Authorization: token_type + ' ' + access_token
        }
    };

    return this.REST.request(options, "200", false);
};

When I execute the method, I receive the following error:
     Error: the string "{\"message\":\"Content type 'application/octet-stream' n
ot supported\",\"error\":\"scim\"}" was thrown, throw an Error :)

Do you have a Curl request to add an User in UAA. I would like to create a user in uaa to call later this method in CC API:
http://apidocs.cloudfoundry.org/222/users/creating_a_user.html
Does exist a UAA documentation in the way of CC API:
http://apidocs.cloudfoundry.org/222/
Many thanks in advance
Juan Antonio

The url used is:
https://uaa.MY_IP.xip.io/Users

I have just updated the request adding some details from:
http://www.simplecloud.info/specs/draft-scim-api-01.html#create-resource
and now it runs, but I think that UAA has some problem with JSON response.
Node detect some problems with string returned, I think.
Users.prototype.add = function (token_type, access_token, uaa_options) {
    "use strict";

    var url = this.UAA_API_URL + "/Users";
    var options = {
        method: 'POST',
        url: url,
        headers: {
            Accept: 'application/json',
            Authorization: token_type + ' ' + access_token
        },
        json: uaa_options
    };

    return this.REST.request(options, "201", false);
};

Way to add:
     Error: the string "{\"message\":\"Content type 'application/x-www-form-urle
ncoded' not supported\",\"error\":\"scim\"}" was thrown, throw an Error :)

I think that if I have a Curl request, I could solve my doubt.
I have updated uaa_options with more data, but the problem continues:
    it("The platform creates an User", function () {
        this.timeout(5000);

        var uaa_options = {
            "schemas":["urn:scim:schemas:core:1.0"],
            "userName":"demo4",
            "emails":[
                {
<EMAIL_ADDRESS>                  "type":"work"
                }
              ]
        };

        return CloudFoundryUsers.add(token_type, access_token, uaa_options).then(function (result) {
            console.log(result)
            expect(true).to.be.a('boolean');
        });
    });

FIXED.


TTTAttributed Label does not support Japanese,Russian and Chinese-Simplified when used along with link attributes

It also doesn't support Hebrew and I assume other RTL languages.
Anything new about this issue ?


Officially support v-model with <slot>

What problem does this feature solve?
Currently, it seems that v-model is not supported with Vue <slot>.
This is the current ESLint rule, which does not allow v-model in <slot>:
https://eslint.vuejs.org/rules/valid-v-model.html
https://github.com/vuejs/eslint-plugin-vue/blob/master/lib/rules/valid-v-model.js#L32
But now with Vue 3, event handlers such as @update:modelValue are passed as props prefixed with on, so technically they are available as slot props.
What does the proposed API look like?
(This is currently technically possible, but not very elegant)
MyComponent.vue:
<slot v-model="data" />

App.vue:
<MyComponent v-slot="{ modelValue, 'onUpdate:modelValue': onUpdateModelValue }">
    <input type="text" :value="modelValue" @input="onUpdateModelValue($event.target.value)"/>
</MyComponent>

<!-- It would be awesome, if something like this would automagically work: -->
<MyComponent v-slot="{ modelValue }">
    <input type="text" v-model="modelValue"/>
</MyComponent>

I made a POC in Stackblitz, showing that it technically works.
https://stackblitz.com/edit/vue3-vmodel-with-slot?file=src%2FApp.vue

Would also like this implemented.

Any updates?


Flow incorrectly parses export default async functions as FunctionExpression instead of FunctionDeclaration

export default async function foo() {}
export default (async function foo() {})

Flow parses both as FunctionExpression but only the second one should be (babylon does it fine).
It makes prettier add parenthesis because it's an expression instead of a declaration :(
http://astexplorer.net/#/gist/13b558367e825b316764c410daf9c45d/cee8ab46f39769211d361c3f06ac88f05c151bf2

Duplicate of https://github.com/facebook/flow/issues/3264

Thanks! cc @mroch  :)


Standalone plugin execution from CLI fails

Right now it's not possible to run the plugin with dev mode standalone, that is with fully-qualified group & artifact.
Following scenario: mvn package net.wasdev.wlp.maven.plugins:liberty-maven-plugin:3.0.M1:dev -X
Fails with:
[ERROR] Failed to execute goal net.wasdev.wlp.maven.plugins:liberty-maven-plugin:3.0.M1:dev (default-cli) on project openliberty-russia: null: MojoExecutionException: NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal net.wasdev.wlp.maven.plugins:liberty-maven-plugin:3.0.M1:dev (default-cli) on project openliberty-russia: null
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:213)
    [...]
Caused by: org.apache.maven.plugin.MojoExecutionException
    at org.codehaus.mojo.pluginsupport.MojoSupport.execute (MojoSupport.java:137)
    [...]
Caused by: java.lang.NullPointerException
    at net.wasdev.wlp.maven.plugins.server.DevMojo.runMojo (DevMojo.java:643)
    at net.wasdev.wlp.maven.plugins.server.DevMojo.doExecute (DevMojo.java:442)
    [...]

The following snippet in DevMojo.java tries to resolve the version of the defined plugin, which doesn't exist. Maybe there's another way around this?
private void runMojo(String plugin, String goal, String serverName, List<String> dependencies)
        throws MojoExecutionException {
    Plugin mavenPlugin = project.getPlugin(plugin);
    log.info("plugin version: " + mavenPlugin.getVersion());
    // ... exception occurs, mavenPlugin is null
}

Update: Looked a bit into this issue and there is another gotcha: if you override the executed plugin (like I did), then the printed plugin version is not correct anyway, since it grabs it from the project model. We need to change that plugin lookup to: "take anything that's explicitly defined, part of the default Maven plugins, or overridden in the command". There must be an easier way, but I'm not a Maven Plugin API expert :)

This is fixed in 3.0-M2.  You can run:
mvn io.openliberty.tools:liberty-maven-plugin:3.0-M2:dev


Update log4cats-core, log4cats-slf4j to 2.1.0

Updates

org.typelevel:log4cats-core
org.typelevel:log4cats-slf4j

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

Files still referring to the old version number
The following files still refer to the old version number (2.0.1).
You might want to review and update them manually.
project/plugins.sbt

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.typelevel" } ]

labels: library-update, semver-minor, old-version-remains

Codecov Report

Merging #229 (b45af72) into master (87310ce) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #229   +/-   ##
=======================================
  Coverage   43.72%   43.72%
=======================================
  Files          25       25
  Lines         263      263
  Branches        6        5    -1
=======================================
  Hits          115      115
  Misses        148      148

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 87310ce...b45af72. Read the comment docs.

Superseded by #249.


update node version & packages

Repo currently requires v16.13.2.
Current stable is v20.7.0.

Also, update packages. There are a few in the package.json that my vulnerability scanner is screaming about.
I know this isn't commercial production software, but I like maintaining my "let's keep it current" skills, even if it is often a painful path to walk. 😄