Max pool grad grad

Adds gpu and cpu kernels for max pool grad. Supports NHWC and NCHW layouts for gpu kernel and only NHWC for cpu kernel. Additionally registers gradient for python MaxPoolGradGrad which is just MaxPoolGrad. Registers gradient for python AvgPoolGrad which is AvgPool evaluated on top_diff.
Continuation of #6299

Can one of the admins verify this patch?

I signed it!

I did some refactoring for MaxPoolingOp which now uses functors and templates and registers kernels using TF_CALL_*. Since currently there more kernels for gpu then cpu, functors are not generalized to devices. Also adding double required a minor tweak to stream_executor (merely duplicating methods for double). I also added python tests with double now. This should fix #547
I also updated registered ops to use more general type - realnumbertype. Note, since I am not using default type for T ops compatibility test fails. Therefore, I have not updated yet ops.pbtxt.
I also would like to add MaxPool3dGradGrad (currently I added only forward declaration for it).
As this pull request is getting quite big, I would appreciate some comments.

I updated 3d kernels. Cpu kernel supports only NHWC and gpu kernel supports both. Currently, python tests for 3d pooling check only NHWC because gpu kernels for pooling and pooling grad only work with this format.
Someone can correct me if I am wrong, but cudnn 5 supports both formats of tensors (NHWC and NCHW). However, both pooling 2d and 3d kernels with cudnn backend always convert tensors from NHWC to NCHW format.

This is really nice @aam-at: we're waiting for Benoit to do an initial review of this code (he's been on vacation the past week or so).

I dropped commit changing ops.pbtxt which required rebase.

Any update on reviewing this?

@vrv @benoitsteiner max pool grad grad definitely looks like some nice changes, would appreciate the review + merge!

I'll kick off a test anyway, but will wait for @benoitsteiner to review.
@tensorflow-jenkins test this please

The build was broken due to the changes in the upstream (191658d54f90ac03c15b339326129cd52d1f56a3). It is a bit confusing that testing is performed after merging with upstream, though, quite reasonable.
I updated pooling with doubles to call new cudnn loading mechanism. So build should be successful now. @vrv Can you rerun tests again?

@tensorflow-jenkins test this please
(I don't know the status of our builds right now, so just trying anyway since it's the weekend and the load is low)

Looks like the sanity check is failing:
=== Sanity check step 3 of 6: do_buildifier (buildifier check) ===
Running do_buildifier on 157 files
tensorflow/core/kernels/BUILD # listsort unsafesort sort:tf_kernel_library.hdrs
buildifier took 0 s
FAIL: buildifier found errors and/or warnings in above BUILD files.
buildifier suggested the following changes:
2648d2647
<         "pooling_ops_common.h",
2649a2649

    "pooling_ops_common.h",

Please fix manually or run buildifier  to auto-fix.

Buildifier requires sorted list of headers and sources. So I fixed that. It's my
first pull request to tensorflow, so I am a bit confused with the requirements
for various tests. Thanks, @vrv!

@tensorflow-jenkins test this please
@gunan one thing that would be cool would be to have the sanity checks run automatically when users push their PRs -- but then we'd control the rest of the testing.

@aam-at this is a pretty epic first PR to TensorFlow, so thank you for your patience :)

Tests are passing, except for macos. I don't have access to macos and I am not
sure why the build is failing. Thank you for your patience too, @vrv!

I think it's a infrastructure failure, the fact that the other tests pass suggests this is ready for review!

I think this can be an issue in build files. But bazel 0.4.3 has a bug in exception propagation, which make us see unhelpful messages. I will upgrade what I can access and rerun tests.

Jenkins, test this please

All tests are passing now. Thanks for the help! I will wait for review now.

ping for @benoitsteiner for this week.

@vrv @benoitsteiner Bumping this item since last post was 10 days ago. :-)

@vrv @benoitsteiner any update on this?

@andydavis1 or @rmlarsen any takers? :)   I am swamped with a lot of other things :(

@rmlarsen, do you have time to look at this change?

I'll take a look a this sometime next week.

@aam-at what's the status of this?

@jlebar would you please review the stream executor changes in this PR?

@martinwicke It implements MaxPoolingGradGrad kernels for CPU and GPU. Tests are passing on my machine.

@aam-at Thanks for the updates. Could you please rebase to resolve the conflicts and address the remaining comments.

@rmlarsen I have finished rebase. One commit was dropped, since TensorFormat handles now 5d tensors. Regarding mask parameter, I am not sure if we should rename this parameter because it can introduce further confusion:

some kernels were borrowed from caffe
not clear how to rename NoMask methods.

There are still (or again) conflicts. @rmlarsen if you can resolve the naming issues, we can move this PR along.

@aam-at OK, let's stick with mask then.

(if this is the last sticking point, make sure to update your review, and I'll switch to just caring about the tests)

@aam-at please resolve the conflict so we can test this more thoroughly.

@rmlarsen I did rebase again. Currently, there are no conflicts, so you can run the tests.

@aam-at Thanks!

@tensorflow-jenkins test this please

@aam-at it looks like there are some broken tests (backwards compatibility and XLA pooling tests) that need attention.

@rmlarsen I fixed backward compatibility tests. Xla pooling ops test should be also fixed.

@tensorflow-jenkins test this please

@aam-at Excellent. Thank you for this large contribution!

@vrv @rmlarsen Thank you for the help!

@aam-at it appears that the two tests:
_testMaxPoolGradGradSamePadding2_1(data_format, use_gpu)
and
_testMaxPoolGradGradSamePadding3_1(data_format, use_gpu)
are flaky when use_gpu is True, e.g.:
Traceback (most recent call last):
File "/usr/grte/v4/k8-linux/lib/python2.7/unittest/case.py", line 331, in run
testMethod()
File "/build/work/0bfa20861d2fc543528291b5513e5ecb/google3/runfiles/google3/third_party/tensorflow/python/kernel_tests/pooling_ops_test.py", line 1293, in testMaxPoolGradGrad
self._testMaxPoolGradGradSamePadding2_1(data_format, use_gpu)
File "/build/work/0bfa20861d2fc543528291b5513e5ecb/google3/runfiles/google3/third_party/tensorflow/python/kernel_tests/pooling_ops_test.py", line 1258, in _testMaxPoolGradGradSamePadding2_1
use_gpu=use_gpu)
File "/build/work/0bfa20861d2fc543528291b5513e5ecb/google3/runfiles/google3/third_party/tensorflow/python/kernel_tests/pooling_ops_test.py", line 813, in _ConstructAndTestSecondGradient
self.assertLess(err, err_tolerance)
File "/usr/grte/v4/k8-linux/lib/python2.7/unittest/case.py", line 932, in assertLess
self.fail(self._formatMessage(msg, standardMsg))
File "/build/work/0bfa20861d2fc543528291b5513e5ecb/google3/runfiles/google3/testing/pybase/basetest.py", line 1205, in fail
return super(TestCase, self).fail(self._formatMessage(prefix, msg))
File "/usr/grte/v4/k8-linux/lib/python2.7/unittest/case.py", line 412, in fail
raise self.failureException(msg)
AssertionError: 1.99932861328125 not less than 0.01
Perhaps there's a bug for padding is SAME? Do you have any idea what the underlying cause might be?

The problem was caused by a race due to using buffer forwarding instead of allocation in MaxPoolingGradGradOp(). I'll submit a fix.

@rmlarsen It was night in my timezone. Thanks for the fix. I added forward_input_or_allocated_output in c1b6aa4b6bbb2e80e228b3ecb9f2877f4e5dc26a. Shouldn't we replace buffer forwarding to allocating output for 3d pooling grad grad too? I am actually not sure why forward_input_or_allocated_output creates race conditions.


update go-topaz-ui:0.1.10

fixes pagination on the relations list

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-6.0%) to 20.65%

Totals

Change from base Build<PHONE_NUMBER>:
-6.0%

Covered Lines:
1753

Relevant Lines:
8489

💛  - Coveralls


Rename json to jsonDecoder

This avoids a common name clash that shadows the implicit and makes the
library more foreboding to new Scala users.
Fixes #599.

👍 , merging.


Minor fixes for the README.md

I've updated the section about the image variants (and corrected the letter-casing there) as the one for sphinx-doc:latex was a bit too complicated.

Thank you @zerok!


"No tsconfig for current file" error when working with Angular2.

Steps to reproduce:

Create a new Angular2 project with Angular cli (ng new dirName)
Edit some TS file inside src/app

Among other things, there will be no lint.

My bad, looks like it has problems with this:
https://github.com/TypeStrong/atom-typescript/issues/1080#issuecomment-253991456


-s, --separate not working

the command -s doesn't create a buffer.bin file from the included mesh in the obj file.
example obj file

hmm seems like the order of the commands are important ..

Order shouldn't matter, can you paste the command line you were using that caused the problem?

Actually I think it's correct that .glb files are self-contained and don't support -s.

Actually I think it's correct that .glb files are self-contained and don't support -s.

I just checked with @lilleyse, glb files can be separate as well, so this is a bug if order matters.

glb files can be separate as well

Interesting.  I believe it, I guess nothing prevents it.  We don't have a single sample of it, anywhere in Cesium or Khronos published sample models, as far as I know.
Anyway I'm re-opening this, for the command-line order problem as described by @mramato.

So I think this behavior is actually expected. The shaders/textures are still written separately but the geometry buffer is embedded in the binary body of the glb. A separate .bin doesn't offer any advantage for binary gltf, so the tool just doesn't handle it (speaking of gltf-pipeline here).
I also checked that the order of commands doesn't matter.


Add naming test for ForbiddenVoid rule

This adds tests to reproduce issue #1642

Codecov Report

Merging #1740 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #1740   +/-   ##
=========================================
  Coverage     75.64%   75.64%
  Complexity     1835     1835
=========================================
  Files           332      332
  Lines          5531     5531
  Branches       1009     1009
=========================================
  Hits           4184     4184
  Misses          807      807
  Partials        540      540

Continue to review full report at Codecov.

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

I don't know what problem CodeFactor has. There's no trailing whitespace there.

Not even in the testing code? It look wierd at github though.


Display title in mobile view

Currently the interview's title is hidden in mobile view. This seems to be an effort to make room for the dropdown menu in the header.
If we shrink the title's font-size, we can still display it while leave enough room for the menu.

