Openstack validation fails with "Unknown" error

Hi there,
I'm currently trying to deploy Cloud Foundry upon Devstack. The CF docs recommend to do an automated verification of the Openstack/Devstack instance in use by means of the cf-openstack-validator project which in turn uses the Bosh Openstack CPI. The verification fails with the following error:
External CPI sending request:
{
   "method":"create_stemcell",
   "arguments":[
      "/opt/stack/.cf-openstack-validator/stemcell/image",
      {
         "name":"bosh-openstack-kvm-ubuntu-trusty-go_agent",
         "version":"3468.1",
         "infrastructure":"openstack",
         "hypervisor":"kvm",
         "disk":3072,
         "disk_format":"qcow2",
         "container_format":"bare",
         "os_type":"linux",
         "os_distro":"ubuntu",
         "architecture":"x86_64",
         "auto_disk_config":true
      }
   ],
   "context":{
      "director_uuid":"validator",
      "request_id":"218563"
   }
}
with command: /opt/stack/.cf-openstack-validator/cpi

External CPI got response:
excon.error {:error=>#<Excon::Error::Found: Expected([200, 204, 300]) <=> Actual(302 Found)
excon.error.response
  :body          => "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n\n<title>302 Found</title>\n\n
Found
\n
The document has moved <a href=\"http://<IP_ADDRESS>/dashboard/\">here.
\n
\n<address>Apache/2.4.18 (Ubuntu) Server at <IP_ADDRESS> Port 80</address>\n\n"
  :cookies       => [
  ]
  :headers       => {
    "Connection"     => "close"
    "Content-Length" => "294"
    "Content-Type"   => "text/html; charset=iso-8859-1"
    "Date"           => "Wed, 22 Nov 2017 15:24:09 GMT"
    "Location"       => "http://<IP_ADDRESS>/dashboard/"
    "Server"         => "Apache/2.4.18 (Ubuntu)"
  }
  :host          => "<IP_ADDRESS>"
  :local_address => "<IP_ADDRESS>"
  :local_port    => 53022
  :path          => "/"
  :port          => 80
  :reason_phrase => "Found"
  :remote_ip     => "<IP_ADDRESS>"
  :status        => 302
  :status_line   => "HTTP/1.1 302 Found\r\n"
>}

So it looks like there're some problems dealing with the redirect to /dashboard.

My validator.yml:
---
openstack:
  auth_url: http://<IP_ADDRESS>/identity/v3 # Keystone V3 URL
  username: admin # String
  password: secret # String
  domain: default # String
  project: demo # String
  default_key_name: cf-validator # String
  default_security_groups: [default,cf-validator] # List of String
  boot_from_volume: false # Boolean
  config_drive: ~ # One of cdrom, disk, or nil
  connection_options: # all connection options that are supported by Excon
    ssl_verify_peer: false # Boolean
    # ca_cert: <replace-me> # Multiline yaml String containing certificate chain

validator:
  use_external_ip: true # Defines from where the Validator is executed. False means from inside your OpenStack.
  network_id: 641d1f8e-a83e-4ddb-a21f-c6b1b79c3154 # String UUID
  floating_ip: <IP_ADDRESS> # String IP
  static_ip: <IP_ADDRESS> # String IP. This IP is used to create a VM with a static IP.
  private_key_path: cf-validator.rsa_id # relative to validator.yml, or absolute path
  public_image_id: a3b4c230-1017-480a-92ca-3c604c5b0343 # String UUID
  ntp: [0.pool.ntp.org, 1.pool.ntp.org] # List of String
  mtu_size: 1500 # expected network MTU size in byte
  releases:
  - name: bosh-openstack-cpi
    url: https://bosh.io/d/github.com/cloudfoundry-incubator/bosh-openstack-cpi-release?v=33
    sha1: 86b8eedcb0a6be3e821a5d0042916180706262be

cloud_config:
  vm_types: # See https://bosh.io/docs/cloud-config.html#vm-types
  - name: default # Don't change this name
    cloud_properties:
      instance_type: m1.small # String
      # availability_zone: <replace-me> # String
      # root_disk: {size: 20} # Integer, size in GiB. Used together with openstack.boot_from_volume.

extensions:
  paths: [] # paths pointing to a directory. Absolute or relative to this config file.
  config: {} # everything below 'config' is available in tests as `Validator::Api.configuration.extensions` inside your test code

Versions in use:

Openstack-Validator: 2.4.0
Bosh CPI: v35 (latest release)
Devstack Pike

Hey @apophis90
currently only CPI version 35 works with OpenStack pike, see release notes: https://github.com/cloudfoundry-incubator/bosh-openstack-cpi-release/releases/tag/v35
Please update to cf-openstack-validator version 2.5.0, which also updates the used CPI to v35.
Let me know if that fixes your issue or you have additional problems with validating pike!

Hi @voelzmo ,
Yep, I already got this from the CPI release notes before. For the results I've shown above I built the CPI v35 on my own and passed it via the --cpi-release flag when starting the validator. Nevertheless, I'll give the 2.5.0 validator release a try tomorrow.

@voelzmo first thx for moving my attention towards the latest validator release, there're indeed some new insights I found while trying it.
First, the error I originally reported above actually went away after having upgraded to validator 2.5.0. However, another error appeared instead. The test case checking the OpenStack API limit fails with the following message:
1) Your OpenStack API rate limit is high enough
     Failure/Error: flavor = Validator::Api::FogOpenStack.compute.flavors.find { |f| f.name == flavor_name }

     Fog::Compute::OpenStack::NotFound:
       Expected([200, 203]) <=> Actual(404 Not Found)
       excon.error.response
         :body          => "{\"itemNotFound\": {\"message\": \"Flavour detail.json could not be found.\", \"code\": 404}}"
         :cookies       => [
         ]
         :headers       => {
           "Connection"                   => "close"
           "Content-Length"               => "85"
           "Content-Type"                 => "application/json; charset=UTF-8"
           "Date"                         => "Mon, 27 Nov 2017 12:10:43 GMT"
           "OpenStack-API-Version"        => "compute 2.1"
           "Server"                       => "Apache/2.4.18 (Ubuntu)"
           "Vary"                         => "OpenStack-API-Version,X-OpenStack-Nova-API-Version"
           "X-OpenStack-Nova-API-Version" => "2.1"
           "x-compute-request-id"         => "req-5ed09e78-fb66-44c0-ba09-e6af19ae99af"
           "x-openstack-request-id"       => "req-5ed09e78-fb66-44c0-ba09-e6af19ae99af"
         }
         :host          => "<IP_ADDRESS>"
         :local_address => "<IP_ADDRESS>"
         :local_port    => 56748
         :path          => "/compute/v2.1/flavors/detail.json"
         :port          => 80
         :reason_phrase => "Not Found"
         :remote_ip     => "<IP_ADDRESS>"
         :status        => 404
         :status_line   => "HTTP/1.1 404 Not Found\r\n"

Further investigation revealed that a PR targeting this had already been merged to the fog-openstack project prior to the fog-openstack 0.1.22 release.
Consequently, since the 2.5.0 validator release still relies on fog-openstack 0.1.19 according to the Gemfile, it seemed logical to me updating this dependency to 0.1.22 and re-run the tests to see what would happen. Indeed, the details.json error disappeared but I was brought back to the original redirect error:
2) Your OpenStack using the CPI against OpenStack can save a stemcell
     Failure/Error: fail("#{error_message} OpenStack error: #{e.message}")

     RuntimeError:
       Stemcell could not be uploaded OpenStack error: Expected([200, 204, 300]) <=> Actual(302 Found)
       excon.error.response
         :body          => "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n\n<title>302 Found</title>\n\n
Found
\n
The document has moved <a href=\"h
ttp://<IP_ADDRESS>/dashboard/\">here.
\n
\n<address>Apache/2.4.18 (Ubuntu) Server at <IP_ADDRESS> Port 80</address>\n\n"
         :cookies       => [
         ]
         :headers       => {
           "Connection"     => "close"
           "Content-Length" => "294"
           "Content-Type"   => "text/html; charset=iso-8859-1"
           "Date"           => "Mon, 27 Nov 2017 12:29:08 GMT"
           "Location"       => "http://<IP_ADDRESS>/dashboard/"
           "Server"         => "Apache/2.4.18 (Ubuntu)"
         }
         :host          => "<IP_ADDRESS>"
         :local_address => "<IP_ADDRESS>"
         :local_port    => 58666
         :path          => "/"
         :port          => 80
         :reason_phrase => "Found"
         :remote_ip     => "<IP_ADDRESS>"
         :status        => 302
         :status_line   => "HTTP/1.1 302 Found\r\n"

In both cases CPI version 35 has been used. I also made sure that my DevStack version is actually Pike:
$ nova-manage version
16.0.4

What do you think?

Good point, we also have a few calls done by pure fog, not just our openstack-cpi. Therefore, we also need to bump the fog-openstack version in the validator in order to run it against pike. I've put a story in our backlog to fix this: https://www.pivotaltracker.com/story/show/153285081

For reference: the redirection to /dashboard might have similar reasons as in https://github.com/fog/fog-openstack/issues/362


clusterIP: "" should not be generated in services

@aledbf asked me to create this ticket. - https://github.com/kubernetes/ingress-nginx/issues/1612
It seems that clusterIP: "" is an internally generated, immutable value.

I have the same issue. It's impossible to just upgrade nginx-ingress chart. I always have to delete and create new one. Please /reopen ;)

Same here

/reopen

Interestingly, when upgrading I get the error message Error: UPGRADE FAILED: Service "killer-gnat-nginx-ingress-controller" is invalid: spec.clusterIP: Invalid value: "": field is immutable. However, in the service ...-nginx-ingress-controller, spec.clusterIP is not rendered at all, as visible via helm template. It is specified in the service  ...-nginx-ingress-default-backend, which doesn't give an error. I just adapted the chart to remove it from the default backend as well and now helm upgrade complains about both services.

yes, I just confirmed: When I remove this check, then the empty clusterIP is rendered into the service and the upgrade completes. This contradicts the error message... Also, I'm not sure wheter the check still should be there and maybe check for nil.

Confirmed that I'm seeing that same issue. Reverting to 0.30.0 chart version fixes this issue for me.

Same problem here.


[SPARK-16216][SQL][FOLLOWUP] Enable timestamp type tests for JSON and verify all unsupported types in CSV

What changes were proposed in this pull request?
This PR enables the tests for TimestampType for JSON and unifies the logics for verifying schema when writing in CSV.
In more details, this PR,

Enables the tests for TimestampType for JSON and
This was disabled due to an issue in DatatypeConverter.parseDateTime which parses dates incorrectly, for example as below:
 val d = javax.xml.bind.DatatypeConverter.parseDateTime("0900-01-01T00:00:00.000").getTime
println(d.toString)

Fri Dec 28 00:00:00 KST 899

However, since we use FastDateFormat, it seems we are safe now.
val d = FastDateFormat.getInstance("yyyy-MM-dd'T'HH:mm:ss.SSS").parse("0900-01-01T00:00:00.000")
println(d)

