Incorrect australian time-zones

I have a feeling you've used the daylight savings "time-zones" for the last few as they seem to be ahead by 1 hour.
  { offset: '+08:00', label: '(GMT+08:00) Western Time - Perth', tzCode: 'Australia/Perth' },
  { offset: '+09:30', label: '(GMT+09:30) Central Time - Darwin', tzCode: 'Australia/Darwin' },
  { offset: '+10:00', label: '(GMT+10:00) Eastern Time - Brisbane', tzCode: 'Australia/Brisbane' },
  { offset: '+10:30', label: '(GMT+10:30) Central Time - Adelaide', tzCode: 'Australia/Adelaide' },
  { offset: '+11:00', label: '(GMT+11:00) Eastern Time - Hobart', tzCode: 'Australia/Hobart' },
  { offset: '+11:00', label: '(GMT+11:00) Eastern Time - Melbourne, Sydney', tzCode: 'Australia/Sydney' },

(UTC +10) - Brisbane, Sydney, Melbourne, Hobart, Canberra
(UTC +9.5) - Adelaide, Darwin, Broken Hill
(UTC +8) - Perth

Ref: https://www.australia.gov.au/about-australia/facts-and-figures/time-zones-and-daylight-saving

Hey there, thanks for opening the issue!
I didn’t really include all of these manually, they come from the tz dataset. I feel they should be pretty accurate. The discrepancy you’ve pointed out is, apparently, due to this:

The UTC DST offset is different from the UTC offset for zones where daylight saving time is observed.

So, while it’s true that Australia/Adelaide has a UTC (GMT) offset of +09:30, the UTC DST offset would be +10:30. For my own use case, this doesn’t really matter. I’d use other other libraries and the tzCode for any serious calculations.
Maybe we could rename the offset key into utcOffset and add the UTC DST info in there as well. If this is something you could do, please let me know. :D

It's a bad idea to bake the offset into the label string, because for the half of the year in all the regions using DST that label is going to be inaccurate.

@vdh I had this exact same conclusion while building my own time zones list, it only embeds the "non DST/summmer time) offsets but allows you to programmatically get the "current time" offsets.
I would be happy getting your feedback here: https://github.com/vvo/tzdb/


HDFS: Correct environment variable names

Previously, using a configuration such as:
{     "data_node": {         "count": 5,          "cpus": 0.5,          "disk": 50000,          "heap": 1024,          "mem": 2048     },      "executor": {         "cpus": 0.1,          "disk": 30500,          "heap": 768,          "mem": 1024     },      "journal_node": {         "count": 3,          "cpus": 0.1,          "disk": 30500,          "heap": 1024,          "mem": 2048     },      "name_node": {         "cpus": 0.1,          "disk": 30500,          "heap": 1024,          "mem": 2048     } }
Would result in both the name and journal nodes using the default memory allocation as opposed to the specified one.

LGTM.


Fix bitnet ops missing class definition

Hello, I was poking around and noticed this was missing which broke the BitLinear layer.

Thanks for fixing it!


getBrowserDimensions returns incorrect dimensions

https://github.com/koola/pix-diff/blob/6ebf6521e7b2d98f336fafc28c3801ec628b3482/index.js#L240-L242
    getBrowserDimensions: function () {
        return browser.executeScript('return { height: window.screen.height, width: window.screen.width};');
    },

^ returns the screen's dimensions -- so when I'm on a 1920x1200 monitor, that's the dimensions I get, instead of my browser's actual size.

Hi @necramirez,
Thnx for the feedback, you are right. I should be more like this
// we need screen.height for the appium implementation, outerHeight for the desktop implementation
const windowHeight = this.platformName? 'window.outerHeight' : 'window.screen.height',
windowWidth = this.platformName ? 'window.outerWidth' : 'window.screen.width';

return browser.driver.executeScript(`return { height: ${windowHeight}, width: ${windowWidth}};`);

@koola can you pick this up also with https://github.com/koola/pix-diff/pull/37

This is fixed, closing.


Fixed Errant space in UEFI guest creation

Created a windows 10 guest with tap interface
got error when ran sh -x /usr/local/sbin/iohyve start win10:
bhyve -c 2 -H -w -m 8G -s 0,hostbridge -s 3,ahci-cd,/iohyve/ISO// -s '4,ahci-hd,/dev/zvol/zroot/iohyve/win10/disk0,sectorsize=512' -s 10, virtio-net,tap5 -s '11,fbuf,tcp=<IP_ADDRESS>:5900,w=800,h=600,wait' -s 12,xhci,tablet -u -s 31,lpc -l com1,/dev/nmdm1A -l bootrom,/iohyve/Firmware/BHYVE_UEFI.fd/BHYVE_UEFI.fd ioh-win10 user@host:~/iohyve # pci slot 10:0: unknown device ""
There should not be a space after -s 10,?
Removed the extra space and the guest started fine.
Sorry , But i did not investigate further how the code is different from the normal startup of non-uefi guests.

The global? $pci variable is empty before so the removed space is just created before.
It also seems that multiple tap interfaces wont work either. (Adds spaces between)
bhyve -c 2 -H -w -m 8G -s 0,hostbridge -s 3,ahci-cd,/iohyve/ISO// -s '4,ahci-hd,/dev/zvol/zroot/iohyve/win10/disk0,sectorsize=512' -s 10,virtio-net,tap5 virtio-net,tap6 -s '11,fbuf,tcp=<IP_ADDRESS>:5900,w=800,h=600,wait' -s 12,xhci,tablet -u -s 31,lpc -l com1,/dev/nmdm1A -l bootrom,/iohyve/Firmware/BHYVE_UEFI.fd/BHYVE_UEFI.fd ioh-win10

Hi,
I don't have the experience with UEFI quest. I think, that multiple TAP interfaces should be:
-s 10:0,virtio-net,tap5
-s 10:1,virtio-net,tap6, mac=...
So we need to enhance the iohyve script.
From the man page of bhyve
-s	slot,emulation[,conf]
slot	     pcislot[:function]	bus:pcislot:function
The pcislot value is 0 to 31.  The	optional
function value is 0 to 7.	The optional bus value
is	0 to 255.  If not specified, the function
value defaults to 0.  If not specified, the bus
value defaults to 0.
BR, Radek

Yes that is correct. This is just a quick-fix I PRed before reading up on the issue. The entire function needs some love to get in line with the functionality provided for non-uefi guests.


Faster tokenization (log(n) lookups & caching of possible merges)

This greatly speeds up tokenization of large prompts (up to 3000x faster for 2k prompt tokens), making it possible to use prompts of the full context length without paying quadratic costs.
Tested runfast builds on an M2 Max Mac w/ hyperfine & lorem:
# `lorem -n 128` yields 336 tokens;
# Only generating / consuming one token to test tokenization itself
hyperfine -L bin run_fasttoken,run_master --warmup=1 "./{bin} llama2.c.stories110M.bin -n 1 -i \"\$( lorem -n 128 )\""

Result:
Benchmark 1: ./run_fasttoken "llama2.c.stories110M.bin" -n 1 -i "$( lorem -n 128 )"
  Time (mean ± σ):      86.7 ms ±   2.9 ms    [User: 32.5 ms, System: 31.0 ms]
  Range (min … max):    81.8 ms …  90.6 ms    10 runs

Benchmark 2: ./run_master "llama2.c.stories110M.bin" -n 1 -i "$( lorem -n 128 )"
  Time (mean ± σ):     11.151 s ±  0.177 s    [User: 10.927 s, System: 0.168 s]
  Range (min … max):   10.950 s … 11.563 s    10 runs

Summary
  './run_fasttoken "llama2.c.stories110M.bin" -n 1 -i "$( lorem -n 128 )"' ran
  128.61 ± 4.72 times faster than './run_master "llama2.c.stories110M.bin" -n 1 -i "$( lorem -n 128 )"'

With lorem -n 750 (1997 tokens), this PR's build takes 100ms and master takes ~6min.

Just realized there's a simpler / even faster way to find the potential merges as any merged token will appear just after the first token of a merged pair in the sorted list of tokens. Turned this PR to Draft mode while I update the code accordingly :-)

Thank you for optimizations!
I've also implemented sorted vocabulary for faster lookup but on top of utf8 branch/PR.
I used bsearch(), it is part of the standard C library, and we can re-use  compare_token for qsort.
https://github.com/atamurad/llama2.c/commit/8a179f69dae5b8501ce5947681b27d16e4b31db4

We merged an alternative that incorporated some of this code. Ty!

@karpathy @atamurad glad that helped, thanks!!


Update 2.x to 2.19.0 (since 2.18.0 was cut)

Description
Update 2.x to 2.19.0 (since 2.18.0 was cut)
Related Issues
N/A

Check List

[ ] Functionality includes testing.
[ ] API changes companion pull request created, if applicable.
[ ] Public documentation issue/PR created, if applicable.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Thanks @dbwiddis , we may need to get https://github.com/opensearch-project/OpenSearch/pull/16455 in first, otherwise we won't be able to get main checks green


Style-based measure example

The existing Measure example is an excellent example of using overlays (and should be retained) - with OpenLayers 3 there was no alternative.  It is however relatively difficult to set up and then to clear, and does not support modify.  With better styling available in later versions of OpenLayers it would be easier to implement using vector styling, modify would be supported, and additional features such as the lengths of individual segments/sides would also be easy to implement.

i like this example ! the behavior of the dashed line  when zooming is funny it's become as animated ... 👍

https://deploy-preview-12441--ol-site.netlify.app/examples/measure-style.html looks great to me.
Thanks!

Hi
Is it a way to remove a point alone ? I can not find...

You can use ALT + click to remove points after you finished drawing, @jipexu


i18n Improvements

Right now, all languages are included in the download binary.  The only issue I have with this is when new translations are submitted, they won't be available in the download unless a new version is released.  Should we continue to release updates that just include translations, or should we only release with one language (en-US) and provide a page where users can download translations?

Created an orphan i18n branch that will now contain all translations.  Binaries will only include en-US.json.  Need to update site to hold a list of translations.


Trying to generate markdown for integration with slate - enchancement

Thanks for raising a Swagger2Markup issue. Please provide a brief description of your problem along with the Swagger2Markup version you are using. If possible, please also consider putting together a complete Swagger specification that reproduces the issue. It's better if the Swagger specification is small and isolate the issue.
Swagger2Markup version:
Problem description: i think this library is a fantastic tool to create a markdown from swagger. But, it wil be awesome if it can be extensible. Majority of the implementations are not extensible.
Ex: you only provide 4 sub sections (OverviewDocumentBuilder, PathsDocumentsBuilder, Def..,Sec..).  This library has so much more potential to be used as an integration layer with slate.

Hi,
what do you suggest? Which labels do you mean?
Feel free to describe your solution and feel free to create a PR. Its an open source project :smile:


Update to Oracle JDK 8u66

Thank you for the contribution. It was merged directly as b78fb320fc303fc503386aa6fac47fdd105ecbfb to keep commit history cleaner. Your contribution is still credited to you.


Refactor: Use dedicated element for app background

Resolves #75
Do not use background-attachment style on body element which suffers performance issues when scrolling leading to flashes of unstyled background, especially on mobile.
Instead, use a dedicated background element which is rendered only each time the viewport changes.

Flashes of styled background not not happening on mobile firefox, but on mobile safari.

Closing because not implementing this workaround. refer to #75 OP.


Live

Docs Build status updates of commit 79d525c:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/apps-in-teams-meetings/API-references.md
:white_check_mark:Succeeded
View

msteams-platform/apps-in-teams-meetings/design/designing-apps-in-meetings.md
:white_check_mark:Succeeded
View

msteams-platform/apps-in-teams-meetings/enable-and-configure-your-app-for-teams-meetings.md
:white_check_mark:Succeeded
View

msteams-platform/apps-in-teams-meetings/meeting-app-extensibility.md
:white_check_mark:Succeeded
View

msteams-platform/apps-in-teams-meetings/teams-apps-in-meetings.md
:white_check_mark:Succeeded
View

msteams-platform/apps-in-teams-meetings/teams-live-share-capabilities.md
:white_check_mark:Succeeded
View

msteams-platform/apps-in-teams-meetings/teams-live-share-faq.md
:white_check_mark:Succeeded
View

msteams-platform/apps-in-teams-meetings/teams-live-share-media-capabilities.md
:white_check_mark:Succeeded
View

msteams-platform/apps-in-teams-meetings/teams-live-share-overview.md
:white_check_mark:Succeeded
View

msteams-platform/apps-in-teams-meetings/teams-live-share-quick-start.md
:white_check_mark:Succeeded
View

msteams-platform/apps-in-teams-meetings/teams-live-share-tutorial.md
:white_check_mark:Succeeded
View

msteams-platform/apps-in-teams-meetings/teams-together-mode.md
:white_check_mark:Succeeded
View

msteams-platform/concepts/build-and-test/deep-links.md
:white_check_mark:Succeeded
View

msteams-platform/concepts/device-capabilities/location-capability.md
:white_check_mark:Succeeded
View

msteams-platform/concepts/device-capabilities/media-capabilities.md
:white_check_mark:Succeeded
View

msteams-platform/concepts/device-capabilities/native-device-permissions.md
:white_check_mark:Succeeded
View

msteams-platform/concepts/device-capabilities/people-picker-capability.md
:white_check_mark:Succeeded
View

msteams-platform/includes/sdk-include.md
:white_check_mark:Succeeded
View

msteams-platform/index.yml
:white_check_mark:Succeeded
View

msteams-platform/m365-apps/prerequisites.md
:white_check_mark:Succeeded
View

msteams-platform/resources/faqs.md
:white_check_mark:Succeeded
View

msteams-platform/resources/m365-plugins/m365-plugins-overview.md
:white_check_mark:Succeeded
View

msteams-platform/resources/partner-apps-for-moodle.md
:white_check_mark:Succeeded
View

msteams-platform/tabs/how-to/access-teams-context.md
:white_check_mark:Succeeded
View

msteams-platform/tabs/how-to/conversational-tabs.md
:white_check_mark:Succeeded
View

This comment lists only the first 25 files in the pull request.
For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Acrolinx Scorecards
We currently enforce a minimum score of 80.
Click the scorecard links for each article to review the Acrolinx feedback on grammar, spelling, punctuation, writing style, and terminology:

Article
Score
Issues
Scorecard
Processed

msteams-platform/apps-in-teams-meetings/API-references.md
91
30
link
:white_check_mark:

msteams-platform/apps-in-teams-meetings/design/designing-apps-in-meetings.md
93
15
link
:white_check_mark:

msteams-platform/apps-in-teams-meetings/enable-and-configure-your-app-for-teams-meetings.md
97
4
link
:white_check_mark:

msteams-platform/apps-in-teams-meetings/meeting-app-extensibility.md
98
7
link
:white_check_mark:

msteams-platform/apps-in-teams-meetings/teams-apps-in-meetings.md
100
0
link
:white_check_mark:

msteams-platform/apps-in-teams-meetings/teams-live-share-capabilities.md
90
7
link
:white_check_mark:

msteams-platform/apps-in-teams-meetings/teams-live-share-faq.md
95
2
link
:white_check_mark:

msteams-platform/apps-in-teams-meetings/teams-live-share-media-capabilities.md
93
4
link
:white_check_mark:

msteams-platform/apps-in-teams-meetings/teams-live-share-overview.md
96
2
link
:white_check_mark:

msteams-platform/apps-in-teams-meetings/teams-live-share-quick-start.md
93
6
link
:white_check_mark:

msteams-platform/apps-in-teams-meetings/teams-live-share-tutorial.md
94
16
link
:white_check_mark:

msteams-platform/apps-in-teams-meetings/teams-together-mode.md
99
1
link
:white_check_mark:

msteams-platform/concepts/build-and-test/deep-links.md
90
30
link
:white_check_mark:

msteams-platform/concepts/device-capabilities/location-capability.md
91
6
link
:white_check_mark:

msteams-platform/concepts/device-capabilities/media-capabilities.md
93
7
link
:white_check_mark:

msteams-platform/concepts/device-capabilities/native-device-permissions.md
93
11
link
:white_check_mark:

msteams-platform/concepts/device-capabilities/people-picker-capability.md
95
4
link
:white_check_mark:

msteams-platform/includes/sdk-include.md
100
0
link
:white_check_mark:

msteams-platform/index.yml
94
1
link
:white_check_mark:

msteams-platform/m365-apps/prerequisites.md
90
20
link
:white_check_mark:

msteams-platform/resources/faqs.md
91
8
link
:white_check_mark:

msteams-platform/resources/m365-plugins/m365-plugins-overview.md
94
8
link
:white_check_mark:

msteams-platform/resources/partner-apps-for-moodle.md
91
2
link
:white_check_mark:

msteams-platform/tabs/how-to/access-teams-context.md
91
28
link
:white_check_mark:

msteams-platform/tabs/how-to/conversational-tabs.md
94
3
link
:white_check_mark:

msteams-platform/tabs/how-to/create-channel-group-tab.md
91
20
link
:white_check_mark:

msteams-platform/tabs/how-to/create-personal-tab.md
93
14
link
:white_check_mark:

msteams-platform/tabs/how-to/create-tab-pages/configuration-page.md
93
5
link
:white_check_mark:

msteams-platform/tabs/how-to/create-tab-pages/content-page.md
91
7
link
:white_check_mark:

msteams-platform/tabs/how-to/create-tab-pages/removal-page.md
90
7
link
:white_check_mark:

More info about Acrolinx
Use the Acrolinx extension, or sidebar, in Visual Studio Code to check spelling, grammar, style, tone, clarity, and key terminology when you're creating or updating content. For more information, see Use the Visual Studio Code extension to run Acrolinx locally.


snap migration: lxd.migrate should copy certificates/key in new location

lxd 2.21,  migration from classic package to snap.
when using lxd.migrate:
new certificates/keys are created when migrating to snap packaging:
after migration, ~/snap/lxd/${id}/.config/lxc contains new client.crt and client.key
old ~/.config/lxc/client.* should be copied in instead.
if not, all already declared remotes do not trust anymore

Oh yeah, that's absolutely right, you should move your ~/.config/lxc/ to snap/lxd/current/.config/lxc/ to keep all your remotes and config. It's not something we can/should be doing from you in the migrate tool, but something we should print a message about for sure.

Fix pushed to our packaging branches.

Eh!
je ne savais pas que tu parlais en Français ;-)
tu as fait une démo hier dans ma société (Extia), Meetup Ops.
(https://www.youtube.com/watch?v=ne3l4COcGjw)
Dommage, je n'étais pas là.

:)


Possible to extend horizontal bar controller?

In the documentation I see that you can extend the controllers for .line, .bar, .radar, .doughnut, .polarArea, and .bubble.  Can you also extend the horizontal bar controller?  I am attempting to add target lines to each bar in the graph and I successfully did that by overriding the original controller.  I would also like to create other horizontal graphs without the target line but since I overridden the horizontal bar controller it will always draw a target line.  Here is my code for the target line with overriding the controller:
            var originalHorBarController = Chart.controllers.horizontalBar;
			Chart.controllers.horizontalBar = Chart.controllers.horizontalBar.extend({
				draw: function(){
					var self = this;
					var base;
					var x;
					var y;
					var width;

					console.log(arguments);
					originalHorBarController.prototype.draw.call(this, arguments[0]);
					console.log(this.chart.data.labels[0]);
					console.log("x:" + this.calculateBarX(1, 0) + " y:" + this.calculateBarY(1, 0) + " width:" + this.calculateBarBase(0, 0));
					console.log(this.getRuler(0).barHeight);
					console.log(this.chart.config.data.labels);
					console.log(this.chart.config.data.datasets[0].data);

					for(var i = 0; i < this.chart.data.datasets[0].data.length; i++){
						base = this.calculateBarBase(0, i);
						x = this.calculateBarX(i, 0);
						y = this.calculateBarY(i, 0);
						width = this.getRuler(i).barHeight;

						this.chart.chart.ctx.beginPath();
						this.chart.chart.ctx.lineWidth = "5";
						this.chart.chart.ctx.strokeStyle ="black";
						this.chart.chart.ctx.moveTo(x - 10, y - (width / 2));
						this.chart.chart.ctx.lineTo(x - 10, y + (width / 2));
						this.chart.chart.ctx.stroke();
					}
				}
			});

              new Chart(canvas, {
				type: 'horizontalBar',
			  	data: data
              });

@daviddevore11 the problem that you're running into is that you are replacing the original horizontalBar controller.
I would create a new type
Chart.controllers.newHorizontalBar= Chart.controllers.horizontalBar.extend({});

new Chart(canvas, {
  type: 'newHorizontalBar',
  data: data
});

@etimberg When I try to do this the graph switches my labels around to make it seem like a vertical bar chart and the graph is empty

@etimberg here is a link to a fiddle that I just created
https://jsfiddle.net/ntcdfs7q/

@daviddevore11 that's because there is no default config for the new chart type.
I updated your fiddle to use the same default config as the horizontal bar https://jsfiddle.net/ntcdfs7q/2/

@etimberg Thank you!  I can't believe I missed that!


Update README.md to fix broken watchOS sample link

These changes just update the README to fix the broken watchOS sample link.

@googlebot I signed it!

cc: @chliangGoogle


Get-DBAAvailabilityGroup - Primary AG member returns as 'Unknown'

Is this a feature OR bug:
Bug
System Details

