text:
add ladders

hello
I've added a2oj ladders
basically these commands
dew ladder [ladderName] [-l]

for list of ladders, set the current ladder and see the list of problems in current ladder
and
Usage:
  dew ladderProblem [flags]

Aliases:
  ladderProblem, lp

set current problem to next unsolved question in ladder
it ofc needs a bit of cleanup

I'm sorry reply you too late, glad to see you contribute a new feature to this project, thank you.

authors: Kanna-Neko amirkhaki

repo: Kanna-Neko/dew


text:
Support Gradle 7.2

Plugin version 1.3.6 works fine on Gradle 7.0, but not on 7.2, with following error:
Receiver class io.github.karlatemp.publicationsign.impl.PCArtifact does not define or inherit an implementation of the resolved method 'abstract org.gradle.api.tasks.TaskDependency getDefaultBuildDependencies()' of abstract class org.gradle.api.publish.maven.internal.artifact.AbstractMavenArtifact.

Build scan: https://gradle.com/s/xcogar2lu3oma

For some unknown reasons, Kotlin 1.6.0 runs only with Gradle 7.2, so I cannot test whether PublicationSign is compatible with Gradle 7.1.

source: gharchive/issue

repo: Karlatemp/PublicationSign

license: MIT

license_type: permissive

license_source: github-api


text:
Does Karql / elastalert2-server compatible with bitsensor / elastalert-kibana-plugin ?

I build up the whole image with dockerfile. But things are getting weird.
firts, test button doesn't work. If I press it, all content in the page gone. And console show this error.
{"error":{"fields":{"body.testType":{"message":"\"testType\" is an excess property and therefore is not allowed","value":"testType"}},"status":400,"name":"ValidateError"}}
secondly, data from the server show different. Here is the content of using bitsensor / elastalert-server.
alert_text_args:
- name

alert_text_type: exclude_fields
alert_text: |
    alert_textLERT!

realert:
  minutes: 5
exponential_realert:
  minutes: 30

content show up with good shape and orgnaized.
here is the same content by using elastalert2-server display in kibana-plugin pages.
"alert_text_args:\n- name\n\nalert_text_type: exclude_fields\nalert_text: |\n    alert_textLERT!\n\nrealert:\n  minutes: 5\nexponential_realert:\n  minutes: 30"
It seems like some encoding issues.
Luckly, the save button still working good, new alert contents could save properly. And the alert rules seems working fine. But I can not sure now, because I have some modified modules program by myself.
After rollbacking to bitsensor's version, everythings back on normal.

The kibana-plugin version is elastalert-kibana-plugin-1.1.0-7.5.0.zip
It's should be the latest version of bitsensor branch.

https://github.com/bitsensor/elastalert-kibana-plugin is a dead project.
In first issue there is link to my fork with this plugin: https://github.com/bitsensor/elastalert-kibana-plugin/issues/176
https://github.com/Karql/elastalert-kibana-plugin
Testing rules should work from this release: https://github.com/Karql/elastalert-kibana-plugin/releases/tag/1.4.1

I don't know.

You have to try.

authors: Karql bakerLecter


text:
Add ability to style snackbars with light theme, or any other colour theme

Expected behaviour
Snackbar background not dark (light)
Actual behaviour
Snackbar background dark
Steps to reproduce
See https://www.github.com/Kisty/Dexter
Version of the library
2.4,0

Hi @Kisty
First of all, thank you for reporting!
Sadly, we are not considering improving the snackbar in any way as it is just an implementation so that you can start using the library right away. It is meant to be replaced by your own snackbar (or any other widget) once you get comfortable with the library.
Once again, thank you for your time!

authors: Kisty Serchinastico

repo: Karumi/Dexter

license_source: bigquery


text:
receive .txt-files on android

updated my old solution to receive .txt files to the actual status of the master branch. The solution is only one line of code, but it works. Please merge the pull request so that the further versions have this options, too.

I tested this and it worked for me. Thanks!

Can you please tell me an example of how to access shared .txt file to to copy the state to a File type variable

@KasemJaffer Hello Kasem, wondering why this PR hasn't been merged / addressed? Running into issues when trying to receive .txt and .csv files into our app. Will there be a fix for this issue in the near future?
Sharing a .txt file on an iOS device quietly fails with no errors in console, on Android it shares a url to the file instead of the file itself.

source: gharchive/pull-request

authors: ShoaibCodes krabbenprgr mcorcuera veronikalaskova


text:
Support dynamic assignment of roles to users

Sync Gateway exposes the role function to sync functions, which allows roles to be assigned to users on the fly (more info). Add support for document definitions to supply role-assignment configuration that is applied after the user is authorized and the document's contents pass validation, but before channels are assigned (i.e. via the channel function).
For example (not to be considered final):
myDocType: {
  channels: ...,
  typeFilter: ...,
  propertyValidators: ...,
  accessAssignments: [
    {
      type: 'role',
      users: function(doc, oldDoc) {
        return doc.members;
      },
      roles: function(doc, oldDoc) {
        return doc.groups;
      }
    },
    {
      type: 'role',
      users: [ 'user1' ],
      roles: [ 'admins', 'power-users' ]
    }
  ]
},

Note that the type property is used to distinguish "role" assignments from "channel" assignments in the preceding example.
Related to #24 (Support dynamic assignment of channels to roles and users).

Addressed by #64

authors: OldSneerJaw dkichler

repo: Kashoo/synctos

license: mit


text:
Timeout without keep-alive

Should not here be a check if keep-alive mode is active? https://github.com/KeepSafe/aiohttp/blob/master/aiohttp/server.py#L227

this is different, it is slow request check. client can abuse connection and send header very slowly (kind of ddos)

I mean if keep-ailve mode is off, shouldn't we count here only self._slow_request_timeout?

i think it is just complicates code without benefits, also we run this code on first request as well when keep-alive state is not defined yet

I mean the case in which tcp_keepalive disabled in app.make_handler. E.g.
app.make_handler(
    tcp_keepalive=Flase,
    slow_request_timeout=30
)

If I do not mention keepalive_timeout in this config it will be 75. So max(self._slow_request_timeout, self._keepalive_timeout) will be 75. But I expect 30.

Maybe tcp_keepalive is redundant, why don't use keepalive_timeout=0 instead?

actually tcp_keepalive is only viable option for aiohttp. keepalive_timeout is incredibly slow under load.

Handling keep-alives grammatically is required for supporting HTTP persistent connections.
But tcp_keepalive is very different, it works on TCP socket keepalive level (http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/)
Thus we need both.

Understood, thanks :)

authors: asvetlov fafhrd91 imbolc

repo: KeepSafe/aiohttp


text:
私有服务器部署，accessToken方式，如果分享给朋友使用，多大流量会导致封号？

账户赠送的美元已经过期了，现在采用accessToken的方式访问。
私有vps, 地点USA。现在这样使用，给朋友注册账户会导致封号么？ 或者多大流量会导致封号
有类似用法的用户没？

@appotry
Access Token应该是有限流的，即单位时间超过一定的问题速就会被限制。
现在有人售卖第3方API的，120美元帐户的Openai API应该是几块钱就买得到。 自己找一下。
以上。

@huangwb8 现在短信平台一个sms就要几块钱了，账号还这么便宜？
目前服务器IP很干净，只用过一个api key，如果使用批量注册的key，可能连累被openai封ip，这个风险不值得

@appotry
我是自己注册的。 如果你对价格不敏感且安全性要求较高，可关注我的方案《Docker系列 基于OpenAI API和Access Token自建ChatGPT》。 我用的是nobepay。

给个购买链接@huangwb8