Tue Jan 01 00:00:00 PST 900

Verifies all unsupported types in CSV
There is a separate logics to verify the schemas in CSVFileFormat. This is actually not quite correct enough because we don't support NullType and CalanderIntervalType as well StructType, ArrayType, MapType. So, this PR adds both types.

How was this patch tested?
Tests in JsonHadoopFsRelation and CSVSuite

Test build #64468 has started for PR 14829 at commit 0f83127.

Thank you for your review @hvanhovell I will quickly address your comments.

Test build #64472 has started for PR 14829 at commit 831268d.

Test build #64468 has finished for PR 14829 at commit 0f83127.

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

Merged build finished. Test PASSed.

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

Test build #64479 has started for PR 14829 at commit 948b456.

Test build #64482 has started for PR 14829 at commit 1baacf2.

Test build #64472 has finished for PR 14829 at commit 831268d.

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

Merged build finished. Test PASSed.

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

(@hvanhovell I don't mind to leave only enabling the test except for other changes if you feel not too sure of the other changes as it seems it ended up with a different issue anyway.)

@HyukjinKwon this is fine. It is a closely related issue.
LGTM - pending jenkins.

Thank you very much for your close look.

Test build #64479 has finished for PR 14829 at commit 948b456.

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

Merged build finished. Test PASSed.

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

LGTM - merging to master. Thanks!

@HyukjinKwon should this be backported? If it does, could you reopen it for 2.0?

Test build #64482 has finished for PR 14829 at commit 1baacf2.

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

Merged build finished. Test PASSed.

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

Yes, I will. Thanks


Update nightly-version file

The nightly-version file is 3 months old. We don't really have an update policy but it seems like 3 months is old enough.
Grab the current version from rust-bitcoin.

Nice, thanks! Yeah, we should update as often as we're willing to tolerate.


Look for test vectors for any of our crypto primitives

Look up standardization efforts, published papers, and other implementations to find any kind of public test vectors for

Pedersen commitments
PS signatures
PS blinded signatures

Closing as too vague.


[fix](runtime filter) Avoid to use  ignored runtime filter (#44708)

Filter size should be set by a global size instead of a local size. This behaviour is introduced by #43885 .
What problem does this PR solve?
pick #44708
Release note
None
Check List (For Author)

Test

[ ] Regression test
[ ] Unit Test
[ ] Manual test (add detailed scripts or steps below)
[ ] No need to test or manual test. Explain why:

[ ] This is a refactor/code format and no logic has been changed.
[ ] Previous test can cover this change.
[ ] No code files have been changed.
[ ] Other reason

Behavior changed:

[ ] No.
[ ] Yes.

Does this need documentation?

[ ] No.
[ ] Yes.

Check List (For Reviewer who merge this PR)

[ ] Confirm the release note
[ ] Confirm test cases
[ ] Confirm document
[ ] Add branch pick label

run buildall


Reduce report generation time

Report generation (with precalculated data) takes typically anything from several minutes up to several hours. It looks a bit unrealistic for a simple rendering task. There have to be some bottlenecks.
Below is a sample, profiling log for the PDBDEV_00000004
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
   1762/1    0.020    0.000  103.081  103.081 {built-in method builtins.exec}
        1    0.005    0.005  103.081  103.081 Execute.py:7(<module>)
        2    0.000    0.000   51.620   25.810 api.py:30(from_file)
        2    0.000    0.000   51.602   25.801 pdfkit.py:160(to_pdf)
        4    0.000    0.000   51.590   12.898 subprocess.py:1090(communicate)
        2    0.000    0.000   51.589   25.794 subprocess.py:1926(_communicate)
      195   51.588    0.265   51.588    0.265 {method 'poll' of 'select.poll' objects}
        2    0.000    0.000   51.587   25.794 selectors.py:403(select)
        1    0.000    0.000   51.281   51.281 Execute.py:157(write_pdf)
        1    0.003    0.003   23.990   23.990 Report.py:117(run_model_quality)
       20    0.310    0.015   23.882    1.194 utility.py:16(dict_to_JSlist)
    31841   23.570    0.001   23.570    0.001 utility.py:40(<listcomp>)
      220    0.003    0.000   18.939    0.086 connectionpool.py:518(urlopen)
      220    0.002    0.000   18.899    0.086 connectionpool.py:357(_make_request)
        1    0.000    0.000   17.385   17.385 Report.py:348(run_sas_validation_plots)
      429    0.001    0.000   14.035    0.033 socket.py:690(readinto)
      220    0.001    0.000   13.262    0.060 client.py:1327(getresponse)
      220    0.001    0.000   13.259    0.060 client.py:312(begin)
      220    0.001    0.000   13.235    0.060 client.py:279(_read_status)
     1457    0.001    0.000   13.234    0.009 {method 'readline' of '_io.BufferedReader' objects}
      193    0.001    0.000   10.929    0.057 webdriver.py:404(execute)
      193    0.001    0.000   10.925    0.057 remote_connection.py:402(execute)
      193    0.002    0.000   10.922    0.057 remote_connection.py:423(_request)
      193    0.000    0.000   10.903    0.056 request.py:58(request)
      193    0.001    0.000   10.902    0.056 poolmanager.py:352(urlopen)
      242   10.803    0.045   10.803    0.045 {method 'recv_into' of '_socket.socket' objects}
      181    0.000    0.000   10.062    0.056 request.py:98(request_encode_body)

After a brief analysis of the calls and code I identified several bottlenecks:

wkhtmltopdf calls.

        2    0.000    0.000   51.602   25.801 pdfkit.py:160(to_pdf)
        4    0.000    0.000   51.590   12.898 subprocess.py:1090(communicate)
        2    0.000    0.000   51.589   25.794 subprocess.py:1926(_communicate)

utility.dict_to_JSlist

       20    0.310    0.015   23.882    1.194 utility.py:16(dict_to_JSlist)

3. various get requests

  220    0.003    0.000   18.939    0.086 connectionpool.py:518(urlopen)
  220    0.002    0.000   18.899    0.086 connectionpool.py:357(_make_request)

Let this issue be an umbrella issue. I'll open separate issues for individual bottlenecks.

all of the aforementioned issues were addressed and merged.


[Bug]: TypeError: Cannot read property 'coverageConfig' of undefined

Hi Guys.
So I'm having an issue, when my specs takes a little longer and I has able to reproduce the error in this clean repository.
https://github.com/CarlosSoares/jest-coverage-issue
For some reason the global is lost when it takes to long to run?

It's actually because of this : https://github.com/kulshekhar/ts-jest#usage

If you're experiencing remapping failure with source lookup, it may due to pre-created cache from jest. It can be manually deleted, or execute with --no-cache to not use those.

This is due to behavior of jest itself that coverage processor cannot overcome at this moment. Basically, jest caches compiled file into its own cache storage, then reuse it unless code actually changes. in result, preprocessor won't be invoked for subsequent run without code change - coverage processor can't lookup global cache from preprocessor.
Jest does not exposes way to access internal cache to any pre/postprocessors, so currently recommended way is run via --no-cache or manually remove cache as needed. I'm trying to find way to create upstream changes for this, but haven't able to start yet.

But even with jest --config=jest.config.json --coverage --no-cache doesn't works.

Solved by this commit: https://github.com/kulshekhar/ts-jest/commit/6eb092a0b60d2097d3d1bcafb24b041718f2e8f0
Please wait for next release in day or two.

Unfortunately now won't generate the coverage.

After a lot of investigation done for this issue - I can say that it doesn't seem to be a problem of ts-jest.
At first I thought that problem caused by async tests, but it's not a case. I've even added tests for this case https://github.com/kulshekhar/ts-jest/commit/f8e6f9be4f65bc3a1c33930af99453f03a622b6b.
Then I checked enzyme package, because it manipulates global object, but it's not a case too.
So this problem could be only with Jest's cache.
Just try to reinstall node_modules and always use coverageprocessor with --no-cache option.
If it won't help, try to invalidate cache by running tests with changed source and --no-cache flag.
And last, remapped coverage could appear in ./coverage/remapped instead of ./coverage.


add QuantileSketch.zero() so memory allocated by sketch can be reused

What does this PR do?
Makes it possible to clear a sketch, so that it behaves as if it's empty, but can hang on to allocated memory.
Motivation
We report latencies in epochs, and don't want recorded values to bleed between epochs. Currently this requires allocating a new sketch, but we would like to reuse the sketch since it will probably be able to reuse the allocated memory.
Additional Notes
Anything else we should know when reviewing?

I wonder if we really want to copy the full arrays when copying stores that have been previously cleared. We should probably allocate just what's necessary. What do you think?

Done.


VM.block and VM.state_db can easily get out of sync

What is wrong?
Having VM.state_db and VM.block is error prone as we need to ensure they're in sync, which is done by assigning VM.state_db.root_hash to VM.block.header.state_root whenever we update the state.
How can it be fixed
We could have the state DB as a property on the Block class, with all state-related functionality wrapped in Block methods, thus completely abstracting the State DB (and the need to keep it in sync with the block) from external code

Looks like my email reply didn't make it in.
So one of my pet-peeves of the pyethereum codebase was that the block object had a ton of business logic baked into it.  I'd like to avoid that if at all possible and try to keep the RLP objects well isolated.
This gets me thinking of alternate ways to solve the same problem and it strikes me as similar to the problem of forgetting to close a file or database connection after opening it.  This gets me thinking about whether there is a context manager style API that would provide an elegant way to solve this so that we not longer have to remember to update the header.state_root.
Looking at where vm.state_db is accessed yields this:
evm/vm/computation.py:        return self.vm.state_db
evm/vm/flavors/frontier/__init__.py:    sender_balance = vm.state_db.get_balance(transaction.sender)
evm/vm/flavors/frontier/__init__.py:    vm.state_db.set_balance(transaction.sender, sender_balance - gas_cost)
evm/vm/flavors/frontier/__init__.py:    vm.state_db.increment_nonce(transaction.sender)
evm/vm/flavors/frontier/__init__.py:            vm.state_db.get_nonce(transaction.sender) - 1,
evm/vm/flavors/frontier/__init__.py:        code = vm.state_db.get_code(transaction.to)
evm/vm/flavors/frontier/__init__.py:        coinbase_balance = vm.state_db.get_balance(vm.block.header.coinbase)
evm/vm/flavors/frontier/__init__.py:        vm.state_db.set_balance(
evm/vm/flavors/frontier/__init__.py:            sender_balance = vm.state_db.get_balance(message.sender)
evm/vm/flavors/frontier/__init__.py:            vm.state_db.set_balance(message.sender, sender_balance + gas_refund_amount)
evm/vm/flavors/frontier/__init__.py:        coinbase_balance = vm.state_db.get_balance(vm.block.header.coinbase)
evm/vm/flavors/frontier/__init__.py:        vm.state_db.set_balance(
evm/vm/flavors/frontier/__init__.py:        vm.state_db.set_balance(account, 0)
evm/vm/flavors/frontier/__init__.py:        vm.state_db.delete_account(account)
evm/vm/flavors/frontier/__init__.py:    vm.block.header.state_root = vm.state_db.root_hash
evm/vm/flavors/frontier/__init__.py:        sender_balance = vm.state_db.get_balance(message.sender)
evm/vm/flavors/frontier/__init__.py:        vm.state_db.set_balance(message.sender, sender_balance)
evm/vm/flavors/frontier/__init__.py:        recipient_balance = vm.state_db.get_balance(message.storage_address)
evm/vm/flavors/frontier/__init__.py:        vm.state_db.set_balance(message.storage_address, recipient_balance)
evm/vm/flavors/frontier/__init__.py:    if not vm.state_db.account_exists(message.storage_address):
evm/vm/flavors/frontier/__init__.py:        vm.state_db.touch_account(message.storage_address)
evm/vm/flavors/frontier/__init__.py:    if vm.state_db.get_balance(message.storage_address) > 0:
evm/vm/flavors/frontier/__init__.py:        vm.state_db.set_nonce(message.storage_address, 0)
evm/vm/flavors/frontier/__init__.py:        vm.state_db.set_code(message.storage_address, b'')
evm/vm/flavors/frontier/__init__.py:        vm.state_db.delete_storage(message.storage_address)
evm/vm/flavors/frontier/__init__.py:        vm.state_db.increment_nonce(message.sender)
evm/vm/flavors/frontier/validation.py:    sender_balance = vm.state_db.get_balance(transaction.sender)
evm/vm/flavors/frontier/validation.py:    if vm.state_db.get_nonce(transaction.sender) != transaction.nonce:
evm/vm/flavors/homestead/__init__.py:    if vm.state_db.account_exists(message.storage_address):
evm/vm/flavors/homestead/__init__.py:        vm.state_db.set_nonce(message.storage_address, 0)
evm/vm/flavors/homestead/__init__.py:        vm.state_db.set_code(message.storage_address, b'')
evm/vm/flavors/homestead/__init__.py:        vm.state_db.delete_storage(message.storage_address)
evm/vm/flavors/homestead/__init__.py:        vm.state_db.increment_nonce(message.sender)
evm/vm/flavors/homestead/headers.py:            balance = vm.state_db.get_balance(account)
evm/vm/flavors/homestead/headers.py:            vm.state_db.delta_balance(dao_refund_contract, balance)
evm/vm/flavors/homestead/headers.py:            vm.state_db.set_balance(account, 0)
tests/json-fixtures/test_vm.py:    verify_state_db(post_state, vm.state_db)


Redesigned the 'Back to Top' button

Related Issue
[Cite any related issue(s) this pull request addresses. If none, simply state “None”]
Fixes:  #2557
Description
This pull request introduces a significant enhancement to the 'Back to Top' button functionality by incorporating animated elements aimed at improving user experience on lengthy web pages. The redesign focuses on seamlessly guiding users back to the top of the page while also engaging them with visually appealing animations.
Type of PR

[ ] Bug fix
[x] Feature enhancement
[ ] Documentation update
[ ] Other (specify): _______________

Screenshots / videos (if applicable)
https://github.com/user-attachments/assets/15c2a23c-592c-4974-a354-0e104fa116e9
Checklist:

[x] I have made this change from my own.
[x] I have taken help from some online resources.
[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[x] I have tested the changes thoroughly before submitting this pull request.
[x] I have provided relevant issue numbers and screenshots after making the changes.

@huamanraj Check now


feat: green, light green, and teal color palettes and swatches

@rultor good to merge.

@rultor good to merge.

@rafamizes OK, I'll try to merge now. You can check the progress of the merge here

@rultor good to merge.

@rafamizes Done! FYI, the full log is here (took me 3min)

Merged by rultor.
Closes #53.


Two different cluster layers

At the moment, we put the annotations in an array of Сluster Manager:
mapView.clusterManager.annotations = annotations
But, what should I do if I want to have two different layers. For example, shops will cluster in one layer and cultural monuments in another.
I have two arrays
var news: [NewsAnnotation]
var monuments: [MonumentsAnnotation]
Accordingly, these two arrays should not cluster together. And should not be displayed on the map as a single layer.
Any ideas?
I Used MapBox.

I have the same problem to resolve, anyone have any ideas how to do it?

I never tested it but creating 2 cluster managers for the same map should work:
let layer1 = CKClusterManager()
layer1.map = self.mapView
layer1.annotations = news

let layer2 = CKClusterManager()
layer2.map = self.mapView
layer2.annotations = monuments

Have you been able to test that? I will close this for now.


Outdated Visual Studio topics in sp-add-ins

The following topics in sp-add-ins (links are on STAGING site) appear to have outdated information about Visual Studio. I suggest that a writer or PM either updates these or removes them:

https://review.docs.microsoft.com/en-us/sharepoint/dev/sp-add-ins/publish-sharepoint-add-ins-by-using-visual-studio?branch=master
https://review.docs.microsoft.com/en-us/sharepoint/dev/sp-add-ins/set-up-an-on-premises-development-environment-for-sharepoint-add-ins?branch=master (this one contains outdated info about Windows Server and Hyper-V under "Install the operating system")
https://review.docs.microsoft.com/en-us/sharepoint/dev/sp-add-ins/what-s-new-in-office-developer-tools-for-visual-studio?branch=master (no info on this page)

On the following topics, I updated the link to "Install Visual Studio" to the 2017 version; 1) please confirm that it is the correct one (links are on STAGING site); 2) also check "installer" links to make sure they're the right ones.

https://review.docs.microsoft.com/en-us/sharepoint/dev/sp-add-ins/get-started-creating-sharepoint-hosted-sharepoint-add-ins?branch=master
https://review.docs.microsoft.com/en-us/sharepoint/dev/sp-add-ins/get-started-creating-provider-hosted-sharepoint-add-ins?branch=master
https://review.docs.microsoft.com/en-us/sharepoint/dev/sp-add-ins/set-up-a-development-environment-for-sharepoint-add-ins-on-office-365?branch=master

Do we know if it is just this one topic, or do we need to check others as well?

It’s the 6 topics that I listed in the bug…
I haven’t looked at the “Develop” section yet; there could be more there.
From: David Chesnut<EMAIL_ADDRESS>Sent: Friday, November 3, 2017 4:26 PM
To: SharePoint/sp-dev-docs<EMAIL_ADDRESS>Cc: Linda Caputo (Steyer Associates Inc<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [SharePoint/sp-dev-docs] Outdated Visual Studio topics in sp-add-ins (#1021)
Do we know if it is just this one topic, or do we need to check others as well?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSharePoint%2Fsp-dev-docs%2Fissues%2F1021%23issuecomment-341851006&data=02|01|v-licapu%40microsoft.com|70894095ab034a3206d708d523123adc|72f988bf86f141af91ab2d7cd011db47|1|0|636453483555330816&sdata=40yV8L1Hhq2i5HR%2FPEgWjqL6dNe1ES2GD4uh8%2FJHRVE%3D&reserved=0, or mute the threadhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAaCAN7FhJCWleEuzmg7Nw64Clr_uR576ks5sy6ECgaJpZM4QRtl2&data=02|01|v-licapu%40microsoft.com|70894095ab034a3206d708d523123adc|72f988bf86f141af91ab2d7cd011db47|1|0|636453483555330816&sdata=54ROCtwWca1DTzjfl%2B%2BxsEsZ%2BUh9%2FsKTHq040dFRzkM%3D&reserved=0.

Hey @davidchesnut  and @VesaJuvonen, I'm about to edit the sp-add-in Develop topics and realized I never got an answer to this question: can you confirm that it's okay to link to Visual Studio 2017 (instead of 2013) on the pages listed above? If so, I can find and fix other instances. Thank you!

Hi @Linda-Editor , to do this correctly you would need to verify that the steps and UI did not change between versions.


Questions to Kaggle dataset

@Makhsuda can you fix the[kaggle] so it also has the link to the task with [kaggle](url)


Certificate ownership verification failed for client

ISSUE TYPE

Other

COMPONENT NAME
CLOUDSTACK VERSION
CLOUDSTACK VERSION
CloudStack <IP_ADDRESS>
CONFIGURATION
advanced networking
OS / ENVIRONMENT
CentOS Linux release 7.8.2003 (Core)
SUMMARY
when i creat vm get thie error
2024-02-26 13:43:02,058 ERROR [o.a.c.c.p.RootCACustomTrustManager] (pool-59459-thread-1:null) (logid:) Certificate ownership verification failed for client: X.X.X.X
2024-02-26 13:43:02,060 ERROR [c.c.u.n.Link] (AgentManager-SSLHandshakeHandler-4:null) (logid:) SSL error caught during wrap data: Certificate ownership verification failed for client: X.X.X.X

@yeganehmehr is this a clean installation?

No.we update to cloudstack  4.17.2

@yeganehmehr , you could

set auth strictness (ca.plugin.root.auth.strictness) setting to false,
restart kvm agent;

if you want secure connections you can then

re-provision certificates.
set the auth strictness back to true
and finally restart cloudstack-agent

let us know how you fare

Usually post-upgrade, systemvms and routers must be upgraded/re-created. For KVM agents, if there was an issue Daan's advised can be followed to apply the workaround.
Closing as the question has been answered.


Just feedback, not a real issue

Hello Sean Weaver,
This is David Fu. I've just started this Cryptol course after working through the Galois Programming Cryptol book, and I sure wish I had just come here first. It is way better.
There is one thing that is really bugging me so far about the language. What is the best forum/way to discuss it with you?
--David

You can try<EMAIL_ADDRESS>On Wed, Dec 2, 2020 at 9:08 AM dfu-github<EMAIL_ADDRESS>wrote:

Hello Sean Weaver,
This is David Fu. I've just started this Cryptol course after working
through the Galois Programming Cryptol book, and I sure wish I had just
come here first. It is way better.
There is one thing that is really bugging me so far about the language.
What is the best forum/way to discuss it with you?
--David
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/weaversa/cryptol-course/issues/147, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABYQSOUMVLZ7AVCQNC5PGSDSSZC7HANCNFSM4UKRMCPA
.


Bot does not work at all.

Bot returning error message: "Unknown (Not enough information gathered)" in lastseen command output.

Discord requires Gateway Intents to be requested on connection. More details https://discordjs.guide/popular-topics/intents.html - need to request GUILD_MEMBERS and GUILD_PRESENCES to make the bot work.


[proposal] CPU burst based on K8s 1.27 resize resources feature

What is your proposal:
CPU burst based on K8s 1.27 resize resources feature https://kubernetes.io/docs/tasks/configure-pod-container/resize-container-resources/
Why is this needed:
Would be a great alternative to quota and period CPU bursting
Is there a suggested solution, if so, please add it:
no

Thanks @lukasmrtvy.
The resize resources feature can indeed be tried in this scenario. However, from the perspective of the implementation of this feature, it is relatively heavy. It needs to modify the Pod Spec and submit it to the APIServer, then to the kubelet for execution, and finally the scheduler will perceive and adjust the internal state of the scheduler. Compared with this specific scene, the whole link is not so suitable.
Koordinator's current CPU Burst mechanism only needs to make estimates or analyze abnormalities based on resource indicators on nodes, and directly modify cgroup parameters, which is very lightweight overall.


Generating native atomic instructions in Numba

DPC++ added a new feature to enable a SPIR-V extension to support FP32 and FP64 atomic adds. https://github.com/intel/llvm/pull/2765
We need to evaluate the changes and make sure we are generating similar code in Numba.

An opt-in support was added. Details in this PR.


Warning with mf.counts()

badfish/badfish.py:132: FutureWarning: sort is deprecated, use sort_values(inplace=True) for INPLACE sorting  mf_sum.sort(ascending = ascending)

Resolved :)


Install junit-plugin in Jenkins

https://github.com/jenkinsci/junit-plugin allows us to access test reports, which is a useful thing for quickly checking what the actual problem is without running the tests locally, and to get more information about non-reproducible errors.

Excellent idea. @javierron WDYT?

Excellent idea. @javierron WDYT?

That would be very helpful. I think the plugin is (available by default)[https://wiki.eclipse.org/Jenkins#Default_plugins_-Jiro.28ci-staging.eclipse.org.2Fxxx_and_ci.eclipse.org.2Fxxx.29].

That would be very helpful. I think the plugin is (available by default)[https://wiki.eclipse.org/Jenkins#Default_plugins_-Jiro.28ci-staging.eclipse.org.2Fxxx_and_ci.eclipse.org.2Fxxx.29].

OK, it's available but not activated? @andre15silva would you have a look on how to activate it in our job? Thanks!

OK, it's available but not activated? @andre15silva would you have a look on how to activate it in our job? Thanks!

Didn't realize it was already available, sorry. I'm going to activate it in #1169.

Didn't realize it was already available, sorry. I'm going to activate it in #1169.


Update download page

Proposed changes
This PR updates Download Page based on feedback

add hide release & show release

add hardfork release tag at accordian

hide versions

Types of changes
Please put an x in the boxes related to your change.

[ ] Minor Issues and Typos
[ ] Major Content Contribution
[ ] Others

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to reach out. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

[ ] I have read the CONTRIBUTING GUIDELINES
[ ] I have read the CLA and signed by comment I have read the CLA Document and I hereby sign the CLA in first time contribute
[ ] I have added necessary documentation (if appropriate)
[ ] Any dependent changes have been merged and published in downstream modules

Related issues

Please leave the issue numbers or links related to this PR here.

Further comments
If this is a relatively large content contribution, kick off the discussion by explaining why you would suggest the content contribution, etc...

I have read the CLA Document and I hereby sign the CLA.

I have read the CLA Document and I hereby sign the CLA

@scott-klaytn could you review this PR? I attached the screen shot on the description of this PR.


Completion inside interface has inconsistent behavior

There is no completion shows up on the first property declaration in an interface

which is fine if it is consistent with the rest. However, we do give completion on the second property declaration.

This could be IDE dependent, I don't find this issue valid on
WebStorm 2020.3.3
Build #WS-203.7717.59, built on March 15, 2021


NullReferenceException in MediatR.Mediator.Send using StructureMap in a test harness

MediatrWithSpecsFor.zip
It's happening with 8.1.0 and 9.0.0. I've reproduced the problem with a pretty small class library - 1 request and 1 handler - and a simple test harness - SpecsFor which uses StructureMap (see attached zip file). I'm following the steps at https://github.com/jbogard/MediatR/wiki to set up the container. If I debug the test and examine the container, I see all the expected types in it. The Mediator object is there. The Send method is called. But it never reaches the Handle method of the handler b/c it gets a NullReferenceException. This is the stack trace:
   at System.Collections.Generic.EnumerableHelpers.ToArray[T](IEnumerable`1 source, Int32& length)
   at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
   at System.Linq.Enumerable.ReverseIterator`1.MoveNext()
   at System.Linq.Enumerable.Aggregate[TSource,TAccumulate](IEnumerable`1 source, TAccumulate seed, Func`3 func)
   at MediatR.Internal.RequestHandlerWrapperImpl`2.Handle(IRequest`1 request, CancellationToken cancellationToken, ServiceFactory serviceFactory)
   at MediatR.Mediator.Send[TResponse](IRequest`1 request, CancellationToken cancellationToken)
   at MediatrApp.BaseRequest`1.<HandleAsync>d__2.MoveNext() in D:\Src\TestFrameworkResearch\MediatrWithSpecsFor\MediatrApp\BaseRequest.cs:line 17

I realize this isn't necessarily the normal scenario for MediatR. But since it's documented as working with StructureMap, and since if it's used in a StructureMap-based application it should be able to be tested in a StructureMap-based test harness (IMO), then what I've put together should work. I've pulled in the MediatR code while debugging, but there's too much going on in a single line within the Send method and within the RequestHandlerWrapperImple.Handle method for me to figure it out.
Thank you.

Thanks for the repro repo, but in the future its easier to just add it as a repo to your profile on github.  I'm assuming you're injecting the IMediator into the request just to show a particular failure?  There would never be any scenario where this would be valid in a real world application.  I could be misunderstanding what you are trying to show.

After messing around with this for a bit I would guess the issue is in the SpecsFor library, not in MediatR.  Whatever engine SpecsFor is using to build the structuremap container in conjunction with Moq might be messing it up.  Given that repo hasn't seen activity in a while it might be an issue that you need to fix yourself.

In a normal scenario with structure map or any other container library, when you ask for a collection of instances, the container will give you an empty collection if there are none. Which is the case here. If you want to add behaviors you can register them (see the samples folder) and then the collection would be non-empty. In either case with the auto mocker that is being used by SpecsFor, you will get back a mocked IEnumerable which won’t work. This is because the StructureMap Automocker adds functionality to the container that ensures a mock is returned for anything that doesn’t explicitly have a registration.  It’s possible to work around this by adding your own policy to the container which would be applied before the automocking policy if you want to continue using this testing library.

At the risk of becoming annoying (or maybe more annoying than I already am)... In an earlier message you said: In this case mediator asks the service factory for a collection of PipelineBehaviors that can handle the request being sent.
I took that to mean that a PipelineBehavior somehow wraps an actual request handler type - "SimpleHandler" in my sample project. But maybe I misunderstood what you meant regarding PipelineBehaviors. What you say in your most recent message implies that these behaviors are optional ("if you want to add [them] you can register them").
So perhaps you can clarify that. More significantly, though, should I understand that if there is at least 1 real PipelineBehavior registered then StructureMap won't return an automock and MediatR might get a valid collection and be able to get past this exception? (FYI - I am going to look at the samples folder).
Thank you again.

Yes the Pipeline Behaviors wrap a request handler and act as middleware, passing the request through all matching behaviors.  They are optional, but the mediator always asks the service factory for them.  In normal execution if you have not registered any you will simply get back an empty collection.
If you register some in your test project you will still get back a mocked IEnumerable<T> this is because there is no explicit registration for the IEnumerable<T>.  The automocker overrides the default container behavior which would be to return all possible registered instances of T when being asked for IEnumerable<T>.   So even registering the behaviors will not work around this.  In order to get this to work you will need to add a custom IFamilyPolicy to the container.

Thank you again, @lilasquared. Closing.

No problem.  I took a look at the default policies that StructureMap ships with, so if you want to work around the error easily you can register the default pipeline behaviors that come with MediatR (as seen in the samples) and then add this line to your container config.
cfg.Policies.OnEmptyFamily(new EnumerableFamilyPolicy());

This way the enumerable policy will be applied before the AutoMocking policy.

I think OnEmptyFamily in your sample code should be OnMissingFamily. Anyway... what you suggested gets around the null reference exception - in fact I don't even need to add the default pipeline behaviors, just the EnumerableFamilyPolicy.
Unfortunately, SimpleHandler never gets invoked. After the line _result = SUT.HandleAsync().Result; executes, _result is false. But SimpleHandler has never been instantiated or its Handle method invoked.
We're likely getting into the real esoteric stuff now.

Its not as esoteric as you think.  What's happening now is that the Automocker is giving you a mock pipeline behavior.  I thought that by adding the default ones it would prevent this but it does not.  Using the below policy will resolve the issue however you will no longer be able to test the pipeline behavior.  It will be more complicated to be able to test them since they rely heavily on closing generics which might be difficult to circumvent given the Automocking behavior.  The below policy simply forces the container to return an empty list.
public class EmptyPipelineFamilyPolicy : IFamilyPolicy
{
    public PluginFamily Build(Type type)
    {
        if (EnumerableInstance.IsEnumerable(type))
        {
            var elementType = EnumerableInstance.DetermineElementType(type);

            if (elementType.Name == typeof(IPipelineBehavior<,>).Name)
            {
                var family = new PluginFamily(type);
                family.SetDefault(buildInstanceForType(elementType));

                return family;
            }

            return null;
        }

        return null;
    }

    public Boolean AppliesToHasFamilyChecks
    {
        get
        {
            return false;
        }

    }
    private static Instance buildInstanceForType(Type type)
    {
        var instanceType = typeof(List<>).MakeGenericType(type);
        var instance = Activator.CreateInstance(instanceType);
        return new ObjectInstance(instance);
    }
}

That did it. I didn't need any of this kind of code from "samples":
cfg.For(typeof(IPipelineBehavior<,>)).Add ...
For the actual MediatR application I'm writing and testing, we're not using the pipeline behaviors; and I don't foresee us needing them. The main issue is relying solely upon StructureMap for DI when running under the test harness (whereas the application itself uses .net core's DI).
Thank you.

Great.  You may want to eventually look into alternate forms of integration testing that uses the same DI for both the tests and the application since they have different features.

Agreed. I need to be able to specify response results for method calls on automocked objects. I can only do that if StructureMap generated the automocks. But I'd much prefer that everything related to MediatR use .net core's DI as the actual app does.


Align argument policy for Object.keys(), Object.seal(), etc. with ES6

ES6 changes the argument policy for functions such as Object.keys() and Object.freeze() to accept primitive values, treating them as though they were non-extensible objects with no properties, rather than rejecting them with a TypeError as in ES5.  This pull implements that change of behavior.
Affected functions:

[x] Object.freeze
[x] Object.getOwnPropertyDescriptor
[x] Object.getOwnPropertyNames
[x] Object.getPrototypeOf
[x] Object.isExtensible
[x] Object.isFrozen
[x] Object.isSealed
[x] Object.keys
[x] Object.preventExtensions
[x] Object.seal

Checklist:

[x] Review ES 2015 to see exactly which functions are affected
[x] Implement the argument policy change
[x] This got a bit awkward in spots, review changes and clean up
[x] Fix testcases to align with new argument policy
[x] Verify against ES6 to ensure other behavior matches
=> Possible issue with freeze/seal, best tackled separately
[x] Squash commits and rebase against latest master
[x] Releases entry

Yep, I thought that would happen.  All I did was to change Object.defineProperty() to coerce its argument instead of throwing a TypeError and I already broke a test. :)

Annex E lists the functions affected by this.  It also lists other behavioral differences between E6 and E5[.1]:
http://www.ecma-international.org/ecma-262/6.0/#sec-additions-and-changes-that-introduce-incompatibilities-with-prior-editions

That's an interesting list, hadn't read that in detail before. I see that ToNumber() coercion needs octal support for example:
Node.js:
> +'0o123'
83

Duktape:
duk> +'0o123'
= NaN

Interestingly, there are also now runtime SyntaxErrors:

In ECMAScript 2015, a runtime SyntaxError is thrown if a Catch clause evaluates a non-strict direct eval whose eval code includes a var or FunctionDeclaration declaration that binds the same Identifier that appears as the Catch clause parameter.

A runtime syntax error is a very odd concept indeed.  It makes sense though since eval() can be thought of as a kind of lazy evaluation.

@svaarala I'll look at finishing this up in the next few days so it'll be ready to go if you decide it should be merged.  The changes are straightforward, it's just a matter of fixing the testcases.

Weird, for some reason I thought Object.defineProperty() was included but it turns out that's not the case.  No idea why I thought that, it doesn't make much sense to pass a primitive value to it.

Many operations create a temporary object which is modified and then lost - that may seem pointless but it does cause side effects and the operation may be rejected e.g. by an inherited property.
But yes, Object.defineProperty() requires an object and won't coerce. Not sure why that's different from e.g. Object.freeze() which also required an object in ES5.1 but is a silent success in ES6.

I assume the rationale for Object.freeze() etc. is that one may do, e.g. return Object.freeze(val); at the end of a function and this allows that to work generically without an explicit type check.  For Object.defineProperty()  it doesn't make much sense to coerce - the defined properties would be lost which would probably lead to misbehavior anyway.

Well, I seem to have broken everything :)
I'll work on this tonight; I'm gearing up to start minisphere 5.0 development, so it'll take me a while to take stock of everything that needs to be done.  In the meantime I'm free to finish up this pull finally.

The ES6 argument policy changes have been implemented for all affected functions.  Next: fixing tests.

The testcases should all be fixed now.  I have to do some cleanup of the implementation before this is merge ready though; for the shared helpers it got a bit messy in spots because of the subtle behavioral differences between variants.

On closer inspection it seems that Object.keys() is still failing (this is probably a bug in the test), and Reflect arg policy is broken too.  So object coercion seems to be applied too broadly now.
I'll fix it tonight, no more time right now.

The Object.keys() fail was indeed a test bug.  Object.keys('foo') returns 3 keys: the character indices.  I forgot that strings were array-like and assumed the returned array would be empty, like with Object.keys(123).
All tests should be passing now.  Just have to give the code a once-over to see if it can be cleaned up, verify the behavior matches ES6, then squash the commits and this will be ready to merge.

Hm, the algorithms for Object.seal() and Object.freeze() in ES6 differ slightly from ES5.  ES5 sets [[Extensible]] to false last:
http://www.ecma-international.org/ecma-262/5.1/#sec-<IP_ADDRESS>
ES6 does it first:
http://www.ecma-international.org/ecma-262/6.0/#sec-setintegritylevel
Not sure if that's observable.

@svaarala This is finally merge ready :)

Weird, all the tests passed except for linux-x86-packed-tval.  I don't think that's related to this pull?

I updated the testrunner to expect an object-based Duktape.info() which is needed for the packed duk_tval test. So it will now be broken until the object-based Duktape.info() is merged, and can just be ignored until then.

@fatcerberus Could you rebase to master? Let's see if the test error gets fixed.
This adds around +150 bytes to footprint for a relatively little change, so I'll open a follow-up to see if I can optimize the footprint a bit.

Regarding footprint, what I'm mainly concerned about for the short term is the low memory footprint for the ES5-ish subset. That's what's mostly used on low memory devices and literally every kilobyte saved in Duktape footprint allows a kilobyte more of actual application code.
So, I'm mostly trying to make sure the "minsize" build doesn't grow in footprint, at least for obvious reasons. It's of course not a blocker for making changes if additional footprint cannot be avoided and the change otherwise makes sense.

I guess most of the extra footprint is due to the extra checks, since there's now behavioral variance between, e.g. Reflect and Object.  I'll see if I can streamline it somewhat.

The packed duk_tval test passed now :)

I made the suggested changes, anything else I can do here?

I'll give it another read through in a bit and I can then merge the change.
In practice this merge means Duktape no longer targets ES5 compliance but rather provides an ES5-ish subset for low memory targets, with the "-ish" caused by semantic changes (to bindings present in ES5) in ES6 and later.
So, I'll need to open a pull for updating the website and other documentation to reflect this compliance goal (or rather, non-goal).

Well if we're being technical about it you already did a couple such merges, for example #1135... ;-)

Hehe, that's true - but those were really technical ones compared to changing the Object built-ins.
I'm fine with that change but it needs to be changed in the documentation.

The practical issue is that it's fine to merge this to master, and it will commit master more to the "ES5-ish" approach. It's still possible, of course, to add a "use strict ES5 semantics" config option and go over all the places with the changed semantics (that's been the basic idea for now). But the more changes are merged, the more extra work that becomes if it's done afterwards (for instance, testcases will need fixing, etc).
I'm leaning towards the ES5-ish approach for practical reasons, though. So it's not an issue for this pull; I just have to update the documentation as master will be more committed to this approach now.

Regarding foorprint, to illustrate the footprint changes in recent pulls, here's a graph of x64 low memory build (gcc -Os with link time removal of unused symbols) over the last 120 pulls (not commits); master on the right; the last uptick is caused by Duktape.info() getting an object format - quite noticeable here:

In last 120 pulls the footprint improvement has been roughly 1kB, for roughly the same (or increased) functionality. The low-memory configuration is roughly a minimal ES5 (or ES5-ish in master) subset. ARM Thumb builds are roughly speaking around 10% smaller IIRC.
As long as the footprint of this configuration doesn't increase compared to an earlier release, a project using Duktape can upgrade to a newer version and won't need to remove or size optimize application code. If the footprint does increase, say by 1kB, the application writer must shave off 1kB somewhere which can be a significant undertaking if the application is already, say, 40kB. Conversely, 1kB more space means the application scope can be increased.
So right now I'm tracking this ES5-ish low memory configuration w.r.t. footprint as that's a useful subset, and since the subset is fixed it's meaningful to compare build sizes. ES6 is a bit difficult to track because as new features are added, footprint will naturally grow. Technically it'd still be interesting to somehow measure "per feature footprint", e.g. the footprint of enabling Proxy over the ES5-ish baseline. Maybe later on comparing footprints of certain ES6 subsets (over versions) may be useful.
With the above in mind, I hope it's clearer why I'm frowning on a +200 bytes minsize footprint impact: it represents losing around 20% of the gains made in the last 120 pulls. It's a constant struggle but very meaningful for people doing low memory stuff :)

And now you have me wondering what that massive spike was around 90 pulls ago... :)

Quite likely it was some new feature (non-ES5) added to master, but without a line in low_memory.yaml to disable it for the low memory configuration. That was then fixed and the spike went away. That's the most likely cause anyway :)

It might be possible to reverse most of the footprint impact here by refactoring things a bit, e.g. rather than a large shared Duktape/C helper with branching code paths based on a magic value, maybe the base functionality itself could be moved into helpers - and then Object and Reflect methods can have separate Duktape/C functions which call the shared primitives after ensuring the value stack state is correct etc.  This way when Reflect support is not present you don't pay for having the related code paths.

Earlier when I was experimenting with footprint, generally a function with a magic value has better footprint than two entrypoints that call a shared helper with flags. But doing so does have the upside that when only one call site remains, the compiler can inline the call and remove any flags checks as having a constant value. With a magic value the compiler can't know what values are possible, so, as you said, the code paths remain.
The other approach is to keep a single function but #ifdef the relevant magic value checks.
If this pull is otherwise functional, I'm fine with merging it and experimenting with footprint improvement as a follow-up pull; if that doesn't work out with a reasonable effort then the added footprint is fine too.

Alright, sounds good to me :)  Do I have to rebase again?

Doesn't seem to conflict and changes in master are unrelated, so no need. I'll merge this tomorrow - I've got to sleep for a bit :)

Whoops, found an unreferenced variable warning and couldn't leave it unfixed :)

@svaarala Not related to this pull specifically but I see your minisphere snapshot is a bit old (May 16).  As various useful enhancements like #1128 get merged into master, I try to take advantage of them so it might be good to keep the minisphere testrunner up to date to help ensure that the newer features aren't broken either.
Six months doesn't sound like much, but for a project as actively developed as minisphere it's an eternity.  Looking at my release history real quick, on 05/16 the current release was v3.1,2.  I'm at v4.3.8 now. ;)

I'll build a few graphs nightly here for fun: http://duktape.org/graphs.html.

@fatcerberus I froze the Minisphere version in the builds because there wasn't support for configuring via DUK_USE_xxx options and tools/configure.py at that point - could I now use Minisphere master?

No automated support no, but currently I do use configure.py internally to build the bundled duktape.c.  I still need a fixup for DUK_OPT_HAVE_CUSTOM_H though because I still support Duktape 1.x (mostly at your request :)
What would I need to do to enable you to update?

Hmm, so maybe if I make the test run tools/configure.py and overwrite the bundled duktape.c - and then just build normally?

Yeah, that should work.  I actually thought that's what that test did already...?

Close but it needs a fixup file:
def context_linux_x64_minisphere():
    cwd = os.getcwd()

    execute([ 'make', 'dist' ])

    # Unpack minisphere snapshot and copy Duktape files over.
    unpack_targz(os.path.join(repo_snapshot_dir, 'minisphere-20160516.tar.gz'))

    prep(options=[ '--fixup-file', os.path.join(cwd, 'minisphere', 'src', 'engine', 'duk_custom.h') ])

    for i in [ 'duktape.c', 'duktape.h', 'duk_config.h' ]:
        execute([
            'cp',
            os.path.join(cwd, 'prep', i),
            os.path.join(cwd, 'minisphere', 'src', 'shared', i)
        ])

    # sudo apt-get install liballegro5-dev libmng-dev
    os.chdir(os.path.join(cwd, 'minisphere'))
    return execute([ 'make' ], catch=True)['success']

Would this work in Minisphere master?

Assuming that prep() runs configure.py, that should work in master.  For my part I'll see if I can phase out the duk_custom.h for minisphere 5.0.


Updated to fix state colours

HA's 2022.12 update broke the state colours for all themes that change them. I have implemented a basic fix to return the themes to how they looked before the update.
New values were taken from here: https://community.home-assistant.io/t/2022-12-color-states-are-broken-unusable/499890/3

FYI, I'm not used to using Github so sorry if I submitted the pull request the wrong way

Same issue for me
I updated the code as listed but no change after restart.
Anything else I need to do?

I moved out of town and I don't have my home assistant to fix the bugs. I will try to analyze and merge.


Query freezes when using the new AQL traversals

I'm experiencing a pretty big issue here.
Basically, I have a graph of entities linked by entityRights, and I want to get all the entities on which the current user has read permissions.
Before the new traversal system, I used that AQL query:
FOR e IN REMOVE_NTH(TRAVERSAL(entities, entityRights, @userID, 'outbound', {followEdges: [{'read': true}]}), 0)
FILTER e.vertex._id == 'entities/role5'
RETURN DISTINCT e.vertex

Then, I migrated it to the new traversals and got (which is much cleaner):
FOR v, e IN 1..10 OUTBOUND @userID entityRights
FILTER e.read == true
FILTER v._id == 'entities/role5'
RETURN DISTINCT v

90% of the time, everything works fine. But sometimes, the last one hangs and completely freezes the database. I can see it in the query manager, it never ends.
When it freezes, I have to kill -9 the DB and if I relaunch it and try again the exact same query, it works perfectly.
I wrote a script to run concurrently multiple of these queries to see if I can get the issue again (that's what my app does when it happens) but it never happens.
So, it seems to me that the problem might appears when some writes are done at the same time these queries run (that's what my app does when it happens).
I had to roll back all my AQL traversals migrations to the old queries to be sure there would not be problems anymore. Everything is fine again.
Are there any precautions to take when using the new traversals ?
Thank you

Hi @solher,
i try to reproduce your situation and need some more information please:

Which version of ArangoDB are you using?
could you give me an example of the modification query that runs in parallel to the AQL traversal?
Are there any collections other than entities connected with edges in entityRights? If so, how many?
If 3) is not NO from which collection is the @userID?

best
Michael

I tried with 2.8.0, 2.8.1 and 2.8.2.
I tried to remove the more queries I could to isolate the issue and it seems to occur when I run:

   {
      "collections": {
        "read": [],
        "write": [
          "entities",
          "entityRights"
        ]
      },
      "action": "function() {
        var db = require('internal').db;
        var userID = 'users/admin';
        var entities = db._query(aqlQuery `LET removed = ( FOR e IN entities FILTER e._key IN ['usradminorg1'] FOR r IN entityRights FILTER r.ownedBy == ${userID} \u0026\u0026 r._to == e._id \u0026\u0026 r.read == true REMOVE r IN entityRights RETURN DISTINCT e ) FOR e IN removed REMOVE e IN entities RETURN OLD`).toArray();
        db._query(aqlQuery `FOR e IN entities FILTER e._key IN ['usradminorg1'] FOR r IN entityRights FILTER r.grantedTo == ${userID} \u0026\u0026 r._to == e._id \u0026\u0026 r.read == true REMOVE r IN entityRights RETURN OLD`).toArray();
        return entities;
    }"
    }
}

