text:
switch type on on interface case, with multi-types case

The following program sample.go triggers an unexpected result
package main

type Intf interface {
	M()
}

type T struct {
	s string
}

func (t *T) M() { println("in M") }

func f(i interface{}) {
	switch j := i.(type) {
	case string, int:
		println("string or int")
	case Intf:
		j.M()
	default:
		println("default")
	}
}

func main() {
	var i Intf
	var k interface{} = 1
	i = &T{"hello"}
	f(i)
	f(k)
}

// Output:
// in M
// default

Expected result
% go run ./_test/issue-1315.go
in M
string or int

Got
% yaegi run ./_test/issue-1315.go
in M
./_test/issue-1315.go:14:2: panic
./_test/issue-1315.go:25:6: panic
run: interface conversion: interface {} is int, not interp.valueInterface
goroutine 1 [running]:
runtime/debug.Stack()
	/Users/mpl/go1/src/runtime/debug/stack.go:24 +0x65
github.com/traefik/yaegi/interp.(*Interpreter).Execute.func1()
	/Users/mpl/src/github.com/traefik/yaegi/interp/program.go:131 +0x94
panic({0x1925120, 0xc000494c60})
	/Users/mpl/go1/src/runtime/panic.go:1038 +0x215
github.com/traefik/yaegi/interp.runCfg.func1()
	/Users/mpl/src/github.com/traefik/yaegi/interp/run.go:193 +0x145
panic({0x1925120, 0xc000494c60})
	/Users/mpl/go1/src/runtime/panic.go:1038 +0x215
github.com/traefik/yaegi/interp.runCfg.func1()
	/Users/mpl/src/github.com/traefik/yaegi/interp/run.go:193 +0x145
panic({0x1925120, 0xc000494c60})
	/Users/mpl/go1/src/runtime/panic.go:1038 +0x215
github.com/traefik/yaegi/interp._case.func5(0x1069dd9)
	/Users/mpl/src/github.com/traefik/yaegi/interp/run.go:2903 +0x1ea
github.com/traefik/yaegi/interp.runCfg(0xc000487e60, 0xc00035e4d0, 0x20, 0x18fdf00)
	/Users/mpl/src/github.com/traefik/yaegi/interp/run.go:201 +0x2ac
github.com/traefik/yaegi/interp.call.func6(0xc00035e210)
	/Users/mpl/src/github.com/traefik/yaegi/interp/run.go:1343 +0x94e
github.com/traefik/yaegi/interp.runCfg(0xc00048cb40, 0xc00035e210, 0xc00048c240, 0xc0001bda80)
	/Users/mpl/src/github.com/traefik/yaegi/interp/run.go:201 +0x2ac
github.com/traefik/yaegi/interp.(*Interpreter).run(0xc00035c000, 0xc00048c240, 0xc00035e000)
	/Users/mpl/src/github.com/traefik/yaegi/interp/run.go:120 +0x385
github.com/traefik/yaegi/interp.(*Interpreter).Execute(0xc00035c000, 0xc0004945a0)
	/Users/mpl/src/github.com/traefik/yaegi/interp/program.go:157 +0x24b
github.com/traefik/yaegi/interp.(*Interpreter).eval(0xc00035c000, {0xc000480300, 0x174}, {0x7ffeefbff6fa, 0xc000480000}, 0x74)
	/Users/mpl/src/github.com/traefik/yaegi/interp/interp.go:615 +0x5c
github.com/traefik/yaegi/interp.(*Interpreter).EvalPath(0xc00035c000, {0x7ffeefbff6fa, 0x15})
	/Users/mpl/src/github.com/traefik/yaegi/interp/interp.go:508 +0xab
main.runFile(0x7ffeefbff6fa, {0x7ffeefbff6fa, 0x15}, 0x0)
	/Users/mpl/src/github.com/traefik/yaegi/cmd/yaegi/run.go:154 +0x8f
main.run({0xc0000321d0, 0xc000000101, 0xc0000606b8})
	/Users/mpl/src/github.com/traefik/yaegi/cmd/yaegi/run.go:117 +0xbec
main.main()
	/Users/mpl/src/github.com/traefik/yaegi/cmd/yaegi/yaegi.go:133 +0xd5

Yaegi Version
master
Additional Notes
Very similar to #1315 , and probably needs the same kind of fix, but for the "default" case of the switch len(types) , which deals with matching against multiple types.

Does not reproduce anymore on master.

authors: mpl mvertes

repo: traefik/yaegi


text:
ASAN support for Linux and Mac

Test by running ./build_dependencies.sh --release --asan llvm-10.
You'll also probably want to compile your tool with something like the following:
CXXFLAGS="-fsanitize=address -fno-omit-frame-pointer -fno-optimize-sibling-calls -ffunction-sections -fdata-sections -Wl,-undefined,dynamic_lookup" \
  CCFLAGS="-fsanitize=address -fno-omit-frame-pointer -fno-optimize-sibling-calls -ffunction-sections -fdata-sections -Wl,-undefined,dynamic_lookup" \
  LDFLAGS="-fsanitize=address -Wl,-undefined,dynamic_lookup" \
  cmake -G Ninja -DCMAKE_INSTALL_PREFIX=$(pwd)/install \
  -DVCPKG_ROOT="<path_to_vcpkg>" \
  -DVCPKG_TARGET_TRIPLET=x64-linux-rel-asan \
  ..

Updated build script to more easily compile with ASAN --asan

Workaround for failing build in LLVM with manually added extra compilation flags. Now just looks for the VCPKG_USE_SANITIZER variable

Brought in gtest to add a patch (ports/gtest/remove-werror.patch) to remove -Werror since there are some warnings with the added sanitizer flags.

[x]  Added new triplet with command line flags for ASAN. These command-line flags might be better used in a toolchain file. See here for example https://github.com/Neumann-A/my-vcpkg-triplets. EDIT: After further investigation, using a CMake toolchain with CMAKE_*_FLAGS, etc. for the sanitizer options did not work for non-cmake project XED, but it did work for CMake project GTest. Might need to wait for upstream to better support forwarding these CMAKE variables to non-cmake projects.

[x] Add osx asan support

[x] Fix build_dependencies script because I think the argparsing won't work if --asan is before --release

Are there a better flags for Address sanitizer support? I took these from a different project

source: gharchive/pull-request

repo: trailofbits/cxx-common

license_type: permissive

license_source: github-api


text:
API revision 3

New fields:
Adcurrent full URL (for browser apps)
Add operation time in millis
Add tags (constructor)
Add application SKU field (constructor)
Add device type and info (iPhone 7) etc. to SDK (automatic defaults)
Add current CPU and memory usage info (automatic defaults)
Add correlation ID (as a new ID to correlate across applications)

Wrong way, (whoops!)

repo: trakerr-com/trakerr-python

license_source: bigquery


text:
B-19728-INT customer upload additional docs

Agility ticket
Summary
Give the customers the ability to upload documents without affecting their workflow!
This work create a new button for customers that appears on their MoveHome page after a move is submitted, that allows them to provide additional documentation to the government without affecting their workflow. We added a new column to the moves table that houses additional_documents_id. Customer have the ability to upload documents and delete documents after they've been uploaded.
How to test

Login as a customer with a move that has been submitted, and navigate to the MoveHome page of a move.
Click on the Upload Additional Documents button attached to the Profile step.
Confirm the page looks good and the upload/delete works, and persists as you navigate away/log out

Warnings

:warning:

Files located in legacy directories (src/shared or src/scenes) have
been edited. Are you sure you don’t want to also relocate them to the new file structure?
View the frontend file org ADR for more information

  Generated by :no_entry_sign: dangerJS against 55776da5438f889421163bc02fc0a6c0e1004375

Shouldn't there be a checkin for the FF in the milmove-feature-flags repository also?  or was that already done?

Moving back to draft to address bug

authors: pambecker paulstonebraker robot-mymove

repo: transcom/mymove

license: MIT


text:
Update Certs Migration generator and fix upload secure migration script

Description
In light of the number of people renewing their CACs and having to create new migrations to update their certs on Staging and Experimental this PR updates the milmove gen certs-migration to support creating an update. It updates the upload-secure-migration script to remove references and uploads to legacy com cloud as that is shut down now. Finally it updates the download-secure-migration script to support govcloud.
Reviewer Notes
Updates made to https://github.com/transcom/mymove/wiki/use-mtls-with-cac and https://github.com/transcom/mymove/wiki/migrate-the-database#secure-migrations
Setup
Generating a cac update Requires a CAC
make bin/milmove
milmove gen certs-migration --cac --update --certid <someuuid> -n <migration name>

Running the below will confirm access to aws but not upload anything without a final confirmation. Other ways to test this is to change the lines that talk to aws temporarily and make them echo instead.
upload-secure-migration <path to secure migration sql>

Running the below will confirm aws access and download the requested file from S3
download-secure-migration <secure migration sql>

Code Review Verification Steps

[ ] Code follows the guidelines for Logging
[ ] Request review from a member of a different team.
[ ] Have the Jira acceptance criteria been met for this change?

References

this slack thread explains more about the approach used.

Fails

:no_entry_sign:
Yarn Audit Issues Found:
high - Prototype Pollution in node-forge
Package node-forge
Patched in >= 0.10.0
Dependency of react-scripts
Path react-scripts > webpack-dev-server > selfsigned > node-forge
More info https://npmjs.com/advisories/1561
1 high vulnerabilities and 0 critical vulnerabilities found

Warnings

:warning:
Please add the JIRA issue key to the PR title (e.g. MB-123)

  Generated by :no_entry_sign: dangerJS against b0124ce379f2b9f9fe48669d14b58e0dbcabdc61

authors: gidjin robot-mymove


text:
MB-8673: Adds logic to interceptor reducer to handle events

