include user's existing term codes

People may use these for other things. (like tmux seamless switching! :smile: )

Merged, thanks.


Syntax highlighting doesn't work in files preview for custom file types.

Info

Operating System:
Shell:
Terminal:
nvim --version: NVIM v0.9.1
fzf --version: 0.42.0 (brew)

[x] The issue is reproducible with mini.sh

Description
I am using following auto command to want to enable SQL syntax highlighting for files with extension *.ksql
autocmd BufEnter *.ksql setlocal filetype=sql

When I open such files - syntax highlighting works, but when I execute :FzfLua files - the preview window doesn't highlight the syntax for *.ksql files.
Can you please help ?

The preview buffer has autocmds disabled and the treesitter highlighting is performed manually, this has many reasons one of which to disable LSP analysis on the preview buffer as well as other potential collisions with other plug-in autocmds - this means your autocmd doesn’t do anything in the context of the preview buffer.
The filetype is determined by a call to vim.filetype.match which doesn’t know about your override:
https://github.com/ibhagwan/fzf-lua/blob/c3c71df6ffba3cc90335c538fad81aa7a0182e57/lua/fzf-lua/previewer/builtin.lua#L774-L775
The only solution I can offer is a manual config override within Fzf-lua, something like:
ext_override = { ['ksql'] = 'sql', … }

If this is something you can live with I can implement if pretty quickly.

https://github.com/ibhagwan/fzf-lua/commit/d5e21216629f277377329374f7f0890714ce1220
@ievgenii-shepeliuk, update to the latest commit and add the below to your setup:
require("fzf-lua").setup({
  previewers = {
    builtin = {
      ext_ft_override = {
        ["ksql"] = "sql",
        -- other filetype overrides
      }
    }
  }
})

Hello @ibhagwan
It's working now, thank you.


Implement concept for modal windows

Summary of changes:

Close button is now focusable.
Close by background click is removed.
Modal has a fixed width.
Header, body and footer are now visibly separated.
Modal keeps responsiveness for smaller screens.
In case of content being higher than maximum height,
modal body is scrollable.

Closes #1681
Closes https://github.com/camunda/camunda-modeler/issues/1575

Umm I missed the close icon hover/active style. Let me fix that.

@nikku @nazlikaya Ready for review

Some visual impressions:

Looks good from the feel perspective.

Added two minor fixes on top.

Looking goood! 👍

Noticed: missing X button for some modals

This needs to be clarified. Not sure what could be the meaning of X button in case of privacy preferences.

This needs to be clarified. Not sure what could be the meaning of X button in case of privacy preferences.

This is by design. The user may not close the dialog via ESC or close button. Instead, she has to explicitly confirm what is written there (provide consent).

This needs to be clarified. Not sure what could be the meaning of X button in case of privacy preferences.

This is by design. The user may not close the dialog via ESC or close button. Instead, she has to explicitly confirm what is written there (provide consent).

Exactly.

Enter needs to trigger the Primary button, only if the primary button is on focus.

Enter needs to trigger the Primary button, only if the primary button is on focus.

That's how it works right now, right?

I added X button for Privacy Preferences when they are already saved somehow (so not for the first startup modal).

:cake:


Memory requested too high in aks-periscope daemonSet

Describe the bug
[Not a bug but a potential point of improvement]
$ az aks kollect -n xxx -g xxx --kube-objects 'default/deployment/ratings-v1' --storage-account xxx
...
$ kubectl describe -n aks-periscope ds aks-periscope
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: aks-periscope
...
          resources:
            limits:
              cpu: '1'
              memory: 2000Mi
            requests:
              cpu: 250m
              memory: 500Mi      *******<<<<
...

From AKS user's practical perspective, this amount of ram request is too much for a debugging feature/plugin. Consumers like omsagent and osm-controller cost around 250Mi, which is still considered high.
To Reproduce
Deploy periscope through az aks kollect (in preview).
Expected behavior
Consider:

Use less sub processes while collecting things sequentially
The debug deploy does not have to be a ds.

Hi @kuzhao - thank you for highlighting this. We'll do some investigation to see how much memory we actually need, as I suspect you're right that it could be significantly lower.
Quick question: what's the 'debug deploy' you're referring to in your last bullet point?

Hi @kuzhao - thank you for highlighting this. We'll do some investigation to see how much memory we actually need, as I suspect you're right that it could be significantly lower.
Quick question: what's the 'debug deploy' you're referring to in your last bullet point?

Appreciate the attention, Peter. For "debug deploy", i might be using a fumble word imao...  im just referring to the aks-periscope (deployed via az aks kollect for debugging, the source of 'debug deploy').
To expand more on this bullet, the periscope daemonSet runs on all nodes, although I set a specific k8s object to debug. Ideally, periscope should launch pod and collect only on nodes where the pods of target k8s object is running.
The alternative could be either rs with podAffinity or ds with nodeSelector.

If that is a need for you, feel free to submit a feature request issue. It's always good to understand people's use cases. @Tatsinnit might recall if that's ever been discussed before?

Thank you so much for this discussion to you both ❤ 🙏 Thanks @peterbom for the question and sorry for delayed reply, to the question the answer is --> no. we had no plan for this in initial days of this tool. Day-1 we were focused on broadcast mechanism hence the use of daemonset to run in all nodes.
💡 Just some built up Idea: we could always move this to discussion and see how many folks really want this scenario et. al. (what do you think?)

Moved the discussion to #225 - thank you @Tatsinnit and @kuzhao for the suggestions and feel free to contribute to the discussions.


Cleanup event handlers before return.

After the promisePipe returns, it leaves some events handlers installed
in the streams. If the user later wants to reuse the streams, the
handlers will be called out of proper contexts, which can lead to bad
code behavior for no clear sane reason.
We fix this by uninstalling all event handlers before the function
returns or when an error happens.
Notice that any prior event handler the user installed for the relevant
events will be lost after the function returns. Fixing this would
require a somewhat bigger code change, which seems not worth
to cover such corner case.

Pushed a commit to remove node 4.

A more careful reading of the stream API showed that contrary to common sense in other stream APIs, a stream in nodejs cannot be reused once it is piped. So, if this is right, this PR has no practical effect.


[Question] What is the purpose of..

I have noticed in the distributed folder two files that aren't present in the repo.

messages_de.js
replacements.js

What's their purpose?

messages_de was planned for a translation of the extension to german.
replacements.js is the file shipped within the old integration, this file was the injected code in Visual Studio Code

Old code that somehow survived in my dist folder. It won't be present in next release.


Encyclopedia Bug/Crash

Encyclopedia Bug/Crash

Count Dooku is broken which is causing the ctd when opening Encyclopedia
Or more accurately it looks like the clans and faction of Count Dooku are the problem.
"allAliveHero.Clan?.Name.ToString() ?? "")" the .Name is returning null so something about the clan name is wack

Some heros are not assigned the correct clans atm. For example Jango Fett is not setup correctly causing to crash when opening his Encyclopedia page


Fix discord invite badge

What piece of documentation is affected?
Discord invite badge is invalid.
What part(s) of the article would you like to see updated?
All the discord bagdes
Additional Information
No response
Acknowledgements

[X] My issue title is concise, descriptive, and in title casing.
[X] I have searched the existing issues to make sure this feature has not been requested yet.
[X] I have provided enough information for the maintainers to understand and evaluate this request.

If you're having an issue in discord, please let us know in discord.

What piece of documentation is affected?
Discord invite badge is invalid.
What part(s) of the article would you like to see updated?
All the discord bagdes
Additional Information
No response
Acknowledgements

[x]  My issue title is concise, descriptive, and in title casing.
[x]  I have searched the existing issues to make sure this feature has not been requested yet.
[x]  I have provided enough information for the maintainers to understand and evaluate this request.

Thanks for letting me know!  Just updated the link.
https://discord.gg/d3TkHRZcjD


Add command line flags for severity

This PR adds a set of command-line flags that enable specifying what message types to fail on.
Presently, to change the message types to fail on( Error, warning, refactor, etc), one would either need to modify pylint-exit's source code or write a wrapper library that overwrites the EXIT_CODE_LIST constant.
I found the requirement of writing a wrapper and/or modifying the source file to be inflexible, as such I sought out an alternate solution.
This pull request provides the following cli flags that modify this list, thereby allowing pylint-exit's behavior to be modified from the command line.

aliases
severity

-wfail, --warn-fail
Fail if a warning level message is emitted

-efail, --error-fail
Fail if an Error level message is emitted

-rfail, --refactor-fail
Fail if a Refactor level message is emitted

-cfail, --convention-fail
Fail if a convention level message is emitted

If the flag is present, it will be used instead of the value from the source file.
If the flag is not present, the value from the source file will be used instead.
This is done as not to change the existing interface.

These flags allow users to specify what message types they want to fail on from a shell script / command line, rather than having to rely on forking this project and making source changes.
Example usage:
pylint-exit> python .\pylint_exit.py 24 -cfail
The following messages were raised:

  - refactor message issued
  - convention message issued

Fatal messages detected.  Failing...

Any way we can get this merged and released @jongracecox ?

Sorry I didn't get to this sooner, the PR somehow slipped under my radar.  I like this update, and I'm going to merge it in.  Some things that I would like to do after merging this is:

Update the readme to include the new command line args.
Add -e, -w, -c, -f command line arguments as shorter versions.
Switch the exit code list into a dict to make it easier to locate things and modify them.  There is some awkward code in there to locate items in the list and that could all go away with a dict.

@theunkn0wn1 Thank you for this PR!  It's a great addition, and I appreciate you taking the time to submit this.  Like I said before, I'm sorry I missed this when you first added it.  I have merged and added it to the latest release (v1.1.0) which is available for install via pip.  I also added some documentation on these new arguments to the readme, and a few doctests to your functions.
Thanks again!


Duplicated sub-piplines

HKube micro-service
This has been shown to @yehiyam .
Sometimes instead of single sub-pipe creation in creates several sub-pipelines

Still happens?
With new wrapper?

never accrued during tests


enable TCP keepalive

Set keepalive at the TCP level to maintain the enode or loadbalancer connection.
Create two new wrapper classes in com.marklogic.client.impl:

MarkLogicSSLSocketFactory extends SSLSocketFactory
MarkLogicSocketFactory extends SocketFactory

Each of the wrapper classes:

Has package visibility
Delegates to the base class
Has a package-visible constructor that takes an instance of the base class and sets a private field
Overrides the createSocket() factory methods to

Construct the socket by delegating to the factory method of the field
Configure the constructed socket by calling socket.setKeepAlive(true)
Return the configured socket

During initialization of the OkHttpClient.Builder within OkHttpServices:

Modify the calls to clientBldr.sslSocketFactory() to pass new MarkLogicSSLSocketFactory(sslContext.getSocketFactory())
Add an else case (where sslContext is null) that calls clientBldr.socketFactory(new MarkLogicSocketFactory(SocketFactory.getDefault()))

