Update scroll-behavior for recent Chrome

Smooth scrolling has been enabled for everyone in Chrome 61, though there was a bug that prevented it from working properly in some cases (see bug here)
I'd update the data myself, but I have no idea what "pinch viewport" in note 1 means (Partial support refers to support everything except of Element.scrollIntoView() and not together with pinch viewport.)
Since this works in Chrome 61, it should also work in Opera 48 with the same caveats.

Same as #3725

Since #3725 is closed, https://caniuse.com/css-scroll-behavior seems up to date and the bug in note 1 appears to be still open, I believe this issue can be closed, right? :)


Calc needs more work with functions referencing object members

Consider this:
def u = {"universal"}
def v = { { universal: true } }
v().u()
Error: Cannot call undefined function u at line 1.

So, I don't think my example ("v().u()") should even work, but "v()[u()]" does indeed work (as it should), so I think this issue is moot.

Reopening b/c v().universal = 127 looks like it works, but v() -> { universal: true } still shows, so the assignment did nothing, but neither did it throw an error (like it should).

Actually, there's still no bug here.  Because the result of v() as it is written is a new object each time.  If, instead, v() returns a reference to an existing (global) object, then the code works fine.
w = {universal: true} -> { universal: true }
Defining function u = {"universal"}
Defining function v = {w}
v().`$u` -> true
v().`$u` = 127 -> 127
v() -> { universal: 127 }


#34516 Option enablement fix; close idle connections with embedded drivers

This PR fixes two issues mentioned in the ticket.

Verified


Add Evernote

Evernote is popular note taking application
They have a deb available from their website.
https://cdn1.evernote.com/boron/linux/builds/Evernote-Beta-10.35.3-linux-ddl-beta-3355-f684e12257.deb

Sorry, we are only accepting software that provides a reliable way to dynamically determine the current published version. Please see:

Add guidelines for what packages are acceptable for inclusion


Unexpectedly poor performance

I came here from Coherence as I am a novice in Elixir, new to Phoenix, and I was looking for a more-or-less prebuilt authentication solution for my app -- preferably one that would essentially behave like Devise in Rails. My test app has nothing configured on it except for Postgres and is running in a Vagrant VM.
The homepage of my app is blank and renders in about 0.2 milliseconds. In addition, previous authentication solutions I attempted to roll into my app (admittedly badly, using Guardian) only performed marginally worse in this respect (about 0.8 milliseconds to request /sessions/new and /registrations/new).
However, after adding pow as per the README directions, and setting up the user model with the extensions PowResetPassword, PowEmailConfirmation, and PowPersistentSession, I found that the time needed to render /session/new had ballooned to a quite comparatively hefty 25ms in my VM, even while running in production mode. For the record, even Devise with all plugins enabled does better than this with /sessions/new clocking in at around 8ms.
I tried profiling my app with fprof and did not find anything useful. I tried using the Mnesia cache instead of the ETS cache, which did not make a difference. I profiled the server using tcpdump and confirmed that it was not communicating with the database during the request. I also tried deleting all the view code for the pages to see if there was something in the view code that was causing the poor performance there, and that did not make a difference (as expected).
What I did find is that with this configuration,
config :myapp, :pow,
  # ...
  extensions: [PowResetPassword, PowEmailConfirmation, PowPersistentSession],
  controller_callbacks: Pow.Extension.Phoenix.ControllerCallbacks,
  # ...

the controller_callbacks used have a substantial impact on the render time.  However, this is still unexpectedly slow, and obviously this breaks those extensions.
What can I do to bring this on par with the performance of a hand-rolled authentication system?

Interesting. I haven't looked at all at performance so there must definitely be room for improvement. I'm pretty sure there isn't anything you can do to improve performance outside digging into Pow and refactoring whatever is slowing down the response.
I'm swamped atm, but will look at this as soon as I've some time available. Please do post any more details if you're going to dig further into it.

This method here seems to be using metaprogramming to generate a list of matching extension modules on the fly, every request, instead of caching them somehow.
Doing this instead
  defp controller_callbacks_modules(config) do
    [PowEmailConfirmation.Phoenix.ControllerCallbacks,
     PowPersistentSession.Phoenix.ControllerCallbacks]

    #Extension.Config.discover_modules(config, ["Phoenix", "ControllerCallbacks"])
  end

seems to have the same effect on performance as removing the controller_callbacks line from the config, but does not seem to break anything.

I did some light tests to verify myself and it definitely shouldn't be as slow as you experience it. The default Phoenix index controller should range around half of what the Pow session controller is. Do you have a sample repo that I can try out, or can you clarify how you test this?
Standard Phoenix setup with Pow on my machine built with distillery, with first load and two subsequent loads:
# Default phoenix index page
16:10:46.386 request_id=FZnGLdU7vPjffz8AAAGG [info] GET /
16:10:46.389 request_id=FZnGLdU7vPjffz8AAAGG [info] Sent 200 in 2ms
16:10:47.372 request_id=FZnGLg_5A_DJQrEAAAGm [info] GET /
16:10:47.372 request_id=FZnGLg_5A_DJQrEAAAGm [info] Sent 200 in 339µs
16:10:49.701 request_id=FZnGLprLnsAYqAoAAAHG [info] GET /
16:10:49.701 request_id=FZnGLprLnsAYqAoAAAHG [info] Sent 200 in 260µs

# Session controller
16:10:13.539 request_id=FZnGJi9FeODffz8AAAEB [info] Sent 200 in 2ms
16:10:14.741 request_id=FZnGJncRO6DJQrEAAAEh [info] GET /session/new
16:10:14.742 request_id=FZnGJncRO6DJQrEAAAEh [info] Sent 200 in 571µs
16:10:24.340 request_id=FZnGKLM0q7CwZyYAAAAI [info] GET /session/new
16:10:24.341 request_id=FZnGKLM0q7CwZyYAAAAI [info] Sent 200 in 516µs

I tried with both controller callbacks on and off and there was virtually no difference.

I have some custom validations in my User changeset.
  def changeset(user_or_changeset, attrs) do
    user_or_changeset
    #|> pow_changeset(attrs)
    #|> pow_extension_changeset(attrs)
    |> cast(attrs, [:name])
    #|> validate_required([:name])
    #|> validate_length(:name, max: 50)
    #|> unique_constraint(:name)
    #|> unique_constraint(:email)
  end

Doing this reduced the average time down to around 1ms.

I suspect it has to do with Pow.Extension.Config.discover_modules/2: https://github.com/danschultzer/pow/blob/b302607a7a8748bc86f16a6cd94d364a23f9aec9/lib/pow/extension/config.ex#L21-L27
If the app is being ran with mix I'm pretty sure Code.ensure_compiled? will be much slower since it halts until the module is loaded and compiled. Mix does a some things to ensure that modules can be dynamically reloaded.

Doing this reduced the average time down to around 1ms. (I don't see why validations are being checked on a model when there is no model)

Yeah, the changeset method always runs when rendering the :new action. This is also the default in Phoenix templates. A changeset is needed for the form.

  def changeset(user_or_changeset, attrs) do
    user_or_changeset
    |> pow_changeset(attrs)
    |> pow_extension_changeset(attrs)
    |> cast(attrs, [:name])
    #|> validate_required([:name])
    #|> validate_length(:name, max: 50)
    #|> unique_constraint(:name)
    #|> unique_constraint(:email)
  end

Of this, some crude benchmarking shows that most of the time is spent in pow_extension_changeset, and the second most time is spent in pow_changeset. These methods are complicated and I have not been having much luck prying into them.

Try change the Pow.Extension.Config.discover_modules/2 method to this:
  def discover_modules(config, module_list) do
    config
    |> extensions()
    |> Enum.map(&Module.concat([&1] ++ module_list))
    |> Enum.filter(fn module ->
      case :code.is_loaded(module) do
        false -> false
        _any -> true
      end
    end)
  end

After I did that I get near identical response time as when modules are not loaded.
Do you run the app with mix? You should see pretty much no slowdown if you make a release build of your app with distillery. I think running dynamically with mix will always be slower than compiling a release.

Thanks, that seems to have fixed it.
Yes, I am running the app with mix right now, as I have not yet deployed it.

Ok, so you shouldn't see any significant slow down with a release. It should definitely be much faster than devise, and more or less the same speed as guardian.
You should be able to test this by making a release and run it locally. The reason it's so slow is the extension module lookup and running it with mix. I believe that modules can be loaded dynamically loaded in mix so that's why it's so slow on each request since it waits for the module to be (re)loaded. That does not happen with the release version.
The Code.ensure_loaded/1 is the better way (albeit slower) to ensure the modules are ready for use, so I'm not sure if there's any way to improve response time when running the app with mix.

After doing a distillery release I can confirm that both methods produce equivalently-performing code and the performance is more or less optimal.
00:39:28.312 [info] Running MyAppWeb.Endpoint with cowboy 2.6.3 at <IP_ADDRESS>:4000 (http)
00:39:28.315 [info] Access MyAppWeb.Endpoint at http://localhost:4000
00:36:44.898 [info] Access KirinWeb.Endpoint at http://localhost:4000
00:36:49.112 request_id=FZnK39-yoR8_bCkAAADx [info] GET /registration/new
00:36:49.115 request_id=FZnK39-yoR8_bCkAAADx [info] Sent 200 in 3ms
00:36:50.255 request_id=FZnK4CPTqpQ1CWgAAAEB [info] GET /registration/new
00:36:50.256 request_id=FZnK4CPTqpQ1CWgAAAEB [info] Sent 200 in 635µs
00:36:53.413 request_id=FZnK4OAKaNvPLKIAAAAC [info] GET /registration/new
00:36:53.414 request_id=FZnK4OAKaNvPLKIAAAAC [info] Sent 200 in 992µs

After doing a distillery release I can confirm that both methods produce equivalently-performing code and the performance is more or less optimal.
00:39:28.312 [info] Running MyAppWeb.Endpoint with cowboy 2.6.3 at <IP_ADDRESS>:4000 (http)
00:39:28.315 [info] Access MyAppWeb.Endpoint at http://localhost:4000
00:36:49.112 request_id=FZnK39-yoR8_bCkAAADx [info] GET /registration/new
00:36:49.115 request_id=FZnK39-yoR8_bCkAAADx [info] Sent 200 in 3ms
00:36:50.255 request_id=FZnK4CPTqpQ1CWgAAAEB [info] GET /registration/new
00:36:50.256 request_id=FZnK4CPTqpQ1CWgAAAEB [info] Sent 200 in 635µs
00:36:53.413 request_id=FZnK4OAKaNvPLKIAAAAC [info] GET /registration/new
00:36:53.414 request_id=FZnK4OAKaNvPLKIAAAAC [info] Sent 200 in 992µs

👍 I'm pretty sure there's still some performance improvements that can be done but doubt it would cut more than 0.1-0.2 ms of the response time 😄


Add ADR proposal and a skeleton for architecture docs.

Describe the behavior changes introduced in this PR
Adds the ADR proposal document.
Also adds the smallest README for the architecture docs directory.
This was separated from #753 to keep it small and not depend on the committime changes.
Let's talk about the ADR format, but let's not bikeshed too much, especially about where the architecture docs should live.
Linked Issues
addresses parts 2 and 3 of #727

can't we merge ADRs.md and README.md into a single file?

I would put this in our read the docs documentation. They are already in markdown format, and would be easier to us to review them (with the read the docs preview CI job) and track them (I am not familiar with a project having more than the README and the documentation website).

Looks like we have #876, excellent! Once I have the time, I'll remove the ADR parts and just leave the arch docs for this PR.

Yes, this is still valid, just moved some parts of your descriptions into the developers docs and introduced tool to manage the ADRs in a consistent way easily (with template generated by the tool).

Superceded by #1042


Add autocomplete toggle

Adds an option to the DSL for enabling/disabling the simple autocomplete feature in CommandFinder:
autocomplete_commands false

Full doc:

If you're curious, the desire to have this feature comes from https://github.com/sportngin/octopolo/issues/34
We have a deployable command in one of our CLI gems and deploy in another - and people (more than once) have accidentally marked their feature branches for merging when they intended a deployment :)
Other small tidbits:

