[Doc Improvement][SEO1 meta title update for same H1][3948816]

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

Article
Score
Issues
Scorecard
Processed

msteams-platform/apps-in-teams-meetings/in-meeting-notification-for-meeting.md
92
7
link
:white_check_mark:

msteams-platform/bots/how-to/authentication/add-authentication.md
90
58
link
:white_check_mark:

msteams-platform/bots/how-to/conversations/bot-copilot-handoff.md
90
8
link
:white_check_mark:

msteams-platform/bots/how-to/format-your-bot-messages.md
95
2
link
:white_check_mark:

msteams-platform/messaging-extensions/build-api-based-message-extension.md
92
53
link
:white_check_mark:

msteams-platform/tabs/how-to/access-teams-context.md
94
17
link
:white_check_mark:

msteams-platform/tabs/how-to/developer-tools.md
87
6
link
:white_check_mark:

msteams-platform/task-modules-and-cards/cards/dynamic-search.md
93
5
link
:white_check_mark:

msteams-platform/toolkit/Teams-Toolkit-CLI.md
90
71
link
:white_check_mark:

msteams-platform/toolkit/add-API-connection.md
91
5
link
:white_check_mark:

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

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

Article
Score
Issues
Scorecard
Processed

msteams-platform/apps-in-teams-meetings/in-meeting-notification-for-meeting.md
92
7
link
:white_check_mark:

msteams-platform/bots/how-to/authentication/add-authentication.md
90
58
link
:white_check_mark:

msteams-platform/bots/how-to/conversations/bot-copilot-handoff.md
90
8
link
:white_check_mark:

msteams-platform/bots/how-to/format-your-bot-messages.md
95
2
link
:white_check_mark:

msteams-platform/messaging-extensions/build-api-based-message-extension.md
92
53
link
:white_check_mark:

msteams-platform/tabs/how-to/access-teams-context.md
94
17
link
:white_check_mark:

msteams-platform/tabs/how-to/developer-tools.md
87
6
link
:white_check_mark:

msteams-platform/task-modules-and-cards/cards/dynamic-search.md
93
5
link
:white_check_mark:

msteams-platform/toolkit/Teams-Toolkit-CLI.md
90
71
link
:white_check_mark:

msteams-platform/toolkit/add-API-connection.md
91
5
link
:white_check_mark:

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

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

Article
Score
Issues
Scorecard
Processed

msteams-platform/apps-in-teams-meetings/in-meeting-notification-for-meeting.md
92
7
link
:white_check_mark:

msteams-platform/bots/how-to/authentication/add-authentication.md
90
58
link
:white_check_mark:

msteams-platform/bots/how-to/conversations/bot-copilot-handoff.md
90
8
link
:white_check_mark:

msteams-platform/bots/how-to/format-your-bot-messages.md
95
2
link
:white_check_mark:

msteams-platform/messaging-extensions/build-api-based-message-extension.md
92
53
link
:white_check_mark:

msteams-platform/tabs/how-to/access-teams-context.md
94
17
link
:white_check_mark:

msteams-platform/tabs/how-to/developer-tools.md
87
6
link
:white_check_mark:

msteams-platform/task-modules-and-cards/cards/dynamic-search.md
93
5
link
:white_check_mark:

msteams-platform/toolkit/Teams-Toolkit-CLI.md
90
71
link
:white_check_mark:

msteams-platform/toolkit/add-API-connection.md
91
5
link
:white_check_mark:

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

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

Article
Score
Issues
Scorecard
Processed

msteams-platform/apps-in-teams-meetings/in-meeting-notification-for-meeting.md
92
7
link
:white_check_mark:

msteams-platform/bots/how-to/authentication/add-authentication.md
90
58
link
:white_check_mark:

msteams-platform/bots/how-to/conversations/bot-copilot-handoff.md
90
8
link
:white_check_mark:

msteams-platform/bots/how-to/format-your-bot-messages.md
95
2
link
:white_check_mark:

msteams-platform/messaging-extensions/build-api-based-message-extension.md
92
53
link
:white_check_mark:

msteams-platform/tabs/how-to/access-teams-context.md
94
17
link
:white_check_mark:

msteams-platform/tabs/how-to/developer-tools.md
87
6
link
:white_check_mark:

msteams-platform/task-modules-and-cards/cards/dynamic-search.md
93
5
link
:white_check_mark:

msteams-platform/toolkit/Teams-Toolkit-CLI.md
90
71
link
:white_check_mark:

msteams-platform/toolkit/add-API-connection.md
91
5
link
:white_check_mark:

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

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

Article
Score
Issues
Scorecard
Processed

msteams-platform/apps-in-teams-meetings/in-meeting-notification-for-meeting.md
92
7
link
:white_check_mark:

msteams-platform/bots/how-to/authentication/add-authentication.md
90
58
link
:white_check_mark:

msteams-platform/bots/how-to/conversations/bot-copilot-handoff.md
90
8
link
:white_check_mark:

msteams-platform/bots/how-to/format-your-bot-messages.md
95
2
link
:white_check_mark:

msteams-platform/messaging-extensions/build-api-based-message-extension.md
92
53
link
:white_check_mark:

msteams-platform/tabs/how-to/access-teams-context.md
94
17
link
:white_check_mark:

msteams-platform/tabs/how-to/developer-tools.md
87
6
link
:white_check_mark:

msteams-platform/task-modules-and-cards/cards/dynamic-search.md
93
5
link
:white_check_mark:

msteams-platform/toolkit/Teams-Toolkit-CLI.md
90
71
link
:white_check_mark:

msteams-platform/toolkit/add-API-connection.md
91
5
link
:white_check_mark:

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


Update rubocop

Summary
Updates RuboCop and related gems. RuboCop is updated to the latest version that supports Ruby 2.3, which turns out to be 0.81.
Details
See above. ~Apart from the above, autocorrects a performance offense.~
Motivation and Context
Keeps stuff up-to-date.
How Has This Been Tested?
I ran RuboCop. CI will have to check if the changes work on all supported Ruby versions.
Types of changes

[x] Bug fix (non-breaking change which fixes an issue).
[ ] New feature (non-breaking change which adds functionality).
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected).

Checklist:

[ ] I've added tests for my code.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.

Travis CI matrix includes Ruby 2.3, still, which does not support the wanted version of rubocop-rspec. Example job which failed
    rubocop-rspec (~> 1.39.0) was resolved to 1.39.0, which depends on

      ruby (>= 2.4.0)

That brings up the question "what is our support schedule for EOL'd Ruby versions?"

IMO dropping 2.3 on the next release is a non-issue

I'll amend this pull request to work with Ruby 2.3.
Regarding dropping Ruby 2.3, it may make sense to first do a release with Cucumber 4 support and drop Ruby 2.3 right after that. @luke-hill are you up for cutting a new release?

Sure makes sense. I'll just need to look into getting the stuff set up my end. But we can stick stuff in for now and worry about cutting it soon after.

Again, thanks for your attention to detail in this!

Thanks @luke-hill. I just merged this as it has now become a really tiny change. Dropping 2.3 &c is handled in #466.


Use Object.freeze to create enums

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/freeze

No longer relevant.


Issue 5 message thread

Fix #5 issue, I changed the FacetMessagethread class. The class doesn't generate a complex structure as illustrated in the message example:
https://github.com/casework/CASE-Examples/blob/master/examples/illustrations/message/message.json).
The class takes into consideration the list of participants (array of Account ObservableObject), the list of messages (array of Message ObservableObjects) and the visibility.
BTW, the example on the repo should be slightly updated replacing the properties:
"uco-observable:displayName": "Best Friend Chat!!" --> uco-core:name outside of the uco-core:hasFacet array and
"drafting:visibility": "PRIVATE" --> boolean value False.

I'm addressing the merge conflict now.


run ha addon as amd64?

if i wanted to run the addon as amd64 - would i just swap the entry in the Dockerfile? also unsure in the dockerfile where the file 'ha_ss-linux-arm64' its referencing is from. thanks!

I've just pushed a amd64 version of the Dockerfile, although I can't test it.  So I suspect you could :
make bin/ha_ss-linux-amd64
cd ha_ss_addon
ssh root@homeassistant mkdir -p /addons/ha_ss_addon
scp Dockerfile* *.yaml run.sh root@homeassistant:/addons/ha_ss_addon
scp ../bin/ha_ss-linux-amd64 root@homeassistant:/addons/ha_ss_addon

Also updated the readme a little.
and, yes, I know this isn't great.  But its what I have right now.

thx - tried real quick and get some errors (i did have to change the files you committed a bit to ensure it was all amd64 fyi).  i did not build direct on HAOS as i dont know how to do that - but i did on a ubuntu machine. maybe thats the source of my issues. i get this error:
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
/ha_ss-linux-amd64: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /ha_ss-linux-amd64)
/ha_ss-linux-amd64: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /ha_ss-linux-amd64)
s6-rc: info: service legacy-services: stopping
s6-rc: info: service legacy-services successfully stopped
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped

i may look into how to compile for haos specifically - but need to travel home first! :)
thanks!

I've re-built mine (arm64) and it still works okay.
I did spot this post - https://kupczynski.info/posts/glibc-not-found/, I'm wondering if you have built with a different go version (I have 1.23.3).

If it helps, I've shared a local build here https://github.com/plord12/webscrapers/releases/tag/v0.0.0-alpha

well i must have done something dumb when compiling myself. this is working great. just wrestling with css selectors but it is working great! thanks.

Great !  I did add a little more docs on CSS selector.
I'll close this issue.


Twitter error response: status code = 403 when fetching favorites