This change should be fully backward compatible.
See internal issues:  MLAAS-2580 and RFE-4350

Merged into master, ready to ship as 5.3.2


Stale cache due to not regenerated .a files

Hey,
Thanks for gocode, it's been a bless to use in my editor (Visual Studio Code)!
I have an issue with some stale cache, on Linux (Ubuntu 64 bits 16.04LTS). I'm running latest updated tip (hash 478b96fe0e77b4451b866559e2adb407fbce7120) gocode with Go 1.7
I did notice some staled cache on my packages, and the new/removed exported structs, variables, or any data fields were not seen by gocode when requesting completion.
I saw that gocode, when completion is requested, is generating the static libraries, .a files, and seems to use them as a reference.
ls -l $GOPATH/pkg/linux_amd64/<path_to_project>/                                                                                total 32
-rw-rw-r-- 1 didrocks didrocks  3252 oct.  27 14:29 dirs.a
-rw-rw-r-- 1 didrocks didrocks  8644 oct.  27 14:29 logger.a
-rw-rw-r-- 1 didrocks didrocks 16076 oct.  27 14:29 state.a

I notice that, making a (valid) change to the state package for instance, that gocode doesn't regenerate state.a (still same size and timestamp), and so, doesn't offer the new exposed struct. However, running
gocode close
gocode --debug -s

shows the partially new state file content. For instance:
Adding Abc struct for testing:
package state

// State that can be a snap in
type State struct {
	Channel  string
	DevMode  bool
	Revision string
	Version  string
}

// Transition from one state to another one
type Transition struct {
	Action Action
	Next   *State
}

// Action associated to a Transition
type Action int

const (
	// Install or update a snap
	Install = iota
	// Revert a snap
	Revert
	// Remove a snap
	Remove
)

type Abc strin#
2016/10/27 14:44:38 -------------------------------------------------------
2016/10/27 14:44:38 Found "io/ioutil" at "/home/didrocks/tools/go/pkg/linux_amd64/io/ioutil.a"
2016/10/27 14:44:38 Found "path" at "/home/didrocks/tools/go/pkg/linux_amd64/path.a"
2016/10/27 14:44:38 Found "github.com/ubuntu/snaps-manager/dirs" at "/home/didrocks/workspace-go/pkg/linux_amd64/github.com/ubuntu/snaps-manager/dirs.a"
2016/10/27 14:44:38 Found "github.com/ubuntu/snaps-manager/logger" at "/home/didrocks/workspace-go/pkg/linux_amd64/github.com/ubuntu/snaps-manager/logger.a"
2016/10/27 14:44:38 Found "gopkg.in/yaml.v2" at "/home/didrocks/workspace-go/pkg/linux_amd64/gopkg.in/yaml.v2.a"
2016/10/27 14:44:38 Offset: 5
2016/10/27 14:44:38 Number of candidates found: 1
2016/10/27 14:44:38 Candidates are:
2016/10/27 14:44:38   type string built-in
2016/10/27 14:44:38 =======================================================

and state.Abc isn't proposed on autocompletion. If you look closely, string isn't complete (compared to file on disk). Would that we why state.a isn't regenerated (triggering a failed compilation too early?), but nothing is showing this in gocode logs.
The .a files are unchanged. Removing them and requesting completion again fixes it once they are regenerated.
If so, this could be an issue with Visual Studio Code plugin itself:
Finished running tool: /home/didrocks/tools/go/bin/go tool vet /home/didrocks/workspace-go/src/github.com/ubuntu/snaps-manager/state/state.go

Finished running tool: /home/didrocks/tools/go/bin/go build -o /tmp/go-code-check -tags "" .

Note that go vet pick the correct (and complete) file on disk and go build doesn't fail. So the file is supposively complete.
Any idea or need more debug info? Thanks!

All I can say is that I don't use autobuild feature and honestly not sure how it works. And while it's not nice for me to not know how part of my software works, that's how it is. If it's indeed fails to rebuild out-dated libraries for some reason, I don't know how to fix that. My view is that gocode will eventually parse source files instead of relying on compiled binaries. But it may be a very distant "eventually". All I can suggest is to look into gocode's code, around the place where it builds stuff (autobuild function in declcache.go). Maybe insert a bunch of printfs there, see what's going on, etc. Maybe it's not even gocode who builds binaries for you, gocode's autobuild feature is disabled by default.

Hi, i got the same problem today. thanks for nfs's opinion.

Thanks lancurtis!
Indeed, lib-path was set matching my go.gopath option from VSC. I don't know how, because looking at https://github.com/Microsoft/vscode-go, there is no clear option set from it. I can only say that shutting down gocode, unset go.gopath from VSC and starting completion again with autobuild gets the static libraries file not stalled anymore and regenerated, even if already present. (and so, completion works)

And I will repeat here what I said in the pull request. If lib-path is set, autobuild shouldn't work, because lib-path is a hack, that says - ignore all Go package lookup rules or whatever other package lookup rules are there and use custom ones with a custom path. Initially lib-path was added to handle very specific Go usage cases, like using Go with google's appengine. Normally text editors shouldn't use lib-path and users shouldn't too.


Disable GPU for Ubuntu18.04

Deleted and recreated the PR.

Link to old review https://github.com/adobe/brackets-shell/pull/647


Integration with microphone and webRTC module

In this example, an integration with the microphone and the webRTC VAD has been done.  I used this as a draft.

Hi,
Many thanks for your example!
Could you please add some minimal information about environment / installation instructions, i.e.:

requirements.txt with your library versions or just some minimal info like pip install lib=version or same via conda;
Some information about environment and any setup required (if any) on the computer this was tested on (i.e. sound drivers or similar);

As for the code it looks nice for an example as is, but in ideal world I would fix a couple of things (these are just a suggestion):

Some of the imports are never used;
Please note that time_stamps =get_speech_ts(audio_float32, model,num_steps=4) can be tuned as well (or you can try using the adaptive method);
Many libraries used (np, wave, scipy, torch, torchaudio) have kind of similar functionalities (i.e. array handling, resampling, loading and saving audio). Ideally in our examples we strive to minimize the dependencies as much as possible. This is by no means obligatory, but if you have time, please try removing redundant APIs (i.e. resampling / saving / loading - can be do via torchaudio for example, np calls can be replaced with torch in most of cases);

requirements added in the README.md
useless imports removed
parameters of get_speech_ts can be tuned
redundant APIs have been removed avoiding functions like resampling, saving, loading ( no time to find the best alternative between libraries)

Nice!

What I like about this - it is the first structured report on using the vad with the language it was not trained on, though italian is kind of similar to spanish
Some people reportedly did this, but they did not return with any tangible tests / demos / metrics, either everything is ok or everything is not ok without details

Yeah, Agree. The possibility to upload small video on issues and readme is a new github feature. I hope to find a lot of instructions like this in the future. I mean, videos are very useful to understand the quality in real case scenarios for examples. Moreover, many people  don't know the metrics and they don't have time to read papers.

Video is very cool
For a long time github has been lacking audio!
Is audio now supported?
Is there some doc / blog post about video?
I totally missed this feature!
Lack of audio / video in md is such a pain

I don't know about blogs or docs but probably you can find them somewhere. Anyway it's very easy! You just need to drag and drop your audio/video on the readme/issue editor! The only limit is about the size. In fact the file should not exceed 10MB


"Unimplemented type: 3" error in protomaps.min.js

Just downloaded a small map
https://protomaps.com/downloads/small_map/a6f512ca-0157-4ca0-8229-9aecb99dc75b
and placed the files on a server, it "works", but with occasional blank tiles (that go away when scrolling or refreshing), and the console log fills up with "Unimplemented type: 3".
The bundled files refer to<EMAIL_ADDRESS>which seems to be quite outdated judging by the versions in the  commits here.

This can be fixed by changing the js & css references to
<link rel="stylesheet"<EMAIL_ADDRESS>/>


Uncaught RangeError: Maximum call stack size exceeded jstree

Hi,
I'm getting this "2jstree.min.js:2 Uncaught RangeError: Maximum call stack size exceeded" when clicking down to a 3-rd depth category on the tree. The output seems correct, and works right for the higher level categories.
$(document).ready(function(){
	$('#jstree_categories').jstree({ 'core' : {
		'data' : <?php echo $treeData; ?>
	} });
	$('#jstree_categories').on("changed.jstree", function (e, data) {
		$('#CategoryID').val(data.selected);
	});
});

// Edit: I'm building the $treeData in php. I can post the actual output if required.

Please use the non-minified version of the code when posting issues. As for the code you posted - you'd be better off using an array and json_encode - your way of building the JSON string is error prone. To get this error I am alwomost certain you have a duplicated ID.
I will reopen if needed when you provide more info (or a demo).
Best regards,
Ivan

My guess is your error is here:
foreach($childrenThird as $childThird){
$treeData .= '{ "text" : "' . $childSecond['CategoryName'] . '", "id" : "' . $childSecond['CategoryID'] . '"},';
}

You probably want to use $childThird?


CDM Editor

Hi,
There are any editor that permit to edit and modify json files in CDM. The goal is to create my custom CDM using the existing files in CDM Folder.
I want to create a folder like Healtcare.
Thank you for your answer and any suggestions are very welcome.

Hello,
These schemas are autogenerated using internal microsoft tooling from dataverse (dynamics) solutions. Currently there is not an editor specifically for CDM files. You can still use VSCode as a tool to create your own manifests and entities from the existing schema documents.
Please check healthcare schema and documentation.

thank you so much :)


Fix set get remove

We use this module in bittorrent-dht and I started to notice some weird errors. The errors were caused by the linked list getting corrupted after a set, get and remove sequence.
I've added a test for this and another commit that fixes the issue. I quick merge on this would be appreciated. Also if you're up for it, feel free to add me as collaborator on this repo if you want some help maintaining this :)

Nice work @mafintosh!

I'll publish 1.2.1 in a sec. I've added you as a contributor @mafintosh and am happy for you to change/add to the library however you see fit. I can also grant npm publish access if you wish.

@chriso thank you! appreciate it. npm publish rights would be great as well :)

@mafintosh what's your npm username?

@chriso it's simply mafintosh , https://npmjs.org/~mafintosh

@chriso did you add me on npm? it doesn't seem to work unless i'm doing something wrong on my end

@mafintosh just added you.

@chriso thanks again!


ITI-66:  search parameters subject vs patient

Section Number
https://profiles.ihe.net/ITI/MHD/ITI-66.html#message-semantics
https://profiles.ihe.net/ITI/MHD/ITI-66.html#example-get
Issue
'patient' and patient.identifier are not a search parameters in this revision of ITI-66 (but they are in ITI-67).  Instead, you have shown subject and subject.identifier
Your example shows patient (which is what we had in find documentmanifests).
GET test.fhir.net/R4/fhir/List?patient=9876&code=submissionset&designationType=http://loinc.org|1234-5
Proposed Change If you meant to search by subject.identifier, then update the example.   When you update this, it would also be good to search by both patient id 9876 and assigning authority, setting a good example.
If you meant to enable search by patient or patient identifier, then update the list of query parameters.
Priority: medium

