Is it possible to pretrain on a different speaker?

Hi,
ForwardTacotron works very well on long articles it is just surprising and welcome. With a good dataset and a lot of training, it is incredible how robust it can get.
Two questions:

I am interested in making a TTS for a specific voice, however, I have a smaller corpus from a different speaker, which is very good in terms of vocabulary and even. In other implementations (Mozilla etc.) it is easy to pretrain the TTS using a corpus and then restore that model when kickstarting training for a new speaker. In ForwardTacotron, I am not really sure how to go about this, if even possible. Should I train Tacotron on the first speaker, or ForwardTacotron? I would like to make use of the first, smaller corpus, because I think it would greatly help with the encoder.

Regarding WaveRNN, is it true that RAW yields better results than MOLD when it comes to sound quality? I tried training it on a studio dataset and I got good results using RAW, after training for 900k steps, however one can still hear some parts where the voice is "shakier". Do you think I may achieve better results using MOLD? The dataset has no background noise, is 22050Hz and monophonic. :)

Thank you for all this work, it is just incredible how well it performs in whole pages of books!

Hi, nice to hear. To the questions:

Since we do not have a speaker embedding implemented it would be necessary to prepare both datasets using separate tacotrons trained on each. I have found though that it is possible to retrain a tacotron model that has built up attention on a different dataset (in case the second dataset is too small for the model to build attention). Once you have both datasets you could try to train ForwardTacotron on the first dataset and then retrain it on the second one - I never tried that though and no idea if it helps...

I have found it much easier to train a RAW model than MOL, i.e. the MOL models usually show large fluctuations in quality and need to be cherry-picked quite well. Personally, I could not really hear much difference between both models anyways. The shakyness is much a matter of cherry-picking the model in my experience (you could look through the top 5 models or so in tensorboard). Also, I found that the shakiness is often present for unseen words or ambigous ones.


spring-boot-starter-docker ignore 'dev' profile and uses docker-compose.yml in the project root

Hi, I saw your tweet with a link to this project. I was immediately interested in the technologies used here🙃. I'd like to help and contribute to the project as well, but I've encountered a problem when launching the project locally.
I don't understand why spring-boot-starter-docker ignores the dev profile and still uses docker-compose in the project root.
This is the console output:
2023-09-16T21:11:25.228+03:00 INFO 66991 --- [ restartedMain] com.enofex.naikan.NaikanApplication : Starting NaikanApplication using Java 20.0.2 with PID 66991 (/Users/panilya/Documents/naikan/naikan-web/target/classes started by panilya in /Users/panilya/Documents/naikan)
2023-09-16T21:11:25.232+03:00 INFO 66991 --- [ restartedMain] com.enofex.naikan.NaikanApplication : The following 1 profile is active: "dev"
2023-09-16T21:11:25.315+03:00 INFO 66991 --- [ restartedMain] .s.b.d.c.l.DockerComposeLifecycleManager : Using Docker Compose file '/Users/panilya/Documents/naikan/docker-compose.yml'
2023-09-16T21:11:26.305+03:00 INFO 66991 --- [utReader-stderr] o.s.boot.docker.compose.core.DockerCli :  Container naikan Created
2023-09-16T21:11:26.311+03:00 INFO 66991 --- [utReader-stderr] o.s.boot.docker.compose.core.DockerCli :  Container naikan Starting
2023-09-16T21:11:26.609+03:00 INFO 66991 --- [utReader-stderr] o.s.boot.docker.compose.core.DockerCli :  Container naikan Started
2023-09-16T21:11:26.610+03:00 INFO 66991 --- [utReader-stderr] o.s.boot.docker.compose.core.DockerCli :  Container naikan Waiting
2023-09-16T21:11:27.119+03:00 INFO 66991 --- [utReader-stderr] o.s.boot.docker.compose.core.DockerCli :  Container naikan Healthy

Thank you.

Great to see you here!
The configuration for the dev profile can be found here
https://github.com/enofex/naikan/blob/main/naikan-web/src/main/resources/application-dev.yml
Here you can find the configuration file: "./development/docker/compose.yml"
The docker-compose in the root is the docker-compose which will be used for the installation
curl -LO https://naikan.io/docker-compose.yml
docker-compose up -d

I didn't really know about the spring-boot-starter-docker dependency before, and it looks cool.
I'm running NaikanApplication using dev profile and it should use the compose.yml file in the development/docker directory, right? But it somehow uses docker-compose.yml in the root of the project which doesn't specify mongodb connection string, I get the following problem when Spring Boot tries to start in docker container:
org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name overviewContactServiceHandler' defined in class path resource [com/enofex/naikan/overview/contact/support/OverviewContactServiceHandler.class]:
Unsatisfied dependency expressed through constructor parameter 0: Error creating bean with name 'overviewContactMongoRepository' defined in class path resource [com/enofex/naikan/overview/contact/support/OverviewContactMongoRepository.class]:
Unsatisfied dependency expressed through constructor parameter 0:
Error creating bean with name 'mongoTemplate' defined in class path resource [com/enofex/naikan/MongoConfiguration.class]:
Unsatisfied dependency expressed through method 'mongoTemplate' parameter 0: Error creating bean with name 'mongoDatabaseFactory' defined in class path resource [org/springframework/boot/autoconfigure/data/mongo/MongoDatabaseFactoryConfiguration.class]:
Unsatisfied dependency expressed through method 'mongoDatabaseFactory' parameter 0:
Error creating bean with name 'mongo' defined in class path resource [org/springframework/boot/autoconfigure/mongo/MongoAutoConfiguration.class]: Failed to instantiate [com.mongodb.client.MongoClient]:
Factory method 'mongo' threw exception with message: Error creating bean with name 'standardMongoSettingsCustomizer' defined in class path resource [org/springframework/boot/autoconfigure/mongo/MongoAutoConfiguration$MongoClientSettingsConfiguration.class]:
Failed to instantiate [org.springframework.boot.autoconfigure.mongo.StandardMongoClientSettingsBuilderCustomizer]: Factory method 'standardMongoSettingsCustomizer'
threw exception with message:
The connection string is invalid. Connection strings must start with either 'mongodb://' or 'mongodb+srv://

Yes, the compose.yml  file will be taken be Spring as specified in the configuration. In the application-dev.yml you can find the configurations for mongodb as well:
spring:
  data:
    mongodb:
      uri: mongodb://localhost:27071/naikan?replicaSet=rs0

When you start the app with the dev profile everything should work out of the box.

Right, but Spring Boot app in Docker container falling back to default profile, however I ran it with dev profile.
2023-09-16 20:50:56 2023-09-16T17:50:56.572Z  INFO 1 --- [           main] com.enofex.naikan.NaikanApplication      : Starting NaikanApplication v0.6.0 using Java 20.0.2 with PID 1 (/BOOT-INF/classes started by root in /)
2023-09-16 20:50:56 2023-09-16T17:50:56.592Z  INFO 1 --- [           main] com.enofex.naikan.NaikanApplication      : No active profile set, falling back to 1 default profile: "default"
2023-09-16 20:50:58 2023-09-16T17:50:58.818Z  INFO 1 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Bootstrapping Spring Data MongoDB repositories in DEFAULT mode.
2023-09-16 20:50:58 2023-09-16T17:50:58.852Z  INFO 1 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Finished Spring Data repository scanning in 25 ms. Found 0 MongoDB repository interfaces.
2023-09-16 20:51:00 2023-09-16T17:51:00.340Z  INFO 1 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port(s): 8080 (http)
2023-09-16 20:51:00 2023-09-16T17:51:00.362Z  INFO 1 --- [           main] o.apache.catalina.core.StandardService   : Starting service [Tomcat]
2023-09-16 20:51:00 2023-09-16T17:51:00.363Z  INFO 1 --- [           main] o.apache.catalina.core.StandardEngine    : Starting Servlet engine: [Apache Tomcat/10.1.12]
2023-09-16 20:51:00 2023-09-16T17:51:00.571Z  INFO 1 --- [           main] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring embedded WebApplicationContext

The profile is not set, as you can the in the log. The configuration depends on the IDE you are using.
Set -Dspring.profiles.active=dev as JVM parameter.

Yes, this is the problem. The profile IS set like you said and it sees dev profile when I run NaikanApplication, this is the console output:
2023-09-16T21:11:25.228+03:00  INFO 66991 --- [  restartedMain] com.enofex.naikan.NaikanApplication      : Starting NaikanApplication using Java 20.0.2 with PID 66991 (/Users/panilya/Documents/naikan/naikan-web/target/classes started by panilya in /Users/panilya/Documents/naikan)
2023-09-16T21:11:25.232+03:00  INFO 66991 --- [  restartedMain] com.enofex.naikan.NaikanApplication      : The following 1 profile is active: "dev"
2023-09-16T21:11:25.315+03:00  INFO 66991 --- [  restartedMain] .s.b.d.c.l.DockerComposeLifecycleManager : Using Docker Compose file '/Users/panilya/Documents/naikan/docker-compose.yml'
2023-09-16T21:11:26.305+03:00  INFO 66991 --- [utReader-stderr] o.s.boot.docker.compose.core.DockerCli   :  Container naikan  Created
2023-09-16T21:11:26.311+03:00  INFO 66991 --- [utReader-stderr] o.s.boot.docker.compose.core.DockerCli   :  Container naikan  Starting
2023-09-16T21:11:26.609+03:00  INFO 66991 --- [utReader-stderr] o.s.boot.docker.compose.core.DockerCli   :  Container naikan  Started
2023-09-16T21:11:26.610+03:00  INFO 66991 --- [utReader-stderr] o.s.boot.docker.compose.core.DockerCli   :  Container naikan  Waiting
2023-09-16T21:11:27.119+03:00  INFO 66991 --- [utReader-stderr] o.s.boot.docker.compose.core.DockerCli   :  Container naikan  Healthy

