text:
Respecting --max-mutations-in-report

Fixes #51

LGTM

Coverage increased (+0.03%) to 91.76% when pulling e8f0ebb6b1fd6b6d529cb8446d0f0d978e50a9ff on vaxrank-respect-max-mutations-in-report into 3a00be5362a7e6e317eb7ac46c144ef28d7c0b67 on master.

authors: coveralls ihodes julia326


text:
Some pasted images are transparent

OS: Manjaro
Desktop Environment: KDE (X11)
Image viewer used for copying image: Gnome Image Viewer (eog)

Issue: Some images copied from EOG become transparent in GDClip demo
~clip library expects image data to be non-premultiplied (alpha). However, if the image is premultiplied, then GDClip sends out a transparent image.~ <- Incorrect guess.
GDClip assumes image spec from clip is correct and does not check to see if alpha shift & mask are valid. In particular, when handling RGB images without alpha channel, clip will set bits_per_pixel to 32 and alpha_{mask,shift} to 0 which yield 0-valued alpha images (fully transparent).
Steps to replicate

Download pixel samples containing 1x1 RGBA8 and red pixel RGB8 png images (named broken_red_pixel.png and working_red_pixel.png, respectively).
red_pixel_test.zip

Copy image and run GDClip demo

Only RGBA8 red pixel image works.
Workaround options
~Here are some potential solutions:~
~1. Ignore problem since all PNGs should be non-premultiplied.~
~2. Ignore alpha channel values and let image be opaque.~
https://www.adriancourreges.com/blog/2017/05/09/beware-of-transparent-pixels/
https://developer.nvidia.com/content/alpha-blending-pre-or-not-pre
https://nigeltao.github.io/blog/2022/premultiplied-alpha.html
https://github.com/Tom94/tev/blob/94218f2e4bfb92c0ff69cb5ba65ec0af72c27741/src/imageio/ClipboardImageLoader.cpp#L82-L100

https://github.com/dacap/clip/blob/246e60fd569993f8a756d548c130602919eec6c0/clip_x11_png.h#L145-L170
Comments describe that 24bpp (RGB) image can be treated as 32bpp (RGBA) image with alpha=255 (fully opaque).

Fixed in 34f19ed7c8117279634322a7b0e0a552557ee9c6

source: gharchive/issue

repo: hansemro/GDClip

license: MIT

license_type: permissive

license_source: github-api


text:
I got stucked at step7 I got this error. Is there something wrong with ASIO version?

Once I run the build-plugin I got this error
D:\kinect-to-holo\cpp\src\kh_receiver.cpp(14,46): error C2039: 'get_io_context': is not a member of 'asio::basic_stream _socket<asio::ip::tcp,asio::any_io_executor>' [D:\kinect-to-holo\cpp\build\x86\src\KinectToHololens.vcxproj] D:\kinect-to-holo\vcpkg\installed\x86-windows\include\asio/ip/tcp.hpp(82): message : see declaration of 'asio::basic_st ream_socket<asio::ip::tcp,asio::any_io_executor>' [D:\kinect-to-holo\cpp\build\x86\src\KinectToHololens.vcxproj] D:\kinect-to-holo\cpp\src\kh_receiver.cpp(14,37): error C2512: 'asio::ip::basic_resolver<asio::ip::tcp,asio::any_io_exe cutor>::basic_resolver': no appropriate default constructor available [D:\kinect-to-holo\cpp\build\x86\src\KinectToHolo lens.vcxproj]

I got stucked at step7 I got this error. Is there something wrong with ASIO version?

I fixed this error by change the code to following
However it got stucked at this new error. Any idea how to fix ?

repo: hanseuljun/kinect-to-hololens


text:
Tiny memory leak in rustler_export_nifs

                name: ::std::ffi::CString::new($name).unwrap().into_raw() as *const u8,

I don't think this is safe; I think the CString is freed at the end of the statement.
Maybe we can do this instead:
    name: concat!($name, "\x00").as_bytes() as *const u8,

CString::into_raw transfers ownership, so it is safe in that sense.
The way it's done currently does cause the string to leak however, so your suggestion is probably a better idea here

OK, db0cf3b is the fix for this.

@hansihe Is this completely leak free now?  If so I'd like to retract https://github.com/erlang/otp/pull/1294 which has technical problems that I did not foresee.  Upcoming Rust macro features in the next year or 2 should resolve the Rust-side limitations I experienced.

@goertzenator No, it is still not completely leak free. The leak is not very large however, and it only happens on a NIF unload,  so we are probably fine either way. You decide if you want to retract the PR.

@hansihe Where do we still leak memory?

@jorendorff Isn't this leaking memory? There is nothing dropping that.

entry gets moved into NIF_ENTRY which is static.  I've looked closely at this file and I'm not seeing leaks.

@goertzenator Ah, I forgot how static variables worked for a second. There is indeed no leaks.

authors: goertzenator hansihe jorendorff

repo: hansihe/Rustler

license_source: bigquery


text:
IntlError: MISSING_MESSAGE: No messages were configured on the provider.

The error message appear only once at first time running nextjs with yarn dev, i know this is not a big problem but it piqued my curiosity and it made me itchy, also the reason why the error appeared four times is still a mystery. this error appears inside terminal (SSR) not a browser console

accordign to https://github.com/amannn/next-intl/issues/161 it seems that the request time required is longer, causing rendering to be done first, but it's not a big problem so I will close this issue now.
for now I can only assume and assume so.

repo: hansputera/bilibili-dl


text:
high err

I train your network without deformable conv and refinement.
The train err on sceneflow is high, about 2.0 epe.
Does it normal?

Sorry, we didn't have such a comparison.

authors: haofeixu meteorshowers

repo: haofeixu/aanet


text:
Requirement.txt

Hi
Would you like to  provide the requirement.txt to me?
Best regards,
PeterPham

Hi, please refer to INSTALL.md for environment configuration, thanks.

@haotian-liu
Thanks


text:
Error while running Colab

I trying to run the model in Colab and face this problem, does anyone have the same problem?

Hi bro, you have to download the model manually. That Google Drive download method does not work.
Also, could you show me the image output after you run it successfully? You can refer to my issue #212

Thank you, the manual method worked well.


text:
Guides don't move with the DOM

As we scroll, there is a delay before the indent markers start moving. This is especially a problem for me as I like my indent markers to be quite wide, making this very apparent. Perhaps the markers should be embedded into the same DIV that is being scrolled?

Yes I find this happening very distracting too.

The guides feel very lose when scrolling.  They're probably not going to the rendering tiles.

authors: saivan shaunlebron shyambalu

repo: harai/indent-guide-improved

license: mit


text:
Feature suggestion - Add partial options overwrite with default values

Hi there,
I would like to know if it would be possible to add a way to specify default PdfOptions but still let the calling site specify some options that should overwrite preset options and complement the ones that were not defined in the defaultOptions?
For example, if someone would define the default conversion options to have a specific format, etc.... which should be applied by default everytime, but then for one specific conversion would need to change the format. It would be nice to be able to pass a partially filled PdfOptions instance which would overwrite the properties it redefines within the default set of options....
I tried using Automapper to do it by mapping object to object, ignoring null members from the source object (which is the new set of options that should overwrite existing ones), but because the PdfOptions properties are not nullable, they get their default values so the mapper overwrites everything from my default set of options...
As of right now, the only way to pass specific options for a conversion is to pass a full PdfOptions object, which is not really optimal as it causes code duplication and if the defaults were to change, then it would require "shotgun surgery" to update every calling site.... What do you think?

I implemented a really dump POC here in which I check if a value was passed within the custom PdfOptions object by checking if they are defined (for nullable properties like string and reference types) or if they have a different value than their default one for non nullable properties.
public static void MergeOptionsWith(this PdfOptions defaultOptions, PdfOptions customOptions)
{
    defaultOptions.HeaderTemplate = !string.IsNullOrEmpty(customOptions.HeaderTemplate) ? customOptions.HeaderTemplate : defaultOptions.HeaderTemplate;
    defaultOptions.Height = customOptions.Height != null ? customOptions.Height : defaultOptions.Height;
    defaultOptions.Width = customOptions.Width != null ? customOptions.Width : defaultOptions.Width;
    defaultOptions.Format = customOptions.Format != null ? customOptions.Format : defaultOptions.Format;
    defaultOptions.PageRanges = !string.IsNullOrEmpty(customOptions.PageRanges) ? customOptions.PageRanges : defaultOptions.PageRanges;
    defaultOptions.Landscape = customOptions.Landscape != default ? customOptions.Landscape : defaultOptions.Landscape;
    defaultOptions.PrintBackground = customOptions.PrintBackground != default ? customOptions.PrintBackground : defaultOptions.PrintBackground;
    defaultOptions.FooterTemplate = !string.IsNullOrEmpty(customOptions.FooterTemplate) ? customOptions.FooterTemplate : defaultOptions.FooterTemplate;
    defaultOptions.PreferCSSPageSize = customOptions.PreferCSSPageSize != default ? customOptions.PreferCSSPageSize : defaultOptions.PreferCSSPageSize;
    defaultOptions.DisplayHeaderFooter = customOptions.DisplayHeaderFooter != default ? customOptions.DisplayHeaderFooter : defaultOptions.DisplayHeaderFooter;
    defaultOptions.Scale = customOptions.Scale != default(double) ? customOptions.Scale : defaultOptions.Scale;
    defaultOptions.MarginOptions = customOptions.MarginOptions != null ? customOptions.MarginOptions : defaultOptions.MarginOptions;
}

In a small wrapper I made a long time ago for WkHtmlToPdf, what I did was that I did use only nullable properties for the options object (doing the proper null-checking where required before using the options). This by default did let me simply overwrite a default set of options by simply mapping between the custom options and the default ones, ignoring null properties), but this might need too much changes for what it's worth. The only thing I don't really like with the above implementation is that if you ever change the PdfOptions object definition, this code will break... so that's why I thought it could be nice if it was part of the library directly so that we can ensure it always maps to the correct properties....
Anyways I'd be glad if you could share your thought on the topic (don't worry if you don't want to implement something similar, I won't complain and I will keep using my custom implementation, hoping the PdfOptions object definition won't be changed silently ahah) :)
Cheers and keep up the good work, this and PuppeteerSharp are really nice projects! (it's just sad that the community decided to work on 2 parallel projects that are essentially the same, especially now that Puppeteer also supports multiple browsers.... and now you have to maintain/choose to focus on only one instead of focusing all the community efforts into a single web automation library!)

Thank you for your feedback and your nice words @os1r1s110 :)
I love your idea. I would like to see this in all our options. I have two thoughts about this:

This is something the user can implement on their side. You can already accomplish this with your function :) So I wouldn't consider it a high priority.
We would get this feature with the with statement in C# 9. So the question would be, should we implement this or should we wait for C# 9?

Oh didn't know about the C# 9 with statement, I guess we can wait for that then :) (and effectively I understand it's not top priority ahah)
That means the options would become Records (so declared with public data class) correct?
I will close the issue as using native C# language features is normally well received compared to hacking an in-house solution :P
Thanks for the hint!

repo: hardkoded/playwright-sharp


text:
Firefox: Pass ScreenshotTests

closes #116

mac & ubuntu are having issues in CI :(

It seems we have consistent fails on MacOS. I'll take a look at it.

@Meir017 fixed :)

source: gharchive/pull-request


text:
Add Korean language

Major changes
Korean translation has been completed.
I also updated the index.json and readme.md files.
❤ harmonoid ❤

Thanks a lot for the translations! I'm really glad.

authors: alexmercerind dart-bird

repo: harmonoid/translations

license: Unlicense


text:
chore(chaos): Correct typographical error in architecture docs

