Ignore more native source files

Atom maintains a bunch of regexes of things to ignore when bundling the app to prevent bloat.
This pull request adds ignore patterns for the latest native modules added to the build; nodegit, marker-index, and cached-run-in-this-context.
This shrinks the app.asar overall size from ~151M to ~105M and the number of files in the bundle from ~18.5K to ~14.1K.  The bulk of the savings was from nodegit which was bundling all of the openssl, libssh, and libgit2 native source code.
@iolsen and I were pairing today and we noticed this when running the script/grunt output-build-filetypes to display what types of files were bundled in the app.
/cc @joshaber @thedaniel :eyes:

So they'll still be included in the app, but not in the asar? Or am I misunderstanding?

So they'll still be included in the app, but not in the asar? Or am I misunderstanding?

Previously all the .c, .cc, and .h files included in nodegit were ending up in Atom.app. This pull request removes them so only the required files like .js and .a files will be included.

Also node-pre-gyp was previously being included as well via nodegit and it looks like it is only needed at install time, not at runtime.

:cool: :+1:


[Bug] Loss=-1.0 and GPU memory keeps increasing in pipeline parallel

[experimental]
pipeline_parallel_degree = 2
pipeline_parallel_microbatches = 2
pipeline_parallel_split_points = ["layers.16"]

cc: @H-Huang  @wconstab
I am guessing we should run more steps to see if the memory keeps increasing or not. For the loss issue, I think only loss is reported on the last stage? We should reconcile that with which rank(s) get logged to console.

cc: @H-Huang  @wconstab
I am guessing we should run more steps to see if the memory keeps increasing or not. For the loss issue, I think only loss is reported on the last stage? We should reconcile that with which rank(s) get logged to console.

Many thanks! I will check the losses for my last stage ranks logs. And for memory increasing issue, let me run more steps to check whether it exists memory leakage possibility.

Hi @leeeizhang,
Re: -1 for loss - when using Pipeline Parallel, only the last stage computes an actual loss.  Thus, you will need to adjust your logging filter to include the final rank.
i.e. (N-1) rank where N = total gpus.  Thus for an 8 gpu node, the loss will be reported only on rank 7.
The other ranks will only show the default no loss of -1.

Re: memory keeps increasing:
Based on the screenshot, it only shows two iterations displayed, iter 1 and iter 10.
Normally, memory will always increase from iter 1 to iter 2, and stabilize from there.
In this case you only show 2 iters where there is an expected increase between first and second iter.
If you keep logging at every 10 iters, I suspect step 20, 30, etc. will be very close to step 10...i.e. it's not truly increasing beyond the expected jump from 1st to 2nd iter.

the recommended methods work for me! many thanks!


Unable to resolve "use-subscription" from "node_modules\native-base\src\core\color-mode\hooks.tsx"

Description
Unable to resolve "use-subscription" from "node_modules\native-base\src\core\color-mode\hooks.tsx"
CodeSandbox/Snack link
Just go from version 3.4.13 to 3.4.14
Steps to reproduce
Just go from version 3.4.13 to 3.4.14
NativeBase Version
3.4.14
Platform

[X] Android
[ ] CRA
[X] Expo
[ ] iOS
[ ] Next

Other Platform
No response
Additional Information
Already described above

Hi @goxr3plus, Please delete and re-install node_modules. We have added some new dependencies.

Hi @goxr3plus, Please delete and re-install node_modules. We have added some new dependencies.

Getting the same error even after a clean install

Yes getting the same issue with the react-native 0.70 project and react-native-reanimated 3.0.0-rc.2

@Viraj-10  in which version can you please mention here? as I'm using this with react-native 0.70 and native-base 3.4.14

@NensiKasundra , It's fixed in 3.4.15.


manga image does not appear

Potential workaround

Download the chapter (also with "split tall images" option enabled just to be sure)

Steps to reproduce

I enter the manga I want to see
I select the chapter
I swipe to read
The next image of the manga does not appear or is glitched

Expected behavior
I wait a few minutes and hope that maybe the image loads but nothing happens, I reload the chapter and it doesn't work, I was hoping that maybe this way the chapter would appear
Actual behavior
The image of the manga disappeared or while I read there are parts of the chapter where there is empty space, which is where the image does not appear
Crash logs
No response
Yōkai version
App version: <IP_ADDRESS> (standard, 8dc093858, 139, 2024-08-05T14:45:59Z)
Android version
Android 10
Device
Motorola e7 plus
Other details
https://github.com/user-attachments/assets/e9c5e59a-4fc5-4f73-80f8-fa8437528575
Video with details of the problem
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
[X] I have written a short but informative title.
[X] If this is an issue with an extension, or a request for an extension, I should be contacting the extensions repository's maintainer/support for help.
[X] I am reporting an issue exclusive to this fork. I have also checked that is not an issue on the main version of Mihon
[X] I have tried the troubleshooting guide.
[X] I have updated the app to version <IP_ADDRESS>.
[X] I have updated all installed extensions.
[X] I have filled out all of the requested information in this form.

I found the same problem as you, but when I used J2K which still had the 32 bit color off feature, the problem as you explained didn't occur, so the conclusion was "there are some devices that may not be compatible with the new 32 Bit color permanent feature" I hope Yokai returns quickly this feature.

if you can use the 32 bit color on/off button, why make it permanent?

I doubt it's that, they reported that the page load properly on Mihon (I assume 0.16.5), which also have 32-bit perma enabled.
The option to disable it completely removed from upstream's API so it can't be easily done.

I also got this bug, but it looks like

If it's too sensitive, feel free to delete this comment
It might be sources-specific problem (As in only mangas from this source that it'll have this issue on mihon and it's forks, not the source itself is the problem).
From my list, only one source got this bug. The same manga, but from different source loads image no problem. I also tried to load a manga from that problematic source on browser. It loads just fine.

Might be fixed in 03043ef01bc16545ac3f79841a2fcc0d856fa90c and 153268052aa4bd460e3843f00790b2eda91fe25a

Partial revert: a12e1c7822381121f997e072f97ee321eeac4bef
I'll port https://github.com/mihonapp/mihon/commit/dcddac5daaff3ec89c8507c35dc13d345ffdb6d7 later