Revamped CommandFinder and GLIOptionParser to use options hashes in their method signatures. This allows for much greater flexibility in doing something such as this autocomplete feature without constantly just pushing more and more parameters into the method signatures.
Full tests for CommandFinder written before I refactored the class a bit. Things are reordered and pushed around but the functionality (beyond the toggle) should be the same.
Lastly, I also added (in the spirit of Git-Like-Interface) the same warning you'd see in Git if a command is autocompleted. However, I'm unsure how you interface with the CLI output so the warning does get printed in tests. Any idea/opinion on how I should handle that?

The tests all pass, but do let me know if you see anything fishy that I missed. Thanks Dave!

Ah, yeah good idea on this feature.  Briefly skimming, this looks good, but I'll give it a more thorough look this weekend.

Thanks for this.  I wrapped the warning puts  in an if ENV["GLI_DEBUG"] block, since the shortened forms aren't a user mistake.

Sweet :+1: Thanks Dave!

This is up as 2.13.0 and the online RDoc should be updated.  Thanks again!


Ruby group capstone: set up your Kanban board

Link to our Project
We are a team of 2:
@everinurmind works is a team member #1
@ghreza-crypto is a team member #2
We did divide team member 3 tasks between us.

Hello, @everinurmind and @ghreza-crypto                    :wave:
Good job so far,  done There are some issues that you still need to work on to go to the next project but you are almost there!
Highlights

Good job adding description for each task +1:

Required Changes

[ ] Make sure to add all the tasks tasks for each bullet point and assign to both of you

[ ] Team member two has significantly more points that the first member, it is not good if a team member has 5+ more points than the other
[ ] Please be reminded to have a task for each of these bullet points, meaning each member needs to have 9 tasks plus the division of the team member 3 which has 9 tasks as well plus the group tasks

Optional suggestions
Every comment with the [OPTIONAL] prefix is not crucial enough to stop the approval of this PR. However, I strongly recommend you to take them into account as they can make your code better.

N/A

Cheers and Happy coding! clapclapclap
Feel free to leave any questions or comments in the PR thread if something is not 100% clear. Please, remember to tag me in your question so I can receive the notification.
Please, do not open a new Pull Request for re-reviews. You should use the same Pull Request submitted for the first review, either valid or invalid unless it is requested otherwise.
As described in the Code reviews limits policy you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.

STATUS: APPROVED :heavy_check_mark:
Hi team :wave:
Your project is complete!
Congratulations! 🎉

Highlights

[x] Each task has a title, a description and at least one assignee :heavy_check_mark:
[x] Tasks distributed equally between the team members :heavy_check_mark:

Optional suggestions
N/A
Every comment with the [OPTIONAL] prefix won't stop the approval of this PR. However, I strongly recommend you to take them into account as they can make your code better. Some of them were simply missed by the previous reviewer and addressing them will really improve your application.
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, remember to tag me in your question so I can receive the notification.

As described in the Code reviews limits policy  you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.


Feature request: IP_STATUS_FILE

Would it be possible to include an option to write the VPN IP out to a file, similar to PORT_FORWARDING_STATUS_FILE?

I slapped this together and added it to my connected rtorrent container to get me by for now.
command: /bin/sh -c 'while [ 1 ]; do \
    PIA_PORT=$(cat /config/forwarded_port); \
    PIA_IP=$(ip route list dev eth0 | awk "/^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+ via / {print \$1}"); \
    sed -i "/port_range/c\port_range = $PIA_PORT-$PIA_PORT" /config/rtorrent/rtorrent.rc; \
    sed -i "/dht.port.set/c\dht.port.set = $PIA_PORT" /config/rtorrent/rtorrent.rc; \
    sed -i "/network.local_address.set/c\network.local_address.set = $PIA_IP" /config/rtorrent/rtorrent.rc; done'

Nice, thanks! The ip route list dev eth0 part is definitely useful, I'll adapt it, probably using horrible hex codes from /proc/net/route.
It would be nice also to log the actual IP address to use for port forwarding in the Docker logs.
Thanks 👍
I'll finish this up in the coming week.

Happy to help! Thank you for considering and taking the time.

It should write the IP address to /ip by default, as soon as the VPN tunnel is running. Enjoy 😉  And feel free to re-open the issue if something doesn't work.


SMB challenge/response never intercepted

Hello, and thank you for this great tool.
I'm facing a problem when trying to MITM the LLMNR requests through Inveigh. I use it with default settings, but what it happens at testing:
[+] [2018-10-29T22:21:53] LLMNR request for ppppppp received from <IP_ADDRESS> [Response Sent]
[+] [2018-10-29T22:21:53] LLMNR request for ppppppp received from <IP_ADDRESS> [Response Sent]
............
And I never receive the SMB challenge. Is that problem has something to do with firewall? I use Inveigh in elevated privileges.

Hi, it could be the firewall. Are you able to do a packet capture on the system that's running Inveigh? That will give you a better view of what's actually hitting the box (smb,ntlmssp).
I did add an indicator of incoming SMB connections for Inveigh 1.4. You should see this for any incoming SMB connection:
[+] [2018-10-31T00:00:37] SMB(445) negotiation request detected from <IP_ADDRESS>:54378
This is just an indicator of an incoming SMB connection and doesn't necessarily mean the authentication will be with NTLM. You should at least see that though before getting a challenge/response through SMB.

Hello, unfortunaly I can't do packet capture on the system running Inveigh.
But I can ensure that I never saw the indicator of incoming SMB connections.
I think nothing actually hitting the box, but I could give you a list of all rules for incoming connections?
Thank you

445 is all that is needed for SMB. 80 for wpad and random http. It looks like you are getting LLMNR traffic through the firewall so I think you're good with UDP 5355.
If you are able to spoof LLMNR, you might be able to just send the traffic to another box that you control on another subnet. The SpooferIP parameter lets you set where the traffic goes. You might have to deal with ACLs between the subnets though.


CMake Error& Compile Error in Centos 7

the CMakeList.txt will raise error in Centos 7
project(SimpleDenoise LANGUAGES C) # change to project(SimpleDenoise)

After that, cmake runs OK. but compilation failed.
the C-compilation must comply with C99 stadand, so I added this
set(CMAKE_C_FLAGS "-std=c99")

the C-style compilation errors have gone, however, there is still issue in main.c.
the author uses some object that comes from c++11, so I need to add the c++11 support in the CMakeList.txt too
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")

Anyway, it's working now.

In Debian Wheezy, the original CMakeList.txt does not work. Only works:
cmake_minimum_required(VERSION 2.8)
project(SimpleDenoise LANGUAGES C)

add_definitions(-std=c99 -D_POSIX_C_SOURCE=199309L)
set(CMAKE_POSITION_INDEPENDENT_CODE ON)
SET(CMAKE_BUILD_TYPE "Release")

include_directories(include)
add_executable(${PROJECT_NAME} main.c)

target_link_libraries(${PROJECT_NAME} -lm -lrt)


Homekit exposure + Chinese cams on locked down subnet

I have some chinese cameras I'm exposing via go2rtc - due to possible security issues I keep them isolated on a no internet access subnet.  I exposed the cams to homekit via go2rtc with absolutely no issues, even though my 'home hubs' (apple tvs) are on a different subnet.  Problem is, I can see the cams in HomeKit when I'm on wifi, but NOT when I leave the house & am on cell network.
I have a very strong suspicion its related to my subnetting and possible mDNS issue????  Anyone have any idea how I might go about keeping these cams isolated yet still allow them to be viewed off the local network?  Do you agree this may be a mDNS issue?  If anyone has any suggestions I can likely do some tweaking to subnets and perhaps get these cams working on wan.
Thanks,

This seemed to be an issue with my HomeHub - not related to network issues.


[Bug]: hover effect

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug
footer search component is not look on hover and One more Thing we can add ref in searh bar on click search icon automatically go on search bar
Expected behavior
if we add ref on search icon it is good for user if he click on icon on search bar  they can search
Add ScreenShots
https://github.com/MAVRICK-1/e-commerce_website/assets/120244528/e672a329-13a3-4590-9ec8-7e8f9ae7bb00
On which device are you experiencing this bug?
Chrome
Record

[X] I have read the Contributing Guidelines
[X] I'm a GSSOC'24 contributor
[X] I have starred the repository

@GOURAVSINGH19 go ahead

please  assign  me and add  lable ...


Allow partial batches

Description of proposed changes
This is a simple additional flag that allows for "partial" batches to be returned.
Fixes #123

@maxrjones @arbennett I wondered if we have any updates on this PR. I recently used xbatcher in a tutorial delivered by Pangeo members in Europe. I added a warning note indicating xbatcher doesn't (yet) return partial batches and mentioned some workarounds (please see the note before the References section).
@weiji14 you've suggested posting this somewhere. I hope this is the correct place for starting the conversation and follow-up actions.

@acocac - thanks for pinging me, I totally lost track of this. I just merged upstream changes into my branch.
@maxrjones - sorry I also missed your ping here, I'll see if I can add a test for this real quick.