Current version:

If display in full size:

If display in shrunken size:

Can we choose to hide the logo instead of having to make the title smaller? If we can make that choice it'd probably be a bit better, otherwise the smaller title is okay.

How about this - it's in full size but without being "bold":


clipboard broken on fresh build

Describe the bug
clipboard doesn't work
To Reproduce
Steps to reproduce the behavior:
Build software via https://github.com/FreeRDP/FreeRDP/wiki/Compilation for debian
https://github.com/FreeRDP/FreeRDP/wiki/Compilation
./tmp/opt/freerdp-nightly/bin/xfreerdp +clipboard /u:my-username /v:remotehost.net /w:1400 /h:1000 /drive:schemas,/tmp/schemas
Expected behavior
Select text in application, copy and it should be accessible from my linux desktop when I chose paste or middle click paste.
** Application details

Version of FreeRDP
./tmp/opt/freerdp-nightly/bin/xfreerdp --version
This is FreeRDP version 2.0.0-dev4 (d0612151f)

Command line used
./tmp/opt/freerdp-nightly/bin/xfreerdp +clipboard /u:my-username /v:remotehost.net /w:1400 /h:1000 /drive:schemas,/tmp/schemas

output of /buildconfig
This is FreeRDP version 2.0.0-dev4 (d0612151f)
Build configuration: BUILD_TESTING=OFF BUILTIN_CHANNELS=ON HAVE_AIO_H=1 HAVE_EXECINFO_H=1 HAVE_FCNTL_H=1 HAVE_INTTYPES_H=1 HAVE_JOURNALD_H=TRUE HAVE_MATH_C99_LONG_DOUBLE=1 HAVE_POLL_H=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK=ON HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIB=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK_SYMBOL= HAVE_SYSLOG_H=1 HAVE_SYS_EVENTFD_H=1 HAVE_SYS_FILIO_H= HAVE_SYS_MODEM_H= HAVE_SYS_SELECT_H=1 HAVE_SYS_SOCKIO_H= HAVE_SYS_STRTIO_H= HAVE_SYS_TIMERFD_H=1 HAVE_TM_GMTOFF=1 HAVE_UNISTD_H=1 HAVE_XI_TOUCH_CLASS=1 WITH_ALSA=ON WITH_CCACHE=ON WITH_CHANNELS=ON WITH_CLIENT=ON WITH_CLIENT_AVAILABLE=1 WITH_CLIENT_CHANNELS=ON WITH_CLIENT_CHANNELS_AVAILABLE=1 WITH_CLIENT_COMMON=ON WITH_CLIENT_INTERFACE=OFF WITH_CUPS=ON WITH_DEBUG_ALL=OFF WITH_DEBUG_CAPABILITIES=OFF WITH_DEBUG_CERTIFICATE=OFF WITH_DEBUG_CHANNELS=OFF WITH_DEBUG_CLIPRDR=OFF WITH_DEBUG_DVC=OFF WITH_DEBUG_KBD=OFF WITH_DEBUG_LICENSE=OFF WITH_DEBUG_MUTEX=OFF WITH_DEBUG_NEGO=OFF WITH_DEBUG_NLA=OFF WITH_DEBUG_NTLM=OFF WITH_DEBUG_RAIL=OFF WITH_DEBUG_RDP=OFF WITH_DEBUG_RDPDR=OFF WITH_DEBUG_RDPEI=OFF WITH_DEBUG_REDIR=OFF WITH_DEBUG_RFX=OFF WITH_DEBUG_RINGBUFFER=OFF WITH_DEBUG_SCARD=OFF WITH_DEBUG_SND=OFF WITH_DEBUG_SVC=OFF WITH_DEBUG_SYMBOLS=OFF WITH_DEBUG_THREADS=OFF WITH_DEBUG_TIMEZONE=OFF WITH_DEBUG_TRANSPORT=OFF WITH_DEBUG_TSG=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_WND=OFF WITH_DEBUG_X11=OFF WITH_DEBUG_X11_CLIPRDR=OFF WITH_DEBUG_X11_LOCAL_MOVESIZE=OFF WITH_DEBUG_XV=OFF WITH_DIRECTFB=OFF WITH_DSP_EXPERIMENTAL=OFF WITH_DSP_FFMPEG=ON WITH_EVENTFD_READ_WRITE=1 WITH_FAAC=OFF WITH_FAAD2=OFF WITH_FFMPEG=TRUE WITH_FFMPEG=TRUE WITH_GFX_H264=ON WITH_GPROF=OFF WITH_GSM=OFF WITH_GSSAPI=OFF WITH_GSTREAMER_0_10=ON WITH_GSTREAMER_1_0=ON WITH_ICU=OFF WITH_IPP=OFF WITH_JPEG=OFF WITH_LAME=OFF WITH_LIBRARY_VERSIONING=ON WITH_LIBSYSTEMD=ON WITH_MACAUDIO=OFF WITH_MACAUDIO=OFF WITH_MACAUDIO_AVAILABLE=0 WITH_MANPAGES=ON WITH_MBEDTLS=OFF WITH_OPENH264=OFF WITH_OPENSLES=OFF WITH_OPENSSL=ON WITH_OSS=ON WITH_PAM=ON WITH_PCSC=ON WITH_PROFILER=OFF WITH_PULSE=ON WITH_SAMPLE=OFF WITH_SANITIZE_ADDRESS=ON WITH_SANITIZE_ADDRESS_AVAILABLE=1 WITH_SANITIZE_MEMORY=OFF WITH_SANITIZE_MEMORY=OFF WITH_SANITIZE_MEMORY_AVAILABLE=0 WITH_SANITIZE_THREAD=OFF WITH_SANITIZE_THREAD=OFF WITH_SANITIZE_THREAD_AVAILABLE=0 WITH_SERVER=ON WITH_SERVER_CHANNELS=ON WITH_SERVER_INTERFACE=ON WITH_SMARTCARD_INSPECT=OFF WITH_SSE2=ON WITH_THIRD_PARTY=OFF WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK_AVAILABLE=0 WITH_WAYLAND=ON WITH_X11=ON WITH_X264=OFF WITH_XCURSOR=ON WITH_XDAMAGE=ON WITH_XEXT=ON WITH_XFIXES=ON WITH_XI=ON WITH_XINERAMA=ON WITH_XKBFILE=ON WITH_XRANDR=ON WITH_XRENDER=ON WITH_XSHM=ON WITH_XTEST=ON WITH_XV=ON WITH_ZLIB=ON
Build type:          RelWithDebInfo
CFLAGS:              -g -O2 -fdebug-prefix-map=/home/colin/build/FreeRDP=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -Wall -Wno-unused-result -Wno-unused-but-set-variable -Wno-deprecated-declarations -fvisibility=hidden -Wimplicit-function-declaration -Wredundant-decls -g -fsanitize=address -fsanitize-address-use-after-scope -fno-omit-frame-pointer

Compiler:            GNU, 8.2.0
Target architecture: x64

OS version connecting to

Windows Server 2012 R2

If available the log output from a run with /log-level:trace

Desktop (please complete the following information):

OS: debian
Version sid / buster

A trace log gzipped but with personal information removed
trace-log.gz

@drocsid Seems I need some additional info regarding this and #4896
I can see you have started /tmp/opt/freerdp-nightly/bin/xfreerdp instead of /opt/freerdp-nightly/bin/xfreerdp which is the default path used by the nightly package build (I assume you used that one?)
If you didn't install it there might be issues with parts of the required libraries not being found.

Hi @akallabeth ,
I tried this 3X yesterday.
First with the debian package provided in debian buster.
Then with a daily package found on your build server.
Finally I built the daily because the one on your build server https://ci.freerdp.com/job/freerdp-nightly-binaries/ was not a daily but built a week ago. It looked like changes related to the clipboard had been pushed to git recently but not in the daily build since it hasn't been built there in a week.
I mentioned this in the #freerdp irc channel.
The final example I built the daily as explained above:
Steps to reproduce the behavior:
Build software via https://github.com/FreeRDP/FreeRDP/wiki/Compilation for debian
https://github.com/FreeRDP/FreeRDP/wiki/Compilation

I used the debian package builder but i ran on the compiled binary...

@drocsid And you are sure clipboard redirection allowed by the server you connect to?

@drocsid FYI: Did a fresh build on my debian stretch today, clipboard is working flawlessly against windows 7, 8, 81. and 10

@akallabeth I wasn't aware that clipboard redirection could be disabled by the server. Then how do we check the windows server 2012 configuration to see if it's enabled or not?

https://social.technet.microsoft.com/Forums/Azure/en-US/778e1cb3-f3d0-4143-9b03-67a50cb3a3de/windows-2012r2-remoteapp-amp-clipboard-redirection-doesnt-work?forum=winserverTS suggests that there is a gateway config that would define this policy. I'm not sure I have the authority to check it or how to do so. If you have a suggestion if I can check it from the host or if it requires greater AD access, I can check it if possible.

@drocsid sorry, missed these posts.
Check Computer Configuration -> Administrative templates -> Windows components -> Remote Desktop Session Host in gpedit.msc

Closing this, assuming it is the configuration error.
Reopen/create a new issue if it is something else.

@drocsid sorry, missed these posts.
Check Computer Configuration -> Administrative templates -> Windows components -> Remote Desktop Session Host in gpedit.msc

Thanks for sharing that. I will double check, but I assume you're correct that it's a configuration issue. Sorry for my lack of knowledge regarding that.


scripts: add gpg key for yyforyongyu [skip ci]

add my key to the signing process

@coderabbitai review


"unbounded" space should be recommended for "immersive-ar" sessions

Right now, Babylon.js is discouraging use of the "unbounded" reference space in "immersive-ar" sessions.  While the unbounded space will be most useful across AR phones/tablets and AR headsets once the anchors module has shipped, it is already useful on devices like HoloLens 2, as it's the only space that enables tagalong content to continue rendering when the user walks through an untracked hallway into a new room.
https://github.com/BabylonJS/Babylon.js/blob/cab0386275b2de037e192f715489cd3f2654e35e/src/XR/webXRExperienceHelper.ts#L105

Thanks! Will change that very soon


Don't percent-encode unreserved mark characters for directory listing links

Description