Description
This pull request combines the work done in previous tickets (MB-8670 and MB-8671), wiring up the interceptor reducer to listen to INTERCEPT_RESPONSE events and update it's internal state accordingly.
Any user action that causes an XHR request to be sent can actually cause several requests to be sent; we want the state to be updated to reflect than an error response has been returned if any of those XHR responses have done so, regardless of which request it was. Since our interception method doesn't have any way logically connect responses to the user actions that caused them, the way we're going to operationalize what a "user action" is will be waiting for a gap of at least three seconds between response interceptions.
How it works:

If an intercepted XHR response returns a 500 status code, set the value of hasRecentError to true in the returned state.
If an intercepted XHR response does not return a 500 status code, and the value of timestamp in the current state is more than 3000ms from right now, set the value of hasRecentError to false in the returned state.
Always set the value of timestamp in the returned state to be the current JS timestamp (from Date.now()).

Reviewer Notes
The actual work is pretty simple, but let's make sure that this code is readable, and that what we're doing around the 3000ms delay makes sense from a product perspective.
You can test that this is working in the running application by inspecting the active redux store state. timestamp (and hasRecentError) should update whenever an XHR response has been received.
Setup
There's no visual changes to the application for this work, but other tickets will use the hasRecentError value from the store to determine whether or not to display an error message in the application.
make server_run
make client_run

Code Review Verification Steps

[ ] There are no aXe warnings for UI.
[ ] This works in Supported Browsers and their phone views (Chrome, Firefox, IE, Edge).
[ ] Request review from a member of a different team.
[ ] Have the Jira acceptance criteria been met for this change?

References

Closes MB-8673.

Messages

:book:
:link: MB-8673

  Generated by :no_entry_sign: dangerJS against e7ce68852265c5fcde5866c3958568f1996eafd1

authors: kylehilltruss robot-mymove


text:
chore: replace xmldom with @xmldom/xmldom

This PR replaces the xmldom dependency with @xmldom/xmldom, and bumps the version to v0.8.1 (Latest version as of writing this PR).
Reasons:

Author no longer publishes to xmldom.
Quote from author:

Since version 0.7.0 this package is published to npm as @xmldom/xmldom and no longer as xmldom, because we are no longer able to publish xmldom.

xmldom versions 0.6.0 and older do not correctly escape special characters when serializing elements removed from their ancestor. This may lead to unexpected syntactic changes during XML processing in some downstream applications.

Thank you for your contribution

authors: RostiMelk vitonsky

repo: translate-tools/core


text:
DID Key Identifiers for NIST Curves are Wrong

See https://github.com/w3c-ccg/did-method-key/commit/f72be388f1c10e76f7785bb02ea2cd7828b47359

Fixed in https://github.com/transmute-industries/did-key.js/pull/97

source: gharchive/issue


text:
🛑 TechinAsia is down

