Update arrow 33

Which issue does this PR close?

Closes #.
Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

   process didn't exit successfully: `/Users/runner/work/arrow-datafusion/arrow-datafusion/target/debug/deps/datafusion-ba45d330e390f3a9` (signal: 4, SIGILL: illegal instruction)

Eep, will investigate, shenanigans may be afoot

Shenanigans did abound - https://github.com/apache/arrow-rs/issues/3691, fix in https://github.com/apache/arrow-rs/pull/3692

Shenanigans did abound - https://github.com/apache/arrow-rs/issues/3691, fix in https://github.com/apache/arrow-rs/pull/3692

Testing for the win!

I can do the communicating if you like

Yes please, my 2 cents is optimising for stability is premature at this point, but welcome other input

I posted a note to the mailing list: https://lists.apache.org/thread/9y6bhdj2vgo9ll7bj72mf5gpwxkqy2b1

Unless there are any comments, I think we should merge this next week


Failed to execute bin/format.bat on windows

> bin/format.bat
'bin' is not recognized as an internal or external command,
operable program or batch file.
Exception: bin/format.bat exited with 1
[tty 521]:1:1: bin/format.bat
> bin\format.bat

Have to use bin\xxx.bat on windows, can it support bin/xxx.bat?
Is it a bug or by design?

Here is the similar issue: https://github.com/elves/elvish/issues/1660
I'm using 0.19.2+official, it seems it has not been fixed.

I can't reproduce your problem. Using the Elvish binary from the official download page your example works for me:
elvish> > bin/c.bat

krader@WINDOWS11 C:\Users\krade>echo yes
yes
elvish> cat bin/c.bat
echo yes

The Elvish version I downloaded was 0.20.0-dev.0.20240111000332-82b32d4aceef+official so it is possible the 0.19.2 version you tested does not work as expected.
P.S., The interleaving of the Elvish and "bat" output is arguably wrong. But that is a separate problem.

Yeah, this was fixed after 0.19.x was branched in https://github.com/elves/elvish/commit/67db2194c8418cfbe7b7c232396ae203c12c8485. Please use a HEAD build.
@krader1961 I'm not sure about what you mean by interleaving - mind clarifying?


example_headnodes directory to create a pxe machine with vagrant

the important puppet config file is manifests/site.pp. The manifests/templates directory contains the files copied into the correct locations to specify service config stuff.

This looks good! One change I'd ask for, if it's possible, is to avoid hard-coded references to the specific image (ie - 14.04.1), and instead look for a pointer that fetches the most recent Ubuntu LTE.

Clarifying my previous comment, within an LTS release (14.04, 16.04, etc), we should have compatibility (package names, file locations, etc). We might not just be able to use the latest LTS release and assume files and whatnot are in the same places.

@henn @gsilvis
what do we do with this. should we close it without merging as Headnode is on its way out of HaaS.

@henn @gsilvis @SahilTikale
hey guys just wanted to see if there was any movement with this, or if you needed me to do anything to close it

My gut is to close; pretty well established that headnode stuff isn't getting features (at least) until it's ripped out of hil

I'm pretty sure we can close this.

Closing. If there's any objection it can be reopened and discussed.


Gpu string osx

Get the gpu name (uses the last reported gpu, which seems to be the discrete one) from the macos objc api.


How to..

How to use a skin? im use a <skin_name> (agar.io/?ip) and doesnt work
why?

Duplicate of #365

http://imgur.com/a/nvOAk

Duplicate of #365


Actually adding historic incidents to global map.

This needs to be added to fix historic incidents after merging previous pr.

The situation we have now is that incidents were "created" for 50k or so historic incidents, but not added to the permanent data structure. In order to fix this I propose we

Stop bosun.
Pull the state file locally and run the following program to delete all incident data from our state file:

package main

import (
	"bosun.org/_third_party/github.com/boltdb/bolt"
	"fmt"
)

func main() {
	db, err := bolt.Open("bosun.state", 0600, nil)
	if err != nil {
		log.Fatal(err)
	}
	defer db.Close()
	err := db.Update(func(tx *bolt.Tx) error {
		bucket := tx.Bucket([]byte("bindata"))
		return bucket.Delete([]byte("incidents"))
	})
	fmt.Println(err)
}

Restart bosun with the new build.

Another possible fix: add some code that always runs createInitialIncidents. We deploy it once, then can remove it. This would not require running a special program with the bosun state file.

To explain more what I was thinking above: we always run createHistoricIncidents, and have it always reassign all incident IDs. This will get them in the right order. Yes, it'll change some, but that's fine since this is so new.


Update fe-toolkit

Summary
Pull in frontend toolkit 23.0.1 to fix filter-on-click caching bug

👍 💯


Issue 2252: Updates on a virtual node created from a real node should not update the original node

Issue 2252

Added doc about update virtual entities

Added test in nlp with write: true to check that there aren't regressions

Per favore mettilo sulla 4.4 come base branch grazie!


solr backend not reachable with ddev v1.16.0

Describe the bug
After starting ddev, trying to reach the solr backend provided by ddev describe results in a connection refused error message. It works fine with ddev 1.15.3.
To Reproduce
Steps to reproduce the behavior:

ddev start
ddev describe
Click on solr url provided by ddev describe
See error

Expected behavior
Get the solr backend.
Version and configuration information (please complete the following information):

Host computer OS and Version: tested on Windows 10 and macOS Catalina

Docker Desktop version if on macOS or Windows (from "About Docker Desktop"): <IP_ADDRESS> (Windows 10), <IP_ADDRESS> (macOS)

ddev version information (use ddev version): 1.16.0

config.yaml contents for the misbehaving project: ddev-yaml-solr.zip

This is https://github.com/drud/ddev/issues/2639 - and there's a workaround for you there.
It the fix has already committed and will be released in v1.16.1
Thanks for reporting!


Upgrading node-sass version to 4.11 in example project

The 3.8 version is no longer available on github hence the example project didn't build any more

@humop @droka Published as 0.7.8 ❇


Open graph support (better link previews)

How should this be handled in the editor?
Should we have a dedicated button for when the user wants to have the preview show versus just have the link txt?

This is not something you typically give the user control over.

mmhmm... I guess we could do what Twitter does and include one link preview at the bottom of the post?

I don't know what you mean

What we could do is automatically generate the preview for links and give the users to 'close' the preview. This would be a good balance

Dropped from 2.6, should be bundled with whenever we move image hosting to new server.

Reopening the issue with new spec:
Non-image links should use the new OG api, only the first link of a post should generate a preview. In the future when #255 has been completed, the user themselves can choose what links have a preview and what links don't.


[FEATURE] Replace JUnit assertEquals() with Hamcrest matchers assertThat()

Is your feature request related to a problem?
It is recommended to replace Assert.assertEquals() with assertThat() for a greater degree of verbosity and readability as seen in issue #1832 . But as of November 2023 there're a little less than 3k instances that need to be replaced. I've made some attempts as seen in #3500 and #3443 but after replacing more than half cases and running into a few issues with new updates to main, perhaps a new take on this issue would make for a good first issue.
What solution would you like?
Replacing all JUnit assertEquals(expected, actual) with Hamcrest assertThat(actual, is(expected))
Based on my experience I would suggest:

using regular expressions to automate much of the work:

sed 's/assertEquals(\(.*\), \(.*\));/assertThat(\2, is(\1));/' inputfile.java > outputfile.java

Note* After running the regex and saving the output as the original file name with mv outputfile.java inputfile.java you might have to then go the outputfile and edit any instances of Assert.assertThat() to assertThat() using a simple replace command in your editor. Also make sure to add imports for each file (as seen below) or create a higher order import:
import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.is;

Pushing for a single PR to have all changes be done all at once to reduce the errors your could receive from file conflicts.
Or breaking up changes into sections (test, integrationTests, etc) and merging them one at a time.

What alternatives have you considered?
As for alternatives to this issue itself, this change isn't really that necessary as it's mainly focused helping with debugging. One could argue that this feature isn't as useful but it could make for a good first PR, albeit a bit tedious.
Do you have any additional context?
As mentioned earlier, I don't think this issue presents too much significance outside the added readability/debugging but it could be something to do or I could simply be mistaken.
Best of luck :)

[Triage] Hi @EduardoCorazon, thank you for filing this issue. This looks like you have added some great detail and cover the background well. Judging from what you wrote, we can close this once we swap over all the of the assertions. Marking as triaged.


Who's Rem Team submission

Hi @ChillFish8, your PR adds an .idea directory outside of your project folder. This is not allowed.
Due to the nature of this directory, deleting it should have no effect on your project. Could you please make an extra commit removing this directory, and push it? Please do not make any other changes in this commit.
We will then be able to merge your project. Thanks!

I would be fine with deleting it however, How do i do that? 😅 As its hidden for me so i cant actually change it.

Should be deleted now 👍

@ChillFish8 thanks, looks great!


Adding commandline args

I've added a new main ContadaminationCompanion that follows the pattern of other ADAM commands, not sure I have it exactly right though.  You can run it using sbt
$ sbt "run-main contadamination.ContadaminationCompanion --help"
...
[info] Running contadamination.ContadaminationCompanion --help
 INPUT                     : Reads path
 -h (-help, --help, -?)    : Print help
 -print_metrics            : Print metrics to the log on completion
 -prob_of_false_positive N : Probability of false positive, default 0.0005
 -reference_paths VAL      : Reference paths
 -window_size N            : Window size, default 30

[success] Total time: 9 s, completed Jul 10, 2015 12:08:05 PM

$ sbt "run-main contadamination.ContadaminationCompanion -window_size 30 foo.bam.adam"
[info] Running contadamination.ContadaminationCompanion -window_size 30 foo.bam.adam
...

If you don't mind this style, the class ContadaminationCommand could be renamed to Contadamination to replace the existing one.
I had to bump the scala version to 2.11.7 for my environment.
The other commits seem to be coming from some reformatting done by the build.

Looks great! Thanks a lot. I'll rename Contadamination as per your suggestion.


Clarify "interactions with components outside of vip-manager"

Both the retry-num and retry-after configuration parameters mention "interactions with components outside of vip-manager". I initially assumed this had something to do with communication with the DCS, but looking at the code, it seems to be about the arp client?
I would assume other "interactions with [other] components outside of vip-manager" would probably require other timeouts/number of retries, so being very unspecific here might not be helpful to the user.

You're right, at the moment the retry logic is only used with the ARP client and sending of ARP packages.
The idea was to at some point reuse these retry parameters for other components as well:

etcd
consul
hetzner "robot" API
hetzner cloud API