Previously we were percent-encoding the whole file and directory entry links when listing a directory regardless if those characters can be allowed to be in a URI "as is".
This PR prevents percent-encoding the following characters (a.k.a unreserved marks): _-!.()*/'~
https://www.ietf.org/rfc/rfc2396.txt
Related Issue

https://github.com/static-web-server/static-web-server/issues/332#issuecomment-2075858645
Motivation and Context

Improve directory listing
How Has This Been Tested?

Functional testing and integration tests adjusted accordingly.
Screenshots (if appropriate):

Performance wise I do not see any significant changes.

@palant for the feedback. Yes, I was too fast when looking at and missing some details.
Definitely, we can do it better!


chore: Version chrome

so we can tell if a certain version breaks something, and can take the version bump thru our process
will also help in saying "this is the version we work with"

need to figure this out some more


Fix getting list of core ids for each chip.

Currently we are getting list of incorrect core ids on multi chip
systems with more number of cores. This patch fixex this issue by
using pythonic way of forming the list of core ids.
Signed-off-by: Pridhiviraj Paidipeddi<EMAIL_ADDRESS>

@stewart-ibm Some how we missed this patch in PR #177 . Can you please merge this one. Thanks.


Translated using Weblate (Italian)

Currently translated at 85.0% (114 of 134 strings)
Restored from Weblate 2.4 MySQL database

Refer to this link for build results (access rights to CI server needed):
http://jenkins.terasology.org/job/TerasologyPRs/342/
Hooray Jenkins reported success with all tests good!


Change default branch to development

If we're going to do most development on the development branch, could we make it the default branch when you land on the github page?
(In case it's still up for discussion, I'd vote to do development on master, though)

My opinion is that people reading the MiAIRR manuscript, and going to the GitHub page, should by default see the latest released version of MiAIRR. And if they clone the repository, the master (or default branch), also by default should be the latest released version. All development, intermediate changes, and etc., should be kept on a separate branch so as not to confuse people.
That's just my preference though. This hasn't been "decided" in any way, and we certainly should discuss in a larger context. My underlying concern is that we don't have a coordinated documentation design for the AIRR Community. You will note that no URL was provided in the MiAIRR manuscript, just an email address. The AIRR Community website is just a redirect to SFU, and we don't have much control over that. Do we use readthedocs even though it is somewhat python oriented, and may not be the best way to describe all docs for the AIRR Community? Are we using DOI's created on zenodo for releases? Should we setup our own web server? Right now it feels that GitHub is the current source of truth, and people are going to get directed here for docs, templates, and etc., until we have an overall strategy in place.

I find it very surprising to land on a GitHub page for a repository and not see the latest commit for the latest development.  It's quite unusual for a GitHub page to point to a release.  Consumers/users of the AIRR standards should view the published documentation (soon to be at docs.airr-community.org) and install released software using common package managers (e.g. pip/PyPI, CRAN, Maven, etc).  People should really only be going to the GitHub page if they're interested in contributing to development, to report bugs, or to see what's been going on recently.

That's understandable. I happen to be the other way in that I'm surprised to land on a repository page and not be immediately presented with a stable release. But each organization has a different dev workflow. My background is often in tools that don't use the package managers that you mention, often instead being in the distribution package (apt-get, rpm, yum), which means they are often out-of-date, but it is interesting that some popular languages have done an end-around this bottleneck and created their own package systems. It is good that we will have a dedicated doc website.

For the workflow you are suggesting, how are multiple versions handled and maintained? I'm seeing the definite scenario that there will be some fine-tuning of the 1.0 spec for the production systems out there, which will require some point releases, but we don't want that intermixed with the 2.0 work.

This is basically what I'm most familiar with:
https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/
To summarize:

One branch where development evolves, e.g., "master" or "trunk" or "devel" etc.  Everything gets committed into this branch
Individuals/groups can work on feature branches. When they want to submit their work, they rebase it on the latest master and submit a pull request.  They can also rewrite their own history a bit in the process to clean up/squash their commits.
The master branch should never be broken.
Releases are basically just a tag on a particular commit. Typically, you'd also have a branch for that release as well.  You'd follow your release process at that commit to push artifacts to any repositories like PyPI, CRAN, etc.
If you need to patch a particular release (e.g. for a bugfix), you'd add a commit off of the release branch.  Oftentimes, you find a bug that you fix on the master branch, but you also want to apply it to a previous release.  In that case, you'd commit to master and then cherry pick that commit onto the release branch as well.

There's a good diagram in the link above.

That's fine, I don't have any particular issue with it. I consider the development branch an additional abstraction that's helpful in some situations, but it's not necessary.
I agree that the master branch should never be broken, but technically this won't happen with this model, unless we strictly enforce a policy. For example, Christian updates the MiAIRR, but he's not going to update the python code, nor the R code, nor maybe some for the docs, etc. All of that will need to be done before the pull request can be merged. I'm okay with that, we just need to enforce the policy. Even then it's unclear whether we could attain 100% coverage, for example testing submission templates to repositories, testing the API for web services, etc.
In my model the master branch is never broken (except for unknown bugs), but the development branch may for periods of time (think integration of features/components). With our small group and tight coordination, these situations may not arise.
The important part to me is handling the release branches in parallel, so long as we agree that when v1.0 comes out, it goes on its own branch, and master then becomes v2.0 work. In my model, there are release branches for major versions, so no change there.
Individual/groups working on features for v1.0 would need to know to create their feature branch from the v1.0 branch, and not master. In fact, we can get rid of master as the name and use the version number for the branch names to be more explicit.

I do not have to much experience with these models in "real" (i.e. distributed and asynchronous settings), so no strong opinions, beside that I prefer rebased histories. So with development gone and master locked, would the usual commit cycle look like below?

fetch master from remote
new local branch from master/HEAD
edits & testing
fetch again master from remote
[if necessary, rebase to current master/HEAD locally]
push new branch to remote
pull request

Yep, pretty much, the key point is to put your work on its own branch and submit a pull request when ready to merge.
Is there a way to get the consistency check travis job to run on a branch without doing a pull request? I have settings enabled that those checks must be passing in order to do a merge, but if it's a hassle to run them locally, would be nice to just run them on a branch.

I think that Travis currently build every pull request and every branch that's pushed into the repo.

Also, perhaps we can disable merge commits?

You can see how the PRs I submitted should've been clean linear commits added to the history, but the merges made it look complex.

I admit I've never paid much attention to these different styles of merging, as they weren't available before git. When I merged your two pull requests, the second wanted me to update with the master branch as it was changed, which I guess explains what you are seeing?
I notice (from airr-formats work) that all of the commits got "collapsed". I tend to do individual commits with messages for specific files. I personally like to see that history but that all gets collapsed into a combined commit message. Is there any way to keep that message/file relationship yet have the linear history that you want?

Ok, cool, then in that case go ahead and change the settings appropriately.

How and where do we best summarize these decisions (i.e. the current development model)?
A CONTRIBUTE.md in the main directory?

For VDJServer we have section in the README.md that describes the development guidelines, so that it's immediately available from the main page.

I noticed there is a contributing section in the settings, maybe that is the place to put it.

Now that we are one big happy repo, how about we create a set of labels (or projects?) so we can tag the different groups (MiAIRR, formats, common repository, etc.)?

I don't know how I missed this issue, but I'm full of opinions! I'm pretty much in full agreement with @schristley.  I would prefer something like a simplified Gitflow approach.
In our repos we use a simple workflow where default (master) is used development, you don't commit broken code to default, and if you need to break something you use a feature branch. The reasons we do it this way are:

We're always working with the latest code, so develop and default might as well be the same. We would never use default internally if it was only for releases.
Repos don't have subprojects. Every repo is a standalone package so there's only one development path.
And the big reason: it's easier to onboard new people who join the lab. The workflow needs to be accessible to 1st years who are unfamiliar with software development.

But, I don't think any of these criteria apply to the airr-standards repo. I'm thinking something like the following would be better:

master should be stable code only with development occurring in the develop branch.
Merges into master are done via pull requests from develop.
Small changes can be committed directly to develop, but larger changes should be a feature branch off develop. Feature branches should never spawn from master, but new development branches might.
Anonymous changes would use pull requests, but work by the core developers can just be commits to develop.

I'm thinking this would be a lot easier to work with.
There wouldn't be all this pull request approval/merge overhead, which currently means someone has to dedicate a chunk of their time to micromanaging the repo. Whomever deals with merges only has to deal with it when you want to pull stable code from develop.
There's no lag for those actively working on the code. For example, we recently had the sphinx doc pull request sitting there for 12 days. Which means if I wanted to update the docs, I couldn't really do so without stacking another pull request on top of a pull request. I know this was because of the AIRR meeting, but we're not always going to have compatible schedules.
This would simplify doc maintenance too, because then we can just have the ReadTheDocs site land on stable without having to update the landing/building version in ReadTheDocs with each release. We can just map stable -> master and latest -> develop.
If we wanted, we could have project specific develop branches. We could have develop-formats-py, develop-formats-r, develop-miairr, etc. Provided these are associated with a strict directory structure, then we can have development proceed independently within separate develop-* branches. Merging into master only when a project hits a stable release with meta-versioning on the master branch. New develop-* branches could be spawned for new projects as needed.
We're a small group. Seven contributors so far? With 3-4 people actively contributing code per project? I'm sure we'll get more contributors over time, but I don't think we need a formal pull request and code review process for such a small group. Just being able to commit would be a lot simpler/faster.
One downside about github is that it doesn't notify you of commits to watched repos. So without the pull requests you fail to notice commits. Though, we could setup a slack channel with github integration if we wanted to work around that.
That's my $0.02. Or maybe it was $0.08.

I fully support your generally preferred approach, @javh, and I think it would be appropriate here too.  What you actually propose for this repo I think will actually just add overhead.
Basically, there needs to be one branch where new stuff goes.  And bc we'll have versioned releases of the standards, there need to be branches for them.  And that's basically it.  The branch where the new stuff goes can be called "develop" or "master" or whatever, but there is really no need for a "develop" and a "master" if we'll also have branches for the versions, which we will.  (I'd personally prefer "master" since it's more common.) People can choose to privately work on their own branches in prep for a pull request, or they can work directly on master for their own fork, but it doesn't really make a difference.  Having multiple develop branches also seems overcomplicated.
Also, the pull request/merge overhead is independent of the git model we choose.  It depends on whether we want literally every commit to be +1'd by one of the "committers", which is typical but also a lot of overhead at this point. A real question is whether we want to let committers commit code without getting approval from someone else.
Regarding the git model, I'd just reiterate that gitflow complicates things unnecessarily IMO.