both should be ".subject" element, and "patient" query parameter.


Fix DCExecutionProfileTest

Right now it is failing on master due to the LWT and tablets conflict:
/jenkins/workspace/scylla-master/driver-tests/cpp-driver-matrix-test/cpp-driver-scylla/tests/src/integration/objects/future.hpp:152
      Expected: CASS_OK
To be equal to: wait_code
      Which is: CASS_ERROR_SERVER_INVALID_QUERY [Invalid query]
Invalid query: Cannot use LightWeight Transactions for table dcexecutionprofile_blacklistdcfiltering.cassandra_blacklistdcfiltering: LWT is not yet supported with tablets

Run example: https://jenkins.scylladb.com/view/master/job/scylla-master/job/driver-tests/job/cpp-driver-matrix-test/1203/

@dkropachev I have a question. Assuming I fixed the tests. What are my next steps?
From our yesterday's discussion, I remembered that I need to apply a patch for an upstream (i.e. in version/datastax/ directory). Do I do the same for scylla (version/scylla directory)? And most importantly, do I open a PR in https://github.com/scylladb/cpp-driver that fixes the tests?
I'm asking this, because AFAIU, only 2 last release versions of the driver are tested. This means if I only merge the changes to master of cpp-driver, these will not be visible in the test (since they are yet to be released). But I might be talking gibberish, so correct me if I'm wrong.

@dkropachev I have a question. Assuming I fixed the tests. What are my next steps?
From our yesterday's discussion, I remembered that I need to apply a patch for an upstream (i.e. in version/datastax/ directory). Do I do the same for scylla (version/scylla directory)? And most importantly, do I open a PR in https://github.com/scylladb/cpp-driver that fixes the tests?

We discussed it briefly, for scylladb/cpp-driver you fix it on master, if it is appropriate, to make next version work properly and put the same fix into versions/scylla to a folder that makes sense.
If you know when it is broken pick right version.
If there is already folders for affected versions, you need to update all of them.
if version where it become broken is not there, create it copying folder for closest version.


Signup not working

Hey Martin, how are you mate?
I love JWT and I try to spread its love as much as possible and this first glance of JWT with Angular 2 is awesome (still too much boilerplate, but awesome nonetheless).
That said, the signup route doesn't work and I hate when I cannot send a PR to fix it because well, I have no clue. Everything seems to be in order.
There is a typo though (PR incoming) but that doesn't fix it.
I also created a KOA backend for the demo (to practice it) and it ended really cool (I can put it on github if you want).
Gracias.

the problem is partly due to the router

I am digging all I can to figure how what's happening. It is not routing anything really. You can't go /login nor /signup.

@Foxandxss the signup link should work now. The state is managing in memory since the location service that manages the url isn't merged yet


 So much so that an audit of only that is unlikely to be accepted as a validation of plain hashtree.
It seemed worth asking (in light of the someday audit of this repo and a desire to link to audited code from C, Nim, Python, etc.), if you know a way to maintain a clear chain of custody / do a clean transformation from a Go assembly origin to ELF .o/.so on Linux | Mach-O on OSX | COFF on Windows. (I realize function calling conventions may vary, but this situation seems to have literally only 1 function.)
I could not seem to get gccgo -c (version 12.2.1) to accept hash_amd64.s at all.  (Running that did show a couple stray space-after-backslash issues - I can do a PR if you want).  Seems gccgo may not even support assembler/OSX/Win in the same way at all, at least 4 years ago according to Ian, the author.
I did find go tool asm -S hash_amd64.s; go tool objdump -gnu hash_amd64.o which emits GAS syntax text as comments { though data interpreted as instructions is not pretty.. :-) }.  So, it may be possible to build a fully expanded variant that way & touch up call entry & exit for re-assembly by GAS.
Maybe you have better ideas?  Thanks in advance!

I don't think this is possible at all, the stack structure of the Go runtime is very different than the C ABI and Go takes care of that completely. Notice that there's not even an attempt in the gohashtree library to deal with stack alignment nor to reserve space in the stack to deal with the saving of variables. Go takes care of that. This is one of the biggest complications in hashtree and in its testing across different OSs. I very much doubt one would be able to export any of these assembly into the other by an automated process.

Yeah. Thanks for the reply.  I guess that just means the arm64 port needs to be done to support a lot of Cloud/Apple hardware on anything but Go.

Yeah. Thanks for the reply. I guess that just means the arm64 port needs to be done to support a lot of Cloud/Apple hardware on anything but Go.

yeah indeed, that's in my open issues for hashtree, will open an issue now and I hope to work on that in the coming weeks


Use json_each for bulk data load

Instead of making batches of a dozen inserts at a time do all inserts in 1 query using a json table passed to json_each. In postgres the same can be done using unnest but sqlite doesn't support arrays :(
https://github.com/electric-sql/electric/blob/02d2b6c69b4d1cd78b49bd38b3128f3949f3fc52/clients/typescript/src/satellite/process.ts#L458

Hey @gorbak25, thanks for your input, this could be a good solution to the problem!
We will need to test it and benchmark it a bit but we will definitely give it a try 👍


Broker displays a direct route to a service, not a tunnelled route

As part of the work to integrate the https://github.com/alphagov/paas-aiven-broker with the GOV.UK PaaS, we're documenting the user-facing ways of interacting with the services it provisions. cf conduit appears to fail to provide a tunnelled-via-an-app route to these services, instead displaying the backend host which is trivially available via cf env.
This is a problem because it doesn't work with services which have an IP whitelist in front of them and which allow only PaaS-originated traffic to reach the service instances.
In Aiven's case, this happens for the Elasticsearch service. It's exposed as an HTTPS URI, with embedded/inline credentials. Perhaps this URI is confusing conduit?
$ cf create-service elasticsearch small-ha-6.x es
Creating service instance foo in org govuk-paas / space demo as admin...
OK

Create in progress. Use 'cf services' or 'cf service es' to check operation status.

$ until cf services | grep ^es | grep -v 'create in progress'; do sleep 5 ; done ; cf conduit es
OK Connecting client
OK Targeting org govuk-paas
OK Targeting space demo
OK Deploying __conduit_8664__
OK Uploading __conduit_8664__ bits
OK Starting __conduit_8664__
OK Waiting for conduit app to become available
OK Fetching service infomation
OK Binding es
OK Fetching environment
OK Starting port forwarding
OK Waiting for port forwarding

The following services are ready for you to connect to:

* service: es (elasticsearch)
  hostname: redacted-1840a56-a302-a57eeb2d3090.aivencloud.com
  password: redacted
  port: 10264
  uri: https://786b50b1-20a0-4d06-b50b-96ca048e4b89:redacted@redacted-1840a56-a302-a57eeb2d3090.aivencloud.com:10264
  username: 786b50b1-20a0-4d06-b50b-96ca048e4b89

Press Ctrl+C to shutdown.

Closing due to time elapsed.

Closing due to time elapsed.


upgrade to black v22.1.0

The CI workflows are failing because black just made their first stable release -- and the most current version on conda-forge has not been updated yet.

this will be resolved in #70


six version is pinned to 1.9.0

Because the requirements.txt sets six==1.9.0, projects that have multiple dependencies on six that use only a lower bound may fail to run because a newer version 1.10.0 might be installed as a result of processing some other dependency and pip is apparently not clever enough to figure all this out on its own.  Any specific reason why the requirement couldn't be six>=1.9.0 ?

There is no reason, I will fix this right away.

fixed in 2.9.2 and pushed to pypi


Unit test generated by RoostGPT

Please pull these awesome changes in!
Test Name      - go-unit-sample
AI Type        - Claude AI
AI Model       - claude-3-opus-20240229
Test Type      - Unit test
Use Type       - cli
Language       - go
Test Framework - Gotest

Exited with exitCode: 1
stdout: === RUN   TestKmp495
=== RUN   TestKmp495/Exact_Match
=== RUN   TestKmp495/No_Match
    Kmp495_test.go:71: Kmp() = [], want []
=== RUN   TestKmp495/Multiple_Matches
=== RUN   TestKmp495/Word_Longer_Than_Text
=== RUN   TestKmp495/Empty_Word
--- FAIL: TestKmp495 (0.00s)
    --- PASS: TestKmp495/Exact_Match (0.00s)
    --- FAIL: TestKmp495/No_Match (0.00s)
    --- PASS: TestKmp495/Multiple_Matches (0.00s)
    --- PASS: TestKmp495/Word_Longer_Than_Text (0.00s)
    --- FAIL: TestKmp495/Empty_Word (0.00s)
panic: runtime error: index out of range [0] with length 0 [recovered]
	panic: runtime error: index out of range [0] with length 0

goroutine 23 [running]:
testing.tRunner.func1.2({0x1125740, 0xc0001a2138})
	/usr/local/go/src/testing/testing.go:1545 +0x238
testing.tRunner.func1()
	/usr/local/go/src/testing/testing.go:1548 +0x397
panic({0x1125740?, 0xc0001a2138?})
	/usr/local/go/src/runtime/panic.go:914 +0x21f
github.com/TheAlgorithms/Go/strings/kmp.Kmp({0x1161250, 0x0}, {0x11323f4, 0x6}, {0x12582a0, 0x0, 0x38d7517e9f39?})
	/private/var/tmp/Roost/RoostGPT/go-unit-sample/1712050662/source/go-samples/strings/kmp/kmp.go:15 +0x175
github.com/TheAlgorithms/Go/strings/kmp.TestKmp495.func1(0xc0001a7380)
	/private/var/tmp/Roost/RoostGPT/go-unit-sample/1712050662/source/go-samples/strings/kmp/Kmp495_test.go:69 +0x4c
testing.tRunner(0xc0001a7380, 0xc0001844c0)
	/usr/local/go/src/testing/testing.go:1595 +0xff
created by testing.(*T).Run in goroutine 18
	/usr/local/go/src/testing/testing.go:1648 +0x3ad
exit status 2
FAIL	github.com/TheAlgorithms/Go/strings/kmp	0.523s
stderr:


Memory leaks?

Hi
It seems that TSID is leaking quite a lot of memory. Valgrind says that for the tests/tsid-formulation:
==59085== LEAK SUMMARY:
==59085==    definitely lost: 229,104 bytes in 17 blocks
==59085==    indirectly lost: 2,912,485 bytes in 1,897 blocks
==59085==      possibly lost: 6,816 bytes in 1 blocks
==59085==    still reachable: 72,704 bytes in 1 blocks
==59085==         suppressed: 0 bytes in 0 blocks
==59085== Reachable blocks (those to which a pointer was found) are not shown.
==59085== To see them, rerun with: --leak-check=full --show-leak-kinds=all

