GO:NEW    invasive hyphae formation

background
Plant infection requires an infection cell, called an appressorium,
which uses a pressure-driven mechanism to breach the tough cuticle of the leaf (3, 4). Once inside plant tissue, the fungus elaborates pseudohyphalike
invasive hyphae that rapidly colonize living host cells, secreting effector molecules to suppress host immunity and facilitate infection (5).
we have plenty of terms for 'entry into host'  but only
GO:0106259    cell-to-cell migration in host
for cell to cell invasion.
I would therefore like to request
GO:NEW    invasive hyphae formation
synonym cell-to-cell migration by invasive hypha (exact)
synonym host  tissue colonization  (related)
synonym plant tissue colonization (related
synonym invasive growth (related, because although it is often called 'invasive growth' here we are describing the physical process rather than a size increase)
is_a  GO:0106259    cell-to-cell migration in host
Definition
The directional movement of a hyphal filament from one host cell to another. This process involves the clearance of plant-derived plasmodesmal occlusion materials, cytoskeleton based constriction of invasive hypha to traverse plasmodesmata.  Septins and F-actin are reorganized into an hourglass shape at the point of maximum hyphal constriction.
I know there is a term
GO:0036267   invasive filamentous growth
but this isn't describing invasion of cells.
@CuzickA  does this sound OK?
Needed for
PMID:29567712
instead of
GO:0030448 | hyphal growth
and GO:0106259 | cell-to-cell migration in host

This is also different from appressorium formation & terms related to that process?

Yes the appressorium is for entry into host, but not cell-to-cell migration, if I understood correctly. See the first paragraph which separates these 2 processes.
@CuzickA  is that correct?

Yes the appressorium is for entry into host, but not cell-to-cell migration, if I understood correctly. See the first paragraph which separates these 2 processes.
@CuzickA is that correct?

Yes this is correct

There  will still be some broader issues to resolve in this area. Entry into host and migration within host will be very different for different species  with different hosts (sometimes will be simultaneous), so these groupings are a little artificial.  A topic for a future call.

I will use 'cell-to-cell migration by invasive hypha' as the term label, since 'formation' would be a child of 'development', it seems confusing.

+[Term]
+id: GO:0140649
+name: cell-to-cell migration by invasive hypha
+namespace: biological_process
+def: "The directional movement of a hyphal filament from one host cell to another. This process involves the clearance of plant-derived plasmodesmal occlusion materials, cytoskeleton based constriction of invasive hypha to traverse plasmodesmata. Septins and F-actin are reorganized into an hourglass shape at the point of maximum hyphal constriction." [PMID:29567712]
+synonym: "host tissue colonization" BROAD []
+synonym: "invasive growth" BROAD []
+synonym: "invasive hyphae formation" EXACT []
+synonym: "plant tissue colonization" BROAD []
+is_a: GO:0106259 ! cell-to-cell migration in host
+property_value: term_tracker_item https://github.com/geneontology/go-ontology/issues/21125 xsd:anyURI
+created_by: pg
+creation_date: 2021-05-25T07:42:38Z
Also added comment: "Do not confuse with GO:0036267 invasive filamentous growth, which \ndoesn't describe invasion of cells within the host."
OK?
Thanks, Pascale


[go_router] Responsive navigation stack

Is there an existing issue for this?

[X] I have searched the existing issues
[X] I have read the guide to filing a bug

Use case
I'm creating a responsive design that works for all platforms that Flutter supports, but I'm finding some problems doing it.
I want to create two separate navigators, one for desktop and another one for mobile.
On the desktop navigator I want to have a left sidebar (a fixed drawer) and the route content at the right of the sidebar, using a nested navigation system.
On the mobile navigator I want to use a bottom navigation bar with the traditional navigation system, where the new screens that you push are set on top of the previous ones, including on top of the bottom navigation bar (no nested navigation).
I tried to achieve that by creating two different navigators, and switching from one to the other based on the screen width, but when I switch to the other navigation the app "resets" and gets back to the initial route. I'm using the same global key for both navigators.
Proposal
Allow to have two different navigators and switch between them based on the screen width (or any other parameter), but when the change happens, the current route should not change. Just repaint the UI but not change the current route.

Hi @JGeek00
You can handle this by using flutter_adaptive_scaffold (navigational elements would be a BottomNavigationBar on a small mobile device and a NavigationRail on larger devices).
I see there are open issues similar to the case you described https://github.com/flutter/flutter/issues/129850, https://github.com/flutter/flutter/issues/99100.
Closing this issue in favor of those issues, so please follow up on them for further updates.


Remove thread pools from importers

We've observed the checker starving its own import of publishing-api
content by sending many requests for the content_id lookup
during the rummager import.
This doesn't always happen but it is not worth the effort to investigate.
We've deployed to jenkins on integration, so we now care
more about consistency than speed.
Since the resources in integration are different from those on
our laptops, we shouldn't expect the execution model used
during dev to carry over particularly well.
We should also consider other users of the integration environment.

How does this affect the import time? Could we just make the pool size configurable and default it to 1?

@MatMoore I haven't tried to see how long it takes in dev, since I now mostly care about the integration runs.
The two envs are sufficiently different to be incomparable.

@MatMoore We could certainly rewrite the execution model to allow this to be configurable, if you think the feature is still needed, but actually at the moment the default would need to be 0 since the overall importer task already has its own thead.

Ok fine by me. We can always revisit it if it's still useful for dev.


German translation

add the German translation for that project

Hey, thanks so much for helping out with this! There are a few things we didn't have on our localization file that we have added now, so if you add these words we'll be good to go:

"category_SortBy" = "Sort by"; on line 8
"general_Detect" = "Detect %@ games on launch"; // %@ Will be replaced with a platform like "Crossover" or "Steam" on line 78 replacing lines 77 and 79
"general_CustomFolder" = "Custom %@ folder"; // %@ Will be replaced with a platform like "Crossover" or "Steam" on line 79 replacing lines 78 and 80.

lmk if you have any questions


Get diff of first commit

Trying to iterate all commits for a repository and unable to get diff of first commit which has no parents.
Try loading tree by hash 4b825dc642cb6eb9a060e54bf8d69288fbee4904 and that is not found.  What do I call patch against to get a diff of first commit? e.g. helpMe.Patch(firstCommit)
git-python supports this for example with NULL_TREE

As far as I know, this is not supported yet, unless you manually create an empty tree that can be fed to patch. We could provide such tree as a variable or modify Patch/DiffTree to allow nil.

Was there any more discussion on this elsewhere, or another pattern that achieves the same result?


Prevent TS registrations if has_unread_must_acknowledge_notifications is true (Old 326)

In gitlab by @A-Lawrence on Aug 31, 2015, 01:07
If the member has must_acknowledge notifications present, then they should be unable to register for TS.
Related to #325.

In gitlab by @A-Lawrence on Aug 31, 2015, 01:12
Resolved in 65e8f64
ALawrence66 - 2015-05-31T01:41:03.154782+00:00

In gitlab by @A-Lawrence on Jan 12, 2016, 19:18
Milestone removed


Snapshots from master not being published

Putting this up here for visibility - after #63, having issues with automatically publishing snapshots of master to Nexus.

K, should be getting snapshots published now...


Negative values mix up currency conversion format (de-de)?

Thanks for this module, it made my life a lot easier. It is working great so far. However, I am running into an small issue where I need some advice.
I am creating an Excel from an SQL Table with a currency column that is set by Set-ExcelRange -NumberFormat 'Currency'.
While for positive numbers, the expected format in Excel is as expected, negative values are formatted differently. No matter if the source column has a data type of DECIMAL(19,2) or MONEY.
Input decimal:

Input money:

Produce same output in Excel that is differently formatted for positive and negative values:

Expected output (after manually setting column to currency in Excel):

My/the users locale is de-de. Am I missing something?

Yes, could be the users locale. Please could you post a simple script and set of data the repros the issue.

Simple script with German style CSV delimiter and number format
$data = ConvertFrom-Csv @"
Region;State;Price
West;Texas;-923,71
North;Tennessee;1770,67
East;Florida;-458,68
East;Maine;661,24
West;Virginia;-053,58
North;Missouri;2235,67
South;Kansas;-992,47
North;North Dakota;640,72
South;Delaware;-5508,55
"@ -Delimiter ";"

$filename = "test"
$extension = ".xlsx"
$exportpath = ".\" + $filename + $extension
$tablename	= "table"
$tablestyle = "Medium4"

$xl = $data | Export-Excel -Path $exportpath -KillExcel -ClearSheet -BoldTopRow -FreezeTopRow -AutoFilter -AutoSize -TableName $tablename -TableStyle $tablestyle -WorkSheetName $filename -PassThru

$ws = $xl.Workbook.Worksheets[$filename]

$ws.Column(3) | Set-ExcelRange -NumberFormat "Currency"

Export-Excel -ExcelPackage $xl -WorkSheetname $filename -Show

Excel output with mixed up currency format:

So this is now marked wontfix?

Is your Get-Culture set to en ? It might be implicit even in under different locales.

This preserves the original numeric string
It needs the actual transform to numeric

$Config = @{
    GlobalImportExcelVerbose = $true
    AlwaysOpen               = $true
    AlwaysKill               = $false
    IncludeCultureDump =  $false
}
if ($Config.GlobalImportExcelVerbose) { $global:PSDefaultParameterValues['ImportExcel*:Verbose'] = $true }
$Paths = @{
    Export  = Join-Path $PSScriptRoot '.export' 'test-culture.xlsx'
}

$data = @'
Region;State;Price
West;Texas;-923,71
North;Tennessee;1770,67
East;Florida;-458,68
East;Maine;661,24
West;Virginia;-053,58
North;Missouri;2235,67
South;Kansas;-992,47
North;North Dakota;640,72
South;Delaware;-5508,55
'@ | ConvertFrom-Csv -Delimiter ';'

$exportExcelSplat = @{
    AutoFilter    = $true
    AutoSize      = $true
    BoldTopRow    = $true
    ClearSheet    = $true
    FreezeTopRow  = $true
    KillExcel     = $Config.AlwaysKill
    Show          = $Config.AlwaysOpen
    TableName     = 'name_table'
    TableStyle    = 'Medium4'
    WorksheetName = 'name_sheet'
}

[OfficeOpenXml.ExcelPackage]$pkg = $data
| Export-Excel @exportExcelSplat -Path $Paths.Export -PassThru -NoNumberConversion 'Price'

$sheet = $pkg.Workbook.Worksheets[1]
($ws = $pkg.Workbook.Worksheets[1])
$ws.Cells| select -first 5 | Ft

# $sheet.Column(3) | Set-ExcelRange -NumberFormat 'Currency'
# Expand-NumberFormat 'Currency'
# Expand-NumberFormat 'Number'

# # one way
# $ErrorActionPreference = 'break'
Set-ExcelRange -Worksheet $ws -Range 'C2:C10' -NumberFormat 'Number'
# or
Set-ExcelRange -Address $ws.Tables[0].Columns['Price'] -NumberFormat 'Currency'
# $ErrorActionPreference = 'continue'

Close-ExcelPackage $Pkg -Show

@caratage does the approach @ninmonkey suggested work for you?

Thanks for the suggestion! I don't have access to the system in question at the moment but will check and report back asap.

@dfinke I think there is a error in the 2nd switch condition of Public/Expand-NumberFormat.ps1 at line 18. It should be switch ([cultureinfo]::CurrentCulture.NumberFormat.CurrencyNegativePattern) { ... }

I will review

Thanks! Here my output for NumberFormat, where I found that my CurrencyNegativePattern equals 8. That would be the right one.
PS> $Culture = Get-Culture
PS> $Culture.NumberFormat

CurrencyDecimalDigits    : 2
CurrencyDecimalSeparator : ,
IsReadOnly               : False
CurrencyGroupSizes       : {3}
NumberGroupSizes         : {3}
PercentGroupSizes        : {3}
CurrencyGroupSeparator   : .
CurrencySymbol           : €
NaNSymbol                : NaN
CurrencyNegativePattern  : 8
NumberNegativePattern    : 1
PercentPositivePattern   : 0
PercentNegativePattern   : 0
NegativeInfinitySymbol   : -∞
NegativeSign             : -
NumberDecimalDigits      : 2
NumberDecimalSeparator   : ,
NumberGroupSeparator     : .
CurrencyPositivePattern  : 3
PositiveInfinitySymbol   : ∞
PositiveSign             : +
PercentDecimalDigits     : 2
PercentDecimalSeparator  : ,
PercentGroupSeparator    : .
PercentSymbol            : %
PerMilleSymbol           : ‰
NativeDigits             : {0, 1, 2, 3...}
DigitSubstitution        : None

bump

Not going to have time to work with this. Need to revisit.
If you can, happy to take a PR with appropriate tests applied for backwards compatibility and the fix.


Support WinGet package manager for Windows 10+

It would be really great to have ability to just install ninja like that out of the box:
windget install --id=NinjaBuild.NinjaBuild
Here is some instructions how it can be done: Microsoft Docs

CMake's winget yaml looks straightforward, it wants an .msi installer

About ".yaml for winget" seems like it should be generated with YAMLCreate.ps1 from winget-pkgs repo..
But this does not seems to be logical - clone whole repo during CI just for one script.
I can suggest something like this if "Ninja.Ninja" would be ok for package ID. So the left-overs are how to generate InstallerSha256 (should be easy) and ProductCode (have not found info yet).
# Created with YamlCreate.ps1 v2.0.0 using YAML parsing
# yaml-language-server: $schema=https://aka.ms/winget-manifest.installer.1.0.0.schema.json

PackageIdentifier: "Ninja.Ninja"
PackageVersion: "1.10.3" # Note 1.10.3 beacuse 1.10.2 already exist without .msi
InstallerLocale: "en-US"
PublisherUrl: "https://github.com/ninja-build/ninja"
PublisherSupportUrl: "https://github.com/ninja-build/ninja/issues/new"
License: "Apache License 2.0"
LicenseUrl: "https://github.com/ninja-build/ninja/blob/master/COPYING"
ShortDescription: "Ninja is a small build system with a focus on speed."
MinimumOSVersion: "<IP_ADDRESS>"
InstallerType: "msi"
Scope: "machine"
InstallModes:
- interactive
- silent
- silentWithProgress
UpgradeBehavior: "install"
Installers:
- Architecture: "x86"
  InstallerUrl: "https://github.com/ninja-build/ninja/releases/download/v1.10.3/ninja-windows.msi"
  InstallerSha256: # Generated with YAMLCreate.ps1
  ProductCode: # Generated with YAMLCreate.ps1
  InstallerSwitches:
    Custom: "ADD_CMAKE_TO_PATH=System"
- Architecture: "x64"
  InstallerUrl: "https://github.com/ninja-build/ninja/releases/download/v1.10.3/ninja-windows.msi"
  InstallerSha256: # Generated with YAMLCreate.ps1
  ProductCode: # Generated with YAMLCreate.ps1
  InstallerSwitches:
    Custom: "ADD_CMAKE_TO_PATH=System"
ManifestType: "installer"
ManifestVersion: "1.0.0"

Guess, PR with generated mainfest should be added to winget-pkgs only after this PR acceptance.

Thanks! I haven't looked at other project repos to see if they just add the .yaml script file, or if they auto-generate with the .ps1. It would only need to regenerate on Ninja release, so maybe it's not such a burden.

Great, thank you very much for the implementation!

P.S. Also found all the manifests inside WinGet REPO.
This might help a bit too

Tagging associated winget issue - https://github.com/microsoft/winget-pkgs/issues/2004

It will be a very interesting feature


Update lucene-analysis-common, ... to 10.0.0

About this PR
📦 Updates

org.apache.lucene:lucene-analysis-common
org.apache.lucene:lucene-core

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

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

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.apache.lucene" }
}]

