Local files

The python requests module supports only http(s) (c.f. https://stackoverflow.com/questions/10123929/fetch-a-file-from-a-local-url-with-python-requests)
Only use it if the schema starts with http(s). Otherwise assume it is a local file.
Tested locally, works as expected.

PS. It would be nice if you could tag the new commit with v0.0.4 upon merging, so that I can use it instead of my own fork for pre-commit. Thanks :D


Block entities arent removed from the inventory when placed

Some block entities (beds, chest, doors etc.) arent removed from the inventory when they are placed in survival mode.

Duplicate of #1700.


How to fetch next page with searchRequest?

Hello,
I can't find how to fetch next page with searhRequest?
I did call first like this.
mDriveSearchCollectionPage = mGraphServiceClient.getMe().getDrive()
//.buildRequest(searchOptions).expand("thumbnails").get();
.getSearch(queryValue).buildRequest()
.select("id, folder, file, name, size, lastModifiedDateTime, createdDateTime, webUrl")
.expand("thumbnails")
.top(500)
.get();
And, I try to use this code for fetching next page.
while (items != null) {

			if (mDriveSearchCollectionPage.getNextPage() == null)
				break;

			items = mDriveSearchCollectionPage
					.getNextPage()
					.buildRequest()
					.get()
					.getCurrentPage();
		}

But, it doesn't not works.
If someone know how to fetch next page with SearchRequest, please help me.
Thank you,

Thank you for reaching out and for your patience. This SDK is being officially deprecated. See #172 for more information


fix broken build by vendoring pkgs

Bug fix
Fixed bug

This is based on https://github.com/PranayShirodkar/rmf_demos/tree/feature/add_speed_limits however the same problems exist on the main branch. rmf_demos_fleet_adapter uses a number of python packages not available in ros humble, these packages are not declared in package.xml so it will not work without manually installing those packages.
There will be errors like:
ModuleNotFoundError: No module named 'fastapi'

Fix applied

Most of the packages are available in ubuntu repos but they are outdated, declaring them in package.xml will cause an incompatible version to be installed. The fix applied is to instead vendor these packages.

As of Ubuntu 24.04 the package mismatch issue of fastapi has been addressed, and with #211 they are specified as dependencies and installed from apt so this should no longer be needed.


fix: upgrade tcp and file reporter fixes http headers reporting

Issue
https://github.com/gravitee-io/issues/issues/7741
Description
fix: upgrade tcp and file reporter fixes http headers reporting

🚀 CI was able to deploy the build of this PR, so you can now try it directly here
Notes: The deployed app is linked to the management API of APIM master. (Same login and password as APIM master)

The version for both reporters has been released so we can update the properties to use the stable versions, and I think we should target 3.15.x no?

Closing in favor of https://github.com/gravitee-io/gravitee-api-management/pull/1981


Feature request: modify document ID during sync

(see Question at the end)
I have sync'd an index between Firestore and Algolia. In my case it's a subcollection of feed items, such that when User1 creates a post (let's call it Post1), if User2 and User3 follow User1, they both get a copy of Post1 in a subcollection.
Here is the data structure, then, after creation/replication:
// posts/{postId}
// users/{userId}/feed/{postId}

posts/Post1 // authorId === User1
users/User1/feed/Post1 // User1's copy of their own post
users/User2/feed/Post1 // User2's copy of the post
users/User3/feed/Post1 // User3's copy of the post

You may already see the problem here: I have 3 documents with the same document ID (Post1).
In Firestore land, this is totally fine; typical use cases generally query subcollections with this sort of syntax: query.collection(users/${userId}/feed).get() - in other words, you've already automatically filtered the returned feed items to prevent duplicate Ids.
In Algolia, it appears that with this configuration, the documents are simply re-written many times, and there is only one copy of Post1 in the end.

Question: perhaps this can be solved with a Transform Function Name function? If so, how would I change the document Id...? I can experiment with this next week, but the documentation here is very light, so I don't want to sink too much time into it if the maintainers can simply speak to it here.

Maybe it is the same problem, right? https://github.com/algolia/firestore-algolia-search/issues/171
In the v1.1.1 it was working properly

Could be the same root cause/fix, but the goal is different: this issue/request deals with overlapping/colliding document IDs, and #171 is dealing with overlapping/colliding collection names.
So I would say it is a different thing.

hello @go-sean-go I have created a RC of the extension that allows you to change the Object in the configuration.  Please try it out and let me know if it solves your problem<EMAIL_ADDRESS>

@smomin Can you confirm how to use the field?
Are the valid values either (a) (path) or (b) a document field/property name (e.g. authorId or something)?
In the case of option (b), must the value of the property name remain stable? Or, if it changes over time (some time after create), would the object ID of the document on the Algolia side change as well?

The valid values are below:
(path) use the document path
authorId  it will get the document attribute

thanks @smomin - regarding my other question using e.g. the authorId:

must the value of the property name remain stable? Or, if it changes over time (some time after create), would the object ID of the document on the Algolia side change as well?

Basically, if the authorId value changes, what happens? Does it change the object ID at Algolia? Or does it only consider the value on initial sync and leave it alone afterward? Or, would it be naive of the Algolia state and simply create a new document? (Would that leave the old one orphaned?)
I'm trying to consider the practical use case for the property value option.

Separately, a question on the (path) option: what are the limits here on the Algolia side? I ask because Firestore's limits on a path are rather extreme (per their docs): paths may have up to 100 segments, each with IDs up to 1,500 bytes, and document names can be up to 6kb, etc. Meaning these paths could be thousands of characters. I imagine Algolia will choke on that? But maybe not - maybe a 1,000 character Algolia ID is fine...? But probably not preferred.

Considering these scenarios, if I might suggest a simpler feature to solve the original issue + avoid these scenarios (which would likely be unintended from the user side): perhaps we should simply offer a simple checkbox option that hashes the full path (VERY LONG STRING) to a standard UUID-length string. This would provide uniqueness, idempotency, and I believe handle even extreme edges of the Firestore quotas - if I'm reading it right & thinking about it right.
Anyway, just my two cents. Let me know about the above.

I haven't re-tested since my original comment - so I'm not sure. If no changes have been made to the feature/code, then yeah, my questions would still be outstanding.
Overall, per my comments above, I don't think the current solution is very durable or clear. The hash mechanism I suggested above would be something to explore (not my area of expertise), I believe - as long as it has a sufficiently large capacity.
To repeat my concerns:

I don't actually understand the inner-workings of the property-name approach, but I have some inferred questions above.
I believe the (path) approach is flawed because Firestore has very extreme limits on # of subcollections and so on (meaning: someone using Firestore in a valid/supported way will probably exceed Algolia's object ID limits, I'm guessing?).
I think the right solution to this problem is probably to offer some idempotent mechanism to generate a new, unique document ID - or do nothing bespoke on this extension, but allow the user modify it by whatever arbitrary code (cloud function?) they like (my understanding is that the existing transform functions don't let you modify the obj ID, but that could be incorrect?).


Ambiguity of nodes with omitted inputs

  <mix name="myMix" type="color3">
    <input name="fg" type="color3" nodename="upstreamA" />
    <input name="bg" type="color3" nodename="upstreamB" />
  </mix>

This node could resolve to one of two different node definitions in the standard library.
  <nodedef name="ND_mix_color3" node="mix" nodegroup="compositing">
    <input name="fg" type="color3" value="0.0, 0.0, 0.0" />
    <input name="bg" type="color3" value="0.0, 0.0, 0.0" />
    <input name="mix" type="float" value="0.0" uisoftmin="0.0" uisoftmax="1.0" />
    <output name="out" type="color3" defaultinput="bg" />
  </nodedef>
  <nodedef name="ND_mix_color3_color3" node="mix" nodegroup="compositing">
    <input name="fg" type="color3" value="0.0, 0.0, 0.0" />
    <input name="bg" type="color3" value="0.0, 0.0, 0.0" />
    <input name="mix" type="color3" value="0.0, 0.0, 0.0" uisoftmin="0,0,0" uisoftmax="1,1,1" />
    <output name="out" type="color3" defaultinput="bg" />
  </nodedef>

For the purposes of the document itself, this ambiguity is actually unimportant, because the implementations of both node definitions will behave the same if there is no mix parameter provided. But this becomes an issue for MaterialX integrations that resolve to a node definition.
I first discovered this while debugging an issue when using the UsdMtlx plugin.  The myMix node above resolves to ND_mix_color3_color3 in UsdMtlx, but I happened to have wanted ND_mix_color3 because I had other USD layers that were going to author an edit to the mix input on the generated shader node.
After discovering this I decided to look elsewhere, closer to home. MaterialXGraphEditor will actually select the opposite node definition, resolving to ND_mix_color3 to UsdMtlx.  This inconsistency is at the very least annoying.  In fact in MaterialXGraphEditor the ambiguity manifests itself a little worse.  If I decide to create a mix_color3_color3 node from the node menu, then I correctly see a color3 typed input for the mix parameter, but If I do not edit anything on the node, save the document and reload it, the my mix node reverts to a mix_color3 with a float typed input for the mix node, which is not what I created.
Note:
All of this ambiguity would be resolved with the addition of an <input> definition on the node to constrain the type of the mix input.  The node below is no longer ambiguous.
  <mix name="myMix" type="color3">
    <input name="fg" type="color3" nodename="upstreamA" />
    <input name="bg" type="color3" nodename="upstreamB" />
    <input name="mix" type="float" />
  </mix>

I don't have any concrete proposals for how to resolve this, but I do have some ideas for discussion.
We could:

Codify a concrete ordering of node definitions, for a given node family, so that there can at least be some level of consistency between integrations.
Improve document validation to inform the user if there are nodes in the document that are ambiguous as to their node definition? - This perhaps could be too noisy, or report "errors" that aren't in fact errors?
Update the document save functionality, such that if it detects it's writing an ambiguous node, then it will add any necessary <input> or <output> elements to concretely constrain the node.

I was experimenting a little with Houdini 20, exporting MaterialX files, and it appears that SideFX get around this problem by always writing all of the <input> tags on each node - which leads to a larger than necessary mtlx file, but removes the ambiguity.
Tagging @crydalch incase he has any insight here.

@ld-kerley that's just how we tend to author things in Houdini, as it helps reduce future updates from changing things unexpectedly.

Another way to remove the ambiguity is to write out the nodedef=<> attribute on the node which I believe is similar to what is done for USD with info:id but this doesn't solve the issue.
BTW, I remember that this issue occurred with other ambiguous signatures and the result was to change the node category so it not both mix so it's mix_float vs mix_color  or something like that.

@kwokcb In this case, the ability to overload generic nodes such as mix and add is an important feature that we want to preserve in MaterialX, so that graph editors can support dynamic resolution of nodes based on the typed data to which an artist connects them.
As @ld-kerley notes, though, it seems valuable for all MaterialX tools to resolve to identical nodes when typed inputs have been omitted from a graph, and this seems like an area where we can be more precise in the MaterialX API and documentation.  Would it make sense to impose a rule that the first matching node definition in the data libraries must be used when multiple matches are present?  We could then validate that the MaterialX API and example applications always provide this behavior, making any required changes to the codebase to ensure this.

I think that arbitrarily choosing the "first" matching node definition could still not be deterministic enough- what if a site an another definition of a node in its own local site_defs.mtlx file and that happened to be loaded before stdlib_defs.mtlx in some situations?
Instead, I would propose that it should match the "simplest" matching definition, however we want to define that.  E.g. perhaps choosing the matching definition with fewer parameters, or one using using a float rather than a color/vector for an unconnected input.  Or perhaps we could add a new attribute to nodedefs indicating a matching order or preference, where if two or more nodedefs matched, the one with the lower matching order value would win.  Obviously we'd need to put a LOT more thought into this, but what do folks think of this as a general idea?

It is quite possible to have order change as it does depend on definition load order which can include target order and namespace order.
There are signatures with the exact same number of input parameters (as in this example). Also you could have the same matching "score". Als in this example, the definitions each have 3 inputs -- 1 which the differentiating input (float vs color3), but the node instance does not override the differentiating input.
There is already a mechanism to return "first" and an "exact" match option + logic which scans all inputs when trying to determine what definition matches.
My feeling is to try to avoid complex "matching" rules to be followed that if there is ambiguity then to either return all matches and let the integration handle it properly, or just fail. As noted in Slack, I'd still like to propose that if there are 2 or more nodefefs with differentiating inputs that must be specified that there is some meta-data to mark them as such. Then if it's missing then a failure condition can be easily found, both at creation time and at validation or definition matching time.
e.g. adding a required tag.
 <nodedef name="ND_mix_color3" node="mix" nodegroup="compositing">
    <input name="fg" type="color3" value="0.0, 0.0, 0.0" />
    <input name="bg" type="color3" value="0.0, 0.0, 0.0" />
    <input name="mix" type="float" value="0.0" uisoftmin="0.0" uisoftmax="1.0" required="true"/>
    <output name="out" type="color3" defaultinput="bg" />
  </nodedef>
  <nodedef name="ND_mix_color3_color3" node="mix" nodegroup="compositing">
    <input name="fg" type="color3" value="0.0, 0.0, 0.0" />
    <input name="bg" type="color3" value="0.0, 0.0, 0.0" />
    <input name="mix" type="color3" value="0.0, 0.0, 0.0" uisoftmin="0,0,0" uisoftmax="1,1,1" required="true"/>
    <output name="out" type="color3" defaultinput="bg" />
  </nodedef>

This is exactly the situation I was thinking about when suggesting "use the simpler of the two matching definitions if both signatures match": in this example, ND_mix_color3 is "simpler" than ND_mix_color3_color3" because the one input ("mix") that has different types for each signature is "float" in the first, and "color3" in the second, and "float" is simpler than "color3".  This wouldn't work if the only differing input was e.g. a "color3" vs a "vector3" but I don't recall that actually being the case.  And we could make this "which nodedef is simpler" more explicit by adding an attribute (name TBD) where the first could have a value of "10" and the second a value of "20" (leaving room before, in the middle and after for other nodedefs to slide into the matching scale for this node wherever they need to.
(Side note: in a  node, I can't imagine a real scenario where the mix input would have neither a provided value or a connection, except in the situation where you were in progress wiring up a nodegraph.  So there wouldn't likely be an ambiguity in a real scene.)

@kwokcb Just to provide additional motivation for the development of rigorous matching rules, it's worth noting that marking inputs as "required" would not be sufficient to resolve this issue, as we'd still need a rigorous set of matching rules to handle documents that omit the input anyway (e.g. legacy documents).  While we can make sure documents in this state emit validation warnings, we still need to generate valid shading code in every language from these documents, and rigorous precedence rules will still be required.
@dbsmythe I'm open to any simple set of rules that fixes the order in which matching definitions should be considered, though it would be ideal if our existing set of MaterialX attributes is sufficient to resolve all cases, as opposed to requiring new attributes to create order.
Giving precedence to the simplest data type (e.g. float > color3 > color4) is one valid option, though selecting the first matching node might be easier for MaterialX integrations to support, and it would give pipeline developers more control over whether their custom nodes are intended to take precedence over the standard set.  Just to give a real-world example, some pipeline developers will intentionally replace shading models such as standard_surface with their own custom interfaces, and in this case they will likely take control over the library import order to ensure that their version takes precedence over the standard one.

About allowing invalid documents still generate code. I’ve always found this to be ambiguous since some validation failures can still allow generation to continue but others do not. In this case it still feels wrong to make a calculated guess as to what is the correct definition to use. At the time of usage there should be no ambiguity. This still allows for a node to be created without a unique signature but it’s very possible to guess one signature and then have code which sets an input be nonambiguous afterwards. In this the wrong definition is created and the subsequent input setting will fail.

In order to keep this discussion focused, it may help to provide a concrete example to discuss, and I'll choose this one from the standard_surface_brick_procedural.mtlx example in our repository:
https://github.com/AcademySoftwareFoundation/MaterialX/blob/5f9fee7ef4a29bb2e2bfbb353fb7427b8072b6dc/resources/Materials/Examples/StandardSurface/standard_surface_brick_procedural.mtlx#L54
This clamp node is technically ambiguous, as its low and high inputs have not been stated, so they could either be 0.0 and 1.0, or they could be 0.0, 0.0, 0.0 and 1.0, 1.0, 1.0, depending on which nodedef is selected at runtime.
Following the design of the MaterialX standard libraries, though, it's important to note that this selection has no effect on rendered visuals, as these two interpretations generate identical results.  This is an intentional design choice rather than an accident, and my recommendation would be to lean into this design principle, making it clear in our specification that nodes with multiple overlapping signatures are expected to generate identical visuals.
We can still provide a recommended order in which nodedefs are matched to nodes, as this will be valuable for the USD use case that originally motivated this thread, but we don't need to make ambiguous nodes such as the example above invalid in documents.

I wanted to highlight #1753, which addresses an inconsistency in our NodeDef lookups across compilers, without changing the expectation of declaration order in the current codebase.
I'll leave this GitHub Issue open, so that we can discuss what order for NodeDef lookups would be ideal, and the recent fix should give us a more consistent baseline to build upon.

Let's go ahead and close out this GitHub Issue, as our latest codebase resolves the earlier inconsistency in NodeDef lookups across platforms, and we can continue the discussion about whether improvements to our rules for NodeDef lookups are needed in the future.
Thanks for bringing this up, @ld-kerley!

If it's the position of the project that node definitions should be selected by taking the first match - then maybe we should add some language as such to the specification?  Currently an implementor doesn't have any guidance as to what to do if there is an ambiguous node resolution.


issue 341_Update init.py

What problem does this PR solve?
Briefly describe what this PR aims to solve. Include background context that will help reviewers understand the purpose of the PR.
Issue link:#[Link the issue here]
Type of change

[ ] Bug Fix (non-breaking change which fixes an issue)
[ ] New Feature (non-breaking change which adds functionality)
[ ] Breaking Change (fix or feature that could cause existing functionality not to work as expected)
[ ] Documentation Update
[ ] Refactoring
[ ] Performance Improvement
[ ] Test cases
[ ] Python SDK impacted, Need to update PyPI
[ ] Other (please describe):

issue 341


Allow immediate typing when tabbing to multiple select.

Fixes #3331.
I'd be willing to make this an option if someone can make the case that it shouldn't be default behaviour.
@philipwalton let me know if this works for you.

If this is moved into the Search decorator for the selection I might entertain the idea of having it as the default behaviour for multiple selects.
Right now this isn't in that decorator, but it depends on that decorator, and will trigger an error (no self.$search).

@rywall are you going to have time to look at this?
If not I might take a look because this would be useful!

The modified version of this patch was committed in https://github.com/select2/select2/commit/02cca7baa7b78e73cdcf393172ee3a54be387167. And the focus war that I discovered (from the patch) was fixed in https://github.com/select2/select2/commit/79cdcc0956e242c1ce642bbaa93e538c54f4be01.


Add a link to the overview post

The blog post gives basics and essential knowledge from the practical point of view.

 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.:x: vavd sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


Yankpad broken for buffer when not choosing category

Hi!
yankpad does not seem to automatically assign the "org-mode" category when I am within an Org-mode buffer. But I am not sure if I did not understand the category feature completely. However, this is not the issue I want to report here. It's just a remark.
When I invoke yankpad-insert and do (accidentally) not choose any mode manually (I have to because the mode is not recognized automatically - see remark above) but press Enter right away, the current buffer can not use yankpad any more because yankpad-insert does not provide any possible target to insert.

Regarding the first issue: Yankpad has to be loaded before you open the file and one of your categories has to be named org-mode.
Second issue: I did not know that it was possible to choose "no category" by accident. I'm not sure what to do about that. Once you've set a category for a buffer yankpad-insert will continue to use that category. That seems to be the case here: you've chosen a (non-existent?) category which doesn't contain any entries. To switch category, use M-x yankpad-set-category. That should solve your problem.

Hi Kungsgeten,
I'll have to look into the order of loading things because yankpad as well as my org-mode files are loaded at startup.
Yes, I did come to the same reasoning: yankpad fell into a category with no entries. Thanks for the pointer to yankpad-set-category to get our of this situation. However, I was thinking of preventing the situation in the first place by making sure that an existing category is chosen when asking for a category.

Hi!
I've just uploaded a new version, please try it out and see if it fixes your problem. I think it should ask for the category again, if you do not have any set.

My Melpa still has 20160716.1613. What is your Melpa-update policy? Or do I have to switch from Melpa package to git repository?

There should be no need to switch. The version shown at https://melpa.org/#/yankpad is 20160903.1935. Packages aren't upgraded automatically though. Use M-x package-list-packages and press U x to upgrade all packages. I think M-x package-reinstall yankpad should work too, but I haven't tried it.

I'm using (add-to-list 'package-archives '("melpa" . "http://stable.melpa.org/packages/")) and after package-list-packages (and optional r) the yankpad version in the list stays at 20160716.1613. When trying to upgrade via U x the yankpad still does not get updated.
Is it because I am using stable and you are referring to something different?

Yes, its because you're using stable. I haven't made any stable release (and actually do not know how to).

Sorry for taking so long, but I've tagged the latest version as stable (I have been using it without problems, and haven't heard anything from other users). It should hopefully appear on Melpa stable soon.


Fix Pulsar to work correctly without auth

Checklist

[x] Changelog has been updated and is aligned with our changelog requirements
[x] Commits are signed with Developer Certificate of Origin (DCO - learn more)

Fixes #5271

can confirm #5271 is fixed by this.  👍


modify class vcl::vect::Vector w. OpenCV

see issue title.
Relates to issue #117 .

completed, tested


Filter based on parameter type

First Check

[X] I added a very descriptive title to this issue.
[X] I used the GitHub search to find a similar issue and didn't find it.
[X] I searched the FastAPI documentation, with the integrated search.
[X] I already searched in Google "How to X in FastAPI" and didn't find any information.
[X] I already read and followed all the tutorial in the docs and didn't find an answer.
[X] I already checked if it is not related to FastAPI but to Pydantic.
[X] I already checked if it is not related to FastAPI but to Swagger UI.
[X] I already checked if it is not related to FastAPI but to ReDoc.

Commit to Help

[X] I commit to help with one of those options 👆

Example Code
@router.get('/{host_id}', response_model=Host)
def get_siphost(host_id: Union[int, str], service: HostsService = Depends()):
    return service.get(host_id)

-----

    def _get(self, host_id: Union[int, str]) -> tables.Host:
        siphost = (
            self.session
            .query(tables.Host)
            .filter_by(id=host_id)   <<<<< is it possible to do dynamic filter based on type int or str
            .first()
        )
        if not host:
            raise HTTPException(status.HTTP_404_NOT_FOUND)
        return host

Description
Hello, sorry for a noobs question, didn't find it in documentation :(
I have a simple route /host with a simple model - id, name (all unique)
is it possible to get a host by id or name on a single path? I mean if /hosts/100 - will be returned host with id 100, if /hosts/localhost - will be returned host with hostname localhost.
Operating System
Linux
Operating System Details
No response
FastAPI Version
0.70.0
Python Version
Python 3.10
Additional Context
No response

do you mean ?
from sqlalchemy.sql import or_

.filter_by(or_(id=host_id, host=host_id))

thank you very much @panla!
in my case this worked like this:
.filter(or_(tables.Host.id==host_id, tables.Host.name==host_id))


Fix test: Fix broken EventAutomations tests

@aaronpoweruser I am really grateful to you for fixing my tests! It's been on my todo list and I have been unable to get to it. Thank you.

Let me know if I need to make any changes. Js is not my primary language.


Add supports for weighted edge sampling

🚀 The feature, motivation and pitch
In large graphs with more than ten million edges, the need for edge sampling is inevitable. Hopefully, GLT can support sampling based on edge weights, so as to better utilize edge features.
Related Content:
PyG

https://github.com/rusty1s/pytorch_cluster/pull/140
DGL：node2vec random walk and top-k sampling
https://docs.dgl.ai/en/0.8.x/api/python/dgl.sampling.html#neighbor-sampling

Alternatives
No response
Additional context
No response

CPU version already merged #72. You're welcome to try CPU sampling and GPU training :) @vincentX3


error:socket closed

when i send my byteball, it shows "socket closed".
when i open the chat and link my bitcoin it shows“socket closed” too……
I want to unistall the client and recover from my seed，but it says，i must install the full wallet。
what should i do？
env:

mac
v1.7.0

Please try the following:

start the wallet
right click and Inspect Background Page
reproduce the error
send me the entire contents of the console log on the background page

I'm having this issue as well? Please, i've tried everything, including the slack help.

Check your firewall.  It blocked connections for other users.

I've shut down all firewalls, and the error is still present.  I reopened after shutting down all firewall processes, including windows firewall. Do i need to reinstall with them down? How do i save the information from this install? Thank you for your help Tony, Jim
  From: tonyofbyteball<EMAIL_ADDRESS>
To: byteball/byteball<EMAIL_ADDRESS>Cc: hmmmshaihulud<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Sent: Sunday, June 4, 2017 10:38 AM
Subject: Re: [byteball/byteball] error:socket closed (#74)
Check your firewall. It blocked connections for other users.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

I don't think a reinstall would help.
What is your hub?

I'm having an identical issue now. No firewall. Hub is the default: byteball.org/bb

Seeing this a lot in the logs: error from server wss://byteball.org/bb: Error: Socket Closed

bb log.zip

I have the same problem because I had activated Tor my solution was to disabled it

I'm using linux ubuntu 16.04 and running the Wallet (v 1.9.0 light) throught Tor without a problem, but in linux you have to have Tor daemon running in the background which is listening on your localhost port for your wallet to connect through, Did you actually have tor running on the system?
See https://www.torproject.org/docs/tor-doc-osx.html.en

Summing up:

check TOR
check firewall
you might be blocked by the hub for 1 hour after sending something invalid.  Wait or change to another hub


HADOOP-15183 S3Guard store becomes inconsistent after partial failure of rename

This is a major patch which has grown to become a "fix up the final issues with Auth mode" patch, built according to my proposed refactoring S3A design.

new stuff goes into an o.a.h.fs.s3a.impl class to make clear its for implementation

Multi-object delete:

o.a.h.fs.s3a.impl.MultiObjectDeleteSupport handles partial delete failures by parsing the response and updating the metastore with those deleted entries

rename (i.e. copy + delete), plus scale and perf of commits
Each metastore has the notion of

BulkOperationState; this can be used by a store to track entries which have been added/found during a set of operations (sequential or in parallel)
and a RenameTracker which implements the algorithm for updating the store on rename. The DelayedUpdateTracker implements the classic "do it at the end" algorithm, while the ProgressiveRenameTracker does it incrementally.
and their own addAncestors() call which can update the bulk state based on examining the store and the current state of the BulkOperationState. This has been pushed down from S3Guard.addAncestors() to allow them to do their own thing with the bulk state.

S3AFilesystem.innerRename now copies in parallel; hard coded at 10 for now (having it a factor of the delete page size makes sense). each parallel copy operation notifies the current RenameTracker of its completion, so letting them choose what to do (DelayedUpdate: saves the change; ProgressiveRenameTracker: updates the store immediately).
The RenameTracker also has the homework of updating the store state on the case of a partial rename failure. DelayedUpdateTracker: update the metastore; ProgressiveUpdate: no-op.
Local and DDB metastores now only use the ProgressiveRenameTracker; this was done after I'd move the classic design into its own tracker (i.e out of S3AFileSystem). Oh, and theres a NullRenameTracker for the null metastore.
The BulkOperationState ends up being passed all the way to the committers; to avoid them explicitly having to understand this, the CommitOperations class now has an inner (non-static) CommitContext class which contains this and exports the commit/abort/revert operations for the committers to call. Internally it then invokes WriteOperationHelper calls with the context, which then gets all the way through to S3AFileSystem.finishedWrite() for the updates there to decide what entries to put into the store.
With this design

Renames are progressive and parallelized. So faster as well as keeping the the metastore consistent.
Bulk delete failures are handled
Commit operations don't generate excessive load on the store: if you are committing 500 files, then each parent dir will be checked ~once. (I say ~once as the get() is done out of a sync block, so multiple parallel entries may duplicate the work, but I'd rather that than lock during a remote RPC call).

Note that for both the parallelized commit and copy ops, we can also shuffle the source data so that we aren't doing it on the same lowest-level directory (what I'd expect today). That should reduce load on the S3 Store. With a move to parallel copy operations that will make a difference: the list comes in sequentially so the initial set of 10 renames will be adjacent. Actually I could be even cleverer there and sort by size. Why so? ensures that a large file doesn't become the straggler in the copy.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
32
Docker mode activated.

_ Prechecks _

+1
dupname
2
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 27 new or modified test files.

_ trunk Compile Tests _

0
mvndep
68
Maven dependency ordering for branch

-1
mvninstall
1073
root in trunk failed.

+1
compile
1118
trunk passed

+1
checkstyle
137
trunk passed

+1
mvnsite
116
trunk passed

+1
shadedclient
916
branch has no errors when building and testing our client artifacts.

+1
javadoc
105
trunk passed

0
spotbugs
69
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
190
trunk passed

_ Patch Compile Tests _

0
mvndep
22
Maven dependency ordering for patch

+1
mvninstall
81
the patch passed

+1
compile
1035
the patch passed

+1
javac
1035
the patch passed

-0
checkstyle
131
root: The patch generated 15 new + 95 unchanged - 3 fixed = 110 total (was 98)

+1
mvnsite
123
the patch passed

-1
whitespace
0
The patch has 51 line(s) that end in whitespace. Use git apply --whitespace=fix <<patch_file>>. Refer https://git-scm.com/docs/git-apply

-1
whitespace
1
The patch 600  line(s) with tabs.

+1
xml
3
The patch has no ill-formed XML file.

+1
shadedclient
649
patch has no errors when building and testing our client artifacts.

-1
javadoc
28
hadoop-tools_hadoop-aws generated 3 new + 1 unchanged - 0 fixed = 4 total (was 1)

+1
findbugs
205
the patch passed

_ Other Tests _

+1
unit
535
hadoop-common in the patch passed.

+1
unit
291
hadoop-aws in the patch passed.

-1
asflicense
45
The patch generated 1 ASF License warnings.

9589

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/hadoop-multibranch/job/PR-843/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/843

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle xml

uname
Linux 796966f8c9ef 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 67f9a7b

Default Java
1.8.0_212

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/1/artifact/out/branch-mvninstall-root.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/1/artifact/out/diff-checkstyle-root.txt

whitespace
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/1/artifact/out/whitespace-eol.txt

whitespace
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/1/artifact/out/whitespace-tabs.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/1/artifact/out/diff-javadoc-javadoc-hadoop-tools_hadoop-aws.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/1/testReport/

asflicense
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/1/artifact/out/patch-asflicense-problems.txt

Max. process+thread count
1654 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-tools/hadoop-aws U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/1/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

The patch 600 line(s) with tabs.

not sure what's up there. Usually its stack traces in docs, but this is a lot.

the 600 tabs are from the file ./hadoop-tools/hadoop-rumen/hs_err_pid15861.log; not relevant

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
33
Docker mode activated.

_ Prechecks _

+1
dupname
1
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 27 new or modified test files.

_ trunk Compile Tests _

0
mvndep
31
Maven dependency ordering for branch

+1
mvninstall
1158
trunk passed

+1
compile
1214
trunk passed

+1
checkstyle
188
trunk passed

+1
mvnsite
127
trunk passed

+1
shadedclient
1017
branch has no errors when building and testing our client artifacts.

+1
javadoc
89
trunk passed

0
spotbugs
65
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
190
trunk passed

-0
patch
97
Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

0
mvndep
27
Maven dependency ordering for patch

+1
mvninstall
83
the patch passed

+1
compile
1088
the patch passed

+1
javac
1088
the patch passed

-0
checkstyle
137
root: The patch generated 14 new + 95 unchanged - 3 fixed = 109 total (was 98)

+1
mvnsite
120
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
xml
3
The patch has no ill-formed XML file.

+1
shadedclient
620
patch has no errors when building and testing our client artifacts.

-1
javadoc
27
hadoop-tools_hadoop-aws generated 6 new + 1 unchanged - 0 fixed = 7 total (was 1)

+1
findbugs
191
the patch passed

_ Other Tests _

-1
unit
537
hadoop-common in the patch failed.

+1
unit
285
hadoop-aws in the patch passed.

-1
asflicense
43
The patch generated 17 ASF License warnings.

7224

Reason
Tests

Failed junit tests
hadoop.util.TestDiskCheckerWithDiskIo

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/hadoop-multibranch/job/PR-843/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/843

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle xml

uname
Linux d160008701a7 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 0c73dba

Default Java
1.8.0_212

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/2/artifact/out/diff-checkstyle-root.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/2/artifact/out/diff-javadoc-javadoc-hadoop-tools_hadoop-aws.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/2/artifact/out/patch-unit-hadoop-common-project_hadoop-common.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/2/testReport/

asflicense
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/2/artifact/out/patch-asflicense-problems.txt

Max. process+thread count
1421 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-tools/hadoop-aws U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/2/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

unit test failures in hadoop common are unrelated; look like directory setup on test VM.
java.nio.file.NoSuchFileException: /home/jenkins/jenkins-slave/workspace/hadoop-multibranch_PR-843/src/hadoop-common-project/hadoop-common/target/test/data/4/test3854891488020485558
	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
	at sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384)
	at java.nio.file.Files.createDirectory(Files.java:674)
	at java.nio.file.TempFileHelper.create(TempFileHelper.java:136)
	at java.nio.file.TempFileHelper.createTempDirectory(TempFileHelper.java:173)
	at java.nio.file.Files.createTempDirectory(Files.java:950)
	at org.apache.hadoop.util.TestDiskCheckerWithDiskIo.createTempDir(TestDiskCheckerWithDiskIo.java:169)
	at org.apache.hadoop.util.TestDiskCheckerWithDiskIo.checkDirs(TestDiskCheckerWithDiskIo.java:152)
	at org.apache.hadoop.util.TestDiskCheckerWithDiskIo.testDiskIoIgnoresTransientWriteErrors(TestDiskCheckerWithDiskIo.java:76)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.lang.Thread.run(Thread.java:748)

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
45
Docker mode activated.