We can just map stable -> master and latest -> develop.

This seems like it would be problematic potentially. When people actually use the airr-standard, we want to make sure they're using a particular version.  If they just point to "stable" then a new version release on our end could break their code/repo.

One downside about github is that it doesn't notify you of commits to watched repos. So without the pull requests you fail to notice commits.

We could enforce the policy that all commits go through a pull request, but let you accept the PR yourself, at least for the core group of committers. This would add a small amount of overhead, but would at least generate the notifications.

So overall, I'm advocating:

a single branch for development ("master") and release branches that correspond to released versions; linear history (no "merge" commits); "master" should never be broken (once we get there)
all contributions to the master branch through PRs, either through forked repos or feature branches (the latter only working for people with write access to the repo, the former for any contributor)
core group of devs that can commit code (accept PRs), including their own
for now, have a policy of "don't do stupid shit"; if you think your change might be controversial, wait for approval from other committers; we can revisit this if the dev group starts to get bigger

We don't have an actual release branch, in my mind that's confusing matters. Maybe we are all talking the same thing but are mixing the words. In the gitflow, "master" is the release branch and "develop" is where development occurs, "master" is never broken but "develop" may be as integration work is performed. In Uri's model, "release" is the release branch and "master" is where development occurs. The "release" branch should never be broken, but "master" may be as integration work is performed.
So are we all talking the same thing, or am I still misunderstanding something?

Hrm. Okay, so this seems to depend upon whether you want to handle releases as branches or tags. In the simplest case we are discussing two options:

Development in master with releases branches off master. Release branches are just a single changeset.
Development in develop with releases as tags in master. Master is just one changeset per release.

We do the first in our repos, except releases are just tags instead of branches. Which is another option. The second gives us more flexibility to do long lived development branches if we want, but we don't have to.  With just a single develop branch, they are really similar. I think we could do either and it would feel pretty much the same day-to-day. However, though the first would remove some flexibility and the ability to manage releases through pull requests. Also, it would mean having unstable code in release branches. For example, if the python library hits a milestone, but the R library is still a work-in-progress, then the unfinished R library will be tagged with the python library version.
Re: ReadTheDocs

This seems like it would be problematic potentially. When people actually use the airr-standard, we
want to make sure they're using a particular version. If they just point to "stable" then a new version
release on our end could break their code/repo.