=> so, about 2Mb for the test (it might look like nothing, but our code create TSID objects about 50-100k times, which means about 100Gb can be lost!
See the full report below. From a quick look, it seems that the tsid formulation calls many new, but no delete (see https://github.com/stack-of-tasks/tsid/blob/master/src/formulations/inverse-dynamics-formulation-acc-force.cpp).
=> is it "normal"? It would not be hard to call delete in the destructor or put everything in shared_ptr, I guess.
==59754== Memcheck, a memory error detector
==59754== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==59754== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==59754== Command: tests/tsid-formulation
==59754==
Running 4 test cases...

*** test_invdyn_formulation_acc_force_remove_contact ***
q: 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
[SolverHQuadProg.solver-eiquadprog] Resizing equality constraints from 0 to 18
[SolverHQuadProg.solver-eiquadprog] Resizing inequality constraints from 0 to 71
[SolverHQuadProg.solver-eiquadprog] Resizing Hessian from 0 to 61
Level 0
 - base-dynamics: w=1, equality, 6x61
 - contact_rfoot_motion_task: w=1, equality, 6x61
 - contact_rfoot_force_constraint: w=1, inequality, 17x61
 - contact_lfoot_motion_task: w=1, equality, 6x61
 - contact_lfoot_force_constraint: w=1, inequality, 17x61
 - task-joint-bounds: w=1, inequality, 37x61
Level 1
 - contact_rfoot_force_reg_task: w=1e-05, equality, 6x61
 - contact_lfoot_force_reg_task: w=1e-05, equality, 6x61
 - task-com: w=1, equality, 3x61
 - task-posture: w=0.01, equality, 31x61
 - task-right-foot: w=1000, equality, 6x61

Time 0
  contact_rfoot force: 392.616 	  contact_lfoot force: 5 	task-com err: 0.1 	v=0	 dv=10.1726

### TEST FINISHED ###
v(37x1): [ 0.0006,     0.2,  -0.004,   2e-06, -0.0004,    0.03,   -0.03,    -0.3,  -0.003,   3e-05,   0.003,     0.3,   -0.03,    -0.3,   0.005, -0.0002,  -0.005,     0.3,    0.05,  -0.006,    0.02,   5e-05,   0.006,   2e-05,  0.0007,  -9e-05,   0.001,  -1e-05, -0.0001, -0.0006,   0.002,    0.02,   3e-05,   0.006,   3e-05,  0.0007,  -7e-05]
Final   CoM position:  0.0219732 0.00825469   0.665849
Desired CoM position: 0.0219541       0.1  0.665915

*** test_invdyn_formulation_acc_force ***
q: 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
[SolverHQuadProg.solver-eiquadprog] Resizing equality constraints from 0 to 18
[SolverHQuadProg.solver-eiquadprog] Resizing inequality constraints from 0 to 71
[SolverHQuadProg.solver-eiquadprog] Resizing Hessian from 0 to 61
nVar 61
nEq 18
nIn 71
Initial CoM position:    0.0219541 -3.46945e-18     0.665915
Initial RF position:   R =
1 0 0
0 1 0
0 0 1
  p =       0  -0.096 0.02996

Initial LF position:   R =
1 0 0
0 1 0
0 0 1
  p =       0   0.096 0.02996

Level 0
 - base-dynamics: w=1, equality, 6x61
 - contact_rfoot_motion_task: w=1, equality, 6x61
 - contact_rfoot_force_constraint: w=1, inequality, 17x61
 - contact_lfoot_motion_task: w=1, equality, 6x61
 - contact_lfoot_force_constraint: w=1, inequality, 17x61
 - task-joint-bounds: w=1, inequality, 37x61
Level 1
 - contact_rfoot_force_reg_task: w=1e-05, equality, 6x61
 - contact_lfoot_force_reg_task: w=1e-05, equality, 6x61
 - task-com: w=1, equality, 3x61
 - task-posture: w=0.01, equality, 31x61

Time 0
  contact_rfoot err: 0 	contact_lfoot err: 0 	task-com err: 0.1 	task-posture err: 0 	v=0	 dv=0
dv(37x1): [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

### TEST FINISHED ###
v(37x1): [ 0.0001,    0.03,  -6e-06,   1e-09,  0.0002,   0.004,  -0.004,   -0.05, -0.0006, -0.0001,  0.0005,    0.05,  -0.004,   -0.05,  0.0005, -0.0001, -0.0006,    0.05,   0.007, -0.0009,   0.003,   1e-05,  0.0009,   4e-06,  0.0001,  -1e-05,  0.0002,   1e-05,  -8e-06,  -3e-05,  0.0006,   0.003,   8e-06,  0.0009,   4e-06,  0.0001,   4e-06]
Final   CoM position:   0.0219545 0.000104108    0.665915
Desired CoM position: 0.0219541       0.1  0.665915

*** test_contact_point_invdyn_formulation_acc_force ***
[SolverHQuadProg.solver-eiquadprog] Resizing equality constraints from 0 to 18
[SolverHQuadProg.solver-eiquadprog] Resizing inequality constraints from 0 to 20
[SolverHQuadProg.solver-eiquadprog] Resizing Hessian from 0 to 26
[SolverHQuadProg.solver-eiquadprog] Resizing equality constraints from 18 to 6
contact_BL_contact force:  -1.226e-17 -7.58874e-09       7.0775
contact_BR_contact force:  -1.226e-17 -7.58874e-09       7.0775
contact_FL_contact force: 1.22461e-17 -7.58874e-09      6.51916
contact_FR_contact force:  1.2246e-17 -7.58874e-09      6.51916

### TEST FINISHED ###
v(14x1): [ 1e-22,  2e-10, -2e-09,  1e-05,  4e-22,  4e-23, -3e-05,  4e-05, -3e-05,  4e-05,  7e-06, -4e-05,  7e-06, -4e-05]
Final   CoM position:         0.1 -0.00821487    0.266836
Desired CoM position:         0.1 -0.00821487    0.266836

*** test_invdyn_formulation_acc_force_computation_time ***
q: 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
[SolverHQuadProg.eiquadprog] Resizing equality constraints from 0 to 18
[SolverHQuadProg.eiquadprog] Resizing inequality constraints from 0 to 71
[SolverHQuadProg.eiquadprog] Resizing Hessian from 0 to 61
[SolverHQuadProgFast.eiquadprog-fast] Resizing equality constraints from 0 to 18
[SolverHQuadProgFast.eiquadprog-fast] Resizing inequality constraints from 0 to 71
[SolverHQuadProgFast.eiquadprog-fast] Resizing Hessian from 0 to 61

### TEST FINISHED ###

*** PROFILING RESULTS [ms]                                  min        avg        max        lastTime   nSamples   totalTime  ***
Control cycle                                               1610.710   1623.882   1651.931   1610.916   10         16238.818
HQP                                                         589.302    598.845    606.936    593.080    10         5988.451
HQP_FAST                                                    604.893    631.785    735.278    614.590    10         6317.847
HQP_RT                                                      4107.444   4287.081   5010.367   4107.837   10         42870.812
Problem formulation                                         1016.642   1023.382   1048.339   1017.208   10         10233.820

*** STATISTICS (min - avg - max - last - nSamples - total) ***
active inequalities                                         16.0	17.2	18.0	16.0	10	172.0
solver iterations                                           18.0	19.2	20.0	18.0	10	192.0

*** No errors detected
==59754==
==59754== HEAP SUMMARY:
==59754==     in use at exit: 3,221,109 bytes in 1,916 blocks
==59754==   total heap usage: 120,783 allocs, 118,867 frees, 25,570,004 bytes allocated
==59754==
==59754== 176 (104 direct, 72 indirect) bytes in 1 blocks are definitely lost in loss record 311 of 672
==59754==    at 0x4C2DF66: malloc (vg_replace_malloc.c:307)
==59754==    by 0x7A0356: Eigen::internal::aligned_malloc(unsigned long) (Memory.h:224)
==59754==    by 0x7A48AF: void* Eigen::internal::conditional_aligned_malloc<true>(unsigned long) (Memory.h:305)
==59754==    by 0x7A1DE8: tsid::trajectories::TrajectoryEuclidianConstant::operator new(unsigned long) (trajectory-euclidian.hpp:31)
==59754==    by 0x78D8E4: tsid_formulationTest::test_invdyn_formulation_acc_force_remove_contact::test_method() (tsid-formulation.cpp:235)
==59754==    by 0x78D3FF: tsid_formulationTest::test_invdyn_formulation_acc_force_remove_contact_invoker() (tsid-formulation.cpp:197)
==59754==    by 0x83DE4D: boost::unit_test::ut_detail::unused boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>::invoke<void (*)()>(void (*&)()) (callback.hpp:56)
==59754==    by 0x83B0E4: boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke() (callback.hpp:89)
==59754==    by 0x6356CB0: operator() (callback.hpp:118)
==59754==    by 0x6356CB0: operator() (unit_test_monitor.ipp:41)
==59754==    by 0x6356CB0: invoke<boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<> > > (callback.hpp:42)
==59754==    by 0x6356CB0: boost::unit_test::ut_detail::callback0_impl_t<int, boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > >::invoke() (callback.hpp:89)
==59754==    by 0x6336995: operator() (callback.hpp:118)
==59754==    by 0x6336995: do_invoke<boost::scoped_ptr<boost::detail::translate_exception_base>, boost::unit_test::callback0<int> > (execution_monitor.ipp:281)
==59754==    by 0x6336995: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:885)
==59754==    by 0x63371B2: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:1211)
==59754==    by 0x6356DE1: boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::unit_test::test_case const&) (unit_test_monitor.ipp:69)
==59754==
==59754== 176 (104 direct, 72 indirect) bytes in 1 blocks are definitely lost in loss record 312 of 672
==59754==    at 0x4C2DF66: malloc (vg_replace_malloc.c:307)
==59754==    by 0x7A0356: Eigen::internal::aligned_malloc(unsigned long) (Memory.h:224)
==59754==    by 0x7A48AF: void* Eigen::internal::conditional_aligned_malloc<true>(unsigned long) (Memory.h:305)
==59754==    by 0x7A1DE8: tsid::trajectories::TrajectoryEuclidianConstant::operator new(unsigned long) (trajectory-euclidian.hpp:31)
==59754==    by 0x7926A6: tsid_formulationTest::test_invdyn_formulation_acc_force::test_method() (tsid-formulation.cpp:350)
==59754==    by 0x79249E: tsid_formulationTest::test_invdyn_formulation_acc_force_invoker() (tsid-formulation.cpp:329)
==59754==    by 0x83DE4D: boost::unit_test::ut_detail::unused boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>::invoke<void (*)()>(void (*&)()) (callback.hpp:56)
==59754==    by 0x83B0E4: boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke() (callback.hpp:89)
==59754==    by 0x6356CB0: operator() (callback.hpp:118)
==59754==    by 0x6356CB0: operator() (unit_test_monitor.ipp:41)
==59754==    by 0x6356CB0: invoke<boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<> > > (callback.hpp:42)
==59754==    by 0x6356CB0: boost::unit_test::ut_detail::callback0_impl_t<int, boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > >::invoke() (callback.hpp:89)
==59754==    by 0x6336995: operator() (callback.hpp:118)
==59754==    by 0x6336995: do_invoke<boost::scoped_ptr<boost::detail::translate_exception_base>, boost::unit_test::callback0<int> > (execution_monitor.ipp:281)
==59754==    by 0x6336995: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:885)
==59754==    by 0x63371B2: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:1211)
==59754==    by 0x6356DE1: boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::unit_test::test_case const&) (unit_test_monitor.ipp:69)
==59754==
==59754== 176 (104 direct, 72 indirect) bytes in 1 blocks are definitely lost in loss record 313 of 672
==59754==    at 0x4C2DF66: malloc (vg_replace_malloc.c:307)
==59754==    by 0x7A0356: Eigen::internal::aligned_malloc(unsigned long) (Memory.h:224)
==59754==    by 0x7A48AF: void* Eigen::internal::conditional_aligned_malloc<true>(unsigned long) (Memory.h:305)
==59754==    by 0x7A1DE8: tsid::trajectories::TrajectoryEuclidianConstant::operator new(unsigned long) (trajectory-euclidian.hpp:31)
==59754==    by 0x7993B5: tsid_formulationTest::test_contact_point_invdyn_formulation_acc_force::test_method() (tsid-formulation.cpp:552)
==59754==    by 0x798A0B: tsid_formulationTest::test_contact_point_invdyn_formulation_acc_force_invoker() (tsid-formulation.cpp:492)
==59754==    by 0x83DE4D: boost::unit_test::ut_detail::unused boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>::invoke<void (*)()>(void (*&)()) (callback.hpp:56)
==59754==    by 0x83B0E4: boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke() (callback.hpp:89)
==59754==    by 0x6356CB0: operator() (callback.hpp:118)
==59754==    by 0x6356CB0: operator() (unit_test_monitor.ipp:41)
==59754==    by 0x6356CB0: invoke<boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<> > > (callback.hpp:42)
==59754==    by 0x6356CB0: boost::unit_test::ut_detail::callback0_impl_t<int, boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > >::invoke() (callback.hpp:89)
==59754==    by 0x6336995: operator() (callback.hpp:118)
==59754==    by 0x6336995: do_invoke<boost::scoped_ptr<boost::detail::translate_exception_base>, boost::unit_test::callback0<int> > (execution_monitor.ipp:281)
==59754==    by 0x6336995: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:885)
==59754==    by 0x63371B2: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:1211)
==59754==    by 0x6356DE1: boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::unit_test::test_case const&) (unit_test_monitor.ipp:69)
==59754==
==59754== 176 (104 direct, 72 indirect) bytes in 1 blocks are definitely lost in loss record 314 of 672
==59754==    at 0x4C2DF66: malloc (vg_replace_malloc.c:307)
==59754==    by 0x7A0356: Eigen::internal::aligned_malloc(unsigned long) (Memory.h:224)
==59754==    by 0x7A48AF: void* Eigen::internal::conditional_aligned_malloc<true>(unsigned long) (Memory.h:305)
==59754==    by 0x7A1DE8: tsid::trajectories::TrajectoryEuclidianConstant::operator new(unsigned long) (trajectory-euclidian.hpp:31)
==59754==    by 0x79D400: tsid_formulationTest::test_invdyn_formulation_acc_force_computation_time::test_method() (tsid-formulation.cpp:673)
==59754==    by 0x79D21D: tsid_formulationTest::test_invdyn_formulation_acc_force_computation_time_invoker() (tsid-formulation.cpp:655)
==59754==    by 0x83DE4D: boost::unit_test::ut_detail::unused boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>::invoke<void (*)()>(void (*&)()) (callback.hpp:56)
==59754==    by 0x83B0E4: boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke() (callback.hpp:89)
==59754==    by 0x6356CB0: operator() (callback.hpp:118)
==59754==    by 0x6356CB0: operator() (unit_test_monitor.ipp:41)
==59754==    by 0x6356CB0: invoke<boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<> > > (callback.hpp:42)
==59754==    by 0x6356CB0: boost::unit_test::ut_detail::callback0_impl_t<int, boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > >::invoke() (callback.hpp:89)
==59754==    by 0x6336995: operator() (callback.hpp:118)
==59754==    by 0x6336995: do_invoke<boost::scoped_ptr<boost::detail::translate_exception_base>, boost::unit_test::callback0<int> > (execution_monitor.ipp:281)
==59754==    by 0x6336995: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:885)
==59754==    by 0x63371B2: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:1211)
==59754==    by 0x6356DE1: boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::unit_test::test_case const&) (unit_test_monitor.ipp:69)
==59754==
==59754== 296 bytes in 1 blocks are possibly lost in loss record 391 of 672
==59754==    at 0x4C2DF66: malloc (vg_replace_malloc.c:307)
==59754==    by 0x7A0356: Eigen::internal::aligned_malloc(unsigned long) (Memory.h:224)
==59754==    by 0x7A48AF: void* Eigen::internal::conditional_aligned_malloc<true>(unsigned long) (Memory.h:305)
==59754==    by 0x7B0B8A: double* Eigen::internal::conditional_aligned_new_auto<double, true>(unsigned long) (Memory.h:462)
==59754==    by 0x7A9AC3: Eigen::DenseStorage<double, -1, -1, 1, 0>::resize(long, long, long) (DenseStorage.h:550)
==59754==    by 0x7BA8B7: Eigen::PlainObjectBase<Eigen::Matrix<double, -1, 1, 0, -1, 1> >::resize(long, long) (PlainObjectBase.h:266)
==59754==    by 0x7BC6B3: void Eigen::internal::call_assignment_no_alias<Eigen::Matrix<double, -1, 1, 0, -1, 1>, Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<double>, Eigen::Matrix<double, -1, 1, 0, -1, 1> >, Eigen::internal::assign_op<double> >(Eigen::Matrix<double, -1, 1, 0, -1, 1>&, Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<double>, Eigen::Matrix<double, -1, 1, 0, -1, 1> > const&, Eigen::internal::assign_op<double> const&) (AssignEvaluator.h:736)
==59754==    by 0x7B5B97: Eigen::Matrix<double, -1, 1, 0, -1, 1>& Eigen::PlainObjectBase<Eigen::Matrix<double, -1, 1, 0, -1, 1> >::_set_noalias<Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<double>, Eigen::Matrix<double, -1, 1, 0, -1, 1> > >(Eigen::DenseBase<Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<double>, Eigen::Matrix<double, -1, 1, 0, -1, 1> > > const&) (PlainObjectBase.h:700)
==59754==    by 0x5B6C784: void Eigen::PlainObjectBase<Eigen::Matrix<double, -1, 1, 0, -1, 1> >::_init1<Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<double>, Eigen::Matrix<double, -1, 1, 0, -1, 1> >, Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<double>, Eigen::Matrix<double, -1, 1, 0, -1, 1> > >(Eigen::DenseBase<Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<double>, Eigen::Matrix<double, -1, 1, 0, -1, 1> > > const&) (PlainObjectBase.h:783)
==59754==    by 0x5B6C326: Eigen::Matrix<double, -1, 1, 0, -1, 1>::Matrix<Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<double>, Eigen::Matrix<double, -1, 1, 0, -1, 1> > >(Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<double>, Eigen::Matrix<double, -1, 1, 0, -1, 1> > const&) (Matrix.h:296)
==59754==    by 0x5E04C1F: pinocchio::DataTpl<double, 0, pinocchio::JointCollectionDefaultTpl>::DataTpl(pinocchio::ModelTpl<double, 0, pinocchio::JointCollectionDefaultTpl> const&) (data.hxx:106)
==59754==    by 0x5DFEB58: tsid::InverseDynamicsFormulationAccForce::InverseDynamicsFormulationAccForce(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, tsid::robots::RobotWrapper&, bool) (inverse-dynamics-formulation-acc-force.cpp:48)
==59754==
==59754== 848 (104 direct, 744 indirect) bytes in 1 blocks are definitely lost in loss record 469 of 672
==59754==    at 0x4C2DF66: malloc (vg_replace_malloc.c:307)
==59754==    by 0x7A0356: Eigen::internal::aligned_malloc(unsigned long) (Memory.h:224)
==59754==    by 0x7A48AF: void* Eigen::internal::conditional_aligned_malloc<true>(unsigned long) (Memory.h:305)
==59754==    by 0x7A1DE8: tsid::trajectories::TrajectoryEuclidianConstant::operator new(unsigned long) (trajectory-euclidian.hpp:31)
==59754==    by 0x78D9DB: tsid_formulationTest::test_invdyn_formulation_acc_force_remove_contact::test_method() (tsid-formulation.cpp:239)
==59754==    by 0x78D3FF: tsid_formulationTest::test_invdyn_formulation_acc_force_remove_contact_invoker() (tsid-formulation.cpp:197)
==59754==    by 0x83DE4D: boost::unit_test::ut_detail::unused boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>::invoke<void (*)()>(void (*&)()) (callback.hpp:56)
==59754==    by 0x83B0E4: boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke() (callback.hpp:89)
==59754==    by 0x6356CB0: operator() (callback.hpp:118)
==59754==    by 0x6356CB0: operator() (unit_test_monitor.ipp:41)
==59754==    by 0x6356CB0: invoke<boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<> > > (callback.hpp:42)
==59754==    by 0x6356CB0: boost::unit_test::ut_detail::callback0_impl_t<int, boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > >::invoke() (callback.hpp:89)
==59754==    by 0x6336995: operator() (callback.hpp:118)
==59754==    by 0x6336995: do_invoke<boost::scoped_ptr<boost::detail::translate_exception_base>, boost::unit_test::callback0<int> > (execution_monitor.ipp:281)
==59754==    by 0x6336995: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:885)
==59754==    by 0x63371B2: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:1211)
==59754==    by 0x6356DE1: boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::unit_test::test_case const&) (unit_test_monitor.ipp:69)
==59754==
==59754== 848 (104 direct, 744 indirect) bytes in 1 blocks are definitely lost in loss record 470 of 672
==59754==    at 0x4C2DF66: malloc (vg_replace_malloc.c:307)
==59754==    by 0x7A0356: Eigen::internal::aligned_malloc(unsigned long) (Memory.h:224)
==59754==    by 0x7A48AF: void* Eigen::internal::conditional_aligned_malloc<true>(unsigned long) (Memory.h:305)
==59754==    by 0x7A1DE8: tsid::trajectories::TrajectoryEuclidianConstant::operator new(unsigned long) (trajectory-euclidian.hpp:31)
==59754==    by 0x79279D: tsid_formulationTest::test_invdyn_formulation_acc_force::test_method() (tsid-formulation.cpp:354)
==59754==    by 0x79249E: tsid_formulationTest::test_invdyn_formulation_acc_force_invoker() (tsid-formulation.cpp:329)
==59754==    by 0x83DE4D: boost::unit_test::ut_detail::unused boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>::invoke<void (*)()>(void (*&)()) (callback.hpp:56)
==59754==    by 0x83B0E4: boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke() (callback.hpp:89)
==59754==    by 0x6356CB0: operator() (callback.hpp:118)
==59754==    by 0x6356CB0: operator() (unit_test_monitor.ipp:41)
==59754==    by 0x6356CB0: invoke<boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<> > > (callback.hpp:42)
==59754==    by 0x6356CB0: boost::unit_test::ut_detail::callback0_impl_t<int, boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > >::invoke() (callback.hpp:89)
==59754==    by 0x6336995: operator() (callback.hpp:118)
==59754==    by 0x6336995: do_invoke<boost::scoped_ptr<boost::detail::translate_exception_base>, boost::unit_test::callback0<int> > (execution_monitor.ipp:281)
==59754==    by 0x6336995: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:885)
==59754==    by 0x63371B2: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:1211)
==59754==    by 0x6356DE1: boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::unit_test::test_case const&) (unit_test_monitor.ipp:69)
==59754==
==59754== 848 (104 direct, 744 indirect) bytes in 1 blocks are definitely lost in loss record 471 of 672
==59754==    at 0x4C2DF66: malloc (vg_replace_malloc.c:307)
==59754==    by 0x7A0356: Eigen::internal::aligned_malloc(unsigned long) (Memory.h:224)
==59754==    by 0x7A48AF: void* Eigen::internal::conditional_aligned_malloc<true>(unsigned long) (Memory.h:305)
==59754==    by 0x7A1DE8: tsid::trajectories::TrajectoryEuclidianConstant::operator new(unsigned long) (trajectory-euclidian.hpp:31)
==59754==    by 0x79D4F7: tsid_formulationTest::test_invdyn_formulation_acc_force_computation_time::test_method() (tsid-formulation.cpp:677)
==59754==    by 0x79D21D: tsid_formulationTest::test_invdyn_formulation_acc_force_computation_time_invoker() (tsid-formulation.cpp:655)
==59754==    by 0x83DE4D: boost::unit_test::ut_detail::unused boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>::invoke<void (*)()>(void (*&)()) (callback.hpp:56)
==59754==    by 0x83B0E4: boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke() (callback.hpp:89)
==59754==    by 0x6356CB0: operator() (callback.hpp:118)
==59754==    by 0x6356CB0: operator() (unit_test_monitor.ipp:41)
==59754==    by 0x6356CB0: invoke<boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<> > > (callback.hpp:42)
==59754==    by 0x6356CB0: boost::unit_test::ut_detail::callback0_impl_t<int, boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > >::invoke() (callback.hpp:89)
==59754==    by 0x6336995: operator() (callback.hpp:118)
==59754==    by 0x6336995: do_invoke<boost::scoped_ptr<boost::detail::translate_exception_base>, boost::unit_test::callback0<int> > (execution_monitor.ipp:281)
==59754==    by 0x6336995: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:885)
==59754==    by 0x63371B2: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:1211)
==59754==    by 0x6356DE1: boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::unit_test::test_case const&) (unit_test_monitor.ipp:69)
==59754==
==59754== 16,271 (296 direct, 15,975 indirect) bytes in 1 blocks are definitely lost in loss record 624 of 672
==59754==    at 0x4C2DF66: malloc (vg_replace_malloc.c:307)
==59754==    by 0x7A0356: Eigen::internal::aligned_malloc(unsigned long) (Memory.h:224)
==59754==    by 0x7A48AF: void* Eigen::internal::conditional_aligned_malloc<true>(unsigned long) (Memory.h:305)
==59754==    by 0x5C3EF21: tsid::solvers::SolverHQuadProg::operator new(unsigned long) (solver-HQP-eiquadprog.hpp:34)
==59754==    by 0x5C3EE77: tsid::solvers::SolverHQPFactory::createNewSolver(tsid::solvers::SolverHQP, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (solver-HQP-factory.cpp:35)
==59754==    by 0x79992D: tsid_formulationTest::test_contact_point_invdyn_formulation_acc_force::test_method() (tsid-formulation.cpp:580)
==59754==    by 0x798A0B: tsid_formulationTest::test_contact_point_invdyn_formulation_acc_force_invoker() (tsid-formulation.cpp:492)
==59754==    by 0x83DE4D: boost::unit_test::ut_detail::unused boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>::invoke<void (*)()>(void (*&)()) (callback.hpp:56)
==59754==    by 0x83B0E4: boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke() (callback.hpp:89)
==59754==    by 0x6356CB0: operator() (callback.hpp:118)
==59754==    by 0x6356CB0: operator() (unit_test_monitor.ipp:41)
==59754==    by 0x6356CB0: invoke<boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<> > > (callback.hpp:42)
==59754==    by 0x6356CB0: boost::unit_test::ut_detail::callback0_impl_t<int, boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > >::invoke() (callback.hpp:89)
==59754==    by 0x6336995: operator() (callback.hpp:118)
==59754==    by 0x6336995: do_invoke<boost::scoped_ptr<boost::detail::translate_exception_base>, boost::unit_test::callback0<int> > (execution_monitor.ipp:281)
==59754==    by 0x6336995: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:885)
==59754==    by 0x63371B2: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:1211)
==59754==
==59754== 111,040 (296 direct, 110,744 indirect) bytes in 1 blocks are definitely lost in loss record 660 of 672
==59754==    at 0x4C2DF66: malloc (vg_replace_malloc.c:307)
==59754==    by 0x7A0356: Eigen::internal::aligned_malloc(unsigned long) (Memory.h:224)
==59754==    by 0x7A48AF: void* Eigen::internal::conditional_aligned_malloc<true>(unsigned long) (Memory.h:305)
==59754==    by 0x5C3EF21: tsid::solvers::SolverHQuadProg::operator new(unsigned long) (solver-HQP-eiquadprog.hpp:34)
==59754==    by 0x5C3EE77: tsid::solvers::SolverHQPFactory::createNewSolver(tsid::solvers::SolverHQP, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (solver-HQP-factory.cpp:35)
==59754==    by 0x79D596: tsid_formulationTest::test_invdyn_formulation_acc_force_computation_time::test_method() (tsid-formulation.cpp:682)
==59754==    by 0x79D21D: tsid_formulationTest::test_invdyn_formulation_acc_force_computation_time_invoker() (tsid-formulation.cpp:655)
==59754==    by 0x83DE4D: boost::unit_test::ut_detail::unused boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>::invoke<void (*)()>(void (*&)()) (callback.hpp:56)
==59754==    by 0x83B0E4: boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke() (callback.hpp:89)
==59754==    by 0x6356CB0: operator() (callback.hpp:118)
==59754==    by 0x6356CB0: operator() (unit_test_monitor.ipp:41)
==59754==    by 0x6356CB0: invoke<boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<> > > (callback.hpp:42)
==59754==    by 0x6356CB0: boost::unit_test::ut_detail::callback0_impl_t<int, boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > >::invoke() (callback.hpp:89)
==59754==    by 0x6336995: operator() (callback.hpp:118)
==59754==    by 0x6336995: do_invoke<boost::scoped_ptr<boost::detail::translate_exception_base>, boost::unit_test::callback0<int> > (execution_monitor.ipp:281)
==59754==    by 0x6336995: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:885)
==59754==    by 0x63371B2: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:1211)
==59754==
==59754== 111,071 (296 direct, 110,775 indirect) bytes in 1 blocks are definitely lost in loss record 661 of 672
==59754==    at 0x4C2DF66: malloc (vg_replace_malloc.c:307)
==59754==    by 0x7A0356: Eigen::internal::aligned_malloc(unsigned long) (Memory.h:224)
==59754==    by 0x7A48AF: void* Eigen::internal::conditional_aligned_malloc<true>(unsigned long) (Memory.h:305)
==59754==    by 0x5C3EF21: tsid::solvers::SolverHQuadProg::operator new(unsigned long) (solver-HQP-eiquadprog.hpp:34)
==59754==    by 0x5C3EE77: tsid::solvers::SolverHQPFactory::createNewSolver(tsid::solvers::SolverHQP, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (solver-HQP-factory.cpp:35)
==59754==    by 0x78DA7A: tsid_formulationTest::test_invdyn_formulation_acc_force_remove_contact::test_method() (tsid-formulation.cpp:244)
==59754==    by 0x78D3FF: tsid_formulationTest::test_invdyn_formulation_acc_force_remove_contact_invoker() (tsid-formulation.cpp:197)
==59754==    by 0x83DE4D: boost::unit_test::ut_detail::unused boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>::invoke<void (*)()>(void (*&)()) (callback.hpp:56)
==59754==    by 0x83B0E4: boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke() (callback.hpp:89)
==59754==    by 0x6356CB0: operator() (callback.hpp:118)
==59754==    by 0x6356CB0: operator() (unit_test_monitor.ipp:41)
==59754==    by 0x6356CB0: invoke<boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<> > > (callback.hpp:42)
==59754==    by 0x6356CB0: boost::unit_test::ut_detail::callback0_impl_t<int, boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > >::invoke() (callback.hpp:89)
==59754==    by 0x6336995: operator() (callback.hpp:118)
==59754==    by 0x6336995: do_invoke<boost::scoped_ptr<boost::detail::translate_exception_base>, boost::unit_test::callback0<int> > (execution_monitor.ipp:281)
==59754==    by 0x6336995: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:885)
==59754==    by 0x63371B2: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:1211)
==59754==
==59754== 111,071 (296 direct, 110,775 indirect) bytes in 1 blocks are definitely lost in loss record 662 of 672
==59754==    at 0x4C2DF66: malloc (vg_replace_malloc.c:307)
==59754==    by 0x7A0356: Eigen::internal::aligned_malloc(unsigned long) (Memory.h:224)
==59754==    by 0x7A48AF: void* Eigen::internal::conditional_aligned_malloc<true>(unsigned long) (Memory.h:305)
==59754==    by 0x5C3EF21: tsid::solvers::SolverHQuadProg::operator new(unsigned long) (solver-HQP-eiquadprog.hpp:34)
==59754==    by 0x5C3EE77: tsid::solvers::SolverHQPFactory::createNewSolver(tsid::solvers::SolverHQP, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (solver-HQP-factory.cpp:35)
==59754==    by 0x79283C: tsid_formulationTest::test_invdyn_formulation_acc_force::test_method() (tsid-formulation.cpp:359)
==59754==    by 0x79249E: tsid_formulationTest::test_invdyn_formulation_acc_force_invoker() (tsid-formulation.cpp:329)
==59754==    by 0x83DE4D: boost::unit_test::ut_detail::unused boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>::invoke<void (*)()>(void (*&)()) (callback.hpp:56)
==59754==    by 0x83B0E4: boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke() (callback.hpp:89)
==59754==    by 0x6356CB0: operator() (callback.hpp:118)
==59754==    by 0x6356CB0: operator() (unit_test_monitor.ipp:41)
==59754==    by 0x6356CB0: invoke<boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<> > > (callback.hpp:42)
==59754==    by 0x6356CB0: boost::unit_test::ut_detail::callback0_impl_t<int, boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > >::invoke() (callback.hpp:89)
==59754==    by 0x6336995: operator() (callback.hpp:118)
==59754==    by 0x6336995: do_invoke<boost::scoped_ptr<boost::detail::translate_exception_base>, boost::unit_test::callback0<int> > (execution_monitor.ipp:281)
==59754==    by 0x6336995: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:885)
==59754==    by 0x63371B2: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:1211)
==59754==
==59754== 146,238 (4,512 direct, 141,726 indirect) bytes in 1 blocks are definitely lost in loss record 663 of 672
==59754==    at 0x4C2DF66: malloc (vg_replace_malloc.c:307)
==59754==    by 0x7A0356: Eigen::internal::aligned_malloc(unsigned long) (Memory.h:224)
==59754==    by 0x7A48AF: void* Eigen::internal::conditional_aligned_malloc<true>(unsigned long) (Memory.h:305)
==59754==    by 0x7A1D14: tsid::InverseDynamicsFormulationAccForce::operator new(unsigned long) (inverse-dynamics-formulation-acc-force.hpp:73)
==59754==    by 0x798ED7: tsid_formulationTest::test_contact_point_invdyn_formulation_acc_force::test_method() (tsid-formulation.cpp:534)
==59754==    by 0x798A0B: tsid_formulationTest::test_contact_point_invdyn_formulation_acc_force_invoker() (tsid-formulation.cpp:492)
==59754==    by 0x83DE4D: boost::unit_test::ut_detail::unused boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>::invoke<void (*)()>(void (*&)()) (callback.hpp:56)
==59754==    by 0x83B0E4: boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke() (callback.hpp:89)
==59754==    by 0x6356CB0: operator() (callback.hpp:118)
==59754==    by 0x6356CB0: operator() (unit_test_monitor.ipp:41)
==59754==    by 0x6356CB0: invoke<boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<> > > (callback.hpp:42)
==59754==    by 0x6356CB0: boost::unit_test::ut_detail::callback0_impl_t<int, boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > >::invoke() (callback.hpp:89)
==59754==    by 0x6336995: operator() (callback.hpp:118)
==59754==    by 0x6336995: do_invoke<boost::scoped_ptr<boost::detail::translate_exception_base>, boost::unit_test::callback0<int> > (execution_monitor.ipp:281)
==59754==    by 0x6336995: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:885)
==59754==    by 0x63371B2: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:1211)
==59754==    by 0x6356DE1: boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::unit_test::test_case const&) (unit_test_monitor.ipp:69)
==59754==
==59754== 210,344 (208,512 direct, 1,832 indirect) bytes in 1 blocks are definitely lost in loss record 667 of 672
==59754==    at 0x4C2DF66: malloc (vg_replace_malloc.c:307)
==59754==    by 0x7A0356: Eigen::internal::aligned_malloc(unsigned long) (Memory.h:224)
==59754==    by 0x7A48AF: void* Eigen::internal::conditional_aligned_malloc<true>(unsigned long) (Memory.h:305)
==59754==    by 0x7B05C2: tsid::solvers::SolverHQuadProgRT<61, 18, 71>::operator new(unsigned long) (solver-HQP-eiquadprog-rt.hpp:38)
==59754==    by 0x7A94CB: tsid::solvers::SolverHQPBase* tsid::solvers::SolverHQPFactory::createNewSolver<61, 18, 71>(tsid::solvers::SolverHQP, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (solver-HQP-factory.hxx:35)
==59754==    by 0x79D65C: tsid_formulationTest::test_invdyn_formulation_acc_force_computation_time::test_method() (tsid-formulation.cpp:687)
==59754==    by 0x79D21D: tsid_formulationTest::test_invdyn_formulation_acc_force_computation_time_invoker() (tsid-formulation.cpp:655)
==59754==    by 0x83DE4D: boost::unit_test::ut_detail::unused boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>::invoke<void (*)()>(void (*&)()) (callback.hpp:56)
==59754==    by 0x83B0E4: boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke() (callback.hpp:89)
==59754==    by 0x6356CB0: operator() (callback.hpp:118)
==59754==    by 0x6356CB0: operator() (unit_test_monitor.ipp:41)
==59754==    by 0x6356CB0: invoke<boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<> > > (callback.hpp:42)
==59754==    by 0x6356CB0: boost::unit_test::ut_detail::callback0_impl_t<int, boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > >::invoke() (callback.hpp:89)
==59754==    by 0x6336995: operator() (callback.hpp:118)
==59754==    by 0x6336995: do_invoke<boost::scoped_ptr<boost::detail::translate_exception_base>, boost::unit_test::callback0<int> > (execution_monitor.ipp:281)
==59754==    by 0x6336995: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:885)
==59754==    by 0x63371B2: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:1211)
==59754==
==59754== 210,728 (632 direct, 210,096 indirect) bytes in 1 blocks are definitely lost in loss record 668 of 672
==59754==    at 0x4C2DF66: malloc (vg_replace_malloc.c:307)
==59754==    by 0x7A0356: Eigen::internal::aligned_malloc(unsigned long) (Memory.h:224)
==59754==    by 0x7A48AF: void* Eigen::internal::conditional_aligned_malloc<true>(unsigned long) (Memory.h:305)
==59754==    by 0x5C3EF56: tsid::solvers::SolverHQuadProgFast::operator new(unsigned long) (in /home/jmouret/deps/tsid/build/libtsid.so.1.4.0)
==59754==    by 0x5C3EE9E: tsid::solvers::SolverHQPFactory::createNewSolver(tsid::solvers::SolverHQP, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (solver-HQP-factory.cpp:38)
==59754==    by 0x79D5F9: tsid_formulationTest::test_invdyn_formulation_acc_force_computation_time::test_method() (tsid-formulation.cpp:684)
==59754==    by 0x79D21D: tsid_formulationTest::test_invdyn_formulation_acc_force_computation_time_invoker() (tsid-formulation.cpp:655)
==59754==    by 0x83DE4D: boost::unit_test::ut_detail::unused boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>::invoke<void (*)()>(void (*&)()) (callback.hpp:56)
==59754==    by 0x83B0E4: boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke() (callback.hpp:89)
==59754==    by 0x6356CB0: operator() (callback.hpp:118)
==59754==    by 0x6356CB0: operator() (unit_test_monitor.ipp:41)
==59754==    by 0x6356CB0: invoke<boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<> > > (callback.hpp:42)
==59754==    by 0x6356CB0: boost::unit_test::ut_detail::callback0_impl_t<int, boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > >::invoke() (callback.hpp:89)
==59754==    by 0x6336995: operator() (callback.hpp:118)
==59754==    by 0x6336995: do_invoke<boost::scoped_ptr<boost::detail::translate_exception_base>, boost::unit_test::callback0<int> > (execution_monitor.ipp:281)
==59754==    by 0x6336995: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:885)
==59754==    by 0x63371B2: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:1211)
==59754==
==59754== 738,782 (4,512 direct, 734,270 indirect) bytes in 1 blocks are definitely lost in loss record 670 of 672
==59754==    at 0x4C2DF66: malloc (vg_replace_malloc.c:307)
==59754==    by 0x7A0356: Eigen::internal::aligned_malloc(unsigned long) (Memory.h:224)
==59754==    by 0x7A48AF: void* Eigen::internal::conditional_aligned_malloc<true>(unsigned long) (Memory.h:305)
==59754==    by 0x7A1D14: tsid::InverseDynamicsFormulationAccForce::operator new(unsigned long) (inverse-dynamics-formulation-acc-force.hpp:73)
==59754==    by 0x7A2CB2: tsid_formulationTest::StandardRomeoInvDynCtrl::StandardRomeoInvDynCtrl(double) (tsid-formulation.cpp:131)
==59754==    by 0x792535: tsid_formulationTest::test_invdyn_formulation_acc_force::test_method() (tsid-formulation.cpp:337)
==59754==    by 0x79249E: tsid_formulationTest::test_invdyn_formulation_acc_force_invoker() (tsid-formulation.cpp:329)
==59754==    by 0x83DE4D: boost::unit_test::ut_detail::unused boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>::invoke<void (*)()>(void (*&)()) (callback.hpp:56)
==59754==    by 0x83B0E4: boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke() (callback.hpp:89)
==59754==    by 0x6356CB0: operator() (callback.hpp:118)
==59754==    by 0x6356CB0: operator() (unit_test_monitor.ipp:41)
==59754==    by 0x6356CB0: invoke<boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<> > > (callback.hpp:42)
==59754==    by 0x6356CB0: boost::unit_test::ut_detail::callback0_impl_t<int, boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > >::invoke() (callback.hpp:89)
==59754==    by 0x6336995: operator() (callback.hpp:118)
==59754==    by 0x6336995: do_invoke<boost::scoped_ptr<boost::detail::translate_exception_base>, boost::unit_test::callback0<int> > (execution_monitor.ipp:281)
==59754==    by 0x6336995: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:885)
==59754==    by 0x63371B2: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:1211)
==59754==
==59754== 739,078 (4,512 direct, 734,566 indirect) bytes in 1 blocks are definitely lost in loss record 671 of 672
==59754==    at 0x4C2DF66: malloc (vg_replace_malloc.c:307)
==59754==    by 0x7A0356: Eigen::internal::aligned_malloc(unsigned long) (Memory.h:224)
==59754==    by 0x7A48AF: void* Eigen::internal::conditional_aligned_malloc<true>(unsigned long) (Memory.h:305)
==59754==    by 0x7A1D14: tsid::InverseDynamicsFormulationAccForce::operator new(unsigned long) (inverse-dynamics-formulation-acc-force.hpp:73)
==59754==    by 0x7A2CB2: tsid_formulationTest::StandardRomeoInvDynCtrl::StandardRomeoInvDynCtrl(double) (tsid-formulation.cpp:131)
==59754==    by 0x79D2AB: tsid_formulationTest::test_invdyn_formulation_acc_force_computation_time::test_method() (tsid-formulation.cpp:662)
==59754==    by 0x79D21D: tsid_formulationTest::test_invdyn_formulation_acc_force_computation_time_invoker() (tsid-formulation.cpp:655)
==59754==    by 0x83DE4D: boost::unit_test::ut_detail::unused boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>::invoke<void (*)()>(void (*&)()) (callback.hpp:56)
==59754==    by 0x83B0E4: boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke() (callback.hpp:89)
==59754==    by 0x6356CB0: operator() (callback.hpp:118)
==59754==    by 0x6356CB0: operator() (unit_test_monitor.ipp:41)
==59754==    by 0x6356CB0: invoke<boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<> > > (callback.hpp:42)
==59754==    by 0x6356CB0: boost::unit_test::ut_detail::callback0_impl_t<int, boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > >::invoke() (callback.hpp:89)
==59754==    by 0x6336995: operator() (callback.hpp:118)
==59754==    by 0x6336995: do_invoke<boost::scoped_ptr<boost::detail::translate_exception_base>, boost::unit_test::callback0<int> > (execution_monitor.ipp:281)
==59754==    by 0x6336995: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:885)
==59754==    by 0x63371B2: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:1211)
==59754==
==59754== 750,238 (4,512 direct, 745,726 indirect) bytes in 1 blocks are definitely lost in loss record 672 of 672
==59754==    at 0x4C2DF66: malloc (vg_replace_malloc.c:307)
==59754==    by 0x7A0356: Eigen::internal::aligned_malloc(unsigned long) (Memory.h:224)
==59754==    by 0x7A48AF: void* Eigen::internal::conditional_aligned_malloc<true>(unsigned long) (Memory.h:305)
==59754==    by 0x7A1D14: tsid::InverseDynamicsFormulationAccForce::operator new(unsigned long) (inverse-dynamics-formulation-acc-force.hpp:73)
==59754==    by 0x7A2CB2: tsid_formulationTest::StandardRomeoInvDynCtrl::StandardRomeoInvDynCtrl(double) (tsid-formulation.cpp:131)
==59754==    by 0x78D4D1: tsid_formulationTest::test_invdyn_formulation_acc_force_remove_contact::test_method() (tsid-formulation.cpp:208)
==59754==    by 0x78D3FF: tsid_formulationTest::test_invdyn_formulation_acc_force_remove_contact_invoker() (tsid-formulation.cpp:197)
==59754==    by 0x83DE4D: boost::unit_test::ut_detail::unused boost::unit_test::ut_detail::invoker<boost::unit_test::ut_detail::unused>::invoke<void (*)()>(void (*&)()) (callback.hpp:56)
==59754==    by 0x83B0E4: boost::unit_test::ut_detail::callback0_impl_t<boost::unit_test::ut_detail::unused, void (*)()>::invoke() (callback.hpp:89)
==59754==    by 0x6356CB0: operator() (callback.hpp:118)
==59754==    by 0x6356CB0: operator() (unit_test_monitor.ipp:41)
==59754==    by 0x6356CB0: invoke<boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<> > > (callback.hpp:42)
==59754==    by 0x6356CB0: boost::unit_test::ut_detail::callback0_impl_t<int, boost::unit_test::(anonymous namespace)::zero_return_wrapper_t<boost::unit_test::callback0<boost::unit_test::ut_detail::unused> > >::invoke() (callback.hpp:89)
==59754==    by 0x6336995: operator() (callback.hpp:118)
==59754==    by 0x6336995: do_invoke<boost::scoped_ptr<boost::detail::translate_exception_base>, boost::unit_test::callback0<int> > (execution_monitor.ipp:281)
==59754==    by 0x6336995: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:885)
==59754==    by 0x63371B2: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:1211)
==59754==
==59754== LEAK SUMMARY:
==59754==    definitely lost: 229,104 bytes in 17 blocks
==59754==    indirectly lost: 2,919,005 bytes in 1,897 blocks
==59754==      possibly lost: 296 bytes in 1 blocks
==59754==    still reachable: 72,704 bytes in 1 blocks
==59754==         suppressed: 0 bytes in 0 blocks
==59754== Reachable blocks (those to which a pointer was found) are not shown.
==59754== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==59754==
==59754== For lists of detected and suppressed errors, rerun with: -s
==59754== ERROR SUMMARY: 18 errors from 18 contexts (suppressed: 0 from 0)

