Add content about the API to the beginning of each vignette.

Let me know when you are ready to merge. Don't worry about Travis if things render fine.

Yeah, I'm also seeing the same title rendered twice:
http://bioconductor.org/packages/devel/bioc/vignettes/GoogleGenomics/inst/doc/VariantAnnotation-comparison-test.html
http://bioconductor.org/packages/devel/bioc/vignettes/GoogleGenomics/inst/doc/PlottingAlignments.html
Below is are a couple of screenshots:

~p

At the top of some pages, I see some R source code getting rendered regarding getting the API key from the environment variable GOOGLE_API_KEY.  Below is an example:

Are you guys requiring R 3.1.3 to work with this package?  I'm getting the following error:
> library(GoogleGenomics)
Loading required package: GenomicAlignments
Loading required package: BiocGenerics
Loading required package: parallel

Attaching package: ‘BiocGenerics’

The following object is masked _by_ ‘.GlobalEnv’:

    get

The following objects are masked from ‘package:parallel’:

    clusterApply, clusterApplyLB, clusterCall,
    clusterEvalQ, clusterExport, clusterMap,
    parApply, parCapply, parLapply, parLapplyLB,
    parRapply, parSapply, parSapplyLB

The following object is masked from ‘package:stats’:

    xtabs

The following objects are masked from ‘package:base’:

    anyDuplicated, append, as.data.frame,
    as.vector, cbind, colnames, do.call,
    duplicated, eval, evalq, Filter, Find, get,
    intersect, is.unsorted, lapply, Map, mapply,
    match, mget, order, paste, pmax, pmax.int,
    pmin, pmin.int, Position, rank, rbind,
    Reduce, rep.int, rownames, sapply, setdiff,
    sort, table, tapply, union, unique, unlist,
    unsplit

Loading required package: S4Vectors
Loading required package: stats4
Loading required package: IRanges
Loading required package: GenomeInfoDb
Loading required package: GenomicRanges
Loading required package: Biostrings
Loading required package: XVector
Loading required package: Rsamtools
Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]) :
  there is no package called ‘checkmate’
In addition: Warning message:
package ‘GenomeInfoDb’ was built under R version 3.1.3
Error: package ‘GenomicAlignments’ could not be loaded
>

@siddharthab I think this is good to go for now.  The issue with two titles might still be there, but let's figure that out later.
@pgrosu I'm not sure about the R version issue you are running into.  This particular PR did not change the dependencies of the package in any way.
Regarding the API KEY blurb, its intentional that its in the vignette but not displayed in the rendered result.  It should help if people are trying to run the vignette manually.

@pgrosu The version warning you are seeing is because you upgraded R but did not upgrade the packages. Some of the packages you have on your system were built for R 3.1.3 and might not work well. The warning will go away when you upgrade all packages. This is completely unrelated to GoogleGenomics.

@deflaux Ah, thanks for the vignette clarification - that makes sense :)  Regarding the double-title it probably is because of the following:
Lines 41-43:

Reproducing Variant Annotation Results

which gets rendered as:

    Reproducing Variant Annotation Results

Line 74:

Reproducing Variant Annotation Results

which is under the following div tag, that starts on line 74:

@siddharthab Hmm...maybe, but I'm pretty sure I checked the R version on my home computer and it said 3.1.2 and then I did the standard biocLite()...update all/some/none packages (a/s/n) and chose a for all, and still got the same thing.  I'm not running the devel version.  I'll try it again tonight when I get home - or on the cluster later in the day - and let you know how it goes.
thx,
~p

@pgrosu -- try pulling either a release or devel Docker image from BioC and
run it in there, it will be rather more revealing.  I don't even bother
reporting errors in my personal BioC setup any more unless I can replicate
them in one of the above Dockers
Statistics is the grammar of science.
Karl Pearson http://en.wikipedia.org/wiki/The_Grammar_of_Science
On Fri, Jul 10, 2015 at 11:33 AM, Paul Grosu<EMAIL_ADDRESS>wrote:

@deflaux https://github.com/deflaux Ah, thanks for the vignette
clarification - that makes sense :) Regarding the double-title it probably
is because of the following:
Lines 41-43:

Reproducing Variant Annotation Results

which gets rendered as:

    Reproducing Variant Annotation Results

Line 74:
Reproducing Variant Annotation Results
which is under the following div tag, that starts on line 74:

@siddharthab https://github.com/siddharthab Hmm...maybe, but I'm pretty
sure I checked the R version on my home computer and it said 3.1.2 and then
I did the standard biocLite()...update all/some/none packages (a/s/n) and
chose a for all, and still got the same thing. I'm not running the devel
version. I'll try it again tonight when I get home - or on the cluster
later in the day - and let you know how it goes.
thx,
~p
—
Reply to this email directly or view it on GitHub
https://github.com/Bioconductor/GoogleGenomics/pull/41#issuecomment-120489037
.

Hi Tim,
I agree, but I am trying to play the naïve user/biologist who is just following the instructions that are written.  I should not need to download a Docker image, since I assume that since the package is part of BioConductor - with the assumption of being thoroughly tested - which I tried to help by performing this on almost all the Google Genomics client PRs before they are merged.  Some users they have their own intricate collection of R scripts, and would be hesitant to download a new R version and update scripts or move things around.  In any case, for example in the following file that is part of this PR:
https://github.com/Bioconductor/GoogleGenomics/blob/c6f1cc21a1b5f98f3413a4f896455ac6d9419ab1/inst/doc/PlottingAlignments.md
the sessionInfo() says that it was tested with ## R version 3.1.1 (2014-07-10) and thus I have something similar (i.e. R 3.1.2).  I then did more tests, and noticed the following warning that I need a higher version of R than what the Provenance section lists:
The downloaded binary packages are in
        C:\Users\Me\AppData\Local\Temp\RtmpoP9Avs\downloaded_packages
Warning message:
package ‘GoogleGenomics’ is not available (for R version 3.1.2)

Of course I switched to that R version, since I have a collection of R versions installed and I test these releases based solely on what is written in the documentation files of these releases.  Some biologists I worked with in the past are not computer experts, but are fantastic at following protocols and instructions.  It's sort of the testing lens I polished for myself over the years, after having given many data analysis training sessions to biologists that spanned a spectrum of computer/programming expertise.  Thus these instructions have to be precise and complete for all users, as the GA4GH and GoogleGenomics releases are geared to make this analysis simple and intuitive.
Hope you have a great weekend,
Paul

Sorry just noticed the file is updated in the Provenance section with just having the sessionInfo() command, without any output information regarding the version details used to generate the results.  So that section probably would need to be updated to list or the minimum required version for users to be at, including some plots (and outputs), in order for people to have some idea of what things should look like.

@pgrosu these are good points. are you going to be in Seattle?  Because I
already have numerous slides' worth of bitching to do about other aspects
of user-facing changes.  At some point it's unbecoming to bite the hand
that feeds me so often.  But if somebody ELSE ranted at developer day,
well, I certainly couldn't be held responsible for THAT ;-)
BioC is one of the best run (perhaps the best run) open bioinformatics
projects in existence and is largely responsible for R being what it is.
Your remarks get right to the heart of some thorny issues when integrating
pay-as-you-go cloud providers with open, reproducible, tested project
infrastructures.
Statistics is the grammar of science.
Karl Pearson http://en.wikipedia.org/wiki/The_Grammar_of_Science
On Sat, Jul 11, 2015 at 8:57 AM, Paul Grosu<EMAIL_ADDRESS>wrote:

Hi Tim,
I agree, but I am trying to play the naïve user/biologist who is just
following the instructions that are written. I should not need to download
a Docker image, since I assume that since the package is part of
BioConductor - with the assumption of being thoroughly tested - which I
tried to help by performing this on almost all the Google Genomics client
PRs before they are merged. Some users they have their own intricate
collection of R scripts, and would be hesitant to download a new R version
and update scripts or move things around. In any case, for example in the
following file that is part of this PR:
https://github.com/Bioconductor/GoogleGenomics/blob/c6f1cc21a1b5f98f3413a4f896455ac6d9419ab1/inst/doc/PlottingAlignments.md
the sessionInfo() says that it was tested with ## R version 3.1.1
(2014-07-10) and thus I have something similar (i.e. R 3.1.2). I then did
more tests, and noticed the following warning that I need a higher version
of R than what the Provenance section lists:
The downloaded binary packages are in
C:\Users\Me\AppData\Local\Temp\RtmpoP9Avs\downloaded_packagesWarning message:package ‘GoogleGenomics’ is not available (for R version 3.1.2)
Of course I switched to that R version, since I have a collection of R
versions installed and I test these releases based solely on what is
written in the documentation files of these releases. Some biologists I
worked with in the past are not computer experts, but are fantastic at
following protocols and instructions. It's sort of the testing lens I
polished for myself over the years, after having given many data analysis
training sessions to biologists that spanned a spectrum of
computer/programming expertise. Thus these instructions have to be precise
and complete for all users, as the GA4GH and GoogleGenomics releases are
geared to make this analysis simple and intuitive.
Hope you have a great weekend,
Paul
—
Reply to this email directly or view it on GitHub
https://github.com/Bioconductor/GoogleGenomics/pull/41#issuecomment-120635654
.

@ttriche  I would love to be in Seattle, but unfortunately I'm swamped with two papers due before the end of the summer.  I share the same sentiments for BioC, since it is what attracted me to the community almost ten years ago and still does.  I understand your frusturations and think your presentation would benefit others, but ideally it should project the theme as helpful recommendations that others might benefit from.  It took me 16 years to learn how to test projects properly - both in academia and in industry - and this is not something that can be taught overnight without being practiced.  Actually failure was my best teacher :)  The most helpful presentations in this domain were ones that gently introduced me to the reasoning behind all the concepts of testing - that also included examples - and how they all integrated together.  I tried to write my posts on GA4GH the same way - some which took me sometimes a week to do - but will be there forever so people can keep coming back to them over years.
I think one other element that helps here is if it is practiced as a team on real projects.  So for instance, we all come together and polish the end product of GoogleGenomics until it works just right.  Sure there will be grumbling along the way, but in the end we get a fairly good product.  If we think a PR is not ready, we throw in a test to proves that something needs to be fixed to fit the standard we are accustomed to.  I'm not sure how many tests the nice folks at Google have - besides the ones in the PRs - but just in case for more than a year I collected a few tests I cherrypick from to run on most of the PRs.  Ideally we have release notes with every version, so that we know what tests would need to updated.  It's understandable that not all of us have access to the backend of the API to determine what might fail a test, but over time we get fairly good coverage.  Ideally yes, we have a standard collection of tests that everything goes through - similarly how hellbender gets looked at by different members of the Broad and Google teams on a variety of tests - but until then we are those test teams and suggest what might be helpful in the roadmap.  There is a ton of low-hanging fruit in this project so the potential is huge here over the next few years.
~p