@maxrjones - okay test added! Sorry for the bad commit message, my backticks got the best of me 🤦
Anyhow, I think the test is implemented correctly, but the need to do the rounding is kinda ugly IMO. Let me know if you have an easy way to clean that up.

Thanks @arbennett! Mind if I push to your branch to fix the pre-commit errors? I'll also take a look at the rounding logic today


UI/CameraWidget: remove deprecated background color

now CameraWidget is not responsible for drawing the color border. we no longer need to fill the background with bg.

Isn't this still needed to ensure a consistent background when there's no frame yet?

Yes... Clearing the background to black may look inconsisten.


Potential Documentation Bug

I installed storm-tuner on colab but couldn't import Tuner class using:
from storm.tuner import Tuner
as mentioned in the PyPi docs
On referring the git repo, I could resolve it. I am now using:
from storm_tuner import Tuner
Also, params is not defined in the following code snippet (available in PyPi):
`from storm.tuner import Tuner
class MyTuner(Tuner):
def run_trial(self, trial, *args):
    # retrieve hyperparameters
    hp = trial.hyperparameters

    # retrieve any parameters supplied via main search method
    X_train, y_train, X_test, y_test = args[0], args[1], args[2], args[3]

    # build our configuration
    model = self.build_fn(hp)

    # train model
    history = model.fit(X_train,
                        y_train,
                        epochs=25,
                        validation_data=(X_test, y_test),
                        batch_size=params['batch_size'])

    # calculate score
    score = history.history['val_loss'][-1]

    # assign score to the trial
    self.score_trial(trial, score)`

I tweaked this by following the repo examples and changed it to:
batch_size = hp.Param('batch_size', [8,16,32])

Thank you very much for pointing that out! This is changed now.


fix: Neptune bulk load bad request

Feature or Bugfix

Feature

Detail

Neptune bulk load bad request

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

AWS CodeBuild CI Report

CodeBuild project: GitHubCodeBuild8756EF16-4rfo0GHQ0u9a
Commit ID: 55a188c7d3cb7813b3e4674e4bcb3bbf362d6fdf
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubCodeBuild8756EF16-4rfo0GHQ0u9a
Commit ID: 90b3d7fa282e44f46f3d72a6d81b55112afb098c
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubDistributedCodeBuild6-jWcl5DLmvupS
Commit ID: 55a188c7d3cb7813b3e4674e4bcb3bbf362d6fdf
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubDistributedCodeBuild6-jWcl5DLmvupS
Commit ID: 90b3d7fa282e44f46f3d72a6d81b55112afb098c
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubCodeBuild8756EF16-4rfo0GHQ0u9a
Commit ID: efa5b73b5fb1d20814d921779ebedfc5ca6acd2a
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubDistributedCodeBuild6-jWcl5DLmvupS
Commit ID: efa5b73b5fb1d20814d921779ebedfc5ca6acd2a
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: GitHubDistributedCodeBuild6-jWcl5DLmvupS
Commit ID: 768f826cacdd784d567570c7a8b116c9a1eefb32
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository


feat(UI-1102): change system log component

Description
Clicking on the system log does nothing when in events view. Rewrite system log component
Linear Ticket
https://linear.app/autokitteh/issue/UI-1102/system-log-in-events-table
What type of PR is this? (check all applicable)

[ ] 💡 (feat) - A new feature (non-breaking change which adds functionality)
[ ] 🔄 (refactor) - Code Refactoring - A code change that neither fixes a bug nor adds a feature
[ ] 🐞 (fix) - Bug Fix (non-breaking change which fixes an issue)
[ ] 🏎 (perf) - Optimization
[ ] 📄 (docs) - Documentation - Documentation only changes
[ ] 📄 (test) - Tests - Adding missing tests or correcting existing tests
[ ] 🎨 (style) - Styles - Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
[ ] ⚙ (ci) - Continuous Integrations - Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
[ ] ☑ (chore) - Chores - Other changes that don't modify src or test files
[ ] ↩ (revert) - Reverts - Reverts a previous commit(s).

When you move between events and the intro/welcome page the system log jumps a little:
https://github.com/user-attachments/assets/fe849876-55c7-4524-8ee7-5cd34f675405


[AutoPR web/resource-manager] Add directive to web apps for Java code gen

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/3387

This PR has been merged into https://github.com/Azure/azure-sdk-for-go/pull/2215


Use arrow notation for FFI

I think it's safe to assume ES6 compatibility now.
Users may turn to Babel if necessary.

Closing in favor of #27 (rather than re-force push to `patch-1')


http.Request setting PostForm manually has no effect

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go version go1.7.1 darwin/amd64

What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH=""
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/m9/_w9cqs554d55x_sscy_0mcrm0000gn/T/go-build997471420=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"

What did you do?
Use following code snippet to execute request
	var httpClient = &http.Client{
		Timeout: time.Second * 10,
	}
	req, _ := http.NewRequest("POST", "https://<IP_ADDRESS>:8000/post", nil)
	req.PostForm = url.Values{"email": {email}, "pass":{password}}
	res, err := httpClient.Do(req)

Inspect traffic (on receiving server) using tcpdump -> tcpdump -i lo -n port 8000 -A
What did you expect to see?
Data was sent properly as body and being url encoded
What did you see instead?
Empty body
Comment
Common sense is - if the field is exposed, then using it should be expected behavior. Right now only way to assign those values is when creating request using NewRequest and then creating intermediate bytes.NewBufferString()

Additionally it will require manually setting Content-Type and Content-Length Headers.. Sigh...

This is documented:
https://beta.golang.org/pkg/net/http/#Request.PostForm

This field is only available after ParseForm is called.
The HTTP client ignores PostForm and uses Body instead.


Add validation for max burst size

This p-r supplements #141. Throttled queue with 0 burst size makes no sense, because it never allows any events.

Thank you!


DC-area zip codes (in MD or VA) still showing event results from DC

Can we eliminate DC events from these geographic searches--since these are all members representing distant parts of the country.
Ex zip code: 20602

We still have "Coffee" events in the database. Should I change those all to "DC events"?

I changed the coffee events in DC to DC Events


Update rand to 0.7, rand_xorshift to 0.2

There are some method calls which require a mutable reference to the
RNG instance. I chose to create the instance and then immediately create
a reference to it which is then used within this scope. If you know a better
solution, feel free to adjust accordingly.

You'll need to update ci/compat-Cargo.lock for the Rust 1.28 check.
Current versions of rand also use dependency renaming for getrandom, which old Rust doesn't support. It might work well enough to resolve the lock file now that someone added a placeholder getrandom_package, though you probably need to use Rust 1.28 directly to see what happens. I'm wary that this might still cause problems for anyone depending on rayon in general though.
We could also wait for Rust 1.31 to be a year old (December 6th) per our policy on the minimum supported compiler, then the package renaming won't be an issue anymore.

Is there a defined procedure for updating the lock file, or is it just manual editing until it works with the desired crate versions on the target version of the compiler?

Yeah, we should probably write some instructions for this. It's a somewhat manual process, but not editing the file directly. Copy ci/compat-Cargo.lock over your root Cargo.lock. If you just cargo build from there, it should update as few dependencies as needed, and then you can copy the file back. You might use cargo +1.28.0 build to do this with the older version, assuming you've installed that with rustup. If any dependencies need manual downgrading for compatibility, you can specify that with cargo update -p some_crate --precise 1.2.3.

Ok, then I was on the correct path already. Building works, but I had attempted to run cargo +1.28.0 test which fails due to rand_xorshift (and probably others, but that's the first one it attempts) using the 2018 edition. If the compatibility to at least one year old compilers matters for dev dependencies, we would in deed have to wait for rustc 1.31 being one year old. Otherwise it would work. I pushed a commit with the updated ci/compat-Cargo.lock file.

I'm inclined to just wait for the anniversary of 1.31 on December 6th, so we can bump our requirement and not worry about the dependencies that use package renaming.
(The one-year compatibility policy is sort of arbitrary, but I feel it's useful to be predictable.)

I rebased this for conflicts with #712. Thanks again!
bors r+


Add new operators to avoid pedersen commitments in amount validation

Validation for NIA contracts currently involves pedersen commitments to verify that the sum of inputs equals the sum of outputs. Since bulletproofs are still not an option, amounts are included in clear within the consignment. Hence, given pedersen commitments are constructed by the receiver during validation, this currently brings no advantages over a simple sum verification, but we still want to keep them so that bulletproof can be added in a backwards compatible update.
This PR introduces 3 new AluVM operators that behave like their pedersen commitment counterparts but only do simple sums. This should bring the following advantages:

no cryptographic operations where they're not necessary, which should simplify audit
no dependency on secp256k1-zkp in case we put pedersen commitment operations behind a feature flag
performance improvement, even though this doesn't seem to be a bottleneck for now

The new operators can be used by schema developers to create schemas corresponding to NIA and CFA that only work with revealed state.

Well, I don't think this is going to work in the real-world cases: once we add bulletproofs and just a single user apply them, he will lose all his assets. This is a footgun

once we add bulletproofs and just a single user apply them, he will lose all his assets.

Why would a user apply bulletproof to an asset using a schema that cannot support bulletproof? He would need a wallet that supports this. If we are concerned about evil/stupid  wallet developers implementing buttons in the UI that lead to the destruction of the user's assets there are already plenty of simpler ways to do it.

Why would a user apply bulletproof to an asset using a schema that cannot support bulletproof?

This PR doesn't introduce such schema, so there is no such thing as a "schema that does not support bulletproof"

This PR doesn't introduce such schema

But in introduces new AluVM operators that would make it possible for schema developers to create such schemas, i.e.  schemas that don't rely on pedersen commitment to verify that the sum of inputs equals the sum of outputs and as a consequence would not be able to support bulletproof whenever it becomes available.

I honestly don't understand how this bulletproof addition will work then. Is it an RGB-wide update that applies to all schemas regardless if they need it or not? What about existing schemas (like UDA) that have no pedersen commitments in validation, will all holders lose those assets when we'll add bulletproofs?
I also tried creating a new NIA-like schema with these new operators and everything seems to work correctly, so I'd say the one issue we should address is how to selectively apply the bulletproof update only to schemas that require it. This would allow both UDA and a new schema using the operators from this PR to be unaffected by a bulletproof addition.

Is it an RGB-wide update that applies to all schemas regardless if they need it or not?

Please forget about schemas in context of bulletproofs; they are unrelated! Bulletproofs apply at the level of RGB basic data structures, much before any schema do exist. Also, UDA has nothing to do with bulletproofs - this is a specific schema, existing outside of rgb-core on the application level.

I also tried creating a new NIA-like schema with these new operators and everything seems to work correctly, so I'd say the one issue we should address is how to selectively apply the bulletproof update only to schemas that require it.

Yes, as I said it will work until we activate bulletproofs :) Thus, with this PR we would either be unable to ever activate them - or their activation would mean loss of the assets using scripts with the opcodes introduced in this PRs (or there would be two RGB versions, incompatible with each other).

I honestly don't understand how this bulletproof addition will work then.

Not just bulletproof: if you add something to RGB (or any client-side validation) which was valid before, but becomes invalid later, than this is called a push-back, which means loss of assets affected by those features - or a protocol split into two incompatible versions.
If you introduce opcodes from this PR, they will be working only when fungible state is not stored as Pedersen commitments (i.e. bulletproofs are not active). Once they are active, the state got concealed and this opcodes will fail for the users - meaning a push-back ("something was valid, becomes invalid").
The only right way to allow non-Pedersen fungible state is to add a new data type to schema and operation modules; and re-write a lot of code in validation etc. Basically we are talking about few thousands lines of consensus code changes...

This is how the removal of bulleptroofs means: https://github.com/RGB-WG/rgb-core/pull/279

Please forget about schemas in context of bulletproofs; they are unrelated! Bulletproofs apply at the level of RGB basic data structures, much before any schema do exist. Also, UDA has nothing to do with bulletproofs - this is a specific schema, existing outside of rgb-core on the application level.

I brought up UDA just an example of a usecase that requires some state that should not be concealed. For instance, RGB21 supports fractioning non-fungible assets, which seems to require some sort of fungible-like state. Would that be concealed in a future bulletproof update as well?

The only right way to allow non-Pedersen fungible state is to add a new data type to schema and operation modules; and re-write a lot of code in validation etc. Basically we are talking about few thousands lines of consensus code changes...

There is a need for schemas that only work with revealed state regardless of any future updates enabling concealed fungible state. At the very least, it would be pretty weird if a system that "was designed to allow everything that is possible with blockchain-based smart contracts" could not support simple fungible assets without computationally intensive privacy features.


add Codecov

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@6fe8293). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             master     #2   +/-   ##
=======================================
  Coverage          ?   100%