Then concurrently:
    {
      "query": "FOR v, e IN 1..3 OUTBOUND @userID entityRights FILTER e.read == true FILTER v._id == 'entities/E2lGteam2' RETURN DISTINCT v",
      "bindVars": {
        "userID": "users/admin"
      }
    }

    {
      "query": "FOR v, e IN 1..3 OUTBOUND @userID entityRights FILTER e.read == true FILTER v._id == 'entities/R2AHteam1' RETURN DISTINCT v",
      "bindVars": {
        "userID": "users/admin"
      }
    }

    {
      "collections": {
        "read": [],
        "write": [
          "entities",
          "entityRights"
        ]
      },
      "action": "function() {
        var db = require('internal').db;
        var now = '2016-02-16T20:26:48.90364563Z';
        var entityID = 'entities/E2lGteam2';
        var userID = 'users/admin';
        var newEntities = [{
            '_key': 'iJwWrole2',
            'type': 'entityTypes/400'
        }];
        var entities = db._query(aqlQuery `FOR a IN ${newEntities} UPSERT { '_key': a._key } INSERT a UPDATE a IN entities RETURN NEW`).toArray();
        db._query(aqlQuery `FOR a IN ${entities} INSERT { 'created': ${now}, 'lastUpdated': ${now}, '_from': ${entityID}, '_to': a._id, 'ownedBy': ${userID}, 'read': true, 'write': true } IN entityRights`).toArray();
        return entities;
    }"
    }

    {
      "collections": {
        "read": [],
        "write": [
          "entities",
          "entityRights"
        ]
      },
      "action": "function() {
        var db = require('internal').db;
        var now = '2016-02-16T20:26:48.909444152Z';
        var entityID = 'entities/R2AHteam1';
        var userID = 'users/admin';
        var newEntities = [{
            '_key': '6wmhrole1',
            'type': 'entityTypes/400'
        }];
        var entities = db._query(aqlQuery `FOR a IN ${newEntities} UPSERT { '_key': a._key } INSERT a UPDATE a IN entities RETURN NEW`).toArray();
        db._query(aqlQuery `FOR a IN ${entities} INSERT { 'created': ${now}, 'lastUpdated': ${now}, '_from': ${entityID}, '_to': a._id, 'ownedBy': ${userID}, 'read': true, 'write': true } IN entityRights`).toArray();
        return entities;
    }"
    }