Signed-off-by: neelanjan00 neelanjan.manna@harness.io

Changed one to once.

What Type of PR is This?

[ ] Issue
[ ] Feature
[x] Maintenance/Chore

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[x] Tested Locally
[ ] Optional Screen Shoot.

Preview environment: https://ci.pr.harness.io/pr-384

Preview environment: https://ci.pr.harness.io/pr-384

Preview environment: https://ci.pr.harness.io/pr-384

repo: harness/developer-hub


text:
GitOps Resources Don't Work.....

I'm unable to get any of the harness_gitops_ prefixed resources to work. It appears either the underlying Go SDK API's don't permit the use of PAT/SAT keys and require a bearer token, or that the keys aren't being passed around internally.
I've tried a few options here in different directions, but ultimately we just want to have a terraform script create some Harness resources and trigger them. It seems this is potentially a trick too much though for the current state of play?

Yeah, I've confirmed this with the Go SDK locally. The fix is in addition to these lines....
	ctx = context.WithValue(ctx, nextgen.ContextAccessToken, hh.EnvVars.BearerToken.Get())

You need to follow them with:
	ctx = context.WithValue(ctx, nextgen.ContextAPIKey, nextgen.APIKey{
		Key: apiKey,
	})

(Where apiKey is from the terraform provider properties). Ideally you should remove any access of environment variables from these resource definitions and do that kind of defaulting in the Terraform provider function itself, not inside the individual resource stoo.

Hi @steve-gray , this has been fixed. Now GitOps resources support the pat token.

I can confirm this is working, and was able to deploy a Gitops agent.
@manavjot-harness  - is there a resource to configure the association between an agent and environment anywhere?

@steve-gray No we don't have a resource for the association for agent and environment. But you can configure environments to use certain clusters from an agent.
Can you please elaborate on the use case?

authors: manavjot-harness steve-gray

repo: harness/terraform-provider-harness


text:
make error on Centos 7

[~/bladebit]: make clean && make -j$(nproc --all)
src/b3/blake3_avx2_x86-64_unix.S
Compiling for linux with g++
src/b3/blake3_avx512_x86-64_unix.S
src/b3/blake3_dispatch.c
src/b3/blake3_portable.c
src/b3/blake3_sse41_x86-64_unix.S
src/b3/blake3.c
src/bech32/segwit_addr.c
src/fse/debug.c
src/fse/entropy_common.c
src/fse/fse_compress.c
src/fse/fse_decompress.c
src/fse/hist.c
src/io/FileStream.cpp
src/main.cpp
src/memplot/DbgHelper.cpp
src/memplot/MemPhase1.cpp
src/memplot/MemPhase2.cpp
src/memplot/MemPhase3.cpp
src/memplot/MemPhase4.cpp
src/memplot/MemPlotter.cpp
src/pch.cpp
src/platform/linux/SysHost_Linux.cpp
src/platform/unix/FileStream_Unix.cpp
src/PlotContext.cpp
src/PlotWriter.cpp
src/pos/chacha8.cpp
src/SysHost.cpp
src/threading/Semaphore.cpp
src/threading/Thread.cpp
src/threading/ThreadPool.cpp
src/Util.cpp
src/util/Log.cpp
lib/linux/x86/libbls.a(relic_bn_add_low.c.o): In function bn_addn_low': relic_bn_add_low.c:(.text+0x414): undefined reference to __gmpn_add_n'
lib/linux/x86/libbls.a(relic_bn_add_low.c.o): In function bn_subn_low': relic_bn_add_low.c:(.text+0x844): undefined reference to __gmpn_sub_n'
lib/linux/x86/libbls.a(relic_bn_mod_low.c.o): In function bn_modn_low': relic_bn_mod_low.c:(.text+0x163): undefined reference to __gmpn_addmul_1'
relic_bn_mod_low.c:(.text+0x180): undefined reference to __gmpn_addmul_1' relic_bn_mod_low.c:(.text+0x19d): undefined reference to __gmpn_addmul_1'
relic_bn_mod_low.c:(.text+0x1bb): undefined reference to __gmpn_addmul_1' relic_bn_mod_low.c:(.text+0x1d5): undefined reference to __gmpn_addmul_1'
lib/linux/x86/libbls.a(relic_bn_mod_low.c.o):relic_bn_mod_low.c:(.text+0x1f0): more undefined references to __gmpn_addmul_1' follow lib/linux/x86/libbls.a(relic_bn_mod_low.c.o): In function bn_modn_low':
relic_bn_mod_low.c:(.text+0x229): undefined reference to __gmpn_add_n' relic_bn_mod_low.c:(.text+0x263): undefined reference to __gmpn_sub_n'
lib/linux/x86/libbls.a(relic_bn_mul_low.c.o): In function bn_mula_low': relic_bn_mul_low.c:(.text+0xa): undefined reference to __gmpn_addmul_1'
lib/linux/x86/libbls.a(relic_bn_mul_low.c.o): In function bn_mul1_low': relic_bn_mul_low.c:(.text+0x1a): undefined reference to __gmpn_mul_1'
lib/linux/x86/libbls.a(relic_bn_mul_low.c.o): In function bn_muln_low': relic_bn_mul_low.c:(.text+0x24): undefined reference to __gmpn_mul_n'
lib/linux/x86/libbls.a(relic_bn_mul_low.c.o): In function bn_muld_low': relic_bn_mul_low.c:(.text+0x37): undefined reference to __gmpn_mul'
lib/linux/x86/libbls.a(relic_bn_shift_low.c.o): In function bn_lsh1_low': relic_bn_shift_low.c:(.text+0x9): undefined reference to __gmpn_lshift'
lib/linux/x86/libbls.a(relic_bn_shift_low.c.o): In function bn_lshb_low': relic_bn_shift_low.c:(.text+0x14): undefined reference to __gmpn_lshift'
lib/linux/x86/libbls.a(relic_bn_shift_low.c.o): In function bn_rsh1_low': relic_bn_shift_low.c:(.text+0x29): undefined reference to __gmpn_rshift'
lib/linux/x86/libbls.a(relic_bn_shift_low.c.o): In function bn_rshb_low': relic_bn_shift_low.c:(.text+0x34): undefined reference to __gmpn_rshift'
lib/linux/x86/libbls.a(relic_fb_add_low.c.o): In function fb_addn_low': relic_fb_add_low.c:(.text+0x36): undefined reference to __gmpn_xor_n'
lib/linux/x86/libbls.a(relic_fb_add_low.c.o): In function fb_addd_low': relic_fb_add_low.c:(.text+0x44): undefined reference to __gmpn_xor_n'
lib/linux/x86/libbls.a(relic_fb_shift_low.c.o): In function fb_lsh1_low': relic_fb_shift_low.c:(.text+0xb): undefined reference to __gmpn_lshift'
lib/linux/x86/libbls.a(relic_fb_shift_low.c.o): In function fb_lshb_low': relic_fb_shift_low.c:(.text+0x18): undefined reference to __gmpn_lshift'
lib/linux/x86/libbls.a(relic_fb_shift_low.c.o): In function fb_rsh1_low': relic_fb_shift_low.c:(.text+0x2b): undefined reference to __gmpn_rshift'
lib/linux/x86/libbls.a(relic_fb_shift_low.c.o): In function fb_rshb_low': relic_fb_shift_low.c:(.text+0x38): undefined reference to __gmpn_rshift'
lib/linux/x86/libbls.a(relic_fp_add_low.c.o): In function fp_addm_low': relic_fp_add_low.c:(.text+0x11a): undefined reference to __gmpn_add_n'
lib/linux/x86/libbls.a(relic_fp_add_low.c.o): In function fp_addc_low': relic_fp_add_low.c:(.text+0x18e): undefined reference to __gmpn_add_n'
lib/linux/x86/libbls.a(relic_fp_add_low.c.o): In function fp_subm_low': relic_fp_add_low.c:(.text+0x31a): undefined reference to __gmpn_sub_n'
lib/linux/x86/libbls.a(relic_fp_add_low.c.o): In function fp_subc_low': relic_fp_add_low.c:(.text+0x36a): undefined reference to __gmpn_sub_n'
lib/linux/x86/libbls.a(relic_fp_add_low.c.o): In function fp_dblm_low': relic_fp_add_low.c:(.text+0x40d): undefined reference to __gmpn_add_n'
lib/linux/x86/libbls.a(relic_fp_add_low.c.o): In function fp_hlvm_low': relic_fp_add_low.c:(.text+0x479): undefined reference to __gmpn_add_n'
relic_fp_add_low.c:(.text+0x491): undefined reference to __gmpn_rshift' lib/linux/x86/libbls.a(relic_fp_add_low.c.o): In function fp_hlvd_low':
relic_fp_add_low.c:(.text+0x515): undefined reference to __gmpn_add_n' relic_fp_add_low.c:(.text+0x58c): undefined reference to __gmpn_rshift'
relic_fp_add_low.c:(.text+0x5a4): undefined reference to __gmpn_rshift' lib/linux/x86/libbls.a(relic_fp_add_low.c.o): In function fp_addn_low':
relic_fp_add_low.c:(.text+0x106): undefined reference to __gmpn_add_n' lib/linux/x86/libbls.a(relic_fp_add_low.c.o): In function fp_addm_low':
relic_fp_add_low.c:(.text+0x152): undefined reference to __gmpn_sub_n' lib/linux/x86/libbls.a(relic_fp_add_low.c.o): In function fp_addd_low':
relic_fp_add_low.c:(.text+0x176): undefined reference to __gmpn_add_n' lib/linux/x86/libbls.a(relic_fp_add_low.c.o): In function fp_addc_low':
relic_fp_add_low.c:(.text+0x1c6): undefined reference to __gmpn_sub_n' lib/linux/x86/libbls.a(relic_fp_add_low.c.o): In function fp_subn_low':
relic_fp_add_low.c:(.text+0x306): undefined reference to __gmpn_sub_n' lib/linux/x86/libbls.a(relic_fp_add_low.c.o): In function fp_subm_low':
relic_fp_add_low.c:(.text+0x33d): undefined reference to __gmpn_add_n' lib/linux/x86/libbls.a(relic_fp_add_low.c.o): In function fp_subd_low':
relic_fp_add_low.c:(.text+0x356): undefined reference to __gmpn_sub_n' lib/linux/x86/libbls.a(relic_fp_add_low.c.o): In function fp_subc_low':
relic_fp_add_low.c:(.text+0x38e): undefined reference to __gmpn_add_n' lib/linux/x86/libbls.a(relic_fp_add_low.c.o): In function fp_negm_low':
relic_fp_add_low.c:(.text+0x3ea): undefined reference to __gmpn_sub_n' lib/linux/x86/libbls.a(relic_fp_add_low.c.o): In function fp_dbln_low':
relic_fp_add_low.c:(.text+0x3f9): undefined reference to __gmpn_add_n' lib/linux/x86/libbls.a(relic_fp_add_low.c.o): In function fp_hlvm_low':
relic_fp_add_low.c:(.text+0x4d1): undefined reference to __gmpn_rshift' lib/linux/x86/libbls.a(relic_fp_inv_low.c.o): In function fp_invm_low':
relic_fp_inv_low.c:(.text+0x81): undefined reference to __gmpn_gcdext' relic_fp_inv_low.c:(.text+0xe0): undefined reference to __gmpn_tdiv_qr'
relic_fp_inv_low.c:(.text+0x11e): undefined reference to __gmpn_sub_n' lib/linux/x86/libbls.a(relic_fp_mul_low.c.o): In function fp_mula_low':
relic_fp_mul_low.c:(.text+0x9): undefined reference to __gmpn_addmul_1' lib/linux/x86/libbls.a(relic_fp_mul_low.c.o): In function fp_mul1_low':
relic_fp_mul_low.c:(.text+0x19): undefined reference to __gmpn_mul_1' lib/linux/x86/libbls.a(relic_fp_mul_low.c.o): In function fp_muln_low':
relic_fp_mul_low.c:(.text+0x26): undefined reference to __gmpn_mul_n' lib/linux/x86/libbls.a(relic_fp_rdc_low.c.o): In function fp_rdcn_low':
relic_fp_rdc_low.c:(.text+0x527): undefined reference to __gmpn_addmul_1' lib/linux/x86/libbls.a(relic_fp_shift_low.c.o): In function fp_lsh1_low':
relic_fp_shift_low.c:(.text+0xb): undefined reference to __gmpn_lshift' lib/linux/x86/libbls.a(relic_fp_shift_low.c.o): In function fp_lshb_low':
relic_fp_shift_low.c:(.text+0x18): undefined reference to __gmpn_lshift' lib/linux/x86/libbls.a(relic_fp_shift_low.c.o): In function fp_rsh1_low':
relic_fp_shift_low.c:(.text+0x2b): undefined reference to __gmpn_rshift' lib/linux/x86/libbls.a(relic_fp_shift_low.c.o): In function fp_rshb_low':
relic_fp_shift_low.c:(.text+0x38): undefined reference to __gmpn_rshift' lib/linux/x86/libbls.a(relic_fp_sqr_low.c.o): In function fp_sqrn_low':
relic_fp_sqr_low.c:(.text+0x9): undefined reference to __gmpn_mul_n' lib/linux/x86/libbls.a(relic_bn_div_low.c.o): In function bn_divn_low':
relic_bn_div_low.c:(.text+0x15): undefined reference to __gmpn_tdiv_qr' lib/linux/x86/libbls.a(relic_bn_div_low.c.o): In function bn_div1_low':
relic_bn_div_low.c:(.text+0x2a): undefined reference to __gmpn_divrem_1' lib/linux/x86/libbls.a(relic_bn_sqr_low.c.o): In function bn_sqra_low':
relic_bn_sqr_low.c:(.text+0x28): undefined reference to __gmpn_addmul_1' relic_bn_sqr_low.c:(.text+0x52): undefined reference to __gmpn_addmul_1'
lib/linux/x86/libbls.a(relic_bn_sqr_low.c.o): In function bn_sqrn_low': relic_bn_sqr_low.c:(.text+0x87): undefined reference to __gmpn_mul_n'
collect2: error: ld returned 1 exit status
make: *** [Makefile:157: bladebit] Error 1

