What's the suitable way to know whether the sql is executed successfully or not?

I am not familiar with futures mechanism. so ask for help...
If the sql don't execute successfully, how can i get err-no and err-message from mysql?
thanks~
Now I do it by this way:
import logging
from tornado import ioloop, gen
from tornado_mysql import pools

dbpool = pools.Pool(...)

@gen.coroutine
def run_sql(sql):
    success = False
    try:
        cur = yield dbpool.execute(sql)
        success = True
    except:
        logging.error('mysql execution error')

    if success:
        # do sth.

https://github.com/PyMySQL/Tornado-MySQL/blob/master/tornado_mysql/err.py
You can catch MySQLError and inspect it's .args.


Enable accidentally (and forgotten) skipped integration test case for NetworkPolicy controller

How to categorize this PR?

/area dev-productivity
/kind test
What this PR does / why we need it:
Enable accidentally (and forgotten) skipped integration test case for NetworkPolicy controller
Special notes for your reviewer:
/cc @timuthy
Release note:

NONE

/retest


Add Android 2.0 deprecated API info to release notes

Adds info on the deprecated APIs for the Android 2.0 release notes.

@praveek @calebk1 @ahmyr After Praveen pointed out that not all of the deprecated APIs were listed on the Feb 23 release notes, i have decided to remove the table and deprecated API part from those release notes. I think we should just have the specific API deprecations noted for each respective extension release which is what was being done before, but the registerExtension API was not noted in the Core release notes so i have added those here.


feat: update deps

Description

feat: update deps

Testing required outside of automated testing?

[x] Not Applicable

Screenshots (if appropriate):

[x] Not Applicable

Rollback / Rollforward Procedure

[ ] Roll Forward
[x] Roll Back

Reviewer Checklist

[ ] Description of Change
[ ] Description of outside testing if applicable.
[ ] Description of Roll Forward / Backward Procedure
[ ] Documentation updated for Change

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


rdma-core: 33.1 -> 34.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/linux-rdma/rdma-core/releases.
meta.description for rdma-core is: "RDMA Core Userspace Libraries and Daemons"
meta.homepage for rdma-core is: "https://github.com/linux-rdma/rdma-core"
meta.changelog for rdma-core is: ""
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 34.0 with grep in /nix/store/0bk9ws7rxcy2kakn7ljxwnp46znpzyqd-rdma-core-34.0

directory tree listing: https://gist.github.com/1a3044e257f82f1a3f422c6361fd847d

du listing: https://gist.github.com/355a1cff186b7b669bf01b9cda2f72b4

Rebuild report (if merged into master) (click to expand)

530 total rebuild path(s)

194 package rebuild(s)

194 x86_64-linux rebuild(s)
170 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
166 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
EBTKS
bareos
bicgl
bicpl
cdo
ceph
ceph-client
ceph-dev
cloudcompare
cntk
conglomerate
dl-poly-classic-mpi
eccodes
elmerfem
ezminc
freecad
gdal
gdal_2
getdp
globalarrays
gmt
gplates
grass
grib-api
gromacsDoubleMpi
gromacsMpi
hdf5-mpi
highfive-mpi
hpcg
hpl
inormalize
ior
lammps-mpi
libLAS
libceph
libminc
librsb
mapnik
mapproxy
merkaartor
migrate
minc_tools
minc_widgets
mni_autoreg
mpi
mysql-workbench
n3
nco
ncview
netcdf

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/0bk9ws7rxcy2kakn7ljxwnp46znpzyqd-rdma-core-34.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A rdma-core https://github.com/r-ryantm/nixpkgs/archive/aa84c57e7fe66c6b68fca6256bea80562d2ac425.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/0bk9ws7rxcy2kakn7ljxwnp46znpzyqd-rdma-core-34.0
ls -la /nix/store/0bk9ws7rxcy2kakn7ljxwnp46znpzyqd-rdma-core-34.0/bin

Pre-merge build results
NixPkgs review skipped

Maintainer pings
cc @markuskowa for testing.

Looks good, does not seem to break direct dependencies. nixos slurm test and rxe test succeed.


Introduce fixture for hermetic CallComposite tests

What
Introduce a separate test fixture for the hermetic CallComposite tests.
Why
The dedicated fixture avoids the need to create real Azure Communication Services users. It does not interact with the backend services at all.
How Tested
Ran hermetic tests locally!

This was a really fun PR to look over!
Thanks for assigning me to this one Prathmesh!

Thanks for splitting the fixtures and tests into hermetic and live folders. Just for my knowledge, is hermetic the right word? Wouldn't changes in Calling SDK interfaces/class (though rare) would cause a mock adapter to change too?

Thanks for splitting the fixtures and tests into hermetic and live folders. Just for my knowledge, is hermetic the right word? Wouldn't changes in Calling SDK interfaces/class (though rare) would cause a mock adapter to change too?

These tests are hermetic in that they do not access any environment resources (network / persistent storage etc.) at runtime. So running them in different environments without any credentials etc will give the same results. Contrast with live tests that depend on the backend services to be accessible and stable.
The term "hermetic" Is commonly used in this case: https://blog.testproject.io/2021/09/13/my-recent-obsession-with-hermetic-tests/


Browser Bundle

Similarly to how algosdk has a minified browser bundle, could one be created for this library so that it can be imported from CDN in the browser?
https://github.com/algorand/js-algorand-sdk#browser

Makes sense, we've added to the enhancements backlog for prioritisation.


DropTracker 3.2

Just added in the ability to hide PMs. It may be a while before my next push so wanted to get this change out there

Just going to redo this


Violet Evergarden added

Looks like there are some merge conflicts in your Fork. Please sync your Fork and then open the Pull Request. Thank you.


repin requirements

Description
Repin because why not.
Depends on #188
Test plan
github actions yo.

is this just updating some dependencies from another PR? I'm confused lol

This is just repinning dependencies to the latest version.


Designer should not crash on incorrect YAML syntax

Example https://github.com/apache/camel-karavan/issues/652


chat_with_retrieval not running