Yes, entityRights can be connected with entities and users.
Exactly. In fact I remove the current user from the result and keep the rest.

Oh and something new occured: after a 16 minutes hang, I got a "lock timeout" error.

BTW, I just found out about the min depth option of the TRAVERSAL function. Will be much better :)

BTW, I just found out about the minDepth option of the TRAVERSAL function. Will be much better :)

Hi thank you very much for the detailed information, this will help me debug it.
The "lock timeout" error is actually intended if you get into a dead-lock situation to recover the system.

Short update: I managed to reproduce the deadlock situation on my machine.
Now we track it down!

Could you try this again with the newest version of 2.8 (2.8.4) ?
We have fixed a potential deadlock in this area. On my machine i did not run into this situation any more.

It seems to be fixed ! Thanks a lot :+1:
And by the way, you didn't lie about the new traversal API in Barcelona, it is truly very good ! ;)

Thanks for the feedback ;)
Glad you like it.

Ok I had to rollback to the old traversal API again because it seems that, even if there is no deadlock anymore, the perfs under heavy loads seems very bad with the new one.
I've got some queries taking almost 5 minutes to complete when I have no problems with the old one (20 seconds max).
Do you see any reasons why it would do that or should I investigate more ?

In fact, I think it has nothing to do with it.
I don't know why but suddently, certain transactions are just really slow.