_ Prechecks _

+1
dupname
1
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 28 new or modified test files.

_ trunk Compile Tests _

0
mvndep
72
Maven dependency ordering for branch

+1
mvninstall
1151
trunk passed

+1
compile
1062
trunk passed

+1
checkstyle
146
trunk passed

+1
mvnsite
120
trunk passed

+1
shadedclient
1032
branch has no errors when building and testing our client artifacts.

+1
javadoc
93
trunk passed

0
spotbugs
64
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
184
trunk passed

-0
patch
97
Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

0
mvndep
21
Maven dependency ordering for patch

+1
mvninstall
76
the patch passed

+1
compile
950
the patch passed

+1
javac
950
the patch passed

-0
checkstyle
147
root: The patch generated 15 new + 98 unchanged - 4 fixed = 113 total (was 102)

+1
mvnsite
118
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
xml
3
The patch has no ill-formed XML file.

+1
shadedclient
736
patch has no errors when building and testing our client artifacts.

-1
javadoc
32
hadoop-tools_hadoop-aws generated 6 new + 1 unchanged - 0 fixed = 7 total (was 1)

+1
findbugs
200
the patch passed

_ Other Tests _

+1
unit
523
hadoop-common in the patch passed.

+1
unit
285
hadoop-aws in the patch passed.