@pgrosu my fussing is orthogonal to that of testing (ok, maybe not really,
since build tests for downstream packages perhaps ought to have caught some
of the fallout) but the short version is, in BioC the standard operating
procedure is to wait 2 release cycles before defunct()ing a function or
package.  Deprecation throws a warning, and the idea is that users have a
solid year to fix any downstream effects.  However, the recent migration of
the SummarizedExperiment class (which is foundational, and was featured in
a recent Nature Methods paper as it existed just a few months ago) has not
followed these conventions, and has resulted in a great deal of fallout
that could have been avoided by simply following the traditional
deprecation cycle.
Testing has not historically been my forte (it's only recently that it sunk
in just how much unnecessary maintenance work can be avoided with proper
testing) so I'm simply not in a position to preach to others about
testing.  It does seem to be wise to canonicalize the build/test
environment, as BioC is starting to do with release and devel containers,
so that bug reports and build failure reports at least have a reproducible
context.  There's something to be said for detective work, but "it's an
efficient use of time" is probably not that something.
Best,
--t
Statistics is the grammar of science.
Karl Pearson http://en.wikipedia.org/wiki/The_Grammar_of_Science
On Sun, Jul 12, 2015 at 4:41 PM, Paul Grosu<EMAIL_ADDRESS>wrote:

@ttriche https://github.com/ttriche I would love to be in Seattle, but
unfortunately I'm swamped with two papers due before the end of the summer.
I share the same sentiments for BioC, since it is what attracted me to the
community almost ten years ago and still does. I understand your
frusturations and think your presentation would benefit others, but ideally
it should project the theme as helpful recommendations that others might
benefit from. It took me 16 years to learn how to test projects properly -
both in academia and in industry - and this is not something that can be
taught overnight without being practiced. Actually failure was my best
teacher :) The most helpful presentations in this domain were ones that
gently introduced me to the reasoning behind all the concepts of testing -
that also included examples - and how they all integrated together. I tried
to write my posts on GA4GH the same way - some which took me someti mes a
we ek to do - but will be there forever so people can keep coming back to
them over years.
I think one other element that helps here is if it is practiced as a team
on real projects. So for instance, we all come together and polish the end
product of GoogleGenomics until it works just right. Sure there will be
grumbling along the way, but in the end we get a fairly good product. If we
think a PR is not ready, we throw in a test to proves that something needs
to be fixed to fit the standard we are accustomed to. I'm not sure how many
tests the nice folks at Google have - besides the ones in the PRs - but
just in case for more than a year I collected a few tests I cherrypick from
to run on most of the PRs. Ideally we have release notes with every
version, so that we know what tests would need to updated. It's
understandable that not all of us have access to the backend of the API to
determine what might fail a test, but over time we get fairly good
coverage. Ideally yes, we have a standard collection of tests that
everything goes through - similarly how hellbender gets looked at by
different members of the Broad and Google teams on a variety of tests - but
until then we are those test teams and suggest what might be helpful in the
roadmap. There is a ton of low-hanging fruit in this project so the
potential is huge here over the next few years.
~p
—
Reply to this email directly or view it on GitHub
https://github.com/Bioconductor/GoogleGenomics/pull/41#issuecomment-120773811
.

@ttriche  I totally agree that the development lifecycle and testing process for BioC would benefit in being revisited and tightened.  I'm really happy to hear you also share in the ideas behind the benefits of testing - it took me many years to see it - and we can all work as a team with BioC community to gradually adopt these ideas, though I'm sure some already know them.
Since seeing the full spectrum of testing could be overwhelming for some, to make it a more gentle adoption, the simplest is to use a test-driven development [TDD] approach, which would be like starting with writing the complete vignette before doing any coding - including all examples and expected outputs - of how every function and class must operate before actually coding it.  Usually when I construct programs, I follow a consistent design recipe where I first start with the test cases - including all edge cases - of how I expect the outputs to be based on the inputs, while using only the function names. This takes up the majority of the time. Then I add the function contracts to the functions (i.e. the defined arguments/parameters) in terms of inputs and outputs based on the tests. I implement them first on the tests, and then add them with expanded definitions to the defined functions. Then these define the commented definition for each function and its types - the interpretation was previously defined via the test cases.  It is only the last 10% of this process that I actually code, which becomes a very mechanical process, since the plan is already written for me by me - having gone through the process of analyzing the complete problem and breaking it into its succinct components. I feel that if the community follows something along these lines of planning out any implementation and its coding portion, then it would be seldom that any surprises would creep up.  All tests of course would travel along with each appropriate package, and in case of R/BioC they can be part of the Examples section for the help page of the function.  Any cross-project tests can also be included as necessary.  If more complex testing is required, then that can be be visited when appropriate.
To expand, the above TDD approach can be augmented with a behavior-driven development [BDD] approach, by utilizing a standard such as the Gherkin language:
Feature: Retrieving assays in a SummarizedExperiment
  Scenario: Retrieving reads using assay() function
    Given a SummarizedExperiment
    When the assay() function is applied on SummarizedExperiment
    Then the assays within the SummarizedExperiment are returned

Then once these descriptive and unit-test type approaches are applied and pass, then all the other complex types of testing (i.e. integration, regression, smoke, etc.) would be performed before the package is released.
So, yes I definitely agree that the development lifecycle and testing process for BioC would benefit in being revisited and tightened, and thus your presentation would be essential to the community.
Best,
~p

Regarding ensuring that packages follow the deprecation cycle, these would need to have an automatic trigger that would halt the package based on an addition deprecation file, that would be submitted by the larger community. This file lists all the functions to be deprecated.  If during the followup release cycle some functions are not deprecated, then it would generate an additional file, with the list of the functions which should have been deprecated, along with an email-alert to the owner of the package.  If on the second release cycle it still has not, then the package is halted until it is fixed.  If the package is deemed critical to many other ones, then it would freeze the release until the package is fixed.  This might be too "industry-like" and overwhelming to a friendly community, but I'm sure via discussions a compromise can be reached which would integrate with a public ticket/svn system, where ideally people can be allowed to jump in an approved manner and fix things for high-impact packages.

@pgrosu and @ttriche: Just a suggestion, but perhaps it is worth having some of this more general discussion on bioc-devel where it is a bit more open.


Permit to rename disks and disk-snapshots inside created VM

Enhancement Request
Description
It would be nice for allow rename of disks inside vm, basically if it non persistent.
Use case
Users can set self user-friendly names for disk after attaching
Interface Changes
XML-RPC API:

add new one.vm.diskrename method, it will same like one.vm.disksaveas
add new one.image.snapshotrename method with string:<session> i4:<image_id> i4:<snap_id>, string:<new_name> arguments

Sunstone:

Add new button: 🖉 -  for rename disk or disk-snapshots

Cli:

onevm disk-rename <vmid> <diskid> <name>
      -s, --snapshot snapshot   ID of the Snapshot to rename.

oneimage rename <imageid> <name>
      -s, --snapshot snapshot   ID of the Snapshot to rename.

It's a good idea but, for the moment, you can use the command onedb update-body vm --id <vmid> and change the attribute SNAPSHOT/NAME.
release 5.4.3


EOL after 0.14

refs #346
@laanwj is 0.12 now maintenance end? Also what is the EOL date for 0.12?

ACK


x509: certificate has expired or is not yet valid