I don't think so. We'll want the docs to land on whatever the latest release version is. If the tip of 'masteris always the current release, then that's the same as manually setting the landing page to the docs that are build from the most recent release branch. I think this again comes done to whethermasteris used only for releases or not. Ifmaster` is stable but not released code, then, yeah, that would be confusing.
Re: Everything through pull requests
I think this is likely to be my biggest issue. I think requiring approval from someone else for each commit is going to be burdensome. But if you can just approve your own pull requests, then why bother with pull requests instead of just doing a normal commit?

And on a separate note, can somebody explain this "no merge commit" thing. I've seen it mentioned multiple times. For pull requests, sometimes they are old and it says that it is "out of date with the master". There is an update branch button (it's called sync on bitbucket). I click that button all the time. Should I be doing something else?

handle releases as branches or tags

Yeah I might have confused matters there because I tend to think of release as tags sitting on the "release" or "master" branch, i.e. what Jason indicates.

Development in develop with releases as tags in master. Master is just one changeset per release.

and so the current repo is a mixture. Instead of making a 0.1 tag on master, I probably should have made a release-0.X branch and put the tag on it.

Oh, and for the simple case we'll still have the "unstable code in release branches/tags" no matter which way we go. I think we'd need the more complex multiple develop branches to fix that. If we care.

Also, it would mean having unstable code in release branches. For example, if the python library hits a milestone, but the R library is still a work-in-progress, then the unfinished R library will be tagged with the python library version.

Ugh. I don't like that at all, but it seems we have to deal with it. My hope was that everything would be properly working before we did a release. This will only become more complicated as we start creating specs/APIs for the common repository and germline WGs.

Ugh. I don't like that at all, but it seems we have to deal with it. My hope was that everything would
be properly working before we did a release. This will only become more complicated as we start
creating specs/APIs for the common repository and germline WGs.

Yeah, we decided to put multiple projects in the same repo. I'm not seeing a way around the problem except some sort of system that somehow divides the repo into sub-repos for each project (eg, multiple develop branches).
I mean, we could just wait on releases until every project in the repo hits a stable milestone. That's all I can think of. It might be annoying though. Maybe someone else has a better idea?

Sorry for the spam, but I just thought of another upside to @laserson's proposal. If we do each release as a separate branch, then it'll make maintenance releases easier. For example, if we discover a bug long after a release and the affected code is no longer in master, it's easy to just continue the original release branch to implement the fix.

I think we are getting confused about terminology.  Ultimately, there is simply a single tree of commits.  A branch and a tag are essentially the same thing...it's just an object that points at a commit on the tree.  The advantage of actually using a branch vs a tag in git is that you can continue adding commits to the branch, in case we need to do a bugfix on an older release (e.g., bump the "z" in version "x.y.z"). But in reality, we'd just do both.  Tag a commit on release, and add a corresponding branch as well.
Therefore, for the docs, we can have a "stable" branch which is the landing page, but it should not point at the "master" branch, but rather a branch that's labeled with the latest version.  If the version branch and the master branch both point at the same commit (i.e., at the tip of the tree), that's no problem. But any time someone uses our software or standards, they should always be referencing a particular version. They can reference "master" if they want, but then they have to deal with the floor falling out beneath them. Part of our release process would be to update the "stable" pointer to the latest released version.
More significantly, having a develop and a master branch just means there are two tips of the tree that are moving forward, and they actually diverge quite a bit before they're merged together again periodically. This seems redundant and potentially confusing.  I think there should be just one tip for the mainline of development, and it should never be broken.  You can feel free to create a long-lived feature branch and have multiple people commit to it for a while before incorporating it into "master".

[On multiple repos vs one repo:] My hope was that everything would be properly working before we did a release.

That's why I'd advocate that we actually stay on v0.x rather than rushing to v1.0. Too late to go back to this?
One option is to keep the airr-standards repo just for "standards" and have separate python and R repos.  Both approaches have advantages and disadvantages.  I slightly lean towards one repo for the moment.

But if you can just approve your own pull requests, then why bother with pull requests instead of just doing a normal commit?

Purely for record-keeping purposes. It also lets people comment on your changes. (Even for stuff already committed I believe.) If you can accept your own pull requests, it should be pretty small overhead. And if we eventually change the policy where we want to have someone else approve, it'll be super easy.

if the python library hits a milestone, but the R library is still a work-in-progress, then the unfinished R library will be tagged with the python library version.

There's just one version for airr-standards. "master" should never be broken, so whenever you tag a release, everything should continue to work. If there's not much change in the R lib but a lot of change in the python lib at a release, doesn't really make a difference.

I think this again comes down to whether master is used only for releases or not.

Of necessity, "master" or "develop" or whatever is always "used" for a release, bc whatever commit you tag as the release was at one point tip of the tree. Which is why there is no point in having both a "develop" and a "master".

another upside to @laserson's proposal. If we do each release as a separate branch, then it'll make maintenance releases easier. For example, if we discover a bug long after a release and the affected code is no longer in master, it's easy to just continue the original release branch to implement the fix.

Yes! This is exactly the reason for doing a branch instead of a tag.

More significantly, having a develop and a master branch just means there are two tips of the tree
that are moving forward, and they actually diverge quite a bit before they're merged together again
periodically. This seems redundant and potentially confusing. I think there should be just one tip for
the mainline of development, and it should never be broken. You can feel free to create a long-lived > feature branch and have multiple people commit to it for a while before incorporating it into "master".

So I think this is a point of confusion. Master and develop aren't independently moving forward. Develop is always equal to or ahead of master in the simple linear case. The difference is just whether branches "go out" from develop (master) to release (trunk to leaves) or "go in" from develop to release (master) (roots to trunk). By definition, if we went with master as a single release branch, the tip of master would be the latest stable release.
After talking about it, it sounds like we're in favor of a simple linear workflow, yes? So in that case, it doesn't really matter to me whether we use branches for releases or master for releases. If go with the former, we lose the ability to do complex non-linear things like having independent versions for each sub-project in the repo. If we're all okay with that downside, then I don't think it makes much difference.
I'm cool with the cactus model then, because develop in Gitflow and master in the cactus model should behave the same.
I'm still not certain it's wise to have the landing page for the github repo being unstable code, but if we properly maintain the README/docs then it should probably be okay. If we don't regularly update the version in the README/docs people will come to the page, read version 1.0, but end up downloading the unstable tip.

Purely for record-keeping purposes. It also lets people comment on your changes.
(Even for stuff already committed I believe.) If you can accept your own pull requests, it should be
pretty small overhead. And if we eventually change the policy where we want to have someone
else approve, it'll be super easy.

You can comment on commits directly. You can even comment on individual lines of code in a commit. I think commits are sufficient record keeping if you don't need to discuss the changes before merging.

Thanks everybody for their effort in discussion, I think we are converging.

That's why I'd advocate that we actually stay on v0.x rather than rushing to v1.0. Too late to go back to this?

I think so, yes. At the AIRR meeting, MiAIRR was presented as v1.0, with goals for v1.1 and longer term goals for v2.0. We could try to make some technical argument that the repo's version are different from MiAIRR but that will likely just confuse people versus being helpful.
We got agreement that submissions (e.g. to NCBI) will have MiAIRR version numbers associated with them, though the technical implementation needs to be resolved. This means that we need to consider release branches as living in perpetuity just like the data. While it might be nice to think that V2.X could interoperate with V1.X data, there's no guarantee of that.

But if you can just approve your own pull requests, then why bother with pull requests instead of just doing a normal commit.

I like the pull requests because it runs the travis job to insure some gross inconsistency wasn't introduced. If you are on a branch, you can see the travis results though they aren't obvious, you have to go to travis and click around. If you commit directly to master, you aren't going to get the check beforehand.
Now you can argue that developers could run the consistency check themselves. But I've tried to run the consistency checks in my development environment, talk about a total pain in the butt, I had to setup a whole docker image, blah blah... So it's nice to let GitHub do it for me.
However, I'm in agreement to keep things simple. I was initially trying to setup all of these formal rules for master to insure it doesn't get messed up in relation to MiAIRR releases, but I think we've resolved that, so we can simplify down to 2 steps:

Always create a pull request.
Pull request must pass the travis job checks to merge.

Now owners can force merges even though the checks fail, and they can also commit directly to master without a pull request, so we just have to agree don't do that!

Okay, to get some closure on this. I've created a document for the development model. Please review pull request 72.

Pull Requests

I like the pull requests because it runs the travis job to insure some gross inconsistency
wasn't introduced. If you are on a branch, you can see the travis results though they aren't
obvious, you have to go to travis and click around. If you commit directly to master, you
aren't going to get the check beforehand.

That is nice, but I personally don't think it's worth the hassle of having to deal with multiple local repos and merges. It also strikes me as somewhat non-linear. Every time you create a fork it's like an anonymous branch, and if the repo changes between your fork and your pull request, then you have to deal with resolving it.
I'm pretty strongly opposed to having to do everything through pull requests. But, here's a thought... we could just not set a rule about it. If you want to do a PR for the remote consistency check you can, or if you want to do pushes and do local consistency checks you can do that too. Just make a judgment call on a case-by-case basis. In the end, it all just ends up as commits in the history regardless of whether it originates as a push or pull request.
This is what we did in the airr-formats repo without ever discussing it and I don't recall any issues. Maybe some confusion on whether to rebase branches or not? I guess we should talk about that too...
Versioning
I think we need to think about this carefully. Off the top of my head, I can only think of two mostly bad options (below). Anyone have any other ideas?
1) We meta-version the repo and wait for each subproject to hit a stable version before incrementing the meta-version.  For example, we might have the following meta-version with component versions described:
AIRR Standards v1.0:

MiAIRR v1.0
PyAIRR v0.1

The downside being that this is more overhead. It's not huge overhead, but the more little tasks you add to each release, the easier it is to forget one. Also, the meta-version would really be more of a convenience for us than something users would refer to, which is potentially confusing.
2) We version the repo with named subproject versions that denote which subproject hit release for the given change set.  For example, we could label the repo MiAIRR v1.0 now. When the python library is done, then we label the repo PyAIRR v0.1. There's no clear linear version history, but you would know which changeset denotes a release for the given project.
Workflow
I feel like if we want input from others a visual aid might be helpful at this point. Essentially, we are debating between the workflows shown below. Each colored circle is a release and the arrow is the development branch.

C is what we do for our repos. A is what @laserson is suggestion. B is what @schristley and I proposed.
At this point, if I understand our goals correctly, @laserson has convinced me A will work if we're smart about the versioning. It's closer to what I'm used to anyway, so I'm not going to complain if that's the decision. :)

(terse bc on my phone at airport)
I still don't understand why we can't have a single version for the whole repo. If a new version only updated the python code, the new version number will still make it clear what's on the R code. And given version bump in any system will almost always focus on some subset of features.
Regarding your diagrams, Jason, A and C start off the same. You only get the extra branches coming off in A if there are actually updates that need to be made to old releases. (Actually, unless you do A, I'm not sure how to even update an older release.)

Also, I'm not sure how B works. If I understand correctly, each colored node is a release, so how does information get transferred from the main trunk into a release?

One of my main points is that different lines of development always need to be merged eventually. Either you do it with a merge commit, which creates the parallel histories, or you do that by rebasing your branch on the tip of master, which results in a linear history.
Finally, @javh, it is not necessary to fork a repo to submit a pull request. You can create a PR from a branch in the same repo.

In order:

Let's say you have two packages in a repo. The code for Package A is ready for release at version 1.1. The code for Package B is currently incomplete and is somewhere between version 2.1 and 2.2. What do you tag the repo as? And if someone downloads the versioned changeset, thinking the code base is stable because there was a release annotation, then they get a broken version of Package B.
A is branched releases and C is tagged releases. Same general idea, but C is just annotating changesets.
This is the workflow where you merge from develop into master when you want to do a release, so the releases are tags on master (master has the circles on it).
Well sure, you can make a bunch of branches, but then aren't we doing Gitflow at that point? If we can push to branches without pull requests, then we pull request into master, then we don't have a single development branch anymore, right? I'm not saying we shouldn't do feature branches when appropriate, I'd just really rather not do a fork/branch for every little thing.

Let's say you have two packages in a repo...

The sub projects cannot have independent versioning, otherwise users won't know what goes with what. What version of MiAIRR is supported by this tool version? Given some data in a specific MiAIRR version, what tool version do I need? With everything as the same version then there is no ambiguity.
I realize that normally this could cause all kinds of problems, but I think we are okay because MiAIRR is stable and will change very infrequently. Most of the stuff we are debating are internal design decisions that won't affect what the average AIRR user sees. Plus I think we can control this by which versions we stick into the public package managers (pip, cran, etc.). Say for example, v1.0.1 python is ready but R isn't, well we put a python package on pip, but don't put anything on cran. Later R is ready, in v1.0.2, so we put it up on cran. Now technically, there is a v1.0.2 of the python package, we can decide if we want to put it or not depending if anything has changed.
If we make a major internal re-design decision, like changing the format of the specification files, then we just have to be conservative and make sure everything is updated before we do a release, and not rush out one tool just because it is ready.
I think if there is some vitally important project, that needs those changes in some stable way, then we can do something ad-hoc like a special tag on the master branch, e.g. python-dev-v1.0.5

I'm not sure that B was what I'm thinking, probably because I don't see changes on the development branch flowing into the release branch, but anyways no matter, I'm good with A. C is not flexible enough for us, so I'd vote for A, however with a minor clarification. I don't think every release should be it's own branch, I think every major release should be it's own branch. So there is a release-1.x.x branch, a release-2.x.x and so on.

I'm pretty strongly opposed to having to do everything through pull requests...

I understand that, and I'm not strongly set on requiring pull requests. What I don't like is allowing anybody to commit without a PR, but I'm cool with the idea that some people are allowed. With the knowledge that if you screw it up, you owe us all a round of drinks at the next AIRR meeting ;-D
And some things really do need to be off limits, i.e. don't go changing the TSV file or the specifications files, until other people have had a chance to review. Simple bug fix to some code, no problem.

Workflow
Well, I feel like we've been talking about something like D occasionally (I updated my visual aid above), which would be having merges into master from development branches/forks, with master containing unstable code, and releases as branches from master. Which I think is more complex than necessary - basically combined A and B into something with messy parts of both.
To answer @laserson's question from earlier about how you update old releases in C (and B)... you don't. Versions should be linear. If you really need to, then you'd have to spawn a maintenance branch from the version tagged changeset, but that would be a special case and not standard practice.
And, yeah, we can set some guidelines for what kind of changes should get reviewed. I'm certainly not envisioning global write access either. I've always felt that the entire point of pull requests was access control - providing a mechanism for people without write access to make commits.

we've been talking about something like D occasionally

Yes exactly, though D is making feature/development branches more explicit, I kinda assumed those were there regardless. I pretty much always put major development on a branch.
What isn't clear to me is what those colored release dots on D are exactly, are they v1.X, v2.X, v3.X? Or are they v1.1.X, v1.2.X, v1.3.X, or are they v1.1.0, v1.1.1, v1.1.2? For releases and version, I think more of that branch in B with the color dots. In which the branch represents v1.1.X, and each of the dots would be v1.1.0, v1.1.1, v1.1.2. When the spec updates to v1.2, we create a new release branch for v1.2.X releases.

Yes exactly, though D is making feature/development branches more explicit, I kinda
assumed those were there regardless. I pretty much always put major development on a branch.

They are. Any of them could have feature branches, but I didn't want to make the diagrams overly complex. It's just an outline of the day-to-day practice.  In D, this would be always doing your development in a branch/fork and then having to do a merge into master (ie, requiring pull request for everything).

What isn't clear to me is what those colored release dots on D are exactly, are they v1.X, v2.X,
v3.X? Or are they v1.1.X, v1.2.X, v1.3.X, or are they v1.1.0, v1.1.1, v1.1.2? For releases and version, I > think more of that branch in B with the color dots. In which the branch represents v1.1.X, and each > of the dots would be v1.1.0, v1.1.1, v1.1.2. When the spec updates to v1.2, we create a new release > branch for v1.2.X releases.

The dots are just "versions" - whatever that means. If we want to do branches for major versions and tags for minor versions, I think that's maybe something to sort out later. Personally, I think using a different mechanism for different types of versions is overly complicated. But I can see some logic to it.

The dots are just "versions" - whatever that means. If we want to do branches for major versions and tags for minor versions, I think that's maybe something to sort out later. Personally, I think using a different mechanism for different types of versions is overly complicated. But I can see some logic to it.

Okay, though later is pretty soon. We already should have a v1.0 MiAIRR, and I'd actually like to release the python package as soon as possible. iReceptor and VDJServer are both pushing for a new public release soon (maybe end of Jan), and they should really point to released versions.
Anyways, the issue I feel we need to consider in our versioning/release strategy is how to support major versions in parallel. I believe that when MiAIRR goes V2.0, we are still going to need to support the V1.0 toolset with bug fixes and maintenance.


[RU] Specifications and types translation

Hello,
@brain-geek @nscyclone can You please check my translation?
Regards!

Thanks for Your suggestions, I've updated my translation

Text & Link fixed, commits squashed! @brain-geek @nscyclone

@yuriibodarev I've looked through the PR. While the text is good, squash is still missing. :)
There are bunch of obsolete merge commits in the PR still:
@nscyclone , can you approve this PR so that I could merge it as soon as it's squashed?

LGTM, thanks, @yuriibodarev and @brain-geek!

After playing with GIT now it looks correct to me. @brain-geek please check my commit!

Thanks, @yuriibodarev !
That's a huge chunk of work you made!


Refreshing the nodes page resets the configuration

Description
When refreshing the nodes page the configuration is lost. It would be good to keep that configuration. For example when we asked for the nodes of a specific farm that configuration is lost when we reload the page.

the current node finder sets the filters in the query params. so after refreshing, the filters will be still applied.


Consider using "『』" instead of "「「」」" for string declarations.

『』 are used in Traditional Chinese as double quote.
Maybe we can consider using it instead of 「「」」  for string declarations which is a little bit too space consuming.
Ex:
吾有一言。名之曰「聲」。
若「三餘」者。加「聲」以「「黃河流水鳴濺濺。」」。昔之「聲」者。今其是矣。云云。
若「五餘」者。加「聲」以「「燕山胡騎鳴啾啾。」」。昔之「聲」者。今其是矣。云云。
吾有一言。曰「聲」。書之。

to
吾有一言。名之曰「聲」。
若「三餘」者。加「聲」以『黃河流水鳴濺濺。』。昔之「聲」者。今其是矣。云云。
若「五餘」者。加「聲」以『燕山胡騎鳴啾啾。』。昔之「聲」者。今其是矣。云云。
吾有一言。曰「聲」。書之。

In my poor memory, 『』means 《》.
Someone who know Japanese and Traditional Chinese well may help

In Japanese, 『』 is used for nesting 「」s.
But I think it's not wrong (or invalid) to use 『』 for string literals for disambiguation.

Thanks for the proposal! (and your VSCode plugin)
So on one hand I would like to refrain from using more special symbols. I enjoy the philosophy of having only two 「」, and the rest is just Chinese characters. There is a minimalistic quality to it.
Another problem I have with『』is that personally I don't think they look very nice in most fonts. The strokes just look too thin for some reason. And the spacing between them is also overly thin. It looks as if someone simply downscaled a bigger version of the glyph.
On the other hand I think you're right. It does save space. And it does make sense.
Let's consider more on this.

Another candidate may be using some keywords before 「」to mark it as a string, not variable name. 若「五餘」者。加「聲」以文「燕山胡騎鳴啾啾。」。 for example.

@tiansh Thanks! your solution is my favorite one so far.

I would personally upvote for the 『』 solution, this will make code snippets seems clearer.
In terms of traditional Chinese convention, I don't think 「「」」 make sense since no one use them in traditional Chinese, especially to represent string literals.
And I don't think "look very nice in most fonts" is a problem, I think they're recognisable enough in most typefaces.
I think a good compromise will be, accept 『』 as the mark to represent string literals (i.e. " in JavaScript), and use 文 for handy escape，for example
『燕山胡騎鳴啾啾。』 => "燕山胡騎鳴啾啾。"
『古有诗云「黃河流水鳴濺濺。」』 => "古有诗云「黃河流水鳴濺濺。」"
文「古有诗云『燕山胡騎鳴啾啾。』」 => "古有诗云『燕山胡騎鳴啾啾。』"
I think 「「」」 is just too verbose.
But how to represent formatted strings, like `${variable}` in JavaScript or f'{variable}' in Python? We need more discussion.


add changelog for https://github.com/Azure/azure-sdk-for-go/pull/20009

[x] The purpose of this PR is explained in this or a referenced issue.
[x] The PR does not update generated files.

These files are managed by the codegen framework at Azure/autorest.go.

[x] Tests are included and/or updated for code changes.
[x] Updates to CHANGELOG.md are included.
[x] MIT license headers are included in each file.

add changelog for https://github.com/Azure/azure-sdk-for-go/pull/20009

@jhendrixMSFT This PR is just adding a changelog item that I missed in previous PR. Could you help to approve?


COVID Result SNOMED Coding

Below is the current logic for COVID result SNOMED coding.  Sender Automation will be coding results almost exclusively from the text given to us.  Almost all COVID results listed in the CMS LIVD spreadsheet have Negative coded as Not Detected instead Negative, and Positive coded as Detected instead of Positive.
First question, should we SNOMED code results based on the LIVD spreadsheet or based on the text provided in the Sender's file??  I can speak for several States that it doesn't matter to them, but should we code as close to the CMS specs as possible??
Second, are all of the SNOMED codes listed below in ReportStream??  The link https://github.com/CDCgov/prime-reportstream/blob/master/prime-router/docs/schema_documentation/covid-19.md does list Not Reactive or Reactive.

IF Source in (Negative, Neg) THEN
- RS.test_result = "260385009"

ELSEIF Source in (Positive, Pos) THEN
- RS.test_result = "10828004"

ELSEIF Source in (Detected, DET) THEN
- RS.test_result = "260373001"
ELSEIF Source in (Not Detected, NDET) THEN
- RS.test_result = "260415000"
ELSEIF Source in (Reactive) THEN
- RS.test_result = "11214006"
ELSEIF Source in (Not Reactive, Non-Reactive, Non Reactive) THEN
- RS.test_result = "131194007"
ELSE
- RS.test_result = ""
END IF

The input schema for SimpleReport data accepts SNOMED test_result_codes.  https://github.com/CDCgov/prime-reportstream/blob/master/prime-router/docs/schema_documentation/primedatainput-pdi-covid-19.md
I didn't get a hit for the Reactive or Not Reactive codes anywhere in the RS repo.

I believe we'll have to remove Reactive and Non Reactive.

For now, I'll remove Non Reactive and Reactive from all mappings.


typo: Microsoft.DataMigration

exising -> existing
capabilites -> capabilities
eligiblity -> eligibility
propery -> property
ertificate -> certificate

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-python

Automation for azure-sdk-for-node

Automation for azure-sdk-for-js

Automation for azure-sdk-for-go

Automation for azure-sdk-for-java


Feat: configurable instance creation timeout

Context
The cloud providers should implement the Provider interface on which the CreateInstance() method is responsible for creating the VM instance then return an Instance type when done. Here, done means a running VM with networking connectivity (IP addresses assigned).
Problem
The CreateInstance() implementation for Libvirt is going to create an Libvirt domain and start. It is needed to wait for the IP addresses to be assigned, and recently we introduced a polling mechanism (issue #1216) alongside a fixed (hard-coded) timeout of 60 seconds. The problem arises when Libvirt cannot meet that 60s deadline, and this can happen very often depending on the environment it runs and its setup. That timeout was 30s no longer ago, but on CI (a VM runner instantiated from Azure) it use to take ~40 seconds, so we had to increase it to 60s; while on my working station 30s is just fine.
As a result, the Libvirt's CreateInstance() should have a configurable timeout mechanism for IP polling (or maybe an overall creation timeout).
Let's look at other providers:

ibmcloud - its CreateInstance() tries up to 10 times with 2 seconds of query interval. Those values are hard-coded.
azure - its CreateInstance() seems to not have an explicit timeout but its create() method uses a call to pollerResponse.PollUntilDone(ctx, nil) to wait the VM be ready. Does PollUntilDone() have an implicit timeout? Probably...

So the other cloud providers might have a more predictable deadline, so they don't need a configurable timeout? Even with flexible instance types in place?
Solutions
One possible solution could be to allow passing an argument to cloud-api-adaptor's binary to specify the expected instance creation timeout. Just like other arguments, that value will be passed via ConfigMap.
Another is to make it configurable via pod annotation seems over. Perhaps not, and the timeout could (or should?) be tied to the instance type?
Other solutions?
Additional information
Recently the CreateInstance() got a new paramter(instanceType) and depending on how we tackle this issue we will need a new timeout parameter.  I am afraid that list can grow substantially overtime and we might need a more robust approach for passing parameters. I can think of:

Use variadic function arguments (https://go.dev/ref/spec#Passing_arguments_to_..._parameters)
Create a new datatype, for example InstanceRequirements, to wrap the instance requirements (instanceType, creation timeout...etc).

Cc @bpradipt @stevenhorsman @surajssd @CarstenLeue

Afaicr, the instance creation timeout is dictated by the remote hypervisor timeout in kata configuration.toml. The retries in CreateInstance are for retrieving the IP address as it takes some time for the instance IP to be available for some providers.
We can introduce a global timeout option for retrieving instance details, on similar lines to the proxy timeout option. But wondering if it's really needed ? or we need to figure out a better mechanism to get libvirt assigned IP address, if it exists?


Adding an extra flag option

Hi, I have been using the semantic highlight functionality to gray out sections of code skipped with #ifdefs, and it's been working great. However, I can't seem to find a solution to deal with compiler specific logic since there is no way to pass additional flags to clang in the coc config. I have tried adding a .clangd configuration file for my project as described in the clangd documentation, but it has no effect. Would you consider adding a new coc configuration field for extra clang flags?

.clangd file should work for the case you've described. Could you give more details about what you tried, expected and really happened? preferably with clangd logs.

.clangd file should work for the case you've described. Could you give more details about what you tried, expected and really happened? preferably with clangd logs.

I placed a .clangd file at my project root, and typed the following lines in it:
CompilerFlags
  Add: [-D__GNUC__, -U__clang__]

I have the following snippet of code in my project:
#if defined(__clang__)
     spdlog::warn("CUDA GPU mode not supported by libraries compiled using clang, recompile use gcc");
#else
         if (
#ifdef _MSC_VER
             RunTimeLinkSuccess("OrtSessionOptionsAppendExecutionProvider_CUDA")
#else
             OrtSessionOptionsAppendExecutionProvider_CUDA
#endif
         )

And I am expecting to see the section of code wrapped in the #if defined(__clang__) macro to be grayed out, but it didn't.
I have enabled verbose logging via coc config but I don't know where clangd saves its log file.

it is CompileFlags not CompilerFlags and you should have an additional colon : after CompileFlags:. I've tested with:
.clangd:
CompileFlags:
  Add: [-U__clang__]

a.cc:
#ifdef __clang__
static_assert(false);
#else
static_assert(false);
#endif

and I can verify that I am seeing the warning on the else branch. you can check coc documentation to figure out how to get to logs, but at some point it was possible to see via :CocInfo. The logs would've also contained errors about unknown keys in the config too.

it is CompileFlags not CompilerFlags and you should have an additional colon : after CompileFlags:. I've tested with:
.clangd:

CompileFlags:

  Add: [-U__clang__]

a.cc:

#ifdef __clang__

static_assert(false);

#else

static_assert(false);

#endif

and I can verify that I am seeing the warning on the else branch. you can check coc documentation to figure out how to get to logs, but at some point it was possible to see via :CocInfo. The logs would've also contained errors about unknown keys in the config too.

Thanks, I got it working now.


use_thin_strokes has no effect on macOS 12

This is the changes that make it work
https://github.com/alacritty/alacritty/issues/4616#issuecomment-860810609
without this change, use_thin_strokes does nothing on macOS 12
can you merge this?
ben@BeniMac2020 crossfont % git diff
diff --git a/src/darwin/mod.rs b/src/darwin/mod.rs
index aded7a7..9a0f84f 100644
--- a/src/darwin/mod.rs
+++ b/src/darwin/mod.rs
@@ -445,10 +445,13 @@ impl Font {

         if use_thin_strokes {
             cg_context.set_font_smoothing_style(16);
+            cg_context.set_allows_font_smoothing(false);
+            cg_context.set_should_smooth_fonts(false);
+        } else {
+            cg_context.set_allows_font_smoothing(true);
+            cg_context.set_should_smooth_fonts(true);
         }

-        cg_context.set_allows_font_smoothing(true);
-        cg_context.set_should_smooth_fonts(true);
         cg_context.set_allows_font_subpixel_quantization(true);
         cg_context.set_should_subpixel_quantize_fonts(true);
         cg_context.set_allows_font_subpixel_positioning(true);

cg_context.set_font_smoothing_style(16);
cg_context.set_allows_font_smoothing(false);
cg_context.set_should_smooth_fonts(false);

It seems to me like these three lines would be in conflict with each other? When you disable font smoothing, surely setting the font smoothing style doesn't make any sense?

cg_context.set_font_smoothing_style(16);
cg_context.set_allows_font_smoothing(false);
cg_context.set_should_smooth_fonts(false);

It seems to me like these three lines would be in conflict with each other? When you disable font smoothing, surely setting the font smoothing style doesn't make any sense?

then cg_context.set_font_smoothing_style(16); should be moved to
else {
}

then cg_context.set_font_smoothing_style(16); should be moved to

You want to move logic that previously only applied to one conditional block to the opposite block? That doesn't make much sense, does it?

then cg_context.set_font_smoothing_style(16); should be moved to

You want to move logic that previously only applied to one conditional block to the opposite block? That doesn't make much sense, does it?

well, i am not the one that made the patch, but i tested it, it works on macOS 12, all characters are thin stroke, with use_thin_strokes: true. i don't quite know how the code works actually :)

i don't quite know how the code works actually

Well, if nobody knows how the code works, then it certainly will not be merged.
If I'm going to send any PR to change the thin strokes behavior on macOS, it will be to remove it completely. I'm personally not interested in this feature and think it's not very beneficial to have anymore.
So if someone else actually cares about thin strokes, they should put in the effort to figure these things out and ensure they work on all macOS systems. Just sending in some patch that might work some of the time won't cut it.

@chrisduerr I've been experimenting with this a bit and have a patch of crossfont and alacritty that decides what to do based on the AppleFontSmoothing user default, which is what the system uses now to decide this behavior, rather than making this a preference in alacritty/crossfont. Is this something you would be interested in? If so I can polish it up and push it for review, but don't want to waste your time if that's not an approach you'd prefer.

Can you configure this default actually? Patches are always welcome, especially for macOS, given that it's not what core contributors use.
I'll be the one reviewing patch anyway, so go ahead.

@kchibisov Sure, I will open a PR and we can discuss further there.


library hides versions with deleted tag

copied code from loader to hide versions with deleted tag

moved to PR https://github.com/pypeclub/avalon-core/pull/114


⚠ Bofrost.si has degraded performance

In 1e705d6, Bofrost.si (https://www.bofrost.si) experienced degraded performance:

HTTP code: 200
Response time: 3714 ms

Resolved: Bofrost.si performance has improved in 4ed7b60 after 10 minutes.


Retrieve num videos in backend

retrieves ALL LIKED VIDEOS in back end by updating youtube API call using page tokens instead of a certain number
retrieves totalLiked videos from youtube JSON response, adds this in JSON response to front end
if not logged in, user is prompted with redirect opened in a new tab. Once logged in, the tab closes.
addresses all of Nick's latest comments

UP TO DATE AS OF MONDAY JULY 28

latest commit updates so JSON response is:
{"data":[{"genre":"Pop music","count":2},{"genre":"Music of Latin America","count":1},{"genre":"Rock music","count":1},{"genre":"Country music","count":1},{"genre":"Other music","count":1},{"genre":"Electronic music","count":1}],

"totalLiked":7,"totalMusic":6,"isMusic":false,"maxGenreCount":2}

ready to be reviewed! 😄

Okay, the current version addresses all of Nick's comments and uses nextPageToken to retrieve ALL youtube videos. So now, the user doesn't choose how many videos he/she wants to retrieve, it automatically retrieves all videos.

latest changes do what Nick requests (not sure why his version doesn't show it)


Allow Option in Regions2d Mask Conversion for Label Names

Currently, Regions2d Mask Conversion functions only allow integer label names in both the 2d and 3d masks. For fish labeled .evr files, it would be beneficial to have the option to have label names in both the 2d and 3d masks that match the region names, like "Hake" and "Rockfish"; so in essence, we want to add the option to have a dictionary that maps string label names to integer label names in the 2d mask.
This issue was brought up in #96.

Some transects from 2017 survey with different labels which could be used to fiddle with different labels.
x100: Herring: 4, Other 3, Hake: 1
x10: Hake: 9, Age 1: 3

I think this issue is the same as #131. @ctuguinay : could you confirm?

This issue is too specific behavior-wise for a general package, and this behavior can already be accommodated by the more flexible mask_labels dictionary. The user just needs to create the mapping between region_id and label names, and set that as the mask_labels input.


Support for Kotlin 1.5 value classes

The recently released Kotlin 1.5 introduces inline (or value) classes which offer a nice way to enforce type safety without memory overhead. The formatter is currently not recognizing value class, resulting in line breaks.
For the example given in the link above:
Input:
@JvmInline
value class Password(val s: String)

Expected:
@JvmInline value class Password(val s: String)

Actual:
@JvmInline value

class Password(val s: String)

What version are you using?
I'm trying to repro using https://facebookincubator.github.io/ktfmt/ (which is running 0.25) and it gives me a reasonable
@JvmInlineBla
value class PasswordBlaBlaBla(val s: String)

(I added some words to make it overflow the 50 column limit, which is the minimum in the online formatter)

Ah, it may appear that we need to update. We are currently using 0.22 so I will give 0.25 a try and will post back. Sorry about that, definitely should have checked against the latest first

I'm surprised 0.22 worked at all, since it was using the Kotlin 1.4 compiler. Maybe the keyword was there but was treated differently? weird, but happy it works :)

Confirming that 0.25 gives the expected output. Thanks again!


Allow whitelisting some email domains so they may send DMs

This PR allows specifying a list of email domains that are still allowed to send DMs if their email is on a specific domain.
This helped us reach some of the requirements needed in a large(ish) edu installation.
I'm opening this PR to elicit some feedback on the implementation. Would you be interested in adding such a feature to the disable-dm plugin? I'm sure the implementation needs some cleanup which I would take care of should you be interested in landing the feature.

Hey @chetanyakan Thanks for your feedback, I'll look into it and try to address your inputs.

I recommend to whitelist different art of taxometries. examples: Teams, Domains, User


Inconsistent channels dimensions with VideoClip

When trying to retrieve a clip using:
video, audio, info, video_idx = self.video_clips.get_clip(idx)
sometimes the output i get is "channels last" and sometimes it's "channels first". Ofcourse, I could verify that by checking video.shape[-1] == 3 and permute the dimensions if needed, but it can cause bugs for others so I think it should be consistent and use "channels first".

This is not actually the case.
The output of read_video (and thus VideoClips is supposed to always be channels last.
We do have a transform to convert from channels first to channels last, see https://github.com/pytorch/vision/blob/6de158c473b83cf43344a0651d7c01128c7850e6/references/video_classification/transforms.py#L42-L43 and https://github.com/pytorch/vision/blob/6de158c473b83cf43344a0651d7c01128c7850e6/references/video_classification/transforms.py#L92-L94
As such, I'm closing this issue as is, but let me know if you think otherwise


Show connector status

If a connector or task is in FAILED state, we'll need at least to have a hover or something with the connector's error message.
@rk3rn3r, I suppose this may require some new backend method, too.

We can just add the error message to the current response when there's an error. We just skipped that because of we were close to the end of the 30 days when we were adding the connectors list (which was not planned for that phase initially)


fix(tooltip): cloned series invert

fix: https://github.com/antvis/G2/issues/5385

存在问题：band 比例尺 invert 会改变 domain
解决办法：clone 一个新的，再 invert
测试：因为不太好添加，这里就先不添加了

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

4 of 6 (66.67%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.01%) to 88.194%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/interaction/tooltip.ts
4
6
66.67%

Totals

Change from base Build<PHONE_NUMBER>:
-0.01%

Covered Lines:
10003

Relevant Lines:
10985

💛  - Coveralls


Marko doesn't recognize new components after first build

Version: 2.3.9
Details
After starting the dev server I created a new component and tried using it. Marko didn't recognize it, needed restart of the server
Expected Behavior
I expected the component will be recognized and be able to be used without restart

confirming this in the vite-express example code. i get this error when adding a new component:
Internal server error: src/components/app-main/index.marko(4,4): Unable to find entry point for custom tag .
  2 |
Hello! world!

  3 |   <test-component/>
> 4 |   <test-component2/>
    |    ^^^^^^^^^^^^^^^
  5 |   <app-sections>
  6 |     <@section title="Buttons">
  7 |

  Plugin: marko-vite:pre
  File: [full path here]/examples/examples/vite-express/src/components/app-main/index.marko
 ....

backtracking from that error message via debugger shows that node.extra is undefined here. i'm guessing the issue is still several layers deeper, but might help as a starting point to debug: https://github.com/marko-js/marko/blob/a0970494e0135559812611b40448e2bb12952f63/packages/translator-default/src/tag/custom-tag.js#L27


refactor(parameters): use boto_config instead of config parameter

Issue number: #4729
Summary
Changes
This PR introduces a new parameter boto_config in the parameter features for dynamodb, ssm, secrets, and appconfig, while deprecating the existing config parameter. This change aims to improve clarity and specificity in our API without immediately breaking existing implementations. A warning will be raised if using config parameter.
User experience
BEFORE
from botocore.config import Config

from aws_lambda_powertools.utilities import parameters

boto_config = Config()
ssm_provider = parameters.SSMProvider(config=boto_config)

def handler(event, context):
    # Retrieve a single parameter
    value = ssm_provider.get("/my/parameter")

    return value

AFTER
from botocore.config import Config

from aws_lambda_powertools.utilities import parameters

boto_config = Config()
ssm_provider = parameters.SSMProvider(boto_config=boto_config)

def handler(event, context):
    # Retrieve a single parameter
    value = ssm_provider.get("/my/parameter")

    return value

Checklist
If your change doesn't seem to apply, please leave them unchecked.

[x] Meet tenets criteria
[x] I have performed a self-review of this change
[x] Changes have been tested
[x] Changes are documented
[x] PR title follows conventional commit semantics

Is this a breaking change?
RFC issue number:
Checklist:

[ ] Migration process documented
[ ] Implement warnings (if it can live side by side)

Acknowledgment
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

Hey @sthulb! I need your review here please.


Block Enhancements: loading, searching and stop button

Hello,
Enhancements for Block explorer:

add a loading wheel/progress bar when Block is first opened as it can take some time for anything to show
add a searching icon wheel/progress bar when user uses the Search function to inform the user that the search is still ongoing
provide an option to stop the search

I think these would improve the user experience as it sometimes takes a while for Block to return anything during which time the screen shows blank. Some community members are unsure whether it is working or not.
The webpage itself appears to have loaded even though Block is still loading.
On open:

During Search:

Thanks,
Jazmin

Hi @MiniJaz Many thanks for this, we'll look in to it.


[storage] Refactor MoveStorage to Improve Readability

Motivation
This small PR improves the readability of MoveStorage by refactoring its APIs to support fetching of a single resource (instead of a batch of resources).
Have you read the Contributing Guidelines on pull requests?
Yes.
Test Plan
(Share your test plan here. If you changed code, please provide us with clear instructions for verifying that your changes work.)
Related PRs
(If this PR adds or changes functionality, please take some time to update the docs at https://github.com/diem/diem/tree/main/developers.diem.com, and link to your PR here.)
If targeting a release branch, please fill the below out as well

Justification and breaking nature (who does it affect? validators, full nodes, tooling, operators, AOS, etc.)
Comprehensive test results that demonstrate the fix working and not breaking existing workflows.
Why we must have it for V1 launch.
What workarounds and alternative we have if we do not push the PR.

/land


Add --md flag

@nikitavoloboev @michaelmior Here you guys go!

Amazing! Thanks @johnletey :)

@michaelmior No problem ... my pleasure!

Although as a side note, it would be nice in the future if LICENSE.md could actually use Markdown formatting. For example, I use the markdown-licenses repo.

Looks good

@michaelmior I was having similar thoughts about using license templates for automation (#19)
@nikitavoloboev Wonderful!

@michaelmior I opened an issue for you: #36


Support for item metadata endpoint

Pretty simple, this just hits the /item/#{itemId}/metadata endpoint.
I'm noticing though that this is giving me a 404.  And when pasting the same access token and item id into the REST client browser (http://www.corespring.org/api#/!/default/get_items_itemId_metadata) the JS code is also throwing a 404.  Could you please make sure this endpoint is working as expected before I dig much deeper?

Looks good to me!


Vim9: ":verbose" reports wrong line number for mapping installed from ":def" function

Describe the bug
In Vim9 script, :verbose reports a wrong line number for a mapping installed from a :def function.
To Reproduce
Run this shell command:
vim -Nu NONE -S <(cat <<'EOF'
    vim9script
    var lines =<< trim END
        vim9script
        def g:FuncA()
            # [ERROR] you can write as many commented lines (or lines of code)
            # anywhere in this function, they are ignored in the count; they should not
            FuncB(0)
        enddef
            # [ERROR] you can write as many commented lines (or lines of code)
            # here, they are ignored in the count; they should not
        def FuncB(
            # [ERROR] the header is wrongly counted as a single line (comments included),
            # even though it's splitted on multiple lines
            n: number
        )
            exe 'nno '
                # [ERROR] you can write as many commented lines (or lines of code)
                # here, they are all counted; they should not
                .. '<F3> a'
                .. 'b'
                .. 'c'
        enddef
    END
    writefile(lines, '/tmp/script.vim')
    so /tmp/script.vim
    g:FuncA()
    verb nno <F3>
EOF
)

This message is printed:
Last set from /tmp/script.vim line 8

The line number is wrong.  It should be 14.
Expected behavior
This is printed:
Last set from /tmp/script.vim line 14

Environment

Vim version: 8.2 Included patches: 1-2771
OS: Ubuntu 16.04.7 LTS
Terminal: xterm(367)

Additional context
The previous snippet includes 4 comments which describe 4 errors.
The first 3 errors disappear when FuncA() is re-written as a legacy function:
vim9script
var lines =<< trim END
    vim9script
    fu g:FuncA()
        " [OK] you can write as many commented lines (or lines of code)
        " anywhere in this function, they are no longer ignored in the count
        call s:FuncB(0)
    endfu
        # [OK] you can write as many commented lines (or lines of code)
        # here, they are no longer ignored in the count
    def FuncB(
        # [OK] all the lines in the header are correctly counted separately
        # (comments included)
        n: number
    )
        exe 'nno '
            # [ERROR] you can write as many commented lines (or lines of code)
            # here, they are all counted; they should not
            .. '<F3> a'
            .. 'b'
            .. 'c'
    enddef
END
writefile(lines, '/tmp/script.vim')
so /tmp/script.vim
g:FuncA()
verb nno <F3>

Last set from /tmp/script.vim line 19

Notice that the reported line number is different, even though the snippet has the same amount of lines in each function (and in-between them); now, it's 19.  It's almost correct; it matches the last line of the multi-line :exe command which installs the <F3> mapping.  But it should match the first line.
The remaining error disappears if FuncB() is also re-written as a legacy function:
vim9script
var lines =<< trim END
    vim9script
    fu g:FuncA()
        " [OK] you can write as many commented lines (or lines of code)
        " anywhere in this function, they are no longer ignored in the count
        call s:FuncB(0)
    endfu
        # [OK] you can write as many commented lines (or lines of code)
        # here, they are no longer ignored in the count
    fu s:FuncB(
        # [OK] all the lines in the header are correctly counted separately
        # (comments included)
        n
    )
        exe 'nno '
            "\ [OK] you can write as many commented lines (or lines of code) here,
            "\ they are no longer counted
            \ .. '<F3> a'
            \ .. 'b'
            \ .. 'c'
    endfu
END
writefile(lines, '/tmp/script.vim')
so /tmp/script.vim
g:FuncA()
verb nno <F3>

Last set from /tmp/script.vim line 14

Fixed by 8.2.2775


Update dependencies

Cool nodes! My apologies for the non-informative commit message. Should I also update versions of the imnodes-related crates?

Thanks, I also pushed a commit updating cimnodes, if there is something missing, feel free to PR 👍 for the latest imnodes changes I'd just wait for cimnodes to regenerate the bindings.


board安装后默认密码无法登陆adminserver和board

In GitLab by @cuiaq123 on Sep 11, 2020, 01:02
board-offline-installer-7.4-97-gd9dc178.tgz

In GitLab by @cuiaq123 on Sep 24, 2020, 08:31
用户名修改为boardadmin

In GitLab by @cuiaq123 on Sep 24, 2020, 08:31
closed


Smooth boundary line of a mesh

Hi, I'm looking to smooth just the boundary line of a mesh (not the entire mesh), I was wondering if there's any functionality in vedo to achieve this? Thanks!

Yes although that is kind of a dangerous operation... Have a look at  method smooth_mls2d().

Sorry i meant smooth_mls1d() after using boundaries().


Rust crate typenum fails to compile, on a clean new project

Hello, i pretty much just created a new project with rust and it compile errors on deploy.
I searched github issues on dfinity/cdk-rs(here) and dfinity/ic but there seemed to be no one pointing this out
Steps to reproduce:
dfx new service -> Picked Rust, SvelteKit and Internet Identity
cd service
dfx start --background
dfx deploy

and that gives me a lot of errors(150 erriors) on the crate typenum about the crate crypto-common, here's a brief of some
error[E0433]: failed to resolve: use of undeclared type `N3`
   --> ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/typenum-1.17.0/src/type_operators.rs:249:14
    |
249 |     let n3 = N3::new();
    |              ^^ use of undeclared type `N3`

Regards.

I could not reproduce the error.
My env:

macOS 14.4.1
rustc 1.76.0 (07dca489a 2024-02-04)

Could you check if you were using a bit outdated Rust toolchain?
If the issue persists, could you provide more info about your dev env?


Task #1231321 Test git

Coverage remained the same at 99.669% when pulling 19b11ee8d73ef1af8da1a9764e65d55db776762e on nhanltt-1788:task/fix_ababa into d19099afeff64ecfb09133c06c1cb18c0d40887e on react-boilerplate:master.


Java: Update modelid in examples

As text-davinci-003 isn't available in Azure Open AI any longer, I switched to davinci-002.

https://github.com/microsoft/semantic-kernel/issues/4390

@johnoliver @d3r3kk @dsgrieve ready for review

@SandraAhlgrimm Closing this PR as your commits have been taken and applied to the java-development branch:
https://github.com/microsoft/semantic-kernel/tree/java-development/java/samples/semantickernel-spring-starter
if you need to make any further updates please PR on that branch.
Thanks you very much for the contribution


Links to most recent dives on home page

Link from home page if dive is < 24 hours old for instance

Difficult to do without any glider dives in db with corresponding time. Try setting up during/after Oban


bump python version to pre-release 0.31.0a0

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/ADAM-prb/3074/
Test PASSed.

Thank you, @akmorrow13


refactor(plan node): move plannode generic

I hereby agree to the terms of the Singularity Data, Inc. Contributor License Agreement.

wocao

Yes, both on the generic_derive.rs and generic.rs. And move them in a dependent path


Update version on PyPI

I have no idea how to get a new version onto PyPI. The setup.py upload is deprecated, the web interface gives me an error message, and I can't run twine because of some obscure dependency version conflict. I'd be happy if someone else could just take over maintenance of the project on PyPI.

I guess, this could be closed: based on sympy maillist thread, you are figured out how to update things on pypi.  (BTW, for the Diofant project I use deployment with travis-ci to automate these things.)

Indeed.