This is probably GCC 11 which BLS/Relic does not support.

You can try to an earlier version of GCC, or see my comment here about pointing the submodule to computer_whisper's fork of BLS. Let me know if you need more help.

Centos 7 default is:
g++ --version
g++ (GCC) 8.4.1 20200928 (Red Hat 8.4.1-1)

Looking at it more closely, you might be missing libgmp.

Closing here if there's nothing else to be said.

authors: grobalt harold-b

repo: harold-b/bladebit


text:
Add support for versioning core register schema

Following the developments in harp-tech/reflex-generator#57 and harp-tech/protocol#21, we started wondering there is currently no way of versioning the common YML file itself.
One option to workaround this is to add an additional schema for the core, e.g. core.json which would require an extra property on these YML files which is the core version. The number added there would have to match the core version used to implement the device firmware for each device.
There might be a few more details to think about related to how we merge this common YML file with the individual device schemas, but this versioning will be important so we don't accidentally start including new registers in a joint device map which are not actually implemented by the device firmware if it is still using an older harp core.

Are core registers tied to a specific core implementation version? no, they are tied to specification version

coreVersionHigh / Low should return the version of the core firmware implementation (atmel core or pico core)
device.yml needs to declare which version of the core specification it implements

Outstanding questions:

are we ok with using "draft-xx" for versioning / url of meta-schema file
what name should this field have?
where do we need to change meta-schema? is it enough to add a new field to device.json? do we need to also add a core.json to use as meta-schema for common.yml?
are we ok with the name common.yml?
should the core version high / low registers return the version number of the common.yml file that it implements?

if yes, do we also need to return the version of the core firmware anyway? maybe not required since there is a tight link between firmware version and harp core firmware version (if core changes, firmware version needs to bump up)

One important consideration is there can be releases of the same device firmware version for different core implementations, for compatibility reasons. This suggests we probably want an extra register to store the specification version.
A proposal which was suggested is to create a new single register containing all version information (hardware, firmware, core, specification) encoded as a payload specification. This would allow us to extend the range of versioning (e.g. to include a new patch version number, the new specification versions, etc) as well as providing a single register to retrieve the entire version information in a single call.
Example definition
  VersionInfo:
    address: 15
    type: U8
    length: 12
    access: Read
    description: Stores the version info for the device hardware, firmware, core, and specification used.
    payloadSpec:
      HardwareVersion:
        offset: 0
        description: Specifies the hardware version of the device.
        interfaceType: HarpVersion
      FirmwareVersion:
        offset: 3
        description: Specifies the firmware version of the device.
        interfaceType: HarpVersion
      CoreVersion:
        offset: 6
        description: Specifies the core version of the device.
        interfaceType: HarpVersion
      SpecVersion:
        offset: 9
        description: Specifies the spec version of the device.
        interfaceType: HarpVersion

Outstanding questions

Name of the register
Number of version components (2 or 3)?
Order of version components (hardware, firmware, core, spec or something else?)
Interface type used to represent version in Bonsai.Harp, there is currently a HarpVersion type already, but it only includes two components (high / low)

Related to #44

Actually, I know realise perhaps the true implications of the comment I had made 4 months ago:

device.yml needs to declare which version of the core specification it implements

This actually opens up another solution to implement this versioning without the need for an extra register: if the device.yml for the device declares which version of the specification is implemented, then it would be possible to deduce immediately from the device.yml which core registers are available, without the need to change anything about the current registers.
Because the change on the device.yml described in #13 is required anyway, and is not exclusive with #44, I am now leaning towards we just implementing #13 first and only afterwards worrying about the new version registers.

I think we need both actually. Otherwise how would you ensure that the hardware you are connecting to implements a specific version of the protocol? There is no guarantees.
If you use the device specific nodes, I can see a way where you could cross reference the implementation version to the protocol version, but this would require saving multiple yml files per assembly and searching through them (since in theory multiple implantation versions might target the same protocol version). Additionally, the core harp package still needs to know which protocol versionthe target device is speaking and here running this cross reference is much harder since we don't keep the device yml in this assembly. So not sure if I follow how a new register is not necessary.

Edit: after re reading your comment, if all your are saying is that this change should take temporal precedence over the register, I agree.

Yes, this is what I was recommending to get this out quicker.

Otherwise how would you ensure that the hardware you are connecting to implements a specific version of the protocol? There is no guarantees.

There is one guarantee that you can make via the firmware version. We know that each specific device firmware version is linked to a unique device.yml file. If this YML file contains in addition the specification version, then indirectly we do know the version.
Especially once we start saving the device YML files together with data logging, I suspect we could use just the changes in YML for a really long time. In fact for data analysis, apart from maybe some QC, I don't think we will need to care much about the spec version register at all.

Ok that makes sense!
Regarding the second point, maybe for data analysis, but for online qc makes things much harder. Additionally it will require people to always use a yaml file, essentially making it impossible to validate the protocol version when using the generic interface.

That is true, but I thought the generic device interface was to be used without validation, to allow for rapid prototyping and debugging. Right now there is no validation by design, and in that case we would have to implement the validation ourselves anyway.

I think we might be thinking about a different kind of validstion tho. The device specific validation makes sense since a specific device implements a specific set of registers and functions which are both locked to the version of the device yaml it is used to generate the interface. The generic interface doesn't care about either of these BUT it does care what version of the protocol the device implements since all the core registers are implemented via this package. The core registers are, in turn, locked to a specific protocol version. Otherwise how else would you be able to know what bonsai.harp package version to install ?

If we don't introduce breaking changes in the protocol, I don't think we need to worry about validating generic Harp devices.
The reason is that all changes are incremental in terms of supported functionality. Even old generic interfaces will be able to accept devices with new registers, and even log everything (yet another advantage of using numbers instead of names for logging).
If you use an old interface you just won't be able to parse the new registers or send newer commands, but to me this seems completely fine and expected, especially since using newer registers is something that is required really only at the workflow level. In other words, if the workflow doesn't need a new functionality anyway, it would work fine with an older core package, even if working with newer devices.
Adding the common.yml metadata to the harp core package is already the plan and it is required for analysis. However, this would not by itself solve the issue of major version compatibility I think. Introducing breaking changes is part of an ongoing bigger and deeper discussion that I feel won't be easily solved by validating single device registers.
As soon as we introduce breaking changes in the protocol and try to mix old and new devices in the same workflow there would be many more things breaking because you can really only have one version of the protocol client assembly installed right now.
I can think of several ways to allow co-existence in the future, but they are all painful, and all of them would force us to spend more maintenance resources than what we can currently allocate.
So on this I agree with @filcarv that we should absolutely try to avoid breaking the protocol for as long as we possibly can until we stabilise both our requirements and the ecosystem.

Ok I agree that they are separate issues and if there are no breaking changes the interface should work. B it I still don't see a user would be able to know what protocol version the device implements without the additional register. Say you use an interface that targets app1.2core2.3 and your interface is for app1.3core2.4. It so happens they the device will work because no breaking changes were made BUT the device yaml that gave rise to the interface knows that app1.3core2.4 happens to be associated with protocol version 0.3. Critically the yaml doesn't know anything about app1.2core2.3. This device yaml might not even exist. How would the user recover this information? This is what I am worried about by not having it explicitly tracked in the device firmware.

#21 depends on this

@glopesdev
The current suggestion would thus include:

Create a new core/common.json that mirrors the "device.json" but specifies the structure for the core, along with a field to track the version;
Refactor common.yml to follow the last point
To the device.json, add a new field to track the Harp protocol version (in order to attempt to cross-reference to the previous point) and a new field to track implementation/architecture (e.g.: RP2040 vs Atmega)

authors: bruno-f-cruz glopesdev

repo: harp-tech/protocol


text:
Support Language Server

Reference: https://code.visualstudio.com/api/language-extensions/language-server-extension-guide

Done!

repo: harry-hov/vscode-gno


text:
changes in post create UI

Describe the bug
The post create page is not the same as other pages.
Expected behavior
Changing the page template to get it to match with other pages' style
Screenshots
Current view of the page

Want to work on this issue @harsh-9in

so u wanna change the UI of the create post template?

yeah changing it to look similar as other pages' UI with few changes

go ahead @Akshi149  :)

@harsh-9in
header and footer will be added later so didn't show it here
the pink color is when the button is hovered

any changes you want to suggest?

plz remove that Filter and trending part

that is actually being rendered from base.html

okk

looks good make pr

in that case, should I make a separate page that contains all (header, form, footer)?

header and footer will be that of #101

first, we will go with good wireframes

first, we will go with good wireframes

ohk 👍

Do one thing make this as pr and I will create another issue for removing this in that you can add footer and header.


text:
feat: password generator

This extension will generate a strong random password of variable length (given by the user)
Hi @harshita214, I would like to contribute to this issue under JWOC'22.
Thanks.

Will it save also the password?

Will it save also the password?

for now, it'll just create random passwords of variable length but I can update that to store the password  later

yes

Okay are u able to complete this in 1-2 days?

I need 2-3 days to code and add a good UI

Can you brief the issue and its features
Like user can add a number then the password will be generated?
Is there any other features etc.

Okay

@r3yc0n1c update?

