Add an option to drop the .html suffix from links

Search Terms
option, html, suffix, extension
Problem
Currently all the links from one part of the documentation to another use .html extensions. This is great as a default because it will work anywhere, but when publishing it via a service like GitHub Pages the .html extension is redundant.
Suggested Solution
I suggest adding an option that will drop the .html extension from all the internal links when building the site.

This is tricky... right now we don't differentiate between creating urls to write the file, and creating urls to link between pages.
I guess for 0.20 and lower, this could be done with a tweak to the relativeURL handlebars helper - https://github.com/TypeStrong/typedoc/blob/1d5d1cb33d460d87fc09f0578ea9f51c60e44990/src/lib/output/plugins/MarkedPlugin.ts#L97-L99
In 0.21, I plan to make a change that will break this... but doing it there isn't horrible either. My first inclination is that I'd like this to be a plugin rather than in TypeDoc proper.

Yeah I was thinking it would work well as a plugin except that leaving them in is great for local development since they are required for navigating around when using file:// and I don't know of a way to selectively enable/disable a plugin.

You can use the --plugin option to select which plugins are loaded, or even add an option in the plugin itself to disable it

...didn't even think of that last option. Yeah that would make sense.
In the interest of future-proofing, what do you plan to change that would cause the use of relativeURL to break?

I'm dropping handlebars in favor of JSX, so handlebars helpers won't be able to mess with things anymore... I guess doing this later, and just doing a string replace before the files are written to disk would be more future proof, assuming I keep that event (I guess I could... wasn't planning on it initially, but if a published plugin is using it, I'm more likely to keep it working)
I'm going to try to have a initial beta (or at least code pushed for local experimentation) this weekend.

I'm going to try to have a initial beta (or at least code pushed for local experimentation) this weekend.

Looking unlikely. I need to start another status issue... spent entirely too much time trying to fix a bug.


Add allowed_applications field

Add allowed_applications so it works with a registered app created independently
Update deprecated property object_id with application_id
Add the posibility to disable function insights

@shibayan I believe that feature is interesting e.g. for qa environments where you do not want to track errors and avoiding that extra cost matters.
Additionally it comes by default enabled so you need to specifically set it to false to not include it.

Tracking errors is for my benefit as well. I cannot sustain development if my support costs increase to save a few cents per month.
Of course you are free to customize your environment, but I would prefer that this be an official module.

@shibayan Do you use Application Insights to send any sort of telemetry in order to solve bugs or is it because you do not want to waste time solving errors without logs enabled making it harder and more time consuming to find a solutio?.
Either case I believe is just better to let the user decide and if they do not have it enabled do not give any bug support at all.

It doesn't seem reasonable that every time an Issue is created I have to check to see if I have Application Insights enabled each time. The module will not implement the option to enable or disable Application Insights in the future.

@shibayan We can just ignore that feature and merge the other two?


Update ug archive and load

close #110

The name of pull request and branch should saying update DG, please ignore this slight problem


How can I add custom dimensions to my traces?

I am attempting to add some info per request to all spans. But whatever values we set when calling span.setAttribute(...) seem to not ever show up in our logs in app insights.
We are using koa, here is an example of what we're trying to do:
const config = new ApplicationInsightsConfig()
const appInsights = new ApplicationInsightsClient(config)
const traceHandler = appInsights.getTraceHandler()
traceHandler.addInstrumentation(new KoaInstrumentation({
  requestHook: (span, info) => {
    span.setAttribute('example', 'abc123')
  }
})

Using a debugger I can see that the request hook is called and I can see that the attribute is set onto the span yet when I look into application insights later, the attribute is not present on the log. A lot of standard data about the request appeared, so I can see that exact route was logged but the example attribute is nowhere in the data.
I am expecting the data to appear in the customDimensions field in the Log Analytics Workspace data. I am able to easily do this in the dotnet version of this library but can't seem to figure out how to use this library to track the same data.

Derp... reading it closely I see this:

...or the dependencies tables...

I queried the dependency tables and boom, I can see them in there instead of the requests table.
So given that, can I ask what determines whether a metric goes into the requests table vs the dependency table?

@justinmchase client Spans will end as dependency telemetry and servers Spans will end as request telemetry.


Add BaseRunner

Codecov Report
Attention: Patch coverage is 0% with 11 lines in your changes missing coverage. Please review.

Project coverage is 99.36%. Comparing base (be5f673) to head (f4b28ad).
Report is 6 commits behind head on main.

Files with missing lines
Patch %
Lines

src/arkas/runner/base.py
0.00%
8 Missing :warning:

src/arkas/runner/__init__.py
0.00%
3 Missing :warning:

Additional details and impacted files
@@             Coverage Diff             @@
##              main     #201      +/-   ##
===========================================
- Coverage   100.00%   99.36%   -0.64%
===========================================
  Files           71       73       +2
  Lines         1709     1720      +11
  Branches       169      170       +1
===========================================
  Hits          1709     1709
- Misses           0       11      +11

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


supreme score board doesn't show correct replay id

0.9.2-beta
mods: common mod tools v1, supreme score board v2.0
replay id is incorrect in live game, it is good in replay though
(phyton faf client has same issue after 0.18.0-rc2+3017, that is why I am still using that version)

hmmnot sure if that is a client issue but it might

logs?

the old phyton client log:
info: /savereplay
info: SSB >>> TRACE GetReplayId()... from cmd /savereplay 8943504
debug: Loading module '\000/mods/supremescoreboard/modules/score_mini.lua\000'
info: SSB >>> TRACE SetLayout()...

This is with downlords, diff, left is replay, right is the game

apparently the command line call /savereplay is no longer parsed correctly,
The old client does this:
/savereplay "gpgnet://localhost/8950120/Mielus.SCFAreplay"
The new:
/savereplay, gpgnet://<IP_ADDRESS>:65106/8947048/Mielus.SCFAreplay
And the port number is parsed as replayed by SSB
from SSB score_manager.lua:
function GetReplayId()
    local id = nil
    --log.Table(GetFrontEndData(''), 'GetFrontEndData')
    local syncID = GetFrontEndData('syncreplayid')
    if HasCommandLineArg("/syncreplay") and HasCommandLineArg("/gpgnet") and syncID ~= nil and syncID ~= 0 then
        id = syncID
        log.Trace('GetReplayId()... from cmd /syncreplay ' .. tostring(id) )

    elseif HasCommandLineArg("/savereplay") then
        local url = GetCommandLineArg("/savereplay", 1)[1]
        local lastpos = string.find(url, "/", 20)
        id = string.sub(url, 20, lastpos-1)
        log.Trace('GetReplayId()... from cmd /savereplay ' .. tostring(id) )

    elseif HasCommandLineArg("/replayid") then
        id =  GetCommandLineArg("/replayid", 1)[1]
        log.Trace('GetReplayId()... from cmd /replayid ' .. tostring(id) )
    end
    return id
end

lua has no regexp support :-(, quick and dirty fix:
--local lastpos = string.find(url, "/", 20) --don't bother searching..
id = string.sub(url, 26, 32)

So a change in the client broke SSB v2.0 and a fix is easy

So is there anything we should change? I am not 100% sure what u talked about

/savereplay, gpgnet://<IP_ADDRESS>:65106/8947048/Mielus.SCFAreplay
So is this valid or not should we remove the "," or what?

it is the port specification in the /savereplay command which throws of SSB, the string is no longer parsed correctly. I suspect since both the phyton and java client do this "new" port thing (since august 2018 or so) because of changes in the server. Should be fixed in SBB in my opinion, that is why I closed the issue.

Oh ok yeah, we use a custom port for the replay sever ;) This more robust. So if some application is running on the standard port it still works


New Feature: Command Summary

A feature that may be worth adding could be something like at the end of a run, getting a summary, such as:
Run time: 00:30:10, Mode: Stress, Threads:8, Average Usage: 32 W, Saved to:./measure/stress8.csv
I could see it being especially useful for testing long term power consumption of things like expansion cards.

Will get to work on it

Added in latest commit 295504b5446b5455032db144ceb0237e0050755b


Cannot download the final image on mobile browser

The bottom image at the end cannot be long-clicked to download, and there is no specific button for it either. Tested in Chrome for Android and MIUI Browser.

This occurs because the final image is a canvas element. I'm aware of the problem but unfortunately I don't know how to fix it! If anyone knows, feel free to contact me or put in a pull request.

This occurs because the final image is a canvas element

A suggestion: have an img overlay the canvas and then:
overlayImg.src = canvas.toDataURL();

Ran into this on mobile Safari too; the above suggestion sounds legit, should work. :)


TypeScript-Babel: jsdoc-to-assert is not working

"build:down_transform": "NODE_ENV=production babel __obj --out-dir lib --source-maps",

and
jsdoc-to-assert is setup in NODE=ENV=development.
and
JSDoc's type is removed in #68
It is not working.
Should we remove this from .babelrc?

Should we remove this from .babelrc?

How about https://github.com/almin/almin/issues/83? We might be able to re-enable power-assert

re-enable power-assert

Looks good to me.


fix: add network route update

:tada: This PR is included in version 1.135.3 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Add color option to CLI

Currently the CLI can't take options such as --color / --no-color. Ideally we'd be able pass these, and they would flow through with an Options struct to the compiler.
A future version could check whether we're in a TTY and default to --no-color if so (it's also possible that clap offers something like this?).
Labeling as Good first issue (which also make good nth issues). As ever, lots of folks will be happy to answer questions!

Hi Max,
I'd like to work on this. My thought of the steps for adding the option are:

Add one enable_color boolean field in the Option struct under the sql/mod.rs.

Add the cli argument enable_color, color, or no-color to the compile command.

Pass the cli argument as an Option field to the compile function

Please correct me if my understanding is wrong.