Hi @jbmouret, and thanks for this report and investigation.
I totally agree, we should use more shared_ptr.
I could handle this task, but not soon, so if anyone wants to help a bit on that, this would be really welcome :)

OK, I will put it in my (long) TODO list.

Agreed. When I first implemented TSID I didn't have in mind this use-case, so I didn't take care of deallocating memory. My bad. Unfortunately now that the semester started I'm also very busy, so I don't know when I could find the time to do it. Worst case could be January for me.

@andreadelprete OK. At least I know that there is no secret deallocator :) I will try to work on this and submit a PL.

Is there a reason for not compiling in c++11 ? (14 or 17 would be even better). We do not have shared_ptr in std:: in c++98, except if we use boost.

Since of URDFDOM >= 1.0.0, we have to rely on C++11 at the Pinocchio level. So, except if @nim65s or @olivier-stasse or @andreadelprete do agree, we may go toward std::shared_ptr and C++11. But boost::shared_ptr remains a good candiate I would say.

Until this month, our TALOS was in 16.04 LTS. And by default 16.04 LTS is in C++98. We had several problems with some boost libraries such as boost::variant not behaving nicely when mixing C++98 and C++11. But all of our robots are now at least on 18.04 LTS. So I am fine with C++11.

I've moved all the pointers to shared_ptr and there is no leak anymore! (and yes, this means c++11)
=56088== LEAK SUMMARY:
==56088==    definitely lost: 0 bytes in 0 blocks
==56088==    indirectly lost: 0 bytes in 0 blocks
==56088==      possibly lost: 0 bytes in 0 blocks