The last of those is still pending to be tested and merged, the second to last will receive an update in the same flush.
For the two DCS implementations, the use of retry logic would certainly be nice.
Let's continue discussion about that over at #69 and update this issue when we arrive at a conclusion there.


Obsolete multi-organism process & 'multi-organism' descendant classes

Please provide as much information as you can:

GO term ID and Label

[x] GO:0051704 multi-organism process
[x] GO:0044037   multi-organism cell wall macromolecule metabolic process
[x] GO:0044703   multi-organism reproductive process -> see https://github.com/geneontology/go-ontology/issues/21459#issuecomment-964356769
[x] GO:0044706   multi-multicellular organism process -> move directly under ''multicellular organismal process''
[x] GO:0044764   multi-organism cellular process -> moved, see https://github.com/geneontology/go-ontology/issues/21459#issuecomment-964385817
[x] GO:0044766   multi-organism transport
[x] GO:0044800   multi-organism membrane fusion
[ ] GO:0044803   multi-organism membrane organization -see https://github.com/geneontology/go-ontology/issues/21459#issuecomment-964353168
[x] GO:1902539   multi-organism macropinocytosis
[x] GO:1902541   multi-organism micropinocytosis
[x] GO:1902579   multi-organism localization
[x] GO:1902581   multi-organism cellular localization
[x] GO:1902590   multi-organism organelle organization
[x] GO:1902594   multi-organism nuclear import

Reason for deprecation
This is not a biologically meaningful grouping class. See also #21432

"Replace by" term (ID and label)
If all annotations can safely be moved to that term

"Consider" term(s) (ID and label)
Suggestions for reannotation

Are there annotations to this term?

How many EXP:
positive regulation of multi-organism process: 6
multi-organism membrane organization: 4
multi-organism cellular process: 1

Are there mappings and cross references to this term? (InterPro, Keywords; check QuickGO cross-references section)

No

Is this term in a subset? (check the AmiGO page for that term)
GO:0051704 multi-organism process: goslim_pir

Any other information

GO:0044803 multi-organism membrane organization - removed 3 annotations, and disputed annotated to PMID:19376974 in P2GO

[x] GO:0044703 multi-organism reproductive process -> removed GO:0051704 ! multi-organism process parent; keep only GO:0022414 ! reproductive process.
[ ] Need to open another ticket to see if other terms need to be changed

'multi-organism cellular process'
remove LD 'cellular process' and ('bearer of' some 'multi-organismal process quality')
and add 'cellular process' as a subclass. This keeps the children under the term 'multi-organism cellular process':
conjugation
'genetic transfer'
'maintenance of stationary phase'
'multi-organism membrane organization'
'myxococcal fruiting body development'
'quorum sensing'

Regarding  GO:0044803 multi-organism membrane organization - removed 3 annotations, and disputed annotated to PMID:19376974 in P2GO
Hi Ruth,
I just discussed this with @pmasson55
The annotations to 'viral RNA genome replication' are incorrect; the virus induces host cells to form intracellular vesicles so it can hide its RNA to avoid degradation, and this allows it to not die and replicate. But the genes have nothing directly to do with replication.
We propose to create 2 terms:

For viral proteins: reorganization of host cellular membranes to establish sites of replication
as a child of biological process involved in interaction with host'

For host proteins: reorganization of cellular membranes to establish viral sites of replication
as a child of biological process involved in interaction with symbiont'
The paper doesn't show which viral protein induced the host membranes to reorganize. But you could annotate the host proteins to 'reorganization of cellular membranes to establish viral sites of replication'
would that work?

Thanks, Pascale

yes of course, very happy to follow the advice above, please let me know when the term is available
Best
Ruth

[ ] obsoleted GO:0044803 multi-organism membrane organization
[ ] removed parent 'GO:0044764 multi-organism cellular process' from ' GO:0046812 host cell surface binding'

[x] GO:0030583 myxococcal fruiting body development -> move under developmental process  @pfey03
[x] GO:0009372 quorum sensing : remove GO:0044764 multi-organism cellular process; keep detection of cell density and cell-cell signaling

Will propose obsoletion of

GO:0060274 maintenance of stationary phase
GO:0060275 maintenance of stationary phase in response to starvation
GO:0060276 maintenance of stationary phase in response to toxin
4 annotations in total + 1 InterPro IPR023034

Will propose obsoletion of GO:0000748 conjugation with mutual genetic exchange
Single annotation to PMID:14871944 that mentions hyphal morphogenesis  but not conjugation

[ ] parasexual conjugation with cellular fusion -> add parent 'reproduction'
[ ]  GO:0009292 genetic transfer -> move under 'cellular process'

GO:0030583 myxococcal fruiting body development -> move under developmental process - fine with me, far away from sorocarp development that is under  GO:0048856 anatomical structure development

[ ] will propose obsoletion of 'conjugation' as a grouping class
[ ] will be able to GO:0044764 multi-organism cellular process

Yes we use these terms in extensions, but I agree that they do not really belong in GO as defined because they are describing a population.
The best alternative for us to represent "stationary phase" is
GO:0036227  mitotic G2 cell cycle arrest in response to glucose starvation

[ ] please can you add related synonym "stationary phase"

Can this be used when a protein is necessary to move from mound to ongoing development? So far we annotated to developmental terms in GO and specified the arrest in phenotypes.

Can this be used when a protein is necessary to move from mound to ongoing development

This is a different process, it's more like quiescence. The entire Dicty development could be considered a 'quiescent' phase, I am not sure 1. why specifically you would annotate mound formation defects, and 2. why you would not annotate with the Dicty development ontology, which is more accurate in this case?

@ValWood you prefer to stick to obsoletion? I thought Jurg wanted to keep this term.

It was just a loose question. If a gene/protein is really involved in the signaling for chemotaxis, aggregation or sporulation I annotate these GO terms typically and that's fine. We annotate more details as phenotypes anyway for several years.

I agree with Petra. We will continue to annotate these phenotypes because the community require them.  But here we are not describing the normal role of a gene product, we are describing the consequences of mutants (decreased/increased/abolished phosphorylation etc, attached to alleles, not to genes), it's a completely different data type. This isn't in the scope of GO annotation, but it is still necessary curation for MODs (mainly for researchers actively working on the detailed characterization of a gene who need a record of the consequences of loss of/gain of function consequences of different variants). e.g. https://www.pombase.org/term/FYPO:0002494
I like @vanaukenk suggestion that these phenotypes can probably be defined logically by uPHENO using  PRO terms, I had wondered about this but had not been able to figure out what would be missing from the design pattern.

This comment was in the wrong ticket!

Jurg did want to keep the term,  but I'm still I'm not convinced it is an actual 'phase' and not a stress response (checkpoint). I think it is OK to keep if we make it available for yeast and bacteria (I thought this was going to be a bacterial specific term).
I still think a name like 'cell dormancy stage' defined as any stage where  'a cell exit from the cell cycle'
might be more appropriate than stationary phase, with 'stationary phase' as a related synonym (because of the population issue).
We can  discuss when we finalize the ageing changes.

for now, I will move the 2 remaining children of  GO:0044764  multi-organism cellular process and obsolete GO:0044764

GO:0000746 conjugation -> under 'reproduction'
GO:0060274 maintenance of stationary phase -> under 'homeostatic process

These 2 terms will be addressed in separate tickets.


Feature/mac compatibility

Not a lot of major things, but xdg-open doesn't work on macOS so I added detection for the platform to fix that and make those functions work. Also found a place where a platform-specific separator broke functionality on linux and mac and one other spot which honestly shouldn't need a check, but somehow it did. I was too lazy to track down exactly why since this easy fix fixes it =]

Awesome.  I had not looked at Mac or Linux issues.  I don't own any recent Mac hardware to test with.  Service went swimmingly Yesterday.  Still that one memory leak on my hardware, not sure if you are seeing it or if it is isolated to something else I am using.  Maybe for in a future release. The tech that typically does service setups is still asking for "verse" control and has also requested source loads offer a way to supply lyrics directly for responsive reading and maybe even optionally point to different text objects to modify.   I am still trying to come with how to keep up with verse selections per Prepared Lyric in a list, given OBS does not offer a way to easily edit tables in the UI.  I will probably implement it in the source load first just to confirm it is working.  It seems most people are generating new UI objects inside a subgroup for each item in a parent list (a list per list item concept).  It would start to look a bit like modifying HotKeys in OBS setup.  Eight prepared songs would have a subgroup open with eight requests for verse filters in a CSV list somewhat like meta tags.  Another option is more file intensive and could read the current verse limits saved with each song with an option to use them as-is or modify them (list per file).  Neither are really pretty answers.  But then OBS is rarely "pretty" when it comes to UI.

Worth noting that the "fade" functionality does not work on mac; I have no idea if it does on linux or not. The text display elements work quite a bit differently on mac and don't have the same options. I'm not super concerned about it, but thought others might want to know.

Most likely a different name for opacity in settings on the MAC.  If I can find what that is we can easily code for it.
DC

On Nov 8, 2021, at 4:20 PM, Richard Bateman @.***> wrote:

Worth noting that the "fade" functionality does not work on mac; I have no idea if it does on linux or not. The text display elements work quite a bit differently on mac and don't have the same options. I'm not super concerned about it, but thought others might want to know.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

Taxillian,
The fade function relies on the capability of Windows GDI+ text objects that apparently are not supported in the Mac version.  The Mac version currently uses the older FreeType 2 text objects that have a fixed Top and Bottom color gradient with alpha channels.   It will be possible to support those to the extent that we currently are supporting gradient text in GDI+.  The properties only keep a single Alpha channel value and that value has to be changed to cause the fade effect.  So we have to try to remember what it was and put it back to that value during a Fade-In.  Using only 0-100% alpha (opacity) values is easier as those are fixed ranges external to the actual alpha values.  This new release of Lyrics offers greater GDI+ support for gradient fades.  After it releases, I can try to add backward support for the older FreeType2 text formats fairly quickly in a future update.  The code is pretty easy, but I do not want to risk having to go back and re-test this close to a major release, nor does it make sense to try and modify the current release at this point in time.  The FreeType2 looks almost identical to the GDI+ gradient.  The FreeText2 format is just RGBA with A being its opacity.  So the functions getSourceOpacity() and apply_source_opacity() will need to be modified to support the older format.  Fortunately, Amirchev's work in refactoring Lyrics to better isolate these functions will make this a fairly easy update.  :)
D.C.

@taxilian great to have you working on Mac compatibility, because I have really only tested this on Windows and am relying on user feedback for other systems. The only catch is we have a large refactor and update coming from the cleanup branch. So, we will manually add this code into the update prior to releasing 2.0. After that's done, I'll close this request. Looks great.