@r3yc0n1c update?

yep... just removed the commented lines and was working on the UI... can you review the PR now?

Completed - #93


text:
Training RSSI->distance to location in brain

Hi,
I am trying to use brain for training RSSI and sensors coordinates as inputs and position as output in x,y,z normalized in single number. can you suggest on data modeling this into brain.
inputs : [{x1,y1,z1,distance1},{{x2,y2,z2,distance2},{x3,y3,z3,distance3}}
output: {x100+y10+z} as position.
i get constant error while training even up to 20000 iterations.
Regards

This repository is unmaintained as the author left Github.
I suggest you to either use a different library or study the source code as
to modify it to suit your needs.
Le 21 mars 2018 06:04, "rpant1979" notifications@github.com a écrit :

Hi,
I am trying to use brain for training RSSI and sensors coordinates as
inputs and position as output in x,y,z normalized in single number. can you
suggest on data modeling this into brain.
inputs : [{x1,y1,z1,distance1},{{x2,y2,z2,distance2},{x3,y3,z3,distance3}}
output: {x100+y10+z} as position.
i get constant error while training even up to 20000 iterations.
Regards
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/harthur/brain/issues/82, or mute the thread
https://github.com/notifications/unsubscribe-auth/AKYwYOy_SiY_5wfTmvCNFG7xZLS__0v0ks5tgd9lgaJpZM4SzBFT
.

Go to: https://github.com/BrainJS/brain.js

authors: Zenohate dan-ryan rpant1979

repo: harthur/brain


text:
Upgrade to Channels 2?

In an initial attempt to write tests, I found that Channels 2 is significantly different from Channels 1, and the testing framework has changed entirely. Rather than write 1-style tests, then possibly have to rewrite all of them later, should we upgrade to 2 and write tests once? ;)
https://channels.readthedocs.io/en/latest/one-to-two.html

Closed in #29 and some subsequent commits, though there are still issues: #30, for example. Also, the local dev environment without Docker is less usable than I'd like, so it needs improvements and/or a docs change.

repo: harvard-lil/dostuff


text:
[BUG] Image object does not expose storage class

Describe the bug
PVC storageClassName is required when creating a VM, and it must match the image's storage class. However, the image
object currently does not expose the storage class (i.e. backingImageStorageClass) after the image is imported.
To Reproduce

from UI, create an image with an valid image URL
after the image is successfully imported, view the image object from 'View in API'

Expected behavior
'backingImageStorageClass' field should be visible in the image object.
Support bundle
N/A
Environment:

Harvester ISO version: master
Underlying Infrastructure (e.g. Baremetal with Dell PowerEdge R630): N/A

Additional context
Add any other context about the problem here.

I am not sure how the storage class name was decided currently when creating the disks based on the image, but we should write it as metadata information in the image status, so other callers can use it as well.

I checked on the previous master version and the field was not here, as expected. I then tested with the latest master version (master-84781dcb-head) and I now see the storageClassName field in View in API mode:
"status": {
  "appliedUrl": "https://download.opensuse.org/distribution/leap/15.3/appliances/openSUSE-Leap-15.3-JeOS.x86_64-OpenStack-Cloud.qcow2",
  "conditions": [
    {
      "error": false,
      "lastUpdateTime": "2021-07-08T09:45:51Z",
      "status": "True",
      "transitioning": false,
      "type": "Initialized"
    }
  ],
  "size": 227497472,
  "storageClassName": "longhorn-image-2g9wz"
}

So all looks good.

authors: guangyee ldevulder yasker

repo: harvester/harvester


text:
[BUG] Use the downloaded kubeconfig to connect to the cluster, display the certificate error

Describe the bug

Use the downloaded kubeconfig to connect to the cluster, display the certificate error
To Reproduce
Steps to reproduce the behavior:

Download the kubeconfig file through the header menu
Use this configuration to connect to the cluster

Expected behavior

Can connect to the cluster normally
Support bundle

Environment:

Harvester ISO version:
Underlying Infrastructure (e.g. Baremetal with Dell PowerEdge R630):

Additional context
Add any other context about the problem here.

Tested in master-8afedf0a-head. fixed.


text:
Is there any stree test about harvester[Question]

I would like to know if Harvester has a stress test report？

For example, the time to create virtual machines in batches and EVS disks

How many virtual machines can a three-node harvester environment support @ibrokethecloud


text:
Admin interface to send email to all subscribers

Depends on #233.
Once we have subscribers in the DB, we need to be able to email them about new features, preferably without having to run a SQL query manually.

Through what email client? some smtp client?

I don't know. Maybe Heroku supply a plug-in. Even a list of addresses would
be nice to start with.
On May 15, 2015 10:48 PM, "aviklai" notifications@github.com wrote:

Through what email client? some smtp client?
—
Reply to this email directly or view it on GitHub
https://github.com/hasadna/anyway/issues/251#issuecomment-102507812.

Flask admin sounds good, I think.

About the smtp account - can we use gmail (anyway.feedback)?
@galraij can we use a @hasadna.org.il address or something?

I think anyway@anyway.co.il will the the best. And yes, it's gmail.
ב-17 במאי 2015, בשעה 09:27, Daniel Hershcovich notifications@github.com כתב/ה:

About the smtp account - can we use gmail (anyway.feedback)?
@galraij can we use a @hasadna.org.il address or something?
—
Reply to this email directly or view it on GitHub.

Gmail is not great when sending a a lot of emails, we might marked as spammers.
I recommend using SendGrid, you can specify what email will be shown as sender and there free account have limit of 400 emails a day which I believe is enough for start.
and they have add-on for heroku - https://devcenter.heroku.com/articles/sendgrid

I added the plugin on Heroku.
On Wed, May 20, 2015 at 10:14 AM Samuel Regev notifications@github.com
wrote:

Gmail is not great when sending a a lot of emails, we might marked as
spammers.
I recommend using SendGrid, you can specify what email will be shown as
sender and there free account have limit of 400 emails a day which I
believe is enough for start.
and they have add-on for heroku -
https://devcenter.heroku.com/articles/sendgrid
—
Reply to this email directly or view it on GitHub
https://github.com/hasadna/anyway/issues/251#issuecomment-103787573.

@aviklai What is still required to complete this? Login credentials for admin?

Basicaly, It is completed. It just need to be tested with a real sendgrid account.
About login credentials for admin - it's already implemented.

We have SendGrid enabled on our Heroku now.
You can login at http://oway.org.il/admin/login/ and try :)
On Mon, May 25, 2015 at 4:09 PM Avi Klaiman notifications@github.com
wrote:

Basicaly, It is completed. It just need to be tested with a real sendgrid
account.
About login credentials for admin - it's already implemented.
—
Reply to this email directly or view it on GitHub
https://github.com/hasadna/anyway/issues/251#issuecomment-105229412.

Can someone send me (via email) the username and password?
It look great from the outside :)
ב-25 במאי 2015, בשעה 16:15, Daniel Hershcovich notifications@github.com כתב/ה:

We have SendGrid enabled on our Heroku now.
You can login at http://oway.org.il/admin/login/ and try :)
On Mon, May 25, 2015 at 4:09 PM Avi Klaiman notifications@github.com
wrote:

Basicaly, It is completed. It just need to be tested with a real sendgrid
account.
About login credentials for admin - it's already implemented.
—
Reply to this email directly or view it on GitHub
https://github.com/hasadna/anyway/issues/251#issuecomment-105229412.

—
Reply to this email directly or view it on GitHub.

I don't have it either.  I don't know if an admin user name and password were created at all. If not, I will do it today, after I figure out how to use heroku :)

@njenia is this ready for use? Is there documentation on how to send the emails?

The basic functionality of sending emails is working with sengrid. Currently it supports only sending plain text without file attachments.

Great. If more enhancement are needed, open a separate issue.

authors: aviklai danielhers galraij samuelregev

repo: hasadna/anyway


text:
Email/phone OTP sign-in on mobile

Slack (the collaboration tool) offers an option to sign in via an emailed access link if the password is too long or complicated to type on the mobile app.
This is a nice touch and we should have something like this in, say, the Funnel app, but we have to consider the security implications, especially if the email address is "stale" -- hasn't been used in a while and is likely to be invalid because the user has changed jobs. Essentially, all the same risks as mailing a password reset code.

Most Indian apps use SMS OTP-based login. This ticket should reflect that as well.

repo: hasgeek/lastuser


text:
MCER01 - Updated demo video and comparative analysis

Updated demo video and comparative analysis

@prernaadev01 noting this is a new standard when it's ready and will need a new folder called "Cercarbono"

repo: hashgraph/guardian


text:
bumping to 0.21.1

Description:
bump version to 0.21.1

Codecov Report
Patch and project coverage have no change.

Comparison is base (72212d7) 74.63% compared to head (5e7366a) 74.63%.

:exclamation: Current head 5e7366a differs from pull request most recent head aad065c. Consider uploading reports for the commit aad065c to get more accurate results

Additional details and impacted files
@@              Coverage Diff              @@
##           release/0.21    #1074   +/-   ##
=============================================
  Coverage         74.63%   74.63%
=============================================
  Files                30       30
  Lines              2030     2030
  Branches            386      386
=============================================
  Hits               1515     1515
  Misses              410      410
  Partials            105      105

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

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

repo: hashgraph/hedera-json-rpc-relay


text:
Complete TLS support

Problem
The SDK currently does not have complete TLS support.
Solution
Hedera Services will be adding TLS support in the 0.17.0 release to enable complete TLS support.
Alternatives
No response

Hedera services to add support for compatible cipher suite https://github.com/hashgraph/hedera-services/issues/2053

@steven-sheehy @Sean-Tedrow-LB @mehcode
TLS questions that come to mind:

Should TLS be the default connection?
Should you be able to turn off TLS?
If someone runs a local network on different ports than 50211 for plaintext and 50212 for TLS how should we handle that? Should the user be able to set which port is for plaintext and which is for TLS or should we simply not support TLS on any network that is not running on those ports? The point here is if someone creates a client for this local network and lets say wants to upgrade the connections to use TLS with something like Client.setUseTransportSecurity(true), would we implicitly try to change the port to 50212?

Should TLS be the default connection?

Not anytime soon at least. Still trying to get it to work.

Should you be able to turn off TLS?

Yes

If someone runs a local network on different ports than 50211 for plaintext and 50212 for TLS how should we handle that? Should the user be able to set which port is for plaintext and which is for TLS or should we simply not support TLS on any network that is not running on those ports? The point here is if someone creates a client for this local network and lets say wants to upgrade the connections to use TLS with something like Client.setUseTransportSecurity(true), would we implicitly try to change the port to 50212?

I don't think we need to worry about local nodes until we have permissionless nodes or maybe at least have community nodes. Long term it should use the address book, whether that's the static one checked in or one pulled from an API. I've previously created a ticket that should make it easy to determine: https://github.com/hashgraph/hedera-services/issues/1452

authors: SimiHunjan danielakhterov steven-sheehy

repo: hashgraph/hedera-sdk-java


text:
Adds Slither tool analysis report

Adds Slither tool analysis, docker files, and POC for ecrecover Slither detector.
Is dependant upon: https://github.com/hashgraph/hedera-smart-contracts/pull/726/files

Hi @nabialek-arianelabs, thanks for the nice work! With a quick scan through the CI, I noticed that there are two tests failed. Please follow the conventional commits guidelines to update the title of the PR to fix the PR Check / Title Check CI task. Another the DCO failed task, it looks like one of the commit in this PR didn't get signed off wit hthe Signed-off-by... message. One way to do it is to squash the commits and add the signature.

authors: nabialek-arianelabs quiet-node

repo: hashgraph/hedera-smart-contracts