https://github.com/resibots/tsid/tree/fix_leaks
I still need to have a look at the python interface, as we usually do not attempt to compile it.

It looks nice. Thanks.

I am fine with the switch to c++11

closed by #112


Add a skeletal Project Portfolio Page (PPP)

Create a skeletal version of your Project Portfolio Page (PPP).

Just the headings are enough. You can write to be added soon as placeholders for content.
PDF conversion not required.
File name (i.e., in the repo): docs/team/github_username_in_lower_case.md e.g., docs/team/goodcoder123.md

[x] Eric
[x] Zhaoqi
[x] Connor
[x] Jason
[x] Safwan

All PPP have been added to docs/team.


The command failed with an unexpected error. Here is the traceback:  argument of type 'NoneType' is not iterable

This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az aks enable-addons
Errors:
argument of type 'NoneType' is not iterable
Traceback (most recent call last):
Temp\pip-install-p8t_6awn\knack\knack\cli.py, ln 206, in invoke
azure\cli\core\commands\__init__.py, ln 603, in execute
azure\cli\core\commands\__init__.py, ln 661, in _run_jobs_serially
azure\cli\core\commands\__init__.py, ln 654, in _run_job
Local\Temp\pip-install-p8t_6awn\six\six.py, ln 693, in reraise
azure\cli\core\commands\__init__.py, ln 631, in _run_job
azure\cli\core\commands\__init__.py, ln 306, in __call__
azure-cli-core\azure\cli\core\__init__.py, ln 485, in default_command_handler
azure\cli\command_modules\acs\custom.py, ln 1844, in aks_enable_addons
azure\cli\command_modules\acs\custom.py, ln 2426, in _ensure_container_insights_for_monitoring
TypeError: argument of type 'NoneType' is not iterable

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az aks enable-addons --addons {} --resource-group {} --name {}