My time is sometimes a bit hit and miss -- I use this every Sunday, but in general it's kindof a "if it ain't broke, don't fix it" thing =] That said, feel free to ping me if you need something checked on mac and I'll try to take a look.
I'm far from a lua expert, but I have enough dev experience to generally figure out solutions when I need to.
the changes in this PR should be pretty easily applied however you want.

Also to be clear I am not personally too concerned about the fade -- I haven't seen it, so i'm not sure if I'd want to use it or not, but I'm fine as-is, I just thought it might be good to have that be a known thing =]

Is there any interest in getting this merged? I've got a local branch with these changes reapplied over the latest main, happy to either open a new PR or upload for @taxilian to nab.

Is this okay @taxilian ? This branch has conflicts

I'm no longer doing livestreams, so haven't used this in many months -- happy to help if there is anything you don't understand and want to import or you can use this or close it however you think best for the project. No need to worry about my feelings or giving credit, I just wanted to contribute back to something I was using if it was helpful


Bug: iOS - Content is null - 400 error

Describe the bug
When I call one of method InvokePromptAsync/GetChatMessageContentsAsync/GetStreamingChatMessageContentsAsync on iOS. The error is raised.
Microsoft.SemanticKernel.HttpOperationException
Invalid value for 'content': expected a string, got null.
Status: 400 (model_error)
Content:
{
"error": {
"message": "Invalid value for 'content': expected a string, got null.",
"type": "invalid_request_error",
"param": "messages.[0].content",
"code": null
}
}
Headers:
x-ms-region: REDACTED
apim-request-id: REDACTED
x-ratelimit-remaining-requests: REDACTED
x-ms-rai-invoked: REDACTED
X-Request-ID: REDACTED
ms-azureml-model-error-reason: REDACTED
ms-azureml-model-error-statuscode: REDACTED
Strict-Transport-Security: REDACTED
azureml-model-session: REDACTED
X-Content-Type-Options: REDACTED
x-envoy-upstream-service-time: REDACTED
x-ms-client-request-id: 7f2d2543-dde4-45fc-87c3-934a33753cee
x-ratelimit-remaining-tokens: REDACTED
Date: Fri, 12 Jul 2024 07:42:46 GMT
Content-Length: 187
Content-Type: application/json
To Reproduce
Steps to reproduce the behavior:

In Maui iOS call InvokePromptAsync/GetChatMessageContentsAsync/GetStreamingChatMessageContentsAsync
See error

Expected behavior
Can call these methods with no error
Platform

OS: iOS
IDE: Visual Studio
Language: C#
Source: NuGet package version 1.15.1

Hi @jerry2007 and thanks for filing this issue. Would you be able to share a snippet of the code that replicates this issue for us?

` _history.AddUserMessage(question);
OpenAIPromptExecutionSettings openAIPromptExecutionSettings = new()
{
ToolCallBehavior = ToolCallBehavior.AutoInvokeKernelFunctions,
Temperature = 0.2
};
var answer = "";
await foreach (var result in _chatCompletionService.GetStreamingChatMessageContentsAsync(
_history,
executionSettings: openAIPromptExecutionSettings,
kernel: _kernel,
CancellationToken.None))
{
answer += result?.Content;
yield return result?.Content;
}`
this code crash on line with foreach....

this is related:
#6993

I found out that downgrade nuget Azure.AI.OpneAI to version 1.0.0-beta.15 in semnatic kernel project Connectors.OpenAI works correctly.
https://github.com/Azure/azure-sdk-for-net/issues/44174


Discuss gpu pinned memory in intro tutorial

and how to set the setting to make scvi-tools friendlier in shared gpu envs

No longer necessary as the new default is False


Default connection priority and implementing requestConnectionPriority support

Hello,
I am using your library for Bluetooth communication in my project, and I am experiencing some frame loss during data transmission. I am curious about the default connection priority used by your library and if it's possible to implement the requestConnectionPriority function to provide better control over the connection quality.
Could you please let me know the default connection priority value used in your library? Also, would it be possible to add support for the requestConnectionPriority function, so that we can adjust the connection priority based on our requirements (e.g., BluetoothGatt.CONNECTION_PRIORITY_HIGH, BluetoothGatt.CONNECTION_PRIORITY_BALANCED, or BluetoothGatt.CONNECTION_PRIORITY_LOW_POWER)? This feature would be really helpful in improving the data transmission reliability and reducing frame losses.
Thank you for your time and consideration. I appreciate your work on this library, and I am looking forward to your response.
Best regards,

Hello there, thank you for your issue :) glad to see you again here.
That is a great idea, right now we use the CONNECTION_PRIORITY_BALANCED priority, we should definitely have an interface to expose this, so the user can decide which one suits best.
I will add this to my plate and will address this as soon as I have the time to do so.

I have put out a prototype of this, would you be so kind to test this on a separate branch?

Of course but I don't know how to do that ?

I haven't pushed the branch yet, I wanted to see if you were open to testing too.
One option is to clone the branch and test it on the Sample app this repo provides.
Another option is, I can release a version for testing, and you would simply use this version on your gradle file.
Which option do you prefer?

Ok for the branch version, it seems to be a more correct option :)

It is up and running on the develop branch.
Let me know if that works well

Nice, is it possible to add the MTU request method added by Valexi7 because on the develop branch because I use it too and it works great? 😊

Hey, yeah there is a PR for it, we will probably have it on another branch for now.
My plan is to release Valexi7's changes alongside this feature, they will be on the same version.

No worries.
FYI, we merged Valexi7's PR :)

v1.8.2 is out, it includes this.


error during inference

Hi,
Did somebody get this error ???
Traceback (most recent call last):
File "/home/pedro/Documents/Documents/projects/pointcloud/h3d/zim_v1/samlidar.py", line 10, in
labels, *_ = model.segment(points=points, view=viewpoint)
File "/home/pedro/anaconda3/envs/samlidar/lib/python3.9/site-packages/segment_lidar/samlidar.py", line 285, in segment
os.makedirs(directory)
File "/home/pedro/anaconda3/envs/samlidar/lib/python3.9/os.py", line 225, in makedirs
mkdir(name, mode)

did you find the solution for your problem?

I ran into the same issue and found that #22 solved it


Remove old crosstest stuff

The new conformance tests are more than adequate replacements. So we can ditch the old tests now.

cc @drice-buf, before the current conformance suite, we had an approach that required clients to implement all of the test  cases themselves (instead of a generic client that was data-driven with test case input) and then run those against a large number of server implementations that were distributed via Docker containers. This pull request rips out the old stuff. When I first added the new conformance suite, I left the old one in place, to let them run in parallel. But the new tests have identified a number of issues and are far more thorough, so there's no reason to keep running the old stuff.


rework inputs

@daichengxin This is how I think checking the input should look like. This should be common to all subworkflows so it should go into the quantms.nf and after that, we split into subworkflows.

Superseded by #78


Wrong HZ_VERSION variable usage in release verification

Correction for Windows hz library version version usage of release verification scripts for building examples.

Test PASSed.


Problem in setting up styled-jsx

Hi, I couldn't find anything related to my problem so here we go. I just installed the module and I'm not able to fix the following problem.
version : "styled-jsx": "^3.2.1"
Line 34:  Parsing error: Adjacent JSX elements must be wrapped in an enclosing tag. Did you want a JSX fragment <>...</>?

This isn't a styled-jsx error, it is a JSX error. See here for more info. Also, note <></> is just shorthand for <React.Fragment></React.Fragment>

If you are using it with Next.js then you need to


ERROR: .espressif\python_env\idf5.2_py3.10_env\Scripts\python.exe doesn't exist! (IDFGH-13578)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.
5.2.0
Operating System used.
Windows
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
CMD
What is the expected behavior?
For export.bat to run without error
What is the actual behavior?
I am running install.bat all and that completes without error. It creates a venv of .espressif\python_env\idf5.2_py3.8_env and when I run export.bat I get the following error.
Checking if Python packages are up to date...
ERROR: .espressif\python_env\idf5.2_py3.10_env\Scripts\python.exe doesn't exist! Please run the install script or "idf_tools.py install-python-env" in order to create it

it's looking for a completely different version of python. I am not sure why this is happening.
Steps to reproduce.
clone the IDF repo.
checkout version 5.2
run install.bat
run export.bat
Build or installation Logs.
No response
More Information.
No response

Thanks for reporting.

Could you check please the environment variables set in you Windows? Do you have IDF_PYTHON_ENV_PATH or other ESP-IDF variables defined?

no variables set for esp idf
run install.bat
run export.bat

Did you run these in sequence in the same terminal?
Yes I ran the batch files in that order.

Is the terminal a clean one before running install.bat or you are running this in an already active ESP-IDF environment (started with an ESP-IDF shortcut or export.bat already run in it)?

This is a clean shell and both scripts are being run from the same shell. No active IDF environments.

Hi @kdschlosser,
it's strange that there are 2 pythons detected, I can think of a few things to check:

What happens when you delete the .espressif\python_env and re-run the install script?
What happens when you delete the .espressif\python_env and run the advised command python.exe idf_tools.py install-python-env?
 Does this change after running the install script?

It seems that the system is confused about what is the default Python version.
To resolve the issue, my suggestion is to either reinstall the Python versions or install a newer version and set it as the default during installation.
Few notes to installing Python on Windows:

Do you recall how you installed the Python versions? I strongly recommend using the official Python installer: https://www.python.org/downloads/windows/
Python versions installed from Windows Microsoft Store cause issues sometimes. Especially when installed with other Python versions.

I have the Microsoft Store disabled. Though when I do the where python.exe I get this as the return...
C:\Python38\python.exe
C:\Users\********\AppData\Local\Microsoft\WindowsApps\python.exe

I tried to get the version from the last entry but I get an error saying the version doesn't exist.
I have Python installed, 3.8, 3.10 and 3.11 and all 3 were installed using the Python installation utility and not from the Microsoft store.

What happens when you delete the .espressif\python_env and re-run the install script?

It recreates the same environment

What happens when you delete the .espressif\python_env and run the advised command python.exe idf_tools.py install-python-env?

