[MXNET-1029] Feature request: randint operator

Description
Incorporates the feature request to support randint operator. Fixes #11218
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[X] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
[X] Changes are complete (i.e. I finished coding on this PR)
[X] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[X] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
[X] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

@mxnet-label-bot [pr-awaiting-review]

@ChaiBapchya ping!
Could you please take a look into the failing CI


Add snarky generic add gadget

This PR adds a snarky gadget for creating add gates with the generic gate.  It includes a new Gadgets module and adds some test cases for the new gadget.

!ci-build-me

what is the purpose of this gadget here : o ? we already have Impl.Field.add for adding two field elements together

Answering @mimoo, this was just for the sake of learning

!ci-build-me

!ci-build-me

I just pushed the addition of ppx_version to dune - there's a lint check that was failing because of that.

!ci-build-me

!ci-build-me


Constant circle speed

During test, circle speed of each circle was different. I could see the difference of speed particulary when my gaze go inside the circle or not.
So I check the code and the problem are from script CircleLife.cs. When program is running, before apply an effect on red circle, speed of circle was reset.
Now, circle speed is always the same one, is constant. To do this, just need to delete the reset of circle speed.
This pull request resolve the issur #19 .

@bastianilso If you want to try it again as the headset is setup now. 😄


Migrate RabbitMQSensor to an active sensor