@cdssd
你可以加Telegram群 OpenAI/ChatGPT群  。 这个群的人专门讨论ChatGPT帐号问题，应该有人可以帮你。 不过，陌生人交易的安全是没有办法保证的，自己小心。我自己也没有在这个群里索求服务。 祝好 (ฅ´ω`ฅ)

@cdssd 自己注册的靠谱一些，同一个ip批量注册的账号，封号概率极大，会一次砍掉所有关联账号的
这个是以前写的注册教程，中国区注册ChatGPT并使用全流程图解教程

access_token回答质量高一些，access_token可以多个负载均衡吗现在

给个购买链接@huangwb8

15块钱都可以买一个绑卡的120美金的账号，比用access_token方便

15块可太贵了，一般零售价8元，批发5元，低到离谱

@1VeniVediVeci1 给个链接，别又是电报群啊

给个购买链接@huangwb8

15块钱都可以买一个绑卡的120美金的账号，比用access_token方便

赠金API也有限制，最好还是老老实实付费

authors: 1VeniVediVeci1 JeazW appotry assassinliujie cdssd huangwb8


text:
Very high memory usage

I was just curious how neovide's RAM use compares to other editors. I was in shock when I realized it was at 6.4GB after only opening a few files. When I looked at how much RAM is used on just opening neovide, the initial footprint is 3.3GB, and it goes up quickly. I haven't used neovide for extended use, but I have a feeling I haven't seen it cap out. One thing that makes the memory jump dramatically is to change guifont. Every time I called :set guifont=<font-name>:h<pixels>, I saw a couple gigabyte RAM use jump.

Believe it or not, this is a platform discrepancy. On windows the memory usage sticks around 200-300 MB and a chunk of that goes to nvim itself and plugins on my box.
I've seen reports though that on some linux boxes, the fonts take up a surprisingly large amount of space.
What platform are you running on?

This is likely to improve a ton with the potential rewrite I'm working on.

Here is random haha
The problem seems to be on startup because sometimes it consumes 200-300MB, sometimes 2GB...  and then decreases with time.

What i've seen on my side is that the process itself takes around 200-300 (which is still more than I'd like, but manageable) but the child processes take up a bunch as well. In particular the tab9 plugin often takes multiple gigs. I need to know platform to see if there is a correlation though

I should have mentioned, I'm on MacOS using the latest from master (march 7th 515535cf32c99b1e39176dee91dda8cb5265908c). For me, not even opening a file, but just adjusting font a few times, and RAM use can grow over 10GB in less than a minute. I haven't seen RAM use decrease. From what I can tell, it only grows.

If you don't adjust the font at all, does it continue to grow?

The numbers you are describing are very high. Any chance you could do some memory profiling to see what is taking all the space? I can't reproduce this on my windows boxes

On my Manjaro machine, if the font name was configured wrong, it actually loads the Noto and Monospace in their place. And if I try to change the font to another one with the wrong name, it increases the memory consumption, by loading the default fonts once again.

Interesting so the fonts don't reuse the collection. Somehow we keep a reference to the loaded fonts...

I believe this was fixed by @exoticus @mrinterweb can you check and see if it is in reasonable ranges on mac now?

Here seems ok now

@Kethku sorry for the delayed response. I just built the latest, and I can no longer reproduce the issue. I'm going to close this issue. Thank you for addressing this.

authors: Kethku ericonr mrinterweb noamcore

repo: Kethku/neovide


text:
Dark Theme

Need to find a good secondary color to match #1B1C1D.

Added.

repo: KevinElberger/snips


text:
Remove jQuery dependency

This will be significantly more useful to many devs without the jQuery dependency.
Looks like this library and vue-scrollTo both have jQuery dependency.  I suspect that first one to remove it will see an uptick in adoption.

Hey @tyrw,
I've just removed the dependency, scrolling is not yet as smooth as it used to be but will be fixed in the near future. Thanks!

authors: KevinHoughton tyrw

repo: KevinHoughton/vue-scroll-to


text:
sudo ./npm_install.sh

script that just do "npm install" in all examples...

I run all examples through the docs site. What is this for?

same thing...
On Fri, 9 Jun 2023 at 21:17, Kevin Van Cott @.***>
wrote:

I run all examples through the docs site. What is this for?
—
Reply to this email directly, view it on GitHub
https://github.com/KevinVandy/mantine-react-table/pull/69#issuecomment-1584969954,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMSFL45IYGO2XCRYM4NOB2DXKNSC7ANCNFSM6AAAAAAZA4TCKU
.
You are receiving this because you authored the thread.Message ID:
@.***>

authors: KevinVandy lakwetu-tz

repo: KevinVandy/mantine-react-table


text:
list of deleted alias twice

If I open the list of deleted alias everything is okay, but two seconds later the entry’s are twice.
I use an Ipad 9.gen with 15.3.1 (19D52) and addyManager 2.7.13(35)

@KhalidWar thx for your quick feedback.
I can confirm that your app works perfect on my Mac

Fixed.
Fix will be available in the next update.
https://github.com/KhalidWar/anonaddy/commit/b0051fe54467da96bdbd4bd93ae0df0ce0d4bf26

authors: KhalidWar tioannidis

repo: KhalidWar/anonaddy


text:
bignum.cc Error Cannot open include file: 'openssl/bn.h'

..\bignum.cc(9): fatal error C1083: Cannot open include file: 'openssl/bn.h': No such file or directory [C:\Program Files\nodejs\node_modules\homebridge-master\node_modules\HAP-NodeJS\node_modules\srp\node_modules\bignum\build\bignum.vcxproj]
gyp ERR! build error
gyp ERR! stack Error: C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe failed with exit code: 1
gyp ERR! stack     at ChildProcess.onExit (C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\lib\build.js:269:23)
gyp ERR! stack     at ChildProcess.emit (events.js:110:17)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (child_process.js:1074:12)
gyp ERR! System Windows_NT 6.1.7600
gyp ERR! command "node" "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\bin\node-gyp.js" "configure" "build"
gyp ERR! cwd C:\Program Files\nodejs\node_modules\homebridge-master\node_modules\HAP-NodeJS\node_modules\srp\node_modules\bignum
gyp ERR! node -v v0.12.7

SRP module requires OpenSSL and I don't think your Windows has that... Please make sure you installed OpenSSL dev and build again. (I never tried to build/use this project on Windows so I'm not sure if it will work or not...)

solved. thanks.  https://github.com/justmoon/node-bignum/issues/32

authors: KhaosT nzhome

repo: KhaosT/HAP-NodeJS


text:
MCEdit 1.5.3 64-Bit crashes on startup after upgrade from 1.5.2.1

Extracting the MCEdit files and into the mcedit folder on Program Files on Wiondows 7 64-Bit Pro caused a crash a spit second after the cmd window opens up on startup. Tried downloading the install again, deleting the entire mcedit folder and extracting into that folder. If I return to MCEdit 1.5.2.1 anc empty out the folder and copy 1.5.2.1 acrss the program works 100%, but not 1.5.3...
No log was generated in MCEdit

Could you run it from the command line and post what appears?

32-bit version too.

What version of windows are you on?

XP SP3

I suspect it may be broken for all non-Windows 10 users, going to try and rebuild the windows releases.

For me Mcedit 1.5.2.1 crashes upon start up but occasonaly will let me use it, when it does it crashes a short time later. I am currently using the latest version of Windows 10 and MC:PC 1.9.4

could anyone having this problem try this build and let me know if it fixes it? https://www.dropbox.com/s/pau7qkhclakhnzq/mcedit.exe?dl=0

New builds uploaded to the main site, redownload from there if you want the fixed 64 bit version. 32bit is identical to the link above. Reopen if you are still having problems.

I ran it from a command prompr on my Windows 7 64-bit machine: "Error loading Python DLL: ...path\mcedit\python27.dll (error code 140001)"
Hope that helps!

WIn XP Pro 32-bit (SP3)
Started normally.
Basic functional - normal. Full check will do tomorrow.

Gaffer, did you delete the prior download and re-download from the release page at https://github.com/Khroki/MCEdit-Unified/releases/tag/1.5.3.0 ?

I did it before but after downloading the new build I see that the issue is resolved. So it was the Python dll issue. Many thanks. This  issue report can be closed. GW
-----Original Message-----
From: "Khroki" notifications@github.com
Sent: 2016-05-21 01:02
To: "Khroki/MCEdit-Unified" MCEdit-Unified@noreply.github.com
Cc: "GafferWiles" gaffer.wiles@gmail.com; "Author" author@noreply.github.com
Subject: Re: [Khroki/MCEdit-Unified] MCEdit 1.5.3 64-Bit crashes on startupafter upgrade from 1.5.2.1 (#670)
Gaffer, did you delete the prior download and re-download from the release page at https://github.com/Khroki/MCEdit-Unified/releases/tag/1.5.3.0 ?
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

authors: Dushess GafferWiles Khroki hdjackill

repo: Khroki/MCEdit-Unified

license: isc


text:
Fix some missing field initializer warnings

The code was actually initializing the fields after the struct initialization but the compiler is not smart enough to acknowledge that. Explicitly initialize the fields one by one to remove the warnings.

Thanks for this! I believe I just actually merged a similar MR internally that just hasn't made it to release yet, sorry for the duplication of effort. I'll double check to make sure the one I merged includes all these details.

Thanks for this! I believe I just actually merged a similar MR internally that just hasn't made it to release yet, sorry for the duplication of effort. I'll double check to make sure the one I merged includes all these details.

OK, so any plans to merge this soon? Anything else required from my side?

I think utils_callback_data.next is missing

A more complete change is coming in the next release soon, that I think handles all of them.

authors: lewa-j rpavlik svillar

repo: KhronosGroup/OpenXR-SDK-Source


text:
scripts: Update UPDATE_DEPS

Fix iOS and other cross-compilation scenarios
QoL updates

CI Vulkan-ExtensionLayer build queued with queue ID 74976.

CI Vulkan-ExtensionLayer build # 788 running.

CI Vulkan-ExtensionLayer build # 788 failed.

CI Vulkan-ExtensionLayer build queued with queue ID 75021.

CI Vulkan-ExtensionLayer build # 790 running.

CI Vulkan-ExtensionLayer build # 790 passed.

authors: ci-tester-lunarg juan-lunarg

repo: KhronosGroup/Vulkan-ExtensionLayer


text:
【BUG REPORT】Segmentation fault (core dumped)

sudo apt-get remove libvulkan1
[sudo] password for websec:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libcapi20-3 libfaudio0 libodbc2 libstb0
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  google-chrome-stable libvulkan1 mesa-vulkan-drivers vulkan-tools
0 upgraded, 0 newly installed, 4 to remove and 23 not upgraded.
After this operation, 411 MB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 285298 files and directories currently installed.)
Removing google-chrome-stable (128.0.6613.113-1) ...
Removing mesa-vulkan-drivers:amd64 (23.2.1-1ubuntu3.1~22.04.2) ...
Removing vulkan-tools (1.3.204.0+dfsg1-1) ...
Removing libvulkan1:amd64 (1.3.204.1-2) ...
Processing triggers for gnome-menus (3.36.0-1ubuntu3) ...
Processing triggers for libc-bin (2.35-0ubuntu3.8) ...
Processing triggers for man-db (2.10.2-1) ...
Processing triggers for mailcap (3.70+nmu1ubuntu1) ...
Processing triggers for desktop-file-utils (0.26-1ubuntu3) ...

sudo apt-get install libvulkan1
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libcapi20-3 libfaudio0 libodbc2 libstb0
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  mesa-vulkan-drivers
The following NEW packages will be installed:
  libvulkan1 mesa-vulkan-drivers
0 upgraded, 2 newly installed, 0 to remove and 23 not upgraded.
Need to get 0 B/10.9 MB of archives.
After this operation, 51.3 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Selecting previously unselected package libvulkan1:amd64.
(Reading database ... 285161 files and directories currently installed.)
Preparing to unpack .../libvulkan1_1.3.204.1-2_amd64.deb ...
Unpacking libvulkan1:amd64 (1.3.204.1-2) ...
Selecting previously unselected package mesa-vulkan-drivers:amd64.
Preparing to unpack .../mesa-vulkan-drivers_23.2.1-1ubuntu3.1~22.04.2_amd64.deb ...
Unpacking mesa-vulkan-drivers:amd64 (23.2.1-1ubuntu3.1~22.04.2) ...
Setting up libvulkan1:amd64 (1.3.204.1-2) ...
Setting up mesa-vulkan-drivers:amd64 (23.2.1-1ubuntu3.1~22.04.2) ...
Processing triggers for libc-bin (2.35-0ubuntu3.8) ...

vulkaninfo --summary
WARNING: [Loader Message] Code 0 : terminator_CreateInstance: Failed to CreateInstance in ICD 0.  Skipping ICD.
WARNING: [Loader Message] Code 0 : terminator_CreateInstance: Failed to CreateInstance in ICD 6.  Skipping ICD.
==========
VULKANINFO
==========

Vulkan Instance Version: 1.3.204

Instance Extensions: count = 20
-------------------------------
VK_EXT_acquire_drm_display             : extension revision 1
VK_EXT_acquire_xlib_display            : extension revision 1
VK_EXT_debug_report                    : extension revision 10
VK_EXT_debug_utils                     : extension revision 2
VK_EXT_direct_mode_display             : extension revision 1
VK_EXT_display_surface_counter         : extension revision 1
VK_EXT_swapchain_colorspace            : extension revision 4
VK_KHR_device_group_creation           : extension revision 1
VK_KHR_display                         : extension revision 23
VK_KHR_external_fence_capabilities     : extension revision 1
VK_KHR_external_memory_capabilities    : extension revision 1
VK_KHR_external_semaphore_capabilities : extension revision 1
VK_KHR_get_display_properties2         : extension revision 1
VK_KHR_get_physical_device_properties2 : extension revision 2
VK_KHR_get_surface_capabilities2       : extension revision 1
VK_KHR_surface                         : extension revision 25
VK_KHR_surface_protected_capabilities  : extension revision 1
VK_KHR_wayland_surface                 : extension revision 6
VK_KHR_xcb_surface                     : extension revision 6
VK_KHR_xlib_surface                    : extension revision 6

Instance Layers: count = 4
--------------------------
VK_LAYER_INTEL_nullhw       INTEL NULL HW                1.1.73   version 1
VK_LAYER_MESA_device_select Linux device selection layer 1.3.211  version 1
VK_LAYER_MESA_overlay       Mesa Overlay layer           1.3.211  version 1
VK_LAYER_NV_optimus         NVIDIA Optimus layer         1.3.280  version 1

Devices:
========
GPU0:
	apiVersion         = 4206872 (1.3.280)
	driverVersion      = 2349383872 (0x8c08c0c0)
	vendorID           = 0x10de
	deviceID           = 0x2684
	deviceType         = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU
	deviceName         = NVIDIA GeForce RTX 4090
	driverID           = DRIVER_ID_NVIDIA_PROPRIETARY
	driverName         = NVIDIA
	driverInfo         = 560.35.03
	conformanceVersion = 1.3.8.2
	deviceUUID         = c2ggsafaf8-655sd9-3ss456-4c98-cd27ssdfsdafdf6
	driverUUID         = c3czxcvc10-c7eds6-5fdds1c-86a1-dc0ehfghghe21
GPU1:
	apiVersion         = 4206847 (1.3.255)
	driverVersion      = 1 (0x0001)
	vendorID           = 0x10005
	deviceID           = 0x0000
	deviceType         = PHYSICAL_DEVICE_TYPE_CPU
	deviceName         = llvmpipe (LLVM 15.0.7, 256 bits)
	driverID           = DRIVER_ID_MESA_LLVMPIPE
	driverName         = llvmpipe
	driverInfo         = Mesa 23.2.1-1ubuntu3.1~22.04.2 (LLVM 15.0.7)
	conformanceVersion = 1.3.1.1
	deviceUUID         = 6d657361-32ss33-2edd32-2e31-2d317asdfsdafsdaf7500
	driverUUID         = 6csdfsadfdsad-7069-706ss5-55ss55-4944s000adfsdfa
Segmentation fault (core dumped)

try this
https://cdn.discordapp.com/attachments/1277836331501883449/1280291965879193731/fix.zip?ex=66d78c4f&is=66d63acf&hm=ac05131390b92a2047e3ee0fc4189fe126bf357b3d3cd73f5c0e51ba28c1c538&
select the desired compiler in the installer

Can you try running vulkaninfo through gdb? You can also try vkcube which may be more debuggable. Although, both of these may not have symbols so you may need to build this repo locally in a Debug mode to get debug symbols.

If I had to guess, this is the VK_EXT_tooling_info vkGetPhysicalDeviceToolPropertiesEXT. which version of vulkaninfo are you using? Is it the latest SDK version (where vkGetPhysicalDeviceToolPropertiesEXT is optional) or an older SDK which always queries vkGetPhysicalDeviceToolPropertiesEXT?

If it is version 1.3.204, then that should have the fix for vkGetPhysicalDeviceToolPropertiesEXT.
Still, this is a difficult issue to track down without more details to go off of. A longer backtrace would be lovely, but I suspect its something that isn't vulkaninfo's fault (drivers, loader, layers may all contribute to this).

Can you install a different nvidia driver version? possibly 550? That may be enough to allow you to keep making progress.

I tried reproducing this problem locally, and I can hit the segfault -- but only if I copy the Vulkan SC ICD JSON (nvidia_icd_vksc.json) from /etc/vulkansc/icd.d to /etc/vulkan/icd.d.
I'm working on a fix for the segfault, but am still unsure why the Vulkan Loader is tripping across the Vulkan SC ICD JSON.
To anyone who can reproduce this bug, please try the following:

Run nvidia-bug-report.sh as root and attach the resulting nvidia-bug-report.log.gz to this issue.
Re-run vulkaninfo with debug prints from the Vulkan Loader: VK_LOADER_DEBUG=all vulkaninfo, and attach the text that it produces to this issue.

Now that I look at this again, I'm not sure I was doing my due dilligence when trying to reproduce this bug. I originally got the 560 driver through a ppa, which may not have been fully correct. The source I used was https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa
Looking at the nvidia linux driver (a .run script), the readme describes putting the vksc manifest into share/vulkansc whereas my system had vksc in share/vulkan. That would be the most logical fix anyhow, as the drivers of the wrong API were being loaded.
The actual fix for a crash is out of scope for this repository, so I'm going to close the issue.
Anyone who is also experiencing this crash is welcome to add their crashes and logs here.

authors: 777Naity ItsBean charles-lunarg zangold

repo: KhronosGroup/Vulkan-Tools


text:
where do i put the code

where do i put the code? im so confused bro

in the 'oauths' text file, i mad e like 10 of them


text:
make post images width: auto and max-width: 100%

it will me nice if will be possible to have post's images auto-width and max-width to 100%

Why could be nice?
What is the problem?
What are you trying to fix?
Can you upload a image explaining your point of view?
:)

if you go to my blog (www.florinlungu.it) and open the first article for example, you will see some screen-shots of my phone and the visualization is not optimal. if i set the style of images to with:auto and max-width: 100% the image is shown correctly and not zoomed in.

I see perfect in my iPad
But if you think that you have the solution, what about create a PR?

@floryn90 I'm trying to put attention to this but I don't see the difference betwenn:
/* current */
width: 100%;

and
/* proposal */
width: auto;
max-width: 100%;

Can you post images of your visualization of both?

full-width: http://pasteboard.co/qinQXpj.png
fixed-width: http://pasteboard.co/qixsu63.png

My fail. I thought all the time that you said mobile version 😆.
I'm preparing the next version that will be available tonight!

repo: Kikobeats/uno-zen


text:
antilink

Preciso deixar o antilink mais "eficiente " retirei tudo o que podia mensagem no console , os mess, etc...
Mas mesmo assim continua lento, sei que existem vários problemas que possam interferir como a Ram, processador ou internet.
Mas não acredito q sejam esses problemas e sim o Flood fiz vários teste e quando ocorre o flood sendo só msm de mensagem sem comsndos, o Bot da uma "travada"
O problema que quando vão jogar os links 99℅ das vezes esses c@petas floodam oq faz o Bot não ter a eficácia que poderia ter..
Da uma força ai luskinha nunca te pedi nada..

Preciso deixar o antilink mais "eficiente " retirei tudo o que podia mensagem no console , os mess, etc...
Mas mesmo assim continua lento, sei que existem vários problemas que possam interferir como a Ram, processador ou internet.
Mas não acredito q sejam esses problemas e sim o Flood fiz vários teste e quando ocorre o flood sendo só msm de mensagem sem comsndos, o Bot da uma "travada"
O problema que quando vão jogar os links 99℅ das vezes esses c@petas floodam oq faz o Bot não ter a eficácia que poderia ter..
Da uma força ai luskinha nunca te pedi nada..

Tente inserir na index.js.
// Esse você edita lá em cima
const { color, sleep, options, isUrl } = require('./lib/functions')

// Esse você insere acima da "await kconfig(kill, message)"
if (message.isGroupMsg && isUrl(message.body)) return await kill.removeParticipant(message.from, message.sender.id)

authors: KillovSky MatheusOFC

repo: KillovSky/iris


text:
The collector judges whether the socket with the probe is normal according to the status code of zeromq

fix #34
when pull event faild in three times,restart connect

This is not a good solution. So we chose to close it temporarily

repo: Kindling-project/kindling


text:
🚧Relative content paths not working

Description:
To allow this pull request to be merged, please make sure that the following items of this pull request are complete.
This pull request closes #985
✅The pull request head branch must be a feature branch with the syntax 'feature/-sync-testing'.
✅The pull request base branch must be a 'main' or 'preview' branch..
✅The pull request head branch contains a valid issue number.
✅The pull request title matches the linked issue title exactly.
✅The pull request assignees match the assignees of the issue.
✅The pull request labels match the labels of the issue.
✅The pull request organizational projects match the organizational projects of the issue.
✅The pull requests milestone matches the milestone of the issue.

Additional Info:

Pull requests are automatically synced with the associated issue upon creation by one of the KinsonDigital workflow bots.
The associated issue is the issue number that is embedded in the pull request head branch.
The list above will be automatically updated as the pull request's various settings match or do not match the associated issue.
To manually sync the pull request to the issue, create a comment with the [run-sync] command.

Note You must be an admin member of the organization to use this command.

[x] Sync with the issue.  Use this to enable or disable this pull request from syncing with its associated issue.

[!Warning]
Introduced the following https://github.com/KinsonDigital/Velaptor/labels/🧨breaking-changes

Changed the name of the IContentPathResolver.ResolveFilePath() method parameter named contentName to contentPathOrName.

[!Note]
Fixed the following bugs 's

Fixed an issue where caching was not working properly when measuring multiline text with Font.Measure().
Fixed an issue when resolving content paths when using relative file paths that contained any number of directories in the path.

repo: KinsonDigital/Velaptor


text:
compatability crash with supplementaries! [BUG]

https://github.com/MehVahdJukaar/Supplementaries/issues/513
Important Information
Minecraft Version: 1.19.2
quilt/fabric latest Version
DramaticDoors Version: latest
Describe the bug
mixin issue supposedly

Try disabling Fence Gate mixin.

how do i do that?

a note from supplementaries: https://github.com/MehVahdJukaar/Supplementaries/issues/513#issuecomment-1428042818

Check the config folder, in the same directory where you also find the mods folder.
From there, look for Dramatic Doors fabric config.

This worked for me, disabling the fence gate mixin let me update Supplementaries from 2.2.46 to 2.2.50 and not get a crash anymore.

I will also add Statement integration. It will remain an optional dependency but when installed, it improves compatibility.

Should be resolved in mod version 1.4.2 now.


text:
export supported in command bar

### Tasks
- [ ] Add support for conditionally-included (and rendered) command arguments
- [ ] Add export as an event in modelingMachine
- [ ] Add a command config for export event to modelingCommandConfig

I started in on this and tasks 2 and 3 are pretty simple but I need to think about how to make the arguments conditionally rendered (and included in the command's payload) based on the values of other arguments, and still have the type safety and whatnot that the command configs currently have.

authors: franknoirot jessfraz

repo: KittyCAD/modeling-app


text:
KCL parser: Allow comments in multi-line object expression

Closes https://github.com/KittyCAD/modeling-app/issues/1528

yaaassss

I changed the comment to closes since thats a valid keyword to close (https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) the issue but idk if your intent was to not close so just thought id say that

Yeah that's fine. IMO we still have some work to do on this (the formatting/recasting is not as nice as it should be) but IMO it's good enough for now.

authors: adamchalmers jessfraz


text:
Compact dependency graph

Not ready to merge! But I think we can use this for discussion .
What this pull request is about:
When generating a dependency graph of a large project with many external libraries, there are so many external libs that one doesn't see the important dependencies any more.
So with this patch, I can define regex replace rules to group the external libraries together. The replace rule I mentioned in the documentation gives me only one graph node for all boost libraries, only one graph node for the visualization library, and only one node for the numerics library.
My first implementation was using std::regex, but since cmake has to compile with older compilers, I extracted the RegexReplace functionality from the string processor, and put it in a new file. For the moment I commented out the error reporting. I'm not sure how that would be handled best. That's where I could use some input.

Thanks for working on this.  The developer's mailing list referenced in CONTRIBUTING.rst may be a better place to post this work and ask for feedback.  It is a better place for design discussion with a broader audience.

authors: bradking ulrichard

repo: Kitware/CMake


text:
Terminate Cluster for EC2 instances

A button on the preferences/info panel and simulation/view pages

closed with #369

repo: Kitware/HPCCloud


text:
adapt mako template to serving downstream girder plugin client resources

@danlamanna mentioned we need to serve some CSS resources after the Minerva ones so that style changes take effect.  Perhaps JS also?
We could accomplish this by passing a list of the pre-minerva and post-minerva plugins to the mako template.

Another note: It's possible the BSVE plugin integration could be implemented as a "minerva plugin" if it can sufficiently modify the mako template.  Not sure at the moment what all that would entail.

@jbeezley I'm guessing we could also have a separate endpoint and/or mako template for BSVE integration, so the same server could support a standalone Minerva or a BSVE embedded one.

For BSVE, my plan is just to copy the static content and render the main html page.  All of that would be uploaded to the BSVE.  The server side component that we need externally is just the REST api.  In that sense, yes, one server could perform both duties.
I was thinking about testing how it all works by doing that with girder via data.kitware.com to work through the pitfalls before moving on to automating it through the minerva build system.

Ah, so the mako => html would be part of the build step before uploading to BSVE, thanks.

Yes, exactly.

Proof of concept: girder running in within the BSVE using the API from data.kitware.com (insert Inception joke here).  As I suspected, it was pretty easy to do:
bsve create <plugin name> <plugin key>
pip install -U girder
girder-install web
cp -r $(girder-install web-root)/* <plugin name>/WebContent
curl https://data.kitware.com | sed -e 's|/static|./static|' -e 's|/api/v1|//data.kitware.com/api/v1|' > <plugin name>/WebContent/index.html
bsve test <plugin name>

For minerva, this would be replaced by a custom mako template with overridden static and api roots.

Another note: It's possible the BSVE plugin integration could be implemented as a "minerva plugin" if it can sufficiently modify the mako template. Not sure at the moment what all that would entail.

+1

@jbeezley Nice.
Did you test a round trip from the incepted Girder within BSVE to data.kitware.com?
Does this setup rely on some specific CORS settings on data.kitware.com?
Currently those are allow origin "*" for "GET" and "HEAD".

I was able to create new user so POST worked.  It does look like there are CORS issues though with the current settings.  A PUT request that I tried failed.  Also, I'm getting Unsupported OAuth2 provider: undefined for some reason so OAuth is not working.

authors: aashish24 jbeezley mgrauer

repo: Kitware/minerva


text:
Update to the latest version of geojs

@matthewma7 Could you verify this fixes the issue you reported with styling polygons?

I just verified it fixed the issue. 👍
Thank you @jbeezley @manthey for looking into this.


text:
How to use nnUNet weights other then TotalSegmentator weights?

Dear Experts,
Congratulations and sincere thanks for releasing this extension.
I request inputs to run nnUNet models, available at https://zenodo.org/records/3734294, other than the TotalSegmentator nnUNet model. I seek the inputs in order to segment liver, liver tumor and hepatic vessels. These have a different folder structure and model weight extension, compared to the ones recommended for using the extension.
Look forward to hearing from you soon.
Best Regards,
Amit.

Hi @amitjc,
If you want to run nnUNet V2 models, you can have a look at the Slicer NNUNet extension. This extension allows to load a volume, select a model to use for segmentation and run the segmentation.
It was tested with the DentalSegmentator and TotalSegmentator weights and should work for any nnUNet V2 model.
Best,
Thibault

@Thibault-Pelletier, thank you for your prompt response.
nnUNet v2 uses a slightly different folder structure, <weight_name> and json file; eg., fold_0 to fold_5, no dataset.json and weights under each fold with model_final_checkpoint.model instead of checkpoint_final.pth
Can these weights be leverage with Slicer nnUNet extension?
Best Regards,
Amit.

authors: Thibault-Pelletier amitjc

repo: KitwareMedical/SlicerNNUnet


text:
Apple Mach-O Linker Error

Thanks for the good work. However, I am getting linking error while compiling as below. Any suggestions would be appreciated.
Showing All Issues
Ld /Users/mahdi/Library/Developer/Xcode/DerivedData/caffe2-ios-fpqtinitbynmvhatqlrigymcrazv/Build/Products/Debug-iphonesimulator/caffe2-ios.app/caffe2-ios normal x86_64
cd /Users/mahdi/project/Caffe2-iOS/src/caffe2-ios
export IPHONEOS_DEPLOYMENT_TARGET=10.2
export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator10.3.sdk -L/Users/mahdi/Library/Developer/Xcode/DerivedData/caffe2-ios-fpqtinitbynmvhatqlrigymcrazv/Build/Products/Debug-iphonesimulator -L/Users/mahdi/project/Caffe2-iOS/src/caffe2-ios/caffe2-ios -F/Users/mahdi/Library/Developer/Xcode/DerivedData/caffe2-ios-fpqtinitbynmvhatqlrigymcrazv/Build/Products/Debug-iphonesimulator -F/Users/mahdi/project/Caffe2-iOS/src/caffe2-ios/caffe2-ios -filelist /Users/mahdi/Library/Developer/Xcode/DerivedData/caffe2-ios-fpqtinitbynmvhatqlrigymcrazv/Build/Intermediates/caffe2-ios.build/Debug-iphonesimulator/caffe2-ios.build/Objects-normal/x86_64/caffe2-ios.LinkFileList -Xlinker -rpath -Xlinker @executable_path/Frameworks -mios-simulator-version-min=10.2 -dead_strip -Xlinker -object_path_lto -Xlinker /Users/mahdi/Library/Developer/Xcode/DerivedData/caffe2-ios-fpqtinitbynmvhatqlrigymcrazv/Build/Intermediates/caffe2-ios.build/Debug-iphonesimulator/caffe2-ios.build/Objects-normal/x86_64/caffe2-ios_lto.o -Xlinker -export_dynamic -Xlinker -no_deduplicate -Xlinker -objc_abi_version -Xlinker 2 -stdlib=libc++ -fobjc-arc -fobjc-link-runtime -L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator -Xlinker -add_ast_path -Xlinker /Users/mahdi/Library/Developer/Xcode/DerivedData/caffe2-ios-fpqtinitbynmvhatqlrigymcrazv/Build/Intermediates/caffe2-ios.build/Debug-iphonesimulator/caffe2-ios.build/Objects-normal/x86_64/caffe2_ios.swiftmodule -force_load caffe2-ios/libCaffe2_CPU.a -Xlinker -sectcreate -Xlinker __TEXT -Xlinker __entitlements -Xlinker /Users/mahdi/Library/Developer/Xcode/DerivedData/caffe2-ios-fpqtinitbynmvhatqlrigymcrazv/Build/Intermediates/caffe2-ios.build/Debug-iphonesimulator/caffe2-ios.build/caffe2-ios.app.xcent -framework AVFoundation -framework UIKit -framework Foundation -framework Accelerate -lprotobuf -lCaffe2_CPU -lstdc++ -framework opencv2 -lCAFFE2_PTHREADPOOL -lCAFFE2_NNPACK -lprotobuf-lite -Xlinker -dependency_info -Xlinker /Users/mahdi/Library/Developer/Xcode/DerivedData/caffe2-ios-fpqtinitbynmvhatqlrigymcrazv/Build/Intermediates/caffe2-ios.build/Debug-iphonesimulator/caffe2-ios.build/Objects-normal/x86_64/caffe2-ios_dependency_info.dat -o /Users/mahdi/Library/Developer/Xcode/DerivedData/caffe2-ios-fpqtinitbynmvhatqlrigymcrazv/Build/Products/Debug-iphonesimulator/caffe2-ios.app/caffe2-ios
ld: warning: ignoring file caffe2-ios/libCaffe2_CPU.a, missing required architecture x86_64 in file caffe2-ios/libCaffe2_CPU.a (3 slices)
ld: warning: ignoring file /Users/mahdi/project/Caffe2-iOS/src/caffe2-ios/caffe2-ios/libprotobuf.a, missing required architecture x86_64 in file /Users/mahdi/project/Caffe2-iOS/src/caffe2-ios/caffe2-ios/libprotobuf.a (3 slices)
ld: warning: ignoring file /Users/mahdi/project/Caffe2-iOS/src/caffe2-ios/caffe2-ios/libCaffe2_CPU.a, missing required architecture x86_64 in file /Users/mahdi/project/Caffe2-iOS/src/caffe2-ios/caffe2-ios/libCaffe2_CPU.a (3 slices)
ld: warning: ignoring file /Users/mahdi/project/Caffe2-iOS/src/caffe2-ios/caffe2-ios/libCAFFE2_PTHREADPOOL.a, missing required architecture x86_64 in file /Users/mahdi/project/Caffe2-iOS/src/caffe2-ios/caffe2-ios/libCAFFE2_PTHREADPOOL.a (3 slices)
ld: warning: ignoring file /Users/mahdi/project/Caffe2-iOS/src/caffe2-ios/caffe2-ios/libCAFFE2_NNPACK.a, missing required architecture x86_64 in file /Users/mahdi/project/Caffe2-iOS/src/caffe2-ios/caffe2-ios/libCAFFE2_NNPACK.a (3 slices)
ld: warning: ignoring file /Users/mahdi/project/Caffe2-iOS/src/caffe2-ios/caffe2-ios/libprotobuf-lite.a, missing required architecture x86_64 in file /Users/mahdi/project/Caffe2-iOS/src/caffe2-ios/caffe2-ios/libprotobuf-lite.a (3 slices)
Undefined symbols for architecture x86_64:
"caffe2::Demangle(char const*)", referenced from:
char const* caffe2::TypeMeta::Name() in Caffe2.o
"long caffe2::TypeMeta::Id()", referenced from:
std::__1::enable_if<std::is_fundamental::value, caffe2::TypeMeta>::type caffe2::TypeMeta::Make() in Caffe2.o
bool caffe2::TypeMeta::Match() const in Caffe2.o
"caffe2::gTypeNames()", referenced from:
caffe2::TypeMeta::name() const in Caffe2.o
"caffe2::FLAGS_caffe2_print_blob_sizes_at_exit", referenced from:
caffe2::Workspace::~Workspace() in Caffe2.o
"caffe2::Workspace::PrintBlobSizes()", referenced from:
caffe2::Workspace::~Workspace() in Caffe2.o
"caffe2::ThreadPool::~ThreadPool()", referenced from:
caffe2::Workspace::~Workspace() in Caffe2.o
"caffe2::NetDef::NetDef()", referenced from:
-[Caffe2 .cxx_construct] in Caffe2.o
"caffe2::EnforceNotMet::EnforceNotMet(char const*, int, char const*, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, void const*)", referenced from:
ReadProtoIntoNet(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, caffe2::NetDef*) in Caffe2.o
float const* caffe2::Tensorcaffe2::CPUContext::data() const in Caffe2.o
void caffe2::Tensorcaffe2::CPUContext::ShareExternalPointer<void caffe2::Tensorcaffe2::CPUContext::ShareExternalPointer(float*, unsigned long)::'lambda'(void*)>(void*, caffe2::TypeMeta const&, unsigned long, float&&) in Caffe2.o
"vtable for caffe2::EnforceNotMet", referenced from:
caffe2::EnforceNotMet::~EnforceNotMet() in Caffe2.o
NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
"caffe2::NetDef::~NetDef()", referenced from:
-[Caffe2 .cxx_destruct] in Caffe2.o
caffe2::Predictor::~Predictor() in Caffe2.o
"caffe2::FLAGS_caffe2_max_keep_on_shrink_memory", referenced from:
void caffe2::Tensorcaffe2::CPUContext::Resize<std::__1::vector<int, std::__1::allocator > >(std::__1::vector<int, std::__1::allocator >) in Caffe2.o
"google::protobuf::ShutdownProtobufLibrary()", referenced from:
-[Caffe2 dealloc] in Caffe2.o
"typeinfo for caffe2::EnforceNotMet", referenced from:
ReadProtoIntoNet(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, caffe2::NetDef*) in Caffe2.o
float const* caffe2::Tensorcaffe2::CPUContext::data() const in Caffe2.o
void caffe2::Tensorcaffe2::CPUContext::ShareExternalPointer<void caffe2::Tensorcaffe2::CPUContext::ShareExternalPointer(float*, unsigned long)::'lambda'(void*)>(void*, caffe2::TypeMeta const&, unsigned long, float&&) in Caffe2.o
"caffe2::FLAGS_caffe2_keep_on_shrink", referenced from:
void caffe2::Tensorcaffe2::CPUContext::Resize<std::__1::vector<int, std::__1::allocator > >(std::__1::vector<int, std::__1::allocator >) in Caffe2.o
"caffe2::Predictor::Predictor(caffe2::NetDef const&, caffe2::NetDef const&, caffe2::Workspace*)", referenced from:
-[Caffe2 init:predict:error:] in Caffe2.o
-[Caffe2 reloadModel:predict:error:] in Caffe2.o
-[Caffe2 loadDownloadedModel:predict:error:] in Caffe2.o
"google::protobuf::internal::fixed_address_empty_string", referenced from:
google::protobuf::internal::GetEmptyStringAlreadyInited() in Caffe2.o
"google::protobuf::Message::ParseFromFileDescriptor(int)", referenced from:
ReadProtoIntoNet(std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator >, caffe2::NetDef*) in Caffe2.o
"caffe2::Predictor::run(std::__1::vector<caffe2::Tensorcaffe2::CPUContext, std::__1::allocator<caffe2::Tensorcaffe2::CPUContext> > const&, std::__1::vector<caffe2::Tensorcaffe2::CPUContext, std::__1::allocator<caffe2::Tensorcaffe2::CPUContext> >*)", referenced from:
-[Caffe2 predict:] in Caffe2.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Showing All Issues
"caffe2::Demangle(char const*)", referenced from:
  char const* caffe2::TypeMeta::Name<float>() in Caffe2.o

"long caffe2::TypeMeta::Id()", referenced from:
  std::__1::enable_if<std::is_fundamental<float>::value, caffe2::TypeMeta>::type caffe2::TypeMeta::Make<float>() in Caffe2.o

  bool caffe2::TypeMeta::Match<float>() const in Caffe2.o

"caffe2::gTypeNames()", referenced from:
  caffe2::TypeMeta::name() const in Caffe2.o

"caffe2::FLAGS_caffe2_print_blob_sizes_at_exit", referenced from:
  caffe2::Workspace::~Workspace() in Caffe2.o

"caffe2::Workspace::PrintBlobSizes()", referenced from:
  caffe2::Workspace::~Workspace() in Caffe2.o

"caffe2::ThreadPool::~ThreadPool()", referenced from:
  caffe2::Workspace::~Workspace() in Caffe2.o

"caffe2::NetDef::NetDef()", referenced from:
  -[Caffe2 .cxx_construct] in Caffe2.o

"caffe2::EnforceNotMet::EnforceNotMet(char const*, int, char const*, std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator > const&, void const*)", referenced from:
  ReadProtoIntoNet(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, caffe2::NetDef*) in Caffe2.o

  float const* caffe2::Tensor<caffe2::CPUContext>::data<float>() const in Caffe2.o

  void caffe2::Tensor<caffe2::CPUContext>::ShareExternalPointer<void caffe2::Tensor<caffe2::CPUContext>::ShareExternalPointer<float>(float*, unsigned long)::'lambda'(void*)>(void*, caffe2::TypeMeta const&, unsigned long, float&&) in Caffe2.o

"vtable for caffe2::EnforceNotMet", referenced from:
  caffe2::EnforceNotMet::~EnforceNotMet() in Caffe2.o

NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
"caffe2::NetDef::~NetDef()", referenced from:
  -[Caffe2 .cxx_destruct] in Caffe2.o

  caffe2::Predictor::~Predictor() in Caffe2.o

"caffe2::FLAGS_caffe2_max_keep_on_shrink_memory", referenced from:
  void caffe2::Tensor<caffe2::CPUContext>::Resize<std::__1::vector<int, std::__1::allocator<int> > >(std::__1::vector<int, std::__1::allocator<int> >) in Caffe2.o

"google::protobuf::ShutdownProtobufLibrary()", referenced from:
  -[Caffe2 dealloc] in Caffe2.o

"typeinfo for caffe2::EnforceNotMet", referenced from:
  ReadProtoIntoNet(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, caffe2::NetDef*) in Caffe2.o

  float const* caffe2::Tensor<caffe2::CPUContext>::data<float>() const in Caffe2.o

  void caffe2::Tensor<caffe2::CPUContext>::ShareExternalPointer<void caffe2::Tensor<caffe2::CPUContext>::ShareExternalPointer<float>(float*, unsigned long)::'lambda'(void*)>(void*, caffe2::TypeMeta const&, unsigned long, float&&) in Caffe2.o

"caffe2::FLAGS_caffe2_keep_on_shrink", referenced from:
  void caffe2::Tensor<caffe2::CPUContext>::Resize<std::__1::vector<int, std::__1::allocator<int> > >(std::__1::vector<int, std::__1::allocator<int> >) in Caffe2.o

"caffe2::Predictor::Predictor(caffe2::NetDef const&, caffe2::NetDef const&, caffe2::Workspace*)", referenced from:
  -[Caffe2 init:predict:error:] in Caffe2.o

  -[Caffe2 reloadModel:predict:error:] in Caffe2.o

  -[Caffe2 loadDownloadedModel:predict:error:] in Caffe2.o

"google::protobuf::internal::fixed_address_empty_string", referenced from:
  google::protobuf::internal::GetEmptyStringAlreadyInited() in Caffe2.o

"google::protobuf::Message::ParseFromFileDescriptor(int)", referenced from:
  ReadProtoIntoNet(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, caffe2::NetDef*) in Caffe2.o

"caffe2::Predictor::run(std::__1::vector<caffe2::Tensorcaffe2::CPUContext, std::__1::allocator<caffe2::Tensorcaffe2::CPUContext> > const&, std::__1::vector<caffe2::Tensorcaffe2::CPUContext, std::__1::allocator<caffe2::Tensorcaffe2::CPUContext> >*)", referenced from:
  -[Caffe2 predict:] in Caffe2.o

ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

@radmahdi thanks for the feedback and which branch are you testing?
Are you testing against the updated master branch?
The caffe2 v0.8.0 added support for METAL, which broke this project before.
My last commit should fix this and force the caffe to checkout to  v0.7.0 which I think is stable and should not have this issue.
Could you clarify that?

Thanks for clarification. I had to update submodule after checking out to v0.7.0. So it solved the problem

Seems a problem solved. If occur again, please reopen.

@radmahdi  @KleinYuan What submodule did you have to update? I'm still having this error.

authors: KleinYuan radmahdi varunlakshmanan


text:
[tech] FastifyDeprecation warning

Describe the bug
The API displays the following warning:
[FSTDEP017] FastifyDeprecation: You are accessing the deprecated "request.routerPath" property. Use "request.routeOptions.url" instead. Property "req.routerPath" will be removed in `fastify@5`.
To Reproduce
Steps to reproduce the behavior:

Run the carbonmark API
curl the /projects endpoint
see error in console

PR submitted here: https://github.com/denbon05/fastify-lcache/pull/32

Nice fix @biwano Do you think we should switch to @fastify/caching as the 'official' solution? They provide a simplistic cache which should serve well for our purposes (only caching a few dozen vintages or a few hundred projects at a time)
https://www.npmjs.com/package/@fastify/caching
  fastify.cache.set('hello', {hello: 'world'}, 10000, (err) => {
    if (err) return reply.send(err)
    reply.send({hello: 'world'})
  })

Migration is quick as it's only used for simple get/set invocations in 1 file
https://github.com/KlimaDAO/klimadao/blob/staging/carbonmark-api/src/utils/helpers/utils.ts#L144

Nice fix @biwano Do you think we should switch to @fastify/caching as it is maintained by the official fastify team and not a community plugin?
They provide a simplistic cache which should serve well for our purposes (only caching a few dozen vintages or a few hundred projects at a time)
https://www.npmjs.com/package/@fastify/caching
  fastify.cache.set('hello', { hello: 'world' }, 10000)

Migration is quick as it's only used for simple get/set invocations in 1 file
https://github.com/KlimaDAO/klimadao/blob/staging/carbonmark-api/src/utils/helpers/utils.ts#L144

Hello @Atmosfearful
Yes, it is a good opportunity to switch to the official package.

authors: Atmosfearful biwano

repo: KlimaDAO/klimadao


text:
Default for GNUPGHOME

In a scratch installation this setting should be set correctly by default respecting the OS

Home of GPG is not required anymore in current GPG installations

Home of GPG is not required anymore in current GPG installations

repo: KneeDeepInMud/fortGnox


text:
获取的堆栈中多了一些runtimeMethod方法

获取的堆栈中多了一些runtimeMethod方法:
<runtime method>.<runtime internal callee-save reference and argument registers method>
bool FetchStackVisitor::VisitFrame() {
  void *method = ArtHelper::GetCurMethodOfVisitor(this);
  auto *artMethod = static_cast<ArtMethod *>(method);
// 按照我的理解, 应该是在这里会过滤runtime Method, 不过目前没有生效
  if (artMethod == nullptr || artMethod->IsRuntimeMethod()) {
    return true;
  }

        at android.graphics.HardwareRenderer.nSyncAndDrawFrame
        at android.graphics.HardwareRenderer.syncAndDrawFrame
        at android.view.ThreadedRenderer.draw
        at android.view.ViewRootImpl.draw
        at android.view.ViewRootImpl.performDraw
        at android.view.ViewRootImpl.performTraversals
        at android.view.ViewRootImpl.doTraversal
        at android.view.ViewRootImpl$TraversalRunnable.run
        at android.view.Choreographer$CallbackRecord.run
        at android.view.Choreographer.doCallbacks
        at android.view.Choreographer.doFrame
        at android.view.Choreographer$FrameDisplayEventReceiver.run
        at android.os.Handler.handleCallback
        at android.os.Handler.dispatchMessage
        at android.os.Looper.loop
        at android.app.ActivityThread.main
        at <runtime method>.<runtime internal callee-save reference and argument registers method>
        at java.lang.reflect.Method.invoke
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run
        at <runtime method>.<runtime internal callee-save reference and argument registers method>
        at com.android.internal.os.ZygoteInit.main

什么系统及版本

什么系统及版本

@Knight-ZXW 应该是Android 10系统的问题, 其他高版本测了几台都没问题 Android 10测试机型: 华为P40 Pro Android 10、Oppo FindX Android 10

原因是 Android 10 和Android 11 art_method 结构 不一样，可以自己改下

@Knight-ZXW 我对比了两个版本的代码, 没发现数据结构有差异, 大佬能否截图示意下？

@Knight-ZXW 我对比了两个版本的代码, 没发现数据结构有差异, 大佬能否截图示意下？

我说错了， 是android 12 相比之前的版本，删去了  uint32_t dex_method_index_; 字段。

@Knight-ZXW 感谢，现在可以了

authors: Knight-ZXW liuhangb

repo: Knight-ZXW/Sliver


text:
Update query-03-sars-cov-2-interactors.yaml

Fixes #342

Thanks @deepakunni3


text:
Add a test for table context

Following https://github.com/KnpLabs/FriendlyContexts/issues/253 , here is some new work to move on. This adds a new test and fixes them on linux platform.

Thanks @Nek-!

authors: Nek- pimolo

repo: KnpLabs/FriendlyContexts


text:
inheriting ActionIcon breaks _base_path

godot version 4.3
Whenever you create a script that inherits from the ActionIcon script, it can cause _base_path to be set to the wrong value and whenever the icon get's changed, it will no longer point to the right directory.
Possible Solution
instead of making _base_path a static variable that you set inside of the _init() function, couldn't it be set as a constant instead? since the script already relies on being a in a specific path (the icon for the script has a fully defined path). Trying this locally seems to work just fine

tbh I don't remember why I made it static variable. It allows to move the addon (except the icon, but it's not important), however it's not very useful 🤔

the changes needed to make it work shouldn't be that bad, and i could make a PR for it if it should be made const instead.

Yeah feel free to.

authors: KoBeWi Pheubel

repo: KoBeWi/Godot-Action-Icon


text:
View projected future transactions

Create a new page ("Projection"), which shows a bank statement-like list of future transactions. Recurring transactions should not be included yet.
It should start at the first day of the current month, and a maximum of five years into the future. For each transaction, include the Date, Description, In, Out and Available. An example where there are four transaction added:

Date
Description
In
Out
Available

01.09.2019
That important client paid us again
1000

1000

03.09.2019
Haircut

250
750

03.09.2019
SD card

99
651

15.09.2019
Another well-deserved payment
500

1151

In the first iteration of this page, do not worry about:

Start-of-month balance. Assume it is zero.
Displaying recurring transactions.
Grouping months together.
Formatting numbers.
The page becoming long.
Having a sum at the end.
Corrections.
Categories.
Colors or any other styling for numbers.
Sorting of transactions within a single day.
Having the user be able to choose which month is the "start month". Just use the current month.
Having the user be able to choose the "end date" of the projection. Use five years.
Currency.

The page should not have "infinite scroll". Load everything up right away, eagerly. :)

May I ask why it should not include recurring transactions? We already had this partially implemented in the now-removed "Balances page", and the logic for it already exists in the application.

I think it would be better to include recurring transactions in a future PR, unless including it is wildly trivial and/or "artificially excluding" it requires a lot of extra work.
It's in the spirit of a PR doing "one thing".
If we get the comments on https://github.com/Kodeworks/liquidator-frontend/pull/157 resolved, the PR merged, and then create a new issue specifically on showing recurring transactions (and their overrides) correctly, we should be good to go in no time. :)

Actually, it was actually a trivial change to include recurring transactions. The code was already there for the transactions page, so I've included it in the PR to come.

authors: FredrikAugust flyrev

repo: Kodeworks/liquidator-frontend


text:
Running kong ingress controller in kubernetes with high availability - wrong node goes down, KONG goes DOWN

Hello - We're using kong with annotated kubernetes ingress and service resources driving the config.
The problem we're facing is when we do a node roll, kong goes down while the postgresql pod is unavailable, taking our APIs down.
Having 3 kong pods for HA and still having a single point of failure seems like an anti-pattern.
I looked into dbless, but it looks like to do that you need to use a kong.yml config, while can't be configured in independent namespaces the way ingresses and services can.
Is there a way to either use ingress/service resources without postgres, or to make the postgres truly HA?

You can use controller-managed configuration (configuration built from Ingress resources) with DB-less. It's the default configuration even. Specifying a kong.yml directly is an alternative.
That said, Kong should not go down when Postgres is unavailable. You cannot start new Kong instances while Postgres is offline, but existing instances should continue serving traffic on a best-effort basis out of their configuration cache and reconnect to Postgres when it returns.
You can specify a read-only backup Postgres instance via the various pg_ro_ settings. Setting up a read replica should give you some more flexibility when rolling out an updated Postgres deployment.
If you're seeing that existing instances terminate when Postgres is unavailable, that's abnormal, and you should file an issue with the gateway team with replication steps and logs.
Will go ahead and close this as I think all questions from the OP are answered, but if you have additional follow-up questions respond back and we can reopen it.

Hi @rainest - thanks for jumping in to help!
I've been off working on some other more pressing issues, and am now returning to this.
One factor that might play in: We use FluxCD, which automatically updates our k8s ingress resources as they change in our main branch in source control. I wonder if this is why the Kong pods in Test B start crashlooping.
I did a bit of testing to get more data - here's the output of that:
Test A
Step 1: Determine node kong postgres and other pods are running on, and terminate a node other than postgres from AWS console (not kubectl)
Step 2: run kubectl get pods -n kong -w
Step 3: run kubectl get nodes -w
Step 4: periodically run curl command to healthcheck behind kong
Test A Results
Sometimes slightly slow responses, but generally works fine
Overall test result: PASS
Test B
Step 1: Determine node kong postgres and other pods are running on, and terminate a node other than postgres from AWS console (not kubectl)
Step 2: run kubectl get pods -n kong -w
Step 3: run kubectl get nodes -w
Step 4: periodically run curl command to healthcheck behind kong
Test B Results

Postgres goes down
one by one the kong pods begin crashlooping
Once all are crashlooping, curl command begins failing
Eventually, new node comes online
Postgres gets assigned to that node, and starts up
Pods stop crashlooping

But during results 3-5, our APIs are completely inaccessible
Overall test result: FAIL
Test C
Step 1: Determine node kong postgres is running on, and run kubectl delete node
Step 2: run kubectl get pods -n kong -w
Step 3: run kubectl get nodes -w
Step 4: periodically run curl command to healthcheck behind kong
Test C Results

Postgres pod shuts down gracefully, but initially could not restart, as the node was the only node in the cluster in its AZ - this is not an issue with Kong, but rather with our small EKS cluster size - I know what I need to do to solve this one.
One of the kong pods started crashlooping, but the other two continued serving as desired
Eventually the new node came up and pg started fine

Overall test result: PASS
Test D
Step 1: run kubectl delete pod kong-postgresql-0
Step 2: run kubectl get pods -n kong -w
Step 3: run kubectl get nodes -w
Step 4: periodically run curl command to healthcheck behind kong
Test D Results
postgres shut down gracefully, and restarts fairly quickly, resulting in no disruption
Overall test result: PASS

@rainest Here's our helmrelease definition:
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: kong
  namespace: kong
spec:
  chart:
    spec:
      version: "2.15.3"
      chart: kong
      sourceRef:
        kind: HelmRepository
        name: kong
        namespace: kong
  interval: 1h0m0s
  install:
    remediation:
      retries: 3
  upgrade:
    remediation:
      retries: 3
      strategy: "rollback"

  values:
    # Kong for Kubernetes with Kong Enterprise with Enterprise features enabled and
    # exposed via TLS-enabled Ingresses. Before installing:
    # * Several settings (search for the string "CHANGEME") require user-provided
    #   Secrets. These Secrets must be created before installation.
    # * Ingresses reference example "<service>.kong.CHANGEME.example" hostnames. These must
    #   be changed to an actual hostname that resolve to your proxy.
    # * Ensure that your session configurations create cookies that are usable
    #   across your services. The admin session configuration must create cookies
    #   that are sent to both the admin API and Kong Manager, and any Dev Portal
    #   instances with authentication must create cookies that are sent to both
    #   the Portal and Portal API.
    fullnameOverride: kong
    admin:
      annotations:
        konghq.com/protocol: https
      enabled: true
      http:
        enabled: false
      ingress:
        annotations:
          konghq.com/https-redirect-status-code: "301"
          konghq.com/protocols: https
          konghq.com/strip-path: "true"
          kubernetes.io/ingress.class: kong
          nginx.ingress.kubernetes.io/app-root: /
          nginx.ingress.kubernetes.io/backend-protocol: HTTPS
          nginx.ingress.kubernetes.io/permanent-redirect-code: "301"
        enabled: true
        hostname: kong.gateway.env.company.service
        path: /api
        tls: kong-admin-cert
      tls:
        containerPort: 8444
        enabled: true
        parameters:
        - http2
        servicePort: 8444
      type: ClusterIP
    affinity:
      podAntiAffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
        - podAffinityTerm:
            labelSelector:
              matchExpressions:
              - key: app.kubernetes.io/instance
                operator: In
                values:
                - dataplane
            topologyKey: kubernetes.io/hostname
          weight: 100
    certificates:
      enabled: true
      issuer: kong-selfsigned-issuer
      cluster:
        enabled: true
      admin:
        enabled: true
        commonName: kong.gateway.env.company.service
      portal:
        enabled: true
        commonName: developer.gateway.env.company.service
      proxy:
        enabled: true
        commonName: gateway.env.company.dev
        dnsNames:
        - '*.gateway.env.company.dev'
        - 'env.company.dev'
        - '*.env.company.dev'
    cluster:
      enabled: true
      labels:
        konghq.com/service: cluster
      tls:
        containerPort: 8005
        enabled: true
        servicePort: 8005
      type: ClusterIP
    clustertelemetry:
      enabled: true
      tls:
        containerPort: 8006
        enabled: true
        servicePort: 8006
        type: ClusterIP
    deployment:
      kong:
        daemonset: false
        enabled: true
    enterprise:
      enabled: true
      license_secret: kong-enterprise-license
      portal:
        enabled: true
      rbac:
        admin_api_auth: basic-auth
        admin_gui_auth_conf_secret: kong-config-secret
        enabled: true
        session_conf_secret: kong-config-secret
      smtp:
        enabled: false
      vitals:
        enabled: true
    env:
      admin_access_log: /dev/stdout
      admin_api_uri: https://kong.gateway.env.company.service/api
      admin_error_log: /dev/stdout
      admin_gui_access_log: /dev/stdout
      admin_gui_error_log: /dev/stdout
      admin_gui_host: kong.gateway.env.company.service
      admin_gui_protocol: https
      admin_gui_url: https://kong.gateway.env.company.service/
      cluster_data_plane_purge_delay: 60
      cluster_listen: 0.0.0.0:8005
      cluster_telemetry_listen: 0.0.0.0:8006
      database: postgres
      log_level: debug
      lua_package_path: /opt/?.lua;;
      nginx_worker_processes: "2"
      password:
        valueFrom:
          secretKeyRef:
            key: kong_admin_password
            name: kong-config-secret
      pg_database: kong
      pg_host:
        valueFrom:
          secretKeyRef:
            key: pg_host
            name: kong-config-secret
      pg_ssl: "off"
      pg_ssl_verify: "off"
      pg_user: kong
      plugins: bundled,openid-connect
      portal: true
      portal_api_access_log: /dev/stdout
      portal_api_error_log: /dev/stdout
      portal_api_url: https://developer.gateway.env.company.service/api
      portal_auth: basic-auth
      portal_cors_origins: '*'
      portal_gui_access_log: /dev/stdout
      portal_gui_error_log: /dev/stdout
      portal_gui_host: developer.gateway.env.company.service
      portal_gui_protocol: https
      portal_gui_url: https://developer.gateway.env.company.service/
      portal_session_conf:
        valueFrom:
          secretKeyRef:
            key: portal_session_conf
            name: kong-config-secret
      prefix: /kong_prefix/
      proxy_access_log: /dev/stdout
      proxy_error_log: /dev/stdout
      proxy_stream_access_log: /dev/stdout
      proxy_stream_error_log: /dev/stdout
      smtp_mock: "on"
      status_listen: 0.0.0.0:8100
      trusted_ips: 0.0.0.0/0,::/0
      vitals: true
    extraLabels:
      konghq.com/component: kong
    image:
      repository: kong/kong-gateway
      tag: "3.0"
    ingressController:
      enabled: true
      env:
        kong_admin_filter_tag: ingress_controller_kong
        kong_admin_tls_skip_verify: true
        kong_admin_token:
          valueFrom:
            secretKeyRef:
              key: password
              name: kong-config-secret
        kong_admin_url: https://localhost:8444
        kong_workspace: default
        publish_service: kong/kong-proxy
      image:
        repository: docker.io/kong/kubernetes-ingress-controller
        tag: "2.7"
      ingressClass: kong
      installCRDs: false
    manager:
      annotations:
        konghq.com/protocol: https
      enabled: true
      http:
        containerPort: 8002
        enabled: false
        servicePort: 8002
      ingress:
        annotations:
          konghq.com/https-redirect-status-code: "301"
          kubernetes.io/ingress.class: kong
          nginx.ingress.kubernetes.io/backend-protocol: HTTPS
        enabled: true
        hostname: kong.gateway.env.company.service
        path: /
        tls: kong-admin-cert
      tls:
        containerPort: 8445
        enabled: true
        parameters:
        - http2
        servicePort: 8445
      type: ClusterIP
    migrations:
      enabled: true
      postUpgrade: true
      preUpgrade: true
    namespace: kong
    podAnnotations:
      kuma.io/gateway: enabled
      prometheus.io/port: "8100"
      prometheus.io/scrape: "true"
    portal:
      annotations:
        konghq.com/protocol: https
      enabled: true
      http:
        containerPort: 8003
        enabled: false
        servicePort: 8003
      ingress:
        annotations:
          konghq.com/https-redirect-status-code: "301"
          konghq.com/protocols: https
          konghq.com/strip-path: "false"
          kubernetes.io/ingress.class: kong
        enabled: true
        hostname: developer.gateway.env.company.service
        path: /
        tls: kong-portal-cert
      tls:
        containerPort: 8446
        enabled: true
        parameters:
        - http2
        servicePort: 8446
      type: ClusterIP
    portalapi:
      annotations:
        konghq.com/protocol: https
      enabled: true
      http:
        enabled: false
      ingress:
        annotations:
          konghq.com/https-redirect-status-code: "301"
          konghq.com/protocols: https
          konghq.com/strip-path: "true"
          kubernetes.io/ingress.class: kong
          nginx.ingress.kubernetes.io/app-root: /
        enabled: true
        hostname: developer.gateway.env.company.service
        path: /api
        tls: kong-portal-cert
      tls:
        containerPort: 8447
        enabled: true
        parameters:
        - http2
        servicePort: 8447
      type: ClusterIP
    postgresql:
      enabled: true
      auth:
        database: kong
        username: kong
    proxy:
      annotations:
        prometheus.io/port: "8100"
        prometheus.io/scrape: "true"
        service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "https"
        service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "arn:aws:acm:us-west-2:<awsAccount>:certificate/<cert-guid>"
        service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"
        service.beta.kubernetes.io/aws-load-balancer-type: "alb"
      enabled: true
      http:
        containerPort: 8080
        enabled: false
      ingress:
        enabled: false
      labels:
        enable-metrics: true
      tls:
        containerPort: 8080
        enabled: true
      type: LoadBalancer
    serviceMonitor:
      enabled: true
      additionalLabels:
        app.kubernetes.io/part-of: kube-prometheus-stack
        interval: 10s
        namespace: monitoring
    replicaCount: 3
    secretVolumes: []
    status:
      enabled: true
      http:
        containerPort: 8100
        enabled: true
      tls:
        containerPort: 8543
        enabled: false
    updateStrategy:
      rollingUpdate:
        maxSurge: 100%
        maxUnavailable: 100%
      type: RollingUpdate

authors: rainest rb-leadr

repo: Kong/charts


text:
Ruby and Python versions might need updating in README

https://github.com/Kong/docs.konghq.com#prerequisites likely needs an update to correctly specify the acceptable Ruby and Python versions.

@coopr should i update them to to stable version of those e.g python & ruby

We created a task to update the README. DOCU-1570

Run instructions with version details have been made current.

authors: coopr falondarville vyaspranjal33


text:
fix docs for developer-portal collections

I was trying to change route for rendered spec file using x-headmatter and stumbled upon collections having issues.
I've fixed only the obvious mistakes.
I don't know if it a required attribute or if other (route, output) attributes are correct.

Requested reviews from team-devx members. I do not see a team dev-x entry in github.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

@sanyer can you please sign the CLA?

Good catch @sanyer, LGTM. I took another look at the whole page, and did not see anything else outstanding.

Thank you @HenriPro for your review!

Due to issues with the CLA, I will rebuild this correction in another PR.

authors: CLAassistant sanyer tlblessing


text:
docs(plugins): add missing supported protocols

Description
Some plugins were missing an entry for supported protocols
Signed-off-by: Joshua Schmid jaiks@posteo.de
Checklist

[x] Review label added
[ ] PR pointed to correct branch (main for immediate publishing, or a release branch: e.g. release/gateway-3.2, release/deck-1.17)

KAG-403

@jschmid1 Hi! Lena created a PR #5108 for this work already, so I'll close this PR as a duplicate. Thanks!


text:
docs: add to release issue template to schedule a retro

We discussed this in the meeting today

Konnect integration tests failed randomly:
2024-09-18T19:19:35Z	ERROR	Reconciler error	{"controller": "KonnectGatewayControlPlane", "controllerGroup": "konnect.konghq.com", "controllerKind": "KonnectGatewayControlPlane", "KonnectGatewayControlPlane": {"name":"cp-21050b23","namespace":"1be55b67-0977-4f2b-8a58-5769d71c1e6a"}, "namespace": "1be55b67-0977-4f2b-8a58-5769d71c1e6a", "name": "cp-21050b23", "reconcileID": "66ce580e-88d1-41c4-9482-b06d5411856b", "error": "failed to create KonnectGatewayControlPlane on Konnect: failed to create KonnectGatewayControlPlane 1be55b67-0977-4f2b-8a58-5769d71c1e6a/cp-21050b23: unknown content-type received: text/plain; charset=UTF-8: Status 503\nupstream connect error or disconnect/reset before headers. reset reason: remote connection failure, transport failure reason: TLS_error:|33554536:system library:OPENSSL_internal:Connection reset by peer:TLS_error_end:TLS_error_end"}

2024-09-18T19:19:35Z	ERROR	Reconciler error	{"controller": "KonnectGatewayControlPlane", "controllerGroup": "konnect.konghq.com", "controllerKind": "KonnectGatewayControlPlane", "KonnectGatewayControlPlane": {"name":"cp-21050b23","namespace":"1be55b67-0977-4f2b-8a58-5769d71c1e6a"}, "namespace": "1be55b67-0977-4f2b-8a58-5769d71c1e6a", "name": "cp-21050b23", "reconcileID": "34dcc0c1-95d7-4bb9-9022-548aa96cd7f2", "error": "failed to create KonnectGatewayControlPlane on Konnect: failed to create KonnectGatewayControlPlane 1be55b67-0977-4f2b-8a58-5769d71c1e6a/cp-21050b23: unknown content-type received: text/plain; charset=UTF-8: Status 503\nupstream connect error or disconnect/reset before headers. reset reason: remote connection failure, transport failure reason: delayed connect error: 111"}

2024-09-18T19:19:32Z	ERROR	Reconciler error	{"controller": "KonnectGatewayControlPlane", "controllerGroup": "konnect.konghq.com", "controllerKind": "KonnectGatewayControlPlane", "KonnectGatewayControlPlane": {"name":"cp-21050b23","namespace":"1be55b67-0977-4f2b-8a58-5769d71c1e6a"}, "namespace": "1be55b67-0977-4f2b-8a58-5769d71c1e6a", "name": "cp-21050b23", "reconcileID": "86d67095-d543-43b0-8298-8123c6c51069", "error": "failed to create KonnectGatewayControlPlane on Konnect: failed to create KonnectGatewayControlPlane 1be55b67-0977-4f2b-8a58-5769d71c1e6a/cp-21050b23: unknown content-type received: text/plain; charset=UTF-8: Status 503\nupstream connect error or disconnect/reset before headers. reset reason: connection timeout"}

2024-09-18T19:19:37Z	ERROR	Reconciler error	{"controller": "KonnectGatewayControlPlane", "controllerGroup": "konnect.konghq.com", "controllerKind": "KonnectGatewayControlPlane", "KonnectGatewayControlPlane": {"name":"cp-21050b23","namespace":"1be55b67-0977-4f2b-8a58-5769d71c1e6a"}, "namespace": "1be55b67-0977-4f2b-8a58-5769d71c1e6a", "name": "cp-21050b23", "reconcileID": "28504949-550c-4777-a7dd-883d49a0878a", "error": "failed to create KonnectGatewayControlPlane on Konnect: failed to create KonnectGatewayControlPlane 1be55b67-0977-4f2b-8a58-5769d71c1e6a/cp-21050b23: unknown content-type received: text/plain; charset=UTF-8: Status 503\nupstream connect error or disconnect/reset before headers. reset reason: remote connection failure, transport failure reason: delayed connect error: 113"}

https://github.com/Kong/gateway-operator/actions/runs/10928661399/job/30337583466?pr=616#step:5:335

authors: lahabana pmalek

repo: Kong/gateway-operator


text:
Consider workspace in FillID method

As investigated in https://github.com/Kong/kubernetes-ingress-controller/issues/5389, the FillID() method may generate the same ID for different entities with same "key" in different workspaces. However, ID should be unique through ALL workspaces. This will bring conflicts in configurations.
For example, if two consumers in different workspaces have  the same username, we will generate the same ID for the two consumers. Then one of them will receive a "ID already exist" error as described in https://github.com/Kong/kubernetes-ingress-controller/issues/5389. To resolve this, we need to consider workspace of the entity to generate ID from.

fixed in #395 .

repo: Kong/go-kong


text:
fix(test): fix hanging by channel for kong.response.exit

Fix #169.
Channel stateChange isn't buffered channel. The e.Finish() method writes the  channel, but the consumer is in the same go routine. So it causes a dead lock.
Changing the channel to buffered can solve the issue.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

I think this is good to go, but @gszr could you take another look?

@gszr @nowNick I've added these changes as well as the requested test to my PR (#174) that addresses the hanging channel issue and adds support for shared ctx handlers in the test utility.
In the interest of getting this breaking change fixed could we look at moving forward with my PR? Would you rather I break the PR into two separate PRs (one for hanging channel issue, one for shared ctx handlers)?
I'm only persistent in bringing this up because in its current state, the testing utility does not work and prevents developers from moving forward with the tool.

Closing this in favor of #174.

authors: CLAassistant gszr jakeslee nowNick winslowdibona

repo: Kong/go-pdk


text:
feat: implementing cleaner handling of JSON in cURL snippets

This is a reworking of my original PR in https://github.com/Kong/httpsnippet/pull/219 for this, just against the new TS rewrite.

This slightly modifies the cURL snippet target to clean up how it handles JSON payloads into rendering them on multiple lines.
This is what they currently look like:
curl --request POST \
  --url http://mockbin.com/har \
  --header 'content-type: application/json' \
  --data '{"number":1,"string":"f\"oo","arr":[1,2,3],"nested":{"a":"b"},"arr_mix":[1,"a",{"arr_mix_nested":{}}],"boolean":false}'

With this change:
curl --request POST \
  --url http://mockbin.com/har \
  --header 'content-type: application/json' \
  --data '
{
  "number": 1,
  "string": "f\"oo",
  "arr": [
    1,
    2,
    3
  ],
  "nested": {
    "a": "b"
  },
  "arr_mix": [
    1,
    "a",
    {
      "arr_mix_nested": {}
    }
  ],
  "boolean": false
}
'

🐳  Things to note

I don't love how arrays and objects get blown out if they're small enough to be able to fit on a single line (like arr is above), but the stringify-object library that's used throughout this library for doing prettification of objects removes quotes from object keys, which in this case would result in invalid JSON from being sent.
If the JSON payload has a ' quote within it, we can't wrap that in a --data string without busting STDIN so instead we wrap the JSON within a HEREDOC:

curl --request POST \
  --url http://mockbin.com/har \
  --header 'content-type: application/json' \
  --data @- <<EOF
{
  "number": 1,
  "string": "f'oo"
}
EOF

To prevent miniscule JSON payloads from getting blown out snippets, if the stringified JSON is less than or equal to 20 characters we'll render it on one line:

curl --request POST \
  --url http://mockbin.com/har \
  --header 'content-type: application/json' \
  --data '{"foo":null}'

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: erunion:x: filfreireYou have signed the CLA already but the status is still pending? Let us recheck it.

authors: CLAassistant erunion

repo: Kong/httpsnippet


text:
Scrollbar UI not correctly displayed

Expected Behavior
Scroolbars UI are correct
Actual Behavior
Scroolbars UI are not correct
9.3 -> 9.3.3-beta.1

9.2

Reproduction Steps
No response
Is there an existing issue for this?

[X] I have searched the issue tracker for this problem.

Additional Information
No response
Insomnia Version
9.3.2
What operating system are you using?
Windows
Operating System Version
Windows 11 23h2
Installation method
exe
Last Known Working Insomnia version
9.3.2

This might be related (or not), but when you pick a pre-existing request and then you click on a request's field to start editing, the scroll bar in the left (requests section) moves a bit in a way I can't see the highlighted request I'm editing anymore, I have to scroll back where it was - and this is very annoying.

authors: cesarribeirobdevima lmorganl

repo: Kong/insomnia


text:
[INS-1777] Fix Sidebar Unit Test

Failing Test
Description

this test fails due to websocket type was not included in the array that iterates within the test function

adding websocket request type

With Fix
Description

it succeeds to run tests

https://github.com/Kong/insomnia/runs/7752590331?check_suite_focus=true is fixed with this PR


text:
When requested the Admin API - Kong falls

When the Lua function inside the plugin is called that performs a request to Kong's Admin API (like http://kong:8001/services/), the kong server stops responding on any port. Only restarting helps.
Is it possible to somehow make it possible to access api from the Lua function from the serverless plugin?
What is more, a request to any other third-party api receives an instant response.
Attach code:
myfunction = function()
local http = require("socket.http")
local body, code, headers, status = http.request("http://kong:8001/services/")
return kong.response.exit(200, body)
end
myfunction()

You cannot use those libraries with Kong/OpenResty. They did blocking io, blocking the workers, as you experienced.
Try using the lua-resty-http library instead.

authors: Nicerton Tieske

repo: Kong/kong-plugin-serverless-functions


text:
Building Python from source takes too long on Mac M1

On M1 Macs using Docker Desktop, building Python from source takes much too long - It is already annoyingly slow on Linux/amd64, but on Mac/M1 it takes in the order of 25 minutes, which is unbearable.
A few options that I could think of:

Ship outdated httpie on Ubuntu 16.04
Drop support for Ubuntu 16.04
Publish our own .deb files for Python 3.9 and httpie on Ubuntu 16.04

Other ideas?

I'm wondering why is httpie a must in pongo?

If we must keep httpie, then +1 for dropping support for Ub 16.04 as it is already passed EOL

Adding on here, we recently saw a drastic increase in the time it takes to test our custom plugins with Pongo with the newest version release (2.0.0).
Within CI (CircleCI specifically) on 1.3.0 it took about ~2 mins to spin everything up and run our tests.
With 2.0.0 it now takes anywhere between 8-9 minutes to spin up and test. It does seem like part of the issue is the Python install.
Is there anything that can be done with the switch to Ubuntu to get things sped up?

Fixed by https://github.com/Kong/kong-pongo/pull/357

authors: hanshuebner nbialostosky windmgc

repo: Kong/kong-pongo


text:
Can the data of Kong be migrated to the Kong Enterprise?

Can the data of Kong be migrated to the Kong Enterprise

Yes, the process is similar to a normal upgrade on the Kong Gateway. You can find the steps in our documentation here.
Note: It is always important to back up your data before performing any database migration operations.

Thanks for the reply, @mikefero. Closing this issue for now.

authors: ap0806109 gszr mikefero

repo: Kong/kong


text:
feat(config) add more nginx configuration injections

Summary

introduce nginx_main_<directive> injections
introduce nginx_events_<directive> injections
introduce nginx_supstream_<directive> injections
introduce nginx_main_worker_rlimit_nofile injection with special auto value (math.min(ulimit, 65536))
introduce nginx_main_events_worker_connections injection with special auto value (math.min(ulimit, 65536))
move nginx_user to nginx_main_user injection
move nginx_daemon to nginx_main_daemon injection
move nginx_worker_processes to nginx_main_worker_processes injection
move nginx_http_upstream_<directive> injections to nginx_upstream_<directive>
move nginx_http_status_<directive> injections to nginx_status_<directive>
move client_max_body_size to nginx_http_client_max_body_size injection
move client_body_buffer_size to nginx_http_client_body_buffer_size injection
move real_ip_header to nginx_proxy_real_ip_header injection
move real_ip_recursive to nginx_proxy_real_ip_recursive injection
remove the undocumented nginx_optimizations config parameter

The tests are failing because this needs to be merged first:
https://github.com/Kong/kong-plugin-prometheus/pull/76

Some thoughts overall:

Overall this certainly seems a step in the direction where we (Thibault and I) wanted to be in when we initially put this feature in, so good job there!
Question: has there been a use-case or an ask for nginx_supstream_? I know there are a couple of directives we set and use but the API surface because of these increase quite a bit so wee should be careful about introducing it.
Please keep the deprecated variables documented in the kong.conf.default. And make sure that they are also documented on the docs site. Some of these are highly used variables and it will take a long time for them to go away, just from Kong's documentations and all the web of products around it.
Some of these properties like real_ip_header are used quite a lot. As much as we want to provide a good experience for Nginx ninjas, we also should keep Kong's configuration friendly for users who have never used Nginx before, which seems to be the majority in our user-base. I'd advise that we don't deprecate some of the config parameters that are used heavily and keep them as is. Explaining to an end user KONG_REAL_IP_HEADER is much easier than KONG_NGINX_HTTP_PROXY_REAL_IP_HEADER.
It is very important to document the big deal changes here in the changelog. Having a very verbose commit with a changelog section or keep those changes around in another doc could help.

A general comment:
This is one humongous commit and it is almost impossible for me to review this thoroughly and hence         I just skimmed it. I'd encourage us to rather make 20 smaller commits (especially when there are unrelated changes), even keep the commits as one makes while hacking this together.
I understand that we are religious about commit messages and commit formats but those can be taken care of at a later stage, even after a review of the code change.

Question: has there been a use-case or an ask for nginx_supstream_? I know there are a couple of directives we set and use but the API surface because of these increase quite a bit so wee should be careful about introducing it.

There is no reason for http to be more supported than stream in this regard. E.g. I have never heard people injecting stuff into http upstream, but that was probably added because a single person asked about it. Especially now that we get rid of service mesh and make stream standard nginx.

Please keep the deprecated variables documented in the kong.conf.default. And make sure that they are also documented on the docs site. Some of these are highly used variables and it will take a long time for them to go away, just from Kong's documentations and all the web of products around it.

We are not removing them at the moment. We just deprecated them. I can add them there, and to document to use a new value.

Some of these properties like real_ip_header are used quite a lot. As much as we want to provide a good experience for Nginx ninjas, we also should keep Kong's configuration friendly for users who have never used Nginx before, which seems to be the majority in our user-base. I'd advise that we don't deprecate some of the config parameters that are used heavily and keep them as is. Explaining to an end user KONG_REAL_IP_HEADER is much easier than KONG_NGINX_HTTP_PROXY_REAL_IP_HEADER.

We discussed it internally, and we got into problems with current injections. Biggest problem was that by injection name you cannot tell where the context stops and where the directive starts. Thus we changed everything to be KONG_NGINX_<SINGLE-WORD>. If we keep supporting multiple, e.g. KONG_REAL_IP_HEADER and KONG_NGINX_PROXY_REAL_IP_HEADER equally we get into issues of priorities, or erroring when defining both. It also adds excess code to handle these. I'd say it just brings more problems than it solves. Yes, I personally brought up the usability, but well, it is just one rename, and we are just deprecating for now.

Please keep the deprecated variables documented in the kong.conf.default. And make sure that they are also documented on the docs site.

Deprecations added to kong.conf.default. Docs site is autogenerated from it.

It is very important to document the big deal changes here in the changelog. Having a very verbose commit with a changelog section or keep those changes around in another doc could help.

I feel that is scope-creep of this PR. We usually do changelogs before releases separately.

This is one humongous commit and it is almost impossible for me to review this thoroughly and hence I just skimmed it. I'd encourage us to rather make 20 smaller commits

I split it to 15 commits.

authors: bungle hbagdi


text:
E2E tests shouldn't use cleaner.Cleanup

Is there an existing issue for this?

[X] I have searched the existing issues

Problem Statement
As E2E tests create their own clusters, it doesn't make sense to use cleaner.Cleanup (cleaning up in-cluster resources created by the test) on their tear down. Instead, we should simply cluster.Cleanup the whole cluster. It should save some time while running the tests.
Proposed Solution
Remove cleaner.Cleanup calls in favour of cluster.Cleanup in all E2E tests (test/e2e/) that create their own cluster.
Additional information
Ticket is a result of discussion: https://github.com/Kong/kubernetes-ingress-controller/pull/3013#discussion_r986589068
Acceptance Criteria

[ ] Every test case in test/e2e/ that always creates its own cluster, calls cluster.Cleanup instead of cleaner.Cleanup on its teardown.
[ ] Diagnostics generated by the cleaner are still being dumped for every test case

These are, I think, mostly just copied boilerplate from the integration tests. Normally part of the cleaner's job is to hold onto resources until the failure diagnostics complete. We used to write API client Delete calls in defers for created resources, but those would execute before the earlier defer to collect diagnostics.
E2E wasn't bothering to clean anything at all and still isn't--we're not calling cleaner.Add so the Cleanup call is basically a no-op.
Change shouldn't interfere with diagnostics though, so long as it's still run after them.

Change shouldn't interfere with diagnostics though, so long as it's still run after them.
Good point, I extended ACs to not lose that.

It's been fixed by https://github.com/Kong/kubernetes-ingress-controller/pull/3431.

authors: czeslavo rainest

repo: Kong/kubernetes-ingress-controller


text:
Release 1.0.0-rc.1

What this PR does / why we need it:
Releases 1.0.0-rc.1 to main. Follows from #887.
Special notes for your reviewer:

This probably will be done during the EMEA day, or I'll be proven wrong twice :D
Not actually creating the release yet. Not sure if that matters--pretty sure it doesn't, as it targets the tag rather than main, and we already have the tag, but figure it's a pretty small task atop the review/merge here. Prepped text: https://gist.githubusercontent.com/rainest/a3f50e7ccd9281edd1b685fa57fc8e1b/raw/50c9a70c912ea533487edba1c47792f035137254/release.md
Image built and pushed to Bintray, but as commented in the release process doc, not tagged latest. Pretty sure we do not want to do this for RCs, so assuming that gets a vote of approval, will work it into revised release process guide.
Didn't perform the "If releasing a new major or minor version, create and push a branch for it, e.g. git checkout 1.0.0-rc.1; git checkout -b 1.0.x; git push 1.0.x. GitHub will automatically protect the branch." step either. Less sure on whether that's something we want to omit for RCs--if we do want to create that immediately, well, the command is <<<
#888 came in mid-release. Minor doc fix. As the tag is already created, I don't want to stick it into RC1, but we probably should go ahead and merge immediately after merging this to incorporate it into 1.0.0 final.

Hmmm, by making a rc pre-release, we've hit the corner case of our release procedure.
I see main as a "stable" branch matching the latest released version. And, obviously, 1.0.0-rc.1 is a pre-release, not a release.
If we merge this PR, then users will get directed to pre-release documentation, and by applying manifests from main's deploy/, they will get an RC instead of latest stable. I don't think that's what they expect, and what the point of a pre-release version is.
Therefore, unless you (@rainest) see value in merging this PR right now regardless of the above, I'm inclined towards holding this PR back for now, and merging next to master only after a final GA release of 1.0.0.

Other than that:

This probably will be done during the EMEA day, or I'll be proven wrong twice :D

Gotcha. 😆

Not actually creating the release yet. Not sure if that matters--pretty sure it doesn't, as it targets the tag rather than main, and we already have the tag, but figure it's a pretty small task atop the review/merge here. Prepped text: https://gist.githubusercontent.com/rainest/a3f50e7ccd9281edd1b685fa57fc8e1b/raw/50c9a70c912ea533487edba1c47792f035137254/release.md

Would it make sense to release but mark as pre-release? (pic rel)

Image built and pushed to Bintray, but as commented in the release process doc, not tagged latest. Pretty sure we do not want to do this for RCs, so assuming that gets a vote of approval, will work it into revised release process guide.

Sounds good to me :+1:

* Didn't perform the "If releasing a new major or minor version, create and push a branch for it, e.g. `git checkout 1.0.0-rc.1; git checkout -b 1.0.x; git push 1.0.x`. GitHub will automatically protect the branch." step either. Less sure on whether that's something we want to omit for RCs--if we do want to create that immediately, well, the command is <<<

My (uneducated) guess is that development towards 1.0.x shall go into the 1.0.x branch. In other words, I see the 1.0.x  as a "bleeding edge" of the 1.0.x stream. Therefore my vote would be to actually perform this step - let's agree on something for the future.

#888 came in mid-release. Minor doc fix. As the tag is already created, I don't want to stick it into RC1, but we probably should go ahead and merge immediately after merging this to incorporate it into 1.0.0 final.

As in my answer immediately above - our release process should be well defined about last-minute drop-ins. That would be problematic if a more serious (in terms of regression risk) PR got merged into next amid a release.

Closing this for now, #891 will be merged into next, followed by a merge of next into main.

authors: hbagdi mflendrich rainest