Fix some issues in new random execution requests

Rename methods so the request type isn't plural.

For example, get_random_deposits_requests to get_random_deposit_requests.

Set DepositRequest.index to rng.randrange(0, 2**64).

In Electra, index doesn't exist in deposit data.
I would have done rng.randint(0, UINT64_MAX) but this is an alias of randrange(a, b+1) and we cannot increment the max uint64 value again. Kind of a weird edge case.

Delete some whitespace & fix some organization nits.

Going to merge now to fix test vectors.


Extract Operation Corrupted

Describe the bug
I started using OpenRefine Version 3.2-beta [8d89a2a]. It seems to have corrupted by undo history--specifically on a number of projects that I've touched, I can no longer "Extract" my history as JSON.
Going back to version 3.1, I find that 3.1 can't extract the history either. Making an edit in 3.1 seems to fix the problem going forward, so that I can then go back to 3.2-beta and see this:

To Reproduce
I can share the project via e-mail, but I haven't been able to replicate the "corruption."
Desktop (please complete the following information):

OS: Windows 10
Browser Version: Version 72.0.3626.121 (Official Build) (64-bit)
JRE or JDK Version:
-- java version "1.8.0_121"
-- Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
-- Java HotSpot(TM) Client VM (build 25.121-b13, mixed mode)