Operating system name and version: Server 2012 R2 Core
Output from $PSVersionTable:

Name                           Value

PSVersion                      4.0
WSManStackVersion              3.0
SerializationVersion           <IP_ADDRESS>
CLRVersion                     4.0.30319.42000
BuildVersion                   6.3.9600.17400
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0}
PSRemotingProtocolVersion      2.2
Evaluate $PSVersionTable in PowerShell and paste the output here

Output of dbatools version:
ModuleType Version    Name

Script     0.8.903    dbatools
Evaluate (Get-Module dbatools -ListAvailable).Version and paste output here

SQL Server version for source/target
2016 Enterprise

Steps to Reproduce
Run:
Get-DbaAvailabilityGroup -SqlServer sql-prd-c01
against cluster from either a primary or secondary sync member
Action Results
AvailabilityGroup : AG-APP-PRD
ReplicaName       : SQL-PRD-V05
Role              : Unknown
SyncState         : Unknown
AvailabilityMode  : SynchronousCommit
FailoverMode      : Automatic
AvailabilityGroup : AG-APP-PRD
ReplicaName       : SQL-PRD-V06
Role              : Secondary
SyncState         : Synchronized
AvailabilityMode  : SynchronousCommit
FailoverMode      : Automatic
AvailabilityGroup : AG-InformationSystemsInternal
ReplicaName       : SQL-PRD-V05
Role              : Unknown
SyncState         : Unknown
AvailabilityMode  : SynchronousCommit
FailoverMode      : Automatic
AvailabilityGroup : AG-InformationSystemsInternal
ReplicaName       : SQL-PRD-V06
Role              : Secondary
SyncState         : Synchronized
AvailabilityMode  : SynchronousCommit
FailoverMode      : Automatic
AvailabilityGroup : AG-Intramaps
ReplicaName       : SQL-PRD-V05
Role              : Unknown
SyncState         : Unknown
AvailabilityMode  : SynchronousCommit
FailoverMode      : Automatic
AvailabilityGroup : AG-Intramaps
ReplicaName       : SQL-PRD-V06
Role              : Secondary
SyncState         : Synchronized
AvailabilityMode  : SynchronousCommit
FailoverMode      : Automatic
AvailabilityGroup : AG-Sharepoint
ReplicaName       : SQL-PRD-V05
Role              : Unknown
SyncState         : Unknown
AvailabilityMode  : SynchronousCommit
FailoverMode      : Automatic
AvailabilityGroup : AG-Sharepoint
ReplicaName       : SQL-PRD-V06
Role              : Secondary
SyncState         : Synchronized
AvailabilityMode  : SynchronousCommit
FailoverMode      : Automatic
AvailabilityGroup : AG-SSISDB
ReplicaName       : SQL-PRD-V05
Role              : Unknown
SyncState         : Unknown
AvailabilityMode  : SynchronousCommit
FailoverMode      : Automatic
AvailabilityGroup : AG-SSISDB
ReplicaName       : SQL-PRD-V06
Role              : Secondary
SyncState         : Synchronized
AvailabilityMode  : SynchronousCommit
FailoverMode      : Automatic
Expected Results
I would expect the PRIMARY member to be listed, instead it is only listed as 'Unknown'. I do recall this working at some point though, I cannot see where this is failing.
Attached Logs or any exception errors

Use of Start-Transcript can help collection of console output and exceptions
Certain commands will generate an exception log that you can find in following directory: dir $env:USERPROFILE\Documents\dbatools-exceptions.txt

None of these return any errors or exceptions.

Additional information, the user running this is a local administrator on both machines as well as 'sysadmin' on both SQL instances.

If you run this command from a secondary replica then the primary is going to return as unknown. This is by design in SMO because the secondary does have the information (only the primary replica does).
I do have plans to try and work on a different method that can be more accurate in showing the primary, no matter what replica in the AG you run it from....just going to take a bit of time.

Ah I think I know where I meesed up and what my particular issue was.
I'm writing a synchronization script to sync logins and SQL Jobs across the cluster members, when I was exctracting the AG group using 'Get-DbaAvailabilityGroup' I was actually pointing it at the CLUSTER name not the SERVER name.
That's why I was seeing the incorrect results.
Running it directly against the server returns the results expected. I'll just have to re-jig my script to take that into account.
If possible I would change this enhancement to 'Run the Get-DbaAvailabilityGroup against the cluster name and return all replica names and their correct roles' that would make things so much easier.
Whether it first checks the cluster for all members, then iterates through checking each AG and the role reported, the merge them into a single output.
My script is simply looking at the AG output, identifying which partner is the primary, then copying the logins and jobs to each secondary, for each AG.

I'm working around it now by simply pulling all the AG names, then using:
(Get-ClusterGroup -Name $agName).OwnerNode.Name
To pull the primary node.

@mhouston100 We have redone the command in the latest release. Let me know if that solves your issue or if we need to make some adjustments.

please reopen if there is an issue! thank you @wsmelton for fixing 👍

Get-DbaAvailiilityGroup does not return info about primaryReplica when run against SQL server 2017

@jensenjk if you feel there is a bug in the command of the current version of the module please open a new issue and provide all the details.


Add parentheses missed in #412

hey thanks @Grebenschikov .
i mean it was a rather large missing parentheses.
sincerly thank you for the catch

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Fix redirections for routes with access-token

Description
Fixes #8288

Upgrade Notes
Does this PR prevent a zero down-time upgrade? (Assume upgrade order: Controller, Broker, Server, Minion)

[ ] Yes (Please label as backward-incompat, and complete the section below on Release Notes)

Does this PR fix a zero-downtime upgrade introduced earlier?

[ ] Yes (Please label this as backward-incompat, and complete the section below on Release Notes)

Does this PR otherwise need attention when creating release notes? Things to consider:

New configuration options
Deprecation of configurations
Signature changes to public methods/interfaces
New plugins added or old plugins removed

[ ] Yes (Please label this PR as release-notes and complete the section on Release Notes)

Release Notes

Documentation

Codecov Report

Merging #8285 (80fe916) into master (c77c2c3) will decrease coverage by 56.65%.
The diff coverage is 12.86%.

:exclamation: Current head 80fe916 differs from pull request most recent head 6efe3a5. Consider uploading reports for the commit 6efe3a5 to get more accurate results

@@              Coverage Diff              @@
##             master    #8285       +/-   ##
=============================================
- Coverage     70.80%   14.15%   -56.66%
+ Complexity     4241       81     -4160
=============================================
  Files          1631     1590       -41
  Lines         85449    83774     -1675
  Branches      12878    12694      -184
=============================================
- Hits          60501    11856    -48645
- Misses        20757    71032    +50275
+ Partials       4191      886     -3305

Flag
Coverage Δ

integration1
?

integration2
?

unittests1
?