it creates the same environment
If I specify the full path to my python 3.10 installation and run idf_tools it creates the environment it is looking for when the failure occurs.
I think I figured out what is going on.. The install script is creating the environment based off what is returned from where. and I find that to be rather foolish. Firstly there should be a parameter that can be passed to the install.bat script so the python path can be user set.... The issue is I have an alias set up using DOSKEY that points python to my 3.10 installation. The export.bat script doesn't use where when running whatever python script it is running to set up the environment. It is blindly making a call to the shell to run python not knowing what version is actually going to get used. If where is going to be the way the install script picks which Python to use then where should also get run to collect the python executable that is going to be used when running the python script from export.bat.
Personally I feel where should not be used at all for any portion of this. What should be done is a simple registry lookup for Python installations and the one that should get used is the one that is the highest version that the ESP-IDF is able to run with. I am using this logic to make that decision. People tend to install things in the order in which they are released. As a new version comes out they install it. so you would have lower version of Python installed first. When a new path is added to the PATH environment variable how is it typically done? Well it can either be prepended or it can be appended. Appending is a whole lot easier to do in just about every programming language that is written and that is usually what gets done. The results of running where is then going to list the oldest versions first yes? Yup... What versions of python are the most likely to get uninstalled from a users PC?? The oldest ones.. So why on earth would the install script use where to determine which python to use?
this regkey gives the different installed python versions along with their installation path. it even tells you what features are installed with that version so you can check to see if the needed parts are installed for python to run. Things like pip which are fairly important to have and if the installation doesn't have it installed then why even bother using it?
/HKEY_LOCAL_MACHINE/SOFTWARE/Python/PythonCore

Here is a batch file script that queries the registry and collects the highest version of Python that is installed onto the system. I am sure it could be written better as I am not a window batch file expert or anything like that. There should also be a check in there to see if the executable even exists prior to setting it as the one that has been found. There also needs to be a check to see if anything has been found. But it gives the basic idea and this is what should be in both the install.bat and also the export.bat files for selecting the version of python to use. Even where will report erroneous paths to the python executable so a check for the existence of the executable should ALWAYS be done.
@echo off
setlocal
setlocal enabledelayedexpansion

set "_version_major=0"
set "_version_minor=0"
set _found_python_path=""

for /f "tokens=1" %%a in ('REG QUERY HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore /s /f InstallPath ^| findstr "HKEY_LOCAL_MACHINE"') do (
  set _python_reg=%%a

  for /f "tokens=3" %%b in ('REG QUERY !_python_reg! /v ExecutablePath') do (
    set _python_path=%%b
  )

  for /f "tokens=5 delims=\" %%v in ("%%a") Do (
    set _version=%%v

    for /f "tokens=1,2 delims=." %%p in ("%%v") Do (
      set "_major=%%p"
      set "_minor=%%q"

      IF !_major! gtr !_version_major! (
        set "_version_major=%%p"
        set "_version_minor=%%q"
        set _found_python_path=!_python_path!
      ) ELSE (
        IF !_major!==!_version_major! IF !_minor! gtr !_version_minor! (
          set "_version_major=%%p"
          set "_version_minor=%%q"
          set _found_python_path=!_python_path!
        )
      )
    )
  )
)
echo !_found_python_path!
endlocal

The above is a better way to collect the executable location for python. It will not get screwed up by something like an alias being set.

another note is any time a subprocess is started from inside of a python script to run another session of python the fill path to the running python executable of python should be given. this is easily gotten from sys.executable passing python only as the executable name can and will cause problems if there are any aliases in place. Never rely on thing being how you would think they would be. Always write code that removed the possibility of variations and providing FULL paths to an executable and not relying on things being in the PATH is the ONLY way to be 100% sure.

Hello @kdschlosser ,
I'm not using Windows, so I can't confirm this, but I think batch files run in a separate context, and doskey macros don't carry over between different contexts or sessions.
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/doskey

To run a macro, type the macro name at the command prompt, starting at the first position. If the macro was defined with $* or any of the batch parameters $1 through $9, use a space to separate the parameters. You cannot run a doskey macro from a batch program.

In my opinion, what's happening is that while install.bat runs in a different context, the doskey macro isn't visible, so python.exe points to your 3.8 version. This means the virtual environment is installed with this Python version.
However, export.bat runs in the current cmd.exe context, where your doskey macro is available and points to Python 3.10.
This is just my guess what might be happening and I of course may be wrong. Also this doesn't solve the problem you are seeing, I'm just trying to understand how this situation can happen.
Thank you

Hi @kdschlosser
I am glad you find a way to make it work.
I understand your view on finding and using the latest version of Python. It's important to consider that there are numerous use cases for Python, and developers may require different versions for specific purposes. Thus, they may implement various ways to invoke particular versions. Understanding the diverse needs of users,  we use the most common method to detect Python.
To fix your problem, I can recommend two solutions:

Set up our IDF_PYTHON_ENV_PATH environmental variable after you create the required python version directory .espressif\python_env\idf5.2_py3.10_env. This ensures that the ESP-IDF finds the Python environment you want to use every run.
Use our ESP-IDF Tools Installer. You can choose to download or use existing ESP-IDF version, and all the required tools with python virtual environment are set up automatically.

batch files run in the same context as the command shell they were launched from and the command they run also run in that same cmd shell unless they explicitly start a new one.
right in the export.bat file there are doskey commands to map python source files to python

My apologies for the noise. I didn't realize that export.bat is actually executed on Windows rather than sourced as it is on Linux. Thank you

@kdschlosser Did the suggestion of @mfialaf about setting that environment variable or using the Windows installer helped you to resolve the issue?

I'm closing this for inactivity.


ochttp creates CHILD instead of PARENT link when span ctx is from remote parent.

Incoming trace context from untrusted source (remote parent) should be added as parent link instead of a child link.
Bug is at this line.

duplicate of #1034


Enables swagger-ui for migrated rest api

PR Description
Not finished yet.
Bugs to fix:

/swagger-ui (without trailing /) not working

Tests to do:

/swagger-ui/index.html from server is 200 and correct
/swagger-ui/swagger-initializer.js (and gzipped) from server is 200 and links internally to /swagger-docs
/swagger-docs responds with correct json
there are no duplicates in /swagger-docs json
file in swagger jar /META-INF/resources/webjars/swagger-ui/<SWAGGER-VERSION/swagger-initializer.js is the same that in infrastructure/restapi/src/main/resources/swagger-ui/vendor/swagger-initializer.js, same for gzipped

Fixed Issue(s)

Fixes #5875
Documentation

[ ] I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

[ ] I thought about adding a changelog entry, and added one if I deemed necessary.

duplicate definitions in swagger should already be well covered in integration tests... every change that impacts swagger breaks an integration test and needs reference files updated, so we shouldnt need to do any further there I think...

Sorry @ajsutton @rolfyone  didn't explain why it's made in this way. But you have correct questions and I've answered it

One additional note: webjars are just static compiled versions of web appication. Static. No logic. The good is it's updated and it's a purpose

All done, some cleanup and polishing needed.
Overall swagger-ui distribution comes with this following set of the files: https://github.com/swagger-api/swagger-ui/tree/master/dist, we swap two of them and their gzipped versions (not sure that latter is really required, need to test), index.html and swagger-initializer.js. It's expected that we will manually patch these two if they are changed (test SwaggerWebjarIntegrityTest will fail in this case). Though it's not good to do this manually, you could follow the links and see that they are changed very rarely, so it shouldn't be an issue. In case with plugins this work among with everything else is mantained by plugin authors. Plus we avoided to copy whole asset folder, which is big plus.

Maybe i steered you in the wrong direction with webjars, i'm not 100% sure what the answer is...
My assumption was that we'd be able to include a second version of swagger.jar and load that on a route via some kind of setup...
does look like some interesting json issues that my current integration tests seem to miss, so im not sure what the answer is re. that side of things...

@rolfyone I think it's ok, doesn't look like a lot of things to maintain, file changes we will need to maintain were changed 2 times in the last 2 years and it's kind of files that shouldn't be changed often by swagger-ui authors. Plus it's a minor part of the plugin which is already far behind and we will be able to drop plugin after this merge easily.

Anyway you will not found more fresh version of swagger-ui that could be easily linked up to the Java application. This jar timeliness is maintained by CI, anything involving json link changes will require manual entry or if built in some automatic manner could fail on any update

Here's an update will look like
https://github.com/ConsenSys/teku/pull/6012/commits/583387fce529ef7e7f4c0c51e108fa54baa10fcf
yes, 2 places, but removing these things looks like a pro for me

Ready for review, some rationale/explanations:

Using org.webjars:swagger-ui because it's an automated built jar from Node.js app so it's the most recent static version of repo release, it's not dependent on some 3rd party manual updates like plugins. It will require us to follow and update changes in 2 files (index.html and swagger-initializer.js), which doesn't look like a huge work, there were 2 changes in latest 2 years and there will be rare changes in future. If it is not done with update, the test will fail.
index.html from swagger-ui was rebuilt with Thymeleaf template to change path from version to version to avoid browser cache issues and other weird things which could worsen client experience. And I don't like to hardcode it in a code or smth like this.
Update of swagger will require changes in 2 places (see https://github.com/ConsenSys/teku/commit/583387fce529ef7e7f4c0c51e108fa54baa10fcf), if change is made only in one place, some test or tests will fail.


RE8 Double Vision when using Interlaced Rendering

When playing RE8 in VR and using interlaced rendering all of the UI including the crosshair is rendered in different positions on each display on the headset sort of giving me double vision and it's really confusing and nauseating so Ive been playing the game with normal rendering so far. I would rather use Interlaced though as it basically doubles my fps with basically no visual impact other than some weird wavy depth perception thingy when in VR which I dont mind at all.
I've also played RE7 in VR and it doesn't have the same issue. In fact it runs perfectly fine except for a missing crosshair which i did find a fix to but its not so much of an annoyance that i would bother changing it.
EDIT: FYI I'm using a quest 2 over oculus link with oculus as the default OpenXR runtime running the game over OpenXR.
Running it over OpenVR does not fix the issue and has worse performance.

У меня такая же проблема


WIP: Use name identity instead of name in diverse methods

[THIS IS A DRAFT]
(it works as is on my machine, but is yet quite incomplete)
In method structures such as EVP_MD, EVP_CIPHER, etc when it's a provider implementation, we currently save away the name...  however, the namemap already supports having a set of names associated with each different method, and saving copies of all the names would be fairly dumb, and the idea of a "canonical" name is still being disputed.
As an alternative, which avoids both the unnecessary saving and the dispute on "canonical" names is to save away the number associate with the name instead, and adapt the rest of the code around it.  That's what this PR does.

This is related to the discussions going on in, among others, #8984 and #8985

(even though this is a draft, it would be nice to get comments on the concept)

This is no longer a draft.

... and out of WIP too

Ping.

Ping

Merged.
f7c16d48a945e80f22f6f02550ee3fe14edb52fa In provider implemented methods, save the name number, not the name string
7cfa1717b812a126ce6f8e4cc32139164c89d789 Modify providers that keep track of underlying algorithms

Thanks!


[VideoView] play audio delayed after seek

When I seek videoview and re-play, the videoview only rendered image and after about 400ms, audio was actually played.
I have set the seekMode to Fast. Any fix?

Does it only happen when seekMode is set to fast? Does it happen in the demo app too? Please tell me the exact steps to reproduce the problem.

Sorry for my late reply, i will build your demo app and let you know as long as possible.

Here is my scenario:

I pulled your full source code, run in android studio newest version
I opened up your videoview and try to seek, the audio work quite well and it just small delay(about 50ms), so I completely accept it.
I changed your code in the VideoViewActivity, set videoview.setSeekmode(FAST).
After that, I realized that, at the first seek audio still work, but the second or more seek make the audio of videoview delayed.

Should I upload my video?

I tested this issue on (Motorola X 2014, android 6.0, arm-v7) and (Asus zenpad 3, android 5.1, x86)

Thanks, I'm looking into it. I can observe it on my test videos too so you don't need to upload yours.

This is actually not a bug but expected behavior. Fast seek seeks to a sync frame, and since audio frames do not necessarily have to follow directly after a sync frame, it can take some time until the next audio frame is read and audio playback continues. If this is a problem, please choose another seek mode as a workaround. I'll push an update in the coming days with different fast seek options which will provide a solution to this problem.

So FastSeek means fast seeking video frame, not apply to audio stream. Therefore, video frame have to wait to sync audio stream, right?
Thanks, I'm waiting your update.

Version 3.1.0 is now available and adds additional fast seek modes. Like I said, this problem is technically not a bug and this behavior depends on file encoding and multiplexing settings. I noticed however that the two new alternative seek modes FAST_TO_CLOSEST_SYNC and especially FAST_TO_NEXT_SYNC mitigate this behavior a lot. Let me know if it works for you!

WOW it worked perfectly, thank you so much!


Cache Mode ignored in settings

With a clean import (and cache cleaned), using bogrep import & bogrep fetch the cache is filled with .txt files.  Again after cleaning, bogrep import & bogrep fetch --mode markdown fills the cache with .md files.  These are expected behaviors.
After cleaning again and editing settings.json setting "cache_mode": "markdown", and running bogrep import & bogrep fetch the cache is filled with .txt files.  The expected behavior should be to download .md files.

Fixed on main branch.
Now, bogrep fetch will use the cache mode configure in settings.json. On the other hand if --mode is specified (e.g. bogrep fetch --mode markdown), the cache mode provided in the --mode argument will be used instead.

My tests show that this is resolved.


fix(fs): fix copying of symlink directories on Windows

This PR fixes the handling of symlink directories in the copy function on Windows. Previously, copying a directory that was a symlink resulted in creating a symlink of type "file" instead of "dir".
The test case for copying symlink directories passed because Deno.lstat() (which does not follow symlinks) was used. However, when Deno.stat() (which follows symlinks) was used on this type of symlink, the system would throw a PermissionDenied error.

Thanks @IgorM867 for working on this!
I merged #6236 and this branch at #6280, but the CI shows some errors. Do you see the reason for those errors?

@kt3k The reason is that in the copySymLink() function, when copying a symlink, await Deno.readLink(src); returns only a relative path ("dir"), not the full path. I believe this is due to how the symlinks were initially created. When I recreated them on Windows, all the tests passed.

@IgorM867

@kt3k The reason is that in the copySymLink() function, when copying a symlink, await Deno.readLink(src); returns only a relative path ("dir"), not the full path. I believe this is due to how the symlinks were initially created.

I think the symlink targeting relative path is fine, and I think we should keep the relative relationship between them while copying.

When I recreated them on Windows, all the tests passed.

Did you create a symlink targeting absolute path? I don't think that works as absolute path vary in every environment


Update usage instructions for Webpack 2

There is now a Webpack 1 deprecation warning at the top of the old link and not using the full elm-webpack-loader name throws an error.
BREAKING CHANGE: It's no longer allowed to omit the '-loader' suffix when using loaders.
                 You need to specify 'elm-webpack-loader' instead of 'elm-webpack',
                 see https://webpack.js.org/guides/migrating/#automatic-loader-module-name-extension-removed

I have also discovered with some difficulty that passing warn doesn't do anything without verbose also being enabled. Should I add this to the PR?

Can you make this guide have info for both webpack 1 and 2?

Make a new Pr for the other issue

Thanks, published as part of 4.3.1


Switch from autosquash to auto-update.

@dmundra yes, I believe so - Github supports auto-merge, so we just need the action to update each branch whenever it lags


403 error code

Hi bros,
I tried to upload via CLI and got issue like that, pls help. Thanks

maybe you need check the sessionId.
make sure it is correct

Unfortunately I am facing the same issue, even when sessionId is correct.

update the latest version
it have been resolved


Update frequency

Is there any particular reason that this extension gets update so frequently? Visual Studio Code tells me there is an update almost daily.

Recently it not frequency ! Now updated once almost three days
In 2017.4.10, I updata too much.

And when developer send a PR, I will merge it and update, please understanding it, now it stable, will not update long time

Thanks for the quick response!

You can watch the PR list, https://github.com/Binaryify/Material-Theme-vscode/pulls?q=is%3Apr+is%3Aclosed  , about php PR has 5  recently


⚠ Processors has degraded performance

In da57b39, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 106 ms

Resolved: Processors performance has improved in 4d83354.


Explicitly include CMDLINE_OPTIONS GUCs when querying pg_settings

followup on #2993

Pull Request Test Coverage Report for Build<PHONE_NUMBER>7
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 99.874%

Totals

Change from base Build<PHONE_NUMBER>9:
0.0%

Covered Lines:
14306

Relevant Lines:
14324

💛  - Coveralls


Covering grammar naming

As it stands, the covering grammar files in data/cg/tsv are just named <lng>.tsv, where <lng> is the three-letter language code. I think the file names should for the CGs should match those used for the data they correspond to, that is, they should phonetic/phonemic status and script name.

+1

On a related note, the .phones files also do not include the script in their filenames. They probably should, though, right? @kylebgorman

No, don't think they need that, since they only refer to the pron side?
On Fri, Mar 26, 2021 at 2:23 PM Aidan Malanoski @.***>
wrote:

On a related note, the .phones files also do not include the script in
their filenames. They probably should, though, right? @kylebgorman
https://github.com/kylebgorman
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kylebgorman/wikipron/issues/385#issuecomment-808428076,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABG4OIHXTICSG2DXXFIIVLTFTGK3ANCNFSM4ZUFBT3A
.

Oh duh, very true


Issue in creating Chrome process

i have one more idea  can we modify poll in a way so that it gives option to user to select poll option if user didnot give the input it selects first option and execute it.


Fix access-token

the GA is failing for PRs (see https://github.com/icatproject/icatproject.github.io/pull/37 and https://github.com/icatproject/icatproject.github.io/pull/28) and we need to investigate and provide an access-token

I think this is due to those PRs coming in from forks, which means they don't have access to the encrypted secret (see https://docs.github.com/en/actions/reference/encrypted-secrets#using-encrypted-secrets-in-a-workflow). However, we only need the access token for publishing, which only happens once merged (and thus will definitely have the access token) so there should be a way to fix this issue for builds only

See https://github.com/enriikke/gatsby-gh-pages-action/issues/27
aka we should either use the solution in that thread or switch to the main github pages action

thanks @louise-davies - this is now fixed 182232e230309febceab714b496a9d13f1a26cf3


made PlentymarketsImportEntityItem hookable

Hallo,
just a small initial commit. I've made the Class PlentymarketsImportEntityItem hookable through shopware's event system. Through that other Plugins can easily hook into the functions and add their own code to them. More classes and some general hook points will follow.
Best regards,
Jochen

Closed in favour of the better method by using Shopware's event system


Update event-hubs.api.md

Update event-hubs.api.md with source changes in #4158

Oh, isn't this supposed to be auto-generated/updated during build time?

@ramya0820: It's updated during the local build, but you need to include the updated file in your PR.


Command to list SKUs Codes

I would like to get a list of the current SKUs codes, not only the name, for my subscription. Is that already possible or it should be added as a feature? E.g.: I am using the Get-AzComputeResourceSku command but I need the SKUs codes.

Compute

@bjosafa Please use az vm list-skus to have a try, add parameter -h then you can see the usage of this command

I already did it, but it did show the sku id as it is shown in the calculator. E.g.:
Virtual Machines (West US - VM 1 D2 v3) = AAA-44930 (Sku code) <- that information that I want to get via cli

In fact, CLI only directly output the results returned by REST service list-skus , while REST does not return the data of SKU codes. Therefore, it needs the support of REST from the server team.
As for PowerShell related requirements, please submit them on https://github.com/Azure/azure-powershell

@jaylabell Could you please look into this issue?

Redirecting updates to https://github.com/Azure/azure-powershell/issues/15526

@bjosafa was the answer provided by @zhoxing-ms sufficient for you:

In fact, CLI only directly output the results returned by REST service list-skus , while REST does not return the data of SKU codes. Therefore, it needs the support of REST from the server team.

@jaylabell, as I understood, the SKU codes were supposed to be provided by the Rest service, but nowadays it is not providing this information. So I can assume this will be added or at least taken into account.

Looking into this issue

@bjosafa Can you please describe what you are referencing when you say SKU Codes? What do you intend on using the list for?
For now this item is not able to be implemented because it is not available through the REST and in order to implement in PS we would need it to be implemented through the REST. The Swagger team is interested in your answer to the question above.
Please re-open if you can provide more details.
Thank you


[feature request] Provide prometheus endpoint for statistic monitoring

It could be separate daemon program, that uses lnd APIs, or built into lnd itself to provide even more statistics.
Useful statistics:

status (i.e. synced or not)
fee estimates
number of transactions performed by type, both on-chain and off-chain
total balances of different things
number of current channels (total and divided by their status, i.e. active, pending, closing, etc.)
size of network and network statistics, similar but not limited to getnetworkinfo
oldest and youngest channel, biggest and smallest channel, or some percentiles for lnd node
aggregated network (TCP/UDP) traffic in and out
number of connected peers
number of outbound payments and total balances done or in progress
number of incoming invoices by status and their totals
total number of lncli/API RPCs and their latency and status (OK, Error), aggregated totals, and by status, or API type.
current fee policy
fwding history aggregates, including total earned fees, and successed and errors (i.e. rejections, etc)
used memory and total CPU usage
uptime
state of wallet (locked / unlocked)
bitcoin backend status, i.e. ok, not ok, number of zmq messages received / processed, and their latency, blockchain height,
internal statistics: number of broadcasts, aggregated size of broadcast batches, number of graph updates, number of new channels discovered, number of orphaned channels removed, etc.
go related statistics: go routine counts, threads, HTTP stats, RPC stats, context switches, IO stats, etc.
number of log lines in log file by status (error, info, warn, etc)
database related stats, i.e. size of db, aggregated read and write io, size of write log, etc.
invalid handshakes, peer counts by protocol version and transport (i.e. ipv6/ipv4)
size of DoS protection database (in the future), and number of peers by status and/or score percentile, etc
size (in elements and bytes) of various internal caches, and their hit and miss counts (so hit ratio rates can be calculated in prometheus, etc).

Sound suggestion, we have a little monitoring+alert toolkit planned. I took at look at Prometheus and it looks like a very viable candidate. I particularly like its query language, and also custom alert thresholds.

Current I am doing this manually by fetching info about lnd and using unix tools to get info about lnd process. I using Prometheus for this, so, +1 for Prometheus integration.

As it seems both of y'all already have experience with the tool, how about
collaborating to bring the monitoring features to lnd?!
On Wed, May 16, 2018, 11:35 AM Witold Baryluk<EMAIL_ADDRESS>wrote:

https://github.com/prometheus/client_golang#instrumenting-applications
appears to be official Go library for instrumenting Go code. There are some
examples there too, and plenty of tests. It requires HTTP server for
serving metrics, but lnd already has one, and I think it should be fine to
not require authentication (especially if only listening on ::1 /
<IP_ADDRESS>), as long as there are no private data exposed via metric labels
and metadata. Or separate HTTP server on separate port can be used (this
has advantage of being able to provide some metrics and status even if
wallet is still locked).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/lightningnetwork/lnd/issues/1243#issuecomment-389621505,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA87LsWX2AYJYxALiJqXyIJMZYYt8L-Iks5tzHFSgaJpZM4T8mrB
.

Ok. I can play with it next week, and write initial code and some tutorial how to use it. Not that I have much real world experience with Prometheus, but I do have a bit with Go, and other monitoring systems, so I can do it.

@baryluk missed this issue. I've ran into similar issues you're trying to solve with Prometheus but picked StatsD because it is faster and more lightweight. Do you want to participate? There's a proof of concept at #1264

I do have working Prometheus integration working. It exports all gRPC server metadata (count of RPCs by type, status ok or error and their latency), Go runtime stats (i.e. garbage collection details and goroutines counts), CPU usages, file descriptor counts and memory usage and few minor lnd specific stats (for a moment just lnd version, number of channels and peers).

$ curl -s "http://[::1]:8081/metrics" | grep lnd
# HELP lnd_active_channels_count Number of active channels.
# TYPE lnd_active_channels_count gauge
lnd_active_channels_count 4
# HELP lnd_best_height Height of the best chain.
# TYPE lnd_best_height gauge
lnd_best_height 524014
# HELP lnd_is_synced Is LND synced?
# TYPE lnd_is_synced gauge
lnd_is_synced 1
# HELP lnd_pending_channels_count Number of pending channels.
# TYPE lnd_pending_channels_count gauge
lnd_pending_channels_count 0
# HELP lnd_version Version of LND running.
# TYPE lnd_version gauge
lnd_version{commit="",version="0.4.1"} 1

# HELP grpc_server_handled_total Total number of RPCs completed on the server, regardless of success or failure.
# TYPE grpc_server_handled_total counter
...
grpc_server_handled_total{grpc_code="OK",grpc_method="GetInfo",grpc_service="lnrpc.Lightning",grpc_type="unary"} 2
grpc_server_msg_received_total{grpc_method="GetInfo",grpc_service="lnrpc.Lightning",grpc_type="unary"} 2
grpc_server_msg_sent_total{grpc_method="GetInfo",grpc_service="lnrpc.Lightning",grpc_type="unary"} 2
grpc_server_started_total{grpc_method="GetInfo",grpc_service="lnrpc.Lightning",grpc_type="unary"} 2

# HELP go_gc_duration_seconds A summary of the GC invocation durations.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 3.3772e-05
go_gc_duration_seconds{quantile="0.25"} 5.0189e-05
go_gc_duration_seconds{quantile="0.5"} 5.9294e-05
go_gc_duration_seconds{quantile="0.75"} 0.00011721
go_gc_duration_seconds{quantile="1"} 0.007832316
go_gc_duration_seconds_sum 0.442792173
go_gc_duration_seconds_count 844
# HELP go_goroutines Number of goroutines that currently exist.
# TYPE go_goroutines gauge
go_goroutines 177
# HELP go_memstats_alloc_bytes Number of bytes allocated and still in use.
# TYPE go_memstats_alloc_bytes gauge
go_memstats_alloc_bytes 1.3921608e+07
...
# HELP go_memstats_stack_sys_bytes Number of bytes obtained from system for stack allocator.
# TYPE go_memstats_stack_sys_bytes gauge
go_memstats_stack_sys_bytes 1.605632e+06
# HELP go_memstats_sys_bytes Number of bytes obtained by system. Sum of all system allocations.
# TYPE go_memstats_sys_bytes gauge
go_memstats_sys_bytes 2.893806e+08
...
# HELP process_cpu_seconds_total Total user and system CPU time spent in seconds.
# TYPE process_cpu_seconds_total counter
process_cpu_seconds_total 61.21
# HELP process_max_fds Maximum number of open file descriptors.
# TYPE process_max_fds gauge
process_max_fds 65536
# HELP process_open_fds Number of open file descriptors.
# TYPE process_open_fds gauge
process_open_fds 28
# HELP process_resident_memory_bytes Resident memory size in bytes.
# TYPE process_resident_memory_bytes gauge
process_resident_memory_bytes 2.19295744e+08
# HELP process_start_time_seconds Start time of the process since unix epoch in seconds.
# TYPE process_start_time_seconds gauge
process_start_time_seconds 1.52708915298e+09
# HELP process_virtual_memory_bytes Virtual memory size in bytes.
# TYPE process_virtual_memory_bytes gauge
process_virtual_memory_bytes 1.187811328e+09

Adding new counters is relatively easy.

Per channel stats:
# HELP lnd_channel_capacity L...
# TYPE lnd_channel_capacity gauge
lnd_channel_capacity{active="false",channel_id="574380476322676737",public="true"} 214606
lnd_channel_capacity{active="false",channel_id="574560796294316032",public="true"} 100000
lnd_channel_capacity{active="true",channel_id="574244136963276801",public="true"} 1.8e+06
lnd_channel_capacity{active="true",channel_id="574379376815177729",public="true"} 958732
lnd_channel_capacity{active="true",channel_id="574379376815243265",public="true"} 597888
# HELP lnd_channel_commit_weight L...
# TYPE lnd_channel_commit_weight gauge
lnd_channel_commit_weight{active="false",channel_id="574380476322676737",public="true"} 600
lnd_channel_commit_weight{active="false",channel_id="574560796294316032",public="true"} 552
lnd_channel_commit_weight{active="true",channel_id="574244136963276801",public="true"} 600
lnd_channel_commit_weight{active="true",channel_id="574379376815177729",public="true"} 600
lnd_channel_commit_weight{active="true",channel_id="574379376815243265",public="true"} 600
# HELP lnd_channel_csv_delay Local channel config CSV delay
# TYPE lnd_channel_csv_delay gauge
lnd_channel_csv_delay{active="false",channel_id="574380476322676737",public="true"} 144
lnd_channel_csv_delay{active="false",channel_id="574560796294316032",public="true"} 144
lnd_channel_csv_delay{active="true",channel_id="574244136963276801",public="true"} 144
lnd_channel_csv_delay{active="true",channel_id="574379376815177729",public="true"} 144
lnd_channel_csv_delay{active="true",channel_id="574379376815243265",public="true"} 144
# HELP lnd_channel_external_commit_fee L...
# TYPE lnd_channel_external_commit_fee gauge
lnd_channel_external_commit_fee{active="false",channel_id="574380476322676737",public="true"} 4163
lnd_channel_external_commit_fee{active="false",channel_id="574560796294316032",public="true"} 1665
lnd_channel_external_commit_fee{active="true",channel_id="574244136963276801",public="true"} 1448
lnd_channel_external_commit_fee{active="true",channel_id="574379376815177729",public="true"} 1520
lnd_channel_external_commit_fee{active="true",channel_id="574379376815243265",public="true"} 1802
# HELP lnd_channel_fee_per_kw L...
# TYPE lnd_channel_fee_per_kw gauge
lnd_channel_fee_per_kw{active="false",channel_id="574380476322676737",public="true"} 5750
lnd_channel_fee_per_kw{active="false",channel_id="574560796294316032",public="true"} 2300
lnd_channel_fee_per_kw{active="true",channel_id="574244136963276801",public="true"} 2000
lnd_channel_fee_per_kw{active="true",channel_id="574379376815177729",public="true"} 2000
lnd_channel_fee_per_kw{active="true",channel_id="574379376815243265",public="true"} 2000
# HELP lnd_channel_local_balance_by_channel Local balance of a channel by channel
# TYPE lnd_channel_local_balance_by_channel gauge
lnd_channel_local_balance_by_channel{active="false",channel_id="574380476322676737",public="true"} 210443
lnd_channel_local_balance_by_channel{active="false",channel_id="574560796294316032",public="true"} 0
lnd_channel_local_balance_by_channel{active="true",channel_id="574244136963276801",public="true"} 1.798552e+06
lnd_channel_local_balance_by_channel{active="true",channel_id="574379376815177729",public="true"} 957212
lnd_channel_local_balance_by_channel{active="true",channel_id="574379376815243265",public="true"} 596086
# HELP lnd_channel_pending_htlcs_count Local commit HTLCs count
# TYPE lnd_channel_pending_htlcs_count gauge
lnd_channel_pending_htlcs_count{active="false",channel_id="574380476322676737",public="true"} 0
lnd_channel_pending_htlcs_count{active="false",channel_id="574560796294316032",public="true"} 0
lnd_channel_pending_htlcs_count{active="true",channel_id="574244136963276801",public="true"} 0
lnd_channel_pending_htlcs_count{active="true",channel_id="574379376815177729",public="true"} 0
lnd_channel_pending_htlcs_count{active="true",channel_id="574379376815243265",public="true"} 0
# HELP lnd_channel_remote_balance_by_channel Remote balance of a channel by channel
# TYPE lnd_channel_remote_balance_by_channel gauge
lnd_channel_remote_balance_by_channel{active="false",channel_id="574380476322676737",public="true"} 0
lnd_channel_remote_balance_by_channel{active="false",channel_id="574560796294316032",public="true"} 98335
lnd_channel_remote_balance_by_channel{active="true",channel_id="574244136963276801",public="true"} 0
lnd_channel_remote_balance_by_channel{active="true",channel_id="574379376815177729",public="true"} 71
lnd_channel_remote_balance_by_channel{active="true",channel_id="574379376815243265",public="true"} 354
# HELP lnd_channel_satoshis_received L...
# TYPE lnd_channel_satoshis_received gauge
lnd_channel_satoshis_received{active="false",channel_id="574380476322676737",public="true"} 0
lnd_channel_satoshis_received{active="false",channel_id="574560796294316032",public="true"} 0
lnd_channel_satoshis_received{active="true",channel_id="574244136963276801",public="true"} 0
lnd_channel_satoshis_received{active="true",channel_id="574379376815177729",public="true"} 0
lnd_channel_satoshis_received{active="true",channel_id="574379376815243265",public="true"} 0
# HELP lnd_channel_satoshis_sent L...
# TYPE lnd_channel_satoshis_sent gauge
lnd_channel_satoshis_sent{active="false",channel_id="574380476322676737",public="true"} 0
lnd_channel_satoshis_sent{active="false",channel_id="574560796294316032",public="true"} 0
lnd_channel_satoshis_sent{active="true",channel_id="574244136963276801",public="true"} 0
lnd_channel_satoshis_sent{active="true",channel_id="574379376815177729",public="true"} 71
lnd_channel_satoshis_sent{active="true",channel_id="574379376815243265",public="true"} 354
# HELP lnd_channel_updates_count Local commit height
# TYPE lnd_channel_updates_count gauge
lnd_channel_updates_count{active="false",channel_id="574380476322676737",public="true"} 37
lnd_channel_updates_count{active="false",channel_id="574560796294316032",public="true"} 356
lnd_channel_updates_count{active="true",channel_id="574244136963276801",public="true"} 75
lnd_channel_updates_count{active="true",channel_id="574379376815177729",public="true"} 114
lnd_channel_updates_count{active="true",channel_id="574379376815243265",public="true"} 282

My next steps are to add information about counts of invoices, count of on-chain transactions (by type / purpose), number of peers by inbound/outbound, histogram of ping times to peers, and total bytes sent / received and total sat sent/received , as the number of peers is usually bounded, breaking this down by peer pub_key is an option too.
After that:

number of broadcast batches and their sizes.
peer errors (i.e. EOF or parsing errors)
counts of channel location failures (i.e. received update about unknown channel from another peer)
number of graph vertex / edge updates (possibly separate by addition / deletions / update)
forwarding stat counters

These roughly correspond to what is seen in LND stderr/stdout and the log file during normal operation, just in more organized and machine parsable way.

@baryluk hey Witold you have any email or are you on the lnd slack? would love to talk about this stuff further

Small prelude of Grafana pulling data from Prometheus:

crt434, I should have a pull request reading in a day or two. It is rather simple, but there is some code duplication in few metrics and I am following some hints from Prometheus Go client library authors to make it cleaner (and more efficient).

@crt434 I am on lnd slack as baryluk.

@baryluk that looks dope!!!
I've been chatting w/ @cfromknecht a bit on the the least invasive way to integrate pluggable monitoring. We've concluded that our preferred path would be to: pull in the existing set of streaming RPCs, poll the relevant non-streaming RPC's, and to finally create a new StreamingTelemetry sub-systems and server-side streaming RPC. The role of this new streaming RPC would be to export simple key-values over the RPC system. The upside of this, is that we don't need to fully integrate a specific metrics or time-series DB, as that would increase the size of dependancies by quite a bit and increase the binary size as well. Instead we'd create internal schemas something like: channel.channel_point.settle, then the value should be something like r_hash.value.fee, and so on. This loosely couples the service pulling the metrics, from those that are actually generating them, and we can even utilize build flags such that if this isn't enabled, this is just a no-op.
The next level would be to collaborate on a new external repo that packages up: prometheus (or preferred, but prometheus seems pretty feature complete), the new daemon that exports parses the metric schema, and finally Grafana. Ideally this is able to be easily run as a docker container, such that it's a "one click install"!
So with this, we can easily add new relevant exported metrics (aside from those that are already in the streaming RPC interface) and also the lndmon deamon itself can also plug in diff metric backends.

We can also start a new channel on the slack to discuss this ongoing.

I find this pointless. Prometheus works very well and can be easily converted to other monitoring system using generic proxy, as it has rich enough metadata in metrics itselfs. Also prometheus Go library do have plugable modules to export data to other systems. Simply need to link in an additional package, or import a package, zero code changes to export stats to InfluxDB, Graphite or StatsD.

The upside of this, is that we don't need to fully integrate a specific metrics or time-series DB, as that would increase the size of dependancies by quite a bit and increase the binary size as well. I
That is pure speculation. Set of dependencies is extremely small. There is almost no change in size of binary or memory usage (my guess is that it is less than 50KB for code and 50KB for state keeping), or CPU usage (my guess it is less than 0.1%, and for some metrics actually exactly zero, as they are only computed at scrape time only) in my prototype. It is immeasurable, and compared to StatsD model, does not add significant network and CPU overheads that scale as the amount of processing incressing (which is silly).

You find the external daemon pointless? The goal there is to reduce the surface area of lnd itself, by providing the capabilities to export responding to requests for metrics to a distinct process. If any security vulnerabilities are discovered in the prometheus clients, then lnd itself would be isolated as the lndmon process would be given a read-only macaroon. The RPC route would also allow us to hide special notifications behind a build flag that can be used to further synchronize our integration tests.

I am in no way, arguing against the usage of Prometheus. From what I've learned of it, it seems pretty amazing.

If you invent a new set of streaming RPCs, and put monitoring outside of the lnd, I think the security will be actually lower, not to mention that the format used to communicate between lnd and external monitoring daemon would most likely follow very closely some existing monitoring system, or be broken due us not having enough experience with all potential future corner cases of monitoring. Why not Prometheues? It is already proven, and well maintained.

[Security vulnerability in Prometheues Go client]
Very unlikely. Almost impossible. The client takes zero input from external users (other than what HTTP server receives via GET request), it never connects actively to any system (trusted or unstrusted), and one is not supposed to leak any dynamic or private data via monitoring (if one does it is a fault of developer/user, not Prometheus Go library). My code opens separate HTTP server (standard Go http server) on localhost, but we can integrate into existing HTTP server, without needing to use separate port (there are benefits to having it on a separate port tho, and with separate request queue / threads for processing metrics). Only issue I could find about using Prometheues Go client is, if one scrapes metrics many times per second (which I actually have solutions for in my prototype - i.e. the size of the Lightning network graph requires O(n) traversal of all vertices, but I do cache results for 60 seconds, so not a problem), or the port is open to public and it is vulnerable to DDoS, but that is true to any monitoring solution, and sensible default and instructions to the user should solve that. Standard interval for monitoring lnd (so called scraping interval) and other systems should be 60 seconds. So not a problem. And even if some data leaks (like channel ids or peer pubkeys, or wallet balances), because somebody added metric with sensitive labels, and made it be open to public, it is not the end of the world, as many of this metadata are already public via network itself.

If any security vulnerabilities are discovered in the prometheus clients, then lnd itself would be isolated as the lndmon process would be given a read-only macaroon.
It is already read only.

The RPC route would also allow us to hide special notifications behind a build flag that can be used to further synchronize our integration tests.
I do not follow. What "special notifications"? Why this feature should be behind build flag? Monitoring is monitoring. It should not be used for too many things. One can use metrics in tests to verify some stuff (like the monitoring counters itself, or some internals of lnd), but that is really it.

You find the external daemon pointless?
More counterproductive, redundant, and reinventing the wheel.

The goal there is to reduce the surface area of lnd itself, ...
And I think using Prometheues go client achieves exactly that (compared to adding lndmon, integration tests, maintaining multiple implementations of lndmon, reinventing communication formats, which has a lot of subtle design issues, like buffering, sync/async, parsing, escaping of labels, no monitoring redundancy, etc). Big plus is that Prometheus go client library is small, well defined and maintained by experts in monitoring. Only security concern would be the fact that this is external dependency, and compromised code could sneak into the code base. But this is official Prometheus dev code, and we can pin dependency to specific release / commit hash. And no different than dozen other dependencies lnd uses.

I understand that using APIs and external daemon seams like more flexible, and extensible and more secure solution, but I not agree with any of these points.

or the port is open to public and it is vulnerable to DDoS, but that is true to any monitoring solution, and sensible default and instructions to the user should solve that.

AFAIK, that's always the case currently? As in there's no default authentication or anything like that, so users would have to spin up their own via like a proxy or special headers perhaps?

The RPC route would also allow us to hide special notifications behind a build flag that can be used to further synchronize our integration tests.

Special notifications as in once a particular operation hits a particular milestone. So like if we're forwarding an HTLC, when we actually decode the onion blob or something like that. This would allow us to further synchronize the integration tests when we do things like restarting or persistence tests.

Why this feature should be behind build flag? Monitoring is monitoring. It should not be used for too many things.

It should be behind a build flag simply because most instances will never actually utilize the features (example laptops and mobile clients), so we can make it opt-in essentially. Only if users set the build flag (when compiling) and also provide the relevant args should it become active. I've read the prometheus go client and it's surrounding code, and it is indeed much lighter than I originally suspected.
I've started to move away from the lndmon architecture all together however. Instead, I favor integrating prometheus at a closer level, but still behind a build flag. So in this case, the telemetry package would expose a certain set of interfaces that closes mirrors the histograms, gauges, counters, etc that come along with prometheus. The default implementation (no build flag specified) would simply just map and proxy these metrics over the regular streaming RPC. However, with the build flag set it would parse the relevant configuration, and set up the appropriate Prometheus client. The one challenge with this approach is creating a set of interfaces that's closely maps to the existing Prometheus interface without deviating too much while still providing it with all the extra options and arguments that come with all the gadgets.

This is on our map for 0.6, it hasn't been forgotten!

Hi, any updates on monitoring for us (folks that test latest changes to lnd)?

No longer on map for 0.6, but still not forgotten! 😆

Hey, in the meantime I built this exporter. https://github.com/platanus/lightning-prometheus-exporter. I don't have access through the api to all the goodies that https://github.com/lightningnetwork/lnd/pull/1355 is exposing, but is the first iteration.

See #3134. We'll have some follow up projects in this lane as well.

Nice! Now we have lnmon - which addresses the monitoring need.
I was able to install it in a few hours. Looks awesome!


Fix html errors

For Rancher (product) docs only
When contributing to docs, please update the versioned docs. For example, the docs in the v2.6 folder of the rancher folder.
Doc versions older than the latest minor version should only be updated to fix inaccuracies or make minor updates as necessary. The majority of new content should be added to the folder for the latest minor version.

Closing in favor of alternate solution.


Update dx-graphics-hlsl-to-load.md

@briannagerads : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@stevewhims : Thanks for your contribution! The author(s) have been notified to review your proposed change.


WIP: target mode spike

https://github.com/chef/chef-rfc/pull/324
Spike on target mode support.
Adds support for using train to configure remote nodes without installing Chef remotely.
Supports the execute resource and guards.

@btm can you rebase this?

@tas50 this is rebased.
@lamont-granquist you have since done the early run context work, I think I refactored to account for that.

This is going to need to be refactored to share more train bits with the new bootstrap I think, but given we need to figure out how we're going to refactor that still I don't know it's worth thinking about today.


Redis Can't modify Transparent Huge Pages (THP) through initContainers

i want to chang "echo never > /sys/kernel/mm/transparent_hugepage/enabled"
create Pod redis-cluster-shard0-1 in StatefulSet redis-cluster-shard0 failed error: Pod "redis-cluster-shard0-1" is invalid: spec.initContainers[0].volumeMounts[0].name: Not found: "host-sys"

Use this helm chart
https://github.com/kmodules/installer/tree/master/charts/prepare-kubernetes-cluster


Blade directive keeps showing as normal text in production

Hi. So i've tested this package on the local dev enviroment.
Now i pushed it to prod. On prod i did:

git pull origin main
composer require silviolleite/laravelpwa --prefer-dist
php artisan vendor:publish --provider="LaravelPWA\Providers\LaravelPWAServiceProvider"
composer dump-autoload
php artisan route:cache

But it still shows the blade directive as normal text.
The console does show that it registered the service worker: Laravel PWA: ServiceWorker registration successful with scope:  https://club.trmc.nl/
It runs on Laravel 11.x with Apache as web server (DirectAdmin.
Hopefully we can figure it out :)

Same issue, did you solve somehow?

Run this:
php artisan cache:clear
php artisan config:clear
php artisan view:clear
it solves my problem


Differ between error states in liftajax.js

LiftRules.ajaxDefaultFailure does currently not distinguish between different types of errors (i.e. non-redirecting status codes). Therefore an ajax call resulting in a 500 has the same effect as an ajax call timing out.
Please see:
https://groups.google.com/forum/?fromgroups=#!topic/liftweb/Je7yX6R76LQ

This could be a simple matter of updating the ajaxOnFailure callback in lift.js to be passed some additional parameters when it is invoked. However, the question is how those parameters are passed. In particular, jQuery normalizes some of the data the browser provides to build things like an aborted status vs a timeout status, etc. The liftVanilla implementation will have to be able to do something similar before we can fully support this.

Back then we just differed between "timeout" (string comparison) and "the rest" (http status code):
https://github.com/dhobi/liftajax/blob/master/src/main/scala/code/util/MyScriptRenderer.scala#L147
Don't know if this much of a help, just thought I'll share our somewhat hacky solution.

Aye, I skimmed that. I think there's value to going all the way here and exposing status code and cause-as-string somehow. Again, the core issue will be the liftVanilla implementation that doesn't rely on jquery---but it could be that that will also be easy. I'm not sure, just wanted to give a brief “this is how this could go” blurb and didn't have time to investigate deeply how hard it will be to differentiate those possibilities.


failed to memset memory: HIP_ERROR_InvalidValue (similar to #227)

System information

Linux CentOS 7.6 64bit
TensorFlow-rocm installed from source
TensorFlow 1.13.1
Python 3.6 (rh-python-3.6)
Installed using pip
Bazel 0.21.0
gcc 8.2.1
ROCm/MIOpen 2.5.7 (latest from yum repo as of June 25th)
Radeon VII 16 GB

First of all, a simple 'pip install tensorflow-rocm' installs a version of tensorflow that does not work in CentOS 7, due to a libm issue (2.23 needed, 2.17 present).
I then rebuilt tensorflow-rocm from source, select "rocm build" and installed the corresponding .whl file.
A very simple test of tf_cnn_benchmarks.py fails with the following log:
2019-06-26 14:40:39.693192: I tensorflow/core/platform/cpu_feature_guard.cc:141] Your CPU supports instructions that this TensorFlow binary was not compiled to use: SSE4.1 SSE4.2 AVX
2019-06-26 14:40:39.810050: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1531] Found device 0 with properties:
name: Vega 20
AMDGPU ISA: gfx906
memoryClockRate (GHz) 1.802
pciBusID 0000:07:00.0
Total memory: 15.98GiB
Free memory: 15.73GiB
2019-06-26 14:40:39.810243: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1642] Adding visible gpu devices: 0
2019-06-26 14:40:39.810334: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1053] Device interconnect StreamExecutor with strength 1 edge matrix:
2019-06-26 14:40:39.810387: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1059]      0
2019-06-26 14:40:39.810437: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1072] 0:   N
2019-06-26 14:40:39.810628: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1189] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 15306 MB memory) -> physical GPU (device: 0, name: Vega 20, pci bus id: 0000:07:00.0)
2019-06-26 14:40:43.521556: E tensorflow/stream_executor/rocm/rocm_driver.cc:461] failed to memset memory: HIP_ERROR_InvalidValue
Traceback (most recent call last):
File "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/tensorflow/python/client/session.py", line 1334, in _do_call
return fn(*args)
File "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/tensorflow/python/client/session.py", line 1319, in _run_fn
options, feed_dict, fetch_list, target_list, run_metadata)
File "/opt/rh/rh-python36/root/usr/lib/python3.6/site-packages/tensorflow/python/client/session.py", line 1407, in _call_tf_sessionrun
run_metadata)
tensorflow.python.framework.errors_impl.FailedPreconditionError: Failed to memcopy into scratch buffer for device 0
[[{{node _SOURCE}}]]
the rocm stack itself is working, tools like rocminfo, rocm_bandwidth_test  and mixbench all report meaningful results.  What can I do to debug this?