I am deploying splunk-otel-collector helm chart on my kubernetes cluster and I am getting x509: certificate error even though I have the latest certificate.
go.opentelemetry.io/collector/exporter/exporterhelper.(*logsExporterWithObservability).send
/builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.67.0/exporter/exporterhelper/logs.go:135
go.opentelemetry.io/collector/exporter/exporterhelper.(*queuedRetrySender).start.func1
/builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.67.0/exporter/exporterhelper/queued_retry.go:205
go.opentelemetry.io/collector/exporter/exporterhelper/internal.(*boundedMemoryQueue).StartConsumers.func1
/builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.67.0/exporter/exporterhelper/internal/bounded_memory_queue.go:61
2023-01-11T21:17:28.753Z	info	exporterhelper/queued_retry.go:426	Exporting failed. Will retry the request after interval.	{"kind": "exporter", "data_type": "logs", "name": "splunk_hec/platform_logs", "error": "Post "https://splunk-awsdev.ezesoft.net:8088/services/collector\": x509: certificate has expired or is not yet valid: current time 2023-01-11T21:17:28Z is after 2017-08-20T17:00:13Z", "interval": "14.070816254s"}
2023-01-11T21:17:30.531Z	error	exporterhelper/queued_retry.go:175	Exporting failed. No more retries left. Dropping data.	{"kind": "exporter", "data_type": "logs", "name": "splunk_hec/platform_logs", "error": "max elapsed time expired Post "https://splunk-awsdev.ezesoft.net:8088/services/collector\": x509: certificate has expired or is not yet valid: current time 2023-01-11T21:17:30Z is after 2017-08-20T17:00:13Z", "dropped_items": 2075}
go.opentelemetry.io/collector/exporter/exporterhelper.(*queuedRetrySender).onTemporaryFailure
/builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.67.0/exporter/exporterhelper/queued_retry.go:175
go.opentelemetry.io/collector/exporter/exporterhelper.(*retrySender).send
/builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.67.0/exporter/exporterhelper/queued_retry.go:410
go.opentelemetry.io/collector/exporter/exporterhelper.(*logsExporterWithObservability).send
/builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.67.0/exporter/exporterhelper/logs.go:135
go.opentelemetry.io/collector/exporter/exporterhelper.(*queuedRetrySender).start.func1
/builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.67.0/exporter/exporterhelper/queued_retry.go:205
go.opentelemetry.io/collector/exporter/exporterhelper/internal.(*boundedMemoryQueue).StartConsumers.func1
/builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.67.0/exporter/exporterhelper/internal/bounded_memory_queue.go:61
2023-01-11T21:17:40.943Z	error	exporterhelper/queued_retry.go:175	Exporting failed. No more retries left. Dropping data.	{"kind": "exporter", "data_type": "logs", "name": "splunk_hec/platform_logs", "error": "max elapsed time expired Post "https://splunk-awsdev.ezesoft.net:8088/services/collector\": x509: certificate has expired or is not yet valid: current time 2023-01-11T21:17:40Z is after 2017-08-20T17:00:13Z", "dropped_items": 15}
go.opentelemetry.io/collector/exporter/exporterhelper.(*queuedRetrySender).onTemporaryFailure
/builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.67.0/exporter/exporterhelper/queued_retry.go:175
go.opentelemetry.io/collector/exporter/exporterhelper.(*retrySender).send
/builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.67.0/exporter/exporterhelper/queued_retry.go:410
go.opentelemetry.io/collector/exporter/exporterhelper.(*logsExporterWithObservability).send
/builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.67.0/exporter/exporterhelper/logs.go:135
go.opentelemetry.io/collector/exporter/exporterhelper.(*queuedRetrySender).start.func1
/builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.67.0/exporter/exporterhelper/queued_retry.go:205
go.opentelemetry.io/collector/exporter/exporterhelper/internal.(*boundedMemoryQueue).StartConsumers.func1
/builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.67.0/exporter/exporterhelper/internal/bounded_memory_queue.go:61
2023-01-11T21:17:41.037Z	info	exporterhelper/queued_retry.go:426	Exporting failed. Will retry the request after interval.	{"kind": "exporter", "data_type": "logs", "name": "splunk_hec/platform_logs", "error": "Post "https://splunk-awsdev.ezesoft.net:8088/services/collector\": x509: certificate has expired or is not yet valid: current time 2023-01-11T21:17:40Z is after 2017-08-20T17:00:13Z", "interval": "6.33654171s"}
2023-01-11T21:17:53.901Z	info	exporterhelper/queued_retry.go:426	Exporting failed. Will retry the request after interval.	{"kind": "exporter", "data_type": "logs", "name": "splunk_hec/platform_logs", "error": "Post "https://splunk-awsdev.ezesoft.net:8088/services/collector\": x509: certificate has expired or is not yet valid: current time 2023-01-11T21:17:53Z is after 2017-08-20T17:00:13Z", "interval": "28.074440969s"}
2023-01-11T21:18:04.084Z	info	exporterhelper/queued_retry.go:426	Exporting failed. Will retry the request after interval.

I have the content of the certificate and the key in values.yaml file as it says.
TIA

The certificate is considered expired, from your error:

x509: certificate has expired or is not yet valid: current time 2023-01-11T21:17:28Z is after 2017-08-20T17:00:13Z", "interval": "14.070816254s"}
Please try to navigate to your HEC endpoint with your web browser, under the /collector/event/health endpoint. You can then check the certificate in your web browser: https://www.globalsign.com/en/blog/how-to-view-ssl-certificate-details

If the certificate appears valid there, please report back.

@atoulme  Thanks. We were able to figure out the certificate issue.


[Question] Add action buttons to notification

Hi all!
Is there any chance to add action buttons to notifications?
I mean like this one:

Looks like you can do that now in core electron. See https://github.com/electron/electron/blob/master/docs/api/structures/notification-action.md and https://github.com/electron/electron/blob/master/docs/api/notification.md. I think core electron covers all the functionality in this package now.


Diagrams not shown

Just installed over VS extentions
But looks like its not working.
No text highlihted and no diagramms displayed
Please, provide any 100% working example.

This is a bit weird. I don't have any other report like the one.
Please describe your environment (OS, VSCode) and the samples you have used.

Hi, same for me with this simple code: [Customer].
I'm running VSCode 1.31.1 on macOS 10.14.3.
Here what I see:

Thanks.

I have found the following behavior so far:

If you try to open a yuml file, it will show the diagram without problems.
If you create a new yuml file, it won't show the diagram (only that icon) until you save it

Workaround: Save the file (Ctrl-S) to see the diagram
Please confirm if this is your case, while I finish to analyze and solve this.

I just installed vscode-yuml, and tried the same [Customer] thing but did not see a diagram show, even after saving it.
The image nboukeffa shows is exactly what I see.
I wish I could show you my environment to better help you... likely, the install didn't quite go correctly.

@nboukeffa (and possibly @tvanriper )
Your yuml code is not correct. It is lacking the diagram type:
// {type:class}

The preview shall show a warning message about it, but it isn't. I suspect it is a collateral of PR #57
I will provide a new version in the following hours.

Fixed and published as version 3.4

That was indeed the issue.  It wasn't obvious to me (because I didn't read carefully enough) that you require the //{type:class} text.  If you browse to https://yuml.me and play around with their online editor, it doesn't have this requirement, which added to the confusion.
It makes sense to me, now that I see it... it just didn't immediately grab me.
For whatever it's worth, I think it is counter-intuitive that something classically appearing as a comment acts as a requirement.  That might have also made it harder for me to grab onto the concept.

There is some rationale behind it:
The yuml file shall contain the type, as we are not specifying the type in the URL as when you invoke yuml.me
As I didn't want to disturb too much the original specification, I used special comment. This is not an unusual practice, there are several language that have controlled comments.


Trigger the original tokenization behavior when no advanced turn settings are provided

Description
#1756 introduces some very advanced features for turn level masking which regresses on the simplified and default behavior for training on the last assistant turn in a conversation history.
This fixes that for the default simplified case

Motivation and Context
This sets None for all the new per turn config features so that the default tokenization strategy prior to #1756 can be done as is without any complicated logic.  Now, the advanced logic is only triggered when any of the advanced features are introduced
How has this been tested?
Added a new unittest to the prompt strategies chat template test suite that tests against Phi-3.5 (where the current behavior most clearly breaks things)
Screenshots (if appropriate)
Types of changes
Simplifying the chat template prompt strategy and undoing some (new) default values
Social Handles (Optional)

@fozziethebeat everywhere

Pylint doesn't seem to like the unittest now that it's gotten bigger.  I tried splitting it into two separate smaller unittests for sanity sake but now pylint is also upset that some lines are duplicated.  Open to suggestions on test cleanliness preferences

thanks @fozziethebeat, I moved the shared fixtures out, which should help with the linting.

That test cleanup strategy works for me!


Make outputdir path more robust

When the phrase "output" is contained in outputdir path, go.part1 couldn't store results in proper location.

I keep getting the following error while g.cwaread'ing a 2-week cwa file
Error code 1: data in block too short for doing non-wear detection
What's the bench mark for "too short' data?
Thanks.

@rx96304 your comment to unrelated to issue #15, please post as separate issue. I am not going to answer unrelated questions in a thread related to the outputdir path.


Remove update_licenses call.

Changes
This has been superseded by go mod vendor.
See https://github.com/tektoncd/chains/pull/695 for when this was removed.

Submitter Checklist
As the author of this PR, please check off the items in this checklist:

[ ] Has Docs included if any changes are user facing
[ ] Has Tests included if any functionality added or changed
[x] Follows the commit message standard
[x] Meets the Tekton contributor standards (including
functionality, content, code)
[ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)
[ ] Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes
NONE

/lgtm


add modal content workflow

I think this is right from what I see in make_site.R.
@bbest : can you verify these instructions are correct?

Looks good! Thanks @7yl4r :)


Update README

Add Chrome Extension template

@GaryLaurenceau Thanks! I think it's more of a KMM project than a plugin for KMM projects.

Yes, it's a KMM project template, not a plugin for KMM.
The data module uses multiplatform. The other modules have to target Kotlin/JS.

Unfortunately, this project isn't a complete KMM project nor is it a plugin for developing KMM projects.
The data module contains only one class.


[SuperEditor][SuperReader][iOS] - CMD key isn't reported correctly on iOS

When on iPad, when trying to use keybindings, the isPrimaryShortcutKeyPressed getter does not return true whatsoever, making it incompatible with iOS devices.
The fix is quite simple, just add the TargetPlatform.iOS check when meta is pressed inside the getter.
From this:
(defaultTargetPlatform == TargetPlatform.macOS && isMetaPressed)

To this:
([TargetPlatform.macOS, TargetPlatform.iOS].contains(defaultTargetPlatform) && isMetaPressed)

This was resolved in https://github.com/superlistapp/super_editor/pull/1678.


added doc for metrics config and fixed counter.set args order

counter.set() has different arguments order now
meetrics system allways expects a typesafe config on initialization

looks good 👍


Add CentOS support to the docker-storage-setup role

What does this PR do?
This let's us use the role on CentOS systems, as well as RHEL. In addition, it
installs docker and makes sure it's restarted (as opposed to just "started"
which has no effect when docker is already running).
These changes will let the OSP provider to use this role instead of our own homemade solution.
How should this be manually tested?
Run the docker-storage-setup role on centos and verify that Docker is installed, run and is configured as per the generated docker-storage-setup file.
Is there a relevant Issue open for this?
n/a
Who would you like to review this?
The role seems to be used by the vmware and rhv reference architectures, so in addition to @e-minguez  and @cooktheryan I'd appreciate a look from some of those folks to make sure we're not breaking anything.

@cooktheryan et al: I was wondering whether we would have this role just generate the docker-storage-setup file and remove packaging and service setup (and leave that on additional playbooks/roles.

A couple of things:

It seems like "container-storage-setup" is the preferred method for >7.4 versions[1][2] (I think to be able to replace docker with other container technologies)
Starting docker service is not required to create the proper configuration files, just calling docker-storage-setup (or container-storage-setup) is enough (to decouple it from docker installation as @tomassedovic said)
container-storage-setup is provided by the container-storage-setup package[4] and should be executed before starting the docker service
docker-storage-setup is provided by the docker package[4] and should be executed before starting the docker service[4], so if using docker-storage-setup it is required the docker package to be installed.

My 2 cents.
[1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html/managing_containers/managing_storage_with_docker_formatted_containers
[2] https://github.com/projectatomic/container-storage-setup
[3]
[edu@edu-rhel7 ~]$ which container-storage-setup
/usr/bin/container-storage-setup
[edu@edu-rhel7 ~]$ rpm -qf /usr/bin/container-storage-setup
container-storage-setup-0.6.0-1.gite67c964.el7.noarch

[4]
[edu@edu-rhel7 ~]$ which docker-storage-setup
/usr/bin/docker-storage-setup
[edu@edu-rhel7 ~]$ rpm -qf /usr/bin/docker-storage-setup
docker-1.12.6-55.gitc4618fb.el7.x86_64

Thanks @e-minguez! I didn't know about container-storage-setup.
In my (limited) testing, Docker seems to run docker-storage-setup when it starts (maybe just on the first start). I didn't dig into it, but it looks like running the docker-storage-setup binary isn't strictly-speaking necessary. But if docker-storage-setup fails, Docker will start without it -- if we ran it manually, we'd get some errors back.

I think docker service will start docker-storage-setup as it is a requirement:
[root@edu-rhel7 ~]# grep Wants /usr/lib/systemd/system/docker.service
Wants=docker-storage-setup.service

Running docker-storage-setup doesn't do anything if the docker storage has been configured and according to the official documentation, running docker-storage-setup should be done previous to start the docker.service[1]
So, from my point of view, I think we should stick to just docker-storage-setup tasks, including:

Check RHEL/CentOS version
If >= 7.4, install container-storage-setup, apply the overlay2 template and run the container-storage-setup command
If <7.4, install docker, apply the dm template and run the docker-storage-setup command
Leave the docker service startup to another role if we want, or restart & enable it here

[1] https://docs.openshift.com/container-platform/3.6/install_config/install/host_preparation.html#configuring-docker-storage

@e-minguez thank you for valuable configuration bits for docker in >=7.4!
I believe the purpose of this initial step is only reusing the openshift-ansible roles as is without additional required modifications. We may want to add the >=7.4 support in the follow up patches. @tomassedovic , thoughts? If we have to adjust something for the <7.4, would be nice to make it openshift-ansible side though, as a dependency patch.

Adding @dav1x and @cwilkers as they use this for their VMware and RHV ref. archs.


As a user, I want to sort a list of all cities in a specific district, organized by population from largest to smallest so that I can identify the most populous cities within the district

SQL:

Added report11.xml to the feature/reports branch


Implement isclose

I implemented isclose.
I want to discuss its specification for scalar values. When input values are scalars, numpy returns bool object. But in cupy, we need to transfer the data. I use cupy.ndarray in such case in this PR same as cupy.sum. How do you think about this problem?

merge #789 first

jenkins test this please

Please check test result.

jenkins test this please

LGTM!


"opencart-2checkout-api" is not working with Opencart3 or Opencart <IP_ADDRESS>

I have tried your plugin on my both websites but it is not working with either one. Kindly tell me how can I get this plugin work for me?

Becase wasn't made for 3.x or 1.5.

Is there any working 2checkout extension for opencart3?

You can hire somebody to convert.

Thanks. I can't afford to convert it. But I will try to convert it myself.
I have tried 2Checkout version from 3.x, it was always fetching price incorrectly like default currency is Euro, order placed in 200 euro, 2Checkout will show 200$ instead of charging in Euro.
2nd client has to enter his/her data again on 2Checkout form. I want to design one-page checkout f. Only 2Checkout is available in Pakistan for payment receiving online.
I am trying to solve these issues but not able to solve them. Also, it was not showing cart after redirection it created Invoice link for redirection without website header and footer.
I am looking for its solution but still no luck. If you have any information let me know. Also, give me hints how can I convert this extension for Opencart 3.x.

Can you tell exactly which version of Opencart work with this plugin?

condor2 and I are working on a version for 3.x, you can checkout the branch at https://github.com/craigchristenson/opencart-2checkout-api/tree/condor2-v3.0

condor2 and I are working on a version for 3.x, you can checkout the branch at https://github.com/craigchristenson/opencart-2checkout-api/tree/condor2-v3.0

I have tried the new version but it is giving "Unauthorized" error when card data is filled.

That error comes from 2Checkout and means that your 2Checkout publishable and private key credentials are wrong. Make sure that you are using your production credentals and that you have sandbox mode unchecked in the configuration.

That error comes from 2Checkout and means that your 2Checkout publishable and private key credentials are wrong. Make sure that you are using your production credentals and that you have sandbox mode unchecked in the configuration.

Thanks. I will try that and let you know.

That error comes from 2Checkout and means that your 2Checkout publishable and private key credentials are wrong. Make sure that you are using your production credentals and that you have sandbox mode unchecked in the configuration.

I have tried your new extension but it is still not authorized to make payment hence all information is correct. I have checked the information several times with your instructions, 2checkout details, and opencart details. There was only "Secret Word" in opencart extension, I could not find it.
I really appreciate your help. Kindly guide me what could be the reason?

Hi Abdul, please contact me directly at<EMAIL_ADDRESS>with
your contact details.  We can do a screen sharing session and figure out
what's going on.
On Sun, Nov 24, 2019, 7:11 AM Abdul Wadood<EMAIL_ADDRESS>wrote:

That error comes from 2Checkout and means that your 2Checkout publishable
and private key credentials are wrong. Make sure that you are using your
production credentals and that you have sandbox mode unchecked in the
configuration.
I have tried your new extension but it is still not authorized to make
payment hence all information is correct. I have checked the information
several times with your instructions, 2checkout details, and opencart
details. There was only "Secret Word" in opencart extension, I could not
find it.
I really appreciate your help. Kindly guide me what could be the reason?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/craigchristenson/opencart-2checkout-api/issues/18?email_source=notifications&email_token=AAB5MZIXN5QL4VFLYGTHQO3QVJVPRA5CNFSM4JKKJJ4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFAJ2XA#issuecomment-557882716,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAB5MZJ4L5IE62ZB5UP5UZDQVJVPRANCNFSM4JKKJJ4A
.

Thanks for your support. As you mentioned before it was happening because of 2Checkout account. I got in touch with 2Checkout team and diagnose the issue with me and resolve it.
Thank you for your support. I really appreciate it.


docs: HoneybadgerBFT

Related Issue
resolve: #20
Description
[WIP] docs: HoneybadgerBFT
Checklist
Thank you for your contribution.
Before submitting this PR, please make sure:

[ ] Test case
[ ] End of Work

TODO: English doc required


A contact with 'other' or blank label for email or/and phone could be treated better

When a contact has an email address or phone with no label or label 'other' the send mail looks like that:

There is no label in sent email for that.
We could resolve it in a way suggested by me in 87f39760a6ca0982a2239a742621c55651641035

BTW: you could simplify the following:
var emailLabel = String(emailField.getLabel());
if (emailLabel === '') emailLabel = 'email';
...
var phoneLabel = String(phoneField.getLabel());
if (phoneLabel === '') phoneLabel = 'phone';

to:
var emailLabel = String(emailField.getLabel()) || 'email';
...
var phoneLabel = String(phoneField.getLabel()) || 'phone';

When coding major-rewriting I purposefully added this: I thought that with the addition of multiple emails the line of text with the contact information was becoming quite crowded and I did not want to add what I thought was unnecessary noise to it.
However we can always discuss this.
What are your thoughts on this @rowanthorpe?

I don't have a strong personal preference either way. If pushed to suggest a favourite, I would propose:
Jemimah Puddleduck - Age: 3 (Home email<EMAIL_ADDRESS>Work email<EMAIL_ADDRESS>Other email(s<EMAIL_ADDRESS>-<EMAIL_ADDRESS>Mobile phone: +xxxxx, Home phone: +xxxxx, Other phone(s): +xxxxx - +xxxxx - +xxxxx)

...where the "other email/phone(s)" are all those which came up with labels of "other", "null", "", "-1", "[stack trace]", "you-get-the-point"...

BTW: @GioBonvi: to just use this thread to mention an unrelated point without opening a whole separate issue just for that - I noticed when updating documentation you changed the numbered list from:
1. blah
1. other blah
1. other blah

to:
1. blah
2. other blah
3. other blah

so just in case you thought those were typos/oversights, I numbered them all with 1. on purpose. That way you can cut-paste, splice, rearrange, delete and reorder numbered-lists as much as you like and the markdown-parser always takes care of numbering the list correctly in the end anyway, without the human maintenance-burden. As mentioned here the parser only needs to see the [any-integer]-[dot]-[space] and will produce self-ordered numbering anyway, irrespective of whether the source is sequentially numbered or not. It mentions that to be future-proof it is a good idea to always start the list with 1 though, because in future they may add a feature for starting a list from higher-than-1 if the first number is higher. If you still prefer manually number-ordering the markdown-source (and the added burden that comes with it) then ignore this, but if it was just because you thought I typo-ed, I'm letting you know.

So in commit 21d414e998af1e4ac268877dec5dec0e0545a516 I did my version. However the solution suggested by @rowanthorpe is IMO better.

@rowanthorpe yes I usually prefer to use the explicit version of the numbered list because on GitHub it can be used to force a list to start on any number: I had once some trouble with an auto-completed list misinterpreting some spaces as "end of the list" thus splitting the list in two different ones.
Since then I decided to go with the "dumb" method.
@baatochan yes, I prefer it as well, so I'd go ahead with it. Who wants to implement it?

As we talk about labels I also noticed that strings for two official Google labels are missing (google voice and pager). I know that those values are not used by most of the people but we can add strings for them (even without translation) or treat them like others which are gonna be implemented.

And speaking about the implementation of @rowanthorpe idea - I don't think I'll be able to do it. It's too complicated for me.

I am working on a PR for the new formatting now.

@baatochan I've tracked down the problem that caused your own birthday to be split into two different lines. The birthday from the event was saved with label "SELF", while the birthday from Google Plus (which is obtained as the event contains your G+ id) was saved as "BIRTHDAY".
I have coded a solution for this, but will push it together with other fixes I am working on right now.

@baatochan

As we talk about labels I also noticed that strings for two official Google labels are missing (google voice and pager). I know that those values are not used by most of the people but we can add strings for them (even without translation) or treat them like others which are gonna be implemented.

I've added this to a list of fixes I am working on: I'm pushing it for review as soon as I've finished them.


describing QB queries

I notice that in the query results list the description of the query  effectively appears twice. This make it much harder to read the lists.

So,
characterization status: conserved unknown
characterization_status_conserved_unknown
can we omit the second one?

Done!  It was showing both the internal ID and the user friendly name.


Add /geolocate endpoint that returns all geoidentifers for a given lat,long

Description
Addresses: API skeleton (AWS api gateway + lambda creation) C1_FR2
Adds lambda and api gateway endpoint for /geolocate which queries our geometry tables to find intersections with a lat,long pair. Reflects design in here
New
ApiStack which initializes the gateway resource and endpoint
Geolocate lambda
Testing and Reviewing
Tested via AWS Gateway test event

Feel free to ignore the review, Alex. I noticed Aaron was out and you're a reviewer on the doc so I thought I'd loop you in


Updates version to 5.1.0-SNAPSHOT for continued development.

Updates the version of the master branch to make way for the release candidate branch.

@whikloj :  good catch on those missed pom references.  I've updated the PR.


Is GraphQl-Yoga in active development

Hi, I read a couple of articles on the future of GraphQL-Yoga which is impacted by Apollo server 2.0 release. I have started using Yoga with Prisma for one of my side project applications that I want to scale up. Do you suggest to me that I stick with Yoga? I am utterly confused

@prisma-label-sync-bot  can someone help me with this query?

I think it's probably best to switch to apollo2 if you can, based on this
https://blog.apollographql.com/announcing-apollo-server-2-2b69fb4702ce

The idea to bundle all the features together into one constructor echoes Prisma’s approach with graphql-yoga. We really liked how it followed our goal of making GraphQL API development more approachable, so we decided that a similar API should be the entry point for Apollo Server 2. Thank you again to the Prisma team for the inspiration and for always pushing the GraphQL community forward.

https://github.com/prisma-labs/graphql-yoga/issues/382#issuecomment-408390953
#449
I switched today with only a few changes needed to my code, like
req.request.get("Authorization") -> req.headers.authorization 😄

Perhaps it would be best to mark this project as unmaintained. The docs for Now deployment, just don't work.

Hey @yesprasad @rafma0 @phishy  we @the-guild-org are the new maintainers of this project. We are actively developing v2. Would love to get your feedback on beta release @graphql-yoga/node@beta https://www.graphql-yoga.com


ENHANCEMENT: automated validation

RE: automated validation
If AutoHotKey is listed as a dependency, skip the message:

notSilent tag is being used. The reviewer will ensure this is being used appropriately. More...

All packages using AHK should have notsilent as a tag.

I'm not sure what problem this is trying to resolve.


fix: update UUID regex

:tada: This PR is included in version 1.0.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


nodePackages: add ts-node

Description of changes
This PR is a follow up on https://github.com/NixOS/nixpkgs/pull/144802, adds the nodePackage ts-node' and solves the issue of the typescript` peer dependency.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

@jraygauthier Please try again. I regenerated node-packages.nix and now it should work. If it works for everyone, we could skip this file to avoid merge conflicts

We could merge it without regernating node-packages.nix and hope it get regenerated in a later PR ;)

There is already a merge conflict.
let's not include the node-packages change.
When someone regenerate node-packages it will be included anyways.

Merge conflict is gone :)

The ci is failing. Perhaps it's a naming problem ?
(you can see the ci at the bottom with all the checks).

@happysalada : CI appears to be failing with the exact same here I had when node-packages did not exist. See above comment:

nix-env failed:
warning: ignoring the user-specified setting 'restrict-eval', because it is a restricted setting and you are not a trusted user
error: while evaluating anonymous function at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/ofborg-evaluator-4/.gc-of-borg-outpaths.nix:47:12, called from undefined position:
while evaluating anonymous function at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/ofborg-evaluator-4/pkgs/top-level/release-lib.nix:123:6, called from /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/ofborg-evaluator-4/lib/attrsets.nix:414:43:
while evaluating 'hydraJob' at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/ofborg-evaluator-4/lib/customisation.nix:218:14, called from /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/ofborg-evaluator-4/pkgs/top-level/release-lib.nix:123:14:
while evaluating the attribute 'name' at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/ofborg-evaluator-4/lib/customisation.nix:223:24:
while evaluating the attribute 'name' at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/ofborg-evaluator-4/pkgs/stdenv/generic/make-derivation.nix:205:7:
while evaluating anonymous function at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/ofborg-evaluator-4/lib/strings.nix:762:3, called from /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/ofborg-evaluator-4/pkgs/stdenv/generic/make-derivation.nix:222:9:
while evaluating the attribute 'version' at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/ofborg-evaluator-4/pkgs/data/fonts/iosevka/default.nix:68:24:
while evaluating 'findSingle' at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/ofborg-evaluator-4/lib/lists.nix:177:5, called from /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/ofborg-evaluator-4/pkgs/data/fonts/iosevka/default.nix:59:5:
while evaluating anonymous function at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/ofborg-evaluator-4/pkgs/data/fonts/iosevka/default.nix:60:8, called from undefined position:
attribute 'ts-node' missing, at /var/lib/ofborg/checkout/repo/38dca4e3aa6bca43ea96d2fcc04e8229/mr-est/ofborg-evaluator-4/pkgs/development/node-packages/default.nix:462:15

I guess this is because node-packages.nix is not regenerated. Should I try to generate it again?

yeah, I guees so.
I tried to look at every place a node packages should be, and the only 2 places appart from node-packages you have changed already.
I guess we can't get the ci to pass if it's not generated.
There should only be conflict if someone is trying to update it. I can't imagine that many people trying to go through the pain of updating node-packages, it's weird.
let's regenerate and hope for the best.
I'll stay close to be ready to merge as soon as it's good.

yeah, I guees so. I tried to look at every place a node packages should be, and the only 2 places appart from node-packages you have changed already. I guess we can't get the ci to pass if it's not generated. There should only be conflict if someone is trying to update it. I can't imagine that many people trying to go through the pain of updating node-packages, it's weird. let's regenerate and hope for the best. I'll stay close to be ready to merge as soon as it's good.

okay ready :)

all good, thank you for being so patient !


EDITOR-#181 enable frame to save time forward.

What is this PR for?

We now enable frame to edit time forward.
What type of PR is it?
[Bug Fix | Improvement | Feature | Documentation | Hot Fix | Refactoring]
Bug Fix
Todos

[ ] - enable frames to shift time across other frames (frontend)

What is the Github issue?

https://github.com/NTUEELightDance/LightDance-Editor/issues/181
How should this be tested?

edit a frame and move its start time forward
Screenshots (if appropriate)
Questions:

Do the license files need updating? No
Are there breaking changes for older versions? No
Does this need new documentation? No

There are some code format difference. I did run "yarn run format" under /editor, but it seemed the same.

There is another bug. We haven't come up with a thorough solution to shifting and inserting any frame anywhere.
If you do now, the order in frame record will be messed up. However, it will be fine after refreshing.

I have tested and the logic is still wrong.

Don't have to put editingData in getHandler, it can purely get by state.editingData in the function.
You should modify the logic to not changing the currentStatus, currentControlIndex and currentPosIndex on EDITING mode


Post: Scaling part 2

This is the second part in a series of 3.

I wanted to first show just how to run etcd and kube-apiserver without all the CAPI stuff. That way it can be useful also for other use cases. However, it ended up making this post pretty long. Do you think it is too much? Would it be better to just skip that part?

Thanks @tuminoid for the feedback! This makes sense! I will make a separate section for etcd :slightly_smiling_face:

/assign @elfosardo

/approve

Oh come on! The pre-commit keeps changing this back and forth. If anyone has an idea about why, please let me know.
 -  "ignoreText": [
-    [
-      "^layout:.*$",
-      "m"
-    ]
-  ],
+  "ignoreText": [["^layout:.*$", "m"]],

/lgtm

Thanks @hroyrh ! All nits fixed :slightly_smiling_face:

/approve


enable EncodeType.TypeChunk with TiKV

cause we disable it here https://github.com/pingcap/tispark/pull/1391

Closed by https://github.com/pingcap/tispark/pull/1425


Make Python files more PEP8 compliant

Description
Really excited for this project!  After reviewing the code using a Atom's linter-pycodestyle 2.0.2 linter, I noticed there were quite a few PEP8 violations (https://www.python.org/dev/peps/pep-0008/).  There is a mix of tabs/spaces for indentations, 1-2 new lines after classes/functions, testing conditional to None using "=" instead of none, and one-line if statements.
Motivation and Context
Standardizes files and makes them easier to read and debug.  This is OCD, but it's better to address this early on in the project than later.  In my linter config, I ignore error codes: E265, E266, E501 (http://pep8.readthedocs.io/en/release-1.7.x/intro.html).  I addressed the cosmetic ones and didn't touch functional ones that I am not sure what they do, like line 1380 in nexpose.py
requestor = lambda: self.RequestSiteScanHistory(site_or_id)
I also didn't touch imports that were not at the top of the file.
How Has This Been Tested?
Ran pytest
python -m pytest
================================================== test session starts ==================================================
platform linux2 -- Python 2.7.13, pytest-2.9.2, py-1.4.31, pluggy-0.3.1
rootdir: /home/user/nexpose-client-python, inifile:
collected 27 items

tests/test_LoadFixture.py ...
tests/test_NexposeNode.py .
tests/test_NexposeReportConfigurationSummary.py ..
tests/test_NexposeSession.py ...........
tests/test_NexposeTag.py .....
tests/test_NexposeUserAuthenticatorSummary.py .
tests/test_NexposeVulnerability.py ....

=============================================== 27 passed in 0.94 seconds ===============================================

Types of changes
Replaced tabs with 4 spaces, added new lines after functions/classes, removed one-line if statements, added/removed spaces around variables, and added two spaces after end of lines that contained comments.
Checklist:

[N/A] I have updated the documentation accordingly (if changes are required).
[N/A ] I have added tests to cover my changes.
[x] All new and existing tests passed.

Thanks for this! I need to setup travis-ci to run tests and a linter as well at some point.
By the way your git config seems to have an issue based on the user associated to your commits. I'll wait for you to decide if you want to fix that or not before merging. Fixing it might involve re-playing the commits to a new branch and opening a new pull request.

Are you referring to the "invalid-email-address"?  I'll probably create a new branch.

Created a new PR: https://github.com/rapid7/nexpose-client-python/pull/16
This one can be closed.


Fourier design matrix definition consistency

This is perhaps controversial, but I consider the way we define our Fourier design matrices in Enterprise not clear or clean enough.
The Fourier design matrix is closely related to the DFT and least-squares spectral analysis. Ideally, we would use definitions that generalize the definition of the DFT used elsewhere in the literature. In scipy/numpy, the DFT/FFT is defined in a way that makes the DFT a unitary transformation with normalizations for various purposes:

norm='ortho': the DFT is a unitary transformation, meaning that np.dot(F.T, F) = np.identity(nobs)
norm='forward': the standard definition of a DFT
norm='backward': going back from the Fourier coefficients to the original data (inverse of 'forward')

In Enterprise (or anywhere in the PTA literature), we use a different definition introduced by the Lentati et al. paper. That definition is closely related to the 'backward' normalization. The only difference is that, for regularly sampled data, our frequency spacing 'Delta f' is off from the standard definition. This is because for a dataset with N observations, you actually only have (N-1) spacings between observations. So the total observation length T is different from the definition you would use for regularly sampled data. For regularly sampled data, one would use the definition T = N * Delta_t. This results in a different multiplicative factor for the frequency spacing of N/(N-1).
I am of the opinion that our definition of the Fourier design matrix should generalize to the usual definition of the DFT for regularly sampled data. The advantage of doing that is also that our Fourier modes would become truly orthogonal for regularly sampled data. Currently, they do not have that property. In practice, this is not a big difference, but it is not optimal.
We can fix this consistency in the gp_bases.py file, by adding a norm keyword. Basically, I would suggest modifying with codeblock that is something similar to:
if norm == 'legacy':
    deltaf = 1.0/T
    const = 1.0
elif norm == 'ortho':
    deltaf = (N-1.0) / (N*T)
    const = np.sqrt(2.0/N)
elif norm == 'forward':
    deltaf = (N-1.0) / (N*T)
    const = 2.0/N
elif norm == 'backward':
    deltaf = (N-1.0) / (N*T)
    const = 1.0

If we need to match different datasets, instead of passing the total observation time Tspan, we should be passing deltaf, because we actually intend on matching the frequency spacing and not the observation time.

I'm not sure this is a good idea.  We're doing something pretty strange already, because we treat the signal as periodic when it isn't. (Yongqi Zhang and I are trying to understand how important the effect of this is and what can be done about it, following your ideas from a while back, Rutger.) Furthermore, typically Tspan is the total timespan of observation, and we analyze every pulsar with the same frequencies n/Tspan.  Generally the first and last observation are not of the same pulsar.  If I understand what you're saying, you're imagining one pulsar that was observed at 1:00, 2:00, 3:00, and 4:00.  So T = 3 hours. If these were equally spaced samples of a periodic signal, the period of the signal would be 4 hours rather than 3, so the frequency spacing should be deltaf = 1/(4 hours) not 1/T.  (But this is N/((N+1) T) rather than (N-1)/(N T) as you suggested, so perhaps I misunderstood.) In any case, it seems to me that this distinction is unimportant here, because this is not a periodic signal.  When we model nonperiodic signals as periodic, the choice of period is rather arbitrary.  So perhaps for the sake of simplicity it might be best to stick with n/Tspan. Otherwise it will be very confusing for the user of our data who looks up the actual frequencies we used and tries to understand why we chose them.

For a PTA, we can define deltaf in a way that makes sense to us. Giving it deltaf=1/Tmax with Tmax the same way we do now is totally reasonable. Also, there is no 'right' way to choose those frequencies, and I am not arguing to modify those.
However, for a single pulsar I think it is a little inconsistent what we are doing now.
Just try to do Fourier analysis of regularly sampled data with an FFT. See if you can understand why the frequencies are chosen by the FFT package. Discrete Fourier Transforms are very well-understood and standardized. All I am arguing is to use the same definitions. I have done the cross-checks, and I can reproduce the results of an FFT to machine precision with the modifications I posted above.

I agree on several points: the user should be specifying deltaf rather than T, not in the least because T is also ambiguous when there are several pulsars, but also because of the other issue we mentioned above.
Also agree regarding counting epochs rather than observations, although this is something than one can argue about.
Most of all, I think we would like "sane defaults", and options. The different normalizations should be options with the same names as in scipy ('forward'/'backward'/'ortho' -- we only use 'backward' now). The defaults IMO ideally would be equal to the FFT frequency bins for regularly sampled data (in epochs).

We should probably keep Tspan in there for compatibility. Since it is None by default it is easy to add a deltaf keyword.
I agree that we should not pass anything like Nepochs or whatever. If they need that kind of processing they can pass deltaf. And 't' is passed, so we have N already, so the normalization can be calculated.
My suggestion would be to default to the scipy/FFT deltaf going forward so we do not confuse people who would want to use such tools in conjunction with Enterprise, but that can also just be done conditional on a keyword that is checked if both Tspan and deltaf are set to None.
So:

Keep Tspan. Default None
Add deltaf keyword. Default None
Add norm argument with 'forward'/'backward'/'ortho', with meaning just as in scipy. Default is 'backward' (which is what it currently does)
Decide on default for deltaf if no Tspan or deltaf keyword is passed: either the FFT/scipy convention, or 1/T. The two conventions are almost identical, and make little difference unless you are comparing higher frequency results.

OK.  So by default you will use the current normalization, for which you don't need to know N.  If the user specifies 'forward' or 'ortho', you'll use a different normalization with N = len(toas)?  That's fine with me.
My preference would be to raise an exception if the caller specifies neither Tspan nor deltaf.  The present default is to use the max-min toa for the specific pulsar under analysis, and this sometimes causes trouble when the person was expecting the max-min toa for the whole PTA.  It also makes you unhappy because it's missing the (N+1)/N factor.  And it's not very hard to just say Tspan=toas.max()-toas.min() if you want that.  The only reason not to do this is to keep it compatible with old code.  I don't know how important this is.
I would strongly oppose silently changing to a different convention.  It's one thing to break people's code and require them to make a small change to their calls, quite another to make their code give different answers, even if they are only slightly different.
I would also favor raising an exception if the user specifies both deltaf and Tspan.

This won't ever be changed, at least not in Enterprise. Closing


Allow integer indexing (closes #92)

This PR contains a few related changes for various issues:

Indexing arrays in Value::find() (#92)
Providing partial array values from Env (#113)
Necessitated by the Env change, new strategies zipjoin/zipmerge, which allow partially overwriting arrays and values inside arrays.

@thorio ran a quick test with my use case
Works like a charm for both top level arrays and also arrays in sub-keys :crown:

@SergioBenitez could you take a look at this?

I fixed all the issues with obvious solutions, I think the rest warrant further discussion.
The big benefit with the zip- strategies is the handling of "there is no value here" values, without it the Env provider would not work correctly for MYARRAY.0=10, MYARRAY.1=20. I picked None for this because it was the simplest option, as well as being fairly pointless in arrays (you'd just remove the entry and shorten the array instead of putting None there).
This also touches on #112, where the user wanted a way to specify "there is no value here", such that None would not replace the previous Some value.
So we need to differentiate between these three cases when merge-ing:

"I have an incoming value and I want to replace the existing value" => Some(value)
"I do not have an incoming value and want to remove the existing value" => None
"I do not have an incoming value and want to leave existing value untouched" => ???

join-ing works the same way, with "incoming value" and "existing value" swapped.
Thus I think we do need something like Value::Void that will always be replaced, regardless of strategy, such that
            [1, 2, _, 4]
merged with [_, 8, 3, _]
becomes     [1, 8, 3, 4]        where _ is this "void" value.


Flatten op_args to be able to find nested widgets

Needs https://github.com/holoviz/holoviews/pull/5184 to work

The error could be recreated with
import xarray as xr
import hvplot.xarray # noqa
import panel.widgets as pnw

ds = xr.tutorial.load_dataset('air_temperature')
diff = ds.air.interactive.sel(time=pnw.DiscreteSlider) - ds.air.mean('time')
kind = pnw.Select(options=['contour', 'contourf', 'image'])
diff.hvplot(cmap='RdBu_r', clim=(-20, 20), kind=kind)

The custom flatten function will be added with https://github.com/holoviz/holoviews/pull/5184. Alternative I could also add it to hvplot.

If I understand correctly, I think having it in HoloViews should be sufficient; no need to duplicate that.

You understood it correctly.

With the release of Holoviews 1.14.8, can I get one to rerun the tests?

Thanks, @Hoxbro for the cool new functionality, and thanks @sophiamyang for reporting the issue and inspiring him to do this work!


Fails to detect USB drive from Docker container

Etcher version: 1.4.4
Operating system and architecture: Debian GNU/Linux 9 (running on Docker version 18.03.1-ce, build 9ee9f40)
Image flashed: N/A
Do you see any meaningful error information in the DevTools? No.

etcher-cli fails to detect a USB drive passed through to a Docker container, via docker run -it --privileged -v /dev/bus/usb:/dev/bus/usb duckietown/image-builder. Displays the following message:
x No available drives were detected, plug one in!

This is the output of lsblk:
root@7bae958062e3:/go# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0         7:0    0 364.8M  1 loop
loop1         7:1    0 364.1M  1 loop
loop2         7:2    0 365.2M  1 loop
loop3         7:3    0  86.6M  1 loop
loop4         7:4    0 591.1M  1 loop
loop5         7:5    0 143.9M  1 loop
loop6         7:6    0 590.7M  1 loop
loop7         7:7    0 565.6M  1 loop
loop8         7:8    0  93.5M  1 loop
sda           8:0    1  59.5G  0 disk
|-sda1        8:1    1    64M  0 part
`-sda2        8:2    1  59.4G  0 part
nvme0n1     259:0    0   477G  0 disk
|-nvme0n1p1 259:1    0   499M  0 part
|-nvme0n1p2 259:2        100M  0 part
|-nvme0n1p3 259:3    0    16M  0 part
|-nvme0n1p4 259:4       48.2G  0 part
|-nvme0n1p5 259:5    0 412.3G  0 part /etc/hosts
`-nvme0n1p6 259:6    0  15.9G  0 part

Expected result is etcher-cli should have detected sda as a valid USB device.

It might be worth opening an issue for this on https://github.com/resin-io-modules/drivelist (which is the module Etcher uses to list drives)

While #1420 seems like a viable workaround, I don't think this is a duplicate, but some issue with USB drive detection that causes it to fail inside Docker environments.


Configure CI for the hugo website

This site is powered by hugo. Let's configure continuous integration so we don't have to build manually before deploying.
Possible guidelines: https://www.metachris.com/2017/04/continuous-deployment-hugo---travis-ci--github-pages/

You can do that by configuring a token in Travis (or wherever), or locally by creating a post-commit hook. I can do the second, although it will have to be installed by hand by linking it from the .git/hooks directory.

feel free to pick this up! <3

whoops, that label was a slip of the finger. This is not a first timers issue!

So I didn't quite understand how the post-commit hook works - I was assuming that it would run on travis (even though you did say above it ran locally!). The hook is great but it doesn't stop people from accidentally commiting changes that won't be reflected on the website.
We have two things we could configure for travis

[ ] build hugo and push to the repo
[ ] build the r script in this pr: https://github.com/yochannah/code-is-science/pull/33

El vie., 11 may. 2018 a las 12:55, Yo Yehudi<EMAIL_ADDRESS>escribió:

So I didn't quite understand how the post-commit hook works - I was
assuming that it would run on travis (even though you did say above it ran
locally!). The hook is great but it doesn't stop people from accidentally
commiting changes that won't be reflected on the website.

When you install it locally, it automatically runs Hugo.

We have two things we could configure for travis

build hugo and push to the repo

That's that the post-commit hook does. Well, it does not push, but it
builds, then you can commit and push. Commit can also be done automatically
with some standard message, if needed.

committing with a standard message (and maybe even push) would be brilliant!
On Fri, May 11, 2018 at 12:29 PM Juan Julián Merelo Guervós <
<EMAIL_ADDRESS>wrote:

El vie., 11 may. 2018 a las 12:55, Yo Yehudi<EMAIL_ADDRESS>escribió:

So I didn't quite understand how the post-commit hook works - I was
assuming that it would run on travis (even though you did say above it
ran
locally!). The hook is great but it doesn't stop people from accidentally
commiting changes that won't be reflected on the website.

When you install it locally, it automatically runs Hugo.

We have two things we could configure for travis

build hugo and push to the repo

That's that the post-commit hook does. Well, it does not push, but it
builds, then you can commit and push. Commit can also be done automatically
with some standard message, if needed.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/yochannah/code-is-science/issues/20#issuecomment-388337880,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AI14jv8IMaKc04Udjvlwe484p9tO2Zdaks5txXY1gaJpZM4RP4Vt
.

Sounds like the post-commit hook is for running hugo locally on each commit, such that the website files get updated and included?
The common Travis CI configurations I've seen generate the website files and push them to a different branch, which GitHub Pages (or another service) then uses for the website. Is that where this issue is headed?

@ha0ye ideally, yes - that way someone who doesn't have hugo on their
machine could still update the site
On Fri, May 11, 2018 at 3:14 PM Hao Ye<EMAIL_ADDRESS>wrote:

Sounds like the post-commit hook is for running hugo locally on each
commit, such that the website files get updated and included?
The common Travis CI configurations I've seen generate the website files
and push them to a different branch, which GitHub Pages (or another
service) then uses for the website. Is that where this issue is headed?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/yochannah/code-is-science/issues/20#issuecomment-388376269,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AI14jhTkP8PwAxXQSGE4ZLio1dBImPaVks5txZzUgaJpZM4RP4Vt
.

@ha0ye that's correct, that's what it does.
@yochannah if you want Travis to update stuff for you this can still be used, but let's look at several scenarios here.

In the first one, you have to set up your GitHub API key in Travis so that Travis can write to your repo. Then every time someone with push access to the repo does that, Travis pushes back to GitHub . That implies setting up the operation in Travis: you do have the repo there, but if I'm not wrong not the whole history, probably that is not needed, but you will definitely have Hugo installed, no big deal either, but you need to have a Go configuration... Which prevents Travis, or at least makes it more difficult, to run any other kind of tests... Besides, it's making a push to Hugo for every commit, and you might not want to have that. In some cases, that might be slow and you might have to be waiting for the next changes to be done. Then, someone with write access might actually have Hugo installed, and you will have to check out whether you actually need to run it... baseline is: uploaded API key, complicated Travis configuration, might not be needed after all, because if someone with push access can't install Hugo, next one can do it probably.
Second scenario are pull requests. These PRs can't access local configuration and env variables for security reasons. No big deal, because when you actually accept the PR it's a push and then you do have permission...
Third scenario is people without write access before the pull request. They will either have to set up Hugo locally or else upload their API key so that their Travis account publishes to their repo... And that might imply to change the Travis tooling to work on their repo...

Baseline is: putting Travis in the loop which, as far as I understand it, is already going to take care of generating a table from Google Drive, is going to too much trouble when you can simply have one or two persons with write access to have Hugo installed, even automatically running as a post-commit hook, and do a @-message in a commit message to do the page generation for you, I guess.
You save going to the command line when accepting PRs to generate the pages again, but you will have to create instead some complicated tooling...
Anyway, your call. Also take into account that other sites, like Shippable or Circle-CI, are kinda better to do this kind of continuous delivery, so maybe several of them could be set up, one for each task...


Suggest adding Spencer regex libraries

Henry Spencer wrote multiple regex libraries which were historically important and are still relevant today: https://garyhouston.github.io/regex/
The one that survives in production code today are the Tcl library which is used in both Tcl and Postgres.
It would be very interesting to know how they fare as they have a number of different approaches from the other historical lineages of regex library, many of which have not been picked up by modern implementations.
The Postgres regex engine supports a lot of modern features like being able to turn on/off greediness per capture group and supporting unicode (well whatever the OS puts in wchar_t).

It sounds good. If you want to contribute adding some libraries check the Contributing section in the readme.


Fixes Zendesk variations & allows for loader switching

There were errors being thrown in the Zendesk loader due to the convertHtml missing making the variations arry null. I also updated the readme to allow for easier switching between either the genesys loader or Zendesk loader.

ill move this to the "HtmlTransformer()" and do a fresh PR as well as move the loader option to a .env as it will be cleaner after talking with Peter


Add pundit policies

Following #309 we need to add dedicated pundit policies for each controller/resource
currently, in the controllers there is a function to bypass pundit
def skip_pundit?
      # TODO add a real policy
      true
end

This function should be removed and proper authorization shall be performed on all the following controllers

[ ] confirmation_controller
[ ] matches_controller
[x] partners
[x] users
[ ] admin/home
[ ] admin/search
[ ] admin/vaccincation_centers
[ ] partners/campaigns
[ ] partners/vaccincation_centers

Those are fairly simple contribution maybe a good first issue label can be added to and who ever wants to tackle one controller/policy can simply raise his hand in a comment to this issue.

See #419 for the admin namespace.


yeoman, grunt, bower --> web components e.g. with Google's Polymer

why not shift this scaffolding into a yeoman generator such as https://github.com/Pent/generator-meteor ? This way one could use all the benefits of grunt, yo, bower as well. That makes especially sense on the upcoming web components revolution e.g. if one would use Meteor + Polymer for example.

This is a good idea but it will make meteoris to be reworked almost every code.
So anyone willing to help are welcome.

I think using a more template-like syntax for the boilerplate would be helpful (right now it is just a search for "replace"), but I agree with @MercedesAMG1 -- overcomplicating this simple tool with grunt et al. would add an unnecessary level of complexity to a very simple tool.

I'll close this for now.


Plot title overlaps colorbar

Describe the bug

We probably reduced the figuresize too much in #786.
How to reproduce
Steps to reproduce the behaviour:

Plot a spatial plot.
Observe it is broken.

Expected behaviour

The plot title should not overlap. Probably target 10 by 10 inch figure size, but will have to check. Make sure to test with a long title.
Environment

Version: [e.g. from cset --version]
Browser (if UI issue): [e.g. Chrome, Firefox]

Could possibly determine the plot aspect ratio (given plot operator is passed the cube, ratio of lat/lon size. Will roughly work for mercator projections, or at least be a sensible first order guess), to avoid colorbar conflicts. Could also explore the GridSpec library

Branch: #815_title_overlaps_colourbar


api-version exception when trying to connect to latest on-prem version "Service Bus 1.1 with TLS 1.2"

api-version exception when trying to connect with SB Explorer to latest on-prem version "Service Bus 1.1 with TLS 1.2"
Perhaps this exception can be caught and adjusted to correct api-version? Or omitted from the uri? The error states that it can be removed or use supported ones. Or this is always hard-coded in Microsoft.ServiceBus.dll dependency?
Perhaps possible to set api-version in connection details to be used for this connection?
These are the supported ones reported back: 2012-03,2012-08,2013-04,2013-07
<16:00:20> InnerException: The remote server returned an error: (400) Bad Request. The api-version in the query string is not supported. Either remove it from the Uri or use one of '2012-03,2012-08,2013-04,2013-07'..TrackingId:26a3a3cb-782b-4b76-ae6b-c6e86eb02871_GNEBT201601,TimeStamp:11/20/2020 4:00:20 PM
Send and Receive operations works fine with 2016-07 api-version later DLL. I have used DLL from windowsazure.servicebus.4.1.3.nupkg (3.0.50870.7) without problems. Perhaps only management adds the api-version to the uri?
Repro:
Install SB 1.1 with TLS 1.2 (latest on-prem Service Bus)
:: Download WebPI : https://www.microsoft.com/web/downloads/platform.aspx
:: Online installation:
WebpiCmd.exe /Install /Products:ServiceBus_1_1_TLS_1_2 /AcceptEula
Run Service Bus setup wizard to create default Service Bus installation (ServiceBusDefaultNamespace)
Get SAS KeyName + Key for Endpoint, e g
Get-SBAuthorizationRule -NamespaceName ServiceBusDefaultNamespace
Try to connect with latest SB Explorer. Earlier 2.1 version works fine.

As stated on the README page, the Service Bus Explorer 2.1.0 can be used with the Service Bus for Windows Server 1.1. The Service Bus Explorer 2.1.0 uses a version of the Microsoft.ServiceBus.dll client library which is compatible with the Service Bus for Windows Server 1.1 RTM version. You can download the source code of the Service Bus Explorer 2.1.0 here.

Thanks. I did also some decompiling of multiple Microsoft.ServiceBus.dll clients where I found this hard-coded api-version limitation in there. I will use old 2.1.0.

Thanks @NiklasEMS

@paolosalvatori Hi, we are facing the same issue but with a twist. We can connect to service with TLS 1.0, and 1.1 enabled. But unable to do so with only 1.2 enabled. Any ideas?

Hi, solved this issue by simply bumping the .NET version to '4.7.2'.


training.main

laion-clap.training.main:
    if args.train_data is None:
        optimizer = None
        scheduler = None

according to params.py,The "train_data" here should be "trian-data"

the train-data will be automatically replaced with train_data in argparse, because the python variable cannot allows the "-"  in the naming.


Refactor formik examples to use children instead of render prop

Render prop in Formik is being deprecated for version 2.x. See: https://formik.org/docs/migrating-v2#all-render-props-have-been-deprecated-with-a-console-warning

 Update Formik examples to remove render props.


Handle selection items overflowing several times

PR #14 was good, but not general enough: there were in fact two different bugs hiding. This PR

documents the logic of the dix
fixes an off-by-two error in the logic (which is easy to overlook; I only found that during manual testing),
fixes clear_preserve_prompt to handle items overflowing several times
cleans up the code slightly using iterators (happy to drop this commit if you prefer)
See individual commits for details.

There's a deeper issue underlying this: for any output line which overflows the terminal (i.e. is longer than the terminal width), we only increase the height by one --- even if the line can span several lines on the terminal. When clearing the terminal, we only take the height into account, i.e. will not clear enough output.
This bug also exists is TermThemeRender::clear.
A deeper fix would be to record the length of each line of output, and take this into account when clearing the terminal. (I have prototyped this; it seems workable, if slightly fiddly.)
Counter-arguments I can think of

Not every terminal has a size (see console::TermTarget::ReadWritePair).
Solution: when no size is available, just use the default size. That's no worse than the current state.

This doesn't handle terminal resizing: if we just check the size at clearing time, that can result in both over- or underclearing, depending on whether the terminal was resized in the meantime.
Solution: don't record the number of additional lines, but the lengths of inputs. Compute the height to clear when clearing. Is not hard; we just store some additional data for each line we wrote.

Do we need this? This issue is particularly pronounced for selection prompts (as the selection items need to be drawn over and over, potentially). It's just not as bad for the other prompts.

@psunkara (or other maintainers). Would you prefer to see a "more right" fix instead?

Looks like it.


ENH : adding bibtex / references to credit solvers

That would be great to have a uniform way of crediting the papers / solvers added to the various benchmarks.
For the moment, no credit is given (except may be the github where some sources might be coming from).
Bibtex of the papers might be reasonable start.
Any thought on the way to proceed @agramfort ?

I would go with either the dumb solution :

add a bibtex class attribute to each solver

or (maybe) use a fancy solution like:

https://github.com/duecredit/duecredit

not sure it's worth it though as it adds quite some dependencies

@josephsalmon this can go in the solver's docstring, which is displayed on the HTML page:

if you find it satisfying I'll let you close the issue

That's lovely. Thanks for this solution.


Auto-dark-mode

Description of the new feature / enhancement
Automatic dark mode function for Windows could be to implement a feature similar to the one found on Android devices.
Scenario when this would be used?
By detecting whether it's day or night based on the user's location or time set by the user, the system could automatically switch to a darker mode during nighttime hours to reduce eye strain and improve sleep quality. Additionally, users could have the option to manually enable or disable this feature as needed.
Supporting information
No response

/dup https://github.com/microsoft/PowerToys/issues/1331


Add watch config to all Rust function extension toml

This should not be merged until simplified deployments with app dev support for functions are released.
This PR does not include sample apps. Watch should be added to those when they are updated to the latest CLI.
Tophatting 🎩
(Already completed for all function types in the CLI on MacOS, and basic test on Windows of Delivery Customization.)

Create an appnpm init @shopify/app@nightly

Create an extension from this branchnpm run generate extension -- --clone-url https://github.com/Shopify/function-examples#rust-file-watch

Then choose a function extension, and Rust as the desired flavor.
Add simplified deployments to the created app.
npm run dev and ensure that

The function is built on startup
The function is built on file change

🤔 Even at launch, there will be folks who haven't upgraded yet. If the only way to ship this is to ensure ubiquitous use of simplified deployments we'd need to wait until the opt-in period ends


Update README.md

Drive-by typo fix while reading documentation :)

@ladydascalie Love this fix. Thank you so much for taking the time!


Allow specifying a namespace other than "default" when creating deployments

Right now, when creating deployments with Monocular, it is not possible to specify the namespace, so all deployments happen in the default namespace.
It would be good to be able to specify a different namespace

Should Monocular show existing namespaces, or just provide a textbox to enter the name of the namespace? Although a dropdown of existing namespaces would be nice, it means Monocular will require special RBAC permissions to query the Kubernetes API for namespaces. A textbox doesn't require this as it will just be passed to Tiller.
In the future, we want to add the ability to view/modify resources created by Monocular, so eventually we will require RBAC permissions, I think it's just a question of whether we do this sooner or later.


Changing an entry to a suggestion doesn't carry over tags

[macOS] Editing an entry and choosing a suggestion (from the list based on previous entries) does not update the tags, unlike the description and project.
When you start an old entry (whether by suggestion or by clicking the start button of an old entry), it creates a new entry with the same details (description, project, tags). This works fine. However, if you try to change an entry and choose one of the suggestions, it only carries over description and project, but not the tag.
That is assuming that tasks with the same description and project should have the same tags. We use tags to identify types of tasks, depending on the stage of a project; design, programming, presentation, etc. If I have an existing entry 'write code' for 'project foo' and change another entry to that, it should also change the tag to the corresponding tag.
Reproduction:

Start entry
Type something in the description
Choose one of the suggestions
Description and project change, but tag doesn't

Why it matters?
Using the hotkey functionality to start/stop tasks, when starting a new task, it starts the task and copies the previous task over. It also puts focus on the description field, so you can edit it straight away if you're not picking up where you left off on the previous task. This is great and handy. Select a suggestion, cool, oh wait... the tag didn't change.
Cheers. Sorry for the long wall of text.

I'm able to reproduce this. Seems to only happen when selecting from autocomplete. Will work on a fix.


PSNativePSPathResolution breaks passing strings starting with ":" to native tools

Steps to reproduce
PS> cmd /c echo ":(top,exclude).*"

Expected behavior
:(top,exclude).*

Actual behavior
C:\Users\duhowett\src\openconsole-inbox\:(top,exclude).*

Environment data

Name                           Value
----                           -----
PSVersion                      7.1.0-preview.7
PSEdition                      Core
GitCommitId                    7.1.0-preview.7
OS                             Microsoft Windows 10.0.19042
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>
WSManStackVersion              3.0

It appears as though the check here
https://github.com/PowerShell/PowerShell/blob/3effa204103460c996a8612aa70718fdf924047d/src/System.Management.Automation/engine/NativeCommandParameterBinder.cs#L388-L406
is not strict enough.
I encountered this by trying to use a git globbing expression, which can begin with : to introduce a set of flags.
PS> & git log ":(top,exclude).git/" ":(top,exclude)**/*.rec"
fatal: invalid object name 'C'.

(This broke an existing script that we were using to generate git logs.)

(We cannot figure out how to get :x to behave normally.)

As for a workaround, on Windows - assuming you don't need PowerShell to perform the globbing - the stop-parsing symbol will (--%) will do (adding the "..." around the arguments would yield the same):
PS> git log --% :(top,exclude).git/ :(top,exclude)**/*.rec

As for the root cause: please see #13640 - I suggest you close this issue in favor of the latter.
Another workaround on Windows is to use '...' rather than "..." quoting, though the fact that this works is arguably a separate bug:
PS> git log ':(top,exclude).git/' ':(top,exclude)**/*.rec'


operation is not propagated when serializing to TransactionAPI

operation denotes a call type (0=call, 1=delegatecall). the transaction would fail if we encode the wrong operation types. multisend specifically requires to be only called as a delegatecall.
users can currently work around this by passing a kwarg like txn(sender=safe, operation=1), but this is not very convenient and it should be fixed either in the library of ape api to allow passing it over.
https://github.com/ApeWorX/ape-safe/blob/4c0891bf6fcdf42e015944189c3ffeb5150a5545/ape_safe/multisend.py#L250

this simple fix in accounts.py works in the meanwhile:
def estimate_gas_cost(self, **kwargs) -> int:
        return 0


[Suggestion] Need Generic Fail(T object) method too

It's hard to always implement IError and being bounded to the IError contract standard. With the generic fail method, developer can set their own implementation of errors.

You can also pass a string as error message which will be converted automatically to an Error object internally. Which class would you want to use for your Error?


fix(helps):rm pkg/apis/helpers/helpers.go

Release note:

The helpers.go is useless for kube-batch logic

/ok-to-test

please remove this file from  hack/.golint_failures

/retest

/approve

LGTM overall, let's get this merge when CI happy :)

hack/verify-golint.sh 执行失败
go get<EMAIL_ADDRESS>parsing go.mod:
	module declares its path as: golang.org/x/lint
	        but was required as: github.com/golang/lint

@leileiwan there's no need for the second Merge pull request #1 from kubernetes-sigs/master commit. #926 is already merged.

/retest

https://github.com/kubernetes-sigs/kube-batch/pull/928 to address module declares its path as: golang.org/x/lint but was required as: github.com/golang/lint error

/retest

/lgtm


deceptive site alert/ taiko hekla

Describe the bug
this keeps showing might be error.,

on the new page
Steps to reproduce
Steps to reproduce here.
need to check if the site is legit
Spam policy

[X] I verify that this issue is NOT SPAM and understand SPAM issues will be closed and reported to GitHub, resulting in ACCOUNT TERMINATION.

I don't know what app or plugin this is, it's not from us

ok... thank for update


Can't combine vsplit with line number

These work as expected but neither combines the two features I need to use together:

nvr -O path/to/file.js: opens the file in a vsplit at the first line as expected
nvr +99 path/to/file.js: opens the file in an existing window at line 99 as expected

One of these should do what I need, but none of them work:

nvr -O +99 path/to/file.js: opens the file in a vsplit as expected, but does not take you to line 99
nvr -O path/to/file.js +99: opens the file in a vsplit as expected, but does not take you to line 99; also opens a new empty file called +99
nvr +99 path/to/file.js -O: throws an expected at least one argument error

Thoughts?

Do all these cases work with Vim? If so, it should be changed, of course.
If you just want to get it done, remember that + merely executes commands (:99 in Vim takes you to line 99). So, in the meanwhile, you could use nvr -c 99 -O path/to/file.js.


Cannot preview template or customization

When I click the Preview button for a template or customization I get the error below

I can now preview templates and customizations.
But the process of canceling or navigating backward from customizations only is problematic. If I click the button in the top right I would expect to go back to editing the Customization (screenshot 1). Instead I see a button "Back to edit phase" - when I click it I am taken to a screen where I can edit phase details. I should not have permission to edit the phase details as an Org Admin since they're part of the template, nor should I be taken to this screen. I tested and I am able to edit the template and save and publish changes from here, none of which should be possible.
The button should say "Back to edit customization" and take me to the appropriate page.