=======================================
  Files             ?      1
  Lines             ?      3
  Branches          ?      0
=======================================
  Hits              ?      3
  Misses            ?      0
  Partials          ?      0

Continue to review full report at Codecov.

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


Improve compatibility with Visual Studio 15.8+ by including Test Adapter dll in all build output folders.

See https://github.com/Microsoft/vstest/issues/1736
Test Explorer changes affect the way test adapters are discovered, and for Fixie this affects the ability for full .NET Framework test assemblies to properly run under test explorer as of VS 15.8.
The workaround as pointed out in the referenced vstest issue is to go to Tools \ Options \ Test and deselect "For improved performance, only use test adapters in test assembly folder or as specified in runsettings file."

It is likely that we can avoid the need to visit this checkbox if we change the way the Fixie NuGet package deals with the Test Adapter dll. Upon the release of Fixie 2, the Test Adapter does appear in the test project build output folder for netcoreapp test projects, and that's why the issue doesn't present itself for such projects. For netXX targets, though, the Test Adapter dll does not appear in the test project build output folder, because historically it simply wasn't needed to be there for Test Explorer to work. Now that VS's behavior has changed for Full Framework tests to more closely match the behavior of .NET Core tests, and for the sake of consistency, the Fixie NuGet package should likely perform the same "extra" dll copy to satisfy Test Explorer.
The consequence would be that the Test Adapter arrives in build output folders even for end users who don't use Test Explorer, which may motivate separating the Test Adapter to a separate NuGet package, though that invites the risk of end users installing incompatible versions of Fixie and Fixie.VIsualStudio.TestAdapter.
Likley implementation: /build/Fixie.props includes ItemGroup tags which explicitly copy dlls to the output directory for .NETCoreApp projects. Attempt adding a similar ItemGroup for full framework test projects to include Fixie.VisualStudio.TestAdapter.

Fixed in v2.0.2


Fix #1166 Add 1x retry with 2sec sleep time. (+Tests)

The retry gets triggered when the parsing of the content fails.
JSON unmarshal fails due to invalid JSON -> retry
CSV cannot find separator -> retry
CSV failed to parse -> retry
HTTP Response from host gets not checked nor there is a timeout
configured for the default http client.
If I should check for the returned HTTP status code ( != 200 ) then I need another client library ... which is one more dependency for hugo ... let me know.

