text:
Error

Hi!
lib/ui/chat_head.dart:96:7: Error: No named parameter with the name 'resizeToAvoidBottomPadding'.
resizeToAvoidBottomPadding: false,
^^^^^^^^^^^^^^^^^^^^^^^^^^
../../../flutter/packages/flutter/lib/src/material/scaffold.dart:1451:9: Context: Found this candidate, but the arguments don't match.
const Scaffold({
^^^^^^^^
FAILURE: Build failed with an exception.

Where:
Script 'D:\Programowanie\flutter\packages\flutter_tools\gradle\flutter.gradle' line: 991

What went wrong:
Execution failed for task ':app:compileFlutterBuildDebug'.

Process 'command 'D:\Programowanie\flutter\bin\flutter.bat'' finished with non-zero exit value 1

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

Get more help at https://help.gradle.org

BUILD FAILED in 12s
Running Gradle task 'assembleDebug'...
Running Gradle task 'assembleDebug'... Done                        12,9s
Exception: Gradle task assembleDebug failed with exit code 1
Please help, I need it

@pudelos  Hi there! look like u r using updated version of sdk as this parameter is now deprecated so comment it and push the code to new branch the owner of repo will merge it .

authors: pudelos uzairleo

repo: mhmzdev/Messenger-Chat-Head-Flutter-UI


text:
Markdown plugin to generate meta elements from prelude items description and keywords

Right now the markdown plugin uses the front matter 'title' item for use in the html title element. It would be great if it could also generate html meta elements from the markdown front matter items description and keywords:
description: ... becomes <meta name="description" content="..." />
keywords: ... becomes <meta name="keywords" content="..." />

I haven't seen the meta keywords tag be relevant for years... description, I could see that being useful. (Keywords though? Search engines don't use that anymore AFAIK.)
Just trying to stay as simple as possible. :) At what point does it become better to fill out a custom template?

It just seemed logical for a module that translates into html. I think it would make a lot of sense to do it, and it's really easy and quick win. Maybe only "description", "author" and perhaps "copyright"? Or you could just put any legal meta name in the front matter into a meta tag. Setting the front matter is a user choice, and there is an obvious way of translating/using it.

I think it's a good idea, and i would do it, but i see a small problem.
Not all meta tags are applicable via
<meta name="key" content="value" />
For example with HTML5 we got
<meta charset="...">
<meta http-equiv="..." content="..."/>
And i think, if we do this, next month we get an request,
Adding generics headers with key value pairs ;)

I think the meta http-equiv elements aren't in wide use anymore now that we have meta charset="utf-8" (which markdown already uses).

Okay,
so i would implement a list with allowed meta tag names, like description, author and so on.
Then check every front matter if it's in this list or not.
If we found the front matter, adding that to another list and iterate in the template over the list like we do it with the styles.
But i think we should not remove it from the existing Variables Map, so we don't kill existing templates and their use of those front matters..

I think there is no actual clash between template use of front matter items and using them as a meta tag when it is a valid meta tag. But to avoid unhappiness it's probably best to just have a limited and useful list of supported meta tags.

source: gharchive/issue

authors: mholt pbeckmann pepa65

repo: mholt/caddy

license_type: permissive

license_source: bigquery


text:
If an encoding has a qvalue strip it

name: Pull request
about: Take in consideration the the qvalue when matching Accept-Encoding
title: ''
labels: ''
assignees: ''

1. What does this change do, exactly?
Take in consideration the the qvalue when matching Accept-Encoding.
https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.3
2. Checklist

[x] I have written tests and verified that they fail without my change
[x] I have squashed any insignificant commits
[x] This change has comments explaining package types, values, functions, and non-obvious lines of code
[x] I am willing to help maintain this change if there are issues with it later

Thanks... someone will review this eventually. :)
What is your specific use case / need for this (advanced content negotiation)? i.e. what are your actual requirements?

None.
I was reviewing the code and I noticed that qvalue was not properly handled.
So I supplied a fix.

Okay. I appreciate it, I really do! But since there isn't an actual use case for it yet, it isn't a huge priority for me personally (Caddy 2 is currently on my plate, and if q-factor'ed content negotiation is important, I can work it into Caddy 2). But I see that this is a decent change since it has tests; albeit the feature is only partially implemented (which is still OK).
If someone considers this a priority they are welcome to review it and I can see about merging it in, I just can't get to it myself quite right now. Thanks!

Feel free to close the PR if it does not fit your needs or if you know if
that section of code will be rewritten
On Wed., May 29, 2019, 6:17 p.m. Matt Holt, notifications@github.com
wrote:

Okay. I appreciate it, I really do! But since there isn't an actual use
case for it yet, it isn't a huge priority for me personally (Caddy 2 is
currently on my plate, and if q-factor'ed content negotiation is important,
I can work it into Caddy 2). But I see that this is a decent change since
it has tests; albeit the feature is only partially implemented (which is
still OK).
If someone considers this a priority they are welcome to review it and I
can see about merging it in, I just can't get to it myself quite right now.
Thanks!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mholt/caddy/pull/2630?email_source=notifications&email_token=AATACXDHJFBRMW5Q34FCYJDPX36INA5CNFSM4HQVOHA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWQZMHQ#issuecomment-497128990,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AATACXBYNX2QGCWFZUQXC4LPX36INANCNFSM4HQVOHAQ
.

FWIW, Caddy 2 does have content negotiation respecting q-values with regards to dynamic encodings: https://sourcegraph.com/github.com/caddyserver/caddy@0d3f99e85a089a6a772ae38f426b5cd5f2f4583f/-/blob/modules/caddyhttp/encode/encode.go#L232
However, content negotiation in general still needs work. I am tracking this in https://github.com/caddyserver/caddy/issues/2665. Although, I am not sure if a matcher is the right approach anymore. (Discuss before implementing!) But would be happy to have your help on it if you're interested.

source: gharchive/pull-request

authors: mholt rouzier


text:
should package.json main be index.js ?

So people can also use craftyjs as a lib ?

When you use a module, it uses the main as the import anyway, does it not? If you require craftjs it'll load app.js.
app.js however does not do a module.export.

I would suggest that index.js exports all our types and factory functions, and app.js requires './index.js' or '.'

yes that's what we do. Hence the issue.

repo: mhsjlw/craftyjs

license: MIT

license_source: github-api


text:
_rkFDQPSolveASMInitIndex()中の不正メモリアクセス