But when I open naikan docker container logs, it falls back to the default profile:
2023-09-16 20:50:56 2023-09-16T17:50:56.572Z  INFO 1 --- [           main] com.enofex.naikan.NaikanApplication      : Starting NaikanApplication v0.6.0 using Java 20.0.2 with PID 1 (/BOOT-INF/classes started by root in /)
2023-09-16 20:50:56 2023-09-16T17:50:56.592Z  INFO 1 --- [           main] com.enofex.naikan.NaikanApplication      : No active profile set, falling back to 1 default profile: "default"
2023-09-16 20:50:58 2023-09-16T17:50:58.818Z  INFO 1 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Bootstrapping Spring Data MongoDB repositories in DEFAULT mode.
2023-09-16 20:50:58 2023-09-16T17:50:58.852Z  INFO 1 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Finished Spring Data repository scanning in 25 ms. Found 0 MongoDB repository interfaces.
2023-09-16 20:51:00 2023-09-16T17:51:00.340Z  INFO 1 --- [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat initialized with port(s): 8080 (http)
2023-09-16 20:51:00 2023-09-16T17:51:00.362Z  INFO 1 --- [           main] o.apache.catalina.core.StandardService   : Starting service [Tomcat]
2023-09-16 20:51:00 2023-09-16T17:51:00.363Z  INFO 1 --- [           main] o.apache.catalina.core.StandardEngine    : Starting Servlet engine: [Apache Tomcat/10.1.12]
2023-09-16 20:51:00 2023-09-16T17:51:00.571Z  INFO 1 --- [           main] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring embedded WebApplicationContext

The dev profile is used only for developing.
When you start the docker-compose.yml the published version will be used and there is no profile set.  So, the logs are correct.
When you want to start the app for developing with all infrastructure then start the app with dev, start the client and point to http://localhost:4200/
You do not have to start the docker-compose.yml in the root, this is for production use.

Deleting mongodb and openldap docker containers and running NaikanApplication again solved my problem.
Thank you.

Feel free to adjust the documentation, if you think something is unclear, thanks.


build(test): require esm for mocha testing, drop extra build steps

Closing this in favor of #209 will reopen if needed.

Closing this in favor of #209 will reopen if needed.


feat(sdk/elixir): support OpenTelemetry traceparent

:WARNING: This PR didn't test it well. The functionality may not work as expected
Add OpenTelemetry to support feature from #6835.

This is super timely! @helderco was working on this recently in https://github.com/dagger/dagger/pull/6835#issuecomment-2024241705 as you've already noticed. Anything that he can help with to get this closer to the final review & merge?

I have no bandwidth to finish this at the moment due to #6967. Will looking into this issue after finish module support. 🙇


This command line did not get the correct layout.

Changed the format from regular text to code format.

Thanks!


Add MicroTVM tutorial using the STM32F746 discovery board

Add MicroTVM tutorial using the STM32F746 discovery board
with a sample tflite model
Signed-off-by: Tom Gall<EMAIL_ADDRESS>Thanks for contributing to TVM!   Please refer to guideline https://tvm.apache.org/docs/contribute/ for useful information and tips. After the pull request is submitted, please request code reviews from Reviewers by @ them in the pull request thread.

@areusch

@tom-gall please look into the CI failure

Hey Tom, to get this to build further along in the CI, I think you can add the following line to docs/conf.py:
'../tutorials/micro'

I added this around line 168

@tom-gall please followup on @liangfu 's comment

@tom-gall please followup on @areusch 's last comments

Thanks @tom-gall @areusch @liangfu !


VS Code -> ADS in git extension

The docs still link to the VS Code docs but that's standard for a lot of the links in the app so leaving those until we decide whether it's worth updating those.
Current :

Fixed :

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.01%) to 48.209%

Files with Coverage Reduction
New Missed Lines
%

extensions/notebook/src/book/bookTreeView.ts
2
38.46%

Totals

Change from base Build<PHONE_NUMBER>:
-0.01%

Covered Lines:
14713

Relevant Lines:
28977

💛  - Coveralls


fixed typos in docs

Was reading through the docs to get started on a project, and noticed a few typos!

Thank you @ConnorLeggettQC!


connect when valid automatically

When we click connect, the second connect view should do that and only give a choice when it is not possible.

The interface changed and the login is now much simpler


[uk] Add localized Cluster Administration concept

/language uk
Work by @andygol; all I did was rebase it and split it out for review.
Preview

/close
See https://github.com/kubernetes/website/pull/48551


Add Python 3.9 and Python 3.10 to the CI test job

Closes #145

Thanks for the contribution @noahdemoes !

You're welcome @MthwRobinson!  Please let me know if I need to do anything else to get this requested merged.


pion/webrtc v2.2.26 wrong transceivers reuse, cannot re-add removed tracks on receiver side.

Your environment.

Version: Ubuntu 20.04.2 LTS 64-bit - GNOME Version 3.36.8
Browser: Google Chrome Version 91.0.4472.77 (Official Build) (64-bit)
Used pion versions:

github.com/pion/dtls/v2 v2.0.4 // indirect
github.com/pion/quic v0.1.4 // indirect
github.com/pion/rtcp v1.2.6
github.com/pion/sctp v1.7.11 // indirect
github.com/pion/srtp v1.5.2 // indirect
github.com/pion/stun v0.3.5
github.com/pion/transport v0.12.0 // indirect
github.com/pion/turn/v2 v2.0.5
github.com/pion/webrtc/v2 v2.2.26

What did you do?
First of all, thank you for your product and support!
We are using pion to implement our own SFU.
We are trying to figure out why, although Chrome's webrtc-internal stats display packet reception, negotiation, and transceiver status change are correct, the audio/video stream doesn't show when tracks are removed and then re-added.
Steps
The panelist initiates the call with only the webcam video track (to simplify debugging) and publishes it, attendees joins the call with only the microphone audio track.
The panelist's audio/video stream is then added to the attendees subscriptions and correctly displayed.
The broadcast of the panelist's audio/video stream is stopped and the attendees subscriptions are stopped.
Then the panelist's audio/video stream is added again and the subscriptions restored.
I am attaching the log of the negotiations on both the panelist and the attendant side and the stats.
We don't think this is your issue, but it would be great if we could get support to try and understand why the stream isn't being received again.
EDIT 2021-06-24
Note that:

both negotiations logs are copy/pasted from chrome://webrtc-internals and reflect the javascript side of the client.
you can also see the SDP generated by your go implementation of webrtc on calls to setRemoteDescription of logs
the add and removal of screen-sharing works correctly even when done multiple times
the attendee never remove the initial stream with one track coming from the mic
you can also see that the id of the tracks remains the same at the next addition which to my knowledge is not normal behavior
we have verified that the track.stop() method is not called for any remote track.

Obviously any information and suggestions will be welcome.
We regret not being able to share more information, we are still investigating, and will keep you updated in case we manage to isolate or solve the problem on our side or on your side.
What did you expect?
The audio/video stream should be visible again.
What happened?
The audio/video stream is not restored.
panelist-negotiations.txt
attendee-negotiations.txt

After investigating we saw that there is a difference between the behavior of the browser and that of the pion webrtc library in handling transceivers and related m-sections in the SDP.
Browser
Offerer side: new tracks or tracks added again always increase the number of m-sections in the SDP
Aswerer side: transceivers are reused whenever possible.
PION WebRTC package
Offerer side: the transceivers and relative m-sections are reused even when the transceiver has already assumed a sendonly or sendrecv state in the past.
Aswerer side (browser): same as previous.
Following the W3C specification on adding tracks (and related modification of senders and transceivers), a transceiver cannot be reused if it previously had the currentDirection state set to sendonly or sendrecv. (https://www.w3.org/TR/webrtc/#dom-rtcpeerconnection-addtrack)
Commenting out the code that iterates over the transceivers in the PeerConnection that attempt reuse of it, we were able to achieve the same behavior found during a webrtc p2p session between two browsers, with the exception that both parties always generate new transceivers and m-sections (file peerconnection.go, AddTrack function, github.com/pion/webrtc/v2 v2.2.26)
You can see the p2p behavior on this fiddle https://jsfiddle.net/yt7m5xvj/ by following these steps:

open it in two tabs
click offer on one and paste it on the other, then hit enter
copy the answer displayed on the first tab
click on "AddTrack" and then on "Remove + Add" to remove the webcam track and add it again.

Currently we cannot switch to the new release of the library and we have seen that even in the latest release currentDirection is not implemented in the RTPTransceiver structure.
Can you give us some advice on how to modify the code to get the behavior from W3C specs instead of always avoiding reusing transceivers?

I am so sorry @marco-sacchi @EdoaLive that I dropped the ball on this. I really appreciate your deep investigation on this and we are going to fix this :) I am trying to get a v3.1.0 together and this will be in it.
I am curious how ReplaceTrack would work? Something different must be happening on that path to make it all work. I would prefer if we could make transceiver reuse work though. If I can't figure out something you are right that disabling it completely is the best way to go.

Hi @marco-sacchi @Edoalive
I am not able to reproduce this. Would you mind cloning this repro and tell me what is wrong/different about my reproduce. I will continue to investigate this! https://github.com/Sean-Der/pion-webrtc-issue-1843

Also I used Version 94.0.4606.12 (Official Build) dev (64-bit)
@Antonito if you have the bandwidth would you mind trying my repro/checking if it matches the summary in https://github.com/pion/webrtc/issues/1843#issuecomment-868521403
I am going to get an old version of Chromium to try also.

Hi,
@Sean-Der from what I understood, your example matches the scenario described – the only difference I spot is the audio stuff, but it should not impact the results.
I ran the example a few times on (MacOS):

Chrome Version 92.0.4515.159 (Official Build) (x86_64)
Safari Version 15.0 (176<IP_ADDRESS>.3)
Firefox 91.0.1 (64-bit)

I didn’t detect any issue – the video played / stopped / continued as expected 🤔
Would you be able to test with a more recent Chrome version or a different browser @marco-sacchi ?
And eventually confirm the issue occurs on your end with Sean's example?
My best guess right now would be an issue with libwebrtc: might be a bug in an old version, or maybe Pion doesn't do something correctly and newer libwebrtc is less strict about it, or may be arch related (Linux vs MacOS, as I guess @Sean-Der also ran the example on a Mac?)

Just tried with Version 91.0.4472.101 (Official Build, ungoogled-chromium) (64-bit) on Debian and was not able to reproduce.
I really appreciate this bug report @marco-sacchi and @Edoalive I just am not able to reproduce. I don't want to disable Transceiver reuse unless we have to. It will really bloat signaling. Those costs really start to add up for some users.
I will leave this open for a few more days, then will resolve.
thanks!

Sorry @Sean-Der and @Antonito, I will be watching carefully during the next week.
Using your repro I have no problems: I have now tested with Chrome Version 92.0.4515.159 (Official Build) (64-bit) on Ubuntu 20.04.3 LTS x64 with GNOME Version 3.36.8.
But the difference I noticed right away, apart from the different version of the webrtc module (github.com/pion/webrtc/v3 v3.0.32 instead of github.com/pion/webrtc/v2 v2.2.26 - which is what we're using ), is that the javascript client is completely passive.
We had problems using a stream coming from the webcam (or from the screen sharing) so the negotiation started in the browser both for the start of the broadcast and for the stop (and subsequent reactivation). This means that in your repro the SDP with the offer is always generated by the Pion webrtc module, while in our case it is always generated by the browser.
These problems were present in my system, but also in the MacBook Pro with macOS Mojave Version 10.14.6 (where I tested Safari and Chrome) and in @EdoaLive's Windows 10 system with Chrome (whose version I don't remember).
I will try to integrate your test using the video track coming from the webcam.

Ah ok nice catch @marco-sacchi, sorry about the behavior differences. How should I modify the example to reproduce the behavior?
The browser should public one webcam feed, every 10 seconds publish a new offer and Pion should add/remove the track every other time?

Also no worry about the delay. You reported this and I was really slow, I moved into a new house June 20th so my life was a blur for a good month :)

You have to loop like this:

get the webcam stream with getUserMedia
generate the offer with the video track and send it to Pion (the webrtc layer of the browser will generate an negotiationneeded event in the PeerConnection object)
Pion has to add the track on the server side and send the answer to the browser
wait 5 seconds on javascript then
remove the stream from the <video> element and from the javascript PeerConnection object with removeTrack without stopping the track with stop(), otherwise you will not be able to make it start again at the next loop
the webrtc layer will trigger an negotiationneeded event to generate an offer to send to Pion
Pion receives the offer, removes the previously added track and sends the answer to the browser
wait 5 seconds on javascript, loop