Hi @jjkeijser , for CentOS distro, we recommend using our docker images, you can find more instructions here:
https://hub.docker.com/r/rocm/tensorflow
ROCm requires devtoolset7 to be configured before the HIP/HCC toolset can function correctly on CentOS user bits, mainly to fulfill the GCC version dependency.

I've tested the docker image and that does work (with good performance, actually!)
However, I'd like to run it without docker; the code builds using either devtoolset-7 or devtoolset-8, it's just that I cannot get beyond the error mentioned above. Also, I noticed that the error code that is returned for the HipMemset function always seems to be InvalidValue - so I have no idea where it is failing.
How can I debug this further?  (if need be, remote access to the system can be arranged).

Thanks @jjkeijser , glad to know the docker image approach can work on your side.
Please note, due to the limited bandwidth, we won't be able to support TF-ROCm project on CentOS user bit configurations for community users; thank you for the understanding.
However, we do have an experimental Dockerfile that can build Tensorflow-rocm 1.13 release branch correctly for CentOS distro. You can find it here, and hopefully that can be helpful for your explorations.

For the record: with the aid of the Dockerfile above I was able to build tensorflow-rocm (natively, not using docker) and it runs even faster than inside the docker container. The only minor issue remaining is the slow startup time, caused by these messages:
2019-07-04 09:54:57.089425: I tensorflow/core/kernels/conv_grad_filter_ops.cc:979] running auto-tune for Backward-Filter
2019-07-04 09:54:59.756359: I tensorflow/core/kernels/conv_grad_input_ops.cc:1027] running auto-tune for Backward-Data