text:
Add Repo Maintainers to CODEOWNERS file

Update CODEOWNERS to provide maintainers ownership of all files in their repos
Description:
Update this repositories .github/CODEOWNER file to ensure that the repository maintainer
group(s) have full control of the files in this repository.

No updates needed

repo: hashgraph/runner-images


text:
df-126 -> DELETE support for DoTValve WELL

This PR includes:

support for WELL DELETE
upgraded DoTValve unit test suite to handle server errors gracefully
expanded use of ValveException in DotValve for passing descriptive failure information to SOAP clients
improved test input XML files

This connects to #126

Summary of file changes
XML Files:

all xml files are changed to use distinct UID values (they overlapped before)

IStore:

IStore was upgraded with a deleteFromStore method per the WitsmlSpec.

StoreImpl:

added deleteFromStore method
added support for valve exception reporting in method responses.

DeleteFromStoreResponse:

created this based on the GetFromStoreResponse to structure responses to SOAP clients.

IValve:

made deleteObject, getObject, and createObject all throw ValveExceptions.
made deleteObject accept a QueryContext.

ValveException:

created this as a custom catch-all exception for shuttling error messages up to the StoreImpl for detailed SOAP client reporting.

ValveDelegator:

added deleteObject handler
transitioned from HttpResponse<JsonNode> responses to HttpResponse<String> responses because when the REST body returned is not valid json, the JsonNode implementation throws obscure parsing errors that are hard to understand.
implemented ValveException throwing in the other delegator methods.

DotValve:

implemented deleteObject
implemented valve exception throwing throughout
added DELETE WELL to getCap

DotValveTest:

added delete tests for 1311 and 1411 wells
added checking in all create tests that accept an already exists error from DoT as a valid, test-passing behavior
updated all UID checks with the updated values in the test files

repo: hashmapinc/Drillflow


text:
add mapKeys

this PR adds mapKeys to the API, following the implementation provided by containers.
I'm not an expert in performances and on the internals of unordered-containers, so feel free to refuse this if it is not up to the standards of the library

@sjakobi I addressed your recommendations. Should be ready now


text:
Provide ghc-modi transport?

Would there be any merit in having hie expose a transport that emulates the one ghc-mod uses in its daemon mode?
PROS

It would allow quick integration into various existing IDEs

CONS

We would be stuck with it forever
There is a recognition that it is not an ideal way of doing things. (True?)

Okay, first of, IMO ghc-mod legacy interactive interface is horribly broken beyond repair. It doesn't support half of what CLI interface does, and has some problems with argument parsing. It is far from ideal.
But it is widely supported in editors. If you mean HIE to be a drop-in replacement, it is a safe bet. I believe legacy interactive interface won't change much, at least, so it's not like you will have to spend much effort maintaining it.

I guess freezing a bad interface is not a good idea, especially as changes will have to happen in the IDEs using it to bring in the other plugins available.

Freezing a bad interface is a fine compatibilty compromise, provided it stays frozen. No fixes, no new features, nothing. That way, legacy software can still work, while newer versions can (and should) use another interface altogether.
In any case, it's up to you if you want to support it. In all honesty, if given an opportunity to switch to a better interface, I won't think twice.

Well, if it freezes, they may as well stay with ghc-mod, so I guess no real
motivation for doing this.
On Sun, Dec 6, 2015 at 9:11 PM, Nikolay Yakimov notifications@github.com
wrote:

Freezing a bad interface is a fine compatibilty compromise, provided it
stays frozen. No fixes, no new features, nothing. That way, legacy software
can still work, while newer versions can (and should) use another interface
altogether.
In any case, it's up to you if you want to support it. In all honesty, if
given an opportunity to switch to a better interface, I won't think twice.
—
Reply to this email directly or view it on GitHub
https://github.com/haskell/haskell-ide-engine/issues/125#issuecomment-162337638
.

authors: alanz lierdakil

repo: haskell/haskell-ide-engine


text:
cannot satisfy -package-id base-4.10.1.0

On my machine:
$  stack new moo
$  cd moo
$  stack build
$  code .

In the Haskell HIE (moo) output, I get this error:
hie: <command line>: cannot satisfy -package-id base-4.10.1.0
    (use -v for more information)

I am using Macos

Similarly for one of my bigger projects:
Using hoogle db at: /Users/jky/.hoogle/default-haskell-5.0.17.hoo
hie: <command line>: cannot satisfy -package-id amazonka-1.5.0-75emjYGGvkjLemS4nvxn4p:
    amazonka-1.5.0-75emjYGGvkjLemS4nvxn4p is unusable due to missing dependencies:
      amazonka-core-1.5.0-CLe3zZeGiNEHP74Gy81THg base-4.10.1.0 conduit-1.2.13.1-J1BFdB3Hq6fHXjEWX9tRjq conduit-extra-1.2.3.2-9rRJTLz14cgLsNkwhYfzn3 directory-1.3.0.2 exceptions-0.8.3-CYMTujxEbkkJnOJ7pW82ZD http-conduit-2.2.4-APl7BW4kI77D9KJHMd6cLS ini-0.3.5-FuJb9pz94NI53ott3rpubZ mmorph-1.1.1-JSXAlwXaEvB9wEd1iGFnPP monad-control-1.0.2.3-KW4P5rxfhfj5WtFbu3Ojsg mtl-2.2.2-8XubxMJDT8QLsstvlNotkc resourcet-1.1.11-LMceVXHmLWt4je3CoOiraW retry-0.7.6.1-JmJGyb2fxW41GGWzawOqDd text-1.2.2.2-9VTsh6V7U7hpagw2HDvpZ transformers-0.5.2.0 transformers-base-0.4.4-CrsDENFNf7rEcT9CB0YGwO transformers-compat-0.5.1.4-EAh8Ccrgitz4vTZtbTPyCM
    (use -v for more information)

what version of stack are you using? what resolver do you end up with in the project?

This is for the bigger project:
$ pwd
/Users/jky/wrk/arbor-networks/gan-feeds-client
 ~/wrk/arbor-networks/gan-feeds-client   master 
$ head -n 1 stack.yaml
resolver: lts-10.10
 ~/wrk/arbor-networks/gan-feeds-client   master 
$ stack --version | head
Version 1.7.1 x86_64
Compiled with:
- Cabal-2.2.0.1
- Glob-0.9.2
- HUnit-1.6.0.0
- QuickCheck-2.11.3
- StateVar-1.1.1.0
- aeson-1.2.4.0
- aeson-compat-0.3.7.1
- annotated-wl-pprint-0.7.0

This was for the stack generated template project:
$ pwd
/Users/jky/wrk/arbor-networks/moo
$ grep "^resolver" stack.yaml
resolver: lts-11.8

This is for the bigger project:
$ pwd
/Users/jky/wrk/arbor-networks/gan-feeds-client
$ head -n 1 stack.yaml
resolver: lts-10.10

haskell-ide-engine was built with:
$ git clone https://github.com/haskell/haskell-ide-engine --recursive
$ cd haskell-ide-engine
$ make build-all

Looks like I needed to set this:
"languageServerHaskell.useHieWrapper": true

Can the documentation be updated to include this?
Thanks!

I'm also okay to close this ticket.

same problem working with LanguageClient-neovim, how do I make the equivalent changes there of "languageServerHaskell.useHieWrapper": true

@soulomoon afaik wrapper is a part of vscode plugin. In neovim you have to select proper hie version yourself.
In case you're working only on stack-based projects (like me), installing hie via make build-copy-compiler-tool and using stack exec hie --lsp as start command for language client in init.vim will put decision on stack's shoulders and work automagically.

Perhaps we should write the wrapper in haskell as an exe, so it can be shared among clients.  This is basically the simplest version of the concierge function we have discussed before in the issues.

See https://github.com/haskell/haskell-ide-engine/pull/627

authors: Anrock alanz newhoggy soulomoon


text:
Add example code for haskellforall.com blog post

http://www.haskellforall.com/2018/10/detailed-walkthrough-for-beginner.html
As demonstrated at haskellX 2018.
A lot of this is plumbing through access to the VFS to be able to get the source text for a LSP Range, which is useful for all plugins anyway.
The actual work is in HfaPlugin.hs, where only the first 75 lines are for the plugin the rest is the code from @Gabriel439 's blog post.

Does anyone know what is wrong with the appveyor build? It seems stack is no longer installed?


text:
话说device_id是怎么获取的？

我在美的美居的app里找不到这个值……

登录的还是物理设备的?
黄巍 @.***> 于2023年7月2日周日 13:12写道：

我在美的美居的app里找不到这个值……
—
Reply to this email directly, view it on GitHub
https://github.com/hasscc/meiju/issues/5, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACOVBX6QK5AHTKB6PE7HSC3XOD7MZANCNFSM6AAAAAAZ3HAP6M
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

就是readme.md里有这样一段config嘛——
meiju:
  # Single account
  username: 18866668888 # Username of Meiju APP (美的美居)
  password: abcdefghijk # Password
  devices:
    - device_id: 160123456789001
      host: 192.168.1.101
    - device_id: 160123456789002
      host: 192.168.1.102

这里的160123456789001，我理解应该是一台物理设备比如洗衣机，这个160123456789001应该怎么拿呢？

这好像是那个脚本解码来的
在 2023年7月4日星期二，黄巍 @.***> 写道：

就是readme.md里有这样一段config嘛——
meiju:
Single account
username: 18866668888 # Username of Meiju APP (美的美居)
password: abcdefghijk # Password
devices:
- device_id: 160123456789001
host: 192.168.1.101
- device_id: 160123456789002
host: 192.168.1.102
这里的160123456789001，我理解应该是一台物理设备比如洗衣机，这个160123456789001应该怎么拿呢？
—
Reply to this email directly, view it on GitHub
https://github.com/hasscc/meiju/issues/5#issuecomment-1619526453, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ACOVBX3OKHRNJ7GELWONXRTXOOUADANCNFSM6AAAAAAZ3HAP6M
.
You are receiving this because you commented.Message ID:
@.***>

先配置账号密码启动：

meiju:
  # Single account
  username: 18866668888 # Username of Meiju APP (美的美居)
  password: abcdefghijk # Password

通过HA系统日志可以看到账号下的所有设备

authors: RimoChan al-one vividmuse

repo: hasscc/meiju


text:
[automated] Re-Apply Coding Standards

Automated changes by create-pull-request GitHub action

Codecov Report

Merging #125 (648683e) into main (8bef6a1) will not change coverage.
The diff coverage is 80.00%.

@@            Coverage Diff            @@
##               main     #125   +/-   ##
=========================================
  Coverage     94.34%   94.34%
  Complexity      602      602
=========================================
  Files           132      132
  Lines          2407     2407
=========================================
  Hits           2271     2271
  Misses          136      136

Flag
Coverage Δ

phpunit
94.34% <80.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...bundle/src/DependencyInjection/HasuraExtension.php
94.66% <0.00%> (ø)

src/graphqlite-bridge/src/ScalarType/Timestamp.php
100.00% <ø> (ø)

src/metadata/src/YamlOperator.php
94.51% <87.50%> (ø)

...rc/laravel/src/ServiceProvider/Concerns/Sailor.php
97.43% <100.00%> (ø)

Continue to review full report at Codecov.

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

authors: codecov-commenter vuongxuongminh

repo: hasura-extra/hasura-extra


text:
gitkube service type ClusterIP cannot be accessed from outside cluster. If this was intended, add remote manually

Whats the deal?
gitkube remote create -f remote.yaml
INFO[0001] remote myremote created
INFO[0001] waiting for remote url
FATA[0002] gitkube service type ClusterIP cannot be accessed from outside cluster. If this was intended, add remote manually
I am on aws eks....
Fix your tutorial so as not to waste other peoples time.