OpenRefine (please complete the following information):

OpenRefine Version 3.2-beta [8d89a2a]

Datasets
Will share via e-mail

@nanobrad could you send the project to me by email<EMAIL_ADDRESS>

Similar issue on SO, but may be related to a badly configured reconciliation service (see #1936)

For what it's worth, I haven't used any reconciliation services or changed any of their configurations.

@nanobrad Can you try again with your backed up project against a build from our master branch, as Antonin has pushed and merged a fix and we would like to see if this works well for you.


[Protected Request] page 161 "Purchase Statistics" PurchPost

Hello,
Is it possible to get the variable PurchPost in page 161 "Purchase Statistics" as protected var?
    PurchPost: Codeunit "Purch.-Post";

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


python312Packages.mmengine: 0.10.4 -> 0.10.5

Description of changes
Changelog: https://github.com/open-mmlab/mmengine/releases/tag/v0.10.5
cc @benxiao

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Tests failing with
AttributeError: 'TestOptimWrapper' object has no attribute 'runTest'

nixpkgs-review result
Generated using nixpkgs-review.

Command: nixpkgs-review pr 343207
Systems: x86_64-linux,aarch64-linux,x86_64-darwin,aarch64-darwin

x86_64-linux

:white_check_mark: 8 packages built:

python311Packages.mmcv
python311Packages.mmcv.dist
python311Packages.mmengine
python311Packages.mmengine.dist
python312Packages.mmcv
python312Packages.mmcv.dist
python312Packages.mmengine
python312Packages.mmengine.dist

aarch64-linux

:fast_forward: 8 packages marked as broken and skipped:

python311Packages.mmcv
python311Packages.mmcv.dist
python311Packages.mmengine
python311Packages.mmengine.dist
python312Packages.mmcv
python312Packages.mmcv.dist
python312Packages.mmengine
python312Packages.mmengine.dist

x86_64-darwin

:fast_forward: 8 packages marked as broken and skipped:

python311Packages.mmcv
python311Packages.mmcv.dist
python311Packages.mmengine
python311Packages.mmengine.dist
python312Packages.mmcv
python312Packages.mmcv.dist
python312Packages.mmengine
python312Packages.mmengine.dist

aarch64-darwin

:fast_forward: 8 packages marked as broken and skipped:

python311Packages.mmcv
python311Packages.mmcv.dist
python311Packages.mmengine
python311Packages.mmengine.dist
python312Packages.mmcv
python312Packages.mmcv.dist
python312Packages.mmengine
python312Packages.mmengine.dist


bug: when building the image by passing all overrides, not able to provide image name

Heighliner commit hash: 2da0b66a365ef9dfd58230f137473b1b264a4927
Steps to reproduce:
Trying to build an Heighliner image of a chain which isn't part of the ./chains.yaml file by providing overrides.
heighliner build --org archway-network --repo archway --dockerfile cosmos --build-target "make build" --build-env "BUILD_TAGS=muslc" --binaries "build/archwayd" --git-ref v3.0.0 --tag test

Alternatively, also tried the below command but still didn't work
heighliner build archway --org archway-network --repo archway --dockerfile cosmos --build-target "make build" --build-env "BUILD_TAGS=muslc" --binaries "build/archwayd" --git-ref v3.0.0 --tag test

Actual behavior:
The generated image name is acrechain:test, which is just the name of the first chain in the chains.yaml.
Expected behavior:
Generate an image with the name archway:test.
It would be quite useful to be able to provide custom names for the generated images.
Relevant Trace:
Loaded chains from /mnt/c/code/heighliner/chains.yaml
Using local cosmos/native.Dockerfile
Go version from go.mod: 1.19, will build with version: 1.19.6 image: 1.19.6-alpine3.17
Building image from ref: v3.0.0, resulting docker image tags: +[acrechain:test]

you just need to add "-c archway"

Thank you!
I didnt realise that -c could be used as the help cmd says
-c, --chain string             Cosmos chain to build from chains.yaml
and archway wasnt in chains.yaml


Vivaldi compatibility issue

Does not work in Vivaldi :)

