Fix scalar dispatching, fixes #6631 and #6611

Be more permissive on the check_if_handled_given_other check, related to #6631 and #6611

[x] Tests added / passed
[x] Passes black dask / flake8 dask
[x] Closes #6631
[x] Closes #6611

cc @jthielen and @mrocklin.

I can take a closer look when I get more time, but here's my initial impression:
#6393 was too strict in its dunder operation type check when it comes to scalars since it essentially ignores non-numeric scalars (something that wasn't even on my mind, as all my own use cases are numeric!). This is definitely an issue that needs to be resolved as soon as possible, particularly for the dominant use case of strings (#6611 and #6631). However, the approach of this PR goes too far the other way towards permissiveness, which breaks my primary motivating use case for #6393: Pint compatibility. With #6393, Dask properly defers to Pint Unit and scalar Quantity, however, that is no longer the case for this PR's implementation.
My general take on this is that Dask Arrays need to defer to unknown scalars just like they do to unknown arrays. So, we should probably do a more comprehensive survey of types that Dask should handle out of the box (most definitely strings, but not sure if there are others?), add those to the current check, and then update the documentation to emphasize that other unknown types (both arrays and scalars) need to be registered in order for Dask to operate with them. Perhaps a name other than register_chunk_type should be looked into?

👋 @jthielen thanks for taking a look, I'm obviously open to suggestions. Quick question:

my primary motivating use case for #6393: Pint compatibility. With #6393, Dask properly defers to Pint Unit and scalar Quantity, however, that is no longer the case for this PR's implementation.

Could you please point me to where is this currently tested?