+1
asflicense
45
The patch does not generate ASF License warnings.

7115

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/hadoop-multibranch/job/PR-843/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/843

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle xml

uname
Linux bbc4f008d07b 4.4.0-139-generic #165~14.04.1-Ubuntu SMP Wed Oct 31 10:55:11 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 544876f

Default Java
1.8.0_212

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/3/artifact/out/diff-checkstyle-root.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/3/artifact/out/diff-javadoc-javadoc-hadoop-tools_hadoop-aws.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/3/testReport/

Max. process+thread count
1346 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-tools/hadoop-aws U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/3/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
49
Docker mode activated.

_ Prechecks _

+1
dupname
1
No case conflicting files found.

+1
@author
1
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 28 new or modified test files.

_ trunk Compile Tests _

0
mvndep
77
Maven dependency ordering for branch

+1
mvninstall
1150
trunk passed

+1
compile
1151
trunk passed

+1
checkstyle
144
trunk passed

+1
mvnsite
122
trunk passed

+1
shadedclient
1033
branch has no errors when building and testing our client artifacts.

+1
javadoc
97
trunk passed

0
spotbugs
66
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
200
trunk passed

-0
patch
98
Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

0
mvndep
23
Maven dependency ordering for patch

+1
mvninstall
84
the patch passed