Pack (replace this with the pack's name)
rabbitmq
Status
Replace this: describe the pack and PR status. Examples:

pack extension
bugfix

Description

Rename to RabbitMQQueueSensor since thats what it really is and added
some comments to that effect.
Changed the config and made a bit more structured to accomodate for
different sensors that support unrelated routing topologies.

Added some comments, but overall, LGTM :+1:


[FR] support Android/chromeOS

With the popularity of chromebooks nowadays, i think it would be really useful to have this working on chromeOS (basically Android). This would as far as i can see require a javascript-only implementation of git (git add/commit, push, pull and branch), which might be a bit tricky to implement.

Which version of Obsidian do you install on chrome OS? The Android version?

Yeah. I think android is more integrated with chrome os and sometimes I have the issue where frosting (the Linux environment) has its GUI entirely brick.
Do you think isomorphic got can be integrated with electron/capacitors or is that not feasible anyways?

you can install MGit from Fdroid (playstore version has problems getting the all file permission necessary) and use that on android

There's been an update that makes the plugin available for mobile, using isogit. Does that solve your problem?

That's actually kind of the solution I was eying for! Solves my problem, although i have gone to Dropbox for syncing my notes in the meantime. I'll try it out soon.


Submission format

I'd like to decide on a submission format, either pbtxt (proto text format; this is what you see when you print a proto in colab) or JSON. I'm also open to accepting both if we feel that is warranted. I'm assuming that we prefer a human-readable format for submissions to make them easier to inspect and review (rather than using the binary wire format).
Both formats are generated via google.protobuf modules (either text_format or json_format). I have a slight preference for pbtxt; I think it is slightly more readable, which might make review a bit easier, and it matches the normal repr() for protos in python. Specifically, there are fewer quotation marks, one less level of nesting, and explicit indications of the keys and values for map entries. However, it uses different syntax for things like repeated fields (see below; components is printed at the start of each element rather than using braces and commas like JSON). I don't expect that either format will be directly edited by users, so writability is less of a concern for me.
Here's a simple example comparing the two formats (for a full example with a more complicated proto, see this gist):
pbtxt
identifiers {
  type: NAME
  value: "deoxyfluorination"
}
inputs {
  key: "alcohol in THF"
  value {
    components {
      identifiers {
        type: SMILES
        value: "c1ccccc1CCC(O)C"
      }
      moles {
        value: 0.1
        units: MILLIMOLES
      }
      reaction_role: REACTANT
      is_limiting: true
      preparation {
        type: NONE
      }
    }
    components {
      identifiers {
        type: NAME
        value: "THF"
      }
      identifiers {
        type: SMILES
        value: "C1CCCO1"
      }
      volume {
        value: 125.0
        units: MICROLITER
      }
      reaction_role: SOLVENT
      preparation {
        type: DRIED
      }
    }
    addition_order: 1
  }
}

JSON
{
  "identifiers": [
    {
      "type": "NAME",
      "value": "deoxyfluorination"
    }
  ],
  "inputs": {
    "alcohol in THF": {
      "components": [
        {
          "identifiers": [
            {
              "type": "SMILES",
              "value": "c1ccccc1CCC(O)C"
            }
          ],
          "moles": {
            "value": 0.10000000149011612,
            "units": "MILLIMOLES"
          },
          "reactionRole": "REACTANT",
          "isLimiting": true,
          "preparation": {
            "type": "NONE"
          }
        },
        {
          "identifiers": [
            {
              "type": "NAME",
              "value": "THF"
            },
            {
              "type": "SMILES",
              "value": "C1CCCO1"
            }
          ],
          "volume": {
            "value": 125.0,
            "units": "MICROLITER"
          },
          "reactionRole": "SOLVENT",
          "preparation": {
            "type": "DRIED"
          }
        }
      ],
      "additionOrder": 1
    }
  }
}

Thoughts?

I'm leaning toward pbtxt as well.
Fewer quotation marks goes a long way for readability IMO. It's very easy to look at a pbtxt and distinguish between words that are part of the schema (field names, all caps enum options) and user-entered text (in quotation marks) or user-entered float values. This seems very useful for administrators reviewing submissions.
The two cons I see are (1)  how pbtxt handles repeated fields or maps (i.e., repeating the name of the field for each entry, making it less clear which fields are allowed to repeat) and (2) json is already universally recognizable and parseable.

OK, let's go with pbtxt for now and we can be sure to include documentation on how to get JSON if people want it for other things.

On further reflection, we are going to prefer binary format. This is largely driven by space considerations, as well as to discourage manual editing of protos (i.e. apart from the programmatic or graphical tools we provide).


MINOR: [R] Fix repository URL configurations for pkgdown website

Rationale for this change
When manually setting repository URLs for pkgdown, four different URLs could be set (home, source, issue, user).
https://pkgdown.r-lib.org/reference/build_site.html#source-repository
Because two of these (home, user) are not configured, the link to the repository home (the GitHub icon in the upper right corner of the menu bar) and the links to the users (the links from the account names on Changelog to the GitHub account) are currently not enabled on the arrow package website.
What changes are included in this PR?
Set up a link to the repository home and links to the users so that pkgdown's ability to link to the repository is fully functional.
Are these changes tested?
I built the website locally by using the pkgdown::build_site_github_pages() and verified that the link works.
Are there any user-facing changes?
No.

@github-actions crossbow submit preview-docs


support for Pin64

Hi.
I know Pine64 is not supported, but it would be great to have it running also on that board (I want to use it for an home automation system)
I try several way to compile the vernemq source code. With the following I can reach the end of the compilation phase, but it gives me an issue with the nif library when I try to start it (probably it's for a path misconfiguration, but I don't know erlang):
Install the following packages (ubuntu xenial):
libssl-dev
libncurses5-dev
openjdk-8-jre-headless
openjdk-8-jdk-headless
git
libsnappy-dev
erlang erlang-dev

git clone git://github.com/erlio/vernemq.git
cd vernemq
make rel

vi _build/default/lib/eleveldb/c_src/build_deps.sh (commented the following lines to avoid an issue with libsnappy)
# if [ ! -d snappy-$SNAPPY_VSN ]; then
#     tar -xzf snappy-$SNAPPY_VSN.tar.gz
#     (cd snappy-$SNAPPY_VSN && ./configure --prefix=$BASEDIR/system --libdir=$BASEDIR/system/lib --with-pic)
# fi

# (cd snappy-$SNAPPY_VSN && $MAKE && $MAKE install)

# export CFLAGS="$CFLAGS -I $BASEDIR/system/include"
# export CXXFLAGS="$CXXFLAGS -I $BASEDIR/system/include"
# export LDFLAGS="$LDFLAGS -L$BASEDIR/system/lib"
# export LD_LIBRARY_PATH="$BASEDIR/system/lib:$LD_LIBRARY_PATH"

vi _build/default/lib/eleveldb/c_src/eleveldb.cc
line 243
from
size_t memory_sz;
to
unsigned long memory_sz;

make rel

vi _build/default/lib/eleveldb/c_src/leveldb/port/atomic_pointer.h
line 96 add (otherwise it can compile for the Pine64 arch)
inline void MemoryBarrier() {
  // See http://gcc.gnu.org/ml/gcc/2003-04/msg01180.html for a discussion on
  // this idiom. Also see http://en.wikipedia.org/wiki/Memory_ordering.
  __asm__ __volatile__("" : : : "memory");
}
#define LEVELDB_HAVE_MEMORY_BARRIER

vi _build/default/lib/eleveldb/c_src/Makefile
line 38
# LDFLAGS += -shared leveldb/libleveldb.a system/lib/libsnappy.a -lstdc++
LDFLAGS += -shared leveldb/libleveldb.a -lstdc++

vi _build/default/lib/mzmetrics/c_src/mzmetrics_nif.c
line 67
// unsigned int align_num_resources(unsigned int num)
static unsigned int align_num_resources(unsigned int num)

vi _build/default/lib/mzmetrics/c_src/mzmetrics_counters_no_preallocation.c
line 6
// #include <cpuid.h>
line 36
// #ifdef __linux__
from line 38
/* #else
    unsigned int eax, ebx, ecx, edx;
    if (!__get_cpuid(1, &eax, &ebx, &ecx, &edx))
        return 0;
    return 0;
#endif */

When I run it I've got the following error:
cd _build/default/rel/vernemq/
./bin/vernemq console

08:02:32.188 [warning] The on_load function for module eleveldb returned {error,{load_failed,"Failed to load NIF library: '/usr/src/apps/vernemq/vernemq/_build/default/rel/vernemq/bin/../lib/eleveldb-2.0.2+build.498.refbc30c2c/priv/eleveldb.so: undefined symbol: _ZN6snappy13RawUncompressEPKcmPc'"}}
08:02:32.189 [error] CRASH REPORT Process <0.97.0> with 0 neighbours exited with reason: call to undefined function eleveldb:validate_options(open, [{block_cache_threshold,33554432},{block_restart_interval,16},{block_size_steps,16},{compression,...},...]) in gen_server:init_it/6 line 352

Hope you can help me

Hi @njordr great effort! :+1:
Have you compared this against the build on Raspberry ('make rpi32')?
I have the strange feeling that I have seen this error, in playing around on the RPi.
@larshesel does this ring a bell?

This error doesn't ring a bell, I'm afraid. But I did notice this:
vi _build/default/lib/eleveldb/c_src/Makefile
line 38
# LDFLAGS += -shared leveldb/libleveldb.a system/lib/libsnappy.a -lstdc++
LDFLAGS += -shared leveldb/libleveldb.a -lstdc++

This means you're not linking against snappy which explains that the symbols for snappy are not found at runtime. Try and re-add the system/lib/libsnappy.a to the LDFLAGS.

Hi @larshesel
This is why I commented the link to snappy lib:
cc: error: system/lib/libsnappy.a: No such file or directory
Makefile:58: recipe for target '/usr/src/apps/vernemq/vernemq/_build/rpi32/lib/eleveldb/c_src/../priv/eleveldb.so' failed
make[1]: *** [/usr/src/apps/vernemq/vernemq/_build/rpi32/lib/eleveldb/c_src/../priv/eleveldb.so] Error 1
make[1]: Leaving directory '/usr/src/apps/vernemq/vernemq/_build/rpi32/lib/eleveldb/c_src'
===> Hook for compile failed!
@ioolkos I try to copile for rpi32 but I've got the same error. This is why a bell ring in your head https://github.com/erlio/vernemq/issues/175 :)

Could you do a fresh build without any changes and post the entire compile output so we can see what the problem with compiling libsnappy (or other things) is?

I'm going to try in few minutes
In the meantime I try to totally disable link to snappy lib, modifying the files above and the file:
_build/rpi32/lib/eleveldb/c_src/leveldb/build_detect_platform
line 175 changed to
if [ "$?" = 355 ]; then
in this way I've got vernemq up & running:
09:39 [root@cerbero:vernemq] 15s # ./bin/vernemq ping
pong
But I don't know if I broke everything :D
I'll send the clena compilation logs in few minutes

Attached the make rpi32 output.
The error is related to an old build_detect_platform script. If you update it, it fails because it cannot recognize the platform
make.txt

alright - since we don't have a pine64 board we're in a bad position to fix this and support that board in general. We would of course be happy to accept a PR fixing this issue.
I suppose you, by disabling snappy completely, have a working solution?

it seems, I want to make the benchmarking tests to sign it off
Which is the role of snappy libraries?

Snappy is a compression/decompression library used by leveldb. Without it I suppose none of the data stored in leveldb is compressed in any way (neither in-mem or on disk). What that means for performance I have no idea, but in any case I wouldn't expect too much in terms of performance on any arm board using sd-cards as storage ;-)

ahahahahahah, great and thanks for the support

You're welcome, let's know if you run into other issues!


giving error asyncio unable to run the tool

Traceback (most recent call last):
File "./openredirex.py", line 126, in
main()
File "./openredirex.py", line 108, in main
asyncio.run(redirme(args.list, args.payloads, args.keyword))
AttributeError: module 'asyncio' has no attribute 'run'
Im getting this while running

solved by  :
1 - going to : https://www.python.org/downloads/
2 - downloading python3.8.2
3 - installing it using the following commands:
./configure
make
make test
sudo make install
4 - then runing  :
sudo pip3 install aiohttp
and finally it worked :
python3 openredirex.py -l urls.txt -p payloads.txt --keyword FUZZ
@devanshbatham thanks for those awesome tools

Thanks mate for the feedback, credit goes to  @NullPxl 😊

@balook asyncio.run() is a new function in python 3.7.  Try running it with python3.7+ with aiohttp installed.  Try following kherwata's guide on installation if you get stuck.

Traceback (most recent call last):
File "/home/kali/Bugbounty/OpenRedireX/openredirex.py", line 126, in
main()
File "/home/kali/Bugbounty/OpenRedireX/openredirex.py", line 108, in main
asyncio.run(redirme(args.list, args.payloads, args.keyword))
File "/usr/local/lib/python3.9/asyncio/runners.py", line 44, in run
return loop.run_until_complete(main)
File "/usr/local/lib/python3.9/asyncio/base_events.py", line 642, in run_until_complete
return future.result()
File "/home/kali/Bugbounty/OpenRedireX/openredirex.py", line 80, in redirme
await gen_tasks(session, url_list, payload_list, keyword)
File "/home/kali/Bugbounty/OpenRedireX/openredirex.py", line 39, in gen_tasks
results = await asyncio.gather(*tasks)
File "/home/kali/Bugbounty/OpenRedireX/openredirex.py", line 46, in getResponse
async with session.get(r_url, allow_redirects=True, timeout=10) as response:
File "/usr/local/lib/python3.9/site-packages/aiohttp/client.py", line 1117, in aenter
self._resp = await self._coro
File "/usr/local/lib/python3.9/site-packages/aiohttp/client.py", line 492, in _request
req = self._request_class(
File "/usr/local/lib/python3.9/site-packages/aiohttp/client_reqrep.py", line 305, in init
self.update_host(url)
File "/usr/local/lib/python3.9/site-packages/aiohttp/client_reqrep.py", line 366, in update_host
raise InvalidURL(url)
aiohttp.client_exceptions.InvalidURL: 88407996/articles?portalId=5212498&currentArticleId=10127762043&currentArticleLanguage=en&currentUrl=https://help.aware360.com/knowledge-base/setting-your&ssoLogin=false


FuturesAsyncWriter return incorrect written size

#[tokio::main]
async fn main() -> Result<()> {
    let mut w = make_writer().await?;

    let data = "hello, opendal";
    for _ in 0..1_000_000 {
        w.write_all(data.as_bytes()).await?
    }

    w.shutdown().await?;
    let wsize = w.written_size.load(std::sync::atomic::Ordering::SeqCst);
    println!("written size: {wsize}");

    Ok(())
}

async fn make_writer() -> Result<TrackWriter> {
    let mut builder = Fs::default();
    builder.root(".");
    let op: Operator = Operator::new(builder)?.finish();

    let w = op
        .writer("test.txt")
        .await
        .unwrap()
        .into_futures_async_write();
    Ok(TrackWriter::new(w))
}

// Copied from https://github.com/icelake-io/icelake/blob/main/icelake/src/io/parquet/track_writer.rs
/// `TrackWriter` is used to track the written size.
pub struct TrackWriter {
    writer: FuturesAsyncWriter,
    written_size: Arc<AtomicU64>,
}

impl tokio::io::AsyncWrite for TrackWriter { ... }

Full code can be found in this repo
The above code write a simple string literal "hello, opendal" to local file test.txt  1_000_000 times using FuturesAsyncWriter.
The expected written_size should be 14000000, but the above code print 14000326 on my machine which does not match the file size.
opendal version: 0.47.1
rustc version: rustc 1.79.0 (129f3b996 2024-06-10)

Hi, please double check the code here:
https://github.com/nooberfsh/opendal_incorrect_write_szie/blob/6f1780a3ca192c0f49f34254245f43ca54634390/src/main.rs#L68-L71
There is no guarantee that write will always write the entire buffer. Therefore, we should calculate the returned n instead.

That piece of code is from icelake, It was originally use the returned n,  this commit changed it to buf.len().
I didn't aware it was changed, sorry for the bother. I will open an issue in icelake.


Update metrics.py

I think this fixes an incorrect import?

Cleanup after #97, xref #96.

Hi @vidartf - thanks for looking into this.
I think the actual change relative to this file is to remove it altogether since it was moved from here into prometheus/log_functions.py in this change: https://github.com/jupyter/notebook/commit/03e5dc00e1639137d9ed5ce4caeb2639ca2650d6 and is no longer present in this location within Notebook.
And then apply this commit https://github.com/jupyter/notebook/commit/7bc7df472c8ff4b8de284c5c5b2178d52561c9a4 to prometheus/log_functions.py as it appears the cherry-pick for this commit was applied to the "pre-moved" metrics.py instead of prometheus/log_functions.py.
I think this would explain why the tests (relative to Batch-3) are passing and we're not getting failure on the change you proposed - which the correct fix otherwise.
Would you mind updating this PR to delete jupyter_server/metrics.py and apply the import update to juptyer_server/prometheus/log_functions.py?

Cleaned up


[botan] update to version 2.17.3

feat add debug symbols

triplets supported/not supported? Have you updated the CI baseline?
all

Does your PR follow the maintainer guide?

YES

If you are still working on the PR, open it as a Draft: https://github.blog/2019-02-14-introducing-draft-pull-requests/

Please run ./vcpkg format-manifest --all :)

Please run./vcpkg format-manifest ./ports/botan/vcpkg.json to format vcpkg.json file.

LGTM now, thanks for your update @agrandville.
For the failures on osx pipeline, there is something wrong with our CI, which is not related with this PR. I will rerun it once solved.

/azp run

The failures caused by popsift will be fixed by #17277.

Error: While reading versions for port botan from file: C:\a\1\s\versions\b-\botan.json
       File declares version `2.17.3` with SHA: f355b4fc82c9cb1c7de67be66ac517931a488f01
       But local port with the same verion has a different SHA: 2d15c43909a9409da601e7b01a9a3a288c50bfb9
       Please update the port's version fields and then run:

           vcpkg x-add-version botan

       to add a new version.

Please run vcpkg x-add-version botan again to update versions.
Note: Have you tested the usage of botan? I noticed that added botan-config.cmake file in the last commit.

I'm upgrading the cmake scripts of opendnssec/SoftHSMv2 project who use vcpkg botan.
For now, SoftHSM compile, with botan crypto backend and vcpkg toolchain, fails due  to missing BotanConfig.cmake file.

You can use vcpkg-x-add-version --overwrite-version botan to update the version files.

@agrandville could you please merge with latest?

@agrandville
Could you please address the review suggestions? Thanks.

Closing this PR since it seems that no progress is being made. Please reopen if work is still being done.


⚠ ClamAV has degraded performance

In 120cfa2, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 490 ms

Resolved: ClamAV performance has improved in 1d7cf8f.


chore(package): repository settings

Prebot App Settings to sync repository settings defined in  .github/settings.yml  to GitHub

:tada: This PR is included in version 1.3.1 :tada:
The release is available on:

npm package (@latest dist-tag)
Visual Studio Marketplace
GitHub release

Your semantic-release bot :package::rocket:


[dev] Remove unnecessary aliases from webpack config

As discussed in https://github.com/CenterForOpenScience/osf.io/pull/2129#discussion_r26187513, the aliases for internal modules are unnecessary, as we already set resolve.root to website/static.
These aliases should be removed in favor of resolving from the root, like so
// Yes
var diffTool = require('js/diffTool');  // can also omit extesion

// No
var diffTool = require('diffTool.js'); // with webpack alias

Closed by https://github.com/CenterForOpenScience/osf.io/pull/2271


setADC() cause freeze arduino when i2c device attached

when try to using setADC() arduino hung if lcd i2c attached, but when disconnected lcd it run without any issue

Thanks for the issue.
Can you provide some info e.g address of i2c lcd and the address of the external adc.
Furthermore a minimal sketch that shows the problem might help me to reconstruct the issue.

As no info is provided I assume the problem is solved.
Feel free to reopen the issue if needed (and please provide requested info)


Export uses wrong tiles when caches convert between image formats

I have some caches:

The main cache, using image/png (as per default), referencing a WMS source
Based on the main cache as source:

One with image: mixed and request_format: png
One with image/jpeg

Based on the mixed cache as source:

Another cache with image/jpeg

They all use the same grid, the only difference is the format.
All caches are empty as I start this.
If I request some imagery from them via WMTS, they get filled with data.
Everything as expected: PNG tiles for the PNG one, both PNG and JPEG tiles for the mixed one and JPEG tiles for the JPEG one. I also confirmed this by storing the tiles in SQLite caches and inspecting the tile BLOBs.
But when I use mapproxy-util export to write any of the non-main caches to a SQLite file, the result is all PNG tiles regardless of the format specified for the cache.
Context
My goal was to use mapproxy-util export to transform an existing cache into another image format.
Expected Behavior
The exported tiles should be in the format specified for the cache.
Actual Behavior
The exported tiles are not in the format specified for the cache.
Steps to Reproduce
I made an reproducible example based on the public demo available at https://www.orka-mv.de/geodienste/orkamv/demo/

Grab the files from https://gist.github.com/kannes/61fe21c861079f717d9776752b696358
Launch mapproxy-util serve-develop wrong-formats-on-export.yml
Launch bash seed-caches.sh to do some requests and get tiles from the remote source
mapproxy-util export -f wrong-formats-on-export.yml --source=myjpegcache --grid=mygrid --levels=10 --type=sqlite --dest=export_jpeg
mapproxy-util export -f wrong-formats-on-export.yml --source=mypngcache --grid=mygrid --levels=10 --type=sqlite --dest=export_png
mapproxy-util export -f wrong-formats-on-export.yml --source=mymixedcache --grid=mygrid --levels=10 --type=sqlite --dest=export_mixed
Inspect the tiles, e.g. using sqlitebrowser, they are all PNG

Context
Probably related to #94 and #52
Your Environment

MapProxy 1.14.0
Python 3.8.10
Ubuntu 20.04

Addendum:
It seems to work fine if a base cache is JPEG and one wants to convert to PNG. But maybe everything gets turned into PNG so this might be a red herring. :)
I used this horror in the Gist linked above to test:
  myjpegbasecache:
    grids: [mygrid]
    sources: [mysource]
    format: image/jpeg
    image:
      resampling_method: nearest
      encoding_options:
        jpeg_quality: 5
    disable_storage: false
    cache:
      type: sqlite
      directory: /tmp/myjpegbasecache/
  mypngfromjpegcache:
    grids: [mygrid]
    sources: [myjpegbasecache]
    format: image/png
    disable_storage: false
    cache:
      type: sqlite
      directory: /tmp/mypngfromjpegcache/