Expected Behavior
Environment Summary
Windows-10-10.0.18362-SP0
Python 3.6.6
Shell: cmd.exe

azure-cli 2.0.75 *

Additional Context

routing to appriopriate team

Please update to the latest cli-version, as this was a known issue in versions older than 2.2.0.
https://github.com/Azure/azure-cli/issues/11456

Thanks , This issue was fixed ,


Game crashed with Robber action

Game crashed when pressing confirm button on discard cards menu during robber phase. Proper amount of cards was selected and user had the right cards to get rid of. Error was in CatanHumanPlayer:

I believe I fixed this issue; there was a bunch of different issues with validation and I think I caught all of them; requires further testing but it should be good to go now


Use Polymer.dom when modifying the dom.

I ran into a bug where none of the dots would show up on the map. After inspecting the elements, the appended children weren't getting the Polymer styles.
To fix this, I pulled out anything polymer specific from src/center.js so you can pass in a regular HTML element or a Polymer Dom element.

Thanks, @brycereitano! It's good point

@dhrytsenko Thanks for the quick merge!


ClickHouse QueryID Issue

Hi , I have a scenario here , we need to get query ID before CH return result , because user don't know this query executed quickly or not , so we injected query ID by modifying the bytecode to override your queryID ,so that we can kill this query by accurate queryID,  but these days we upgrade CH to 0.3.2 ,we found that you have changed this code by this way(below image) , and this is a bit tricky to override queryID again. so could you please advise this for us ? and I think modify bytecode is not a good way to inject query ID....