@jjkeijser , thanks for the update.
FYI, MIOpen compiles the kernels on the fly when you see those auto-tune message from TF. This is a one-time effort (for the particular release), the second time you run the TF benchmark MIOpen runtime can fetch the compiled kernels from the ~/.cache/miopen, therefore you won't see the warmup slowness.

@jjkeijser Hi, I had the same issue, I have cherry-pick #194 to fixed it. But I don't know why.


Adding StatementClient#filterByContextExtension

We have a need to use this filter -- hoping to get added into the library's API. Thanks!

failing tests due to #24 (fixed by #25)

If this is too specific of a helper method, maybe we could get the addFilter method made publicly visible instead.

Thanks for all the work! We're kinda crammed right now but we'll take a look at everything soon and provide feedback or accept the PR.

Opened up https://github.com/adlnet/jxapi/pull/27 - closing this PR


[SMALLFIX]improve javadoc

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/10080/
Test PASSed.

Merged build finished. Test PASSed.

LGTM


Errors with Technica_analysis_app.py

Error with @st.cache for function 'get_sp500_components()"
For this file "https://github.com/erykml/Python-for-Finance-Cookbook-2E/blob/main/05_technical_analysis_and_building_interactive_dashboards/technical_analysis_app.py"

Hi!
What kind of error are you getting?
Also, are you sure you are using the streamlit version from the requirements file?
Cheers!