Then seeded via:
curl http://<IP_ADDRESS>:8080/wmts/mypngfromjpegcachelayer/mygrid/10/23/11.jpeg > /dev/null
curl http://<IP_ADDRESS>:8080/wmts/mypngfromjpegcachelayer/mygrid/10/24/11.jpeg > /dev/null
curl http://<IP_ADDRESS>:8080/wmts/mypngfromjpegcachelayer/mygrid/10/24/12.jpeg > /dev/null

and exported:
mapproxy-util export -f debugging.yml --source=mypngfromjpegcache --grid=mygrid --levels=10 --type=sqlite --dest=mypngfromjpegcache
The resulting SQLite export contained all PNG tiles.

I successfully tested standard seeding to see if that used a working code path and it worked successfully:

Set the cache to store its tiles in sqlite
Write a seeding YAML for the whole coverage of it and the desired zoom levels
Run the seeding
The created .mbtile files should basically be identical to what the export would have created

Sorry, I made a total mess with the "reproducible" example above. Should be fixed and actually easy to reproduce now I hope.

I got some lazy downtime at the moment and thought I'd browse around to maybe find the issue. I did not but I did notice some things that might help (or turn out to be red herrings). It's quarantine and the spiders on the walls are closing in so this might be incoherent rambling, sorry in advance...
mapproxy-util export warns about incompatible grids for jpeg+mixed
For the jpeg and mixed caches, I get warning:
WARN: grids are incompatible. needs to scale/reproject tiles for export.
For the png cache this does not appear.
They all use the very same grid and from everything I read about Grids in the documentation, the image format has nothing to do with them.
-> No idea what's up with this or it if is related in any way
Amount of tiles in export varies

cache contains 48 tiles
export_png ends up containing 48 tiles
export_jpeg ends up containing 464 tiles
export_mixed ends up containing 240 tiles

Yes, I deleted everything in between. :o)
-> No idea... I guess it is related to the different grid issue? I didn't look into this any further.
The PNG tiles ending up in the jpeg and mixed exports are new
I extracted the 10/22/8 tile from the caches and compared them:

Bytes
MD5
File

30988
2f095fedf714218b194b325323d5c7e1
mycache.png

30988
2f095fedf714218b194b325323d5c7e1
mypngcache.png

30720
771c7e8061fa39c80530a4a248b822c5
myjpegcache.png

30720
771c7e8061fa39c80530a4a248b822c5
mymixedcache.png

So I guess what happens is NOT that existing tiles are re-used as-are from the existing cache (PNG) but they actually do get compressed as PNG again explicitly at some point leading to slightly different files compared to the originals.
-> OK, cool. Helped me drop the idea that there was some broken mechanism that mistakenly took existing tiles even though they were not the wanted format.
image_opts goes from jpeg to png
When processing identifier='export_mygrid' for the jpeg cache
https://github.com/mapproxy/mapproxy/blob/b44b90045e26ea6bf4df2e8b97c1896f3147f540/mapproxy/config/loader.py#L1547 ends up turning the inputs
source_image_opts=[ImageOptions(
    encoding_options={},
    format='image/jpeg',
    resampling='bicubic'
)]

and
base_image_opts=ImageOptions(
    colors=256,
    encoding_options={},
    format='image/png',
    resampling='bicubic'
)

into
image_opts=ImageOptions(
    colors=256,
    encoding_options={},
    format='image/png',  # <- EEEEK!
    resampling='bicubic'
)

This leads to its TileManager using image/png and I guess that's how it trickles further? Or maybe this is fine and it is actually the base_image_opts that are wrong here (and should be with JPEG already)? When I overwrote the image_opts with ImageOptions(encoding_options={}, format='image/jpeg', resampling='bicubic') here I did end up with all JPEG tiles.
-> Probably a red herring.
To be continued
Next comment has some actual finding in it, I promise.

The "export" cache gets assigned "image/png" because no value is configured?
ConfigurationBase's init will fill a configuration with default values if they do not exist:
https://github.com/mapproxy/mapproxy/blob/b44b90045e26ea6bf4df2e8b97c1896f3147f540/mapproxy/config/loader.py#L260-L264
For a CacheConfiguration there is defaults = {'format': 'image/png'}:
https://github.com/mapproxy/mapproxy/blob/b44b90045e26ea6bf4df2e8b97c1896f3147f540/mapproxy/config/loader.py#L1049=
And behold, for the temporary volatile "export" cache used by the export util, there is no format configured. On init for the jpeg cache its self.conf is
{
  'name': 'export',
  'grids': ['mygrid'],
  'sources': ['myjpegcache'],
  'cache': {'type': 'sqlite', 'directory': 'export_jpeg'}
}

and thus {'format': 'image/png'} gets added. This seems like the base issue. Yay!
Fixed by copying the source cache's format configuration
I fixed this by grabbing the existing source cache's format configuration and adding it to the cache_conf just before the CacheConfiguration is created in export.py:
cache_conf['format'] = conf.caches[options.source].conf["format"]
Alternatively conf.caches[options.source].image_opts().format could be used, not sure which one is more suitable. We probably need more configuration from the source cache that is not in the image_opts so I chose the former option.
-> Now I get JPEG tiles when I export the myjpegcache and PNG tiles when I export the mypngcache. Hooray!
"mixed" mode is still broken
For exporting mymixedcache MapProxy rightfully complained about the request_format not being set to image/png for the "export" cache so I added that as well:
request_format = conf.caches[options.source].conf.get("request_format")
if request_format is not None:
    cache_conf['request_format'] = request_format