Note that you must create the PeerConnection object at the beginning and that it must be destroyed only at the end of the N loops you decide to do.
I wrote it from memory, so I hope I haven't been wrong somewhere.

Hi @Sean-Der , I created a pull-request following the steps I indicated above and I was able to reproduce the behavior indicated in the first post of the issue..

@marco-sacchi That example is perfect! I am also surprised on the behavior (and don't know the right answer). If Pion gets an offer that disables a currently disabled track, I wouldn't expect it to be re-enabled automatically.
I need to make a JS Fiddle to see what happens Chrome<->Chrome. If your transceiver is disabled by the remote, can it be re-enabled by the remote?

@Sean-Der, you don't need to create a fiddle, I had already attached one in this post (https://github.com/pion/webrtc/issues/1843#issuecomment-868521403) of this issue.

Hey @marco-sacchi
Can you pull + try the repro repo. It looks like signaling does work in this case. I just had to do the folliwng

Keeping the Timestamps + SequenceNumbers contiguous
Don't unset the video elements srcObject

@Sean-Der, you can't avoid to unset the video element, this way the track continues to exist on the javascript side.
Your changes work because, from the browser's point of view, instead of sending a new track you are just stopping and resuming sending packets to a track that already exists in the peerConnection. Even though Pion has created a new transceiver, the new track is not actually used.
As you can see, on the javascript side, pc.ontrack is triggered only once, while it should fire again at the next renegotiation for the new inbound track:
10:52:46.018 Connection open
10:52:47.545 Camera started.
10:52:47.548 Signal offer to server RTCSessionDescription {type: "offer", sdp: "v=0\r\no=-<PHONE_NUMBER>033631080 2 IN IP4 <IP_ADDRESS>\r\ns…7961 label:5390b2ac-f010-431a-ad6c-ffa87d871858\r\n"}
10:52:47.551 Answer received.
10:52:47.555 New remote video track: 1db9c085-90c2-4f5d-ae7e-0f3b8cdeb774  <---
10:52:57.265 Camera stopped.
10:52:57.291 Signal offer to server RTCSessionDescription {type: "offer", sdp: "v=0\r\no=-<PHONE_NUMBER>033631080 3 IN IP4 <IP_ADDRESS>\r\ns…7961 label:5390b2ac-f010-431a-ad6c-ffa87d871858\r\n"}
10:52:57.295 Answer received.
10:52:59.569 Camera started.
10:52:59.574 Signal offer to server RTCSessionDescription {type: "offer", sdp: "v=0\r\no=-<PHONE_NUMBER>033631080 4 IN IP4 <IP_ADDRESS>\r\ns…2695 label:d37b842a-7134-4eb0-afcf-51d47367afd5\r\n"}
10:52:59.575 Answer received.
10:53:18.191 > pc.getTransceivers()
10:53:18.212 (2) [RTCRtpTransceiver, RTCRtpTransceiver]
   0: RTCRtpTransceiver
   currentDirection: "recvonly"
   direction: "recvonly"
   mid: "0"
   receiver: RTCRtpReceiver
      playoutDelayHint: null
      rtcpTransport: null
      track: MediaStreamTrack {kind: "video", id: "1db9c085-90c2-4f5d-ae7e-0f3b8cdeb774", label: "1db9c085-90c2-4f5d-ae7e-0f3b8cdeb774", enabled: true, muted: false, …}
      transport: RTCDtlsTransport {iceTransport: RTCIceTransport, state: "connected", onstatechange: null, onerror: null}
      [[Prototype]]: RTCRtpReceiver
   sender: RTCRtpSender {track: null, transport: RTCDtlsTransport, rtcpTransport: null, dtmf: null}
   stopped: false
   [[Prototype]]: RTCRtpTransceiver

   1: RTCRtpTransceiver
   currentDirection: "sendonly"
   direction: "sendrecv"
   mid: "1"
   receiver: RTCRtpReceiver
      playoutDelayHint: null
      rtcpTransport: null
      track: MediaStreamTrack {kind: "video", id: "f02f9159-c0b4-4d06-8df8-c0f7f3a7ea72", label: "f02f9159-c0b4-4d06-8df8-c0f7f3a7ea72", enabled: true, muted: true, …}
      transport: RTCDtlsTransport {iceTransport: RTCIceTransport, state: "connected", onstatechange: null, onerror: null}
      [[Prototype]]: RTCRtpReceiver
   sender: RTCRtpSender
      dtmf: null
      rtcpTransport: null
      track: MediaStreamTrack {kind: "video", id: "d37b842a-7134-4eb0-afcf-51d47367afd5", label: "Aukey-PC-LM1E Camera (****:****)", enabled: true, muted: false, …}
      transport: RTCDtlsTransport {iceTransport: RTCIceTransport, state: "connected", onstatechange: null, onerror: null}
      [[Prototype]]: RTCRtpSender
      stopped: false
   [[Prototype]]: RTCRtpTransceiver
   length: 2
[[Prototype]]: Array(0)

Note:
I opened this issue, not because Pion doesn't reuse transceivers, but because it reuses them even when it shouldn't, causing a different behavior than the p2p connection between two browsers.
Following the W3C specification on adding tracks (and related modification of senders and transceivers): "a transceiver cannot be reused if it previously had the currentDirection state set to sendonly or sendrecv. (https://www.w3.org/TR/webrtc/#dom-rtcpeerconnection-addtrack)".
Could you please check this behavior?


pub run polymer:new_entry failed

 Issue by zoechi
Originally opened as dart-lang/sdk#21512

I

checked out https://github.com/dart-lang/core-elements
created a new branch
run pub upgrade
run pub -v run polymer:new_entry test/core_list_dart_test.html
and got

FINE: Pub 1.8.0-edge.41510
FINE: Clean up system cache temp directory /home/myuser/.pub-cache/_temp.
Exception: UnimplementedError: Cannot handle non-entry_point entries for polymer transformer
#0      _createBoilerPlate (http://localhost:57930/new_entry.dart:135)
#1      main (http://localhost:57930/new_entry.dart:64)
#2      _startIsolate (dart:isolate-patch/isolate_patch.dart:237)
#3      _startMainIsolate.<anonymous closure> (dart:isolate-patch/isolate_patch.dart:192)
#4      _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:130)
Error creating files in /home/myuser/dart/dart-lang/core-elements/test
but the file test/core_list_dart_test.html was created successfully.
Dart VM version: 1.8.0-edge.41510 (Tue Nov  4 14:07:36 2014) on "linux_x64"

 Comment by jakemac53

submitted in dart-lang/sdk@d0ea6776edf2b815f5e9824571ba50c1ff471192 and released as 0.15.0+5 (forgot to put something about it in the release notes though)

Added Fixed label.

 Comment by jakemac53

https://codereview.chromium.org/683883004 pending

 Comment by jakemac53

Set owner to @jakemac53.
Removed Priority-Unassigned label.
Added Priority-Medium, Started labels.


[in_app_purchase] update gradle tool to 4.1.0

The gradle and gradle tool version have been upgraded in in_app_purchase_android https://github.com/flutter/plugins/commit/e83a6833c98f13009c73cb19cc5da5e85dbb130f, which caused a version mismatch in the in_app_purchase plugin
Pre-launch Checklist

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I read and followed the relevant style guides and ran the auto-formatter. (Note that unlike the flutter/flutter repo, the flutter/plugins repo does use dart format.)
[x] I signed the CLA.
[x] The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
[ ] I listed at least one issue that this PR fixes in the description above.
[ ] I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
[ ] I updated CHANGELOG.md to add a description of the change.
[ ] I updated/added relevant documentation (doc comments with ///).
[ ] I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test exempt.
[x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

If this mismatch is only an issue for this Android-specific test, wouldn't the better fix be to move the test into the Android plugin?

@stuartmorgan there are actually no tests in in_app_purchase, the tests that are failing are in in_app_purchase_android.
I'm actually not sure why java tests in in_app_purchase_android would be executed with in_app_purchase/example
I'm trying to figure it out now. @blasten might know.

Do we have a weird configuration left over from https://github.com/flutter/flutter/issues/81695 maybe?

I couldn't find anything that's suspicious. Seems like ./gradlew test tries to build test files in a dependency (in_app_purchase_android)

@stuartmorgan Sure
I think there might be a worse issue regarding this tho. If our example app's ./gradlew test can fail because it uses a lower gradle version, any flutter app that uses in_app_purhcase_android would potentially face the same thing when they run ./gradlew test.

The Gradle version set in a plugin only matters if you are running the plugin's java tests.
When an app is built, only one Gradle version is used (the one set by the app). (The analogy I find is, it'd would be like using two or more different Dart SDK versions to build a single app).

@blasten But why is the app-facing package's example app building the tests from the Android implementation package?

I didn't see the issue link before posting, we can continue the discussion there.


[DRAFT] HubIpaddress Bug

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

[ ] Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.

adding/removing APIs.
adding/removing properties.
adding/removing API-version.
adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

[ ] If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Please follow the link to find more details on API review process.

/azp run automation - sdk

@saisujithreddym Please fix examples as well to pass ModelValidation

Can one of the admins verify this patch?

We will be having another PR. I am closing this one


reflect: map iteration does unnecessary excessive allocation for non-pointer types

Given a map[string]*T or map[uint16]T or many other types, iterating via reflection is expensive, because we will allocate a new value on the heap each time for very many types.
In a call to reflect.MapKeys, MapIndex, MapIter.Key, MapIter.Value, the implementation includes the following code:
func copyVal(typ *rtype, fl flag, ptr unsafe.Pointer) Value {
	if ifaceIndir(typ) {
		// Copy result so future changes to the map won't change the underlying value.
		c := unsafe_New(typ)
		typedmemmove(typ, c, ptr)
		return Value{typ, c, fl | flagIndir}
	}
	return Value{typ, *(*unsafe.Pointer)(ptr), fl}
}

The ifaceIndir call returns true for very many types, including string, intXXX, uintXXX, bool, []uint8 ([]byte), etc.
This causes an allocation to be done when retrieving each map key or value.
Iterating through a large map[int][]byte for example, will cause an allocation for each key or value retrieved from the map.
Without reflection, this doesn't happen. And it need not happen.
It has the effect of causing an explosion in memory use of my benchmarks. Here, I have a map[string]*codec.stringUint64T with about 8192 entries. And I have other maps in here also.
Sample benchmark result:
Benchmark__Json_______Encode-8   	     625	   7503851 ns/op	     432 B/op	       4 allocs/op
Benchmark__Json_______Encode-8   	     297	  15948731 ns/op	  528784 B/op	   32879 allocs/op

The first result was manual using range operator, while the second result was via reflection. The number of allocation jumped from 4 to 32879 per op.

To illustrate, I ran my benchmark which includes a map[string]*codec.stringUint64T with about 8192 entries.
go test -run Nothing -tags "alltests codecgen" -bench "__Json_*En" -benchmem -benchtime 1x  | grep -v -E "^(goos:|goarch:|pkg:|PASS|ok)"

I then instrumented the copyVal function to validate it.

var copyValMap = make(map[*rtype]bool)
var copyValMapNoIface = make(map[*rtype]bool)

// copyVal returns a Value containing the map key or value at ptr,
// allocating a new variable as needed.
func copyVal(typ *rtype, fl flag, ptr unsafe.Pointer) Value {
	if ifaceIndir(typ) {
		if _, ok := copyValMap[typ]; !ok {
			println("copyVal: ifaceIndir: ", typ, typ.String())
			copyValMap[typ] = true
		}
		// Copy result so future changes to the map won't change the underlying value.
		c := unsafe_New(typ)
		typedmemmove(typ, c, ptr)
		return Value{typ, c, fl | flagIndir}
	}
	if _, ok := copyValMapNoIface[typ]; !ok {
		println("copyVal: NO   iface: ", typ, typ.String())
		copyValMapNoIface[typ] = true
	}
	return Value{typ, *(*unsafe.Pointer)(ptr), fl}
}

copyVal: ifaceIndir:  0x14d8880 string
copyVal: ifaceIndir:  0x14d7b00 int64
copyVal: ifaceIndir:  0x14d2380 []uint8
copyVal: NO   iface:  0x1521500 *codec.stringUint64T
copyVal: ifaceIndir:  0x14d8bc0 uint16
copyVal: NO   iface:  0x15213c0 *codec.TestStruc
copyVal: ifaceIndir:  0x1553820 codec.TestStruc

I then instrumented copyVal again to track the number of times that the allocation happened.
It was as expected (>32000 times).
var copyValMap = make(map[*rtype]int)
var copyValMapNoIface = make(map[*rtype]int)

// copyVal returns a Value containing the map key or value at ptr,
// allocating a new variable as needed.
func copyVal(typ *rtype, fl flag, ptr unsafe.Pointer) Value {
	if ifaceIndir(typ) {
		copyValMap[typ]++
		if copyValMap[typ]%1000 == 0 {
			println("copyVal: ifaceIndir: ", typ, typ.String(), copyValMap[typ])
		}
		// Copy result so future changes to the map
		// won't change the underlying value.
		c := unsafe_New(typ)
		typedmemmove(typ, c, ptr)
		return Value{typ, c, fl | flagIndir}
	}
	copyValMapNoIface[typ]++
	if copyValMapNoIface[typ]%1000 == 0 {
		println("copyVal: NO   iface: ", typ, typ.String(), copyValMapNoIface[typ])
	}
	return Value{typ, *(*unsafe.Pointer)(ptr), fl}
}

copyVal: ifaceIndir:  0x14d8960 string 32000
copyVal: NO   iface:  0x15215e0 *codec.stringUint64T 32000

What version of Go are you using (go version)?

$ go version
go version devel +1531192272 Mon May 27 17:58:39 2019 +0000 darwin/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE="on"
GOARCH="amd64"
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/bt/526m392x16x8y149jwx28mkm0000gp/T/go-build760118559=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

What did you expect to see?
What did you see instead?

See attached
github_golang_issue_32424_test.go.txt
Please rename the file to .go, and run as below:
mv github_golang_issue_32424_test.go.txt github_golang_issue_32424_test.go
go test -tags "32424" -run Nothing -bench 'Map(Range|ReflectIter|ReflectIndex)' -benchmem  -cpuprofile cpu.out -memprofile mem.out -memprofilerate 1

Got results:
BenchmarkMapRange-8          	   89374	     12812 ns/op	       0 B/op	       0 allocs/op
BenchmarkMapReflectIter-8    	     660	   1805001 ns/op	   16546 B/op	    1026 allocs/op
BenchmarkMapReflectIndex-8   	     576	   2146006 ns/op	   41088 B/op	    1026 allocs/op

For an operation that shouldn't have any allocations, we have a lot.
$ go tool pprof mem.out
(pprof) top 2
Showing nodes accounting for 38.34MB, 93.02% of 41.21MB total
Dropped 163 nodes (cum <= 0.21MB)
Showing top 2 nodes out of 20
      flat  flat%   sum%        cum   cum%
   22.47MB 54.52% 54.52%    22.47MB 54.52%  reflect.copyVal
   15.87MB 38.50% 93.02%    26.51MB 64.32%  reflect.Value.MapKeys

The allocation is mostly from copyVal (which I traced as being called for each time we convert a map key or value into a reflect.Value, where we call unsafe_New because interfaceIndir(t) returns true.
For Reflect using MapIndex, the call to MapKeys allocates a slice with same length as the map, which is a reason for why MapIter is better. But that (MapIter) still has allocation because of the copyVal function call.
As you see above, with normal range, there is no allocation. And the allocation is completely because the copyVal code does a seemingly unnecessary allocation for composing a reflect.Value from the map key or value.

From my understanding, the reason for this is that reflection works off interface{}, and so we MUST create a pointer for each non-pointer that is wrapped in an interface.
I am hoping there is a way to create an API that works around this. For example, we could pass in a reflect.Value to each call to MapIter.Key() or Value(), and that would be used to pass on Set the value   on each iteration?

From my understanding, the reason for this is that reflection works off interface{}, and so we MUST create a pointer for each non-pointer that is wrapped in an interface.

Correct.

I am hoping there is a way to create an API that works around this. For example, we could pass in a reflect.Value to each call to MapIter.Key() or Value(), and that would be used to pass on Set the value on each iteration?

That's a possibility. That would be a pretty ugly API though.
In general there are lots of places (not just map iteration) where reflect is slow because we're putting non-pointers in interfaces. We've historically come down on the side of cleaner API even though there might be faster ways with an uglier API.

@randall77

I am hoping there is a way to create an API that works around this. For example, we could pass in a reflect.Value to each call to MapIter.Key() or Value(), and that would be used to pass on Set the value on each iteration?

That's a possibility. That would be a pretty ugly API though.
In general there are lots of places (not just map iteration) where reflect is slow because we're putting non-pointers in interfaces. We've historically come down on the side of cleaner API even though there might be faster ways with an uglier API.

It's just that I can make a workaround for all other types because I control their location in memory i.e. for a (u)int(|8|16|32|64), float(32|64), bool, string, I can put these in a struct, slice or array or standalone variable, and make an addressable reference. For slices/array (pointers), all elements are already addressable (in general).
However, for maps, because the "slot" can be reused and reclaimed under the hood, we do not expose the allocated space and MUST always re-allocate to expose the entries as an interface{}.
It is thus the case that only map iteration has no workaround.
This is why the option of passing a reference is the only workaround specifically for maps.
I am currently looking to mimic such an interface, leveraging unsafe and cull'ing from the reflection codebase, for API below:
//- look up key, and set val (expecting settable)
//- if return false, then no entry for that key
mapIndex(mapp reflect.Value, key reflect.Value, val reflect.Value) bool
//- creates an iterator, using key and val (expecting both settable) to set the next entries on each iteration
// - if any of key or val is invalid, treat as if a _ was passed to "for ... range"
//
//- if Next() returns true, then key and val have been set to the next iteration key/value pair
//- if Next() returns false, no more entries
mapIter(key, val reflect.Value) *mapIter
(*mapIter).Next()

IMO, it is not an inelegant API. If retrofited to the current reflection API, it would look like:
// Look up key, and set its mapping into val, returning true if mapping exists
Value.MapIndexUsing(key, val reflect.Value) bool
// Create an iterator, using key and val for each key/value mapping
// Treat as _ if invalid (zero value) allowing us simulate for k, _ = range; _, v = range; k, v = range
Value.MapRangeUsing(key, val reflect.Value) *MapIter

Again, I personally do not see this as an inelegant or unweildly API.
My usecase is the go-codec encoding library: https://github.com/ugorji/go. This is the one place where code-generation is far and away more performant than reflection-based.
Others "encoders" in the space e.g. json-iterator went the way of completely re-writing the reflection package, which I think is extremely fraught with peril: see https://github.com/json-iterator/go https://github.com/modern-go/reflect2 . But they have gotten a lot of mileage doing this, gaining performance equivalent to static codebases.

We could add methods to *reflect.MapIter:
// SetKey does dst.Set(it.Key()).
func (it *MapIter) SetKey(dst Value) { ... }

(and the same for values)
I think that would provide an allocation-free path.
It seems strange to me that we'd provide this optimized path for map iteration, and not for other things that construct a Value.  Just scanning value.go, you could make a case for *Recv, Select, Convert, MapIndex, Zero, and Append.

Nice - the methods on *reflect.MapIter work nicely!
I would love to have for MapIndex also, as that is a common use-case. That is the Value.MapIndexUsing(key, dst reflect.Value) reflect.Value above.
Specifically regarding Zero, I always assumed that it would be allocation-free. I thought it would be sufficient to return a readonly non-addressable and non-settable static value as the zero value. That way, every caller gets the same one, but they cannot do much with it except set something else with it or use it readonly.
Regarding Append, there is a somewhat allocation free path with AppendSlice (as you can pass a slice of non-pointers). You can also pass Value which are addressable elements of a slice. So - there is not much of a gap here.
The remaining gaps will be the chan ones (Recv, Select) and Convert. Those are seemingly less common in typical usage (in my limited experience - YMMV). I also do not have a common use for them and do not have any good ideas of how to present it on the API.

I came by the reflect.Append case allocating a new slice value in an append loop in the last weeks and optimized it by using reflect.MakeSlice and reflectSliceValue.Index(i).Set(...)
If we can reuse the existing pointed to SliceHeader in the reflect.Value and just set the underlying len to the new length we may be able to avoid an allocation per call. Seems like this would need a new API e.g. reflect.AppendInplace(s Value, x ...Value) (no return value) since it would be a behaviour change.
If that sounds resonable I try to benchmark a prototype to confirm and open an extra proposal for a less allocating Append/AppendSlice reflect API.

@randall77 Sorry, I missed this earlier.

Zero is being handled in #33136 .
I agree that the channel ones are probably not worth worrying about, performance-wise.
Convert I'm not sure.
But Slice (and the ones that call Slice, like Append and AppendSlice) would be even more important than the map ones, I suspect. @ugorji I didn't understand how you think Append could be made allocation free - could you explain?

As @martish alluded to, a new API like AppendInPlace(s Value, x ...Value) will be needed.
In the same vein, AppendSlice() can elide the allocation caused by the call to s.Slice, by doing something akin to:
Copy(s.Slice(i0, i1), t)

to
p := (*unsafeheader.Slice)(s.ptr)
p0 := *p
p.Data = arrayAt(p0.Data, i0, typ.elem.Size(), "i < cap")
p.Len = i1 - i0
Copy(s, t)
*p = p0


Added machine readable struct for odo project list

What is the purpose of this change? What does it change?

Was the change discussed in an issue?
fixes #1361

How to test changes?
odo project list -o json

:white_check_mark: odo build 1775 completed and artifacts can be found here (for commit https://github.com/redhat-developer/odo/commit/bd3f00c18b by @surajnarwade)

/assign @mik-dass

/approve

/lgtm

@mohammedzee1000 , rebased with latest chages


Add pre-parsed qualifier based recovery at top-level and statement-level

Description:
$subject.
e.g.
public function testFunction() {
    isolated <cursor>
}

isolated <cursor>

Although this is an improvement point for the parser. This is a blocker for LS.

As a solution, we can get the first token of the node and then loop through its minute and get the qualifier list.
For this, we need to give an API with ST.


Use field name name provided by tree sitter

Then we won't have to use these error prone extract...Name functions that are language-specific.

This is waiting for the implementation of field bindings in node-tree-sitter.

https://github.com/tree-sitter/node-tree-sitter/issues/54


[BUG] A bug in Document.encode which overrides existing leaves, files and blobs

lets say we have a dict -> data = {'x': '?encodable...', 'y': '?encodable', '_leaves': {}, '_files'}
and we wrap this with data = Document(data)
now if we do data.encode() -> ...
.encode will override existing leaves, files and blobs.

Solved by #2097.


Remove delay on window focus (fixes #9544)

Wire up the focus handler unconditionally
Add new core.gitRepositoryRefreshOnWindowFocus setting
Check core.gitRepositoryRefreshOnWindowFocus in focus handler
Remove refreshOnWindowFocus param since it was unused
Document the project and config params

Description of the Change
If the user has one or more projects in the tree view with Git repositories, Atom freezes for a few seconds each time the window gains focus. The editor spends this time re-indexing Git data for all of those projects in the foreground. This makes Atom feel sluggish and unresponsive, and disrupts work flow when the user is likely to be ready to blaze ahead with an active task.
See #9544 for full discussion of the issue.
After this change, the default behavior is to no longer do this re-indexing work on window focus. A new settings checkbox can be used to enable the old behavior:

Alternate Designs
The old code had an unused Boolean parameter controlling whether the focus handler would be wired up. We could have passed the new setting as the value of that parameter. I decided that wasn't desirable because the changes could not take effect immediately when the user changed the setting. To respond to user setting changes on the fly, we need to wire up the event unconditionally and check the setting's current value when it fires. Since the old parameter would conflict with the new setting, it is removed.
Why Should This Be In Core?
Fixes an issue with Core.
Benefits

Improved responsiveness when multitasking Atom with other applications
Multiple users on #9544 reported quitting Atom or almost quitting due to this issue, so possible improvement in user outreach and retention
Multiple users on #9544 resorted to risky workarounds (deleting or renaming a project's .git folder, deactivating core packages, avoiding the use of project folders), so possible improvement in general stability if those workarounds are no longer needed

Possible Drawbacks
The old code does not document why this behavior existed, so we do not know the exact rationale for it or what might be lost by removing it. I speculate that it is to account for the possibility that the user might make changes affecting one of Atom's currently open Git repositories in an external application, which would then need to be reflected in Atom. However, this behavior imposes a serious usability penalty for all Git users, and users who do not need it have no recourse to eliminate this penalty. Furthermore, it is not a robust solution to that potential problem, as it is possible to modify a Git repo without switching focus away from Atom (for example, via a scheduled task or a remote login from another computer).
To mitigate the possibility of new issues, the problematic code is not simply removed. Rather, a setting is created so that users who need the old behavior and are willing to tolerate its drawbacks can enable it with a checkbox in the Core settings.
Applicable Issues

Fixes #9544

The latest CI error says:
Error: Expected HTMLNode not to be defined.
    at new jasmine.ExpectationResult (/Users/distiller/atom/vendor/jasmine.js:120:32)
    at newMatchersClass.toBeDefined (/Users/distiller/atom/vendor/jasmine.js:1241:29)
    at jasmine.Spec.<anonymous> (/Users/distiller/atom/node_modules/fuzzy-finder/spec/fuzzy-finder-spec.coffee:1268:131)
    at jasmine.Block.execute (/Users/distiller/atom/vendor/jasmine.js:1070:17)
    at jasmine.Queue.next_ (/Users/distiller/atom/vendor/jasmine.js:2102:31)
    at /Users/distiller/atom/vendor/jasmine.js:2092:18

If that's actually related to this PR, I'll be happy to make whatever changes are needed, but it looks spurious to me.

Hi @HebaruSan, thanks for the PR!  However, we already have a different PR fixing this in the short/medium term at #15702, and a long-term fix is in-progress at atom/git-utils#80.  For those two reasons, I'm going to close this PR.  Thanks again for your initiative and interest in Atom though!

I look forward to trying out the proper solution!


Add support for tab collections

Add support tab collections. Allows opening collections of pickers separately. For example having a separate collection for git pickers.
I tried to use tabs for indenting since that is what has been used for the most part. I also haven't written much lua, so I don't know what is considered best practices.
I also tried keeping the interface to the "tabs" mostly unchanged, which means it is unaware of the collections. Making the rest of the code base aware of this change could allow removing some code.
Also, I really like the plugin :) . Allows me to use a lot of the pickers I otherwise wouldn't because it would require too many binds.

the PR is awesome! thanks a lot :rocket:
i checked it out and it works like a charm. I have little experience with lua as well but the code looks great to me!
I'd keep it the way it is now, without the codebase knowing a lot about collections.. at least until i got into testing nvim plugins a bit more. I always feel like hell could break loose by any change without having proper test :D But as soon as I added some tests, refactoring a bit more sounds like a good idea..


10.7.0 External Database Connector Release Notes

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

@SurabhiSaraf , thank you for the PR! I merged it but missed that the CLA is not signed. Could you still sign it?


many build errors maybe resulting from different hprotoc version?

when i build, with stack, i get
04:21 PM noon ∈ dnngraph@master>stack build
caffegraph-<IP_ADDRESS>: build
Preprocessing library caffegraph-<IP_ADDRESS>...
[65 of 79] Compiling NN.DSL           ( NN/DSL.hs, .stack-work/dist/x86_64-linux/Cabal-<IP_ADDRESS>/build/NN/DSL.o )

/home/noon/dev/dnngraph/NN/DSL.hs:74:13:
    Couldn't match type ‘Maybe Utf8’ with ‘s -> Identity t’
    Expected type: ASetter s t a68 (Maybe Utf8)
      Actual type: LayerParameter -> Maybe Utf8
    Relevant bindings include
      ty :: LayerTy -> s -> t (bound at NN/DSL.hs:74:1)
    In the first argument of ‘(?~)’, namely ‘LP.type'’
    In the expression: LP.type' ?~ s (asCaffe type'')

/home/noon/dev/dnngraph/NN/DSL.hs:77:23:
    Found hole ‘_type'’ with type: LayerParameter -> Maybe Utf8
    Relevant bindings include
      l :: LayerParameter (bound at NN/DSL.hs:77:9)
      layerTy :: LayerParameter -> LayerTy (bound at NN/DSL.hs:77:1)
    In the expression: LP._type'
    In the first argument of ‘fromJust’, namely ‘(LP._type' l)’
    In the first argument of ‘(&)’, namely ‘fromJust (LP._type' l)’

/home/noon/dev/dnngraph/NN/DSL.hs:79:18:
    Couldn't match type ‘Seq NetStateRule’ with ‘s -> Identity t’
    Expected type: ASetter s t (Seq a49) (Seq a49)
      Actual type: LayerParameter -> Seq NetStateRule
    Relevant bindings include
      phase' :: b -> s -> t (bound at NN/DSL.hs:79:1)
    In the first argument of ‘(<>~)’, namely ‘include’
    In the expression: include <>~ singleton (def & phase ?~ phase'')

/home/noon/dev/dnngraph/NN/DSL.hs:79:50:
    Couldn't match type ‘Maybe Phase’ with ‘a50 -> Identity a49’
    Expected type: ASetter a50 a49 a51 (Maybe b)
      Actual type: NetStateRule -> Maybe Phase
    In the first argument of ‘(?~)’, namely ‘phase’
    In the second argument of ‘(&)’, namely ‘phase ?~ phase''’

/home/noon/dev/dnngraph/NN/DSL.hs:81:12:
    Couldn't match type ‘Seq ParamSpec’ with ‘s -> Identity t’
    Expected type: ASetter s t a48 (Seq a)
      Actual type: LayerParameter -> Seq ParamSpec
    Relevant bindings include
      param' :: [a] -> s -> t (bound at NN/DSL.hs:81:1)
    In the first argument of ‘(.~)’, namely ‘param’
    In the expression: param .~ fromList v

/home/noon/dev/dnngraph/NN/DSL.hs:85:25:
    Couldn't match type ‘Maybe DataParameter’ with ‘s -> Identity t’
    Expected type: p23 (Maybe a53) (f23 (Maybe b23)) -> s -> Identity t
      Actual type: LayerParameter -> Maybe DataParameter
    Relevant bindings include
      source' :: String -> s -> t (bound at NN/DSL.hs:85:1)
    In the first argument of ‘setF’, namely ‘data_param’
    In the expression: setF data_param source (s source'')

/home/noon/dev/dnngraph/NN/DSL.hs:85:36:
    Couldn't match type ‘Maybe’ with ‘p23 a53’
    Expected type: (a52 -> Identity (Maybe Utf8)) -> p23 a53 (f23 b23)
      Actual type: DataParameter -> Maybe Utf8
    In the second argument of ‘setF’, namely ‘source’
    In the expression: setF data_param source (s source'')

/home/noon/dev/dnngraph/NN/DSL.hs:86:18:
    Couldn't match type ‘Maybe TransformationParameter’
                   with ‘s -> Identity t’
    Expected type: p0 (Maybe a3) (f0 (Maybe b0)) -> s -> Identity t
      Actual type: LayerParameter -> Maybe TransformationParameter
    Relevant bindings include
      cropSize' :: a -> s -> t (bound at NN/DSL.hs:86:1)
    In the first argument of ‘setF’, namely ‘transform_param’
    In the expression: setF transform_param TP.crop_size

/home/noon/dev/dnngraph/NN/DSL.hs:86:34:
    Couldn't match type ‘Maybe’ with ‘p0 a3’
    Expected type: (a2 -> Identity (Maybe a)) -> p0 a3 (f0 b0)
      Actual type: TransformationParameter -> Maybe Word32
    In the second argument of ‘setF’, namely ‘TP.crop_size’
    In the expression: setF transform_param TP.crop_size

/home/noon/dev/dnngraph/NN/DSL.hs:87:29:
    Couldn't match type ‘Maybe TransformationParameter’
                   with ‘s -> Identity t’
    Expected type: p24 (Maybe a55) (f24 (Maybe b24)) -> s -> Identity t
      Actual type: LayerParameter -> Maybe TransformationParameter
    Relevant bindings include
      meanFile' :: String -> s -> t (bound at NN/DSL.hs:87:1)
    In the first argument of ‘setF’, namely ‘transform_param’
    In the expression: setF transform_param TP.mean_file (s meanFile'')

/home/noon/dev/dnngraph/NN/DSL.hs:87:45:
    Couldn't match type ‘Maybe’ with ‘p24 a55’
    Expected type: (a54 -> Identity (Maybe Utf8)) -> p24 a55 (f24 b24)
      Actual type: TransformationParameter -> Maybe Utf8
    In the second argument of ‘setF’, namely ‘TP.mean_file’
    In the expression: setF transform_param TP.mean_file (s meanFile'')

/home/noon/dev/dnngraph/NN/DSL.hs:88:16:
    Couldn't match type ‘Maybe TransformationParameter’
                   with ‘s -> Identity t’
    Expected type: p1 (Maybe a5) (f1 (Maybe b1)) -> s -> Identity t
      Actual type: LayerParameter -> Maybe TransformationParameter
    Relevant bindings include
      mirror' :: a -> s -> t (bound at NN/DSL.hs:88:1)
    In the first argument of ‘setF’, namely ‘transform_param’
    In the expression: setF transform_param TP.mirror

/home/noon/dev/dnngraph/NN/DSL.hs:88:32:
    Couldn't match type ‘Maybe’ with ‘p1 a5’
    Expected type: (a4 -> Identity (Maybe a)) -> p1 a5 (f1 b1)
      Actual type: TransformationParameter -> Maybe Bool
    In the second argument of ‘setF’, namely ‘TP.mirror’
    In the expression: setF transform_param TP.mirror

/home/noon/dev/dnngraph/NN/DSL.hs:89:19:
    Couldn't match type ‘Maybe DataParameter’ with ‘s -> Identity t’
    Expected type: p2 (Maybe a7) (f2 (Maybe b2)) -> s -> Identity t
      Actual type: LayerParameter -> Maybe DataParameter
    Relevant bindings include
      batchSize' :: a -> s -> t (bound at NN/DSL.hs:89:1)
    In the first argument of ‘setF’, namely ‘data_param’
    In the expression: setF data_param batch_size

/home/noon/dev/dnngraph/NN/DSL.hs:89:30:
    Couldn't match type ‘Maybe’ with ‘p2 a7’
    Expected type: (a6 -> Identity (Maybe a)) -> p2 a7 (f2 b2)
      Actual type: DataParameter -> Maybe Word32
    In the second argument of ‘setF’, namely ‘batch_size’
    In the expression: setF data_param batch_size

/home/noon/dev/dnngraph/NN/DSL.hs:90:18:
    Couldn't match type ‘Maybe DataParameter’ with ‘s -> Identity t’
    Expected type: p3 (Maybe a9) (f3 (Maybe b3)) -> s -> Identity t
      Actual type: LayerParameter -> Maybe DataParameter
    Relevant bindings include
      backend' :: a -> s -> t (bound at NN/DSL.hs:90:1)
    In the first argument of ‘setF’, namely ‘data_param’
    In the expression: setF data_param backend

/home/noon/dev/dnngraph/NN/DSL.hs:90:29:
    Couldn't match type ‘Maybe’ with ‘p3 a9’
    Expected type: (a8 -> Identity (Maybe a)) -> p3 a9 (f3 b3)
      Actual type: DataParameter -> Maybe Gen.Caffe.DataParameter.DB.DB
    In the second argument of ‘setF’, namely ‘backend’
    In the expression: setF data_param backend

/home/noon/dev/dnngraph/NN/DSL.hs:93:16:
    Couldn't match type ‘Maybe ConvolutionParameter’
                   with ‘s -> Identity t’
    Expected type: p (Maybe a91) (f (Maybe b)) -> s -> Identity t
      Actual type: LayerParameter -> Maybe ConvolutionParameter
    Relevant bindings include
      setConv :: ((a -> Identity (Maybe a92)) -> p a91 (f b))
                 -> a92 -> s -> t
        (bound at NN/DSL.hs:93:1)
    In the first argument of ‘setF’, namely ‘convolution_param’
    In the expression: setF convolution_param

/home/noon/dev/dnngraph/NN/DSL.hs:94:23:
    Couldn't match type ‘Maybe’ with ‘p4 a11’
    Expected type: (a10 -> Identity (Maybe a)) -> p4 a11 (f4 b4)
      Actual type: ConvolutionParameter -> Maybe Word32
    In the first argument of ‘setConv’, namely ‘CP.num_output’
    In the expression: setConv CP.num_output

/home/noon/dev/dnngraph/NN/DSL.hs:95:22:
    Couldn't match type ‘Maybe’ with ‘p5 a13’
    Expected type: (a12 -> Identity (Maybe a)) -> p5 a13 (f5 b5)
      Actual type: ConvolutionParameter -> Maybe Word32
    In the first argument of ‘setConv’, namely ‘CP.num_input’
    In the expression: setConv CP.num_input

/home/noon/dev/dnngraph/NN/DSL.hs:96:24:
    Couldn't match type ‘Maybe’ with ‘p6 a15’
    Expected type: (a14 -> Identity (Maybe a)) -> p6 a15 (f6 b6)
      Actual type: ConvolutionParameter -> Maybe Word32
    In the first argument of ‘setConv’, namely ‘CP.kernel_size’
    In the expression: setConv CP.kernel_size

/home/noon/dev/dnngraph/NN/DSL.hs:97:17:
    Couldn't match type ‘Maybe’ with ‘p7 a17’
    Expected type: (a16 -> Identity (Maybe a)) -> p7 a17 (f7 b7)
      Actual type: ConvolutionParameter -> Maybe Word32
    In the first argument of ‘setConv’, namely ‘CP.pad’
    In the expression: setConv CP.pad

/home/noon/dev/dnngraph/NN/DSL.hs:98:19:
    Couldn't match type ‘Maybe’ with ‘p8 a19’
    Expected type: (a18 -> Identity (Maybe a)) -> p8 a19 (f8 b8)
      Actual type: ConvolutionParameter -> Maybe Word32
    In the first argument of ‘setConv’, namely ‘group’
    In the expression: setConv group

/home/noon/dev/dnngraph/NN/DSL.hs:99:20:
    Couldn't match type ‘Maybe’ with ‘p9 a21’
    Expected type: (a20 -> Identity (Maybe a)) -> p9 a21 (f9 b9)
      Actual type: ConvolutionParameter -> Maybe Word32
    In the first argument of ‘setConv’, namely ‘CP.stride’
    In the expression: setConv CP.stride

/home/noon/dev/dnngraph/NN/DSL.hs:100:24:
    Couldn't match type ‘Maybe’ with ‘p10 a23’
    Expected type: (a22 -> Identity (Maybe a)) -> p10 a23 (f10 b10)
      Actual type: ConvolutionParameter -> Maybe FillerParameter
    In the first argument of ‘setConv’, namely ‘CP.bias_filler’
    In the expression: setConv CP.bias_filler

/home/noon/dev/dnngraph/NN/DSL.hs:101:26:
    Couldn't match type ‘Maybe’ with ‘p11 a25’
    Expected type: (a24 -> Identity (Maybe a)) -> p11 a25 (f11 b11)
      Actual type: ConvolutionParameter -> Maybe FillerParameter
    In the first argument of ‘setConv’, namely ‘CP.weight_filler’
    In the expression: setConv CP.weight_filler

/home/noon/dev/dnngraph/NN/DSL.hs:104:16:
    Couldn't match type ‘Maybe PoolingParameter’ with ‘s -> Identity t’
    Expected type: p (Maybe a91) (f (Maybe b)) -> s -> Identity t
      Actual type: LayerParameter -> Maybe PoolingParameter
    Relevant bindings include
      setPool :: ((a -> Identity (Maybe a92)) -> p a91 (f b))
                 -> a92 -> s -> t
        (bound at NN/DSL.hs:104:1)
    In the first argument of ‘setF’, namely ‘pooling_param’
    In the expression: setF pooling_param

/home/noon/dev/dnngraph/NN/DSL.hs:105:17:
    Couldn't match type ‘Maybe’ with ‘p12 a27’
    Expected type: (a26 -> Identity (Maybe a)) -> p12 a27 (f12 b12)
      Actual type: PoolingParameter -> Maybe PoolMethod
    In the first argument of ‘setPool’, namely ‘pool’
    In the expression: setPool pool

/home/noon/dev/dnngraph/NN/DSL.hs:106:18:
    Couldn't match type ‘Maybe’ with ‘p13 a29’
    Expected type: (a28 -> Identity (Maybe a)) -> p13 a29 (f13 b13)
      Actual type: PoolingParameter -> Maybe Word32
    In the first argument of ‘setPool’, namely ‘PP.kernel_size’
    In the expression: setPool PP.kernel_size

/home/noon/dev/dnngraph/NN/DSL.hs:107:20:
    Couldn't match type ‘Maybe’ with ‘p14 a31’
    Expected type: (a30 -> Identity (Maybe a)) -> p14 a31 (f14 b14)
      Actual type: PoolingParameter -> Maybe Word32
    In the first argument of ‘setPool’, namely ‘PP.stride’
    In the expression: setPool PP.stride

/home/noon/dev/dnngraph/NN/DSL.hs:108:17:
    Couldn't match type ‘Maybe’ with ‘p15 a33’
    Expected type: (a32 -> Identity (Maybe a)) -> p15 a33 (f15 b15)
      Actual type: PoolingParameter -> Maybe Word32
    In the first argument of ‘setPool’, namely ‘PP.pad’
    In the expression: setPool PP.pad

/home/noon/dev/dnngraph/NN/DSL.hs:111:14:
    Couldn't match type ‘Maybe InnerProductParameter’
                   with ‘s -> Identity t’
    Expected type: p (Maybe a91) (f (Maybe b)) -> s -> Identity t
      Actual type: LayerParameter -> Maybe InnerProductParameter
    Relevant bindings include
      setIP :: ((a -> Identity (Maybe a92)) -> p a91 (f b))
               -> a92 -> s -> t
        (bound at NN/DSL.hs:111:1)
    In the first argument of ‘setF’, namely ‘inner_product_param’
    In the expression: setF inner_product_param

/home/noon/dev/dnngraph/NN/DSL.hs:112:25:
    Couldn't match type ‘Maybe’ with ‘p16 a35’
    Expected type: (a34 -> Identity (Maybe a)) -> p16 a35 (f16 b16)
      Actual type: InnerProductParameter -> Maybe FillerParameter
    In the first argument of ‘setIP’, namely ‘IP.weight_filler’
    In the expression: setIP IP.weight_filler

/home/noon/dev/dnngraph/NN/DSL.hs:113:21:
    Couldn't match type ‘Maybe’ with ‘p17 a37’
    Expected type: (a36 -> Identity (Maybe a)) -> p17 a37 (f17 b17)
      Actual type: InnerProductParameter -> Maybe Word32
    In the first argument of ‘setIP’, namely ‘IP.num_input’
    In the expression: setIP IP.num_input

/home/noon/dev/dnngraph/NN/DSL.hs:114:22:
    Couldn't match type ‘Maybe’ with ‘p18 a39’
    Expected type: (a38 -> Identity (Maybe a)) -> p18 a39 (f18 b18)
      Actual type: InnerProductParameter -> Maybe Word32
    In the first argument of ‘setIP’, namely ‘IP.num_output’
    In the expression: setIP IP.num_output

/home/noon/dev/dnngraph/NN/DSL.hs:115:23:
    Couldn't match type ‘Maybe’ with ‘p19 a41’
    Expected type: (a40 -> Identity (Maybe a)) -> p19 a41 (f19 b19)
      Actual type: InnerProductParameter -> Maybe FillerParameter
    In the first argument of ‘setIP’, namely ‘IP.bias_filler’
    In the expression: setIP IP.bias_filler

/home/noon/dev/dnngraph/NN/DSL.hs:118:15:
    Couldn't match type ‘Maybe LRNParameter’ with ‘s -> Identity t’
    Expected type: p (Maybe a91) (f (Maybe b)) -> s -> Identity t
      Actual type: LayerParameter -> Maybe LRNParameter
    Relevant bindings include
      setLRN :: ((a -> Identity (Maybe a92)) -> p a91 (f b))
                -> a92 -> s -> t
        (bound at NN/DSL.hs:118:1)
    In the first argument of ‘setF’, namely ‘lrn_param’
    In the expression: setF lrn_param

/home/noon/dev/dnngraph/NN/DSL.hs:119:21:
    Couldn't match type ‘Maybe’ with ‘p20 a43’
    Expected type: (a42 -> Identity (Maybe a)) -> p20 a43 (f20 b20)
      Actual type: LRNParameter -> Maybe Word32
    In the first argument of ‘setLRN’, namely ‘local_size’
    In the expression: setLRN local_size

/home/noon/dev/dnngraph/NN/DSL.hs:120:20:
    Couldn't match type ‘Maybe’ with ‘p21 a45’
    Expected type: (a44 -> Identity (Maybe a)) -> p21 a45 (f21 b21)
      Actual type: LRNParameter -> Maybe Float
    In the first argument of ‘setLRN’, namely ‘alpha’
    In the expression: setLRN alpha

/home/noon/dev/dnngraph/NN/DSL.hs:121:19:
    Couldn't match type ‘Maybe’ with ‘p22 a47’
    Expected type: (a46 -> Identity (Maybe a)) -> p22 a47 (f22 b22)
      Actual type: LRNParameter -> Maybe Float
    In the first argument of ‘setLRN’, namely ‘beta’
    In the expression: setLRN beta

/home/noon/dev/dnngraph/NN/DSL.hs:124:25:
    Couldn't match type ‘Maybe Utf8’ with ‘a57 -> Identity a56’
    Expected type: ASetter a57 a56 a58 (Maybe Utf8)
      Actual type: FillerParameter -> Maybe Utf8
    In the first argument of ‘(?~)’, namely ‘FP.type'’
    In the second argument of ‘(&)’, namely ‘FP.type' ?~ s "constant"’

/home/noon/dev/dnngraph/NN/DSL.hs:124:52:
    Couldn't match type ‘Maybe Float’ with ‘a56 -> Identity b’
    Expected type: ASetter a56 b a59 (Maybe b34)
      Actual type: FillerParameter -> Maybe Float
    Relevant bindings include
      constant :: b34 -> b (bound at NN/DSL.hs:124:1)
    In the first argument of ‘(?~)’, namely ‘value’
    In the second argument of ‘(&)’, namely ‘value ?~ value'’

/home/noon/dev/dnngraph/NN/DSL.hs:125:23:
    Couldn't match type ‘Maybe Utf8’ with ‘a61 -> Identity a60’
    Expected type: ASetter a61 a60 a62 (Maybe Utf8)
      Actual type: FillerParameter -> Maybe Utf8
    In the first argument of ‘(?~)’, namely ‘FP.type'’
    In the second argument of ‘(&)’, namely ‘FP.type' ?~ s "gaussian"’

/home/noon/dev/dnngraph/NN/DSL.hs:125:50:
    Couldn't match type ‘Maybe Float’ with ‘a60 -> Identity b’
    Expected type: ASetter a60 b a63 (Maybe b34)
      Actual type: FillerParameter -> Maybe Float
    Relevant bindings include
      gaussian :: b34 -> b (bound at NN/DSL.hs:125:1)
    In the first argument of ‘(?~)’, namely ‘std’
    In the second argument of ‘(&)’, namely ‘std ?~ std'’

/home/noon/dev/dnngraph/NN/DSL.hs:126:21:
    Couldn't match type ‘Maybe Utf8’ with ‘a65 -> Identity a64’
    Expected type: ASetter a65 a64 a66 (Maybe Utf8)
      Actual type: FillerParameter -> Maybe Utf8
    In the first argument of ‘(?~)’, namely ‘FP.type'’
    In the second argument of ‘(&)’, namely ‘FP.type' ?~ s "xavier"’

/home/noon/dev/dnngraph/NN/DSL.hs:126:46:
    Couldn't match type ‘Maybe Float’ with ‘a64 -> Identity b’
    Expected type: ASetter a64 b a67 (Maybe b34)
      Actual type: FillerParameter -> Maybe Float
    Relevant bindings include
      xavier :: b34 -> b (bound at NN/DSL.hs:126:1)
    In the first argument of ‘(?~)’, namely ‘std’
    In the second argument of ‘(&)’, namely ‘std ?~ std'’

/home/noon/dev/dnngraph/NN/DSL.hs:130:18:
    Couldn't match type ‘Maybe Float’ with ‘s -> Identity t’
    Expected type: ASetter s t a1 (Maybe b)
      Actual type: ParamSpec -> Maybe Float
    Relevant bindings include
      lrMult' :: b -> s -> t (bound at NN/DSL.hs:130:1)
    In the first argument of ‘(?~)’, namely ‘lr_mult’
    In the expression: lr_mult ?~ value'

/home/noon/dev/dnngraph/NN/DSL.hs:131:21:
    Couldn't match type ‘Maybe Float’ with ‘s -> Identity t’
    Expected type: ASetter s t a0 (Maybe b)
      Actual type: ParamSpec -> Maybe Float
    Relevant bindings include
      decayMult' :: b -> s -> t (bound at NN/DSL.hs:131:1)
    In the first argument of ‘(?~)’, namely ‘decay_mult’
    In the expression: decay_mult ?~ value'

/home/noon/dev/dnngraph/NN/DSL.hs:134:49:
    Couldn't match type ‘Maybe AccuracyParameter’
                   with ‘a69 -> Identity b’
    Expected type: ASetter a69 b a70 (Maybe b25)
      Actual type: LayerParameter -> Maybe AccuracyParameter
    Relevant bindings include
      accuracy :: b34 -> b (bound at NN/DSL.hs:134:1)
    In the first argument of ‘(?~)’, namely ‘accuracy_param’
    In the second argument of ‘(&)’, namely
      ‘accuracy_param ?~ (def & top_k ?~ k')’

/home/noon/dev/dnngraph/NN/DSL.hs:134:74:
    Couldn't match type ‘Maybe Word32’ with ‘a71 -> Identity b25’
    Expected type: ASetter a71 b25 a72 (Maybe b34)
      Actual type: AccuracyParameter -> Maybe Word32
    In the first argument of ‘(?~)’, namely ‘top_k’
    In the second argument of ‘(&)’, namely ‘top_k ?~ k'’

/home/noon/dev/dnngraph/NN/DSL.hs:135:11:
    No instance for (Default s1) arising from a use of ‘def’
    The type variable ‘s1’ is ambiguous
    Note: there are several potential instances:
      instance Default (Maybe a)
        -- Defined in ‘Text.ProtocolBuffers.Basic’
      instance Default Int32 -- Defined in ‘Text.ProtocolBuffers.Basic’
      instance Default Int64 -- Defined in ‘Text.ProtocolBuffers.Basic’
      ...plus 58 others
    In the first argument of ‘(&)’, namely ‘def’
    In the expression: def & ty SoftmaxWithLoss
    In an equation for ‘softmax’: softmax = def & ty SoftmaxWithLoss

/home/noon/dev/dnngraph/NN/DSL.hs:136:36:
    Couldn't match type ‘Maybe DropoutParameter’
                   with ‘a73 -> Identity b’
    Expected type: ASetter a73 b a74 (Maybe b26)
      Actual type: LayerParameter -> Maybe DropoutParameter
    Relevant bindings include
      dropout :: b34 -> b (bound at NN/DSL.hs:136:1)
    In the first argument of ‘(?~)’, namely ‘dropout_param’
    In the second argument of ‘(&)’, namely
      ‘dropout_param ?~ (def & dropout_ratio ?~ ratio)’

/home/noon/dev/dnngraph/NN/DSL.hs:136:60:
    Couldn't match type ‘Maybe Float’ with ‘a75 -> Identity b26’
    Expected type: ASetter a75 b26 a76 (Maybe b34)
      Actual type: DropoutParameter -> Maybe Float
    In the first argument of ‘(?~)’, namely ‘dropout_ratio’
    In the second argument of ‘(&)’, namely ‘dropout_ratio ?~ ratio’

/home/noon/dev/dnngraph/NN/DSL.hs:137:8:
    No instance for (Default s3) arising from a use of ‘def’
    The type variable ‘s3’ is ambiguous
    Note: there are several potential instances:
      instance Default (Maybe a)
        -- Defined in ‘Text.ProtocolBuffers.Basic’
      instance Default Int32 -- Defined in ‘Text.ProtocolBuffers.Basic’
      instance Default Int64 -- Defined in ‘Text.ProtocolBuffers.Basic’
      ...plus 58 others
    In the first argument of ‘(&)’, namely ‘def’
    In the expression: def & ty ReLU
    In an equation for ‘relu’: relu = def & ty ReLU

/home/noon/dev/dnngraph/NN/DSL.hs:138:24:
    Couldn't match type ‘Maybe ConvolutionParameter’
                   with ‘a77 -> Identity b’
    Expected type: ASetter a77 b a78 (Maybe b27)
      Actual type: LayerParameter -> Maybe ConvolutionParameter
    Relevant bindings include conv :: b (bound at NN/DSL.hs:138:1)
    In the first argument of ‘(?~)’, namely ‘convolution_param’
    In the second argument of ‘(&)’, namely ‘convolution_param ?~ def’

/home/noon/dev/dnngraph/NN/DSL.hs:139:22:
    Couldn't match type ‘Maybe InnerProductParameter’
                   with ‘a79 -> Identity s6’
    Expected type: ASetter a79 s6 a80 (Maybe b28)
      Actual type: LayerParameter -> Maybe InnerProductParameter
    In the first argument of ‘(?~)’, namely ‘inner_product_param’
    In the second argument of ‘(&)’, namely
      ‘inner_product_param ?~ def’

/home/noon/dev/dnngraph/NN/DSL.hs:140:25:
    Couldn't match type ‘Maybe TransformationParameter’
                   with ‘a82 -> Identity a81’
    Expected type: ASetter a82 a81 a83 (Maybe b29)
      Actual type: LayerParameter -> Maybe TransformationParameter
    In the first argument of ‘(?~)’, namely ‘transform_param’
    In the second argument of ‘(&)’, namely ‘transform_param ?~ def’

/home/noon/dev/dnngraph/NN/DSL.hs:140:50:
    Couldn't match type ‘Maybe DataParameter’ with ‘a81 -> Identity b’
    Expected type: ASetter a81 b a84 (Maybe b30)
      Actual type: LayerParameter -> Maybe DataParameter
    Relevant bindings include data' :: b (bound at NN/DSL.hs:140:1)
    In the first argument of ‘(?~)’, namely ‘data_param’
    In the second argument of ‘(&)’, namely ‘data_param ?~ def’

/home/noon/dev/dnngraph/NN/DSL.hs:141:27:
    Couldn't match type ‘Maybe PoolingParameter’
                   with ‘a85 -> Identity s9’
    Expected type: ASetter a85 s9 a86 (Maybe b31)
      Actual type: LayerParameter -> Maybe PoolingParameter
    In the first argument of ‘(?~)’, namely ‘pooling_param’
    In the second argument of ‘(&)’, namely ‘pooling_param ?~ def’

/home/noon/dev/dnngraph/NN/DSL.hs:142:27:
    Couldn't match type ‘Maybe PoolingParameter’
                   with ‘a87 -> Identity s11’
    Expected type: ASetter a87 s11 a88 (Maybe b32)
      Actual type: LayerParameter -> Maybe PoolingParameter
    In the first argument of ‘(?~)’, namely ‘pooling_param’
    In the second argument of ‘(&)’, namely ‘pooling_param ?~ def’

/home/noon/dev/dnngraph/NN/DSL.hs:143:22:
    Couldn't match type ‘Maybe LRNParameter’ with ‘a89 -> Identity b’
    Expected type: ASetter a89 b a90 (Maybe b33)
      Actual type: LayerParameter -> Maybe LRNParameter
    Relevant bindings include lrn :: b (bound at NN/DSL.hs:143:1)
    In the first argument of ‘(?~)’, namely ‘lrn_param’
    In the second argument of ‘(&)’, namely ‘lrn_param ?~ def’

/home/noon/dev/dnngraph/NN/DSL.hs:144:11:
    No instance for (Default s13) arising from a use of ‘def’
    The type variable ‘s13’ is ambiguous
    Note: there are several potential instances:
      instance Default (Maybe a)
        -- Defined in ‘Text.ProtocolBuffers.Basic’
      instance Default Int32 -- Defined in ‘Text.ProtocolBuffers.Basic’
      instance Default Int64 -- Defined in ‘Text.ProtocolBuffers.Basic’
      ...plus 58 others
    In the first argument of ‘(&)’, namely ‘def’
    In the expression: def & ty Concat
    In an equation for ‘concat'’: concat' = def & ty Concat

--  While building package caffegraph-<IP_ADDRESS> using:
      /home/noon/.stack/setup-exe-cache/setup-Simple-Cabal-<IP_ADDRESS>-x86_64-linux-ghc-7.10.2 --builddir=.stack-work/dist/x86_64-linux/Cabal-<IP_ADDRESS>/ build lib:caffegraph --ghc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1

these seem like something is fundamentally a bit wrong.
i'm not sure if this is because the build environment isn't properly specified; or because the project is in need of some refactoring?

I'm getting the same.
`Preprocessing library caffegraph-<IP_ADDRESS>...
[59 of 79] Compiling NN.Backend.Torch.Lua ( NN/Backend/Torch/Lua.hs, dist/build/NN/Backend/Torch/Lua.o )
NN/Backend/Torch/Lua.hs:13:22:
Couldn't match type ‘[Char]’ with ‘Data.Text.Internal.Text’
Expected type: Word32 -> Data.Text.Internal.Text
Actual type: Word32 -> String
In the second argument of ‘(.)’, namely ‘show’
In the expression: Number . show
NN/Backend/Torch/Lua.hs:16:27:
Couldn't match type ‘[Char]’ with ‘Data.Text.Internal.Text’
Expected type: Data.Text.Internal.Text
Actual type: String
In the first argument of ‘String’, namely ‘s'’
In the expression: String s'
NN/Backend/Torch/Lua.hs:19:22:
Couldn't match type ‘[Char]’ with ‘Data.Text.Internal.Text’
Expected type: Float -> Data.Text.Internal.Text
Actual type: Float -> String
In the second argument of ‘(.)’, namely ‘show’
In the expression: Number . show
NN/Backend/Torch/Lua.hs:30:27:
Couldn't match expected type ‘Name’ with actual type ‘[Char]’
In the first argument of ‘funCall’, namely ‘"require"’
In the expression: funCall "require" [toLua $ L module']
In an equation for ‘require’:
require module' = funCall "require" [toLua $ L module']
NN/Backend/Torch/Lua.hs:30:48:
Couldn't match type ‘Name’ with ‘[Char]’
Expected type: String
Actual type: Name
In the first argument of ‘L’, namely ‘module'’
In the second argument of ‘($)’, namely ‘L module'’
cabal: Error: some packages failed to install:
caffegraph-<IP_ADDRESS> failed during the building phase. The exception was:
ExitFailure 1
cosmo@cosmo-T101MT:/media/cosmo/DATA/ai/ajtulloch-dnngraph-152f457$
`


What can I do to resize the grid-stack

I would like to change the position of the
 in my ready page function. But when I change and the position gets larger than the
, it does not increase the height and item is above the footer. What can I do to resize the
 ??? Thank you and im sorry about bad English.
$("#salvarCookie").click(function() {
	var $divs = $(".grid-stack-item");
	var $canvas;

	for (var i = 0; i < $divs.length; i++) {
		$canvas = $divs[i].getElementsByTagName("canvas");
		setCookie($canvas[0].id + "_data-gs-x", $divs[i].getAttribute("data-gs-x"));
		setCookie($canvas[0].id + "_data-gs-y", $divs[i].getAttribute("data-gs-y"));
		setCookie($canvas[0].id + "_data-gs-width", $divs[i].getAttribute("data-gs-width"));
		setCookie($canvas[0].id + "_data-gs-height", $divs[i].getAttribute("data-gs-height"));
	}
});

$("body").ready(function() {
	var $divs = $(".grid-stack-item");
	var $canvas;
	var $aux;
	var $id;

	var $cookie = document.cookie.split(";");
	for (var i = 0; i < $cookie.length; i++) {
		$aux = $cookie[i].split("=");

		if ($aux[0].indexOf("chart") > -1) {
			$id = $aux[0].split("_");
			$("#" + $id[0].trim()).parent().parent().attr($id[1], $aux[1]);
		}
	}
});

@fabberg How about you update the height of
 based on its contents after you add all grid-stack-items?

When I play with the height of the gridstack after init, it breaks the drag & drop feature: the positions are wrong / displaced.

Closing due to inactivity. @fabberg if you're still having a problem, please reopen and we can figure it out. Changing the height shouldn't be a problem. Hope you got it figured out!


MODULE_NOT_FOUND when including a plugin

Thank you for your awesome work, graph looks awesome! 🙌
Unfortunately, I have an issue with connecting the plugin to a project. I added the plugin to node_modules and config.js, and when I started vuepress dev targetDir --debug I received MODULE_NOT_FOUND error.
Full debug output:
debug Plugins defined at @vuepress/internal-site-config [ [Function (anonymous)], 'vuepress-plugin-catalog-graph' ]
debug Error: Cannot find module '/Users/DBoger/PycharmProjects/tlroadmap/node_modules/vuepress-plugin-catalog-graph/src/index.js'. Please verify that the package.json has a valid "main" entry
    at tryPackage (internal/modules/cjs/loader.js:318:19)
    at Function.Module._findPath (internal/modules/cjs/loader.js:700:18)
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:963:27)
    at resolve (internal/modules/cjs/helpers.js:78:19)
    at resolveModule (/Users/DBoger/PycharmProjects/tlroadmap/node_modules/@vuepress/shared-utils/lib/moduleLoader.js:55:26)
    at Object.loadModule (/Users/DBoger/PycharmProjects/tlroadmap/node_modules/@vuepress/shared-utils/lib/moduleLoader.js:60:26)
    at ModuleResolver.resolveDepPackage (/Users/DBoger/PycharmProjects/tlroadmap/node_modules/@vuepress/shared-utils/lib/moduleResolver.js:140:34)
    at Object.tryChain [as default] (/Users/DBoger/PycharmProjects/tlroadmap/node_modules/@vuepress/shared-utils/lib/tryChain.js:13:24)
    at ModuleResolver.resolve (/Users/DBoger/PycharmProjects/tlroadmap/node_modules/@vuepress/shared-utils/lib/moduleResolver.js:84:44)
    at PluginAPI.normalizePlugin (/Users/DBoger/PycharmProjects/tlroadmap/node_modules/@vuepress/core/lib/node/plugin-api/index.js:121:39)
    at PluginAPI.use (/Users/DBoger/PycharmProjects/tlroadmap/node_modules/@vuepress/core/lib/node/plugin-api/index.js:89:23)
    at /Users/DBoger/PycharmProjects/tlroadmap/node_modules/@vuepress/core/lib/node/plugin-api/index.js:146:12
    at Array.forEach (<anonymous>)
    at PluginAPI.useByPluginsConfig (/Users/DBoger/PycharmProjects/tlroadmap/node_modules/@vuepress/core/lib/node/plugin-api/index.js:145:19)
    at PluginAPI.use (/Users/DBoger/PycharmProjects/tlroadmap/node_modules/@vuepress/core/lib/node/plugin-api/index.js:107:12)
    at App.applyUserPlugins (/Users/DBoger/PycharmProjects/tlroadmap/node_modules/@vuepress/core/lib/node/App.js:194:8) {
  code: 'MODULE_NOT_FOUND',
  path: '/Users/DBoger/PycharmProjects/tlroadmap/node_modules/vuepress-plugin-catalog-graph/package.json',
  requestPath: 'vuepress-plugin-catalog-graph'
}
warning An error was encountered in plugin "vuepress-plugin-catalog-graph"

I also encountered this error when using<EMAIL_ADDRESS>After analysis, I suspect that the author renamed the source code directory src to lib, but did not update the configuration.
So I changed the configuration manually:

Edit the file node_modules/vuepress-plugin-catalog-graph/package.json
Change "main": "src/index.js" to "main": "lib/index.js".

Finally I managed to see this interesting directory diagram. But it seems that my site has too many directories and it takes 3 minutes to render.

Thanks for posting and answering the issue! The problem should be fixed in the latest release.


Allowing others to connect to Timeplus Proton via mysql client/JDBC

Use case

Although Timeplus team provides some drivers for different tools/languages, in some cases, we cannot add the Timeplus integration/driver to the 3rd party system. One example is AWS QuickSight.
While querying Timeplus historical data, we should allow the users to use MySQL client/lib to connect to Timeplus databases. Comparing to Postgresql, ClickHouse provides much better compatibility support on mySql protocol. We should leverage such code from ClickHouse community to improve the interoperability for Timeplus for other data engineering tools.
Describe the solution you'd like

Restore and enhance the mysql protocol support in Timeplus
Describe alternatives you've considered

Use Timeplus JDBC, ODBC or Go/python driver to talk to 8463, 8123, or 9000 port. But still there are some cases using MySQL port/protocol is preferred
Additional context

"+1, our use case requires integration with various third-party data analysis platforms. While native support would be ideal, most third-party platforms support PostgreSQL/MySQL connection interfaces. I believe building a MySQL/PostgreSQL interface will sufficiently meet most use cases. Additionally, Node.js can utilize existing MySQL/PostgreSQL packages to facilitate connections to Timeplus."


Removed django-polymorphic dependency

Bravo, bravissimo!!

thanks it was pretty easy
I think it won't be hard to do it on GeoNode as well
On Tue, Jun 28, 2016 at 4:46 PM, Ariel Núñez<EMAIL_ADDRESS>wrote:

Bravo, bravissimo!!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/cga-harvard/HHypermap/pull/66#issuecomment-229177991,
or mute the thread
https://github.com/notifications/unsubscribe/AAJDnCn5DTSzmOBZR1rcBTQ_n79ZlJoLks5qQYg_gaJpZM4I_jCJ
.

--
Paolo Corti
Geospatial software developer
web: http://www.paolocorti.net
twitter: @capooti
skype: capooti