Hello,
I am trying to use the scripts in the chat_with_retrieval folder .
Created a python environment with requirements. Unfortunatelly the streamlit app is crashing (please see the attached image).
I also listing the console output:
(generative_ai_with_langchain-env) c0274@c0274-i7:~/generative_ai_with_langchain/chat_with_retrieval$ streamlit run app.py
You can now view your Streamlit app in your browser.
Local URL: http://localhost:8501
Network URL: http://<IP_ADDRESS>:8501
INFO:root:[Document(page_content='Madam Speaker, ...
...
metadata={'source': '/tmp/tmpa4gyz1pv/state_of_the_union.txt'})]
2024-05-13 18:23:37.354 Uncaught app exception
Traceback (most recent call last):
File "/home/c0274/generative_ai_with_langchain/generative_ai_with_langchain-env/lib/python3.10/site-packages/langchain/vectorstores/docarray/base.py", line 19, in _check_docarray_import
import docarray
File "/home/c0274/generative_ai_with_langchain/generative_ai_with_langchain-env/lib/python3.10/site-packages/docarray/init.py", line 5, in
from docarray.array import DocList, DocVec
File "/home/c0274/generative_ai_with_langchain/generative_ai_with_langchain-env/lib/python3.10/site-packages/docarray/array/init.py", line 1, in
from docarray.array.any_array import AnyDocArray
File "/home/c0274/generative_ai_with_langchain/generative_ai_with_langchain-env/lib/python3.10/site-packages/docarray/array/any_array.py", line 22, in
from docarray.base_doc import BaseDoc
File "/home/c0274/generative_ai_with_langchain/generative_ai_with_langchain-env/lib/python3.10/site-packages/docarray/base_doc/init.py", line 1, in
from docarray.base_doc.any_doc import AnyDoc
File "/home/c0274/generative_ai_with_langchain/generative_ai_with_langchain-env/lib/python3.10/site-packages/docarray/base_doc/any_doc.py", line 3, in
from .doc import BaseDoc
File "/home/c0274/generative_ai_with_langchain/generative_ai_with_langchain-env/lib/python3.10/site-packages/docarray/base_doc/doc.py", line 22, in
from pydantic.main import ROOT_KEY
ImportError: cannot import name 'ROOT_KEY' from 'pydantic.main' (/home/c0274/generative_ai_with_langchain/generative_ai_with_langchain-env/lib/python3.10/site-packages/pydantic/main.py)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/c0274/generative_ai_with_langchain/generative_ai_with_langchain-env/lib/python3.10/site-packages/streamlit/runtime/scriptrunner/script_runner.py", line 600, in _run_script
exec(code, module.dict)
File "/home/c0274/generative_ai_with_langchain/chat_with_retrieval/app.py", line 35, in
CONV_CHAIN = configure_retrieval_chain(
File "/home/c0274/generative_ai_with_langchain/chat_with_retrieval/chat_with_documents.py", line 108, in configure_retrieval_chain
retriever = configure_retriever(docs=docs, use_compression=use_compression)
File "/home/c0274/generative_ai_with_langchain/chat_with_retrieval/chat_with_documents.py", line 47, in configure_retriever
vectordb = DocArrayInMemorySearch.from_documents(splits, embeddings)
File "/home/c0274/generative_ai_with_langchain/generative_ai_with_langchain-env/lib/python3.10/site-packages/langchain/vectorstores/base.py", line 417, in from_documents
return cls.from_texts(texts, embedding, metadatas=metadatas, **kwargs)
File "/home/c0274/generative_ai_with_langchain/generative_ai_with_langchain-env/lib/python3.10/site-packages/langchain/vectorstores/docarray/in_memory.py", line 67, in from_texts
store = cls.from_params(embedding, **kwargs)
File "/home/c0274/generative_ai_with_langchain/generative_ai_with_langchain-env/lib/python3.10/site-packages/langchain/vectorstores/docarray/in_memory.py", line 38, in from_params
_check_docarray_import()
File "/home/c0274/generative_ai_with_langchain/generative_ai_with_langchain-env/lib/python3.10/site-packages/langchain/vectorstores/docarray/base.py", line 29, in _check_docarray_import
raise ImportError(
ImportError: Could not import docarray python package. Please install it with pip install "langchain[docarray]".
Any clue is very welcome.
langchain[docarray] is already installed .

This is a very strange error. This smells of an environment problem to me. Could you please check if you have a directoryhome/c0274/generative_ai_with_langchain/generative_ai_with_langchain-env/lib/python3.10/site-packages/docarray?

Same issue for me and I do have the directory you mention

This should only have been an issue of installing docarray as indicated in the error. Anyway, I've made a few changes to the environment (requirements.txt, conda yaml). Please check again with the new environment. There's also a new branch softupdate with a later version of LangChain that should work.


[sil] Eliminate end_borrow_argument now that end_borrow has a single …

…operand.
I changed all of the places that used end_borrow_argument to use end_borrow.
rdar://33440767

@swift-ci smoke test

While looking at those failing tests I discovered we aren't strictly verifying guaranteed arguments as much as we can. The behavior that we want is that a guaranteed argument must be contained strictly within the parent borrowed scope. I have an additional commit that is going to tighten this up and adds a bunch of tests to check the behavior.

It is ok to ignore that for now since SILGen doesn't emit +0 non-function arguments.

@swift-ci smoke test and merge

@swift-ci smoke test and merge

@swift-ci smoke test and merge

Lets try this one last time.

@swift-ci smoke test and merge

@swift-ci smoke test and merge

@swift-ci smoke test and merge


JVM crash while on Stampede replication

2016-12-16T10:12:48.988 INFO 'StampedeService STARTING' c.t.s.StampedeService Starting up ToroDB Stampede
2016-12-16T10:12:48.999 INFO 'StampedeService STARTING' c.t.b.p.PostgreSqlDbBackend Configured PostgreSQL backend at localhost:5432
2016-12-16T10:12:49.455 INFO 'PostgreSqlDbBackend STARTING' c.t.b.AbstractDbBackendService Created pool session with size 28 and level TRANSACTION_REPEATABLE_READ
2016-12-16T10:12:49.496 INFO 'PostgreSqlDbBackend STARTING' c.t.b.AbstractDbBackendService Created pool system with size 1 and level TRANSACTION_REPEATABLE_READ
2016-12-16T10:12:49.511 INFO 'PostgreSqlDbBackend STARTING' c.t.b.AbstractDbBackendService Created pool cursors with size 1 and level TRANSACTION_REPEATABLE_READ
2016-12-16T10:12:50.119 INFO 'BackendBundleImpl STARTING' c.t.b.m.AbstractSchemaUpdater Schema 'torodb' not found. Creating it...
2016-12-16T10:12:50.351 INFO 'BackendBundleImpl STARTING' c.t.b.m.AbstractSchemaUpdater Schema 'torodb' created
2016-12-16T10:12:50.509 INFO 'StampedeService STARTING' c.t.s.StampedeService Database is not consistent. Cleaning it up
2016-12-16T10:12:50.572 INFO 'StampedeService STARTING' c.t.s.StampedeService Replicating from seeds: localhost:27017
2016-12-16T10:12:50.901 INFO 'MongodbReplBundle STARTING' c.t.m.r.MongodbReplBundle Starting replication service
2016-12-16T10:12:51.073 INFO 'topology-executor-0' c.t.m.r.t.TopologyCoordinator Waiting for 2  pings from other members before syncing
2016-12-16T10:12:51.089 INFO 'topology-executor-0' c.t.m.c.p.MemberHeartbeatData Member ushuaia:27017 is now in state RS_PRIMARY
2016-12-16T10:12:52.074 INFO 'topology-executor-0' c.t.m.r.t.TopologyCoordinator Waiting for 1  pings from other members before syncing
2016-12-16T10:12:53.075 INFO 'topology-executor-0' c.t.m.r.t.TopologyCoordinator Waiting for 1  pings from other members before syncing
2016-12-16T10:12:54.096 INFO 'topology-executor-0' c.t.m.r.t.TopologyCoordinator syncing from: ushuaia:27017
2016-12-16T10:12:54.096 INFO 'TopologyService STARTING' c.t.m.r.t.TopologyService Topology service started
2016-12-16T10:12:54.145 WARN 'ReplCoordinator STARTING' c.t.m.r.ReplCoordinator loadStoredConfig() is not implemented yet
2016-12-16T10:12:54.145 INFO 'ReplCoordinator STARTING' c.t.m.r.ReplCoordinator Database is not consistent.
2016-12-16T10:12:54.146 INFO 'MongodbReplBundle STARTING' c.t.m.r.MongodbReplBundle Replication service started
2016-12-16T10:12:54.146 INFO 'StampedeService STARTING' c.t.s.StampedeService ToroDB Stampede is now running
2016-12-16T10:12:54.147 INFO 'repl-coord-starting-recovery' c.t.m.r.ReplCoordinatorStateMachine Starting RECOVERY mode
2016-12-16T10:12:54.164 INFO 'RecoveryService' c.t.m.r.RecoveryService Starting RECOVERY service
2016-12-16T10:12:54.165 INFO 'RecoveryService' c.t.m.r.RecoveryService Starting initial sync
2016-12-16T10:12:54.180 INFO 'RecoveryService' c.t.s.DefaultConsistencyHandler Consistent state has been set to 'false'
2016-12-16T10:12:54.182 INFO 'RecoveryService' c.t.m.r.RecoveryService Using node ushuaia:27017 to replicate from
2016-12-16T10:12:54.201 INFO 'RecoveryService' c.t.m.r.RecoveryService Remote database cloning started
2016-12-16T10:12:54.286 INFO 'RecoveryService' c.t.b.SharedWriteBackendTransactionImpl Created internal index did_pkey for table oplog_replication
2016-12-16T10:12:54.320 INFO 'RecoveryService' c.t.b.SharedWriteBackendTransactionImpl Created internal index rid_pkey for table oplog_replication_lastappliedoplogentry
2016-12-16T10:12:54.330 INFO 'RecoveryService' c.t.b.SharedWriteBackendTransactionImpl Created internal index did_idx for table oplog_replication_lastappliedoplogentry
2016-12-16T10:12:54.340 INFO 'RecoveryService' c.t.b.SharedWriteBackendTransactionImpl Created internal index did_seq_idx for table oplog_replication_lastappliedoplogentry
2016-12-16T10:12:54.387 INFO 'RecoveryService' c.t.m.r.RecoveryService Local databases dropping started
2016-12-16T10:12:54.406 INFO 'RecoveryService' c.t.m.r.RecoveryService Local databases dropping finished
2016-12-16T10:12:54.406 INFO 'RecoveryService' c.t.m.r.RecoveryService Remote database cloning started
2016-12-16T10:12:54.414 INFO 'RecoveryService' c.t.m.u.c.AkkaDbCloner Collection aht.githubarchive will be cloned
2016-12-16T10:12:54.416 INFO 'RecoveryService' c.t.m.r.c.i.DropCollectionReplImpl Dropping collection aht.githubarchive
2016-12-16T10:12:54.416 INFO 'RecoveryService' c.t.m.r.c.i.DropCollectionReplImpl Trying to drop collection aht.githubarchive but it has not been found. This is normal when reapplying oplog during a recovery. Ignoring operation
2016-12-16T10:12:54.416 INFO 'RecoveryService' c.t.m.r.c.i.CreateCollectionReplImpl Creating collection aht.githubarchive
2016-12-16T10:12:54.426 INFO 'RecoveryService' c.t.m.u.c.AkkaDbCloner Cloning collection data aht.githubarchive into aht.githubarchive
2016-12-16T10:12:55.201 INFO 'db-cloner-1' c.t.b.SharedWriteBackendTransactionImpl Created index githubarchive__id_x_a_idx for table githubarchive associated to logical index aht.githubarchive._id_
2016-12-16T10:13:04.575 INFO 'db-cloner-3' c.t.m.u.c.AkkaDbCloner 11000 documents have been cloned to aht.githubarchive
2016-12-16T10:13:14.706 INFO 'db-cloner-2' c.t.m.u.c.AkkaDbCloner 114000 documents have been cloned to aht.githubarchive
2016-12-16T10:13:24.717 INFO 'db-cloner-2' c.t.m.u.c.AkkaDbCloner 236000 documents have been cloned to aht.githubarchive
2016-12-16T10:13:34.815 INFO 'db-cloner-1' c.t.m.u.c.AkkaDbCloner 352000 documents have been cloned to aht.githubarchive
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f352d024ec2, pid=11621, tid=0x00007f34e1446700
#
# JRE version: Java(TM) SE Runtime Environment (8.0_111-b14) (build 1.8.0_111-b14)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.111-b14 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# j  com.torodb.backend.postgresql.converters.sql.StringSqlBinding.set(Ljava/sql/PreparedStatement;ILjava/lang/Object;)V+4
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /tmp/kk/hs_err_pid11621.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#
[1]    11621 abort      /tmp/torodb-stampede-1.0.0-beta1/bin/torodb-stampede --backend-database torod

JVM trace file attached below:
hs_err_pid11621.log.txt

It cannot be reproduced


Using GasToken to stabilize gas fees

https://gastoken.io/

I would like to read a blog post specifically dealing with how to use GasToken.


Regarding results

Thank you for sharing the code!
I generated and tested 50,000 samples with the LDM-4 checkpoint that you provided, but I got IS 58.2. I think I did something wrong, and I hope you can provide some guidance.

@yoohyewony Hi, I also encountered this problem, the IS metrics of all different bits are generally low, but FID and sFID are good. Did you find any way to reproduce the IS results in the paper?

No I still have the same problem :(

Hey guys, do the images you generated look normal? The results of IS and FID reported in paper are obtained by this tool

I used the same tool (which is provided by openAI guided diffusion) and generated images look normal. I don't know why only IS value is far below the paper.

Yes, the images are also good, and only IS is far below than report. Can you provide the exact setting to reproduce the results? Like ddim_steps, ddim_eta, and scale for sampler, and do you generate 50 images for each class? Thanks a lot!

It's 20 steps, eta=0, scale=3, 50 images for each class. However, since the images look proper, I don't think the generation configuration is the reason for the low IS...

Yes, the images are also good, and only IS is far below than report. Can you provide the exact setting to reproduce the results? Like ddim_steps, ddim_eta, and scale for sampler, and do you generate 50 images for each class? Thanks a lot!

It's 20 steps, eta=0, scale=3, 50 images for each class. However, since the images look proper, I don't think the generation configuration is the reason for the low IS...

Thanks a lot! Looks like i use the same setting, any idea how to fix this? Or could you provide the scripts for generating the .npz file, in case that i miss anything important. Also did you modify the config in https://github.com/openai/guided-diffusion/blob/main/evaluations/evaluator.py line 23-24?
FID_POOL_NAME = "pool_3:0" FID_SPATIAL_NAME = "mixed_6/conv:0"

Yes, the images are also good, and only IS is far below than report. Can you provide the exact setting to reproduce the results? Like ddim_steps, ddim_eta, and scale for sampler, and do you generate 50 images for each class? Thanks a lot!

It's 20 steps, eta=0, scale=3, 50 images for each class. However, since the images look proper, I don't think the generation configuration is the reason for the low IS...

Thanks a lot! Looks like i use the same setting, any idea how to fix this? Or could you provide the scripts for generating the .npz file, in case that i miss anything important. Also did you modify the config in https://github.com/openai/guided-diffusion/blob/main/evaluations/evaluator.py line 23-24? FID_POOL_NAME = "pool_3:0" FID_SPATIAL_NAME = "mixed_6/conv:0"

No, I did not modify this config. I update the script to generate 50k samples in scripts/generate_samples_4_evaluation_FP.py, you may have a try.

Do you use the imagenet reference batch provided here?

Do you use the imagenet reference batch provided here?

Yes, I use the ImageNet 256x256 reference batch.

@cantbebetter2 Hi, can you get the good FID and sFID? I have a problem to reproduce the results. I doubt it's my wrong settings. I try to set 20 steps, eta=0, scale=3 for the LDM-4 ImageNet, and keep the epoch of training as 160 (This is the default setting in open source code). Can you share your setting? Very much looking forward to your reply! Thanks!


Updated to install via dpkg

Now that deb packages is available the installation can be done using dpkg. I've updated the docs to reflect that.

@yooakim : Thanks for your contribution to the Azure documentation! The author, @stevestein, has been notified to review your proposed change.

@yooakim - The update looks good, thanks!
#sign-off - this PR is ready to merge.


Snippet support

I have been looking into kak-lsp's snippet support. From the docs it seems like there should be support for snippets: https://github.com/kak-lsp/kak-lsp#snippets. In my configuration I've enabled snippet support with snippet_support = true.
Now I've tested this with the typescript language server in a javascript file. The ts language server is working as expected. I would expect common patterns like a for loop to be completed as a snippet, as can be seen in the vscode docs here for example: https://code.visualstudio.com/docs/editor/userdefinedsnippets#_builtin-snippets. But that does not work with kak-lsp out of the box, all that happens is that the language server in kakoune suggests completing the for keyword.
The documentation on kak-lsp's snippet support is a little sparse. Should there be autocompletion via snippets for common language features like a for loop, a switch, etcetera? Does the user need to install these snippets themselves?

yeah snippets are supported (see 22b0602f58ca2815c76ed35baef190ef6eeddc93 for how they usually work) but we don't have VSCode's extra user-defined snippets. They need to come from the language server. With rust-analyzer there are lots of snippets.
user-defined snippets could go into a dedicated snippets plugin

Ideally the the language server supplies snippets, then it works for all editors.
it's possible to add a new completer option that works like lsp_completions.
It's probably not ergonomic because you'd need to match a few implementation details.


added windows 11

after reading this article, i found windows 11 is missing so i added windows 11.

Thank you @RAJU2529 @JohanFreelancer9


⚠ Bofrost.es has degraded performance

In f50110b, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1628 ms

Resolved: Bofrost.es performance has improved in d8f0990 after 17 minutes.


can i use alamofire at my project with minimum deployment target 8.0 and  support swift 3.0

Swift 3 is compatible with iOS 8 and newer.
So the same question here, why did limit to the minimum iOS Platform 9?
Or some way to work around when use iOS 8 with Alamofire 4.0. Thanks.

#1367  look this

Same question . Consider whether or not to change a library...Be crazy...

Please see #1367 and #1490.
Cheers. 🍻

@cnoon It looks not tasteful, we cannot drop iOS 8 users. Is there any chance to support iOS 8 with Alamofire 4.0+? We have to support iOS 8+, and we need Swift 3+.

Same issue here. I want Swift 3.0, but then I have to drop macOS 10.10 support. It's really a hard decision.

I want both Swift3 and iOS8 too。where
is my way?

Similar situation here, temporarily forked Alamofire to support iOS 8 until we drop it. You can find it here: https://github.com/rebe1one/Alamofire
Given that all the iOS 9+ functionality I see being used is streaming, I am wondering why you guys didn't just mark them available for 9+ only. It doesn't seem like much to support.


perf: benchmark datasets again megatronlm

This PR includes multiple changes, which were initially separated, but were added with the common goal to make our dataset utilities achieve a competitive performance with MegatronLM's Dataset variant.
Therefore this PR holds:

#24 - is added here, since the way of loading data changed due to performance reason. It still includes iso-8859-1 as default encoding due to incompatibilities with existing OpenGPT-X Datasets. See #24 for more details. (Closing https://github.com/Modalities/modalities/pull/24 hence)
#20 - in order to have the prepared (indexed, tokenized) datasets as small as possible, this feature was added as well. The hope was to gain some speed with it, but any increase was negligible.
#23 - the intial motivation for these changes

In order to achieve similar performance to MegatronLM, several things were changed:

tokenization during preparation is now parallelized via multiprocessing
unnecessary read-access during index creation using np.memmap got replaced with simple file.seek(), file.read() usage
made any PackedDataset use one central np.memmap, instead of singular access attempts and combined it with more numpy parsing in general, instead of using python builtins.

In order to reproduce the numbers of the benchmark, one requires a jsonl-file with a respective size and a parallel opengptx_data setup

@ndoll1998 - reviewer

related to #20 #23

merging this, since all points got verified and no feedback happened for the "discussion" points during the last 4 weeks. Therefore I am assuming them to be not critical.


Improve diff with "\r\n" and "\n"

The output produced by a difference with new lines is not very clear.
To reproduce :
#[test]
fn f() {
    pretty_assertions::assert_eq!("\n", "\r\n");
}

thread 'test::f' panicked at 'assertion failed: `(left == right)`

Diff < left / right > :

I don't know if that has not been thought or if I am doing something wrong.

Thanks for the report. This looks like an issue in the underlying diff, and transitively, std crates, whereby 'lines' are created by splitting on \n characters, and then any trailing \r characters are stripped:

diff::lines
std::str::lines

I think a resolution to this issue would take one of two approaches:

Don't actually fix the underlying issue - detect when pretty_assertions can't print a good diff, and show a warning to the user.

For example: "Warning: values were different, but no line diff was generated. Do your values have the same line endings?"

Handle differing line endings correctly.

Detect the line ending type used by one value.

optional: run it on both values, and print a user warning if we think the values have different line endings

Use that to split both values explicitly, don't strip trailing \rs print a diff as normal

I know that line ending detection is possibly Hard, and would probably require a linear pass over the diffed values. Might not be a big a deal as I initially think though.
One benefit of the first approach is that it would be a catch-all to warn about other edge cases such as this, which don't produce good output. We could even make it an error-report style message, like "please open an issue at github.com/... with the following details", but that might actually be annoying to users if seen repetitively during testing.

For anyone wanting to pick up the first approach (print a warning on no diff), the following diff may be useful:

At the point we iterate through changes, accumulate some stats about number of Both, Left and Right changes. Return this from the printing function.
The caller of the printing function can then decide what to do if, e.g. there are only Both changes (no diff).

diff --git a/pretty_assertions/src/printer.rs b/pretty_assertions/src/printer.rs
index af3e3e6..6edba1e 100644
--- a/pretty_assertions/src/printer.rs
+++ b/pretty_assertions/src/printer.rs
@@ -89,7 +89,7 @@ pub(crate) fn write_lines<TWrite: fmt::Write>(
     let mut previous_deletion = LatentDeletion::default();

     while let Some(change) = changes.next() {
-        match (change, changes.peek()) {
+        match (dbg!(change), changes.peek()) {
             // If the text is unchanged, just print it plain
             (::diff::Result::Both(value, _), _) => {
                 previous_deletion.flush(f)?;
@@ -594,5 +594,23 @@ Cabbage"#;

             check_printer(write_lines, left, right, &expected);
         }
+
+        /// Test diffing newlines from different conventions.
+        ///
+        /// See: https://github.com/colin-kiegel/rust-pretty-assertions/issues/100
+        #[test]
+        fn different_newlines() {
+            // The below inputs caused an output with no visible diff
+            let left = "\r\n";
+            let right = "\n";
+            let expected = format!(
+                "
+
+Warning: No diff generated for different values.
+",
+            );
+
+            check_printer(write_lines, left, right, &expected);
+        }
     }
 }

I'm gonna try the first approach.


Fix scope on $root_group

Without this change, permitting root login attempts to create an
ssh::allowgroup resource with an undefined title.

Thanks!


Release 5.2.0

Could you release a version 5.2.0 to crates.io soon? I ask because:

#37, restoring compatibility with stable Rust, has been merged but not released
The last stable-compatible version, 4.1.0, now results in a future-compatibility warning in Rust 1.68.0 (due to using an old version of nom).

Done! Thank you!

It's working. Thanks!


Add code of conduct

Hytest should have a code of conduct, something along the lines of: https://github.com/pydata/xarray/blob/main/CODE_OF_CONDUCT.md

agree -- no code of conduct that I know of, but there is a CONTRIBUTING in doc... related but separate.


Wrong Inception Score Calculation

When running my own inception score calculation script I get a way higher Inception Score then your script is returning and that is reported in the paper. My script however gives around the same inception score when running on other models as reported from the authors of the other models. Also, your inception score is lower than the one reported in other papers that are using a GAN model, although your images are way better quality wise as the images generated by such a GAN model.
I haven't debugged your inception calculation script but I do think, that there is something wrong, as the inception score should be way better (between 25 and 35 according to my script, depending on the settings used in your model).

OMG, thank you very much for your feedback! I will carefully review the relevant code later. I apologize for being busy with other work recently.
Additionally, most other works employing GANs have some methodological issues because they use the uncorrected original dataset released in 2017, which has been questioned for its potential design flaws. Experiments on that dataset have resulted in surprisingly high classification accuracies, indicating that the generated results are usually correct. Our method was initially trained and tested on that dataset as well. I remember this because during one test, the accuracy exceeded 90% or 95% (probably, I can't remember clearly), which made me question the validity of the experimental results. This prompted a thorough examination of the dataset and related literature, and we then used its revised version for scientificity.
Another potential problem with using GANs is that they were trained on very few images, causing the GAN to overfit to these images and potentially generate only one of the 40 categories regardless of the input. Considering that IS measures image quality (how recognizable they are) and diversity (whether the number of generated images across different categories is balanced), their results might be very high. This is mainly because their method showed very high generation accuracy on a flawed dataset, resulting in almost all the generated images being correct, with a similar number of images generated across different categories. Therefore, using self-trained GANs might make it challenging to accurately evaluate using IS.

Thank you very much.! I have uploaded a new script for calculating IS. Besides, I also uploaded a script for calculating FID.

Awesome, so what are the scores you are getting?

Really better than I expected. The average IS is 30.9985, and the average FID is 126.6576.

@RomGai Could you share your source for the dataset being corrected?

@RomGai Could you share your source for the dataset being corrected?

Please refer to "README" → "Preparation" → "Download required files" → "3"; the data is correct.


Perl

Update to CB3, add perl / tk / gettext support. Fixes #12, closes #14, and fixes #40.
A bunch of overlap with changes from AnacondaRecipes and probably should have just merged that, but they switch git sources on Windows and I don't know whether we want to do that or not? It wouldn't have been a clean merge anyway, we can always sync up later anyway.
Note that gettext is not pinned at all. It's totally backwards-compatible (except for an SONAME change in 0.19.8 that was undone in <IP_ADDRESS>; we never packaged the broken one), so we don't really need to.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

FYI this is passing @conda-forge/git.


Flip a sprite

This is not necessarily an issue but is it possible to flip a sprite? I tried to set a negative xScale  but it is not mirroring the svg texture as I would expect.

The way I've gotten around this is to flip the sprite in an image editor, import it as a second image, then set body.render.sprite.texture to the reversed sprite when you want it to reverse.

Yeah it's not supported in the built in renderer I'm afraid, what @jeff-v says sounds like a fine solution, thanks!

Using patch-package:
diff --git a/node_modules/matter-js/build/matter.js b/node_modules/matter-js/build/matter.js
index b36c3f5..b9c134e 100644
--- a/node_modules/matter-js/build/matter.js
+++ b/node_modules/matter-js/build/matter.js
@@ -8984,6 +8984,7 @@ var Mouse = _dereq_('../core/Mouse');

                     c.translate(part.position.x, part.position.y);
                     c.rotate(part.angle);
+                    part.render.sprite.flip && c.scale(-1, 1);

                     c.drawImage(
                         texture,
@@ -8994,6 +8995,7 @@ var Mouse = _dereq_('../core/Mouse');
                     );

                     // revert translation, hopefully faster than save / restore
+                    part.render.sprite.flip && c.scale(-1, 1);
                     c.rotate(-part.angle);
                     c.translate(-part.position.x, -part.position.y);
                 } else {

In the body:
    sprite: {
      texture: Cat,
      yScale: 0.1,
      xScale: 0.1,
      flip: false
    },

When changing directions:
body.render.sprite.flip = true;

Note that this only works for horizontal, if you want vertically then need to improve to support both axis. Something like:
c.scale(
  part.render.sprite.xFlip ? -1 : 1,
  part.render.sprite.yFlip ? -1 : 1
);

Can you please have an instruction for how to use that patch package?


Open Mainframe Education annual review - 5/26

@Vallau01 Note that Open Mainframe Education is up for annual review at the TAC meeting on 5/26; let @yarille know if that time still works for you.,

Renewed - https://github.com/openmainframeproject/omp-landscape/commit/33eae862f533d54d8b627c525179ac8fd7782461


Refactor WebXRHandTracking

This is a pretty substantial refactor of the WebXRHandTracking feature, which yields about a 10-15 fps improvement on HoloLens with BabylonNative.
These images kinda look the same, but the left is a representative frame timing of the original (25-35 FPS) and the right is a representative frame timing after the refactor (40-50 FPS):

The main things I did were:

Refactor the IWebXRHandTrackingOptions to make them a bit clearer by more explicitly separating hand and joint mesh options
Move hand mesh ownership out of WebXRHand and into WebXRHandTracking (fixes #10453)
Refactor the default rig mapping to generate something closer to what a user would give us, and make it easier to swap out for a different default model in the future if we choose to do so
Use XRFrame.fillPoses and XRFrame.fillJointRadii to more efficiently query poses (fixes #10454)
Refactor the logic that actually applies queried poses to the transform nodes in a way that minimizes object churn

@rgerd - any update on that one? would be great to merge this

It now has couple minor conflicts as well @rgerd

@RaananW @sebavan Hi sorry I took some time off while working on this. Feedback will be responded to by EOD.

@rgerd Only the linting to go :-) @RaananW it looks ok to me but would like your back review :-)


Warning when using "popup" class

When any tag has "popup" class popup directive fires and console gets ""$tooltip is now deprecated. Use $uibTooltip instead."
https://jsbin.com/femino/1/edit?html,console

@yoorek, maintaining a large and popular OSS library is a difficult task performed by a lot of people.  As such we ask that you please be respectful of our time by looking at both open and closed issues before you enter anything in the issues forum.
That said, the deprecation warnings were added in the 0.14.x releases as we introduced a uib- prefix for all our directives (to avoid namespace clashes with both other angular frameworks and native HTML) and the purpose of deprecation warnings are to let the API user know that the API has changed and they need to update their code accordingly.  In your example, you need to use uib-popover instead of just popover.
I should also note that with the 1.0 release all the deprecation warnings and the deprecated code will be removed.  This means that your example would no longer throw a deprecation warning but also not work at all.

I know about warnings. Try to understand what THIS ISSUE MEANS.
You attach "popup" Directive to "popup" Class not attribute. So, after 1.0 i should use "uib-popup" CSS Class ?! Try to convince bootstrap
Dnia 24.12.2015 o godz. 05:11 Adam Gordon<EMAIL_ADDRESS>napisał(a):

@yoorek, maintaining a large and popular OSS library is a difficult task performed by a lot of people. As such we ask that you please be respectful of our time by looking at both open and closed issues before you enter anything in the issues forum.
That said, the deprecation warnings were added in the 0.14.x releases as we introduced a uib- prefix for all our directives (to avoid namespace clashes with both other angular frameworks and native HTML) and the purpose of deprecation warnings are to let the API user know that the API has changed and they need to update their code accordingly. In your example, you need to use uib-popover instead of just popover.
I should also note that with the 1.0 release all the deprecation warnings and the deprecated code will be removed. This means that your example would no longer throw a deprecation warning but also not work at all.
—
Reply to this email directly or view it on GitHub.

@yoorek, reading your initial post as I did, i.e., someone who is not yourself and from the perspective of a library maintainer, that is how I interpreted it.  You need to be more clear about what you were trying to say.
All that aside, you don't have to use the CSS class directive, you can use the uib-popover attribute directly instead.  We apply the appropriate Bootstrap classes via the tooltip and popover template.  The only thing that has changed here is the name of the directive.

I don't need to but i want to use "popup" css Class. And you force popup directive when i do it. Class selector directive are considered BAD practice. JUST RESTRICT DIRECTIVE TO "EA"
I attached JSBIN with JUST class="popup" (no popup attribute) which causes popup directive to fire and warnings in console. How much more specific can i be?
Dnia 24.12.2015 o godz. 15:05 Adam Gordon<EMAIL_ADDRESS>napisał(a):

@yoorek, reading your initial post as I did, i.e., someone who is not yourself and from the perspective of a library maintainer, that is how I interpreted it. You need to be more clear about what you were trying to say.
All that aside, you don't have to use the CSS class directive, you can use the uib-popover attribute directly instead. We apply the appropriate Bootstrap classes via the tooltip and popover template. The only thing that has changed here is the name of the directive.
—
Reply to this email directly or view it on GitHub.

@yoorek, relax and take a breath.  Your last comment was clear and you should have led with that.  We are not savants and aren't able to read minds.  We are aware that class directives are bad and it is on our radar to remove them.  But as we are focused on the 1.0 release, this is a lower priority.  Feel free to use the non-class based directives with the build from master and you'll be fine.


When checkpoint is not successful, next checkpoint is twice the size.

Bug Report
What did you do?
Start prometheus with aggressive settings (--storage.tsdb.max-block-duration=10m --storage.tsdb.min-block-duration=1m)
Wait for a checkpoint:
data/wal/checkpoint.000040/
Let's say that the checkpoint has a size of 5M
Copy the checkpoint to data/wal/checkpoint.000042.tmp
It simulates the case where the tmp checkpoint is not written completely
What did you expect to see?
when checkpoint 0000042 is written, its size is 5M
What did you see instead? Under which circumstances?
checkpoint 0000042 is 10M, because it contains the tmp that was not written successfully.
Environment
Linux

Prometheus version:

2.15.2

Why was the original checkpoint not successful?

In this case it is not even about being successful or not @brian-brazil . Just shutdown Prometheus in the middle of the compression process is enough.

What do we do for compactions in that case?

I see that the next checkpoints still get that huge size

I mean what happens to the temporary files compaction uses if we shutdown?

I think https://github.com/prometheus/prometheus/issues/6408 could be related. I was the one reporting this issue here to @roidelapluie on IRC yesterday. I am running into this issue again and again, because the system running prometheus does not have enough memory (12 GB shared with some smaller apps) to compress the WAL in time before getting evicted/killed by OOM.


About openpose and inference code

Thank you for great work @Wangt-CN .
Where is run.py in openpose?
And can you release inference code? so I can run demo on my machine.
Thanks.

Hi @anhquannguyen21, thanks for your interests! I will update the inference demo jupyter and resolve the openpose issue within 2 days.

Hi @anhquannguyen21, please the local inference demo jupyter example code here. The run.py file in openpose is also fixed. Feel free to re-open the issue for any further problems.


net/http: false positives checking for Ogg files

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go version go1.8.1 darwin/amd64
What operating system and processor architecture are you using (go env)?
MacOS Sierra 10.12.5
What did you do?
Wrote a test of http.DetectContentType() after reading the code.
(In net/http/sniff.go, the mask used to test for application/ogg is bogus.)
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
https://play.golang.org/p/jr4yXFJZLZ
What did you expect to see?
A file beginning with "owow\000" would be classified as application/octet-stream
What did you see instead?
It is classified as application/ogg

Hello there @gtownsend, thanks for filing the issue. Nice catch.
My apologies, the bug is that unfortunately I mismatched and used:

[]byte("\x4F\x67\x67\x53\x00")
instead of
[]byte("\xFF\xFF\xFF\xFF\xFF")
as the mask
https://github.com/golang/go/blob/b9daf0a408acb4099eda268ed80203f83ecd3fa5/src/net/http/sniff.go#L109-L113

The algorithm and reference that we use is at:

I'll make a CL and a test for it, although Brad is on vacation for a week, but if anyone can help me review and merge it that'd be nice.
Anyways, the catch here is that the bug for "application/ogg" gives a false positive if the byte pattern BITWISE AND'd with 4F 67 67 53 00 in hex matches itself 4F 67 67 53 00  for example:

oooS
owow

/cc @bradfitz @rsc can this go in for Go1.9?


Add generic home page section generation

This change enables theme user to specify arbitrary order of sections, and add multiple sections of the same type (more generic approach than in #105, which is applicable only to experience blocks).

All sections are specified in config as a list, with order of items directly reflecting order on the main page (including navbar).
Type of a section is specified with a new type field.
If there are multiple sections of the same type, in order to distinguish them for navbar navigation, you need to specify unique id field.
Navbar and main page generation is more generic, allowing to add custom section types – the only requirement is a custom partial named after the section type. Styling can be provided in a custom CSS (enabled with customCSS site param).

Hi @MarekPikula , Thanks for all your valuable pull requests ❤ . All your pull requests can make this template to use in more effective way.

As it involves more changes, I will check this pull request clearly and merge.

Sure thing. The main issue I have with this PR in particular is that it introduces braking changes. I thought about making it backwards-compatible, but couldn't find a way to do it cleanly (yet). I'd say that we have a few options:

Try to make this change backwards-compatible. It may make the code look somewhat uglier, but it won't break people's setup.
Merge as is but provide a clear instructions on how to transition to the new config scheme. The question is where is the right place for this. I'd say that maybe a wiki article, a release pointing to that article, and maybe a note in the README.

What do you think.

I just rebased the branch onto the recent master, so that it's directly mergable.


bug in data transfer when using acquisition tab

I encountered a bug when acquiring birefringence data via the acquisition tab. Before clicking acquisition, I had evaluated calibration curves with a few different settings (swings, intensity, # of states), and acquired background with 4-state settings. Screenshot and trace below:

---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
c:\users\labelfree\recorder\recOrder\plugin\widget\calibration_plugin_widget.py in _handle_acq_error(self=, exc=ValueError('cannot reshape array of size 20971520 into shape (4,2048,2048)'))
    229
    230     def _handle_acq_error(self, exc):
--> 231         raise exc
        exc = ValueError('cannot reshape array of size 20971520 into shape (4,2048,2048)')
    232
    233     def _handle_load_finished(self):

~\.conda\envs\recOrder\lib\site-packages\napari\_qt\qthreading.py in run(self=)
    154                 warnings.filterwarnings("always")
    155                 warnings.showwarning = lambda *w: self.warned.emit(w)
--> 156                 result = self.work()
        result = undefined
        self.work = >
    157             if isinstance(result, Exception):
    158                 if isinstance(result, RuntimeError):

c:\users\labelfree\recorder\recOrder\plugin\acquisition\acquisition_workers.py in work(self=)
    138         self._check_abort()
    139         self.n_slices = stack.shape[2]
--> 140         birefringence, phase, meta = self._reconstruct(stack[0])
        birefringence = undefined
        phase = undefined
        meta = undefined
        self._reconstruct = >
        stack =  (1, 4, 1, 2048, 2048) uint16
    141         self._check_abort()
    142

c:\users\labelfree\recorder\recOrder\plugin\acquisition\acquisition_workers.py in _reconstruct(self=, stack= (4, 2048, 2048) uint16)
    254             bg_data = self._load_bg(self.calib_window.acq_bg_directory, stack.shape[-2], stack.shape[-1])
    255             self._check_abort()
--> 256             bg_stokes = recon.Stokes_recon(bg_data)
        bg_stokes = undefined
        recon.Stokes_recon = >
        bg_data =  (5, 2048, 2048) float64
    257             self._check_abort()
    258             bg_stokes = recon.Stokes_transform(bg_stokes)

c:\users\labelfree\waveorder\waveorder\waveorder_reconstructor.py in Stokes_recon(self=, I_meas= (5, 2048, 2048) float64)
    991
    992         A_pinv = np.linalg.pinv(self.A_matrix)
--> 993         S_image_recon = np.reshape(np.dot(A_pinv, I_meas.reshape((self.N_channel, -1))), (self.N_Stokes,)+img_shape[1:])
        S_image_recon = undefined
        global np.reshape =
        global np.dot =
        A_pinv =  (4, 4) float64
        I_meas.reshape =
        self.N_channel = 4
        self.N_Stokes = 4
        img_shape = (5, 2048, 2048)
    994
    995

 in reshape(*args=( (4, 5242880) float64, (4, 2048, 2048)), **kwargs={})

~\.conda\envs\recOrder\lib\site-packages\numpy\core\fromnumeric.py in reshape(a= (4, 5242880) float64, newshape=(4, 2048, 2048), order='C')
    296            [5, 6]])
    297     """
--> 298     return _wrapfunc(a, 'reshape', newshape, order=order)
        global _wrapfunc =
        a =  (4, 5242880) float64
        newshape = (4, 2048, 2048)
        order = 'C'
    299
    300

~\.conda\envs\recOrder\lib\site-packages\numpy\core\fromnumeric.py in _wrapfunc(obj= (4, 5242880) float64, method='reshape', *args=((4, 2048, 2048),), **kwds={'order': 'C'})
     55
     56     try:
---> 57         return bound(*args, **kwds)
        bound =
        args = ((4, 2048, 2048),)
        kwds = {'order': 'C'}
     58     except TypeError:
     59         # A TypeError occurs if the object does have such a method in its

ValueError: cannot reshape array of size 20971520 into shape (4,2048,2048)

fixed in #31

👍🏼  Did I pick a background stack that was acquired with 5-state algorithm, i.e., was this a user error in picking the right background?


Does not accept response incase extra space is added

Describe the Issue
If the following code snippet response is submitted as a response, the response succeeds.
const makeServerRequest = new Promise((resolve, reject) => {

});

But, if we add a space after "new Promise" like:
const makeServerRequest = new Promise ((resolve, reject) => {

});

the, response should be accepted technically, but it throws error Your promise should receive a function with resolve and reject as parameters.
Affected Page
https://www.freecodecamp.org/learn/javascript-algorithms-and-data-structures/es6/create-a-javascript-promise
Your code
const makeServerRequest = new Promise ((resolve, reject) => {

});

Expected behavior
should be accepted and the current lessons must be marked as done
Screenshots
Code that Works:

Output of above:

Code that does not work:

Output of above:

System

Device: HP 255 g7
OS: Manjaro Linux
Browser: Mozilla Firefox
Version: 101.0.1

Additional context
No response

Proper syntax for a JS promise does not allow for spaces after the word "promise."

What do you mean by allow?
As far as I know, you can call any constructor with as many spaces before the parentheses as you like. Not sure why you would, but the constructor works just fine.
new Date            ();

Proper formatting rules shouldn't allow it, but that has nothing to do with allowed syntax.


Build pipeline ignore defined node version in package.json and azure-pipelines.yml.

Describe the bug
Build pipeline ignore defined node version defined in package.json and azure-pipelines.yml.
Inpackage.json I have:
{
   //...
  "engines": {
    "node": ">=20.15.0",
    "npm": ">=10.7.0"
  },
  "dependencies": {
    "next": "14.2.6",
    "next-auth": "^4.24.8",
    "react": "^18",
    "react-dom": "^18",
  },
  "devDependencies": {
    "@svgr/webpack": "^8.1.0",
    "@types/node": "^20",
    "@types/react": "^18",
    "@types/react-dom": "^18",
    "eslint": "^8",
    "eslint-config-next": "14.2.6",
    "postcss": "^8",
    "tailwindcss": "^3.4.1",
    "typescript": "^5"
  }
}

and in pipelines.yml i have:
  - task: NodeTool@0
    inputs:
      versionSpec: '20.15.0'
    displayName: 'Use Node.js 20.15.0'

  - script: |
      echo "After setting Node.js version:"
      node -v
      npm -v
    displayName: 'Check Node.js version after setting'

  - script: |
      curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.3/install.sh | bash
      source ~/.nvm/nvm.sh
      nvm install 20.15.0
      nvm use 20.15.0
      node -v
      npm -v
    displayName: 'Install and use Node.js 20.15.0 with nvm'

  - task: AzureStaticWebApp@0
    inputs:
      azure_static_web_apps_api_token: $(AZURE_STATIC_WEB_APPS_API_TOKEN)
      app_location: "/"
      output_location: ".next"
      api_location: ""

the node version shows 20.15.0 after first three steps, but when build  azure static web app, the log shows detecting platforms, nodejs:22.9.0 then ignore the previous defined version and use 22.9.0. but auzre pipeline doesn't support node v22 then lead to failed pipeline run.
Detecting platforms...
Detected following platforms:
  nodejs: 22.9.0
Version '22.9.0' of platform 'nodejs' is not installed. Generating script to install it...
Detected the following frameworks: Typescript,Next.js

---End of Oryx build logs---
Try to validate location at: '/...swa-oryx/app/.next'.
Finished building app with Oryx
Node version 22.9.0 is not supported. Please use one of the following versions 12, 14, 16, 18, 20.

Expected behavior
Use defined node version.
Additional context
Same pipeline file runs successfully with defined node version at Oct. 17

fixed issue by use:
  "engines": {
    "node": "20.15.0",
    "npm": "10.7.0"
  },

I think the underlying issue is still valid. Shouldn't Oryx be able to choose supported Node engine if available with respect to engines.node?


Required spectre driver?

What is the required spectre driver to build?

There is so many and I don't know which one to pick.

Select "Release|x64". Anything else is not valid and leftover after studio project creation.

Like this? Which ones do you have selected?

https://docs.microsoft.com/en-us/visualstudio/ide/understanding-build-configurations?view=vs-2019

The one that I selected works fine, thank you.

There should be no spectre mitigation code in result driver otherwise it may not load/work properly because this is not a real driver but a shellcode. Do as I told you in first post.

@hfiref0x I have compiled everything but I do not know what to do with the compiled files. Is there a video tutorial on what to do?

https://github.com/hfiref0x/VBoxHardenedLoader/blob/master/Binary/howto.md

This works now, thank you.

everything is going well, but only one BAD detection.

Inside this VM open cmd -> windows+r, type cmd.
In cmd type wmic command, press enter.
In wmic type the exact command wmic /namespace:\\root\cimv2 path Win32_PnPEntity GET Name, DeviceId >output.txt
Find this output.txt file and upload it here or find here any entry with PCI\VEN_80EE&DEV_CAFE substring inside and post it here.

Output.txt uploaded here: http://hastebin.com/gilaticofo.apache

Try disabling USB on this VM.

Test results:

Still shows BAD, after disabling the USB controller.

Remove this device from device list.


Missing uv_sem_timedwait

Version: current master
Currently we do have uv_cond_timedwait, but the implementation of portable
int sem_timedwait(sem_t *sem, const struct timespec *abs_timeout);

Which (I guess) should be called uv_sem_timedwait is missing.

You're welcome to open a pull request but one problem I see off the bat is this:
sem_timedwait() uses a real-time clock (i.e., can move back in time) but uv_sem_t on macOS is implemented in terms of Mach semaphores and those use a monotonic clock. WaitForSingleObject() on Windows may have the same issue.

The reason libuv uses Mach instead of POSIX semaphores is because the latter used to be broken/missing.
I think they're there and working okay now but switching over won't help this feature request because macOS still lacks sem_timedwait().

I'm going to close this for lack of movement but if anyone still wants to work on this, by all means go ahead and open a pull request.

In case anyone does decide to pick this up later, inside the mach kernel it is called semaphore_wait_deadline (with uint64_t deadline, using clock monotonic nanoseconds) since 10.6 (https://developer.apple.com/documentation/kernel/1585829-semaphore_wait_deadline), and is exported as semaphore_timedwait[_signal] (with mach_timespec_t wait_time)


Performance drop with points cloud and apearance issues starting from version 1.97.

Description:
Point Cloud tilesets that were rendered without any problems in Cesium 1.96 and prior versions are rendered inappropriately and with a significant performance drops in Cesium starting from version 1.97.
Examples:

Appearance in 1.95 - everything is normal:

Appearance in 1.97 and up to 1.103 - points are to dark and there are some weird artifacts on tiles edges. Performance drops in 10-15 seconds of viewing:

Appearance in 1.103  - points are bright as they should be but there are still some weird artifacts on tiles edges. Performance drops in 10-15 seconds of viewing:

Sandcastle example
Details:
Browser: Chrome Version 111.0.5563.146 (Official Build) (64-bit)
Operating System: Microsoft Windows 11 Pro Version10.0.22000 Build 22000
Tileset: generated with Agisoft Metashape.
Comments
Probably related to https://github.com/CesiumGS/cesium/issues/11166.

In case it may be helpful - tileset is generated with Draco compression.

Seems like Draco compression is not the source of the issues.
Here is a Sandcastle with the point cloud exported from Metashape with compression on,
and here is a Sandcastle with the point cloud exported from Metashape with compression off.

Looks related or even duplicating #11270

Attaching profile.
Trace-point-cloud-no-styling.json.zip

I don't see any performance problems in version 1.109, looks like it has been fixed somehow.


[Test] Check interaction with hidden tokens/combatants

So... Not tested yet, because I haven't had the chance, but this probably will show a message for hidden tokens and/or hidden combatants.  It probably shouldn't.  Check, fix if needed.

Setting added in current dev build (to be released once I've done some other bits)


Distconfig squeezenet MNIST5 seems incorrect

Hi, I was trying to reproduce your code and I noticed that the value for the MNIST5 cosine distance seems incorrect. I have the following settings: layer:12 and dist_type = "cosine". When I run the code in the inter-dataset similarity.ipynb I get the following values:

but your code lists the following values:

could you please clarify how you obtained the values in the code?

After carefully rereading your paper I assume this difference is because of the fine-tuning on ImageNet100. However, I cannot seem to find which 100 classes you finetuned on. Is my assumption that this difference comes from here correct, and could you perhaps share the model weights or the 100 classes from ImageNet you used to finetune?


Update broken URLs & Some other changes

The following changes were made:

Update the README URL to correctly direct to the FOSSBilling website. It was missing the "https://" part and was trying to direct to a GitHub directory.
Update the Code of Conduct to remove the Slack leftover.

The following changes were made in a separate commit for an easier revert if they're not desired:

Rename master to main. While "master branch" remains a valid term, it is my belief this will help avoid any potential confusion.
Update the feature request URLs. Currently, the FAQ link directs to the Issues page, I removed that and instead added two new links, the first one linking "search for existing feature requests" to the Issues page, filtered with feature requests only and the second one, "add new ones", utilizes the site's feature request opener URL].

Feel free to make any changes / ask me to change anything.

Thanks! :)


define query string parameters for pagination

see also alphagov/tech-and-data-standards#4 which is related.  One thing I have learned from that issue is that whatever way we handle pagination, we should try to identify resources which don't change.  The current page-index and page-size parameters result in resources which do change as more entries are added to a register.

Do we actually need to define the parameters in the spec? If clients are rightly following previous and next link headers, can the spec simply treat pagination query strings as opaque?

Agreed that the spec defines pagination as implementation specific so relies on the Link header for rels next and previous.


Investigate logging and replaying OpenOCD-generated JTAG commands for DV tests

This idea of replaying a JTAG transcript definitely seems plausible, but there's a few things to sort out first:

[x] Is this an M2 task? I've tentatively filed it as one.
[ ] Is JTAG is a replayable protocol? Are there any negotiations that occur? For instance, I believe OpenOCD can automatically determine the JTAG clock speed, so we'd want to make sure to use a fixed clock speed.
[ ] How can we extract JTAG commands from OpenOCD? Ideally, we wouldn't have to modify OpenOCD, but in the worst case, I'm sure we could insert some printf statements.

To get a handle on what OpenOCD gives us out of the box, I modified PR #15024 to run OpenOCD with the additional flags --debug=3 --log_output /tmp/openocd.log, and this is the log file it generated: openocd.log.
Debug: 5432 1128 command.c:146 script_debug(): command - reg pmpcfg0 0x009d009f
Debug: 5433 1128 riscv.c:1921 riscv_openocd_poll(): polling all harts
Debug: 5434 1128 riscv.c:2916 riscv_set_current_hartid(): setting hartid to 0, was 0
Debug: 5435 1128 riscv.c:1873 riscv_poll_hart(): polling hart 0, target->state=2
Debug: 5436 1128 riscv-013.c:399 scan(): 41b r 00000000 @11 -> + 00000000 @11; 7i
Debug: 5437 1128 riscv-013.c:399 scan(): 41b - 00000000 @11 -> + 00030382 @11; 7i
Debug: 5438 1128 riscv-013.c:409 scan():  ->  allresumeack anyresumeack allhalted anyhalted authenticated version=2
Debug: 5440 1128 target.c:3054 handle_reg_command(): -
Debug: 5441 1128 riscv.c:3469 register_set(): [0]{0} write 0x009d009f to pmpcfg0 (valid=0)
Debug: 5442 1128 riscv.c:3038 riscv_set_register_on_hart(): {0} csr928 <- 9d009f
Debug: 5443 1128 riscv-013.c:3641 riscv013_set_register(): [0] writing 0x9d009f to register csr928 on hart 0
Debug: 5444 1128 riscv.c:2916 riscv_set_current_hartid(): setting hartid to 0, was 0
Debug: 5445 1128 riscv-013.c:1306 register_write_direct(): {0} csr928 <- 0x9d009f
Debug: 5446 1128 riscv-013.c:399 scan(): 41b w 009d009f @04 -> + 00000000 @11; 7i
Debug: 5447 1129 riscv-013.c:399 scan(): 41b - 00000000 @04 -> + 009d009f @04; 7i
Debug: 5448 1129 riscv-013.c:782 execute_abstract_command(): command=0x2303a0; access register, size=32, postexec=0, transfer=1, write=1, regno=0x3a0
Debug: 5449 1129 riscv-013.c:399 scan(): 41b w 002303a0 @17 -> + 00000000 @04; 7i
Debug: 5450 1129 riscv-013.c:399 scan(): 41b r 00000000 @16 -> + 002303a0 @17; 7i
Debug: 5451 1129 riscv-013.c:399 scan(): 41b - 00000000 @16 -> + 08000002 @16; 7i
Debug: 5452 1129 riscv-013.c:409 scan():  ->  progbufsize=8 datacount=2
Debug: 5453 1129 riscv.c:3054 riscv_set_register_on_hart(): [riscv.tap.0]{0} wrote 0x9d009f to pmpcfg0 valid=0
User : 5454 1129 gdb_server.c:723 gdb_output(): pmpcfg0 (/32): 0x009d009f
User : 5455 1129 gdb_server.c:723 gdb_output():

These scan() lines appear to be coming from OpenOCD's dump_field() in riscv-013.c. It appears that every DMI (Debug Module Interface) operation is logged on one of these scan() lines. To actually make sense of these operations, I'd need to dig into RISC-V External Debug Support Version 0.13.2.
I think we could scrape the OpenOCD log to build a transcript of the RISC-V DMI operations, but it would take a little more work to extract JTAG commands. @tjaychen, what makes more sense from a DV perspective?

ah @dmcardle just to chime in a bit here.
I don't think we need to go to the level of JTAG.
I think rather, like when we debugged the openocd / pmpcfg3 issue, we just need the information about what data openocd is trying to program where.
We already know it for register access for example, so now we just need to figure out for things like stepping, jumping the PC to sram etc. Once we have that information, we can translate it into jtag on DV side.
The other thing i wanted to check, is that technically from the jtag perspective, there are things we need to do to ibex (regsiter access, jumping pc etc), and things we need to do to memory.  The latter can use the sba interface, which is also pretty friendly for DV.

the openocd log to dmi operations i think is close to what i'm describing right? just to make sure i understand.
and if that's the case, i think this would definitely fall into M2, since we have several dv scenarios that are dependent on this.

Oh great, I think you want the DMI transcript rather than a JTAG transcript.

i think so. Does that make sense to you? Based on our debugging for pmpcfg3, i think that should actually work quite well.
This way you also don't need to worry about the nitty gritty jtag details.

i think so. Does that make sense to you? Based on our debugging for pmpcfg3, i think that should actually work quite well. This way you also don't need to worry about the nitty gritty jtag details.

Yeah, I think this makes sense. It shouldn't be too difficult to create a Bazel target for a txt file containing the DMI commands scraped from the OpenOCD log. I don't have much intuition on what format would be useful for DV — should we parse it and emit JSON or something?

@sriyerg
@weicaiyang
@cindychip
@jdonjdon
i'm adding folks who have touched jtag in DV before.
#15008 kind of shows how it will look like in DV land.
So I feel like a text file showing where we are writing (abstract command / data, something else, program buffer), and what data to write would be helpful. The DV folks can comment better.

If this is cmd / data format like this (https://github.com/lowRISC/opentitan/blob/c1192e8086997a35d0b99f508c04662a6771599b/hw/top_earlgrey/dv/env/seq_lib/chip_jtag_base_vseq.sv#L48-L54)
should be straight forward.

I'm attaching openocd.log, which is the complete stdout/stderr output from OpenOCD when running //sw/device/examples/sram_program:sram_program_fpga_cw310_test.
I think we can extract the abstract commands with grep.
% grep execute_abstract_command openocd.log
Debug: 274 39 riscv-013.c:782 execute_abstract_command(): command=0x321008; access register, size=64, postexec=0, transfer=1, write=0, regno=0x1008
Debug: 279 40 riscv-013.c:805 execute_abstract_command(): command 0x321008 failed; abstractcs=0x8000202
Debug: 284 40 riscv-013.c:782 execute_abstract_command(): command=0x220301; access register, size=32, postexec=0, transfer=1, write=0, regno=0x301
Debug: 490 255 riscv-013.c:782 execute_abstract_command(): command=0x221001; access register, size=32, postexec=0, transfer=1, write=0, regno=0x1001
Debug: 502 257 riscv-013.c:782 execute_abstract_command(): command=0x221002; access register, size=32, postexec=0, transfer=1, write=0, regno=0x1002
...

It's a little noisy, but I think the hex representation of the command is all that we'd need. Some creative grepping/sedding extracts the hex literals.
% grep 'execute_abstract_command(): command=' /tmp/openocd.log | sed -E 's/^.*command=(0x[0-9a-f]+).*$/\1/' | head
0x321008
0x220301
0x221001
0x221002
0x221003
0x221004
0x221005
0x221006
0x221007
0x221008

Hi @dmcardle, can you cross reference the E2E test cases we are planning to run in DV that this issue is blocking?

@sriyerg and I were discussing yesterday, and I think his feelings are that the commands are perhaps simple enough that we do not need to do the scraping, and we can simply replicate the steps directly in DV.
@sriyerg can you elaborate more?

@sriyerg do you still need any info from @dmcardle for the injection tests?
@dmcardle had pointed me to the gdb code that does the injection and it's ..quite high level, so I thought getting the actual dmi commands might be nice, it's up to you though.

postponed to post M2, see #14145

@sriyerg Here are debug logs for the RMA instances of the two tests we chatted about. CC: @timothytrippel and @alphan.

rom_e2e_debug_test_otp_rma.log
sram_program_fpga_cw310_test_otp_rma.log

Caveat 1: I couldn't get the rom_e2e_debug_test_otp_rma to pass when OpenOCD's debug logging is enabled. Rather than seeing OK!GDB-OK printed to the UART, I only see O. I imagine this is a timing issue, since it takes OpenOCD non-zero time to print to its log, but I haven't nailed it down yet. I think the first 90% of the log should still be useful, though.
Caveat 2: These logs will look a little different than the one a few comments up. I can no longer redirect just OpenOCD's output, because our test harness uses its output to sequence operations. Instead, I'm just redirecting the stdout of bazel test, but it should still be trivial to grep for abstract commands.
I needed to adjust a few timeouts after enabling OpenOCD debug logging:
diff --git a/rules/scripts/gdb_test_coordinator.py b/rules/scripts/gdb_test_coordinator.py
index f1b0598d1..5e5bc4eb0 100644
--- a/rules/scripts/gdb_test_coordinator.py
+++ b/rules/scripts/gdb_test_coordinator.py
@@ -143,6 +143,7 @@ def main(rom_kind: str = typer.Option(...),
     ]
     openocd_command = [
         openocd_path,
+        "-d",
         "-f",
         openocd_jtag_adapter_config,
         "-c",
@@ -166,7 +167,7 @@ def main(rom_kind: str = typer.Option(...),
     console_command = opentitantool_prefix + [
         "console",
         "--timeout",
-        "30s",
+        "60s",
     ]
     if exit_success_pattern is not None:
         console_command.append("--exit-success=" + exit_success_pattern)
diff --git a/sw/device/silicon_creator/rom/e2e/BUILD b/sw/device/silicon_creator/rom/e2e/BUILD
index 86a108945..5a8547632 100644
--- a/sw/device/silicon_creator/rom/e2e/BUILD
+++ b/sw/device/silicon_creator/rom/e2e/BUILD
@@ -1771,7 +1771,7 @@ SRAM_JTAG_INJECTION_GDB_SCRIPT = """
 [
     opentitan_gdb_fpga_cw310_test(
         name = "sram_program_fpga_cw310_test_otp_" + otp_name,
-        timeout = "short",
+        timeout = "moderate",
         exit_success_pattern = "sram_program\\.c:\\d+\\] PC: 0x100020e0, SRAM: \\[0x10000000, 0x10020000\\)",
         gdb_script = SRAM_JTAG_INJECTION_GDB_SCRIPT,
         gdb_script_symlinks = {
@@ -2844,7 +2844,7 @@ test_suite(
 [
     opentitan_gdb_fpga_cw310_test(
         name = "rom_e2e_debug_test_otp_" + otp_name,
-        timeout = "short",
+        timeout = "moderate",
         exit_success_pattern = "OK!GDB-OK(?s:.*)BFV:0142500d",
         gdb_expect_output_sequence = [

For future reference, these are the commands I used to extract the logs:
./bazelisk.sh test --test_output=all //sw/device/silicon_creator/rom/e2e:sram_program_fpga_cw310_test_otp_rma > sram_program_fpga_cw310_test_otp_rma.log
./bazelisk.sh test --test_output=all --experimental_ui_max_stdouterr_bytes=-1 //sw/device/silicon_creator/rom/e2e:rom_e2e_debug_test_otp_rma  > rom_e2e_debug_test_otp_rma.log

Hey @sriyerg, I've worked around caveat 1 from the previous comment by dropping the verbose -d flag from OpenOCD and adding some custom logging [branch]. I think the issue was timing-related, and that by only logging what we want, we can squeak by under some threshold.

rom_e2e_debug_test_otp_rma-2.log

I believe you said you had gotten up to the first uart_putchar(), but no further. If you skim ahead in the new log for 0x4000001c (the address of UART0's WDATA), you'll see three places where we are presumably writing O, K, and ! via the progbuf. Here's one of them:
src/target/riscv/riscv-013.c:3999 write_memory                         address=0x4000001c, size=4
src/target/riscv/riscv-013.c:3665 write_memory_bus_v1                  0x4000001c
src/target/riscv/riscv-013.c:4797 riscv013_dmi_write_u64_bits          target=0x564fe9809f00
src/target/riscv/riscv-013.c:4413 riscv013_fill_dmi_write_u64          target=0x564fe9809f00
src/target/riscv/riscv-013.c:4431 riscv013_fill_dmi_nop_u64            target=0x564fe9809f00
src/target/riscv/riscv-013.c:4797 riscv013_dmi_write_u64_bits          target=0x564fe9809f00
src/target/riscv/riscv-013.c:4431 riscv013_fill_dmi_nop_u64            target=0x564fe9809f00
src/target/riscv/riscv-013.c:4431 riscv013_fill_dmi_nop_u64            target=0x564fe9809f00
src/target/riscv/riscv-013.c:3806 write_memory_progbuf                 0x4000001c

Disassembling the ROM tells me that uart_putchar lives at 0x0000cd02. I haven't dug into it very deeply, but I see that OpenOCD is setting the dpc register to uart_putchar eight times. (Here's a handy one-liner for viewing ROM disassembly: ./bazelisk.sh build-then 'less %s' //sw/device/silicon_creator/rom:rom_with_fake_keys_fpga_cw310_dis.)
src/target/riscv/riscv-013.c:4115 riscv013_set_register                [0] writing 0xcd02 to register pc

Is this level of detail useful?

Hey @sriyerg, I've worked around caveat 1 from the previous comment by dropping the verbose -d flag from OpenOCD and adding some custom logging [branch]. I think the issue was timing-related, and that by only logging what we want, we can squeak by under some threshold.

rom_e2e_debug_test_otp_rma-2.log

I believe you said you had gotten up to the first uart_putchar(), but no further. If you skim ahead in the new log for 0x4000001c (the address of UART0's WDATA), you'll see three places where we are presumably writing O, K, and ! via the progbuf. Here's one of them:

To clarify, I have not yet modeled the GDB call functionality yet - I wanted to see what OpenOCD did first.

src/target/riscv/riscv-013.c:3999 write_memory                         address=0x4000001c, size=4
src/target/riscv/riscv-013.c:3665 write_memory_bus_v1                  0x4000001c
src/target/riscv/riscv-013.c:4797 riscv013_dmi_write_u64_bits          target=0x564fe9809f00
src/target/riscv/riscv-013.c:4413 riscv013_fill_dmi_write_u64          target=0x564fe9809f00
src/target/riscv/riscv-013.c:4431 riscv013_fill_dmi_nop_u64            target=0x564fe9809f00
src/target/riscv/riscv-013.c:4797 riscv013_dmi_write_u64_bits          target=0x564fe9809f00
src/target/riscv/riscv-013.c:4431 riscv013_fill_dmi_nop_u64            target=0x564fe9809f00
src/target/riscv/riscv-013.c:4431 riscv013_fill_dmi_nop_u64            target=0x564fe9809f00
src/target/riscv/riscv-013.c:3806 write_memory_progbuf                 0x4000001c

Disassembling the ROM tells me that uart_putchar lives at 0x0000cd02. I haven't dug into it very deeply, but I see that OpenOCD is setting the dpc register to uart_putchar eight times. (Here's a handy one-liner for viewing ROM disassembly: ./bazelisk.sh build-then 'less %s' //sw/device/silicon_creator/rom:rom_with_fake_keys_fpga_cw310_dis.)
src/target/riscv/riscv-013.c:4115 riscv013_set_register                [0] writing 0xcd02 to register pc

Is this level of detail useful?

Hey @sriyerg, I've worked around caveat 1 from the previous comment by dropping the verbose -d flag from OpenOCD and adding some custom logging [branch]. I think the issue was timing-related, and that by only logging what we want, we can squeak by under some threshold.

rom_e2e_debug_test_otp_rma-2.log

I believe you said you had gotten up to the first uart_putchar(), but no further. If you skim ahead in the new log for 0x4000001c (the address of UART0's WDATA), you'll see three places where we are presumably writing O, K, and ! via the progbuf. Here's one of them:
src/target/riscv/riscv-013.c:3999 write_memory                         address=0x4000001c, size=4
src/target/riscv/riscv-013.c:3665 write_memory_bus_v1                  0x4000001c
src/target/riscv/riscv-013.c:4797 riscv013_dmi_write_u64_bits          target=0x564fe9809f00
src/target/riscv/riscv-013.c:4413 riscv013_fill_dmi_write_u64          target=0x564fe9809f00
src/target/riscv/riscv-013.c:4431 riscv013_fill_dmi_nop_u64            target=0x564fe9809f00
src/target/riscv/riscv-013.c:4797 riscv013_dmi_write_u64_bits          target=0x564fe9809f00
src/target/riscv/riscv-013.c:4431 riscv013_fill_dmi_nop_u64            target=0x564fe9809f00
src/target/riscv/riscv-013.c:4431 riscv013_fill_dmi_nop_u64            target=0x564fe9809f00
src/target/riscv/riscv-013.c:3806 write_memory_progbuf                 0x4000001c

Disassembling the ROM tells me that uart_putchar lives at 0x0000cd02. I haven't dug into it very deeply, but I see that OpenOCD is setting the dpc register to uart_putchar eight times. (Here's a handy one-liner for viewing ROM disassembly: ./bazelisk.sh build-then 'less %s' //sw/device/silicon_creator/rom:rom_with_fake_keys_fpga_cw310_dis.)
src/target/riscv/riscv-013.c:4115 riscv013_set_register                [0] writing 0xcd02 to register pc

Is this level of detail useful?

Thanks @dmcardle for the log. The first log was super helpful - the verbose debug level messages provided info at all levels of abstraction which helped me make sense of the sequence of events. For example, see these messages from the first log (this is the output of grep looking for very specific things in the log):
758:[OPENOCD] Debug: 738 235 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0x81b8
771:[OPENOCD] Debug: 751 237 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0x81b8
1290:[OPENOCD] Debug: 1268 314 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0x8080
1303:[OPENOCD] Debug: 1281 316 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0x8080
1642:[OPENOCD] Debug: 1617 364 riscv.c:3396 riscv_set_register(): [riscv.tap.0] dcsr <- 4000b0c7
1652:[OPENOCD] Debug: 1627 366 riscv.c:3414 riscv_set_register(): [riscv.tap.0] wrote 0x4000b0c7 to dcsr valid=0
2082:[OPENOCD] Debug: 2055 421 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0x81a0
2095:[OPENOCD] Debug: 2068 423 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0x81a0
2298:[OPENOCD] Debug: 2266 451 breakpoints.c:88 breakpoint_add_internal(): [0] added hardware breakpoint at 0x000081a8 of length 0x00000004, (BPID: 0)
2330:[OPENOCD] Debug: 2297 454 riscv.c:3396 riscv_set_register(): [riscv.tap.0] dcsr <- 4000b103
2340:[OPENOCD] Debug: 2307 456 riscv.c:3414 riscv_set_register(): [riscv.tap.0] wrote 0x4000b103 to dcsr valid=0
2388:[OPENOCD] Debug: 2355 473 riscv-013.c:4340 riscv013_halt_reason(): {0} halted because of trigger
2845:[OPENOCD] Debug: 2808 531 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0x81a8
2858:[OPENOCD] Debug: 2821 533 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0x81a8
2911:[OPENOCD] Debug: 2874 539 breakpoints.c:291 breakpoint_free(): free BPID: 0 --> 0
3280:[OPENOCD] Debug: 3243 597 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0x81ba
3293:[OPENOCD] Debug: 3256 599 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0x81ba
3603:[OPENOCD] Debug: 3566 656 breakpoints.c:88 breakpoint_add_internal(): [0] added hardware breakpoint at 0x000081a8 of length 0x00000004, (BPID: 1)
3687:[OPENOCD] Debug: 3650 671 breakpoints.c:88 breakpoint_add_internal(): [0] added hardware breakpoint at 0x000081f6 of length 0x00000002, (BPID: 2)
3771:[OPENOCD] Debug: 3734 687 breakpoints.c:88 breakpoint_add_internal(): [0] added hardware breakpoint at 0x00008800 of length 0x00000002, (BPID: 3)
3861:[OPENOCD] Debug: 3824 703 breakpoints.c:88 breakpoint_add_internal(): [0] added hardware breakpoint at 0x0000ccc0 of length 0x00000004, (BPID: 4)
3897:[OPENOCD] Debug: 3860 707 riscv.c:3396 riscv_set_register(): [riscv.tap.0] dcsr <- 4000b087
3907:[OPENOCD] Debug: 3870 708 riscv.c:3414 riscv_set_register(): [riscv.tap.0] wrote 0x4000b087 to dcsr valid=0
3955:[OPENOCD] Debug: 3918 720 riscv.c:3396 riscv_set_register(): [riscv.tap.0] dcsr <- 4000b103
3965:[OPENOCD] Debug: 3928 722 riscv.c:3414 riscv_set_register(): [riscv.tap.0] wrote 0x4000b103 to dcsr valid=0
4013:[OPENOCD] Debug: 3976 790 riscv-013.c:4340 riscv013_halt_reason(): {0} halted because of trigger
4481:[OPENOCD] Debug: 4439 850 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0x81f6
4494:[OPENOCD] Debug: 4452 851 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0x81f6
4547:[OPENOCD] Debug: 4505 858 breakpoints.c:291 breakpoint_free(): free BPID: 1 --> 0
4596:[OPENOCD] Debug: 4554 864 breakpoints.c:291 breakpoint_free(): free BPID: 2 --> 0
4645:[OPENOCD] Debug: 4603 871 breakpoints.c:291 breakpoint_free(): free BPID: 3 --> 0
4694:[OPENOCD] Debug: 4652 877 breakpoints.c:291 breakpoint_free(): free BPID: 4 --> 0
4873:[OPENOCD] Debug: 4831 901 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0x81f6
4886:[OPENOCD] Debug: 4844 902 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0x81f6
5165:[OPENOCD] Debug: 5123 942 breakpoints.c:88 breakpoint_add_internal(): [0] added hardware breakpoint at 0x000081a8 of length 0x00000004, (BPID: 5)
5318:[OPENOCD] Debug: 5276 971 breakpoints.c:88 breakpoint_add_internal(): [0] added hardware breakpoint at 0x00008800 of length 0x00000002, (BPID: 6)
5471:[OPENOCD] Debug: 5429 997 breakpoints.c:88 breakpoint_add_internal(): [0] added hardware breakpoint at 0x0000ccc0 of length 0x00000004, (BPID: 7)
5513:[OPENOCD] Debug: 5471 1006 riscv.c:3396 riscv_set_register(): [riscv.tap.0] dcsr <- 4000b087
5523:[OPENOCD] Debug: 5481 1008 riscv.c:3414 riscv_set_register(): [riscv.tap.0] wrote 0x4000b087 to dcsr valid=0
5571:[OPENOCD] Debug: 5529 1014 riscv.c:3396 riscv_set_register(): [riscv.tap.0] dcsr <- 4000b103
5581:[OPENOCD] Debug: 5539 1020 riscv.c:3414 riscv_set_register(): [riscv.tap.0] wrote 0x4000b103 to dcsr valid=0
5629:[OPENOCD] Debug: 5587 1100 riscv-013.c:4340 riscv013_halt_reason(): {0} halted because of trigger
6083:[OPENOCD] Debug: 6040 1158 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0x8800
6096:[OPENOCD] Debug: 6053 1160 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0x8800
6149:[OPENOCD] Debug: 6106 1166 breakpoints.c:291 breakpoint_free(): free BPID: 5 --> 0
6198:[OPENOCD] Debug: 6155 1173 breakpoints.c:291 breakpoint_free(): free BPID: 6 --> 0
6247:[OPENOCD] Debug: 6204 1179 breakpoints.c:291 breakpoint_free(): free BPID: 7 --> 0
6400:[OPENOCD] Debug: 6357 1201 breakpoints.c:88 breakpoint_add_internal(): [0] added hardware breakpoint at 0x000081a8 of length 0x00000004, (BPID: 8)
6559:[OPENOCD] Debug: 6516 1222 breakpoints.c:88 breakpoint_add_internal(): [0] added hardware breakpoint at 0x0000ccc0 of length 0x00000004, (BPID: 9)
6594:[OPENOCD] Debug: 6551 1226 riscv.c:3396 riscv_set_register(): [riscv.tap.0] dcsr <- 4000b087
6604:[OPENOCD] Debug: 6561 1227 riscv.c:3414 riscv_set_register(): [riscv.tap.0] wrote 0x4000b087 to dcsr valid=0
7026:[OPENOCD] Debug: 6983 1282 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0x8802
7039:[OPENOCD] Debug: 6996 1283 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0x8802
7204:[OPENOCD] Debug: 7161 1309 breakpoints.c:88 breakpoint_add_internal(): [0] added hardware breakpoint at 0x00008800 of length 0x00000002, (BPID: 10)
7241:[OPENOCD] Debug: 7198 1313 riscv.c:3396 riscv_set_register(): [riscv.tap.0] dcsr <- 4000b103
7251:[OPENOCD] Debug: 7208 1315 riscv.c:3414 riscv_set_register(): [riscv.tap.0] wrote 0x4000b103 to dcsr valid=0
7299:[OPENOCD] Debug: 7256 1412 riscv-013.c:4340 riscv013_halt_reason(): {0} halted because of trigger
7757:[OPENOCD] Debug: 7709 1470 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0xccc0
7770:[OPENOCD] Debug: 7722 1471 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0xccc0
7823:[OPENOCD] Debug: 7775 1478 breakpoints.c:291 breakpoint_free(): free BPID: 8 --> 0
7872:[OPENOCD] Debug: 7824 1484 breakpoints.c:291 breakpoint_free(): free BPID: 10 --> 0
7921:[OPENOCD] Debug: 7873 1491 breakpoints.c:291 breakpoint_free(): free BPID: 9 --> 0
8249:[OPENOCD] Debug: 8201 1538 breakpoints.c:88 breakpoint_add_internal(): [0] added hardware breakpoint at 0x000081a8 of length 0x00000004, (BPID: 11)
8402:[OPENOCD] Debug: 8354 1559 breakpoints.c:88 breakpoint_add_internal(): [0] added hardware breakpoint at 0x00008800 of length 0x00000002, (BPID: 12)
8486:[OPENOCD] Debug: 8438 1571 breakpoints.c:88 breakpoint_add_internal(): [0] added hardware breakpoint at 0x00008894 of length 0x00000004, (BPID: 13)
8521:[OPENOCD] Debug: 8473 1574 riscv.c:3396 riscv_set_register(): [riscv.tap.0] dcsr <- 4000b087
8531:[OPENOCD] Debug: 8483 1575 riscv.c:3414 riscv_set_register(): [riscv.tap.0] wrote 0x4000b087 to dcsr valid=0
8953:[OPENOCD] Debug: 8905 1630 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0xccc4
8966:[OPENOCD] Debug: 8918 1632 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0xccc4
9137:[OPENOCD] Debug: 9089 1663 breakpoints.c:88 breakpoint_add_internal(): [0] added hardware breakpoint at 0x0000ccc0 of length 0x00000004, (BPID: 14)
9168:[OPENOCD] Debug: 9120 1666 riscv.c:3396 riscv_set_register(): [riscv.tap.0] dcsr <- 4000b103
9178:[OPENOCD] Debug: 9130 1668 riscv.c:3414 riscv_set_register(): [riscv.tap.0] wrote 0x4000b103 to dcsr valid=0
9226:[OPENOCD] Debug: 9178 1735 riscv-013.c:4340 riscv013_halt_reason(): {0} halted because of trigger
9689:[OPENOCD] Debug: 9631 1793 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0x8894
9702:[OPENOCD] Debug: 9644 1794 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0x8894
9822:[OPENOCD] Debug: 9764 1811 breakpoints.c:291 breakpoint_free(): free BPID: 13 --> 0
9873:[OPENOCD] Debug: 9815 1817 breakpoints.c:291 breakpoint_free(): free BPID: 11 --> 0
9922:[OPENOCD] Debug: 9864 1824 breakpoints.c:291 breakpoint_free(): free BPID: 12 --> 0
9971:[OPENOCD] Debug: 9913 1830 breakpoints.c:291 breakpoint_free(): free BPID: 14 --> 0
9995:[OPENOCD] Debug: 9937 1840 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0x8894
10008:[OPENOCD] Debug: 9950 1841 riscv-013.c:4087 riscv013_get_register(): [0] read PC from DPC: 0x8894

You can make out the following interesting details about what OpenOCD does for each of the gdb commands:

When coming out of a breakpoint, it deletes all breakpoints, single steps the CPU and restores the original breakpoints, and then resume the CPU, as opposed to resuming the CPU right away.
It does not treat break "*_rom_main" any differently (than break foo without the asterisk).

The second log you provided appears to a bit too low level - I will need to interpret the hex values and figure out what bits are set to what DMI registers. Let me give it a shot though.

OK, I tried another tactic to get the regular OpenOCD verbose log. I temporarily enabled debug logging just for call uart_putchar('G'). I also temporarily redirected the log output to a file. (For some reason, when I let it write the verbose log to stderr, the test hangs. Not really sure what's up with that.)
Here's the log:

rom_e2e_debug_openocd.log

Patch:
diff --git a/sw/device/silicon_creator/rom/e2e/BUILD b/sw/device/silicon_creator/rom/e2e/BUILD
index 4d178f57f..524267165 100644
--- a/sw/device/silicon_creator/rom/e2e/BUILD
+++ b/sw/device/silicon_creator/rom/e2e/BUILD
@@ -3129,7 +3129,7 @@ test_suite(
 [
     opentitan_gdb_fpga_cw310_test(
         name = "rom_e2e_debug_test_otp_" + lc_state,
-        timeout = "short",
+        timeout = "eternal",
         exit_success_pattern = "OK!GDB-OK(?s:.*)BFV:0142500d",
         gdb_expect_output_sequence = [
             ":::: GDB script complete.",
@@ -3223,7 +3223,11 @@ test_suite(
             print *(uint32_t*)($uart0_base + $uart_wdata) = '!'

             echo :::: Execute code from GDB with `call` command.\\n
+            monitor log_output rom_e2e_debug_openocd.log
+            monitor debug_level 3
             call uart_putchar('G')
+            monitor debug_level 2
+            monitor log_output default
             call uart_putchar('D')
             call uart_putchar('B')


Change all alerts style to Material UI 4.9

Connect account
Receive connect wallet

receipt page message box.


chore(settings): remove emoji to fix settings bot

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


Missing PredNet

Hi, PredNet is mentioned in the document and model weight links, but the codes don't seem to implement it. Could you also provide the implementation?

We removed it in the lightning version. But it can be found in the OpenSTL 0.3.0 branch.

I will close this issue if there are no more questions. Please feel free to open a new issue when you have new questions.


Add additional fields to transaction_list to support tipping

transaction_list needs to add additional fields:

type : (support, claim, update, "unbound")
claim_id : (claim_id of support/content/channel)
is_tip (true if type=support and sent to address that matches address of claim)

And drop label

Rename value to amount (but keep value for now)

Add fee

Right now value has to be kept as it is, right?

Discussed on Slack. Moving back to In Progress.

Update(23 Aug, '17): being worked on in lbryio/lbryum#148


Minimum port is ignored if port on local is 0

Hello,
I was trying to add option for max port however I discovered issue and wanted to discuss it before any action.
When you set minimum port on server and the client send wanted port using -p option the server correctly check if it's in range or not.
But when the port is set to 0 (or not given) by local the check is skipped because of condition:
if port != 0 && port < self.min_port {

Port is selected by TcpListener from tokio which is bypassing the setting.
The simplest solution that came to my mind is to generate random port on server within given range so currently MIN_PORT and 65535
What do you think?

Steps to reproduce:

run bore server --min-port 65535 on server
run bore local --to <server ip> <any port> -p 65534 on local
You can see it does not work and there is proper message on the server
run bore local --to <server ip> <any port> -p 0 on local
You can see assigned port is in most cases under MIN_PORT value

Hi @BxOxSxS, this is actually intended behavior. min_port is only used to specify port numbers specified by the user bore local ... --port x that are accepted. Unfortunately I don't believe it's possible to ask the operating system for a TCP listener on any given port :0 with the added constraint of being within a range of port numbers.

Yes it's not possible that way but bore could somehow choose and assign specyfic port if local gave value 0. Currently--min-port option is much less useful that it could be and description can also lead to missunderstanding. It can be problematic with firewalls and general management of server

Yes it's not possible that way but bore could somehow choose and assign specyfic port if local gave value 0.

I don't believe this is possible, but if you have a specific technical approach to doing this then we can reopen. Closing this issue.

Here is more technical example:
https://github.com/rust-lang-nursery/rust-cookbook/issues/500
I tried that first approach with for loop and it's working fine under linux but does now work on windows as someone commented on the issue. I will try to experiment with second way and report back

Here is a means of limiting random port selection to a range via "ip_local_port_range": https://unix.stackexchange.com/questions/305308/how-to-limit-range-of-random-port-sockets


Fix that navbar absolute.

Assigned all the best 👍

can you please add gssoc-ext label also

done

@Anu27n  brother this contribution is still not showing in my gssoc profile 😅 ,I think you need to add level label also ....like level1 ,level2 , level3


Add support for content types and fields in ClientSidePages

Make it possible to provision client side pages including content types, fields, etc.

This is now fully supported with schema v. 201903.


Screenshot to reflect new Engine versions

Hi Jaiden!
I updated screenshot.png to reflect the new UI as it has changed quite a bit since 5.0 - It has the same dimensions as well.
Already optimized with imgbot in my fork, I can roll it back though if need be, not sure how well Imgbot handles already processed images being merged in.

Cheers,
ziro.

Hey ziro, thanks for the update! Looks great to me so I'll go ahead and merge it in! ☺


Fix temp dir creation

fixes #2017
Looks like most chains copied this code for their wasmd integration.
We should probably inform them about this change.

Sounds good. I added a comment.


Update windows-autopilot-reset-remote.md, issue 3129

issue #3129
added clarification related to hybrid deployments

@nenonix @JohanFreelancer9 - kindly do the copy editor review for this PR. Thanks.

@greg-lindsay - can you please assist to check, approve and merge the content for this PR based on issue #3129?
Thank you.

@greg-lindsay - I would like to follow up on this. Can you please assist to check, approve and merge the content for this PR based on issue #3129?
Thank you.

@greg-lindsay - I would like to follow up on this. Can you please assist to check, approve and merge the content for this PR based on issue #3129?
Thank you.


(maint) Handle WaitWritable errors on Windows

The Bash shell was raising WaitWritable errors due to incorrect assumptions
about the behavior of select/wait_writable on Windows. Specifically, when
the IO buffer is full, IO.select will still indicate that the stream is
writable. Our subsequent call to write_nonblock will then raise
WaitWritable which we don't handle.
We now anticipate that condition by passing exception: false to
write_nonblock, indicating that it should return a :wait_writable symbol
rather than raise an error, and we treat that as having written 0 bytes,
sending us back through our IO.select loop again.

CLA signed by all contributors.


bundler: 2.3.9 -> 2.3.19

Description of changes
See https://github.com/rubygems/rubygems/blob/master/bundler/CHANGELOG.md
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] 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/)
22.11 Release Notes (or backporting 22.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
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 185655 run on x86_64-linux 1

1 package built:

bundler

Bundle 2.3.20 has been released.

Upgraded bundler to 2.3.20: https://github.com/rubygems/rubygems/blob/3.3/bundler/CHANGELOG.md#2320-august-10-2022


Add additional customization and configuration options for OpenTracing

Adding some nice-to-have features to make configuration and customization of tracing (mostly OpenTracing) easier:

Add configuration property to set global tags for spans. Will address this in separate PR.
Add configuration properties to configure sampling for OpenTracing, since that already exists for Sleuth.
Support overriding of the default WavefrontSpanReporter.
Add customizer for WavefrontTracer.Builder to allow for any further customizations.

lgtm

I'd like we move this to our next feature release. There are some changes in the current snapshot we need to push in a 2.0.2 first. I've flagged the one on hold accordingly.

@hanwavefront thanks for the update, I've polished things in 1047ab4, please take a look when you get a chance.
This PR has a number of changes which makes it hard to have a single description that the user can spot while browsing the changelog. Going forward, it would be better to have isolated PRs with more focused changes rather than a "theme" in a single PR.
The following improvements are available:

A WavefrontTracerBuilderCustomizer callback interface to customize the auto-configured WavefrontTracer
Configuration properties for OpenTracing's sampling (probability and duration)
The default Reporter can be overridden and all such beans in the context are wrapped in a composite automatically