Hey, @milipili. This is a known issue for Vivaldi. See related issue.

Is it known if Vivaldi will "fix" this? I know they use a custom UI, but not sure if they plan to add in the necessary API support.


Moving the signing methods from State to User

What's wrong
The current way that State signs stuff and holds balance lets us shoot ourselves in the foot.

Key is lost when a state is created or cloned
Balance is outdated
Mock state has the source of truth of keys and the state tree has the source of truth of balance

How we are fixing it
We create a User class that knows only their stateID and pubkeyID and they sign stuff.
State only holds balances and the state tree has the single source of truth of balances.
We also created a Group class to handle a group of users gracefully.

Thank you for the review 😄


Updated Sessions

Added session details and the definition of done to both sessions.

nice updates, btw once the working session reaches this state we can change its status from 'draft'


[App-Sec] Modified Pre-receive hooks

Please always provide the GitHub issue(s) your PR is for, as well as test URLs where your change can be observed (before and after):
Fix #
Test URLs:

Before: https://main--prisma-cloud-docs--hlxsites.hlx.page/
After: https://--prisma-cloud-docs--hlxsites.hlx.page/
Worker: https://prisma-cloud-docs-production.adobeaem.workers.dev/?branch=

Hey @JBakstPaloAlto please do not merge PRs.

Hi,
I will not merge any more PRs. without requiring a review.
Jonathan
On Thu, Oct 26, 2023 at 7:55 PM Pubs-MV @.***> wrote:

Hey @JBakstPaloAlto
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_JBakstPaloAlto&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=t2p7TYcZF_sHc4m7vRldth542LT3TN5LzPq3XOymizI&m=qNbpMOUfRTNYqi3R08TygbHUE-qKHbsrHs-ioJki4NoU1Nli5uOPNFtr9vBFIOnC&s=99kEuquL44SMak0RR8CFO86wZM2_FXMF-f8nEu71QQ4&e=
please do not merge PRs.
—
Reply to this email directly, view it on GitHub
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_hlxsites_prisma-2Dcloud-2Ddocs_pull_200-23issuecomment-2D1781495919&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=t2p7TYcZF_sHc4m7vRldth542LT3TN5LzPq3XOymizI&m=qNbpMOUfRTNYqi3R08TygbHUE-qKHbsrHs-ioJki4NoU1Nli5uOPNFtr9vBFIOnC&s=BTNsL_ha6ohIrtzssvXsR0gVzS87BlLtualqU0B_52g&e=,
or unsubscribe
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AZIYZPCTVNAANJEB727AU7TYBKIYTAVCNFSM6AAAAAA6QR4XTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBRGQ4TKOJRHE&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=t2p7TYcZF_sHc4m7vRldth542LT3TN5LzPq3XOymizI&m=qNbpMOUfRTNYqi3R08TygbHUE-qKHbsrHs-ioJki4NoU1Nli5uOPNFtr9vBFIOnC&s=v65KPYmgbrCT6yAQXHYCMc0yQbKksPjwkZfeV2QGa34&e=
.
You are receiving this because you were mentioned.Message ID:
@.***>


Rewards query fails on token.fairground.wtf

Since the release of the update for Fairground token front end earlier today, we're seeing a 422 / GraphQL query error when navigating to the Rewards tab with a Vega wallet connected.

https://token.fairground.wtf/rewards
query Rewards($partyId: ID!) {
  party(id: $partyId) {
    id
    rewardDetails {
      asset {
        id
        symbol
        __typename
      }
      rewards {
        assetId
        partyId
        epoch
        amount
        percentageOfTotal
        receivedAt
        __typename
      }
      totalAmount
      __typename
    }
    delegations {
      amount
      epoch
      __typename
    }
    __typename
  }
  epoch {
    id
    timestamps {
      start
      end
      expiry
      __typename
    }
    __typename
  }
}

Closing as duplicate of #1006, addressed in #1010
Thanks for the detailed report :pray:


fix version regex

In the current state, the getVersion() function always returns null so version-pinning in arcanist doesn't work. This is because the version output is multiline:
➜  ~ shellcheck --version
ShellCheck - shell script analysis tool
version: 0.6.0
license: GNU General Public License, version 3
website: https://www.shellcheck.net
➜  ~

The current regex requires matching beginning and end of the output. By removing those, allowing the version output to be in the middle of other output, I can get version pinning to work:
➜  ~ arc lint --everything
Exception
Linter ArcanistShellCheckLinter requires shellcheck version 0.2.0. You have version 0.6.0.
(Run with `--trace` for a full exception trace.)
➜  ~

Review at https://devcentral.nasqueron.org/D2064


Images

Hi.
Is it possible to get images what this is supposed to look like when Javascript is working correctly?
Thanks!
Chris Bartos
Ohio State Libraries
<EMAIL_ADDRESS>

Quite possibly...lemme see what I can do.


unknow error when start farming

все норм работало, либо обнова вышла, либо что-то рухнуло
такая же ошибка при попытке старта фарма

 all the rules worked, or the round-up came out, or something collapsed same mistake when trying to start a pharmac

Hello @parafius
Thanks for posting the issue.
Your query would be best dealt with by the support team.
Please see the link below to our dedicated support line:
Support : Help Center
Note: Click on the live chat icon at the bottom corner of the page to start a conversation


Automated cherry pick of #900: misc fix:

Cherry pick of #900 on release/2.8.0.
#900: misc fix:

/lgtm
/approve


Update arg arrays from trained model params with names matched in Python

Hi, I would like to do the equivalent in Python to the below R commands, updating arg_arrays with names matched, any method in Python there?
Many thanks!!!
Trying to translate from R to Python:
mx.exec.update.arg.arrays(testExecutor, model$arg.params, match.name=TRUE)
mx.exec.update.aux.arrays(testExecutor, model$aux.params, match.name=TRUE)
mx.exec.update.arg.arrays(testExecutor, list(data=mx.nd.array(t(test.x))),
match.name=TRUE)

Hi, found it ;)
testExecutor.copy_params_from(model.arg_params)
Thanks.


ci: use cache_test_results=auto for non-ci/daily bazel builds