Getting an error when I run that says there is a batch inferencing error when trying to pull data from s&p 500. I also ensured I had the correct streamlit version to match the requirements file. Do I need the exact versions from the requirements text for any programs external to python to run that specific code?

That is weird, as it works for me. Maybe some other library has issues. Could you try to create a new venv, install only the dependencies from requirements.txt and see if everything works then?


[TASK] Update official document Longhorn Networking

What's the task? Please describe
Update official document Longhorn Networking

conversion webbhook
admission webhook
recovery backend server

Describe the items of the task (DoD, definition of done) you'd like

Please use a task list for items on a separate line with a clickable checkbox https://docs.github.com/en/issues/tracking-your-work-with-issues/about-task-lists

[ ] item 1

Additional context
Add any other context or screenshots about the task request here.

I would like to contribute to this issue


Update scala-compiler, scala-library, ... to 2.13.6

Updates

org.scala-lang:scala-compiler
org.scala-lang:scala-library
org.scala-lang:scala-reflect

from 2.13.0 to 2.13.6.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Files still referring to the old version number
The following files still refer to the old version number (2.13.0).
You might want to review and update them manually.
.travis.yml

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-lang" } ]

labels: library-update, semver-patch, old-version-remains

Coverage decreased (-0.5%) to 95.455% when pulling 4d347c8e0353abbb053181b3c8e25ab261d0487b on scala-steward:update/scala-compiler-2.13.6 into cc542fa6a0c118677a94867c631cfd3799170ec5 on iheartradio:master.