labels: library-update, early-semver-major, semver-spec-major, commit-count:1

Superseded by #222.


Updated readme

I was just implementing oauth for my twitter/django application, and while the readme was really helpful, some commands were out of date (for example, the twitter API url's have been updated, parameters have been changed, etc). I've updated these in the documentation.

Closed the wrong PR. Sorry about that. Some of this is fixed.

Khalid Aziz
Computer Science
McCormick School of Engineering and Applied Science
Northwestern University, Class of 2013
Phone:<PHONE_NUMBER>
On Tue, Jul 28, 2015 at 10:13 PM, Joe Stump<EMAIL_ADDRESS>wrote:

Reopened #137 https://github.com/joestump/python-oauth2/pull/137.
—
Reply to this email directly or view it on GitHub
https://github.com/joestump/python-oauth2/pull/137#event-367928818.

@joestump for review or needs work?

I think we need to revisit the README's example and update it for Django 3, etc. I'd close this out for now I think.


Cleaned up remote debugger output

Two simple changes to address most, if not all the issues with missing newlines and whitespace in debug output from the remote debugger.

Return the original untrimmed string when MIResults.ParseCString does not parse a quoted string. This preserves newlines and whitespace from remote printf statements.
Append a newline as needed to unhandled notification messages ("=thread-group-added", "=library-unloaded", etc.)

Hi @devilman3d, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
We will now validate the agreement and then real humans will evaluate your PR.
TTYL, MSBOT;

:+1:

:+1:

:+1:


migrate to fargate and remove CDK code

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Integ tests are failing. Need to figure out why.


Fix TaskBuilderTest: Allow multiple port ranges in various tests

...which might happen (rarely) because of the port randomization.

LGTM


Update beam terminology to bridge

Describe Changes

Update beam to bridge

Checklist before requesting a review

[ ] I have performed a self-review of my code
[ ] Code styles have been enforced
[ ] All Hardhat tests are passing

Even though we can update the code in the repo without updating the bytecode, we can't reverify with the updated code and I'd rather keep the repo in sync with block explorers so I'm closing this


Stop Signing over the PartSetHeader for Votes and remove it from the Header

Description
This PR builds off of #441 and continues the work of #418 by not including the PartSetHeader in the CanonicalVote. It also removes the PartSetHeader from the Header's hash by removing it entirely from both types.Header and tmproto.Header
This PR can be merged into #441 or master after #441 is merged, whichever is most convenient for the reviewers
Closes: #456

Codecov Report

Merging #457 (74fcda5) into master (9d4265d) will increase coverage by 0.04%.
The diff coverage is 63.63%.

@@            Coverage Diff             @@
##           master     #457      +/-   ##
==========================================
+ Coverage   62.77%   62.82%   +0.04%
==========================================
  Files         263      263
  Lines       32526    32499      -27
==========================================
- Hits        20419    20417       -2
+ Misses      10555    10532      -23
+ Partials     1552     1550       -2

Impacted Files
Coverage Δ

state/validation.go
94.54% <ø> (-0.29%)
:arrow_down:

types/block.go
79.05% <ø> (+0.28%)
:arrow_up:

types/protobuf.go
53.33% <0.00%> (+1.38%)
:arrow_up:

types/vote.go
84.13% <0.00%> (-1.78%)
:arrow_down:

state/state.go
82.94% <100.00%> (ø)

types/canonical.go
95.23% <100.00%> (-0.22%)
:arrow_down:

libs/clist/clist.go
63.52% <0.00%> (-4.51%)
:arrow_down:

p2p/ipld/sample.go
83.63% <0.00%> (-3.64%)
:arrow_down:

types/tx.go
84.61% <0.00%> (-3.30%)
:arrow_down:

types/share_merging.go
72.47% <0.00%> (-2.30%)
:arrow_down:

... and 8 more


[ADAP-769] [Regression] bq jobs labeling doesn't work on 1.6.0

Is this a new bug in dbt-bigquery?

[X] I believe this is a new bug in dbt-bigquery
[X] I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior
Hello!
I have a macro that reads a list of environment variables and builds a dictionary that later is being caught by query-comment.job-label feature.
macros/bq_labels.sql:
{% macro bq_labels() %}{
    "system": "{{ env_var('LABEL_SYSTEM', 'airflow') }}",
    "owner": "{{ env_var('LABEL_OWNER', 'unknown') }}",
    "envtype": "{{ env_var('LABEL_ENV', 'dev') }}",
    "dag_id": "{{ env_var('LABEL_DAG_ID', 'unknown') }}"
}{% endmacro %}

dbt_project.yml:
...
macro-paths:
  - macros
query-comment:
  comment: '{{ bq_labels() }}'
  job-label: true
  append: true

It works perfectly when using dbt-bigquery==1.5.3. When I run the bq show command for my job, I can see the following output in the "Labels" column:
owner:monideep
system:airflow
envtype:local
dbt_invocation_id:58a6c0f6-3001-4c2c-8a73-84847f95662d
dag_id:demo-dag_test_dbt_dag_mde

But when using 1.6.0, it looks like it can't "parse" the macro. The output is the following:
dbt_invocation_id:fbf2d221-dd52-4baf-851a-9de0933689e5
query_comment:___bq_labels_____

Expected Behavior
The labels are parsed correctly, like in 1.5.3
Steps To Reproduce

Create a macro as described
Update dbt_project.yml as described
Run dbt run command

Relevant log output
No response
Environment
- OS: macos 13.4.1, ubuntu 20.04
- Python: 3.8
- dbt-core: 1.6.0
- dbt-bigquery: 1.6.0

Additional Context
No response

Thanks for reporting this @ddovbii !
I was able to reproduce the regression you reported locally using the following commands (assuming zsh on macOS and that the bq CLI is installed):

Reprex
Activate an environment using dbt-bigquery 1.5 and run:
dbt run --full-refresh
last_bq_job_id=$(grep -oE '[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}' logs/dbt.log | tail -n 1)
bq show --job=true "$last_bq_job_id"

Output:
  Job Type    State      Start Time         Duration            User Email          Bytes Processed   Bytes Billed   Billing Tier                           Labels
 ---------- --------- ----------------- ---------------- ------------------------- ----------------- -------------- -------------- --------------------------------------------------------
  query      SUCCESS   06 Aug 16:31:35   0:00:00.118000<EMAIL_ADDRESS> 0                 0              0              owner:unknown
                                                                                system:airflow
                                                                                envtype:dev
                                                                                dbt_invocation_id:8b68368d-51b7-4281-8a3a-d50d283f7bd4
                                                                                dag_id:unknown

Activate an environment using dbt-bigquery 1.6 and run:
dbt run --full-refresh
last_bq_job_id=$(grep -oE '[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}' logs/dbt.log | tail -n 1)
bq show --job=true "$last_bq_job_id"

Output:
  Job Type    State      Start Time         Duration            User Email          Bytes Processed   Bytes Billed   Billing Tier                           Labels
 ---------- --------- ----------------- ---------------- ------------------------- ----------------- -------------- -------------- --------------------------------------------------------
  query      SUCCESS   06 Aug 16:53:34   0:00:00.136000<EMAIL_ADDRESS> 0                 0              0              dbt_invocation_id:4f25a098-8b11-4be5-8025-1dcc17177f09
                                                                                query_comment:___bq_labels_____

I didn't confirm or deny, but the changes in #707 related to query_comment might be involved.

@aranke Are you suggesting that reverting just those two lines would resolve this? Or is there more to it?

Reverting those two lines did not resolve the issue. It looks like we're getting the unrendered query comment on profile. I'll keep digging.

I've spent a decent amount of time troubleshooting this and could not find the root cause. I was able to write a test that demonstrates this regression in the attached PR. However, when I run that test against 1.5.3, the functionality it calls doesn't work either; it actually throws an exception from attempting to run the underlying code. My guess is that something changed in one of the dependencies (google-cloud-* or dbt-core) and we're picking up a newer patch version that introduces a case that was never tested.
@dbeatty10 When you tested this on 1.5, did you use a fresh install, or did you reuse an environment that you already had? If it's the former, that would rule out my hypothesis. If it's the latter, then I'm really not sure how this was ever working on 1.5.3, despite knowing that both you and the OP got it to run successfully. In the meantime, could you run a pip list on your 1.5 and 1.6 environments and throw them up here? That would help us rule out packages.
@Fleid I think we need to slot this as sprint work as it would involve testing different combinations of dependencies to reproduce. Let me know what you think.

@mikealfare fair, and thanks a lot for digging into it.
Let's see what @dbeatty10 has to say about this ;)

@mikealfare It's no longer working in 1.4.x, 1.5.x, or 1.6.x for me. I don't recall if I updated my virtual environments related to 1.5.x since my reprex or not 🤷 See below for pip list and pip freeze and my most recent output across those three environments.

Reprex

Activate an environment using dbt-bigquery 1.4
deactivate
source ~/projects/environments/bigquery_1.4.0/bin/activate
dbt --version
python -m pip list > pip_list_bigquery_1.4
python -m pip freeze > requirements_bigquery_1.4.txt

python -m pip | pbcopy

Package                  Version
------------------------ ---------
agate                    1.6.3
attrs                    22.2.0
Babel                    2.11.0
betterproto              1.2.5
cachetools               5.3.0
certifi                  2022.12.7
cffi                     1.15.1
charset-normalizer       3.0.1
click                    8.1.3
colorama                 0.4.6
dbt-bigquery             1.4.0
dbt-core                 1.4.1
dbt-extractor            0.4.1
future                   0.18.3
google-api-core          2.11.0
google-auth              2.16.0
google-cloud-bigquery    3.4.2
google-cloud-core        2.3.2
google-cloud-dataproc    5.3.0
google-cloud-storage     2.7.0
google-crc32c            1.5.0
google-resumable-media   2.4.1
googleapis-common-protos 1.58.0
grpcio                   1.51.1
grpcio-status            1.48.2
grpclib                  0.4.3
h2                       4.1.0
hologram                 0.0.15
hpack                    4.0.0
hyperframe               6.0.1
idna                     3.4
isodate                  0.6.1
Jinja2                   3.1.2
jsonschema               3.2.0
leather                  0.3.4
Logbook                  1.5.3
MarkupSafe               2.1.2
mashumaro                3.3.1
minimal-snowplow-tracker 0.0.2
msgpack                  1.0.4
multidict                6.0.4
networkx                 2.8.8
packaging                21.3
parsedatetime            2.4
pathspec                 0.10.3
pip                      23.2.1
proto-plus               1.22.2
protobuf                 3.20.3
pyasn1                   0.4.8
pyasn1-modules           0.2.8
pycparser                2.21
pyparsing                3.0.9
pyrsistent               0.19.3
python-dateutil          2.8.2
python-slugify           7.0.0
pytimeparse              1.1.8
pytz                     2022.7.1
PyYAML                   6.0
requests                 2.28.2
rsa                      4.9
setuptools               58.1.0
six                      1.16.0
sqlparse                 0.4.3
stringcase               1.2.0
text-unidecode           1.3
typing_extensions        4.4.0
urllib3                  1.26.14
Werkzeug                 2.2.2

python -m pip freeze | pbcopy

agate==1.6.3
attrs==22.2.0
Babel==2.11.0
betterproto==1.2.5
cachetools==5.3.0
certifi==2022.12.7
cffi==1.15.1
charset-normalizer==3.0.1
click==8.1.3
colorama==0.4.6
dbt-bigquery==1.4.0
dbt-core==1.4.1
dbt-extractor==0.4.1
future==0.18.3
google-api-core==2.11.0
google-auth==2.16.0
google-cloud-bigquery==3.4.2
google-cloud-core==2.3.2
google-cloud-dataproc==5.3.0
google-cloud-storage==2.7.0
google-crc32c==1.5.0
google-resumable-media==2.4.1
googleapis-common-protos==1.58.0
grpcio==1.51.1
grpcio-status==1.48.2
grpclib==0.4.3
h2==4.1.0
hologram==0.0.15
hpack==4.0.0
hyperframe==6.0.1
idna==3.4
isodate==0.6.1
Jinja2==3.1.2
jsonschema==3.2.0
leather==0.3.4
Logbook==1.5.3
MarkupSafe==2.1.2
mashumaro==3.3.1
minimal-snowplow-tracker==0.0.2
msgpack==1.0.4
multidict==6.0.4
networkx==2.8.8
packaging==21.3
parsedatetime==2.4
pathspec==0.10.3
proto-plus==1.22.2
protobuf==3.20.3
pyasn1==0.4.8
pyasn1-modules==0.2.8
pycparser==2.21
pyparsing==3.0.9
pyrsistent==0.19.3
python-dateutil==2.8.2
python-slugify==7.0.0
pytimeparse==1.1.8
pytz==2022.7.1
PyYAML==6.0
requests==2.28.2
rsa==4.9
six==1.16.0
sqlparse==0.4.3
stringcase==1.2.0
text-unidecode==1.3
typing_extensions==4.4.0
urllib3==1.26.14
Werkzeug==2.2.2

dbt run --full-refresh
last_bq_job_id=$(grep -oE '[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}' logs/dbt.log | tail -n 1)
bq show --job=true "$last_bq_job_id"

Output:
  Job Type    State      Start Time         Duration            User Email          Bytes Processed   Bytes Billed   Billing Tier                                      Labels
 ---------- --------- ----------------- ---------------- ------------------------- ----------------- -------------- -------------- -------------------------------------------------------------------------------
  query      SUCCESS   11 Aug 07:22:57   0:00:00.157000<EMAIL_ADDRESS> 0                 0              0              dbt_invocation_id:f2879858-379b-40e2-95a8-888deb9d3f95
                                                                                query_comment:__system_______env_var__label_system____airflow_________owner__

Activate an environment using dbt-bigquery 1.5
deactivate
source ~/projects/environments/bigquery_1.5/bin/activate
dbt --version
python -m pip list > pip_list_bigquery_1.5
python -m pip freeze > requirements_bigquery_1.5.txt

python -m pip list | pbcopy

Package                   Version
------------------------- -----------
agate                     1.6.3
attrs                     23.1.0
Babel                     2.12.1
cachetools                5.3.1
certifi                   2023.7.22
cffi                      1.15.1
charset-normalizer        3.2.0
click                     8.1.3
colorama                  0.4.6
dbt-bigquery              1.5.5
dbt-core                  1.5.4
dbt-extractor             0.4.1
future                    0.18.3
google-api-core           2.12.0.dev0
google-auth               2.22.0
google-cloud-bigquery     3.11.4
google-cloud-core         2.3.3
google-cloud-dataproc     5.4.3
google-cloud-storage      2.10.0
google-crc32c             1.5.0
google-resumable-media    2.5.0
googleapis-common-protos  1.60.0
grpc-google-iam-v1        0.12.6
grpcio                    1.57.0rc1
grpcio-status             1.57.0rc1
hologram                  0.0.16
idna                      3.4
importlib-resources       6.0.0
isodate                   0.6.1
Jinja2                    3.1.2
jsonschema                4.18.6
jsonschema-specifications 2023.7.1
leather                   0.3.4
Logbook                   1.5.3
MarkupSafe                2.1.3
mashumaro                 3.6
minimal-snowplow-tracker  0.0.2
msgpack                   1.0.5
networkx                  2.8.8
packaging                 23.1
parsedatetime             2.4
pathspec                  0.11.2
pip                       23.2.1
pkgutil_resolve_name      1.3.10
proto-plus                1.22.3
protobuf                  4.24.0rc3
pyasn1                    0.5.0
pyasn1-modules            0.3.0
pycparser                 2.21
python-dateutil           2.8.2
python-slugify            8.0.1
pytimeparse               1.1.8
pytz                      2023.3
PyYAML                    6.0.1
referencing               0.30.1
requests                  2.31.0
rpds-py                   0.9.2
rsa                       4.9
setuptools                56.0.0
six                       1.16.0
sqlparse                  0.4.4
text-unidecode            1.3
typing_extensions         4.7.1
urllib3                   1.26.16
Werkzeug                  2.3.6
zipp                      3.16.2

python -m pip freeze | pbcopy

agate==1.6.3
attrs==23.1.0
Babel==2.12.1
cachetools==5.3.1
certifi==2023.7.22
cffi==1.15.1
charset-normalizer==3.2.0
click==8.1.3
colorama==0.4.6
dbt-bigquery==1.5.5
dbt-core==1.5.4
dbt-extractor==0.4.1
future==0.18.3
google-api-core==2.12.0.dev0
google-auth==2.22.0
google-cloud-bigquery==3.11.4
google-cloud-core==2.3.3
google-cloud-dataproc==5.4.3
google-cloud-storage==2.10.0
google-crc32c==1.5.0
google-resumable-media==2.5.0
googleapis-common-protos==1.60.0
grpc-google-iam-v1==0.12.6
grpcio==1.57.0rc1
grpcio-status==1.57.0rc1
hologram==0.0.16
idna==3.4
importlib-resources==6.0.0
isodate==0.6.1
Jinja2==3.1.2
jsonschema==4.18.6
jsonschema-specifications==2023.7.1
leather==0.3.4
Logbook==1.5.3
MarkupSafe==2.1.3
mashumaro==3.6
minimal-snowplow-tracker==0.0.2
msgpack==1.0.5
networkx==2.8.8
packaging==23.1
parsedatetime==2.4
pathspec==0.11.2
pkgutil_resolve_name==1.3.10
proto-plus==1.22.3
protobuf==4.24.0rc3
pyasn1==0.5.0
pyasn1-modules==0.3.0
pycparser==2.21
python-dateutil==2.8.2
python-slugify==8.0.1
pytimeparse==1.1.8
pytz==2023.3
PyYAML==6.0.1
referencing==0.30.1
requests==2.31.0
rpds-py==0.9.2
rsa==4.9
six==1.16.0
sqlparse==0.4.4
text-unidecode==1.3
typing_extensions==4.7.1
urllib3==1.26.16
Werkzeug==2.3.6
zipp==3.16.2

dbt run --full-refresh
last_bq_job_id=$(grep -oE '[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}' logs/dbt.log | tail -n 1)
bq show --job=true "$last_bq_job_id"

  Job Type    State      Start Time         Duration            User Email          Bytes Processed   Bytes Billed   Billing Tier                           Labels
 ---------- --------- ----------------- ---------------- ------------------------- ----------------- -------------- -------------- --------------------------------------------------------
  query      SUCCESS   11 Aug 07:38:06   0:00:00.138000<EMAIL_ADDRESS> 0                 0              0              dbt_invocation_id:71ac120a-a308-43ca-9db5-5b08dfe5f3fe
                                                                                query_comment:___bq_label_macro_name_____

Activate an environment using dbt-bigquery 1.6
deactivate
source ~/projects/environments/bigquery_1.6/bin/activate
dbt --version
python -m pip list > pip_list_bigquery_1.6
python -m pip freeze > requirements_bigquery_1.6.txt

python -m pip list | pbcopy

Package                  Version
------------------------ ---------
agate                    1.7.1
attrs                    23.1.0
Babel                    2.12.1
cachetools               5.3.1
certifi                  2023.5.7
cffi                     1.15.1
charset-normalizer       3.1.0
click                    8.1.3
colorama                 0.4.6
dbt-bigquery             1.6.1
dbt-core                 1.6.0
dbt-extractor            0.4.1
dbt-semantic-interfaces  0.2.0
future                   0.18.3
google-api-core          2.11.1
google-auth              2.20.0
google-cloud-bigquery    3.11.1
google-cloud-core        2.3.2
google-cloud-dataproc    5.4.1
google-cloud-storage     2.9.0
google-crc32c            1.5.0
google-resumable-media   2.5.0
googleapis-common-protos 1.59.1
grpc-google-iam-v1       0.12.6
grpcio                   1.56.0rc2
grpcio-status            1.56.0rc2
hologram                 0.0.16
idna                     3.4
importlib-metadata       6.6.0
isodate                  0.6.1
Jinja2                   3.1.2
jsonschema               3.2.0
leather                  0.3.4
Logbook                  1.5.3
MarkupSafe               2.1.3
mashumaro                3.8.1
minimal-snowplow-tracker 0.0.2
more-itertools           8.10.0
msgpack                  1.0.5
networkx                 2.8.8
packaging                23.1
parsedatetime            2.4
pathspec                 0.11.1
pip                      23.2.1
proto-plus               1.22.2
protobuf                 4.23.3
pyasn1                   0.5.0
pyasn1-modules           0.3.0
pycparser                2.21
pydantic                 1.10.9
pyrsistent               0.19.3
python-dateutil          2.8.2
python-slugify           8.0.1
pytimeparse              1.1.8
pytz                     2023.3
PyYAML                   6.0
requests                 2.31.0
rsa                      4.9
setuptools               56.0.0
six                      1.16.0
sqlparse                 0.4.3
text-unidecode           1.3
typing_extensions        4.6.3
urllib3                  1.26.16
Werkzeug                 2.3.6
zipp                     3.15.0

python -m pip freeze | pbcopy

agate==1.7.1
attrs==23.1.0
Babel==2.12.1
cachetools==5.3.1
certifi==2023.5.7
cffi==1.15.1
charset-normalizer==3.1.0
click==8.1.3
colorama==0.4.6
dbt-bigquery==1.6.1
dbt-core==1.6.0
dbt-extractor==0.4.1
dbt-semantic-interfaces==0.2.0
future==0.18.3
google-api-core==2.11.1
google-auth==2.20.0
google-cloud-bigquery==3.11.1
google-cloud-core==2.3.2
google-cloud-dataproc==5.4.1
google-cloud-storage==2.9.0
google-crc32c==1.5.0
google-resumable-media==2.5.0
googleapis-common-protos==1.59.1
grpc-google-iam-v1==0.12.6
grpcio==1.56.0rc2
grpcio-status==1.56.0rc2
hologram==0.0.16
idna==3.4
importlib-metadata==6.6.0
isodate==0.6.1
Jinja2==3.1.2
jsonschema==3.2.0
leather==0.3.4
Logbook==1.5.3
MarkupSafe==2.1.3
mashumaro==3.8.1
minimal-snowplow-tracker==0.0.2
more-itertools==8.10.0
msgpack==1.0.5
networkx==2.8.8
packaging==23.1
parsedatetime==2.4
pathspec==0.11.1
proto-plus==1.22.2
protobuf==4.23.3
pyasn1==0.5.0
pyasn1-modules==0.3.0
pycparser==2.21
pydantic==1.10.9
pyrsistent==0.19.3
python-dateutil==2.8.2
python-slugify==8.0.1
pytimeparse==1.1.8
pytz==2023.3
PyYAML==6.0
requests==2.31.0
rsa==4.9
six==1.16.0
sqlparse==0.4.3
text-unidecode==1.3
typing_extensions==4.6.3
urllib3==1.26.16
Werkzeug==2.3.6
zipp==3.15.0

dbt run --full-refresh
last_bq_job_id=$(grep -oE '[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}' logs/dbt.log | tail -n 1)
bq show --job=true "$last_bq_job_id"

  Job Type    State      Start Time         Duration            User Email          Bytes Processed   Bytes Billed   Billing Tier                           Labels
 ---------- --------- ----------------- ---------------- ------------------------- ----------------- -------------- -------------- --------------------------------------------------------
  query      SUCCESS   11 Aug 07:37:17   0:00:00.186000<EMAIL_ADDRESS> 0                 0              0              dbt_invocation_id:a2723e58-86f8-421d-9992-bd0e7496bc68
                                                                                query_comment:___bq_label_macro_name_____

That's interesting, I wonder why we're getting pre-releases in our final releases:

<EMAIL_ADDRESS>google-api-core, grpcio, grpcio-status, protobuf
<EMAIL_ADDRESS>grpcio, grpcio-status

Here's what we have for the prerelease bundle:
https://github.com/dbt-labs/dbt-core-bundles/blob/main/release_creation/bundle/requirements/v1.5.pre.requirements.txt
And for the initial final release bundle:
https://github.com/dbt-labs/dbt-core-bundles/blob/29c6e2ee14ddafe846d0c3f4eec2122da39ee266/release_creation/snapshot/requirements/v1.5.latest.requirements.txt
And for the homebrew formula for 1.5.1 (we released later minors yesterday, so they wouldn't be valid snapshots):
https://github.com/dbt-labs/homebrew-dbt/blob/main/Formula/dbt-bigquery%401.5.1.rb

I'm not currently creating my local virtual environments using bundles, but maybe I should switch over?
Instead, I've been using commands like this so that I can install and try out betas for dbt-bigquery 1.7 without needing to change my instructions once it is a final release. But I'm guessing that the --pre is allowing prereleases of dependencies to be installed as well?
python3 -m venv bigquery_1.5
source bigquery_1.5/bin/activate
python3 -m pip install --upgrade pip
python3 -m pip install --upgrade --pre dbt-bigquery~=1.5.0.dev0 dbt-core~=1.5.0.dev0
source bigquery_1.5/bin/activate
dbt --version
deactivate

Oh, yes, the --pre is why we're getting pre-releases. Ok, I'm less concerned about that now. I know we're moving towards bundles in general for end use because it's a repeatable installation. Having another person try it out early would be useful for feedback. Also, we do generate bundles for prereleases, but I think they need to be at the RC stage. So if you're looking to try out 1.7.0b1 or 1.7.0a1, you probably still need to do what you're doing.

Is there any updates on the above issue or corresponding PR please?

hi, is there any updates on the this issue?

@mikealfare @dbeatty10
I have worked on this in a local environment and have been able to get it working again.
I believe that these two lines are the culprit and reverted them back to before the change mentioned to get the job-labels working again.
Firstly, this change talks about adding a limit to the execute signature to align with dbt-core; which in itself is absolutely fine. But I don't think changing these two lines were necessary to achieve that and an oversight given the below reasoning.
The implementation of query_header.comment.query_comment is different to profile.query_comment in that the query_header version implements MacroQueryStringSetter which seems to be performing some security checks around SQL injection within a query comment after obtaining it from the profile.query_comment rather than just pulling directly. It seems odd to have removed these checks?
I feel I PR to change the two lines in question back to their original state will fix things.
What do people think?

@RGreen90 These are the same two lines that @aranke had also pointed out above. I reverted those two lines, but that didn't work due to methods and/or properties not existing. In other words, it seems like something else changed related to items in those two lines, and those two lines cannot be reverted in isolation. Perhaps I'm misunderstanding something. Feel free to throw up the PR and I'll review it.

@mikealfare
Yes I realised this when I checked over the dev init and it failed the mypy checks. It's weird, so I was initially testing this in a poetry managed env using the poetry run pip install -e /path and things were working with just changing those two lines. Will dig a bit further!

Is there any plans to fix this?

hi @affsantos thanks for the bump. @mikealfare was able to create a test case that demonstrates the regression, but we haven't had time yet to iron it out.
our current plan is to dedicate capacity for fixing it in a current sprint. in the meantime, you're welcome to branch off of #872 to get the test passing. maybe @github-christophe-oudar has some ideas?

@dataders I feel like this regression has been possibly been introduced somewhere in core. As previously mentioned in the thread, these two lines, previously inherited from a query header object, but now take their data from the profile object.
So whatever the _labels_from_query_comment function is trying to do is no longer receiving correctly formatted data?
But just a thought...

I ran into that bug few weeks ago and I'm actually thinking about pushing information in the query-comment with a macro and parsing the output instead of labels so far. It's no convenient but it's a workaround.
Regarding actually fixing that issue, from what I saw, if you're using a jinja macro in the query-comment, it won't be evaluated resulting in the weird values ( '{{ bq_labels() }}' becoming query_comment:___bq_labels_____ instead of a list).
I guess there was some code that was doing macro evaluation in the string and then splitting that values... but I don't know where it is (was?). I didn't really looked into it as I'm busy planning "duck" stuff 🦆

Hi,
Based on the previous investigations on this issue and by exploring the code of dbt-core and dbt-bigquery, I might have found a fix with #955 (I basically reverted the 2 lines previously identified and added checks to make sure the value is not null).
@mikealfare Given that I copy-pasted your test highlighting the regression with a minor modification (the labels should be a valid JSON so I removed the trailing comma), I included you in the Changie entry.
Let me know if you think this solution isn't valid.


agebox: 0.7.1 -> 0.7.2

Changes:
https://github.com/slok/agebox/releases/tag/v0.7.2
Includes age fix for CVE-2024-56327

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

nixpkgs-reviewd workflow started
Status and logs: https://github.com/nixosbrasil/nixpkgs-reviewd/actions/runs/12481269272

nixpkgs-reviewd workflow finished
Status and logs: https://github.com/nixosbrasil/nixpkgs-reviewd/actions/runs/12481269272
nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 367884

x86_64-darwin

:white_check_mark: 1 package built:

agebox

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 367884

aarch64-darwin

:white_check_mark: 1 package built:

agebox

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 367884

x86_64-linux

:white_check_mark: 1 package built:

agebox


Style the navigation bar on the forum page

Description:
I would like to style the navigation bar on the forum page to match the navigation bar on the homepage. Kindly assign this issue to me @arncv under hacktoberfest and hacktoberfest-accepted labels.

Assigned!

@arncv can I work on this issue?

@Stormbreakerr20 Assigned!

@arncv I have made the PR, and have updated the nav in forum section which now looks like home screen nav


container-collection: Add OwnerKind and OwnerName to K8sEnrichment

When using the KubernetesEnrichment resolve also the Owner Kind and Owner Name. Partially solves https://github.com/inspektor-gadget/inspektor-gadget/issues/3260
For ig w/ K8s we need to talk to the API server. This is still TODO, needs to be discussed and should be optional (either enrichment failing siliently or actived through flag)
image based gadgets
./kubectl-gadget run trace_exec -n gadget --fields k8s.podname,k8s.owner.kind,k8s.owner.name,comm
K8S.PODNAME                        K8S.OWNER.KIND     K8S.OWNER.NAME     COMM
gadget-mdwnx                       DaemonSet          gadget             gadgettracerman
gadget-mdwnx                       DaemonSet          gadget             gadgettracerman

Built-in gadgets
./kubectl-gadget trace exec -n gadget -o columns=k8s.podname,k8s.owner.kind,k8s.owner.name,comm
K8S.PODNAME                        K8S.OWNER.KIND     K8S.OWNER.NAME     COMM
gadget-mdwnx                       DaemonSet          gadget             gadgettracerman
gadget-mdwnx                       DaemonSet          gadget             gadgettracerman

I think this breaks the CI -> https://github.com/inspektor-gadget/inspektor-gadget/actions/runs/10355549023/job/28663453554


Support analyzing kzip files with multiple compilation units

[X] Support in go_indexer.go
[x] Support in JavaIndexer.java
[x] Support in ClassFileIndexer.java
[ ] Support in C++ frontend.cc

Currently when using index pack files, usage looks like cxx_indexer --index_pack=path/to/file hash [more hashes...]
Do we want also want the ability to select specific CU hashes when working with kzips, or should we always read all CUs when given a kzip file? From what I can tell, the java and go indexers just read all contents of kzips.

I think analyzing all compilations in a .kzip is a good default.

C++ support added in #3232.


fix the docker image name for release image build

Description
fix the docker image name for release image build
Issues
List the issue or RFC link this PR is working on. If there is no such link, please mark it as n/a.
Type of change
List the type of change like below. Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds new functionality)
[ ] Breaking change (fix or feature that would break existing design and interface)
[ ] Others (enhancement, documentation, validation, etc.)

Dependencies
List the newly introduced 3rd party dependency if exists.
Tests
Describe the tests that you ran to verify your changes.

The left issue for DBQnA image build will be fixed in another PR.


Bug: investigate why sometimes TransferMessage.transactionHash is undefined

@ErinHales reported this, could you please add details here and link to code where you have to work around it?


Chrome button on update page does not take you direct to download page

Chrome's landing page is full of adverts for Chrome addons and games. The download link is small and non-obvious for non-geeks.
We should instead detect desktop/mobile and route the user to either
https://www.google.com/chrome/browser/mobile/
or
https://www.google.com/chrome/browser/desktop/

Thank you! That's a good idea. I will set it to the desktop mode because we only notify desktop browsers at the moment.


Ability to create cosmos container with auto RU configured

Is your feature request related to a problem? Please describe.
Atm we can use database.create_container method and create manual RU, it woudl be great if python can support ability to switch to Auto RU when we create it. I know powershell supports it so it is feasible
Describe the solution you'd like
Ability to updtae auto ru container offer
Describe alternatives you've considered
we could go back to using powershell
Additional context
Add any other context or screenshots about the feature request here.

@Rodrigossz Thanks for your feedback! Routing this to the right people.

This is a control plane capability, not present in the SDK by design.
Use the Azure portal, Azure Resource Manager template, CLI or PowerShell to enable autoscale on an existing database or container. You can switch between autoscale and standard (manual) provisioned throughput at any time. See this documentation for more information.


Open workshop page in browser

Can you please add a "Open workshop page in browser" button that opens the mod page in the default browser. I don't keep steam open all the time but I do my browser so when i click the "Open workshop page" it has to start steam which takes some time to start. I also prefer to browse the workshop in my browser. This is the only reason i haven't switched from 0.7.1 even though I like all the new features in 0.8.

I will add a button and recall the previous system (open in browser)

Should be available in Indev release now


x/tools/gopls: change links in hover for replaced modules

Run go version to get version of Go

go version go1.14.4 windows/amd64

Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders

1.45.1 x64

Check your installed extensions to get the version of the VS Code Go extension

0.14.4

Run go env to get the go development environment details

set GO111MODULE=on
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\dtsp\AppData\Local\go-build
set GOENV=C:\Users\dtsp\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\dtsp\YandexDisk\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\GO
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\GO\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=NUL
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map

Share the Go related settings you have added/edited
    "go.testFlags": [
        "*.go": "go"
    "[go]": {},
    "go.formatTool": "goimports",
    "go.useLanguageServer": true,

Describe the bug
When I enable Go Language Server all my local Go modules become unavailable.

All these modules are local to project folder and are available using replace:
replace (
	transflow.ru/pkg/api v0.0.0 => ../api
	transflow.ru/pkg/assign v0.0.0 => ../assign
	transflow.ru/pkg/cache v0.0.0 => ../cache
	transflow.ru/pkg/consts v0.0.0 => ../consts
)

But even struct Server which is defined at the very same package is unavailable as you may see at screenshot.

@DmitriyVTitov: Can you please run gopls -rpc.trace -v check path/to/file.go from your module root and share that output here? It definitely sounds related to the replace directive.
As for the pkg.go.dev links, those don't check for replace directives either, so that's a separate bug.

gopls.exe -rpc.trace -v .\server.go
got error:
flag provided but not defined: -rpc
The Go Language source tools.

Usage: gopls [flags] <command> [command-flags] [command-args]

Make sure you provide the check subcommand, so gopls.exe -rpc.trace -v check .\server.go.

Make sure you provide the check subcommand, so gopls.exe -rpc.trace -v check .\server.go.

PS C:\Users\dtsp\YandexDisk\go\src\transflow.ru\pkg\server> C:\Users\dtsp\YandexDisk\go\bin\gopls.exe -rpc.trace -v check .\server.go
flag provided but not defined: -rpc
The Go Language source tools.

Usage: gopls [flags] <command> [command-flags] [command-args]

This might be a PowerShell issue (https://stackoverflow.com/questions/26614969/how-can-i-pass-batch-arguments-with-dots-into-a-powershell-script). Looks like you may need to do something like gopls.exe --% -rpc.trace -v check path/to/file.go.

You were right:
PS C:\Users\dtsp\YandexDisk\go\src\transflow.ru\pkg\server> C:\Users\dtsp\YandexDisk\go\bin\gopls.exe --% -rpc.trace -v check .\server.go
2020/06/11 21:22:46 Info:2020/06/11 21:22:46 Build info
----------
golang.org/x/tools/gopls 0.4.1
<EMAIL_ADDRESS>h1:0e3BPxGV4B3cd0zdMuccwW72SgmHp92lAjOyxX/ScAw=
<EMAIL_ADDRESS>h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ=
<EMAIL_ADDRESS>h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0=
<EMAIL_ADDRESS>h1:KU7oHjnv3XNWfa5COkzUifxZmxp1TyI7ImMXqFxLwvQ=
<EMAIL_ADDRESS>h1:vcxGaoTs7kV8m5Np9uUNQin4BrLOthgV7252N8V+FwY=
<EMAIL_ADDRESS>h1:e7nYe9s94RHunFJ7b+mmPxiQMOKMVSqYASToWb1EcHs=
<EMAIL_ADDRESS>h1:E7g+9GITq07hpfrRu66IVDexMakfv52eLZ2CXBWiKr4=
<EMAIL_ADDRESS>h1:sXmLre5bzIR6ypkjXCDI3jHPssRhc8KD/Ome589sc3U=
<EMAIL_ADDRESS>h1:KaMb5GLhlcSX+e+qhbRJODnUUBvlw01jt4yrjFIHAuA=

Go info
-------
go version go1.14.4 windows/amd64

2020/06/11 21:22:47 Info:2020/06/11 21:22:47 go env for C:\Users\dtsp\YandexDisk\go\src\transflow.ru\pkg\server
(valid build configuration = true)
(build flags: [-modfile=C:\Users\dtsp\AppData\Local\Temp\go.server.010609871.mod])
set GO111MODULE=on
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\dtsp\AppData\Local\go-build
set GOENV=C:\Users\dtsp\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\dtsp\YandexDisk\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\GO
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\GO\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\Users\dtsp\YandexDisk\go\src\transflow.ru\pkg\server\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\dtsp\AppData\Local\Temp\go-build743783070=/tmp/go-build -gno-record-gcc-switches

2020/06/11 21:22:48 Info:2020/06/11 21:22:48 go/packages.Load
        snapshot=0
        directory=C:\Users\dtsp\YandexDisk\go\src\transflow.ru\pkg\server
        query=[./... builtin]
        packages=4

Glad that worked! Looks like the gopls check command does not report any errors, unlike VS Code. Just to confirm, this is the file in which you see errors in VS Code?

Glad that worked! Looks like the gopls check command does not report any errors, unlike VS Code. Just to confirm, this is the file in which you see errors in VS Code?

I don't see ERRORS no more, but 'Go to definition' do not work. When I deleted root go.mod all red underscores disappeared.
Still language server is not usable without Ctrl+Click.
I mean in screenshot above I cannot Ctrl+Click even Reciever type in the function definition despite this type (Server) is in the same package (module) as server.go.

Deleting the go.mod is not a good solution, as that will put you back into GOPATH mode. If you can follow these steps to capture verbose logs, I can help you continue debugging: https://github.com/golang/tools/blob/master/gopls/doc/troubleshooting.md#capturing-logs.

Deleting the go.mod is not a good solution, as that will put you back into GOPATH mode. If you can follow these steps to capture verbose logs, I can help you continue troubleshooting: https://github.com/golang/tools/blob/master/gopls/doc/troubleshooting.md#capturing-logs.

Sorry Rebecca, but I don't have time to switch extension on and off for now. I will continue to work without language server.
Thanks for your help!

Not a problem. I'll leave this issue open as a reminder to add regression tests that use replace directives.

@stamblerre the gopls check output has
go env for C:\Users\dtsp\YandexDisk\go\src\transflow.ru\pkg\server
(valid build configuration = true)

while the gopls server output has
go env for C:\Users\dtsp\YandexDisk\go\src\transflow.ru
(valid build configuration = true)

Doesn't it mean the workspace roots used in two cases are different?

Yes, it does seem like that's the case.

There hasn't been much activity on this issue, and we have a few CLs planned to improve the workflow with replaced modules. The one thing left to address is the hover links showing up for the original module.

Also I'ts strange that VSCode offers me to open link to, for example,

https://pkg.go.dev/transflow.ru/pkg/yandex

despite it's local package specified with replace directive in go.mod

After some discussion, we've concluded that the hover links may still be useful, even if the module has been replaced. We can change the links to point to the replaced module, if possible, however.

I experienced same issue and i want to solve this.
Can i handle it?


Minor improvements at the crap helper class (no pun intended)

Description

Converting to boolean the return of the method validateAlias, avoiding the ternary condition.
Using array_map function to parse the arguments, that way we get rid of the foreach and the $require.

Motivation and context
Since the parseArguments method is mutating an array of arguments, I believe that the array_map function is the perfect solution for this case.
Thanks for making such a cool library :D

Coverage remained the same at 100.0% when pulling 1b044b092e3f9b81b49716b7ea1cef9ed0053bd7 on flyingluscas:improvement/refactoring-crap-helper into a3f3cb1d7c539e42218e6370d8b9ae2cbe874947 on geekish:master.

Coverage remained the same at 100.0% when pulling 1b044b092e3f9b81b49716b7ea1cef9ed0053bd7 on flyingluscas:improvement/refactoring-crap-helper into a3f3cb1d7c539e42218e6370d8b9ae2cbe874947 on geekish:master.

Thanks!


Clarify which signal is discarded in Signal.merge example

One thing I've noticed in Elm documentation generally is that the documentation sometimes (as in this case) refers to the names of variables, but when the documentation is presented on the web site, the names of variables don't actually show up. Now, sometimes you can tell from the types, but in this case the types are the same. And, in this case I suppose you could deduce what "left" and "right" mean, but sometimes it is more difficult than that.
So, this PR solves the general problem by being more explicit in the documentation -- that is, being explicit about which parameter is "left" and "right".
It might make sense to change the way the package web-site is generated, to solve the problem more generally, by showing the variable names in documentation. However, I guess that functions don't always
name their variables (if written in point-free form). So, it might be tricky -- perhaps being more explicit in the documentation is the best practical solution.

I would agree with that - the people coming from Haskell backgrounds are usually fine guessing how something works from the type signature, but for those from JS/web dev backgrounds, having the names there is important.

Can you provide an example of the general issue of using invisible parameter names in the documentation? In the specific example here, I cannot see the issue. The use of "left" and "right" in the documentation here is not a reference to the parameter names left/right, but to the natural language concepts "left"/"right". So I don't think the extra sentence is necessary.
If the extra sentence is to be added, then the "Mouse.position" should be put into backticks, so that it will show up properly type-set on the package documentation page.

The issue here came up yesterday on IRC - someone didn't understand which argument was to be considered right. When talking about function arguments, normal language used to refer is instead "nth argument" rather than left or right. Signal.merge could take the 1st param as being right, and the 2nd param as right - in the current documentation, it's ambiguous. In terms of Signals, left and right makes sense, if you have seen the relevant visualizations or read the research. By making it explicitly clear which argument is referred to here, people learning Elm can understand how to use Signal.merge without needing the complete background.

Interesting. I would never have thought that in either of merge x y or x `merge` y there could be any doubt which is left and which is right. The text as written should make clear which of x and y is considered the left one? Just as for foldl and foldr it is clear what the "left" and what the "right" end are of a list [1,2,3]? (In particular, I don't need to assume someone having specific signal visualizations in mind, or read the research, to make it seem clear that x is the left and y is the right parameter in both expressions as written above.)
Anyway, you do mention evidence that someone was confused. I'll leave it to Evan to decide whether to merge this for the documentation.
Still, I'm actually more intriguied by @rgrempel's comment that generally some documentation snippets work only based on the assumption that the reader knows how the function parameters are called in the source code. And still, I don't see the current instance as an example for this. Here, the understanding the documentation assumed as given was not "you should know what I mean by left and right, because it's how I called the function parameters", but instead "you should know what I mean by left and right, because we are talking about function application expressions, and these are layed out as text, and there you can see which is the left and which the right operand".

The text as written should make clear which of x and y is considered the left one?

I personally didn't have any issues understanding it, but when they mentioned being confused by it, I can certainly see where they're coming from - but that's just because usually I would refer to arguments as nth argument. In this case, I would think that using nth argument would have the potential to be equally confusing, especially if you start talking about the 1st signal or the 2nd signal being dropped - it would imply an order to something unordered (signals coming in at the same time).
With an infix example, left and right certainly are a lot more obvious - I guess the difference here is that because the arguments are on different lines, it may lead to a different interpretation. The reader may left feeling like they are expected to know which is left and right in the implementation, as the chap on IRC did yesterday. But I don't know if there's a right answer here or not, really.
As to @rgrempel's point, the one that popped up in my head as a good example is the documentation for Graphics.Collage.collage, which a student complained to me about.

A collage is a collection of 2D forms. There are no strict positioning relationships between forms, so you are free to do all kinds of 2D graphics.

They were used to defining things as height, width, and thus were confused when their collage didn't come out as expected - simply naming the arguments in the documentation would've prevented their confusion. Perhaps adding width, height to the docs would've made it more clear

Create a collage with a given width and height, from a collection of 2D forms. There are no strict positioning relationships between forms, so you are free to do all kinds of 2D graphics.

The same applies to move, switching

Move a form by the given amount. This is a relative translation so (move (10,10) form) would move form ten pixels up and ten pixels to the right.

with

Move a form by the given amount (x, y). This is a relative translation so (move (5,10) form) would move form five pixels to the right and ten pixels up.

made it obvious to my student that for some reason their coordinate system was backwards compared to everyone else.

Yes, I see. The case of move is particularly nasty, since the current wording with "up" being mentioned first could leave one to assume that the first pair component is about up and down.
I guess the best to be done here is to fix the individual cases where something potentially confusing like this appears in the docs.
@evancz, do I have free reign to merge this and similar doc improvements?

Ah, for the specific case, reading the new sentence in context: Adding that sentence might create semantic confusion here. Because it makes it sound as if it could actually happen that Mouse.position and Time.fps fire at the same time. Whereas we are telling people (on the mailing list, though probably not explicitly anywhere in the docs) that signals fed by different sources (like here: mouse and timer) will never fire at the same time.
So maybe a less invasive fix is possible here that does not give this impression? Maybe something like just saying in the brackets "(...; above that [the dropped stuff] would be the event from the fps-derived signal)".

As for this particular example, I don't think "the left update wins" is actually all that clear. My first thought when I originally read it (being new to Elm) was "Hmm, I wonder what makes an update 'left' or 'right' -- perhaps there is something about Elm signals that makes them have handed-ness". Of course, that seems silly to me now -- but, especially for newbies without Haskell background, Elm is exotic enough (in a nice way) that you don't necessarily immediately dismiss the idea that things might have properties that you haven't heard of before.
Now, if it had said "the update provided by the left parameter wins", then I suppose I would have figured that ought pretty fast. Although, as @eeue56 points out, the usual idiom elsewhere is to refer to the first parameter or second parameter -- perhaps referring to left and right parameters is a Haskell idiom (I don't know). If there would three parameters, would the second parameter be the 'middle' parameter?
In any event, when I saw the parameter names, I thought "Aha -- now I see clearly what's going on."
And, I know that when I'm writing documentation for my own packages, I struggle a little bit to know exactly how to refer to parameters. In jsdoc or javadoc, I'm used to referring to the parameters by name. But, in Elm documentation, it's essentially a bad idea to do that, because the documentation doesn't show the names. So, there is a mis-match -- it potentially seems perfectly clear to the documentation writer, because the documentation writer can see the names. But the reader will not. So, the documentation writer has a kind of false confidence that the documentation will make sense -- it might make sense in a given case, but that's just fortunate.
Anyway, when I have a spare hour, I'll scan through core and see if I can come up with other examples.

For the case of move I already submitted a PR and that was merged, but I haven't noted any of the examples I've come across yet - I'll talk with the student who had issues understanding and see which ones apart from collage they got confused by, and make a new issue for them.

signals fed by different sources (like here: mouse and timer) will never fire at the same time.

If that is the case, that two Signals from different sources will never collide, then the docs here need to be changed - my understanding from the source code for genericMerge was that always was used to select the winning signal, and therefore left always wins since always : a -> b -> a. But now reading it again with your comment in mind, it is clear that can't happen due to the parent id checks.

maybe a less invasive fix is possible here that does not give this impression?

I think with the above in mind, it might be good to have somewhere else in the docs to refer to the algorithms used for Signal merge/map/foldp. The current docs on Signals could probably do with updating, to make it clearer how the Signals libraries work. It's been a while since I've read the Evan's papers, so I don't know which bits exactly are explained in the papers - but I don't remember merges being explained.

If an update comes from either of the incoming signals, it updates the outgoing signal. If an update comes on both signals at the same time, the left update wins (i.e., the right update is discarded).

So perhaps something along the lines of

If an update comes from either of the incoming signals, it updates the outgoing signal. If the two merged input signals are from the same source at the same time, then the left signal wins and the right signal is discarded.

How's that? I still feel it might be good to have an example of when it would be discarded and wouldn't be discarded, though that may be more suited to documentation on elm-lang rather than for core-documentation.

The thing is: While it is (currently) true that two signals originating from different "event sources" will never fire at the same time, I have the impression Evan doesn't want to have this promise made or implied in the documentation. (Different implementation strategies could be used for the Elm runtime, and then the statement may stop being true. That's why I said in a comment above that we do tell people this on the mailing list but it's not written in the docs.)

Ah, I see. In that case I'm not sure on the best wording here. Any thoughts? My gut instinct would be to document it as it works currently, with a note that it may be subject to change later in the future.

I don't really understand why expressing "from the same source at the same time" is important for understanding what this function does. Why isn't "at the same time" enough? It is currently true that two events from different sources cannot occur at the same time, so adding "from the same source" is not wrong, but redundant right now. If the runtime changes at some point then it might be the case that events from different sources can occur at the same time, but when that happens, I expect that merge's behavior will be such that "from the same source at the same time" will become incorrect, and only "at the same time" will be correct.

I must admit that I initially found the whole concept of throwing away an event because it arrived "at the same time" as another event to be a little puzzling, in the "why would you want to do that" sense. After all, the Elm architecture encourages you to merge multiple event sources -- why would I want, at some random (and rare) moment, to drop one of the events? I mean, I understand that it would be extremely rare, given the granularity of "same time", but still -- why would you want that? There's nothing about "same time" that inherently makes me want to drop an event.
However, when I saw it said that events from different sources can never occur at the same time, then I understood that there could be a use case for dropping an event. Imagine a signal graph with various maps & merges forming a bit of a diamond -- so that in some cases an event from one source might trigger an event further down the signal graph on multiple merged input nodes. (Whereas in other cases those nodes fire separately, triggered by other sources). In that case, the two events arriving at the same time actually have the same genesis -- that is, they arise from the same original event (if you think of 'original event' as the event which originally enters the signal graph).
Now, in that case, I can imagine that you might want to be able to drop one of the events. But that is because in some sense they are the 'same' event (or, to be more precise, entered the signal graph as the same event). And it seems to me the only way that 'same time' makes any sense is as a proxy for 'entered the signal graph as the same event'.

@rgrempel, there are valuable considerations in your comment. It does seem to me this is not anymore about "just" clarifying the documentation of merge, so I'm not sure how to move forward from here.
Maybe what you say is an argument for rethinking the approach of not committing, in the documentation, to specific semantics of "same" vs. "different" event sources. Maybe also relevant would be considerations to make the genericMerge function from the JavaScript runtime (which underlies the Elm merge, but is more powerful than it) available to users of core? But these are general API considerations that seem to really transcend the documentation issue at hand.

Now, in that case, I can imagine that you might want to be able to drop one of the events. But that is because in some sense they are the 'same' event

This is the reason I feel that the documentation (here)[http://elm-lang.org/guide/reactivity#Signals] should be expanded a little. The only discussion on merge/foldp/map/filter there is through the graph and just listing the API. It should be the other way around, the documentation on elm-lang should cover the way Elm's Signals work, and core should briefly define the API and example usage and refer back to elm-lang for further information.

make the genericMerge function from the JavaScript runtime available to users of core

This would probably help to some extend, especially if it shows Signal.merge's implementation as an example (just genericMerge always left right), but I don't think it fully answers the issue of sources - it would still have the issue of what language to use when talking about conflict resolution.

these are general API considerations that seem to really transcend the documentation issue at hand.
Perhaps we should make a new issue for further discussion along those lines, and for now close this PR for now

I have made two pull requests about documentation of collage and merge (#405 and #406), picking up suggestions from the discussion above.
As suggested in the last comment by @eeue56, I'll close this issue here.
Discussion of the more general concerns from @rgrempel's comment above could be continued in a fresh issue.


Version Interleaving – Mapping controller action to all future API versions of controller

I just have a question about what approach to take when doing minor version changes of actions in a controller
For my versioning strategy, I create a minor version for any non-breaking change made to the API.
Take the example below.  I wanted to add an optional parameter to the GetUserStatus method, I created an API version 1.2 and then mapped the new method to that API version using MapToApiVersion.
[ApiVersion("1.2")]
[ApiVersion("1.1")]
[ApiVersion("1.0")]
[RoutePrefix("api/Users")]
public class TestController : BaseApiController
{
    [Route("{username}/Status"), HttpGet]
    public IHttpActionResult GetUserStatus(string username)
    {
        //get user status from Db
        return Ok(Models.UserStatus.Active);
    }

    [Route("{username}/Status"), HttpGet]
    [MapToApiVersion("1.2")]
    public IHttpActionResult GetUserStatusV1_2(string username, bool includeArchivedUsers=false)
    {
        //get user status from Db
        return Ok(Models.UserStatus.Active);
    }
}

This will only include this action in api version 1.2.  What approach do I take to include this action in all api versions starting from api version 1.2.
i.e.  is it possible to now have api version 1.3 and 1.4 of the controller without having to add MapToApiVersion(“1.3”) and MapToApiVersion(“1.4”) to the new action?
[ApiVersion("1.4")]
[ApiVersion("1.3")]
[ApiVersion("1.2")]
[ApiVersion("1.1")]
[ApiVersion("1.0")]
[RoutePrefix("api/Users")]
public class TestController : BaseApiController
{
    [Route("{username}/Status"), HttpGet]
    public IHttpActionResult GetUserStatus(string username)
    {
        //get user status from Db
        return Ok(Models.UserStatus.Active);
    }

    [Route("{username}/Status"), HttpGet]
    [MapToApiVersion("1.2")]
    public IHttpActionResult GetUserStatusV1_2(string username, bool includeArchivedUsers=false)
    {
        //get user status from Db
        return Ok(Models.UserStatus.Active);
    }
}

Thanks

Amazingly clear :)
I mistakenly thought mixing attributes and conventions are bad also for versioning, thanks a lot for clarifying that!
I didn't find much reference to IHttpControllerTypes though... can you please refer to its documentation?
To allow the transition to ASP.NET Core in the future, might it be better to use reflection anyway?
Thanks a lot!

In Web API, it would look like this:
HttpConfiguration configuration;
var services = configuration.Services;
var assembliesResolver = services.GetAssembliesResolver();
var typeResolver = services.GetHttpControllerTypeResolver();
var controllerTypes = typeResolver.GetControllerTypes( assembliesResolver );

There isn't an complimentary service in Core that I'm aware of. Core doesn't care much about controllers; it's primarily actions. I'm sure there is some service that can get you the assemblies to consider. After that, filtering with the Reflection API should be straight forward.

Thank you!
Another related question: is there a way to check attribute-based versions of a controller before applying convention-based versioning? I would like to use conventions to add versions to many controllers at once, UNLESS the controller has explicit ApiVersion attribute(s). Is that possible at all?
Thank you.

That isn't a scenario supported out-of-the-box. The default behavior unions the convention and attribute defined API versions into a distinct set as evident in ControllerApiVersionConventionBuilderBase.cs.
I don't know of anyone that has tried this - yet, but the design is meant to be extensible to support such a scenario. In a short review while digging out the links, it appears some of the things you would need to override may not be available. This is something I'm willing to fix/enhance if it's a path you want to pursue.
From your description, when your custom conventions would be applied, you would simply skip the processing if the metadata has been applied by attributes.
I think the types of complex rule processing that these scenarios want to use do not make sense to be first-class concepts in-box, but I definitely want to make sure the extension and customization points are there so you can enable or change them if you want to.
Ultimately, using custom conventions is something that you can definitely enable. There may be a few things that are not as easy change or are unchangeable when they should be. Let me know if you find any road-blockers and we can spin up a new issue to track that. In terms of wiring it up, you would just set it in the options like so:
configuration.AddApiVersioning( options =>
{
    var conventions = new MyCustomConventionBuilder();

    // TODO: apply your conventions

    options.Conventions = conventions;

    // TODO: any remaining options
}

Thanks for the quick response (again).
It looks like I would have to rewrite/duplicate the whole builder, since the existing ControllerApiVersionConventionBuilder implements the abstract methods of ControllerApiVersionConventionBuilderBase but the ApplyTo is not replaceable as it's implemented in the base class (correct me if I'm wrong).
At the moment it seems like a big overhead, and I'll probably create some mapping of the 'exceptional' controllers and perform this logic in the conventions buildup, without using attributes. It's less preferable as I wanted the developers of the services to only deal with the controllers they create, and have a central management of the conventions that apply to the 'regular' controllers (those that didn't have a breaking change, which should support all versions).
However, if you want me to help by creating an issue and help you enable this scenario, I'd be happy to.
Thanks!

@cuanp2007, it seems you are unblocked. Please come back or reopen the issue if you're not.
@nirzamir, I've opened #258 to track the enhancements required to make the convention builder fully extensible (as was originally intended). Feel free to post additional comments or needs on that issue.
Thanks


Added required prop type to DatePicker

@miksansegundo It looks like you are missing the pipe you initially reported in #1472.

@michaelmyers I think it's already fixed so this PR finishes fixing both issues. Thanks for noticing and for the fix @miksansegundo


The Release version has no mute prop,maybe need update

Maybe have a look at my version, inspired by Tesla. https://github.com/avidofood/vue-responsive-video-background-player


Lovelace example, please

Hello!
Can you give me an example of card code with a maximum of options, please.

When the component is installed, it ships with a (not working because lacking of entity_id) example. It is:
type: custom:slider-button-card
entity: '<put here your entity_id>'
slider:
  percentage: true
  direction: left-right
  background: gradient
  use_state_color: false
  use_percentage_bg_opacity: false
  show_track: false
  force_square: false
show_name: true
show_state: true
icon:
  show: true
  use_state_color: true
  rotate: false
  tap_action:
    action: more-info
action_button:
  mode: toggle
  icon: mdi:power
  show: true
  show_spinner: true
  tap_action:
    action: toggle

When the component is installed, it ships with a (not working because lacking of entity_id) example. It is:

Thank you!
I can't change icon to another one. This construction don't work:
          - type: custom:slider-button-card
            entity: light.light_room_lamp
            icon: mdi:floor-light
            use_state_color: true
            name: Лампа

And this too:
              icon:
                show: true
                use_state_color: true
                rotate: false
                tap_action:
                  action: more-info
              action_button:
                mode: toggle
                icon: floor-light
                show: true
                show_spinner: true
                tap_action:
                  action: toggle

You need to pay attention to indentation, as well as expected values.
Your first example is not supplying an object as expected, you're supplying a string.
Your second example is supplying the toggle object properly, but the icon string is missing "mdi:"
Use the UI card tool to get a feeling for what the values should be, or read through the docs, and you'll have a much better time with this.

Thank you!
Looks like I don't understand expected values :(

Your second example is supplying the toggle object properly, but the icon string is missing "mdi:"

Oops. So, I use it with mdi and also nothing new.
Copy paste from example:
            - type: custom:slider-button-card
              entity: light.light_hall_l1
              name: Коридор
              icon:
                show: true
                use_state_color: true
                rotate: false
                tap_action:
                  action: more-info
              action_button:
                mode: toggle
                icon: mdi:power
                show: true
                show_spinner: true
                tap_action:
                  action: toggle

give me this with default icon

Mode should be custom in that example, sorry was on mobile and missed it. Toggle overrides pretty much everything else for the action button.

Mode should be custom in that example, sorry was on mobile and missed it. Toggle overrides pretty much everything else for the action button.

Yes, it work!
              action_button:
                mode: custom
                icon: mdi:power

Anyway, looks like there is a lot of code for only icon change. What code will be enough for slider with default options and only new icon?

Experiments give me this:
          - type: custom:slider-button-card
            entity: light.light_room_lamp
            name: Лампа
            icon:
              show: true
              use_state_color: true
              icon: mdi:floor-lamp-dual
            action_button:
              mode: custom
              icon: mdi:power
              show_spinner: true
              tap_action:
                action: toggle

@mattieha  these examples really should be in the readme

@johntdyer I've added yaml examples to the readme, please let me know if you're missing a certain example.


Extended Scanning

Hi,
perhaps this is a good idea...
I extended the scanning engine that also "POTENTIALLY_VULNERABLE" files will be identified.
If "log4j-core/pom.properties" is NOT available in a JAR the scanner will check existence of "org/apache/logging/log4j/core/lookup/JndiLookup.class" -> then it is POTENTIALLY_VULNERABLE. It meight be useful if somebody repacked the JAR an does not include the pom.xml file.
Last but not least a simple classpath is also scanned; it will look for existence of the mentioned files in the directory (not packed in a JAR).
Have a look and feel free to change. Perhaps it is usefull

Thank you for suggestion. I will review it later.


Use Tokenizer in Generator

Your P.R. to upstream is well qualified. Highly appreciate it.
I did some modifications to the Generator code with your Tokenizer changes. It leads towards the direction I wrote to you earlier in the email. It's still WIP, and I will make additional progress by catching up your tokenization changes.
I would like to add my changes to your branch, so that both of our changes can show up in the P.R.
And don't worry too much about the linter warnings for now.

Ouch... sorry! but we have a few conflicts with this PR... could you take a look?

Don't worry about it. I am closing this one in favor of yanagiba/swift-transform#9 and yanagiba/swift-transform#12. I will try to take a look at them tomorrow.


Read initial state from server

I want to pass preloaded state from server
createStore(window.__PRELOADED_STATE__, [], [sagaMiddleware])

(https://redux.js.org/recipes/serverrendering#client-js)
Problem is initial state passed to createStore overwrites by initial state from each dynamically loaded reducer. How can I apply preloaded state to them?

@Stoope  We don't overwrite any state intentionally, I will try it out and see if I can get a repro.

@navneet-g Have made playground https://codesandbox.io/s/k917m5ppjv. If you remove defaultModule from createStore app works as expected.

Awesome ... thanks for doing it @Stoope  ... I will take a look tonight or over the weekend.

@Stoope  I took a look, this is happening as the keys in initialState are ignored by combinedReducer, as the defaultModule does not contain any reducers for those keys. If the defaultModule can contain the
Notice line 163 onwards in following file in redux code.
https://github.com/reduxjs/redux/blob/3f93d6bb21fd104263bc83da87bd2e113e82bd9f/src/combineReducers.js
I have modified the playground to illustrate it
https://codesandbox.io/s/xj49x173kz
Please let me know if you have any question.

@navneet-g Thanks, I see... This is a problem since I don't know about other reducers at initial stage, they will be added later with react-loadable. Best solution is to read window.__PRELOADED_STATE__.somereducer state in each module's reducer, right?

Yes ... That is an alternative, I don't know though, when does the library overwrites the state in window object.

Closing as hopefully the above answered the question, please reopen if you still need help with this.


gnupg21: 2.1.17 -> 2.1.18

See http://lists.gnu.org/archive/html/info-gnu/2017-01/msg00013.html
for release announcement.
Motivation for this change
Things done

[X] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] Linux

[X] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[X] Fits CONTRIBUTING.md.

nox-review fails for some derivations, but they also fail on master.


Added a triggers api for auto routines

Removed old choreo command api

This will have to wait for a stabilization of the frontend/app on how it emits event markers in the trajectory json

This will remain unmerged until we (hopefully) release a final 2024 version of Choreo before the UI rewrite, since this is such a breaking change.

That makes complete sense, i still have to test it on a robot irl. I have made a python script to change old .traj files to the new format so devs can beta test stuff until ui catches up.
The changes to the traj spec include the name of the trajectory in the json and an alternate event type thats simpler than pp event triggers.

The robot project files add a lot of bloat I'd like to avoid. The WPILib VS Code plugin supports vendordeps adding custom examples, so we should look into that.

I removed the example project for now as it should either be in its own repo or inside the vendor dep, my offseason code can be used as a preliminary example of the trigger features


feat: support 360speedX and sogou

Proposed changes
feat: support 360speedX browser(password\cookie\bookmark\session storage)
fix: Update the configuration file path of Sogou browser(password\cookie\bookmark\history\local storage\session storage)
Checklist

[x] Pull request is created against the dev branch
[x] All checks passed (lint, unit, build tests etc.) with my changes
[x] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (if appropriate)

LGTM！


Setting HNSW ef_search variable

No matter what I do, ef_search defaults to 40, so I'm always limited to 40 results. Can't seem to find a way to pass that variable in this wrapper, works fine in sql directly with
SET hnsw.ef_search = N;
Any way to do it now? (I'm using django)

Hi @creepykedi, you can use:
with connection.cursor() as cursor:
    cursor.execute('SET hnsw.ef_search = 100')

https://docs.djangoproject.com/en/4.2/topics/db/sql/#executing-custom-sql-directly


shoal-agent crashes when dns entry for a shoal server is unavailable

During the most recent openstack upgrade at CERN the DNS entry for shoal.heprc.uvic.ca was unavailable for some period. We need to catch this error and just wait for the the DNS to be available.
Traceback (most recent call last):
  File "/usr/bin/shoal-agent", line 142, in <module>
    main()
  File "/usr/bin/shoal-agent", line 134, in main
    amqp_send(json.dumps(data))
  File "/usr/bin/shoal-agent", line 37, in amqp_send
    connection = pika.BlockingConnection(pika.URLParameters(HOST))
  File "/usr/lib/python2.6/site-packages/pika/adapters/blocking_connection.py", line 107, in __init__
    super(BlockingConnection, self).__init__(parameters, None, False)
  File "/usr/lib/python2.6/site-packages/pika/adapters/base_connection.py", line 62, in __init__
    on_close_callback)
  File "/usr/lib/python2.6/site-packages/pika/connection.py", line 590, in __init__
    self.connect()
  File "/usr/lib/python2.6/site-packages/pika/adapters/blocking_connection.py", line 206, in connect
    if not self._adapter_connect():
  File "/usr/lib/python2.6/site-packages/pika/adapters/blocking_connection.py", line 274, in _adapter_connect
    if not super(BlockingConnection, self)._adapter_connect():
  File "/usr/lib/python2.6/site-packages/pika/adapters/base_connection.py", line 105, in _adapter_connect
    0, 0, socket.getprotobyname("tcp"))
socket.gaierror: [Errno -2] Name or service not known
``

@consold can you comment on this. You can replicate by  editing /etc/resolv.conf .

I spent some time trying to reproduce this by adding and editing entries in the local /etc/resolv.conf.
I found that i couldn't reproduce the error by adding a bad entry for the production shoal server, I could however get an error if i pointed the lookup server to a bad place:
Traceback (most recent call last):   File "/usr/bin/shoal-agent", line 199, in <module>     main()   File "/usr/bin/shoal-agent", line 150, in main     data['hostname'] = socket.gethostbyaddr(public_ip.values()[0])[0] socket.herror: [Errno 2] Host name lookup failure
However, I don't think this is really what the original error was about as the lookup server shouldn't be going down. Any more information about how to reproduce this error would be helpful.

Issue appears fixed. Reopen if anyone is able to reproduce this in the future.


[ISSUE-10] Implemented propagation of pg sphere version.

Implemented propagation of pg sphere version from Makefile into the code. Fixed pg_sphere_version function.

It seems there are build problems on 11+ versions. The error is occured when compiling with clang. It seems PG_CFLAGS is not utilised with clang. Not sure, how clang compilation is performed. I see no clang rules. It is interesting that there is no clang compilation with 10 version. Investigating it.

The problem with clang was because of JIT compilation (--with-llwm option). Variables PG_CXXFLAGS, PG_CFLAGS are not propagated into clang compilation. Using PG_CPPFLAGS fixes the problem.

@esabol thank you for the review. I'm going to merge this PR because there are no objections.