Recently we moved to --cache_test_results=no for CI, and then
daily bazel builds (see #6773 and #6806).  An upshot of this was
that we also moved to --cache_test_results=yes for the other
bazel builds.
However, --cache_test_results=yes is not the same as defaulting
the flag.  In particular, yes indicates that test failures
should be cached, which is undesirable when those tests are flaky.
So restore those other bazel builds to the default caching mode
of --cache_test_results=auto, which always reruns failed tests
(and also reruns under --runs_per_test).

This change is

TIL. Thanks.


ADDED a BASE Contributing.md file, Will edit more

please do consider this PR and i'll be updating more
and add Hacktoberfest tag if possible

#208

Ok ma'am

ma'am done Changing Name to UpperCASE

Ma'am

ma'am please add hacktoberfest tag

ma'am pls add hacktoberfest tag

@prabaljainn thank you, hacktoberfest accepted.


Set up to level

level.SetUpToLevel creates the possibility to set a log level that is enabled  up to the desired level.
This way, one can create different formatters for low levels and high levels.
For example:
    format1 := MustStringFormatter("%{color}%{time:15:04:05.000} %{level:.4s} %{id:03x} %{message}%{color:reset}")
	backend1 := NewLogBackend(os.Stderr, "", 0)
	backendFormatter1 := NewBackendFormatter(backend1, format1)
	backendLeveled1 := AddModuleLevel(backendFormatter1)
	backendLeveled1.SetUpToLevel(INFO, "")

	format2 := MustStringFormatter("%{color}%{time:15:04:05.000} %{longfile}:%{shortpkg}.%{longfunc} ▶ %{level:.4s} %{id:03x} %{message}%{color:reset}")
	backend2 := NewLogBackend(os.Stderr, "", 0)
	backendFormatter2 := NewBackendFormatter(backend2, format2)
	backendLeveled2 := AddModuleLevel(backendFormatter2)
	backendLeveled2.SetLevel(ERROR, "")
	SetBackend(backendLeveled1, backendLeveled2)
	log := MustGetLogger("testing")
	log.Debug("debug")
	log.Info("info")
	log.Error("error")

will result in a format for levels up to INFO and another for ERROR or CRITICAL.

Wouldn't it make more sense to add a SetMaxLevel function and track these levels separately? Please add tests.

I also can't guarantee that I will merge this. It feels like there has to be a cleaner approach.

Sorry for the delay. Wouldn't it be nicer if you created a new backend which adds this functionality? Closing for now. Please open a new PR where you haven't disabled tests.


Update requirements.txt

Pull Request Title
PR for Conflict in Dependency Versions: urllib3 and typing_extensions
Related Issue

#142
Description

Updated the dependency of urllib3
Type

[x] Bug Fix
[ ] Feature Enhancement
[ ] Documentation Update
[ ] Code Refactoring
[ ] Other (please specify):

Proposed Changes

Updated the  requirement to urllib3>=1.26.14

How to Test

Clone the repository.
Install the packages specified in the requirements.txt file using pip.

Checklist

[x] The code compiles successfully without any errors or warnings
[x] The changes have been tested and verified
[ ] The documentation has been updated (if applicable)
[x] The changes follow the project's coding guidelines and best practices
[x] The commit messages are descriptive and follow the project's guidelines
[ ] All tests (if applicable) pass successfully
[x] This pull request has been linked to the related issue (if applicable)

Additional Information

Thanks @admalekar  and @Devasy23  it's working for me as well.


Logitech rgb turned off after installing aurora

Expected behavior:
affter i download aurora, now my logitech 810 only have G icon with  back light, another key have no backlight :(
How often does this problem occur?
now everytime i plugin my keyboard all have no back light :(
What is the version of Aurora you are experiencing this issue with?
i used aurora v.0.6.4b
Does the previous version of Aurora have this issue?
i never used aurora v before that

G810 too.
My Aurora's layout has stop working a few days ago with no reason. I had to follow again the steps for the Logitech Gaming Software integration to have my configuration back.
Have you seen the first-time instructions for Logitech and installed the wrapper?


Import typedorm from private repo

Changes

Import DRM internal package as typeDORM
fix lint/build errors
init release packages for core/common/testing

:tada: This PR is included in version 1.0.0-beta.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0-beta.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0-beta.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Improve discovery

As of now, discovery seems to be pretty spotty and slow. Nodes work and peer with each other, but not consistently.
Related:
#62
#48

Seems to be improved now. Related to the bootstrap peers used. Closing for now.


unclear documentation comments for persistence in workflow-controller-configmap.yaml

Currently workflow-controller-configmap.yaml has
      # save the entire workflow into etcd and DB
      nodeStatusOffLoad: false
      # save completed workloads to the archived, even if disabled, you'll be able to
      # read from the archive
      archive: false

Perhaps more clearer would be "nodeStatusOffLoad if false saves the entire workflow into both etcd and the persistence DB, if true node status is only saved to the persistence DB to avoid the 1MB limit in etcd".
For archive the wording appears to have a typo and is unclear about what can be read from the archive.
Thanks very much for all the great work!

You statement is incorrect - or at least - should be.
Nodes should only be offloaded if nodeStatusOffload: true. Is this not the behavior you're seeing please?

See  #2170

@alexec the linked PR does improve the comment for nodeStatusOffLoad, but not for archive

@alexec the linked PR does improve the comment for nodeStatusOffLoad, but not for archive

better now?

a bit better but what I still don't clearly understand is that if archive is false what gets stored in the persistence DB if nodeStatusOffLoad is false and if nodeStatusOffLoad true?

the two features are independent - the whole workflow is store in the archive, including any data that was offloaded (or not)

So if both nodeStatusOffLoad: false and archive: false then nothing is written to the persistence DB?
And if nodeStatusOffLoad: true and archive: false just the nodeStatus is temporarily written to the DB but then deleted?

correct - the node status is deleted when the workflow is deleted


using different models under bertin

Can we try to train different models like gpt2 or t5/mt5 in the bertin pipeline? gpt2 is more of a priority.

@mrm8488 , based on offline conv, you will be training distillgpt2 on a filtered version of hi, vi, sw and es, and testing on perplexity. We will then try to search for hyper-parameter (grid/random) based on higher cutoff of perplexity, to find optimal perplexity output.


Use shared_ptr in ClientConfig::get/setLoadBalancer

Fixes #650.
Depends on #673
As opposed to the way it was described in the referred issue, we decided to use smart pointers and keep the inheritance.

Linux test PASSed.

Windows test PASSed.

Windows test FAILed.

Linux test FAILed.


Cannot compile "Hello World" example on Windows Azure VM

Finished dev [unoptimized + debuginfo] target(s) in 3.34s
Running target\debug\hellorust.exe
Error: NoAvailablePixelFormat
error: process didn't exit successfully: target\debug\hellorust.exe (exit code: 1)
(I apologise for the formatting. I don't know how to escape backticks here...or if you can)
Terminal output after following through the Hello World portion of the guide and entering cargo run in shell. It installed all the dependencies and only gave up when trying to compile main.rs.
I had similar problems with Bevy but not much luck in tracking down a workaround...

Wow, that's not a use-case I'd anticipated. I've not used Azure VMs at all; I'm assuming it gives you RDP access to a GUI? The pixel format error occurs when the built-in video driver isn't able to find an OpenGL version/screen definition with which it can work. I'm not sure what versions of GL/video drivers are supported in Azure VMs?
I am currently trying to get GL working on a much older version to help with older devices - maybe that'll help too? (I'm running into some oddness in which the GL library lets me ask for old contexts and gives me latest/greatest anyway!)
As a workaround, you might try curses or crossterm for remote access? You can try those by changing your dependency in Cargo.toml to:
bracket_lib = { version = "~0.8", default-features=no, features = [ "curses" ] }

Or:
bracket_lib = { version = "~0.8", default-features=no, features = [ "cross_term" ] }

That won't give you fancy graphics, but will give a text-mode output. In the meantime, I'll keep trying to get older GL profiles working.

Thanks for the update!
bracket-lib = { version = "~0.8", default-features=false, features = [ "curses" ] } worked for me (thanks to 17cupsofcoffee on the rust dev discord)
I don't know if this related now, then, but I'm getting a bunch of "undeclared crate or module rltk errors. I'm guessing I just need to replace all instances of that with bracket-lib though?

I misread the benevolent coder: it should be
rltk = { version = "~0.8", default-features=false, features = [ "curses" ] }
Compiles just fine now. Makes sense...rltk is the wrapper for bracket-lib! Thanks again.


Proposed Analysis to Styling workflow via Widgets

We have a suggestion on a proposed workflow that combines widgets and default styling in the map view when running through analysis methods.
As pointed out here it is difficult to know what fields have been created as a result of an analysis method. It is also difficult to know what styling should be applied to best visualize the results of the analysis.
We have a proposed workflow that we think will more easily guide users through both steps.
1. Automatically Add Widgets from Derived Column(s)
Have a Widget output on the right-hand panel derived from the new fields that have been added as a result of an analysis method

For example, if someone ran Moran’s i, when the analysis is finished, two widgets would show in the right hand panel: quads and significance

2. Styling
The styling defaults we define for each analysis output would be tied to a type of auto styling that is only inside of the map view.

If a user clicks on the tear drop icon on a Widget inside of the map view, the styling on the map will default to our predefined styling for that analysis method

These styles would be based off defaults that we think are most appropriate to display the analysis results.

The user could choose to keep the ‘map view auto style’ or they could choose their own

This would be different than the embed map auto styling

When adding a second, third or Nth analysis, it would override the set Style if selected to do so by the user

cc: @andrewxhill @stuartlynn @ohasselblad @talos

An addendum to step 1. We wouldn't want to add widgets for every new column added to the data, only the ones that are most relevant to the analysis.
Using the same example, Moran's i produces more than just the quads and significance attributes, but those are the only two that we would want added as widgets.
We can help formulate a list of columns that should become widgets based on analysis method.
cc @stuartlynn

I really think we need also a default styling that is not depending on the drop button of the widgets.

i do too... I'm trying to figure out how we can do both.
One idea:
We have default styling that is the same styling as if you clicked on the inside map view tear drop on the widget. When the widget is added, the teardrop is on by default. If you uncheck the widget teardrop, you go back to default default.
Basically, the workflow here would be:

run analysis
widgets added to the view tied to new column(s)
by default, the teardrop would be activated and the default styling for that analysis is there
turn the teardrop off, and the default styling for that analysis goes back to default
user can select their own style or select the default style from the teardrop

But this raises some questions:

if multiple analysis are run, and the user selects default styling, how do we make all the combinations of possible analysis look good together? f
when more than one widget is added as a result of an analysis, which widget should be on by default?

Any other ideas on a workflow here for the styling piece?

My proposal was that we change the behavior of the teardrop slightly

Teardrop symbology probably would need to change
The teardrop is an informed best style based on what is showcased in the widget (aka, autostyle).
When the user clicks it, the teardrop derived style becomes the NEW base style for that map
The teardrop isn't published publically with the map, it is just a shortcut to applying a new Style to the layer

@andrewxhill so what do you see the default map style being when the analysis is finished? I was interpreting what @saleiva was saying as that.
That's why I was thinking that maybe the teardrop derived style should just be on after the analysis is finished which means that the teardrop would be on by default? And then the user can choose to use the teardrop style for their public map if they want or create their own.

Sorry, yes, that is the end of my thought. When a new analysis is applied, there should be two options inside the analysis.

[x] AutoWidget
[x] AutoStyle

So when a user applies that new analysis, it will,

Based off the first checkbox, add a new widget
Based off the second checkbox, apply that autostyle of that Widget, so Teardrop will appear activated for that new widget

The user can then avoid overwriting any of their custom styles by just unchecking the autostyle option.

@piensaenpixel this issue should also be considered with the default analysis styling (https://github.com/CartoDB/cartodb/issues/8162#issuecomment-366651813)

+1 @makella


zfsbootmenu: refactor installation, support system and user runtime hooks

All core components, docs and runtime hooks are handled by a common install_helper that is aware of both dracut and mkinitcpio methods

Installation now adds "system" runtime hooks in addition to those configured by the user; user hooks with names that conflict with system hooks will "mask" the system version

The hooks 10-console-init.sh and xhci-teardown.sh have been elevated to "system" status and are always installed in ZBM images

The zfsbootmenu/hook path has been renamed to zfsbootmenu/pre-init to avoid confusion with the new zfsbootmenu/hooks directory of system runtime hooks, and the dracut-only hook scripts have been moved to the dracut module

A new zbm.skip_hooks command-line argument allows a comma-separated list of hooks to skip (matched on basename only) to provide an easy mechanism for skipping default hooks without zbm.hookroot

Create the zfsbootmenu-run-hooks libexec helper, allowing easy addition of future hook points.

I've tested this in various forms locally, everything looks good to me.


Creating a new profile and entering a raid does not enable snow if the event is active

Requires a client restart to enable it.

Originally written by chomp

Fixed with: https://dev.sp-tarkov.com/SPT-AKI/Server/commit/5e1da93a69b80cb35411d6020ea4a79daa119163

Originally written by chomp

tested with a new profile, works, closing

Originally written by CWX


[BUG] Nuxt 3 Warning: Could not access pt in PrimeVue

Hello,
I'm currently using PrimeVue in a Nuxt 3 project and I've encountered a warning in the console related to the pt property.
Description:
When I run my Nuxt 3 application with PrimeVue, I get the following warning in the console:
Could not access `pt`. The only available runtime config keys on the client side are `public` and `app`.

This warning appears every time I load a page that uses a PrimeVue component. Everything else works fine.
Here's a snippet of my code:
<template>

Pipelines Visualization

Nuxt 3 + PrimeVue + Tailwind

        <Button class="p-0 mt-4" @click="addEvent">Add Event</Button>

</template>

Using any PrimeVue component triggers this warning.

Here's my nuxt.config.ts:
import path from 'path';

export default defineNuxtConfig({
  devtools: { enabled: true },
  css: ['~/assets/css/main.css','~/node_modules/primeicons/primeicons.css'],
  modules: ['nuxt-primevue', '@nuxtjs/tailwindcss'],
  primevue: {
    options: {
      unstyled: true,
    },
    importPT: { from: path.resolve(__dirname, './presets/my-preset/') }
  },
  nitro: {
    serverAssets: [
        {
            baseName: 'presets',
            dir: '../presets'
        }
    ]
}
})

Expected behavior:
I expect not to see any warnings in the console related to PrimeVue when running my Nuxt 3 application.
Environment:

Nuxt version: 3.12.1
PrimeVue version: 3.52.0 (Happens with v4 Beta 4 as well)
Browser: Google Chrome

Thank you for your help with this issue.

This issue pertains to PrimeVue.
The issue has been resolved in PrimeVue v4.0.0-rc.2, but it remains unresolved in version 3.
Nuxt Discussion #27645.

It'll be fixed in v3.53.
I think it's okay to refer to this and solve it temporarily.

It'll be fixed in v3.53.
I think it's okay to refer to this and solve it temporarily.

Thank you!