@davidmontgom Like the error mentions, ClusterIPs are not intended to be used with gitkube because you cannot access them from outside the cluster. How will you do git push from your local dev if you don't have an accessible IP?

authors: davidmontgom tirumaraiselvan

repo: hasura/gitkube


text:
[HxGrid] No overload for 'method' matches delegate 'delegate'

When I try to use HxGrid on different pages with different data sources I get the compiler error CS0123: "No overload for 'method' matches delegate 'delegate'"

Can you provide me with some repro code? This usually originates from incorrect syntax in .razor file.

This is the HXGrid in Frontend code:
<HxGrid TItem="ToolHistory" Responsive="true" DataProvider="GridDataProviderToolData" PageSize="10">
<Columns>
<HxGridColumn TItem="ToolHistory" HeaderText="Date" ItemTextSelector="@(item => item.tool_no)" SortKeySelector="@(item => item.tool_no)" IsDefaultSortColumn="true" SortDirection="Havit.Collections.SortDirection.Descending" />
</Columns>
</HxGrid>

This is the code snippet from the code section:
private async Task<GridDataProviderResult<ToolDataRes>> GridDataProviderToolData(GridDataProviderRequest<ToolDataRes> request)
    {
        return  request.ApplyTo(toolDataList);
    }

The toolDataList comes from
    protected override async Task OnInitializedAsync()
    {
        toolDataList = await Http.GetFromJsonAsync<ToolDataRes[]>("https://funcmytooldev.azurewebsites.net/api/GetToolData?code=YqZiVvUAhSgiEo1Orq8aFcVBN6OKFTRxUXpO86yHfEUkAzFuHHraqQ==&clientId=MyTool_Frontend");
      }

Hope this helps. :)

The TItem type parameter of HxGrid and the DataProvider method (GridDataProviderToolData) must match.
You are using ToolDataRes for the DataProvider.

Thanks. That solved my issue. :)

authors: basdie hakenr


text:
Double tooltip shown for a button

Hi,
I've discovered this during development, before I managed to reserve more space for the button.
Consider a button that has truncated text and is disabled in the same time. We should try to avoid showing 2 tooltips at once.

@jvorcak I suggest we should only the disabled tooltip. WDYT?

authors: aigoncharov jvorcak

repo: hazelcast/frontend-shared


text:
Mixed Multimap Implementation

Added the mixed multimap implementation and test.

Test PASSed.

authors: devOpsHazelcast ihsandemir

repo: hazelcast/hazelcast-cpp-client


text:
Path to pretrained model

Which model shall i include in path when I want to test results for both static and dynamic objects in single frame.

The models for static and dynamic layouts are separate so you can't use both at once for KITTI dataset. You'll need to run them separately. We'll provide the combined model for running it on Argoverse shortly.


text:
Make style injection configurable

I've been trying to make the component work inside a shadowRoot web-component but it injects the styles into the document.head tag.
It'd be nice if style injection could be controlled. For example, emotion has a provider that will configure all emotion based components in the tree: https://emotion.sh/docs/cache-provider

Sorry, It's been long time and since now tsup based on esbuild does this automatically so customisation might not be possible
the main reason I kept styles auto inject so it will be easy for anyone to get started. we can revisit this if we have any other simpler way that removes barrior of css import
closing this w/ won't fix

authors: harshzalavadiya jemmyw

repo: hc-oss/react-multi-select-component


text:
chore: build with vcpkg & upgrade deps version.

boost: unknown -> 1.79.0
libgit2: 1.0.0 -> 1.4.2
rapidjson: 1.0.2 -> 1.1.0

Also submit to upstream: https://github.com/cmarcusreid/git-status-cache/pull/28

repo: hcoona/git-status-cache


text:
Fix klayout build on macos

This fixes the klayout package so that it now builds properly on osx-arm64.

Note that I'm not sure why build/pymod/*.dylib isn't copied over to bin-release/pymod/, but it seems to be copied on the Linux version. So I added the final cp for only that platform.

Note that I'm not sure why build/pymod/*.dylib isn't copied over to bin-release/pymod/, but it seems to be copied on the Linux version. So I added the final cp for only that platform.

Maybe @klayoutmatthias as a clue?

I added a symlink to klayout, which allows it to be used from the command line.

Looks like the osx build failed with:
2023-02-18T11:44:41.6904360Z ld: warning: -pie being ignored. It is only used when linking a main executable
2023-02-18T11:44:41.7225230Z ld: in '/Applications/Xcode_14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk/System/Library/Frameworks//ColorSync.framework/Versions/A/ColorSync.tbd', unsupported tapi file type '!tapi-tbd' in YAML for architecture x86_64
2023-02-18T11:44:41.7241560Z clang-14: error: linker command failed with exit code 1 (use -v to see invocation)
2023-02-18T11:44:41.7265570Z make[2]: *** [Makefile:384: ../../tl/libtl_tests.0.28.5.dylib] Error 1
2023-02-18T11:44:41.7284780Z make[1]: *** [Makefile:76: sub-unit_tests-make_first] Error 2
2023-02-18T11:44:41.7296980Z make: *** [Makefile:74: sub-tl-make_first] Error 2

Conda seems to be adding -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -mmacosx-version-min=10.15 on my local build, and I can't figure out where that's coming from.
What's even more annoying is that the environment doesn't seem to have those variables anywhere. If I modify build.sh to use the correct values, it appears twice:
    export CXXFLAGS="${CXXFLAGS} -mmacosx-version-min=${MACOSX_DEPLOYMENT_TARGET} -D_LIBCPP_DISABLE_AVAILABILITY -isysroot ${CONDA_BUILD_SYSROOT}"
    export CFLAGS="${CFLAGS} -mmacosx-version-min=${MACOSX_DEPLOYMENT_TARGET} -D_LIBCPP_DISABLE_AVAILABILITY -isysroot ${CONDA_BUILD_SYSROOT}"

becomes:
...
-mmacosx-version-min=11.0 \
-D_LIBCPP_DISABLE_AVAILABILITY \
-isysroot /Users/sean/Code/EDA/sdk/MacOSX10.9.sdk \
-std=c++17 \
-fvisibility=hidden \
-std=c++17 \
-fvisibility=hidden \
-std=gnu++1z \
$(EXPORT_ARCH_ARGS) \
-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk \
-mmacosx-version-min=10.15
...

...also, I'm not sure where it's getting MACOSX_DEPLOYMENT_TARGET=10.15 or MACOSX_DEPLOYMENT_TARGET=11.0 from. Both ci/conda_build.config.yaml and the build environment set MACOSX_DEPLOYMENT_TARGET=10.9, and that's what Conda seems to imply is the default:
https://docs.conda.io/projects/conda-build/en/latest/user-guide/environment-variables.html#env-vars

Note that I'm not sure why build/pymod/*.dylib isn't copied over to bin-release/pymod/, but it seems to be copied on the Linux version. So I added the final cp for only that platform.

Maybe @klayoutmatthias as a clue?

Honestly, I have never tested pymod generation on MacOS. Mainly because MacOS is not my home turf. The installation basically is generic, but maybe it needs to be specialized for MacOS.

I discovered that Qt ignores standard CFLAGS and CXXFLAGS and instead uses its own QMAKE_CFLAGS and QMAKE_CXXFLAGS.
I also discovered that MacOS 11.0 was the first version that supported arm64, so I bumped the minimum version up to that.
Note that 10.11 is the first version that supported Metal, so we would need to use that at a minimum in order to get support for klayout.
Additionally, it looks like it might be possible to build osx-arm64 from osx-x86_64 as documented at https://conda-forge.org/blog/posts/2020-10-29-macos-arm64/ -- note that they also build for macos 11.0 in there.

Additionally, it looks like it might be possible to build osx-arm64 from osx-x86_64 as documented at https://conda-forge.org/blog/posts/2020-10-29-macos-arm64/ -- note that they also build for macos 11.0 in there.

Filed https://github.com/hdl/conda-eda/issues/299 to discuss arm64 builds.

It builds and passes tests! \o/

Looks like python3.10 job is failing when trying to install python >= 3.10 as a host dep from conda running on python 3.7.

I'll just remove that, then...

Merging since both jobs passes (not sure if we want to suffix the job with -python38 for consistency).

authors: klayoutmatthias proppy xobs

repo: hdl/conda-eda


text:
can I pass a letter and showed as Image ?

is there any way that I can pass a letter in case of error to be shown inside the image view?

Actually, I also want this type of functionality. Like in the phone application when we save the contact without a photo then the app automatically saved the first letter of the contact name with some background color.

There's no support for this built into the library as it focuses on working with images/bitmap and creating a bitmap of a letter in front of a colored background just to get a circle shape would be very inefficient. If you still want to go down that route, you can use a simple TextView with a a background color and then create a Bitmap from it, this Stackoverflow question might be a good starting point. The created Bitmap can then be used as source for your CircleImageView.

authors: Abdelsattar deepak-prajapatii hdodenhof

repo: hdodenhof/CircleImageView


text:
打不开

手机浏览器 提示版本获取不到，就没了

有个小飞机的按钮，需要在后台发布下。

authors: answer-huang sknown


text:
Building python binding and packaging

Description
I'm building python binding; pyoperon from source with this install
example. link. After several partially solved dependency
dependency issues built successfully with some modifications in CMakeLists.txt.
Testing current build with python package with python -c "from operon.sklearn import SymbolicRegressor"
giving this error.

 File "<string>", line 1, in <module> File "/github/home/miniconda/envs/operon-env/lib/python3.7/site-packages/operon/__init__.py", line 4, in <module> from ._operon import * ImportError: /github/home/miniconda/envs/operon-env/lib/python3.7/site-packages/operon/_operon.cpython-37m-x86_64-linux-gnu.so: undefined symbol: _ZN3fmt2v76detail7vformatENS0_17basic_string_viewIcEENS0_11format_argsE Error: Process completed with exit code 1.

Modification on CMakeList.txt

Without this change build failed with /__w/zbuild/zbuild/operon/src/core/dataset.cpp:11:10: fatal error: vstat.hpp: No such file or directory  11 | #include "vstat.hpp"   |          ^~~~~~~~~~~ compilation terminated.

FetchContent_Declare(
vstat
GIT_REPOSITORY https://github.com/foolnotion/vstat
GIT_TAG 1ae255167708916cf1f9e494769ac978fdffd888
DOWNLOAD_DIR ${PROJECT_SOURCE_DIR}/thirdparty/vstat
SOURCE_DIR ${DOWNLOAD_DIR}
)

Without this change build cant find pratt.hpp

FetchContent_Declare(
infix_parser
GIT_REPOSITORY https://github.com/foolnotion/pratt-parser-calculator
GIT_TAG f2156e72a598763dc0be8be97d7ce765e61acfe9
DOWNLOAD_DIR ${PROJECT_SOURCE_DIR}/thirdparty/parser
SOURCE_DIR ${DOWNLOAD_DIR}
)

Conda environment

name: operon-env
channels:

conda-forge
dependencies:
python=3.7.1
cmake=3.19.1
pybind11=2.6.1
eigen=3.4.0
fmt=7.1.3
ceres-solver=2.0.0
taskflow=3.1.0
openlibm
cxxopts

Build command
cmake .. -DCMAKE_BUILD_TYPE=Release  -DBUILD_PYBIND=ON -DUSE_OPENLIBM=ON -DUSE_SINGLE_PRECISION=ON -DCERES_TINY_SOLVER=ON
make VERBOSE=1 -j pyoperon
make install