In b48b122, TechinAsia (https://www.techinasia.com) was down:

HTTP code: 403
Response time: 710 ms

Resolved: TechinAsia is back up in da300ef after 10 minutes.

repo: traqy/upptime


text:
🛑 TechinAsia is down

In d13e215, TechinAsia (https://www.techinasia.com) was down:

HTTP code: 403
Response time: 986 ms

Resolved: TechinAsia is back up in 755ed84 after 10 minutes.


text:
🛑 TechinAsia is down

In fd0195a, TechinAsia (https://www.techinasia.com) was down:

HTTP code: 403
Response time: 1033 ms

Resolved: TechinAsia is back up in 9fa7133 after 10 minutes.


text:
🛑 TechinAsia_WordPress_API is down

In faf1713, TechinAsia_WordPress_API (https://www.techinasia.com/wp-json/techinasia/2.0/posts) was down:

HTTP code: 403
Response time: 172 ms

Resolved: TechinAsia_WordPress_API is back up in 94743dd after 9 minutes.


text:
🛑 TechinAsia_Laravel_API is down

In 192a429, TechinAsia_Laravel_API (https://www.techinasia.com/api/2.0/companies) was down:

HTTP code: 403
Response time: 245 ms

Resolved: TechinAsia_Laravel_API is back up in 1ccc30f after 8 minutes.


text:
🛑 TechinAsia_WordPress_API is down

In f11e876, TechinAsia_WordPress_API (https://www.techinasia.com/wp-json/techinasia/2.0/posts) was down:

HTTP code: 403
Response time: 171 ms

Resolved: TechinAsia_WordPress_API is back up in abe5535 after 7 minutes.


text:
🛑 TechinAsia is down

In 58671bb, TechinAsia (https://www.techinasia.com) was down:

HTTP code: 403
Response time: 1007 ms

Resolved: TechinAsia is back up in 2b262d5 after 8 minutes.


text:
How to train dataset without camera data?

I want to train the DeepRoute Open Dataset. Here is the website: https://gas.graviti.cn/dataset/graviti-open-dataset/DeepRoute
There is no camera data in the dataset, only lidar data. It is different with KITTI.

Did you konw how to train my own data without image and calib?


text:
Move cz config from package to file

.czrc is supported

back in business once this gets published in a release: https://github.com/commitizen/cz-cli/pull/484

example: https://github.com/travi/no-unstaged/blob/master/.czrc

repo: travi/javascript-scaffolder


text:
26 travis build failed

https://travisci.assembla.com/spaces/Enterprise/tickets/26
Changes to solve tests on travis CI.

Verified on local TCI Enterprise setup.

repo: travis-ci/travis-build


text:
Ensure build-bom exit code matches build command exit code

The existing code sets an exit code if there is a tracee returned, otherwise it exits with zero.  However, the internal routine monitoring the trace loops until the return is not Ok, which results in returning None for the tracee value.  This adds capture of the last execution's exit code to use when the tracee is None.

aha - I had noticed that an error code was getting dropped, but hadn't gotten around to figuring out where. Thanks!

authors: kquick travitch

repo: travitch/build-bom


text:
Leak in term writing?

The following program aborts with a malloc error (likely from a buffer overflow):
:- op(201, fy, '@').

test :-
	Result = dict('.'(:(valid,@(true)),'.'(:(fields,dict('.'(:(revision,dict('.'(:(valid,@(true)),'.'(:(ignored,@(true)),[])))),'.'(:(creator,dict('.'(:(valid,@(true)),'.'(:(ignored,@(true)),[])))),'.'(:(updated_at,dict('.'(:(valid,@(true)),'.'(:(ignored,@(true)),[])))),'.'(:(created_at,dict('.'(:(valid,@(true)),'.'(:(ignored,@(true)),[])))),'.'(:(qux_abbreviation,dict('.'(:(valid,@(true)),[]))),'.'(:(qux_name,dict('.'(:(valid,@(false)),'.'(:(error,'256文字以下の値を入力してください'),[])))),'.'(:(baz_id,dict('.'(:(valid,@(false)),'.'(:(error,'256文字以下の値を入力してください'),[])))),'.'(:(owner_id,dict('.'(:(valid,@(true)),'.'(:(ignored,@(true)),[])))),'.'(:(qux_type_code,dict('.'(:(valid,@(true)),[]))),'.'(:(foo,dict('.'(:(fields,dict('.'(:('foo/bar_groups',dict('.'(:(valid,@(true)),[]))),'.'(:('foo/acme_notification_url',dict('.'(:(valid,@(false)),'.'(:(error,'「https://」で始まらなければなりません'),[])))),'.'(:('foo/qux_api_version',dict('.'(:(valid,@(true)),[]))),'.'(:('foo/xyz_unit_id',dict('.'(:(valid,@(false)),'.'(:(error,'256文字以下の値を入力してください'),[])))),'.'(:('foo/abc_label',dict('.'(:(fields,dict('.'(:('foo/abc_label/print_abc_list',dict('.'(:(valid,@(true)),[]))),'.'(:('foo/abc_label/report_id',dict('.'(:(valid,@(true)),[]))),'.'(:('foo/abc_label/report_setting_key',dict('.'(:(valid,@(true)),[]))),[]))))),'.'(:(valid,@(true)),[])))),'.'(:('foo/xyz_notes',dict('.'(:(valid,@(true)),[]))),[])))))))),'.'(:(valid,@(true)),[])))),'.'(:(system_id,dict('.'(:(valid,@(false)),'.'(:(error,'256文字以下の値を入力してください'),[])))),'.'(:(qux_status,dict('.'(:(valid,@(true)),[]))),[])))))))))))))),'.'(:(spec,dict('.'(:(type,model),'.'(:(model,qux_config),[])))),[])))),
	write(Result).

$ tpl leak.pl -g test,halt
malloc(): invalid size (unsorted)
Aborted

Writing with ignore_ops(true) seems to avoid it, so my guess would be it has to do with space insertion for the @ operator.
Valgrind log
==2116== Memcheck, a memory error detector
==2116== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2116== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==2116== Command: tpl leak.pl -g test,halt
==2116==
==2116== Invalid write of size 2
==2116==    at 0x4842B33: memmove (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x1AA12D: plain (print.c:232)
==2116==    by 0x1AEF4F: print_term_to_buf (print.c:844)
==2116==    by 0x1B1344: print_term_to_buf (print.c:1033)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B21D8: print_term_to_buf (print.c:1127)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B2EFE: print_term_to_stream (print.c:1317)
==2116==  Address 0x59f1930 is 1,200 bytes inside a block of size 1,201 alloc'd
==2116==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x1B2E8C: print_term_to_stream (print.c:1313)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==    by 0x1B393B: pl_eval (prolog.c:122)
==2116==    by 0x1164F2: main (tpl.c:274)
==2116==
==2116== Invalid write of size 1
==2116==    at 0x4842B63: memmove (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x1AA12D: plain (print.c:232)
==2116==    by 0x1AEF4F: print_term_to_buf (print.c:844)
==2116==    by 0x1B1344: print_term_to_buf (print.c:1033)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B21D8: print_term_to_buf (print.c:1127)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B2EFE: print_term_to_stream (print.c:1317)
==2116==  Address 0x59f1932 is 1 bytes after a block of size 1,201 alloc'd
==2116==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x1B2E8C: print_term_to_stream (print.c:1313)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==    by 0x1B393B: pl_eval (prolog.c:122)
==2116==    by 0x1164F2: main (tpl.c:274)
==2116==
==2116== Invalid write of size 1
==2116==    at 0x1AA13B: plain (print.c:233)
==2116==    by 0x1AEF4F: print_term_to_buf (print.c:844)
==2116==    by 0x1B1344: print_term_to_buf (print.c:1033)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B21D8: print_term_to_buf (print.c:1127)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B2EFE: print_term_to_stream (print.c:1317)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==  Address 0x59f1933 is 2 bytes after a block of size 1,201 alloc'd
==2116==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x1B2E8C: print_term_to_stream (print.c:1313)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==    by 0x1B393B: pl_eval (prolog.c:122)
==2116==    by 0x1164F2: main (tpl.c:274)
==2116==
==2116== Invalid write of size 1
==2116==    at 0x4E05F81: __vsnprintf_internal (vsnprintf.c:112)
==2116==    by 0x4DDBDF5: snprintf (snprintf.c:31)
==2116==    by 0x1AEFD2: print_term_to_buf (print.c:848)
==2116==    by 0x1B1344: print_term_to_buf (print.c:1033)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B21D8: print_term_to_buf (print.c:1127)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B2EFE: print_term_to_stream (print.c:1317)
==2116==  Address 0x59f1933 is 2 bytes after a block of size 1,201 alloc'd
==2116==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x1B2E8C: print_term_to_stream (print.c:1313)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==    by 0x1B393B: pl_eval (prolog.c:122)
==2116==    by 0x1164F2: main (tpl.c:274)
==2116==
==2116== Invalid write of size 1
==2116==    at 0x4E05FAB: __vsnprintf_internal (vsnprintf.c:117)
==2116==    by 0x4DDBDF5: snprintf (snprintf.c:31)
==2116==    by 0x1AEFD2: print_term_to_buf (print.c:848)
==2116==    by 0x1B1344: print_term_to_buf (print.c:1033)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B21D8: print_term_to_buf (print.c:1127)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B2EFE: print_term_to_stream (print.c:1317)
==2116==  Address 0x59f1933 is 2 bytes after a block of size 1,201 alloc'd
==2116==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x1B2E8C: print_term_to_stream (print.c:1313)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==    by 0x1B393B: pl_eval (prolog.c:122)
==2116==    by 0x1164F2: main (tpl.c:274)
==2116==
==2116== Invalid write of size 1
==2116==    at 0x4842B63: memmove (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x1AA12D: plain (print.c:232)
==2116==    by 0x1B19DE: print_term_to_buf (print.c:1084)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B21D8: print_term_to_buf (print.c:1127)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B2EFE: print_term_to_stream (print.c:1317)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==  Address 0x59f1933 is 2 bytes after a block of size 1,201 alloc'd
==2116==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x1B2E8C: print_term_to_stream (print.c:1313)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==    by 0x1B393B: pl_eval (prolog.c:122)
==2116==    by 0x1164F2: main (tpl.c:274)
==2116==
==2116== Invalid write of size 1
==2116==    at 0x1AA13B: plain (print.c:233)
==2116==    by 0x1B19DE: print_term_to_buf (print.c:1084)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B21D8: print_term_to_buf (print.c:1127)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B2EFE: print_term_to_stream (print.c:1317)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==  Address 0x59f1934 is 3 bytes after a block of size 1,201 alloc'd
==2116==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x1B2E8C: print_term_to_stream (print.c:1313)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==    by 0x1B393B: pl_eval (prolog.c:122)
==2116==    by 0x1164F2: main (tpl.c:274)
==2116==
==2116== Invalid write of size 1
==2116==    at 0x4E05F81: __vsnprintf_internal (vsnprintf.c:112)
==2116==    by 0x4DDBDF5: snprintf (snprintf.c:31)
==2116==    by 0x1AEB60: print_term_to_buf (print.c:806)
==2116==    by 0x1B21D8: print_term_to_buf (print.c:1127)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B21D8: print_term_to_buf (print.c:1127)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B2EFE: print_term_to_stream (print.c:1317)
==2116==  Address 0x59f1934 is 3 bytes after a block of size 1,201 alloc'd
==2116==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x1B2E8C: print_term_to_stream (print.c:1313)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==    by 0x1B393B: pl_eval (prolog.c:122)
==2116==    by 0x1164F2: main (tpl.c:274)
==2116==
==2116== Invalid write of size 1
==2116==    at 0x4E05FAB: __vsnprintf_internal (vsnprintf.c:117)
==2116==    by 0x4DDBDF5: snprintf (snprintf.c:31)
==2116==    by 0x1AEB60: print_term_to_buf (print.c:806)
==2116==    by 0x1B21D8: print_term_to_buf (print.c:1127)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B21D8: print_term_to_buf (print.c:1127)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B2EFE: print_term_to_stream (print.c:1317)
==2116==  Address 0x59f1934 is 3 bytes after a block of size 1,201 alloc'd
==2116==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x1B2E8C: print_term_to_stream (print.c:1313)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==    by 0x1B393B: pl_eval (prolog.c:122)
==2116==    by 0x1164F2: main (tpl.c:274)
==2116==
==2116== Invalid write of size 2
==2116==    at 0x4842B33: memmove (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x1AA12D: plain (print.c:232)
==2116==    by 0x1AEF4F: print_term_to_buf (print.c:844)
==2116==    by 0x1B21D8: print_term_to_buf (print.c:1127)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B21D8: print_term_to_buf (print.c:1127)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B2EFE: print_term_to_stream (print.c:1317)
==2116==  Address 0x59f1934 is 3 bytes after a block of size 1,201 alloc'd
==2116==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x1B2E8C: print_term_to_stream (print.c:1313)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==    by 0x1B393B: pl_eval (prolog.c:122)
==2116==    by 0x1164F2: main (tpl.c:274)
==2116==
==2116== Invalid write of size 1
==2116==    at 0x1AA13B: plain (print.c:233)
==2116==    by 0x1AEF4F: print_term_to_buf (print.c:844)
==2116==    by 0x1B21D8: print_term_to_buf (print.c:1127)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B21D8: print_term_to_buf (print.c:1127)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B2EFE: print_term_to_stream (print.c:1317)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==  Address 0x59f193e is 13 bytes after a block of size 1,201 alloc'd
==2116==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x1B2E8C: print_term_to_stream (print.c:1313)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==    by 0x1B393B: pl_eval (prolog.c:122)
==2116==    by 0x1164F2: main (tpl.c:274)
==2116==
==2116== Invalid write of size 1
==2116==    at 0x4E05F81: __vsnprintf_internal (vsnprintf.c:112)
==2116==    by 0x4DDBDF5: snprintf (snprintf.c:31)
==2116==    by 0x1AEFD2: print_term_to_buf (print.c:848)
==2116==    by 0x1B21D8: print_term_to_buf (print.c:1127)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B21D8: print_term_to_buf (print.c:1127)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B2EFE: print_term_to_stream (print.c:1317)
==2116==  Address 0x59f193e is 13 bytes after a block of size 1,201 alloc'd
==2116==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x1B2E8C: print_term_to_stream (print.c:1313)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==    by 0x1B393B: pl_eval (prolog.c:122)
==2116==    by 0x1164F2: main (tpl.c:274)
==2116==
==2116== Invalid write of size 1
==2116==    at 0x4E05FAB: __vsnprintf_internal (vsnprintf.c:117)
==2116==    by 0x4DDBDF5: snprintf (snprintf.c:31)
==2116==    by 0x1AEFD2: print_term_to_buf (print.c:848)
==2116==    by 0x1B21D8: print_term_to_buf (print.c:1127)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B21D8: print_term_to_buf (print.c:1127)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B2EFE: print_term_to_stream (print.c:1317)
==2116==  Address 0x59f193e is 13 bytes after a block of size 1,201 alloc'd
==2116==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x1B2E8C: print_term_to_stream (print.c:1313)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==    by 0x1B393B: pl_eval (prolog.c:122)
==2116==    by 0x1164F2: main (tpl.c:274)
==2116==
==2116== Invalid write of size 1
==2116==    at 0x4E05F81: __vsnprintf_internal (vsnprintf.c:112)
==2116==    by 0x4DDBDF5: snprintf (snprintf.c:31)
==2116==    by 0x1AC98D: print_iso_list (print.c:586)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B21D8: print_term_to_buf (print.c:1127)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B2EFE: print_term_to_stream (print.c:1317)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==  Address 0x59f193e is 13 bytes after a block of size 1,201 alloc'd
==2116==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x1B2E8C: print_term_to_stream (print.c:1313)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==    by 0x1B393B: pl_eval (prolog.c:122)
==2116==    by 0x1164F2: main (tpl.c:274)
==2116==
==2116== Invalid write of size 1
==2116==    at 0x4E0C134: _IO_default_xsputn (genops.c:394)
==2116==    by 0x4E0C134: _IO_default_xsputn (genops.c:370)
==2116==    by 0x4DF10FB: __vfprintf_internal (vfprintf-internal.c:1688)
==2116==    by 0x4E05F99: __vsnprintf_internal (vsnprintf.c:114)
==2116==    by 0x4DDBDF5: snprintf (snprintf.c:31)
==2116==    by 0x1AC98D: print_iso_list (print.c:586)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B21D8: print_term_to_buf (print.c:1127)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B2EFE: print_term_to_stream (print.c:1317)
==2116==  Address 0x59f193e is 13 bytes after a block of size 1,201 alloc'd
==2116==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x1B2E8C: print_term_to_stream (print.c:1313)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==    by 0x1B393B: pl_eval (prolog.c:122)
==2116==    by 0x1164F2: main (tpl.c:274)
==2116==
==2116== Invalid write of size 1
==2116==    at 0x4E05FAB: __vsnprintf_internal (vsnprintf.c:117)
==2116==    by 0x4DDBDF5: snprintf (snprintf.c:31)
==2116==    by 0x1AC98D: print_iso_list (print.c:586)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B21D8: print_term_to_buf (print.c:1127)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B2EFE: print_term_to_stream (print.c:1317)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==  Address 0x59f193f is 14 bytes after a block of size 1,201 alloc'd
==2116==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x1B2E8C: print_term_to_stream (print.c:1313)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==    by 0x1B393B: pl_eval (prolog.c:122)
==2116==    by 0x1164F2: main (tpl.c:274)
==2116==
==2116== Invalid write of size 1
==2116==    at 0x4E05F81: __vsnprintf_internal (vsnprintf.c:112)
==2116==    by 0x4DDBDF5: snprintf (snprintf.c:31)
==2116==    by 0x1AF5E0: print_term_to_buf (print.c:909)
==2116==    by 0x1B21D8: print_term_to_buf (print.c:1127)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B2EFE: print_term_to_stream (print.c:1317)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==  Address 0x59f193f is 14 bytes after a block of size 1,201 alloc'd
==2116==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x1B2E8C: print_term_to_stream (print.c:1313)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==    by 0x1B393B: pl_eval (prolog.c:122)
==2116==    by 0x1164F2: main (tpl.c:274)
==2116==
==2116== Invalid write of size 1
==2116==    at 0x4E05FAB: __vsnprintf_internal (vsnprintf.c:117)
==2116==    by 0x4DDBDF5: snprintf (snprintf.c:31)
==2116==    by 0x1AF5E0: print_term_to_buf (print.c:909)
==2116==    by 0x1B21D8: print_term_to_buf (print.c:1127)
==2116==    by 0x1ABDA3: print_iso_list (print.c:520)
==2116==    by 0x1AE067: print_term_to_buf (print.c:741)
==2116==    by 0x1AF47E: print_term_to_buf (print.c:895)
==2116==    by 0x1B2EFE: print_term_to_stream (print.c:1317)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==  Address 0x59f1940 is 15 bytes after a block of size 1,201 alloc'd
==2116==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x1B2E8C: print_term_to_stream (print.c:1313)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==    by 0x1B393B: pl_eval (prolog.c:122)
==2116==    by 0x1164F2: main (tpl.c:274)
==2116==
==2116== Invalid write of size 1
==2116==    at 0x4E05F81: __vsnprintf_internal (vsnprintf.c:112)
==2116==    by 0x4DDBDF5: snprintf (snprintf.c:31)
==2116==    by 0x1AF5E0: print_term_to_buf (print.c:909)
==2116==    by 0x1B2EFE: print_term_to_stream (print.c:1317)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==    by 0x1B393B: pl_eval (prolog.c:122)
==2116==    by 0x1164F2: main (tpl.c:274)
==2116==  Address 0x59f1941 is 16 bytes after a block of size 1,201 alloc'd
==2116==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x1B2E8C: print_term_to_stream (print.c:1313)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==    by 0x1B393B: pl_eval (prolog.c:122)
==2116==    by 0x1164F2: main (tpl.c:274)
==2116==
==2116== Invalid write of size 1
==2116==    at 0x4E05FAB: __vsnprintf_internal (vsnprintf.c:117)
==2116==    by 0x4DDBDF5: snprintf (snprintf.c:31)
==2116==    by 0x1AF5E0: print_term_to_buf (print.c:909)
==2116==    by 0x1B2EFE: print_term_to_stream (print.c:1317)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==    by 0x1B393B: pl_eval (prolog.c:122)
==2116==    by 0x1164F2: main (tpl.c:274)
==2116==  Address 0x59f1942 is 17 bytes after a block of size 1,201 alloc'd
==2116==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x1B2E8C: print_term_to_stream (print.c:1313)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==    by 0x1B393B: pl_eval (prolog.c:122)
==2116==    by 0x1164F2: main (tpl.c:274)
==2116==
dict([valid: @true,fields:dict([revision:dict([valid: @true,ignored: @true]),creator:dict([valid: @true,ignored: @true]),updated_at:dict([valid: @true,ignored: @true]),created_at:dict([valid: @true,ignored: @true]),qux_abbreviation:dict([valid: @true]),qux_name:dict([valid: @false,error:256文字以下の値を入力してください]),baz_id:dict([valid: @false,error:256文字以下の値を入力してください]),owner_id:dict([valid: @true,ignored: @true]),qux_type_code:dict([valid: @true]),foo:dict([fields:dict([foo/bar_groups:dict([valid: @true]),foo/acme_notification_url:dict([valid: @false,error:「https://」で始まらなければなりません]),foo/qux_api_version:dict([valid: @true]),foo/xyz_unit_id:dict([valid: @false,error:256文字以下 の値を入力してください]),foo/abc_label:dict([fields:dict([foo/abc_label/print_abc_list:dict([valid: @true]),foo/abc_label/report_id:dict([valid: @true]),foo/abc_label/report_setting_key:dict([valid: @true])]),valid: @true]),foo/xyz_notes:dict([v==2116== Invalid read of size 1
==2116==    at 0x4E0C01E: _IO_default_xsputn (genops.c:399)
==2116==    by 0x4E0C01E: _IO_default_xsputn (genops.c:370)
==2116==    by 0x4E096F9: _IO_new_file_xsputn (fileops.c:1265)
==2116==    by 0x4E096F9: _IO_file_xsputn@@GLIBC_2.2.5 (fileops.c:1197)
==2116==    by 0x4DFD3C0: fwrite (iofwrite.c:39)
==2116==    by 0x15286D: net_write (network.c:330)
==2116==    by 0x1B2F27: print_term_to_stream (print.c:1321)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==    by 0x1B393B: pl_eval (prolog.c:122)
==2116==    by 0x1164F2: main (tpl.c:274)
==2116==  Address 0x59f1931 is 0 bytes after a block of size 1,201 alloc'd
==2116==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x1B2E8C: print_term_to_stream (print.c:1313)
==2116==    by 0x1D4E88: fn_iso_write_1 (streams.c:1998)
==2116==    by 0x1BC369: start (query.c:1749)
==2116==    by 0x1BCB84: execute (query.c:1949)
==2116==    by 0x1654CA: run (parser.c:3615)
==2116==    by 0x1B393B: pl_eval (prolog.c:122)
==2116==    by 0x1164F2: main (tpl.c:274)
==2116==
alid: @true])]),valid: @true]),system_id:dict([valid: @false,error:256文字以下の値を入力してください]),qux_status:dict([valid: @true])]),spec:dict([type:model,model:qux_config])])==2116==
==2116== HEAP SUMMARY:
==2116==     in use at exit: 11,526 bytes in 68 blocks
==2116==   total heap usage: 5,701 allocs, 5,633 frees, 56,428,199 bytes allocated
==2116==
==2116== 3,299 (2,960 direct, 339 indirect) bytes in 10 blocks are definitely lost in loss record 3 of 4
==2116==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x154DC9: directives (parser.c:397)
==2116==    by 0x161B9A: process_term (parser.c:2887)
==2116==    by 0x16283E: tokenize (parser.c:3046)
==2116==    by 0x14FF6A: load_text (module.c:1276)
==2116==    by 0x156E29: directives (parser.c:678)
==2116==    by 0x161B9A: process_term (parser.c:2887)
==2116==    by 0x16283E: tokenize (parser.c:3046)
==2116==    by 0x14FF6A: load_text (module.c:1276)
==2116==    by 0x156E29: directives (parser.c:678)
==2116==    by 0x161B9A: process_term (parser.c:2887)
==2116==    by 0x16283E: tokenize (parser.c:3046)
==2116==
==2116== 8,227 (7,104 direct, 1,123 indirect) bytes in 24 blocks are definitely lost in loss record 4 of 4
==2116==    at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2116==    by 0x154DC9: directives (parser.c:397)
==2116==    by 0x161B9A: process_term (parser.c:2887)
==2116==    by 0x16283E: tokenize (parser.c:3046)
==2116==    by 0x14FF6A: load_text (module.c:1276)
==2116==    by 0x1B553E: pl_create (prolog.c:533)
==2116==    by 0x115C14: main (tpl.c:165)
==2116==
==2116== LEAK SUMMARY:
==2116==    definitely lost: 10,064 bytes in 34 blocks
==2116==    indirectly lost: 1,462 bytes in 34 blocks
==2116==      possibly lost: 0 bytes in 0 blocks
==2116==    still reachable: 0 bytes in 0 blocks
==2116==         suppressed: 0 bytes in 0 blocks
==2116==
==2116== For lists of detected and suppressed errors, rerun with: -s
==2116== ERROR SUMMARY: 54 errors from 23 contexts (suppressed: 0 from 0)

Thanks a bunch, works now!

repo: trealla-prolog/trealla


text:
Add td-output-sftp sample

@toru-takahashi Please review this!

Sorry, I fixed both of parts.

ah, see file changes tab?

Okay, I modified result_url part from list to code.

authors: kamikaseda toru-takahashi

repo: treasure-data/workflow-examples


text:
Github action to build docker image and release

Resolves CRT-2215. We use this image for running in standalone mode on development machines. Followed Mat's work in nexus-resource. I'll tag after this is approved/merged.

@mymasse do the secrets exist at an organization level or do they need to be added here too?


text:
Excel libary

Would it be possible to also add bundles and packs to the the excel Excel libary?

Thanks for your input.
Adding bundles could be done. On the other hand, packs are difficult to implement as they have to refer to a box that is supposed to be in an other tab of the sheet.
Anyway, we are currently working on an online database (hosted on MS Azure) which will allow storing all your items (pack included) and in the end, the only purpose of the Excel file loader might be to fill the user database.

repo: treeDiM/StackBuilder

license: mit


text:
Wrong HANA cluster info after failover

This issue has been noticed in the test environment what has been set up for the QA Team.
High level description: in one of the HANA clusters, we have stopped the primary database, waited for the secondary node to take over and checked the status of the cluster in the Trento Console. The detail view of the cluster shows the following:

HANA secondary snyc state = green dashed icon (but it should be red SFAIL according to SAPHanaSR-showAttr)
No stopped resources (but the SAPHANA slave resource is actually stopped in former primary node)

How to reproduce the error (required public IP addresses and private key for SSH connection will be provided on demand):

Log on vmhdbdev01:
localworkstation# ssh -i ~/.ssh/id_rsa_cloud cloudadmin@vmhdbdev01
Switch to user hddadm:
vmhdbdev01:cloudadmin> sudo su - hddadm
Gracefully stop the HANA instance:
vmhdbdev01:hddadm> HDB stop
Monitor failover until secondary database is promoted to primary and IP address moves to vmhdbdev02:
cloudadmin@vmhdbdev01:~> sudo crm status
Open the QA Trento Console URL.
Click on Pacemaker Clusters in the Menu section, filter by Cluster type = HANA scale-up and Tag = env3.
Click on the cluster name or ID and review the status of the cluster.

Hey @abravosuse ,
I have been trying to reproduce this issue, but I was not able to.

The SFAIL not showing issue was most probably fixed at: https://github.com/trento-project/trento/pull/525
About the stopped resource, as much as I try, the resource always goes to a FAILED state, not STOPPED. This state is not handled by now as far as I know (I mean that we don't do anything in the UI)
Is there something I'm missing?
Maybe you could paste here your crm_mon output, so I can at least make an idea about what exactly I need to reproduce

@arbulu89 Zaoliang is about to start the second testing cycle. Let us please circle back to you after we have run the corresponding test.

feedback:
I stopped database on vmhdbprd01 by HDB stop and then later checked: http://20.67.108.123/databases/3740fd10a150d7aa15a43a5875ccfcf2
vmhdbprd01 still has SAPControl-GREEN which is wrong.
Under Hosts I see vmhdbprd01 and vmhdbprd02 both with red '!'.  Click each of them, I see both have issue with agent status error code 500.

@arbulu89 I have reproduced the issue in the QA testing environment for cycle 2 (v0.6.0).
This is the output of crm_mon. You can see that the master (primary) instance is running in node 02 whereas the instance in node 01 is not running:

Here you have also the output of SAPHanaSR-showAttr where, as you can see, sync_state = SFAIL

However this is what you see in the cluster detail view in the Trento Console:

As you can see, the HANA secondary sysnc state shows a green dash icon rather than red SFAIL. and the Stopped resources sections says that there are no stopped resources, which is not true.

Ok, I will have a 2nd look

Hey @abravosuse ,
This is the thing.

The health state
Depending on the order of the nodes, the health state takes a different value. If the failed node is the 1st one, it will show this red flag as you show in the screenshot. If the failed node is the 2nd one (once a failover is done and the 2nd node is the new primary), we will see green icon with 4. This is due the ordering.  I guess here, we should show the state of the Secondary always, as the primary can be right even if there is not correct system replication. Would this be OK?

The sync state
I cannot reproduce this icon, in my case, i find an empty cell... Most probably we have different version.. Because I cannot find this - value anywhere in the code. We return an empty string, which makes sense with my error. We will fix this to get the value always from the secondary node

About the stopped resources
In this case, the resource is in a failed, not in a stopped or not active states. They are different things in pacemaker nomencluture. What should we do here? Should we include the failed resource in the Stopped resources list?

0.7.0+git.dev39.1640009634.6e57174: amazing @arbulu89

authors: Zaoliang abravosuse arbulu89

repo: trento-project/trento


text:
Add provider field in the cloud details section

Add the provider field in the cloud details:

Not bad, do we want to capitalize the string?

The other remaining providers would by acronyms most probably.
We could put:

Azure
AWS
GCP
Would this be better?

Yeah I like this @arbulu89 :smile:

@dottorblaster
Changes done in: https://github.com/trento-project/trento/pull/711/commits/d2943d14f3879ed0b287838b8c5b5b006e636eab


text:
Added safe check before setting termguicolors

What ?
Checking if termguicolors available & then setting it.
Why is this needed ?
https://github.com/trevordmiller/nova-vim/issues/56

@PezCoder thank you for your interest and contribution. However, two things:

the compiled files shouldn't be editing directly:

I'm not interested in supporting older versions of Vim since the maintenance cost is high to deal with multiple color values per group. Please see the comments on a similar closed pull request: https://github.com/trevordmiller/nova-vim/pull/52

Thanks for using Nova! I would recommend upgrading to latest Vim 8 as it has many improvements :)

authors: PezCoder trevordmiller

repo: trevordmiller/nova-vim


text:
Set storage to user-owned, change entity identification

Fixes #115

Download:
Environment: MINGW=C:\Qt\Tools\mingw530_32, QTDIR=C:\Qt\5.11\mingw53_32, QT=5.11, ARCH=x86
installer/trik-studio-installer-master-x86.exe
trik-studio-master_qt5.11_x86.zip
Environment: MINGW=C:\Qt\Tools\mingw492_32, QTDIR=C:\Qt\5.6\mingw49_32, QT=5.6, ARCH=x86
installer/trik-studio-installer-master-x86.exe
trik-studio-master_qt5.6_x86.zip

authors: AppVeyorBot iakov

repo: trikset/trik-studio


text:
🛑 CMC Telecom is down

In fb9bb83, CMC Telecom (http://hcmspeedtest.cmctelecom.vn:8080) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CMC Telecom is back up in 9f32eda after 6 minutes.

repo: trilwu/vn-isp-monitoring


text:
FEATURE REQ: Prediction of regionwise COVID cases based on the data from confirmed cases and self reported cases

Utilize both encrypted and redacted data for predicting regionwise COVID cases.

I think this is likely also a Healthcare Authority operation, not really an app-side feature.  Do you agree?

I think it would be very useful and fairly easy to implement. I'm of the opinion that we should try to release the strain and expectations of any health "authority", as much as possible. In addition, (clearly?) not all health authorities have the possibility and time to implement this right now.

Strongly disagree, again. We don't have a team of epidemiologist and physicians to validate those data.
Confirmed cases are biased by the people who reach the healthcare providers (especially in the US, not 100%) and those who are tested (again, not 100%) and doesn't track asymptomatic and presymptomatic which are still contagious (to a percentage yet unknown) and thus generate contacts.
Would not implement in the app.

@andreanuzzo
I think the issue is in the title "prediction". If we skip that word, it would be very useful to have a heat-map like picture over your own city or neighborhood. I completely agree that we should not have to employ any epidemiologist for this. But I do see the important advantage of being able to self-report, especially as there are now thousands of PoC kits being sold online for people to test themselves at home. They need a way to self-report.  (Like I mentioned in #309.)
NOTE. Those the anti-body kits are far better to help determine and detect otherwise the large pool of unknown cases. However, they are not directly telling you if you are contagious, unless you have stayed home AND been well in the last 3 weeks.

Closing this issue out as we have taken it into consideration and documented the feedback on this page in Jira.

authors: E3V3A Patrick-Erichsen andreanuzzo penrods tremblerz

repo: tripleblindmarket/private-kit


text:
Upgrade to Swift 4

After merging this PR, please create a 2.0.0 tag:
cd HidingNavigationBar/
git checkout master
git pull origin master
git tag 2.0.0
git push origin 2.0.0

Then, send an update to CocoaPods, that way we can just run pod update HidingNavigationBar and get all of the Swift 4 goodies:
pod trunk push

Thanks!

Thank you very much for handling the migration  👍

authors: jeffaburt tristanhimmelman

repo: tristanhimmelman/HidingNavigationBar


text:
[TOOLS] Move backend template src files to third_party/tools folder

Triton AOT compiler use template files for cuda program interface generation now, I think it's more reasonable to put them to third_party/tools folder instead of public folder.
Also package_data in setup.py needs change (follows language/extra), because compile.py itself will be executed from the python interpreter.

New contributor declaration

[x] I am not making a trivial change, such as fixing a typo in a comment.

[x] I have written a PR description following these
rules.

[x] I have run pre-commit run --from-ref origin/main --to-ref HEAD.

Select one of the following.

[ ] I have added tests.

/test for lit tests
/unittest for C++ tests
/python/test for end-to-end tests

[x] This PR does not need a test because FILL THIS IN.

Select one of the following.

[x] I have not added any lit tests.
[ ] The lit tests I have added follow these best practices,
including the "tests should be minimal" section. (Usually running Python code
and using the instructions it generates is not minimal.)

@ptillet  Could you take anther look or invite appropriate reviewers to review for this PR?

repo: triton-lang/triton


text:
hotfix: restrict DiffEqBase.jl to let CI pass

Closes #1784
A better fix would be #1785 but there seems to be something missing for it right now...

Does not seem to work (yet)?

Installed DiffEqBase ─────────────────────── v6.144.1

That's the line from installing the package. I modified the settings for the tests. Thus, it should downgrade DiffEqBase.jl when running tests.

Ok. But shouldn't we then just restrict it for Trixi.jl itself, and not just the tests? Otherwise people might still end up with the wrong version, wouldn't they?

We don't depend on DiffEqBase.jl explicitly in Trixi.jl.

authors: ranocha sloede


text:
fix HLL flux with vanishing wave speeds; closes #502

I fixed the HLL flux. From my point of view, this cannot introduce any spatial bias. If any reasonable wave speed estimates gives zero for both the minimal and maximal wave speed, the solution of the associated Riemann problem is constant in time. Hence, the fluxes at the left and right state are identical (Rankine-Hugoniot).
Shall I run an example problem using this branch to stress spatial symmetry? If so, which one (with which parameters, final time, ...)?

Here are some plots of numerical solutions (at the final time)

trixi_include("examples/2d/elixir_euler_blast_wave_amr.jl", surface_flux=flux_hll, cfl=0.1)

trixi_include("examples/2d/elixir_euler_blast_wave.jl", surface_flux=flux_hll, cfl=0.5)

These look quite symmetric to me.

These look quite symmetric to me.

Yes, but IIRC, you cannot easily spot the difference in the solution itself, but rather in the shock/AMR indicator values and/or the AMR grid resolution.
Sorry for seeming to be overly fussy about this, but I know that I have encountered the non-symmetry issue already at least twice in the past year, so I don't want it to (once in FLUXO, once in Trixi), and I don't want to set us up for a third time...

You could argue in another way: If this change would introduce symmetry issues, this could only be caused by the single case where both wave speed estimates are zero. Well, we cannot have something like this in our setups since we would have stumpled across this bug by getting NaNs...

@sloede: @gregorgassner approved this PR. Can we merge it?


text:
Height of the terminal is not taken into account

Hi,
I tried to use YouTube-viewer under the terminal and display the comments for the selected video. My terminal displays env variable LINES=33, but the YouTube-viewer shows more comments than it can be displayed in one screen, so I have to scroll up. That is not very convenient. Could youtube-viewer make use of terminal LINES to display content in pages which would fit the screen?
Regards,
Piotr

You can try the --results=n option, which will limit the number of results per page.
youtube-viewer --results=5 --comments 'https://www.youtube.com/watch?v=AuA2EAgAegE'

However, this will not guarantee that the comments will fit in one screen. Another approach would be to use the less command, similar to:
youtube-viewer --comments 'https://www.youtube.com/watch?v=AuA2EAgAegE' --no-interactive | less

...but built into youtube-viewer. I think this would work, but I will have to think a little bit about it. Probably I will add it as an option disabled by default.
Thanks for the report.

Thanks for the hints. It is for sure some workaround. However this paging is affecting all the places (like :h command in interactive session). Nice to have as the option or automatically used reading LINES terminal variable (if present).

Making youtube-viewer's various output functions terminal size aware would be a definite enhancement.

authors: ZaxonXP dokpm0 trizen

repo: trizen/youtube-viewer


text:
🛑 Nagios is down

In 1b937c2, Nagios (https://nagios.tronflix.app) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Nagios is back up in e2b3c83.

repo: tronyx/upptime


text:
🛑 Lidarr is down

In ddd0c69, Lidarr (https://tronflix.app/lidarr/activity/queue/) was down:

HTTP code: 302
Response time: 123 ms

Resolved: Lidarr is back up in 8dd1582 after 6 minutes.


text:
🛑 qBit is down

In ecf7616, qBit (https://tronflix.app/qbit/) was down:

HTTP code: 302
Response time: 85 ms

Resolved: qBit is back up in ff15a93 after 2 hours, 17 minutes.


text:
🛑 Lidarr is down

In c056d0d, Lidarr (https://tronflix.app/lidarr/activity/queue/) was down:

HTTP code: 520
Response time: 25 ms

Resolved: Lidarr is back up in e1993d3 after 8 minutes.


text:
🛑 Ombi is down

In 9948a7a, Ombi (https://tronflix.app/ombi/) was down:

HTTP code: 520
Response time: 40 ms

Resolved: Ombi is back up in 73d8860 after 6 minutes.


text:
🛑 PiHole Backup is down

In 6ee980c, PiHole Backup (https://pihole-backup.tronflix.app/admin/login.php) was down:

HTTP code: 520
Response time: 227 ms

Resolved: PiHole Backup is back up in b0bc99a after 8 minutes.


text:
🛑 Ombi is down

In a40207b, Ombi (https://tronflix.app/ombi/) was down:

HTTP code: 520
Response time: 64 ms

Resolved: Ombi is back up in 84ab66d after 11 minutes.


text:
🛑 Plex is down

In ed32014, Plex (https://tronflix.app/plex/web/index.html) was down:

HTTP code: 302
Response time: 147 ms

Resolved: Plex is back up in 589b0c0.


text:
rewrote the library with google gson

Currently all the test case are getting passed with a modification in testcases.
net.sf.json generates "timeout":30 for TIMEOUT(30.0f) but
gson  generates "timeout":30.0.
Further I have some questions/suggestions/Modifications.

tropo.parse(httpservletrequest) should be removed. Currently rest framework like spring and jersey internally call the request.getInputStream() method which can be called only once, so again calling tropo.parse causes a second call to request.getInputStream() and it fails.
We already have a method tropo.parse(String) which is enough I think.

What is the role of parent field in Action.class.

In Action.class there are two method for the same purpose json() and getNode() ?.

accumulate not supported in gson, So I had to do manual accumulate, please review that code strongly.

In gson there is no method put(string, object). Instead it has putProperty(string, Character); putProperty(string, Number); putProperty(string, String); and putProperty(string, Boolean); Please review this modification too.

I have updated the pom with version 1.0.0 and artifact id tropo-webapi-java-gson. Please changed it as per your requirement.

There is a commented code with TODO in Action.class, I didn't understand what it was trying to do. Please have a look

Looking forward for your response.

Thanks @hemantsonu20. I've gone through your changes and they look good therefore pushed the pull request. Answering your questions:

Parent is for complex cases with nested actions like when you want to execute something like "and(on(...).say(...),...)". In this example the and method gets the say action as a parameter, but that is not the object you want to add when building the json structure but the parent ("on") object instead.

Yep. Likely some leftover.

They looked good.

Bumped it to 0.4.0

It sets the pointer to the recently added element. But as the json libraries will copy it then you need to refetch it again.

thanks @mpermar for accepting pull request and explanation. I added two points on number 1 by mistake. You forgot to answer first 1 related to tropo.parse(request).
if we emove this method only,  we dont need ioutil as well as mock request/response file in test.

Ah, right. The library has to be usable outside of any concrete frameworks like Jersey/Spring. That's why there is both a parse(request) and a parse(string). If you are on Jersey/Spring just use the parse(string).

repo: tropo/tropo-webapi-java


text:
MaxListenersExceededWarning: Possible EventEmitter memory leak detected

Hi,
I'm getting this error whenever I upload a file:
(node:49079) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 connection listeners added. Use emitter.setMaxListeners() to increase limit
The upload completes just fine, but I obiously need to address this issue.
I have this in an app that is also running Hapi, but I disabled that and I still get the same error.
By way of a second question. is there an event that fire when a file has been uploaded?

Re: MaxListenersExceededWarning
How many connections are you making to the FTP Server?
Are you adding listening events to the FtpServer or Connection instances?
Do you have other event emitters in the code you're using?
I've never seen this warning while using this module, I'm thinking more than 10 events are being listened to on either the FtpServer or Connection.

Re: Event on file upload
Current there is no event for file uploads or anything like that. That is a great idea though, I think some event overhaul would be great.

I'm just going to lock this, I have a feeling it's just your settings for event listeners, and shouldn't be an issue.
Feel free to comment with an update.

Sorry. I didn't notice your response. I commented out every other service in the app (Hapi, SFTP etc.) so that it was only this left. I was still seeing that error.
Off hand I cannot recall whether it was the FtpServer to Connection instances I had the listeners on. Due to some other issues I ended up using another FTP module - modified to suit my very specific needs (a client with a very strange FTP client sending us data).

authors: ianbale trs

repo: trs/ftp-srv


text:
Error: sender doesn't have enough funds to send tx.

I have the issue "Error: sender doesn't have enough funds to send tx.  The upfront cost is: 6000000000000000 and the sender's account only has: 0". It occurs every time after doing first transaction.
My ganache version is:-

Thanks @princesinha19 for reporting this. Can you provide steps to reproduce?

Possibly related to https://github.com/trufflesuite/ganache-core/issues/161

@princesinha19 Unfortunately we can't reproduce the error with your steps. Given your error, it seems that you're not using the correct account in your transaction. Please reopen if you have specific reproduction steps. Sorry we couldn't be more help!

I have solved this issue by removing -h 0.0.0.0 parameter from the command.
Thanks for your comments @davidmurdoch @seesemichaelj.

repo: trufflesuite/ganache-cli


text:
electrotyper, faisan

This pull request was generated by the 'mq' tool

/trunk merge

repo: trunk-io/mergequeue-staging


text:
afunction, chlorguanide

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[a,c]

/trunk merge


text:
antiforeignism, gullibility

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[a,g]

/trunk merge


text:
browzer, enormous

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[b,e]

/trunk merge


text:
dasycladaceous, gahrwali

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[d,g]

/trunk merge


text:
glucosaemia, breakneck

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[b,g]

/trunk merge


text:
gasproof

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[g]

/trunk merge


text:
finises

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[f]

/trunk merge


text:
clearheaded, entitlement

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.4
logical conflict every: 100
sleep for: 300s
[pullrequest]
requests per hour: 30
deps=[c,e]

/trunk merge


text:
daishikis

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[d]

/trunk merge


text:
fleabags

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.4
logical conflict every: 100
sleep for: 300s
[pullrequest]
requests per hour: 30
deps=[f]

/trunk merge


text:
gangrening, evocators

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.4
logical conflict every: 100
sleep for: 300s
[pullrequest]
requests per hour: 30
deps=[e,g]

/trunk merge


text:
bladeless, caritas

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[b,c]

/trunk merge


text:
claspt, alfilaria

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[a,c]

/trunk merge


text:
brandish, condenses

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 100
sleep for: 300s
close stale after: 4 hours
[pullrequest]
requests per hour: 0
deps=[b,c]

/trunk merge


text:
funnellike, gamey

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[f,g]

/trunk merge

repo: trunk-io/mergequeue


text:
gallus, eolopile

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[e,g]

/trunk merge


text:
dynagraph, counterwill

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[c,d]

/trunk merge


text:
exarchic, curvaceously

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[c,e]

/trunk merge


text:
architrave, clackdish

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[a,c]

/trunk merge


text:
belltopper, fearfuller

This pull request was generated by the 'mq' tool

/trunk merge


text:
floodwall, dacryosolenitis

This pull request was generated by the 'mq' tool

/trunk merge


text:
adpress

This pull request was generated by the 'mq' tool

/trunk merge


text:
gametangium

This pull request was generated by the 'mq' tool

/trunk merge


text:
garner

This pull request was generated by the 'mq' tool

/trunk merge


text:
brawlys, finnmarks

This pull request was generated by the 'mq' tool

/trunk merge


text:
glutinate, cranebill

This pull request was generated by the 'mq' tool

/trunk merge


text:
glucosone, angledozer

This pull request was generated by the 'mq' tool

/trunk merge


text:
erept, caldarium

This pull request was generated by the 'mq' tool

/trunk merge


text:
fault, bumbledom

This pull request was generated by the 'mq' tool

/trunk merge


text:
ensepulchering, astragalonavicular

This pull request was generated by the 'mq' tool

/trunk merge


text:
biotechnologies, eery

This pull request was generated by the 'mq' tool

/trunk merge


text:
coffinmaker, excitatory

This pull request was generated by the 'mq' tool

/trunk merge


text:
growed, arthropoda

This pull request was generated by the 'mq' tool

/trunk merge


text:
gentleship, brigander

This pull request was generated by the 'mq' tool

/trunk merge


text:
euthenics, chargeship

This pull request was generated by the 'mq' tool

/trunk merge


text:
eupomatia, dazzlement

This pull request was generated by the 'mq' tool

/trunk merge


text:
banefulness, gynandrism

This pull request was generated by the 'mq' tool

/trunk merge


text:
detonated, acylase

This pull request was generated by the 'mq' tool

/trunk merge


text:
fleckless

This pull request was generated by the 'mq' tool

/trunk merge


text:
cyclonologist, almudes

This pull request was generated by the 'mq' tool

/trunk merge


text:
begeck, flummox

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[b,f]

/trunk merge


text:
epilogation, angelfish

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[a,e]

/trunk merge


text:
filleting, demipuppet

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[d,f]

/trunk merge


text:
anoxybiosis, clipperman

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[a,c]

/trunk merge


text:
citronellic

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[c]

/trunk merge


text:
exenteritis, committitur

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[c,e]

/trunk merge


text:
endometria

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[e]

/trunk merge


text:
bewinter, finfoot

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[b,f]

/trunk merge


text:
diphtherial, feudalism

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[d,f]

/trunk merge


text:
fitfulness, brushability

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[b,f]

/trunk merge


text:
exarchal, drubbly

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[d,e]

/trunk merge


text:
anthropocosmic, concept

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[a,c]

/trunk merge


text:
coprolagnist, distortable

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[c,d]

/trunk merge


text:
diapophysial, bellflower

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 100
deps=[b,d]

/trunk merge


text:
autosome, fust

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 2100s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[a,f]

/trunk merge


text:
gooseskin, figurines

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[f,g]

/trunk merge


text:
breediness, crapshooter

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[b,c]

/trunk merge


text:
enchasten, fucate

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[e,f]

/trunk merge


text:
etherialise, goyetian

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[e,g]

/trunk merge


text:
fundable, euroclydon

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[e,f]

/trunk merge


text:
elaterium, footsoreness

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[e,f]

/trunk merge


text:
dorian, bugeye

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[b,d]

/trunk merge


text:
gynecophoric, eviller

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[e,g]

/trunk merge


text:
awedly, bestselling

This pull request was generated by the 'mq' tool
[test]
flake rate: 0.1
logical conflict every: 1000
sleep for: 600s
close stale after: 24 hours
[pullrequest]
requests per hour: 20
deps=[a,b]

/trunk merge


text:
Bazel cache Problem

Hi,
I am using trunk in a Bazel project. It works nicely so far, the only issue that I have is that the Bazel calls by trunk constantly invalidate the cache of the Bazel server. That means that I have to recompile every dependency, when I want to run a file (takes about 1 minute, instead of an incremental build taking 10 secs).
Maybe this issue is caused by the env being different for my zsh shell and trunk. Are there any advises on how to fix this?
Best,
Henrik

Hi Henri,
Are you running with come --config  locally or other bazel flag?
Trunk runs bazel query (with default options) as if it was a plain bazel command.
It will pick up things in your .bazelrc, but not what you manually specify on the cli.

Yes, that could be part of the issue. I usually compile with -c opt. Nevertheless, It would be great, if one could control more arguments.

I submitted the request to the product team.
As far as our setup go, we add this to our bazelrc:
# Make a "user.bazelrc" file in the repo root to store personal settings, it's gitignored
try-import %workspace%/user.bazelrc

the try-import statement doesn't fail if the file doesn't exist and we add our bazel flags there for local dev. That way it gets picked up by everything that calls bazel.

Closed as stale

authors: henrixapp pat-trunk-io

repo: trunk-io/plugins


text:
Decouple _render method from _applyTransform.

the _render method (after possibly being renamed) can be simply for calculating sizing (after #66) and transform matrices. A separate function can apply the updated values to DOM or WebGL (eventually the DOMRenderer or WebGLRenderer).
Also related: #70. We want Node to only care about updating size and matrix values, but not about how to pass those values to DOM or WebGL.

This was completed when I re-organized and moved logic into ElementManager.applyTransform. #66 can be done separately.

repo: trusktr/infamous


text:
fix: Fix starting index for covariance update

See RHOAIENG-8257.
This PR fixes a problem where a non-convergence error would occur when sampling the synthetic background with only one sample.
This was caused:

Initial covariance not properly initialised
Covariance calculation should start only when n=2

/test all

/test trustyai-explainability-e2e

authors: RobGeada ruivieira


text:
solar_system file missing

Describe the bug
solar_system file is not uploaded
Steps to reproduce the bug
Unable to run it
Expected behavior
No response
Screenshots
No response
NuGet package version
No response
Additional context
No response

we can test with any local file

repo: tryAGI/LangChain


text:
shopping cart / phone mask / empty cart message

Hi,
I have a great prayer, and I'm sure they are somewhat more skilled than me. That's why I'm asking for help.

the shopping cart (the one at the bottom of the page) appears only when a product is inserted into the cart.

how do I delete the phone's mask (country prefix) so that it does not appear anymore.

How do I replace the message: Do I help you to spend your money :) in the empty basket?

Thank you,

To delete a mask, you need to manually find the appropriate layouts and edit the code, similar to: <input type="tel" name="telephone" value="{{ telephone }}" id="input-telephone" class="validate" placeholder="+7_(___)___-____" data-inputmask="'alias':'phone'">
Change it to this: <input type="tel" name="telephone" value="{{ telephone }}" id="input-telephone" class="validate">
This template matches the file: catalog/view/theme/materialize/template/account/register.twig
The cart template in OpenCart is edited here: catalog/view/theme/materialize/template/common/cart.twig

Thank you very much...

ПРивет) Нужна подсказка. Я установил шаблон на Opencart 3.0.0 и после установки слетети CSS. Как можно устранить этот вопрос. Я новичек, может чего и не понимаю

Здравствуйте @DmitryUA13!
Следуйте инструкции, Вы не выполнили обязательный пункт для OpenCart со страницы 4.

authors: DmitryUA13 openscart trydalcoholic

repo: trydalcoholic/opencart-materialize


text:
Some new tests

@JuliaRegistrator register(branch="release-1.2.0")

Registration pull request created: JuliaRegistries/General/51778
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v1.2.0 -m "<description of version>" f13a46507b84f842d7a183b312ec45bfb4862100
git push origin v1.2.0

authors: JuliaRegistrator tsabelmann


text:
Cannot build deb package without libpcsclite1 dependency

I'm trying to build the TSDuck deb package without smartcard support by adding the NOPCSC make variable, but the deb package is still built with a dependency on the libpcsclite1 package. Is it possible to build the package without this dependency?

Hi @cbernander,
I have fixed the makefiles so that .rpm and .deb packages are built with not more dependencies than specified on the make command line.
However, the various make NOxxx variables were essentially made for custom builds in a restricted environment. When you generate a package for a distro, it is better to take full advantage of the distro and let the package manager resolve all dependencies for you.
If you do not want to take care of dependencies before building TSDuck, the script build/install-prerequisites.sh is here to help.
I do not like the idea of different binary packages for the same version of TSDuck offering distinct sets of features. If you build a .deb package without PCSC support (or without CURL or Dektec or whatever), please keep it for your private usage. Do not distribute it. This would create some confusion.

Understood - it will only be used internally.
Thank you.

authors: cbernander lelegard

repo: tsduck/tsduck


text:
4.0+ doesn't start on restart

Describe the bug
On a home assistant restart, the add-on either doesn't seem to restart (Start on boot is selected) or MQTT messages are not received(?) .. does not pick up status of various alarm components. Worked on reboot prior to 4.0.
Home Assistant 0.114.4
Ring Hassio 4.0.4
External MQTT broker

When you say restart Home Assistant, do you mean system reboot, or just Home Assistant restart?  It's a little confusing because you mention start on boot, which isn't involved in Home Assistant restart, only a system reboot.
Also, without logs I'm not sure what you expect me to be able to do.  The add-on logs should clearly show if the add-on is running or not, and it's up to Home Assistant to start the add-on during boot.  I run this on 3 different systems and all handle restarts and reboots with no issue and the logic around this did not change in any significant way since 3.0.
One thing to check if you are talking about Home Assistant restarts, were you using the old birth/last will MQTT settings in configuration.yaml?  If you're using the web configured MQTT integration, what are your birth/last will settings there?  This is how the add-on knows if Home Assistant is restarted, although this is not related to reboots.

Hi @tsightler
If I do a Home Assistant restart (i.e. from Configuration > Server Controls), all entities upon starting up are unavailable until I restart the Ring add-on.
Sample of Ring logs
2020-09-11T02:44:22.194Z ring-mqtt ring/b995eb74-777a-4500-68e6-7fa53e76eb4c/alarm/36085e7e-75d5-4d9e-900c-46c1f5b08b19/info/state {"batteryLevel":100,"batteryStatus":"full","commStatus":"ok","firmwareStatus":"up-to-date","lastCommTime":"2020-09-11T01:45:46.630Z","lastUpdate":"2020-09-11T01:45:46.769Z","linkQuality":"ok","serialNumber":"xxx","tamperStatus":"ok"}
2020-09-11T02:44:22.963Z ring-mqtt ring/b995eb74-777a-4500-68e6-7fa53e76eb4c/alarm/cf0c233f-01ca-4906-9f3c-ac60942eff22/info/state {"acStatus":"ok","batteryStatus":"charged","brightness":0.4048583,"commStatus":"ok","lastUpdate":"2020-09-11T00:19:21.078Z","serialNumber":"xxx","tamperStatus":"ok","volume":1}
2020-09-11T02:44:24.383Z ring-mqtt Home Assistant state topic homeassistant/status received message: offline

My MQTT configuration:
mqtt:
  broker: !secret synology_ip
  username: !secret mqtt_user
  password: !secret mqtt_password
  discovery: true
  discovery_prefix: homeassistant
  birth_message:
    topic: 'hass/status'
    payload: 'online'
    qos: 0
    retain: false

Like a lot of people I'm guessing, I have a manual MQTT configuration and as far as I'm aware its default settings. Appears as if all of my other MQTT sensors are available upon reboot, this started occurring with 4.0, hope that's helpful. Thanks

As noted in the documentation of ring-mqtt, Home Assistant >0.113 changed the default birth/last will message topic from 'hass/status' to "homeassistant/status" and made birth messages default.  This was part of an overall change to standardize the way MQTT addons can monitor for Home Assistant restarts, something this script has done from the start, but many other tools never implemented.  The 4.0.0 release and beyond use this new default since they were developed and released after 0.113.  To fix it all you need to do is change 'hass/status' to 'homeassistant/status' which the script now listens for by default.
I did consider monitoring both the legacy topic and the new topic, and maybe I should do that, but I was afraid that might lead to people opening cases on other topics because their config wouldn't work (this project was one of the few that was encouraging people to implement birth messages).  Note that this change actually happened back in the 3.x versions (about 6 weeks ago), and is clearly documented on the ring-mqtt site with a dedicated section suggesting that everyone modify their configs to match this new default.
I know it's not easy to keep up with all of this stuff, but the good thing is, it's standard now, so shouldn't change in the future.

BTW, the likely reason your other MQTT devices show up is because a lot of other tools send device discovery messages with retain which allows Home Assistant to "rediscover" these devices automatically, even if the MQTT component isn't available.  I elected a long time ago not to do this as it leads to other behaviors which I just don't like, primarily with stale devices that require manual user steps to remove from MQTT and devices that appear in Home Assistant as online even if the MQTT component servicing them is not running, etc.  Also, many other tools don't even bother to send real availability state about devices, but I wanted users to know clearly if state data was stale, devices were offline, the script stopped, etc. so I implemented robust state and and support for birth messages from the very start of this project, and resisted the urge to simply hide these behaviors by using retain.
For example, I can block one of my Wifi switches from the network and restart Home Assistant and HA will still happily show the device online in whatever state it was in last.  I just don't like this behavior at all.

@tsightler thanks much for the troubleshooting, I made the MQTT configuration change and that fixed the above issue. Appreciate you pointing out the issue. I try not to 'fix' what isn't broken and must've missed that update. Hopefully this will help anyone else that may have run across the same problem.

authors: tsightler yieldhog

repo: tsightler/ring-mqtt-ha-addon


text:
Distinguish the 4 different causes for I/O errors.

This PR displays specific error messages instead of the generic ERROR: Could not open file .....

@catull cool! Thanks for cleaning this up!

authors: catull rexim

repo: tsoding/bm


text:
Does musializer not have logging?

This says to check logs but the whole project have no log files

But in windows it doesn't show any log

I think I know why. Recently they switched the subsystem to windows instead of console, which means stdio is detached

I think I know why. The subsystem is switched to windows instead of console, which means stdio is detached.

I didn't understand what you meant, so I looked around and wanted to leave some references.
I suppose it's related to the usage of /SUBSYSTEM:WINDOWS in nob_win64_msvc.c.
Link to msvc nob source (and elsewhere)
From this page:

WINDOWS
The application doesn't require a console, probably because it creates its own windows for interaction with the user. [...]

But this seems to be exactly the approach shown in raylib's build-windows.bat:
set SUBSYSTEM_FLAGS=/SUBSYSTEM:WINDOWS /ENTRY:mainCRTStartup

Link to raylib source
So I don't really know if trying other values is the way to go around this.

The equivalent flag for /subsystem:windows is -mwindows in mingw.
By default windows subsystem gui applications don’t get a console which means they don’t have stdout, stdin and stderr. You manually allocate or attach a console by using the win32 api and get stdio back and achieve a hybrid console/gui app.

authors: Markos-Th09 Subhranil-Maity jgabaut

repo: tsoding/musializer


text:
Not all required fields are filled in.

First Thanks for the Integration.
I am trying to get true the setup but i al stuck @ this screen :

I am facing the same issue. I tried in the mobile app and different browsers as well. Same issue

yes facing same issue

I have the same problem.  Has anyone solved this?

repo: tsunglung/XiaomiAirFryer


text:
Quickrun runner

https://github.com/lambdalisue/vim-quickrun-neovim-job
も参考にしつつ

vital の Job 利用による、透過的job runner
intervalでのsession.outputでの進捗表示対応

できたらいいな

vital jobで配列しか受けない + 先頭がコマンド単体である必要があり、Windowsが無事死亡。
どうしよう。

repo: tsuyoshicho/vimrc-reading


text:
Add rudimentary mobile support

Double tap to draw/delete
Long tap to ping
Fix dragging characters in mobile
Fix unintentional text selection bugs

bors merge

repo: ttbud/ttbud


text:
Does 2_evaluate.sh work properly?

Hi, thanks for your work.
I executed Gaitgraph / experiments / 2_evaluate.sh, then it gave the following output.
Is this working properly?
../data/casia-b_pose_valid.csv: 148464: ./074-nm-06-180/000105.jpg,163.31964,59.367306000000006,0.62753356,160.98886000000002,57.036533,0.6496187,163.31964,57.61923,0.6171515999999999,160.40617,57.61923,0.91751564,167.98117,57.61923,0.9350721,156.91002,68.690384,0.90779334,172.64272,68.690384,0.9123460999999999,153.41386,82.09231,0.87953293,174.97348,80.926926,0.877726,153.41386,93.16346999999999,0.86672676,174.97348,90.832695,0.9115324,158.6581,91.998085,0.8330506999999999,169.14656000000002,91.998085,0.8313613999999999,160.40617,110.64424,0.87980276,168.56387,110.0: not found4657,160.40617,129.2904,0.85843027,168.56387,125.79423999999999,0.86784875

Hi,
ich checked again and 2_evaluate.sh runs fine for me.
Could you send me the content of your file? It's probably just formatting issue.
Cheers,
Torben

repo: tteepe/GaitGraph


text:
Bug : Transliteration writing does not work right in butterflies.ai

The transliteration writing feature is great, please fix this bug
It does not delete the original text

Solved
@ttop32 love forever


text:
Default reference frame for spherical harmonics

Defining a spherical harmonic gravity field manually requires the specification of the reference frame in which it is defined. This is the associated_reference_frame input in tudatpy:.
https://tudatpy.readthedocs.io/en/latest/gravity_field.html#tudatpy.numerical_simulation.environment_setup.gravity_field.spherical_harmonic
Since this presently has to be the body-fixed frame of the body, I propose to make this input an optional one, with the default being whatever the present identifier of the body-fixed frame is.

Code added here to address this issue:
https://github.com/tudat-team/tudat/tree/feature/po_updates
https://github.com/tudat-team/tudatpy/tree/feature/po_updates
https://github.com/tudat-team/tudat-multidoc/tree/feature/po_updates

Merged into develop (tudat/tudatpy) and main (tudat-multidoc)

repo: tudat-team/tudat


text:
Secrets deletion proposal

Proposal and implementation for a DELETE secret operation. It could be desirable that if a secret is removed from Vault, it is removed also from the K8s cluster which is referencing it.
Some posible behaviours:

Delete in Vault => Delete on K8s and fail if the configmap is not updated
Delete in Vault => Delete section in Configmap and delete the secret in K8s
Delete in Vault => Just fail until the configmap is updated with the secret removed
Delete in Configmap => Just do nothing as we do

Anything else?

Closing as it's fixed by #30

authors: fcgravalos fllaca

repo: tuenti/secrets-manager


text:
Edit of run_hwid_check.bat

Major changes:
Added firmware update function.
Added stops for previously unexpected conditions.
Changed order of functions so HWID always has to match before further updates.
Minor changes:
Cleaned code.
Changed code readability and order.

Current bootloader version of all trackers I have is v1637337510. The script checks for a bootloader version of 1629157907

To note, the firmware function is checking for the firmware currently found in the SteamVR folder. That version is 1632556731. The script checks for said version. If the device version is older than that it updates with the locally stored file "tundra-tracker_application_v1632556731.fw".

Updated script only checks if bootloader is 1622649182 or 1629157907. If it is 1622649182 it gets updated. Everything else gets ignored and the script gets stopped.

Major changes:
Added check for amount of connected devices.
Made the script exit after pressing enter.

Thank you for making these edits!
As I was saying on the the forum, I don't know how I feel about the tool flashing firmware into the tracker.  For the purpose that you have outlined, I think that it is good however I wouldn't want this to become the main firmware flashing tool.
I always get worried about customers flashing firmware into their index and breaking it.
I'll give the merge a try and we can evaluate long term

Flashing the firmware directly does pose a risk. As note in line 94 it is a quick change to just verify that a minimum firmware level is reached before continuing further on so just the most outdated firmware gets updated, or to just end the script at that point and ask them to update the firmware via SteamVR before continuing. I just don't know which minimum firmware level would be save.

My worry is mainly about flashing firmware into a device with a HWID that is not supported.  The script is actually pretty safe from this perspective.  Unfortunately the consequences of someone making a mistake are really unfortunate too.  If you strategically hit ctrl+C at jus thte right time the batch file may just skip a step instead of actually executing the check I think.

authors: Keigun-Spark lgbeno