+1
compile
1407
the patch passed

+1
javac
1407
the patch passed

-0
checkstyle
175
root: The patch generated 12 new + 98 unchanged - 4 fixed = 110 total (was 102)

+1
mvnsite
141
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
xml
5
The patch has no ill-formed XML file.

+1
shadedclient
762
patch has no errors when building and testing our client artifacts.

+1
javadoc
102
the patch passed

+1
findbugs
244
the patch passed

_ Other Tests _

+1
unit
604
hadoop-common in the patch passed.

+1
unit
295
hadoop-aws in the patch passed.

+1
asflicense
58
The patch does not generate ASF License warnings.

7933

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/hadoop-multibranch/job/PR-843/4/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/843

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle xml

uname
Linux 174a51b985e1 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 751f0df

Default Java
1.8.0_212

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/4/artifact/out/diff-checkstyle-root.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/4/testReport/

Max. process+thread count
1387 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-tools/hadoop-aws U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/4/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

thanks all for reviews, will go through them. FWIW, the latest patch has checks on dir updates if the batch update overwrites a file updated in the ongoing operation with a dir entry. And its failing in a prune test (one which shouldn't IMO, be doing a full store-wide prune)

[ERROR] testPruneCommandConf(org.apache.hadoop.fs.s3a.s3guard.ITestS3GuardToolDynamoDB)  Time elapsed: 15.828 s  <<< ERROR!
org.apache.hadoop.fs.PathIOException: `s3a://hwdev-steve-ireland-new/fork-0007/test/ITestMagicCommitProtocol-testParallelJobsToAdjacentPaths': Duplicate and inconsistent entry in update operation
	at org.apache.hadoop.fs.s3a.s3guard.DynamoDBMetadataStore$AncestorState.findDirectory(DynamoDBMetadataStore.java:2184)
	at org.apache.hadoop.fs.s3a.s3guard.DynamoDBMetadataStore.completeAncestry(DynamoDBMetadataStore.java:820)
	at org.apache.hadoop.fs.s3a.s3guard.DynamoDBMetadataStore.innerPut(DynamoDBMetadataStore.java:1144)
	at org.apache.hadoop.fs.s3a.s3guard.DynamoDBMetadataStore.removeAuthoritativeDirFlag(DynamoDBMetadataStore.java:1418)
	at org.apache.hadoop.fs.s3a.s3guard.DynamoDBMetadataStore.prune(DynamoDBMetadataStore.java:1366)
	at org.apache.hadoop.fs.s3a.s3guard.DynamoDBMetadataStore.prune(DynamoDBMetadataStore.java:1325)
	at org.apache.hadoop.fs.s3a.s3guard.AbstractS3GuardToolTestBase.testPruneCommand(AbstractS3GuardToolTestBase.java:295)
	at org.apache.hadoop.fs.s3a.s3guard.AbstractS3GuardToolTestBase.testPruneCommandConf(AbstractS3GuardToolTestBase.java:320)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
	at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.lang.Thread.run(Thread.java:748)

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
31
Docker mode activated.

_ Prechecks _

+1
dupname
1
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 30 new or modified test files.

_ trunk Compile Tests _

0
mvndep
75
Maven dependency ordering for branch

+1
mvninstall
1383
trunk passed

+1
compile
1261
trunk passed

+1
checkstyle
165
trunk passed

+1
mvnsite
152
trunk passed

+1
shadedclient
1162
branch has no errors when building and testing our client artifacts.

+1
javadoc
110
trunk passed

0
spotbugs
74
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
217
trunk passed

-0
patch
109
Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

0
mvndep
25
Maven dependency ordering for patch

+1
mvninstall
94
the patch passed

+1
compile
1248
the patch passed

+1
javac
1248
the patch passed

-0
checkstyle
164
root: The patch generated 27 new + 97 unchanged - 5 fixed = 124 total (was 102)

+1
mvnsite
134
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
xml
3
The patch has no ill-formed XML file.

+1
shadedclient
786
patch has no errors when building and testing our client artifacts.

-1
javadoc
31
hadoop-tools_hadoop-aws generated 1 new + 1 unchanged - 0 fixed = 2 total (was 1)

+1
findbugs
250
the patch passed

_ Other Tests _

+1
unit
615
hadoop-common in the patch passed.

-1
unit
69
hadoop-aws in the patch failed.

-1
asflicense
51
The patch generated 7 ASF License warnings.

8075

Reason
Tests

Failed junit tests
hadoop.fs.s3a.TestS3AGetFileStatus

hadoop.fs.s3a.TestStreamChangeTracker

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/hadoop-multibranch/job/PR-843/5/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/843

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle xml

uname
Linux 0cea5ead54a0 4.4.0-143-generic #169~14.04.2-Ubuntu SMP Wed Feb 13 15:00:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 97607f3

Default Java
1.8.0_212

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/5/artifact/out/diff-checkstyle-root.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/5/artifact/out/diff-javadoc-javadoc-hadoop-tools_hadoop-aws.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/5/artifact/out/patch-unit-hadoop-tools_hadoop-aws.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/5/testReport/

asflicense
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/5/artifact/out/patch-asflicense-problems.txt

Max. process+thread count
1460 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-tools/hadoop-aws U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/5/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
31
Docker mode activated.

_ Prechecks _

+1
dupname
1
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 32 new or modified test files.

_ trunk Compile Tests _

0
mvndep
21
Maven dependency ordering for branch

+1
mvninstall
1027
trunk passed

+1
compile
1081
trunk passed

+1
checkstyle
127
trunk passed

+1
mvnsite
115
trunk passed

+1
shadedclient
915
branch has no errors when building and testing our client artifacts.

+1
javadoc
82
trunk passed

0
spotbugs
63
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
181
trunk passed

-0
patch
93
Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

0
mvndep
23
Maven dependency ordering for patch

+1
mvninstall
78
the patch passed

+1
compile
1014
the patch passed

+1
javac
1014
the patch passed

-0
checkstyle
130
root: The patch generated 28 new + 102 unchanged - 5 fixed = 130 total (was 107)

+1
mvnsite
108
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
xml
2
The patch has no ill-formed XML file.

+1
shadedclient
620
patch has no errors when building and testing our client artifacts.

-1
javadoc
28
hadoop-tools_hadoop-aws generated 1 new + 1 unchanged - 0 fixed = 2 total (was 1)

+1
findbugs
191
the patch passed

_ Other Tests _

+1
unit
537
hadoop-common in the patch passed.

+1
unit
295
hadoop-aws in the patch passed.

+1
asflicense
54
The patch does not generate ASF License warnings.

6748

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/hadoop-multibranch/job/PR-843/6/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/843

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle xml

uname
Linux 11e0754b52cd 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 309501c

Default Java
1.8.0_212

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/6/artifact/out/diff-checkstyle-root.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/6/artifact/out/diff-javadoc-javadoc-hadoop-tools_hadoop-aws.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/6/testReport/

Max. process+thread count
1600 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-tools/hadoop-aws U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/6/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
33
Docker mode activated.

_ Prechecks _

+1
dupname
3
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 32 new or modified test files.

_ trunk Compile Tests _

0
mvndep
22
Maven dependency ordering for branch

+1
mvninstall
1025
trunk passed

+1
compile
1014
trunk passed

+1
checkstyle
136
trunk passed

+1
mvnsite
131
trunk passed

+1
shadedclient
992
branch has no errors when building and testing our client artifacts.

+1
javadoc
107
trunk passed

0
spotbugs
69
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
188
trunk passed

-0
patch
109
Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

0
mvndep
24
Maven dependency ordering for patch

-1
mvninstall
30
hadoop-aws in the patch failed.

-1
compile
927
root in the patch failed.

-1
javac
927
root in the patch failed.

-0
checkstyle
143
root: The patch generated 28 new + 100 unchanged - 2 fixed = 128 total (was 102)

-1
mvnsite
46
hadoop-aws in the patch failed.

+1
whitespace
0
The patch has no whitespace issues.

+1
xml
3
The patch has no ill-formed XML file.

+1
shadedclient
686
patch has no errors when building and testing our client artifacts.

-1
javadoc
33
hadoop-tools_hadoop-aws generated 1 new + 1 unchanged - 0 fixed = 2 total (was 1)

-1
findbugs
46
hadoop-aws in the patch failed.

_ Other Tests _

+1
unit
531
hadoop-common in the patch passed.

-1
unit
46
hadoop-aws in the patch failed.

+1
asflicense
51
The patch does not generate ASF License warnings.

6563

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/hadoop-multibranch/job/PR-843/7/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/843

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle xml

uname
Linux 221b675e67c7 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / b057479

Default Java
1.8.0_212

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/7/artifact/out/patch-mvninstall-hadoop-tools_hadoop-aws.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/7/artifact/out/patch-compile-root.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/7/artifact/out/patch-compile-root.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/7/artifact/out/diff-checkstyle-root.txt

mvnsite
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/7/artifact/out/patch-mvnsite-hadoop-tools_hadoop-aws.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/7/artifact/out/diff-javadoc-javadoc-hadoop-tools_hadoop-aws.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/7/artifact/out/patch-findbugs-hadoop-tools_hadoop-aws.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/7/artifact/out/patch-unit-hadoop-tools_hadoop-aws.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/7/testReport/

Max. process+thread count
1361 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-tools/hadoop-aws U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/7/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

I've just pushed up a new version which includes the checkstyle complaints and the various nits reported. Tested s3 ireland. All good except for the new test where I'm trying to create an inconsistency in the table to cause problems in prune. I think I'm going to put that to one side right now and worry about that in some tests for fsck in a subsequent patch
After this iteration I'm going to have to move to a new PR; yetus is unhappy again.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
111
Docker mode activated.

_ Prechecks _

+1
dupname
2
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 32 new or modified test files.

_ trunk Compile Tests _

0
mvndep
21
Maven dependency ordering for branch

+1
mvninstall
1140
trunk passed

+1
compile
970
trunk passed

+1
checkstyle
140
trunk passed

+1
mvnsite
122
trunk passed

+1
shadedclient
1045
branch has no errors when building and testing our client artifacts.

+1
javadoc
105
trunk passed

0
spotbugs
76
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
221
trunk passed

-0
patch
116
Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

0
mvndep
24
Maven dependency ordering for patch

+1
mvninstall
104
the patch passed

+1
compile
1207
the patch passed

+1
javac
1207
the patch passed

-0
checkstyle
161
root: The patch generated 31 new + 100 unchanged - 2 fixed = 131 total (was 102)

+1
mvnsite
148
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
xml
2
The patch has no ill-formed XML file.

+1
shadedclient
803
patch has no errors when building and testing our client artifacts.

-1
javadoc
39
hadoop-tools_hadoop-aws generated 1 new + 1 unchanged - 0 fixed = 2 total (was 1)

+1
findbugs
235
the patch passed

_ Other Tests _

+1
unit
584
hadoop-common in the patch passed.

+1
unit
293
hadoop-aws in the patch passed.

+1
asflicense
44
The patch does not generate ASF License warnings.

7659

Subsystem
Report/Notes

Docker
Client=18.09.5 Server=18.09.5 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-843/8/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/843

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle xml

uname
Linux e1e471b5943e 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 5740eea

Default Java
1.8.0_212

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/8/artifact/out/diff-checkstyle-root.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/8/artifact/out/diff-javadoc-javadoc-hadoop-tools_hadoop-aws.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/8/testReport/

Max. process+thread count
1348 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-tools/hadoop-aws U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/8/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
31
Docker mode activated.

_ Prechecks _

+1
dupname
1
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 32 new or modified test files.

_ trunk Compile Tests _

0
mvndep
23
Maven dependency ordering for branch

+1
mvninstall
1094
trunk passed

+1
compile
1145
trunk passed

+1
checkstyle
144
trunk passed

+1
mvnsite
120
trunk passed

+1
shadedclient
975
branch has no errors when building and testing our client artifacts.

+1
javadoc
82
trunk passed

0
spotbugs
74
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
201
trunk passed

-0
patch
105
Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.

_ Patch Compile Tests _

0
mvndep
22
Maven dependency ordering for patch

+1
mvninstall
82
the patch passed

+1
compile
1009
the patch passed

+1
javac
1009
the patch passed

-0
checkstyle
144
root: The patch generated 20 new + 100 unchanged - 2 fixed = 120 total (was 102)

+1
mvnsite
126
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
xml
3
The patch has no ill-formed XML file.

+1
shadedclient
696
patch has no errors when building and testing our client artifacts.

+1
javadoc
99
the patch passed

+1
findbugs
223
the patch passed

_ Other Tests _

-1
unit
504
hadoop-common in the patch failed.

+1
unit
293
hadoop-aws in the patch passed.

+1
asflicense
51
The patch does not generate ASF License warnings.

7086

Reason
Tests

Failed junit tests
hadoop.util.TestDiskChecker

Subsystem
Report/Notes

Docker
Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/hadoop-multibranch/job/PR-843/9/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/843

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle xml

uname
Linux 86f97d3cf0fe 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 4fecc2a

Default Java
1.8.0_212

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/9/artifact/out/diff-checkstyle-root.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/9/artifact/out/patch-unit-hadoop-common-project_hadoop-common.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/9/testReport/

Max. process+thread count
1348 (vs. ulimit of 5500)

modules
C: hadoop-common-project/hadoop-common hadoop-tools/hadoop-aws U: .

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-843/9/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

closed to create a squashed one and keep yetus happy; rebase to trunk first.

new PR is #951. Please can people review that as it is ~ready to go in and in need of criticism


package name with capital letter first leads to broken .xmir

If my package name starts with a capital letter, I'm getting this:
   <metas>
      <meta>
         package
         <tail>EOorg.EOeolang</tail>
         <part>EOorg.EOeolang</part>
      </meta>
      ...

Here, EOorg.EOeolang is not a valid package name. Every part in the package name must be a valid attribute name, which must start with a small English letter. Probably, it should be something like:
   <metas>
      <meta>
         package
         <tail>j$EOorg.j$EOeolang</tail>
         <part>j$EOorg.j$EOeolang</part>
      </meta>
      ...

@volodya-lombrozo please, help

@yegor256 Yes, sure, I will do it. However, the usage of capital letters in package names is the dangerous practice and should be avoided:

Package names are written in all lower case to avoid conflict with the names of classes or interfaces.

@rultor release, tag is 0.6.9, title is 0.6.9

@rultor release, tag is 0.6.9, title is 0.6.9

@volodya-lombrozo OK, I will release it now. Please check the progress here.

@rultor release, tag is 0.6.9, title is 0.6.9

@volodya-lombrozo Done! FYI, the full log is here (took me 12min).

@volodya-lombrozo thanks!


https://djangopackages.com doesn't work (missing a redirect on the webserver)

http://djangopackages.com redirects to https://www.djangopackages.com but using https doesn't work. I would redirect all variations to https://djangopackages.com but at least it should redirect to the www site.

It's still not working :(

Can you try it now? We just fixed all the DNS stuff.

It's working now, thanks! :)

Yay! 🚀


Last item disappears when sorting

Hello.
When I move the last item to an other place, it renderers it, in the correct position, but it's "invisible".
If I try to place an item on top of this "invisible" item, that item is also becomes "invisible".
I tried to reproduce it in a snack, but I couldn't.
I checked, every item gets rendered after sorting. The strange thing to me, that it leaves exactly as much empty place as the component itself.
Did someone encountered similar bug?

I am encountering the same problem you have described.


Search results can carry over between catalogue and roadmap

Occasionally, search results will carry over between the search hit containers in the catalogue and the roadmap
https://github.com/icssc/peterportal-client/assets/8922227/4ccad3b8-8d24-4508-990b-2f070c14755b

I think I fixed this in #297


CDN Profile: "Monitoring" section is no longer available in the blade

Step 2 under the "Configuration - Azure portal" section indicates that there is a "Monitoring" section in the blade. Based on this image, it should be between the "Settings" and "Automation" section.  However, this no longer appears to be the case.

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

ID: 3af5b015-4ac5-9d08-4ea0-4fbcdf9c0f6b
Version Independent ID: 35a8cce3-e122-1570-773a-a54d1ad0a73b
Content: Monitoring metrics and raw logs for Azure CDN from Microsoft
Content Source: articles/cdn/enable-raw-logs.md
Service: azure-cdn
GitHub Login: @asudbring
Microsoft Alias: allensu

@fcatacut, This RAW log feature is available for only Microsoft-CDN (Standard Microsoft).

SS:

@SubhashVasarapu-MSFT, thank you for the the clarification.  I was reviewing a colleague's Terraform code and glossed over the "Important" bubble that you pointed out and skipped directly to the "Configuration - Azure Portal" section.  Apologies for wasting your time.


Cannot create record in record explorer view.

Describe the bug
Cannot create record in record explorer view.
To Reproduce

Go to explorer view
Click on the "plus" in the record explorer ( with the tooltip: new record )
Select a table
Leave record id empty or you manually put an id in
You either fill in the content or you can leave as it is.
Press "create record"
It doesn't create

Expected behavior
When creating the record via the record explorer view it should make the record after you press the "create record" button.
Environment:
Platform: Desktop
OS: Windows_NT
Architecture: x86_64
WebView: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36 Edg/<IP_ADDRESS>
Version: 2.0.3
Flags: featureFlags: true, models_view: true, apidocs_view: true, themes: true, newsfeed: true

I am having this same problem on mac as well.

Same problem on Arch linux.


New parser implementation should accept numbers for the default placeholder option.

See discussion here.
While I am of the opinion that only a string value should be accepted for the default placeholder option, an official parser does accept numbers as well.
That might be reason enough to support it in our implementation too.

First things first:

In fact, I think we should be linting the use of placeholder options as part of the "deprecation" rule.

Fully agree. I don't think that's controversial (at least among our team). There are other lints I'd put ahead of this on a priority list, but definitely want to see a Deprecated lint implemented before any v1-type of release.

But on to the actual issue here: thanks for the thorough write up in the other thread.

Given that placeholder options are deprecated and there were only a few occurrences of not using a quoted value in the gauntlet run, I was thinking the current behavior and a "c’est la vie" approach would be best here.

I'm inclined to agree. Especially given that our new parser is infallible (👏 ) and the rest of the document can still be parsed/linted/etc. I vote we leave it as is, unless someone complains and asks us to "fix" this case. I just think it's such a niche issue it isn't worth the bandwidth to fix.


How could I connect (join in a channel) in React Native?

I have created a web server and connect successfully in web with Autobahn JS.
How can I connect my mobile app (react native) into Web Socket and join in a channel?
My co-worker is using the package 'rxjs/webSocket'. And after the connection estabilished, he received the message '[0,"17002626736109788d50a5a968057079",1,"Ratchet/0.4.3"]'.
Code below:
const ws = new WebSocket('ws:<IP_ADDRESS>/ws/notification', '', {
headers: {
Pragma: 'no-cache',
Origin: 'http:/',
'Accept-Language': 'pt-BR,pt;q=0.9,en-US;q=0.8,en;q=0.7',
'Sec-WebSocket-Key': '/vF5doUroqd1GERmgHxT7w==',
'User-Agent':
'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36',
Upgrade: 'websocket',
'Sec-WebSocket-Extensions':
'permessage-deflate; client_max_window_bits',
'Cache-Control': 'no-cache',
Connection: 'Upgrade',
'Sec-WebSocket-Version': '13',
'Sec-WebSocket-Protocol': 'wamp'
}
})
ws.onopen = () => {
connection opened
ws.send({
<info_json>
})  send a message
}
ws.onmessage = e => {
console.log('onmessage')
console.log(e)
console.log(JSON.parse(e.data))
}

Origin field above is missing, because I am connecting in another machine, not in localhost.


Backwards Compatibility - no version 1.7.10 and 1.8.0

Will the latest version of multiverse work with KCauldron server version 1.7.10? The latest 2 releases of Multiverse seem like they support game version 1.7.9 and 1.8.1. So I am wondering why it doesn't list 1.7.10 and 1.8.0.

We can only select one version when uploading a file. It works on all of the version you listed as far as we know.


Bazel target to create C++ library headers

Thanks to the //tensorflow:libtensorflow.so target, I can now build a shared library that I can use in my C++ programs.  I want to install that library in /usr/local/lib and put the headers for it in /usr/local/include, but there is no target to build and install those headers.  In particular, building the library doesn't build the headers from the proto files, so I have error_codes.proto, but not error_codes.pb.h, so I can't even use the source directory for the headers.

@martinwicke is this addressed in any planned build system changes?

No

Is the target //tensorflow/core:framework_headers_lib not sufficient?

The .proto files are not compiled to .pb.h files when I build the //tensorflow/core:framework_headers_lib target
$ **bazel build //tensorflow/core:framework_headers_lib**
..
WARNING: /private/var/tmp/_bazel_aaron/cd1b...c/external/protobuf/WORKSPACE:1: Workspace name in /private/var/tmp/_bazel_aaron/cd1b...c/external/protobuf/WORKSPACE (@__main__) does not match the name given in the repository's definition (@protobuf); this will cause a build error in future versions.
WARNING: /private/var/tmp/_bazel_aaron/cd1b...c/external/re2/WORKSPACE:1: Workspace name in /private/var/tmp/_bazel_aaron/cd1b...c/external/re2/WORKSPACE (@__main__) does not match the name given in the repository's definition (@re2); this will cause a build error in future versions.
WARNING: /private/var/tmp/_bazel_aaron/cd1b...c/external/highwayhash/WORKSPACE:1: Workspace name in /private/var/tmp/_bazel_aaron/cd1b...c/external/highwayhash/WORKSPACE (@__main__) does not match the name given in the repository's definition (@highwayhash); this will cause a build error in future versions.
INFO: Found 1 target...
Target //tensorflow/core:framework_headers_lib up-to-date (nothing to build)
INFO: Elapsed time: 5.460s, Critical Path: 0.01s

@hillegass Sorry, I misunderstood your requirement. //tensorflow/core:framework_headers_lib is meant for use within a BUILD file, when building with bazel. If you want to use libtensorflow.so in a different build system, and just want the header files, we package them up in the pip packages. For example, here is the python2 pip package. The header files go in <install path>/tensorflow/includem where <install path> is platform dependent. It usually is something like /usr/local/lib/python2.7/site-packages. Feel free to close the issue once you verify that it works for you.

My fault.  The headers were, indeed, in the python directory.  (For other lost people, on a Mac the include directory is /Library/Python/2.7/site-packages/tensorflow/include/ . Thank you!

Quick follow up note for others: A couple of the important headers (especially those related to sessions) are not in that include directory, so you will need to copy them from the source tree:
$ cd tensorflow/tensorflow/core/public $ sudo cp session.h session_options.h tensor_c_api.h /Library/Python/2.7/site-packages/tensorflow/include/tensorflow/core/public/

I have built the "//tensorflow:libtensorflow.so" target by bazel. Then I have copied all header files in "/usr/local/lib/python3.5/dist-packages/tensorflow" to "/usr/local/include". And I double checked that "session.h" is definitely in "/usr/local/include/tensorflow/core/public".
So I tried to build a very simple project by running command "g++ -o a.out main.cc -I/usr/local/include". And the error message is "main.cc:1:45: fatal error: /tensorflow/core/public/session.h: No such file or directory".  Apparently the "#include "/tensorflow/core/public/session.h" cannot find the header file in "/usr/local/include" even though the "session.h" is definitely there. Can anyone help? I got stuck in this for several days..

Heads-up: there is a dedicated //tensorflow:install_headers target now


Name added for project "Power Tools Sharing Economy"

There're two commits here, one makes a mess and the other cleans it up. Can you squash it please? See http://code.dblock.org/2015/08/31/getting-out-of-your-first-git-mess.html for help.


support for .net 6 LTS

I have no idea if this is the proper way to get .net 6 support changes over to you or if you even care about .net 6 but here is a PR just in case.

Hi @PostImpatica,
Thanks for sending this through, I do care about .NET 6 and appreciate the time you've taken to give the codebase a nudge.
I will give it a review. 👍


No CSS

I have updated to the latest version of vue, vue-cli, vue-multiselect and for some reason vue-multiselect is not loading .multiselect___*.* classes. Any idea what would be the reason?
It's loading my overrides but not native component's classes...

http://monterail.github.io/vue-multiselect/#sub-getting-started
in the very first block under basic usage

http://monterail.github.io/vue-multiselect/#sub-getting-started
in the very first block under basic usage

Oh dear... missed that. What is the reason behind this change?

@PrimozRome It was required to support SSR. Before that change it was impossible to run on the server side. It also made the whole thing a bit smaller, even after you combine the new CSS + JS file.

I have very similar error ( #791 ). After couple refreshes styles load, but before that  it basically blocks loading another styles. I tried via npm and via CDN ways.


Migrate torchdiffeq dependency from "extras" to "install_requires"

Currently, the dynamics module requires torchdiffeq as its only available backend. While it is unfortunate to add torchdiffeq as a core dependency for all of chirho, it seems necessary until #202 is addressed.
As the title states, this small PR migrates torchdiffeq dependency from "extras", which may or not be installed when a user installs chirho, to "install_requires", which will always be installed.

extras is a bit a blunt instrument currently. I'll add a "dynamics" option.


Publish to web - removed?

I can't find it, was it removed?

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

ID: bc005634-24c6-15c4-4352-e1455d63f4f3
Version Independent ID: 577c460a-08cc-892e-c5f9-e6106958f856
Content: Publish to web from Power BI - Power BI
Content Source: powerbi-docs/service-publish-to-web.md
Service: powerbi
GitHub Login: @markingmyname
Microsoft Alias: maghan

@dadadance Are you referring to the Publish to Web article - https://docs.microsoft.com/en-us/power-bi/service-publish-to-web?


Fix memory santization error

Fixes #759
Discovered using the Address Sanitizer diagnostic in Xcode, which I've left enabled in Debug.
We must explicitly zero-out the pointee field after this unsafe allocation, otherwise it could literally be pointing anywhere.

Possible that this will fix https://github.com/subconsciousnetwork/subconscious/issues/749


getNodeById

Hi, I'm new to d3. I'm creating nodes with id
  vis.selectAll("circle")
      [...]
      .attr("id", function(d) { return 'N'+i++; })
      [...]

Now, I have an array containing some nodeIDs (N001, N002, N003)
Where is the problem here?
for (var nodeid in stack){
		console.log(d3.select("[id='" + nodeid + "']").attr("name"))
	}

that select is not actually referring to my nodes

To select by id use #:
console.log(d3.select("#N001").node())

i get the error
Uncaught SyntaxError: Failed to execute 'querySelector' on 'Document': '575' is not a valid selector.

I was making a logical error, I need the original json source not the d3 reference, sorry.


Add model inference

There are linting errors.

The ipython notebook can be added in a separate PR.

hello,When do you plan to resolve these conflicts.

There are conflicts now.
Class names needs refactoring.


Improve iterators

Button -> Dealer
circle_table -> circle_index, which only takes the length and state for indexing players
Remove position
add n_iter to iterators, so that we can collect the results and simplify the tests

bors r+

bors r-

bors r+

Closes #81

This doesn't close #73, but we may be able to just skip non-active players on the fly. This PR at least ensures that we start iterating on active players.


fix uuidv7 in nodejs v18

https://github.com/bitrix24/b24jssdk/issues/2

Thank you.
I'll look into it soon.


Optimize Editor's memory consumption

Editor spawns too many external objects that explodes finalisation resource manager.

We can close this now. The recent changes already improve the situation dramatically. We can open more specific issues.


shapely 1.8.2 pyinstaller build on mac: AttributeError: 'NoneType' object has no attribute 'GEOSversion'

Sorry if this is the wrong place - I am posting here because while it's only an issue for conda users, it is a bug in the shapely source and not the conda feedstock.
Expected behavior and actual behavior.
Expect importing shapely.wkt to work in a pyinstaller app built in a conda environment, but instead it raises AttributeError: 'NoneType' object has no attribute 'GEOSversion'
Steps to reproduce the problem.
$ conda create -n test pyinstaller shapely==1.8.2 && conda activate test
$ echo "import shapely.wkt" > script.py
$ pyinstaller script.py
$ dist/script/script
Traceback (most recent call last):
  File "script.py", line 1, in <module>
    import shapely.wkt
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
  File "PyInstaller/loader/pyimod03_importers.py", line 495, in exec_module
  File "shapely/wkt.py", line 6, in <module>
  File "<frozen importlib._bootstrap>", line 1027, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1006, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 688, in _load_unlocked
  File "PyInstaller/loader/pyimod03_importers.py", line 495, in exec_module
  File "shapely/geos.py", line 252, in <module>
  File "shapely/geos.py", line 242, in _geos_version
AttributeError: 'NoneType' object has no attribute 'GEOSversion'
[9218] Failed to execute script 'script' due to unhandled exception!

The problem seems to be in this conditional:
https://github.com/shapely/shapely/blob/15e748b658f9ff9cf51bfb3fd958ded866478ec4/shapely/geos.py#L131-L147
In a pyinstaller frozen environment, _lgeos is never set and alt_paths are unused.
If you install shapely with pip instead of conda, there is no error because the dylib glob path matches and _lgeos gets defined:
https://github.com/shapely/shapely/blob/15e748b658f9ff9cf51bfb3fd958ded866478ec4/shapely/geos.py#L117-L129
Operating system
MacOS 10.15.7
Shapely version and provenance
1.8.2 from conda-forge

Same issue with conda on Linux... but not Windows (it works!?)

it seems that you lose a package:shapely.lib
I try to put this into the dist dictionary and solve this problem

I'd be happy to submit a pull request for this, if that would be helpful.

A PR is certainly welcome (that will make it easier to see what change is needed, I think none of the maintainers is very familiar with pyinstaller)

Just wondering if there is any update about this. I have a project where I'm currently having to pin shapely<1.8.2 because of this. Thanks!!

I had the same error building a bundle with pyinstaller from a conda environment on Linux using:

Ubuntu 20.04.5 LTS
shapely=1.7.1
pyinstaller=3.4
python3.6

Following approach might be possible to adjust to work on other platforms such as Mac or Windows as well.
geos.py
Checking out the geos.py file of the shapely package showed that there is already a routine for conda env and frozen states, see a copy of that part below for the version I am using:
if sys.platform.startswith('linux'):
    # Test to see if we have a wheel repaired by 'auditwheel' containing its
    # own libgeos_c
    geos_whl_so = glob.glob(os.path.abspath(os.path.join(os.path.dirname(
        __file__), '.libs/libgeos_c-*.so.*')))
    if len(geos_whl_so) == 1:
        _lgeos = CDLL(geos_whl_so[0])
        LOG.debug("Found GEOS DLL: %r, using it.", _lgeos)
    elif hasattr(sys, 'frozen'):
        geos_pyinstaller_so = glob.glob(os.path.join(sys.prefix, 'libgeos_c-*.so.*'))
        if len(geos_pyinstaller_so) == 1:
            _lgeos = CDLL(geos_pyinstaller_so[0])
            LOG.debug("Found GEOS DLL: %r, using it.", _lgeos)
    elif os.getenv('CONDA_PREFIX', ''):
        # conda package.
        _lgeos = CDLL(os.path.join(sys.prefix, 'lib', 'libgeos_c.so'))

The conda statement is pointing to libeos_c.so which is correctly found and bundled into the target directory of the pyinstaller bundle. However, when importing shapely while in bundle world the frozen statement runs trying to locate the library with the name libgeos_c-*.so.*. This however does not get created automatically during the bundling via PyInstaller.
PyInstaller hook for shapely
Hence, I wrote a custom hook for PyInstaller for this case. It makes sure to include the library in the target bundle so that it can be found by shapely there.
import sys
import os
import glob

if os.getenv('CONDA_PREFIX', ''):
	# path to general lib directory
	LIB_DIR = os.path.join(sys.prefix, 'lib')

	# check if geos frozen lib name is existent
	# at least with PyInstaller==3.4 it otherwise does not get created
	if not glob.glob(os.path.join(LIB_DIR, 'libgeos_c-*.so.*')):
		# otherwise create a new symlink to be copied to the frozen target
		# conda package. (from shapely.geos source code)
		LIB_FILE_NAME = 'libgeos_c.so'

		# create symlink that shapely package can locate when in frozen state
		LIB_SYM_PATH = os.path.join(LIB_DIR, 'libgeos_c-1.so.1')
		command = f'ln -sf {LIB_FILE_NAME} {LIB_SYM_PATH}'
		print(f"Created symlink {LIB_SYM_PATH} -> {LIB_FILE_NAME} and added to target.")

		os.system(command)
	else:
		# if the library can already be found make sure it still gets included
		# when bundling
		LIB_SYM_PATH = glob.glob(os.path.join(LIB_DIR, 'libgeos_c-*.so.*'))[0]

	# pass path of library to pyinstaller variable binaries [(source,target)]
	binaries = [(LIB_SYM_PATH, '.')]

Saving above code as hook-shapely.py into the hooks folder of PyInstaller executes the script when importing shapely somewhere in a script. In Linux the hooks directory could be retrieved by the following terminal commands:
HOOK_PATH=$(python -c "import PyInstaller.hooks; print(PyInstaller.hooks.__file__)")
SHELL_PATH="$(dirname "$BASH_SOURCE")"

Summary
This hook is what works on Linux and with some small changes might solve similar issues on other platforms. Ideally, a more complete version would be suggested to the PyInstaller team to include in their next version, but I thought I'll still post here in case that is helpful for somebody.

I think this has been fixed. https://github.com/shapely/shapely/issues/1526 looks like a duplicate of this issue.

In any case, everything that is mentioned here is also specific to Shapely <= 1.8, since starting with 2.0 the core library has been fully refactored.


patch not working

when i try to use it with mpv . the swallowing patch is not working. even not for emacs, sxiv too. when i try to open it opening different window

i didnt patch swallowing patch in st

hmm i'll try it here

anyway thanks dude i am using alternative way to do swallow the mpv,sxiv and zathura.
yay -S --noconfirm devour-git
with this package  devour
like
devour mpv vid.mp4
devour zathura book.pdf
devour sxiv pic.jpg
to automate this i add the alias to my ~.zshrc file

oh cool then :D

please investigate in that too. i am also try to please do that

Works for me. @r4vanan try to replace this line in your dwm:
{ "St",               NULL,     NULL,           0,         0,          1,           0,        -1 },

with this:
{ "st",     		 NULL,     NULL,           0,         0,          1,           0,        -1 },

@basilioss thanks bro it works fine now


Give UI nodes with Display::None an empty clipping rect

Objective
Outlines are drawn for UI nodes with Display::None set and their descendants. They should not be visible.
Solution
Make all Nodes with Display::None inherit an empty clipping rect, ensuring that the outlines are not visible.
Fixes #10940

Changelog

In update_clipping_system if a node has Display::None set, clip the entire node and all its descendants by replacing the inherited clip with a default rect (which is empty)

Are there any performance implications to this "rendering and then clipping" as opposed to special casing Display::None eliding rendering entirely?

Are there any performance implications to this "rendering and then clipping" as opposed to special casing Display::None eliding rendering entirely?

Basically what this PR does is special case Display::None in the clipping system to ellide rendering.


Use os/user.Current() instead of Getenv("USER[NAME]")

Environment variables like this are usually set by the shell that
started this gitea. If there is no shell involved in the starting
process relying on env vars failes.
An example for this scenario would be Debian's start-stop-daemon,
which doesn't set this variable for the process it starts.

Probably it is when you are in Active Directory/Domain , depending by the network et al. I have a software using it, and I noticed no problems in my infrastructure. As you can see HERE this is the first control I do. In my experience, on Windows this is running a bit slow just when the LDAP/AD is having some issue.... I think you could ignore this, "dev" can't solve other's network problems.

Thanks. @Knorkebrot @uriel-fanelli


Fix YouTube playlist insert

Using the Docker develop image, I noticed that the YouTube playlist insert API call failed with the message Playlist id not specified.
It's fixed after adding a 'this.' before the playlist_id variable.
2024-01-04T19:42:52.886Z | YouTubeExporter.export <success> Video uploaded: wuM-TsF7XXX
2024-01-04T19:42:52.887Z | YouTubeExporter.addToPlaylist <info> Adding wuM-TsF7XXX to playlist...
2024-01-04T19:42:52.887Z | YouTubeExporter.addToPlaylist <info> Found playlist PLvNNyUh4Ovo0Zk9PLjUsFMPYoSAcXXXX for channel XYZ
2024-01-04T19:42:53.223Z | YouTubeExporter.addToPlaylist <error> Could not add video to playlist: Playlist id not specified.
2024-01-04T19:42:53.223Z | YouTubeExporter.export <error> Could not add video to playlist: Playlist id not specified.
2024-01-04T19:42:53.224Z | automator.onEndDownload <error> Export error: Playlist id not specified.

this isn't really how the logic is supposed to flow, i think i made an error in the playlist id empty check on line 399, but where you've changed code it's supposed to be a "fallback" if the automatic settings are not configured. it needs a bit of a rethink from me

oh yeah, I see. I didn't further look into the reason why the function parameter is empty in the first place


Add Python 3.6, drop support for EOL Python

Python 2.5-2.6 and 3.3 are EOL and no longer receiving security updates (or any updates) from the core Python team.

Version
Release date
Supported until

2.5
2006-09-19
2011-05-26

2.6
2008-10-01
2013-10-29

3.0
2008-12-03
2009-06-27

3.1
2009-06-27
2012-04-09

3.2
2011-02-20
2016-02-27

3.3
2012-09-29
2017-09-29

They're also little used. Here are its PyPI downloads for last month:

category
percent
downloads

3.6
35.84%
252,944

2.7
33.30%
235,031

3.5
18.91%
133,480

3.7
10.06%
70,965

3.4
1.58%
11,154

null
0.19%
1,345

2.6
0.08%
594

3.3
0.02%
147

3.8
0.01%
45

3.2
0.00%
11

3.1
0.00%
1

Total

705,717

Further:

2.5 and 2.6 are not tested on the CI, so it's quite possible it doesn't work on those.

3.3 is now broken on master on the CI due to dependencies no longer supporting it: https://travis-ci.org/hugovk/virtualenv-clone/builds/435578978

The test requirements virtualenv, tox and pytest have already dropped <=2.6 and 3.0-3.3.

Merged, thanks @hugovk!  @eeshangarg can you bump the version and do a pypi release?

It would be nice to include https://github.com/edwardgeorge/virtualenv-clone/pull/40 in the next release. Please can you have a look?

Reviewed and merged, thanks @hugovk!

@hugovk FYI, we just got the 0.4.0 release out to pypi.  Thanks again for the PR!

Thank you, and you're welcome!