Hi,
Thanks for making the issue. For the first error it seems like either some library is missing or the library versions don't match. Could you try to post the output of ldd _operon.cpython-37m-x86_64-linux-gnu.so?
For the second error, unfortunately for the time being the dependencies are not so easy to handle. We see here that an upstream change in the structure of the vstat project ended up breaking the build.
We are working on refactoring the build system, extracting the python module into a separate project and improving the dependency management. For now please adjust the include path manually like you did.
Best,
Bogdan

Building should be easier now - see BUILDING.md.
Feel free to reopen if any issues remain.

authors: foolnotion q-eldar

repo: heal-research/operon


text:
import for Swift?

I added this import to my bridging header:
#import <RHAddressBook/AddressBook.h>
but XCode complains that it can't find various types.  Does anyone have RHAddressBook working with a Swift app?

SOLUTION:
import RHAddressBook

repo: heardrwt/RHAddressBook


text:
Endless create/leave loop when TZ changed to a TZ run that is not enabled.

commit: feba50097719754e9b0ce67bf0ca2d4b3011fd8a
It will create game, go to the TZ that is not enabled on the TZ list. and show game completed once it took waypoint there then leave and do again till the hour is over. If i restart bot it will resume as normal and skip this TZ since its not enabled. The current TZ during this was stony field (this was not enabled, but the prior hours TZ was jail, which is enabled.)
+skip all runs and only do tz when available is enabled.
time=13:28:03 level=INFO msg="Running: TerrorZone Run: Stony Field, Jail Level 1, Jail Level 2, Jail Level 3"
time=13:28:03 level=DEBUG msg="Loading screen detected, waiting until loading screen is gone"
time=13:28:08 level=DEBUG msg="Load completed, continuing execution"
time=13:28:08 level=DEBUG msg="Checking for character corpse..."
time=13:28:08 level=DEBUG msg="Character corpse not found :D"
time=13:28:08 level=DEBUG msg="Checking for items to identify..."
time=13:28:08 level=DEBUG msg="No items to identify..."
time=13:28:08 level=DEBUG msg="Belt Stats Health: 8/8 healing, 4/4 mana, 4/4 rejuv."
time=13:28:08 level=DEBUG msg="Checking for items to stash..."
time=13:28:08 level=DEBUG msg="No items to stash..."
time=13:28:08 level=DEBUG msg="Checking for items to stash..."
time=13:28:08 level=DEBUG msg="No items to stash..."
time=13:28:08 level=DEBUG msg="TZ area skipped" area="Stony Field"
time=13:28:12 level=DEBUG msg="CTA found: swapping weapon and casting Battle Command / Battle Orders"
time=13:28:12 level=DEBUG msg=Buffing...
time=13:28:15 level=DEBUG msg="Reached area" area="Stony Field"
time=13:28:15 level=DEBUG msg="No items detected, waiting a bit and will try again" waitMs=1000
time=13:28:16 level=INFO msg="Run TerrorZone Run: Stony Field, Jail Level 1, Jail Level 2, Jail Level 3 finished, length: 13.20s" ```

I have similar problem.
TZ is in Arreat Plateu. I noticed that my nova sorc stucks a lot of times on the map, spelling a lot of nova when there is a lot of fire in area and doesnt teleport to new place. So I wanted to disable Arreat Plateu in config. After that bot creates new game, sorc goes to Arreat WP, casts all  buffs and quits game.
time=11:53:46 level=INFO msg="Waiting for character selection screen..."
time=11:54:02 level=INFO msg="Character selection screen found"
time=11:54:02 level=INFO msg="Selecting character..."
time=11:54:02 level=INFO msg="Character found"
time=11:54:06 level=DEBUG msg="Fetching map data..."
time=11:54:09 level=DEBUG msg="Fetch completed" ms=3708
time=11:54:09 level=INFO msg="Starting Game #0. Run list: TerrorZone Run: Arreat Plateau, Hell2, pit"
time=11:54:09 level=INFO msg="Running: TerrorZone Run: Arreat Plateau, Hell2"
time=11:54:10 level=DEBUG msg="Loading screen detected, waiting until loading screen is gone"
time=11:54:12 level=DEBUG msg="Load completed, continuing execution"
time=11:54:12 level=DEBUG msg="Checking for character corpse..."
time=11:54:12 level=DEBUG msg="Character corpse not found :D"
time=11:54:12 level=DEBUG msg="Checking for items to stash..."
time=11:54:12 level=DEBUG msg="Checking for items to identify..."
time=11:54:12 level=DEBUG msg="No items to identify..."
time=11:54:12 level=DEBUG msg="Belt Stats Health: 4/4 healing, 3/4 mana, 8/8 rejuv."
time=11:54:12 level=DEBUG msg="Checking for items to stash..."
time=11:54:12 level=DEBUG msg="Checking for items to stash..."
time=11:54:12 level=DEBUG msg="TZ area skipped" area="Arreat Plateau"
time=11:54:16 level=DEBUG msg="CTA found: swapping weapon and casting Battle Command / Battle Orders"
time=11:54:16 level=DEBUG msg=Buffing...
time=11:54:20 level=DEBUG msg="Reached area" area="Arreat Plateau"
time=11:54:20 level=DEBUG msg="Clearing TZ area" area=Hell2
time=11:54:20 level=DEBUG msg="Destination area not found" area=Hell2
time=11:54:20 level=WARN msg="Game finished with errors, reason: unrecoverable error occurred, game can not continue: attempt limit reached on step: InteractEntranceStep: area Hell2 [126]  not found. Game total time: 10.78s" supervisor=MoooMooo mapSeed=1502982702
time=11:54:23 level=INFO msg=Stopping... configuration=MoooMooo
time=11:54:23 level=INFO msg="Finished stopping" configuration=MoooMooo
time=11:54:30 level=ERROR msg="Error creating new game: error creating game! Timeout"

repo: hectorgimenez/koolo


text:
Fork markdown-it-toc-done-right

While working on https://github.com/hedgedoc/react-client/issues/815, we noticed that the package markdown-it-toc-done-right needed an update to work for us. This was implemented, but never merged. I guess we don't have a choice, but to fork this into hedgedoc/markdown-it-plugins.

Part of this could be https://github.com/hedgedoc/hedgedoc/issues/2946

Reason of forking: https://github.com/nagaozen/markdown-it-toc-done-right/pull/66

authors: DerMolly mrdrogdrog

repo: hedgedoc/markdown-it-plugins


text:
Default props className to form-horizontal

Why do you default the Form className to form-horizontal ?
Form.defaultProps = {
    model: {},
    className: 'form-horizontal',
    validationEvent: 'onChange',
    onInvalidSubmit: function onInvalidSubmit() {}
};

Adding default classname was an oversight.
As for you PR #6, I'll do some testing to see if removing action prop has any side effects and will merge it tomorrow.
Thanks!

Alright thanks.
As for the action prop, you could default it when it's not passed as a prop.

authors: LoicUV heilhead

repo: heilhead/react-bootstrap-validation


text:
Bug in CTA

public class IntroSlideActivity extends IntroActivity {

@Override
protected void onCreate(Bundle savedInstanceState){
    setFullscreen(true);
    super.onCreate(savedInstanceState);
    showSlide();
}

private void showSlide(){
    addSlide(new SimpleSlide.Builder()
            .title("Test title")
            .description("Test description")
            .buttonCtaLabel("Skip")
            .buttonCtaClickListener(v -> System.out.println("CTA button clicked"))
            .background(R.color.startupScreen1)
            .build());
    setButtonNextVisible(true);
}}

It appears that the CTA click Listener is not called at all because i am not seeing "CTA button clicked" in my console system out.

Bug happens on Nexus 5x(emulator) on Android 8.0 and Xperia Z3 on Android 6.0.1

CTA Button click leading to app close

Is it crashing with the app crash error alert? Or it could be that there is no activity being called on after the intro is done. After the intro is finished or skipped it automatically takes the user back to the previous activity.

yea, my bad. I forgot about this issue. Anyway, I have fixed this issue. I made a mistake by assuming the intro slides is a separate activity by itself. Thanks.

repo: heinrichreimer/material-intro


text:
fix labels rotation with x_reflection

fix labels rotation with x_reflection

@joamatab Thanks for the fix!

authors: heitzmann joamatab

repo: heitzmann/gdspy


text:
Specify a tag for vddl-draggable

Currently the <vddl-draggable> renders as a <div>.
Would it be possible to specify the rendered tag with a custom directive :tag="button" for exemple?
Thanks in advance 🙂

Sorry, it is not supported now. 😢

@hejianxian I just made a pull request to include it ;)

repo: hejianxian/vddl


text:
Hotspot b58 Addresses
112N31kFvKGbHaS5raUrzDqcBqecGiRuyd9MYtBLKr7wHB7ab6RF
112MEiEhsStFRSpE3M7sFAFQxtTj65xmaCcgkkwa3bH98bqgoMnm
112VuQtEojpWRjXfKNynMupYjaZRrjCb6W1xByzi4rWiWrEhgroQ

Discord Handle
#6967
Reason(s)
Spoofing, most of Hs in this zone are spoofing. Please investigate!

UPDATE!!! from yesterday, the situation is this.... BAN THEM PLZ

!

UPDATE2!!
More hotspots flowers....

More comes... :/

Update

Heltec Automation and Midas cluster combo

repo: helium/denylist


text:
[Bug]: Maker onboarded hotspot qty seems to have broken

What happened?
The counter on the makers tab seems to have got stuck and has not incremented in some time, despite hotspots being added.
Tried on several devices and browsers and seems to persist on all.
URL
https://explorer.helium.com/hotspots/makers
What browsers are you seeing the problem on?
Chrome, Safari, Firefox
Do you see the issue on Mobile or Desktop?
Mobile, Desktop
Relevant log output
No response

looks like we can use the activity/count route and look up add_gateway_v1 and sum assert_location_v1 and assert_location_v2 to tabulate quantity
https://api.helium.io/v1/accounts/13Zni1he7KY9pUmkXMhEhTwfUpL9AcEV1m2UbbvFsrU9QPTMgE3/activity/count

Update: explorer does use those routes, but it updates on a 10 minute interval. However it seems to not be updating consistently so we'll have to look at this in explorer-api
cc @allenan

It's been stuck for at least ~12 hours or so now I think. Didn't screenshot the exact time but it was around 6am this morning I looked and now 6pm UK time and hasn't changed for any vendor.

I'm not disagreeing that something's wrong.. just that the person that can look is out today.

@cokes518 no didn't think you were disagreeing, just wanted to note roughly how long it had been stuck for was all 🙂

checking in. we're still investigating. we think it's because calchip's maker account's activity feed is returning 404. unfortunately there are larger API issues that needs addressing first.

The above calchip issue resolved things but now, 24hours later - it appears that maker numbers has remained the same again

this is now fixed.

this is now fixed.

I'm sorry - this is not fixed.
The 'Hotspots added' numbers at https://explorer.helium.com/hotspots/makers has been the same since August 13th.
The 'Hotspots added' numbers at https://explorer-v1.helium.com/hotspots shows numbers that reflect around July 19th

@allenan the data has updated, but still stale.

API is returning 53506 for calchip

https://api.helium.io/v1/accounts/13ENbEQPAvytjLnqavnbSAzurhGoCSNkGECMx7eHHDAfEaDirdY/activity/count
Explorer:

authors: cokes518 esticle shawaj

repo: helium/explorer


text:
[Hyperparameter Inquiry] Can't Reproduce ACE05 Results

Hi Haoyu,
Nice work on this MRE one-pass! I noticed that the commands in README.md are for SemEval 2018. Do you know what are the commands that you run ACE05 with? (We are especially curious about the hyperparameters.)
Thank you in advance for your information!
Best,
Zhijing

The ACE dataset is using the same set of hyper parameter as SemEval except for the number of epochs is 15 instead. However, due to the nature of the randomness of BERT finetuning, we simply run all experiment for 5 times and pick up the best performed one.

authors: helloeve zhijing-jin

repo: helloeve/mre-in-one-pass


text:
Image and content overlapped

In the group feed section, Image and content got sometimes overlapped! check image attahced

Oh yeah, thank you @aboullaite. I'll fix that soon.

PR to fix this issue, wait until it has been merged and deployed https://github.com/hellowin/kanca/pull/150

It's already deployed @aboullaite. I'll close this issue. Feel free to re-open it if you still found related bug.

authors: aboullaite hellowin

repo: hellowin/kanca


text:
Fixes #1341 -- update Jenkins chart documentation

@lachie83
@viglesiasce
What this PR does / why we need it:
Update values.yml documentation on using LoadBalancer type of
Service in a secure way by adding required annotations. This creates
an internal LoadBalancer with locked down rules on allowed CIDR ranges
via annotations.
The default setting - ClusterIp - only works inside the same cluster.
Which issue this PR fixes

fixes #1341

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed

Linting is failing because I did not bump version -- is that required for documentation update?

repo: helm/charts


text:
[stable/kube-ops-view] add apiVersion

Adding the apiVersion for chart.yaml
to fix the issue: https://github.com/helm/charts/issues/13763
Checklist

[x] DCO signed
[x] Chart Version bumped
[x] title of the PR contains starts with chart name e.g. [stable/chart]

/assign @mattfarina

/lgtm

authors: cpanato maorfr


text:
[stable/nextcloud] Bump nextcloud image to version 16.0.3

What this PR does / why we need it:
Version bump
Checklist

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/chart])

/ok-to-test

/lgtm

authors: chrisingenhaag pfuhrmann


text:
[stable/redmine] Add JSON Schema & standardize ingress configuration

Signed-off-by: juan131 juan@bitnami.com
Is this a new chart
No
Description of the change
This PR includes a basic JSON schema for the Redmine chart. It doesn't cover all the possible values of the chart but just the ones that, in my opinion, are more likely to be modified.
This is valid for Helm 3 to validate some values and, at the same time, for Kubeapps to render a simple form so the chart containing it is easier to configure and deploy. See https://github.com/kubeapps/kubeapps/blob/master/docs/developer/basic-form-support.md for more information.
This is an example of the file rendered by Kubeapps:

This PR also standardizes the way we configure Ingress.
Checklist

[x] Chart version bumped in Chart.yaml according to semver.
[x] Title of the PR starts with chart name (e.g. [stable/chart])

/assign @carrodher @andresmgot

/hold
Blocking this PR since the syntax below in the hidden section is not supported yet (see https://github.com/kubeapps/kubeapps/blob/master/docs/developer/basic-form-support.md#subsections):
    "externalDatabase": {
      "type": "object",
      "title": "External Database Details",
      "description": "If MariaDB is disabled. Use this section to specify the external database details",
      "form": true,
      "hidden": "mariadb.enabled and postgresql.enabled",

/hold

No backwards incompatibility introduce since the commands below work:
$ helm install stable/redmine --name redmine \
    --set redminePassword=myredminepass \
    --set mariadb.rootUser.password=myredminedbpass \
    --set databaseType.mariadb=true \
    --version 13.6.0
$ helm upgrade redmine stable/redmine \
    --set redminePassword=myredminepass \
    --set mariadb.rootUser.password=myredminedbpass \
    --set databaseType="mariadb" \
    --version 13.7.0

/hold cancel

/retest

@juan131  needs rebase

@sameersbn rebase done

/lgtm


text:
"my chart" has no deployed releases error - if history is full and no revision is in deployed status

Output of helm version:
version.BuildInfo{Version:"v3.7.1", GitCommit:"1d11fcb5d3f3bf00dbe6fe31b8412839a96b3dc4", GitTreeState:"clean", GoVersion:"go1.17.2"}

Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.4", GitCommit:"b695d79d4f967c403a96986f1750a35eb75e75f1", GitTreeState:"clean", BuildDate:"2021-11-17T15:41:42Z", GoVersion:"go1.16.10", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.0", GitCommit:"af46c47ce925f4c4ad5cc8d1fca46c7b77d13b38", GitTreeState:"clean", BuildDate:"2020-12-08T22:31:47Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.):  kind
We're experiencing situations where helm fails to upgrade a release with
Error: UPGRADE FAILED: "my-hello" has no deployed releases

if the history is full (default capacity is 10), and no revision in the history is in status deployed.
I believe the error is generated as follows:
When helm performs the upgrade, it creates a new release in the storage https://github.com/helm/helm/blob/main/pkg/action/upgrade.go#L323,
and if the recorded history has reached max capacity (maxHistory), it tries to remove the least recent release to make space for the new one: https://github.com/helm/helm/blob/a27c468c82fe2cb9a4e07d7c82c9df6b6fed9ed7/pkg/storage/storage.go#L62-L68.
When it removes the least recent release, it wants to preserve the last deployed one, so it invokes Deployed https://github.com/helm/helm/blob/a27c468c82fe2cb9a4e07d7c82c9df6b6fed9ed7/pkg/storage/storage.go#L179, which returns an error if we have no revision in the history in deployed status. https://github.com/helm/helm/blob/a27c468c82fe2cb9a4e07d7c82c9df6b6fed9ed7/pkg/storage/storage.go#L121-L123
at this point, the error is bubbled up and the release interrupts.
I think the behavior should be different and helm should just remove the least recent release if no deployed releases are found in the history, and proceed with the release.
Could the maintainers confirm if this is the intended behavior, or if I can propose a fix?
How to reproduce it:
Create a kind cluster and install a release that will fail the installation:
kind create cluster --image "kindest/node:v1.20.0"
helm repo add cloudecho https://cloudecho.github.io/charts/
helm repo update cloudecho
helm install my-hello cloudecho/hello -n hello --wait --create-namespace --timeout=30s --set image.repository="wrongrepo"

Perform more upgrades that won't fix the release:
helm upgrade my-hello cloudecho/hello -n hello --wait --timeout=30s --set image.tag=v1
helm upgrade my-hello cloudecho/hello -n hello --wait --timeout=30s --set image.tag=v2
helm upgrade my-hello cloudecho/hello -n hello --wait --timeout=30s --set image.tag=v3

at this point the history will be:
helm history my-hello -n hello
REVISION	UPDATED                 	STATUS	CHART      	APP VERSION	DESCRIPTION
1       	Thu Jan 13 10:46:22 2022	failed	hello-0.1.2	0.1.0      	Release "my-hello" failed: timed out waiting for the condition
2       	Thu Jan 13 10:47:55 2022	failed	hello-0.1.2	0.1.0      	Upgrade "my-hello" failed: timed out waiting for the condition
3       	Thu Jan 13 10:55:28 2022	failed	hello-0.1.2	0.1.0      	Upgrade "my-hello" failed: timed out waiting for the condition
4       	Thu Jan 13 10:56:28 2022	failed	hello-0.1.2	0.1.0      	Upgrade "my-hello" failed: timed out waiting for the condition

now perform another upgrade reducing the history capacity: (in this case the upgrade would fix the release)
helm upgrade my-hello cloudecho/hello -n hello --wait --timeout=30s --set image.repository="cloudecho/hello" --history-max=3

helm tries to shorten the history, preserving the last deployed release, but because no revision is in deployed status, the release will not proceed, giving:
Error: UPGRADE FAILED: "my-hello" has no deployed releases

but if we perform the same upgrade without history-max (meaning that the history capacity will be the default 10, so no need to remove any revision from the history), the upgrade proceeds:
helm upgrade my-hello cloudecho/hello -n hello --wait --timeout=30s --set image.repository="cloudecho/hello"
Release "my-hello" has been upgraded. Happy Helming!
NAME: my-hello
LAST DEPLOYED: Thu Jan 13 12:08:39 2022
NAMESPACE: hello
STATUS: deployed
REVISION: 6

this is particularly impacting us, as we have a large number of applications that reach this condition during their initial development stage.

This has started biting us too.
Looks like it was previously fixed in helm 2 but must have been rebroken in helm 3. https://github.com/helm/helm/pull/4978

Exact the same issue on helm v3.5.3

authors: JohnJAS cebernardi sethgupton-mastery

repo: helm/helm


text:
toYaml does not properly indent list items

Calling toYaml always places array items at the same indentation depth as the parent item. Here's an example of this behavior:
Template:
---
{{- $valuesInObjForm := mustDeepCopy .Values -}}

# Via pipe:
{{ $valuesInObjForm | toYaml }}

# Via arg:
{{ toYaml $valuesInObjForm }}

Values:
---
array:
  - val 1
  - val 2

key:
  nestedArray:
    - val 1
    - val 2

Output of helm template:
---
# Source: bugtest/templates/test-template.yaml
# Via pipe:
array:
- val 1
- val 2
key:
  nestedArray:
  - val 1
  - val 2

# Via arg:
array:
- val 1
- val 2
key:
  nestedArray:
  - val 1
  - val 2

I would expect the following output instead:
---
# Source: bugtest/templates/test-template.yaml
# Via pipe:
array:
  - val 1
  - val 2
key:
  nestedArray:
    - val 1
    - val 2

# Via arg:
array:
  - val 1
  - val 2
key:
  nestedArray:
    - val 1
    - val 2

Am I missing something here? If this is an actual bug then I figured somebody else would have found it by now.
Output of helm version:
version.BuildInfo{Version:"v3.13.2", GitCommit:"2a2fb3b98829f1e0be6fb18af2f6599e0f4e8243", GitTreeState:"clean", GoVersion:"go1.21.4"}
Also tested this on v3.10 with identical results
Output of kubectl version: N/A
Cloud Provider/Platform (AKS, GKE, Minikube etc.): N/A

Is this the same as https://github.com/helm/helm/issues/3854? The issue is closed but I don't see anything addressing the list indentation issue mentioned there.

Additional indentation before list items is completely stylistic (e.g. "Indentation" on https://www.yaml.info/learn/bestpractices.html). So I disagree here, and that the output of toYaml is proper.
There could be a toYamlPretty function added to Helm, but it would be fairly subjective to whether the effort would be worth it.

Personally I see value in some option for producing YAML with indented list items, given that most YAML linters requires this. by default. While no indentation may be syntactically correct, it is not accepted by many other tools in the ecosystem.
@gjenkins8 would the project support a PR for a toYamlPretty function? I have a tiny PR for this that essentially amounts to:
func toYAMLPretty(v interface{}) string {
	var data bytes.Buffer
	encoder := goYaml.NewEncoder(&data)
	encoder.SetIndent(2)
	err := encoder.Encode(v)

	if err != nil {
		// Swallow errors inside of a template.
		return ""
	}
	return strings.TrimSuffix(data.String(), "\n")
}

Along with a small unit test and a couple extra lines of "glue".

hmm, I was expecting yaml formatting to have more "knobs" than encoder.SetIndent(...) (I probably should have looked :) )

but it would be fairly subjective to whether the effort would be worth it.

Here, I should have said something more like: "subjective to whether the additional complexity of any functionality is worth the value it brings" (the above sounds like coding effort, which isn't really what I meant)
If there is a reason to support a toYamlPretty, and the usage of such is going to be simple enough for users. Then I would tend to agree, it would make sense to include in Helm.

Not stale, don't close this

I'm running into the same issue. Would be very glad to see this fixed either way.

make toYAML somehow configurable to indent or not indent
or introduce the toYamlPretty

This is not stale - let's keep this open until the fix PR merges.

not stale. please keep open

authors: fheinecke gjenkins8 markcheret michaelkorofiverr