Now exporting mymixedcache works but the result contains all JPEG tiles. :(
What I investigated:

In MBTilesCache._store_bulk() the content is always JPEG, not mixed JPEG or PNG. I confirmed this by writing each content to a file and checking what I got. -> Bad image data here.

MBTilesCache._store_bulk() uses the tile_buffer() context manager which uses tile.source.as_buffer() which is ImageSource.as_buffer()

ImageSource.as_buffer() uses img_to_buf() and here I do see mixed tiles being created though. Again confirmed by writing them to files, here I got both JPEG and PNG files, the format is correctly chosen for empty or mixed tiles. -> Correct image data here.

I tried to find out more but there is too much magic around this and no documentation or explanation on the general architecture so I had to give up.

Note

Something seems to force a bad PNG mode by default, I had to add paletted: false to the configuration to actually get transparency in the PNGs instead of white or black color in the "mixed" tiles. For testing I did this using the globals:

globals:
  image:
    paletted: false

MBTilesCache's load_tile() and load_tile_metadata() seem to have broken handling of dimensions. I added dimensions=None as additional parameter to load_tile() and set dimensions=None as default value for load_tile_metadata(). No idea what it is all about, if that is the correct handling or if I broke something so I can't make a PR with that. For me, MapProxy had crashed due to the parameter missing for load_tile().

I think this is fixed by https://github.com/mapproxy/mapproxy/pull/599. Feel free to create a new issue if needed

I think we just forgot to close this. Thank you!


Add healthz path to AlwaysAllowPaths

The "/healthz" API is supposed to be accessed anonymously. However,
there were unintentional subjectaccessreviews queries sent to the
Kubernetes API when kubelets were executing liveness probe for antrea
components. This patch adds "/healthz" path to AlwaysAllowPaths to avoid
unnecessary overheads to the Kubernetes API.

/test-all

@antoninbas it didn't create issues, I observed failed subjectaccessreview requests every 10 seconds when debugging https://github.com/vmware-tanzu/antrea/issues/802#issuecomment-640681757 with Jay (cannot access K8s svc after toggling security group is another issue I haven't root caused yet and may need a EC2 cluster to reproduce) and realized it would lead to 100 requests per second to K8s API in a scale cluster with 1000 nodes.


Allow for overriding remote environment variables with those from a local file.

Looking for a way to override the remote environment variables from a local file, like a .env file.  This would allow for a quick way to replace only targeted variables without having to directly edit the main mirrord config every time a variable should be overridden.
Could be done with something like
{
  "feature": {
    "env": {
      "override": {
        "DATABASE_CONNECTION": "db://localhost:7777/my-db",
        "LOCAL_BEAR": "panda"
      },
      "overrideEnvFile": "./env"
    }
  }
}

or if possible, have mirrord check what's defined locally and then override from there.
Thanks!

This has actually already been suggested - see #1913 . Closing this one as duplicate.


make step and int_step consistent

Summary:
int_step(x) and step(x) return different values for 0 and NaN.

[ ] Change the definition of step(x) so that it matches int_step(x)
[ ] update definitions in doc and include note that the behavior of step() has changed
[ ] update unit tests

OR

[ ] deprecate both of these functions and suggest (x > 0) as a replacement for step(x) and int_step(x).

OR

[ ] deprecate step() in favor of int_step()

Description
Here's what the definitions look like now.
template <typename T>
inline int int_step(const T& y) {
  return y > 0;
}

vs.
template <typename T>
inline double step(const T& y) {
  return y < 0.0 ? 0 : 1;
}

Other Info
BUGS defines step(x) == (x >= 0), which matches our current int_step() and is the behavior that makes most sense to me.
Current Version:
v2.17.0

I just submit 2 pull requests, one in https://github.com/stan-dev/stan/pull/2501, which matches tests across int_step.stan and step.stan and one in https://github.com/stan-dev/math/pull/805, in which the step function definitions were changed and tests were updated.  Review when convenient, please.  Thanks.

Thanks.  I'll get to these ASAP.


Support for totalDuration metadata from network inputs

Description:
Include in the OnProgressChanged event args an object containing data supplied by ffmpeg's startup logging, Specifically this line :
Duration: 00:05:34.08, start: 0.000000, bitrate: 1530 kb/s

The MediaInfo replaces the current totalDuration value that doesn't work much of the time.
The current value reports 00:00:00 when the source is accessed by ftp/http or when the engine is started using custom args by calling Execute
I am unsure if my technique of getting the data from the ffmpeg stdout logging has any downsides, but as far as I can see it works well.
Perhaps MediaInfo should be renamed to ClipInfo? Thoughts?

I just Removed a few bits that snuck in from something else I was testing.


Generate test coverage report

This is kind of a proposal actually. Running a mere coverage check on the main package, I found out it was pretty low and thought it'd be a good idea to have a coverage check run in the CI pipeline.
The script comes from codecov/example-go, and the coverage badge in the readme will work as soon as the account on codecov.io is ready.
Do you also think this make sense?

Codecov Report

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

@@           Coverage Diff            @@
##             master     #83   +/-   ##
========================================
  Coverage          ?   59.3%
========================================
  Files             ?       3
  Lines             ?     376
  Branches          ?       0
========================================
  Hits              ?     223
  Misses            ?     144
  Partials          ?       9

Continue to review full report at Codecov.

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


Healthy thinking report icon list

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

Original: https://www.sunstar.com/healthy-thinking-report/oral-survey-2021

Before: https://main--sunstar--hlxsites.hlx.live/healthy-thinking-report/oral-survey-2021

After: https://healthy-thinking-report-icon-list--sunstar--hlxsites.hlx.live/healthy-thinking-report/oral-survey-2021

[ ] New Blocks introduced in this PR
If yes, please provide details below
Block Name : For e.g. cards

[ ] Documented in sidekick library

[x] New variations introduced in this PR
Variation Name :  Image-Collage(icon-caption), Image-Collage(icon-title-text), Image-Collage(icon-title-list)

[x] Documented in sidekick library

[ ] New mixins introduced in this PR
Mixin Name :  For e.g. compact, white

[ ] Documented in sidekick library

Do you think we could replace the authoring experience for the first collage with something like this? We would also leverage the caption autoblocking this way and it might be easier for the authors to visualise what they're going for

@dnbute It's a good idea to let the author know the same look&feel during the authoring. I think it's something related to the authoring habit. Somebody feel it's easier to use 2 columns table for authoring, and somebody prefer multiple columns. So far, grid type blocks like Image-Collage and Cards follow the 2 columns table, I think it's great to keep the consistency.
Also, these variations are just introduced by healthy-thinking-report page, I don't feel it can bring much benefit to involve autoblocking. What do you think?

Do you think we could replace the authoring experience for the first collage with something like this? We would also leverage the caption autoblocking this way and it might be easier for the authors to visualise what they're going for

@dnbute It's a good idea to let the author know the same look&feel during the authoring. I think it's something related to the authoring habit. Somebody feel it's easier to use 2 columns table for authoring, and somebody prefer multiple columns. So far, grid type blocks like Image-Collage and Cards follow the 2 columns table, I think it's great to keep the consistency. Also, these variations are just introduced by healthy-thinking-report page, I don't feel it can bring much benefit to involve autoblocking. What do you think?

Those are some good points as well, I think that the current image-collage is like that because that's what was needed at that point (I think it was created for the engineering website), I do agree that we should keep the experience consistent however. imho I think it's just a matter of opinion at this point, but yeah, since we have a pretty big number of blocks, consistency wins, let's keep it like this

@dnbute This was cached during my testing, I just clear the cache.

The last icon repeats a bunch of times, I might be wrong but this doesn't seem intended


Hidden spot on itens!

Could be possible have a hidden spot here to include spells like curses? Could be nice player dont have access to all information about the item. Or just be possible turn the notes field only avaialble to GM

This is an interesting idea.   We currently don't model the "identified" status of an item.
However, this is a module, GM Notes https://foundryvtt.com/packages/gm-notes that adds that to Character and Items sheets.   I will leave this issue open, in case we do decide to model the "identified" status.  But for now, I think you can do what you want  using the GM Notes module.


Translation Issues

In the last set of strings there are misspellings etc in the English language. Cause I couldn't find a way to inform you via Weblate I post these here.
Key first
Misspelling/issue second
photo_picker_sub
adnroid
file_explorer_picker_sub
recieving
pciked
add_sequence_number_sub
strandard
add_sequence_number_sub
(key uses „add“, string uses „replace“)
BTW, if you want a clean issue section you can probably shift this topic to Discussions. I can't open one in an inaccessable area, so I put it here.

Oh, thabks, i will fix it :)

You can fork the project and open a PR with updated strings, that would be great, because I don't have much time now :(

Also, does Weblate perhaps allow for activating and filling in a context field? See https://docs.weblate.org/ru/latest/user/translating.html#source-context and also the image right above, see field "explanation". Context would help a lot!

Not sure whether a closed topic sends mail. So perhaps leave open or transfer to discussions.
Can you explain a little about the sense of the special orthography in sequenceNum and originalFilename? Is that a variable, so should be left untranslated?
Another typo, BTW, in string load_image_from_net_sub form - > from

The last one is typo, first ones is needed to be translated, so everyone will get the meaning of each setting :)

Will fix everything

Also, does Weblate perhaps allow for activating and filling in a context field? See https://docs.weblate.org/ru/latest/user/translating.html#source-context and also the image right above, see field "explanation". Context would help a lot! Or screenshots of new UI elements.

I will check what is it👀

Thanks!
In the meantime, I think I found the two "variables" in the app's UI itself: These are used in the prefs drawer, for composing the example filename, right? So they should be as short as possible. These three informations (what, where, purpose (and - if suitable - how)) are often useful for us translators :)
If there's a direct communication channel to activate in Weblate itself, like Crowdin offers to its users, that'd be also great for translators for asking re specific strings.

No, unfortunately I have not heard of such a possibility (

explicit_description:
"give" should be "given"

Thanks!


Add retries when requesting the Grafana server

This fix for the issue #95 adds a fixed number of retries (5 attempts
with a 1 second interval between each) in case the Grafana server isn't
ready to serve the requests immediately.

Awesome :)


Update block production algorithm once ZIP-317 updates

Motivation
We're expecting a minor update to the ZIP-317 block production algorithm.
Specifications
https://zips.z.cash/zip-0317
With the changes from the PR:
https://github.com/zcash/zips/pull/650
Designs

Replace the dynamic size limit with a fixed action limit. This makes the design simpler.

Don't make the limit configurable for now, we'll see if we need to do that later.

Update comments to link to ZIP-313:

[ZIP-313]: https://zips.z.cash/zip-0313#specification
https://github.com/ZcashFoundation/zebra/pull/5724#discussion_r1036518490

