gpio_callback ambiguity in union pin vs pin_mask

I notice that the gpio_callback structure has a union that's documented as identifying the pins that trigger a callback, expressed as either a single ordinal (pin) or a mask of pins (pin_mask).  The union documentation in the header explicitly states that the application may change the pins associated with the callback at any time.  (Oddly, documentation for members of the struct does not appear to be generated.)
There's nothing in the structure that clearly indicates which union member is valid.
As best I can tell, the gpio_utils.h assumes that the pin_mask field is the one used; this is also the one initialized by gpio_init_callback().
However, gpio_intel_apl references the pin element.
Something's hinky here.  Probably the union should be replaced by the pin_mask field, any resulting compilation errors fixed, and the suggestion that callbacks can be controlled by pin ordinals removed from the documentation.

Thanks; that explains it.  Issue was introduced in PR #10085.  Looping in @dcpleung.
Nonetheless, a field that's public and documented as under application control (since the application owns the structure) now has a driver-specific interpretation.  That's a problem that should be resolved before it bites somebody.  Somebody new might write an application that sets the callback pin by using an ordinal, which will fail on every platform except up_squared.

yes, that might create an issue in application indeed, mostly a portability one since setting up the cb will not be the same on that controller than other ones.

Sorry for the late reply. I was on vacation. :)
I have given some thoughts about this. I think expanding the APIs to support both pin bitmasks and ordinal pin numbers would lessen the confusion. The GPIO drivers can decide which one to support/implement (or both). As for callback, it is always possible to tag each callback to specify whether the value is a pin mask or ordinal number. However, it would make the ISRs more complicated. I think the drivers should only support one value type in callback.

Subordinate devices (I2C, SPI) that have auxiliary GPIOs like reset signals must be able to manipulate those GPIOs in driver code without knowing whether a particular SoC GPIO driver uses mask or ordinal pin specifiers.  How would you support that?
Supporting two incompatible GPIO APIs seems like a far more complex and impactful approach than simply having up-squared split the 40 GPIO pins across two devices.

Attempted fix in PR #12850


Add test case for protected \Slim\Psr7\Stream::attach method

This test case would test, if the detach method gets called in case the attach method is called but there was already a stream attached.
This is maybe an overkill as this method would actually only be called on construction of a new \Slim\Psr7\Stream. Of course, in this case, there is no stream attached.

Coverage increased (+0.1%) to 96.752% when pulling a39217d825a0d25efb995ff55593a3be7b209391 on adriansuter:patch-streamTest into 84c7a0ab681a301803ad49cf449fffab3879bf5f on slimphp:master.


feat: c2-event evidence type

Adding an evidence type to capture C2 events in ASHIRT.
We have ingestors (python script + systemd service file) for both Cobalt Strike and Brute Ratel, though both have some bugs we are working through squashing. If we like the direction of adding this feature into ASHIRT I'd be partial to the ingestor repo being owned by ashirt-ops so that they can live with the rest of the project.
I confirm that this contribution is made under the terms of the license found in the root directory of this repository's source tree and that I have the authority necessary to make this contribution on behalf of its copyright owner.

Saw this come in. Should have some time tomorrow to look through the PR. We're happy to adopt the ingestor repo over to the org. I think that makes sense as well. Do you have some samples of logs from brute ratel or cobalt strike so that we can test things end to end? Also, are the ingestors public currently?

Just made the ingestors public here. There are some (very succinct) sample logs there for BR and CS (no mythic atm), as well as a python script to simulate log writing to test the ingestors.

I've made the changes we've discussed here. Sorry for the delay on this one, thanks for your patience. If there's anything else I can do to clean this up do lmk, this was my first time writing React 😁

Thanks for getting the changes in. I should have some time this afternoon to take a look

I'll make some time this weekend to go through it.

Thanks for the review Joel. I'm going to get to work on the code cleanup work you noted. When it comes to styling I'd appreciate some help (especially grid sizing issue, i can't get that thing centered for the life of me), but let me give this one more pass and I'll ping for another review and any styling help I may need.

I'll try to find some time. fit seems like the primary issue why it doesn't fit right is because of the padding on the c2-event-grid. That somewhat breaks the lightbox view, but I think that there should be a way to fix specifically that (it's been awhile though, so I don't know what it is off the top of my head).
I'd say look at the har viewer as an example, but that's broken due to lazy loading components. There may still be some insight there though.


test

The action should add aneed more info label and comment with the required items

Actual Behavior
codepen.io
Expected behavior
Action removes the need more info label

codepen.io

Expected Behavior


Carthage support

Carthage depends on dynamic frameworks and since SwiftyUserDefaults was meant to be used with CocoaPods you didn't need any xcodproj. To support Carthage those targets were needed so I made xcodproj that has two targets for each iOS and OSX. I hope this isn't a problem. CocoaPods support should remain unchanged.
I also moved tests from main.swift to test file and substituted assert with XCTAssert, so now tests can be run for each platform individually.

Thanks @rad3ks, but #14 already added Carthage support (it just took me a while to get it merged).
Could you elaborate about why XCTAssert is better than assert? I mean, I know the latter doesn't integrate with Xcode, but for the purposes of this project, it works fine. What do you mean about running for "each platform individually"?

Oh thanks, didn't check if there is already a pending PR with Carthage support.
I used XCTAssert because I moved tests to XCTestCase, this is the only reason.
For each platform individually, because I added separate framework targets for iOS and OS X. This was just a quick PR so I can move on with my own job (need only iOS platform) and I couldn't figure out how to build all architectures from a single framework target (had some issues - don't remember specifics).
Thanks for merging that other PR :+1:


Null pointer crash after failed HRESULT returned by DX12

Description
My Unreal Engine game "Raven.exe" crashes when I take a Renderdoc capture but it does not crash otherwise.  It's not clear if this is a RenderDoc bug so feel free to close this issue if crashing is the expected behavior.
What happens is that DX12 returns the error 0x887A0006: DXGI_ERROR_DEVICE_HUNG (See the attached log file of the Raven.exe process), and then Renderdoc dereferences an internal null pointer.  What I expect to happen is for Renderdoc to propagate the error to the application instead of crashing internally inside Renderdoc.
Steps to reproduce
My game is very large and under NDA so I can't upload it.
I've attached a log file and some debugger screenshots which show how the game crashes inside Renderdoc:
"Raven_Process_Log.txt" shows the output of the Raven.exe process launched by Renderdoc.
"First_Exception.png" shows the DXGI_ERROR_DEVICE_HUNG exception.
"Crash.png" shows where Renderdoc dereferences a null pointer.
Environment

RenderDoc version: v1.16 (compiled on my local machine at git tag v1.16)
Operating System: Windows 10
Graphics API: DX12
See attached file, "Hardware_Specs.png"

Raven_Process_Log.txt

There are some variants of this problem where the crash happens at other code locations inside Renderdoc.

Are you able to share your program with my privately? I understand that you can't share it publicly due to NDAs but unless I can reproduce the problem there's no way I can investigate this issue.

That's a GPU driver crash. Everything from the attached log is essentially useless after line 2, when wer.dll is loaded (windows error reporting). All logging/behavior after that is just reacting to the GPU driver crash unfortunately. Causes for that can be extremely hard to figure out but one thing you should always do when hitting those types of issues is updating your drivers.

Yes I'm aware of what the error messages mean. That's why I asked above for a reproducible test case to investigate with.

I'm having difficulty reproducing the crash in a small test project that doesn't contain private content.  However, I did manage to get the same crash in Unreal without running Renderdoc at all, which means Renderdoc is not the cause of the crash.  However, unreal responds by catching the DX12 error and exiting gracefully with a message.  Ideally, Renderdoc would also respond by exiting gracefully instead of dereferencing a null pointer.

I treat device lost errors about as equally as fatal as memory allocation failures, and trying to detect and gracefully handle it in all cases it can happen is similarly not always feasible or even particularly useful (since the worst is you get a crash instead of a message box before a fatal error, if the application would handle it as well).
If the device lost is caused by RenderDoc work then it papers over the real problem, so I'd still want to investigate it regardless, but if you're seeing it without RenderDoc then it sounds like it might be caused by invalid use on the application side which is not something RenderDoc is intended to handle.
FWIW I do try to handle these on the replay side since it's a much more controlled environment and I know the exact flow rather than being injected into another program, but most importantly I can actually prompt the user to share a repro case with the capture itself - which is not possible when capturing.


feat: add authorization & authentication to broker

Adds a simple layer for authorization and authentication.
In an average situation, the broker server starts up and generates a token that can create and revoke more tokens with other scopes. This control token is printed out as a debug log statement, where it can be found to create tokens with the correct scope for jobs to be used with the runner and bot modules.
Ideally, in the future we can OAuth or something of that nature into a simple web portal to control these tokens.
To-do

[x] Add an authorization layer to the broker
[ ] Augment bot and runner code to use their tokens from env
[ ] Run integration tests

@ckerr Looks like base64url probably isn't available on node v14 (the feature only landed this past January, which makes sense why it'd only be in v16 or so), which is what's being used in the GitHub Action currently. Leave it as-is or change it back?

The coverage is still low because of the two new broker endpoints I added being left untested & uncovered by tests. I'm mostly just put off by the current method of testing the endpoints we have right now and either need more energy to write those two sets of tests or pitch a plan to refactor our testing. 💡


Backlog spikes reported every hour

We run many workers on GKE that essentially pull messages from a Pubsub subscription at a rate of about 120k/min, do some processing and write the result into Bigtable. As part of a recent change we upgraded this Pubsub client library from 0.29.1 to 1.2 and immediately started to see alerts.
What we started to see after this upgrade was spikes in the reported backlog (and oldest unacked message age). These happened hourly. However, our service appeared not to suffer, and continued to output its product at a steady rate.
Here is an overview of this upgrade as seen in Stackdriver (running Pubsub v1.2 highlighted in red, then after 10am Friday we reverted JUST the pubsub version and the process returned to normal):

Zooming into approx Friday 12am until noon, and showing backlog at the top and oldest message at the bottom:

It is pretty clearly something that happens every hour.
I know there's another Github issue for memory spikes, but at least as far as we can tell that's not the case for us. In fact, I don't think we actually saw a real impact on processing output. This assessment is based on: 1) we didn't see lag in out downstream client which is usually the case with actual backlogs and 2) we didn't see increase in worker cpu when the backlog recovered. The biggest problem is we use these alerts on this subscription as our main indicator that the process may be experiencing problems for some reason.
Environment details

OS: GKE
Node.js version: 12.x
npm version: 6.11.3
@google-cloud/pubsub version: 1.2

Steps to reproduce
Not sure we do anything special. Each worker instance creates a simple client which processes messages. We run this on GKE, with one node instance per pod. Approximately 64 workers are all pulling from the same subscription. We generally just ack messages regardless of successful processing because in this application it's ok to just drop them (a separate process will take care of it).
Hope this is helpful. Let me know if I can provide any additional data.
Thanks!

@pjm17971 Hi Peter, we've been seeing a number of issues lately that involved upgrading the nodejs-pubsub version from one of the 0.x to the latest one. The common suggestion I've seen is to try switching to the C++ gRPC bindings, so you might give that a try.
const {PubSub} = require('@google-cloud/pubsub');
const grpc = require('grpc');
const pubsub = new PubSub({grpc});

(Or however you instantiate the PubSub object, you can provide grpc to replace its implementation.)
I'll look at this some more, but I wanted to give you something quick to try!

We have seen similar behaviour when using the @grpc/grpc-node pure JavaScript module that is the default in > 0.29.1 versions and I can confirm that this is solved, like suggested above, by opting in to the native bindings gRPC module instead.

Just chiming in to let you know that I'm experience the precise same behavior as @pjm17971 with a couple of subscribers running on GKE.
Here are the versions and the respective behavior that I have been observing:
2020-01-26  pubsub-0.31.1 grpc-js-0.5.2  --> No spikes
2020-02-17  pubsub-1.1.5  grpc-js-0.6.9  --> Spikes
2020-02-17  pubsub-1.5.0  grpc-js-0.6.16 --> Maxed out CPU on idle subscriptions (will report in separate issue)
2020-02-17  pubsub-1.1.5  grpc-js-0.6.9  --> Spikes (reverted due to above issues)
2020-02-18  pubsub-1.5.0  grpc-1.24.2    --> No spikes since then (using C++ grpc instead of grpc-js)

Providing the C++ grpc bindings to the PubSub() constructor as suggested by @feywind seems to be a viable workaround so far.