unittests2
14.15% <12.86%> (-0.05%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...va/org/apache/pinot/common/config/NettyConfig.java
0.00% <0.00%> (ø)

...pache/pinot/common/config/provider/TableCache.java
0.00% <0.00%> (-83.86%)
:arrow_down:

...inot/common/function/scalar/DateTimeFunctions.java
0.00% <0.00%> (-98.64%)
:arrow_down:

...ot/common/request/context/predicate/Predicate.java
0.00% <0.00%> (-66.67%)
:arrow_down:

.../org/apache/pinot/core/common/MinionConstants.java
0.00% <ø> (ø)

...manager/realtime/LLRealtimeSegmentDataManager.java
0.00% <ø> (-70.97%)
:arrow_down:

...a/manager/realtime/RealtimeSegmentDataManager.java
0.00% <ø> (-50.00%)
:arrow_down:

...ata/manager/realtime/RealtimeTableDataManager.java
0.00% <ø> (-68.28%)
:arrow_down:

...ava/org/apache/pinot/core/plan/FilterPlanNode.java
0.00% <ø> (-87.86%)
:arrow_down:

...inot/core/query/reduce/StreamingReduceService.java
0.00% <0.00%> (-67.93%)
:arrow_down:

... and 1370 more

Continue to review full report at Codecov.

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

Thanks for the fix! @joshigaurava Can you please take a look? The change looks good to me but my UI knowledge is very limited.

Reviewed. @Jackie-Jiang, looks good to me.


Support for HTTP basic auth in Kontena Loadbalancer

Single user/pass would be a good start

For stats, backends or frontends?

"web apps deployed in kontena"

Ok. Adding reminder here how I think it should look like in the haproxy config:
userlist auth_users_www_app
  user user1 password <bcrypt_password>
  user user2 insecure-password pass1234

frontend www_app
    .....
    acl auth_ok_www_app http_auth(auth_users_www_app)
    http-request auth realm www_app unless auth_ok_www_app

I'm thinking something like this. In the service which you have behind LB:
environment:
    - KONTENA_LB_BASIC_AUTH_SECRET=BASIC_AUTH_FOR_XYZ
secrets:
      - secret: BASIC_AUTH_FOR_XYZ
        name: BASIC_AUTH_FOR_XYZ
        type: env

The to write the secret use something like:
$ kontena vault write BASIC_AUTH_FOR_XYZ << EOF
→ user user1 password <bcrypt_password>
→ user user2 insecure-password pass1234
→ EOF

Would this kind of setup be simple enough?
Of course the docs should be have the usual warnings about basic auth limitations.

could it be simplified (no env "pointers")
secrets:
  - secret: BASIC_AUTH_FOR_XYZ
    name: KONTENA_LB_BASIC_AUTH_SECRET
    type: env

$ kontena vault write BASIC_AUTH_FOR_XYZ << EOF
→ user user1 password <bcrypt_password>
→ user user2 insecure-password pass1234
→ EOF

So users would be split with \n

Or it could just use users from the master's user db.
30.9.2016 16.25 "Matti Paksula"<EMAIL_ADDRESS>kirjoitti:

could it be simplified (no env "pointers")
secrets:

secret: BASIC_AUTH_FOR_XYZ
name: KONTENA_LB_BASIC_AUTH_SECRET
type: env

$ kontena vault write BASIC_AUTH_FOR_XYZ << EOF
→ user user1 password <bcrypt_password>
→ user user2 insecure-password pass1234
→ EOF
So users would be split with \n
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/kontena/kontena/issues/1053#issuecomment-250743436,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AANuy08yjsorR6TUl111jMsk7-VQWuFeks5qvQ2ugaJpZM4KKvbJ
.

@matti true, no need to duplicate
@kke I wouldn't use users from master as these user are not Kontena users, they are users of a given app/service


Remove "usedRoutes" from "gc" blob in summary

Currently, we store the following in the "gc" blob in summary for each data store:

gcNodes - A list of all nodes (data store and its DDSs) and their outbound routes (link to other nodes).
usedRoutes - A list of routes that are used in the data store.
The usedRoutes are added to the summary so that when a new summarizer client loads, it can identify whether a data store's used state changed since last summary. If so, it will summarize it again since it may have to update the unreferenced flag or the data store or its DDSs.

However, the usedRoutes can be removed which will reduce the size of the GC blob. We can generate the usedRoutes when a summarizer loads pretty cheaply:

Get the gcNodes from the "gc" blob of each data store. We don't need to realize the data stores for this, just read it's "gc" blob. We do this anyway the first time GC runs. We can delay this step until the first time GC runs too.
Run GC mark phase on the gcNodes and get the list of used routes for each data store. These become the reference usedRoutes as per the summary of the data stores.

@vladsud @anthony-murphy @pleath FYI

Sounds reasonable with me.
This will be a breaking change, right? In a sense that we need to keep writing old data for at least couple releases while using only gcNodes calculation.

Yes, we will have to write the used routes for couple of versions. However, once we stop writing the used routes, the summary for such files will not have used routes in gc blob. If these files are opened in an older version of runtime (without the new code that calculates used routes), it will realize every data store and DDS while summarizing. It's a corner case and it might be a little expensive but it should be fine.

Closing this in favor of https://github.com/microsoft/FluidFramework/issues/8429


Create a template for a landing page.

Currently both archive.html and index.html support sections.
so its easy to create a directory under content and a _index.md that points to either of those templates, for instance for content/blog or content/posts.
The plan is create an additional template for a landing page, this template could then be referenced in the main content/_index.md
This would make it so that the main site has a landing page and then the posts could be under any section/directory
I will create example content, that makes setting up under either format easy.

I think this is what I do with tabi: serve all posts from /blog, but show them in the main index/section. I explain how to set this up for tabi in the docs.
Instead of using a new template, I check for the existence of a single section_path variable. If that's present, I send that section to the paginate macro.
See the template and the macro.
Hope that helps!

I finished this a few days ago, I extended the pages.html template to also work with sections. I just have not commit it yet.


[0H5E] Pipeline reproduction (SPM - raw)

Softwares

SPM: We are Luddites and used SPM8 because most of our scripts were written for that and we didn't feel like changing them, and most of the pre-processing steps we use haven't really changed much since SPM5. Don't judge us.
NeuroSynth (online) was used to generate masks of anatomical regions for purposes of verifying our anatomical judgments.
Custom Matlab scripts for everything not handled entirely within SPM.

Input data
raw data
Additional context
see description below
List of tasks
Please tick the boxes below once the corresponding task is finished. :+1:

[ ] :ok_hand: A maintainer of the project approved the issue, by assigning a :checkered_flag:status: ready for dev label to it.
[ ] :deciduous_tree: Create a branch on your fork to start the reproduction.
[ ] :sunrise: Create a file team_{team_id}.py inside the narps_open/pipelines/ directory. You can use a file inside narps_open/pipelines/templates as a template if needed.
[ ] :inbox_tray: Create a pull request as soon as you completed the previous task.
[ ] :brain: Write the code for the pipeline, using Nipype and the file architecture described in docs/pipelines.md.
[ ] :blue_book: Make sure your code is documented enough.
[ ] :snake: Make sure your code is explicit and conforms with PEP8.
[ ] :microscope: Create tests for your pipeline. You can use files in tests/pipelines/test_team_* as examples.
[ ] :microscope: Make sure your code passes all the tests you created (see docs/testing.md).

NARPS team description : 0H5E
General

teamID : 0H5E
NV_collection_link : https://neurovault.org/collections/4936/
results_comments : Our responses are complicated somewhat by the fact that SPM masks out voxels with low signal, and in group analyses, if any one subject is missing a voxel, that voxel is masked out of the entire analysis. In this dataset, the amygdala ended up masked out of the whole-brain group analysis for both groups, and the ventral striatum ended up masked out of the equal indifference group only. So, by the rules that we are supposed to report whole-brain analysis results, we have to say "No" for any regions that did not appear in the whole-brain analysis, but really a "Not applicable" response would be more appropriate. To help supplement the whole-brain corrected-threshold results, we also looked at whole-brain results at an uncorrected threshold of p<.05 (cluster size = 5 voxels) and ran ROI analyses based on manually selected coordinates for ventral striatum and amygdala within a small sphere. Our confidence values are thus partially based on the outcomes of these supplementary analyses. We also recognize that not every analysis package masks out low-signal voxels as aggressively as SPM, which has partially informed our judgments about similarity to other teams. Further notes on each hypothesis are below.
Hypothesis 1 -- Did not show up at corrected threshold but did show up at an uncorrected threshold (and was marginally significant in an ROI analysis), so we think a Type II error is reasonably likely and the hypothesis might have been confirmed in a larger sample.

Hypothesis 2 -- Did not show up at any threshold (corrected or uncorrected up to p<.05) and also did not show up in ROI analysis, so we are reasonably confident in our rejection of this one.
Hypothesis 3 -- Did not show up at any threshold, but we confirmed that ventral striatum was not in the mask for the analysis, so it would not be expected to. However, even with manually selected ROIs, the hypothesis was not confirmed anyway (p=.5).
Hypothesis 4 -- Did show up at the corrected threshold (and thus enough of ventral striatum was in-mask for the analysis to work), and also came out significantly in our manually selected ROI analysis (p=.03).
Hypothesis 5 -- There was a very large and obvious cluster even at the corrected threshold, and it was also highly significant in our ROI analysis (p=1.6e-5).
Hypothesis 6 -- Did not show up at corrected threshold but at an uncorrected threshold there was a fairly clear cluster, although the ROI analysis was not significant (p=.14). So we think there is some chance of a Type II error and that the hypothesis might be confirmed in a larger sample, but with a bit less confidence than we had for Hypothesis 1. (Less confident of a possible Type II error, that is -- i.e., a bit more confident in our main result that Hypothesis 6 was not confirmed.)
Hypothesis 7 -- Did not show up at any threshold but we confirmed that amygdala was not in the mask for the analysis, so it would not be expected to. The effect WAS significant with manually selected ROIs (p=2.3e-5) -- but in the opposite direction of what was hypothesized (i.e., we found a negative effect of loss). Thus, by our interpretation of the rules, we are reporting this as "hypothesis not confirmed" with fairly high confidence, as the whole-brain analysis did not have any information about the amygdala and the ROI analysis actually contradicted the hypothesis.
Hypothesis 8 -- Did not show up at any threshold but again was not in the analysis mask. However, nothing was significant in the ROI analysis either (p=.41).
Hypothesis 9 -- This one is tricky to report, as we knew the amygdala did not appear in the whole-brain analysis mask for either group, and thus it was formally impossible to test with a whole-brain group analysis as instructed. However, in our ROI analysis, the hypothesis appeared to be confirmed (p=.019), although both means were negative, so really the "greater response to losses" for the equal range group would be more accurately described as a "less negative response to losses." By our interpretation of the rules, we are reporting this as "hypothesis not confirmed" in the whole-brain analyses because it can't really be tested with our standard pipeline, although we know the ROI analysis does seem to confirm the hypothesis, hence the low confidence we reported for the whole-brain "result." Note that we did run the stats model we would have run for the whole-brain analyses merely for purposes of uploading to NeuroVault, but we know there are no amygdala voxels in it.

preregistered : No
link_preregistration_form : NA
regions_definition : For the whole-brain analyses, we mostly used our own expertise in neuroanatomy combined with searches of the literature, especially for the subcortical structures. For vmPFC, whole-brain results were fortunately all unambiguous (either large portions of what was unmistably vmPFC were activated, or nothing in that general region was), but in all cases, we did also compare our judgments to NeuroSynth masks that matched those anatomical search terms. Typically we would not frame our hypothesis exactly the way they were in this study -- e.g., testing the hypothesis "is there an effect in vmPFC?" with a whole-brain analysis, as instructed. Either we would have an anatomical hypothesis that we would test with an ROI analysis (based either on coordinates from an atlas/meta-analysis, a functional localizer, or manual definition of the anatomial boundaries), OR we would run a whole-brain analysis and simply report loci of activity descriptively (i.e., listing the significant clusters and assigning anatomical labels as accurately as possible to the voxels within those clusters, but with no specific a priori hypotheses about the regions activated). So the way the project was framed did not fit exactly into our standard way of making inferences, and we simply did our best to accommodate the requirements without changing too much of our standard process.
softwares : SPM: We are Luddites and used SPM8 because most of our scripts were written for that and we didn't feel like changing them, and most of the pre-processing steps we use haven't really changed much since SPM5. Don't judge us. ,
NeuroSynth (online) was used to generate masks of anatomical regions for purposes of verifying our anatomical judgments. Custom Matlab scripts for everything not handled entirely within SPM.
general_comments :

Exclusions

n_participants : 100
exclusions_details : sub-100: taken out because inter-subject registration was extremely poor even after manually re-orienting the original images
sub-030, sub-088, sub-116: taken out for extreme head motion; this was subjectively based on visual inspection of all subjects' motion parameters for all runs and our own judgment (treating the motion holistically, including considerations for factors like overall movement vs. the number/magnitude of sudden motion spikes, but without explicit enumeration of the weighting of those factors), but was only performed once (i.e., we did not go back on our decisions after running statistical analyses)
sub-025, sub-043, sub-094, sub-113: taken out for their post-registration voxel masks being a poor fit to the overall sample mask (>2 standard deviations worse than average), as this meant it would further reduce the set of voxels SPM would include in the group analysis. (Note that this would not normally be a part of our workflow – we deemed it necessary after seeing how many voxels SPM had cut out of the analysis mask, but that is not an issue for us in our typical studies.)

Preprocessing

used_fmriprep_data : No
preprocessing_order : Removal of "dummy" scans (deleting the first four volumes from each run -- timing files were adjusted accordingly), motion correction, rigid coregistration ("Coregister" SPM command) of subject anatomical to MNI template, rigid coregistration of each subject's functional data to their coregistered anatomical image, resample images with all of those linear operations applied, non-rigid registration/warping ("Normalise" SPM command) of anatomical to MNI template, application of warping ("Normalise" again -- but only writing the transformation, not estimating it) to functional images, spatial smoothing.
brain_extraction : Not performed.
segmentation : Not performed (we use the older form of spatial normalization in SPM that does not require segmentation).
slice_time_correction : Not performed. (Typically we follow the recommendation not to use slice-timing correction for TRs under 2000ms or so.)
motion_correction : SPM8 "Realign" command -- Estimation parameters as follows: Quality=1 (highest), separation=4mm (default), smoothing=5mm (default), number of passes="register to mean" (does a first pass registering everything to the first image in the run, creates a temporary mean image, and then does a second pass registering everything to that mean), interpolation="7th Degree B-spline" (although we do not permanently write out the interpolated images at this step; we save only a mean image and the affine transformations in the NIfTI headers [see below]), wrapping="No wrap", weighting=none. Reslicing parameters: Resliced images="Mean image only", interpolation="7th Degree B-spline", wrapping="No wrap", masking="Mask images".

Other notes: No non-rigid registration at this stage; no unwarping; similarity metric is least squares (no option to change in SPM8), no slice timing correction as noted above.

motion :
gradient_distortion_correction : Not performed.
intra_subject_coreg : SPM8 "Coregister" command, "Estimate" procedure only (we do not write out interpolated images at this stage; we only save the affine transformations in the NIfTI headers, as with motion correction). Reference image=subject's anatomical (already coregistered to MNI template in an earlier step), source image=mean image from each run (generated during motion correction), other images=all other images from that run (post motion correction), objective function="Normalized Mututal Information", separation=[4 2] (default), tolerances=default values (a 12-item matrix), histogram smoothing=[7 7] (default).

Other notes: All rigid at this stage.

distortion_correction : Not performed.
inter_subject_reg : Two main steps -- rigid and non-rigid (see overall order of pre-processing above).

Rigid intersubject registration: SPM8 "Coregister" command, "Estimate" and "Reslice" procedures. "Estimate" options: Reference image=MNI T1.nii template provided with SPM8 (2mm isotropic voxels), source image=subject's raw T1 anatomical, other images=none, objective function="Normalized Mututal Information", separation=[4 2] (default), tolerances=default values (a 12-item matrix), histogram smoothing=[7 7] (default). "Reslice" options: Interpolation="7th degree b-spline", wrapping="No wrap", masking="Don't mask images".
Non-rigid registration: SPM8 "Normalise" command, "Estimate" and "Write" procedures. "Estimate" options: Source image=subject's T1 anatomical (post rigid coregistration), source weighting image=none, images to write=normalized version of same T1 anatomical (no other images written out at this stage), template image=MNI T1.nii template (same as for coregistration), template weighting image=none, source image smoothing=8mm [default], template image smoothing=none, affine regularisation="ICBM space template", nonlinear frequency cutoff=25 (default), nonlinear iterations=16 (default), nonlinear regularisation=1 (default). "Write" options: Preserve="preserve concentrations" (default), bounding box=default coordinates, voxel sizes=2mm x 2mm x 2mm, interpolation="7th degree b-spline", wrapping=none.
Non-rigid registration parameters from the anatomical non-rigid registration were then applied to all functional images from that subject (after rigid coregistration of the functional images to the subject's anatomical image), with all of the same "Write" options under the SPM8 "Normalise" command except for voxel size, which was set to 2.5mm isotropic.
Other notes: No surface-based registration; all volume-based. All based on T1 anatomical; no bias field correction, no segmentation, no Talairach transformations.

intensity_correction : Not performed.
intensity_normalization : Not performed (we used SPM but selected "None" rather than "Scaling" for the "Global normalisation" parameter during individual-subject stats).
noise_removal : Not performed. (In particular, we did not include motion parameters in our statistical estimation.)
volume_censoring : Not performed. (Any subject with extreme motion spikes enough to warrant de-spiking was removed from analysis entirely.)
spatial_smoothing : SPM8 "Smooth" command. Options: Images to smooth=all the images from each run (after all other pre-processing steps), FWHM=9mm x 9mm x 9mm, data type="same", implicit masking=none.

Other notes: Basic fixed (non-iterative) 9mm FWHM isotropic Gaussian smoothing kernel. All in volume space after all registration steps (i.e., after all subjects are in MNI space). True confession time: We originally used a 6mm kernel but after running some preliminary sanity checks on the group analyses, we decided too many voxels were getting masked out of the group analysis due to anatomical inconsistencies between subjects, so we re-ran the smoothing at 9mm and used that for the final analyses. We would normally use a smaller kernel but also our typical sample sizes are smaller than in this dataset (closer to N=20 and a single subject group), and because of the way SPM masks out voxels from group analyses, the higher the N, the more voxels are going to get masked out --  hence our decision to smooth more in order not to over-mask the group analyses. (This still did not work perfectly in the case of amygdala and ventral striatum, but we did our best.)

preprocessing_comments : The one pre-processing step we did that wasn't discussed here (but which was mentioned in our description of overal pre-processing sequence) was a resampling step we did between all the linear transformations on the functional images and the nonlinear (warping) transformation. We only do this as a separate step because we try to avoid resampling the functional images a bunch of times without need if all the transformations are doing is updating the NIfTI header's affine transformation matrix, which is true for our initial motion correction and linear coregistration steps, but we do like to save a resampled copy of the images with all of those affine transformations applied before any subsequent steps. (This is normally so we can do certain statistical analyses in individual-subject space that has been loosely affine-registered with standard space but not warped... we did not have to do any such analyses in this particular case but it is part of our standard processing stream, so we left it in.) Unfortunately SPM8's coregistration routine has a weird feature where it will only resample output images at the same voxel size as the reference image (even though the normalization routine will let you freely select a bounding box and voxel size). We did not want to resample all functional images at the resolution of our anatomical template, and unfortunately SPM8 does not provide a pure image-resampling function, so our hacked-together solution is to generate a spatial normalization matrix defining a null transformation and apply that to the functional images through the SPM8 normalization routine, which effectively resamples the images to the desired resolution without transforming them (but with any affine transformations from the NIfTI header applied prior to resampling and then zero'ed out in the resampled images). We chose to resample to 2.5mm isotropic voxels as that is the usual size at which we currently acquire our own fMRI data (and a convenient size to work with in general), although arguments could be made that another size could be more optimal for the NARPS dataset that was originally acquired at a different voxel size.

Analysis

data_submitted_to_model : All timepoints except for the removal of the first four volumes in each run (as discussed above), and all subjects except those specifically removed (as described above). We used all runs from every subject left in the analysis.
spatial_region_modeled : Full brain -- although as we noted at the top, this didn't really work as intended because SPM8 masked out essentially all amygdala voxels from the group analysis, due to one or more subject(s) having low signal, as well as most/all of the ventral striatum voxels for one of the participant groups. As such, inferences for those regions were not really possible following our standard pre-processing and stats procedures, even after expanding our initially chosen smoothing kernel and excluding subjects whose brains did not fit the groupwise in-brain voxel mask very well. This is not normally an issue for us because 1) we typically focus on areas that do not suffer from low signal, e.g. visual cortex and frontoparietal regions; 2) we typically have smaller samples (~20), and the more participants in a sample, the more voxels SPM8 is going to mask out of the group analysis; and 3) we don't do too many groupwise whole-brain analyses these days anyway (most of our analyses are things like MVPA which are all run at the single-subject level and do not require second-level fMRI group analyses), and if we were focusing on tricky areas like the amygdala or ventral striatum, we would typically use an ROI approach. As such, we did do the supplementary ROI analyses described earlier, where we essentially chose a single voxel from each region of interest for each subject (left amygdala, right amygdala, left ventral striatum, right ventral striatum) based on examining the functional and anatomical images, extracted a small (6mm radius) sphere around each one, averaged the relevant values from the first-level analysis in each sphere (excluding any NaN values using Matlab's 'nanmean' function), averaged left and right (excluding either one if all of its voxels were NaN values), and used that resultant value as the subject's value for that ROI in the subsequent group analysis. ROI analyses for VMPFC were similar, except we used the same seed voxel for everyone ([0 48 -8], the maximum voxel in the Neurosynth "ventromedial" meta-analysis) and a slightly larger sphere (10mm radius), and did not run separate analyses for left and right since the ROI was medial.
independent_vars_first_level : We used SPM8's "parametric modulations" feature, using the values specified in the NARPS data for each gain/loss parameter (1st order/linear effects only). The durations were modeled as 4sec because that was the value in the timing files we were given. Not sure what you mean exactly by "block design" predictors -- if you mean how runs were modeled, we did what most people do in SPM analyses -- modeled all of the runs in a single first-level model for each subject, with SPM automatically adding a regressor of all 1's for each run to model out the mean/baseline for that run. We used the canonical HRF included in SPM8 with no derivatives. We did not include regressors for motion or drift, although we did use SPM's default high-pass filter (128sec period). No other nuisance regressors. Other first-level parameters included: microtime resolution=16 (default), microtime onset=1 (default), model Volterra interactions=no, Global normalisation=none, no explicit mask, serial correlations=AR(1).

Orthogonalization of regressors -- this got a little weird. It is our understanding that SPM orthogonalizes parametric regressors in the order they are entered (i.e. the second parametric modulator essentially gets whatever variance is left over from the first; see e.g. http://andysbrainblog.blogspot.com/2014/08/parametric-modulation-with-spm-why.html). In theory this should not be a big deal if the regressors were properly orthogonalized in the design, but just in case, our solution was actually to run the first-level stats for each subject twice -- always putting both regressors in the model, but once entering the effect of gains first (followed by losses), and once entering losses first (followed by gains). The reasoning was that we wanted to emulate the logic of doing Type III sum of squares e.g. in an ANOVA model -- considering only the unique contributions of the regressor in question after the other effects had been accounted for. Thus, to get the effect of losses, we used the model in which gains had been entered first, and to get the effect of gains, we used the model in which losses had been entered first.
At the first level, we then entered a contrast to get the positive effect of gains for the losses-first model or the positive effect of losses for the gains-first model, e.g. [0 0 .25 0 0 .25 0 0 .25 0 0 .25 0 0 0 0] to get a contrast image that effectively averaged the beta values across runs for each subject.

RT_modeling : none
movement_modeling : 0
independent_vars_higher_level : Group stats were very simple in most cases. We just used the "one-sample t-test" 2nd-level model type in SPM8 and used the contrast images from the 1st-level analysis, with no covariates, implicit masking only, no "global calculation" or "overall grand mean scaling" or "normalisation" (these latter three being PET-only settings). Separate analyses were used for the effect of gains for range group, gains/indifference group, losses/range, and losses/indifference. For the effect of losses, in which we were asked to provide results in both positive and negative directions, we just specified two contrasts in the group model -- one of [+1] and one of [-1], with the latter simply reversing the direction of the test. For hypothesis 9, the question of how between-groups effects were modeled was moot, because we knew the amygdala values would be masked out. However, our supplementary ROI analysis for that hypothesis was done using a simple two-sample t-test (equal variances assumed since the assumption was not violated, although it did not affect the outcome either way to assume equal variances or not). Purely for purposes of uploading to NeuroVault, we did run the whole-brain between-groups model we would have run for hypothesis 9, which was a "two-sample t-test" SPM8 group model with independence=yes, variance=unequal, grand mean scaling=no, ANCOVA=no, no covariates, implicit masking only, no "global calculation" or "overall grand mean scaling" or "normalisation" (these latter three being PET-only settings).
model_type : Mass univariate.
model_settings : Included above but repeated here for 1st-level: We used SPM's default high-pass filter (128sec period). No other nuisance regressors. Other first-level parameters included: microtime resolution=16 (default), microtime onset=1 (default), model Volterra interactions=no, Global normalisation=none, no explicit mask, serial correlations=AR(1).

Included above but repeated here for 2nd-level (everything but hypothesis 9): No covariates, implicit masking only, no "global calculation" or "overall grand mean scaling" or "normalisation" (these latter three being PET-only settings).
Included above but repeated here for 2nd-level (hypothesis 9): Independence=yes, variance=unequal, grand mean scaling=no, ANCOVA=no, no covariates, implicit masking only, no "global calculation" or "overall grand mean scaling" or "normalisation" (these latter three being PET-only settings).
Further details: 2nd level was SPM default OLS approach. Variance for hypothesis 9 was SPM8 default re: pooling. Everything else in this section is N/A.

inference_contrast_effect : Noted above, but simple contrasts of [0 0 .25 0 0 .25 0 0 .25 0 0 .25 0 0 0 0] used at first level essentially to average across runs; at the second level, all models were simple t-tests so the only contrasts entered were [+1] and [-1]. We did not double p-values since the hypotheses in each region were directional (although in normal life we don't typically use or approve of one-tailed tests, for some reason they are still the norm in mass univariate fMRI analyses). Supplementary ROI analyses all used two-tailed tests.
search_region : Whole brain; no small volume correction. (Except for supplementary ROI analyses, but those were condensed to single values before statistical inference so no corrections were needed.)
statistic_type : Voxel-wise. No cluster significance corrections, but we did set a minimum cluster size of 5 voxels for ease of viewing results. (In theory, this would make our stats a bit over-conservative as we did not account for this minimum cluster size in any way, but it should be negligible for all practical purposes.)
pval_computation : Standard parametric inference.
multiple_testing_correction : Typical B&H voxel-wise FDR, as implemented in SPM8 (although in SPM8 it has to be enabled by a special preference setting).
comments_analysis : N/A on our end, but please let us know if anything is unclear / missing / appears to be wrong.

Categorized for analysis

region_definition_vmpfc : neurosynth, visually
region_definition_striatum : visually
region_definition_amygdala : visually
analysis_SW : SPM
analysis_SW_with_version : SPM8
smoothing_coef : 9
testing : parametric
testing_thresh : adaptive
correction_method : FDR voxelwise
correction_thresh_ : k>5

Derived

n_participants : 100
excluded_participants : 100, 030, 088, 116, 025, 043, 094, 113
func_fwhm : 9
con_fwhm :

Comments

excluded_from_narps_analysis : No
exclusion_comment : Rejected due to large amount of missing brain in center.
reproducibility : 2
reproducibility_comment :

warning : the pipeline might not be reproducible, as it seems to use custom code that is not shared.

@bclenet - I've reviewed the description of this pipeline and I did not identify steps that would make it impossible for us to reproduce. I agree with your reading that the "custom" code here might be related to building the flow of the pipeline more than adding custom steps. So I would keep this pipeline into the "to be reproduced" group.


Database interactions functions require a resource id to be exposed

Problem
Ex:
This issue was found by executing the following command.
atlas generate model another --fields name=string,friends=string[]
All comments will refer to code artifacts generated by the previous command.
Foreword
This issue implies an architecture choice that would force other changes on the current express service. Currently, the controllers layer is coupled with a MongoDb database, for the simple reason that you are exposing the Mongo Document interface when returning the "INew & Document" (aliased as "INewModel") type.
The following comments will adress an issue that arises if the Document interface is not exposed to the controllers layer.
Example
For the following command
atlas generate model another --fields name=string,friends=string[]
Sample output
See the database/interactions/new.ts file.
    find: (newId: string): Promise<INew> => {
        return New.findOne({ _id: newId }).exec();
    },

See the interfaces/INew.ts
export interface INew {
    friends: string;
    name: string;
}

The controller has no way of knowing a given database resource's id.
Proposal
Generated code for the interfaces/INew.ts
export interface INew {
    friends: string;
    name: string;
}

export type INewContent = Omit<INew, "_id">;
export type INewPartial = Partial<INew>;

Generated Code for the database/interactions/new.ts
export const newDBInteractions = {

    create: (neew: INewContent): Promise<INew> => {
        return New.create(neew);
    },

    all: (): Promise<INew[]> => {
        return New.find().exec();
    },

    find: (newId: string): Promise<INew> => {
        return New.findOne({ _id: newId }).exec();
    },

    update: (newId: string, newNew: INewPartial): Promise<INew> => {
        return New.findByIdAndUpdate(newId, newNew, { new: true }).exec();
    },

    delete: (newId: string): Promise<INew> => {
        return New.findByIdAndDelete(newId).exec();
    },
};

Why would we not expose INodeModel to the controllers?


Resolves #474: Add property support to UseDepVersion

adding a new parameter, processProperties, which will also update property values if dependencies are controlled by properties
the above parameter will be turned off in order to retain backwards compatibility

The behaviour of the property is described here:
/**
 *
Will augment normal processing by, if a dependency value is set using a property, trying to update
 * the value of the property.

 *
If the property value is specified directly, will process it normally (as with {@code processProperties} being
 * {@code false}. If the property being updated is redefined in the reactor tree, will only change the property
 * value which lies closest to the dependency being updated. If the same property is also used to set
 * the value of another dependency, will not update that property value, and log a warning instead.
 * Finally, if the property value is specified in a parent file which is outside of the project, will log
 * a warning message.

 *
Default is {@code false}.

 *
 * @since 2.14.2
 */

also, the behaviour is also "described" in the unit tests.
@slawekjaranowski please review
By the way, I've put 2.14.2 tentatively, but because of the nature of this PR, I'd understand if it did not fit into the release.

Manual testing...

Changed it so that it doesn't scan the whole tree if we're not processing properties.
Unfortunately, there's one problem I still don't know how to tackle -- maven unnecessarily descends into children even if the plugin could have made all necessary changes starting from root level.
Do you know how to change that so that Maven doesn't run recursively -- from the plugin?

I would like to postpone this for next minor release ... in next year 😄

That's OK 😄

So I guess that's a nice PR for 🎄😄

Note to self: https://maven.apache.org/developers/mojo-api-specification.html#The_Descriptor_and_Annotations
Since there's time, I'll polish it a bit.

Changed to aggregate mode; this change spurred the creation of a new enhancement: #880

Temporarily converting to draft: let's see if I we can use maven (to do the recursion) and plugin context instead.


Fix error in dereferencing kernel double pointers

BPF verifier can detect safety of pointer accesses for BTF-based probes (k(ret)func, iter) and therefore it is not necessary to use bpf_probe_read_kernel inside such probes. This feature was enabled in bpftrace by commit c2c3ab96 ("Support identifying btf type").
Unfortunately, the verifier is not able to track BTF information for dereferences and array accesses on double pointers so, e.g. the following script fails to load:
# bpftrace -e 'kfunc:__module_get { print(args.module->trace_events[0]->flags);' } -v
INFO: node count: 13
Attaching 1 probe...

Error log:
reg type unsupported for arg#0 function kfunc_vmlinux___module_get#22
0: R1=ctx(off=0,imm=0) R10=fp0
0: (79) r1 = *(u64 *)(r1 +0)
func '__module_get' arg0 has btf_id 250 type STRUCT 'module'
1: R1_w=ptr_module(off=0,imm=0)
1: (79) r1 = *(u64 *)(r1 +1128)       ; R1_w=scalar()
2: (79) r1 = *(u64 *)(r1 +0)
R1 invalid mem access 'scalar'
processed 3 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0

ERROR: Error loading program: kfunc:vmlinux:__module_get

A similar error happens when dereferencing the double pointer with *
# bpftrace -e 'kfunc:__module_get { print((*args.module->trace_events)->flags);' } -v

An analogous program fails to load even when written using libbpf.
We need to use bpf_probe_read_kernel for such cases so do not propagate the SizedType::is_btftype flag when observing a dereference or array access of a double pointer in semantic analyser.
This also fixes another bug related to array access - field analyser was not doing field resolution on array accesses on pointers to structs.
Overall, this resolves #3016.

Checklist

[ ] Language changes are updated in man/adoc/bpftrace.adoc
[x] User-visible and non-trivial changes updated in CHANGELOG.md
[x] The new behaviour is covered by tests

nice find! did you report this upstream? wonder if this should be supported by kernel

Not yet, but I'll report it. I wanted to check first if it is a bug or a feature :)

Seems more like a lack of a feature to me

Turns out the same problem exists when dereferencing via array accesses, i.e. args.trace_events[0]->flags. I'll try to fix that, too, in this PR.

Fixed the array access on our side, too. I'll report/fix kernel upstream.
Originally, I wanted to separate the dereference fix from the array access one b/c the latter is one of two issues causing #3016. It turned out that it makes more sense to have them together so I added the other fix for #3016 to this PR. We now have two changelog entries with the same PR number but I think that it makes sense to merge everything together.

Why is it that we need to reset is_btftype on the type contained within the array, but for pointers only the outer type gets reset?

It's actually the other way around - for pointers, we just reset the pointed type, for arrays we reset both the array and the element types.
The reason is that there's a slight difference in codegen for ptr->x and ptr[0]:

For ptr->x, we have two operations - dereference and field access. The load/probe_read is only done during the field access so the check for is_btftype is done on the type of *ptr.
For ptr[0], we have just a single operation so the check must be done on the type of ptr. We must also reset is_btftype on the element type to avoid further propagation.

Is it possible to add a unit test for the FieldAnalyser change?

Sure! I added a test (and confirmed that it failed prior to this PR).

While adding the test, I updated data_source.c for BTF and DWARF which changed one codegen test.

This slipped off my radar. I rebased onto the current master and will merge today afternoon if there are no objections.

Looks like a legit unit test failure

Looks like a legit unit test failure

This is a tricky one. It doesn't reproduce on a local build (at least not on my setup), only in Nix. It's caused by this (seemingly trivial) change in data_source.c:
diff --git a/tests/data/data_source.c b/tests/data/data_source.c
index c6a7f713..eaecbc45 100644
--- a/tests/data/data_source.c
+++ b/tests/data/data_source.c
@@ -21,7 +21,7 @@ struct Foo3 {

 struct Foo3 foo3;

-struct Foo3 *func_1(int a, struct Foo1 *foo1, struct Foo2 *foo2)
+struct Foo3 *func_1(int a, struct Foo1 *foo1, struct Foo2 *foo2, struct Foo3 *foo3)
 {
   return 0;
 }
@@ -115,7 +115,7 @@ int main(void)
   struct bpf_iter__task_file iter_task_file;
   struct bpf_iter__task_vma iter_task_vma;

-  func_1(0, 0, 0);
+  func_1(0, 0, 0, 0);

   bpf_iter_task();
   bpf_iter_task_file();

With this, the field_analyser_dwarf.uprobe_args unit test fails because liblldb willl fail to get function parameters for func_3. I was able to narrow it down to dwarf_parser.cpp:80 where func_3 is found but, for some reason, it is not identified as a function and therefore fn will be null. Maybe @ttreyer could give some help on this?

With this, the field_analyser_dwarf.uprobe_args unit test fails because liblldb willl fail to get function parameters for func_3. I was able to narrow it down to dwarf_parser.cpp:80 where func_3 is found but, for some reason, it is not identified as a function and therefore fn will be null. Maybe @ttreyer could give some help on this?

I have reproduced the environment with the error and will have a look at it 🙂

This look like an issue with LLDB and/or GCC 12.3.0, but not with GCC 11.4.1. I'm investigating further...
In the meantime, as a workaround to unblock this PR, you can add __attribute__((noinline)) to func_3, which force GCC to emit enough DWARF for LLDB to correctly locate the function and its information.

In the meantime, as a workaround to unblock this PR, you can add __attribute__((noinline)) to func_3, which force GCC to emit enough DWARF for LLDB to correctly locate the function and its information.

Works great, thanks! I added it to the PR, should be now ready to merge.


Baseline models

Hi guys,
Do you know if some GNN based baseline methods are going to be implemented in the tutorial? Similar than NN and LSTM for Argoverse 1.0 API, in order to know how to deal with the vectorized map.

Hi @Cram3r95, thanks for your interest in the AV2 MF dataset! It is in the cards to update the WIMP baseline with a preprocessing script compatible with AV2, but we don't have an ETA quite yet.
We'll be sure to update this issue when the baseline is ready.

Hi @wqi, that would be fantastic, since AV2 presents more information in order to leverage the vectorized hdmap, so GNNs could be a good option. Thank you!


add(dev-docs) video converter cli rfc

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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 26.383%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
255

Relevant Lines:
842

💛  - Coveralls


dapper&opentracing

I have a question, zipkin is based on dapper, and cs,cr,ss,sr have the same spanid.  But in opentracing, cs,cr and ss,sr do not have the same span id ,and they have a child of relationship. Is that may have some influence？
Looking forward for your answer！

opentracing does not define how to represent remote operations, so what you
are mentioning is how some choose to do it (or perhaps example code), right?
zipkin predates OT by a while, and its data model was written for RPCs
sharing span for client and server. That said, you'll notice
zipkin-go-opentracing has a flag on how to handle remote spans (ex shared
span or not).
Regardless, there's still work needed to support a single-host model, and
the primary driver for this work is OT which while doesn't explicitly
require single-host spans, in practice, many assume it.
https://github.com/openzipkin/zipkin/issues/1480

thanks for your answer, in brave-opentracing,
public final Span joinSpan(TraceContext context) , public Span newTrace(SamplingFlags samplingFlags)
the above two functions
so in remote operations, if i want to use the same span, i can just use joinSpan, if not just use newTrace.
is that right?

actually, you'd want to use newChild as newTrace should only be used when an existing trace can't be read (as it restarts a trace) cc @reta

oh i see, thanks so much


FAC.js:44     POST https://.my.connect.aws/ccp-v2/fac 400

I see this error 7 times in the console log after each login to CCP.

Same, has been that way since I've started working on it. It hasn't ever caused an issue that I'm aware of. I tracked it down somewhere but it's too minor for me to have given much time to it. If you search through previous issues and google it you'll see it's common. Out of curiosity- are you using federated authentication?

FAC 400 errors are expected, and not affecting anything.

I agree, if it's expected, it's not an error, and shouldn't be logged as such. at the least, it's a drag on development.

Why was this issue closed? At a minimum, if FAC errors are expected then do not write to the log as error. Just report it as info that a certain feature is not enabled/available. Ideally make the logs less verbose by default. At present there is not a decent way to mute these logs.
@vpogudina - Only ERRORS should be logged to the console. If it's not causing a problem then why log it as an error?
@hxgnZO - I am using SAML login. Finally, after lot of struggle I was able to get the SAML login to work. But, now I wonder if I should have gone with Twilio. The CCP login and logs are horrible!

I second this - I'll have to dig into it again sometime, I forget exactly what it was, I want to say it was an API gateway thing. If you are familiar with AWS resources/have good access, dig into the full application configuration for connect and how it is built. Might be something you can figure out. I think it was something to do with waiting for federated login basically- definitely would be nice to handle it. It's frustrating explaining to my boss/customer "yeah those errors are normal".

Just to be clear, this happens with non-federated login as well

Just to be clear, this happens with non-federated login as well

Thank you for that. I was curious about that. Whatever it is it only happens before the use authenticates shrug


Add basic CLI

Currently supports host and port args (which can also be set by S3_ACTIVE_STORAGE_{HOST,PORT} env vars. Is it worth adding some kind of --debug flag for setting log level instead of falling back to RUST_LOG?

Example of current cli output:
S3 Active Storage Proxy command line interface

Usage: s3-active-storage [OPTIONS]

Options:
      --host <HOST>  [env: S3_ACTIVE_STORAGE_HOST=] [default: <IP_ADDRESS>]
      --port <PORT>  [env: S3_ACTIVE_STORAGE_PORT=] [default: 8080]
  -h, --help         Print help

Addresses #14

Newer CLI help output with added doc strings:
S3 Active Storage Proxy command line interface

Usage: s3-active-storage [OPTIONS]

Options:
      --host <HOST>  The IP address on which the proxy should listen [env: S3_ACTIVE_STORAGE_HOST=] [default: <IP_ADDRESS>]
      --port <PORT>  The port to which the proxy should bind [env: S3_ACTIVE_STORAGE_PORT=] [default: 8080]
  -h, --help         Print help


bip32: infallible derive_pub

Closes #2752.

This looks great to me. A minor point on naming is that I notice we have from_*_idx methods, which are weird because (a) idx is an abbreviation that we don't use in other method names (according to our API docs it does appear in the bip152 module which we should also fix), but (b) our types are called Numbers not indexes.
I think we should change the names of the new types to HardenedChildNumber etc rather than just HardenedChild. This is a mouthful but I think usually users won't be using these, since in almost all cases they'd want the more-generic-and-shorter ChildNumber enum. And we should rename from_hardened_idx to from_hardened_child_number and same for the non-hardened one.

This looks great to me. A minor point on naming is that I notice we have from_*_idx methods, which are weird because (a) idx is an abbreviation that we don't use in other method names (according to our API docs it does appear in the bip152 module which we should also fix), but (b) our types are called Numbers not indexes.

Ok will do in this PR.

I think we should change the names of the new types to HardenedChildNumber etc rather than just HardenedChild. This is a mouthful but I think usually users won't be using these, since in almost all cases they'd want the more-generic-and-shorter ChildNumber enum.

Should we remove the pub from these new structs?

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

93 of 122 (76.23%)  changed or added relevant lines in 2 files are covered.
12 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.09%) to 83.052%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

bitcoin/src/psbt/mod.rs
6
9
66.67%

bitcoin/src/bip32.rs
87
113
76.99%

Files with Coverage Reduction
New Missed Lines
%

bitcoin/src/psbt/mod.rs
1
78.67%

bitcoin/src/bip32.rs
11
84.34%

Totals

Change from base Build<PHONE_NUMBER>:
-0.09%

Covered Lines:
19553

Relevant Lines:
23543

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

93 of 122 (76.23%)  changed or added relevant lines in 2 files are covered.
12 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.09%) to 83.052%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

bitcoin/src/psbt/mod.rs
6
9
66.67%

bitcoin/src/bip32.rs
87
113
76.99%

Files with Coverage Reduction
New Missed Lines
%

bitcoin/src/psbt/mod.rs
1
78.67%

bitcoin/src/bip32.rs
11
84.34%

Totals

Change from base Build<PHONE_NUMBER>:
-0.09%

Covered Lines:
19553

Relevant Lines:
23543

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

94 of 127 (74.02%)  changed or added relevant lines in 2 files are covered.
12 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.1%) to 83.039%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

bitcoin/src/psbt/mod.rs
6
9
66.67%

bitcoin/src/bip32.rs
88
118
74.58%

Files with Coverage Reduction
New Missed Lines
%

bitcoin/src/psbt/mod.rs
1
78.67%

bitcoin/src/bip32.rs
11
83.89%

Totals

Change from base Build<PHONE_NUMBER>:
-0.1%

Covered Lines:
19554

Relevant Lines:
23548

💛  - Coveralls

Note to myself (TODO)
Ok, we can now accept in Xpub::derive_pub a AsRef<[NormalChildNumber]>> but we need to implement the AsRef<[NormalChildNumber]>> for DerivationPath

we need to implement the AsRef<[NormalChildNumber]>> for DerivationPath

That is impossible. At best we could completely revamp the layout to allow unsafe casts but that loses conversions to enum. Now I realize the situation is pretty annoying and maybe the extension traits for Vec<*ChildNumber> & co are the right approach, so people could enforce normal numbers at parsing time but that still may suck. I think that a fallible version would still be useful.
(BTW time locks kinda have the same problem but people don't store them in arrays, so it's fine.)

I did a PR right now to @storopoli s branch...
where we did a tryfrom function that, from a DerivationPath, we could extract a vec<NormalChildNumber> that made the implementation work...
Still not resolving everything but we got progress.

@jaoleal that can be useful in a bunch of cases but it allocates so it'd be nice to see a non-allocating version too.

I`m not certain of what kind of "allocation" do you mean.
I wonder if is because of the
let mut ret = Vec::new()
Its possible. the only restriction is that we need to return a vec<KindOfKey> instead of a direct slicing...
But not possible for this one to be infallible because of the unreachable possibility of containing a HardenedChildNumber

Pedantically, it's not Vec::new but it's close enough. Returning a new vec requires an allocation (and the fact you mentioned new suggests your conversion isn't even optimal).

Its possible to exclude that and retrieve directly from the DerivationPath struct. the only restriction is that we need to return a vec<KindOfKey> instead of a direct slicing...

I don't understand this but it's getting late here, so maybe I'm just tired.

But not possible for this one to be infallible

Exactly that's why a fallible alternative method is useful.

That is impossible. At best we could completely revamp the layout to allow unsafe casts but that loses conversions to enum. Now I realize the situation is pretty annoying and maybe the extension traits for Vec<*ChildNumber> & co are the right approach, so people could enforce normal numbers at parsing time but that still may suck. I think that a fallible version would still be useful.

Yes, exactly. If we've Xpub::derive_pub only accepting AsRef<[NormalChildNumber]>> we then break the Xpub::derive_pub API and we need to fix all examples and other code to use NormalChildNumber.
This is a significant departure from the current API and also it would make Xpub::derive_pub very different from siblings that take a DerivationPath.
We can't infallible convert DerivationPath into a [NormalChildNumber] because nothing guarantees that the derivation path only contains NormalChildNumber (can still have HardenedChildNumber).
Is this a good tradeoff? Make Xpub::derive_pub but breaking the API?
If yes, then I will finish the work in this PR.
Otherwise we can close.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

94 of 126 (74.6%)  changed or added relevant lines in 2 files are covered.
11 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.1%) to 83.058%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

bitcoin/src/psbt/mod.rs
6
9
66.67%

bitcoin/src/bip32.rs
88
117
75.21%

Files with Coverage Reduction
New Missed Lines
%

bitcoin/src/psbt/mod.rs
1
78.67%

bitcoin/src/bip32.rs
10
84.08%

Totals

Change from base Build<PHONE_NUMBER>:
-0.1%

Covered Lines:
19581

Relevant Lines:
23575

💛  - Coveralls

@storopoli API breaks are expected these days and we prefer better API over unbroken API.
I personally believe we should have both methods because some applications will prefer to enforce normal path at parsing and the conversion is complicated. Something like this should work:
// note the lack of pub
fn internal_derive_pub<T: TryInto<NormalChildNumber>(&self, path: impl Iterator<Item=T>) -> Result<Xpub, T::Error> {
// current code here, call .try_into()? on each item in the for loop
}

pub fn derive_pub<I: IntoIterator<Item=NormalChildNumber>>(&self, path: I) -> Xpub {
    self.internal_derive_pub(path.into_iter()).unwrap_or_else(|never| match never {})
}

pub fn try_derive_pub<I: IntoIterator<Item=NormalChildNumber>>(&self, path: I) -> Result<Xpub, NormalChildNumberError> {
    self.internal_derive_pub(path.into_iter())
}

(We could also just expose the internal method and let people use unwrap_or_else but I think we should make the better approach less annoying.)

pub fn derive_pub<I: IntoIterator<Item=NormalChildNumber>>(&self, path: I) -> Xpub {
    self.internal_derive_pub(path.into_iter()).unwrap_or_else(|never| match never {})
}

What is the point of using a non-null safe language to do this ?
Including the
impl TryFrom<DerivationPath> for Vec<NormalChildNumber> {
    type Error = Error;
    fn try_from(value: DerivationPath) -> Result<Self, Self::Error> {
        let mut ret = Vec::new();
        for cnum in value.0.iter() {
            match *cnum {
                ChildNumber::Normal(normal) => {
                    ret.push(normal);
                },
                _ => return Err(Error::InvalidChildNumberFormat),
            }
        }
        Ok(ret)
    }
}

we could improve your proposal of a function for each possibility. Like:
// Certain of normalized path
fn derive_pub_pure( v: Vec<NormalChildNumber>) -> Xpub {}

// Uncertain about whats inside
fn try_derive_pub( v: DerivationPath) -> Result<Xpub, Error>{}

And use it like
let path: Vec<NormalChildNumber> = DerivationPath::from(*).try_into()

derive_pub_pure(path)

///Would work here too
try_derive_pub(path)

///Since a vector of Normals are easily convertible for DerivationPath

Pedantically, it's not Vec::new but it's close enough. Returning a new vec requires an allocation (and the fact you mentioned new suggests your conversion isn't even optimal).

Improving is not hard, we can iterate DerivationPath and return a owned vector slice...

Is this a good tradeoff? Make Xpub::derive_pub but breaking the API?

Yes. Don't worry about DerivationPath. Maybe we need to make a second NonHardenedDerivationPath or something to handle the case where users want an entire path of non-hardened child numbers, but we can do that later in a non-breaking way.
Right now we have a derive_pub method which unambiguously returns errors that can be caught at compile-time because it is doing an internal type coversion that users could be doing themselves (and which may not even be necessary).

What is the point of using a non-null safe language to do this ?

I don't understand what relation this has to non-null. Care to explain?

we could improve your proposal of a function for each possibility. Like:

Sorry, now I see I messed up the types. Check the fixed version.

And use it like

In your example you're doing an unneeded heap allocation. Let's not do those.

Improving is not hard, we can iterate DerivationPath and return a owned vector slice...

I don't understand, returning an owned vec requires heap allocation.

In your example you're doing an unneeded heap allocation. Let's not do those.

The only way that i could think of have certainty of ChildNumbers types and not using a heap allocation(I think, not expert on memory allocation) is:

//Here we just get rid of some abstraction since `NormalChildNumber` and `HardenedChildNumber`
//implement the same traits.
pub enum ChildNumber {
    /// Non-hardened key
    NormalChildNumber(u32),
    /// Hardened key
    HardenedChildNumber(u32),
}

struct DerivationPath<ChildNumber> (Vec<ChildNumber>);

impl DerivationPath<ChildNumber>{
    fn to_normal( path: Self) -> Result<DerivationPath<NormalChildNumber>, Error> {
        path.iter().for_each(|cnum| {
            if cnum <<PHONE_NUMBER> {
                cnum = ChildNumber::NormalChildNumber(cnum);
            } else {
                return Error
        }
        });
        Self
    }
    fn to_hard( path: Self) -> Result<DerivationPath<HardenedChildNumber>, Error> {
        path.iter().for_each(|cnum| {
            if cnum ><PHONE_NUMBER> {
                cnum = ChildNumber::HardenedChildNumber(cnum);
            } else {
                return Error
        }
        });
        Self
    }
}
//No more uncertainty
fn derive_pub(p: DerivationPath<NormalChildNumber>) -> Xpub {}

@jaoleal that doesn't work and there's no need to do that. The code that's written right now already avoids allocation. We only need to refactor it a bit to make fallibility generic.

I've spoken offline with @jaoleal and he will be taking over this PR.
We need more developers to rust-bitcoin.
I'll gladly review the PR and, if necessary, take over future PRs.

I`ll reopen the PR tagging the issue when i think better of the @Kixunil Iterator's strategy


[Add] new youtube channel link for web3 technologies

Site URL
https://www.youtube.com/@web3mantra
Description of the above provided site
This YouTube channel has 114 educational videos based on web3 technologies like blockchain, solidity, hardhat, smart contracts, etc. It is the best resource for web3.
Category
Youtube
Sub Category
web3
Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I am willing to work on this issue (optional)
[X] I am participating in Hacktoberfest 2023

@AmanPathan you are assigned!


How often does this poll?

I made some changes but haven't seen anything in slack yet maybe an hour ago. Using the hosted account.

you should see a notification in less the 30 seconds


fix: support nesting import config change

Description
breaking change in unimport
prefer to keep the current config pattern for unplugin-auto-import

Linked Issues
#236
Additional context

Thanks but it was actually intended. I didn't mark it as a breaking change because we didn't document it here.
Docs improved here e668704761e482f04e78741b6adad00a23a54939

https://github.com/antfu/unplugin-auto-import/issues/236#issuecomment-1192207243


Lmaskati/test

This PR is a draft until https://github.com/BabylonJS/UrlLib/pull/1 is merged, after which it needs to be tested with an updated CMake.

PR title could be updated here too :-)


Point to correct repository

Noticed the NPM page points to a different package's repository. Also, not stalking I swear.

Coverage remained the same at 100.0% when pulling 6090086cb4edff986e7331be589476ee6279c664 on Sintendo:patch-1 into 4dfd6aaed982ef660292d01057da6482777cc35f on Moeriki:master.

Whoops. Thanks!


Awesome books: style core elements

Description:
In this project, the Awesome Books application has been enhanced with CSS styles to improve its visual appeal and match the provided wireframe.
General Requirements:

Ensured there are no linter errors.
Followed the correct GitHub flow.
Documented work in a professional manner.
Adhered to the best practices for HTML & CSS.
Added CSS styles to the application to match the provided wireframe.
Used plain CSS to style the application.

Project Requirements

Implemented CSS styles to align the application with the overall layout specified in the provided wireframe.
Emphasized the overall layout rather than focusing on minor details.
Incorporated custom colors, fonts, backgrounds, and other stylistic elements to improve the user interface.

Changes Made:

Header Styling:

Improved the appearance of the header to ensure it aligns with the wireframe.
Adjusted font size, color, and margin for better visual hierarchy.

Book List Styling:

Styled the book list section to match the wireframe.
Used alternating background colors for book items to enhance readability.
Added border and padding to book items for a cleaner look.

Form Styling:

Styled the form to align with the wireframe.
Adjusted input fields and buttons for better alignment and usability.
Ensured the add button is positioned correctly at the right side of the form.

General Layout

Ensured the overall layout of the application matches the wireframe.
Concentrated on maintaining a consistent look and feel across the application.

Preview:

How to Test:

Clone the repository and navigate to the project directory.
Open the index.html file in a browser.
Verify that the application UI matches the wireframe.
Ensure all functionalities (adding, displaying, and removing books) are working as expected.

Screenshot of the completed work:

Conclusion:

This pull request enhances the Awesome Books application by adding CSS styles that improve its visual appeal and align it with the provided wireframe. All changes adhere to the project's requirements and best practices for HTML & CSS.

@landpeacelogistics
This comment is appreciated.

Our goal is to restrict having two books with the same title, the functionality was omitted due to inadequate inspection, this comment will be attended to as soon as possible.

@landpeacelogistics
@adejam

All previously received comments have been a positive contribution. Based on the comments received, we have been able to achieve the goal of building a bookstore with unique functionalities.

Changes Made:

Duplicate Book Title Check:

Added a mechanism to prevent adding duplicate book titles.
When a user attempts to add a book with a title that already exists, a modal dialog is displayed with the message "A book with this title already exists."

Book Removal and Restoration Logic:

Updated the removeBook method to move the book to a removed books list.
Implemented the restoreBook method to allow users to restore previously removed books.
Ensured that restoring a book checks for duplicate titles to maintain the integrity of the title uniqueness constraint.

Modular Modal Dialog Handling:

Created a showModal function to display messages in a modal dialog for better user interaction.
Introduced a showEditModal function to handle editing book details within a modal dialog.

Local Storage Management:

Enhanced local storage handling to store and retrieve both active and removed books.
Updated the updateLocalStorage method to handle both active and removed books, ensuring persistence across sessions.

UI Updates:

Updated the createBookElement and createRemovedBookElement methods to include buttons for removing, restoring, and editing books.
Improved the display logic in displayBooks to reflect the current state of the active and removed books.

Event Handling Improvements:

Streamlined event handling for form submission, book removal, restoration, and editing.
Ensured modals close properly on clicking outside or using the close button.

Testing:

[ ] Tested the application on multiple devices to ensure responsiveness and proper functionality of the added features.
[ ] Verified that duplicate titles are not allowed in both active and removed book lists.
[ ] Confirmed that modals display appropriate messages and close correctly.

screenshot of the job done:

LGTM
Looks good to me... Please merge... Goodluck on your next milestones

All comments are sincerely appreciated.