Replace "transparent P2SH single signature address" with "transparent P2SH address", the single signature part is wrong

@teor2345 can you please add an estimate to this issue?


Add User classes and changes name of Enum folder User

Adds the classes User, NewUser, Patient, Staff, and Admin into the backend folder. The Enum folder User is also changed to Users in order to avoid collisions between said folder and User.java and User class.

LGTM, thanks for your work!

Based on the UML Diagram in our Software Design Document, I assume the maximum is 32.

Ignore the commit Testing as there are no changes and there were simply issues from my side.


[VestedToken] Check if tokens can be transferred on transferFrom

While becoming more familiar with the idea of approve and transferFrom I have just realized that the current implementation of VestedToken was broken and one could bypass the vesting calendar transferring tokens using approve and transferFrom as the amount of transferrableTokens wasn't checked.
This is pretty bad as someone can do approve(myself, tokens) and then transferFrom(myself, otherAccount, tokens) and all tokens will be transferred regardless of the grant.
I have been doing some mainnet exploring before posting this, and AFAIK it doesn't look like anyone had deployed it yet. I might be wrong, so if you know anyone running it in production, urge them to revoke all token grants and migrate the contract ASAP.

Good catch. I don't think anyone has deployed a VestedToken yet. Will release new version now


multiple POST variables with same name only appear once

Doing a POST, looking at the variables for a checkbox with multiple values. Expecting:

consent: read
consent: write

However, SAML Tracer shows only one of them. I have not checked whether this affects also GET query parameters.

Hi Martin!
You're right, that's a bug (POST-only, GET works).
My bad... I didn't correctly convert the function parsePOST.
For anyone interested: You can reproduce this using the following two JSFiddles (checking "coding" and "music"):
GET (https://jsfiddle.net/p7sfp61r/1/) produces:
GET
interest: coding
interest: music
other:

POST (https://jsfiddle.net/p7sfp61r/) produces:
POST
interest: coding
other:

I just fixed it in pull request #30.

Thanks Jan for the quick response! Good stuff!


Update to use SDWebImage

Moves from JMImageCache to SDWebImage.
Note my operation storage methodology of using the instance's memory address in a var. Any thought about a better way of doing this with UIImageView when we don't necessarily know where the image view is (like in a table cell or a collection view) and we can't invalidate it in the prepareForReuse method of the cell?

Why not value.to_s?

I figured "%p" % self runs self.inspect and would be more reliable. Do you have an idea about an alternative method, @jamonholmgren?

If it works, fine with me. Using the url of the image as the cache key kind of makes sense, though, doesn't it?

Not really... there's an edge case where two different images request the same image almost simultaneously and it might overwrite the first operation with the new operation. I think it's safer to go based off the UIImageView requesting the image's memory address since we know there'll only be one image request per UIImageView.

... and when that same UIImageView requests a new remote image, we cancel it's previous image operation and start the new one.

WOOHOO! Specs passed. This is ready to go if you guys think it looks good @jamonholmgren @twerth @GantMan

:+1: :shipit:

:clap:


complete docs pertaining to vcm

in particular, how vcm integrates into a pipeline (does it rely on yunitator output? can it take a different input, such as textgrid or rttm with a "chi" speaker tagged?)
and how it can be evaluated (using evalDiar or not?)

I just learned yesterday, there is only 1 line of RTTM produced, because the result applies to an entire audio file. "aha!" :)


Enhancement: disable specific log messages

As a workaround to suppressing unwanted messages from ace, leoflexx.leo contains this code:
f __name__ == '__main__':
    flx.launch(LeoApp)
    allowed = r'(Critical|Error|Leo|Session|Starting|Stopping|Warning)'
    pattern = re.compile(allowed, re.IGNORECASE)
    flx.set_log_level('INFO', pattern)
    flx.logger.info('LeoApp: after flx.launch')
    flx.run()

Instead, it would be better to "say what I mean":
flx.set_log_level('INFO', ignore="Automatically scrolling cursor")
# or...
flx.set_log_level('INFO', ignore=[
   "Unwanted message 1",
   "Unwanted message 2",
])

Presumably, this could be done in _MatchFilter.filter in flexx/util/logging.py.
Aside: My old Sherlock tracing product allowed even more flexibility: a list of patterns, to be applied in order, that either enabled or disabled tracing: ["+x", "-y", "+z"] where x, y and z could be any pattern.  This list was applied to the function's name, and tracing was enabled or disabled as soon as a pattern matched.  This is surely possible in _MatchFilter (match against record.funcName), but it's probably not worth documenting :-)  Otoh, being able to suppress one or more patterns is worth doing, imo.

Hmm.  What to do if both enabling and disabling patterns are present?  In my use case, disabling should have priority.  But perhaps that's contentious.  If so, maybe the Sherlock way would let the user decide. Something like:
flx.set_log_level('INFO', filters=[
   ("disable", "(possibly regex) pattern 1"),
   ("enable", "Desired (possibly regex) pattern 1"),
   ...
])

But this might be low priority.  Certainly in my use case an ignore list suffices.

It's an interesting thought. I've never felt the need for such precise filtering myself, nor do I know how other projects handle this. Would be interesting to add at somepoint, but probably not a hight priority indeed.

@almarklein I'd like to push back a little bit, and suggest that this item should have a reasonably high priority.
Previously, I muddied the waters by talking about various more complicated ways to disable logs.  Instead, I would be happy with a single new disable arg .  As with the enabling arg, this would either be a string or a compiled regex. Obviously, the regex could disable multiple messages using regex alternation:
disable = re.compile(r'(message1|message2)')

So _MatchFilter.filter would be something like this (not tested):
def filter(self, record):
    match = self.match
    suppress = self.suppress # The suppression arg.
    if not match and not suppress:
        return True
    # Look at suppressions first.
    if isinstance(suppress, str):
        if (suppress in record.name or
            suppress in record.getMessage() or
            suppress in record.funcName
        ):
            return False
    elif suppress:
        if (re.search(suppress, record.name) or
            re.search(suppress, record.getMessage()) or
            re.search(suppress, record.funcName)
        ):
            return False
    # Previous code
    if isinstance(match, str):
        return (match in record.name or
                match in record.getMessage() or
                match in record.funcName)
    else:
        return (re.search(match, record.name) or
                re.search(match, record.getMessage()) or
                re.search(match, record.funcName))

This doesn't seem too difficult ;-)  However, setting self.suppress would take a little more doing.

Here is why this issue is important to me.  Without the proposed enhancement, I can't safely enable any set of messages, because then there is a real danger that I won't enable some error message.
I got bit by this yesterday: no messages, but unexpected results.  It took awhile to remember to turn the debug switch back on so all message would be visible. I then saw the tracebacks. In other words, this code doesn't enable enough:
allowed = r'(Critical|Error|Leo|Session|Starting|Stopping|Warning)'
pattern = re.compile(allowed, re.IGNORECASE)
flx.set_log_level('INFO', pattern)

Sure, I could try to add some more enablers, but there would be no guarantee that these patterns would allow all important errors.  But heh, as I write this I see that adding 'Traceback' to the list would be a good idea ;-)
In short, the only truly safe workaround during testing is to allow all log messages, which is annoying.

I can see your use case, but I'm also curious to what kind of messages are so abundant and annoying that you want to filter them. Before diving into this and making the logger system more complex, maybe there's a simpler solution? E.g. what about simply setting log level to 'WARNING'? Or perhaps these annoying messages should use logger.debug instead of logger.info?

On Tue, Nov 20, 2018 at 4:53 AM Almar Klein<EMAIL_ADDRESS>wrote:

I can see your use case, but I'm also curious to what kind of messages are
so abundant and annoying that you want to filter them. Before diving into
this and making the logger system more complex, maybe there's a simpler
solution? E.g. what about simply setting log level to 'WARNING'? Or perhaps
these annoying messages should use logger.debug instead of logger.info?

Why didn't I think of that?  The messages are:
[W 09:45:42 flexx.app] JS: Automatically scrolling cursor...
Setting the level to 'ERROR' works just fine.
Edward

I'm good with closing this.  Thanks for your help.

That's a log message from your code, right? Maybe consider logging such a message using logger.info() or logger.debug(); it does not look like a warning to me :)

On Wed, Nov 21, 2018 at 2:11 AM Almar Klein<EMAIL_ADDRESS>wrote:

That's a log message from your code, right?
It's a message from the ace editor.

Maybe consider logging such a message using logger.info() or
logger.debug();
it does not look like a warning to me :)

Huh? Of course it's a warning:
[W 09:45:42 flexx.app] JS: Automatically scrolling cursor...

Maybe consider logging such a message using logger.info() or
logger.debug();

Both show the unwanted message.
Edward


Feature Request: Add timer hud for spells

That would be great if the wheels of fate or spells u use show you a timer hud telling you how many seconds left before it end...
Can show that below of Current Pumpkins: x hud
sry for my bad english...
cheers

Good idea! I'll think it over!

I've investigated this feature and tried to implement it, but many spells have no duration, and wheel of fate spells have different logic, which is why the implementation looks inconsistent and kinda weird. This implementation will confuse players, so I'll not add this to the next version.


Sequence does not open a second time

Sometimes when viewing an expanded sequence, after closing it, the will not reopen in the UI if clicked on. There does not seem to be a workaround, deleting and remaking the sequence with the same name did not fix the issue. Only re-simulating and remaking the sequence entirely on a new simulation dataset works, which is not a viable workaround for longer plans.
Refreshing the page fixes the issue, but then you lose all the simulated children on the view so that's not helpful for expansion purposes either. But it might be a viable workaround when we're able to reload the last simulation into the view.
I'll add more info if I'm able to figure it out; so far it has happened twice but I haven't been able to pin down what might be the common factor.
This was discovered on 0.13.0. I will report if it occurs again.
Internal ticket: https://jira.jpl.nasa.gov/browse/AERIEQS-391

Closing this because no repro steps and it's old. Will reopen with repro steps if we encounter this again.


bug: Flex Message Image: Displays on Mobile but Not on Desktop