we need to get query ID before CH return result

Perhaps you can call Statement.cancel() so that you don't have to know the query ID and kill the query manually?

emm... we don't use native jdbc(mybatis instead) , so it will be a little trouble to get statement .  : )

I see. Just did a quick search and it seems mybatis still does not support cancel.
Anyway, I think we need to enhance the driver to expose methods for setting/getting query id. Before that, I can only think of AOP to replace query id passed to Clickhouse request.query(sql, queryId).

good idea, thank you so much : )

I think there are a few issues requesting an interceptor and the ability to customize query id etc., I'll enhance the driver to expose an interface for this.

Starting from 0.3.2-patch11, you should be able to customize query ID and session ID by implementing ClickHouseRequestManager.
https://github.com/ClickHouse/clickhouse-jdbc/blob/27f8951cdc380bf1799f76efc21fc377fc6d5981/clickhouse-client/src/main/java/com/clickhouse/client/ClickHouseRequestManager.java#L16-L17

@ltl0814 Hello, I have a requirement similar to yours. I would like to ask how you use the query ID to cancel a query, and how effective it is in a distributed ClickHouse setup?

@ltl0814 Hello, I have a requirement similar to yours. I would like to ask how you use the query ID to cancel a query, and how effective it is in a distributed ClickHouse setup?

sql : kill query where query_id = xxx  on cluster xxx


Capstone Project PR

In this Milestone, I implemented the following Project requirements.

[ ] Contents of Cindy Shin's page have been personalized and the topic has been chosen Arcadia Music Fest.
[ ] The Home page and About page have been built.
[ ] Each of these pages has versions for two different screen sizes.
[ ] Mobile: up to 768px
[ ] desktop: 768px or beyond.
[ ]  The home page has a link in the menu to the about page.
[ ]  The logo in the header links to the home page.
[ ] In the mobile menu, when the user clicks the hamburger button, the mobile menu appears over the page.
[ ]  The mobile menu has a close(X) button that closes the menu.
[ ]  The section Featured Speakers has been created dynamically in JavaScript.
[ ] Have added a Time countdown by using js
[ ] and also added a see and less button for featured speakers using js
[ ]  Created a Loom video about the project. Link
[ ]  The page has been deployed by the GitHub page so anyone will be able to see the Live demo.

Hello @Ibizugbe, Thanks for reviewing and investing time.😍