That would be great @Shuozeli !
I think that sounds very reasonable.
I would pass a full Options struct to the compile function (I think that's what you were suggesting). And yes re the --color / --no-color flags.
There's a "smaller" version where we strip out the color at the CLI level, I think that would be easier but less good (but OK!)
@aljazerzen lmk if you have any thoughts!

Hmm, sql does not do any highlighting ATM, so it doesn't need color option (at least for now). But the cli argument would be use to control this param in error formatting. This function is called
The best way to do this would be:

add a new Options struct to lib.rs:struct Options {
    sql: sql::Options,
    color: bool
}

change compile(prql: &str, options: Option<sql::Options>)
to this compile(prql: &str, options: Option<Options>)
add a impl Default for Options and impl From<sql::Options> for Options for convenience
make sure that all crates compile and pass cargo test

OK, so we'd have a nested Options struct. That seems very reasonable too.
@Shuozeli does that make sense to you?

Yes, thank you for the clarification. I will be working on this one.

@Shuozeli Any progress on this?


Always format date given by prometheus

What
Prometheus is returning the date in various different formats. For
instance, once it comes back as ISO string, the other as a UNIX
timestamp. This is causing problems with Date object where as moment
has been magically figuring this out.
How to review

Deploy to staging environment
See if performance dashboard is now behaving

🚨⚠ Please do not merge this pull request via the GitHub UI ⚠🚨

i suspect it's failing because of test data. we're already formatting the stub data to ISO in getGappyRandomData so I guess trying to format again in the controller isn't making it happy. wonder what format prom is returning in


[pickers] Uniformize customization, replace openPickerIcon prop

Breaking changes

[pickers] Uniformize customization, replace openPickerIcon prop

<DateTimePicker
  components={{
    LeftArrowIcon: AlarmIcon,
    RightArrowIcon: SnoozeIcon,
+   OpenPickerIcon: ClockIcon,
  }}
- openPickerIcon={<ClockIcon />}

[x] I have followed (at least) the PR section of the contributing guide.

Related to #21453 and #24511

Thanks for the feedback, i will make the changes over the weekend.

@eps1lon Ok, fair enough, I have changed the lens, isolating the issues and their solution.


[CT-1224] [Bug] type_string - Spark

Is this a new bug in dbt-core?

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

Current Behavior
When using the dbt-glue adapter with calogica/dbt-expectations macro for testing column types it would appear that type_string is trying to CAST to TEXT instead of STRING.
This causes the tests to fail
Expected Behavior
type_string should return STRING for casting.
Steps To Reproduce
11:42:15        from (
11:42:15          with relation_columns as (
11:42:15
11:42:15
11:42:15            select
11:42:15                cast('GL_HEADER_KEY' as TEXT) as relation_column,
11:42:15    ------------------------------------^^^
11:42:15                cast('STRING' as TEXT) as relation_column_type
11:42:15            union all
Relevant log output
No response
Environment
- OS: OSX
- Python: 3.9.13

Core:
  - installed: 1.2.1
  - latest:    1.2.1 - Up to date!

Plugins:
  - postgres: 1.2.1 - Up to date!
  - spark:    1.2.0 - Up to date!

Packages -
packages:
  - package: dbt-labs/spark_utils
    version: [">=0.3.0"]
  - package: dbt-labs/dbt_utils
    version: [">=0.9.2"]
  - package: calogica/dbt_expectations
    version: [">=0.6.1", "<0.7.0"]
  - package: calogica/dbt_date
    version: [ ">=0.6.0", "<0.7.0" ]
  - package: dbt-labs/dbt_external_tables
    version: [">=0.8.0"]

Which database adapter are you using with dbt?
other (mention it in "Additional Context")
Additional Context
Issue first raised with dbt-expectations who have pointed me in your direction.
https://github.com/calogica/dbt-expectations/issues/196
The following macro has fixed the issue for now.
{% macro spark__type_string() -%}
    STRING
{%- endmacro %}

Hey @pixie79 — thanks for opening, and glad you were able to find a functional workaround.
I'm not able to reproduce this using dbt-core + dbt-spark v1.2:
-- models/my_model.sql
select cast('a_string' as {{ type_string() }}) as my_col

$ dbt run

-- target/run/test/models/my_model.sql
create or replace view dbt_jcohen.my_model

  as
    select cast('a_string' as string) as my_col

Do you have other dbt packages installed (in packages.yml)? Or custom reimplementations of any other macros in your own project that might be relevant?
Explanation
Here's where the type_string() macro is defined in dbt-core:
https://github.com/dbt-labs/dbt-core/blob/b089a471b7121d02105f3bbca3046be12276d92d/core/dbt/include/global_project/macros/utils/data_types.sql#L1-L13
In the general case, this does return TEXT, because the default Column class in dbt-core translates STRING → TEXT (STRING isn't supported in PostgreSQL):
https://github.com/dbt-labs/dbt-core/blob/b089a471b7121d02105f3bbca3046be12276d92d/core/dbt/adapters/base/column.py#L10-L16
https://github.com/dbt-labs/dbt-core/blob/b089a471b7121d02105f3bbca3046be12276d92d/core/dbt/adapters/base/column.py#L23-L25
However, in dbt-spark we don't do any type translation — we just return the exact data type that's been passed in. The relevant code is here:
    @classmethod
    def translate_type(cls, dtype: str) -> str:
        return

So if "string" is what's passed in, "string" is also what you should be seeing on the other side — and what I see when I run this locally.


in ddev version 1.24 the plugin does not work for me

In a project that was working fine with database connections in Sqlsrv, I updated the ddev version to 1.24.1 and the add-on stopped working. I have reviewed all the configuration but I always got the message could not driver found. I have returned to version of ddev 1.23.5 and everything has worked normally again.
I am working in a local environment with wsl ubuntu 22.04 and laravel

Related Discord conversation: https://discord.com/channels/664580571770388500/1068592266752573440/1316758290176147537
@manuel-benavides, you'll need to provide more details to help us understand the issue, including the exact steps you're following and any error messages.
Do you have the latest add-on version ddev add-on list --installed? Also, have you made any custom changes to its configuration?
Try reproducing the problem by creating a new Laravel project, installing this add-on, and explaining what we need to do. (I'm not familiar with MSSQL.)

Also @manuel-benavides if you would be so kind as to attach the output of ddev debug test, and say whether you did what I suggested in Discord, (https://discord.com/channels/664580571770388500/1316758290176147537/1316775311987179595) -
ddev ssh
sqlcmd -S sqlsrv -U sa -P "Password12!"
>

Hello everyone;
I have installed a project from scratch with Laravel mysql and sqlsrv and everything works correctly. I have installed everything with ddev version 1.24.
Perdon por mi ignorancia

Glad it worked for you!


Fling Magic missing item?

Hi, I'm probably overlooking something, but I created a new character for one of my players. When trying to execute the Fling Magic macro (from wand implement) I keep getting the message that the actor is missing an item [ID KPmj8dZpcuD1EG
f]. I tried to manage implement and selecting an item as the wand implement, holding it in a hand, assigning the actor to a player. All no effect. What am I doing wrong?

That's not my error, I don't have the wand implement implemented into the module yet.


Add alert when delete transaction.

Please pay attention to the case when several transactions will be deleted. In this case, you must specify TRANSACTIONS in the text.
https://app.zeplin.io/project/5ba9be48f029d520c456f395/screen/5cebaee2bff8802fafa3fb01

Checked

Also, need to add this alert when the user selects "Delete" transaction on the "Transaction details" screen.

Checked


Inconsistent Order by createdAt_ASC

Hi, I just found out that there are some issues with ordering with our query.

Is there a way to get consistent order to our query?
Can the query be told to purge some specific ID?

 claim 10 drops   trigger update metadata

id,name,blockNumber
379-2404223588,MEADOW,6750520
379-2404238914,MEADOW,6750520
379-2404144915,MEADOW #150,6750520
379-2404257488,MEADOW #151,6750520
379-2404267204,MEADOW #152,6750520
379-2404270139,MEADOW #155,6750520
379-2404285152,MEADOW #147,6750520
379-2404387843,MEADOW #149,6750520
379-2404624504,MEADOW #153,6750520
379-2404630981,MEADOW #148,6750520

id,name,blockNumber
379-2404144915,MEADOW #150,6750520
379-2404257488,MEADOW #151,6750520
379-2404270139,MEADOW #155,6750520
379-2404285152,MEADOW #147,6750520
379-2404387843,MEADOW #149,6750520
379-2404624504,MEADOW #153,6750520
379-2404630981,MEADOW #148,6750520
379-2404223588,MEADOW #147,6750520
379-2404238914,MEADOW #148,6750520
379-2404267204,MEADOW #152,6750520

related: https://github.com/kodadot/nft-gallery/issues/10025

Can you please expand your thoughts please?

Hi Vik, the order from NFTs with the same block numbers is inconsistent.
while claiming the drops, this id<PHONE_NUMBER>588 is on index 146
then, I test it by updating the metadata for all of them. Then, the order was changed. This id<PHONE_NUMBER>588 was changed to index 147
The expected result is that<PHONE_NUMBER>588 is still on index 146. All of them should be the same before and after
Is there a way to make it consistent? Currently, the order is using "orderBy": ["createdAt_ASC"]

Can the query be told to purge some specific ID?

alternatively, is there a way to purge some data to query?

Hi Vik, the order from NFTs with the same block numbers is inconsistent.
while claiming the drops, this id<PHONE_NUMBER>588 is on index 146 then, I test it by updating the metadata for all of them. Then, the order was changed. This id<PHONE_NUMBER>588 was changed to index 147

Fixed for you in 44c9650

Can the query be told to purge some specific ID?
alternatively, is there a way to purge some data to query?

Still dont understand, sorry

Made update in #268, it should be much faster

Still dont understand, sorry

something like hit our query endpoint (mutation graphql), then the query will reindex the item again

Made update in #268, it should be much faster

thank you

something like hit our query endpoint (mutation graphql), then the query will reindex the item again

Well, I can do that either manually or reindex

any idea why indexer return wrong metadata. I'm trying to update metadata on ahk: https://assethub-kusama.subscan.io/extrinsic/6751672-2
the metadata return #153: https://fxart-beta.kodadot.workers.dev/metadata/v1/json?chain=ahk&collection=379&nft=2404285152&metadata=ipfs:%2F%2Fbafybeihutexevnef7j4msobm5v5uczx2mempxeixihnbgrmpwqogzcbtzm%2F0.json
but, on indexer always return #147: https://kodadot.xyz/ahk/gallery/379-2404285152

oohh, I mean reindex but just for specific item only, not reindex all from the starts

#270
#271


latest package on pypi requires impossible napari

Not sure how this happened... since the setup.py here looks fine, but if you try to pip install, you get:
ERROR: No matching distribution found for napari[all]>=4.0.0

indeed... in the latest wheel at https://pypi.org/project/paintedlife/#files, in the .dist-info/METADATA file it says:
Requires-Dist: napari[all] (>=4.0.0)

the people need easy access to paintedlife! :joy:

Thanks for this @tlambert03! It should work now.
Dyslexia strikes again 🤦♀🤦♀🤦♀ 😂


New feature

Is it possible to add a setting for the number of columns displayed on the screen? On a widescreen screen, the current setup of three performers in a row looks extremely poor.


Remove Final-Energy variables added to common-definitions

fyi @phackstock

Good to be merged from my side. Glad that we have the automated consistency checks.

I also ran a comparison to make sure that I didn't inadvertently delete a variable...


Document Fields as a function

Example that goes along with #317

Closing. See: https://github.com/erikras/redux-form/pull/317


Spanish translation of acceptable files in templates

As per the guidelines, only files which are already translated into French can be translated into another language. There are currently two templates which have French translations.

overview.html
sponsors.html

Thanks for your input! And for accepting my previous PR (my first ever to an open solution) :smile:
I'll finish the remaining templates files mentioned above. Would you like the locales file translation included in this file or would you prefer a new branch?

I'll finish the remaining templates files mentioned above. Would you like the locales file translation included in this file or would you prefer a new branch?

When I work on the French version, I translate each page in a different PR. This way, it's easier to review and we can merge things while still working on the other pages. :)

@stanislas-m Sounds good. I'll stop pushing changes to this PR. Please consider it complete and ready for review. From now I'll create a separate branch and PR for each translated page.

@jmvbxx It looks great! added some comments for your consideration.

Thank you @stanislas-m .. Fixing with a new PR now.
On Wed, Sep 26, 2018 at 12:21 PM Stanislas Michalak <
<EMAIL_ADDRESS>wrote:

@jmvbxx https://github.com/jmvbxx I've merged the PR, but I forgot
something: sponsors.es.html is empty.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gobuffalo/gobuffalo/pull/335#issuecomment-424800303,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJryYzJRGMjb1w1OckYegFb9Xw2N-eNcks5ue7ewgaJpZM4W3tcQ
.


CompositionSurfaceBrush bizarre scaling behavior

I've been trying to create a tiled background brush using XamlCompositionBrushBase, CompositionDrawingSurface, CompositionSurfaceBrush and a CompositionEffectBrush with a BorderEffect to do the tiling. Now, this is all working well, except I had great difficulty in getting the borders of the tiles to be crisp. I had set CompositionSurfaceBrush.Stretch to None, so I expected it to map pixels in the drawing surface directly to display pixels. However, I eventually realised this is not the case. It turns out that if you don't want the surface to be scaled, then you have to set the Scale property (!) of the surface brush to 1/DisplayInformation.GetForCurrentView().RawPixelsPerViewPixel. This was very counter-intuitive to me. I guess this behavior is OK, but maybe could you update the docs to make it clear?

@benstevens48 Thank you for the feedback. Can you please share the documentation link where you think this information would be useful to update ?

Probably in the remarks on this page - https://docs.microsoft.com/en-us/uwp/api/windows.ui.composition.compositionsurfacebrush, plus maybe on the scale property page - https://docs.microsoft.com/en-us/uwp/api/windows.ui.composition.compositionsurfacebrush.scale#Windows_UI_Composition_CompositionSurfaceBrush_Scale.

This is, fwiw, the default scaling behaviour of nearly everything in XAML - it's all in device independent pixels that deals with DPI differences for you, so generally shouldn't be that unexpected in regards to the rest of the framework - so I think it's assumed everywhere in the documentation that mentions pixels and scaling that it's all in device-independent pixels, and not raw pixels unless explicitly stated.

This case is a bit different though. After you've drawn to the composition surface, that is effectively a bitmap. I can't imagine a case, having set stretch = none, where you would want the bitmap to be scaled to cover more display pixels than the number of pixels in the surface by default, so that it ends up blurred. Presumably you did some drawing on the surface and you would want it to remain crisp. Having said this, I think the behavior of setting image.stretch  to none is the same, as far as I remember, so I suppose at least it's consistent even though it doesn't really make sense.

Perhaps, but this is the same for all bitmaps in XAML  - the expectation being that the end result still looks visually the same if you change the system DPI which is important for a lot of UI design, rather than bitmap assets staying the same and the rest of XAML scaling up leading to unexpected size differences - especially strange if you're using bitmap assets for icons and UI flourishes. (And of course images and photos in general)
Ideally what you should be doing is what is recommended here: https://docs.microsoft.com/en-us/windows/uwp/app-resources/images-tailored-for-scale-theme-contrast
Using tailored image assets for different DPI sizes.

@JohnnyWestlake If I'm not mistaken bitmaps generally carry a resolution with them which is respected, composition surfaces being fixed to 96 DPI and you having to set the scale transformation as workaround seems odd to me and certainly worth documenting.

@JohnnyWestlake - I guess maybe it does make sense for images, especially where they are available as assets at build time. In this case it's true you'd probably expect them to take up the same space independent of the system DPI. The scale asset naming convention can be used the ensure sharpness, but only if you are loading an image from assets using a URI source.
The case here of drawing to a surface created at runtime is quite different. I guess I can live with the existing behavior for consistency, but it should be clearly documented how to scale the surface in such a way that you get crisp results, because naively using the default scaling will result in blurred drawings.
@weltkante - technically it's true that Direct2D bitmaps can be given a DPI, but if you load bitmaps from a file then by default the Direct2D bitmap will be given a DPI of 96 by most of the APIs relating to loading from a file - any DPI information in the file is ignored (and this is a good thing because it is generally arbitrary, is difficult to set, and it would be annoying to have to compensate for it).

@duncanmacmichael Per our offline discussion, please take a look.

Were the docs ever updated to explain the behaviour (specifically how to create a drawing that is crisp on non 100% display scales)?


RequestOptions Missing onSendProgress Funtion

I see your RequestOptions miss onSendProgress so I can't receive any Progress when post file! Need Hot Fix that!!! Please!!!!!

RequestOptions({     String method,     int connectTimeout,     int sendTimeout,     int receiveTimeout,     Iterable<Cookie> cookies,     this.data,     this.path,     this.queryParameters,     this.baseUrl,     this.onReceiveProgress, // this is your issue where is onSendProgress     this.cancelToken,     Map<String, dynamic> extra,     Map<String, dynamic> headers,     ResponseType responseType,     ContentType contentType,     ValidateStatus validateStatus,     bool receiveDataWhenStatusError = true,     bool followRedirects = true,     int maxRedirects,     RequestEncoder requestEncoder,     ResponseDecoder responseDecoder,   }  it have onReceiveProgress but don't have onSendProgress


[BUG][BACKPORT][v1.2.4] Longhorn manager NPE due to the nil engine during the backup creation

#3484

Validation - PASSED
Tested with test_backup_npe function hinted in the new doc:

Validation - PASSED
Tested longhorn v1.2.x-head(b5927573) on v1.22.5+k3s1 cluster with test_backup_npe function hinted in the new doc:
root@longhorn-test:/integration/tests# bash run.sh test_npe.py
+ flake8
+ pytest -v test_npe.py
========================================================================================= test session starts =========================================================================================
platform linux -- Python 3.9.9, pytest-5.3.1, py-1.11.0, pluggy-0.13.1 -- /usr/local/bin/python
cachedir: .pytest_cache
rootdir: /integration, inifile: pytest.ini
plugins: repeat-0.9.1
collected 2 items

test_npe.py::test_backup_npe[s3] PASSED                                                                                [ 50%]
test_npe.py::test_backup_npe[nfs] PASSED                                                                                [100%]

==================================================================================== 2 passed in 334.48s (0:05:34) ====================================================================================

More context please refer to this comment: https://github.com/longhorn/longhorn/issues/3484#issuecomment-1014195698


pplx-ai is conveniently OpenAI client-compatible

What is the Only writers can set a specific model?
I use pplx-aiI, my .env.local file is as follows:
# Used to set the base URL path for OpenAI API requests.
# If you need to set a BASE URL, uncomment and set the following:
# OPENAI_API_BASE=

# Used to set the model for OpenAI API requests.
# If not set, the default is gpt-4-turbo.
# OPENAI_API_MODEL='gpt-4-turbo'

# OpenAI API key retrieved here: https://platform.openai.com/api-keys
# OPENAI_API_KEY=

# Tavily API Key retrieved here: https://app.tavily.com/home
# TAVILY_API_KEY=

# Only writers can set a specific model. It must be compatible with the OpenAI API.
USE_SPECIFIC_API_FOR_WRITER=true
SPECIFIC_API_BASE=https://api.perplexity.ai
SPECIFIC_API_KEY=pplx-xxx
SPECIFIC_API_MODEL=sonar-small-online

Error Message: unhandledRejection: LoadAPIKeyError [AI_LoadAPIKeyError]: OpenAI API key is missing. Pass it using the 'apiKey' parameter or the OPENAI_API_KEY environment variable.

OPENAI_API_KEY and TAVILY_API_KEY are not optional values. If they are not set, an error will occur.
https://github.com/miurla/morphic?tab=readme-ov-file#3-fill-out-secrets
Please refer to the Note.

Note: This project focuses on Generative UI and requires complex output from LLMs. Currently, it's assumed that the official OpenAI models will be used. Although it's possible to set up other models, if you use an OpenAI-compatible model, but we don't guarantee that it'll work.
https://github.com/miurla/morphic?tab=readme-ov-file#3-fill-out-secrets

If pplx-ai is used, it needs to be set only for the Writer agent.
Reference: https://github.com/miurla/morphic/issues/36


DUOS-1292[risk=no] Chair Console: Update for DAR Collection

Addresses DUOS-1292
PR adds the Vote, Open, and Cancel buttons to the Chair Collection table for the Chair Console (on the new_chair_console route).
Have you read Terra's Contributing Guide lately? If not, do that first.

Label PR with a Jira ticket number and include a link to the ticket
Label PR with a security risk modifier [no, low, medium, high]
PR describes scope of changes
Get a minimum of one thumbs worth of review, preferably two if enough team members are available
Get PO sign-off for all non-trivial UI or workflow changes
Verify all tests go green
Test this change deployed correctly and works on dev environment after deployment

PR looks good and I observed the correct behavior on the chair console.
The Vote button was displayed for me for new DARs that were submitted. I was only shown an Update button after submitting votes. The review_results page is linked when I click on the status including Denied, Approved, and Unreviewed. When an election is still open, there is no link but I think that makes sense because there wouldn;t even be a review page for that DAR, right?

I think you visited the current Chair Console. The PR makes a new_chair_console page to show off the new Chair Console. The PR's primarily the table styling, the new table, and the updated chair actions (Though the linkable status is a good idea).

Code changes look good to me. The new_chair_console page also looks good - I saw the Open, Vote, and Cancel buttons present where they should be. One difference I noticed though was that I have a certain DAC id: 439 (DAR-506) that has the "Update Vote" and "Cancel" options on the old chair_console but only has "Vote" and "Cancel" options on the new_console_chair page.
When I click on "Vote" option on the new_chair_console, it errors out:

Looks like that bug is happening on the DarCollectionReview component, not the console. Can you file this as a bug ticket outlining what happens and how to recreate the bug?


Feature: push devlogs

As mentioned in itchio/itch.io#677, it would be nice to be able to push a devlog from butler.
I'm imagining something similar to how git does commit messages, though I am curious if @charliesgames has a different idea.

That was pretty much what i was thinking.

I agree this would be a great addition to butler, but is this even possible with the itch.io API? (i'm looking for some doc on the matter)

No, there is no API support for doing this at the moment.

Alright, fair enough. Is this something the team would like to add at some point or is this totally out of scope ?
Also, sorry for reopening an old issue, didn't see it was from 2018.


[BUG] Birthday displaying incorrectly on the website

Describe the bug
When I enter 3/29/1991 as birthday, the resume shows 03/28/1991 (off by 1 day)

Product Flavor

[x] Managed (https://rxresu.me)
[ ] Self Hosted

To Reproduce

create a new resume on the website
type in 03/29/1991 for birthday
see in preview that the date is wrong

Expected behavior
date should be correct
Screenshots

Desktop (please complete the following information):

OS: windows 11
Browser chrome
Version webpage

Additional context

Seems as if all dates are off by 1. I was adding education and it was failing as well


Update to 1.0.0-RC2 triggers 'assertion failed: asTerm called on not-a-Term val '

Version(s)
1.0.0-RC2
Describe the bug
After upgrading to 1.0.0-RC2 the script below fails to compile with the following error:
Error: Unexpected error when compiling project_8be8567734-de847ff703: 'assertion failed: asTerm called on not-a-Term val <none>'

System: Tried Ubuntu 23.04 and 22.04 so far
To Reproduce
//> using scala "3.2.2"
//> using jvm "17"
//> using lib "com.github.alexarchambault::case-app:2.1.0-M24"

import caseapp._

case class Options(
  domain: String = "development"
)

object BuildAndRegister extends CaseApp[Options] {
  override def run(options: Options, remainingArgs: RemainingArgs): Unit = {}
}

scala-cli compile script.sc

Note that the bug only appears to occur on Scala 3 in combination with a script:
scala-cli --cli-version 1.0.0-RC2 compile script.sc # error
scala-cli --cli-version 1.0.0-RC1 compile           # works
scala-cli compile --scala-version 2.13              # also works

mv script.sc script.scala
scala-cli compile script.sc # works

Also, if we remove the default arg in the options case class, it also works again:
case class Options(
-  domain: String = "development"
+ domain: String
)

I haven't been able to minimize the example further yet.
One hunch is that the new class based wrapping triggers something here as it happens only in scripts.
Expected behaviour
The script should compile like in earlier versions.

A new flag and using directive were added for forcing the object wrapper in scripts. You can use --object-wrapper or using objectWrapper as a workaround for the mentioned problem.

Thanks for letting me know @MaciejG604


Make Azul Zulu JDK the default JDK when available

This PR changes the default JDK installed by the buildpack from a custom build OpenJDK to the certified Azul Zulu JDK when the specified version is available.
For example, the following system.properties configuration will install Zulu 8u144:
java.runtime.version=1.8.0_144

The following configuration will also install Zulu 8u144:
java.runtime.version=zulu-1.8.0_144

But this configuration will install the custom built OpenJDK 8u144 (the old default):
java.runtime.version=openjdk-1.8.0_144

If no Zulu binary is available for the version specified, the buildpack will install the custom built OpenJDK for that version.

This little change broke our prod because of cryptography extensions. I have no idea why anyone thought this should become the default behavior without even announcing it to the heroku changelog, but whoever they are should know this was a seriously breaking change to try to slide under the radar.

@pettyjamesm i'm very sorry this caused you problems. Can you provide some more detail regarding the cryptography extensions? What error were you getting, and what extensions were missing?
The Github master branch of the buildpack is consider "in development". We don't post changelog entries for changes introduced here because they have not yet been released. If you want a more stable version of the buildpack please use heroku/jvm. You can set this by running heroku buildpacks:set heroku/jvm.
Again, I'm very sorry, but I'd love to know more about your issues to we can make the Zulu JDK a better option. Thanks.

We use 256bit AES GCM for certain operations within our application which requires having the unlimited strength JCE patch installed in the Oracle jdk but is available by default in openjdk. I'm not familiar with using Zulu, but the observed behavior was as if the JCE was not present (invalid key length exception).
Do you have a rationale for why Zulu is replacing openjdk as the default?

@pettyjamesm thanks for the details! I can confirm that Zulu does not have the TLS_*_AES_256_GCM ciphers by running SSLSocketFactory.getSupportedCipherSuites(), which is I believe causing the problem you describe. I definitely consider this a blocker for switching to Zulu. But I think we can get parity between openjdk and zulu by installing the unlimited strength JCE. In fact, I'm going to talk to the folks at Azul to find out why it doesn't ship with it by default.
The primary motivation for switching to Zulu JDK is that it is TCK certified, which makes it a better option than the custom built OpenJDK we have been using by default. With the exception of JCE, they are essentially the same.
Even with Zulu as the default, however, we will still provide the option of putting java.runtime.version=openjdk-1.8.0_144 (or whatever version) in your `system.properties.
I would love your feedback on this? Do you hate it? Do you think our other customers will hate it? I truly believe that Zulu is the better option, but I must make sure we're giving customers what they want.

I'm reverting this until I can correct the JCE issue #37

@jkutner having never used Zulu before, I can't say I'm against it so much as I think it's an odd choice to use as a default.
I'm not sure how custom the OpenJDK version currently being shipped is, but I suspect the majority of users don't really care about the TCK but expect a JVM that works pretty much like their local development JDK (probably Oracle). People concerned with TCK compliance can of course opt-in, but I doubt it's especially important.


Cannot install tensorrt_llm

System Info

I use image nvidia/cuda   12.1.0-devel-ubuntu22.04 from docker pull
Who can help?
No response
Information

[X] The official example scripts
[ ] My own modified scripts

Tasks

[ ] An officially supported task in the examples folder (such as GLUE/SQuAD, ...)
[ ] My own task or dataset (give details below)

Reproduction
Obtain and start the basic docker image environment.
docker run --rm --runtime=nvidia --gpus all --volume ${PWD}:/TensorRT-LLM --entrypoint /bin/bash -it --workdir /TensorRT-LLM nvidia/cuda:12.1.0-devel-ubuntu22.04
Install dependencies, TensorRT-LLM requires Python 3.10
apt-get update && apt-get -y install python3.10 python3-pip openmpi-bin libopenmpi-dev
Install the stable version (corresponding to the cloned branch) of TensorRT-LLM.
pip3 install tensorrt_llm==0.8.0 -U --extra-index-url https://pypi.nvidia.com
Expected behavior
install success
actual behavior
like image
additional notes
no

did you try: nvidia/cuda:12.4.0-devel-ubuntu22.04 ?

I have verified that these commands work
docker run --rm --runtime=nvidia --gpus all --shm-size 25g \
  --entrypoint /bin/bash -it nvidia/cuda:12.4.0-devel-ubuntu22.04

sudo apt-get update && sudo apt-get -y install python3.10 python3-pip openmpi-bin libopenmpi-dev git git-lfs

pip3 install tensorrt-llm==0.11.0.dev2024062500 -U --pre --extra-index-url https://pypi.nvidia.com

Could you take a try?


operators [N] gitops-primer (0.0.1)

Signed-off-by: Jason Montleon<EMAIL_ADDRESS>Updates to existing Operators

[X] Did you create a ci.yaml file according to the update instructions?
[X] Is your new CSV pointing to the previous version with the replaces property if you chose replaces-mode via the updateGraph property in ci.yaml?
[X] Is your new CSV referenced in the appropriate channel defined in the package.yaml or annotations.yaml ?
[X] Have you tested an update to your Operator when deployed via OLM?
[X] Is your submission signed?

Your submission should not

[X] Modify more than one operator
[X] Modify an Operator you don't own
[X] Rename an operator - please remove and add with a different name instead
[X] Modify any files outside the above mentioned folders
[X] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[X] Description about the managed Application and where to find more information
[X] Features and capabilities of your Operator and how to use it
[X] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[X] Human readable name and 1-liner description about your Operator
[X] Valid category name1
[X] One of the pre-defined capability levels2
[X] Links to the maintainer, source code and documentation
[X] Example templates for all Custom Resource Definitions intended to be used
[X] A quadratic logo

Remember that you can preview your CSV here.

@rayfordj can you take a look, please. These should match the changes to the gitops-primer repo I made last night.

/merge possible


HealthKit.requestAuthorization works once only

Hi,
I believe there is a bug when calling HealthKit.requestAuthorization([]) where the requestAuth modal only shows once when the app is running?
Steps to reproduce are as follows:

Currently calling await HealthKit.authorizationStatusFor(HKCategoryTypeIdentifier.sleepAnalysis) to check if we have access to sleepAnalysis
This is returning as 0 (false)
We then check HealthKit.isHealthDataAvailable() which is true.
We then render the request UI via await HealthKit.requestAuthorization([HKCategoryTypeIdentifier.sleepAnalysis])
In the first instance, this shows.
Image if use doesn't give permission and doesn't click Don't Allow. User kills app.
User re-opens app and the above logic runs but the HealthKit.requestAuthorization doesn't render the UI

Any thoughts on working around this?

I'm fairly certain what you're describing is working as intended (by Apple that is). A few things that might help:

Apple only lets apps present the dialog once per type of data. So it's probably a good idea to prepare the user before presenting the dialog.
There is no way to tell if a user denied the app access to reading data - you will simply receive no data.
isHealthDataAvailable is for indicating whether the device supports health data, as per Apples docs

I'm fairly certain what you're describing is working as intended (by Apple that is). A few things that might help:

Apple only lets apps present the dialog once per type of data. So it's probably a good idea to prepare the user before presenting the dialog.
There is no way to tell if a user denied the app access to reading data - you will simply receive no data.
isHealthDataAvailable is for indicating whether the device supports health data, as per Apples docs

Thanks @robertherber. Regardless of the scenario I mentioned above, I'm also finding also that if the user granted access in current version of out app and then if we then released a newer version of the app then HealthKit.authorizationStatusFor(HKCategoryTypeIdentifier.sleepAnalysis) is false and so when we try and present the modal again, the modal doesn't show.
The only workaround that works is that we need to ask users to uninstall the app and then re-open and then the modal appears.

@pratikdhody Yes, this is the same behaviour for any iOS app regarding showing the permission UI. You can only show it once per type of health data, that's it.
As for the authorizationStatusFor there is some discussion going on in #61 on whether it's reporting the correct value currently. I haven't had time to dig into it yet.
I'd recommend using getRequestStatusForAuthorization instead since it directly indicates whether you can/should ask the user for permissions (shouldRequest) or if you should just go ahead. This is what is exposed by Apple.


Fixes various small things

Updates typescript compiler to use paths to handle package linking
(better for live reload)

Updates the Application in GameManager to use the window's
devicePixelRatio to prevent gaps between sprites (this is a problem
when creating a map with 32x32 pixels)

amended commit to also:

Adds AutoDensity so rendering works the same with the native
devicePixelRatio
Fixes circle clamping - you could clip out of the left end of the map
and couldn't reach the far right.

@LukeWood Thank you for your PR, I've been quite busy lately and sadly didn't get the chance to work on the project as I had expected, but I'll test and merge it this weekend if everything is good 👍. There is something I need to check on yarn workspaces first and packages linking.

sounds good!  Don't sweat it no rush.
I am not using your deployment stuff actually so I very well may have broken that without realizing.
Thanks again for publishing tosios - it really helped me kick start my game :).

p.s. - linked you in my credits :). https://tp-scramble.io/credits. t

@LukeWood Thanks for quoting me in your credits! Concerning your changes, I have actually refactored the whole configuration for workspaces, TypeScript and eslint. So now the paths and reload work especially well! Thanks for your first insights which gave me motivation to do this refactor (along other things). It will be shipped in 0.12.0


Does not display buckets with non-ASCII characters in names

After successful login i get the Exception in terminal window:
Exception in thread Thread-1:
Traceback (most recent call last):
  File "threading.py", line 801, in __bootstrap_inner
  File "threading.py", line 754, in run
  File "storj-gui-client\UI\mainUI.py", line 216, in initialize_bucket_select_combobox
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-9: ordinal not in range(128)

Exception in thread Thread-2:
Traceback (most recent call last):
  File "threading.py", line 801, in __bootstrap_inner
  File "threading.py", line 754, in run
  File "storj-gui-client\UI\mainUI.py", line 174, in update_files_list
IndexError: list index out of range

main-newest is running and work some way :)

Yes, some progress, but still unfisished, probably tomorrow will be done :) Also please check bucket select list in file upload dialog - there should be good, but please give me a feedback

nope, is not good :)

Oh, strange, so It probably will be fixed tomorrow :) Thanks for reporting :)

You're welcome

Fixed in branch develop, binaries will be soon

now it's showing :)


Add paginator support for SSM Client Executions and ExecutionTargets

Adds paginator data for DescribeAssociationExecutions and DescribeAssociationExecutionTargets

Codecov Report

Merging #1631 into develop will increase coverage by 0.03%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop    #1631      +/-   ##
===========================================
+ Coverage     92.2%   92.23%   +0.03%
===========================================
  Files           52       52
  Lines         9592     9592
===========================================
+ Hits          8844     8847       +3
+ Misses         748      745       -3

Impacted Files
Coverage Δ

botocore/credentials.py
98.82% <0%> (+0.39%)
:arrow_up:

Continue to review full report at Codecov.

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


Number of users remains fixed at one value

Hi guys,
This is regarding the MWP. We just fully launched today! Woohoo! However, the number of users working on our project seems to be static at 129. Could you look into this if it's possible?
https://www.zooniverse.org/projects/povich/milky-way-project
Thank you so much!
Best,
Tharindu

#1982 might solve this when it gets deployed later today.

Thanks guys! This fixed the problem 👍


⚠ Bofrost.nl has degraded performance

In 1829f58, Bofrost.nl (https://www.bofrost.nl) experienced degraded performance:

HTTP code: 200
Response time: 911 ms

Resolved: Bofrost.nl performance has improved in 459265b.


PSR-0 autoload screwed

Hi guys,
I'm currently using 73078a3dc3c16dc3ba56575d9378ec206e1991af as a vendor in my project.
After running composer dump, my generated autoload_files.php looks like this:
<?php

// autoload_files.php @generated by Composer

$vendorDir = dirname(dirname(__FILE__));
$baseDir = dirname($vendorDir);

return array(
    '0315ef56cc9493664bd73459cd8f4e6b' => $vendorDir . '/picocms/pico/lib/pico.php',
);

As you can see, I'm missing autoload entries for https://github.com/picocms/Pico/blob/master/composer.json#L36-L39, aka AbstractPicoPlugin and PicoPluginInterface...
Any ideas ?

Nevermind, issue with my composer cache.


Tiny typo fix in daemon-reload command

Just corrects the daemon-reload command. Saves a question here or on telegram for somebody new to *nux.

Thanks for the update


util: throw if file has !digit characters

Throw if file has non-numeric data, in addition to hinting the path that caused the error.
Fixes: #304, https://github.com/prometheus/node_exporter/issues/1710

Wrong remote. ;)


Call the notification executable only on actual Jabber Messages

Currently it also gets called if anything appears in the feed of my own jabber id, e. g. changing statuses, authorization requests, jackline startup message(s) etc.
This is pretty confusing to me.

If you could give me some hints I could try to look into this myself.

the callout is here, which is triggered by any event (via a mailbox var) (git grep state_mvar shows all the producers of events, mainly notify in cli/cli_state.ml, which is called in cli/cli_commands.ml by various callbacks form src/xmpp_callbacks).
I actually think that authorization requests are worth notifying.. not sure about the reconnects and other messages... if someone changes a status, there shouldn't be a notification (I also filter in my shell script for if [ $2 != "connected" ]; then alarm me; fi)

Mhhh but if you pass the script the event type as argument, I'd say that is rather a feature™ because there's a wider range of possibilities.

while $2 could be more fine-grained, I'm closing this for now... someone should write a proposal (in form of documentation and a PR) what $2 can be

+1


module 'spateo.align' has no attribute 'group_pca'

st.align.group_pca(X_input, pca_key='X_pca')
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
Cell In[14], line 1
----> 1 st.align.group_pca(X_input, pca_key='X_pca')

AttributeError: module 'spateo.align' has no attribute 'group_pca'

Hi, thank you for your interest in our work! We are still organizing the code and have recently made some updates, adding a few helper functions. Please check and update the code. In the latest version, the group_pca function should be included.


Fix test timeout after 1h

In https://github.com/knative-sandbox/eventing-kafka-broker/pull/694/checks?check_run_id=2022472233
we got panic: test timed out after 1h0m0s

Proposed Changes

Increase timeout for KinD e2e tests

Some tests run longer than 1hr?! :fearful:

Yep, that sometimes happens.

/test pull-knative-sandbox-eventing-kafka-broker-integration-tests

/retest

/test pull-knative-sandbox-eventing-kafka-broker-integration-tests


Web responsive/landing page

Description
Making the Landing page responsive at 320px width Small phone.
Type of change
Please delete options that are not relevant.

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

Change Status

[ ] Complete, tested, ready to review and merge
[ ] Complete, but not tested (may need new tests)
[x] Incomplete/work-in-progress, PR is for discussion/feedback

Has This Been Tested?

[ ] Yes

[ ] What was tested?

[ ] No

Checklist

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] My code has been reviewed and commented by at least two peers
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] There are no merge conflicts

Note: Although we are using less files, the project doesn't have less installed neither it is set up to compile.

I still need to work on the bottom section and footer, do not merge this PR


Disable Baby Piglin

Hello, i need your help guys.
Is it possible in Multiverse Core to disable just the baby piglins so that only the adults spawn?

You can try set monster black list for it. https://github.com/Multiverse/Multiverse-Core/wiki/World-properties#monsters

I already blacklisted piglins but i still get the baby piglins but i just want the adults to spawn

Can you send your full startup log, found in logs/latest.log via https://hastebin.com/ and send link generated from /mvversion -p


querystring parameter example update #69

Great work Vitaly on this component, it's been a real help!
What are your plans with respects to new releases, any planned in the next couple of weeks as I could do with this feature:
https://github.com/vitalybibikov/AzureExtensions.Swashbuckle/pull/69
I know I can do a build myself but I'd like to use official released builds, if possible.
Regards
Steve

Sorry for the wait, I released it just now => https://www.nuget.org/packages/AzureExtensions.Swashbuckle/3.3.2

@YARG I'm closing it now, please open a new one if any questions arise

Thanks for this, great news!


[Feedback]  Shorten the goal by Betty

Feedback details
ID: 358 | created at 2023-05-11T10:23:29 | feedback type: feedback-addFeedback
Message 1 from user fde39bdf-3c15-47fc-9688-b68167a9982b
Selected text
Goal
Introductions, explore expectations, set ground rules and discuss roles of the facilitator.
User feedback
Shorten the goal by Betty
Template target
[{"el": "container", "templatename": "session_overview"}, {"el": "component", "name": "goals", "type": "display_group"}]

Revise the goals to 'Introductions and Expectations'

Closed as it was testing


Deploying eshop fails with naming problem

🔥 Bug Description
Error from server (Invalid): error when creating "C:\\dev\\git\\eShop\\src\\eShop.AppHost\\aspirate-output": ConfigMap "EventBus-env" is invalid: metadata.name: Invalid value: "EventBus-env": a lowercase RFC 1123 subdomain must consist of lower case alphanumeric
characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')
Error from server (Invalid): error when creating "C:\\dev\\git\\eShop\\src\\eShop.AppHost\\aspirate-output": Deployment.apps "EventBus" is invalid: [metadata.name: Invalid value: "EventBus": a lowercase RFC 1123 subdomain must consist of lower case alphanumeric
characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*'), spec.template.spec.containers[0].name: Invalid value: "EventBus": a
lowercase RFC 1123 label must consist of lower case alphanumeric characters or '-', and must start and end with an alphanumeric character (e.g. 'my-name',  or '123-abc', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?'), spec.template.spec.containers[
0].envFrom[0].configMapRef.name: Invalid value: "EventBus-env": a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[
a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')]
Failed to deploy manifests in 'C:\dev\git\eShop\src\eShop.AppHost\aspirate-output'

See https://github.com/dotnet/eShop/compare/davidfowl/aspirate?expand=1
🔍 Steps to Reproduce the Bug
Run aspirate generate on the apphost
🧯 Possible Solution
Making sure resource names safely translate to k8s friendly names

Thanks David. I'll get it fixed tonight
I had a similar issue with image names I had to fix the other day as upper case registry isn't allowed either.
I'll introduce some normalisation post parse of the manifest that way we can cover everything at the same time.


Sidebar text is grey

I cannot find the CSS element that controls the color of text for the sidebar. Please advise.

https://github.com/widget-/slack-black-theme/issues/21#issuecomment-342551435 solves this issue. Needed in addition to readme code.


React 17 Support

Updated react peerDependencies in package.json.
Updated react-native peerDependencies in package.json.
Updated @types/react-native devDependencies in package.json.
Updated metro-react-native-babel-preset devDependencies in package.json.

@karthick3018 @Dmitry-GH  @topmaster716 Can you guys look at this pull request?


feat: gateway preparation

What ❔

adds new fields to DB tables and rust structs
adds new config variables
update commitment generator to work with post-gateway
adds new vm subversion (vm fast is not changed yet)

Why ❔
prepare for gateway, reduce sync-layer-stable diff
Checklist

[ ] PR title corresponds to the body of PR (we generate changelog entries from PRs).
[ ] Tests for the changes have been added / updated.
[ ] Documentation comments have been added / updated.
[ ] Code has been formatted via zk_supervisor fmt and zk_supervisor lint.

Not going to lie, the current PubdataBuilder design looks overly complicated, and in some aspects worse than the ad-hoc design during the last review. I think it could be salvaged though; see line comments.

I agree but the previous version was rather naive. I'm trying to find some spot between "keep it as simple as possible and delay dealing with complexity till we need first custom builder" and "implement complex solution that fully allows custom pubdata"


Does cog support multiple Path input? e.g. List[Path] as input?

  File "/root/.pyenv/versions/3.9.18/lib/python3.9/site-packages/cog/predictor.py", line 239, in get_input_type
    raise TypeError(
TypeError: Unsupported input type list for parameter `model_faces`. Supported input types are: str, int, float, bool, cog.File, cog.Path.

ⅹ Failed to get type signature: exit status 1

I got error as above when I try to build the below Predictor(...)
def predict(
        self,
        target_image: Path = Input(
            description="Faces in target image would be changed.",
        ),
        model_faces: list[Path] = Input(
            description="Model Faces would be swapped into target image.",
            default=None,
        ),
        inference_mode: str = Input(
            default="swap",
            choices=["swap", "detect"],
            description="Face swap mode or detection mode. Default is swap.",
        ),
    ) -> Union[List[tuple], List[Path]]:
        """Run a single prediction on the model"""

Does cog support a List of Path as input in any method? In my scenario, I wish to make multiple faces processing in one HTTP API calling instead of 6-7 times HTTP latency.

Which cog version are you using? You may have more luck with one of the 0.9 beta's, which support list and union inputs.

@yorickvP how do you use that?

Which cog version are you using? You may have more luck with one of the 0.9 beta's, which support list and union inputs.

0.8.3. I am going to upgrade cog to 0.9 beta. Thank you.😄

@peter65374 @yorickvP it didn't work for me...
Version: 0.9.0b9
TypeError: Unsupported input type typing.List for parameter `liked_images`. Supported input types are: str, int, float, bool, cog.File, cog.Path.
ⅹ Failed to get container status: exit status 1

TypeError: Unsupported input type list for parameter `liked_images`. Supported input types are: str, int, float, bool, cog.File, cog.Path.
ⅹ Failed to get container status: exit status 1

I'm also running into this, but I swear it was working yesterday...

This should work
❯ sudo curl -o /usr/local/bin/cog -L "https://github.com/replicate/cog/releases/download/v0.9.0-beta11/default.cog_darwin_arm64"

@jonhilgart22
sudo cog predict -i prompt='mona lisa eating ice cream' -i seed=4 -i<EMAIL_ADDRESS>-i auto_depth=True -i ddim_steps=28
/usr/local/bin/cog: 1: Syntax error: "(" unexpected

That's weird. Looks like something installed wrongly. The official instructions are as follows:
sudo curl -o /usr/local/bin/cog -L "https://github.com/replicate/cog/releases/latest/download/cog_$(uname -s)_$(uname -m)"
sudo chmod +x /usr/local/bin/cog

Alternatively, try sudo rm /usr/local/bin/cog; brew install cog


Refactored build-script-impl in for cross-compiling support

What's in this pull request?

In the current build-script-impl, we use the variable name "deployment_target" pretty loosely when talking about the Build, Host and Target of the products we're building. You can see this in places - like where the test phase iterates every STDLIB_DEPLOYMENT_TARGET (i.e. Target), before skipping those which are not, effectively, host platforms, so we're tripping up on all these types of "deployment targets" floating around.
I'm aware the build script is being rewritten in python. The rewrite is approaching the stage where it's going to be getting to some of the points I've addressed here (e.g. calculating stdlib targets), so I think it's a good idea if we get this done first, so the python implementation can consider it from the start.
This PR replaces uses of "deployment_target" with "host" when talking about a platform which will ultimately host a Swift compiler. The Build platform is implicitly a Host. It replaces uses of "deployment_target" with "stdlib_target" when talking about a platform for which the stdlib is to be built. This terminology is consistent with the actual swift/llvm build process: llvm_host_triple, SWIFT_HOST_VARIANT_* and host-related flags get set set_build_options_for_host instead of set_deployment_target_options, and SWIFT_STDLIB_TARGETS calculation has been moved to a function - calculate_targets_for_host.

SWIFT_STDLIB_TARGETS now gets recalculated for each host we build, as it should.
Executables are always searched for in the LOCAL_HOST (Build machine) products
Some switching on 'uname' with switches on the host, in support of future cross-compiling
Removed lipo step (it lipos stuff between hosts, which doesn't make sense - possibly a result of confused terminology again?)

Note: The diff is large because of things like moving the stdlib target calculation in to a function and relocating it to be close to the function which sets the host options. The actual changes are not that extreme, and really limited to some variable renaming, function encapsulation and moving.

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    OS X platform               | @swift-ci Please test OS X platform
    Linux platform              | @swift-ci Please test Linux platform

Note: Only members of the Apple organization can trigger swift-ci.

Use consistent terminology for target platforms, disambiguate uses of
'deployment_target'
Calculate targets per host, in preparation for cross-compiling
Only use executables from LOCAL_HOST
Only execute testable targets of the LOCAL_HOST
Remove some cases of switching on 'uname' in preparation for
cross-compiling

Diff is now more manageable

The primary reason why I didn't use the Build/Host/Target terms is because it assumes one combination of the three, and does not work well with multi-target cross-compilers compilers, which Swift is.

After reading the script more, I find the change to the plain "host/target" terms to be a readability loss.  In the current script, I tried to use "stdlib-deployment-target" and "tools-deployment-target" to be extra clear about what is happening.

@swift-ci Please test

Some strange CI issues.  Let's try again.
@swift-ci Please test

@karwa I just wanted to thank you and say that I deeply appreciate your work on the build system.

Happy to help!

@swift-ci Please test

@swift-ci Please test

@karwa Can you please fix the conflicts?

OK I've tested that we can build on OSX and it configures for all available SDKs but only builds OSX. You can turn on iOS with the --ios flag and it will build those too, without having to reconfigure. You can also limit the slices to build with build-stdlib-deployment-targets... in theory. The ninja command is limited appropriately, but our CMake configuration files are not yet that granular. So limiting the build to macosx-x86_64;iphoneos-armv7 will build for OSX and all iphoneos slices.
We would need to change our configuration to be more granular if we wanted to limit building any further:
build stdlib/public/core/swiftCore-iphoneos:
    phony stdlib/public/core/CMakeFiles/swiftCore-iphoneos
    lib/swift/iphoneos/libswiftCore.dylib
    lib/swift/iphoneos/arm64/libswiftCore.dylib
    lib/swift/iphoneos/armv7s/libswiftCore.dylib
    lib/swift/iphoneos/armv7/libswiftCore.dylib

I'm building a toolchain locally to verify that there are no changes in the installed content.

@karwa Could you resolve the conflicts, please?

LGTM

@karwa Sorry, the build did not finish because of an error while archiving:
-- Create Info.plist --
-- Removing: <srcroot>/swift/swift-nightly-install//Library/Developer/Toolchains/swift-LOCAL-2016-05-25-a.xctoolchain/Info.plist
File Doesn't Exist, Will Create: <srcroot>/swift/swift-nightly-install/Library/Developer/Toolchains/swift-LOCAL-2016-05-25-a.xctoolchain/Info.plist
tar: Library/Developer/Toolchains/swift-LOCAL-2016-05-25-a.xctoolchain: Cannot stat: No such file or directory

I used the command printed by ./utils/build-toolchain local.swift and added --skip-test-osx --skip-test-lldb --skip-test-swift to it.

There are some strange things in those presets (and the toolchain building code in general), which reference some kind of install-directory of /Library/Developer/Toolchains/<toolchain name>. This path doesn't get used anywhere - it isn't in the Info.plist or encoded anywhere in the resulting toolchain, it's not even a writeable location unless you're root, and it's not necessary to put toolchains there in any case - they can quite happily go in a user-scoped ~/Library/Developer/Toolchains directory.

@karwa This command:
tar -c -z -f "${package_for_host}" "${TOOLCHAIN_PREFIX/#\/}"

used to archive the .../swift-nightly-install/Library/Developer/Toolchains/ directory.  Now $TOOLCHAIN_PREFIX does not seem to be a full path, so tar fails.

OK, it expands to:
--toolchain-prefix=/Library/Developer/Toolchains/swift-LOCAL-2016-05-26-a.xctoolchain --install-prefix=/usr
Which should be correct.

And another issue is that now build-script-impl creates a doubly-nested directory structure in the installation directory:
swift-nightly-install/Library/Developer/Toolchains/swift-LOCAL-2016-05-25-a.xctoolchain/Library/Developer/Toolchains/swift-LOCAL-2016-05-25-a.xctoolchain/usr/bin/swift

Okay, took a long time to build the preset to test this fix, but we can work with paths for toolchain prefixes as before 👍

@karwa Thank you for resolving conflicts, I'm building a toolchain again.

@karwa Thank you, we are really close.  The issue I just got is that swiftc is located in a funny path:
swift-nightly-install/Library/Developer/Toolchains/swift-LOCAL-2016-05-25-a.xctoolchain/Library/Developer/Toolchains/swift-LOCAL-2016-05-25-a.xctoolchain/usr/bin/swiftc

I see you just pushed an update, so I'll rebuild again.

Update was just a comment fix

I can't reproduce. I built the same preset and it produced a perfectly fine tree:
good_tree.txt

@karwa Indeed, I can't reproduce either -- sorry!  Probably I did something wrong last time.  I'll try building a Linux toolchain tomorrow, and if that goes well, we should be ready to merge.

@swift-ci Please test

@karwa Could you take a look at the buildbot error?
error: --install-destdir is required
/Users/buildnode/jenkins/workspace/swift-PR-osx/swift/utils/build-script: command terminated with a non-zero exit status 1, aborting
/Users/buildnode/jenkins/workspace/swift-PR-osx/swift/utils/build-script: using preset 'buildbot_all_platforms,tools=RA,stdlib=RA', which expands to

/Users/buildnode/jenkins/workspace/swift-PR-osx/swift/utils/build-script --test --validation-test --ios --tvos --watchos --build-subdir=buildbot_incremental --release --assertions --llbuild --swiftpm -- --reconfigure --verbose-build --build-ninja --build-swift-stdlib-unittest-extra --compiler-vendor=apple --skip-test-ios-host --skip-test-tvos-host --skip-test-watchos-host

@rintaro Failure on Linux is because the python parts of the build script try, like they do for Darwin targets, to configure for all target SDKs. So when you try to build linux-x86_64, it will configure for both the host and for android-armv7, in the same way it configures for macosx-x86_64 and for iphoneos-arm64 iphonesimulator-x86_64 ...etc. But if you don't have the Android NDK, we're not able to configure the Android target in CMake and that's considered an error.
I'm not sure it really makes sense to automatically configure Android for all Linux targets the same way we do for iOS. The iOS and OSX SDKs come as one package with Xcode, so everybody building for a Mac can always configure for iOS as well. Most people on linux-x86_64 platforms won't be building for Android, so we shouldn't configure for it unless you explicitly ask for it IMO.

@karwa I think, the original intent of --stdlib_deployment_targets is
just a list of stdlib targets which the native host can build.
This part was in build-script-impl, then migrated in #2187.
And that change introduced --stdlib_deployment_targets.
I think, this argument is not intended to be used by users, but just for
sharing data between build-script and build-script-impl

Most people on linux-x86_64 platforms won't be building for Android, so we shouldn't configure for it unless you explicitly ask for it IMO.

I think that's the right way to go.  Cross-compiling to iOS from OS X is more of an exception than the rule, but it is a critically important usecase on OS X.

I think, this argument is not intended to be used by users, but just for sharing data between build-script and build-script-impl

Currently (when it is called --swift-sdks) it is intended to be used by users who have broken SDKs that they don't even want to configure.  This is a rare usecase.  Usually it is put in a preset that some automated system uses.

Currently (Prior to this PR):
--swift-sdks is to limit auto detected SDKs to configure.
SDK auto detection is done in CMakeLists.txt
--skip-build-{target_variant} is to limit auto detected stdlib targets to build.
The target list auto detection is done in build-script and passed to build-script-impl using --stdlib_deployment_targets
Right?

I saw https://github.com/apple/swift/pull/2497/files#r64635763 this comment right now.
You modified the semantics of  --stdlib-deployment-targets from "build" to "configure".
If so, I think, you should also modify Python code
from stdlib-deployment-target to build-stdlib-deployment-target .

@karwa I was looking into merging this patch and realized that something that would be really nice (and make it easier to merge the patch) is to add support to build-script to temporarily continue accepting swift-sdks and translate that to the new arguments.  We have internal presets that rely on swift-sdks.  I would really appreciate if you could make this change.

OK, the update I just pushed fixes the OSX buildbot (no longer errors when no install-destdir given).
I'll work on the swift-sdks issue

@swift-ci Please test

@karwa Just wanted to give you a heads up about a possibly conflicting PR in flight: https://github.com/apple/swift/pull/2739/files

--swift-sdks is to limit auto detected SDKs to configure.
SDK auto detection is done in CMakeLists.txt

Calling it 'auto detection' is being a bit generous. If you don't explicitly set a list of SDKs to configure, it'll try to configure everything based on what other parameters you've set (e.g. if you've given it an Android NDK path, it'll configure the Android SDK). So really, it isn't auto detection at all - it just detects to configure for Android based on the presence of an ANDROID_NDK_PATH parameter rather than the SWIFT_SDKS parameter. It doesn't save you the need to be explicit about configuring Android, it just saves you needing the know the correct parameter for which targets get configured and it doesn't fail if you forgot to set some other required parameter.
Right now we're always explicit about which SDKs to configure for. You're right that this breaks auto detection from CMake. Eventually auto detection should probably be moved in to the build script, anyway:

SDK names aren't architecture-specific, so eventually build-script-impl is going to have to start configuring swift using stdlib-deployment-targets such as linux-armv7 instead of just LINUX, or iphoneos-arm64 instead of just IOS.
Once we do that, we can remove the hardcoded architectures from CMake. They're all in the build script anyway, so we can be explicit (actually somebody forgot iphoneos-armv7s in targets.py, but otherwise they're all there).
In fact, if CMake doesn't have hardcoded architectures for its SDKs, it will require us to be explicit about the targets to configure.

Eventually auto detection should probably be moved in to the build script, anyway

I agree.

OK, so:

Install issue has been fixed. Now errors only if trying to install and --install-destdir not given, as before.
Updated description of stdlib-deployment-targets
Python changes:
I don't know what you'd call it... symbol-ising? symbolicating? the deployment target string literals. Brought iphoneos-armv7s back and added allTargets helpers so we don't forget any in the future.
swift-sdks gets migrated for presets (tested by reverting the change to build-presets.ini, it gets expanded correctly)
stdlib_deployment_targets() is now default_stdlib_deployment_targets(). For all platforms other than OSX, it just returns the host's deployment target.
DeploymentTarget.Android.armv7 added on request instead of being part of the default list for linux

@swift-ci Please test

@swift-ci Please test

@karwa I'm getting this error now:
ninja: error: unknown target 'swift-benchmark-iphoneos-armv7s', did you mean 'swift-benchmark-iphoneos-armv7'?

Seems to be caused by this line in benchmark/CMakeLists.txt:
set(iphoneos_arch "arm64" "armv7")

OK, so either armv7s was intentionally left out of the stdlib-deployment-targets (strange if true, probably deserves a comment to explain), or the benchmarks need to be updated.
@rintaro ?

I think there is a possibility it might have been intentionally left out of benchmarks because armv7 is not dramatically different from armv7s.

@swift-ci Please test

of course swift-build-support has tests which must be updated, too...
Oh well. Let this be the final fix. 😣

@karwa Did you accidentally drop this change?
-                # Never build iOS armv7s benchmarks.
-                if [[ "${stdlib_deployment_target}" == "iphoneos-armv7s" ]]; then
-                    build_benchmark_this_target=
-                fi

@gribozavr Yes; too eager to get this merged.

@karwa Sorry, just noticed another thing -- I'm not seeing where the build_and_test_installable_package function ends.  Did we lose the close brace?

Yes, we lost a } with the last merge. Sorry about that.

@karwa I looked into this further and I think we lost more than just the brace.  I see these diffs (compared to yesterday's checkout):
           if [[ "${DARWIN_TOOLCHAIN_INSTALLER_PACKAGE}" ]] ; then
             echo "-- Create Installer --"
             "${SWIFT_SOURCE_DIR}/utils/toolchain-installer" "${install_destdir}" "${DARWIN_TOOLCHAIN_BUNDLE_IDENTIFIER}" \
             "${DARWIN_TOOLCHAIN_INSTALLER_CERT}" "${DARWIN_TOOLCHAIN_INSTALLER_PACKAGE}" "${DARWIN_TOOLCHAIN_INSTALL_LOCATION}" \
             "${DARWIN_TOOLCHAIN_VERSION}" "${SWIFT_SOURCE_DIR}/utils/darwin-installer-scripts"
           fi

-          # host_install_destdir contains the toolchain prefix.
-          # We want to create the package in host_install_destdir_nonprefixed.
-          (cd "$(get_host_install_destdir_nonprefixed {host})" &&
-            tar -c -z -f "${package_for_host}" "${TOOLCHAIN_PREFIX/#\/}")
-        else
-            # tar on OSX doesn't support --owner/--group.
-            if [[ "$(uname -s)" == "Darwin" ]] ; then
-                (cd "${install_destdir}" &&
-                        tar -c -z -f "${package_for_host}" "${INSTALL_PREFIX/#\/}")
-            else
-                (cd "${install_destdir}" &&
-                        tar -c -z -f "${package_for_host}" --owner=0 --group=0 "${INSTALL_PREFIX/#\/}")
-            fi
+      (cd "${INSTALL_DESTDIR}" &&
+        tar -c -z -f "${INSTALLABLE_PACKAGE}" "${TOOLCHAIN_PREFIX/#\/}")
+    else
+      (cd "${INSTALL_DESTDIR}" &&
+        tar -c -z -f "${INSTALLABLE_PACKAGE}" --owner=0 --group=0 "${INSTALL_PREFIX/#\/}")
+    fi
+    if [[ "${TEST_INSTALLABLE_PACKAGE}" ]] ; then
+        PKG_TESTS_SOURCE_DIR="${WORKSPACE}/swift-integration-tests"
+        PKG_TESTS_SANDBOX_PARENT="$(build_directory swift_package_sandbox none)"
+        PKG_TESTS_TEMPS="${PKG_TESTS_SANDBOX_PARENT}"/"tests"
+
+        if [[ "$(uname -s)" == "Darwin" ]] ; then
+            PKG_TESTS_SANDBOX="${PKG_TESTS_SANDBOX_PARENT}"/"${TOOLCHAIN_PREFIX}"
+        else # Linux
+            PKG_TESTS_SANDBOX="${PKG_TESTS_SANDBOX_PARENT}"
         fi
-        if [[ "${TEST_INSTALLABLE_PACKAGE}" ]] ; then
-            PKG_TESTS_SOURCE_DIR="${WORKSPACE}/swift-integration-tests"
-            PKG_TESTS_SANDBOX_PARENT="$(build_directory swift_package_sandbox_${host} none)"
-
-            if [[ "${host}" == "macosx-"* ]] ; then
-                PKG_TESTS_SANDBOX="${PKG_TESTS_SANDBOX_PARENT}"/"${TOOLCHAIN_PREFIX}"
-            else # Linux
-                PKG_TESTS_SANDBOX="${PKG_TESTS_SANDBOX_PARENT}"
-            fi
             LIT_EXECUTABLE_PATH="${LLVM_SOURCE_DIR}/utils/lit/lit.py"
             FILECHECK_EXECUTABLE_PATH="$(build_directory_bin ${LOCAL_HOST} llvm)/FileCheck"
             echo "-- Test Installable Package --"
             set -x
             rm -rf "${PKG_TESTS_SANDBOX_PARENT}"
             mkdir -p "${PKG_TESTS_SANDBOX}"
             pushd "${PKG_TESTS_SANDBOX_PARENT}"
             tar xzf "${package_for_host}"
             popd

-            (cd "${PKG_TESTS_SOURCE_DIR}" &&
-                    python "${LIT_EXECUTABLE_PATH}" . -sv --param package-path="${PKG_TESTS_SANDBOX}" --param filecheck="${FILECHECK_EXECUTABLE_PATH}")
-            { set +x; } 2>/dev/null
-        fi
+        (cd "${PKG_TESTS_SOURCE_DIR}" &&
+                python "${LIT_EXECUTABLE_PATH}" . -sv --param package-path="${PKG_TESTS_SANDBOX}" --param filecheck="${FILECHECK_EXECUTABLE_PATH}" --param test-exec-root="${PKG_TESTS_TEMPS}")
+        { set +x; } 2>/dev/null
     fi
 }

I don't think this is intended.  The indentation is off, and the tar command is back to using TOOLCHAIN_PREFIX.  Could you double-check?

Oh gosh, I'm incredibly sorry; it's a difficult patch to keep merged but that's still a big oversight.
I've re-rebased and double-checked.

@karwa Thank you, I'm building toolchains to verify.

I don't know, everything is working for me except the LLDB install location, which still forgets to put a path separator before the toolchain prefix. My next idea is that it's a problem with Xcode, as per Xcode's documentation:
INSTALL_DIR
Description:
Directory path. Identifies the directory in the developer’s filesystem into which the installed product is placed.
Effectors:
DSTROOT (Installation Build Products Location), INSTALL_PATH (Installation Directory).
Value:
$DSTROOT/INSTALL_PATH
Example value:
/tmp/MyProduct.dst/Users/genica/Library/Bundles

Meanwhile, I'm seeing:
export DSTROOT=/Spring/Projects/3rdParty/OpenSource/Apple/cross-compile/out/destdir
...
export INSTALL_PATH=swift3.xctoolchain/System/Library/PrivateFrameworks
...
export INSTALL_DIR=/Spring/Projects/3rdParty/OpenSource/Apple/cross-compile/out/destdirswift3.xctoolchain/System/Library/PrivateFrameworks

with parameters:
--install-destdir="${cc_files}/out/destdir"
--toolchain_prefix="swift3.xctoolchain"

I'm pretty sure I should go back to ignoring the LLDB_TOOLCHAIN_PREFIX parameter. While I was changing the build presets, it occurred to me that we never even used to use the TOOLCHAIN_PREFIX parameter - we just slapped it on the front of INSTALL_PREFIX and pretended there was no TOOLCHAIN_PREFIX. We do a similar thing now in the build script - appending on to INSTALL_DESTDIR instead of prefixing the prefix. I think that means we should be able to safely ignore the parameter.
Indeed, that's what fixed it before.

@karwa I'm seeing this issue now (tested the PR before the LLDB change):
-- Test Installable Package --
[...]
Testing Time: 19.18s
  Expected Passes    : 11
  Unsupported Tests  : 8
--- Creating symbols package ---
-- Package file: <src>/swift/swift-LOCAL-2016-05-27-a-osx-symbols.tar.gz --
+ pushd <src>/swift/swift-nightly-symroot
OSError: [Errno 2] No such file or directory: '<src>swift/swift-nightly-symroot'

While I was changing the build presets, it occurred to me that we never even used to use the TOOLCHAIN_PREFIX parameter

I think we were.  From https://ci.swift.org/job/oss-swift-package-osx/1704/consoleText:
Build settings from command line:
    LLDB_TOOLCHAIN_PREFIX = /Applications/Xcode.app/Contents/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2016-05-26-a.xctoolchain

But that's a total lie, the toolchain does not end up being installed there.  Given that, I think something about LLDB should have changed since the time when this option was introduced.
/CC @scallanan: what do you think?

@karwa Rebuilt from scratch again, still hitting
--- Creating symbols package ---
-- Package file: <src>/swift/swift-LOCAL-2016-05-27-a-osx-symbols.tar.gz --
+ pushd <src>/swift/swift-nightly-symroot
OSError: [Errno 2] No such file or directory: '<src>swift/swift-nightly-symroot'

Turns out that --toolchain-prefix isn't a parameter anymore. build-script now invents it by extracting the first component of the --install-prefix. That will probably explain the LLDB issues, and it's why it can't find the symroot package afterwards.
In that case it's probably best that I revert the --install-prefix change and add another parameter: cross-compile-host-install-prefix. We're not going to be able to share --install-prefix with other platforms.

@karwa Your proposed plan sounds reasonable.

@swift-ci Please test

@swift-ci Please smoke test

@gribozavr Okay, changes to TOOLCHAIN_PREFIX reverted and it builds a correctly laid-out toolchain on OSX.

@swift-ci Please smoke test

@karwa Thank you, I'm building a toolchain locally to double-check.

@gribozavr Hadn't pushed all commits

Fetched again.

@karwa Thanks!  The install tree looks a little funny, Swift does not seem to be installed into the toolchain:
swift-nightly-install/Library/Developer/Toolchains/swift-LOCAL-2016-05-27-a.xctoolchain/usr/bin/lldb # LLDB is OK
swift-nightly-install/usr/bin/swift # Swift is not

swift will be inside the toolchain:
swift-nightly-install/Library/Developer/Toolchains/swift-LOCAL-2016-05-27-a.xctoolchain/usr/bin/swift

@karwa Sorry, I don't understand you...  I built a toolchain and the file list I posted is what I got.  Are you saying that you are working on a fix?

No, I'm saying that swift is installed where it should be - inside the toolchain directory. The path you posted was in the install_destdir itself.
This is the tree I got from build_toolchain:
toolchain.txt

Looks like this is the issue:
DESTDIR="${host_install_destdir}" "${CMAKE}" --build "${build_dir}" -- ${INSTALL_TARGETS}

Should it use ${host_install_destdir}${host_install_prefix} instead?

The path you posted was in the install_destdir itself.

Well, yes, that's the issue I'm pointing out.  The tree I posted is what I got from build-toolchain, too.

@swift-ci Please test

No I'm still pretty sure this is right - the install prefix wasn't in the DSTDIR variable before these changes, either. Swift gets this information from the CMAKE_INSTALL_PREFIX variable.
If you have an extra copy of swift, maybe it's left over from another build?

Let's see if it reproduces in CI.

No I'm still pretty sure this is right - the install prefix wasn't in the DSTDIR variable before these changes, either. Swift gets this information from the CMAKE_INSTALL_PREFIX variable.

But when we call the CMake action to install, we override the directory with DSTDIR environment variable.

If you have an extra copy of swift, maybe it's left over from another build?

It is not an extra copy, it is the only copy.  (And I'm always doing from-scratch builds, removing the ../build directory and swift-nightly-* directories.)

I will also build another toolchain without this PR to check which commands were run before.

No I'm still pretty sure this is right - the install prefix wasn't in the DSTDIR variable before these changes, either. Swift gets this information from the CMAKE_INSTALL_PREFIX variable.

But when we call the CMake action to install, we override the directory with DESTDIR environment variable.

I finally see what you meant, sorry, I misunderstood you.  I'm building again now.  I can confirm that CMAKE_INSTALL_PREFIX for LLVM and Swift are correct, now waiting for the installation step.

I just built the toolchains again on OS X and Linux, and everything matches up exactly!  So it was a misconfiguration on my side, sorry for wasting your time, @karwa.

@gribozavr Thank you so much for all your help and for reviewing it. Also to @rintaro and everybody else.

I can't tell for sure, but it looks like this commit introduced Linux triples of the form "armv7-linux-gnueabihf" instead of "armv7-unknown-linux-gnueabihf", causing SR-3019. Was this intentional?

@jrose nope. I picked that to be as close as possible to the GCC triple arm-linux-gnueabihf (but I don't think anybody uses armv6/7 on GCC). I wasn't aware that triples in LLVM needed a fourth component.

They need three components, but the second component has to be a vendor. Are you sure the GCC triple is arm-linux-gnueabihf and not arm-unknown-linux-gnueabihf?

Okay, I could have just checked for that, indeed it is.

Yeah sorry, you're right that the second component should be "unknown" (rustc  apparently uses that), but GCC seems to use an incorrect triple: http://packages.ubuntu.com/precise/devel/gcc-arm-linux-gnueabihf
I've been having some issues with LLDB reloading images because of mismatching architectures. I'll investigate if this could be the reason for it...

I doubt it is, but we should pull in a fix anyway.


Show practical support, ext pledges, and fulfillments in changelog

I rule and have completed some work on Case Manager that's ready for review!
Since we're off mongo this is a bit more straightforward! Required some adjustments to i18n though. Made some quality-of-life improvements to the changelog while I was in there.
This pull request makes the following changes:

Display changes for external pledges, practical supports, and fulfillments in the patient changelog
clean up some long-running display issues (missing keys + null changesets)
add keys to i18n registry

The display isn't perfect but they're likely deducible from context clues to a CM. An example with an ext pledge and a few psupport entries:

It relates to the following issue #s:

Fixes #826

For reviewer:

Adjust the title to explain what it does for the notification email to the listserv.
Tag this PR:

feature if it contains a feature, fix, or similar. This is anything that contains a user-facing fix in some way, such as frontend changes, alterations to backend behavior, or bug fixes.
dependencies if it contains library upgrades or similar. This is anything that upgrades any dependency, such as a Gemfile update or npm package upgrade.

If it contains neither, no need to tag this PR.

given the time in drafting, going to bump to include fulfillments too

this is now in good shape, except for bullet thinking we're eager loading when we don't need to. Going to iron that out soon I hope, and then this PR should be in mergeable shape again

I think we have some confusing behavior introduced here, unfortunately. When you change only one part of an External Pledge or a Practical Support, the Change Log is ambiguous as to what happened. Can we make them show more context in the logs?

@lomky I think this might be a bit better of an approach - stapling the exact obj type and id in the changelog. So we wind up with something like this:

thoughts?


Production error: variant.replaceAll is not a function

On my 1st project to incorporate the UI, I am running into an issue that is breaking my staging and production environments
I cannot duplicate this error locally wether its in dev mode or i build and run the server locally:
[nuxt] [request error] [unhandled] [500] variant.replaceAll is not a function
I see in the codebase this runs for each component, but i do notice variant?.replaceAll which I assume would stop this from happening.  I am breaking up my implementation into sections to try and determine where this is happening, I'll update this issue as I get more information.
Here is the cloudwatch logs seen from fume:

also seeing
[nuxt] [request error] [unhandled] [500] key.replaceAll is not a function

I was able to get a more detailed stack:
Unhandled Promise Rejection {"errorType":"Runtime.UnhandledPromiseRejection","errorMessage":"TypeError: variant.replaceAll is not a function","reason":{"errorType":"TypeError","errorMessage":"variant.replaceAll is not a function","stack":["TypeError: variant.replaceAll is not a function"," at ReactiveEffect.fn (file:///var/task/.output/server/chunks/app/server.mjs:4206:44)"," at ReactiveEffect.run (/var/task/.output/server/node_modules/@vue/reactivity/dist/reactivity.cjs.js:162:19)"," at ComputedRefImpl.get value [as value] (/var/task/.output/server/node_modules/@vue/reactivity/dist/reactivity.cjs.js:1143:33)"," at unref (/var/task/.output/server/node_modules/@vue/reactivity/dist/reactivity.cjs.js:1022:29)"," at Object.get (/var/task/.output/server/node_modules/@vue/reactivity/dist/reactivity.cjs.js:1028:35)"," at Object.get (/var/task/.output/server/node_modules/@vue/runtime-core/dist/runtime-core.cjs.js:2912:26)"," at _sfc_ssrRender$3 (file:///var/task/.output/server/chunks/app/server.mjs:4253:17)"," at renderComponentSubTree (/var/task/.output/server/node_modules/@vue/server-renderer/dist/server-renderer.cjs.js:683:9)"," at renderComponentVNode (/var/task/.output/server/node_modules/@vue/server-renderer/dist/server-renderer.cjs.js:631:12)"," at ssrRenderComponent (/var/task/.output/server/node_modules/@vue/server-renderer/dist/server-renderer.cjs.js:86:10)"]},"promise":{},"stack":["Runtime.UnhandledPromiseRejection: TypeError: variant.replaceAll is not a function"," at process.<anonymous> (/var/runtime/index.js:35:15)"," at process.emit (events.js:400:28)"," at processPromiseRejections (internal/process/promises.js:245:33)"," at processTicksAndRejections (internal/process/task_queues.js:96:32)"]}

Upgrading node in Lambda from 14.x to 18.x fixed this (was a pretty old function) - and since in your package.json you require 16+ I think this might be invalid and closeable, I'll let yall decide or close this in a couple days if theres no activity

Closing due to disappearance after upgrading node


Config changes to reflect the default branch from master to main. Please merge to complete the default branch renaming job.

Auto branch renaming content.

Docs Build status updates of commit 92cb453:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

.openpublishing.publish.config.json
:white_check_mark:Succeeded

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


Bump io-sim dependency and fix registry test

This PR bumps the io-sim dependency to include threadStatus in the interface. The idea is for the Registry example to start working. However, because we are running on a new scheduling semantics than the old funky version of the example this currently doesn't quite work - hence draft PR.

Ok, turns out the example was just broken for bad reasons probably related to some attempt to use it as a tutorial at some point. The tests pass now 🎉