Describe the Bug
When sending a Flex Message with an image via the LINE Bot, the image displays correctly on the mobile app but fails to load or display on the desktop version of LINE.
pc

mobile

Steps to Reproduce

Open the LINE Bot on the desktop version of LINE.
Send a Flex Message containing an image.
Observe that the image is missing or not displayed, while it works fine on the mobile app.

Environment Information
LINE desktop version: [e.g., 7.20.1, Windows 10]
Submission Checklist

[X] Follow our Code of Conduct
[X] Check that there isn't already an issue reporting the same bug to avoid duplicates.

Close duplicate GitHub issue regarding Flex Message image bug


Whichkey config and instructions are outdated

Whichkey does not function when following instructions or using this repo

specifically, whickey is missing vim.o.timeout = true to run


手机（安卓）通过WiFi（已设置代理）使用微信某些表情无法接收

正在使用的版本：v2.40 (20171006) 64位（Windows10 X64）
你的使用场景是：通过已设置代理的WiFi使用微信“接收表情图片”
看到的不正常是：微信表情图片无法加载，不关闭聊天窗口v2ray日志不断刷屏
你期待看到的是：微信表情图片正常接收和显示
附上的配置文件： https://github.com/v2ray/v2ray-core/files/1280238/config.json.txt
出错时软件输出：（通过设置安卓代理，使用CCProxy测试可以正常接收，唯独v2ray不行）
V2Ray v2.40 (One for all) 20171006
An unified platform for anti-censorship.
2017/10/13 21:48:50 [Debug]App|Proxyman|Inbound: creating tcp worker on <IP_ADDRESS>:8080
2017/10/13 21:48:50 [Info]Transport|Internet|TCP: listening TCP on <IP_ADDRESS>:8080
2017/10/13 21:48:50 [Warning]Core: V2Ray started
2017/10/13 21:48:55 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/iclZP0U7JBU9Vicu0fJicxXHSmVoa1eKh1EP7HhciaCQVgm3qp94dPOo4Q/]
2017/10/13 21:48:55 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:55 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:55 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:55 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/1eg6vsOfJXB62algww0s1kdPQO2cZ3R3KzmdTL8dDSNC4F6807qCk7h2ClEAbeFV/]
2017/10/13 21:48:55 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:55 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:55 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:55 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|Freedom: connection ends > context canceled
2017/10/13 21:48:55 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/iclZP0U7JBU9Vicu0fJicxXHSmVoa1eKh1EP7HhciaCQVgm3qp94dPOo4Q/]
2017/10/13 21:48:55 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:55 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:55 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:55 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/1eg6vsOfJXB62algww0s1kdPQO2cZ3R3KzmdTL8dDSNC4F6807qCk7h2ClEAbeFV/]
2017/10/13 21:48:55 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:55 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:55 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:55 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|Freedom: connection ends > context canceled
2017/10/13 21:48:55 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|Freedom: connection ends > context canceled
2017/10/13 21:48:55 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/iclZP0U7JBU9Vicu0fJicxXHSmVoa1eKh1EP7HhciaCQVgm3qp94dPOo4Q/]
2017/10/13 21:48:55 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:55 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:55 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:55 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/1eg6vsOfJXB62algww0s1kdPQO2cZ3R3KzmdTL8dDSNC4F6807qCk7h2ClEAbeFV/]
2017/10/13 21:48:55 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:55 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:55 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:55 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/iclZP0U7JBU9Vicu0fJicxXHSmVoa1eKh1EP7HhciaCQVgm3qp94dPOo4Q/]
2017/10/13 21:48:55 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:55 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:55 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:55 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|Freedom: connection ends > context canceled
2017/10/13 21:48:55 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/1eg6vsOfJXB62algww0s1kdPQO2cZ3R3KzmdTL8dDSNC4F6807qCk7h2ClEAbeFV/]
2017/10/13 21:48:55 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:55 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:55 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:55 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/iclZP0U7JBU9Vicu0fJicxXHSmVoa1eKh1EP7HhciaCQVgm3qp94dPOo4Q/]
2017/10/13 21:48:55 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:55 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:55 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:55 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/1eg6vsOfJXB62algww0s1kdPQO2cZ3R3KzmdTL8dDSNC4F6807qCk7h2ClEAbeFV/]
2017/10/13 21:48:55 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:55 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:55 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:55 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/iclZP0U7JBU9Vicu0fJicxXHSmVoa1eKh1EP7HhciaCQVgm3qp94dPOo4Q/]
2017/10/13 21:48:55 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:55 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:55 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/1eg6vsOfJXB62algww0s1kdPQO2cZ3R3KzmdTL8dDSNC4F6807qCk7h2ClEAbeFV/]
2017/10/13 21:48:55 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:55 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:55 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:55 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:55 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|Freedom: connection ends > context canceled
2017/10/13 21:48:56 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/iclZP0U7JBU9Vicu0fJicxXHSmVoa1eKh1EP7HhciaCQVgm3qp94dPOo4Q/]
2017/10/13 21:48:56 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:56 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|Freedom: connection ends > context canceled
2017/10/13 21:48:56 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/iclZP0U7JBU9Vicu0fJicxXHSmVoa1eKh1EP7HhciaCQVgm3qp94dPOo4Q/]
2017/10/13 21:48:56 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:56 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|Freedom: connection ends > context canceled
2017/10/13 21:48:56 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/1eg6vsOfJXB62algww0s1kdPQO2cZ3R3KzmdTL8dDSNC4F6807qCk7h2ClEAbeFV/]
2017/10/13 21:48:56 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:56 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|Freedom: connection ends > context canceled
2017/10/13 21:48:56 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/iclZP0U7JBU9Vicu0fJicxXHSmVoa1eKh1EP7HhciaCQVgm3qp94dPOo4Q/]
2017/10/13 21:48:56 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:56 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/1eg6vsOfJXB62algww0s1kdPQO2cZ3R3KzmdTL8dDSNC4F6807qCk7h2ClEAbeFV/]
2017/10/13 21:48:56 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:56 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/iclZP0U7JBU9Vicu0fJicxXHSmVoa1eKh1EP7HhciaCQVgm3qp94dPOo4Q/]
2017/10/13 21:48:56 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:56 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/1eg6vsOfJXB62algww0s1kdPQO2cZ3R3KzmdTL8dDSNC4F6807qCk7h2ClEAbeFV/]
2017/10/13 21:48:56 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:56 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|Freedom: connection ends > context canceled
2017/10/13 21:48:56 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/iclZP0U7JBU9Vicu0fJicxXHSmVoa1eKh1EP7HhciaCQVgm3qp94dPOo4Q/]
2017/10/13 21:48:56 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:56 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/1eg6vsOfJXB62algww0s1kdPQO2cZ3R3KzmdTL8dDSNC4F6807qCk7h2ClEAbeFV/]
2017/10/13 21:48:56 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:56 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|Freedom: connection ends > context canceled
2017/10/13 21:48:56 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/iclZP0U7JBU9Vicu0fJicxXHSmVoa1eKh1EP7HhciaCQVgm3qp94dPOo4Q/]
2017/10/13 21:48:56 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:56 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/1eg6vsOfJXB62algww0s1kdPQO2cZ3R3KzmdTL8dDSNC4F6807qCk7h2ClEAbeFV/]
2017/10/13 21:48:56 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:56 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|Freedom: connection ends > context canceled
2017/10/13 21:48:56 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/1eg6vsOfJXB62algww0s1kdPQO2cZ3R3KzmdTL8dDSNC4F6807qCk7h2ClEAbeFV/]
2017/10/13 21:48:56 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:56 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|Freedom: connection ends > context canceled
2017/10/13 21:48:56 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/iclZP0U7JBU9Vicu0fJicxXHSmVoa1eKh1EP7HhciaCQVgm3qp94dPOo4Q/]
2017/10/13 21:48:56 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:56 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/1eg6vsOfJXB62algww0s1kdPQO2cZ3R3KzmdTL8dDSNC4F6807qCk7h2ClEAbeFV/]
2017/10/13 21:48:56 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:56 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/iclZP0U7JBU9Vicu0fJicxXHSmVoa1eKh1EP7HhciaCQVgm3qp94dPOo4Q/]
2017/10/13 21:48:56 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:56 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/1eg6vsOfJXB62algww0s1kdPQO2cZ3R3KzmdTL8dDSNC4F6807qCk7h2ClEAbeFV/]
2017/10/13 21:48:56 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:56 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/1eg6vsOfJXB62algww0s1kdPQO2cZ3R3KzmdTL8dDSNC4F6807qCk7h2ClEAbeFV/]
2017/10/13 21:48:56 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:56 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/iclZP0U7JBU9Vicu0fJicxXHSmVoa1eKh1EP7HhciaCQVgm3qp94dPOo4Q/]
2017/10/13 21:48:56 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:56 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/1eg6vsOfJXB62algww0s1kdPQO2cZ3R3KzmdTL8dDSNC4F6807qCk7h2ClEAbeFV/]
2017/10/13 21:48:56 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:56 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|Freedom: connection ends > context canceled
2017/10/13 21:48:56 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/iclZP0U7JBU9Vicu0fJicxXHSmVoa1eKh1EP7HhciaCQVgm3qp94dPOo4Q/]
2017/10/13 21:48:56 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:56 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:56 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/1eg6vsOfJXB62algww0s1kdPQO2cZ3R3KzmdTL8dDSNC4F6807qCk7h2ClEAbeFV/]
2017/10/13 21:48:57 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:57 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|Freedom: connection ends > context canceled
2017/10/13 21:48:57 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/1eg6vsOfJXB62algww0s1kdPQO2cZ3R3KzmdTL8dDSNC4F6807qCk7h2ClEAbeFV/]
2017/10/13 21:48:57 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:57 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/iclZP0U7JBU9Vicu0fJicxXHSmVoa1eKh1EP7HhciaCQVgm3qp94dPOo4Q/]
2017/10/13 21:48:57 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:57 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|Freedom: connection ends > context canceled
2017/10/13 21:48:57 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|Freedom: connection ends > context canceled
2017/10/13 21:48:57 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/iclZP0U7JBU9Vicu0fJicxXHSmVoa1eKh1EP7HhciaCQVgm3qp94dPOo4Q/]
2017/10/13 21:48:57 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:57 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/1eg6vsOfJXB62algww0s1kdPQO2cZ3R3KzmdTL8dDSNC4F6807qCk7h2ClEAbeFV/]
2017/10/13 21:48:57 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:57 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|Freedom: connection ends > context canceled
2017/10/13 21:48:57 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/iclZP0U7JBU9Vicu0fJicxXHSmVoa1eKh1EP7HhciaCQVgm3qp94dPOo4Q/]
2017/10/13 21:48:57 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:57 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/1eg6vsOfJXB62algww0s1kdPQO2cZ3R3KzmdTL8dDSNC4F6807qCk7h2ClEAbeFV/]
2017/10/13 21:48:57 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:57 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|Freedom: connection ends > context canceled
2017/10/13 21:48:57 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/iclZP0U7JBU9Vicu0fJicxXHSmVoa1eKh1EP7HhciaCQVgm3qp94dPOo4Q/]
2017/10/13 21:48:57 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:57 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/1eg6vsOfJXB62algww0s1kdPQO2cZ3R3KzmdTL8dDSNC4F6807qCk7h2ClEAbeFV/]
2017/10/13 21:48:57 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:57 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]App|Proxyman|Outbound: failed to process outbound traffic > Proxy|Freedom: connection ends > context canceled
2017/10/13 21:48:57 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/iclZP0U7JBU9Vicu0fJicxXHSmVoa1eKh1EP7HhciaCQVgm3qp94dPOo4Q/]
2017/10/13 21:48:57 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:57 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/1eg6vsOfJXB62algww0s1kdPQO2cZ3R3KzmdTL8dDSNC4F6807qCk7h2ClEAbeFV/]
2017/10/13 21:48:57 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:57 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/iclZP0U7JBU9Vicu0fJicxXHSmVoa1eKh1EP7HhciaCQVgm3qp94dPOo4Q/]
2017/10/13 21:48:57 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:57 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]Proxy|HTTP: request to Method [GET] Host [<IP_ADDRESS>] with URL [http://<IP_ADDRESS>/wx_emoji/1eg6vsOfJXB62algww0s1kdPQO2cZ3R3KzmdTL8dDSNC4F6807qCk7h2ClEAbeFV/]
2017/10/13 21:48:57 [Info]App|Dispatcher|Default: taking detour [direct] for [tcp:<IP_ADDRESS>:80]
2017/10/13 21:48:57 [Info]Proxy|Freedom: opening connection to tcp:<IP_ADDRESS>:80
2017/10/13 21:48:57 [Info]Transport|Internet|TCP: dailing TCP to tcp:<IP_ADDRESS>:80

我也遇到了同样的问题。我试着抓了个包，不知道是不是因为v2ray修改了表情请求的http头部中的什么东西导致的？
我用tcpdump在安装了v2ray的作为中转的树莓派端抓包，用wireshark翻译得到如下内容
微信请求某个表情的时候：
GET http://<IP_ADDRESS>/wx_emoji/OWlNJY6TmjpMibr4lFdSRHPDibEq1StKI4icTtWPJZ4W89poBggoVdspQ/ HTTP/1.1\r\n
Request Method: GET
Request URI: http://<IP_ADDRESS>/wx_emoji/OWlNJY6TmjpMibr4lFdSRHPDibEq1StKI4icTtWPJZ4W89poBggoVdspQ/
Request Version: HTTP/1.1
Host: emoji.qpic.cn\r\n
X-Online-Host: emoji.qpic.cn\r\n
referer: http://weixin.qq.com/?version=637866038&uin=【这个字段好像是个隐私信息】&nettype=1&signal=40\r\n
User-Agent: Dalvik/2.1.0 (Linux; U; Android 7.0; MI 5s Plus MIUI/7.11.2)\r\n
Connection: Keep-Alive\r\n
Accept-Encoding: gzip\r\n
\r\n
Full request URI: http://<IP_ADDRESS>/wx_emoji/OWlNJY6TmjpMibr4lFdSRHPDibEq1StKI4icTtWPJZ4W89poBggoVdspQ/
得到的答复是一个404。
以下是在移动数据网络环境下不使用代理抓包翻译后的结果：
微信请求同上面一样的表情：
GET /wx_emoji/OWlNJY6TmjpMibr4lFdSRHPDibEq1StKI4icTtWPJZ4W89poBggoVdspQ/ HTTP/1.1\r\n
Request Method: GET
Request URI: /wx_emoji/OWlNJY6TmjpMibr4lFdSRHPDibEq1StKI4icTtWPJZ4W89poBggoVdspQ/
Request Version: HTTP/1.1
Host: emoji.qpic.cn\r\n
X-Online-Host: emoji.qpic.cn\r\n
referer: http://weixin.qq.com/?version=637866038&uin=【这个字段好像是个隐私信息】&nettype=13000&signal=85\r\n
User-Agent: Dalvik/2.1.0 (Linux; U; Android 7.0; MI 5s Plus MIUI/7.11.2)\r\n
Connection: Keep-Alive\r\n
Accept-Encoding: gzip\r\n
\r\n
Full request URI: http://emoji.qpic.cn/wx_emoji/OWlNJY6TmjpMibr4lFdSRHPDibEq1StKI4icTtWPJZ4W89poBggoVdspQ/
得到的答复是请求的那个表情（jpg图像）。

前几天在微信中发现一些奇怪的行为，已经进行了修复，使用 2.51 (包括手机端) 试一下。

使用 2.51 测试后还是不行，显示”轻触重试”。

试一下 http 代理的 allowTransparent.

在 HTTP 代理开启 allowTransparent 后依然不行~

同上，安卓APN代理设置为v2ray的http，开启allowTransparent后，微信表情仍然“轻触重试”。


Inconsistent types in kore_x family of functions

This is fairly minor, but I wanted to share it.
In kore/prelude.py, we have:

kore_{set|list|map} take Python native types (containing Kore wrappers) and return Kore wrappers.

In kore/match.py, we have:

kore_{int|bool|str|bytes} take Kore wrappers and return Python native types, with the inverse provided by the function dv.

Ideally:

one family of functions goes from Python native types to wrapped Kore types;
one family of functions goes from wrapped Kore types to Python native types.

I agree, this asymmetry is indeed confusing. Let's fix it.
So these are the current names:

prelude.py
match.py

Bool
bool_dv(bool) -> DV
kore_bool(P) -> bool

Int
int_dv(int) -> DV
kore_int(P) -> int

String
string_dv(str) -> DV
kore_str(P) -> str

Bytes
bytes_dv(bytes) -> DV
kore_bytes(P) -> bytes

List
kore_list(*P) -> P
match_list(P) -> tuple[P, ...]

Set
kore_set(*P) -> P
match_set(P) -> tuple[P, ...]

Map
kore_map(*tuple[P, P]) -> P
match_map(P) -> tuple[tuple[P, P], ...]

There are also higher-order functions

K Sort
match.py

List
kore_list_of(P -> T) -> (P -> tuple[T, ...])

Set
kore_set_of(P -> T) -> (P -> tuple[T, ...])

Map
kore_map_of(P -> K, P -> V) -> tuple[tuple[K, V], ...]

I guess the reason for kore_int (instead of the more symmetric match_int) is to play well with these combinators:
kore_list_of(kore_int)(pattern)  # extracts list[int]

Notation:

P abbreviates Pattern
T is a type variable
*P denotes *args: P
X -> Y denotes Callable[[X], Y]

string_dv should be renamed to str_dv. It's shorter, and then it could also be read as "str to DV". This also works with the match.py counterpart: kore_str is "KORE (Pattern) to str".
Along these same lines, how about we rename kore_list to list_pattern? It's a bit longer unfortunately, but it resolves the asymmetry issue, while still enables the easy-to-read kore_list_of(kore_int)?
Like this:

prelude.py
match.py

String
str_dv(str) -> DV
kore_str(P) -> str

List
list_pattern(*P) -> P
match_list(P) -> tuple[P, ...]

@sskeirik, what do you think?

I think the suggestion sounds good. I think a similar renaming of kore_set and kore_map to set_pattern and map_pattern for consistency would also be good.

a similar renaming of kore_set and kore_map to set_pattern and map_pattern for consistency would also be good

Definitely.


Type error in SSELink Apollo example

Screenshot
I use code from the example here

Expected Behaviour
The example should work without type errors.
Actual Behaviour
Instead I get the error as shown above.
Further Information
This started showing up when i updated all patch versions of my packages. Likely some typescript instrumentation just caught it, because downgrading back the apollo and graphql packages did not help.

Out of curiosity, I've checked the dependency update one by one. This is caused by updating @apollo/client 3.10.4 -> 3.11.8

Any solutions here?

I just downgraded.

You can always cast to any.

I assume it will be fixed eventually, if not I'll probably do that.

Instead of importing FetchResult from @apollo/client, import ExecutionResult from graphql.
import { ApolloLink, Operation, Observable } from "@apollo/client/core";
import { ExecutionResult, print } from "graphql";
import { createClient, ClientOptions, Client } from "graphql-sse";

export class SSELink extends ApolloLink {
  private client: Client;

  constructor(options: ClientOptions) {
    super();
    this.client = createClient(options);
  }

  public request(operation: Operation): Observable<ExecutionResult> {
    return new Observable((sink) => {
      return this.client.subscribe<ExecutionResult>(
        { ...operation, query: print(operation.query) },
        {
          next: sink.next.bind(sink),
          complete: sink.complete.bind(sink),
          error: sink.error.bind(sink),
        },
      );
    });
  }
}

I confirm, that @RMHonor suggestion sovles the problem.
:tada:

Even though https://github.com/enisdenjo/graphql-sse/issues/108#issuecomment-2498644581 is a fix, I consider this a bug because there's no reason the FetchResult should not work. I think the issue is caused by the lack/improper usage of the patch message in graphql-sse.

I've just been looking at switching from graphql-ws to graphql-sse and came across this line in the GraphQLWsLink code.
https://github.com/apollographql/apollo-client/blob/77b89318040748b3ffad97938eccacd8b1fbb4bd/src/link/subscriptions/index.ts#L85
@enisdenjo Thanks for the library, are there any plans to add a link based on your recipe to the apollo codebase? I don't know if that was yourself or the apollo guys who originally contributed it.

@mbiggs-gresham a new major release is cooking, and fixing this issue is certainly on the list (along many other important fixes)! Please bear with me, I am quite busy at the moment but it shouldn't be too long.


Npm package outdated

Seems that the npm package is still 1.0.3 and there has been quite a few changes since then. Could you publish the 2.0.0 version?
Thanks

Hi Markus,
The 2.0.0 version in master is pretty different than v1.0, and not exactly in a releasable state yet. We've introduced a number of breaking API changes, and want to reserve the right to continue to do that before the release. We're being particular careful with this as the intention is to not make any breaking API changes once released.
If you'd like to use v2.0.0 you can easily change your dependencies in your package.json to point to:
   "amqp10": "noodlefrenzy/node-amqp10#master"

Hi Matt,
Thanks for the quick reply.
Then I know the reasoning behind it. Would you consider 2.0 to be ready for production or should I use v1 for now?
Kind regards,
Markus

@markusahlstrand well that point is up for debate :smile: I'm currently using it in production, but I'm also able to iterate quickly dependent on bug fixes. So I'm sort of beta-testing the 2.0.0 release currently, and we would absolutely love more people to do this if they are willing. I can say that it's been quite reliable for me so far.

Ok, then I'll continue to use the 2.0 version.
Thanks


gitleaks: 8.16.4 -> 8.17.0

Diff: https://github.com/zricethezav/gitleaks/compare/v8.16.4...v8.17.0
Changelog: https://github.com/zricethezav/gitleaks/releases/tag/v8.17.0
Description of changes

Things done

Built on platform(s)

[ ] 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/)
23.11 Release Notes (or backporting 23.05 Release notes)

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