@n-wakisaka
volume接触力計算で不正メモリアクセスが発生しているようです。
example/chain/arm_wall_testを走らせると、終了時に
malloc(): smallbin double linked list corrupted
が出ます。
valgrindのレポートを貼り付けます（長いです）。直接的には_rkFDQPSolveASMInitIndex()の中で起こってるようですが、rkCDColVolBREPVert()で二重解放か何かやっちゃってるようにも見えます。何かわかりますか？
zhidao@ubuntu[1289] valgrind --tool=memcheck --leak-check=yes ./arm_wall_test
==29581== Memcheck, a memory error detector
==29581== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==29581== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==29581== Command: ./arm_wall_test
==29581==
==29581== Invalid read of size 1
==29581==    at 0x48FA4DC: _zQHHorizon (zeo_bv3d_ch.c:365)
==29581==    by 0x48FA4DC: _zQHInc (zeo_bv3d_ch.c:421)
==29581==    by 0x48FBB4C: _zQHCreate (zeo_bv3d_ch.c:463)
==29581==    by 0x48FBF26: zCH3DPL (zeo_bv3d_ch.c:516)
==29581==    by 0x489DAB8: _rkCDBREPMergeCH.isra.0 (rk_cd.c:641)
==29581==    by 0x489DBF5: _rkCDPairColVolBREP (rk_cd.c:679)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x486500F: _rkFDUpdateRef (rkfd_sim.c:546)
==29581==    by 0x48650FE: rkFDUpdate (rkfd_sim.c:564)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==  Address 0x7d64890 is 144 bytes inside a block of size 152 free'd
==29581==    at 0x484B27F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48F91E2: _zQHFacetListDestroy (zeo_bv3d_ch.c:112)
==29581==    by 0x48FAF66: _zQHInc (zeo_bv3d_ch.c:428)
==29581==    by 0x48FBB4C: _zQHCreate (zeo_bv3d_ch.c:463)
==29581==    by 0x48FBF26: zCH3DPL (zeo_bv3d_ch.c:516)
==29581==    by 0x489DAB8: _rkCDBREPMergeCH.isra.0 (rk_cd.c:641)
==29581==    by 0x489DBF5: _rkCDPairColVolBREP (rk_cd.c:679)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x486500F: _rkFDUpdateRef (rkfd_sim.c:546)
==29581==  Block was alloc'd at
==29581==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48FB5EC: _zQHSimplex (zeo_bv3d_ch.c:188)
==29581==    by 0x48FB5EC: _zQHCreate (zeo_bv3d_ch.c:457)
==29581==    by 0x48FBF26: zCH3DPL (zeo_bv3d_ch.c:516)
==29581==    by 0x489DAB8: _rkCDBREPMergeCH.isra.0 (rk_cd.c:641)
==29581==    by 0x489DBF5: _rkCDPairColVolBREP (rk_cd.c:679)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x486500F: _rkFDUpdateRef (rkfd_sim.c:546)
==29581==    by 0x48650FE: rkFDUpdate (rkfd_sim.c:564)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==
==29581== Invalid read of size 1
==29581==    at 0x48FA4A5: _zQHHorizon (zeo_bv3d_ch.c:365)
==29581==    by 0x48FA4A5: _zQHInc (zeo_bv3d_ch.c:421)
==29581==    by 0x48FBB4C: _zQHCreate (zeo_bv3d_ch.c:463)
==29581==    by 0x48FBF26: zCH3DPL (zeo_bv3d_ch.c:516)
==29581==    by 0x489DAB8: _rkCDBREPMergeCH.isra.0 (rk_cd.c:641)
==29581==    by 0x489DBF5: _rkCDPairColVolBREP (rk_cd.c:679)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x486500F: _rkFDUpdateRef (rkfd_sim.c:546)
==29581==    by 0x48650FE: rkFDUpdate (rkfd_sim.c:564)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==  Address 0x7d64cf0 is 144 bytes inside a block of size 152 free'd
==29581==    at 0x484B27F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48F91E2: _zQHFacetListDestroy (zeo_bv3d_ch.c:112)
==29581==    by 0x48FAF66: _zQHInc (zeo_bv3d_ch.c:428)
==29581==    by 0x48FBB4C: _zQHCreate (zeo_bv3d_ch.c:463)
==29581==    by 0x48FBF26: zCH3DPL (zeo_bv3d_ch.c:516)
==29581==    by 0x489DAB8: _rkCDBREPMergeCH.isra.0 (rk_cd.c:641)
==29581==    by 0x489DBF5: _rkCDPairColVolBREP (rk_cd.c:679)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x486500F: _rkFDUpdateRef (rkfd_sim.c:546)
==29581==  Block was alloc'd at
==29581==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48F977D: _zQHHorizonNewFacet (zeo_bv3d_ch.c:339)
==29581==    by 0x48FAD5A: _zQHHorizon (zeo_bv3d_ch.c:392)
==29581==    by 0x48FAD5A: _zQHInc (zeo_bv3d_ch.c:421)
==29581==    by 0x48FBB4C: _zQHCreate (zeo_bv3d_ch.c:463)
==29581==    by 0x48FBF26: zCH3DPL (zeo_bv3d_ch.c:516)
==29581==    by 0x489DAB8: _rkCDBREPMergeCH.isra.0 (rk_cd.c:641)
==29581==    by 0x489DBF5: _rkCDPairColVolBREP (rk_cd.c:679)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x486500F: _rkFDUpdateRef (rkfd_sim.c:546)
==29581==
==29581== Invalid read of size 1
==29581==    at 0x48FA4B8: _zQHHorizon (zeo_bv3d_ch.c:365)
==29581==    by 0x48FA4B8: _zQHInc (zeo_bv3d_ch.c:421)
==29581==    by 0x48FBB4C: _zQHCreate (zeo_bv3d_ch.c:463)
==29581==    by 0x48FBF26: zCH3DPL (zeo_bv3d_ch.c:516)
==29581==    by 0x489DAB8: _rkCDBREPMergeCH.isra.0 (rk_cd.c:641)
==29581==    by 0x489DBF5: _rkCDPairColVolBREP (rk_cd.c:679)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x486500F: _rkFDUpdateRef (rkfd_sim.c:546)
==29581==    by 0x48650FE: rkFDUpdate (rkfd_sim.c:564)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==  Address 0x7d64b30 is 144 bytes inside a block of size 152 free'd
==29581==    at 0x484B27F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48F91E2: _zQHFacetListDestroy (zeo_bv3d_ch.c:112)
==29581==    by 0x48FAF66: _zQHInc (zeo_bv3d_ch.c:428)
==29581==    by 0x48FBB4C: _zQHCreate (zeo_bv3d_ch.c:463)
==29581==    by 0x48FBF26: zCH3DPL (zeo_bv3d_ch.c:516)
==29581==    by 0x489DAB8: _rkCDBREPMergeCH.isra.0 (rk_cd.c:641)
==29581==    by 0x489DBF5: _rkCDPairColVolBREP (rk_cd.c:679)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x486500F: _rkFDUpdateRef (rkfd_sim.c:546)
==29581==  Block was alloc'd at
==29581==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48F977D: _zQHHorizonNewFacet (zeo_bv3d_ch.c:339)
==29581==    by 0x48FA597: _zQHHorizon (zeo_bv3d_ch.c:392)
==29581==    by 0x48FA597: _zQHInc (zeo_bv3d_ch.c:421)
==29581==    by 0x48FBB4C: _zQHCreate (zeo_bv3d_ch.c:463)
==29581==    by 0x48FBF26: zCH3DPL (zeo_bv3d_ch.c:516)
==29581==    by 0x489DAB8: _rkCDBREPMergeCH.isra.0 (rk_cd.c:641)
==29581==    by 0x489DBF5: _rkCDPairColVolBREP (rk_cd.c:679)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x486500F: _rkFDUpdateRef (rkfd_sim.c:546)
==29581==
==29581== Invalid write of size 8
==29581==    at 0x48527FB: memset (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x494BD8E: memset (string_fortified.h:59)
==29581==    by 0x494BD8E: zMatZero (zm_mat.c:95)
==29581==    by 0x486C4EE: _rkFDSolverFrictionConstraint (rkfd_volume.c:125)
==29581==    by 0x486C4EE: _rkFDSolverVolume (rkfd_volume.c:946)
==29581==    by 0x486C4EE: rkFDSolverUpdate_Volume (rkfd_volume.c:1014)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==  Address 0x84d8390 is 0 bytes after a block of size 6,000 alloc'd
==29581==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x494B4C4: zMatAlloc (zm_mat.c:46)
==29581==    by 0x486CE2E: _rkFDSolverPrpReAllocQPCondition (rkfd_volume.c:70)
==29581==    by 0x486CE2E: _rkFDSolverVolume (rkfd_volume.c:945)
==29581==    by 0x486CE2E: rkFDSolverUpdate_Volume (rkfd_volume.c:1014)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==
==29581== Invalid write of size 8
==29581==    at 0x48527FF: memset (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x494BD8E: memset (string_fortified.h:59)
==29581==    by 0x494BD8E: zMatZero (zm_mat.c:95)
==29581==    by 0x486C4EE: _rkFDSolverFrictionConstraint (rkfd_volume.c:125)
==29581==    by 0x486C4EE: _rkFDSolverVolume (rkfd_volume.c:946)
==29581==    by 0x486C4EE: rkFDSolverUpdate_Volume (rkfd_volume.c:1014)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==  Address 0x84d8398 is 8 bytes after a block of size 6,000 alloc'd
==29581==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x494B4C4: zMatAlloc (zm_mat.c:46)
==29581==    by 0x486CE2E: _rkFDSolverPrpReAllocQPCondition (rkfd_volume.c:70)
==29581==    by 0x486CE2E: _rkFDSolverVolume (rkfd_volume.c:945)
==29581==    by 0x486CE2E: rkFDSolverUpdate_Volume (rkfd_volume.c:1014)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==
==29581== Invalid write of size 8
==29581==    at 0x48527F4: memset (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x494BD8E: memset (string_fortified.h:59)
==29581==    by 0x494BD8E: zMatZero (zm_mat.c:95)
==29581==    by 0x486C4EE: _rkFDSolverFrictionConstraint (rkfd_volume.c:125)
==29581==    by 0x486C4EE: _rkFDSolverVolume (rkfd_volume.c:946)
==29581==    by 0x486C4EE: rkFDSolverUpdate_Volume (rkfd_volume.c:1014)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==  Address 0x84d83a0 is 16 bytes after a block of size 6,000 alloc'd
==29581==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x494B4C4: zMatAlloc (zm_mat.c:46)
==29581==    by 0x486CE2E: _rkFDSolverPrpReAllocQPCondition (rkfd_volume.c:70)
==29581==    by 0x486CE2E: _rkFDSolverVolume (rkfd_volume.c:945)
==29581==    by 0x486CE2E: rkFDSolverUpdate_Volume (rkfd_volume.c:1014)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==
==29581== Invalid write of size 8
==29581==    at 0x48527F7: memset (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x494BD8E: memset (string_fortified.h:59)
==29581==    by 0x494BD8E: zMatZero (zm_mat.c:95)
==29581==    by 0x486C4EE: _rkFDSolverFrictionConstraint (rkfd_volume.c:125)
==29581==    by 0x486C4EE: _rkFDSolverVolume (rkfd_volume.c:946)
==29581==    by 0x486C4EE: rkFDSolverUpdate_Volume (rkfd_volume.c:1014)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==  Address 0x84d83a8 is 24 bytes after a block of size 6,000 in arena "client"
==29581==
==29581== Invalid write of size 8
==29581==    at 0x48CA762: zVec3DMul (zeo_vec3d.c:98)
==29581==    by 0x486C5DB: _rkFDSolverFrictionConstraint (rkfd_volume.c:129)
==29581==    by 0x486C5DB: _rkFDSolverVolume (rkfd_volume.c:946)
==29581==    by 0x486C5DB: rkFDSolverUpdate_Volume (rkfd_volume.c:1014)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==  Address 0x84d8480 is 64 bytes inside a block of size 88 free'd
==29581==    at 0x484B27F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48FE8EC: _zBREPTruncFace (zeo_brep_trunc.c:190)
==29581==    by 0x48FE8EC: zBREPTrunc (zeo_brep_trunc.c:221)
==29581==    by 0x48FEF60: zBREPTruncPH3D (zeo_brep_trunc.c:236)
==29581==    by 0x489DBB0: _rkCDPairColVolBREP (rk_cd.c:670)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==  Block was alloc'd at
==29581==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48FE32A: _zBREPTruncFaceA (zeo_brep_trunc.c:59)
==29581==    by 0x48FEA84: _zBREPTruncFace (zeo_brep_trunc.c:196)
==29581==    by 0x48FEA84: zBREPTrunc (zeo_brep_trunc.c:221)
==29581==    by 0x48FEF60: zBREPTruncPH3D (zeo_brep_trunc.c:236)
==29581==    by 0x489DBB0: _rkCDPairColVolBREP (rk_cd.c:670)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==
==29581== Invalid write of size 8
==29581==    at 0x48CA76A: zVec3DMul (zeo_vec3d.c:98)
==29581==    by 0x486C5DB: _rkFDSolverFrictionConstraint (rkfd_volume.c:129)
==29581==    by 0x486C5DB: _rkFDSolverVolume (rkfd_volume.c:946)
==29581==    by 0x486C5DB: rkFDSolverUpdate_Volume (rkfd_volume.c:1014)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==  Address 0x84d8490 is 80 bytes inside a block of size 88 free'd
==29581==    at 0x484B27F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48FE8EC: _zBREPTruncFace (zeo_brep_trunc.c:190)
==29581==    by 0x48FE8EC: zBREPTrunc (zeo_brep_trunc.c:221)
==29581==    by 0x48FEF60: zBREPTruncPH3D (zeo_brep_trunc.c:236)
==29581==    by 0x489DBB0: _rkCDPairColVolBREP (rk_cd.c:670)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==  Block was alloc'd at
==29581==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48FE32A: _zBREPTruncFaceA (zeo_brep_trunc.c:59)
==29581==    by 0x48FEA84: _zBREPTruncFace (zeo_brep_trunc.c:196)
==29581==    by 0x48FEA84: zBREPTrunc (zeo_brep_trunc.c:221)
==29581==    by 0x48FEF60: zBREPTruncPH3D (zeo_brep_trunc.c:236)
==29581==    by 0x489DBB0: _rkCDPairColVolBREP (rk_cd.c:670)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==
==29581== Invalid write of size 8
==29581==    at 0x48CA762: zVec3DMul (zeo_vec3d.c:98)
==29581==    by 0x486C62A: _rkFDSolverFrictionConstraint (rkfd_volume.c:130)
==29581==    by 0x486C62A: _rkFDSolverVolume (rkfd_volume.c:946)
==29581==    by 0x486C62A: rkFDSolverUpdate_Volume (rkfd_volume.c:1014)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==  Address 0x84d8498 is 0 bytes after a block of size 88 free'd
==29581==    at 0x484B27F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48FE8EC: _zBREPTruncFace (zeo_brep_trunc.c:190)
==29581==    by 0x48FE8EC: zBREPTrunc (zeo_brep_trunc.c:221)
==29581==    by 0x48FEF60: zBREPTruncPH3D (zeo_brep_trunc.c:236)
==29581==    by 0x489DBB0: _rkCDPairColVolBREP (rk_cd.c:670)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==  Block was alloc'd at
==29581==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48FE32A: _zBREPTruncFaceA (zeo_brep_trunc.c:59)
==29581==    by 0x48FEA84: _zBREPTruncFace (zeo_brep_trunc.c:196)
==29581==    by 0x48FEA84: zBREPTrunc (zeo_brep_trunc.c:221)
==29581==    by 0x48FEF60: zBREPTruncPH3D (zeo_brep_trunc.c:236)
==29581==    by 0x489DBB0: _rkCDPairColVolBREP (rk_cd.c:670)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==
==29581== Invalid write of size 8
==29581==    at 0x48CA76A: zVec3DMul (zeo_vec3d.c:98)
==29581==    by 0x486C62A: _rkFDSolverFrictionConstraint (rkfd_volume.c:130)
==29581==    by 0x486C62A: _rkFDSolverVolume (rkfd_volume.c:946)
==29581==    by 0x486C62A: rkFDSolverUpdate_Volume (rkfd_volume.c:1014)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==  Address 0x84d84a8 is 16 bytes after a block of size 88 free'd
==29581==    at 0x484B27F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48FE8EC: _zBREPTruncFace (zeo_brep_trunc.c:190)
==29581==    by 0x48FE8EC: zBREPTrunc (zeo_brep_trunc.c:221)
==29581==    by 0x48FEF60: zBREPTruncPH3D (zeo_brep_trunc.c:236)
==29581==    by 0x489DBB0: _rkCDPairColVolBREP (rk_cd.c:670)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==  Block was alloc'd at
==29581==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48FE32A: _zBREPTruncFaceA (zeo_brep_trunc.c:59)
==29581==    by 0x48FEA84: _zBREPTruncFace (zeo_brep_trunc.c:196)
==29581==    by 0x48FEA84: zBREPTrunc (zeo_brep_trunc.c:221)
==29581==    by 0x48FEF60: zBREPTruncPH3D (zeo_brep_trunc.c:236)
==29581==    by 0x489DBB0: _rkCDPairColVolBREP (rk_cd.c:670)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==
==29581== Invalid read of size 16
==29581==    at 0x48CAAD2: zVec3DCatDRC (zeo_vec3d.c:192)
==29581==    by 0x486C681: _rkFDSolverFrictionConstraint (rkfd_volume.c:131)
==29581==    by 0x486C681: _rkFDSolverVolume (rkfd_volume.c:946)
==29581==    by 0x486C681: rkFDSolverUpdate_Volume (rkfd_volume.c:1014)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==  Address 0x84d8498 is 0 bytes after a block of size 88 free'd
==29581==    at 0x484B27F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48FE8EC: _zBREPTruncFace (zeo_brep_trunc.c:190)
==29581==    by 0x48FE8EC: zBREPTrunc (zeo_brep_trunc.c:221)
==29581==    by 0x48FEF60: zBREPTruncPH3D (zeo_brep_trunc.c:236)
==29581==    by 0x489DBB0: _rkCDPairColVolBREP (rk_cd.c:670)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==  Block was alloc'd at
==29581==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48FE32A: _zBREPTruncFaceA (zeo_brep_trunc.c:59)
==29581==    by 0x48FEA84: _zBREPTruncFace (zeo_brep_trunc.c:196)
==29581==    by 0x48FEA84: zBREPTrunc (zeo_brep_trunc.c:221)
==29581==    by 0x48FEF60: zBREPTruncPH3D (zeo_brep_trunc.c:236)
==29581==    by 0x489DBB0: _rkCDPairColVolBREP (rk_cd.c:670)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==
==29581== Invalid write of size 8
==29581==    at 0x48CAAEA: zVec3DCatDRC (zeo_vec3d.c:192)
==29581==    by 0x486C681: _rkFDSolverFrictionConstraint (rkfd_volume.c:131)
==29581==    by 0x486C681: _rkFDSolverVolume (rkfd_volume.c:946)
==29581==    by 0x486C681: rkFDSolverUpdate_Volume (rkfd_volume.c:1014)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==  Address 0x84d8498 is 0 bytes after a block of size 88 free'd
==29581==    at 0x484B27F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48FE8EC: _zBREPTruncFace (zeo_brep_trunc.c:190)
==29581==    by 0x48FE8EC: zBREPTrunc (zeo_brep_trunc.c:221)
==29581==    by 0x48FEF60: zBREPTruncPH3D (zeo_brep_trunc.c:236)
==29581==    by 0x489DBB0: _rkCDPairColVolBREP (rk_cd.c:670)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==  Block was alloc'd at
==29581==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48FE32A: _zBREPTruncFaceA (zeo_brep_trunc.c:59)
==29581==    by 0x48FEA84: _zBREPTruncFace (zeo_brep_trunc.c:196)
==29581==    by 0x48FEA84: zBREPTrunc (zeo_brep_trunc.c:221)
==29581==    by 0x48FEF60: zBREPTruncPH3D (zeo_brep_trunc.c:236)
==29581==    by 0x489DBB0: _rkCDPairColVolBREP (rk_cd.c:670)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==
==29581== Invalid read of size 8
==29581==    at 0x48CAAF2: zVec3DCatDRC (zeo_vec3d.c:192)
==29581==    by 0x486C681: _rkFDSolverFrictionConstraint (rkfd_volume.c:131)
==29581==    by 0x486C681: _rkFDSolverVolume (rkfd_volume.c:946)
==29581==    by 0x486C681: rkFDSolverUpdate_Volume (rkfd_volume.c:1014)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==  Address 0x84d84a8 is 16 bytes after a block of size 88 free'd
==29581==    at 0x484B27F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48FE8EC: _zBREPTruncFace (zeo_brep_trunc.c:190)
==29581==    by 0x48FE8EC: zBREPTrunc (zeo_brep_trunc.c:221)
==29581==    by 0x48FEF60: zBREPTruncPH3D (zeo_brep_trunc.c:236)
==29581==    by 0x489DBB0: _rkCDPairColVolBREP (rk_cd.c:670)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==  Block was alloc'd at
==29581==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48FE32A: _zBREPTruncFaceA (zeo_brep_trunc.c:59)
==29581==    by 0x48FEA84: _zBREPTruncFace (zeo_brep_trunc.c:196)
==29581==    by 0x48FEA84: zBREPTrunc (zeo_brep_trunc.c:221)
==29581==    by 0x48FEF60: zBREPTruncPH3D (zeo_brep_trunc.c:236)
==29581==    by 0x489DBB0: _rkCDPairColVolBREP (rk_cd.c:670)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==
==29581== Invalid write of size 8
==29581==    at 0x48CAAF7: zVec3DCatDRC (zeo_vec3d.c:192)
==29581==    by 0x486C681: _rkFDSolverFrictionConstraint (rkfd_volume.c:131)
==29581==    by 0x486C681: _rkFDSolverVolume (rkfd_volume.c:946)
==29581==    by 0x486C681: rkFDSolverUpdate_Volume (rkfd_volume.c:1014)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==  Address 0x84d84a8 is 16 bytes after a block of size 88 free'd
==29581==    at 0x484B27F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48FE8EC: _zBREPTruncFace (zeo_brep_trunc.c:190)
==29581==    by 0x48FE8EC: zBREPTrunc (zeo_brep_trunc.c:221)
==29581==    by 0x48FEF60: zBREPTruncPH3D (zeo_brep_trunc.c:236)
==29581==    by 0x489DBB0: _rkCDPairColVolBREP (rk_cd.c:670)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==  Block was alloc'd at
==29581==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48FE32A: _zBREPTruncFaceA (zeo_brep_trunc.c:59)
==29581==    by 0x48FEA84: _zBREPTruncFace (zeo_brep_trunc.c:196)
==29581==    by 0x48FEA84: zBREPTrunc (zeo_brep_trunc.c:221)
==29581==    by 0x48FEF60: zBREPTruncPH3D (zeo_brep_trunc.c:236)
==29581==    by 0x489DBB0: _rkCDPairColVolBREP (rk_cd.c:670)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==
==29581== Invalid write of size 8
==29581==    at 0x486C54B: memcpy (string_fortified.h:29)
==29581==    by 0x486C54B: _rkFDSolverFrictionConstraint (rkfd_volume.c:127)
==29581==    by 0x486C54B: _rkFDSolverVolume (rkfd_volume.c:946)
==29581==    by 0x486C54B: rkFDSolverUpdate_Volume (rkfd_volume.c:1014)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==  Address 0x84d85d0 is 16 bytes inside a block of size 56 free'd
==29581==    at 0x484B27F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48FE069: zBREPDestroy (zeo_brep.c:157)
==29581==    by 0x489DDD5: _rkCDPairColVolBREP (rk_cd.c:695)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==  Block was alloc'd at
==29581==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48FE5F2: _zBREPTruncIntersect (zeo_brep_trunc.c:34)
==29581==    by 0x48FE5F2: zBREPTrunc (zeo_brep_trunc.c:219)
==29581==    by 0x48FEF60: zBREPTruncPH3D (zeo_brep_trunc.c:236)
==29581==    by 0x489DBB0: _rkCDPairColVolBREP (rk_cd.c:670)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==
==29581== Invalid write of size 8
==29581==    at 0x486C555: memcpy (string_fortified.h:29)
==29581==    by 0x486C555: _rkFDSolverFrictionConstraint (rkfd_volume.c:127)
==29581==    by 0x486C555: _rkFDSolverVolume (rkfd_volume.c:946)
==29581==    by 0x486C555: rkFDSolverUpdate_Volume (rkfd_volume.c:1014)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==  Address 0x84d85e0 is 32 bytes inside a block of size 56 free'd
==29581==    at 0x484B27F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48FE069: zBREPDestroy (zeo_brep.c:157)
==29581==    by 0x489DDD5: _rkCDPairColVolBREP (rk_cd.c:695)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==  Block was alloc'd at
==29581==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x48FE5F2: _zBREPTruncIntersect (zeo_brep_trunc.c:34)
==29581==    by 0x48FE5F2: zBREPTrunc (zeo_brep_trunc.c:219)
==29581==    by 0x48FEF60: zBREPTruncPH3D (zeo_brep_trunc.c:236)
==29581==    by 0x489DBB0: _rkCDPairColVolBREP (rk_cd.c:670)
==29581==    by 0x489F8EF: _rkCDColVolBREPVert (rk_cd.c:773)
==29581==    by 0x489F8EF: rkCDColVolBREPVert (rk_cd.c:786)
==29581==    by 0x4869795: rkFDSolverColChk_Volume (rkfd_volume.c:1004)
==29581==    by 0x4864B46: _rkFDUpdateCD (rkfd_sim.c:468)
==29581==    by 0x4864F23: _rkFDUpdateAll (rkfd_sim.c:528)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==
==29581== Invalid read of size 8
==29581==    at 0x4942154: zRawVecInnerProd (zm_raw_vec.c:240)
==29581==    by 0x4865598: _rkFDQPSolveASMInitIndex (rkfd_opt_qp.c:33)
==29581==    by 0x4865598: rkFDQPSolveASM (rkfd_opt_qp.c:75)
==29581==    by 0x486C704: _rkFDSolverQP (rkfd_volume.c:544)
==29581==    by 0x486C704: _rkFDSolverVolume (rkfd_volume.c:947)
==29581==    by 0x486C704: rkFDSolverUpdate_Volume (rkfd_volume.c:1014)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==  Address 0x84d8390 is 0 bytes after a block of size 6,000 alloc'd
==29581==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x494B4C4: zMatAlloc (zm_mat.c:46)
==29581==    by 0x486CE2E: _rkFDSolverPrpReAllocQPCondition (rkfd_volume.c:70)
==29581==    by 0x486CE2E: _rkFDSolverVolume (rkfd_volume.c:945)
==29581==    by 0x486CE2E: rkFDSolverUpdate_Volume (rkfd_volume.c:1014)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==
==29581== Invalid read of size 8
==29581==    at 0x4942162: zRawVecInnerProd (zm_raw_vec.c:240)
==29581==    by 0x4865598: _rkFDQPSolveASMInitIndex (rkfd_opt_qp.c:33)
==29581==    by 0x4865598: rkFDQPSolveASM (rkfd_opt_qp.c:75)
==29581==    by 0x486C704: _rkFDSolverQP (rkfd_volume.c:544)
==29581==    by 0x486C704: _rkFDSolverVolume (rkfd_volume.c:947)
==29581==    by 0x486C704: rkFDSolverUpdate_Volume (rkfd_volume.c:1014)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==  Address 0x84d8398 is 8 bytes after a block of size 6,000 alloc'd
==29581==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x494B4C4: zMatAlloc (zm_mat.c:46)
==29581==    by 0x486CE2E: _rkFDSolverPrpReAllocQPCondition (rkfd_volume.c:70)
==29581==    by 0x486CE2E: _rkFDSolverVolume (rkfd_volume.c:945)
==29581==    by 0x486CE2E: rkFDSolverUpdate_Volume (rkfd_volume.c:1014)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==
==29581== Invalid read of size 8
==29581==    at 0x4942170: zRawVecInnerProd (zm_raw_vec.c:240)
==29581==    by 0x4865598: _rkFDQPSolveASMInitIndex (rkfd_opt_qp.c:33)
==29581==    by 0x4865598: rkFDQPSolveASM (rkfd_opt_qp.c:75)
==29581==    by 0x486C704: _rkFDSolverQP (rkfd_volume.c:544)
==29581==    by 0x486C704: _rkFDSolverVolume (rkfd_volume.c:947)
==29581==    by 0x486C704: rkFDSolverUpdate_Volume (rkfd_volume.c:1014)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==  Address 0x84d83a0 is 16 bytes after a block of size 6,000 alloc'd
==29581==    at 0x484DA83: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29581==    by 0x494B4C4: zMatAlloc (zm_mat.c:46)
==29581==    by 0x486CE2E: _rkFDSolverPrpReAllocQPCondition (rkfd_volume.c:70)
==29581==    by 0x486CE2E: _rkFDSolverVolume (rkfd_volume.c:945)
==29581==    by 0x486CE2E: rkFDSolverUpdate_Volume (rkfd_volume.c:1014)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
==29581==

valgrind: m_mallocfree.c:303 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed.
valgrind: Heap block lo/hi size mismatch: lo = 6064, hi = 0.
This is probably caused by your program erroneously writing past the
end of a heap block and corrupting heap metadata.  If you fix any
invalid writes reported by Memcheck, this assertion failure will
probably go away.  Please try that before reporting this as a bug.

host stacktrace:
==29581==    at 0x5804284A: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==29581==    by 0x58042977: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==29581==    by 0x58042B1B: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==29581==    by 0x5804C8CF: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==29581==    by 0x5803AE9A: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==29581==    by 0x580395B7: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==29581==    by 0x5803DF3D: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==29581==    by 0x58038868: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==29581==    by 0x5800F344: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==29581==    by 0x10031A927A: ???
==29581==    by 0x1002DA9F2F: ???
==29581==    by 0x581FCD83: ??? (in /usr/libexec/valgrind/memcheck-amd64-linux)
==29581==    by 0x1002DA9F17: ???
==29581==    by 0x1002DA9F2F: ???

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 29581)
==29581==    at 0x49421BE: zRawVecInnerProd (zm_raw_vec.c:240)
==29581==    by 0x4865598: _rkFDQPSolveASMInitIndex (rkfd_opt_qp.c:33)
==29581==    by 0x4865598: rkFDQPSolveASM (rkfd_opt_qp.c:75)
==29581==    by 0x486C704: _rkFDSolverQP (rkfd_volume.c:544)
==29581==    by 0x486C704: _rkFDSolverVolume (rkfd_volume.c:947)
==29581==    by 0x486C704: rkFDSolverUpdate_Volume (rkfd_volume.c:1014)
==29581==    by 0x4864FA2: _rkFDUpdate (rkfd_sim.c:537)
==29581==    by 0x4992E51: _zODE2RegularFunc (zm_ode2.c:55)
==29581==    by 0x4990EE7: zODEUpdate_RKG (zm_ode_rkg.c:72)
==29581==    by 0x4993218: zODE2UpdateRegular (zm_ode2.c:101)
==29581==    by 0x48650E3: rkFDUpdate (rkfd_sim.c:562)
==29581==    by 0x1094E2: main (arm_wall_test.c:69)
client stack range: [0x1FFEFFB000 0x1FFF000FFF] client SP: 0x1FFEFFF710
valgrind stack range: [0x1002CAA000 0x1002DA9FFF] top usage: 18984 of 1048576

Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.

報告ありがとうございます！
こちら #41 にて修正のPR出させていただきました．
QPSolver内で使っているワークスペース(行列，ベクトル，インデックス)のメモリ割り当て周りでバグがありました．
手元ではexample/chain/arm_wall_test.cはエラーなく終了しております．

対応ありがとう。こちらクローズします。

authors: n-wakisaka zhidao

repo: mi-lib/roki-fd


text:
Add a pipeline step for training HPO models from a list of MLJ compatible models.

We should also compile a list of sane defaults for hyperparameters if defaults aren't always the best.

This step is relevant for choosing which models to include in super-learner


text:
Add example of compact Tabs to Code page

Summary of the changes
Added an example of the compact variant of 'IcTab'
Related issue
#176
Checklist

[ ] I have manually accessibility tested any changes, if relevant.
[ ] I have raised this pull request against the develop branch

I think this needs rebasing off develop as it's got changes made to a different file that have already been merged

can't seem to make the compact example receive tab focus: eg from here, tab focus jumps to web components

It's fine for other examples?!!

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


text:
Consider enabling type='date' on IcTextField

Summary
As title. With type='date' on IcTextField in my experiments so far, a perfectly usable date picker is rendered, which is plenty for my app's requirements. It defers to the browser implementation of course, so specific functionality isn't controllable but for simple date picking it is a great low-code solution. I'd like to request that you consider adding support for that type value, since at the moment i'm having to use
// eslint-disable-next-line @typescript-eslint/ban-ts-comment
// @ts-ignore
to get it to work.
Thanks all!

Thanks very much for your contribution. We have purposefully excluded type='Date' on textFields for now as this functionality will be available in the upcoming Date input component that is currently being developed.


text:
rtv console (NO X, Linux), mpv does not accept key input running in rtv.

Hello
When in my tty and I run rtv --enable-media and select a video, gifv or whatever, it plays the selected link using mpv (or mplayer if configured) in a window.
The player will then not register key input like "q" or any other key (to quit the video) under rtv.
Using the player without rtv, it accepts keystrokes.
This makes it hard to quit a video if I change my mind and do not want to see the video after all, or if the video is very long, I have to wait for it to end.
This is not a problem (example) using w3mimgdisplay to show images, as it does accept key input (q) to quit w3mimgdisplay.

Thanks for submitting a bug report. I think that this is a limitation in the example mailcap command because it pipes the video from youtube-dl to mpv. E.g. If I type this straight into my terminal then I can't quit either:
youtube-dl -q -o - 'https://www.youtube.com/watch?v=jwC544Z37qo' | mplayer -cache 8192 -vo caca -quiet -
Do you have a better example of a command that we can use? Do mpv/mplayer support downloading directly from URLs?

Well, perhaps an easier as mpv supports directly playing of links without piping in terminal.
I changed
# Ascii videos
video/x-youtube; youtube-dl -q -o - '%s' | mplayer -cache 8192 -vo caca -quiet -; needsterminal
video/*; wget '%s' -O - | mplayer -cache 8192 -vo caca -quiet -; needsterminal

to
# Full motion videos
video/x-youtube; mpv -vo drm -quiet '%s'; needsterminal
video/*; mpv -vo drm -quiet '%s'; needsterminal

When running rtv --enable-media and selecting gifv and/or video links, it will play it using the framebuffer under rtv.
Input/shortcuts works as expected.
Please try. I don't know if the videooutput drm will work for everybody.

I tried your mpv commands out and they worked for me on Ubuntu if I enabled the framebuffer. I was surprised that mpv was able to parse youtube urls 👍 . I couldn't get it to work on macOS because I couldn't figure out how to install mpv with the drm driver. Even if I did install it, I'm not sure if the framebuffer stuff works on macOS.
I propose that we put your mpv commads first in the example mailcap configuration, with a comment mentioning that they require a framebuffer to run. We can keep the mplayer libcaca commands at the bottom so that they're available for people to play around with.

Sounds like a good idea :)

authors: michael-lazar mikedebian

repo: michael-lazar/rtv

license: mit


text:
Buttons become invisible when vertical space is limited

When showing a dialog with a large content on a small screen, the button bar becomes invisible as the content is stretched to the whole available vertical space.

Fixed in version 1.0.1.

repo: michael-rapp/AndroidMaterialDialog


text:
Duplicate entries  in the 0.5 cut catalog

It appears that are duplicate entries at least in the 0.5 cut  csv files in some cases..
For example I have:
488.92527796427413,283.42631325721743,2277.2586112976073,6649.35964659055,209.19709872152092,44.129834465313714,128.01835043922821,391.3928304362869,271.22236959730355,427.41745758605964,206.75622395261806,APF0000q7s,1
listed twice in  ESP_021494_0945_fans.csv under applied_cut_0.5
178.03871848366478,291.06212165138936,918.0387184836648,11251.062121651392,51.881296109111894,13.286515110774953,13.777289639625213,186.2403877064726,304.335176078663,169.83704926085696,277.78906722411574,167.19966246744863,299.56674242432524,188.87777449988093,282.5575008784535,APF0000kou,1
is listed twice in APF0000kou ESP_021526_0985_blotches.csv
It doesn't look like every entry is duplicated so I'm not sure what exactly happened here.

Wow, started to look at this yesterday, thanks for the find, something is seriously wrong with how I apply the cut. Fortunately, the fnotching itself is okay, as evident by the fact that the files outside the applied cut don't seem to show any duplicates (I ran a check on all of them).
But here's the stats on the cut-applied files:

Meaning, while most have no dupes, there's more than 10 files that have between 1000 and 2000 dupes!
Looking into this now.

I think this explains why I see the catalog has a significant number more fans and blotches than were marked by the science team for the gold standard data and might explain the variation Anya saw for two images taken at very close temporal separations.

So, this lead down to a rabbit hole, but I'm seeing the end of it:

First, I found a not insignificant bug with on-disk filtering of data columns that were stored as pandas.Categories (reported at pydata/pandas#13322).  I am using those instead of just strings for image_id and image_name because the predetermined length of the strings saves currently around 2 GB of disk space for the reduced classification data-base. Not a biggie, apart from when I want to copy around the database file often. For now, worked around by using again strings for image_id and _name.
Then, importantly, I found a lingering bug in my fnotching code, that was introduced when we realized that it is helpful to keep both the planet4 tile coordinates of markings and the hirise image coordinates alive through-out the clustering process so that one can refer one to the other later for plotting. I previously did brutally kick out what I did not needed, and renamed image_x and image_y to x and y if clustering on hirise scope. This meant, when I removed the renaming and kept both image_x/y and x/y, the fnotching would use the planet4 x/y coords, even so the pipeline was working on the hirise scope. This lead to the sometimes thousands of duplicates, because the fnotching code, when presented with all data for a whole Hirise image, found of course many overlying clusters, while only looking at p4 tile coordinates, as there are many p4 tiles in an Hirise image. Fixed that by now always requiring a scope argument that tells at all times in what scope i'm working in (planet4 or hirise) and uses then the appropriate data columns, without losing any.
Finally, it became clear, that after repairing the previous bullet, there are still some duplicates remaining. I am reproducing a catalog now to assess the status after the bigger bugfix.

So, the remaining dupes after fixing above mentioned bug is this: Out of 439 blotch and fan files for season 2 and 3, 172 show duplicates, with the ones having more than 20 looking like this:

Anya will run this new catalog today through her scripts to see if so far it had any influence on the variability of the early in the season data points.

Within that highest obsid, the distribution of the top duplicate containers is like this:

authors: michaelaye mschwamb

license: isc


text:
Tweens?

It would be nice to have some. Investigate possibilities here.

Fixed with #48

repo: michalbe/cervus


text:
Modifying Distance

Right now all movement (translate, flip, etc) are static.
Is there a way of specifying them different for some elements?
p.e. data-aos-distance.

Hi @thewinger. There is no such an option, but if you need custom animation, you can easily add your own and use it with data-aos="your-animation-name".
Check out this codepen http://codepen.io/michalsnik/pen/WxvNvE

authors: michalsnik thewinger

repo: michalsnik/aos


text:
bump Go vertion to 1.22

Closes #314

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 84.41%. Comparing base (eaa8692) to head (fd43f48).
Report is 2 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff             @@
##             main     #315       +/-   ##
===========================================
- Coverage   96.71%   84.41%   -12.31%
===========================================
  Files          60       97       +37
  Lines        2621     2630        +9
===========================================
- Hits         2535     2220      -315
- Misses         58      381      +323
- Partials       28       29        +1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

authors: codecov-commenter michimani

repo: michimani/gotwi


text:
RegisterSubscriber

What subscriber headers? Please stop talking in screenshots.

like this , set headers

broker.Subscribe("/topic/hello", func(p broker.Publication) error {

 return nil
}, stomp.SubscribeHeaders(map[string]string{

"activemq.subscriptionName": "name",

}), broker.DisableAutoAck())

Broker options are not supported using the RegisterSubscriber function. Broker is a low level component which we abstract away in the server. If you need to use more detailed subscribe options then you should use the broker directly. It's unlikely we promote the ability to do these things at the high level.

authors: asim metooweb

repo: micro/go-micro


text:
Composition barplot

A typical way to visualize microbiome composition is the "Composition barplot" as shown e.g. in microbiome tutorial (see section with that name).
Consider implementing this as a function, or as an option in an existing function that visualizes the composition (if not readily available).
Add example in miaViz vignette and/or OMA.

This should be possible with
library(mia)
library(miaViz)
data(GlobalPatterns)
tse <- GlobalPatterns
plotAbundance(tse, abund_values="counts", rank = "Phylum", order_sample_by = "Bacteroidetes")

However, when selecting order_sample_by = "Bacteroidetes" the figure does not seem to be sorted by Bacteroidetes abundance.
Check why, and fix if necessary or add an option to sort based on the abundance of a given taxonomic group at the chosen level (as in the visualization example in microbiome tutorial linked above).
PR the changes to miaViz (if needed) and then add an example to OMA, section on community composition.
I suggest that @ChouaibB works on this, supervised by @tvborm . Then me and @FelixErnst will support where necessary.

How about:
"plotAbundance(tse, abund_values="counts", rank = "Phylum", order_rank_by="revabund", order_sample_by = "Bacteroidetes")"
It gives the following:

Ah, right. Of course, this does not work that well with the count assay.
I suggest the following:

The figure was confusing with the count assay because I overlooked the fact that the data is visualized as relative abundances anyway. A warning might be in place if one tries to run this with something else than "relabundance" assay but the visualization is done with relabundance anyway? Then it looks like sample sorting is not correct, although it is.

Before the visualization, add a line that aggregates the rare taxa to "Other" category; an example is already shown in OMA section on Visualizing the most dominant genus on PCoA

Can we add this example with relabundance to OMA, sorting by Bacteroidetes and showing the top-5 taxa + "Other"

Just one more comment about sorting by samples. I might be a bit confused still, because I tried the following and it seems it does sort the samples:
library(mia)
library(miaViz)
data(GlobalPatterns)
tse <- GlobalPatterns
plotAbundance(tse, rank="Phylum", add_legend=FALSE, add_x_text=TRUE) +
  theme(axis.text.x.bottom = element_text(angle = 90, hjust = 0))
plotAbundance(tse, rank="Phylum",order_sample_by = "Bacteroidetes", add_legend=FALSE,add_x_text=TRUE) +
  theme(axis.text.x.bottom = element_text(angle = 90, hjust = 0))

Output: (first without order_by_sample and second is)

Yes it does the sorting but if you sort by Bacteroidetes then you could expect to see that in the plot. The explanation is clear in this case but a warning might help uncautious users like me.
I suggest to use minimal examples and exclude themselves and other elements in the code that are unrelated to the issue.

The assay should be explicitly defined to avoid confusion?

Guess for readability the line:
tse <- relAbundanceCounts(tse)

Could be added.
In documentation the default values set for the args is clear about using relabundance, and gets calculated if not present.
I tested it when  "abund_values" not passed (like the earlier comment) by default it counts relative abundance if it is not present among the assays.

Yes, it counts relabundances for the visualization.
But sorting is not done on that assay by default, i.e.
plotAbundance(tse, rank="Phylum",order_sample_by = "Bacteroidetes")
Does sorting for Bacteroidetes but does not specify which assay.
plotAbundance(tse, rank="Phylum",order_sample_by = "Bacteroidetes", abund_values="counts")
would be explicit about the assay that is being used in the sorting.
However, when I do
tse <- relAbundanceCounts(tse)
plotAbundance(tse, rank="Phylum",order_sample_by = "Bacteroidetes", abund_values = "relabundance")

The values do not seem to be sorted by Bacteroidetes relative abundance.
Adding  the order_rank_by option does the trick with revabund
plotAbundance(tse, rank="Phylum",order_sample_by = "Bacteroidetes", abund_values = "relabundance", order_rank_by="revabund")
But the documentation is not very clear on how the abund and revabund are expected to differ, or what order_rank_by="name" really means/does.
plotAbundance(tse, rank="Phylum",order_sample_by = "Bacteroidetes", abund_values = "relabundance", order_rank_by="abund")
Action point: clarify function documentation and examples, and afterwards also add example in OMA.

Ok I see your point clearly now.
I try figure out what "name" or "abund" do, then move to OMA.

Also improvisaatio function documentation, I couldnt figure out from that. Ask support from the authors of this function if necessary

Ok "name" sorts names/labels present in rank, if no rank is mentioned the first in taxonomyRanks (e.g. Kingdom) names are sorted. I double check with authors about all.

authors: ChouaibB antagomir

repo: microbiome/miaViz


text:
Initial feature-flagged search

First PR for #440.
There's lots still to do tracked on the issue.

Link with flag disabled: https://review-python-editor-next.microbit.org/lunr/?flag=none
All looks good there.

repo: microbit-foundation/python-editor-next


text:
Turn off superbright green led

When I'm running this on a battery, there's an eye-melting green led saturating my visual cortex. :)
How does one turn off this led?  Apologies if this is super basic.

Thanks for your feedback! The led is automatically run to indicate the battery status in the Run() function. We will limit it brightness in the next release

authors: divbell microbotsio

repo: microbotsio/CodeCell


text:
Enum Field Usage for linking Main / SubPage

Description:
If the Records of a SubPage and Main Page are linked via a Enum Field, the System does not correctly populate the values in the SubPage and the Client also does not show the Enum Values, if a Tablerelation was defined.

ALProject10.zip
I have attached a Sample Project.
Versions:

AL Langauge: 3.0.102444
Business Central:14.0.28823

Have you tried the setting PopulateAllFields?

Even, if it should not be necessary to set PopulateAllFields - I have tried it with PopulateAllFields = true, but the Behaviour is the same - the Field MyField1 in the SubPage has no Value and in the DropDown-Box no Enum Values are shown.

This is a serious bug that makes enums not able to replace optionstrings. I am experiencing this same behavior in the spring release. This I believe is also related to a bug with enums and GetFilter and Evaluate.
This also does not work if you do page variables and record setranges like below. There is no filter set on the opened page.
tableA.SetRange("Enum Field 1", "EnumValue1");
listPageA.SetTableView(TableA);
listPageA.Run();

Please, move this bug higher on the queue, because it is already known many months and not solved. We cannot use ENUM till this is solved, because any page using enums is not behaving as option regarding auto-filling the values based on the filters and this is BIG BLOCKING BUG to adopt enums!
If you want example of the difference, I can send you simple app I made to test that.

Fixed in the 2019 Wave 2 release and the upcoming CU of the Wave 1 release

authors: BartPermentier esbenk kevindstanley1988 kine wweidl

repo: microsoft/AL


text:
Running Save Participants with AL Format is slow since the VSCode January '20 update

Describe the bug
We're actively using FormatOnSave for our al files. Until a week ago, everything worked fine and we did not notice a major delay when saving our files.
"[al]": {"editor.formatOnSave": true }
However, since the VSCode January '20 update, the release notes states that background tasks of  extensions during save (such as the Format Document) now show in a notification window ("Running Save Participants ...")
We've seen cases where autoFormat now takes several minutes instead, forcing us to close the notification window. Maybe related, but since the last VS Code update, we also faced numerous times that files cannot be saved / closed, forcing us to kill VS Code.
Screenshots

Versions:

I have the same exact issue since this update. Happening on vscode insiders and regular.

I'm getting the same thing. Everything worked fine before the update, I am formatting using the Prettier extension.

Seeing the same issue

Disabling formatonsave and doing a manual format document seems to improve speed a lot ...

Still seeing this in, format on save used to be fast and worked always
Version: 1.42.1
Commit: c47d83b293181d9be64f27ff093689e8e7aed054
Date: 2020-02-11T14:44:27.652Z
Electron: 6.1.6
Chrome: 76.0.3809.146
Node.js: 12.4.0
V8: 7.6.303.31-electron.0
OS: Darwin x64 18.0.0

I've also encountered this problem, “Quick Fixes” runs a long time.

This issue is very annoying. I'm using PHP, PHP Code Beautifier, and PHP Codesniffer.  I had to disable all three.

Seems to be the same issue for golang formatting as well.

vsocde is trying to execute ESLint in my .sh files in an endless loop.
it is not definied in any config file that he should format it with eslint^^
// settings.json
{
  "[html]": {
    "editor.defaultFormatter": "vscode.html-language-features"
  },
  "[javascript]": {
    "editor.defaultFormatter": "dbaeumer.vscode-eslint"
  },
  "[json]": {
    "editor.defaultFormatter": "dbaeumer.vscode-eslint"
  },
  "atomKeymap.promptV3Features": true,
  "colorize.languages": ["css", "sass", "scss", "less", "postcss", "sss", "stylus", "xml", "svg", "javascript", "javascriptreact", "typescript", "typescriptreact"],
  "editor.codeActionsOnSave": {
    "source.fixAll": true
  },
  "editor.largeFileOptimizations": false,
  "editor.minimap.enabled": true,
  "editor.renderIndentGuides": false,
  "editor.renderWhitespace": "none",
  "editor.rulers": [100],
  "editor.showFoldingControls": "always",
  "editor.tabSize": 2,
  "emmet.includeLanguages": {
    "javascript": "javascriptreact"
  },
  "emmet.syntaxProfiles": {
    "javascript": ["js", "jsx"]
  },
  "eslint._legacyModuleResolve": true,
  "eslint.alwaysShowStatus": true,
  "eslint.packageManager": "yarn",
  "explorer.confirmDelete": false,
  "explorer.confirmDragAndDrop": false,
  "files.associations": {
    "*.graphqls": "graphql"
  },
  "files.autoSave": "off",
  "files.eol": "\n",
  "files.participants.timeout": 0,
  "git.autofetch": true,
  "git.enableSmartCommit": true,
  "git.inputValidationSubjectLength": 72,
  "javascript.updateImportsOnFileMove.enabled": "always",
  "javascript.validate.enable": false,
  "material-icon-theme.showUpdateMessage": false,
  "npm.enableScriptExplorer": true,
  "npm.scriptExplorerAction": "run",
  "peacock.affectActivityBar": false,
  "peacock.affectTitleBar": false,
  "peacock.favoriteColors": [{
    "name": "Angular Red",
    "value": "#b52e31"
  }, {
    "name": "Auth0 Orange",
    "value": "#eb5424"
  }, {
    "name": "Azure Blue",
    "value": "#007fff"
  }, {
    "name": "C# Purple",
    "value": "#68217A"
  }, {
    "name": "Gatsby Purple",
    "value": "#639"
  }, {
    "name": "Go Cyan",
    "value": "#5dc9e2"
  }, {
    "name": "Java Blue-Gray",
    "value": "#557c9b"
  }, {
    "name": "JavaScript Yellow",
    "value": "#f9e64f"
  }, {
    "name": "Mandalorian Blue",
    "value": "#1857a4"
  }, {
    "name": "Node Green",
    "value": "#215732"
  }, {
    "name": "React Blue",
    "value": "#00b3e6"
  }, {
    "name": "Something Different",
    "value": "#832561"
  }, {
    "name": "Vue Green",
    "value": "#42b883"
  }],
  "scm.defaultViewMode": "tree",
  "sync.autoDownload": false,
  "sync.autoUpload": false,
  "sync.forceDownload": false,
  "sync.gist": "140cb49bd5ae6404af78e9636059cd89",
  "sync.quietSync": false,
  "sync.removeExtensions": true,
  "sync.syncExtensions": true,
  "terminal.integrated.rendererType": "auto",
  "terminal.integrated.scrollback": 10000,
  "typescript.tsserver.log": "verbose",
  "window.zoomLevel": 0,
  "workbench.activityBar.visible": true,
  "workbench.colorTheme": "One Monokai",
  "workbench.editor.showTabs": true,
  "workbench.iconTheme": "material-icon-theme",
  "workbench.sideBar.location": "left",
  "workbench.startupEditor": "welcomePage",
  "workbench.tree.renderIndentGuides": "none"
}

@ChiefORZ it looks like vscode-eslint is your formatter for javascript and JSON.

@photocurio ya, of course. but isnt it strange that he tried to convert a .sh with a formatter associated with javascript and JSON 😜

experiencing this also lately. it works ok for a while after restart but then becomes slow.

@fvet Would you be able to provide some more information? Are you still experiencing this issue with the newest version of the AL extension and with a newer version of VS Code different from 1.42?
If you are still experiencing, would you please provide a minimal working example which reproduces the issue?
I suspect this issue might be more related to VS Code itself as per these two:
https://github.com/microsoft/vscode/issues/88149
https://github.com/microsoft/vscode/issues/92652

Past weeks, I've worked on the AL insider vsix (6.x version), now I'm working on AL Version 5.0.320540 and still experiencing the delay a lot, all linked to the 'FormatOnSave', disabling this solves the issue. I can't provide a repro here, since the project I'm working in contains 4500+ files. You can always remotely debug if really needed.
VS Code
Version: 1.48.2 (user setup)
Commit: a0479759d6e9ea56afa657e454193f72aef85bd0
Date: 2020-08-25T10:13:11.295Z
Electron: 7.3.2
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 10.0.14393

Thanks @fvet ! We were concerned that the FormatOnSave is completely blocking the save experience. From our testing, it appears to be related to the performance of the format command when working with large projects. We will continue working on performance improvements in the next months and follow up.

I had a similar problem with saving AL files: it took several minutes to do that. After setting the property "al.enableCodeAnalysis" to "false" in settings.json file the problem was solved. I don't know if it is exactly the same problem/reason, but VS Code was also showing, that the Formatter is running.

@yurim108, disabling CodeAnalysis is only a workaround. VS Code should be able to support both CodeAnalysis and AutoFormat next to each other in a single workspace. I'm often updating lots of objects (regex replace, ...) or when working with 'larger' objects / objects used in a wide area of the application, FormatOnSave just slows down the entire process, but don't want to give up CodeAnalysis, since we expect to be alerted on warnings / errors in the same operation.

Same thing here with HTML Language Features Formatter:

I've had this issue seemingly for the life of BC AL development and it appears to be getting worse.  Over the past two days, simple file changes will completely lock up VS Code not infrequently

Same issue here. The format on save is slow, but so is the auto complete (ctrl+space), find references, go to source, etc. It all slows a lot in bigger projects. I don't know if the code analysis is what slows this down, or if it's just vs code struggling with larger files now.

Same. The issue is consuming so mush time that we had to turn it off.

Same. The issue is consuming so mush time that we had to turn it off.

Same issue, formatOnSave is currently way too time consuming.
VSCODE: 1.52.1
AL: v6.1.397164

Same issue, formatOnSave is currently way too time consuming.
VSCODE: 1.52.1
AL: v6.1.397164

As a workaround, I'm currently trying the following VS Code setting:

So far, with success.

As a workaround, I'm currently trying the following VS Code setting:

So far, with success.

After setting the property "al.enableCodeAnalysis" to "false" in settings.json file the problem was solved.

This was the work around for me.

After setting the property "al.enableCodeAnalysis" to "false" in settings.json file the problem was solved.

This was the work around for me.

As a workaround, I'm currently trying the following VS Code setting:

So far, with success.

How large is your project / files? Even with this setting, it will still take 2-5 minutes, seemingly arbitrarily.

As a workaround, I'm currently trying the following VS Code setting:

So far, with success.

How large is your project / files? Even with this setting, it will still take 2-5 minutes, seemingly arbitrarily.

@mjmatthiesen Two apps with round about 200 AL files.
In case the setting changed nothing on your side: Have you checked whether it applies to the right scope (User, Workspace, Folder), thus it is not overruled by another scope setting?

@mjmatthiesen Two apps with round about 200 AL files.
In case the setting changed nothing on your side: Have you checked whether it applies to the right scope (User, Workspace, Folder), thus it is not overruled by another scope setting?

It's scoped to just the project. Regardless of file size, it struggles a lot, but maybe it's just a problem with the performance available.

It's scoped to just the project. Regardless of file size, it struggles a lot, but maybe it's just a problem with the performance available.

This bug still seems to be open.
We are working on a project with 1600+ AL files
Any solutions yet?

@kalberes could you share some tips on how to mitigate this issue?

There is nothing new to be added but what has been said.
Format on save if enabled is very slow on large projects.  The only thing to do is to disable it with this setting:
"[al]": { "editor.formatOnSave": false}
It could also be tried what @NKarolak has suggested to only format on modifications. But if the AL file is large (many hundreds of lines) than that may also be slow.

authors: ChiefORZ DCMK320 EmilDamsbo JacobSMoller MBK75 NKarolak Nikodermus atoader fvet kalberes lyonsbp mboustedt mikedizon mjmatthiesen mxshapira photocurio ralf-escher sirpy sstalder wubo0067 yurim108


text:
IdRanges by Object Type in App.json

I have an OnPrem Customer solution with multiple extensions that all should fit within Customers purchased Object ranges.
Typically you do not have as many Table object as Pages/Report etc.
Example:
50 Tables and Codeunits available + 100 Pages and Reports available in Customer Licens.
"Ext A" needs 40 Tables and 50 Pages. "Ext B" and "Ext C" both needs 5 tables each, total og 50 tables.
IdRanges in App.json :
"Ext A" : 50.000 - 50.050  OK
"Ext B" : 50.050 - 50.059 (No tables available !)
"Ext C" : 50.060 - 50.069 ( No Tables available !)
How should I handle this Issue - IdRange by Object Type would be an option ?

I know one solution could be to re-assign some Object ranges in the Customer License, but some Types as Reports are locked from 50.000 - 50.099 as a result of licens conversion from older NAV versions.

For consideration i will add:
If u have 20 tables and 100 pages in a extension, u can just:
add a range of 20 items (and dont use more than 20 pages/pagesext/report)
OR
add 100 items and without the programmer knowledment, the app will give an error to the client when the client try to use the 21,22,23... tables.
This problem would be solved with the suggestion above

Please go ahead and post this to our Ideas forum at https://aka.ms/BusinessCentralideas, or vote up the idea if its already there. We're constantly monitoring top Ideas and will consider them for a future release.

authors: MetaK Vibaek atoader


text:
[Extensibility Enhancement] Table 5902 - Service Line - AutoReserve (align CA/MX/US with W1)

Dear ALAppExtensions team,
Through this issue we would like to request an overload to be added for the AutoReserve procedure in table 5902 Service Line for localizations CA/MX/US to align these localizations with W1.
W1 has the AutoReserve procedure, with the following signature:
    procedure AutoReserve()
    var
        ServiceMgtSetup: Record "Service Mgt. Setup";
        ReservationEntry: Record "Reservation Entry";
        ReservMgt: Codeunit "Reservation Management";
        ConfirmManagement: Codeunit "Confirm Management";
        QtyToReserve: Decimal;
        QtyToReserveBase: Decimal;
    begin
        TestField(Type, Type::Item);
        TestField("No.");
        if Reserve = Reserve::Never then
            FieldError(Reserve);
        ReserveServLine.ReservQuantity(Rec, QtyToReserve, QtyToReserveBase);
        if QtyToReserveBase <> 0 then begin
            ReservMgt.SetReservSource(Rec);
            if ReplaceServItemAction then begin
                ReserveServLine.FindReservEntry(Rec, ReservationEntry);
                ReservMgt.SetTrackingFromReservEntry(ReservationEntry);
            end;
            ReservMgt.AutoReserve(FullAutoReservation, '', "Order Date", QtyToReserve, QtyToReserveBase);
            Find;
            ServiceMgtSetup.Get();
            if (not FullAutoReservation) and (not ServiceMgtSetup."Skip Manual Reservation") then begin
                Commit();
                if ConfirmManagement.GetResponse(ManualReserveQst, true) then begin
                    ShowReservation();
                    Find;
                end;
            end;
        end;
    end;

For CA/MX/US we would like to request a procedure with the same (parameterless) signature to be added, resulting in the following:
    // >> NEW PROCEDURE
    procedure AutoReserve()
    begin
        AutoReserve(true);
    end;
    // << NEW PROCEDURE

    procedure AutoReserve(ShowReservationForm: Boolean)
    var
        ServiceMgtSetup: Record "Service Mgt. Setup";
        ReservationEntry: Record "Reservation Entry";
        ReservMgt: Codeunit "Reservation Management";
        ConfirmManagement: Codeunit "Confirm Management";
        QtyToReserve: Decimal;
        QtyToReserveBase: Decimal;
    begin
        TestField(Type, Type::Item);
        TestField("No.");
        if Reserve = Reserve::Never then
            FieldError(Reserve);
        ReserveServLine.ReservQuantity(Rec, QtyToReserve, QtyToReserveBase);
        if QtyToReserveBase <> 0 then begin
            ReservMgt.SetReservSource(Rec);
            if ReplaceServItemAction then begin
                ReserveServLine.FindReservEntry(Rec, ReservationEntry);
                ReservMgt.SetTrackingFromReservEntry(ReservationEntry);
            end;
            ReservMgt.AutoReserve(FullAutoReservation, '', "Order Date", QtyToReserve, QtyToReserveBase);
            Find;
            ServiceMgtSetup.Get();
            if (not FullAutoReservation) and (not ServiceMgtSetup."Skip Manual Reservation") and ShowReservationForm then begin
                Commit();
                if ConfirmManagement.GetResponse(ManualReserveQst, true) then begin
                    ShowReservation();
                    Find;
                end;
            end;
        end;
    end;

This would resolve the breaking change between W1 and CA/MX/US and allow extensions that invoke this procedure to be installed in these localizations as well.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.

authors: JesperSchulz rvanbekkum

repo: microsoft/ALAppExtensions


text:
[Extensibility Request] Table 99 "Item Vendor" - Procedure from Local to Global

Hello, we need the following currently Local procedure to be set as Global. Can you please check this? Thank you!
 procedure InsertItemCrossReference()

No, this is not possible, this is obsoleted and already removed

authors: AlexanderYakunin MarkoMilosavljevic


text:
[Event Request] Page 95 Sales Quote Subform - OnQuantityOnAfterValidateOnBeforeDeltaUpdateTotals

please include sender in the event OnQuantityOnAfterValidateOnBeforeDeltaUpdateTotals in the page 95
[IntegrationEvent(true, false)]
local procedure OnQuantityOnAfterValidateOnBeforeDeltaUpdateTotals(var SalesLine: Record "Sales Line"; var xSalesLine: Record "Sales Line")
begin
end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 47651.

authors: JesperSchulz miljance


text:
[Event Request] - OnBeforeCheckLine in Codeunit 12 "Gen. Jnl.-Post Line"

Hello, please consider adding the following event to Codeunit  12 "Gen. Jnl.-Post Line"
    [IntegrationEvent(false, false)]
    local procedure OnBeforeCheckLine(var GenJnlLine: Record "Gen. Journal Line"; var IsHandled: Boolean)
    begin
    end;

and call it accordingly inside the "Code" procedure:
local procedure "Code"(var GenJnlLine: Record "Gen. Journal Line"; CheckLine: Boolean)
    var
        Balancing: Boolean;
        IsTransactionConsistent: Boolean;
        IsPosted: Boolean;

        **IsHandled: Boolean;**

    begin
        IsPosted := false;
        OnBeforeCode(GenJnlLine, CheckLine, IsPosted, GLReg);
        if IsPosted then
            exit;

        GetGLSourceCode();

        with GenJnlLine do begin
            if EmptyLine() then begin
                InitLastDocDate(GenJnlLine);
                exit;
            end;

            **OnBeforeCheckLine(GenJnlLine, IsHandled);
            if not IsHandled then begin**

                if CheckLine then begin
                    if OverrideDimErr then
                        GenJnlCheckLine.SetOverDimErr();
                    GenJnlCheckLine.RunCheck(GenJnlLine);
                end else
                    if GenJnlCheckLine.DateNotAllowed("Posting Date") then
                        FieldError("Posting Date", Text1130024);

            **end;**

            AmountRoundingPrecision := InitAmounts(GenJnlLine);

            if "Bill-to/Pay-to No." = '' then
                case true of
...
...

Thank you !

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 52463.

authors: JesperSchulz oldmat


text:
[Event Request] Codeunit 6620 Copy Document Mgt. - procedure CopySalesDocLine - OnAfterInsertToSalesLine

Please add the following Event OnAfterInsertToSalesLine to procedure CopySalesDocLine in Codeunit 6620 Copy Document Mgt.
[Event Request] Codeunit 6620 - Copy Document Mgt. - procedure CopySalesDocLine
var
    RoundingLineInserted: Boolean;
    CopyThisLine: Boolean;
    InvDiscountAmount: Decimal;
    IsHandled: Boolean;
begin
    CopyThisLine := true;
    IsHandled := false;
    OnBeforeCopySalesLine(ToSalesHeader, FromSalesHeader, FromSalesLine, RecalculateLines, CopyThisLine, MoveNegLines, Result, IsHandled, DocLineNo);
    if IsHandled then
        exit(Result);
    ...
    IsHandled := false;
    OnCopySalesDocLineOnBeforeCopyThisLine(ToSalesHeader, ToSalesLine, FromSalesLine, FromSalesDocType, RecalculateLines, CopyThisLine, LinesNotCopied, Result, IsHandled, NextLineNo, DocLineNo, MoveNegLines);
    if IsHandled then
        exit(Result);
    if CopyThisLine then begin
        OnBeforeInsertToSalesLine(
          ToSalesLine, FromSalesLine, FromSalesDocType.AsInteger(), RecalculateLines, ToSalesHeader, DocLineNo, NextLineNo, RecalculateAmount);
        ToSalesLine.Insert();

        OnAfterInsertToSalesLine(ToSalesLine, FromSalesLine, FromDocType, MoveNegLines);   // <-- NEW EVENT

        HandleAsmAttachedToSalesLine(ToSalesLine);
    ...

[IntegrationEvent(true, false)] // <-- we need IncludeSender to be set to true to call IsCopyItemTrkg
local procedure OnAfterInsertToSalesLine(var ToSalesLine: Record "Sales Line"; var FromSalesLine: Record "Sales Line"; FromDocType: Option; MoveNegLines: Boolean)
begin
end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 10998.


text:
[Event Request] Add new event to apply filters on Approval Entry Record and Workflow Step Instance Record before Send Approval and Cancel approval for General Journal batch.

Hi team,
There is a new feature that I am working on for approvals based on General Journal batch.
In order to make our functionality work we will need additional events to apply filters on Approval Entry and Workflow Step Instance Records.
New Event Will be

codeunit 1501 "Workflow Management"

Event signature will be:-
[IntegrationEvent(false, false)]
local procedure OnFindWorkflowStepInstanceWithOptionalWorkflowStartOnAfterSetWorkflowStepInstanceLoopFilters(RecRef: RecordRef; var WorkflowStepInstanceLoop: Record "Workflow Step Instance"; FunctionName: Code[128]; StartWorkflow: Boolean)
begin
end;

codeunit 1535 "Approvals Mgmt."

Event signature will be:-
[IntegrationEvent(false, false)]
local procedure OnHasOpenApprovalEntriesForCurrentUserOnAfterSetApprovalEntryFilters(var ApprovalEntry: Record "Approval Entry")
begin
end;

Event signature will be:-
[IntegrationEvent(false, false)]
local procedure OnAfterApproveSelectedApprovalRequest(var ApprovalEntry: Record "Approval Entry")
begin
end;

Event signature will be:-
[IntegrationEvent(false, false)]
local procedure OnBeforeRejectSelectedApprovalRequest(var ApprovalEntry: Record "Approval Entry")
begin
end;

Event signature will be:-

[IntegrationEvent(false, false)]

local procedure OnAfterDelegateSelectedApprovalRequest(var ApprovalEntry: Record "Approval Entry")

begin

end;

table 232 "Gen. Journal Batch"

Event signature will be:-

[IntegrationEvent(false, false)]

local procedure OnGetBalanceOnAfterSetGenJournalLineFilters(var GenJournalLine: Record "Gen. Journal Line")

begin

end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 12576.

authors: JesperSchulz arvindbinarystream


text:
Add event OnBeforeDimCodeToType into codeunit 7130 "Item Budget Management"

Describe the request
The code should be like this:
local procedure DimCodeToType(DimCode: Code[20]; ItemBudgetName: Record "Item Budget Name") Result: Enum "Item Budget Dimension Type"
var
    Location: Record Location;
    Item: Record Item;
    Cust: Record Customer;
    Vend: Record Vendor;
    IsHandled: Boolean;
begin
    IsHandled := false;
    OnBeforeDimCodeToType(DimCode, ItemBudgetName, Result, IsHandled);
    if IsHandled then
        exit(Result);

    GetGLSetup();
    case DimCode of
        '':
            exit(Enum::"Item Budget Dimension Type"::Undefined);
        UpperCase(Item.TableCaption()):
            exit(Enum::"Item Budget Dimension Type"::Item);
        UpperCase(Cust.TableCaption()):
            exit(Enum::"Item Budget Dimension Type"::Customer);
        UpperCase(Vend.TableCaption()):
            exit(Enum::"Item Budget Dimension Type"::Vendor);
        UpperCase(Text003):
            exit(Enum::"Item Budget Dimension Type"::Period);
        UpperCase(Location.TableCaption()):
            exit(Enum::"Item Budget Dimension Type"::Location);
        GLSetup."Global Dimension 1 Code":
            exit(Enum::"Item Budget Dimension Type"::"Global Dimension 1");
        GLSetup."Global Dimension 2 Code":
            exit(Enum::"Item Budget Dimension Type"::"Global Dimension 2");
        ItemBudgetName."Budget Dimension 1 Code":
            exit(Enum::"Item Budget Dimension Type"::"Budget Dimension 1");
        ItemBudgetName."Budget Dimension 2 Code":
            exit(Enum::"Item Budget Dimension Type"::"Budget Dimension 2");
        ItemBudgetName."Budget Dimension 3 Code":
            exit(Enum::"Item Budget Dimension Type"::"Budget Dimension 3");
        else
            exit(Enum::"Item Budget Dimension Type"::Undefined);
    end;
end;

[IntegrationEvent(false, false)]
local procedure OnBeforeDimCodeToType(DimCode: Text[30]; ItemBudgetName: Record "Item Budget Name"; var Result: Enum "Item Budget Dimension Type"; var IsHandled: Boolean)
begin
end;

Additional context
Like codeunit 7153 "Item Analysis Management" we need this event to handle the program logic and customized it.
Internal work item: AB#538745

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 21278.

Availability update: We will publish a fix for this issue in the next update for release 24.
Build ID to track: 21287.

authors: JesperSchulz NBTPaolinoMattia


text:
[EventRequest] codeunit 80 “Sales-Post”, PostPayment[local]

Please add a new publisher event OnBeforePostPayment in Codeunit 80 on function PostPayment and call it as shown in the image below:

Please add the corresponding Integration Event In the bottom of the codeunit

I cannot find PostPayment in W1, which country is this?

The country is Italy (IT)

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.