I've been using tweepy for a while but I didn't care much about how the twitter APIs have changed. And recently I found out that my app has been suspended for "violating twitter rules" (I'm using a script that sometimes fetch all of my favorite tweets using tweepy.Cursor(api.favorites, id=User, tweet_mode="extended").items(4000) ).
So I made a new app and tried to make thing work again but I keep getting Twitter error response: status code = 403 exception.
I'm using free plan and apparently according to this link:
https://developer.twitter.com/en/docs/twitter-api/getting-started/about-twitter-api#item0
I'm understanding that we cannot pull tweets when using free plan anymore. Am I understanding it correctly or am I missing something?

Yes, retrieving Tweets is not available with Free access.
https://twittercommunity.com/t/announcing-new-access-tiers-for-the-twitter-api/188728
https://twittercommunity.com/t/deprecation-of-legacy-access-tiers-in-the-twitter-api/196162
https://developer.twitter.com/en


Refactored Display implementation for Platform enum

WHOAMI
Key Changes:

Display Restructuring:

Significantly restructured the Display implementation for the Platform type.
Introduced a dedicated file, disp.rs, to centralize and streamline platform-specific display functions.

Aesthetic Enhancements:

Revamped the platform display, focusing on enhancing the overall aesthetic.
Resulting in a more visually appealing output for improved user experience.

To enhance the utility's adaptability, a crucial implementation has been added. The program checks whether it is running in a terminal environment (using https://crates.io/crates/is-terminal) before deciding how to display the platform. If executed in a terminal, the graphical version is presented; otherwise, in scenarios like running in a pipe, the text version is displayed.

Please make sure you have here only your files changed. It sees that you changed the line endings.

Looks good, please send this to upstream and place a link to it here. Please explain the idea with the terminal in the pull request description.

https://github.com/ardaku/whoami/pull/83


Support multiple dbt project roots in a single repo

We have a multi-project structure within a single dbt repo. Is it possible to set up multiple project root directories in a single .dbt-checkpoint.yml file?

@ammarchalifah-bolt Do you mean a single .pre-commit-config.yaml file?

Hello,
I also have the exact same use case : I have a centralized "dbt" folder, each of them containing a store, e.g :

dbt/store_a/target/manifest.json
dbt/store_b/target/manifest.json
etc

It would be ideal to be able to either have a configuration supporting multiple folders or to at least give a glob-like path to find the manifest.json, from a single .pre-commit-config.yaml. It could probably be added in the .dbt-checkpoint.yaml,
something like this :
Solution 1
version: 1
dbt-project-dirs:
   store_a:
      - dbt/store_a/target
   store_b:
      - dbt/store_b/target

or
Solution 2
dbt-projects-glob: dbt/*/target
I know that this sound quite exotic, yet I believe that this dbt architecture could be more and more used as more people are advocating for multi-repo dbts (examples :

https://discourse.getdbt.com/t/how-to-configure-your-dbt-repository-one-or-many/2121
https://docs.getdbt.com/best-practices/how-we-mesh/mesh-2-structures )

Now I guess that the change could be quite tricky, yet it would help tremendously when an engineer modifies multiple identical marts for distinct companies to ensure that the commits are ok.

We are having exactly the same issue as you. We are currently trying to figure a strategy for this since we don't want to be repeating the same configuration for multiple subprojects

Also facing this, not sure how to resolve it, we have one dbt repo with a folder for each project
e.g.
dbt-repo/team_a/dbt_project.yml
dbt-repo/team_b/dbt_project.yml
We want to be able to run dbt-checkpoint for changes in both projects, and ideally allow each project to define its own list of hooks for their project


net-cygwin: megacon crashes when blkinhand and posixth are enabled

Original issue: https://charm.cs.illinois.edu/redmine/issues/1288

I cut the enabled tests down to just blkinhand and posixth in megacon.c, and got the following failure:
../../../bin/testrun  ./pgm +p1  ++local
Charmrun> scalable start enabled.
Charmrun> started all node programs in 0.047 seconds.
Converse/Charm++ Commit ID: v6.7.0-432-g43122f2
[0] isomalloc.c> Disabling isomalloc because isomalloc disabled by conv-mach
Charm++> scheduler running in netpoll mode.
test 0: initiated [blkinhand]
test 0: completed (0.00 sec)
test 1: initiated [posixth]
test 1: completed (0.00 sec)
test 2: initiated [multi blkinhand]
Charmrun> error on request socket to node 0 '<IP_ADDRESS>'--
Error on socket recv!
Makefile:91: recipe for target 'test' failed
make: *** [test] Error 1

If I reverse their order, the test passes on 1 PE, and then fails on 2. If I disable either of those two, the test passes.

Original date: 2017-03-03 17:38:18

net-cygwin is deprecated


@import errors

Why can't we just leave the import as it is!?
just copy it to the output file without any changes or processing!?
Many remote styles are connected as @import url ("//sdfdsf/sdfdsfsd/fsdfds")
two slashes at the beginning mean using the main page schema, why does this cause an error for you!?
Thank you for your work, but the quality of the product is very poor(

Hey @ivanff - please have a look at this test case: https://github.com/jakubpawlowicz/clean-css/blob/master/test/integration-test.js#L2146 - you can easily turn off @import inlining via inline: 'none' option as described in https://github.com/jakubpawlowicz/clean-css#inlining-options
Also protocol-less @imports are left intact, only raising a warning, see: https://github.com/jakubpawlowicz/clean-css/blob/master/test/protocol-imports-test.js#L918
Please reopen this issue if needed or suggest an constructive improvement.

Hey @ivanff - please have a look at this test case: https://github.com/jakubpawlowicz/clean-css/blob/master/test/integration-test.js#L2146 - you can easily turn off @import inlining via inline: 'none' option as described in https://github.com/jakubpawlowicz/clean-css#inlining-options
Also protocol-less @imports are left intact, only raising a warning, see: https://github.com/jakubpawlowicz/clean-css/blob/master/test/protocol-imports-test.js#L918
Please reopen this issue if needed or suggest an constructive improvement.


can't visit HeadedDemo from a remote machine through web browser

I follow the wiki, and all work well.
Then I launch HeadedDemo on machine A, and I can get response from HeadedDemo UI.
But when I try to visit HeadedDemo from machine B with Chrome, I can't get any response.
I have checked:

Machine A and B are in same LAN;
Firewall of machine A is off.

Hi liudanking,
Are you running the HeadedDemo app from windows 10 on a pc from within visual studio? If so, you might run into http.sys uac permissioning issues.
Can you try running the HeadedDemo in visual studio in administrator mode and trying again? If that works then you might have to use netsh to add a port reservation for the app.
Let me know how you get on and if you have any questions, I'll try and add a wiki page about this sometime this week as well.
Cheers,
Jark

@Jark
In the manifest I checked "Private Networks (Client & Server)", and it works now.

Hi @liudanking,
Glad it's now working for you.
The HeadedDemo should however work out of the box as **"Private Networks (Client  & Server)" is specified in the application manifest -> https://github.com/tomkuijsten/restup/blob/master/src/HeadedDemo/Package.appxmanifest#L27.
Did you happen to copy the HeadedDemo files into a new project?

@Jark I did not copy that file to new project.
I think  and  have different capability. I just find that if I want to visit HeadedDemo from another machine, I must add .

Looks like this issue can be closed, correct?

Yes :)

Just reading it again and didn't initially see the difference between Internet (Client & Server) and Private Networks (Client & Server). The latter is not enabled in the demo projects and according to this issue it should be, am I correct?

Yes

Yup, this is why I didn't close it yet, I thought I would have time last night to do the change.
I was going to to add that capability to the demo projects just to make sure it works on Windows 10 systems when tried over a local network.
See: https://msdn.microsoft.com/en-us/library/windows/apps/br211423.aspx
The description at privateNetworkClientServer says: "On Windows Phone, provides the same access as internetClient or internetClientServer." Which is why it's probably not necessary for Windows 10 IOT.
@tomkuijsten do you want to make the change? If not I can do it.


reading in slice of raster is unexpectedly slow

I'm working with future worldclim data for bioclimatic variables, which is chunked along the X axis, and also has a Y and Band axis.
Reading in a single slice along the Band axis takes almost as long as reading in the entire thing, even though I'd expect it to take 1/19th the time.
Reproduce:
using Rasters, RasterDataSources, Dates, ArchGDAL
path = getraster(WorldClim{Future{BioClim, CMIP6, GFDL_ESM4, SSP370}}; res = "2.5m", date = Date(2090))
bior = Raster(path; lazy = true)
@time read(view(bior, :, 1, :));
@time read(view(bior, :, :, 1));
@time read(bior);

Gives
  0.004638 seconds (290 allocations: 652.578 KiB)
 11.733330 seconds (291 allocations: 142.394 MiB)
 14.055928 seconds (416 allocations: 2.642 GiB, 1.03% gc time)

May be a DiskArrays or ArchGDAL issue?

This would be easier to diagnose if you wrap the data in ras within an AccessCountDiskArray...will investigate.

On my machine I get these timings:

julia> @time read(view(bior, :, 1, :));
  0.002350 seconds (290 allocations: 652.578 KiB)

julia> @time read(view(bior, :, :, 1));

  4.612768 seconds (411 allocations: 142.396 MiB, 1.41% gc time)

julia> @time read(bior);
  6.438516 seconds (294 allocations: 2.642 GiB, 0.05% gc time)

Curiously, open doesn't help:
julia> open(bior) do bior
       @time read(view(bior, :, 1, :));
       @time read(view(bior, :, :, 1));
       @time read(bior);
       end
  0.001171 seconds (101 allocations: 646.484 KiB)
  4.587579 seconds (101 allocations: 142.388 MiB)
  6.128943 seconds (110 allocations: 2.642 GiB, 0.22% gc time)
╭────────────────────────────────╮

but if I modify it to be an AccessCountDiskArray, I get GDAL failures
using DiskArrays.TestTypes: AccessCountDiskArray

bior = modify(bior) do A
AccessCountDiskArray(A; chunksize = (8640, 1, 1))
end

julia> @time read(bior)
ERROR: GDALError (CE_Failure, code 10):
	Pointer 'hDS' is NULL in 'GDALGetRasterBand'.

Stacktrace:
  [1] maybe_throw()
    @ GDAL ~/.julia/packages/GDAL/hNyuz/src/error.jl:42
  [2] aftercare
    @ ~/.julia/packages/GDAL/hNyuz/src/error.jl:59 [inlined]
  [3] gdalgetrasterband
    @ ~/.julia/packages/GDAL/hNyuz/src/libgdal.jl:7270 [inlined]

and if I rebuild it I get a memory failure (?!)

julia> bior_r = rebuild(bior; data = AccessCountDiskArray(bior.data; chunksize = (8640, 1, 1)))
╭────────────────────────────────╮
│ 8640×4320×19 Raster{Float32,3} │
├────────────────────────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── dims ┐
  ↓ X    Projected{Float64} LinRange{Float64}(-180.0,<PHONE_NUMBER>3333326, 8640) ForwardOrdered Regular Intervals{Start},
  → Y    Projected{Float64} LinRange{Float64}(89.95833333333333, -89.99999999999997, 4320) ReverseOrdered Regular Intervals{Start},
  ↗ Band Categorical{String} [wc2.1_2.5m_bioc_GFDL-ESM4_ssp370_2081-2100_1, wc2.1_2.5m_bioc_GFDL-ESM4_ssp370_2081-2100_2, …, wc2.1_2.5m_bioc_GFDL-ESM4_ssp370_2081-2100_18, wc2.1_2.5m_bioc_GFDL-ESM4_ssp370_2081-2100_19] Unordered
├─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── metadata ┤
  Metadata{Rasters.GDALsource} of Dict{String, Any} with 4 entries:
  "units"    => ""
  "offset"   => 0.0
  "filepath" => "/Users/anshul/downloads/WorldClim/Future/BioClim/ssp370/GFDL-ESM4/wc2.1_2.5m_bioc_GFDL-ESM4_ssp370_2081-2100.tif"
  "scale"    => 1.0
├───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── raster ┤
  extent: Extent(X = (-180.0,<PHONE_NUMBER>9999991), Y = (-89.99999999999997, 90.0), Band = (nothing, nothing))
  missingval: NaN32
  crs: GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AXIS["Latitude",NORTH],AXIS["Longitude",EAST],AUTHORITY["EPSG","4326"]]
  filename:
└─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

julia> @time read(bior_r)
ERROR: MethodError: no method matching GenericMemory(::Int64, ::Ptr{Nothing})
The type `GenericMemory` exists, but no method is defined for this combination of argument types when trying to construct it.

    @ Rasters ~/.julia/dev/Rasters/src/array.jl:169
 [17] open(f::Rasters.var"#28#29"{UnionAll}, A::Raster{Float32, 3, Tuple{…}, Tuple{}, AccessCountDiskArray{…}, Symbol, DimensionalData.Dimensions.Lookups.Metadata{…}, Float32}; kw::@Kwargs{})
    @ Rasters ~/.julia/dev/Rasters/src/array.jl:162
 [18] open(f::Function, A::Raster{Float32, 3, Tuple{…}, Tuple{}, AccessCountDiskArray{…}, Symbol, DimensionalData.Dimensions.Lookups.Metadata{…}, Float32})
    @ Rasters ~/.julia/dev/Rasters/src/array.jl:155
 [19] modify(f::Type{Array}, A::Raster{Float32, 3, Tuple{…}, Tuple{}, AccessCountDiskArray{…}, Symbol, DimensionalData.Dimensions.Lookups.Metadata{…}, Float32})
    @ Rasters ~/.julia/dev/Rasters/src/array.jl:98
 [20] #read#223
    @ ~/.julia/dev/Rasters/src/read.jl:16 [inlined]
 [21] read(x::Raster{Float32, 3, Tuple{X{…}, Y{…}, Band{…}}, Tuple{}, AccessCountDiskArray{Float32, 3, Rasters.FileArray{…}, DiskArrays.ChunkRead{…}}, Symbol, DimensionalData.Dimensions.Lookups.Metadata{Rasters.GDALsource, Dict{…}}, Float32})
    @ Rasters ~/.julia/dev/Rasters/src/read.jl:12
 [22] macro expansion
    @ ./timing.jl:581 [inlined]
 [23] top-level scope
    @ ./REPL[26]:1
Some type information was truncated. Use `show(err)` to see complete types.

I think you have the chunksize inverted?

Hm I'm not sure what is going on here - I haven't really done much I/O.
But I noticed that the first time you read in any band from an ArchGDAL dataset, it is much slower than all other reads from the same dataset, even different bands.
using ArchGDAL, Rasters, RasterDataSources, Dates
path = getraster(WorldClim{Future{BioClim, CMIP6, GFDL_ESM4, SSP370}}; res = "2.5m", date = Date(2090))
dataset = ArchGDAL.read(path)
@time band = ArchGDAL.getband(dataset, 1) |> Array
@time band = ArchGDAL.getband(dataset, 1) |> Array
@time band2 = ArchGDAL.getband(dataset, 2) |> Array

 11.663348 seconds (69.17 k allocations: 286.877 MiB, 2.46% gc time)
  0.232574 seconds (69.17 k allocations: 286.877 MiB, 38.37% gc time)
  0.270758 seconds (69.17 k allocations: 286.877 MiB, 12.53% gc time)

The first timing is similar to reading a single band from a lazy Raster, but all subsequent reads are still equally slow.
ras = Raster(path; lazy = true)
@time read(view(ras, Band = 1))
@time read(view(ras, Band = 2))

 11.957042 seconds (86.80 k allocations: 288.140 MiB, 1.73% gc time)
 12.023004 seconds (86.73 k allocations: 288.139 MiB, 1.68% gc time)

Seems curious the number of allocations is the exact same but the timing is so different? Profiling doesn't help because it's all just C calls.

Yeah, you may want to try doing the in an open(rast) do R block

Riiight that fixes it

Guess I need to communicate that much better, and maybe as @asinghvi17 wants allow opening without a do block.

Haha I was waiting for this one :)
Open the Raster before making the stack!
It's opening each one separately. We should be smart and union the filenames, open them once, then map them back to stack layers.

Why is nearly all of the cost just opening the file if it's chunked

Doesn't make any sense. What is GDAL doing for those 12 seconds?
At the end the point of this would be to be able to do
stack = RasterStack(WorldClim{Future{BioClim, CMIP6, GFDL_ESM4, SSP370}}; res = "2.5m", date = Date(2090), lazy = true)
stack_cropped = stack[1:10, 1:10];

without this crazy overhead, and without users ever knowing that this thing came from a single .tif file with bands, and not from 19 separate .tifs.

Maybe... We should allow mid-level laziness open on load using lazy=:open.

Is that necessary here? There should be a way to call open before maplayers somehow?

The problem is actually knowing that each stack layer is from the same file. There is a bunch of code that chains the opening of multiple stack files, but here it probably just opens the same file over and over because its not that smart.
The stack will already hold views of FileArray objects, we just need to put the same actual ArchGDAL.RasterDataset inside all of them and it will work fine with one load.


Implement CI builds/pipeline

I think I got one set up for build/test on PRs and the main branch. Seems to be working.
I think we can use https://github.com/qzb/standard-version-action to do the standard version thing for us automatically based on our commit log.

I think the only thing remaining here is worrying about the docs site, which I think is a separate issue so closing this


Failed to load a language-chialisp package grammar

I am at a loss at how to resolve the below error:
I have tried installing the chialisp language package in both the manual and automated fashions on different devices and operating systems but have received an error each time. Is the below referenced module "tree-sitter-chialisp" contained within the .zip or is this compiled at time of installation? Is it possible to manually load this module?

download .zip from Github
extract and copy contents to ~/.atom/packages directory
ran apm i from project directory
open project in Atom
error appears upon opening Atom:

"Cannot find module 'tree-sitter-chialisp'
Require stack:

C:\Users\donot.atom\packages\language-chialisp-master\grammars\chialisp.cson in C:\Users\donot.atom\packages\language-chialisp-master\grammars\chialisp.cson"

Atom: 1.58.0 x64
Electron: 9.4.4
OS: Microsoft Windows 10 Pro
Thrown From: language-chialisp package 1.0.4
Stack Trace
Failed to load a language-chialisp package grammar
At Cannot find module 'tree-sitter-chialisp'
Require stack:
- C:\Users\donot\.atom\packages\language-chialisp-master\grammars\chialisp.cson in C:\Users\donot\.atom\packages\language-chialisp-master\grammars\chialisp.cson

Error: Cannot find module 'tree-sitter-chialisp'
Require stack:
- C:\Users\donot\.atom\packages\language-chialisp-master\grammars\chialisp.cson
    at Module._resolveFilename (internal/modules/cjs/loader.js:797:17)
    at o._resolveFilename (electron/js2c/renderer_init.js:43:689)
    at Function.get_Module._resolveFilename (<embedded>:11:157920)
    at new TreeSitterGrammar (<embedded>:11:3432197)
    at GrammarRegistry.createGrammar (<embedded>:11:362991)
    at <embedded>:11:362832
    at u (<embedded>:11:584283)
    at <embedded>:11:585520
    at FSReqCallback.oncomplete (fs.js:158:21)

  at /packages/language-chialisp-master/grammars/chialisp.cson:1:1

Commands

Non-Core Packages
language-chialisp 1.0.4

Closed to non-response


Named Operations handled by AddOperations

We need to implement AddOperationsToChain with NamedOperations to ensure the OperationChain within a NamedOperation is also updated.

This is related to #1063.

The changes have been completed, but it depends on pull request https://github.com/gchq/Gaffer/pull/1092 to be merged in first.

Migration Steps
Named operations are now part of core Gaffer and as long as you have configured a cache service for Gaffer named operations will be available.
This means you should remove the following from your store properties file:
gaffer.store.operation.declarations=NamedOperationDeclarations.json

Remove this dependency:
<dependency>
    <groupId>uk.gov.gchq.gaffer</groupId>
    <artifactId>named-operation-library</artifactId>
    <version>${gaffer.version}</version>
</dependency>

Named operations are now resolved via a GraphHook. If you do not manually add the NamedOperationResolver graph hook then it will be automatically added as the first graph hook. So you want to run other graph hooks before the named operations are resolved (such as OperationChainLimiter) then you must manually add the NamedOperationResolver as a graph hook in the required position.

Merged into develop-1.0.0.


DNS01 Validation Failing: No OpenIDConnect provider found in your account

Hi. :wave:
We have two AWS accounts with EKS 1.19 clusters: 1 running in regular AWS (call it staging) and the other running in govcloud. Because govcloud doesn't allow for public DNS zones we are using cross-account role assumption to have the cert-manager in govcloud assume a role in staging to complete DNS01 validation for cert requests. The validation fails with this error message
cert-manager/controller/challenges/finalizer "msg"="error cleaning up challenge" "error"="error instantiating route53 challenge solver: unable to assume role: WebIdentityErr: failed to retrieve credentials\ncaused by: InvalidIdentityToken: No OpenIDConnect provider found in your account for https://oidc.eks.us-gov-east-1.amazonaws.com/id/xxxxxxxxxx\n\tstatus code: 400, request id: xxxxxxxxxxxxxxxxxxxxxxx" "dnsName"="test-gov.managed.kubernetes.stage.company.net" "resource_kind"="Challenge" "resource_name"="test-cert-vjwc2-1386816997-2277483838" "resource_namespace"="cert-manager" "resource_version"="v1" "type"="DNS-01"

We're using the v1.2.0 cert-manager chart, and have added the annotation eks.amazonaws.com/role-arn: arn:aws:iam::1234567:role/cert-manager to the ServiceAccount used by the pod. The account used in this arn maps to the staging account. The cert-manager role in the staging account has the necessary AWS permissions for Route 53. It also has two trust relationships configured: one for arn:aws:iam::1234567:oidc-provider/oidc.eks.us-east-2.amazonaws.com/id/xxxxxxxxxxxxxx and another for arn:aws:iam::1234567:oidc-provider/oidc.eks.us-gov-east-1.amazonaws.com/id/xxxxxxxxxxxxxx. Each trust relationship has a condition attached looking for a key/value of the OIDC endpoint and system:serviceaccount:cert-manager:cert-manager .
The letsencrypt clusterissuer's solver section looked like this
dns:
            - type: route53
              hostedZoneID: Z0xxxxxxxxxxxxxxx
              region: us-east-1

(I say looked because we changed it to reference an AWS key and K8s secret to work around the failures).
We can't figure out why cert-manager is reporting that it can't find the OIDC provider in the govcloud account. external-dns, which is using the same mechanisms (the only differences being the service account names and IAM permissions), is successfully registering K8s services fromgovcloud into staging Route 53 so we feel like we must be overlooking something in our cert-manager setup.
We'd apreciate any insights or suggestions on how to debug this or what we could be missing. Happy to share more detailed configs if needed.
Thank you!

@transient1 I have had a similar issue using AWS SSM plugin for Ansible in Govcloud. It was resolved by adding the AWS_DEFAULT_REGION=us-gov-west-1 env variable to the docker container


Updates

This PR updates the devDependencies to their latest versions, including babel@7, and the new eslint-config-okonet. This simplifies the eslint configuration a bit.
It also removes yarn and opts into using only npm. On the CI npm ci is used. I read through https://github.com/okonet/lint-staged/issues/449 and it seems the reason for yarn was npm having issues in CI. This should be fixed with recent versions.
There's also an improvement for setting the SIGINT handler only on the bin. This improves testing, since calling runAll won't create a new listener every time.

I personally prefer yarn but if you think migrating to npm helps, I’m fine with it :)

That's debatable. I also think yarn is a bit better in regards to installation speed, but then again having both is pretty weird too. 🤷♂

What do you mean by having both? We only had yarn.lock before afaik

All the package.json scripts currently use npm run ..., because (what I assume from https://github.com/okonet/lint-staged/issues/449) not everyone uses yarn. Then again, I don't know why one would want to develop/test lint-staged without yarn.
In any case, I'd prefer either one or the other, and since npm is still default, I'd choose that just to avoid one extra dependency. Using yarn is fine too, but then it should probably be explicit via something like:
"preinstall": "echo \"$npm_execpath\" | grep -q \"yarn\.js$\" || (echo 'lint-staged uses yarn instead of npm' && exit 1)"

I can also drop this change from the PR, so the others can get merged.

I removed the npm part from this PR, since the other stuff would be nice to merge regardless.

It seems commitizen has removed support for node v8 in version 4.0.0; I’ll need to downgrade that.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[BUG] MSIX cannot install per-user service

Project
MSIX SDK
Describe the bug
With the advent of Windows 10, Microsoft introduced per-user Windows Services. These services are started when a user logs in, run with the user's permissions, and are automatically shut down when the user signs off.
These new user services also alleviate some of the security restrictions put in place for Windows Services with newer releases of Windows (since they are effectively background user processes).
To Reproduce
Create an MSIX project (using the MSIX Packaging Tool, using manifest schema, or otherwise).
Under StartAccount (from the manifest's desktop6:Service XML entry), there is no option for per-user services.  The only options are "localSystem", "localService", and "networkService"--all of which are system service options.
See: https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-desktop6-service
Expected behavior
I expected to be able to specify "userService", possibly also requiring a share/own process option (since the SERVICE_USER_SERVICE (0x40) flag is OR'd with similar flags in a traditional Windows Installer context).
Screenshots
n/a
Platform
Windows 10 and Windows 11
Additional context
To follow best security practices and to enable services to seamlessly use the current user's security context, some services should be run as per-user services rather than under system accounts.  Many of Windows 11's services can do this.
We can do this with MSI.  But it would be really great if we could move forward and use the latest packaging technology and all of the benefits it provides--both in Enterprise environments and also for consumers (with simple right-click app removal, etc.).
Some notes from Microsoft on per-user services:
https://learn.microsoft.com/en-us/windows/application-management/per-user-services-in-windows
A useful post with some background info on installing per-user services:
https://helgeklein.com/blog/per-user-services-in-windows-info-and-configuration/

I dug a little bit more on that topic.
If we update the proper registry keys of the service, then we can see it will be installed as a per-user service. But unfortunately, when it tries to reach the executable under "C:\Program Files\WindowsApps", it is not authorized to do so and crashes.
Is there be anyway to make some progress on this topic?

NOTE: This isn't a bug, it's an enhancement request. MSIX today supports per-machine Services and doesn't support per-user Services.

I dug a little bit more on that topic. If we update the proper registry keys of the service, then we can see it will be installed as a per-user service. But unfortunately, when it tries to reach the executable under "C:\Program Files\WindowsApps", it is not authorized to do so and crashes.

Interesting but insufficient. Even if the pkgdir's ACLs were updated you'd still run afoul of the Deployment stack's notion of how to service a Service. That only understands per-machine semantics; that won't work per-user.

Is there be anyway to make some progress on this topic?

Please create an Issue for the enhancement request to support per-user Services. That gets it onto our radar for planning consideration.
This almost certainly requires changes to Windows, though WinAppSDK may also be part of the solution. Similar to how the windows.dataShortcut extension was implemented in WinAppSDK 1.1.

@DrusTheAxe a couple of questions if you have the time.

Is there an explanation anywhere of the WindowsApps ACLs in depth, what exactly they do and why? You reference updating them here as if that's a normal thing to do but it seems that changing the ACLs is a common source of people breaking their own machines in unexpected ways.

The reason I ask is, we help people make MSIX packages for their apps, and sometimes they hit unexpected problems whereby attempting to run an EXE inside a WindowsApp directory fails with permissions errors, either from outside the package or sometimes inside it, and it's not at all obvious why or what the purpose of this permissions check actually is. I can imagine that listing the contents of c:\Program Files\WindowsApps is denied for privacy reasons (to stop apps finding out what other apps you have installed?) and the reason why you can't write to your app dir is obvious, but it seems to go beyond that and operations you'd expect to work fine can nonetheless fail. When this happens it's unclear if there's a problem or if it's expected/desired that this part of the filesystem behaves differently (more awkwardly) than normal.

You mention MSIX being patched via the "WinAppSDK". The page you link to implies that MSIX is now being upgraded outside of Windows Update cycles. Is there more information about this? If you're shipping a Win32 app inside an MSIX, how does one get these updates onto users systems and are there any catches (e.g. win10 not being supported)?


Deprecate BuildListener.buildStarted

Expected Behavior
org.gradle.BuildListener.buildStarted(Gradle gradle) should be triggered when a listener is implemented and also this should happen before other listeners such as ProjectEvaluationListener
Current Behavior
buildStarted is not triggered at all.
Context
This is started to happen in  5.0-20181024213332+0000
It affects because we depend on buildStarted to initialize some custom build metrics that we have in https://github.com/nebula-plugins/gradle-metrics-plugin. We applied a workaround but we don't feel confident that it will be enough and also wondering if other methods are triggered in the proper order.
Steps to Reproduce (for bugs)
https://github.com/nebula-plugins/gradle-nebula-integration/tree/master/build-started-listener-issue
Given this listener https://github.com/nebula-plugins/gradle-nebula-integration/blob/master/build-started-listener-issue/src/main/groovy/nebula/plugin/test/MyBuildListener.groovy and adding it to the project via https://github.com/nebula-plugins/gradle-nebula-integration/blob/master/build-started-listener-issue/src/main/groovy/nebula/plugin/test/MyPlugin.groovy
I should expect this test to pass: https://github.com/nebula-plugins/gradle-nebula-integration/blob/master/build-started-listener-issue/src/test/groovy/nebula/plugin/test/MyPluginSpec.groovy#L8
However, buildStarted is never triggered and the build will fail.
As a note, project.gradle.addListener(myListener) or project.gradle.addBuildListener(myListener) have the same behavior

The buildStarted method is left over from a very old API from the Gradle 0.x days that was used to embed Gradle and that is no longer used.
It doesn't make sense to call this method from a listener registered within a build, as the build has already started. We should remove this method instead. If there's some code that feels like it should belong in a buildStarted method, it would be better to put this code somewhere else and call it just before you register the listener.

Thanks for the clarification @adammurdoch. It would be nice if this could be marked as deprecated and put a not that is not even triggered anymore.. it seems like a breaking change without nottice

Since Gradle now requires Java 8 minimum, it'd have been better to make the methods in BuildListener default, because an implementation is forced to override them anyway, and the error message shows up in the build logs continuously.
I think the error message should suggest that BuildAdapter is used instead.


[Reconciliation] Wait for reconciliation queue to drain

Changes

[ ] Update version
[x] Add ReconciliationDrainDisabled to configure the rosetta-cli to exit before draining the backlog
[ ] If ReconciliationDrainDisabled is false, wait for reconciliation queue to exit before draining.

Pull Request Test Coverage Report for Build 5581

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

Totals

Change from base Build 5570:
0.0%

Covered Lines:
186

Relevant Lines:
223

💛  - Coveralls


Release v0.2

I'm maintaining out-of-tree riscv-compliance target code for two RISC-V implementations (SERV and SweRV). I had some bug reports coming in recently that made me realize that the current master had an API change (in the guise of a commit called Add Parallel make for supported targets) since v0.1
It would be great to have a v0.2 release so that I can point my users to that for a known good vetsion instead of a random git commit
P.S. I'm seeing hints of something called riscof framework. Is this something I should be aware of?

So I think what the issue is: since the addition of the parallel make api, there have also been upgrades to the test. So if you are using an older version, its quite possible that some bugs aren't being detected.
That said, I think @eroom1966 @simon5656 can suggest how to proceed on this
RISCOF is the next version of compliance  - possibly v0.2.
Details of riscof: https://gitlab.com/incoresemi/riscof
Details of riscv-config:  https://github.com/riscv/riscv-config
PS: If you are sure its the paralle make, then the fix is in the arguments of your target Makefile.include files. Refer to PR: https://github.com/riscv/riscv-compliance/pull/101/files#diff-0be0f8dee7d8097a0906e624fefe1ec0 for possible hints on changes required.

Thanks for the links. Will read up on the new framework and look into adding support for my targets
I would say this is all the more reason to do a new release, if the current framework is in maintenance mode. Just slap on a tag, write a couple of lines in a release note and use the release to communicate to others that nothing more will happen with this code base and that people should turn their eyes towards the riscof framework in the future.
And yes, I'm sure it was the parallel make that broke my target files. I already fixed it for one target. But I must also take the opportunity to say that I'm not impressed by how these changes were communicated. The name of the commit didn't indicate ant API changes and it seems only ovpsim target was fixed which broke the other targets

Hi Olof
Thanks for the feedback - I am sorry you had a problem with the way changes were communicated regarding the move to parallel and the fact that riscvOVPsim target was fixed.
Can you suggest how we could improve this process as clearly we don't have a good process - each company that has their own target has to be the one to move their target forward to match the evolution of the compliance framework - as many targets are not public and are specific to one company? The group does not require each target to made public and available for regression testing with CI. We tested 3 targets and went forward with the commit.
You are incorrect in your assumption that the current framework is in maintenance mode - it is evolving with the needs of the compliance challenge (e.g. going to parallel as their over 5,000 tests in the under development vector suite that we are developing) and it will evolve further.
The working group has a specification document regarding future direction of the framework, and there is still much discussion and no decisions as what it will be and what any plans and roadmap are for developing a new framework - and yes the riscof python code is an example that is talked about.
So, Olof - please suggest how we could have handled the parallel addition so that it did not rely on each simulator/target maintainer updating their specific target scripts.
Simon (Imperas)

From: Olof Kindgren<EMAIL_ADDRESS>Sent: 09 May 2020 06:18
To: riscv/riscv-compliance<EMAIL_ADDRESS>Cc: Simon Davidmann<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [riscv/riscv-compliance] Release v0.2 (#109)
Thanks for the links. Will read up on the new framework and look into adding support for my targets
I would say this is all the more reason to do a new release, if the current framework is in maintenance mode. Just slap on a tag, write a couple of lines in a release note and use the release to communicate to others that nothing more will happen with this code base and that people should turn their eyes towards the riscof framework in the future.
And yes, I'm sure it was the parallel make that broke my target files. I already fixed it for one target. But I must also take the opportunity to say that I'm not impressed by how these changes were communicated. The name of the commit didn't indicate ant API changes and it seems only ovpsim target was fixed which broke the other targets
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/riscv/riscv-compliance/issues/109#issuecomment-626113932, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA3V7ZG2JL6O5VBJ4JCLEYTRQTYTZANCNFSM4M4QAJOA.

Hi Simon,
First of all, thanks everyone for all the work you put into the compliance tests. I'm a heavy user of them and have many times cursed how thorough they are when I make changes to my CPU that really shouldn't break anything :)
I think the particular issue with the parallel make API could had been solved in a backwards-compatible way by defining $work_dir_isa on targets that hadn't yet opted in to use the parallel make. But I might very well be wrong, and it's really beside the point. Stuff needs to break sometimes. I also hadn't updated my local copy of the repo in over a year. And I totally understand it's a hard issue since it's not feasible, or even possible to test all the targets in this repository by someone making changes. And it's of course even harder with targets that reside outside of this repo. I very much appreciate the possibility to have the target code externally, so that's something I would like to keep see support for (not least because I wrote the patch to enable that :))
So let's focus on the process. I got three proposals that might improve the situation.

I think it's easier to communicate API breaks between versions, than between random git commits. So doing more frequent releases would help my target files, since I can say it works with riscv-compliance e.g. v0.4 up to v1.2.

I think it would be great also to have an opt-in mailing list or other forum where target maintainers can be notified of breaking changes and be given a chance to comment. This is a bit similar to how changes that affect multiple CPU architectures work in the Linux kernel

Make sure to communicate backwards-incompatible changes in the commit message and/or ChangeLog. Sometimes things break by mistake, and that's fine. But if they are known, they should be written down

I'm still a bit confused about the relation between riscv-compliance the the riscof framework. I noticed it mainly because there were a lot of bugs that were marked with Fixed in RISCOF which led to my conclusion that it was a new framework replacing the other one. But this issue report has already wandered far from its original purpose so I'll bring up those questions in another forum instead.  And feel free to close the issue if you're not planning on making a new release, which was the original issue I had

I'll comment on the last question about riscof.
When I was made chair of compliance, there had been a decision made that
tests were going to move from a static signature type of test to a
comparison against a formal model. I wasn't there when the decision was
made, but it was pretty clear to me that, once we started aggressively
testing privileged modes, we needed a framework that could describe the
actual implementation and select (or configure) tests that applied to those
modes.  Another goal (of mine) was to make tests easier to write or
generate. The 1.2.5 test format spec was the outcome of that,
Many of the open issues marked "fixed in riscof" are tests that simply
can't be fixed - but must be rewritten (or must have a separate test
written) because they make assumptions about exactly which set of
architectural options that a target has implemented. We can't simply allow
an implementor to decide which tests they want to run, and then declaring
themselves compliant with whatever subset they decided,  So, hey can't
simply delete the tests that don't pass from the list and insert one that
does; they need to declare what they implement and have the framework
select the tests.
Riscof is a prototype (and the only one) that was written to take all of
that into account. The riscv-configuration repository was spun off from
that, since it had much wider applicability than just compliance.
My hope is that as soon as riscof becomes really production worthy, it will
be the next version of the framework, and will permit  testing far more
corners of the architecture than is possible now. There's a lot of work
that needs to be done there, including rewriting tests to meet the v1.2.5
spec (which can be done even before switching to riscof).
Note that there is another dependency that will take a while to resolve:
the formal model has to support all the possible options that the
architecture allows, and that is probably a ways off.
On Mon, May 11, 2020 at 6:25 AM Olof Kindgren<EMAIL_ADDRESS>wrote:

Hi Simon,
First of all, thanks everyone for all the work you put into the compliance
tests. I'm a heavy user of them and have many times cursed how thorough
they are when I make changes to my CPU that really shouldn't break anything
:)
I think the particular issue with the parallel make API could had been
solved in a backwards-compatible way by defining $work_dir_isa on targets
that hadn't yet opted in to use the parallel make. But I might very well be
wrong, and it's really beside the point. Stuff needs to break sometimes. I
also hadn't updated my local copy of the repo in over a year. And I totally
understand it's a hard issue since it's not feasible, or even possible to
test all the targets in this repository by someone making changes. And it's
of course even harder with targets that reside outside of this repo. I very
much appreciate the possibility to have the target code externally, so
that's something I would like to keep see support for (not least because I
wrote the patch
https://github.com/riscv/riscv-compliance/commit/6e46969fdaab38805b34e09068e37facc7d4ec13
to enable that :))
So let's focus on the process. I got three proposals that might improve
the situation.

I think it's easier to communicate API breaks between versions, than
between random git commits. So doing more frequent releases would help my
target files, since I can say it works with riscv-compliance e.g. v0.4 up
to v1.2.
2.
I think it would be great also to have an opt-in mailing list or other
forum where target maintainers can be notified of breaking changes and be
given a chance to comment. This is a bit similar to how changes that affect
multiple CPU architectures work in the Linux kernel
3.
Make sure to communicate backwards-incompatible changes in the commit
message and/or ChangeLog. Sometimes things break by mistake, and that's
fine. But if they are known, they should be written down
I'm still a bit confused about the relation between riscv-compliance the
the riscof framework. I noticed it mainly because there were a lot of bugs
that were marked with Fixed in RISCOF which led to my conclusion that it
was a new framework replacing the other one. But this issue report has
already wandered far from its original purpose so I'll bring up those
questions in another forum instead. And feel free to close the issue if
you're not planning on making a new release, which was the original issue I
had
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-compliance/issues/109#issuecomment-626699980,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHPXVJQJRKNOZCD7YGEW6BLRQ74EHANCNFSM4M4QAJOA
.

@olofk
Parallel build can be disabled by adding the make variable
PARALLEL=0
(but the default is set as PARALLEL=1)
I have not seen your code, but if copied from one of the other targets, a likely error is the 'temp' file used in one of the commands, for example here is an example form the spike script
RUN_TARGET=\
    $(TARGET_SIM) $(TARGET_FLAGS) --isa=rv32imc \
        +signature=$(work_dir_isa)/$(*).signature.output \
        $(work_dir_isa)/$< 2> $(work_dir_isa)/$@; \
                                cat $(work_dir_isa)/$(*).signature.output | sed 's/.\{8\}/& /g' | \
                                awk '{print $$4 " " $$3 " " $$2 " " $$1}' | sed 's/ /\n/g' > temp; \
                                mv temp $(work_dir_isa)/$(*).signature.output;

so what happens here is that multiple parallel processes all write to the same file - not good
this should be qualified as an intermidiate file by using the stem, eg
RUN_TARGET=\
    $(TARGET_SIM) $(TARGET_FLAGS) --isa=rv32imc \
        +signature=$(work_dir_isa)/$(*).signature.output \
        $(work_dir_isa)/$< 2> $(work_dir_isa)/$@; \
                                cat $(work_dir_isa)/$(*).signature.output | sed 's/.\{8\}/& /g' | \
                                awk '{print $$4 " " $$3 " " $$2 " " $$1}' | sed 's/ /\n/g' > $(*).temp; \
                                mv $(*).temp $(work_dir_isa)/$(*).signature.output;

Thx
Lee

IF the above suggestions have fixed the issue, could you close it please?
FYI: there is another update coming very shortly that will have some further changes (see PR#154)
IT will have a LOT of new tests whose format conforms to the test format spec, a standard trap handler, streamlined test directory, a more regular naming convention, and updated documentation.
There is a migration document that has details on what to change (not very much, as there are aliases and symlinks for backwards compatibility, but there are a few macros that need renaming).
We would appreciate it if you could try it out and let us know what breaks.

I was just reminded of the existence of this bug report and don't think there is any point in keeping it open


Build failed after Gradle 8.0.2 upgrade (on 1.1.7)

Hello, I'm getting this error:
[        ] FAILURE: Build failed with an exception.
[        ] * What went wrong:
[        ] Execution failed for task ':flutter_contacts:compileDebugKotlin'.
[        ] > 'compileDebugJavaWithJavac' task (current target is 1.8) and 'compileDebugKotlin' task (current target is 17) jvm target compatibility should be set to the same Java version.
[        ]   Consider using JVM toolchain: https://kotl.in/gradle/jvm/toolchain
[        ] * Try:
[        ] > Run with --debug option to get more log output.
[        ] > Run with --scan to get full insights.
[        ] * Exception is:
[        ] org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':flutter_contacts:compileDebugKotlin'.

that I can fix it by adding
// ...

android {
    namespace 'co.quis.flutter_contacts'

    compileOptions {
        sourceCompatibility JavaVersion.VERSION_17
        targetCompatibility JavaVersion.VERSION_17
    }
    kotlinOptions {
        jvmTarget = '17'
    }
    // ...
}

// ...

to my ...\AppData\Local\Pub\Cache\hosted\pub.dev\flutter_contacts-1.1.7\android\build.gradle but it shouldn't require this normally, all the other packages are fine so it suggests Gradle configuration isn't well done in this package. It's also obviously bad to manually modify the cached packages.
For starters, the namespace should be defined like this for backward compatibility (this fixes another potential issue, not the current one) :
// ...

android {

    // Conditional for compatibility with AGP <4.2.
    if (project.android.hasProperty("namespace")) {
        namespace 'co.quis.flutter_contacts'
    }

    // ...
}

// ...

cc: @joachimvalente

Thanks for reporting @TiffApps
Closing as duplicate of #127


Access docs cleanup

We're doing really weird spacing (or lack of spacing) all over this page ... I think I got all instances for this guide

I think your editor added even more really weird spaces .. Can you make this PR look more like: https://github.com/linode/manager/pull/2439/files?w=1

yes

https://reactjs.org/blog/2014/02/20/react-v0.9.html#jsx-whitespace is behind this

gonna re-PR this now that I've figured out how to fix


w-select menu in a w-dialog gets rendered below the dialog

Hey there!
when I use a w-select in a w-dialog, the menu elements are rendered behind the dialog and were not accessible. I tried to fix it by adding:
.w-select__menu {
  z-index: 100;
}

But I could not get it working. I will let you know, if I find some more details.
Cheers :)

Same issue when using a w-overlay

Hi @nmauersberg,
This is actually possible with the detach-to option.
Example: https://codepen.io/antoniandre/pen/ZEexvEP?editors=1000
  <w-dialog class="my-dialog" content-class="pa6">
    <w-menu detach-to=".my-dialog">
      <template #activator="{ on }">
        <w-button
          v-on="on"
          outline
          color="primary">
          Show menu on click
        </w-button>
      </template>
      Menu content
    </w-menu>
  </w-dialog>

Alternatively, you could use the z-index option on the w-menu element to increase it.
The reason why it's not automatic, is that generating the z-index internally via JavaScript according to where it is mounted in (in a dialog or even a nested dialog) would actually be troublesome to override externally via CSS - and also heavier in JavaScript.
Hope it makes sense!
Side note: I just released version 1.32.4 where now, a click on the activator will hide the open menu (not with show-on-hover).

Oh cool! Thank you for the explanation! :) Yes, makes perfectly sense. Hiding the menu on an additional click is also very nice! Already tried to customize that. The same functionality would be awesome for w-select elements! ;) Sometimes its hard to get out of them, when there is little space around.
Now after the update the labels do not work in the w-select menu, like before. Do I need to change it for w-select?

Here is an Image of what happens: https://imgur.com/6lICHNI.png
Labels get undefined.
Cheers!

From v. 1.32.4 on the labels in the "w-select" dropdown are showing undefined for me. Tried with the most basic w-select and it was still like that, so there might be a small bug? :)
https://imgur.com/6lICHNI.png

Will close this issue now.
Thank you! :)

Hi @nmauersberg,
Thanks for reporting the other issues and feedback.
I've investigated what could have happened on your project and why you would see "undefined", and I could reproduce on a not-up-to-date Nuxt project, switching from Wave UI 1.32.3 to 1.32.4.
Which means the problem came from a change I made between these 2 versions. Looking at it, https://github.com/antoniandre/wave-ui/commits/master the only change I made is the update of the Vue dependency: https://github.com/antoniandre/wave-ui/commit/acb8059dde4dfd884b0037ab5b19fcde2d004e42
So to solve this issue, you need to either run npm i vue vue-server-renderer vue-template-compiler (the renderer & compiler must have the same version number as Vue), or delete your node_modules and package-lock.json (or yarn.lock) and run the install of dependencies again.
For the w-select click to close, I agree! I'll see what I can do.

Hi @antoniandre :)
This solved it for me, I missed deleting the package-lock.json. Thank you for investigating!!
Wishing you an excellent week ahead.
Cheers

@nmauersberg, w-select is now also closable on click in version 1.32.7!
Have a great week too.

@antoniandre Thank you! 😊 Awesome!!

Hey @nmauersberg,
I realized I showed you an example for w-menu and not w-select. I hope you figured in the end!
I have updated the missing description for menu-props to make it a little bit clearer (https://antoniandre.github.io/wave-ui/w-select#menu-props).
And just to be clear, the w-select component uses w-menu under the hood to attach the floating menu to a DOM node (by default to .w-app) and you could override that with :menu-props="{ detachTo: '.my-container' }".
If in the future you find something not well explained in the docs don't hesitate to ask!

@antoniandre Thank you friend! I appreciate your work and your help very much.
Yes, I figured it out, thanks :) Your components are structured very understandable, so I saw that w-menu is used in w-select.
You'll certainly hear from me anyways xD
Cheers

@antoniandre One more question came up today, the "w-checkbox" seems to transform into several divs, with the first one having the "w-flex" and the "wrap" class attached. I am trying to remove the wrap class somehow, because I don't want it to wrap, when there is little space around. Do you know a way to achieve this?
And should I open an issue for small questions like this? Maybe some sort of Community / Chat / Forum would be cool, for wave-ui users to exchange and to help each other. I don't want to waste your time with small support requests and questions like this.
Kind regards,
Nico

@antoniandre Nevermind! It was my own stupidity! :D

Sorry Nicolai, I've been very busy lately.
I'll catch up later this week with a solution for you. :)

Hi @nmauersberg,
I've modified a few things to apply the wrap class (causes a flex-wrap) more precisely, on UI elements that are in a form.
That's the class that causes you trouble. :)
The purpose of the wrap class is to put on multiple lines an element when a label is present and is positioned outside of the field on the left or right, or to wrap the w-checkboxes and w-radios when inline and not fitting on 1 line.
In these screenshots you'll see how the new layout of all the components on different resolutions.

As you can see when a label is outside, it is best to display it on top of the field itself. But I also agree it does not make sense for single checkbox, single radio, and switch as you pointed. So I removed the wrap for them.
Let me know if there's anything else you see not working.
Cheers!

@antoniandre Thank you :) This is really awesome!
The notification manager is a great improvement too. Unfortunately the update to 1.36.0 is not working for me. I am getting the following error:
 ERROR  [Vue warn]: Error in render: "TypeError: Cannot read property 'notifications' of null"                                                                                15:13:09

found in

---> <WNotificationManager> at src/wave-ui/components/w-notification-manager.vue
       <WApp> at src/wave-ui/components/w-app.vue
         <Layouts/default.vue> at layouts/default.vue
           <Root>

After a look at the "w-notification-manager" component, it seems to me like the "this.notifManager" data prop is still initialized as null, when the computed method tries to access it. Even though it should be instantiated as a "new NotificationManager()" in beforeMount. Maybe some sort of (nuxt-related) timing issue?
I tried debugging, but changes to the source code in the node_module did apply, since the bundled version is used and I was not able to rebuild the module properly. I also tried deleting node_modules and the package-lock.json, but I keep getting this error, using nuxt js.
Cheers! :)

@antoniandre Don't worry! I fully understand that you are busy! :) I am really grateful for your work, no need to rush, when I ask something.
Okay, I will open a new Issue for the w-notification-manager issue.


[CT-1296] If the name of a macro and the name of a folder is the same - the docs site does not load properly

Details

Describe the bug
This is the most obscure bug I've ever come across (perhaps also this feels like it should occur more often?). But if you have a folder with the same name as the filename (where in it the macro name is also the filename) - then the generated docs site throws a type error.
Edit: It looks like if you have a macro that is the same name as a folder name.
Steps To Reproduce
Project setup:
# dbt_project.yml
name: "my_dbt_project"
version: "1.0.0"
config-version: 2
profile: "snowflake"

models:
  my_dbt_project:
    +materialized: table

^ Doesn't matter actually.
Macros:
-- macros/bar.sql
{% macro my_macro(arg) %}

select * from my_table

{% endmacro %}

-- macros/my_macro/foo.sql
{% macro foo(arg) %}

select * from my_table

{% endmacro %}

^ Important bit. A macro called my_macro exist but there's also a folder called my_macro.
Now lets generate some docs and have a look at our site:
dbt clean && dbt docs generate && dbt docs serve

Expected behavior
The site should load as expected.
Screenshots and log output
Logs aren't interesting because there is no issue generating the artefacts.
These are the relevant bits in the manifest.json file... I wonder how they're causing the JS error we see:
    "macro.my_dbt_project.my_macro": {
      "unique_id": "macro.my_dbt_project.my_macro",
      "package_name": "my_dbt_project",
      "root_path": "/Users/jeremy/src/dbt-sandcastles/dbt/snowflake",
      "path": "macros/bar.sql",
      "original_file_path": "macros/bar.sql",
      "name": "my_macro",
      "macro_sql": "{% macro my_macro(arg) %}\n\nselect * from my_table\n\n{% endmacro %}",
      "resource_type": "macro",
      "tags": [],
      "depends_on": { "macros": [] },
      "description": "",
      "meta": {},
      "docs": { "show": true },
      "patch_path": null,
      "arguments": [],
      "created_at":<PHONE_NUMBER>.010019
    },
    "macro.my_dbt_project.foo": {
      "unique_id": "macro.my_dbt_project.foo",
      "package_name": "my_dbt_project",
      "root_path": "/Users/jeremy/src/dbt-sandcastles/dbt/snowflake",
      "path": "macros/my_macro/foo.sql",
      "original_file_path": "macros/my_macro/foo.sql",
      "name": "foo",
      "macro_sql": "{% macro foo(arg) %}\n\nselect * from my_table\n\n{% endmacro %}",
      "resource_type": "macro",
      "tags": [],
      "depends_on": { "macros": [] },
      "description": "",
      "meta": {},
      "docs": { "show": true },
      "patch_path": null,
      "arguments": [],
      "created_at":<PHONE_NUMBER>.010705
    },

The output of dbt --version:
dbt-core 1.2.1
dbt-snowflake 1.2.0

Ftr, I tried with dbt 0.21.0 as well to see if manifest generation got wonky in 1.0 just see if this was a newish behaviour but it remained the same.
Additional context
Probably the folder tree issue:

Don't really know how to navigate this code base but interestingly when I force the flat to be:
      var new_flat = [
        {
          type: "folder",
          name: "my_dbt_project",
          active: false,
          items: [
            {
              type: "folder",
              name: "macros",
              active: false,
              items: [
                {
                  type: "file",
                  name: "my_macro",
                  node: {
                    unique_id: "macro.my_dbt_project.my_macro",
                    package_name: "my_dbt_project",
                    root_path:
                      "/Users/jeremy/src/dbt-sandcastles/dbt/snowflake",
                    path: "macros/bar.sql",
                    original_file_path: "macros/bar.sql",
                    name: "my_macro",
                    macro_sql:
                      "{% macro my_macro(arg) %}\n\nselect * from my_table\n\n{% endmacro %}",
                    resource_type: "macro",
                    tags: [],
                    depends_on: {
                      macros: [],
                    },
                    description: "",
                    meta: {},
                    docs: {
                      show: true,
                    },
                    patch_path: null,
                    arguments: [],
                    created_at:<PHONE_NUMBER>,
                  },
                  active: false,
                  unique_id: "macro.my_dbt_project.my_macro",
                  node_type: "macro",
                  $$hashKey: "object:34",
                },
                {
                  type: "folder",
                  name: "my_macro",
                  active: false,
                  items: [
                    {
                      type: "file",
                      name: "foo",
                      node: {
                        unique_id: "macro.my_dbt_project.foo",
                        package_name: "my_dbt_project",
                        root_path:
                          "/Users/jeremy/src/dbt-sandcastles/dbt/snowflake",
                        path: "macros/my_macro/foo.sql",
                        original_file_path: "macros/my_macro_new/foo.sql",
                        name: "foo",
                        macro_sql:
                          "{% macro foo(arg) %}\n\nselect * from my_table\n\n{% endmacro %}",
                        resource_type: "macro",
                        tags: [],
                        depends_on: {
                          macros: [],
                        },
                        description: "",
                        meta: {},
                        docs: {
                          show: true,
                        },
                        patch_path: null,
                        arguments: [],
                        created_at:<PHONE_NUMBER>,
                      },
                      active: false,
                      unique_id: "macro.my_dbt_project.foo",
                      node_type: "macro",
                      $$hashKey: "object:43",
                    },
                  ],
                  $$hashKey: "object:35",
                },
              ],
              $$hashKey: "object:29",
            },
          ],
          $$hashKey: "object:22",
        },
      ];

Around:
https://github.com/dbt-labs/dbt-docs/blob/092cbd53413814bbda84e52bfcdd6dd8fb1e904c/src/app/services/project_service.js#L644
Purposely having 2 objects with the name being my_macro... the site rendered alright:

Somewhere here is breaking it currently:
https://github.com/dbt-labs/dbt-docs/blob/092cbd53413814bbda84e52bfcdd6dd8fb1e904c/src/app/services/project_service.js#L620-L640
But don't fully understand what.

thanks for opening and all of the investigation @jeremyyeo! this looks tricky


Update Show/String to Debug/Display

This commit replaces usage of the Show and fmt::String traits with the Debug and Display traits, respectively. This was required to fix breaking changes introduced by rust-lang/rust#21457. Additionally, the superfluous detail method on docopt::Error was removed as it no longer exists in the trait. Also, hi!

Hi @ianbollinger! Small world!
Thank you. :D

I've uploaded 0.6.31 to crates.io.


Access-Control-Allow-Origin

Failed to load.... No 'Access-Control-Allow-Origin' header is present on the requested resource.Therefore not allowed access. The response had HTTP status code 415.

When I check with API through Ajax post request ,it is throwing an error : Failed to load resources:ERR_CERT_COMMON_NAME_INVALID error ) when accessing remote HTTPS webpage.
Is there anyone who can help me how to get rid of the errors and receive the data I need for my application?

@sushantkumarswain You're running into a CORS issue, you can read more on this here.


Remove Vote::isVoteValid type hint

see https://github.com/FriendsOfSymfony/FOSCommentBundle/issues/538#issuecomment-227469302

The warnings aren't related.

Thanks!


No CORS-Headers sent in Lumen 5.2

Using Lumen 5.2.6 and laravel-cors 0.8.0.
After copying cors.php to /config and updating my /bootstrap/app.php with
// [...]

$app->middleware([
    Barryvdh\Cors\HandleCors::class
]);

$app->register(Barryvdh\Cors\LumenServiceProvider::class);

$app->configure('cors');

// [...]

no CORS headers are being sent and no errors are shown.
The /config/cors.php is being picked up though.
Adding header("Access-Control-Allow-Origin: *"); to /public/index.php shows the header.
Is there anything missing, or do I still need to specify the cors middleware in my routes/controllers?

Any update on this? Still the same issue with Lumen 5.2.

@bernhardw @Jordy-A
Did you somehow managed to solve this issue? I'm having the same one - i've tried about 5 or 6 different cors libraries and none of them works in lumen.
Also, i would add that on php 5.6.x i get 200 for OPTIONS (cors working) and then 200 for POST (cors header not present), but: when i switch to php 7.0.x then i get 200 for OPTIONS (cors working) and then... 404 for post.

Honestly, I just kept the Access-Control-Allow-Origin headers hard-coded in my index.php for that project and was using Laravel since.

Yes, same for me. I created my own middleware and that seems to work.

@bernhardw @Jordy-A Thank's for quick response!
Envy you guys: I have preflight requests (as far as i understand because of Authorization: Bearer: <jwt-token> header) and those workarounds probably won't work for me, as i'd end up defining an OPTIONS for every possible route then.

@bernhardw @Jordy-A I've found something. It seems that everything works fine, just as expected, but only when i have xdebug enabled in php.ini. Anyway after enabling it, two (laravel-cors and some other i've tested) of them works fine without any hacks. After disabling xdebug they stop working. An so on.
Do you maybe happen to code with xdebug disabled and / or on windows wamp (this were i have the issue)?
Anyway it seems like it's absolutely not laravel-cors related.

It could be related to Wamp as I'm using that too, yes. I'll take a look at it later!


queryRenderedFeatures returns wrong results

queryRenderedFeatures does not work anymore. wrong - incomprehensible - results.
@ntadej
issue startet with this commit: https://github.com/maplibre/maplibre-gl-native/commit/fe041b80caca953d5ffbea19b5d2a36484d0286a
before this commit (e.g. https://github.com/maplibre/maplibre-gl-native/commit/c0d76c69cc6f3abbc2be44c79f387bab114a0875) everything is as expected.
so far only tested under android

Can you try to make a minimal reproducer? I see there's a unit test available, but not sure how to run it for Android: https://github.com/maplibre/maplibre-gl-native/blob/master/test/api/query.test.cpp

After some (more) tests I find out that this change causes the problems:
src/mbgl/util/tile_coordinate.hpp
https://github.com/maplibre/maplibre-gl-native/commit/fe041b80caca953d5ffbea19b5d2a36484d0286a#diff-0ee83ffd64534bebe9fbe1eff7412f516881e00460b30a21ba4edefae1830441
After reverse this change and recompile all seems to be like it should be.
I am absolutly not familiar with C++ and cannot see the issue. Perhaps anybody can comprehend (and explain) why this change makes problems.

oh sorry,
could it be that this commit is relating and fixed it?
135dca679b648f885b9c7273c4b820faf597c826
I only tested latest Android release https://github.com/maplibre/maplibre-gl-native/releases/tag/android-v9.5.1 and not latest MASTER
If this is the case and this issue does not exist in master i think there should be a hotfix release android-v9.5.2 in order to fix this  critical issue in public release version.

I have the same issue with the latest iOS release v5.12.1.
Going back to v5.12.0 resolves the issue and MapView.visibleFeatures(at: CGPoint) works just fine.

@mkieselmann
yes. I can confirm commit fe041b8 has also landed in ios-5.12.1 release. So you have to wait for a new release (or compile master yourself).
unfortunately i don't know if this project is still alive and if further releases will come.

@mkieselmann @moodstubos @ntadej I have created new android release 9.5.2. Any chance to re-test this issue with the new release so that we can close it? Thanks!


CodeGen incorrect for type guards in is- and match-expressions

When using type guards, the generated JS does not check them, instead assigns values to the names in every case and only performs a null-check.
This applies to both match-expressions and is-expressions.
I would have expected to see these checks generated with either an instanceof generator or through some additional metadata.
Steps To Reproduce
https://deck.net/2bf6281aab2e19f88a983eeda316f41d
public class Base {}
public class Derived1 : Base {
    public void foo() {}
}
public class Derived2 : Base {
    public void bar() {}
}

public class Program
{
    public static void Main()
    {
        Base foo = new Derived1();
        switch(foo) {
            case Derived1 d:
                d.foo();
                break;
            case Derived2 e:
                e.bar();
                break;
        }
        if (foo is Derived2 f) {
            f.bar();
        }
    }
}

Expected Result
/**
 * @compiler Bridge.NET 17.0.0
 */
Bridge.assembly("Demo", function ($asm, globals) {
    "use strict";

    Bridge.define("Demo.Base");

    Bridge.define("Demo.Program", {
        main: function Main () {
            var foo = new Demo.Derived1();
            do {
                if (foo instanceof Demo.Derived1) {
                    var d = foo;
                    d.foo();
                    break;
                }

                if (foo instanceof Demo.Derived2) {
                    var e = foo;
                    e.bar();
                    break;
                }
            } while (false);
            var f;
            if ((f = foo) instanceof Demo.Derived2) {
                f.bar();
            }
        }
    });

    Bridge.define("Demo.Derived1", {
        inherits: [Demo.Base],
        methods: {
            foo: function () { }
        }
    });

    Bridge.define("Demo.Derived2", {
        inherits: [Demo.Base],
        methods: {
            bar: function () { }
        }
    });
});

Actual Result
/**
 * @compiler Bridge.NET 17.0.0
 */
Bridge.assembly("Demo", function ($asm, globals) {
    "use strict";

    Bridge.define("Demo.Base");

    Bridge.define("Demo.Program", {
        main: function Main () {
            var foo = new Demo.Derived1();
            do {
                if (foo) {
                    var d = foo;
                    d.foo();
                    break;
                }

                if (foo) {
                    var e = foo;
                    e.bar();
                    break;
                }
            } while (false);
            var f;
            if (((f = foo)) != null) {
                f.bar();
            }
        }
    });

    Bridge.define("Demo.Derived1", {
        inherits: [Demo.Base],
        methods: {
            foo: function () { }
        }
    });

    Bridge.define("Demo.Derived2", {
        inherits: [Demo.Base],
        methods: {
            bar: function () { }
        }
    });
});

Hi @Cu3PO42 It appears this issue has already been fixed and will be available in the next release.
You can check the generated output in our dev instance of Deck.
https://dev.deck.net/2bf6281aab2e19f88a983eeda316f41d
Hope this helps.

Awesome! Thanks so much again.


Type-safe project accessors

[ ] Read CONTRIBUTING.md.

Use type-safe project accessors.
Summary of changes:

Type-safe project accessors.
Remove testInstrumentationRunner.

Tested changes:
App builds 👍

TODO: Fix #75.


Network experiment structure update

Automation for azure-sdk-for-go

Can one of the admins verify this patch?


Support busybox

sort -C is not supported in busybox, which is used in alpine linux

@elruwen Thanks for opening up the PR. I rebased it and added some lint/shellcheck updates. Outside of that, I don't see any reason we can't use little c here since most operating systems seem to support it.


Dag workflow will stay running forever in some long run situation.

Is this a BUG REPORT or FEATURE REQUEST?:
BUG
What happened:
Workflow stay running forever
What you expected to happen:
Workflow failed
How to reproduce it (as minimally and precisely as possible):
Here is Workflow Status
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  creationTimestamp: 2019-01-24T06:44:57Z
  generateName: dag-diamond-
  generation: 1
  labels:
    workflows.argoproj.io/completed: "true"
    workflows.argoproj.io/phase: Succeeded
  name: dag-diamond-8q456
  namespace: default
  resourceVersion: "3363752"
  selfLink: /apis/argoproj.io/v1alpha1/namespaces/default/workflows/dag-diamond-8q456
  uid: 9059470d-1fa3-11e9-bc14-00163e0337d4
spec:
  activeDeadlineSeconds: 0
  arguments: {}
  entrypoint: diamond
  templates:
  - container:
      command:
      - echo
      - '{{inputs.parameters.message}}'
      image: alpine:3.7
      name: ""
      resources: {}
    inputs:
      parameters:
      - name: message
    metadata: {}
    name: echo
    outputs: {}
  - dag:
      tasks:
      - arguments:
          parameters:
          - name: message
            value: A
        name: A
        template: echo
      - arguments:
          parameters:
          - name: message
            value: B
        dependencies:
        - A
        name: B
        template: echo
      - arguments:
          parameters:
          - name: message
            value: C
        dependencies:
        - A
        name: C
        template: echo
      - arguments:
          parameters:
          - name: message
            value: D
        dependencies:
        - B
        - C
        name: D
        template: echo
    inputs: {}
    metadata: {}
    name: diamond
    outputs: {}
status:
  finishedAt: 2019-01-24T06:45:17Z
  nodes:
    dag-diamond-8q456:
      children:
      - dag-diamond-8q456-1022901548
      displayName: dag-diamond-8q456
      finishedAt: 2019-01-24T06:45:17Z
      id: dag-diamond-8q456
      name: dag-diamond-8q456
      outboundNodes:
      - dag-diamond-8q456-972568691
      phase: Running
      startedAt: 2019-01-24T06:44:57Z
      templateName: diamond
      type: DAG
    dag-diamond-8q456-972568691:
      boundaryID: dag-diamond-8q456
      displayName: D
      finishedAt: 2019-01-24T06:45:16Z
      id: dag-diamond-8q456-972568691
      inputs:
        parameters:
        - name: message
          value: D
      name: dag-diamond-8q456.D
      phase: Succeeded
      startedAt: 2019-01-24T06:45:14Z
      templateName: echo
      type: Pod
    dag-diamond-8q456-1022901548:
      boundaryID: dag-diamond-8q456
      children:
      - dag-diamond-8q456-1073234405
      - dag-diamond-8q456-1056456786
      displayName: A
      finishedAt: 2019-01-24T06:45:08Z
      id: dag-diamond-8q456-1022901548
      inputs:
        parameters:
        - name: message
          value: A
      name: dag-diamond-8q456.A
      phase: Succeeded
      startedAt: 2019-01-24T06:44:57Z
      templateName: echo
      type: Pod
    dag-diamond-8q456-1056456786:
      boundaryID: dag-diamond-8q456
      children:
      - dag-diamond-8q456-972568691
      displayName: C
      finishedAt: 2019-01-24T06:45:11Z
      id: dag-diamond-8q456-1056456786
      inputs:
        parameters:
        - name: message
          value: C
      name: dag-diamond-8q456.C
      phase: Succeeded
      startedAt: 2019-01-24T06:45:09Z
      templateName: echo
      type: Pod
    dag-diamond-8q456-1073234405:
      boundaryID: dag-diamond-8q456
      children:
      - dag-diamond-8q456-972568691
      displayName: B
      finishedAt: 2019-01-24T06:45:11Z
      id: dag-diamond-8q456-1073234405
      inputs:
        parameters:
        - name: message
          value: B
      name: dag-diamond-8q456.B
      phase: Succeeded
      startedAt: 2019-01-24T06:45:09Z
      templateName: echo
      type: Pod
  phase: Running
  startedAt: 2019-01-24T06:44:57Z

You can see that root DAG step is running.   But all  children node is failed.
Anything else we need to know?:
Environment:

Argo version:

argo: v2.2.1
  BuildDate: 2018-10-11T16:26:28Z
  GitCommit: 3b52b26190163d1f72f3aef1a39f9f291378dafb
  GitTreeState: clean
  GitTag: v2.2.1
  GoVersion: go1.10.3
  Compiler: gc
  Platform: linux/amd64

[root@iZ8vb5qgxqbxakfo1cuvpaZ ~]# argo get dag-diamond-8q456
Name:                dag-diamond-8q456
Namespace:           default
ServiceAccount:      default
Status:              Running
Created:             Thu Jan 24 14:44:57 +0800 (34 minutes ago)
Started:             Thu Jan 24 14:44:57 +0800 (34 minutes ago)
Finished:            Thu Jan 24 14:45:17 +0800 (34 minutes ago)
Duration:            20 seconds

STEP                  PODNAME                       DURATION  MESSAGE
 ● dag-diamond-8q456
 ├-✔ A                dag-diamond-8q456-1022901548  11s
 ├-✔ B                dag-diamond-8q456-1073234405  2s
 ├-✔ C                dag-diamond-8q456-1056456786  2s
 └-✔ D                dag-diamond-8q456-972568691   2s

Can anyone help to debug this situtation.

@alexmt  @jessesuen
I can reproduce this pure dag issue, in diamond pattern.
https://gist.github.com/xubofei1983/e73f184e5770c0a6f8677b7c4069b32f

● retry-with-dags-krj86
├-✔ hello1(0)            retry-with-dags-krj86-2368448136  1s
├-✔ hello2(0)            retry-with-dags-krj86-1872593483  1s
├-✔ hello32
| ├-✔ hellosub21(0)      retry-with-dags-krj86-2590853895  2s
| ├-✔ hellosub22(0)      retry-with-dags-krj86-4155253284  29s
| └-✔ hellosub23(0)      retry-with-dags-krj86-528723241   2s
├-✔ hello33
| ├-✔ hellosub21(0)      retry-with-dags-krj86-2923825724  1s
| ├-✔ hellosub22(0)      retry-with-dags-krj86-2922153183  1s
| └-✔ hellosub23(0)      retry-with-dags-krj86-1164382842  22s
└-✖ hello31
├-✔ hellosub11(0)      retry-with-dags-krj86-1343433011  1s
├-✔ hellosub12(0)      retry-with-dags-krj86-1339882672  10s
└-✖ hellosub13                                                     No more retries left
├-✖ hellosub13(0)    retry-with-dags-krj86-913253045   16s       failed with exit code 1
├-✖ hellosub13(1)    retry-with-dags-krj86-2859603944  1s        failed with exit code 1
├-✖ hellosub13(2)    retry-with-dags-krj86-711627427   1s        failed with exit code 1
└-✖ hellosub13(3)    retry-with-dags-krj86-242001190   1s        failed with exit code 1

@alexmt  create another run and that's the output
https://gist.github.com/xubofei1983/9d2317db84ee2419c2883169e440036f

Also, for such case   "argo terminate" does not work at all, I think because all pods already finished.
So there is no way to stop and resubmit to my knowledge.  We have to start from beginning, which is terrible.

Thanks for providing a simple way to reproduce the issue @xubofei1983 . Your case should be fixed by https://github.com/argoproj/argo/pull/1208 . Root cause was incorrect handling of successfully completed step with retries.
Here is simplest workflow which causes it:
 dag with retry
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: retry-with-dags-
spec:
  entrypoint: retry-with-dags
  templates:
  - name: retry-with-dags

    dag:
      tasks:
      - name: success1
        template: success

      - name: sub-dag1
        template: sub-dag
        dependencies:
        - success1

      - name: success2
        dependencies:
        - sub-dag1
        template: success

  - name: sub-dag
    dag:
      tasks:
      - name: fail
        template: fail

  - container:
      args:
      - import random; import sys; exit_code = 1; sys.exit(exit_code)
      command:
      - python
      - -c
      image: python:alpine3.6
    name: fail

  - container:
      args:
      - import random; import sys; exit_code = 0; sys.exit(exit_code)
      command:
      - python
      - -c
      image: python:alpine3.6
    name: success
    retryStrategy:
      limit: 3

I'm still unable to reproduce original issue described at https://github.com/argoproj/argo/issues/1190#issue-402573294 (pure dag without retries) though. Keep looking at it.

Thanks @alexmt  for the quick fix.

What is the best way to install your fix? Do we update the workflow-controller container to point at the latest tag here https://hub.docker.com/r/argoproj/workflow-controller/tags ?
I can easily recreate this issue, and just cause general chaos, with this test:
`
apiVersion:             argoproj.io/v1alpha1
kind:                   Workflow
metadata:
generateName:         testing-workflow-
spec:
entrypoint:           testing-workflow
templates:

name:               testing-workflow
steps:

name:           testing-steps
template:       testing-steps
withItems:
- "a"
- "b"
- "c"
- "d"
- "e"
- "f"
- "g"
- "h"
- "i"
- "j"
- "k"
- "l"
- "m"
- "n"
- "o"
- "p"
- "r"
- "s"
- "t"
- "u"
- "v"
- "w"
- "x"
- "y"
- "z"

name:               testing-steps
dag:
tasks:

name:           run-testing1
template:       run-testing
name:           run-testing2
template:       run-testing
dependencies:   [run-testing1]

name:               run-testing
container:
image:            frolvlad/alpine-bash
imagePullPolicy:  Always
command:          [bash, -c]
args:             ["if (( RANDOM % 2 )); then echo 'fail'; exit 1; else echo 'success'; fi"]
`

@andreweskeclarke I have the same problem with my DAG workflow so I did this:
kubectl set image deployment/workflow-controller workflow-controller=argoproj/workflow-controller:latest --namespace=argo

It is not ideal. But until the new version is released, this seems to work.

I'm trying to use @illagrenan's suggestion to pull the latest tag and use that, but the latest tag is still failing for this issue. Version I'm currently using "Workflow Controller (version: v2.3.0+2b0b8f1.dirty)".
Anyone else have success with this fix?

@alexmt   I use the master branch build the image, but for the test case
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: retry-with-dags-
spec:
  entrypoint: retry-with-dags
  templates:
  - name: retry-with-dags

    dag:
      tasks:
      - name: success1
        template: success

      - name: sub-dag1
        template: sub-dag
        dependencies:
        - success1

      - name: success2
        dependencies:
        - sub-dag1
        template: success

  - name: sub-dag
    dag:
      tasks:
      - name: fail
        template: fail

  - container:
      args:
      - import random; import sys; exit_code = 1; sys.exit(exit_code)
      command:
      - python
      - -c
      image: python:alpine3.6
    name: fail

  - container:
      args:
      - import random; import sys; exit_code = 0; sys.exit(exit_code)
      command:
      - python
      - -c
      image: python:alpine3.6
    name: success
    retryStrategy:
      limit: 3

It will be running forever always,
[root@iZ8vbha5mb49ipi1114n6bZ dag-hang]# ags get retry-with-dags-z5kdr
Name:                retry-with-dags-z5kdr
Namespace:           default
ServiceAccount:      default
Status:              Running
Created:             Mon Mar 25 17:46:53 +0800 (3 minutes ago)
Started:             Mon Mar 25 17:46:53 +0800 (3 minutes ago)
Duration:            3 minutes 24 seconds

STEP                      PODNAME                           DURATION  MESSAGE
 ● retry-with-dags-z5kdr
 ├-✔ success1(0)          retry-with-dags-z5kdr-563744608   8s
 └-✖ sub-dag1
   └-✖ fail               retry-with-dags-z5kdr-1558755693  9s        failed with exit code 1

I'm having the same issue with DAGs, and I can easily replicate off the above script using v2.3.0-rc1. This is a pretty urgent bug, as errors will go unreported if the jobs do not properly fail.

@alexmt Pls take a look

Will try to look into it tomorrow and hopefully include into 2.3

@alexmt Any update on this?

@alexmt is looking into this. It will be fixed soon.

I have a fix for this.