That said, with the pubsub-1.1.5 grpc-js-0.6.9 combo I occasionally got precisely this error crashing my node process: https://github.com/googleapis/nodejs-firestore/issues/739
node[1]: ../src/node_http2.cc:892:ssize_t node::http2::Http2Session::ConsumeHTTP2Data(): Assertion `(flags_ & SESSION_STATE_READING_STOPPED) != (0)' failed.
 1: 0x9bcb80 node::Abort() [node]
 2: 0x9bcc07  [node]
 3: 0x9f253a node::http2::Http2Session::ConsumeHTTP2Data() [node]
 4: 0x9f2ec0 node::http2::Http2Session::OnStreamRead(long, uv_buf_t const&) [node]
 5: 0xad941b node::TLSWrap::ClearOut() [node]
 6: 0xadb878 node::TLSWrap::OnStreamRead(long, uv_buf_t const&) [node]
 7: 0xa71e66 node::LibuvStreamWrap::OnUvRead(long, uv_buf_t const*) [node]
 8: 0x12baaa9  [node]
 9: 0x12bb0d0  [node]
10: 0x12c0c08  [node]
11: 0x12af54b uv_run [node]
12: 0xa00127 node::NodeMainInstance::Run() [node]
13: 0x993dd8 node::Start(int, char**) [node]
14: 0x7fc6d2cf42e1 __libc_start_main [/lib/x86_64-linux-gnu/libc.so.6]
15: 0x932cb5  [node]

@pjm17971 have you been observing these errors as well?
I was not able to reliably correlate these crashes with the spikes in unacked messages though.
Also, according to this grpc issue the crashes problem might have been fixed in grpc-js-0.6.13 which I haven't been able to verify yet, because at least grpc-js-0.6.16 seems to be causing a whole different range of problems… Will let you know if I find out more.

I just realized that in the original issue description the spikes appear exactly each full hour. This is not the case in my setup. In my setup the spikes appear in irregular intervals around 2-5 times per day.

Just a quick confirmation that the issue is gone for me since switching back to the C++ bindings. Need to wait for #890 until I can try out grpc-js again.

@feywind Sorry I didn't reply, but kind of a non-update from my end: we went back to the C++ gRPC implementation and our process behaved fine. We couldn't reproduce easily in a non-production environment so we did not attempt to deploy again with the bad library version. We can try any new version of grpc-js again down the road if a fix is believed to be in place and give feedback as to if this works for us. Sounds like #890 kind of has this problem covered.

Thanks, everyone! There's a PR out now to update to the grpc-js that should fix the issues in https://github.com/googleapis/nodejs-pubsub/issues/890. I'll update here again once that's merged, and an update to that nodejs-pubsub should pull it in.

I have removed the C++ bindings again and upgraded to<EMAIL_ADDRESS>(which fixed  #890 for me). I have not observed a single spike for 24h now, a situation I have never seen with<EMAIL_ADDRESS>So for the time being I conclude that
<EMAIL_ADDRESS><EMAIL_ADDRESS>
is finally a stable setup for my use case again!
@pjm17971 I think the above versions are a setup that is worth trying out.

Thanks for the update! I'm working on getting the default grpc-js version pushed up to 0.6.18. There might be a next tag coming up that will pull in 0.7.0, but the timing on that is TBD.

grpc-js is up to 0.6.18 in the last few releases, and this issue hasn't seen much traffic lately, so I'm going to go ahead and close it. Please feel free to re-open/comment if necessary.


add documentation on how to set up friendly-snippets

Added documentation to clarify #680

I am unsure whether it would be better to just outright enable vscode-style snippets for LuaSnip so people would not encounter this problem, since a comment telling you to insert code somewhere else seems weird (to me).

Hi.
This would need substantial rework in order to be useful. Also I'm not sure that providing 1000% VSCode compat is the goal of this project.
In particular, should you choose to re-open and pursue this, you'd need explicit instructions as to where to put what so as to be more friendly for newer folks which is the target audience of this project.
Thank you for your contribution but I'm closing for now.

@feoh I am not sure what you are getting at here; the friendly-snippets plugin requires LuaSnip to accept vscode-style snippets for it to work properly, thus the comment/suggestion. That being said, I agree with you in that this commit itself is not the way to go.


Google Places API

This gem looks great. Are you planning to add Google Places search, autocomplete, etc?

Support for google places is coming thanks to @dabooze .
See this thread: https://github.com/apneadiving/Google-Maps-for-Rails/pull/123#issuecomment-3326743


Refactor formula file creation

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.
[x] Have you successfully run brew tests with your changes locally?

This change consolidates almost all of the instances of formula_file = CoreTap.new.formula_dir/"testball.rb" into the method include_formula_file, which makes use of @formula_file.

For tests that involve at least two formula files, the method include_formula_files creates @foo_file and @bar_file.

Tests that involve three formula files create a @baz_file.

The url for @formula_file is now solely "file://#{File.expand_path("..", __FILE__)}/tarballs/testball-0.1.tbz".

Before, it was either "file://#{File.expand_path..." or "https://example.com/testball-0.1.tar.gz".

Some tests ensure only @formula_file.unlink, whereas others ensure @formula_file.unlink unless @formula_file.nil?

These were left as-is, but should all tests have the same ensure block?

test_create was left as-is -- I wasn't sure how to improve upon it, given that url is not an accessible attribute on formula instances.

test_options has also been (mostly) left as-is for now.

It seems like depends_on "bar" => :recommended should not be included in the default @formula_file, though maybe I could append this to the formula from within test_options?
Edit: hm, appending doesn't seem to be a solution (at least, not the way I've used it).

I've run test_options as shown below, and this error is raised within cmd_output :
Error: undefined method 'depends_on' for Formulary::FormulaNamespace2d3ec45e3a12a54ca19cb33c3b0cddbf:Module

def test_options
  include_formula_file
  @formula_file.append_lines("depends_on \"bar\" => :recommended")

  assert_equal "--with-foo\n\tBuild with foo\n--without-bar\n\tBuild without bar support",
    cmd_output("options", "testball")
ensure
  @formula_file.unlink
end

🎈

A few comments but generally looking great 😍

The de-duplication of this stuff is good, but may I suggest a somewhat different approach? Here is what I'd hope this refactoring would yield:

A method named setup_test_formula(name) that:

Creates either of three possible formulae depending on the given name: testball, foo, or bar.
Adds the path (a Pathname object) of the just created formula to an array @formula_files.
Returns that same path for use within the calling test_* method.

A modified teardown method that:

Iterates over the entries of @formula_files and unlinks all those files. No need to do this in every single test in the ensure block.

A lot of modified test_* methods that:

Only use the path returned by the setup_test_formula method and refrain from touching the @formula_files instance variable.
Quite a few dropped or shortened ensure blocks.

I hope I was somewhat convincing. 😸 I strongly believe this will combine the benefits of less boilerplate (already achieved in the current code) with greater clarity (explicitly requesting certain formulae by name and getting their path in return while avoiding implicitly defined instance variables).

To accommodate the currently unhandled cases where a more customized formula is needed, the method could be extended with a second argument to accept something like:
baz_path = setup_test_formula "baz", <<-EOS.undent
  desc "The baz formula"
  url "http://example.com/baz-0.1.tar.gz"
  depends_on "foo"
  depends_on "bar" => :optional
EOS

This would allow to still benefit from the auto-cleanup logic suggested above and the method could further reduce the necessary boilerplate code by providing the surrounding class Baz (generated with Formulary.class_s from name) and end lines.

Thanks for the suggestions, @UniqMartin! This was a fun challenge.
I have:

defined setup_test_formula.
modified setup, teardown, and various test_* methods to account for the @formula_files array.

I have also:

fixed most of the "offenses" detected by brew style test_integration_cmds.rb
refactored test_desc and test_home according to prior discussion re: test_search

I hope it's OK that I made those extra changes even if they weren't strictly related to the task at hand; I figured I might as well.

Unsurprisingly, I really like the approach. :joy: But in all seriousness, I think this is a very nice improvement to the testing code and a nice consolidation of the test formula setup logic. :+1: The diff statistics are also quite encouraging (we got rid of 166 basically redundant lines):
$ git merge pr/370
Auto-merging Library/Homebrew/test/test_integration_cmds.rb
Merge made by the 'recursive' strategy.
 Library/Homebrew/test/test_integration_cmds.rb | 388 +++++++++++++++++++----------------------------------------------
 1 file changed, 111 insertions(+), 277 deletions(-)

I hope it's OK that I made those extra changes even if they weren't strictly related to the task at hand; I figured I might as well.

Ideally, these would have been separate commits, but I don't mind accepting this as-is (modulo the minor indentation fixes pointed out in the code comments).

I hope it's OK that I made those extra changes even if they weren't strictly related to the task at hand; I figured I might as well.

Ideally, these would have been separate commits, but I don't mind accepting this as-is (modulo the minor indentation fixes pointed out in the code comments).

👍  Thank you! I'll keep this in mind for future reference.
I've made the indentation fixes, but I'm having trouble with git rebase (again 😣 )... attempts to remove the previous commit leads me to a modified file where the work of my previous commit has been wiped out, and there are merge conflicts for test_deps and test_uses...
This may be because I blindly ran git rebase -s recursive -X ours master at some point during this process. Sorry, any idea of how to resolve this problem?

I've made the indentation fixes, but I'm having trouble with git rebase (again 😣 )... attempts to remove the previous commit leads me to a modified file where the work of my previous commit has been wiped out, and there are merge conflicts for test_deps and test_uses. Normally, just removing the previous commit during rebase seems to bring the desired effect...

I'm assuming you're talking about git rebase -i? You almost never want to remove individual commits in the sheet this brings up, as that indeed removes the changes made in the respective commits. This would also explain the merge conflicts as the follow-up adjustments depend on those changes. What you instead want to do in almost all cases is combine the changes from multiple commits, e.g. you leave the first commit at pick and change the next commit in the list from pick to squash. This will combine these two commits and ask you for the commit message of this combined commit in the process.
Or use git commit --amend, if all you want to do is make adjustments to the most recent commit.

This may be because I blindly ran git rebase -s recursive -X ours master at some point during this process. Sorry, any idea of how to resolve this problem?

Don't do that, unless you know exactly what it is doing or someone else (me) has advised to use it in very specific circumstances after having tested it does the right thing. 😛
You almost always want to use a regular git rebase or git rebase -i depending on whether you want to rebase your changes on top of an updated upstream branch or whether you want to squash/rearrange/… commits in your current branch (but usually without actually rebasing your branch, i.e. the base commit in the upstream branch from where your branch forks off remains the same).

And if you're stuck with a borked local branch: The easiest fix in this case would be to throw away the local branch with git branch -D refactor-formula-file-creation and then recreate it from the remote branch in your forked repository via git checkout eirinikos/refactor-formula-file-creation (it is still in good condition). The indentation fixes are small enough to be manually reapplied on top of that.

This may be because I blindly ran git rebase -s recursive -X ours master at some point during this process. Sorry, any idea of how to resolve this problem?

Don't do that, unless you know exactly what it is doing or someone else (me) has advised to use it in very specific circumstances after having tested it does the right thing. 😛
You almost always want to use a regular git rebase or git rebase -i depending on whether you want to rebase your changes on top of an updated upstream branch or whether you want to squash/rearrange/… commits in your current branch (but usually without actually rebasing your branch, i.e. the base commit in the upstream branch from where your branch forks off remains the same).

Thanks @UniqMartin! Yup! I ought not to have done that; I guess I often throw caution to the wind when things seem desperate. 😬

And if you're stuck with a borked local branch: The easiest fix in this case would be to throw away the local branch with git branch -D refactor-formula-file-creation and then recreate it from the remote branch in your forked repository via git checkout eirinikos/refactor-formula-file-creation (it is still in good condition).

I went ahead with this route, did git add and git commit, checked out and switched to a new branch, and successfully squashed the commits with git rebase -i. Thanks for the explanations; I've had a lot of trouble with rebasing and I'm still getting familiar with its usage.

I'm happy with this refactoring and think it's ready to be merged, but will keep it open a bit longer (maybe a day or two) so that @MikeMcQuaid and other maintainers have a chance to voice their opinions.

😍 @eirinikos!


($$18++NEW@SEX))*Lily Phillips Viral Video Lily Phillips Leaks Original Video On Social Media X TikTok Trending #61

44 seconds ago
L𝚎aked Video Lily Phillips Original Video Viral Video L𝚎aked on X Twitter Telegram
..
[-𝐅𝐔𝐋𝐋-𝐕𝐈𝐑𝐀𝐋-]— Lily Phillips Video Original Video Link Lily Phillips Video Viral On Social Media X Now [1U2M3N]
[-wATCH-]— Lily Phillips Video Original Video Link Lily Phillips Video Viral On Social Media X Trending Now
[-wATCH-]— Lily Phillips Video Original Video Link Lily Phillips Video Viral On Social Media X Trending Now
[-wATCH-]— Lily Phillips ʟᴇᴀᴋᴇᴅ Video ᴠɪʀᴀʟ On Social Media ˣ ᵀʷⁱᵗᵗᵉʳ
[-wATCH-]— Lily Phillips ʟᴇᴀᴋᴇᴅ Video ᴠɪʀᴀʟ On Social Media ˣ ᵀʷⁱᵗᵗᵉʳ
[-wATCH-]— Lily Phillips Video Original Video Link Lily Phillips Video Viral On Social Media X Trending Now
Lily Phillips Original Video video took the internet by storm and amazed viewers on various social media platforms. Lily Phillips, a young and talented digital creator, recently became famous thanks to this interesting video.
L𝚎aked Video Lily Phillips Original Video Viral Video L𝚎aked on X Twitter
Lily Phillips Original Video video oficial twitter
L𝚎aked Video Lily Phillips Original Video Viral Video L𝚎aked on X Twitter...

2


Fix native loaders when processing ledger

Problem
Native loaders do not work properly when the solana-runtime dependency is a git or crates.io dependency (See here for details: https://github.com/solana-labs/solana/issues/5966)
Solution

Add a callback to modify each new bank to have instruction processors for vote and stake transactions

Depends On: https://github.com/solana-labs/solana/pull/6383

@jstarry - is this PR still needed?

Nope


Getting "File exists" error upon concurrent start of pex package

pex version: 1.2.9
In pex/environment.py: force_local(), the os.rename(explode_tmp, explode_dir) operation may fail because another process ran the pex (for the "first time") at the same time.
Looking at the .pex/code directory, we can see that indeed, the target directory (4042b3b39dfbb555b729eeb9f664f280069e1277) was created just before
$ ls ~/.pex/code | grep 515
drwxr-xr-x  3 usr grp  107 Aug 19 21:36 4042b3b39dfbb555b729eeb9f664f280069e1277
drwxr-xr-x  3 usr grp  107 Aug 19 21:36 4042b3b39dfbb555b729eeb9f664f280069e1277.de58f52453e24270b06046ec8695458f
$ stat 4042b3b39dfbb555b729eeb9f664f280069e1277 | grep Modify
Modify: 2017-08-19 21:36:59.976220274 -0700
$ stat 4042b3b39dfbb555b729eeb9f664f280069e1277.de58f52453e24270b06046ec8695458f | grep Modify
Modify: 2017-08-19 21:36:59.980220272 -0700

Suggestion: catch the case where the directory exists and pass, assuming that another instance of the pex did the job already.

This style of inter-process concurrency bug has been fixed wholesale for a while now by moving to the atomic_directory abstraction throughout the code base:
https://github.com/pex-tool/pex/blob/27044bd7fb425725a705c3e7e776ed34e1c58b20/pex/atomic_directory.py#L236-L256
The implementation was hammered into its current shape by alot of very concurrent usage via the Pants v2 engine.


Osmedeus v4.1.1 using full disk at subdomain scanning

Hi,
The osmedeus latest version uses full disk for subdomain scan. At the step of subdomain scanning, huge results generate and save into final-subdomain files. The scanning process runs until the disk is full.
Please check out this urgently.
I am using the pro version.

Thank you for reporting this, this is actually the expected result since it does permutation subdomain enumeration with goaltdns and str-replace.
I just update a new workflow with the options to disable it like this
osmedeus scan -f extensive -t sample.com -p 'enablePermutation=false'

I try osmedeus scan -f extensive -t target.com -p 'enablePermutation=false' this command but still same result.

this is a file  "probing.yaml"


Broken links in docs.microsoft.com

For example all of the links in the "Option Module" on this page: https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/options

Thanks for noting this. It is a dupe of dotnet/docs#17579.


Improvement for listener(InventoryListener) method.

I want to use that method without provider and with buttom inventory. For example;
@NotNull
public SmartInventory inventory(@NotNull final Player player) {
    return SmartInventory.builder()
        .title(this.title.build(MapEntry.from("%player_name%", () -> player.getName())))
        .manager(DynamicShop.getAPI().inventoryManager)
        .size(this.size / 9, 9)
        .closeable(true)
        .id("quick-sell-page")
        .provider(new InventoryProvider() {
            @Override
            public void init(final Player player, final InventoryContents contents) {
            }

            @Override
            public void update(final Player player, final InventoryContents contents) {
            }
        })
        .listener(new InventoryListener<>(InventoryClickEvent.class, event -> {
            event.getWhoClicked().sendMessage("test");
        }))
        .build();
}

I want to sell that with just click on it, but the inventory library can use with just top inventory. the test message don't come when I click the item in the buttom inventory. But It will be a good feature.

This code is forbidding that feature.

Maybe buttomListener(InventoryListener) method can add for the builder with;
if (clickedInventory.equal(buttomInventory)) {
    // TODO run buttom listener.
}

So that would be same as #12


holographic-remoting-version-history: Fix date associated with 2.9.3

Follow-up of commit ec2641049 (Add 2.9.3 Release notes (#4011) )

#sign-off

#sign-off

Thanks for the review and integration 🙏👌


There is any way to use it globally..?

Where have a dropdown or something like that we need this, my question is can we use this globally.? that's why we don't need to import this in every component.

I'm also interested in this.

I'm also interested in this.

In main.js, simply do
Vue.mixin({
  mixins: [ clickaway ]
})

Anything you define inside Vue.mixin, is globally available, that be data, methods, computed or more mixins.

Using in component template should be defined in directives:
Vue.component('iam-select', {
		directives: {
			onClickaway: VueClickaway.directive,
		},

and html-file should have
<script<EMAIL_ADDRESS>


US: Fred Meyer

Brand : Fred Meyer
Opening rule : shops open with adjusted hours
Wikipedia / Wikidata : https://www.wikidata.org/wiki/Q5495932
Opening hours :  07:00 - 21:00, with 07:00-08:00 dedicated to Senior shoppers (https://www.fredmeyer.com/i/coronavirus-update/store-information)
Source :  https://www.fredmeyer.com/i/coronavirus-update

This is integrated, thank you :+1:


Support for 360 Pano Images (glomap)

This is a great Work!
Are there any plans to develop a glomap that supports spherical images?

I have no experience with global SfM. Thus, no planing is for glomap.


KeyError: 'feat_map' in dataset.py

Thanks for releasing your wonderful work!
When I run the training commend, I got this error. Then I print all keys of info and I found that there is no feat_map item. I'm sure the program load info from db_trainval_with_pool.pkl file. Is there any thing wrong with my operation?
  File "/home/x/Desktop/wsl/_HOI/IDN/dataset.py", line 290, in __getitem__
uni_vec.append(f['R'][info['feat_map'][cand_id], :])
KeyError: 'feat_map'
All keys in info:
dict_keys(['obj_gt_classes', 'obj_scores', 'is_gt', 'labels_ro', 'cand_id', 'pair_ids', 'obj_id', 'labels_r', 'height', 'width', 'boxes', 'is_gt_pair', 'pair_iou', 'obj_classes', 'filename', 'labels_sr', 'pool', 'H_mapping'])
Looking forward to your replay!

BTW, when I run eval.py, it told me that:
RuntimeError: exp/IDN_IPT_hico/epoch_30.pth is a zip archive (did you mean to use torch.jit.load()?)
According to web, this error is due to the version of pytorch. However, my env is torch==1.3.1 same to requirements.txt. How can I deal with this situation? Thanks a lot!

Thanks for releasing your wonderful work!
When I run the training commend, I got this error. Then I print all keys of info and I found that there is no feat_map item. I'm sure the program load info from db_trainval_with_pool.pkl file. Is there any thing wrong with my operation?
 File "/home/x/Desktop/wsl/_HOI/IDN/dataset.py", line 290, in __getitem__
uni_vec.append(f['R'][info['feat_map'][cand_id], :])
KeyError: 'feat_map'
All keys in info:
dict_keys(['obj_gt_classes', 'obj_scores', 'is_gt', 'labels_ro', 'cand_id', 'pair_ids', 'obj_id', 'labels_r', 'height', 'width', 'boxes', 'is_gt_pair', 'pair_iou', 'obj_classes', 'filename', 'labels_sr', 'pool', 'H_mapping'])
Looking forward to your replay!

We have fixed it in the latest commit.

BTW, when I run eval.py, it told me that:
RuntimeError: exp/IDN_IPT_hico/epoch_30.pth is a zip archive (did you mean to use torch.jit.load()?)
According to web, this error is due to the version of pytorch. However, my env is torch==1.3.1 same to requirements.txt. How can I deal with this situation? Thanks a lot!

We will update the requirements.txt

Thank you very much for your reply!
When I train AE again, I print loss every batch. And I found that the Loss explode....Here is the information

I didn't change the code....It seems that this problem is caused by semi_hard loss.
Looking forward to your replay. Thank you very much!

The semi-hard loss did result in loss exploding sometimes. Using the probability could help a lot in making the loss more stable with little performance drop (less than 0.1 in our experiments). We have updated the code to the more stable version.

Thank you for your remanding! Now this code can work.
But the loss changes negative. It's this right?

Thank you very much!

This could be fine, though tuning down the loss scale by weighting the semi-hard loss might bring better performance.

Thank you very much for your reply. We are looking forward to your improvement of this project, which is very enlightening!

Thanks for your support! We will keep going to enrich this project.


Make Plot Titles Informative

Have the titles of the plots actually tell the user something about the data being presented. This will be query features, like Country, Year, etc.

The descriptive plot titling has been started, but it would be useful to know: What information do we want to put in the titles? All the query parameters? Some subset of those?

We want to include all the query parameters except those that are otherwise displayed. For instance, country might be displayed as a color on the xy plots, so that shouldn't be in the title.

We might consider creating a "caption" (that's ggplot2 lingo for this) that describes the data rather than putting this in a title.  The title for a plot should really act more like a headline, explaining tersely what the point of the plot is.
Here is an example of a caption used to explain the data source:

I'm not sure whether plotly has a similar notion of caption.  If not, this might need to emulated some other way.

see https://stackoverflow.com/questions/45103559/plotly-adding-a-source-or-caption-to-a-chart

Fixed bug causing parameters with multiple selections to crash showing the plot. Stemmed from the plot title function.


checkout-keystore [nfc]: Use less-fancy Bash for filtering stderr

Thanks to Anders for the suggestion:
https://github.com/zulip/zulip-mobile/pull/5144#issuecomment-985778181
I wasn't sure if /dev/fd/N was available on macOS, but indeed it
seems to be, and this >(…) Bash syntax works just fine there.
(Even in the ancient /bin/bash that Apple ships.)
This sure is simpler to read!  Really not much different from
the usual case of applying a grep to a command's stdout.  More
shell-style, in the spirit of shell pipelines, while the coproc
approach feels lower-level.
I kept the grep command pulled out separate from the main sq
command, as a tiny shell function, in order to have a place to put
the comment explaining what it's there for.
Suggested-by: Anders Kaseorg<EMAIL_ADDRESS>/cc @andersk

LGTM, I tested and got the following in the output:
Wrote decrypted file: /Users/chrisbobbe/dev/zulip-mobile/android/release.keystore

This file will be deleted in 15 minutes.

So all looks good. I'll hold off on merging in case Greg would like Anders to review first.

Merging. Thanks for the reviews!


[refactor] give topic a default value so we don't have to do that many undefined checks

Probably not worth it, makes testing harder and re-constituting facts from disk
patch.txt

Wait, let's bring this back.
I don't like storing default values on the Rule object because it's super mysterious and non-obvious who is setting the default values
The test problem has been fixed by using a real Engine in our tests
I don't think saving stuff to the disk was every a problem.

OK, saving to disk was a problem. Fixable though.

This may lead to weird things down the line where undefined is conflated with the default value. We will never be able to write the default value to disk, unless when we get a new fact, we EXPLICITLY CHECK IF IT IS THE DEFAULT VALUE. IF THE DB FACT IS UNDEFINED AND WE ARE PASSING THE DEFAULT VALUE, WRITE IT TO DB!!! <---todo

A bit of strange stuff happening in Engine now.
If fact has not changed, we are still saving the fact because JUST MAYBE the underlying db has a fact of undefined and we are trying to set it to the default value.
The db will never return undefined if the fact has a default value.
It really shouldn't be the db's job to give back the default value, but I don't want to check for defaults everywhere... Perhaps engine.get can check for defaults and have nobody use the db.get ?

Moving default value logic checking onto Engine instead of FactStore.
Not 100% sure it belongs here (it's a weird static function because it doesn't depend on any of the Engine's state) but we'll roll with it for now.
Commits of interest if we want to revert this change in the future -
1df1594c3bb2feb047a358ba0aa66ab6d3442197 (have Engine handle defaults)
ec89c7c1db91d4276fda69a6f6e651279282fc8c (have FactStore handle defaults)


ng error: Unknown error: SyntaxError: Unexpected token 'export'

Hello,
I installed cli with command:
sudo npm install -g<EMAIL_ADDRESS>which is the last release at this moment.
I tried ng new angularclient
and I had this error:

Unknown error: SyntaxError: Unexpected token 'export'

I tried just ng and had the same error.
I try to discover Angular so this is a big stop for me in discovering Angular ;)
Here is the package info:

> sudo npm info @angular/cli dist-tags
{
latest: '10.1.6',
next: '11.0.0-next.6',
'v6-lts': '6.2.9',
'v8-lts': '8.3.29',
'v7-lts': '7.3.10',
'v9-lts': '9.1.12'

> node -v
v12.19.0

Hi @dumitru-h,
I cannot replicate the error with the steps provided.

Here is my OS info maybe this can help:
I am on Xubuntu:

> lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.5 LTS
Release:	18.04
Codename:	bionic

> uname -a
Linux my_host 4.15.0-101-generic #102-Ubuntu SMP Mon May 11 10:07:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

I uninstalled, re-installed. Nothing helps.

So just to get this right, when executing the ng new angularclient command you are getting Unknown error: SyntaxError: Unexpected token 'export' error?

So just to get this right, when executing the ng new angularclient command you are getting Unknown error: SyntaxError: Unexpected token 'export' error?

Even without arguments the error is the same.

Seems like there is this SO issue
https://stackoverflow.com/questions/64051509/unknown-error-syntaxerror-unexpected-token-export-on-ng-command
Which indicates that this is not an Angular CLI issue, therefore closing this as it's unactionable from our end.

The stackoverflow proposed solution worked for me.


implemented smooth scroll for tips on top of sonata app

implemented smooth scroll for tips on top of sonata app


Multiscale

Add basic support for multiscale.
array -> multiscale helper function
open array from ome-ngff compliant pyramid

related (it was working before):
from funlib.persistence import open_ds
path = "/nrs/cellmap/data/jrc_cos7-1a/jrc_cos7-1a.zarr/recon-1/em/fibsem-uint8/s2"
ds = open_ds(path, 'r')
ds.voxel_size

result: (1, 1, 1)
Is there an easy fix to it
@pattonw @yuriyzubov

our old zarr file (no multiscale) - metadata:
cat .zattrs
{
    "offset": [
        16900,
        17156,
        21164
    ],
    "resolution": [
        2,
        2,
        2
    ]
}

new version of funlib.persistence can't detect the voxel_size from resolution

thank you. i did fix the old data one resolution data. but still the multiscale bug
/nrs/cellmap/data/jrc_cos7-1a/jrc_cos7-1a.zarr/recon-1/em/fibsem-uint8/.zattrs  :
{
    "multiscales": [
        {
            "axes": [
                {
                    "name": "z",
                    "type": "space",
                    "unit": "nanometer"
                },
                {
                    "name": "y",
                    "type": "space",
                    "unit": "nanometer"
                },
                {
                    "name": "x",
                    "type": "space",
                    "unit": "nanometer"
                }
            ],
            "coordinateTransformations": [
                {
                    "scale": [
                        1.0,
                        1.0,
                        1.0
                    ],
                    "type": "scale"
                }
            ],
            "datasets": [
                {
                    "coordinateTransformations": [
                        {
                            "scale": [
                                4.0,
                                4.0,
                                4.0
                            ],
                            "type": "scale"
                        },
                        {
                            "translation": [
                                0.0,
                                0.0,
                                0.0
                            ],
                            "type": "translation"
                        }
                    ],
                    "path": "s0"
                },
                {
                    "coordinateTransformations": [
                        {
                            "scale": [
                                8.0,
                                8.0,
                                8.0
                            ],
                            "type": "scale"
                        },
                        {
                            "translation": [
                                2.0,
                                2.0,
                                2.0
                            ],
                            "type": "translation"
                        }
                    ],
                    "path": "s1"
                },
                {
                    "coordinateTransformations": [
                        {
                            "scale": [
                                16.0,
                                16.0,
                                16.0
                            ],
                            "type": "scale"
                        },
                        {
                            "translation": [
                                6.0,
                                6.0,
                                6.0
                            ],
                            "type": "translation"
                        }
                    ],
                    "path": "s2"
                },
                {
                    "coordinateTransformations": [
                        {
                            "scale": [
                                32.0,
                                32.0,
                                32.0
                            ],
                            "type": "scale"
                        },
                        {
                            "translation": [
                                14.0,
                                14.0,
                                14.0
                            ],
                            "type": "translation"
                        }
                    ],
                    "path": "s3"
                },
                {
                    "coordinateTransformations": [
                        {
                            "scale": [
                                64.0,
                                64.0,
                                64.0
                            ],
                            "type": "scale"
                        },
                        {
                            "translation": [
                                30.0,
                                30.0,
                                30.0
                            ],
                            "type": "translation"
                        }
                    ],
                    "path": "s4"
                },
                {
                    "coordinateTransformations": [
                        {
                            "scale": [
                                128.0,
                                128.0,
                                128.0
                            ],
                            "type": "scale"
                        },
                        {
                            "translation": [
                                62.0,
                                62.0,
                                62.0
                            ],
                            "type": "translation"
                        }
                    ],
                    "path": "s5"
                }
            ],
            "name": "/recon-1/em/fibsem-uint8",
            "version": "0.4"
        }
    ],
    "name": "fibsem-uint16"

For working with OME metadata I would recommend using an ome-ngff specific tool to read and write the metadata. open_ds lets you directly pass in the offset, voxel_size, axis_names, and units if they aren't directly available on the array you are trying to open.
Something like:
offset, voxel_size, axis_names, units = read_ome_metadata("/path/to/pyramid", scale_level=0)
open_ds("path/to/pyramid/0", offset=offset, voxel_size=voxel_size,axis_names=axis_names, units=units)

The OME-NGFF metadata spec is quite extensive so it is probably better to use a library dedicated to it rather than writing a custom implementation in funlib.persistence.
If you have a good library for reading/writing OME-NGFF metadata let me know, I plan on adding a open_ome_ds and prepare_ome_ds at some point

is there anyway to have a strict mode if it is activated raise an error if no voxel_size is found instead of returning default values
https://github.com/funkelab/funlib.persistence/blob/3c0760e48edf1b287c4f75d7d11dc6b775332b2b/funlib/persistence/arrays/metadata.py#L141

Not at the moment but that would be a good feature to add

Hi @pattonw
So initially I modified _read_voxel_size_offset method so it could fetch voxel size and offset from metadata. I had my own issues with the way it was implemented, as I believe that fetching metadata for N5 and Zarr should be separated, but it worked ok.
did you encounter any issues when testing prepare_ds() method, before pushing code to main branch?

If you have a good library for reading/writing OME-NGFF metadata let me know, I plan on adding a open_ome_ds and prepare_ome_ds at some point

I tried to look into ome-zarr-py repo. Perhaps it makes sense to utilize ome_zarr.reader.Reader when creating open_ome_ds?

as output, DaCapo+funlib.show.neuroglancer are not working anymore with all cellmap data


fast version of locateAll() using OpenCV

I'm putting this out there as a basis for discussion. If its acceptable to require OpenCV and numpy as dependencies (in return for faster performance), then I'll test this more and smooth out the remaining wrinkles. But maybe you don't want the extra dependencies.
Upsides:

faster: for me, finding a small image in a 2880 x 1800 pix screenshot takes ~0.95s vs ~4.5s previously
(with grayscale and downsampling by 4 its faster still: ~0.10s)
confidence-based thresholding is possible: I have not played with this much, looks interesting
less code required

Downside:

requires OpenCV (and numpy), not sure if OpenCV is working well with python 3 on all platforms yet

Limitations:

not thoroughly tested yet but looks very promising
takes file names only (not PIL images, which would need to be converted)
only tested on Mac 10.9, 64-bit python 2.7.8, OpenCV 2.4.8

I needed to explicitly import screenshotUtil * to get the new code to be used
(I'm baffled how locate() gets into the pyautogui namespace without doing this!)
credits: https://stackoverflow.com/questions/7670112/finding-a-subimage-inside-a-numpy-image/9253805#9253805

I'll take a look at this. I haven't worked with opencv, but this seems like a good idea. The important thing is that PyAutoGUI's features work with Python 2 and 3. Also, I'd like to not require opencv and numpy for PyAutoGUI, so maybe we could have those import conditionally. I'll try to think of a way to do this that isn't too disruptive. (And I'm open to suggestions.)
Also, the bulk of these changes should be done to the pyscreeze project, which pyautogui uses for the screenshot-related features: https://github.com/asweigart/pyscreeze/

(Message me again if I lose track of this after several days. I've been traveling and juggling different tasks recently.)

moved development & discussion to pyscreeze


Institutions XSD: Add relations between contacts and IIAs

As @kaiqu explained here, we might need relations between <contact>s and IIAs.
In version 0.1.0 of the Institutions API schema, this is dealt with via the <iia-id> sequence, but - if I understood this correctly - this is not enough. We need to able to assign iia-ids for every role of every contact.
@kaiqu, did I understand this correctly?

As @kaiqu explained here, we might need relations between "contact"s and IIAs.
In version 0.1.0 of the Institutions API schema, this is dealt with via the "iia-id" sequence, but - if I understood this correctly - this is not enough. We need to able to assign iia-ids for every role of every contact.
@kaiqu, did I understand this correctly?

First, some data model terminology:

Coordinators are Persons with Roles
Contacts are Coordinators for Mobilities

A Coordinator belongs to an Institution/Org Unit, and can (in the next version) be connected to 0..* IIAs. I think the latter connections belong in the IIAs API.
BTW, I suggest we use "quotes" (or something) instead of XML  for elements, since the latter convention aren't displayed in quoted text.

Contacts are Coordinators for Mobilities

Oops, I have used a different terminology in my XSD. Are these terms defined in WP2's dictionary?
My "contact" element is not necessarily a person. It can be, for example, an office (a phone number, or an email address, shared by a couple of people). Do you think it's a wrong assumption on my part? Do you think that we can require all coordinators to be specific persons?

A Coordinator belongs to an Institution/Org Unit, and can (in the next version) be connected to 0..* IIAs. I think the latter connections belong in the IIAs API.

I would rather assume that coordinators are part of factsheets (and factsheets are served in Institutions API).
In my mind, these two entities are divided quite clearly, according to the following:

Factsheets contain information which is public, and can change in time without the need of signing the IIA again.
IIAs contain information which is not necessarily public, and - if it changes - it requires the agreement to be signed again.

My "contact" element is not necessarily a person.

For example, see here (source), or here (source).

Contacts are Coordinators for Mobilities

Oops, I have used a different terminology in my XSD. Are these terms defined in WP2's dictionary?

No - the task of aligning the model with the dictionary was assigned a lower priority, to be done after the structure is finalized.

My "contact" element is not necessarily a person. It can be, for example, an office (a phone number, or an email address, shared by a couple of people). Do you think it's a wrong assumption on my part? Do you think that we can require all coordinators to be specific persons?

This is a matter of terminology, rather than structure (it was probably not a good idea to delay the above-mentioned aligning with the dictionary, since it's important to know exactly what we are talking about when designing the structure). In the model, there is a sharp delineation between two types of contact information:

For people it's defined in the Coordinator entity
For functions it's defined in Inst/Org Unit attributes

I've never been quite happy with the latter, so now might be the time to change it.
In my mind, the term "coordinator" denotes a person, while "contact" is more general.
I propose the following:

An Inst/Org Unit has Contacts and Coordinators
A Contact is basically a URL/Email/Phone with a Role
Coordinator stays the same (a Person with a Role, independent of IIAs)
The present Contact entity (Coordinator for a Mobility) is renamed to Mobility Coordinator

A Coordinator belongs to an Institution/Org Unit, and can (in the next version) be connected to 0..* IIAs. I think the latter connections belong in the IIAs API.

I would rather assume that coordinators are part of factsheets (and factsheets are served in Institutions API).

The Coordinators themselves, yes. I was referring to their connections to IIAs - i.e. a Coordinator having Role for an IIA (denoted in the coming version by a N:M relationship).

In my mind, these two entities are divided quite clearly, according to the following:
Factsheets contain information which is public, and can change in time without the need of signing the IIA again.
IIAs contain information which is not necessarily public, and - if it changes - it requires the agreement to be signed again.

With that distinction, I guess assigning a new Coordinator to an IIA doesn't necessitate re-signing, so then I agree that the assignment of Coordinators to IIAs belong in the Institutions/Departments APIs.

My "contact" element is not necessarily a person.
For example, see here (source), or here (source).

The Contact term is discussed in my previous message, but I notice that the above examples seem to indicate more Roles than the ones mentioned so far.

(more factsheet examples)

I looked at some of these in the beginning of the modeling process, but it would probably be a good idea to go through some more fact sheets at this point to 1) check that the model hasn't lost any information and 2) complete code sets such as Role...

(...) two types of contact information: For people it's defined in the Coordinator entity

The term "coordinator" seems to fit our current set of roles. But I can imagine that as the list of roles grows, it might become very awkward, at some point. Intuitively, "coordinating something" seems to be a subset of all possible roles (and we can expect for this set to be growing).
BTW - our model image is becoming a bit tangled up. Do we need to model all entities on a single image? Perhaps it would be easier for the readers to split it up, for example, by the API?
Before I tackle your other comments - let's think about minimum requirements again, for a moment. The more I think on this, the more I wonder if we really need to model all these roles. Since EWP allows communication between whole systems, then perhaps it's up to the particular system developer to know who is supposed to do what in which context, and the partner doesn't need to know that. If this is true, then do we need roles in our model at all? Or, perhaps, we need only a small subset?
I would start with the smallest set of features required to meet our use cases. We can always add more features as we go.

Since it's somewhat unclear to me at this point, I have moved <role-id> and other related elements to a separate feature branch. (So that the master branch stays "clean".)

No - the task of aligning the model with the dictionary was assigned a lower priority, to be done after the structure is finalized.

It is a good assumpiton if we talk about technical dictionary prepared by WP3, not terminology prepared by WP2. That should be taken care of in the first place.

I looked at some of these in the beginning of the modeling process, but it would probably be a good idea to go through some more fact sheets at this point

You will find a substantial set gathered once by the partners in the Mobility project:
https://www.usos.edu.pl/Mobility/InfoSheets/

I would start with the smallest set of features required to meet our use cases. We can always add more features as we go.

I agree.

The term "coordinator" seems to fit our current set of roles. But I can imagine that as the list of roles grows, it might become very awkward, at some point. Intuitively, "coordinating something" seems to be a subset of all possible roles (and we can expect for this set to be growing).

Yes.

BTW - our model image is becoming a bit tangled up. Do we need to model all entities on a single image? Perhaps it would be easier for the readers to split it up, for example, by the API?

Splitting up by API is not really possible, as many entities are used in more than one API. I guess it could be split up into some kind of "business areas", associating entities with a "primary" API:
Organization

Institution/Org Unit
Coordinator
HEI Contact Info
Person
Person Contact Info
Contact Type
Learning Opportunity Specification
Learning Opportunity Instance
Academic Term/Year
Result Distribution

IIA

IIA
IIA Partner
Cooperation Condition

Mobility

Mobility
Learning Agreement
LA Component

There are basically three ways to do this (ranging from the easiest to the most work):

Assigning three colors to the entities
Blowing the model up to A3 format
Distributing the entities on 2 pages (the last two should fit one the same page)

I would like to try option 1 first, if we can assume everyone to have access to color printers?

Before I tackle your other comments - let's think about minimum requirements again, for a moment. The more I think on this, the more I wonder if we really need to model all these roles. Since EWP allows communication between whole systems, then perhaps it's up to the particular system developer to know who is supposed to do what in which context, and the partner doesn't need to know that. If this is true, then do we need roles in our model at all? Or, perhaps, we need only a small subset?

I assume contact information is only visual (if it was to be used programmatically in a different way for different Roles, the Roles would definitely be necessary). The only reason, then, for having defined Roles would be to be able to programmatically display contact information in a standard way for those Roles (and possibly to determine which Roles are assigned at a HEI).

I would start with the smallest set of features required to meet our use cases. We can always add more features as we go.

I agree. If Roles are deemed to be outside the smallest set, I'll remove them.

the task of aligning the model with the dictionary was assigned a lower priority, to be done after the structure is finalized.

It is a good assumpiton if we talk about technical dictionary prepared by WP3, not terminology prepared by WP2. That should be taken care of in the first place.

Aha. Ok, I will do that before releasing the next version of the model.

You will find a substantial set gathered once by the partners in the Mobility project:
https://www.usos.edu.pl/Mobility/InfoSheets/
In fact any proposal for the model should first be checked against this set of fact sheets.

There are more than 70 documents here (counting the ones in the subdirectories) - is it possible to identify a key subset of them, for me to check?

I would have to look at them myself ;)
I did but it was a couple of years ago.
Just pick up 10 randomly.

It might be of some use to have a look at businessCardT in:
https://www.usos.edu.pl/Mobility/Documentation2/default.html

It might be of some use to have a look at businessCardT in:
https://www.usos.edu.pl/Mobility/Documentation2/default.html

Hm... Leaving out userDefinedBusinessCardSectionT and userDefinedSectionItemT (a generic name/value structure), the remaining components seem to be modeled by the current version:
organizationBCSection is covered by:

Institution/Org Unit
HEI Contact Info

iroOfficeBCSection is covered by:

Institution/Org Unit
HEI Contact Info
Coordinator
Person
Person Contact Info

So, unless there is need for such a generic name/value structure, the model seems sufficient in this respect.

It is a good assumpiton if we talk about technical dictionary prepared by WP3, not terminology prepared by WP2. That should be taken care of in the first place.

Aha. Ok, I will do that before releasing the next version of the model.

I have produced a version of the WP2 Dictionary (data_dictionary.xslx), where I map from the Field Name to the current model, expressed by two added columns "WP3 - Attribute" and "WP3 - Entity". There are some questions which should be cleared up - should I commit the spreadsheet (possibly to a branch), or would this be considered unnecessary clutter in the repo?

I have produced a version of the WP2 Dictionary (data_dictionary.xslx), where I map from the Field Name to the current model, expressed by two added columns "WP3 - Attribute" and "WP3 - Entity". There are some questions which should be cleared up - should I commit the spreadsheet (possibly to a branch), or would this be considered unnecessary clutter in the repo?

I tried pushing the commented file to a new branch, but the server returns "permission denied" / HTTP 403. Should I have write access to this repo, or is it better to send the commented file to the technical mailing list?
@wrygiel @erasmus-without-paper/wp2

So, unless there is need for such a generic name/value structure, the model seems sufficient in this respect.

In my opinion there is a need for such generic section since it gives the possibility to send any information which might seem relevent by sending HEI. Our old Mobility client and server is in operation, you can see some real examples at:
http://mobility.usos.edu.pl/mobility-server-transport/
These are business cards prepared by partner institutions.

So, unless there is need for such a generic name/value structure, the model seems sufficient in this respect.

In my opinion there is a need for such generic section since it gives the possibility to send any information which might seem relevent by sending HEI. Our old Mobility client and server is in operation, you can see some real examples at:
http://mobility.usos.edu.pl/mobility-server-transport/
These are business cards prepared by partner institutions.

I think this is solved by the Info attribute in Inst/Org Unit in the latest version of the model. It represents 0..* Info elements with Headers for display/grouping (as described in my message to the technical list yesterday). I propose to replace the predefined Role IDs with this.

Is this already reflected in the XSD or XML example?

Are you sure that all posted Business Cards (Fact Sheets) from the Mobility servrr can be easily described by the model? Could we see the XML examples showing this? That would be real proof of concept.

What you see at
http://mobility.usos.edu.pl/mobility-server-transport/
is posted automatically by the server after API invocation of the client. XML contains header (title) section which helps to structure information in a way readable for humans. We might even post such Facts Sheets of EWP partners at the registry web page (if we decide to have one and if there comes an attribute 'public' with the invocation).

Are you sure that all posted Business Cards (Fact Sheets) from the Mobility servrr can be easily described by the model? Could we see the XML examples showing this? That would be real proof of concept.

I am working on it.

What you see at
http://mobility.usos.edu.pl/mobility-server-transport/
is posted automatically by the server after API invocation of the client. XML contains header (title) section which helps to structure information in a way readable for humans.

This fits the Info structure perfectly (header + content repeated), which was the result of examining quite a few fact sheets (including the one from UW). It also fits pretty well with what @wrygiel created in a branch (except he called the structure "embedded-mobility-factsheet" and made it embeddable/recursive).
Also, since there doesn't seem to be any need for programmatic processing of predefined Role IDs, I propose to replace them with headers. That way, we get the header/content structure for all kinds of repeating information connected to Inst/Org Unit. (Coming in the next model version)

I tried pushing the commented file to a new branch, but the server returns "permission denied" / HTTP 403.

In general, only WP2 is allowed to change things in ewp-wp2-* repositories, because they are responsible for their contents. If you would like to suggest changes, the "GitHub way" of doing this is to create a fork (your local copy of the repository), and then make a pull request. Then, you assign people to this pull request to review your comments.

BTW, @kaiqu, I see we are working on one API in parallel. I hope it's not too confusing for you :) I also have some local changes for Organizational Units API, but I'm not sure if will be able to push them before I leave for my holidays.

In general, only WP2 is allowed to change things in ewp-wp2-* repositories, because they are responsible for their contents. If you would like to suggest changes, the "GitHub way" of doing this is to create a fork (your local copy of the repository), and then make a pull request. Then, you assign people to this pull request to review your comments.

Sorry about the GitHub newbie questions, but I have created the fork and pull request, but I don't see how to assign people to it?

BTW, @kaiqu, I see we are working on one API in parallel. I hope it's not too confusing for you :) I also have some local changes for Organizational Units API, but I'm not sure if will be able to push them before I leave for my holidays.

No problem :-)
I'm waiting with the Org Units API until the Institutions API is finished, since they will be very similar.

I have created the fork and pull request, but I don't see how to assign people to it

It seems that you'd need to have write-permissions to assign people directly. So, lets use @mention tags instead.

As @kaiqu explained here, we might need relations between <contact>s and IIAs.

In the latest IIAs API draft (version 0.1.0), we have dealt with this problem by allowing <contact> elements in various places of the IIA element tree. Each such contact can have a <role-description>. Contacts with very specific roles have separate elements to distinguish them. We will see if this proves enough for our purposes (new, more specific issues might arise in the future).
BTW, this also means that some data that we initially planned to put in the Institutions API, will now be placed in the IIAs API (as explained here).


HDFS-16546. Fix UT TestOfflineImageViewer#testReverseXmlWithoutSnapshotDiffSection to branch branch-3.2

The test fails due to incorrect layoutVersion.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
11m 43s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ branch-3.2 Compile Tests _

+1 :green_heart:
mvninstall
33m  5s

branch-3.2 passed

+1 :green_heart:
compile
1m 11s

branch-3.2 passed

+1 :green_heart:
checkstyle
1m  1s

branch-3.2 passed

+1 :green_heart:
mvnsite
1m 22s

branch-3.2 passed

+1 :green_heart:
javadoc
1m 14s

branch-3.2 passed

+1 :green_heart:
spotbugs
3m 29s

branch-3.2 passed

+1 :green_heart:
shadedclient
17m 52s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m 12s

the patch passed

+1 :green_heart:
compile
1m  3s

the patch passed

+1 :green_heart:
javac
1m  3s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 46s

the patch passed

+1 :green_heart:
mvnsite
1m  9s

the patch passed

+1 :green_heart:
javadoc
0m 53s

the patch passed

+1 :green_heart:
spotbugs
3m  8s

the patch passed

+1 :green_heart:
shadedclient
18m 39s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
239m 47s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
1m 20s

The patch does not generate ASF License warnings.

336m 12s

Reason
Tests

Failed junit tests
hadoop.hdfs.server.namenode.snapshot.TestRenameWithSnapshots

hadoop.hdfs.server.namenode.TestNameNodeMXBean

hadoop.hdfs.server.namenode.TestFsck

hadoop.hdfs.server.blockmanagement.TestBlockManager

hadoop.hdfs.server.namenode.TestNamenodeCapacityReport

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4187/2/artifact/out/Dockerfile

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell

uname
Linux f07b812b75c5 4.15.0-166-generic #174-Ubuntu SMP Wed Dec 8 19:07:44 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
branch-3.2 / 610c97711c8110a25e740158297efc9d7929e75d

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~18.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4187/2/testReport/

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

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4187/2/console

versions
git=2.17.1 maven=3.6.0 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.


API documentation section essentially empty

Visit https://pyproject-fmt.readthedocs.io/en/latest/#module-pyproject_fmt, see:

This section should either be removed or changed to explain an API.

I think let's remove it, PR welcome.

Done via https://github.com/tox-dev/pyproject-fmt/releases/tag/2.0.3

Does this mean that developers using the API should use https://github.com/tox-dev/pyproject-fmt-rust instead (I understand that one is currently undocumented but supposedly that is a WIP)?

What's your use case?

For now, I would like to be able to run pyproject-fmt (with its default configurations) on a str variable.
That is used in ini2toml.
Previously I was running format_pyproject(Config(Path("pyproject.toml"), text))

The rust package has no defaults. Today, your best chance would be to just do a sub process call. We could expose an endpoint for this functionality though. PR welcome 🤗

OK, I think in this case that might be a regression on https://github.com/tox-dev/pyproject-fmt/issues/3?

We changed the interface, so the new API would also need to look differently.

Thanks @gaborbernat, I will give another go at reimplementing the feature with a new look.

So if I understand this correctly you are not really interested in the fancy diff or check functionality. You just want to format the file after generating it with no output, Yes?

Fixed via https://github.com/tox-dev/pyproject-fmt/releases/tag/2.1.0


Controller errors out when TLSRoute CRD is not installed

We installed the latest version (v1.0.6) onto our cluster without first installing the TLSRoute CRD since we dont need it. The controller started erroring out with the following error:
 {"level":"error","ts":"2024-07-30T13:29:26.831Z","logger":"setup","caller":"workspace/main.go:249","msg":"failed to wait for tlsroute caches to sync: timed out waiting for cache to be synced for Kind *v1alpha2.TLSRouteproblem running manager"}

This was resolved by applying the TLSRoute CRD...

The TLSRoute CRD is included in the v1.0.6 controller helm chart. Without it, the v1.0.6 controller is not fully functional and expect not to work.  Any specific reasons why you prefer not to install the TLSRoute in your cluster? just you don't need the TLSRoute and TLS pass-through functionality ?
Maybe we can do that improvement in the controller code: once that controller detect the current cluster don't have TLSRoute CRD, it automatically disable the TLSRoute(TLS pass-through) functionality and the controller start normally. What do you think about this approach?

I think that approach can def work but the approach mentioned in https://github.com/aws/aws-application-networking-k8s/issues/660 could also work.

Any specific reasons why you prefer not to install the TLSRoute in your cluster? just you don't need the TLSRoute and TLS pass-through functionality ?

We are indeed not using this functionality and would like to not expose it in our platform cluster

ok, I  will update the public doc and v1.0.6 release note to mention user need to install TLSRoute CRD if they hope to use v1.0.6 controller


fix: make web platform types compatible with native types

Summary
This PR fixes #1920
When react-native-svg is used on a web project where typescript has been configured to resolve .web.ts file exentions before .ts, it causes type errors.
This is because the types in ReactNativeSVG.web.ts don't match the types in ReactNativeSVG.ts
This PR adds the correct types for all exported components on the web platform inside ReactNativeSVG.web.ts. Those changes are:

Added missing prop types for all components
Made style, gradientTransform, and patternTransform optional in BaseProps.
Made styleProp argument of resolve() undefined-able, to support style being an optional prop (this also seems to follow the logic in the body of the function, which has a  check for a truthy styleProp)

These changes only impact types - no functionality has been changed.
Test Plan
I'm not sure there's a clear/easy way to add tests for this update without creating an entirely new test/demo project with its own tsconfig, so I haven't added any. I'm happy to add tests if someone can offer a suggestion for a simpler way to accomplish it.
I can at least confirm that when I tested these changes in my own project, it resolved the TSC errors I was seeing; but since it's a private repo, I can't share it. :(
What's required for testing (prerequisites)?
A typescript project with compilerOptions.moduleSuffixes set to [".web", ""] in its tsconfig.json that uses react-native-svg
What are the steps to reproduce (after prerequisites)?
Run tsc --noEmit in that project.
Compatibility

OS
Implemented

iOS
N/A

Android
N/A

Web
✅

Checklist

[ ] I have tested this on a device and a simulator
[ ] I added documentation in README.md
[X] I updated the typed files (typescript)
[ ] I added a test for the API in the __tests__ folder

@WoLewicki here's a repository with a minimal reproduction of the bug in a next.js app:
https://github.com/nderscore/rn-svg-web-module-suffix-repro


Outdated code

When I installed it in Atom.io, I got the following alerts from Depreciation Cop:
atom.workspaceView is no longer available. In most cases you will not need the view. See the Workspace docs for alternatives: https://atom.io/docs/api/latest/Workspace. If you do need the view, please use atom.views.getView(atom.workspace), which returns an HTMLElement.

Called 1 timeCreate Issue on script repo

Atom.Object.defineProperty.get - C:\Users\Vector\AppData\Local\atom\app-0.182.0\resources\app\src\atom.js:54:11
ScriptOptionsView.initialize - C:\Users\Vector\.atom\packages\script\lib\script-options-view.coffee:51:9
-----
atom.workspaceView is no longer available. In most cases you will not need the view. See the Workspace docs for alternatives: https://atom.io/docs/api/latest/Workspace. If you do need the view, please use atom.views.getView(atom.workspace), which returns an HTMLElement.

Called 1 timeCreate Issue on script repo

Atom.Object.defineProperty.get - C:\Users\Vector\AppData\Local\atom\app-0.182.0\resources\app\src\atom.js:54:11
Object.activate - C:\Users\Vector\.atom\packages\script\lib\script.coffee:30:9

See #407 which addresses these deprecations.


Unable to download the model

Thank you for your sharing. The model download link in Checkpoint cannot be opened. Could you please provide a new download link? Thank you!

The server is down for maintenance, I will update you here once we get it back running again. Sorry for the inconvenience.

The server is down for maintenance, I will update you here once we get it back running again. Sorry for the inconvenience.

Thank you for your reply. Best wish!

Thank you for your reply. Best wish!

Hi, I am still looking forward to accessing the server since we want to make a fair comparison with the proposed method.  I wonder if there is another way to get the data and code, such as email or google drive and so on. I really appreciate any help you can provide.

We have updates the new links to the model in the readme. Sorry for the delay


fix: Prevent lots of 'circular buffer empty' errors in MM

Trying to read from an empty circular buffer causes lots of error messages in MM error log. Prevent them.

this was fine i think! why close?  cause of the test fails?

Semantic check of the commit message failed, wanted to write it again with new commit message. Not necessary?
I have no idea about the other problem on macos.

yeah, not necessary :)  just a silly little thing that I impose here,  by changing the title of the PR (as I did above) it will be fine.

I have no idea about the other problem on macos.

i think these are unrelated, and likely just due to some Qt issues when running on github actions that occasionally pop up.

I just reopened this, so we should be good here.  thanks!!


problems when importing

Greetings friends.
I am executing a project in colab, but when importing I get the following error:
ImportError: cannot import name 'DiversityScore' from 'featuretools.primitives' (/usr/local/lib/python3.9/dist-packages/featuretools/primitives/__init__.py)
I'm new to using the library, I really don't know why I have this error, I would like someone to explain to me how I can solve it. Thank you

@JoelUser Can you make sure nlp_primitives is installed?
python -m pip install nlp_primitives

I get this same issue, it doesn't resolve when I run: !pip install nlp_primitives
ImportError: cannot import name 'DiversityScore' from 'featuretools.primitives', additionally it can't import PolarityScore
This is in Ubuntu, python 3.8.10.

@JoelUser Can you make sure nlp_primitives is installed? In Colab you can run the following:
!pip install nlp_primitives

Not working in kaggle


Support distributed tracing

I added a tiny wrapper around this library to participate in distributed tracing, works like a charm with nodejs services (communicating with swift services through rabbitmq.)
Ideally, this can come out of the box. We'd either need some sort of config for it or maybe a middleware system?
Here is what I use:
struct AMQPHeaderPropagation: Extractor, Injector {
    typealias Carrier = Table?

    func extract(key: String, from carrier: Carrier) -> String? { carrier?[key]?.asString }

    func inject(_ value: String, forKey key: String, into carrier: inout Carrier) {
        carrier = carrier ?? Table()
        carrier![key] = .longString(value)
    }
}

private extension Field {
    var asString: String? {
        switch self {
        case let .longString(s): return s
        // NOTE: maybe support more data types
        default: return nil
        }
    }
}

extension ServiceContext {
    var asAqmpHeaders: Table? {
        var headers: Table?
        InstrumentationSystem.instrument.inject(self, into: &headers, using: AMQPHeaderPropagation())
        return headers
    }
}

extension AMQPResponse.Channel.Message.Delivery {
    var serviceContext: ServiceContext {
        var context = ServiceContext.topLevel
        InstrumentationSystem.instrument.extract(properties.headers, into: &context, using: AMQPHeaderPropagation())
        return context
    }
}

Btw: When implementing it I stumbled over this spec stating that the traceparent must be some binary thing.
All I can say is that I used strings and it works just fine with the opentelemetry package for amqplib. So that might be a bit sticky situation to consider.

I would like to second this suggestion. Having distributed tracing integrated would be very nice.
@sliemeobn I would be grateful for at few pointers wrt how to integrate your code above with Swift tracing/Otel.  I am new to both swift and distributed tracing but have a working example with http from a swift client (using AsyncHTTPClient with retrofitted distributed tracing built from https://github.com/bok-/devworld24-tracing-demo.git) to a Hummingbird server (which supports distributed tracing out of the box). Traces sent to Tempo and visualized with Grafana.

@tweidema it sounds like you have it all setup then, I am not quite sure for which part are you looking for pointers.
I guess the only piece missing are the actual spans, I use the following for now (not sure how otel spec-compliant it is though):
extension AMQPChannel {
    func publish(_ buffer: ByteBuffer, to exchange: String, with routingKey: String) async throws {
        try await withSpan("\(exchange) > \(routingKey) publish", ofKind: .producer) { span in
            span.attributes = [
                "messaging.system": "rabbitmq",
                "messaging.destination": .string(exchange),
                "messaging.rabbitmq.routing_key": .string(routingKey),
            ]

            try await basicPublish(
                from: buffer, exchange: exchange, routingKey: routingKey,
                properties: .init(
                    headers: ServiceContext.current?.asAqmpHeaders,
                    deliveryMode: .deliveryModePersistent,
                    expiration: "\(SharelogBrokerDefaults.DEFAULT_ACKNOWLEDGE_EXPIRATION)",
                    type: SharelogBrokerDefaults.MESSAGE_TYPE_PUBSUB
                )
            )
        }
    }

extension BrokerMessageReponder { // <- my type that handles messages
    @discardableResult
    func handleDelivery(_ delivery: AMQPResponse.Channel.Message.Delivery, from channel: AMQPChannel, logger: Logger) async -> HandleDeliveryResult {
        await withSpan("\(delivery.exchange) \(delivery.routingKey) process", context: delivery.serviceContext, ofKind: .consumer) { span in
            span.attributes = [
                "messaging.system": "rabbitmq",
                "messaging.destination": .string(delivery.exchange),
                "messaging.rabbitmq.routing_key": .string(delivery.routingKey),
            ]
            span.attributes["messaging.conversation_id"] = delivery.properties.correlationID

            // ... process message ...
        }
    }
}

@sliemeobn Thank you very much. That helped me get the span-headers passed back and forth. Still missing a piece reg. how to get the span-context on the receiving side set from those headers. So I get two distinct traces - one from the client and one from the server - they are not being seen as one trace.
I can guess it has something to do with the extension you have on AMQPResponse.Channel.Message.Delivery, just can't figure out how to plug that in.

in the snippet I posted above you see where the service context stored in the headers on publish here
headers: ServiceContext.current?.asAqmpHeaders,

and on the receiving side, the span is initialized with the context extracted from the message here
await withSpan("\(delivery.exchange) \(delivery.routingKey) process", context: delivery.serviceContext, ofKind: .consumer) { span in

this should forward the traceId as part of the serviceContext

@sliemeobn Finally got around to looking at this again, and that was the piece I was missing. Have it working now! Thanks so much for your help.


Location API for improved location search

Description
Improve location API to pull from appropriate source once a suggestion is clicked. Return a location and information associated with it using output from query suggestion table #136 when appropriate, and to pull from GCC geocoding location API when appropriate.
Acceptance Criteria

[x] traffic signal and pedestrian crossover location information can be pulled up using this API
[x] API works with the GCC geocoding location service

Closing this - the work in #392 and #393 helps address the integration part, and we'll open more specific tasks to get specific data sources added to location search.


"Fun" Quirks

Hello,
Some "fun" stuff I noticed running your mod client-side:

The TPS significantly drops while in the inventory/crafting window compared to playing without the mod (10.8 at the lowest vs. 20... the lag fest is insane)
In Survival mode, pre-existing stacks of items before the mod was added will either refuse to stack together or the mod will delete the pre-existing stacks entirely; it did work once like a randomized chance.
While gathering materials in Survival mode, items will only stack to 64 and can't be combined to stack past that default value.
In Creative mode, if I grab a max stack of an item (i.e., saplings) and then open a chest, all the max stack of items I grabbed from the creative menu disappears from my Hotbar
If I grab a max stack of items and put it in the Hotbar and the survival inventory, switch to Survival mode and open a chest, both stacks I grabbed from Creative disappear.

Thanks for your report!
However, I wasn't able to recreate all of the issues you found in the latest beta2 build for 1.20. Try it here to see if any of your issues are resolved.

The issue with items taken from creative inventory should be fixed with this mixin, in fact this is copied from Stacc.
I think there is a conflict with some other mods. Please attach your launcher log here.

This is getting weird. Here's my try with Item Scroller mod:
https://github.com/NotAHero04/inventory-mod/assets/84689840/bc3138d8-0876-4f8c-aa13-0a92d19c80ca
It does seem to work fine... While there's some issues about the holding stack getting de-synchronized when transferring to the chest, that's about it.
I will update to you if something wrong happens.

Happy New Year, it's me again.
I just tried your set of mods, though on MC 1.20.1, and I can confirm that these things work on my side.

Newly gathered items still stack normally above 64. I can even merge like stacks and nothing breaks.
Grabbing items from Creative and then putting it in a container (I tested with a barrel) works fine.
Item Scroller mod also works (like above).

However, I was able to fix one bug while testing, which is the log spam. It was caused by my mod trying to parse empty strings from EMI.

Happy New Year, it's me again.
I just tried your set of mods, though on MC 1.20.1, and I can confirm that these things work on my side.

Newly gathered items still stack normally above 64. I can even merge like stacks and nothing breaks.
Grabbing items from Creative and then putting it in a container (I tested with a barrel) works fine.
Item Scroller mod also works (like above).

However, I was able to fix one bug while testing, which is the log spam. It was caused by my mod trying to parse empty strings from EMI.

After many desperate attempts (and some sleepless hours) for a successful recreation of your issues, I still fail badly (as always).
This issues will temporarily be closed; however it's already pinned, so I can get back to it when I find something.

Hi,
I have addressed some of my oversights in this build. Please check if any of your issues has been resolved. Thanks.


Update Message.php (optional param)

Quick fix, because we needed to update or calls to mergeFromJsonArray  method with a second parameter.

@googlebot I signed it!


Remove legacy classes row and panel that conflict with bootstrap CSS

This is important for https://github.com/openreview/openreview-web/pull/63, however it could be deployed before the migration is complete as it does not contain any breaking changes.

Should we migrate current webfields when we switch to openreview-web?

Well, the existing recruitment webfields will not be viewed again, so we don't need to migrate those, but it would be nice to migrate some of the active PC console webfields. The only downside to not migrating them is that the table won't quite fill the whole width of the page, it will have some extra padding on the sides. So I'd say it's not totally necessary.

It looks good to me, I prefer to merge this before sending invitations to ICLR reviewers. waiting fro @mohituniyal review.


Add Juli Cheng to Contributors list

Hey @julicheng
Thank you for your contribution, and congrats on the PR!


5 parser bug

Improves dtype formatting
Improves logging
Improved error handling

Closes #5

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
Attention: Patch coverage is 94.11765% with 1 line in your changes missing coverage. Please review.

Project coverage is 91.20%. Comparing base (27d3606) to head (e78ba3d).

Files with missing lines
Patch %
Lines

src/imf_reader/weo/reader.py
90.90%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main       #6      +/-   ##
==========================================
+ Coverage   91.01%   91.20%   +0.19%
==========================================
  Files           6        6
  Lines         178      182       +4
==========================================
+ Hits          162      166       +4
  Misses         16       16

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

Thanks @lpicci96 my only question would be about setting types vs doing something like on the importers package + pyarrow. That way we let that engine figure out the right data types, instead of hardcoding. What do you think?

@lpicci96 we should incorporate into bblocks