Can you fix the commit message in line with the guide lines (and the +Tests is superflous, goes without saying ... "No tests" would be relevant if the commit doesn't contain any).

Done.

Wouldn't it be simpler to just do a for loop around the httpClient.Get:
if res.StatusCode == 200 {
  break
}
``

Maybe check for all status-codes in the 200-series (if >= 200 && < 300), but this looks too complicated to solve a simpler problem.`

Yes I thought also this way ... but what if it's a 200er reponse with no valid file content?
Let us test (aka merge) this version and if it sucks I'll refactor it to the status codes.

Yea, well - I see the issue starter also talks about garbled content. Merged in cc5d63c


Feature request, run in demo mode with just in memory datasource

To be able to try it and see how it work, it would be great to be able to just run it with out needing to set up the database.

Thanks for your request! Currently in the java-client we provide 2 options for you:

Within the client we already provide a FakeUnleash implementation, mostly to facilitate unit-testing: https://github.com/finn-no/unleash-client-java/blob/master/src/main/java/no/finn/unleash/FakeUnleash.java

Feel free to use the openly deployed cloud demo for local testing:
http://unleash.herokuapp.com/

If you want the server to be able to run in in-memory mode it would be better to post your request on the unleash project on github

Ops i actually meant this for the actual unleash node app, not the java client, but yes that point two there answers my request i guess. Include it in the readme of the main repo maybe? :D


Update client3:async-http-client-backend-zio, ... to 3.7.2

Updates

com.softwaremill.sttp.client3:async-http-client-backend-zio
com.softwaremill.sttp.client3:circe
com.softwaremill.sttp.client3:core
com.softwaremill.sttp.client3:slf4j-backend
com.softwaremill.sttp.client3:zio

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

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.softwaremill.sttp.client3" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "com.softwaremill.sttp.client3" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, commit-count:1

Superseded by #386.


Web3-Onboard - Move deployProjectButtonText into separate component, shared across v1 and v2 [3/n]

What does this PR do and why?
Provide a description of what this PR does. Link to any relevant GitHub issues, Notion tasks or Discord discussions.
Screenshots or screen recordings
If applicable, provide screenshots or screen recordings to demonstrate the changes.
Acceptance checklist

[ ] I have evaluated the Approval Guidelines for this PR.
[ ] I have tested this PR in all supported browsers.
[ ] I have tested this PR in dark mode and light mode (if applicable).

Current dependencies on/for this PR:

main

PR #1739

PR #1740

PR #1741   👈

This comment was auto-generated by Graphite.


Protect against the default .js extension being replaced before pirates gets a chance to store originalJsExtension

Right now pirates assumes that Module_.extensions['.js'] points to the original javascript extension the first time it sees it. That is an improper assumption, as it could have been changed already by any one of the following:

Another module that doesn't use pirates.
Another module that uses a semver incompatible version of pirates (so it's not deduped).
Another module that uses pirates in an npm@2 environment (so there is no de-duping regardless).

Reference:

https://github.com/jamestalmage/default-require-extensions. Should provide an easy fix for this.
https://github.com/jamestalmage/append-transform/issues/6. Reasons we chose this way vs alternative solutions.

Hmm... I'm not 100% sure about this... It might be valid that you want to copy
whatever the chain for .js is. (ie. You're adding a clmpile-to-js file format).
Let me think on it.
Thanks! Ari
On Tue, Jan 26, 2016 at 7:26 PM, James Talmage<EMAIL_ADDRESS>wrote:
Right now pirates assumes that Module_.extensions['.js'] points to the original javascript extension. That is an improper assumption, it
could have been changed already by any one of the following:

Another module that doesn't use pirates.
Another module that uses a semver incompatible version of pirates (so it's
not deduped).
Another module that uses pirates in an npm@2 environment (so there is no de-duping regardless).

Reference:

[https://github.com/jamestalmage/default-require-extensions] https://github.com/jamestalmage/default-require-extensions
[https://github.com/jamestalmage/default-require-extensions] . Should provide an easy fix for this.
jamestalmage/append-transform#6
[https://github.com/jamestalmage/append-transform/issues/6] . Reasons we chose this way vs alternative solutions.

—
Reply to this email directly or view it on GitHub [https://github.com/ariporad/pirates/issues/24] .[https://github.com/notifications/beacon/ABu7pEOcVDo87ozAorJ1qmdG92GTj0heks5peDCDgaJpZM4HNF4r.gif]

Yeah, that was discussed in jamestalmage/append-transform#6.


How to run locally

Hello, team,
Sorry for disturbing you, but I'm trying to run the application locally on my machine, but I'm facing some problems. I found the docs folder and I tried to follow the instructions there and run the application, but without success. I faced the following error during running this command:
docker run \
    -e EDC_VAULT_SECRETS="key1:secret1;key2:secret2" \
    -p 8080:8080 -p 8181:8181 -p 8282:8282 -p 9090:9090 -p 9999:9999 \
    -v ${CONFIGURATION_PROPERTIES_FILE:-/dev/null}:/app/configuration.properties \
    -v ${LOGGING_PROPERTIES_FILE:-/dev/null}:/app/logging.properties \
    -i edc-runtime-memory:latest

And here is the error
Caused by: org.eclipse.edc.spi.EdcException: Mandatory config value missing: 'edc.iam.sts.oauth.token.url'. This runtime is not operational.

Could you please, point out what else should i run to have this oauth url and setup the application?
Regards,
Petar

@PeterSRWeb3 first of all, this is not an issue, but - at best - a discussion. I think, not even that.
Second, it most definitely is not a bug, because you are obviously not using the official Tractus-X EDC helm charts. Please, don't raise bugs simply because you are not willing to go the officially supported route.
Third, the exception says in black-and-white what is missing, i.e. a config value. It even tells you which one.
If you don't read official documentation nor use official distributions of Tx-EDC we can't help you.


Binary Format additional Option & Cleanup

Feature Request:

Currently using a lot of binary fields which contain bit flags. It would be very useful for a formatting option that displayed the results as 1's & 0's
Feature Request add a binary data formatter that will output strings in an arbitrary base.
Include a checkbox that will pad the front with 0's (to maximum length of binary strings) if checked.
I'm interested in base 2 which would output 1's & 0's but other base options may be useful to other people.
example output when base is input as 2, and my maximum length of binary strings is 5
select to_byte(0) -> 0,     if checkbox for padding zeros is checked 00000
select to_byte(1) -> 1,     if checkbox for padding zeros is checked 00001
select to_byte(2) -> 10,   if checkbox for padding zeros is checked 00010
select to_byte(4) -> 100, if checkbox for padding zeros is checked 00100

Also is there a reason that Binary fields contain the binary image in every record rather than in just the header as opposed to the other fields such as int & date.
Request remove the small image from binary records and leave the image/data type indicator in the header so its consistent with other data types.

What is "binary fields" actual type? Is it numeric or byte array?
With attribute transformers (new feature which will present in 3.6.6) I can represent numeric data types in any radix (e.g. in binary or hex). Will it solve your problem?
In regards to cell images - you can disable them on "Result Sets->Presentation" preference page.

What is "binary fields" actual type? Is it numeric or byte array?

For my use case it is typically stored on the db as a numeric. Although I think its within reason to assume that the value will be returned as byte array (which is what I'm trying to demonstrate with to_byte).
Being able to display numeric in binary is nice but I'd like to be able to display only byte array datatypes in binary as well. I.e. I don't want to display all numbers as binary only the values i return as byte arrays with to_byte. Does that make sense?
For example consider user_id = 123, preferences_flag = 23 both stored as numeric on the db.
Ideally, i could configure the binary data formatter in such a way that i could return the following.
select user_id, to_byte(preferences_flag)

user_id
to_byte(preferences_flag)

123
10111

Yeah, it is how it supposed to work.


fix raw value error test introduced in #955

This test was introduced in #955, which went through a couple of revisions and the message got out of date.
(I spotted it as soon as I got the merge notification, @lattner)

Ah, thanks for noticing!

@lattner sorry about that 😛


Job status search + UTC date formatting changes

Multiselect option to search jobs by status
UTC format for all date time fields

part of #164

Coverage remained the same at 88.878% when pulling fd09cbe51382c494ddf7d06c3ec0370b92c43b70 on cabhishek:develop into 4ab4a309c5d4f76c2ee725b4354c768ac64b1453 on Netflix:develop.

Coverage remained the same at 88.878% when pulling 12a88ded8a8c286f78e6d626706a239457db7809 on cabhishek:develop into 851ee6eeed342ecfcb7e9698821d0950ef1a1b84 on Netflix:develop.


Add XQuartz beta

Based on the xquartz cask in the main repo, but now with more beta!
Also updates the prefs plist to point Sparkle at the beta feed, since there's no way to do so inside the UI.

Xquartz in the main repo is broken. This seems to have the same problematic line; are you sure it works?

Hi @3van , sorry for delaying this so much, could you please rebase latest commits from master and push again to see if it's passing all tests?

Closing this as a duplicate of #788


Directly integrate with wallet

Is there a way to just deeplink and directly connect with a installed wallet, on android?

Hello @Hardu2203, i think you can create your deeplink and parse the link you got and then pass it to signClient.pair(YOUR_DEEPLINK)


Support for newer diffusion models (2.1 and XL) and other questions

Will the technology support more modern SD2.1 and SDXL models?
SD1.5 is popular at the moment, but it slows down the development of neural networks and models.
Will the technology conflict (or replace) ToMe?
And it is not very clear on the consumption of video memory. How much percent will increase the consumption of it? (Approximately as a percentage)
There is also a question about training LoRA models for HyperTile.
Is there any information at this stage on how to do this?!

I need to locate the SDXL layers that takes longer to evaluate, to try tiling it.
Tiling just the attention gives only 1.1 to 1.2 speed-up.
Memory usage is not increased compared to non-tiled version. Its decreases memory usage and decreases time too. win-win.
I'll play with a fork of Kohya-ss that I made a few weeks ago, https://github.com/tfernd/kohya_ss-multiplier.
They use diffusers as back-end, so it should be really simple. Still don't know if that decreases the memory usage by a lot during the backward pass since now the attention is smaller.


K8SSAND-1263 ⁃ How to explain/describe cassandradatacenter CRD resource via kubectl?

Cass-Operator : 1.9.0
DSE Version : 6.8.19
When performing kubectl explain on cassandradatacenter resource, it responds with empty description and content.
here's the example.
`kubectl explain cassandradatacenter

kubectl explain cassandradatacenter
KIND:     CassandraDatacenter
VERSION:  cassandra.datastax.com/v1beta1

DESCRIPTION:

`
┆Issue is synchronized with this Jira Task by Unito
┆friendlyId: K8SSAND-1263
┆priority: Medium

You can't. The kubectl explain only allows to display CRDs which have no "free fields", such as our spec.config field.

That said, in kube 1.23 and the newest (master) cass-operator, these features worked for me:
➜  cass-operator git:(go_117_update) ✗ kubectl explain cassandradatacenters
KIND:     CassandraDatacenter
VERSION:  cassandra.datastax.com/v1beta1

DESCRIPTION:
     CassandraDatacenter is the Schema for the cassandradatacenters API

FIELDS:
   apiVersion   <string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values.  Servers may infer this from the endpoint the client submits
     requests to. Cannot be updated. In CamelCase. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

   metadata     <Object>
     Standard object's metadata.


Cannot pass result of typeof ... == 'function' of instanceof Function as function parameter

Bug Report
🔎 Search Terms
typeof function, instanceof Function, narrowing, Function

🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about

⏯ Playground Link
Playground link with relevant code
💻 Code
function wrap (fn: (...args: any[]) => unknown) {}

function tryWrap (fn: unknown): void {
  if (typeof fn == 'function') wrap(fn)
} //         The error is over here ↑↑

🙁 Actual behavior
Error: Argument of type 'Function' is not assignable to parameter of type '(...args: any[]) => unknown'.   Type 'Function' provides no match for the signature '(...args: any[]): unknown'.(2345)
🙂 Expected behavior
No error
Notes
The reason for having this problem is because typeof ... == 'function' is narrowing to Function. And here we have a few problems:

Assuming that Function interface is basically an implementation detail of the compiler
Function is too generic

The behavior for instanceof Function is the same.
So, the solution would be to narrow it to a different type, because implementation details should not be exposed as a result of basic ES operations, or fix the Function type

IMO this is a correct error.  wrap is free to call fn, per its signature, with any number and type of arguments.  Given that the only thing you know about fn is that it's a function, you have no way to know that any attempt to call it is safe, so the compiler prevents that from happening.

In other words, since this is an error...
function tryWrap (fn: unknown): void {
  if (typeof fn == 'function') {
    fn(42, "foo");
  }
}

...then this should also be an error (and is)...
function wrap (fn: (...args: any[]) => unknown) {
  fn(42, "foo");
}

function tryWrap (fn: unknown): void {
  if (typeof fn == 'function') wrap(fn)
}

@fatcerberus

I have tried your code in the playground - it gives no error
It's up to wrap to decide on what to do with fn, not tryWrap

It's up to wrap to decide on what to do with fn, not tryWrap

If it’s not safe to call fn directly with arbitrary arguments (which it isn’t, and I don’t know why that code isn’t an error), then why should you be allowed to pass it to a function that can freely do the same?

The ability to call comes from the nature of ECMAScript - something that has typeof "function" can be called. TypeScript is checking only the types of arguments and the return value. And the signature of wrap is as generic as possible. Moreover, it uses any, and any should disable any kind of type checks

The ability to call comes from the nature of ECMAScript - something that has typeof "function" can be called.

This falls under all legal JavaScript is legal TypeScript.  Yes, if typeof f === 'function', you can call f with any number of arguments of any type and that will not result in a runtime error.  But the callee may very well throw a runtime error of its own because it got arguments it didn't expect, or it might not throw an error but might do an entirely inappropriate thing for your use case.  The errors that Typescript gives help you avoid these undesirable situations.  If you want to say "shut up I know what I'm doing" to the compiler, consider asserting fn as any or setting the compiler option noEmitOnError: false.

you can call f with any number of arguments of any type

yes

and that will not result in a runtime error

no. A runtime error is not a term of TypeScript.
You can provide to wrap any kind of function you can specify and wrap can do anything with it - TypeScript will give no error
function foo (x: number) {}

declare const boo: (...args: never) => unknown

function wrap(fn: (...args: any[]) => unknown) {
  fn('abc')
}

wrap(foo)
wrap(boo)

This is expected and intended. So arguments types have nothing to do with the problem here because checking on them has been disabled by any.
The problem here is with the synthetic Function type that seems to cover something more than a function in JavaScript or TypeScript can be

Hey, just to mention that typeof class {} is also "function"... 😶🌫


Is this package still maintained?

Atom is currently sunsetting (shutting down their services) so I switched to pulsar (https://pulsar-edit.dev/) as the successor.
So is this package going to be maintained? According to the README.md it looks pretty dead.

As of May, 25th 2022, this project is officially unmaintained. The last maintainer (me) doesn't have admin access to the repository, and couldn't get the organization owner's attention to get it, so if you'd like to take over, feel free to fork. @lierdakil


Add IRC status commands EDITPORT and restrict DELPORT

Possible fix (if wanted) for issue #1806
In "danger" of locking yourself out by removing your active port, this should not be possible (same as to HTTP) in my opinion.
This will allow the modification of an active port instead.

Any tests?


Fixes for Accessibility Bugs 458661 & 586335

Fixes for Accessibility bugs 458661 and 586335.
The fix for 458661 changes the Add/Edit Enum Type Dialog so that the help text is available on every cell of the data grid as requested.
I am unable to fix 586335 the way they suggest in the bug - the underlying layer does not expose the required API. However I added handlers for Ctrl+Up and Ctrl+Down which cause the appropriate entity or entity compartment to collapse or expand. Then I added help text that should make this clear to a user. So that should provide a solution for users who use screen readers.

@lajones When you say, "underlying layer" do you mean the DSL Toolkit?

@ajcvickers yes.

@lajones If there is further pushback on 586335, then we can route to the DSL Tookit team.
/cc @divega

Checked into master with 72b5214fb.


Push ++: and :++ down from collection.Iterable to collection.Seq and pull +: and :+ up from immutable.Seq to collection.Seq.

The problem is less important with Seq than it is with Set or Map, because in immutable.Seq the addition operations are named :+ and +:, whereas in mutable.Seq we only have +=, so there is no confusion possible with :+= (which would desugar to xs = xs :+ y).
In immutable.Set and immutable.Map, however, we have + and -, and in mutable.Set and mutable.Map we have += and -=. If mutable.Set and mutable.Map also had + and -, then += and -= would be confusing: is it the actual += and -= operators or the sugar for xs = xs + y and xs = xs - y?

I removed the @inline final from concat as requested. I also made another PR (#206) that pushes ++: and :++ down to immutable.Seq instead of to collection.Seq as this PR does (no need to move +: and :+ in that PR since those are already defined in immutable.Seq).

I think collection.Seq is the right place for those. I don't know how much will break by removing ++ and ++: from Iterable but all the :+ and :+ uses I've seen so far were for collection.Seq.

all the :+ and :+ uses I've seen so far were for collection.Seq.

But if we do scala.Seq[A] = scala.collection.immutable.Seq[A] then at least existing code that was using +: and :+ on the default Seq will still work if we move these operations to the immutable Seq.

You often use it on collection.Seq because you want it to work on all Seqs. Switching the default may work for some cases but I expect the majority will still require these methods (or be reimplemented in possibly very inefficient ways).

I also think the utility of these methods makes them worth having even for collections typed purely as mutable.  The argument that they're inefficient with mutable collections and you want to discourage their use isn't a very good one, because changing a mutable collection into an immutable one is also not very efficient.  It's a bit of a learning barrier, but for something so central to the use of the language I don't think we should sacrifice much in the way of trained usage for the benefit of learners.

@odersky do you want to weigh in on one side or the other?

Hi @odd, in our last meeting we finally agreed on putting these methods on collection.Seq but to rename them to kind of convey an immutable meaning: instead of append and prepend we would have appended and prepended (that’s consistent with Map which already has updated)

Thanks for the update(d), I suppose the symbolic aliases will still be the same though.

That makes sense to me. The work on SeqView & Co could then be moved into a separate PR.

@odd I’ve merged the two first commits into master. I had to rebase because I fixed a couple of compilation errors. I’m closing this PR.


Black models on some devices

Description
We recently deployed model-viewer for a client and have been getting some reports of black models. The client was able to show me the issue over video chat and provided OS (Windows 10 Home 1903) + browser (Chrome 80) info. They were using a laptop, but I don't know the make and model. I had them go to modelviewer.dev and I saw that astronaut was black as well.
I've been trying to reproduce the issue so that I can get more details, but I haven't been able to yet. Posting here in the hopes that others are having the same problem. Other issues, such as #679, look to be similar, but were last updated almost 6 months ago.
The only time that I've seen black models was in development when the hdr environment image path was wrong. Based on that, I guessed that perhaps the image wasn't getting downloaded fast enough, so as an attempted workaround I added this js code to try to get the browser to re-download and reset it, but it doesn't seem to help.
function reloadLighting() {
  var viewers = document.getElementsByTagName('model-viewer')
  if (viewers.length > 0) {
    var viewer = viewers[0];
    viewer.addEventListener('load', function() {
      var imgSrc = viewer.getAttribute('environment-image');
      var background = new Image();
      background.src = imgSrc;
      viewer.setAttribute('environment-image', imgSrc);
    });
  }
}

// Event Listeners
window.addEventListener('load', function() {
  reloadLighting();
});

Note: I've also had reports of black textures on an "older LG phone" and reports that our homepage, https://www.3xr.com (with 3 models) causes an Awh Snap crash in chrome on an underpowered mini conference room PC.
Live Demo
The client's website where this is live currently (2/28/2020) is running an A/B test, so the 3D model link doesn't always appear. Here's the link: https://helixsleep.com/products/midnight-luxe?variant=queen
The page that actually contains the model viewer is in an iframe, here:
https://www.3xr.com/asset/view/w4cc76styjyf/web
Here is another demo page here with more models. It has the same code that the client is using to open the iframe in a modal: https://www.3xr.com/demo/helix
Note: this works on most devices, and I haven't been able to see black models on the machines that I've tested, including a VM with the same Windows + Chrome versions as reported.
Screenshot:
Browser Affected

[X] Chrome - 80.0.3987.122 (as reported to me)
[ ] Edge
[ ] Firefox
[ ] Helios
[ ] IE
[ ] Safari

OS

[ ] Android
[ ] iOS
[ ] Linux
[ ] MacOS
[X] Windows - Home 1903 - 18362.6.7 (as reported to me)

I've asked the client to send me the output of chrome://gpu and will add it as a comment when I have it.
Versions

model-viewer: v0.9.0 (loaded from<EMAIL_ADDRESS>and<EMAIL_ADDRESS>three.js: ??? - I don't see three.js loaded in the network tab on the debug console.
This also happens on modelviewer.dev with the astronaut.

@MikeFesta thanks for the report. Three.js is bundled with <model-viewer> so will probably be r113 (since that is what we ship with v0.9.0).
We'll look forward to the results from chrome://gpu
I speculate that this could have some overlap with #1043, which shows a <model-viewer> page crashing in Chrome on Windows 10. But, until we get chrome://gpu reports, it will most likely challenging for us to reproduce this issue.

The report is quite long and was unformatted if pasted here, so I put it in this google doc:https://docs.google.com/document/d/1kygiUoIHqOd2t8szf6i2D7z-IPXl39vGg4-HtQ3HwLY/edit?usp=sharing
Here's a preview screenshot

@MikeFesta if you just click the "copy to clipboard" button, it will produce an abridged report that is easy to paste here. Here is mine, for example:
Data exported | 2020-02-28T20:16:03.952Z
-- | --
Chrome version | Chrome/80.0.3987.122
Operating system | Mac OS X 10.15.3
Software rendering list URL | https://chromium.googlesource.com/chromium/src/+/cf72c4c4f7db75bc3da689cd76513962d31c7b52/gpu/config/software_rendering_list.json
Driver bug list URL | https://chromium.googlesource.com/chromium/src/+/cf72c4c4f7db75bc3da689cd76513962d31c7b52/gpu/config/gpu_driver_bug_list.json
ANGLE commit id | 362168eb695d
2D graphics backend | Skia/80 97c9a95908bc8c7a6794259b35f366a3291e2d0f
Command Line | /Applications/Google Chrome.app/Contents/MacOS/Google Chrome --flag-switches-begin --flag-switches-end --enable-audio-service-sandbox

Getting the same issue with some .glb files looking completely black (example .glb file here).
Preview Tests
Texture is not shown in model-viewer even though it is shown when previewing it on tools like https://gltf-viewer.donmccurdy.com/ or https://sandbox.babylonjs.com/.
Previewing it with Three.js (https://threejs.org/editor/) also looks black. But can be fixed by adding a DirectionalLight to the scene (on the top menu bar: Add -> DirectionalLight)
File Origin
I encountered this issue when using Windows Paint 3D, importing a 3D file from their 3D library, and saving it as .glb. These .glb files look completely black with model-viewer.
chrome://gpu Output

Data exported
2020-04-24T17:09:49.239Z

Chrome version
Chrome/81.0.4044.122

Operating system
Windows NT 10.0.18362

Software rendering list URL
https://chromium.googlesource.com/chromium/src/+/44f4233f08910d83b146130c1938256a2e05b136/gpu/config/software_rendering_list.json

Driver bug list URL
https://chromium.googlesource.com/chromium/src/+/44f4233f08910d83b146130c1938256a2e05b136/gpu/config/gpu_driver_bug_list.json

ANGLE commit id
91c39dae9a51

2D graphics backend
Skia/81 5e3098d8fad5b3a6fa9c70d6438f416eec201db7

Command Line
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --flag-switches-begin --flag-switches-end --enable-audio-service-sandbox

Please help!

Any time the model is black until a directional light is added, we have found it is nearly always because the AO texture channel is completely black. Apparently some exporters do this by default, but it is an error.

Hi there. Any chance to find a out of the box way to fix black models on android? Everything I look from model-viewer on my Samsung j5 using chrome v85 is black, except for the aquarium scene from the related issue.

@ymongo When you say everything, do you mean the pages at modelviewer.dev are all black models as well? Can you please provide links to at least one page that is black and one that is not so I can try to understand what's happening?

Hi elalish,
Thanks for your answer. modelviewer.dev astronaut model is black on my phone, as well as some three.js models from tutorials, but the webgl aquarium page is fine.
Some screenshots here: https://photos.app.goo.gl/njATBJF4iRNE7TWm9

@ymongo Can you please be more specific and add links for each of the pages you reference? I don't know where the "aquarium page" is, nor which tutorials you're referring to, nor what the "van customizer" is. Also, your screenshots link is an empty album.

Sorry it seems I missclicked and deleted the screenshots, now restored.
renders black model on Android:
https://modelviewer.dev
https://tympanus.net/Tutorials/3DModelCustomizer/
https://osorina.github.io/3d-headphones/
renders properly:
https://webglsamples.org/aquarium/aquarium.html

@ymongo It sounds like you have probably found a GPU driver issue with three.js, so you might try filing an issue on their Github. The only one of those sites that even uses model-viewer is your first link, and given the other trouble you have, it seems to be problem that's below our codebase.


Where is distinct_id stored in cookies?

I can get distinct_id through console,

but when I see the cookie, I didn't find anything revelant to Mixpanel

I want to know where is the distinct_id?
Thanks!

You want the cookie named mp_<YOURTOKEN>_mixpanel.

@tdumitrescu I'm sorry, but I really didn't see it. But I can access it through mixpanel.get_distinct_id(). The pic you see is the cookie for all (GA, Amplitude, Segment, but no mixpanel).

I really have no idea why this is happening.... My app is at http://learnbyreading.herokuapp.com/

@cqcn1991 The Mixpanel cookie (by default) is a cross-subdomain cookie. Heroku does not allow cross-subdomain cookies.
Change the cross_subdomain_cookie config setting in your mixpanel.init function to false, which will allow your subdomain's cookie to be stored and keep the Mixpanel distinct_id consistent across the sub-domain:
mixpanel.init(PROJECT_TOKEN,{cross_subdomain_cookie:false});
Or, use a CNAME to change from yourdomain.herokuapp.com to yourdomain.com.
See here: Track Across Hosted Subdomains

For what it's worth, I get the MP cookie just fine on that site, along with a bunch of others that are not in @cqcn1991's screenshot:

@jaredmixpanel Thanks! That's the right anwser. I just found the option at Segment, and when I turn it off, the cookie appears.


feat(json_schema): make KeywordMap Send + Sync

May break backward compatibility.
should fix: #22

There were the following issues with your Pull Request

Commit: 1026ca29780a140615a728d09f89e003ece46fa2
Commits must be in the following format: %{type}(%{scope}): %{description}

Guidelines are available at https://github.com/rustless/valico/blob/master/CONTRIBUTING.md

This message was auto-generated by https://gitcop.com

There were the following issues with your Pull Request

Commit: 1026ca29780a140615a728d09f89e003ece46fa2
Commits must be in the following format: %{type}(%{scope}): %{description}

Guidelines are available at https://github.com/rustless/valico/blob/master/CONTRIBUTING.md

This message was auto-generated by https://gitcop.com


Elegantly handle incorrect <PrismicText> usage with Key Text fields

Is your feature request related to a problem? Please describe.
The <PrismicText> component is designed to accept and render Rich Text fields. It outputs a plain text version of its input using @prismicio/helpers's asText() helper.
A developer might reach for the <PrismicText> component for other text-related fields, such as a Key Text field. This is an invalid input, thus the component fails to handle it properly and results in an unhandled error.

Describe the solution you'd like
While <PrismicText> shouldn't be used to render plain strings (as is the case with a Key Text field), we can handle the invalid case in a more friendly way.
For example, the component could continue to throw an error when it receives an invalid input, but the message could contain an explanation of why the input is invalid and how to fix it.
The component could also pass through the input with no processing, but also print an error/warning to the console explaining that the input is unsupported.
Lastly, TypeScript users could receive an special message displayed in their code editors when passed an invalid input. This might be implemented with something like @deprecated which allows for a more friendly message than a complex TypeScript type error.

Describe alternatives you've considered
Rename <PrismicText>
The <PrismicText> component could be renamed to better reflect what it is doing. It lives within a small family of Rich Text components:

<PrismicRichText> - Converts a Rich Text field into React components.
<PrismicText> - Converts a Rich Text field into a plain string.

<PrismicText> could be renamed to something like <PrismicRichTextAsString>. This is verbose and ugly.
Remove <PrismicText> and move functionality into <PrismicRichText>
Alternatively, <PrismicText> could be removed if its functionality was moved into <PrismicRichText>. A prop could be added that lets a developer select between component output or string output.
<PrismicRichText field={doc.data.field} format="text" />

This is harder to parse throughout a codebase than <PrismicText> since you must read both <PrismicRichText> and format="text" to understand it is rendering a string. It also complicates the <PrismicRichText> component; it is now handling two different use cases.

Additional context
Slice Machine was providing a helpful, but incorrect, snippet for Key Text fields. It told developers to use <PrismicText> rather than using the field's value directly. While there could be a number of reasons for the error, the root problem was clear: <PrismicText>'s purpose is ambiguous.

Awesome! I'd be for letting it fail and logging a prismic.dev message when field is of type string :)

Implemented in #152.


reconfiguring search definitions

@drkane if you check the branch at https://github.com/NICVA/find-that-charity/tree/es_query_yaml I've made a couple of changes that might make ongoing maintenance easier. Let me know if you like the look of it and I'll merge it into NICVA/master and submit a PR.

Reconfigured the ES search query json so that it is defined in it's own yaml file es_config.yaml which will be read in to the server command and converted to the json string. I find yaml easier to read and adapt than a json string, so good for ongoing development.
Added the CCEW, CCNI and OSCR charity number fields to the search query (see these lines). Means that a user can enter a known charity number in the search box and get a match.
Separated the ES search json for reconcile service, as it's likely that this will take different arguments than the web service version (e.g. names only). As with the above it's defined in its own yaml file recon_config.yml, and it's used in /reconcile GET and POST now instead of the previous search query.

Looks great - happy for a PR, you're right that YAML is a lot more readable that JSON for editing.


6.4.x Branch selector fix

Bug 1313094 - If one user changes a branch, the branch is changed for all the users
Bug 1313095 - Repository listing and File explorer in Adminstration perspective were often out of sync

(cherry picked from commit f5d03019ce516141d8f1604060333017a1daea85)
https://github.com/droolsjbpm/guvnor/pull/271
https://github.com/droolsjbpm/kie-wb-common/pull/284
https://github.com/droolsjbpm/drools-wb/pull/136
https://github.com/droolsjbpm/jbpm-console-ng/pull/350
https://github.com/droolsjbpm/jbpm-designer/pull/171
https://github.com/droolsjbpm/jbpm-form-modeler/pull/41
https://github.com/droolsjbpm/optaplanner-wb/pull/41
https://github.com/droolsjbpm/kie-wb-distributions/pull/217

6.4.x: 4886d49e95c6c98d57f98587d3311e96cf2345c3


Download Pages Not Found

It seems like none of the release assets can be found on the Download page. I've tried clicking the links for multiple versions and they all return this page...

Thanks for the notice, looks like my web host had an upgrade yesterday and some Python modules broke. Should be fixed now.

Yup- it's resolved now. Thanks!


Update autorest version to prerelease

Triggered from branch: main

API change check
APIView has identified API level changes in this PR and created following API reviews.
com.azure:azure-ai-documentintelligence


Release new version

Heya, please could we get a new release with:

https://github.com/mitchmindtree/daggy/pull/33

It would also contain the fix for https://github.com/mitchmindtree/daggy/issues/28
Thank you

Heya @mitchmindtree, please could we get #33 merged and subsequently a release?
Thanks :bow:

Thanks! and shall copy this here for reference:

For future reference, if anyone's after a new version, feel free to open a PR with a version bump > - I've think I've setup this repo to auto-publish :)

@mitchmindtree ah, it doesn't have auto publish set up :stuck_out_tongue: needs a cargo publish

Ah thanks for the heads up, looks like the repo still had an old revoked key from the days before that old crates.io breach https://github.com/mitchmindtree/daggy/runs/4054053704?check_suite_focus=true#step:4:26.
Should be fixed now :+1:


add saga annotation samples

add saga annotation local service sample

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

Please see https://github.com/seata/seata/pull/5300


Update _config.yml

Sorry, I performed this operation incorrectly

It looks like you are attempting to push a change to the template repository, for help with deploying your own website please start a new thread in the discussions.


Write the Docs 2015

I'm not sure it's directly Python-related but this repo already has 2013, 2014 and 2016 editions.

Schedule: http://www.writethedocs.org/conf/na/2015/schedule/
Playlist: https://www.youtube.com/playlist?list=PLmV2D6sIiX3UW1kPWlhzyo4lr6e3US6re

I'm at the PyCon sprints right now. I'll take this one.

See https://github.com/pyvideo/data/pull/262
Thank you @thejessleigh !
Closing.


Implement json functions

What type of PR is this：

[ ] bug
[x] feature
[ ] enhancement
[ ] others

Summary

Supported json functions: parse_json, json_query, json_exists, json_object, json_array

The overall implementation LGTM, but the function detail still need other people review.


Add Tests for Execute Command Functions

Purpose

Add the test cases for the Execute command functionality along with Test Utility refactor

LGTM
Reg the text : @since v0.982.0
-we don't use "v"
-also there should be new line after calls description before the version tag

Fixed the version doc comment with #10162


Added paperfig command (A BUG)

If an existing figure in the paper directory is not in the result directory, the command is just going to skip it?

Yes
On Dec 16, 2015 3:41 PM, "changsiyao"<EMAIL_ADDRESS>wrote:

If an existing figure in the paper directory is not in the result
directory, the command is just going to skip it?
—
Reply to this email directly or view it on GitHub
https://github.com/berkeley-stat159/project-theta/pull/160#issuecomment-165286193
.

And travis fails? should we ignore?

Good to go

great！

Should probably make a note to ross that we added the paperfig command
because he already ran the make all and it will fail
On Wed, Dec 16, 2015 at 4:28 PM, changsiyao<EMAIL_ADDRESS>wrote:

Merged #160 https://github.com/berkeley-stat159/project-theta/pull/160.
—
Reply to this email directly or view it on GitHub
https://github.com/berkeley-stat159/project-theta/pull/160#event-494159489
.


Change peerDep to ^ form. Update contributors

Update contributors as done for linkedin-dustjs repo.  Change the recently added peerDependency to use the ^ semver form. The ~ form causes other peerDependency issues with other modules using ^2.4.0 for dustjs-linkedin peer dependencies.

Because we've moved to explicitly supporting N+1 Dust (e.g. helpers 1.5 supports dustjs-linkedin: "2.5 - 2.6" only) we can't use carats.


NodeJS: Fix batching createByteLengthFunction

Codecov Report

Merging #1625 into master will not change coverage.
The diff coverage is 100%.

@@            Coverage Diff            @@
##             master    #1625   +/-   ##
=========================================
  Coverage     86.86%   86.86%
  Complexity     4187     4187
=========================================
  Files           408      408
  Lines         16802    16802
  Branches       1803     1803
=========================================
  Hits          14595    14595
  Misses         1709     1709
  Partials        498      498

Impacted Files
Coverage Δ
Complexity Δ

...codegen/transformer/nodejs/NodeJSSurfaceNamer.java
91.47% <100%> (ø)
74 <0> (ø)
:arrow_down:

Continue to review full report at Codecov.

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


Improve client component discovery

Description
In Hydrogen, the client components are only imported in the server App, but not in the client. This means that the browser build cannot discover client components automatically and emit chunks to download them later on demand.
To work around that, we were using Vite's import.meta.glob('..../**/*.client.jsx') for discovering all the client components in the working dir during browser build.
This worked and helped us move fast but it brings some problems:

Can only check known paths such as src or node_modules/@shopify/hydrogen/dist. Importing from 3p libs would need to provide a new path manually.
It creates references to all the client components matched by the glob, not only the ones that are actually used. This means it emits extra chunks that are never used, and adds some weight to the client bundle with references that are never used.

This PR improves the client component discovery strategy to only use those components that are imported by the server App. In dev, it simply uses the server entry to find them. During client build, it spins up a secondary Vite server and find them  (Viteception 🤯 ).

[x] Discover components in dev.
[x] HMR during dev for new client components added to the file system.
[x] Discover components in client build (adds 1.5s to the client build).

Due to #1071 , this might still be finding some unused components but it's at least a good step.
This PR needs to be merged to v1 branch once #1065 is merged

Before submitting the PR, please make sure you do the following:

[x] Read the Contributing Guidelines
[x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123)
[x] Update docs in this repository according to your change
[ ] Run yarn changeset add if this PR cause a version bump based on Keep a Changelog and adheres to Semantic Versioning

Continues in #1247


⚠ Samsung has degraded performance

In e9c7e15, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 2588 ms

Resolved: Samsung performance has improved in a9dee12.


Missing 1.0.1 changelog

Howdy,
Just noticed that there's no CHANGELOG entry for 1.0.1.

Good catch, I'll try to sort it out later in the weekend

fixed in latest


Proper handling of random state for models that use randomness (i.e. dropout) is needed for some optimizers

There are a number of optimization methods that require you to be able to evaluate a pure function over and over at different inputs (parameters to optimize over) but there is one common pitfall when using them, namely that if the model or loss function uses randomness then you have to be able to call it with the same randomness over and over, for instance, the same features dropped out. Using different randomness will break most common line search algorithms, for instance, pretty easily. Currently the way I would have to do this is manually fork the RNG, even with functorch. A good way to manage random state/wrap forking the RNG into a pure function that takes a seed as one of it arguments/some such thing would be much appreciated!
Thank you,
Katherine Crowson

Hi @crowsonkb! Thanks for the issue! In an attempt to delay some heavy duty refactors to the underlying PyTorch, we've been working on adding a flag version of this (i.e. vmap(...., different_randomess=False) with the name being up for discussion). I'd been trying to wait until everything is ready to go to put up the diffs but now I'll put up what I have so far since the remaining operations are just distributions.
One question for you: Do you have cases where within the same vmap call you sometimes want the same randomness and sometimes want the different randomness behavior? As a concrete example, would there be a case where during a single run of vmap you would want some dropouts to use the same randomness and others not to? If there is the flag version won't be able to solve this, so this will help us reprioritize!

I wouldn't actually be using vmap for this specific thing, I think. It would be a normal evaluation of a model with a normal batch dimension, I just have to use the same randomness on subsequent calls (not done at the same time, for instance an iterative line search with a termination criterion). I can't think of anything offhand where I would want to repeat some but not all randomness in a vmap but I'm sure I would run into it at some point...

Thanks for that context! To unblock you if you aren't using vmap, does it work to reset the manual seed? If not, I would be curious why it's not working

Hi @crowsonkb! Just waned to let you know that "different" and "same" randomness are supported in vmap in our 0.1 release that came out alongside PyTorch 1.11. More documentation here, sorry it's on nightly but is definitely in 1.11
If you have a chance to play around with it, any feedback is really appreciated as we're solidifying our APIs and trying to understand what use cases this covers and does not cover


Remove development files from NPM package

Some of the files that end up in node_modules/bonjour-service are not needed at runtime, so they can be omitted from the package.
Whether to omit examples is a bit debatable: users that use bonjour-service directly probably would like them, but when bonjour-service is installed as a subdependency it will just be a waste of bytes.
Thanks for your consideration!

@jorrit Agreed. Many thanks


Component retains old event listener after its content changes

I have the following component with a  span that should only call unclick when it's clicked but calls click and unclick.
function component() {
  if (...) {
    return

        Click me
      </div

  }

  return

      Unclick

}

Here is a running example:
https://codepen.io/v4n/pen/bgQNGW?editors=0010

Mithril redraws after the unclick function runs because of the m.mount, and it seems like that happens faster than the event can bubble. I verified in the chrome debugger that there's no stale click handler on the .unclick-me element, just on the .

Stopping event propagation in the unclick handler will also prevent the click handler from being re-triggered.

Here's a smaller repro: https://jsbin.com/nesehey/3/edit?js,output

Another argument for #1592
Conspiracy theory: I'm starting to think @lhorie is actually a secret Zalgo priest, luring unsuspecting coders to feed his master. The Zalgo article was mentioned in #1, and Leo is usually convinced by rational arguments, yet, maybe-sync redraws are still there, justified as an optimization, and calls for always async are ignored...
Sync redraws wins at best 16 ms, 8 on average on platforms that support rAF... Changes that happen within 100ms are percieved as instantaneous... Incorrect code is infinitely slower, anyway.

https://codepen.io/ilsenem/pen/JEeYzx?editors=0010
This behavior is not the case in v0.2.5 with the same code base.
It may be fast redraw as @tivac mentioned.

@pygy

Conspiracy theory: I'm starting to think @lhorie is actually a secret Zalgo priest [...]

He must've been teaming up with this guy at one point! :laughing:

In reality, I think it took the monster of 0.2 for him to start becoming a little more conservative when it comes to architecting the code. That old code base was almost the epitome of Zalgo. There was enough spaghetti logic to make improvement nearly impossible without breaking everything, over and over and over. (And this is why it wound up with a full revert - it was a read-only code base, where only the slightest change in seemingly unrelated areas caused an entire mountain to topple.)

As for the current rewrite, I just haven't had the chance to take a decent look at it for performance tweaks.

@isiahmeadows this particular variant of Zalgo results from a consumer API contract that occasionally deviates from otherwise predictable resolution expectations - specifically: mostly asynchronous but sometimes synchronous. Like the unreliable attempt by m.request to delay redraw until all derivative thens have resolved, the 'occasionally sync' redraw is a whimsical feature with no use case, no documentation, and the potential to create incredibly confusing and difficult to debug expectation shortfalls.

I'd say that here, Mithril unleashes Zalgo on itself by calling said public API in the event handler...
A cheap "fix" would be to setTimeout(m.redraw) in the event handler wrapper...

@pygy based on your early comment, I'm assuming https://github.com/lhorie/mithril.js/pull/1592 would fix this bug?
@isiahmeadows @tivac mind adding a bug label to this if you guys agree it's?

@v4n it would, but I'd rather have #1643 merged first. Both PRs modify the tests in a way that causes conflicts and #1592 will be easier to rework than #1643. Adding a node there...

@v4n if this is blocking you, you can add
e.redraw = false
setTimeout(m.redraw)

to the problematic handlers
Live: https://codepen.io/anon/pen/EZqrMQ?editors=0010

Found the culprit: this branch should have an else.

@isiahmeadows isn't covered here?

No, but my initial suspicion is wrong.

The problem is that the inexistence isn't being handled correctly.

Another suspect: this function should clean up removed attributes as well.

It's not a 1.1 blocker, though (although it still repros).

Closing in favor of #1804.


Set battery_max_charge_current based on a template value

Existing sensor definitions can be found here
Sunsynk
Details about your Inverter: 8 kw
Describe the issue/bug and what you expect
I'd like to set the based on the following template value battery_max_charge_current, so that during the 6 hour charge window the rate of charge is set based on the remaining battery level.
{{ (((100 - (states('sensor.sunsynk_battery_soc') | float))/100 * 9.2)/6*1000/48) | round }}
It looks like this is currently only set using a fixed number?
Logs (if applicable)

paste logs in 3x backticks...

You can do this with an automation
make the automation to trigger every x minutes and then set the value based on the template


fix: turn JSON RPC request body ID to pointer

Description
JSON RPC requests can omit the ID field to signal that the request is a notification: https://www.jsonrpc.org/specification#notification. These notification requests are not expected to have a response.
The SingleRequestBody model in the jsonrpc module uses the omitempty tag on the ID field.  The default "zero" value for an int64 in Golang is zero.  This means that any JSONRPC requests with ID of zero will not have the ID field present.  This causes the request to look like a notification, and the resulting response will have content-length of zero as well.
The graph-node uses a library called rust-web3 to make the JSONRPC requests to node providers.  This library ends up making requests that have ID set to 0 in the request.  When pointed to the node-gateway, the request hits the bug explained above and the response body is empty. The graph-node is not able to deserialize the empty response body correctly and we see the error: failed to deserialize response: data did not match any variant of untagged enum Output.  Interally, graph-node uses a model named Output to deserialize the JSONRPC response, hence why untagged enum Output shows up in the error.
To prevent this, we can use a pointer for the ID field in the request model.  This prevents omitempty from removing the ID field when it is zero.  This approach is more favorable because we do not have control over the JSONRPC ID used in graph-node.
Fixed the tests to reflect the new field type.  Changed the SingleResponseBody ID to also be int64 to be more consistent.  A valid JSONRPC response will never have ID not set, so it is OK to not have it as a pointer.
Type of change

[x] 🐛 Bug fix (non-breaking change which fixes an issue)
[ ] 😎 New feature (non-breaking change which adds functionality)
[ ] ⁉ Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] ⚒ Refactor (no functional changes)
[ ] 📖 Documentation (updating or adding docs)

How Has This Been Tested?
Ran node-gateway locally and made requests with ID set to 0.  After the fix, we get a proper response:
curl -v "localhost:8080/mainnet" \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{"method":"eth_getTransactionReceipt","params":["0xa7f0de85ac222baecfd6bd9e074c350347fceb368a925f82be2e92bc83ae9d3f"],"id":0,"jsonrpc":"2.0"}'
...
{"result":{"blockHash":"0x8f33faf77241a3e43ac014021b583dd5b1f6fed8c67b42bbf3ddd793ca4f56d2","blockNumber":"0xf55595","contractAddress":null,"cumulativeGasUsed":"0x3c4cca","effectiveGasPrice":"0x2eb3b65c8","from":"0x06082441dbc4f3dedec7e5c53507c28bde682dd7","gasUsed":"0x144cf","logs":[{"address":"0x4ed9c0dca0479bc64d8f4eb3007126d5791f7851","blockHash":"0x8f33faf77241a3e43ac014021b583dd5b1f6fed8c67b42bbf3ddd793ca4f56d2","blockNumber":"0xf55595","data":"0x000000000000000000000000000000000000000009157bc2e79f571c58c76ee3","logIndex":"0x7d","removed":false,"topics":["0x9e2c1201748a5c10b659169e27843c246931edf32ccc126c79505db2352fbc3b"],"transactionHash":"0xa7f0de85ac222baecfd6bd9e074c350347fceb368a925f82be2e92bc83ae9d3f","transactionIndex":"0x21"},{"address":"0xcc88a9d330da1133df3a7bd823b95e52511a6962","blockHash":"0x8f33faf77241a3e43ac014021b583dd5b1f6fed8c67b42bbf3ddd793ca4f56d2","blockNumber":"0xf55595","data":"0x4554482d41000000000000000000000000000000000000000000000000000000736166657479507269636500000000000000000000000000000000000000000000000000000000000000000000000000000000040d79a314623f673578189a70","logIndex":"0x7e","removed":false,
...

Side note for future discussion: any good JSONRPC clients we could use to avoid these types of bugs?


Updating manage to work with docker v2 and tweak to docker-compose.yml

Signed-off-by: Stephen Curran<EMAIL_ADDRESS>

@ianco -- can you please take a look at this one?  Particularly the docker-compose.yml change to do with the ports. I don't know why there are two Env variables associated with the ports -- one with _EXPOSED. Not sure which should be used when only one is permitted.
Arrggh...I merged this without getting an approval. There is no branch protection for that.  I guess I will fix that next.
Thanks!


Fixed #31234 - Increase entropy in make_msgid().

https://code.djangoproject.com/ticket/31234

This change won't be accepted as per my comment.

@pope1ni fair enough, I had made the assumption that a collision of message-ids would be a security concern, but after looking at https://tools.ietf.org/html/rfc2822#section-3.6.4 more closely, it might be a stretch to make that case.

Closing per ticket.