Right now, it isn't being tested in Dask, but in Pint: https://github.com/hgrecco/pint/blob/master/pint/testsuite/test_compat_downcast.py#L95-L111. It's still xfailed, however, due to Pint's slower cadence and its grouping with the similar issue of numpy/numpy#15200 with masked arrays. When writing the comment, though, that was based on just a quick, informal test in the repl.
Perhaps a mock scalar test should also be added to Dask in this regard (don't want it to be Pint-specific, rather than any generic upcast type), or, even better yet, effort be put towards a more robust collection of these array/scalar interoperability tests across the ecosystem?

@jthielen I see, we should definitely add a test that covers that use case.
Now looking at the implementation of Pint, I see why this PR would no longer delegate to Pint. It's a bigger question of whether Dask should or should not delegate to "unknown scalars", and more importantly how should that change be introduced in Dask (because it is a breaking change). Is there an agreement on this @TomAugspurger @mrocklin @jthielen ?

I didn't follow the original issue closely so I'm not sure what's best
here. Do you have a recommendation?
On Mon, Sep 14, 2020 at 2:10 PM Rafal Wojdyla<EMAIL_ADDRESS>wrote:

@jthielen https://github.com/jthielen I see, we should definitely add a
test that covers that use case.
Now looking at the implementation of Pint, I see why this PR would no
longer delegate to Pint. It's a bigger question of whether Dask should or
should not delegate to "unknown scalars", and more importantly how should
that change be introduced in Dask (because it is a breaking change). Is
there an agreement on this @TomAugspurger
https://github.com/TomAugspurger @mrocklin https://github.com/mrocklin
@jthielen https://github.com/jthielen ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask/pull/6632#issuecomment-692255324, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKAOISFGCE6Z3TBNPDMMPDSFZTC3ANCNFSM4RKCY4YA
.

@jthielen I added a simple test to cover your original issue:
class TestScalar:
    def __radd__(self, other):
        return TestScalar()

def test_unknown_scalar_delegation():
    # Current implementation does not delegate to unknown scalars:
    assert type(da.from_array([1, 2]) + TestScalar()) == da.Array
    # Previous implementation would be:
    # assert type(da.from_array([1, 2]) + TestScalar()) == TestScalar

@TomAugspurger
Some context:

prior to #6393 all scalars (non array-like) were handled by Dask
after #6393 scalars that are [Number, list, tuple, np.generic, dask.dataframe.core.Scalar] are handled by Dask, the rest gets delegated (this includes str, custom user types etc)

There is at least 2 solutions:

treat unknown scalars the same we currently (post #6393) treat unknown arrays, which would involve defining a registry of known scalars that Dask would handle (potentially pandas' isscalar) (essentially https://github.com/dask/dask/pull/6632#issuecomment-692209381)
go with this PR's implementation, and handle arrays according to the defined hierarchy, but scalars/non array-like by default are handled by Dask

There are obviously pluses/minuses to both. Looking at this from the perspective of a user, in my opinion, scalar handling before #6393, made more sense (which this PR "reverts" to). That said we should probably still allow for a custom scalar (like Pint's Quantity) to notify Dask that it can/wants to handle an operation (via for example of some kind of evidence/protocol inside of the custom scalar, thus delegating the responsibility to the custom scalar's class/definition). I might be wrong but in my mind these kind of scalars would be special cases, and therefor should be treated that way. What do you think?

Do we have one other option? We could try manually deferring to other by calling its dunder method. We'd take over only if it's not implemented. Essentially re-implementing Python's logic manually. There are probably edge cases I'm not considering.
I'm somewhat pessimistic about a system that relies on third-party libraries registering things, at least specifically with Dask.

Looking at this from the user perspective, in my opinion, scalar handling before #6393, made more sense

My hope is that this doesn't affect most users at all :) If we ironed out all the issues with the current implementation by having Dask take over for more types, would the two implementations be equivalent from your point of view?

👋 @TomAugspurger

I'm somewhat pessimistic about a system that relies on third-party libraries registering things, at least specifically with Dask.

Just to be clear, in my mind that would not be a "manual" registration (akin to the current design of register_chunk_type), but rather an evidence/protocol that the custom class would have to implement. I actually see you suggestion as an implementation of that (where the custom class has to implement dunder method for (Dask) array), I was actually thinking about something more explicit, but I like your idea as well! There are some things I am worried about tho:

Dask would essentially reverse the python order of resolution, for __op__, it would first try to delegate (I assume to __rop__ of the custom scalar), and only if it gets NotImplemented it handles the __op__
do we need some kind of special consideration for in-place ops?

Quoting Guido van Rossum from this issue:

Originally my design was just

try left arg's __op__
if that returns NotImplemented, try right arg's __rop__

That's simple to explain and usually works. But when thinking through edge cases, we found that if the right class is a subclass of the left class, this gives unexpected results, so we added the exception. if the right class subclasses the left class and it overrides __rop__, try that first
I honestly believe that I didn't realize that it could ever matter if the right class subclasses the left class without overriding __rop__. And nobody else realized it either.
I think we decided on the "right class must override __rop__" condition in part to preserve the original, simpler rules for cases where we thought they would suffice, in part because for most users trying __rop__ before __op__ is unexpected, and in part because we didn't realize that it mattered.
And it only matters if the base class uses something like type(self) or self.__class__, which as a design pattern is sometimes dubious and other times useful.
Also note that the language Stephan quoted is somewhat different: it uses "provides" (__rop__) instead of "overrides". I could imagine that this, again, was a difference too subtle for most folks to notice.
If I had to do it over, I agree that if the right class subclasses the left class, we should always try __rop__ first. But now that this has been an ingrained behavior for so long I worry that it will break existing code, esp. in cases where there is an asymmetry between __op__ and __rop__ and the class author did not expect __rop__ ever to be called first.

afaiu #6393 follows that design (+ NEP-13) for array-like (with explicit downcast hierarchy, which makes sense), for scalars, there is no hierarchy, so it seems like we should follow the pythonic way (subclasses before superclass, left to right)? We could diverge, I'm just no sure what kind of dragons to expect once we cross that threshold?
Another alternative could be for scalars to "force" their own op on (Dask) array by setting __array_ufunc__ to None, according to NEP-13:
class TestScalar:
    __array_ufunc__= None

    def __add__(self, other):
        return TestScalar()

    __radd__ = __add__

@pytest.mark.parametrize("arr", [da.from_array([1, 2]), np.asarray([1, 2])])
def test_unknown_scalar_delegation(arr):
    assert type(arr + TestScalar()) == TestScalar
    assert type(TestScalar() + arr) == TestScalar

The test above, actually works, but actually NOT for the reasons that it should (more on that below). No change in Dask is needed (apart from this PR, which reverts scalar handling to priori to #6393), and we delegate the responsibility to the scalar classes. BUT it seems Dask Arrays do not follow NEP-13 when to comes to handling classes with disabled __array_ufunc__ (by setting it to None), the check_if_handled_given_other's wrapper should probably have:
    try:
        return other.__array_ufunc__ is None
    except AttributeError:
        return False

Which actually is the recommended solution from NEP-13.
Also I'm wondering, how many custom scalars apart from Pint's Quantity etc, would actually need this support? I'm essentially wondering how important is this feature to solve right now? For example, we could revert the scalar (not the array-like) handling from #6393, and open a completely new issue on Dask to discuss the design for custom scalar resolution in depth, essentially solve the pressing issue now, and gradually improve without affecting users. The only "real" use case I'm aware of is the Pint's dask_arr * quantity (which can be workaround by depending on python operand order quantity * dask_arr). I'm not saying we should not fix it, but I'm saying maybe it's not as time sensitive as the issues that #6393 has already introduced.
Btw on Pint's Quantity, it turns out that Quantity already has __array_ufunc__, to my understanding (and barely looked at the codebase), Quantity sometimes acts like a scalar and sometimes like an array, this introduces complexity, but afaiu if Dask was to follow NEP-13 (__array_ufunc__ check on scalars), that complexity is delegated to Pint, not Dask.

Thanks for that analysis @ravwojdyla. It'll take me some time to digest it :)
Input from others (possibly @shoyer if you have time, since you've thought about this a lot) would be welcome.

@jthielen thanks for the feedback. To reiterate, I'm not against Pint's use of * to construct a Quantity (since I have never used Pint, I don't have an opinion about that construct). But I do worry about effectively "broken" Dask master. That could mean creating a separate issue to discuss scalar handling further if necessary.
@jthielen @TomAugspurger on the 2nd glance at Pint's Quantity, and remembering something from NEP-13, maybe there is a middle ground, if:
def check_if_handled_given_other(f):
    @wraps(f)
    def wrapper(self, other):
        try:
            if other.__array_ufunc__ is None:
                return NotImplemented
        except AttributeError:
            pass

        if (
            hasattr(other, "__array_ufunc__")
            and not is_valid_array_chunk(other)
            and not is_dask_collection(other)
        ):
            return NotImplemented
        else:
            return f(self, other)

This implementation of the check_if_handled_given_other makes Dask Array more NEP-13 compliant given:

If other.array_ufunc is None, ndarray returns NotImplemented. Control reverts to Python, which in turn will try calling a corresponding reflexive method on other (e.g., other.rmul), if present.

If the array_ufunc attribute is absent on other and other.array_priority > self.array_priority, ndarray also returns NotImplemented (and the logic proceeds as in the previous case). This ensures backwards compatibility with old versions of NumPy.

Otherwise, ndarray unilaterally calls the corresponding Ufunc. Ufuncs never return NotImplemented, so reflexive methods such as other.rmul cannot be used to override arithmetic with NumPy arrays if array_ufunc is set to any value other than None. Instead, their behavior needs to be changed by implementing array_ufunc in a fashion consistent with the corresponding Ufunc, e.g., np.multiply. See List of operators and NumPy Ufuncs for a list of affected operators and their corresponding ufuncs.

A class wishing to modify the interaction with ndarray in binary operations therefore has two options:
Implement array_ufunc and follow Numpy semantics for Python binary operations (see below).
Set array_ufunc = None, and implement Python binary operations freely. In this case, ufuncs called on this argument will raise TypeError (see Turning Ufuncs off).

First point is fulfilled by the first try/catch. Second point, __array_priority__ is replaced by the explicit downcast registry check in the if branch, and third point by the else branch.
Above implementation passes test_dispatch +:
@pytest.mark.parametrize("arr", [da.from_array([1, 2]), np.asarray([1, 2])])
def test_unknown_scalar_delegation(arr):
    ureg = pint.UnitRegistry()
    assert type(arr * ureg.meter) == ureg.Quantity
    assert type(ureg.meter * arr) == ureg.Quantity

def test_operator_on_scalar():
    a = da.from_array(["a", "b", ".", "d"])
    # Validate/fix 6631
    assert_eq(a == ".", [False, False, True, False])
    # Validate/fix 6611
    assert "b" in a

@ravwojdyla That fix looks almost perfect to me! It aims to preserve the hierarchical dispatching for any array/scalar implementer of __array_ufunc__, which seems appropriate, while also switching over the default handling for non-__array_ufunc__ implementers to being on Dask's end, as needed for #6631 / #6611. The only problem I can see with it as written is duck Dask Arrays: types that implement both __array_ufunc__ and the Dask Collection interface, but are not Dask Arrays themselves (e.g., Pint Quantities and xarray DataArrays that wrap Dask Arrays). However, I think that should be easy to resolve by replacing the is_dask_collection check with a more explicit check for Dask's internal types?
To me, more detailed discussion about scalar handling is only needed if a use case for a non-__array_ufunc__ implementer needs to take priority over dask.array.Array in Python binary operations arises...and I can't really see that ever being the case?

PTAL @TomAugspurger @shoyer @jthielen

I'm happy to defer to others here.

I've taken a brief look through this and I'm also going to pass I think.  If no one shows up to review I'm ok to trust @ravwojdyla and @jthielen  and merge .  However, I think that it would be good to get more perspectives in here if possible.  The code changes here are not large.
In addition to @shoyer I'm also going to ping @pentschev , who I think has a good understanding of cross-array interactions.

The most recent updates generally look good to me! Just one suggestion for the modification to an existing test (see inline comment), and one question: given the refactor of binops and __array_ufunc__ checks to use _should_delgate (which was a great idea), should __array_function__ do likewise, or leave it as-is? If it is refactored, we could get rid of is_valid_chunk_type and just use is_valid_array_chunk by way of _should_delgate.

@jthielen I suggest we keep NEP-18 separate for now, and create a couple of issues:

consolidate NEP-13 and NEP-18
binops should delegate via __array_ufunc__ (which is the NEP-13 recommendation)

Thanks for looking Peter.
I'll plan to merge this later today (@jcrist was maybe going to look if he had time). We'll hopefully have a release tomorrow that should include these changes.

The implementation looks good to me, but I confess I don't have a strong understanding of __array_ufunc__ semantics to know if we're doing the right thing. I trust the people that did this work though, and the tests look good.


Unable to parse file Assets/Mirror/Runtime/Transport/Telepathy/Telepathy.dll.meta

Just got the latest version from assets store (9.0.2) and after importing it in an empty project I got this error
"Unable to parse file Assets/Mirror/Runtime/Transport/Telepathy/Telepathy.dll.meta: [Parser Failure at line 30: Expect ':' between key and value within mapping]"

Paste the meta file here please

fileFormatVersion: 2
guid: cc38a12e9b5834143976137abe1c8f23
PluginImporter:
externalObjects: {}
serializedVersion: 2
iconMap: {}
executionOrder: {}
isPreloaded: 0
isOverridable: 0
platformData:

first:
Any:
second:
enabled: 1
settings: {}
first:
Editor: Editor
second:
enabled: 0
settings:
DefaultValueInitialized: true
first:
Windows Store Apps: WindowsStoreApps
second:
enabled: 0
settings:
CPU: AnyCPU
userData:
assetBundleName:
assetBundleVariant:

What version of Unity?

2019.3.0f6

Restarted Unity after import?  Mine's the same and no such error.

I should've done that, sorry for the trouble, no error now.
Thanks.

I got the same error, but my version is 2021.3.10f1c1. XD


Update gitops.md

Hey @CathPag , please have a look here

Hey Cathy.
Thanks for your feedback. I'll be working on it 👍
Get Outlook for Androidhttps://aka.ms/AAb9ysg

From: Catherine Paganini @.>
Sent: Monday, March 14, 2022 5:17:24 PM
To: cncf/glossary @.>
Cc: Akshat Sharma @.>; Author @.>
Subject: Re: [cncf/glossary] Update gitops.md (PR #551)
@CathPag commented on this pull request.
Hi there, thanks for your contribution. This definitely needs some work. Please see my comments.

In content/en/gitops.mdhttps://github.com/cncf/glossary/pull/551#discussion_r825847323:

What it is

+Let's start with DevOps and then move on to GitOps.
+DevOps is a set of methods that automate and integrate processes between development and operations teams.
There is no need to define DevOps as we already have a definition.

In content/en/gitops.mdhttps://github.com/cncf/glossary/pull/551#discussion_r825852745:

What it is

+Let's start with DevOps and then move on to GitOps.
+DevOps is a set of methods that automate and integrate processes between development and operations teams.
+GitOps includes the involvement of a version-control system Git which increases the security and efficiency by many folds.

+GitOps is a set of best practices based on shared principles that are applied to a workflow that relies on software agents to automate the reconciliation of a declared system state or configuration in a git repository that stores the software's code.
This is the part that needs to be simplified. What's a workflow? What are agents? What's the reconciliation of a declared system state? This description is correct but too technical. That's what we need help with.
It's not an easy term to work on, btw.

In content/en/gitops.mdhttps://github.com/cncf/glossary/pull/551#discussion_r825855157:

-GitOps is a set of best practices based on shared principles, applied to a workflow that depends on software agents that enable automation to reconcile a declared system state or configuration in a git repository.
-These software agents and practices are used to execute a cohesive workflow that leverages a source control system like Git as the “single source of truth” and extends this practice to applications, infrastructure, and operational procedures.
+These software agents and practices are used to execute a cohesive workflow that leverages a source control system like Git as the "single source of truth" and extends this practice to applications, infrastructure, and operational procedures.
Same here. Let's not talk about agents. It requires explaining what it is and introduces a lot of unnecessary complexity. What is a cohesive workflow that leverages source control systems?

In content/en/gitops.mdhttps://github.com/cncf/glossary/pull/551#discussion_r825856099:

-Existing processes for infrastructure configuration management can face challenges such as configuration drift, failed deployments, relying on a system's previous state for success, missing documentation, or unknown development history.
-Adopting a GitOps workflow can help alleviate these issues, among several others.

+## Problems it addresses
Problem it addresses should not talk about GitOps at all and should focus on the problem only. What is life without GitOps like?

In content/en/gitops.mdhttps://github.com/cncf/glossary/pull/551#discussion_r825856440:

-Existing processes for infrastructure configuration management can face challenges such as configuration drift, failed deployments, relying on a system's previous state for success, missing documentation, or unknown development history.
-Adopting a GitOps workflow can help alleviate these issues, among several others.

+## Problems it addresses
+- Git eliminates the need of relying on previous software state for successful deployment.
Please make sure to keep the style consistent. We don't use bullet points in the glossary
—
Reply to this email directly, view it on GitHubhttps://github.com/cncf/glossary/pull/551#pullrequestreview-908645077, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AQS2UCGWSA2QAZF5L7IQBA3U74RMZANCNFSM5QD74T3Q.
You are receiving this because you authored the thread.Message ID: @.***>

Hey @CathPag , I need some more time to work on this.

Hey @CathPag , I need some more time to work on this.

I'm glad to hear. This is a difficult term and can't be done quickly :) We had a team of GitOps pros working on it and we didn't get to a point where it was mergeable. Feel free to pick an easier term too, if this turns out to be too tough.

Hi @akshatcoder-hash, are you still interested in working on this? If not, I'll go ahead and close this PR and free up the issue.

Hey @CathPag , you can close the PR

Hey @CathPag , you can go on closing it

Ok, thank you!


Execute file

ExecuteCommand and the bugfix are implemented

Resolve conflicts

I think you need to add a second parameter to the function, so it can be executed in Linux and on Windows


Hackathon Tracker

Hackathon Tracker #24
please add gssoc and hacktober label too

https://github.com/user-attachments/assets/b8ea671f-f8f6-4e26-a18c-7474c3265e04

Mention the correct issue number.

close #180


Describe Other Configuration Values in README

Will save others from having to go spelunking through the source code like I did :smile:. eg #17

Good one. Will start working on that :+1:

@hundredwatt @paulodiniz
I've opened a PR to update the README to include a section about the configuration options. I believe this addresses this issue and will help future readers should they need to set the portal_id or other important values. Thank you for opening an issue. 💛


P110 getting current energy usage via different api method

I'm seeking help in adding support in p110 api to get current power draw, let me explain.
All my "smart" devices are on network without internet access for privacy and security concerns and i've noticed that if the device turns on and connects to that network or even looses connection and then reconnects, none of the get_device_usage,get_energy_usage,get_energy_usage work which in the tplink app i can see as no energy usage graphs whatsoever. To fix that you need to kickstart them with internet connection and then they work fine just fine. But while they are not working, i noticed in the app i could still see current power draw and fankly thats all i care about (on/off works fine), so i was hoping you could help me/we could work together on finding out that api method, but if you got P110/115 then you don't need my help :P
I'm happy to provide any information and help in any way i can to get it as it's stopping me from achieving perfection

So far i tested the get_current_power and indeed, get_device_usage/get_energy_usage/get_energy_data all fail with different unknown tapo errors and get_current_power does indeed return current power draw!

Imma close this now since it's merged and I was able to do it myself :P

It's been released in v0.7.2. Thank you!

I'm all for adding whatever it's helpful to people.
What do you have in mind?

While looking at the apps code i just noticed some other functions, might not be exactly useful but full api coverage would be good no?

i'm gonna add small thingy to generate mappings for c++ which i used for my project

I don't think that full API coverage should be a target in itself because:

the API is private, and Tp-Link might pull the plug on it or revamp it any day
there is no documentation, and some of the endpoints, especially the ones that change the state of the device, are quite time-consuming to figure out how they work

However, if someone needs a particular function, I'll gladly support its addition.
If you're looking into adding FFI-related stuff, you might want to look at and/or branch off https://github.com/mihai-dinculescu/tapo/pull/100.

Oki gotcha that makes sense
Hmm but thats for python gotta add bindings for c++ along with cbindgen :P But well this is not issue for that
Thanks

I've done a bit of reverse engineering on the app (i'm newb) and i've located CurrentPowerResult which returns ONLY currentPower which I strongly believe is the result i'm interested in, and the request is called get_current_power

I'm getting
DEBUG:tapo.api.api_client:Get Current power...
DEBUG:tapo.api.protocol.klap_protocol:Request: {"method":"get_current_power","params":null}
DEBUG:tapo.api.protocol.klap_protocol:Device responded with: TapoResponse { error_code: 0, result: Some(CurrentPowerResult { current_power: 0 }) }

get_energy_usage() works...

perhaps current power draw is 0? I've not had issues with it ever since, and get_enery_usage just returned inbuilt statistics

yes, thanks absolutely feasible
DEBUG:tapo.api.api_client:Get Current power...
DEBUG:tapo.api.protocol.klap_protocol:Request: {"method":"get_current_power","params":null}
DEBUG:tapo.api.protocol.klap_protocol:Device responded with: TapoResponse { error_code: 0, result: Some(CurrentPowerResult { current_power: 98 }) }
***Current power: {'current_power': 98}
So my next problem is how to install on RPi?

I think that's incorrect place to ask :)


Migrated from Standard to flex and lost the mapping of / -> /index.jsp

From a customer:
I'm working on migrating my app from standard -> flex and am using the compat image (java 7) and have run into a small inconsistency I thought I'd check in about and see if it's a known issue:
My app has an admin site written in .jsp which when deployed in standard is available at:
https://XXX.appspot.com/admin_console
When deployed in Flex (using true in the .xml descriptor) I need to explicitly call out the jsp path to get the content:
https://XXX.appspot.com/admin_console/index.jsp
Note: There is a filter installed on /admin_console/* which requires authentication. This filter is working properly which is why regardless of the deployment you don't 404. However, if you were able to authenticate, then in the case where this app is deployed on Flex, you would see no content unless you used the second url form. In the case where it's deployed in Standard, it would be business as usual.
Update, Later:
FWIW with the new version it works if you put the / in but not without.
Works:
http://XXX.appspot.com/admin_console/
Doesnt:
http://XXX.appspot.com/admin_console

That update explains a bit.
For a request to /contextPath there are two actions that take place:

a redirection is performed to /contextPath/, so that relative paths will work correctly
the redirected request to put through the welcome page mapping of the context to locate the actual page.

So it appears that step 2 is working, but step 1 is not.  Step 1 is optional by calling ContextHandler.setAllowNullPathInfo(true),  but the default is false and I find it highly unlikely that somebody would have configured this?  But we should check.
Thus is may be some interaction with the authentication redirections at that URI as well?
So we need to investigate.  However, I think there is probably an enhancement we can do to jetty to make it try the welcome page redirections even with a null path info.  This wont help us short term but will make this more robust.  I have raised https://github.com/eclipse/jetty.project/issues/506

@ludoch How is the context path being set in this case?  It is hard coded to / in root.xml in the images I can see?

I think so, ( I guess but will check with the reporter). I doubt he
customized any of the jetty xml conf files we have.
On Mon, Apr 11, 2016 at 5:53 PM, Greg Wilkins<EMAIL_ADDRESS>wrote:

@ludoch https://github.com/ludoch How is the context path being set in
this case? It is hard coded to / in root.xml in the images I can see?
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/appengine-java-vm-runtime/issues/210#issuecomment-208649985

maybe it is the only legacy image with jetty9.2
On Mon, Apr 11, 2016 at 7:11 PM, Greg Wilkins<EMAIL_ADDRESS>wrote:

I've been testing 9.3.x and it does correctly map requests to /context to
welcome files even if setAllowNullPathInfo(true) has been called. It may be
JSP related, but we need to know more about their setup before we do much
more.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/appengine-java-vm-runtime/issues/210#issuecomment-208664417

setup:
do not put 1.8 in the pom.xml
add true in appengine-web.xml of a standard GAE all
On Mon, Apr 11, 2016 at 7:39 PM, Ludovic Champenois <
<EMAIL_ADDRESS>wrote:

maybe it is the only legacy image with jetty9.2
On Mon, Apr 11, 2016 at 7:11 PM, Greg Wilkins<EMAIL_ADDRESS>wrote:

I've been testing 9.3.x and it does correctly map requests to /context to
welcome files even if setAllowNullPathInfo(true) has been called. It may be
JSP related, but we need to know more about their setup before we do much
more.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/appengine-java-vm-runtime/issues/210#issuecomment-208664417

@ludoch still need to checkout how he is setting context path before we deploy anything
By "a standard GAE all" do you mean master or something prior to that?
Will check 9.2.x and JSP behaviour shortly for null pathinfo, but that still does not explain why the redirection is not done in the first place.

https://github.com/eclipse/jetty.project/issues/506 was closed, as testing showed that jetty 9.2 and 9.3 handles serving index jsp files with null path info just fine.
Need more info from reporter about their setup.


How to install from submodules for serverless

Hey guys,
I want to make a serverless function. The main logic has been encapsulated in a submodule repo, the  model_handler.py will just call the content of the submodule.
location:
CVAT
|----serverless
      |------------modules
                     |-------------------some-foo

in function-gpu.yaml  I added following:

        - Kind: ADD
          value: ./modules/some-foo /home/user/
        - kind: RUN
          value: pip3 install /home/user/modules/some-foo

But the ./modules/some-foo cannot be found  while running serverless/deploy_gpu.sh ie.
Any idea, thank you!

@XinyueZ
Please, use other channels to ask such kind of questions.
GitHub issues is a channel about the tool, its problems and features.

@XinyueZ
For this purpose you can use for example github discussions or discord channel (but TBH i find Diecussions better, because your question won't instantly disappear under a ton of new messages/questions/comments..


Limit root/sudo aspect of installation

It is understandable, albeit, unfortunate that the ./install.sh script requires sudo access.
However, the opencoarray-installation directory should definitely not be owned by root.

@tclune, fyi, sudo is not needed for a default installation with no arguments:
./install.sh
Such an installation results in an opencoarrays-installation directory that is not owned by root. Up until the commit that I just made and that I will merge into the master branch tomorrow (Tuesday), sudo was required if the user passed an installation path that requires root privileges:
sudo ./install.sh /installation/path/requiring/root/permissions
As soon as I merge this commit into our master branch (which will be included in our next release), ./install.sh will check whether the user has write permission for the chosen installation path.  If not, then install.sh uses sudo only for the final "make install" step of the OpenCoarrays installation.  That sudo invocation will prompt the user for his or her password if necessary.
On a related note, the default installation location for all prerequisites is in a directory of the form
opencoarrays/install_prerequisites/name-version-installation
where "name" is replaced with the package name and "version" is replaced with the version number.  At the present time, if one desires to install any prerequisites elsewhere, they must be installed individually in the following manner:
cd install_prerequisites
./build cmake  /desired/installation/path
where  can be replaced with "--default" for the default choice.  If a prerequisite is installed in the above manner, then "build" performs analogously to "install.sh" in that it only invokes "sudo" for the final "make install" step if necessary.  I'll close this issue when I merge the commit.

@tclune I believe this issue has been addressed in PR #84 which has been merged. I'm going to close this issue for now, unless you object. You can try the latest script by cloning the master branch, or if you're more patient than I am, you can wait until the next release which should be in a week or two. If you find that it has not been adequately addressed, feel free to reopen the issue.

Thanks - I’ll wait for the update (and probably still need to be prodded gently by Damian).
Cheers,

Tom

On Dec 23, 2015, at 11:02 PM, Izaak Beekman<EMAIL_ADDRESS>wrote:
@tclune https://github.com/tclune I believe this issue has been addressed in PR #84 https://github.com/sourceryinstitute/opencoarrays/pull/84 which has been merged. I'm going to close this issue for now, unless you object. You can try the latest script by cloning the master branch, or if you're more patient than I am, you can wait until the next release which should be in a week or two. If you find that it has not been adequately addressed, feel free to reopen the issue.
—
Reply to this email directly or view it on GitHub https://github.com/sourceryinstitute/opencoarrays/issues/34#issuecomment-167038351.

Thomas Clune, Ph. D<EMAIL_ADDRESS>Software Infrastructure Team Lead
Global Modeling and Assimilation Office, Code 610.1
NASA GSFC
MS 610.1 B33-C128
Greenbelt, MD 20771
301-286-4635


Update Travis CI config

Drops PHP <5.6
Add Behat test runner

While the do tests fail, the config works.


WASM Target compiliation

I'm using seed-rs to display plots with the inline html.
seed-rs uses wasmpack which compile libraries with the wasm32-unknown-unknown target.
Repo to reproduce the error
error[E0599]: no function or associated item named `show_with_default_app` found for struct `plot::Plot` in the current scope
   --> C:\[...]\.cargo\git\checkouts\plotly-32f25712b3766afa\870dfc6\plotly\src\plot.rs:209:15
    |
96  | pub struct Plot {
    | --------------- function or associated item `show_with_default_app` not found for this
...
209 |         Plot::show_with_default_app(temp_path);
    |               ^^^^^^^^^^^^^^^^^^^^^ function or associated item not found in `plot::Plot`

@ykafia the function show_with_default_app is implemented only for linux, windows and macos which is why you're receiving this error. I haven't considered WASM integration yet however I'll be adding a few fixes that will help in that direction (see #26 )

@ykafia the function show_with_default_app is implemented only for linux, windows and macos which is why you're receiving this error. I haven't considered WASM integration yet however I'll be adding a few fixes that will help in that direction (see #26 )

Any progress on wasm integration?

@ykafia the function show_with_default_app is implemented only for linux, windows and macos which is why you're receiving this error. I haven't considered WASM integration yet however I'll be adding a few fixes that will help in that direction (see #26 )

Any progress on wasm integration?

There's a branch/fork somewhere that has removed some stuff that binds the library to desktop

There's a branch/fork somewhere that has removed some stuff that binds the library to desktop

@ykafia I'll try and add this in the next release; however given that I'm quite busy with work right now any help would be appreciated.


Translations update from Weblate (#7884)

Summary
Cherry pick of https://github.com/mattermost/mattermost-webapp/pull/7884 to cloud branch
Ticket Link
Related Pull Requests

Has server changes (please link here)
Has redux changes (please link here)
Has mobile changes (please link here)

Screenshots

Amy feel free to merge it when all is green


HV-999 Upgrading to TCK 1.1.4.Final; Adding tests removed from the TCK to HV's own tests

merged thanks.


Unable to read from a Kinesis stream

Hi,
I am trying to consume from a Kinesis stream with the following config:
input:
  type: kinesis
  kinesis:
    credentials:
      profile: "default"
    region: us-west-2
    start_from_oldest: true
    limit: 10
    stream: "stream_test"

output:
  type: file
  file:
    delimiter: ""
    path: "./logs.out"

This gives me a ResourceNotFoundException when I run benthos.
./benthos -c benthos-to-file.yaml
{"@timestamp":"2019-11-07T18:05:48-06:00","@service":"benthos","level":"INFO","component":"benthos","message":"Launching a benthos instance, use CTRL+C to close."}
{"@timestamp":"2019-11-07T18:05:48-06:00","@service":"benthos","level":"INFO","component":"benthos","message":"Listening for HTTP requests at: http://<IP_ADDRESS>:4195"}
{"@timestamp":"2019-11-07T18:05:51-06:00","@service":"benthos","level":"ERROR","component":"benthos.input","message":"Failed to connect to kinesis: ResourceNotFoundException: Shard shardId-000000000000 in stream stream_test under account<PHONE_NUMBER>68 does not exist\n\tstatus code: 400, request id: c68217c4-d806-1bbb-90bc-a46079e0c462"}
{"@timestamp":"2019-11-07T18:05:51-06:00","@service":"benthos","level":"ERROR","component":"benthos.input","message":"Failed to connect to kinesis: ResourceNotFoundException: Shard shardId-000000000000 in stream stream_test under account<PHONE_NUMBER>68 does not exist\n\tstatus code: 400, request id: c33fe856-e765-2026-9501-5bf311b0c07f"}
{"@timestamp":"2019-11-07T18:05:52-06:00","@service":"benthos","level":"ERROR","component":"benthos.input","message":"Failed to connect to kinesis: ResourceNotFoundException: Shard shardId-000000000000 in stream stream_test under account<PHONE_NUMBER>68 does not exist\n\tstatus code: 400, request id: d840d7f5-ff1a-1d90-8e7e-6450396fed41"}
However, at the same time using the AWS CLI, I am able to successfully consume messages using aws kinesis describe-stream --stream-name stream_test, aws kinesis get-shard-iterator --stream-name stream_test --shard-id shardId-000000000000 --shard-iterator-type TRIM_HORIZON, and aws kinesis get-records --shard-iterator <shardIterator>.
Can someone please help me understand where might I be going wrong?

Hey @krishnatg, are you sure that the region is set correctly? It might also be worth giving the kinesis_balanced input a try to see if it behaves differently. Let me know and I'll try and think of ways to help diagnose this.

Thanks for pointing out the potential problem with the region, @Jeffail ! Turns out that was the problem. AWS concepts are still quite new to me. I have a follow-up question around consuming avro-formatted data that I will ask on Slack. Thanks again for the prompt response 👍


Clean up test data

Delete or archive test projects and test institutions.  There is a flood of test and sample data that was never archived after testing.

Over half of the size of our database is filled with test data, mostly accidentally large gridded plots.


fix: apply public access to packages

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


@u4/opencv4nodejs cannot be used in worker threads

Environment

opencv4nodejs: 6.5.2
openvc: 4.9.0
nodejs: 18.16.1
macos: sonoma 14.4.1

Description of Issue
I'm attempting to offload image processing to workers using the native worker_threads library. The first time my application starts up a worker, runs the computation, and cleans up the worker, things work great. However, the second attempt to do so causes my whole app to crash silently. I noticed that commenting out any imports of @u4/opencv4nodejs in the worker files allows them to start and terminate as often as I like without issue. Upon investigating, I found the below resources related to context aware c++ addons.
Additional Resources

https://github.com/justadudewhohacks/opencv4nodejs/issues/555 - same open issue in the upstream repo
https://github.com/nodejs/node/issues/21481 - closed issue in nodejs further describing the problem
https://nodejs.org/docs/latest-v10.x/api/addons.html#addons_context_aware_addons - relevant nodejs documentation
https://github.com/UrielCh/opencv4nodejs/issues/43 - open issue in this library, same fundamental problem showing up there because electron runs multiple node instances

Given the computationally intensive nature of image processing, supporting workers in order to not block the main thread seems like it should be a requirement for this library. Creating a long running subprocess is not an option for me due to memory constraints. Happy to provide any more info/help land on a solution. Thanks!

Any news on this? Electron.js also dropped support for non-context-aware models, so I don't think opencv4nodejs can still run on current electron versions.

Same question ！！ hope to support, after all, imwrite blocking is too long
https://github.com/UrielCh/opencv4nodejs/issues/148


Adds the user home to the search path

Following to #59, added the functionality that look into user's home for the config files.
That code broke 2 tests, which I fixed and added alternate versions to include the user's home to the tests.

Closing as stale. If somebody would like to revisit this functionality, feel free to open a new PR.


[SPARK-20426] Lazy initialization of FileSegmentManagedBuffer for shuffle service.

What changes were proposed in this pull request?
When application contains large amount of shuffle blocks. NodeManager requires lots of memory to keep metadata(FileSegmentManagedBuffer) in StreamManager. When the number of shuffle blocks is big enough. NodeManager can run OOM. This pr proposes to do lazy initialization of FileSegmentManagedBuffer in shuffle service.
How was this patch tested?
Manually test.

Spark jobs are running on yarn cluster in my warehouse. We enabled the external shuffle service(--conf spark.shuffle.service.enabled=true). Recently NodeManager runs OOM now and then. Dumping heap memory, we find that OneFroOneStreamManager's footprint is huge. NodeManager is configured with 5G heap memory. While OneForOneManager costs 2.5G and there are 5503233 FileSegmentManagedBuffer objects.

Test build #76105 has started for PR 17744 at commit 5fb91bf.

Test build #76105 has finished for PR 17744 at commit 5fb91bf.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/76105/
Test FAILed.

Test build #76131 has started for PR 17744 at commit e38f0e8.

Test build #76132 has started for PR 17744 at commit a0a6594.

Test build #76131 has finished for PR 17744 at commit e38f0e8.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/76131/
Test PASSed.

Test build #76132 has finished for PR 17744 at commit a0a6594.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/76132/
Test PASSed.

We see the same issue on some of our clusters.  I was planning on doing 2 things. Something like this to reduce that memory usage and then on the other side you could change the shuffle fetcher to limit the # of blocks it fetches in one try.  The second is a separate jira though and could have the affect of slowing down the shuffle and could also not be as effective if its a ton of different reducers fetching but still a good option to have.
I think this approach is good for now. I ran a bunch of manual tests on the cluster and memory has greatly improved.
+1. Thanks @jinxing64

@tgravescs
Thanks a lot for merging.
I proposed to resolve this by "Lazy initialization of FileSegmentManagedBuffer" and simplify the change. But after checking the code, could we remove OpenBlocks. In my understanding, OpenBlocks is just a handshake before fetching remote blocks and could be removed conceptually(did I miss something?). This is just a brainstorming and will be a bigger change.

Yes conceptually it could be removed but as you say is a bigger change. Are you still seeing memory issues after this change?

Thanks again for help review this pr. Currently I'm not seeing memory issue on my nodemanagers. I'd report to community if there's new finding :)


Translate static labels

Add localization files. Files could be located in a better location.
Still missing template translations.

Looks good, will be testing shortly and updating the remaining French terms to be translated.
Thanks!


Improve invalid HTTP status code responses failure mode handling

If the model only uses the @http trait to define the response code, Smithy already checks that this is a valid status code, so the conversion cannot fail, and we can avoid rejecting with ResponseRejection::InvalidHttpStatusCode.
This commit also removes this variant from RPC protocols, where HTTP binding traits are not allowed, and so this failure mode can never happen.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.


Arduino uno support

How would this work, like over serial?

Yes I was hoping serial

Can you provide a bit more information about your request for Arduino Uno support? Are you wanting the code to run on the Uno standalone? (unlikely to be possible) Or are you wanting the Uno to act like the Node MCU, and the audio processing code would run on a computer? (would be possible)

@scottlawsonbc the audio processing code would be on the computer and it would communicate through serial

I just created a "issue" about the serial communication. It's working on a Nano with a very small (8 led) ring. I can't test with a larger array as I don't have one right now. There's nothing I can think of preventing it from working with a Uno as well.

Combining serial related discussion to #52


Colab Notebook Running Issue - standalone_get_prelogits()

When I try and run the following cell:
cifar10_test_prelogits, cifar10_test_logits, cifar10_test_labels = standalone_get_prelogits(
params,
cifar10_ds_test,
image_count=N_test
)
I get the error message below. Please help me resolve this issue :)
ERROR MESSAGE:
UnfilteredStackTrace: RuntimeError: UNKNOWN: Failed to determine best cudnn convolution algorithm for:
%cudnn-conv = (f32[128,24,24,1024]{2,1,3,0}, u8[0]{0}) custom-call(f32[128,384,384,3]{2,1,3,0} %copy, f32[16,16,3,1024]{1,0,2,3} %copy.1), window={size=16x16 stride=16x16}, dim_labels=b01f_01io->b01f, custom_call_target="__cudnn$convForward", metadata={op_name="jit(conv_general_dilated)/jit(main)/conv_general_dilated[window_strides=(16, 16) padding=((0, 0), (0, 0)) lhs_dilation=(1, 1) rhs_dilation=(1, 1) dimension_numbers=ConvDimensionNumbers(lhs_spec=(0, 3, 1, 2), rhs_spec=(3, 2, 0, 1), out_spec=(0, 3, 1, 2)) feature_group_count=1 batch_group_count=1 lhs_shape=(128, 384, 384, 3) rhs_shape=(16, 16, 3, 1024) precision=None preferred_element_type=None]" source_file="/usr/local/lib/python3.7/dist-packages/flax/linen/linear.py" source_line=371}, backend_config="{"conv_result_scale":1,"activation_mode":"0","side_input_scale":0}"
Original error: UNIMPLEMENTED: DNN library is not found.
To ignore this failure and try to use a fallback algorithm (which may have suboptimal performance), use XLA_FLAGS=--xla_gpu_strict_conv_algorithm_picker=false.  Please also file a bug for the root cause of failing autotuning.
The stack trace below excludes JAX-internal frames.
The preceding is the original exception that occurred, unmodified.

The above exception was the direct cause of the following exception:
RuntimeError                              Traceback (most recent call last)
/usr/local/lib/python3.7/dist-packages/flax/linen/linear.py in call(self, inputs)
369           dimension_numbers=dimension_numbers,
370           feature_group_count=self.feature_group_count,
--> 371           precision=self.precision
372       )
373     else:
RuntimeError: UNKNOWN: Failed to determine best cudnn convolution algorithm for:
%cudnn-conv = (f32[128,24,24,1024]{2,1,3,0}, u8[0]{0}) custom-call(f32[128,384,384,3]{2,1,3,0} %copy, f32[16,16,3,1024]{1,0,2,3} %copy.1), window={size=16x16 stride=16x16}, dim_labels=b01f_01io->b01f, custom_call_target="__cudnn$convForward", metadata={op_name="jit(conv_general_dilated)/jit(main)/conv_general_dilated[window_strides=(16, 16) padding=((0, 0), (0, 0)) lhs_dilation=(1, 1) rhs_dilation=(1, 1) dimension_numbers=ConvDimensionNumbers(lhs_spec=(0, 3, 1, 2), rhs_spec=(3, 2, 0, 1), out_spec=(0, 3, 1, 2)) feature_group_count=1 batch_group_count=1 lhs_shape=(128, 384, 384, 3) rhs_shape=(16, 16, 3, 1024) precision=None preferred_element_type=None]" source_file="/usr/local/lib/python3.7/dist-packages/flax/linen/linear.py" source_line=371}, backend_config="{"conv_result_scale":1,"activation_mode":"0","side_input_scale":0}"
Original error: UNIMPLEMENTED: DNN library is not found.
To ignore this failure and try to use a fallback algorithm (which may have suboptimal performance), use XLA_FLAGS=--xla_gpu_strict_conv_algorithm_picker=false.  Please also file a bug for the root cause of failing autotuning.

If I try to install the requirements.txt on a linux machine using pip install -qr vision_transformer/vit_jax/requirements.txt, pip is unable to install jaxlib. Could this be relevant?

Did you read his code ? Paper says they train a classifier on the in datasets(finetune), but all code used 'trained = False', and I can't find any opitmizer related code, how does the 'Dense' module update its parameters?


doesn't work in excalidraw.

Unfortunately, it doesn't work in excalidraw in drawing mode. nothing happens after clicking on any of the emojis. I even checked the markdown mode to see if there was something there, but it wasn't.

Can I recommend that you use the plugin with Twitter Emoji setting turned off. I've turned this off by default now in v0.4.0
If the problem still persists even with this turned off, feel free to re-open.


[5.57] Crash when teleporting to RFDimension

https://gist.github.com/1188aaaa51c011f151d7ef4e11e2a0d0
I'm pretty sure the dimension tab got destroyed
The crash happens where the world would normal start loading after entering the teleporter

Link doesn't work

Fixed the link
I also found out some more; There seems to be some underlying RFTDim bug that is repeatably causing newly created dimension tabs to show "Dimension information Missing!" after restarting minecraft and subsequently refusing to work and as a result of that the matter transmitter breaks and causes aforementioned crash on trying to teleport.

can confirm also happening to me all worlds get deleted on restarting minecraft all  become invalid

There is no crash in the provided log so that's not very useful for me. Does it crash client or server side? Is this single or multiplayer?
Sorry people, but I am going to need a lot more information then this. What exactly is your minecraft setup? Are you using a server? And I would need a real crash log.

thats sort of the problem jty there is no real crash log using the lastest RF tools dim thats public make a dimension in single player close mc open it back up the world is corrupt and gone and teleporting there of course crashes with a generic error as there is no dimension to go to

Well then I need more info on the mods you're using. Note that rftools dimensions is being used with no issues by several people so there must be something specific in your setup of mods that is causing this issue. Also did you try other dimension mods?

other dimensions seem to work fine its only RFtools dims i can post up a full mods list give me a few

http://pastebin.com/skZwc11w there we go

Does this happen for every single dimension? How many did you try? Does the dimension itself work while you're in it the first time?

every one i make yes i can go in there it works perfectly its only when closing out of minecraft fully down then restart it the world comes out like http://imgur.com/a/CUIpz this

Are you doing anything special when starting your world? What launcher are you using? That information is stored in a special location (saves/YourWorld/data/RFToolsDimensionManager.dat). It looks as if somehow that file is getting corrupted or overwritten

i am using curse saving is done normally nothing special at all other than firing it up make a dim then close and re-open and boom i will try making a dim in a brand new world just to make sure its not sthing strange like that but if  that does not work i can just drop you my mods/config folder if you would like so you can take a look see if its possible to de-bug whatever the hell cross mod conflict is causing it

I am also interested in the full log (the biggest logs in your logs folder) btw. Would like to see if there is something special in there

i will gladly send you everything i have on the instance see if you can work it out like 95% of the errors i get i can explain from a code stand point even and report accurately this just seems very obscure almost like on world load its losing the world info

https://www.dropbox.com/s/4h20lpfk2bbt2gx/mcinstance.rar?dl=0 thats the instance logs included no saves for size but it seems to happen in any world just make a quick world power it go in teleport back then close down mc all together open it back up and the world is broken using latest forge on curse

Not 100% sure but it might be a conflict with hardcore wither. I submitted a bug report to them:
https://gitlab.com/thor12022/HardcoreWither/issues/54
It would be great if you could temporarily remove that mod and try in a new world to see if the problem still occurs. That way we know for sure if it is that mod or not.
Thanks

welp i removed it and its still doing it sadly D'=

On a new world with new dimensions?

yeppers removed all the RFtools world files made a new world all together then made a new dim in that and still does it

Ok then (for now) I give up. No clue what can cause this

you have to click on the banner at the top to see the part of the log with the crash
"This file has been truncated, but you can view the full file."
I'm going though adding mods one by one right now looking for the culprit

Success! I replicated it with only these 3 mods so it looks like JEI is the mod causing the worlds to corrupt
forge-1.10.2-<IP_ADDRESS>8
jei_1.10.2-<IP_ADDRESS>1
rftools-1.10-5.57
rftoolsdim-1.10-4.43
and another time the crash log of trying to teleport to it with the RFTools block
https://gist.github.com/b9c27e41418f355cac830bd3daabefec

well that or some change to the newer forges

@mezz_mc Any explanation for how JEI could cause that?

I can reproduce this with that verison of JEI. We will investigate this
@mezz I can reproduce this now. Seems that version of JEI causes an issue with the rftools dimension information. Most likely cause is that fake world but as of now I have no clue why. This is a pretty critical bug though. Completely breaks my mod

Bug if fixed in 4.44


Failed to push the bundle following the steps in readme

root@kube-worker:~/workspace/src/github.com/docker/cnab-to-oci# bin/cnab-to-oci push examples/helloworld-cnab/bundle.json --target myhubusername/repo
Starting to copy image cnab/helloworld:0.1.1...
Error: image "cnab/helloworld:0.1.1" digest differs "" after fixup: "sha256:a59a4e74d9cc89e4e75dfb2cc7ea5c108e4236ba6231b53081a9e2506d1197b6"

Hi, @ywk253100,
Thanks a lot for reporting the issue!
#65 introduced a change in how we handle pushing images, so the current behaviour is that cnab-to-oci will fail if the registry generates a different content digest for any image referenced in the bundle.
    {
      "imageType": "docker",
      "image": "cnab/helloworld:0.1.1",
      "size": 42
    }
Error: image "cnab/helloworld:0.1.1" digest differs "" after fixup: "sha256:a59a4e74d9cc89e4e75dfb2cc7ea5c108e4236ba6231b53081a9e2506d1197b6"

(notice how the content digest obtained after pushing the image is different from the one initially included in the bundle).
The same change also introduced the --auto-update-bundle flag for push, which will automatically update the bundle with the new content digest.
The reason we chose not to do that by default is because this operation has to mutate your bundle file before pushing, and we believe this should be something a user should explicitly ask for.
That being said, we should absolutely have a working example in the readme, and should either:

update the readme to include the --auto-update-bundle flag for the push command
replace the example bundle with one that contains the content digest for the image - see below a minimal complete bundle example in canonical form:

{"description":"A short description of your bundle","invocationImages":[{"contentDigest":"sha256:a59a4e74d9cc89e4e75dfb2cc7ea5c108e4236ba6231b53081a9e2506d1197b6","image":"cnab/helloworld:0.1.1","imageType":"docker","mediaType":"application/vnd.docker.distribution.manifest.v2+json","size":942}],"keywords":["helloworld","cnab","tutorial"],"maintainers":[{"email":"jane.doe@example.com","name":"Jane Doe","url":"https://example.com"}],"name":"helloworld","schemaVersion":"v1.0.0-WD","version":"0.1.1"}

I hope this gives you a little context into what is happening.
Thanks a lot for reporting, keeping it open until we have a fix.


Show money and FTE in associations project list

As soon as it is clicked would be nice, but definitely needs to be there once associated when looking at existing associations.

Shannon allows left table to be small to compensate the new columns in the right table

Shannon allows left table to be small to compensate the new columns in the right table


Correct demo reference in Readme

at least, I assume that this is what's meant :-)

Sure, thanks.


Can't install the agent: Invalid signature (key: 8ADF7451)

Hello,
I'm trying to install the agent on Debian 9. I have installed jmx4perl-1.12.tar.gz
# jolokia --verbose download
* Loading Jolokia meta data from http://www.jolokia.org/jolokia.meta
* Added jmx4perl key
Invalid signature (key: 8ADF7451)

# jolokia --version
jolokia 1.12

# java -version
openjdk version "1.8.0_171"
OpenJDK Runtime Environment (build 1.8.0_171-8u171-b11-1~deb9u1-b11)
OpenJDK 64-Bit Server VM (build 25.171-b11, mixed mode)

I am also running into the same issue on Ubuntu 18.04 LTS.

There is something bad about a GPG key which is being provided by an upstream server.  I forget the details now, but with enough effort that could be tracked down.  You can get around this issue by removing gpg from your PATH, thereby reverting to using SHA-1 validation of the downloaded file instead of GnuPG calculations.  Possibly this is somewhat less secure (use of SHA-1 is no longer generally encouraged any more), but as a practical matter, when the recommended action is broken, decent access is better than no access.


Update cocoa pods trunk

Thanks for this library. The pod spec registered with cocoa pods does not point to the latest version of master. Can you update the pod spec with cocoa pods? Thanks!

@dbachrach Now it point to the latest version of master.


Threading not supported on pyfftw 0.13.1

Solution to issue cannot be found in the documentation.

[X] I checked the documentation.

Issue
I ran into an issue using pyfftw 0.13.1 from conda-forge when trying to use threads. This was previously (and is currently) working with pyfftw 0.12.
The error is:
>>> import numpy as np
>>> from pyfftw.interfaces.numpy_fft import rfftn
>>> arr = np.random.randn(86400)
>>> rfftn(arr, threads=2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/chambeca/miniconda3/envs/pyfftw-threaded/lib/python3.11/site-packages/pyfftw/interfaces/numpy_fft.py", line 286, in rfftn
    threads = _default_threads(threads)
              ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/chambeca/miniconda3/envs/pyfftw-threaded/lib/python3.11/site-packages/pyfftw/builders/_utils.py", line 114, in _default_threads
    raise ValueError("threads > 1 requested, but pyFFTW was not built "
ValueError: threads > 1 requested, but pyFFTW was not built with multithreaded FFTW.

I replicated this in a fresh environment created using:
conda create -n pyfftw-threaded -c conda-forge pyfftw

Creating a similar fresh environment with pyfftw==0.12 does not result in the error.
I'm running into this error across all operating systems and python 3.[8-11] in tests here associated with this PR
Installed packages
# packages in environment at /home/chambeca/miniconda3/envs/pyfftw-threaded:
#
# Name                    Version                   Build  Channel
_libgcc_mutex             0.1                 conda_forge    conda-forge
_openmp_mutex             4.5                       2_gnu    conda-forge
bzip2                     1.0.8                h7f98852_4    conda-forge
ca-certificates           2022.12.7            ha878542_0    conda-forge
ld_impl_linux-64          2.40                 h41732ed_0    conda-forge
libblas                   3.9.0           16_linux64_openblas    conda-forge
libcblas                  3.9.0           16_linux64_openblas    conda-forge
libffi                    3.4.2                h7f98852_5    conda-forge
libgcc-ng                 12.2.0              h65d4601_19    conda-forge
libgfortran-ng            12.2.0              h69a702a_19    conda-forge
libgfortran5              12.2.0              h337968e_19    conda-forge
libgomp                   12.2.0              h65d4601_19    conda-forge
liblapack                 3.9.0           16_linux64_openblas    conda-forge
libnsl                    2.0.0                h7f98852_0    conda-forge
libopenblas               0.3.21          pthreads_h78a6416_3    conda-forge
libsqlite                 3.40.0               h753d276_0    conda-forge
libstdcxx-ng              12.2.0              h46fd767_19    conda-forge
libuuid                   2.32.1            h7f98852_1000    conda-forge
libzlib                   1.2.13               h166bdaf_4    conda-forge
ncurses                   6.3                  h27087fc_1    conda-forge
numpy                     1.24.2          py311h8e6699e_0    conda-forge
openssl                   3.0.8                h0b41bf4_0    conda-forge
pip                       23.0.1             pyhd8ed1ab_0    conda-forge
pyfftw                    0.13.1          py311hcb2cf0a_0    conda-forge
python                    3.11.0          he550d4f_1_cpython    conda-forge
python_abi                3.11                    3_cp311    conda-forge
readline                  8.1.2                h0f457ee_0    conda-forge
setuptools                67.5.1             pyhd8ed1ab_0    conda-forge
tk                        8.6.12               h27826a3_0    conda-forge
tzdata                    2022g                h191b570_0    conda-forge
wheel                     0.38.4             pyhd8ed1ab_0    conda-forge
xz                        5.2.6                h166bdaf_0    conda-forge

Environment info
active environment : pyfftw-threaded
    active env location : /home/chambeca/miniconda3/envs/pyfftw-threaded
            shell level : 3
       user config file : /home/chambeca/.condarc
 populated config files : /home/chambeca/.condarc
          conda version : 22.11.1
    conda-build version : 3.21.9
         python version : 3.9.15.final.0
       virtual packages : __archspec=1=x86_64
                          __cuda=12.0=0
                          __glibc=2.37=0
                          __linux=5.15.94=0
                          __unix=0=0
       base environment : /home/chambeca/miniconda3  (writable)
      conda av data dir : /home/chambeca/miniconda3/etc/conda
  conda av metadata url : None
           channel URLs : https://conda.anaconda.org/conda-forge/linux-64
                          https://conda.anaconda.org/conda-forge/noarch
                          https://repo.anaconda.com/pkgs/main/linux-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/linux-64
                          https://repo.anaconda.com/pkgs/r/noarch
          package cache : /home/chambeca/miniconda3/pkgs
                          /home/chambeca/.conda/pkgs
       envs directories : /home/chambeca/miniconda3/envs
                          /home/chambeca/.conda/envs
               platform : linux-64
             user-agent : conda/22.11.1 requests/2.28.1 CPython/3.9.15 Linux/5.15.94-1-MANJARO manjaro/22.0.4 glibc/2.37
                UID:GID : 1000:1000
             netrc file : None
           offline mode : False

I see a similar issue downstream in https://github.com/conda-forge/fbpic-feedstock/pull/1
Can you enable threading for pyFFTW?
https://github.com/pyFFTW/pyFFTW/issues/294

I think there is an inconsistency on Linux/macOS.
Upstream fftw-static is build with OpenMP, not threads:
https://github.com/conda-forge/fftw-feedstock/blob/e3fcf707566c5d71f7302ff4943eb0a4006e1bcb/recipe/build_fftw.sh#L18
but the feedstock here uses threads, not OpenMP:
https://github.com/conda-forge/pyfftw-feedstock/blob/6b0c1880fc91742f98c6aec6e69ee7838324e647/recipe/build.sh#L8-L9

When OpenMP was added to FFTW, it was our understanding that pthreads support would remain ( https://github.com/conda-forge/fftw-feedstock/pull/46#issuecomment-442564040 ),
the flag in PyFFTW is intended to use pthreads ( https://github.com/conda-forge/pyfftw-feedstock/pull/29 )
The static library should include threads support too
Am guessing there is something else going on

I think this is due to failures in the test builds to detect the FFTW+pthreads static libraries. That causes the extension to build without any threading support leading to the errors. I think #60 should fix that problem.

Finally fixed by https://github.com/conda-forge/pyfftw-feedstock/pull/60!


ignore build on appengine

Hi.
When I deploy my application with the kami on the appengine, I caught the following error:
$ goapp deploy .
:
: snip
:
04:52 PM Error 422: --- begin server output ---
Compile failed:
2015/08/30 00:52:19 go-app-builder: Failed parsing input: parser: bad import "syscall" in github.com/zenazn/goji/graceful/einhorn.go
--- end server output ---
: snip

The kami use graceful package at serve.go. This package use syscall package, so compile failed.
So serve.go file ignore on appengine.
$ goapp version
go version go1.4.2 (appengine-1.9.25) darwin/amd64

Thanks.

Hello, thank you for the fix! This seems to have been caused by a Goji change from January.
I will add a Serve() function for appengine after I merge this.


Add Vultr and DO Marketplace links

as title + smal fix

Codecov Report

Merging #16297 (d9bd661) into main (6554835) will increase coverage by 0.00%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main   #16297   +/-   ##
=======================================
  Coverage   45.42%   45.43%
=======================================
  Files         709      709
  Lines       83500    83500
=======================================
+ Hits        37929    37936    +7
+ Misses      39490    39484    -6
+ Partials     6081     6080    -1

Impacted Files
Coverage Δ

models/unit.go
41.09% <0.00%> (-2.74%)
:arrow_down:

modules/log/event.go
58.96% <0.00%> (-0.95%)
:arrow_down:

modules/queue/workerpool.go
53.81% <0.00%> (-0.77%)
:arrow_down:

routers/web/repo/view.go
40.88% <0.00%> (-0.58%)
:arrow_down:

routers/api/v1/repo/pull.go
28.74% <0.00%> (+0.59%)
:arrow_up:

modules/log/file.go
75.39% <0.00%> (+1.58%)
:arrow_up:

modules/notification/mail/mail.go
38.23% <0.00%> (+1.96%)
:arrow_up:

modules/process/manager.go
75.30% <0.00%> (+2.46%)
:arrow_up:

modules/queue/manager.go
68.36% <0.00%> (+2.82%)
:arrow_up:

services/mailer/mail_comment.go
85.18% <0.00%> (+7.40%)
:arrow_up:

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 6554835...d9bd661. Read the comment docs.


Add support for footnotes

Footnotes should be supported. Footnotes should be shown at the bottom of the respective pages.

I'm actually quite fond of footnotes, and at this point, the only problem I see with their support is that footnotes from internal sections show up on all the corresponding parent pages. Is that the core of the problem - filtering out footnotes that don't belong, and re-indexing them so there are no holes in their numbering on individually separated pages?

That's correct. We should also check (and include in tests) a footnote inside a block style table cell (nested document) to make sure that works properly.

The problem is still there. Used 0.0.18 to generate multipage version of asciidoc book (400paged pdf).
Got nice look for online help, but footnotes messed up the whole thing.
I'm using nested includes, may they be the cause?

I'm using nested includes, may they be the cause?

This is probably not related to nested includes.

This issue requires #46 to be done first.


How do I put the bar in the middle of the screen ?

How do I put the bar in the middle of the screen ? I will use the top part for something else

Duplicate of #720
hey, you can check out the following.

@DhruvTekchandani how can I do it programmatically


Nx moving JS graph building to new location

Current Behavior
@nx-plus/vue doesn't use the plugin project graph API that was released in Nx 12.X, instead, it patches part of Nx's code on postinstall. The file that is patched is being renamed on Nx's side of things, so this will break either before v16 or at v16, depending on how we release our changes.
Expected Behavior
@nx-plus/vue uses the plugin project graph API, or at minimum adds the new path to the getPath function inside the patching code.
https://github.com/ZachJW34/nx-plus/blob/master/libs/vue/patch-nx-dep-graph.js#L28
Steps to Reproduce

Check out the branch from https://github.com/nrwl/nx/pull/15365 and attempt to use @nx-plus/vue's graph support on a codebase with that branch's code installed
Note error.

Im going to close this out since v17 of nx has first party support for vue.


Refactor app/pkg init logic

What this PR does / why we need it:
Refactors and cleans up app/package init logic
Which issue(s) this PR fixes:

Fixes #827
Does this PR introduce a user-facing change?

NONE

Review Checklist:

[ ] Follows the developer guidelines
[ ] Relevant tests are added or updated
[ ] Relevant docs in this repo added or updated
[ ] Relevant carvel.dev docs added or updated in a separate PR and there's
a link to that PR
[ ] Code is at least as readable and maintainable as it was before this
change

Additional documentation e.g., Proposal, usage docs, etc.:

Gotta work towards wrapping up pending cleanup on this through a bunch of reviews @praveenrewar


Request to support per-player view distance

Referencing this sponge thread
Would it be possible to support per-player view distance? A method to send a certain amount of chunks based on a player's individual setting (either specified by them or the server) would be unbelievable. I stumbled upon paperspigot, and apparently they support this feature.
In any case, thanks for the great work you guys do on Sponge!

Would this prevent the chunks from even loading? or is this just a move to save on serialization / sending to the player?

The related Paper patch can be found here - https://github.com/PaperMC/Paper/blob/master/Spigot-Server-Patches/0036-Add-player-view-distance-API.patch

@dags- I saw you were working on a plugin like this. If you wanted to make PRs to Sponge or at least provide some feedback on how you'd like to see this done in the API that would be fantastic!

https://github.com/SpongePowered/SpongeAPI/pull/1659 has merged per world view distances FYI.

World and Player both have methods 'getViewDistance' which refer to different things:

World's being the radius of chunks around a player which get sent to the client etc.
Player's being the clientside view-distance setting (clarified in Common).

To me, 'get/setChunkRadius' (or similar) makes sense for the server-side notion of chunks around a player (the server setting doesn't change the client-side view-distance), but even in the server.properties file it's called 'view-distance'.
Alternatively the method currently in Player could just be renamed to 'getClientViewDistance'.
I'm a little out of touch with the latest Sponge developments in all honestly so not sure what the preferred plan of attack would be.
Other than getter/setters, a reset method as added to the per-World PR would be a good idea.


Add validation pass for barrier instructions.

@atgoo this is marked as Done in the validator project.  If it's done, please reference the PR and close this issue.

Fixed by https://github.com/KhronosGroup/SPIRV-Tools/pull/1259


hosting error

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. Mac m2]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone XR]
OS: [e.g. iOS1 5.5]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.
I bought my hosting, i specified its ip in seashell but listening still doesn't work, how can i configure seashell to work in wan?

@kenzWeb Make sure that <IP_ADDRESS> is a correct IP address and is available through one of the network interfaces on your computer. To check all IP addresses available, type ifconfig command in your terminal. This error only appears if IP address is invalid, so please check it.

<IP_ADDRESS> is the ip address of my host, I enter it on my mac and listening does not work, and now myself and the command "listener" does not work

It is not how IP addresses work. You need to start listener on host that belong to you machine. I am closing this issue, because the problem is not related to SeaShell.


TEIIDTOOLS-738: Errors with CORS, setting of SB2 specific servlet con…

…text, and marking the POST,PUT requests with BODY payloads

Pulled locally land was successful in deploying a syndesis-dv pod :)

super! There are a couple of issues on UI side and backend side which do not involve with SB2 migration, which are related to view creation. I will see if I can submit PR for that.


TS server - call tsc programmatically from Node.js server

I have the following command, which I run in a new child process, and which will transpile a single file:
tsc --skipLibCheck --noResolve --jsx react --module amd --target es5 /foo/bar/baz

I am looking to speed this up by 500ms. This command probably takes 300ms to warm up and run. I can probably do this if I can issue this command programmatically from a pre-running process (a.k.a server).
Is there a way to call tsc programmatically from inside a Node.js server? This is the feature I am looking for - calling tsc programmatically instead of from the command line.

The problem with tsc -w is that is transpiles all the .ts/tsx files in my project upon a change to only one file. In this case I only want to transpile the one file that changed.

Should I write my own using this:
https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API
?

The docs you found describe how to do what you want to do. The ts.transpile function will likely be the fastest possible way to transform a single file

@RyanCavanaugh thanks, I will work with those docs


Feature: backend auth

Hi guys
thank you very much for this plugin.
This is something I've worked on too (based on the older OCMS plugin that is based on a pre v1.0 version of tymon/jwt-auth),
and I was very happy when I saw your great implementation.
One thing I want for an OCMS JWT Auth plugin is the possibility to also use it for backend user accounts,
to be able to use the OCMS permissions and roles system and to access non-personal data for background services or frontend app access.
It would be great if you could check out what I have done so far in my fork at https://github.com/marcogrueter/JWTAuth/tree/feature-backend-auth
The implementation is rather simple. The differentiation between the user resolvers is simply handled by looking at the request route, see https://github.com/marcogrueter/JWTAuth/blob/feature-backend-auth/Plugin.php#L53.
Everything else is basically copied and adapted from your work.
Any feedback or comment is welcome, and of course I am willing to work on it if you think this would be something good for the plugin.
I'm currently using it together with another plugin (https://github.com/octobroid/oc-api-plugin/) to create REST API endpoints in Plugins.
This way I can create backend users that have certain roles and permissions set in the OctoberCMS settings and can check for those permissions in my API endpoints, for example:
        // check permissions
        $user = app('JWTGuard')->user();

        if(!$user->hasPermission('medworld.eventmanager.api.list_events')) {
            abort('403', 'Permission denied');
        }

And since the roles and corresponding permissions are sent with the user object after the authentication,
it would also be possible for the client-side to work with them. Example excerpt after loggin in:

Thank you and kind regards
Marco

Hi! Create a PR with proposed changes, and we will review them as soon as possible. Thanks.

@marcogrueter After talking with @LeMaX10 we decided that this functionality doesn't meet our goals in security concerns. If you believe that there is a need in this functionality on market - you can create your own plugin that extends ours, and add new resolver for BackendAuth gateway.

Thank you for your feedback!


manager: speed up the volume starting time

We can reduce the liveness check retry interval
Start replica and controller at the same time, then add the replicas to the controller.

With the refactoring code, the speed of attaching/detaching is even slower. We have to fix this before the release.

There are still a few significant lags when putting the system on load, e.g. by starting a volume with 10 replicas.
One problem has been identified is when instance manager starts the process and reports back to the Longhorn manager, the manager can take more than 1 second to change the replica or engine state to Running. A significant part of that has been spent on the call to update Instance Manager's status (https://github.com/longhorn/longhorn-manager/blob/e59e4724e654b25304a6ac90814ab657bba830a5/datastore/longhorn.go#L1349 ). It's not much we can do about it now, unless we separate the instances into their own CRDs.

Another identified problem is also related to the time to run update API to Kubernetes. The process of setting the desired state to running for the replica can delay (https://github.com/longhorn/longhorn-manager/blob/e59e4724e654b25304a6ac90814ab657bba830a5/controller/volume_controller.go#L776 ). The root cause of the delay is similar to the previous issue, that UpdateReplica call may also take more than 1 second to execute (https://github.com/longhorn/longhorn-manager/blob/e59e4724e654b25304a6ac90814ab657bba830a5/datastore/longhorn.go#L616).
Those two problems can explain most of the gap between the time spent on the Longhorn manager part vs the time spent on the instance manager part.

During the POC, start engine and replica at the same time probably would only save about 1 second of the time when the load is light. All the engine and replicas can be up in 2 seconds but it will still take a couple of seconds for the engine to add all the replicas. We can revisit the idea to see if it's more helpful during the heavy workload in the future.

Consider it's done for the current stage.
For the next step, we also may optimize the instance manager to start the Longhorn process faster. Currently, it took about 1.2 seconds to start a replica process, 2.4 seconds to start an engine process (including starting the block device frontend) in our development environment.


Adding IsWorkflowExecutionAlreadyStartedError helper

Adding IsWorkflowExecutionAlreadyStartedError to make is easier to detect if an error to execute means that the workflow to execute is already running.

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

Pull Request Test Coverage Report for Build 219db680-6598-43d7-92f0-ca23bd94f24f

0 of 4 (0.0%)  changed or added relevant lines in 1 file are covered.
5 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.07%) to 75.692%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

error.go
0
4
0.0%

Files with Coverage Reduction
New Missed Lines
%

internal/internal_task_pollers.go
2
73.85%

internal/common/convert.go
3
84.62%

Totals

Change from base Build 223462fb-362b-4c54-92a8-407788d3661a:
-0.07%

Covered Lines:
8918

Relevant Lines:
11782

💛  - Coveralls


Update some mate packages patch version

Motivation for this change
Update some mate packages patch version:
mate.mate-user-guide: 1.22.2 -> 1.22.3
mate.mate-system-monitor: 1.22.1 -> 1.22.2
mate.mate-settings-daemon: 1.22.0 -> 1.22.1
mate.mate-session-manager: 1.22.1 -> 1.22.2
mate.mate-screensaver: 1.22.1 -> 1.22.2
mate.mate-power-manager: 1.22.1 -> 1.22.2
mate.mate-panel: 1.22.1 -> 1.22.2
mate.mate-notification-daemon: 1.22.0 -> 1.22.1
mate.mate-menus: 1.22.0 -> 1.22.1
mate.mate-media: 1.22.1 -> 1.22.2
mate.mate-indicator-applet: 1.22.0 -> 1.22.1
mate.mate-icon-theme: 1.22.1 -> 1.22.2
mate.mate-desktop: 1.22.1 -> 1.22.2
mate.mate-control-center: 1.22.1 -> 1.22.2
mate.mate-calc: 1.22.1 -> 1.22.2
mate.mate-applets: 1.22.1 -> 1.22.2
mate.marco: 1.22.2 -> 1.22.3
mate.libmateweather: 1.22.0 -> 1.22.1
mate.eom: 1.22.1 -> 1.22.2
mate.caja-extensions: 1.22.0 -> 1.22.1
Tested on a VM.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

I can test this in a VM today @romildo and review the patch releases.

@GrahamcOfBorg build mate.caja-extensions mate.eom mate.libmateweather mate.marco mate.mate-applets mate.mate-calc mate.mate-control-center mate.mate-desktop mate.mate-icon-theme mate.mate-indicator-applet mate.mate-media mate.mate-menus mate.mate-notification-daemon mate.mate-panel mate.mate-power-manager mate.mate-screensaver mate.mate-session-manager mate.mate-settings-daemon mate.mate-system-monitor mate.mate-user-guide

Seeing these errors in the journal
Unable to contact datetime settings daemon: Error calling StartServiceByName for org.mate.SettingsDaemon.DateTimeMechanism: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ServiceNotFound: Bus name not found in system service directory

Other than this, everything seems fine when testing in a VM.


Split container images by server type and replace supervisord by tini

Closes #526
A couple of other changes:

Only run OA4MP setup script for origin container
Added .dockerignore to ignore static files and node_moduels
Only log into harbor when it's in pelican main repo, as thing for push container
Merge release-container.yml with publish-container.yml to reuse most of the logic and renamed various container-related actions to be clear
Cached container image build to GHA cache

If we want to make containers as lightweight as possible, the S3 plugin only needs to be added to origin images. Lotman will only need to be in cache containers.

If we want to make containers as lightweight as possible, the S3 plugin only needs to be added to origin images. Lotman will only need to be in cache containers.

@jhiemstrawisc  Agree. There's a ton of dependencies only for origin/cache. Director and registry can mostly run out of the pelican binary without any dependency. I'd like to clean that up which can also speed up the building speed for director and registry image, but Brian suggests to hold on doing that, rather, get the idea work first. So I guess the dependency split will be a separate ticket

LGTM. Thanks!

Thanks! Looking forward to trying it out.


Update tsconfig.json

Note: This is fixing an issue that was reported in Discord (https://discordapp.com/channels/415874313728688138/596276596319453207/634682707435323402) relating to VSCode not finding this.$q type reference when using Object syntax for components.


Incorrect Download URL

It appears the location has been changed and not updated in the tutorial.
sudo pip install --upgrade https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow-0.8.0-cp27-none-linux_x86_64.whl

Collecting tensorflow==0.8.0 from https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow-0.8.0-cp27-none-linux_x86_64.whl
  HTTP error 404 while getting https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow-0.8.0-cp27-none-linux_x86_64.whl
  Could not install requirement tensorflow==0.8.0 from https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow-0.8.0-cp27-none-linux_x86_64.whl because of error 404 Client Error: Not Found for url: https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow-0.8.0-cp27-none-linux_x86_64.whl
Could not install requirement tensorflow==0.8.0 from https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow-0.8.0-cp27-none-linux_x86_64.whl because of HTTP error 404 Client Error: Not Found for url: https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow-0.8.0-cp27-none-linux_x86_64.whl for URL https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow-0.8.0-cp27-none-linux_x86_64.whl

Getting the same error.

Same.

Same!!!

Same!! :(

It's still 0.8.0rc0, we changed the install instructions before we uploaded the new packages.  Sigh.
Example:
https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow-0.8.0rc0-cp27-none-linux_x86_64.whl

Not sure if this one is the new?
https://pypi.python.org/packages/2.7/r/requests/requests-2.0.0-py2.py3-none-any.whl#md5=6af9c16dbddd2fc751ae4f1606d041e8

This works for mac:
sudo pip install --upgrade https://storage.googleapis.com/tensorflow/mac/tensorflow-0.8.0rc0-py2-none-any.whl

Fixed in github, pushed to website.

I'm stil getting the same error

I still get the same error

Following the installation instructions here when I run this it works
export TF_BINARY_URL=https://storage.googleapis.com/tensorflow/mac/cpu/tensorflow-0.11.0rc1-py3-none-any.whl

BUT on the next step of
pip3 install --upgrade $TF_BINARY_URL

I get the error HTTP error 404 while getting https://storage.googleapis.com/tensorflow/mac/cpu/tensorflow-0.11.0rc1-py3-none-any.whl

Same here 😭

I install tensorflow in conda environment and it worked. Maybe you should give a try.
After installing anaconda make sure to set your path. Or else it would conda: command not available.

Use this URL: https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow-0.11.0rc0-cp27-none-linux_x86_64.whl
It works (replace rc1 for rc0)

it works to install but doesn't work to run because it wants cuda 7.5 and the latest is 8 :P

create a simlink on the cuda 7.5 file to cuda 8.0 file with a same name and it works :P

Maybe you can just
cpu
pip install tensorflow
gpu
pip install tensorflow-gpu


Port to dotnetcore

Port from regular .NET to .NET core in order to provide xplat support.
Please don't mind the amount of commits - it's been a rough ride with only AppVeyor to build ;-)

How does this work with SonarQube? You expressed some concerns in issue #6

@simondel updated to include .NET core info. It works with SonarQube (see last comment on the issue):

the sonar-msbuild-scanner looks for a ProjectGuid in the .csproj file - I have included placeholders there.
it only works if the targets are in the right place. I have updated the InitializeSonarqubeAnalysis.bat file to copy the targets to the correct location.
I have replaced OpenCover with DotCover so we can use it anyway.

Thanks for the hard work!

Agreed. You've done a lot:)


Catch out of memory exceptions while inspecting download of large files

This solves #88.
@jasta that should do (solution 1), right?

Also per https://help.github.com/articles/closing-issues-via-commit-messages/, please write "Closes #88" in the commit message, ideally on the last line by convention.

@jasta good for ChromeDevToolsServer and NetworkEventReporterImpl.
I'm not sure on what to do with Network, is there a standard way to communicate the failure with chrome dev tools? I guess throwing a JsonRpcException would do the trick but I'm not sure.

Yes I think Network should use a JsonRpcException.  This will cause it to show up in the Console as an error.

Great, done. Thank you a lot for being so patient and guiding me through it :)

Looks good except the one minor issue about which ErrorCode you're using.  Feel free to squash/rebase into a single commit, then I can merge.

Awesome, thanks!


Fix log store ut

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (e073fe2) 47.65% compared to head (8f6e186) 58.60%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff             @@
##           master     #304       +/-   ##
===========================================
+ Coverage   47.65%   58.60%   +10.95%
===========================================
  Files         107      107
  Lines        9271     9202       -69
  Branches     1197     1174       -23
===========================================
+ Hits         4418     5393      +975
+ Misses       4390     3290     -1100
- Partials      463      519       +56

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


All links should be "pretty" by default

Pretty links allow urls like http://treo/somename where the source page "somename.html" gets saved as index.html in a parent folder named somename:
somename
|__ index.html

Done. Yes!


Update code for diamond operator

Thank you for your pr.  But we think the code should can be compile base on jdk6. So we can't  accept the pr. Thank you very much.