[ ] Fits CONTRIBUTING.md.

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

1 package built:

gitleaks


add warning for soon to be depricated plugin structure

this will be a warning marking the deprecated plugin structure for one release
still need to add link to the blog post explaining how will the plugins be migrated

related: https://github.com/NativeScript/android-runtime/issues/369


feat: list metadata/-types stdout is table

What does this PR do?
moves regular output into a table for
list metadata
list metadata-types
What issues does this PR fix or reference?
@W-6015646@

QA:
org list metadata-types -o hub
✅ works, columns look fine
🎨  I think these should be sorted by Xml Names.  I'd also maybe alphabetize the childXmlNames (nit)
./bin/run.js org list metadata -o hub -m CustomObject
✅ works
❌  type column is lowercased.  I'm not sure it should be there at all (is there a case where it wouldn't just be the type you just asked for?)
💡 I only see Id and Namespace Prefix when there's a Manageable State.  I wonder if there should be 2 or 3 tables, grouped by Manageable state, so that the table without manageable state doesn't need those fields?
🎨 I think a reasonable sort order for these would be state, prefix (unless you decide to do separate tables), full name.
🎨 I'm not a fan of the 1970-01-01.  I think I'd rather those be empty than "obviously wrong date."  And they really weren't Created or Modified on that date by somebody, either.  They were just Standard Objects that predate the org?