Probably safe to say this issue is fixed now (https://github.com/null2264/yokai/commit/01fcd7d12244156ab64bd2b5122384ac303fc314, https://github.com/null2264/yokai/commit/fd73958923bda0b6a0a522cb9ebf14f235eeca93, https://github.com/null2264/yokai/commit/c66bf9b2800aa61334a754680d0145677e968129)


Cannot build for Android

I tryed to build latest MRuby for Android on Ubuntu16.
First, I moved include folder of NDK to target arc folder.
Then I build MRuby with follow command.
rake MRUBY_CONFIG=android_arm64-v8a ANDROID_NDK_HOME=/home/pc/android-ndk-r20

However, It failed.
checking for android-arm64-v8a-gcc... /home/pc/android-ndk-r20/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -MMD -MP -D__android__ -DANDROID --sysroot="/home/pc/android-ndk-r20/platforms/android-21/arch-arm64" -target aarch64-none-linux-android -gcc-toolchain "/home/pc/android-ndk-r20/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64" -Wno-invalid-command-line-argument -Wno-unused-command-line-argument -fpic -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -fexceptions
checking whether the C compiler works... no
configure: error: in `/home/pc/mruby/build/android-arm64-v8a/mrbgems/mruby-onig-regexp/onigmo-6.2.0':
configure: error: C compiler cannot create executables
See `config.log' for more details
**rake aborted!**
./configure --disable-shared --enable-static --host android-arm64-v8a failed
/home/pc/mruby/build/repos/android-arm64-v8a/mruby-onig-regexp/mrbgem.rake:47:in `run_command'
/home/pc/mruby/build/repos/android-arm64-v8a/mruby-onig-regexp/mrbgem.rake:69:in `block (2 levels) in bundle_onigmo'
/home/pc/mruby/build/repos/android-arm64-v8a/mruby-onig-regexp/mrbgem.rake:56:in `chdir'
/home/pc/mruby/build/repos/android-arm64-v8a/mruby-onig-regexp/mrbgem.rake:56:in `block in bundle_onigmo'
Tasks: TOP => default => all => build => gensym => /home/pc/mruby/build/presym => /home/pc/mruby/build/repos/android-arm64-v8a/mruby-onig-regexp/src/mruby_onig_regexp.c => /home/pc/mruby/build/android-arm64-v8a/mrbgems/mruby-onig-regexp/onigmo-6.2.0/.libs/libonigmo.a
(See full trace by running task with --trace)

I Installed gcc and clang but still build failed.
How can I build collect?

I think it was caused by mruby-onig-regexp which does not support cross-compiling due to autoconf. There must be a way to use autoconf in the cross-compiling environment. File an issue to mruby-onig-regexp.
If there's anything we (mruby core) can do, reopen this issue.


Fix the scroll api call

I am doing a migration from elasticsearch v2.3.3 to another elasticsearch v2.3.3 instance, and I stuck upon the problem 'scrollId is missing'. Here are a bit more details:

[debug] | scrollRequest: {"uri":"http://src.mysite.com/_search/scroll?scroll=10m\",\"method\":\"POST\",\"body\":\"cXVlcnlUaGVuRmV0Y2g7NTsxNTA4NTk5OklUYmJ0LXFTUjgtQzhKcFhYdm9wRkE7MTUwODYwMTpJVGJidC1xU1I4LUM4SnBYWHZvcEZBOzE1MDg2MDA6SVRiYnQtcVNSOC1DOEpwWFh2b3BGQTsxNTA4NjAzOklUYmJ0LXFTUjgtQzhKcFhYdm9wRkE7MTUwODYwMjpJVGJidC1xU1I4LUM4SnBYWHZvcEZBOzA7\"}", "Sun, 26 Jun 2016 03:35:03 GMT [debug] | body: "{\"error\":{\"root_cause\":[{\"type\":\"action_request_validation_exception\",\"reason\":\"Validation Failed: 1: scrollId is missing;\"}],\"type\":\"action_request_validation_exception\",\"reason\":\"Validation Failed: 1: scrollId is missing;\"}

After I checked the elasticsearch doc,  seems like the backward compatibility is not preserved. So I made a little adjustment and it worked well.

Thanks for this, but this change breaks compatibility with Elasticsearch v1.x.x

closing due to lack of interest from original poster


.withRule chaining seems to only check last rule in Bun

Issue:
When I chain .withRule(fixedWindow()).withRule(detectBot()), only the detectBot results returned. Seems like each call to withRule() replaces all previous withRule()s.
Expected behaviour:
Each call to withRule() should append to the list of rules to be applied.
Steps to reproduce:
Run the following code with bun run .... It will check shield for being in the main config, and detectBot for being the last chained rule.
import arcjet, { detectBot, fixedWindow, shield } from "@arcjet/bun";

const aj = arcjet({
  key: Bun.env.ARCJET_KEY!,
  rules: [
    shield({
      mode: "LIVE",
    })
]});

function getClient(userId?: string) {
  if (userId) {
    return aj;
  } else {
    return aj
      .withRule(detectBot({ mode: "LIVE", block: ["AUTOMATED"] }))
      .withRule(fixedWindow({ mode: "LIVE", max: 10, window: "1m" }));
  }
}

export default {
  port: 3000,
  fetch: aj.handler(async (req) => {
    const userId = undefined;
    const decision = await getClient(userId).protect(req);

    for (const result of decision.results) {
      console.log("Rule Result", result);

      if (result.reason.isRateLimit()) {
        console.log("Rate limit rule", result);
      }

      if (result.reason.isBot()) {
        console.log("Bot protection rule", result);
      }
    }

    return new Response("Hello world");
  }),
};

Returns:
Rule Result ArcjetRuleResult {
  state: "RUN",
  conclusion: "ALLOW",
  reason: ArcjetShieldReason {
    type: "SHIELD",
    shieldTriggered: false,
  },
}
Rule Result ArcjetRuleResult {
  state: "RUN",
  conclusion: "ALLOW",
  reason: ArcjetBotReason {
    type: "BOT",
    botType: "LIKELY_NOT_A_BOT",
    botScore: 0,
    userAgentMatch: false,
    ipHosting: false,
    ipVpn: false,
    ipProxy: false,
    ipTor: false,
    ipRelay: false,
  },
}
Bot protection rule ArcjetRuleResult {
  state: "RUN",
  conclusion: "ALLOW",
  reason: ArcjetBotReason {
    type: "BOT",
    botType: "LIKELY_NOT_A_BOT",
    botScore: 0,
    userAgentMatch: false,
    ipHosting: false,
    ipVpn: false,
    ipProxy: false,
    ipTor: false,
    ipRelay: false,
  },
}

(Some attributes removed for readability)
If I switch the .withRule calls around (detectBot first, then fixedWindow), I get the following:
Rule Result ArcjetRuleResult {
  state: "RUN",
  conclusion: "ALLOW",
  reason: ArcjetShieldReason {
    type: "SHIELD",
    shieldTriggered: false,
  },
}
Rule Result ArcjetRuleResult {
  state: "RUN",
  conclusion: "ALLOW",
  reason: ArcjetRateLimitReason {
    type: "RATE_LIMIT",
    max: 10,
    remaining: 8,
    reset: 59,
    window: 60,
    resetTime: 2024-06-13T23:13:18.000Z,
  },
}
Rate limit rule ArcjetRuleResult {
  ruleId: "",
  ttl: 0,
  state: "RUN",
  conclusion: "ALLOW",
  reason: ArcjetRateLimitReason {
    type: "RATE_LIMIT",
    max: 10,
    remaining: 8,
    reset: 59,
    window: 60,
    resetTime: 2024-06-13T23:13:18.000Z,
  },
}

(Some attributes removed for readability)
To verify it's the last .withRule() I added a third, and only got shield and the third rule.

This is a bug with every instance of withRule (not just Bun). Instead of applying the last chain of rules, I am combining the root rules and the new rule.


upgrading from older version creates error:

I have updated json_theme from version 6.3.1 to version 6.4.0
then, when building my apk, running: flutter build apk I'm getting this error
  - file:///C:/Users/<myUser>/AppData/Local/Pub/Cache/hosted/pub.dev/json_theme-6.4.0/lib/src/codec/theme_decoder.dart:5473:16
Target aot_android_asset_bundle failed: Exception: Avoid non-constant invocations of IconData or try to build again with --no-tree-shake-icons.

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:compileFlutterBuildRelease'.
> Process 'command 'C:\Users\<myUser>\Documents\flutter\bin\flutter.bat'' finished with non-zero exit value 1

The issue isn't here, it's that you need to pass in the --no-tree-shake-icons per the README.

Important Note
Because this library allows for icons to be dynamically referenced, Flutter cannot tree shake icons because it has no way of knowing what icons may or may not be referenced. If you include this library, then you will need to add the --no-tree-shake-icons flag to your Flutter build or you will get an error stating that Flutter cannot tree shake the icons.


Compatibility with smartgit.

When I try pull in smartgit(I think that smagit try delete that y create new one archive when it have changes) and i have atom opened with this archive without saved, atom doesn´t allow permise that.
(permise denied)

I'm not familiar with smartgit. Can you provide a link?
Also, can you provide more detailed repro steps including exactly what you did, what actually happened and what you expected to happen?

not problems now :) i close all tabs before sincro and no problems. i had problems when i not save a file and http://www.syntevo.com/smartgit/ try modify this file. thanks :)


Allow to import/export circuits

Is your feature request related to a problem? Please describe.
To use the tool in a serious context, we can't just trust that the website & sponsor will be there forever. In order to consider the tool, we need to be able to export the work.

Trust
Outages
Discontinuation of the project / sponsors
Moving the circuit between local instance for dev and live one.
Work around limitations of the tools by exporting / editing / re-importing. (i.e. preprogramming eeprom)

Describe the solution you'd like
A button in the menu to export the circuit in any format (text format like json / yaml would be nice, but could be anything) as well as a button to import.
Describe alternatives you've considered
The alternative is to use Logisim, but it is not ideal.
Are you working on this? (Yes/No)
No.

+1 on this.
In the meantime, a workaround for this is to select and copy the circuit.
This puts the corresponding JSON data in the clipboard, which one can then save anywhere.
Then one can paste that data back into CircuitVerse to regenerate the circuit.

I didn't realize we could copy/paste outside as JSON :). That do the trick for now, but a "full blown" import/export would still be nice.
In the same topic, having some kind of version control would be great. Maybe even a sync with github with the raw json file in a repo.

I would like to work on this issue.


[BACKPORT][v1.3.x][BUG] The default access mode of a restored RWX volume is RWO

Describe the bug
backport https://github.com/longhorn/longhorn/issues/3444

Verified on v1.3.x-head 20220915

longhorn v1.3.x-head (cefb545)
longhorn-manager v1.3.x-head (9a5807f)

The test steps
Scenario 1

Create two volumes: ReadWriteOnce (RWO) * 1 + ReadWriteMany (RWX)
kubectl apply -f create_2vol_rwx+rwo.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: vol-0
  namespace: default
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: longhorn
  resources:
    requests:
      storage: 0.5Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: vol-1
  namespace: default
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn
  resources:
    requests:
      storage: 0.5Gi

Volume attach to the pod. Deploy pod mypod1
kubectl apply -f pod_mount_2vol.yaml

kind: Pod
apiVersion: v1
metadata:
  name: mypod1
  namespace: default
spec:
  containers:
    - name: testfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/data0/"
        name: vol-0
      - mountPath: "/data1/"
        name: vol-1
  volumes:
    - name: vol-0
      persistentVolumeClaim:
        claimName: vol-0
    - name: vol-1
      persistentVolumeClaim:
        claimName: vol-1

Create backups for each volumes
Wait all backups are complete, then delete all volumes.
Switch to Backup page, and click the backup name and the tags filed.
Select all backups and click Restore Latest Backup button without changing any parameters during the restore
Switch back to Volume page and click the name filed.
CHECK: The access mode should be same as the volume's backup.

Scenario 2

Create two volumes: ReadWriteOnce (RWO) * 1 + ReadWriteMany (RWX)
kubectl apply -f create_2vol_rwx+rwo.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: vol-0
  namespace: default
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: longhorn
  resources:
    requests:
      storage: 0.5Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: vol-1
  namespace: default
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn
  resources:
    requests:
      storage: 0.5Gi

Volume attach to the pod. Deploy pod mypod1
kubectl apply -f pod_mount_2vol.yaml

kind: Pod
apiVersion: v1
metadata:
  name: mypod1
  namespace: default
spec:
  containers:
    - name: testfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/data0/"
        name: vol-0
      - mountPath: "/data1/"
        name: vol-1
  volumes:
    - name: vol-0
      persistentVolumeClaim:
        claimName: vol-0
    - name: vol-1
      persistentVolumeClaim:
        claimName: vol-1

Wait all backups are complete, then delete all volumes.
Switch to Backup page, and click the backup name and the tags filed.
5.1 Select ReadWriteOnce backup volumes and set the access mode as ReadWriteMany
5.2 Select ReadWriteMany backup volumes and set the access mode as ReadWriteOnce
Switch back to Volume page and click the name filed.
7.1 The ReadWriteOnce backup volumes access mode should be ReadWriteMany volume
7.2 The ReadWriteMany backup volumes access mode should be ReadWriteOnce volume

Result Passed


KCOV: suppress parasitic coverage

Some common kernel helper functions, especially the ones with loop, or called inside of loops, can produce lots of uninteresting coverage that overflows KCOV buffer. We already don't instrument some of such helpers, but we need to support more.
These can be found by running programs with beefy coverage (esp the ones that overflow KCOV buffer) with syz-execprog -coverfile, and then passing the resulting traces via addr2line.
Some helpers that I found:

is_bpf_text_address called during stack unwinding
arch_static_branch is called a lot from somewhere
string_nocheck has a loop
common containers (lib/xarray.c, lib/maple_tree.c) (are they interesting for us?)

Add discussion link here https://groups.google.com/g/syzkaller/c/rSPSMttoNWw
and print pc count PR https://github.com/google/syzkaller/pull/5617 since syz-execprog, then addr2line takes much time.


bazel: fix //quality:rustfmt_fix

There is no bindgen module rom_error any more (or maybe not yet?), in either case this patch is needed to make sure that 'basel run //quality:rustfmt_fix' can actually execute.

Looks like this module is used afterall ... @vbendeb

@timothytrippel  can you run basel run //quality:rustfmt_fix in es100? It is failing for me...


Error: bad argument #1 to 'ipairs' (table expected, got nil)

version:
kong-0.10.2
openresty-<IP_ADDRESS>
Kong-0.10.1 upgrade to kong-0.10.2, the following error:
Error: bad argument #1 to 'ipairs' (table expected, got nil)
Run with --v (verbose) or --vv (debug) for more details
[root@localhost openresty]# kong start --vv
2017/05/03 20:00:57 [verbose] Kong: 0.10.2
2017/05/03 20:00:57 [debug] ngx_lua: 10007
2017/05/03 20:00:57 [debug] nginx: 1011002
2017/05/03 20:00:57 [debug] Lua: LuaJIT 2.1.0-beta2
2017/05/03 20:00:57 [verbose] no config file found at /etc/kong/kong.conf
2017/05/03 20:00:57 [verbose] no config file found at /etc/kong.conf
2017/05/03 20:00:57 [verbose] no config file, skipping loading
Error:
...uite/openresty/luajit/share/lua/5.1/kong/conf_loader.lua:189: bad argument #1 to 'ipairs' (table expected, got nil)
stack traceback:
[C]: in function 'ipairs'
...uite/openresty/luajit/share/lua/5.1/kong/conf_loader.lua:189: in function 'check_and_infer'
...uite/openresty/luajit/share/lua/5.1/kong/conf_loader.lua:359: in function 'conf_loader'
...bsuite/openresty/luajit/share/lua/5.1/kong/cmd/start.lua:10: in function 'cmd_exec'
...ebsuite/openresty/luajit/share/lua/5.1/kong/cmd/init.lua:88: in function <...ebsuite/openresty/luajit/share/lua/5.1/kong/cmd/init.lua:88>
[C]: in function 'xpcall'
...ebsuite/openresty/luajit/share/lua/5.1/kong/cmd/init.lua:88: in function <...ebsuite/openresty/luajit/share/lua/5.1/kong/cmd/init.lua:45>
/opt/websuite/openresty/bin/kong:5: in function 'file_gen'
init_worker_by_lua:38: in function <init_worker_by_lua:36>
[C]: in function 'pcall'
init_worker_by_lua:45: in function <init_worker_by_lua:43>

old version:
kong-0.10.1
openresty-<IP_ADDRESS>
update version:
kong-0.10.2
openresty-<IP_ADDRESS>

@xulongju what does the content of your kong.conf file look like?

[root@localhost openresty]# cat kong.conf
prefix = /opt/config/openresty/kong/
log_level = error
custom_plugins =
anonymous_reports = off
proxy_listen = <IP_ADDRESS>:80
proxy_listen_ssl = <IP_ADDRESS>:443
admin_listen = <IP_ADDRESS>:8001
admin_listen_ssl = <IP_ADDRESS>:8444
mem_cache_size = 128m
ssl = on
ssl_cert =
ssl_cert_key =
admin_ssl = off
admin_ssl_cert =
admin_ssl_cert_key =
upstream_keepalive = 60
server_tokens = on
latency_tokens = on
database = postgres
pg_host = <IP_ADDRESS>
pg_port = 5432
pg_user = kong
pg_password = kong
pg_database = kong
pg_ssl = off
pg_ssl_verify = off
cluster_listen = <IP_ADDRESS>:7946
cluster_listen_rpc = <IP_ADDRESS>:7373
cluster_advertise =
cluster_encrypt_key =
cluster_keyring_file =
cluster_ttl_on_failure = 3600
cluster_profile = wan
dns_resolver =
dns_hostsfile = /etc/hosts
lua_ssl_trusted_certificate =
lua_ssl_verify_depth = 1
lua_code_cache = on
lua_package_path =
lua_package_cpath =
lua_socket_pool_size = 30

I re-compile and install kong 0.10.2, use openresty -<IP_ADDRESS>, start any error, as follows:
[root@localhost cron.hourly]# kong start --vv
2017/05/07 09:45:17 [verbose] Kong: 0.10.2
2017/05/07 09:45:17 [debug] ngx_lua: 10006
2017/05/07 09:45:17 [debug] nginx: 1011002
2017/05/07 09:45:17 [debug] Lua: LuaJIT 2.1.0-beta2
2017/05/07 09:45:17 [verbose] reading config file at /opt/config/openresty/kong.conf
Error:
...uite/openresty/luajit/share/lua/5.1/kong/conf_loader.lua:188: bad argument #1 to 'ipairs' (table expected, got nil)
stack traceback:
[C]: in function 'ipairs'
...uite/openresty/luajit/share/lua/5.1/kong/conf_loader.lua:188: in function 'check_and_infer'
...uite/openresty/luajit/share/lua/5.1/kong/conf_loader.lua:358: in function 'conf_loader'
...bsuite/openresty/luajit/share/lua/5.1/kong/cmd/start.lua:10: in function 'cmd_exec'
...ebsuite/openresty/luajit/share/lua/5.1/kong/cmd/init.lua:88: in function <...ebsuite/openresty/luajit/share/lua/5.1/kong/cmd/init.lua:88>
[C]: in function 'xpcall'
...ebsuite/openresty/luajit/share/lua/5.1/kong/cmd/init.lua:88: in function <...ebsuite/openresty/luajit/share/lua/5.1/kong/cmd/init.lua:45>
/opt/websuite/openresty/bin/kong:5: in function 'file_gen'
init_worker_by_lua:38: in function <init_worker_by_lua:36>
[C]: in function 'pcall'
init_worker_by_lua:45: in function <init_worker_by_lua:43>

I'm receiving same issue on 0.10.2 and 0.10.1 ,
is there any patch or update on this?

@p0pr0ck5
if kong.conf or kong_default.lua include "cassandra_contact_points" ,then run "kong migrations up" is OK
if kong.conf or  kong_default.lua is not include "cassandra_contact_points" ,then run "kong migrations up" is not work ,and print
"Error:
...uite/openresty/luajit/share/lua/5.1/kong/conf_loader.lua:188: bad argument #1 to 'ipairs' (table expected, got nil)"

Hello, I'm currently running into the same issue with Kong 0.10.1. I've got Cassandra client-node encryption working (was able to connect with cqlsh through ssl) but when I try to run kong with ssl verification disabled I receive the same error @xulongju reported. If I run the migrations manually I get the same result.

if kong.conf or kong_default.lua is not include "cassandra_contact_points"

Why would you remove this property from kong_default.lua? Why would you modify this file at all, even? Please don't.
@ivanpondal If you are still experiencing this on a more recent version of Kong, please open another issue with a reproducible use-case and the actual error you are seeing.
@kevinpgrant That is a completely different issue as per the error log - this does not even happen in the CLI. Anyway, it should be fixed in more recent versions (as of today, 0.13.1).


Find function strings instead of objects

Today a had the chance to try out the new version and I noticed that the find function now returns an array of strings instead of objects. That's not a huge problem, but it does make it a bit less simple to use, especially for newcomers to the project. I am not sure why this decision was made and what the benefits of it are. But let us reconsider the pros and cons of this again.

That must have happened during the switch to Napi. It's a mistake on my behalf for not checking the return type in the previous bindings.
I'll change it back to objects asap. It's slightly faster to return an object anyway because we can copy from a Spino dom node to a Napi object rather than stringification and re-parsing.
As an aside I've been developing unit tests, trying to achieve maximum test coverage with all the corner cases I can possibly imagine. I had some partial test coverage of the c++ code, and of the gobject bindings but none for node bindings. But there's been far too many bugs sliding through and we're doing something about it.

Fixed in d2d59321acf7a292a090747f2c8485a54ccfbd8c


Use MMCV's EvalHook in MMDetection

refer: https://github.com/open-mmlab/mmcv/pull/739

CI failed.
Need to keep the module in mmdet.core for at least a month and add warnings to avoid BC-breaking.


Fix links in quick-start-guide.md

fix links by switching to Markdown relative file references

Thanks Alex!


Collect fulfilment [3/3]

Changed

New ext_feature_collect_fulfilment  column.
Collect fulfilment text added in the installation page.
Application initialisation now reflects if the fulfillment is collection or application-address

[Delivers #158838199]

Tested the feature, it is ready to go.
@wnowicki since the requested change was addressed, I'm assuming you are fine with it being merged.


SSO works sometimes but fails often with  invalid_grant error. AADSTS9002313.

I am using SSO for Office add-in.  I obtain an authorization code with a request to https://login.microsoftonline.com/common/oauth2/v2.0/authorize
and redeem the code for an access token with a post to https://login.microsoftonline.com/common/oauth2/v2.0/token. The SSO works for some users but fails for others.  Here is a typical response received from the token server:
{"error":"invalid_grant","error_description":"AADSTS9002313: Invalid request. Request is malformed or invalid.\r\nTrace ID: f351e59c-dc4f-4b10-8293-4e6fe8c8c600\r\nCorrelation ID: 196c96ec-1310-4afb-8d4b-ab70d77bb816\r\nTimestamp: 2021-02-22 00:34:40Z","error_codes":[9002313],"timestamp":"2021-02-22 00:34:40Z","trace_id":"f351e59c-dc4f-4b10-8293-4e6fe8c8c600","correlation_id":"196c96ec-1310-4afb-8d4b-ab70d77bb816","error_uri":"https://login.microsoftonline.com/error?code=9002313"}
The App is configured in Azure portal to support accounts in any organizational directory and personal Microsoft accounts.

@cghaddar Could you please fill out one of our issue templates? Without more information about what library you are using we cannot debug this issue.

@pkanher617 Thank you for the reply.  I did figure out the error eventually.  The auth. code should be url decoded before redeeming. Some codes apparently did not require decoding while others did.


Count and Comment Adding

In this model User's..........
-[ ] Can add a new comment to project
-[ ] Add counter to comment and can populate the total comment in a pop-up

Branch nor working and keep giving error when opened. May be opened when fixed.


[docs] add two survey papers to readme

Pull Request Description
Summary
This pull request updates the README file with the latest research on diffusion models for visual computing, including the state-of-the-art paper and a comprehensive survey.
Changes

Incorporated  arxiv 23 Paper "State of the Art on Diffusion Models for Visual Computing" and  CSUR 24 Paper" Diffusion Models: A Comprehensive Survey of Methods and Applications", along with the respective GitHub repo Github.
Ensured that the links are functional and the information is up-to-date.

Review Notes

Please review the added content for accuracy and formatting.
Check that the links provided are correct and lead to the intended resources.
Please check if both the Chinese and English READMEs have been updated simultaneously.

Related Issues

Closes #159

Additional Comments

The inclusion of these resources will greatly benefit the community by providing a wealth of information on the latest advancements and applications in diffusion models for visual computing.

FYI : The acronym for ACM Computing Surveys is CSUR.


Same agent for more than one application in the same host.

Expected Behavior

When having more than one applications hosted in the same server I'm expected to be able to use the same agent as we can define the application name dinamically.

Current Behavior

It is working for the first messages that the agent collects but after some time it start showing the message "app_name can't change when working".

Steps to Reproduce
Please provide detailed steps for reproducing the issue.

start the agent in the host.
start the first application with name AP1 that will send message using sock file to the agent started in step1.
start the second application with name AP2 that will send message using sock file to the agent started in step1.
in web-ui you can se some message that are from AP1 and AP2 but after a while you get the warning "[WARNING] [AppManagement.py:51]  app_name can't change when working"

Context

Operating System: Centos8

PHP Version:7.4

php.ini:
extension=pinpoint_php.so
; unix:(unix sock address)
pinpoint_php.CollectorHost=unix:/tmp/collector-agent.sock
pinpoint_php.SendSpanTimeOutMs=0 # 0 is recommanded
pinpoint_php.TraceLimit=-1
;pinpoint_php.DebugReport=true

php-fpm or apache: php-fpm
[AP1 pinpoint defines]
define('APPLICATION_NAME','AP1');
define('APPLICATION_ID','server298');
[AP2 pinpoint defines]
define('APPLICATION_NAME','AP2');
define('APPLICATION_ID','server298');

pinpoint_agent.conf:
[Collector]
AgentID=server298
ApplicationName=AP1
collector.grpc.agent.ip=<IP_ADDRESS>
collector.grpc.agent.port=9991
collector.grpc.stat.ip=<IP_ADDRESS>
collector.grpc.stat.port=9992
collector.grpc.span.ip=<IP_ADDRESS>
collector.grpc.span.port=9993
[Common]
Web_Port=443
Log_Level=INFO
LOG_DIR=/var/log/pinpoint/
[Agent]
Address=/tmp/collector-agent.sock

You can use more than one app just define them with diferent name and diferent agent id.
My problem was the APPLICATION_NAME and APPLICATION_ID length limit of 25.


Android 2.3.6 not installing

Hi,
I have a problem with this library, I can't install my app on android 2.3.6 with Android Studio. I have to remove this line from gradle to install it on 2.3.6:
dependencies {
compile 'com.loopj.android:android-async-http:1.4.9'
}
On newer Android, it installs well.

We currently have minimum sdk version of 8, Android 2.3.6 shouldn't be any problem.
What error is given on install?


Port user_agent_extra from session over to client config

This is the ability to append to an existing user agent.
Note that this branch is based off of the clients-only branch, which I just rebased against develop and force-pushed.
cc @kyleknap

Coverage decreased (-0.55%) to 95.35% when pulling edd02d4fa35ac2799f8b333f2eb37e8e1f3927f4 on jamesls:user-agent-extra into 643d08c40cdc5e1d19483d0b71685fe91a757fb7 on boto:clients-only.

Looks good. :ship:

Merged into the clients-only branch via e770f6a


Create a social media dashboard template

Only the frontend part

can I work on this ?

Sure. I am assigning it to you

I want to work on this. Please assign it to me.


[Docs] DG show command

Codecov Report
Base: 71.93% // Head: 71.59% // Decreases project coverage by -0.34% :warning:

Coverage data is based on head (d623260) compared to base (6bd2024).
Patch has no changes to coverable lines.

Additional details and impacted files
@@             Coverage Diff              @@
##             master      #84      +/-   ##
============================================
- Coverage     71.93%   71.59%   -0.35%
- Complexity      645      650       +5
============================================
  Files           100      100
  Lines          1935     1968      +33
  Branches        211      215       +4
============================================
+ Hits           1392     1409      +17
- Misses          478      491      +13
- Partials         65       68       +3

Impacted Files
Coverage Δ

src/main/java/seedu/address/model/tag/TagSet.java
54.54% <0.00%> (-25.46%)
:arrow_down:

src/main/java/seedu/address/model/AddressBook.java
73.84% <0.00%> (-4.85%)
:arrow_down:

...rc/main/java/seedu/address/model/ModelManager.java
77.08% <0.00%> (-2.49%)
:arrow_down:

src/main/java/seedu/address/model/Model.java
100.00% <0.00%> (ø)

...du/address/logic/parser/TagCommandGroupParser.java
0.00% <0.00%> (ø)

...u/address/logic/parser/CreateTagCommandParser.java

...seedu/address/logic/commands/DeleteTagCommand.java
80.95% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Excessive INFO logging when market removed

/flumine/markets/markets.py
def remove_market(...)
		...
        logger.info(
            "Market removed",
            extra={"market_id": market_id, "event_id": event_id, "events": self.events},
        )

If live logging is set to INFO then each market removed is logged which is fine.
However, included with this data is a list of all items in the "events" dictionary and a list of all the market objects and their memory addresses - often this one message can amount to 15k+ of text - see sample below. Suggest either changing this logging to DEBUG or omitting the "events" dictionary from the output ie
extra={"market_id": market_id, "event_id": event_id},
Sample logging (11k long - only market subscription was to UK greyhounds)
{"asctime": "2023-12-09 12:08:47,769", "levelname": "INFO", "message": "Market removed", "market_id": "1.222313329", "event_id": "32863922", "events": {"32863893": ["<flumine.markets.market.Market object at 0x000001BF8CD58880>", "<flumine.markets.market.Market object at 0x000001BF8CD58430>", ...  ALL MARKET OBJECTS FOR THAT event_id ARE THEN LISTED

I will remove it, ironically this was added to try and isolate a memory leak.


[iOS][crash]EXC_BAD_ACCESS: countByEnumeratingWithState:objects:count: > setSrc: > Attempted to dereference garbage pointer 0x30.

Environment
System:
OS: macOS 10.14.5
CPU: (4) x64 Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
Memory: 669.12 MB / 16.00 GB
Shell: 3.2.57 - /bin/bash
Binaries:
Node: 10.16.0 - /usr/local/bin/node
Yarn: 1.17.0 - /usr/local/bin/yarn
npm: 6.9.0 - /usr/local/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
SDKs:
iOS SDK:
Platforms: iOS 12.2, macOS 10.14, tvOS 12.2, watchOS 5.2
Android SDK:
API Levels: 23, 24, 25, 26, 27, 28
Build Tools: 23.0.1, 23.0.3, 25.0.1, 25.0.2, 25.0.3, 26.0.1, 26.0.2, 27.0.3, 28.0.2, 28.0.3
npmPackages:
react: ^16.8.6 => 16.8.6
react-native: 0.59.9 => 0.59.9
Platforms
iOS
Versions
iOS: 12.3.1
react-native-svg: 9.5.3
react-native: 0.59.9
react: 16.8.6
Description
It crashed when I keep switching pictures multiple times
this is error:

Can you make a full reproduction?

Closing until a reproduction is available. Reopen when it is, or create a new issue.


Error encountered in build the Nvidia-container-toolkit

Dear all:
I encountered an error when I try to test whether the nvidia-container-toolkit will rum properly.
"
The docker has correctly installed and gives a correct response when I use 'hello-world" tested it
I run the nvidia-smi, and got the following information:
" NVIDIA-SMI 510.47.03    Driver Version: 510.47.03    CUDA Version: 11.6 "
THere are eight A40 GPU on the server.
The information about install nvidia-docker2 is as follows:
"# dnf install -y nvidia-docker2
Last metadata expiration check: 1:59:23 ago on Thu 21 Jul 2022 12:27:22 PM CST.
Module yaml error: Unexpected key in data: static_context [line 9 col 3]
Module yaml error: Unexpected key in data: static_context [line 9 col 3]
Dependencies resolved.
Package                          Architecture  Version                  Repository                               Size
Installing:
nvidia-docker2                   noarch        2.11.0-1                 libnvidia-container                      12 k
Installing dependencies:
libnvidia-container-tools        x86_64        1.10.0-1                 libnvidia-container                      53 k
libnvidia-container1             x86_64        1.10.0-1                 libnvidia-container                     1.0 M
nvidia-container-toolkit         x86_64        1.11.0-0.1.rc.1          libnvidia-container-experimental        3.2 M
Transaction Summary
Install  4 Packages
Total download size: 4.3 M
Installed size: 12 M
Downloading Packages:
(1/4): nvidia-docker2-2.11.0-1.noarch.rpm                                               23 kB/s |  12 kB     00:00
(2/4): libnvidia-container-tools-1.10.0-1.x86_64.rpm                                    89 kB/s |  53 kB     00:00
(3/4): libnvidia-container1-1.10.0-1.x86_64.rpm                                        1.2 MB/s | 1.0 MB     00:00
(4/4): nvidia-container-toolkit-1.11.0-0.1.rc.1.x86_64.rpm                             2.3 MB/s | 3.2 MB     00:01
Total                                                                                2.3 MB/s | 4.3 MB     00:01
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing        :                                                                                1/1
Installing       : libnvidia-container1-1.10.0-1.x86_64                                                          1/4
Running scriptlet: libnvidia-container1-1.10.0-1.x86_64                                                          1/4
Installing       : libnvidia-container-tools-1.10.0-1.x86_64                                                     2/4
Installing       : nvidia-container-toolkit-1.11.0-0.1.rc.1.x86_64                                               3/4
Installing       : nvidia-docker2-2.11.0-1.noarch                                                                4/4
Running scriptlet: nvidia-container-toolkit-1.11.0-0.1.rc.1.x86_64                                               4/4
Running scriptlet: nvidia-docker2-2.11.0-1.noarch                                                                4/4
Verifying        : libnvidia-container-tools-1.10.0-1.x86_64                                                     1/4
Verifying        : libnvidia-container1-1.10.0-1.x86_64                                                          2/4
Verifying        : nvidia-docker2-2.11.0-1.noarch                                                                3/4
Verifying        : nvidia-container-toolkit-1.11.0-0.1.rc.1.x86_64                                               4/4
Installed products updated.
Installed:
libnvidia-container-tools-1.10.0-1.x86_64                       libnvidia-container1-1.10.0-1.x86_64
nvidia-container-toolkit-1.11.0-0.1.rc.1.x86_64                 nvidia-docker2-2.11.0-1.noarch
Complete!"
Anyone can give me a help? Thanks

Thanks for the feedback! We recently moved to a better supported 11.1.1 cuda base image, which should resolve this issue.

Should the relevant line in the README be updated to reflect this change?  I also encountered an error (though not exactly the same as @sippmilkwolf's) when running that line, but things so far seem error-free when replacing 11.0 with 11.1.1.


Expression import reorders conditions

The default view of the data in the experiment view for an imported data file reorders the conditions into alphabetical order, rather than showing the original order of the data in the file. This seems odd, since it erases the groupings that were in place in the original data.
Original data:

Initial view:

I realize that in the analysis the order gets switched around but for an initial perusal of the data it make sense to me that it be in the order as defined by the user.

Fixed and waiting for the deployment in the production

The fix is available in production.


Enable pod identity and export for AKS deployments

Description
This PR enables pod identities for AKS deployments and uses the pod identity for export to a storage account.
Related issues
Addresses issue #1079.
Testing
E2E export tests enabled.

/azp run

/azp run

/azp run


Dump hardware details for Linux

On Linux, include a hardware information file in the tar file created by export-logs and export-local-logs.
The file is created by running uname -a, lscpu, lsgpu, lsmem, and lsblk, and writing that to a single file hardware.info in the config dir. (It's not removed, could add that if desired).
Example output:
Linux tabouleh 5.4.0-56-generic #62-Ubuntu SMP Mon Nov 23 19:20:19 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

*** Output from 'lscpu' ***

Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   43 bits physical, 48 bits virtual
CPU(s):                          16
On-line CPU(s) list:             0-15
Thread(s) per core:              2
Core(s) per socket:              8
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       AuthenticAMD
CPU family:                      23
Model:                           8
Model name:                      AMD Ryzen 7 2700X Eight-Core Processor
Stepping:                        2
Frequency boost:                 enabled
CPU MHz:                         2197.810
CPU max MHz:                     3700.0000
CPU min MHz:                     2200.0000
BogoMIPS:                        7399.22
Virtualization:                  AMD-V
L1d cache:                       256 KiB
L1i cache:                       512 KiB
L2 cache:                        4 MiB
L3 cache:                        16 MiB
NUMA node0 CPU(s):               0-15
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Full AMD retpoline, IBPB conditional, STIBP disabled, RSB filling
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb hw_pstate sme ssbd sev ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca
Linux tabouleh 5.4.0-56-generic #62-Ubuntu SMP Mon Nov 23 19:20:19 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

*** Output from 'lsgpu' ***

sys:/sys/devices/pci0000:00/0000:00:03.1/0000:1f:00.0/drm/card0
    subsystem       : drm
    drm card        : /dev/dri/card0
    parent          : sys:/sys/devices/pci0000:00/0000:00:03.1/0000:1f:00.0

sys:/sys/devices/pci0000:00/0000:00:03.1/0000:1f:00.0/drm/renderD128
    subsystem       : drm
    drm render      : /dev/dri/renderD128
    parent          : sys:/sys/devices/pci0000:00/0000:00:03.1/0000:1f:00.0

sys:/sys/devices/pci0000:00/0000:00:03.1/0000:1f:00.0
    subsystem       : pci
    drm card        : /dev/dri/card0
    drm render      : /dev/dri/renderD128
    vendor          : 10DE
    device          : 1D01

Linux tabouleh 5.4.0-56-generic #62-Ubuntu SMP Mon Nov 23 19:20:19 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

*** Output from 'lsmem' ***

RANGE                                  SIZE  STATE REMOVABLE  BLOCK
0x0000000000000000-0x00000000dfffffff  3.5G online       yes   0-27
0x0000000100000000-0x000000081fffffff 28.5G online       yes 32-259

Memory block size:       128M
Total online memory:      32G
Total offline memory:      0B
Linux tabouleh 5.4.0-56-generic #62-Ubuntu SMP Mon Nov 23 19:20:19 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

*** Output from 'lsblk' ***

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    0   1.8T  0 disk
└─sda1        8:1    0   1.8T  0 part /run/timeshift/backup
sr0          11:0    1  1024M  0 rom
nvme0n1     259:0    0 931.5G  0 disk
├─nvme0n1p1 259:1    0   731M  0 part /boot
├─nvme0n1p2 259:2    0 900.2G  0 part /
└─nvme0n1p3 259:3    0  30.6G  0 part [SWAP]

Closes #6799.

spotted a bug, will fix


Copy manifest and bundle from S3 to jenkins

Description
[Describe what this change achieves]
This change basically achieves two things:

Copying the files from S3
Putting the files into S3

Issues Resolved
[List any issues this PR will resolve]
Issue No. 260
https://github.com/opensearch-project/opensearch-build/issues/260
Check List

Signed-off-by: Megha Sai Kavikondala<EMAIL_ADDRESS>By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

This is replaced with #367


large config in web editor causes browser to hang

Describe the bug
There seems to be some sort of file size limits for the display engine used to view the config in the system settings. The config I have is currently 415 lines long (22KB on disk). If I go the system tab I get this in firefox:

Chrome hangs for a while before it sends a popup with the same thing, Wait or kill.
Chrome shows its graphql related:

Affected Component(s)

[ ] Back-End (Database, Microservices, Containers, etc)
[x] Front-End (Flask, API, etc)
[ ] Docs
[ ] Build System

To Reproduce
Still trying to nail down exactly where the limit is hit that causes it to stall.
Expected behavior
The config editor shouldn't stall
Screenshots
inline.
System (please complete the following information):

OS: OSX 10.15.4 (Catalina),
Browser Chrome v80, firefox v75
Version latest on github as of April 23rd 2020

Additional context
Add any other context about the problem here.

387 lines of config seems safe and normal speed.

Could be related to large copy and paste also, not the overall length of the file. Seems to happen if I paste a large amount of the config at one time, but load better after its been fully saved and the page totally refreshed?

@pixitha graphql connection stays open forever as it's a websocket. Can you check on the network tab the times for the websocket messages?

I want to see if the problem is on the yaml renderer that we use. If you can follow these steps and tell me if it runs ok. Use chrome and go to the sources tab:

Then find the prod-graphql.js and double-click it:

Then go to line 42 and click on the number to turn blue (it should be the fetchConfigStatsLive function) and then refresh the page:

After refreshing you will hit a breakpoint there and then you need to write on the console on the bottom b = function(){}:

Finally, click again on the line 42 to remove the breakpoint and click on the resume button for the script to continue.

If the page has loaded normally (it will not show the configuration though) and fast then it means that the render of the configuration is the slow part.

The page still seemed to load a bit slower, but not as slow/unresponsive as when the function is left to run.

After testing the above the page loads quickly and I can scroll around the page normally as soon as its on screen, unlike when its hung.

According to @pixitha this may be related to autoformatting. Therefore, we need to look in the code for places where we write the entire configuration in an automated way and deactivate them with a flag to check if the hanging issue is dealt with. Will make a small PR on this soon.

Tentatively fixed in new frontend (to be released). Closing for now, will re-open if problem persists.


Add numbers to left navigation menu like in voila

At the ends of stages, we say "proceed to stage N". This may be a bit confusing if we don't number the stages the way we did in voila. Can we change those box icons to numbers?
This version:

Voila version:

@patudom What about something like this? AFAICT these are the only numeric circle MDI icons (the previous numbers came from the v-stepper component, which we aren't using anymore)

That's great - thank you!

Can we merge this to both the demo branch and main?

Oops, sorry, deleted the image by mistake. Here it is again:

@patudom This is a cosmicds-level change so both versions will pick this up.

Also, FWIW I was able to recreate the menu using the v-stepper component that we have previously used in voila, but the routing behavior was not as nice (it seemed to reload the app on each route). Something about the navigation drawer with nav=True must work better with the Solara routing.

@patudom This is a cosmicds-level change so both versions will pick this up.

Are we not using https://github.com/cosmicds/cosmicds/tree/public-demo for the demo version?


Create GhostCounter.json

Temporary file so i can change that to true when the bestiary update drop

Move to draft. idk if we can close it entirely.

We can close as the bestiary update was added like a month or two ago


how to get a OPENAI_API_KEY?

I run:
$ python3 ingest_data.py
  Did not find openai_api_key, please add an environment variable `OPENAI_API_KEY` which contains it, or pass  `openai_api_key` as a named parameter. (type=value_error)

I tried the following to get a OPENAI_API_KEY:
Sign up on https://app.aleph-alpha.com/
and Create Token on https://app.aleph-alpha.com/profile
I get a token 125 chars long.
I run:
$ export OPENAI_API_KEY=eyJ0eXAiOiJKV...
$ python3 ingest_data.py
openai.error.AuthenticationError: <empty message>

What is the correct way to get OPENAI_API_KEY?

Ok, it is needed an API key from OpenAI. Here it is how to get an account and key:
https://platform.openai.com/signup
https://platform.openai.com/account/api-keys


How to create Docker image?

Checklist

[X] I'm asking a question and not reporting a bug or requesting a feature
[X] I've looked through the README
[X] I've verified that I'm running yt-dlp version 2022.07.18 (update instructions) or later (specify commit)
[X] I've searched the bugtracker for similar questions including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue

Please make sure the question is worded well enough to be understood
How can I create a Docker container image for yt-dlp? It worked for youtube-dl but now not for yt-dlp. Here's my dockerfile:
FROM openjdk:8u151-jre-alpine
RUN apk update && apk add bash && apk add python3 && apk add ffmpeg
RUN apk add gcc
RUN pip3 install yt-dlp
I'm using Windows 11  and Docker 4.3.1
Provide verbose output that clearly demonstrates the problem

[ ] Run your yt-dlp command with -vU flag added (yt-dlp -vU <your command line>)
[ ] Copy the WHOLE output (starting with [debug] Command-line config) and insert it below

Complete Verbose Output
...
 > [4/5] RUN pip3 install yt-dlp:
#7 0.576 Collecting yt-dlp
#7 1.022   Downloading https://files.pythonhosted.org/packages/1f/13/b1f7b4e44b11584a5f077af87895961b57911217a629efb8d3a9efd2a491/yt_dlp-2022.7.18-py2.py3-none-any.whl (2.7MB)
#7 2.752 Collecting pycryptodomex (from yt-dlp)
#7 3.200   Downloading https://files.pythonhosted.org/packages/52/0d/6cc95a83f6961a1ca041798d222240890af79b381e97eda3b9b538dba16f/pycryptodomex-3.15.0.tar.gz (4.5MB)
#7 6.478 Collecting certifi (from yt-dlp)
#7 6.596   Downloading https://files.pythonhosted.org/packages/e9/06/d3d367b7af6305b16f0d28ae2aaeb86154fa91f144f036c2d5002a5a202b/certifi-2022.6.15-py3-none-any.whl (160kB)
#7 6.695 Collecting mutagen (from yt-dlp)
#7 6.798   Downloading https://files.pythonhosted.org/packages/16/b3/f7aa8edf2ff4495116f95fd442b2a346aa55d1d46313143c8814886dbcdb/mutagen-1.45.1-py3-none-any.whl (218kB)
#7 6.941 Collecting websockets (from yt-dlp)
#7 7.174   Downloading https://files.pythonhosted.org/packages/0d/bd/5262054455ab2067e51de331bfbc53a1dfa9071af7c424cf7c0793c4349a/websockets-9.1.tar.gz (76kB)
#7 7.457 Collecting brotli; platform_python_implementation == "CPython" (from yt-dlp)
#7 7.604   Downloading https://files.pythonhosted.org/packages/2a/18/70c32fe9357f3eea18598b23aa9ed29b1711c3001835f7cf99a9818985d0/Brotli-1.0.9.zip (510kB)
#7 8.151 Installing collected packages: pycryptodomex, certifi, mutagen, websockets, brotli, yt-dlp
#7 8.151   Running setup.py install for pycryptodomex: started
#7 8.588     Running setup.py install for pycryptodomex: finished with status 'error'
#7 8.588     Complete output from command /usr/bin/python3.6 -u -c "import setuptools, tokenize;__file__='/tmp/pip-install-5rfpe7l7/pycryptodomex/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-record-5z20tc3d/install-record.txt --single-version-externally-managed --compile:

.......

#7 8.589     copying lib/Cryptodome/Math/_IntegerBase.pyi -> build/lib.linux-x86_64-3.6/Cryptodome/Math
#7 8.589     running build_ext
#7 8.589     building 'Cryptodome.Hash._MD2' extension
#7 8.589     creating build/temp.linux-x86_64-3.6
#7 8.589     creating build/temp.linux-x86_64-3.6/src
#7 8.589     gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Os -fomit-frame-pointer -g -Os -fomit-frame-pointer -g -Os -fomit-frame-pointer -g -DTHREAD_STACK_SIZE=0x100000 -fPIC -DPYCRYPTO_LITTLE_ENDIAN -DSYS_BITS=64 -DLTC_NO_ASM -Isrc/ -I/usr/include/python3.6m -c src/MD2.c -o build/temp.linux-x86_64-3.6/src/MD2.o
#7 8.589     In file included from src/MD2.c:28:0:
#7 8.589     src/common.h:34:19: fatal error: stdio.h: No such file or directory
#7 8.589      #include <stdio.h>
#7 8.589                        ^
#7 8.589     compilation terminated.
#7 8.589     error: command 'gcc' failed with exit status 1
#7 8.589
#7 8.589     ----------------------------------------
#7 8.659 Command "/usr/bin/python3.6 -u -c "import setuptools, tokenize;__file__='/tmp/pip-install-5rfpe7l7/pycryptodomex/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-record-5z20tc3d/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-install-5rfpe7l7/pycryptodomex/
#7 8.921 You are using pip version 18.1, however version 21.3.1 is available.
#7 8.921 You should consider upgrading via the 'pip install --upgrade pip' command.
------
executor failed running [/bin/sh -c pip3 install yt-dlp]: exit code: 1

Change to pip3 install yt-dlp --no-dep

Thank you. It works.
FROM openjdk:8u151-jre-alpine

RUN apk update && apk add bash && apk add python3 && apk add ffmpeg
RUN pip3 install yt-dlp --no-dependencies


Run history is not showing anything in logic app

Describe the Bug with repro steps
Run history is showing only result count but not the details in logic app workflow overview screen

What type of Logic App Is this happening in?
Consumption (Portal)
Which operating system are you using?
Windows
Are you using new designer or old designer
New Designer
Did you refer to the TSG before filing this issue? https://aka.ms/lauxtsg
Yes
Workflow JSON
No response
Screenshots or Videos
No response
Browser
Firefox
Additional context
No response

Hey @jain-vikas thans for raising this issue,  if you close or click in the icon next to the "Essentials" tab in your screenshot, does it close and shows the list of runs?

Also have same issue.

Hi @jain-vikas @Red1971 we have seen that there is an ongoing issue with the run history in standard logic apps. By any chance do you see any logs/errors in the console or network tab?

Hey @jain-vikas thans for raising this issue, if you close or click in the icon next to the "Essentials" tab in your screenshot, does it close and shows the list of runs?

Yes I can see run history details after clicking on essentials.. Thanks

I am using a Standard Logic App with VNet Integration. I can't see either "run" or "trigger" history.
Wonder if its related to...
https://github.com/Azure/logicapps/issues/820

Hi @Red1971 I think the issue is not related.

Do you see any error/message in the console or network tab?
Is there any chance we can get the HAR file when you load the run history tab? Here is a small guide on Collecting network logs in a HAR file. You can send the file to my email<EMAIL_ADDRESS>Can we also get the name of the logic app and workflow to do some proper investigation. You can share that as well in my email.

Thanks!

Have emailed<EMAIL_ADDRESS>with the information requested

Hi @Red1971 Thanks for the email. I will take a look at it


Refresh part 4 of writing rust policies, validation logic.

Keeping in draft for the moment, until the question regarding failing cargo test from the previous PR can be answered. Then I can work through this one to make sure it all works.
Tutorials should just work.
Will close #298 when merged.

Closing the PR as the 'first three' one #295 ended up having all the changes.


Recognition of Lecanopteris sensu lato (Polypodiaceae)

Author(s) of proposal
Ashley Field
Name of taxon
Lecanopteris Reinw.
Rank of taxon
Genus
Approximate number of species affected
12
Description of change
Perrie et al. (2021) re-circumscribed the genus Lecanopteris Reinw. based on a further morphological and philosophical appraisal of the phylogenies of Testo et al. (2019) and Chen et al. (2020). Lecanopteris was broadened to include the recently resurrected and recircumscribed genus Dendroconche and recently described genus Zealandia to achieve monophyly from a previously paraphyletic Microsorum and Colysis. The abstract of Perrie et al. (2021) is reproduced below:
"The fern genus Microsorum is not monophyletic, with previous phylogenetic analyses finding three lineages to group not with the type species, but to form a grade related to the 13 species of Lecanopteris. These three lineages have recently been recognised as separate genera: Bosmania, Dendroconche, and Zealandia. Here, we explore the morphological characterisation of Lecanopteris and these other three lecanopteroid genera. While the\ traditional circumscription of Lecanopteris has seemed sacrosanct, its defining morphological character states of rhizome cavities and ant brooding associations occur in other lecanopteroid ferns and elsewhere in the Polypodiaceae. Instead, we suggest that the morphological characterisation of an expanded Lecanopteris including the Dendroconche and Zealandia lineages is just as good, if not better, with the pertinent character states being the absence of sclerenchyma strands in the rhizome and at least some fronds having Nooteboom's type 5 venation pattern. This wider circumscription is also better able to accommodate phylogenetic uncertainty, and it means that groups of species traditionally placed together in a single genus are not distributed across different genera. General users familiar with the narrower circumscription of Lecanopteris will not be significantly disrupted, because there is little geographic overlap with the lineages added to the genus. Consequently, we make new combinations in Lecanopteris for 11 species and one subspecies."
Reason for change
Multiple studies have shown that Microsorum and Colysis as adopted in PPG I (2016) were paraphyletic. This proposal is directed at achieving monophyly among relevant genera by recognition a broadly circumscribed Lecanopteris subsuming the recently described Dendroconche and Zealandia but not Bosmania. This proposal should be read in conjunction with proposals for Bosmania + Dendroconche + Lecanopteris s.s. + Zealandia sensu Testo et al. (2019) (#25, #26, #27).
This proposal affects approximately 12 species occurring across Oceania. It was adopted World Ferns. It should be compared to the contrasting three-genus classification presented by Testo et al. (2019).
Reference(s) for publication of the name
Perrie L.R., Field A.R., Ohlsen D.J., Brownsey P.J. (2021) Expansion of the fern genus Lecanopteris to encompass some species previously included in Microsorum and Colysis (Polypodiaceae) Blumea 66: 242–248.
See also:
Chen C-C, Hyvönen J, Schneider H. 2020. Exploring phylogeny of the microsoroid ferns (Polypodiaceae) based on six plastid DNA markers. Molecular Phylogenetics and Evolution 143: 106665.
Testo W.L., Field A.R., Sessa E.B., Sundue M. (2019) Phylogenetic and Morphological Analyses Support the Resurrection of Dendroconche and the Recognition of Two New Genera in Polypodiaceae Subfamily Microsoroideae Systematic Botany 44(4): 1–16.
List the numbers of any related issues
#25, #26, #27
Code of Conduct

[X] I agree to follow the PPG Code of Conduct

I wish to weigh in on this proposal, as I am one of the folks responsible for the recognition of Zealandia and the resurrection of Dendroconche, both of which would be treated within Lecanopteris. if this proposal were accepted.
The non-monophyly of Microsorum and several related genera is well-documented (Kreier et al., 2008; Testo & Sundue, 2014; Chen et al., 2020) and has stymied efforts to produce a satisfactory generic level classification of Polypodiaceae subfamily Microsoroideae. Testo et al. (2019) generated a phylogeny of subfamily Microsoroideae using four chloroplast loci and 167 taxa – including the type species of all 12 genera recognized by PPG1 (2016) for the subfamily – and demonstrated that 16 taxa that had treated as Microsorum and Colysis were not closely related to those genera and instead formed three monophyletic groups that were successively sister to Lecanopteris. Using ancestral character state reconstruction of six morphological characters, Testo et al. (2019) demonstrated that each of the three groups presented readily evident synapomorphies and all of them could be easily distinguished from each other and from Lecanopteris. We recognized these three clades at the generic level – one name (Dendroconche) was resurrected from synonymy, and two others (Bosmania and Zealandia) were newly described.
As thus circumscribed, the four genera of lecanopteroid ferns (tribe Lecanoptereae C.C. Chen & H. Schneider) are:
Lecanopteris, characterized by an association with ants that live in cavities either within or underneath dramatically enlarged rhizomes.
Dendroconche, characterized by hemiepiphytic growth habit, non-pruinose rhizomes, non-impressed sori, bright yellow verrucate spores, and specialized laterally inserted clasping roots used for climbing.
Zealandia, characterized by (mostly) epiphytic growth habit, deeply impressed sori that are readily visible on the adaxial laminar surface, prominent veins that contrast strongly with the laminar tissue, and pruinose rhizomes.
Bosmania, characterized by terrestrial growth habit, membranaceous laminae, and simple leaves that are deciduous in the dry season.
These synapomorphies are supported by ancestral character state reconstructions and images are provided to guide users.

The monophyly of these genera was supported by a subsequent study (Chen et al. 2020) with improved taxon sampling and a different set of loci, though that study recovered Dendroconche (vs. Zealandia in Testo et al. 2019) as sister to Lecanopteris. Chen et al. (2020) compared the generic classification proposed by Testo et al. (2019) to two alternatives involving a more broadly construed Lecanopteris; they concluded that extending Lecanopteris to include Dendroconche was “less suitable” than recognizing the latter as a distinct genus and that recognizing Lecanopteris with Dendroconche and Zealandia included in it “would still perhaps not be the best option because it would be morphologically poorly defined.”
As proposal #28 shows, Perrie et al. (2021) rejected the recognition of Zealandia and Dendroconche in favor of an expanded Lecanopteris that includes those taxa. Here, I will outline the main arguments presented by Perrie et al. (2021) for expanding Lecanopteris and explain why I think recognition of four genera within Tribe Lecanoptereae is preferable.
Utility and stability of genus-level synapomorphies:  Perrie et al. (2021) suggests that “the morphological characterisation of an expanded Lecanopteris including the Dendroconche and Zealandia lineages is just as good, if not better, with the pertinent character states being the absence of sclerenchyma strands in the rhizome and at least some of the fronds having Nooteboom’s type 5 venation pattern.”
With the exception of Zealandia powelii, all of the species included in Lecanopteris by Perrie et al. (2021) lack free sclerenchyma strands in the rhizome, though many of these species do possess sclerenchyma bands associated with the rhizome vasculature (Bosman, 1991; Nooteboom, 1997; Testo & Sundue, 2014). In addition, and as pointed out by Perrie et al. (2021), numerous taxa that belong to non-lecanopteroid lineages in subfamily Microsoroideae also lack sclerenchyma strands in the rhizome, including species of Microsorum, Lepidomicrosorium, Neocheiropteris, and several unplaced taxa.
Further, the type 5 venation pattern of Nooteboom (1997) is not present in all species included in Perrie et al.’s concept of Lecanopteris (Zealandia powellii lacks such venation) and is only present in the fertile leaves of what is by far the most commonly collected species in the clade (Zealandia pustulata). They also report that “type 5 patterns were recorded for several species currently unplaced phylogenetically but which may be lecanopteroids.” This includes Microsorum aurantiacum, which was suggested by Nooteboom (1997) to be a close relative of taxa now placed in Zealandia, but which possesses sclerenchyma strands in the rhizome, thereby presenting another potential exception to the characters used by Perrie et al. (2021) to support an expanded Lecanopteris.

The above is Figure 2 from Perrie et al. (2021), which shows (from left to right) venation types 5, 3, and 1 of Nooteboom (1997). In my view, the differences between these venation types are subtle and considerably more challenging to interpret than the characters proposed by Testo et al. (2019) as synapomorphies for the genera recognized therein.
With character stability set aside, I do not agree with Perrie et al.’s claim that “the morphological characterisation of an expanded Lecanopteris including the Dendroconche and Zealandia lineages is just as good, if not better,”than the traditional circumscription of the genus on the basis of myrmecophily and highly modified rhizomes, like these (photo by Chuck Hung, used under CC BY-NC-SA license):

Perrie et al. (2021) also argue that myrmecophily and rhizomes with ant domatia are not suitable synapomorphies for Lecanopteris, as they occur in other genera of Polypodiaceae. They do not, however, apply the same logic to the presence of sclerenchyma strands in the rhizome or reticulate venation with large costal areoles, the characters they use to define the genus. Both characters occur in many genera of Polypodiaceae and other fern families and are doubtlessly much more homoplastic than than ant-fern symbiosis like that found in Lecanopteris.
Setting this point aside, both the classification schemes of Testo et al. (2019) and Perrie et al. (2021) utilize some synapomorphies that are not unambiguous (i.e. those character states are not shared by all members of the genus or they occur in other clades); this is certainly not unique to this group of ferns. In such a case, having a greater number of characters that together define clades –like the classification of Testo et al. (2019)-- is clearly preferable. This approach to classifying the lecanopteroid ferns promotes recognition of genera that are more morphologically cohesive, share a larger number of evident synapomorphies, and maintains the long-standing circumscription of Lecanopteris, one of the most distinctive Polypodiaceae genera.
Stability in the face of phylogenetic uncertainty:
Perrie et al. (2021) argue that an expanded Lecanopteris is better suited than the classification proposed by Testo et al. (2019) to accommodate phylogenetic uncertainty in the microsoroid ferns. This uncertainty is problematic in part, they suggest, because Testo et al. (2019) and Chen et al. (2020) recovered different phylogenetic relationships for the genera in tribe Lecanoptereae, and Perrie et al. (2021) depict the relationships of Dendroconche, Zealandia, and Lecanopteris with a polytomy (Figure 1). Though Testo et al. (2019) and Chen et al. (2020) do differ in the clade they recover as sister to Lecanopteris, neither study recovers a polytomy, and all the genera proposed by Testo et al. (2019) are strongly supported as monophyletic in all analyses conducted by both Testo et al. (2019) and Chen et al. (2020).
Following up on this, Perrie et al. (2021) point to numerous species currently treated in Microsorum that have not been placed in a phylogenetic context and may eventually be found to be members of tribe Lecanoptereae. They state that “if any of the unplaced species did not fall within the already identified lineages (as happened within this geographic region for some New Caledonian Lastreopsis; Gardner et al. 2017), then additional genera would be required.*** While that could happen at some point in the future, I do not agree that such a possibility is “arguably a significant problem,” as Perrie et al. (2021) posit. Such discoveries have improved our understanding of fern evolution and informed classification efforts, whether they have ultimately led to an increase (e.g. dissolution of Blechnum s.l.; Perrie et al. 2014; Gasper et al. 2017) or a decrease (e.g. union of Eriosorus and Jamesonia; Sánchez-Baracaldo 2004) in the number of recognized genera.
***A brief aside – the Lastreopsis taxa mentioned were found both by Gardner et al. (2017) and Perrie et al. (2021b) to be clearly nested within Lastreopsis, and no new genus name was ever proposed to accommodate them. I point this out as it is relevant to this and possibly to future proposals.
Testo et al. (2019), Chen et al. (2020), and Perrie et al. (2021) all concur that data available at this time are not sufficient to confidently assign these unplaced species to the genera defined by Testo et al. (2019), other lineages within the lecanopteroid ferns, or to another clade of subfamily Microsoroideae altogether. I think that is OK. As I see it, decisions about generic classification should be made based on available data, and generic circumscriptions can (and should) be re-evaluated as new data become available.
Regional versus global perspectives on fern classification:
Perrie et al.’s argument for expanding Lecanopteris to include Zealandia and Dendroconche is based in part on the premise that these lineages rarely overlap geographically, thereby minimizing disruption and confusion for workers in a given country or region. As I understand it, this point argues that the disruption of the traditional circumscription of Lecanopteris at a global scale will not significantly impact a worker based in New Zealand, for example, because they previously did not have any Lecanopteris species in their flora, so they have a “fresh slate”, so to speak. Similarly, someone working in Malaysia would not be seriously inconvenienced, Perrie et al. argue, because all but one of the species of a newly expanded Lecanopteris in their flora had been treated in that genus already.
While I do not agree with Perrie et al.’s point that it is inconsequential to lump readily distinguishable groups because workers in one region or another may not notice much of a difference (in that case, why not re-circumscribe Salpichlaena to include Stenochlaena and Telmatoblechnum?), I think that is is more important to note that such a viewpoint appears to be incompatible with the goals of PPG2. Attempts at developing coherent classifications for ferns in the modern era (e.g., Smith et al., 2006; Christenhusz & Chase, 2014; PPG1, 2016) have had a global scope, and PPG2 is no exception. PPG2 is a global community effort includes nearly 200 participants from dozens of countries, and there is good reason to expect that the classification we develop will be widely adopted by users from around the world for applications that are often global in scope. Of course, some users may opt for alternative classifications that are framed by regional or national perspectives on plant diversity; nonetheless, I do not think such views should inform the PPG2 approach to classification.
For these reasons, I will be voting against the recognition of an expanded Lecanopteris and in favor of the recognition of Bosmania(#27), Dendroconche(#27), and Zealandia(#26).
-- Wes Testo
References
Bosman, M. T. M. 1991. A monograph of the fern genus Microsorum (Polypodiaceae) including an attempt towards a reconstruction of the phylogenetic history of the microsoroids. Leiden Botanical Series, 14: 1–161.
Chen C-C, Hyvönen J, Schneider H. 2020. Exploring phylogeny of the microsoroid ferns (Polypodiaceae) based on six plastid DNA markers. Molecular Phylogenetics and Evolution 143: 106665.
Christenhusz, M. J., & Chase, M. W. 2014. Trends and concepts in fern classification. Annals of botany, 113: 571–594.
Gardner, J. J., Perrie, L., Shepherd, L., & Nagalingum, N. S. 2017. Taxonomic placement of unassigned species of lastreopsid ferns (Dryopteridaceae) using phylogeny. Systematic Botany 42: 385–391.
de Gasper, A. L., Almeida, T. E., Dittrich, V. A. D. O., Smith, A. R., & Salino, A. 2017. Molecular phylogeny of the fern family Blechnaceae (Polypodiales) with a revised genus‐level treatment. Cladistics, 33: 429–446.
Kreier, H. P., Zhang, X. C., Muth, H., & Schneider, H. 2008. The microsoroid ferns: Inferring the relationships of a highly diverse lineage of Paleotropical epiphytic ferns (Polypodiaceae, Polypodiopsida). Molecular Phylogenetics and Evolution, 48: 1155–1167.
Nooteboom, H. P. 1997. The microsoroid ferns (Polypodiaceae). Blumea: Biodiversity, Evolution and Biogeography of Plants, 42: 261–395.
Perrie, L. R., Wilson, R. K., Shepherd, L. D., Ohlsen, D. J., Batty, E. L., Brownsey, P. J., & Bayly, M. J. 2014. Molecular phylogenetics and generic taxonomy of Blechnaceae ferns. Taxon, 63: 745–758.
Perrie L.R., Field A.R., Ohlsen D.J., Brownsey P.J. (2021) Expansion of the fern genus Lecanopteris to encompass some species previously included in Microsorum and Colysis (Polypodiaceae) Blumea 66: 242–248.
Perrie, L. R., Amice, R., Shepherd, L. D., & Brownsey, P. J. (2021B). Lastreopsis abscondita (Dryopteridaceae), a new fern species endemic to New Caledonia. New Zealand Journal of Botany, 59(3), 409-422.
PPG 1. 2016. A community‐derived classification for extant lycophytes and ferns. Journal of systematics and evolution, 54: 563–603.
Sánchez‐Baracaldo, P. 2004. Phylogenetics and biogeography of the neotropical fern genera Jamesonia and Eriosorus (Pteridaceae). American Journal of Botany, 91: 274–284.
Smith, A. R., Pryer, K. M., Schuettpelz, E., Korall, P., Schneider, H., & Wolf, P. G. 2006. A classification for extant ferns. Taxon, 55: 705–731.

Testo W.L., Field A.R., Sessa E.B., Sundue M. (2019) Phylogenetic and Morphological Analyses Support the Resurrection of Dendroconche and the Recognition of Two New Genera in Polypodiaceae Subfamily Microsoroideae Systematic Botany 44(4): 1–16.

The lecanopteroid ferns are a tricky situation, perhaps explaining why there was no action for 15 years after their non-monophyly with respect to Microsorum was first detected.  The two principal solutions of [1] recognising several, small, genera (i.e., Bosmania, Dendroconche, and Zealandia) or [2] expanding Lecanopteris both have disadvantages (as well as merits).  We prefer the expansion of Lecanopteris, which is why we offered it for consideration (Perrie et al. 2021) – it is for us the “least worst” of two unpalatable options.
The principal disadvantage of expanding the circumscription of Lecanopteris is that even more morphological variation is encompassed.  But it's important context that one of the species of Lecanopteris s.s. does not form rhizome cavities, and some of the species of the Dendroconche lineage seem to be associated with ants, meaning that the traditional circumscription of Lecanopteris is ‘fuzzier’ than usually portrayed.  The characters in this broader group of ferns are unfortunately rarely perfectly diagnostic, including those suggested for the segregates.  Leaf venation may be subtle to some, but, speaking from personal field experience of these ferns, so are several of the characters proffered for the segregates.
At issue is not whether the geographic focus of PPG should be anything but global, but rather whether it is primarily for taxonomists or for general users of taxonomic names.  There are a lot more of the latter, and there is an argument for prioritising their needs (albeit within a monophyletic classification) over what might be a taxonomist’s desire to have genera that are globally morphologically cohesive.
In this regard, expanding Lecanopteris keeps together several species that have long been congeneric (albeit in different genera) rather than disassociating them across a couple of genera (i.e., Dendroconche and Zealandia for several Australian, New Caledonian, and New Zealand examples).  The surveying I’ve done, albeit admittedly limited, anecdotal, and only in New Zealand, indicates a clear preference among general users for keeping the relevant species in one genus (which would mean adopting an expanded Lecanopteris).
There are consequences for general users in the regions with Lecanopteris s.s. in that three species would be added within their regions if its circumscription was expanded, with one of these species being widespread (but little observed – just two observers on iNaturalist for these three species even though there are tens of thousands of users of this citizen science platform in these regions).  Weighing impacts on general users across regions is invidious, but a name change is needed for these species regardless (whether it be to Dendroconche or Lecanopteris).  General taxonomy users familiar with Lecanopteris s.s. already need to deal with its morphological variability, such that accommodating another species (or three species for those in New Guinea) within its circumscription is unlikely to be overly problematic for regional identification keys, and means dealing with one less genus name.
A second advantage of an expanded Lecanopteris is that a broader genus can more easily and stably accommodate the uncertain relationships of several species.  As these are tested with DNA analyses, there is every possibility that they will fall outside the Dendroconche, Zealandia, and Bosmania (and Lecanopteris s.s.) lineages.  If so, they could easily be accommodated within an expanded Lecanopteris circumscription, but, under the segregated system, they would necessitate the description of additional genera that would be similarly small (likely one to a few species).  Preserving Lecanopteris s.s. could well entail recognising more genera than just the three additions already posited.
Perhaps it’s only a matter of taste as to whether one prefers fewer, bigger, more stable genera or smaller genera that have a propensity to proliferate as we learn more about evolutionary relationships – splitting in the face of phylogenetic uncertainty tends to beget more splitting.  General users typically prefer stability and fewer (generic) names.
*** with the aside about Lastreopsis, it’s less about the genus circumscription (although note the support values in Gardner at al. 2016), and more about it being unclear to which of the two subgenera the New Caledonian species should be assigned.  The point that is relevant to the lecanopteroids is that it is not unusual to find lineages even in the Pacific that don’t fit comfortably with patterns determined elsewhere/previously.
Gardner JJ, Perrie L, Shepherd L, Nagalingum NS. 2017. Taxonomic placement of unassigned species of lastreopsid ferns (Dryopteridaceae) using phylogeny. Systematic Botany 42: 385–391.
Perrie LR, Field AR, Ohlsen DJ, Brownsey PJ. 2021 Expansion of the fern genus Lecanopteris to encompass some species previously included in Microsorum and Colysis (Polypodiaceae) Blumea 66: 242–248.

This proposal was voted on during PPG Ballot 3 (voting period September 2023). A total of 68 votes were cast. There were 34 'Yes' votes (50%) and 34 'No' votes (50%). The proposal does not pass.


Improve logic for closing stale issues

This is to make sure we only ever close a stale issue if the warning has already been posted.
Fixes https://github.com/OpenAstronomy/baldrick/issues/68

Looks good to me, but bear in mind that I'm not familiar with the codebase.
The only real question I have is: what happens to the PRs/issues that should have been closed already but the bot wasn't running? I suppose they got their warnings next time the bot runs, but the they get closed the next week when the bot runs again?

Codecov Report

Merging #69 into master will decrease coverage by 0.34%.
The diff coverage is 57.14%.

@@            Coverage Diff             @@
##           master      #69      +/-   ##
==========================================
- Coverage   82.22%   81.88%   -0.35%
==========================================
  Files          16       16
  Lines         799      806       +7
==========================================
+ Hits          657      660       +3
- Misses        142      146       +4

Impacted Files
Coverage Δ

baldrick/github/github_api.py
63.46% <0%> (-0.6%)
:arrow_down:

baldrick/scripts/stale_issues.py
96.22% <100%> (-1.74%)
:arrow_down:

Continue to review full report at Codecov.

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

The only real question I have is: what happens to the PRs/issues that should have been closed already but the bot wasn't running? I suppose they got their warnings next time the bot runs, but the they get closed the next week when the bot runs again?

The scripts run daily in fact - and the way the code is written, the warning is posted relative to when the label was added, and the closing happens relative to when the warning was added, so it should all work fine even for very old issues.


runner.Test undefined (type weavertest.Runner has no field or method Test

I'm running weaver v0.12.
I followed the official documentation to create tests.
I use a similar code:
func TestAdd(t *testing.T) {
     runner := weavertest.Local  // A runner that runs components in a single process
     runner.Test(t, func(t *testing.T, adder Adder) {
         ctx := context.Background()
         got, err := adder.Add(ctx, 1, 2)
         if err != nil {
             t.Fatal(err)
         }
         if want := 3; got != want {
             t.Fatalf("got %q, want %q", got, want)
         }
     })
}

It seems like weavertest.Local.Test does not exist.
runner.Test undefined (type weavertest.Runner has no field or method Test)

Running onto the same issue.
I've tried also with version v0.10 => same compilation error ...

Ah, this is unfortunately a known problem with our online documentation. The docs reflect the main branch of our repo which is ahead of the latest version (0.12.0 in this case). We'll release v0.13.0 soon which should fix the problem. We'll also work on changing the online docs to reflect the latest version. Sorry for this!

This should be fixed now! I'll close the issue, but please re-open if the problem persists.

Thank you for this, it works now with version v0.13.0


Implement possibility to delete report in debug tab

In the old GUI it is possible to delete reports when the debug storage not only implements LogStorage but also CrudStorage. See the code of the old GUI:
https://github.com/ibissource/ibis-ladybug/blob/v2.2/src/main/java/nl/nn/testtool/echo2/reports/ReportComponent.java#L343
This is used by Tibet2.
It can be tested with the test webapp that is using the memory storage by default (which implements both LogStorage and CrudStorage)

Make an API call that checks if the storage is a Crudstorage, if so, you can add the delete button and consequently delete reports from debug tab.


Misc fixes

I'm wondering a bit why we did not discover the missing "tf_toolchains" dependency earlier.

I believe it gets downloaded when we run bazel sync but not in local/
when building from the "upstream" tarball we have created, the local target isn't executed (the folder exists) and tf_toolchains is consequently missing


Numerically stable summation methods

It would be nice to be able to use numerically stable summation methods like

pairwise summation
Kahan summation

for applications where numerical accuracy is important.
This could work with an optional stable keyword argument to tf.reduce_sum or via a tf.stable_reduce_sum op.
I think implementing Kahan summation in the Eigen tensor library wouldn't be difficult at all, we would simply have to add a stateful KahanSumReducer.
It should also be possible to provide a vectorized version.
Pairwise summation might be more difficult, as the reduction code would have to be touched.

dibs

@suiyuan2009: Cool, but you should get some input from one of the tensorflow devs before starting. @benoitsteiner, would this be a reasonable contribution?

Any news? I could make good use of this.

@egpbos want to contribute?

In principle, yes, but I'm still deciding whether to go with TensorFlow in our project in the first place, which most importantly depends on #5323. Might take a few more weeks before we decide.

Looks like this fell through the cracks.  Good idea though, so I'll leave it open.

@girving I am trying to get this into the Eigen library but the mailing list/issue tracker seem very inactive and I think that getting it into Eigen is going to take a long time. Is there some way I could implement this within tensorflow?

@rmlarsen Any suggestions for how to do Kahan summation without changing Eigen?  One problem is that an ideal implementation would probably stride the Kahan summation algorithm based on the architecture optimal packet size.

Please remove the assignee, as this issue is inviting external contributions. Otherwise, remove the contributions welcome label. Thank you.

Please remove the assignee, as this issue is inviting external contributions. Otherwise, remove the contributions welcome label. Thank you.

TF members, I'm not sure I understand the tensorflowbutler comments, but it seems the issue creator is not responding to the request to drop requests for contributions. Can you fix this your end?  It is now 2 years old, but very important to those who care about it.

Encounter the same problem here, the differences are huge for my task.  Any replacements?

Please remove the assignee, as this issue is inviting external contributions. Otherwise, remove the contributions welcome label. Thank you.

Please remove the assignee, as this issue is inviting external contributions. Otherwise, remove the contributions welcome label. Thank you.

Please remove the assignee, as this issue is inviting external contributions. Otherwise, remove the contributions welcome label. Thank you.

Is there any update on this issue? I think it's especially important for policy gradient reinforcement learning, since the basin of attraction is less stable. I can run the same RL algorithm twice with all other sources of nondeterminism eliminated, and get significantly different results each time. I would like to publish reproducible results, even if the performance hit is significant.

This snippet might be related:
import tensorflow as tf
import numpy as np
data = np.random.rand(int(1e4), int(1e4)) + np.random.rand(int(1e4), 1)
data = data.astype('float32')
vec = tf.placeholder(tf.float32, data.shape)
s = tf.reduce_sum(vec)
with tf.Session(config=tf.ConfigProto(intra_op_parallelism_threads=1)) as sess:
    np_sum = np.sum(data)
    tf_sum = sess.run(s, feed_dict={vec: data})
    diff = abs(tf_sum - np_sum)
    print(diff, diff/1e8)   # difference can be as large as 200656, when running with CPU.

data = data.astype('float64')
vec = tf.placeholder(tf.float64, data.shape)
s = tf.reduce_sum(vec)
with tf.Session(config=tf.ConfigProto(intra_op_parallelism_threads=1)) as sess:
    np_sum = np.sum(data)
    tf_sum = sess.run(s, feed_dict={vec: data})
    diff = abs(tf_sum - np_sum)
    print(diff, diff/1e8)

Please remove the assignee, as this issue is inviting external contributions. Otherwise, remove the contributions welcome label. Thank you.

Please remove the assignee, as this issue is inviting external contributions. Otherwise, remove the contributions welcome label. Thank you.

Please remove the assignee, as this issue is inviting external contributions. Otherwise, remove the contributions welcome label. Thank you.

Please remove the assignee, as this issue is inviting external contributions. Otherwise, remove the contributions welcome label. Thank you.

Please remove the assignee, as this issue is inviting external contributions. Otherwise, remove the contributions welcome label. Thank you.

Please remove the assignee, as this issue is inviting external contributions. Otherwise, remove the contributions welcome label. Thank you.

Please remove the assignee, as this issue is inviting external contributions. Otherwise, remove the contributions welcome label. Thank you.

Please remove the assignee, as this issue is inviting external contributions. Otherwise, remove the contributions welcome label. Thank you.

Please remove the assignee, as this issue is inviting external contributions. Otherwise, remove the contributions welcome label. Thank you.

Please remove the assignee, as this issue is inviting external contributions. Otherwise, remove the contributions welcome label. Thank you.

Please remove the assignee, as this issue is inviting external contributions. Otherwise, remove the contributions welcome label. Thank you.

unassign

Would it be sufficient to su recursively across the dimensions of a Tensor?
This would reduce the problem from being O(size) to O(size of largest dimension), which might just be enough for most use-cases, and should be a lot easier to implement than compensated summation.

@tensorflow/dev-support Can you remove the contribution welcome label and retriage this?
I think we don't have a clear enough contribution path to label this as contribution welcome so we need to re-triage it.
This ticket is very old but recently we had another related bug at https://github.com/tensorflow/tensorflow/issues/58133

Eigen already does tree reduction (similar to pairwise summation) on CPU for floating-point types (https://gitlab.com/libeigen/eigen/-/blob/master/unsupported/Eigen/CXX11/src/Tensor/TensorReduction.h#L240).
On GPU, it ends up being (mostly) pairwise: https://gitlab.com/libeigen/eigen/-/blob/master/unsupported/Eigen/CXX11/src/Tensor/TensorReductionGpu.h#L541
We do not currently do kahan summation in addition to tree reduction.  Adding it to TensorFlow would involve implementing it in Eigen for CPU/GPU (potentially with vectorization).  Someone can raise a feature request over there: https://gitlab.com/libeigen/eigen/-/issues/new

Hi,
Kindly refer to the comment above.
Thank you for opening this issue. Since this issue has been open for a long time, the code/debug information for this issue may not be relevant with the current state of the code base.
The Tensorflow team is constantly improving the framework by fixing bugs and adding new features. We suggest you try the latest TensorFlow version with the latest compatible hardware configuration which could potentially resolve the issue. If you are still facing the issue, please create a new GitHub issue with your latest findings, with all the debugging information which could help us investigate.
Please follow the release notes to stay up to date with the latest developments which are happening in the Tensorflow space.
Thank you!


Empty filter highlighted as an error

I use this addon to add fields to card templates.
The issue is the added fields are basically empty filters, e.g. {{info-Type:}}, so the editor always throws the "Missing field name" error.
While I have added the needed fields into "Custom Filter Names" and even tried to disable the "Invalid Field Diagnostics" and "Invalid Filter Diagnostics" options in the VSCode extension settings, it doesn't seem to make the problem go away.
It isn't a big issue, but still, when valid parts of the code are always highlighted red it makes spotting actual mistakes significantly harder. It would be nice to see an option added for ignoring empty filter fields.

Hi, thanks for raising this issue. I hadn't considered that add-ons could add a filter that wouldn't require a field.
I've updated the setting for custom filters so you can now enter custom filters as both strings and objects. When defining it as an object, you can specify if a field is required when the filter is used in a replacement.
For example:
"anki-editor.customFilterNames": [
        "custom-filter1",
        {
            "name": "custom-filter2",
            "fieldRequired": false
        }
    ]

I've also added a setting to disable the missing field error entirely.
These changes are available in version 1.0.3, which has been published to the VSCode Marketplace.
I hope this solves your issue.

Works great!
Thank you for the quick fix


Remove setParitionerClass call from SortableBytes

Callers override the partitioner class themselves. So we should remove setting of the partitioner class from the method in SortableBytes class.
The two cases where this method is used and the callers are then overwriting the values are:
DetermineParitionJobs#run() dimSelectionJob.setPartitionerClass(DeterminePartitionsDimSelectionPartitioner.class);
and
IndexGeneratorJor#run() job.setPartitionerClass(IndexGeneratorPartitioner.class);
@jihoonson @gianm - could you guys please review when you get a chance. Thanks!

@samarthjain is this change going to have a user-visible effect or is this just code cleanup?
How about organizing it such that the Job passes in a Partitioner class to the useSortableBytesAsMapOutputKey function? That way, we still know that the partitioner is being set properly.

@gianm - this is more of a code cleanup and there shouldn't be any user facing change. It was something I discovered when I was trying to understand how the batch hadoop indexing for druid works.
It would be good to get your eyes on the code though to confirm that what jobs were doing all this while was correct i.e. they should have been using their own partitioners and not the SortableBytesPartitioner class.
Updated the pull request with your suggested change.