Can't get signoutPopup to work

I'm using v1.2.2 (and I've also tried with 1.3.0-beta.3).
signinPopup({..}) works great.
However, when I try and run signoutPopup() the promise is never resolved. I believe this is due to #254 ?
Brief review of the code sees signoutPopup uses a similar mechanism to signinPopup yet the latter doesn't have a unique return url, nor an associated callback.

https://github.com/IdentityModel/oidc-client-js/blob/dev/sample/public/user-manager-sample-popup.html#L14

Ah, sorry -- signout (I originally misread it as signin). I'll look into the other issue when I can.

No probs! I tried to add a similar callback for signout, but couldn't get it to work. It's never that simple 😛!
BTW, 1.3.0-beta3, everything is defined in the global(?) namespace instead of under Oidc.

1.3.0-beta3, everything is defined in the global(?) namespace instead of under Oidc., not sure if this is by design?

Hmm, well, depends how you pull in the library. But the ~/dist version is still supposed to be under Oidc.

Ah yes, rightly so, my mistake!

I came across the same problem. The user unloaded normally but the popup windows didn't dismiss after calling signoutRedirectCallback(). In the meantime, I can only add a catch method after calling Usermanager.signoutPopup(), and window.close() the callback window after calling signoutRedirectCallback(),

Ok, I'll see if I can spend some time to track this down.

Relevant: https://github.com/IdentityModel/oidc-client-js/issues/254#issuecomment-290279814

This is a dup of #254 so I'll close this one. Thanks for bring this to my attention!


[BUG] - Page unexpectedly reloading when I use react-router for client-side routing and href attribute on Tabs and Dropdown components

NextUI Version
2.2.9
Describe the bug
I am using the Dropdown and Tabs components for routing in my application. I employ react-router for client-side routing, and I have set it up according to the instructions on the page https://nextui.org/docs/guide/routing.
When I pass the href attribute to the Link or Listbox components, routing works as expected. However, if the href attribute is passed to the Dropdown or Tabs components, it causes an unexpected page reload every time a Tab or DropdownItem is clicked.
You can see the issue in detail in the attached video. The code from the application in the video is provided below.
main.tsx
import React from 'react'
import ReactDOM from 'react-dom/client'
import './index.scss'
import AppTest from './AppTest.tsx'
import {BrowserRouter} from "react-router-dom";

ReactDOM.createRoot(document.getElementById('root')!).render(
    <React.StrictMode>
        <BrowserRouter>
            <AppTest />
        </BrowserRouter>
    </React.StrictMode>,
)

AppTest.tsx
import {Route, Routes, useLocation, useNavigate} from 'react-router-dom';
import {
    NextUIProvider,
    Avatar, Link,
    Card, CardBody, CardHeader,
    Dropdown, DropdownItem, DropdownMenu, DropdownTrigger,
    Listbox, ListboxItem,
    Tab, Tabs
} from '@nextui-org/react';

const AppTest = () => {

    const navigate = useNavigate();
    const {pathname} = useLocation();

    return (
        <NextUIProvider navigate={navigate}>

                    <Tabs selectedKey={pathname}>
                        <Tab href="/" key="/" title="main" />
                        <Tab href="/user" key="/user" title="user" />
                    </Tabs>

                    <Dropdown>
                        <DropdownTrigger><Avatar /></DropdownTrigger>
                        <DropdownMenu>
                            <DropdownItem href="/">Main</DropdownItem>
                            <DropdownItem href="/user">User</DropdownItem>
                        </DropdownMenu>
                    </Dropdown>

                <Routes>

                    <Route path="/" element={<Home />} />

                    <Route path="/user" element={<User />} />

                </Routes>

                <Card className="mb-6">
                    <CardHeader className="text-sm text-success">
                        {'<Listbox>'} routing works fine without page reloading
                    </CardHeader>
                    <CardBody>
                        <Listbox>
                            <ListboxItem href="/" key="home">main</ListboxItem>
                            <ListboxItem href="/user" key="user">user</ListboxItem>
                        </Listbox>
                    </CardBody>
                </Card>

                <Card>
                    <CardHeader className="text-sm text-success">
                        {'<Link>'} routing works fine without page reloading
                    </CardHeader>
                    <CardBody>
                        <Link href="/">{'<Link href="/">'}</Link>
                        <Link href="/user">{'<Link href="/user">'}</Link>
                    </CardBody>
                </Card>

        </NextUIProvider>
    );

}

const Home = () => {
    return <Card className="mb-6">
        <CardBody className="text-center font-bold">
            Some contents here
        </CardBody>
    </Card>
}

const User = () => {
    return <Card className="mb-6">
        <CardBody className="text-center font-bold">
            Some user related contents here
        </CardBody>
    </Card>
}

export default AppTest

Your Example Website or App
No response
Steps to Reproduce the Bug or Issue

Set up client-side routing according to the instructions at https://nextui.org/docs/guide/routing.
Utilize the Dropdown or Tabs components.
Specify the href attribute in the Tab or DropdownItem components.

Expected behavior
Expected Behavior:
Navigating between different routes without reloading the application.
Actual Result:
Page reloads when using the href attribute in DropdownItem and Tab.
Screenshots or Videos
https://github.com/nextui-org/nextui/assets/20705877/a6b2f9c8-114c-48d4-824d-add697c50777
Operating System Version
MacOS
Browser
Chrome

Just ran into this and initially used onSelectionChange to manually push the router page, but while playing with other components specifically Button, found out that all you need is as={Link} on the <Tab component to make it work.

Fixed in https://github.com/nextui-org/nextui/pull/3240


Change ignore file format to json

[x] I have read the contributing guidelines and I agree with the Code of Conduct
[x] Have you checked that there aren't other open pull requests for the same changes?
[x] Have you tested that the committed code can be executed without errors?

The existing implementation can't handle package-ids with commas. This changes the format of the ignore config files to a simple json format.
Since this is a one time change I didn't add a conversion for existing ignore files.

Closes #1487

Relates to #XXXX

We do need a conversion for the old blacklisted packages. I will implement it.


Pylance

 Environment data

Language Server version: 2022.8.30
OS and version: win32 ia32
Python version (and distribution if applicable, e.g. Anaconda):
python.analysis.indexing: null
python.analysis.typeCheckingMode: off

 Code Snippet

XXX

 Repro Steps

XXX

 Expected behavior
XXX
 Actual behavior
XXX
 Logs

XXX

Thanks for the report, unfortunately, this is not enough data for us to investigate this issue.
If this continues to be a problem, would you please reopen the issue and add the information described in the troubleshooting guide?


Explicit expression wrapping in AST

Aims to fix following:

#1225

Adds the DMASTExpressionWrapping which has no visitor, instead it reroutes the visitor directly to the wrapped expression's own visitor instead. If this is undesirable, do let me know. This change does decommission DMASTIdentifierWrapped as it is functionally the same but with its own visitor.

[x] Fix #1225

Alright. After some more debugging, I was too quick to when I made the conclusion that #1267 was related to wrapping, when it was not.