Add Background to file property tab so aliases aren't invisible

uhhhhhh yeah i just got fed up with not being able to see my aliases in the property menu instead of in-editor because they're basically invisible being the same colour as the background so here's a jank fix that doesn't change much

I'm not quite sure where/what the problem is ... in my screenshot everything appears to show up. Let me know what you're not seeing and I'll make adjustments. I won't merge these changes though because the theme.css file is rendered by compiling all the scss files from the source folder. No biggie though - if you can show a screenshot I'll try and reproduce the problem.
Here's what I'm seeing:

Oh, I just saw your posts in the Obsidian forum and you had screenshots there. I didn't realize you were talking about the sidebar. You're right - since it's a black and white theme it's a pain to get the styles right. I'd love to sit down one day and figure out a better way to do it. I've thought about just making the right side panel stay light colored. Anyway, for now I've put a change in that will make the properties panel more visible. There's a few more tweaks to make, but thanks for the feedback!

There's something else that didn't get merged. It's specifically to make sure that the vault switcher text doesn't blend into the background

.workspace-drawer-vault-name {     color: var(--nav-item-color); }
that snippet should fix it.

and also the properties disappear on hover and while editing them. that's why i added a white background, so they can be more visible since the properties fields in both the doccument and sidebar share the same css attributes

Thanks for the extra info - I just pushed a new version, hopefully makes everything else more visible in the properties panel. Also the vault name, and the suggestion popups.


Dynamic service and cog loading doesn't handle nested packages

Currently the dynamic loading code only searches the current layer in the cogs and services folder. this makes it impossible to have nested cog/service packages. The dynamic loading code will need to be rewritten with this in mind.

closed in #106


SABR director review of lite project documents (? will we do this?)

Director reviewed and approved the business case.


fix(models): update field model reference for fields with nested string models

What
String field models were resolved just once on init and when the outer model ($scope.model) is totally overridden, the field's model still references the old model.
How
I have added a shallow reference watcher to every field that has string model. It checks if the reference changed and updates field.model accordingly.
I had to add 5th parameter to evalCloseToFormlyExpression because I didn't want to override the field object on each watcher. This might seem a bit dirty :+1:
Test case for the fix added.
Checklist:

[x] Follows the commit message conventions
[x] Is rebased with master
[x] Is only one (maybe two) commits

Current coverage is 96.04%

Merging #653 into master will increase coverage by +0.01% as of 0280668

@@            master    #653   diff @@
======================================
  Files           16      16
  Stmts         1160    1163     +3
  Branches         0       0
  Methods          0       0
======================================
+ Hit           1114    1117     +3
  Partial          0       0
  Missed          46      46

Review entire Coverage Diff as of 0280668

Uncovered Suggestions

+0.34% via ...alidationMessages.js#25...28
+0.26% via src/test.utils.js#38...40
+0.26% via ...s/formlyUsability.js#18...20
See 7 more...

Powered by Codecov. Updated on successful CI builds.

LGTM, could I have someone else review and merge this? Ping @formly-js/angular-formly-collaborators

I guess the only performance hit we're going to see is for people using nested objects. Looks fine, LGTM


Web application

Things to do before launching the web application:

[x] app modifications :1st_place_medal:

[x] session save and store - probably better to do atomic request updates
[x] zoom user config
[x] layout plot settings
[x] fix initial load function
[x] fix rings not appearing on reload (due to getting the filtered store in the ring panel not the data panel)
[x] add session re-hydration, consider what to do with files, see also:  #6
[x] file deletion in table
[x] implement reference ring as an endpoint for consistency
[x] blastn configuration options in ring
[x] set timeout of celery task checks in docker compose env var
[x] fix indexing of label ring and added new outer ring'
[x] fix png export opacity animation
[x] fix title font styling
[x] fix default values on plotConfig
[x] positioning of labels on line around circle
[x] bug: all labels are added again (RingStore)
[x] labels responsive to changes in ring settings
[x] default visualisation on landing page
[x] ~add version to session, ring and file models~ backwards compatibility targeted for major release
[x] change all form actions to dispatchers, see also: #11
[x] improve error message, see also:  #9
[x] save session and new session clipboards

[x] replace bind mount with volume as work directory
[x] fix package and software versions
[x] production-grade deployment and containers
[x] dev and prod docker compose profiles
[x] cli task and timed data deletion instead of basic script
[x] cocogitto bump tests and pre-bump hooks :3rd_place_medal:

[x] package.json
[x] brick.api.core.config
[x] pyproject.toml

[x] MongoDB setup and container cfg
[x] CI/CD GitHub actions

[x] action workflow for testing on test/** branches ~dev branch~
[x] action workflow for releases on release branch - i'm not sure if cocogitto is quite stable yet, there seems to be a bug (to be submitted after more testing) when bumping versions in a branch that is carried over into other branches including main
[x] action workflow for remote update and deployment

[x] reverse proxy setup and configuration :2nd_place_medal:
[x] README

not quite there yet

Mostly there, improvements to CI/CD and other actions in 0.4.0 after testing.


Refresh button for contract metadata

PR-Codex overview
This PR adds a new Link component, renames VerifyContractParams to ContractParams, and introduces a feature to purge contract metadata cache.
Detailed summary

Added Link component
Renamed VerifyContractParams to ContractParams
Added purgeMetadataCache function
Added PurgeCacheModal component
Added functionality to refresh metadata cache
Updated modals and buttons for verification and cache refresh

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

#3834  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @kumaryash90 and the rest of your teammates on  Graphite


How to register new processes to Sprokit?

I have found following description to Sprokit here:
https://github.com/Kitware/kwiver/blob/dev/add-track-oracle/sprokit/doc/running-notes.md
Modules are loaded from a set of directories that are configured into the loader at build time. The default directory is 'lib/sprokit' subdirectory of the install tree. Additionally, at build time, The build directory can be added to the loading path by selecting the cmake variable KWIVER_USE_BUILD_TREE Set environment variable SPROKIT_MODULE_PATH to list directories of loadable modules

So I have to put a new module into the subdirectory 'lib/sprokit' and rebuild Kwiver?

Following processes aren't registered.

kw_archive_writer_process
kw_print_number_process

I tried to set the environment variable SPROKIT_MODULE_PATH and to rebuild Kwiver, but it didn't worked.
So the question is:
What is the standard approach to register a process to Sprokit?

Sprokit "discovers" processes by looking through the libraries in its module path, so there is no requirement to rebuild sprokit or kwiver to add a new process. That being said, the easiest way to get started might be to add your process to the sprokit/src/processes/examples directory and update the registration.cxx file.
Here's a longer explanation of how to add processes.
Processes are usually grouped in a directory and linked into a loadable library (e.g. DLL or SO). This directory/library may contain one or more processes. These processes are registered with sprokit at run time by code in an additional file that is executed when the library is loaded. See sprokit/src/processes/examples/registration.cxx for an example. This registration file must contain a function called regsiter_processes() with C linkage. See registration.h for an example of how to do this. This function must be declared with external linkage so it is visible outside of the library. The example file uses a defined symbol that is created by the build process. It may be easier to just use the compiler specific declaration:

Windows - __declspec(dllexport)
linux/gcc - __attribute__((__visibility("default")))

After the library is built, it is easiest to move it to lib/sprokit so it will be found.
The tool processopedia can be used to display information about processes that sprokit can load. This is a good way to see if your process has been discovered.

Thank you very much for the detailed explanation.
It helps me a lot.


Fix input lost focus when entering on no result found

Details

When the search has no result and the user uses the enter key, we should keep the input is focused
Fixed Issues

$ https://github.com/Expensify/App/issues/28072
PROPOSAL: https://github.com/Expensify/App/issues/28072#issuecomment-1732348418
Tests

Go to Settings > Workspaces
Select any workspace and open the member page
Click on the invite button
Enter the random input that will display no result found
Press the enter key
Verify that the input keeps focusing
Open emoji picker and do the same thing
Verify that the result is the same with step 6

[x] Verify that no errors appear in the JS console

Offline tests

QA Steps

Go to Settings > Workspaces
Select any workspace and open the member page
Click on the invite button
Enter the random input that will display no result found
Press the enter key
Verify that the input keeps focusing
Open the emoji picker and do the same thing
Verify that the result is the same with step 6

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web
https://github.com/Expensify/App/assets/129500732/9aa0e7ab-aa00-4732-9b4f-9af40da0351b

Mobile Web - Chrome
https://github.com/Expensify/App/assets/129500732/79603fa5-c4d0-4e1d-88d1-c3c4a68fa74a

Mobile Web - Safari
https://github.com/Expensify/App/assets/129500732/5fa32242-2f14-4931-b886-458c71a67fc4

Desktop
https://github.com/Expensify/App/assets/129500732/a16c2253-ad99-47cb-a63d-007a4c8f1e63

iOS
https://github.com/Expensify/App/assets/129500732/7af83fd2-9976-4dbb-a64d-48f041376d97

Android
https://github.com/Expensify/App/assets/129500732/c476ac88-0a48-4e8c-8388-4d98a11e12e5

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/nkuoch in version: 1.3.78-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/Beamanator in version: 1.3.78-4 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/nkuoch in version: 1.3.79-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/jasperhuangg in version: 1.3.79-5 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
failure ❌

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/jasperhuangg in version: 1.3.79-5 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
cancelled 🔪

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/jasperhuangg in version: 1.3.79-5 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


RTL and i18n fixes for Hebrew. Update ace to latest build with RTL support

Coverage decreased (-0.01%) to 62.221% when pulling d27c12026f95ced14d7af7f340d2a9533feaf726 on rtl-tweaks into 58ec5180deb41b5d246071a32213d2b2adb4fe5e on master.


Move frame delaying functions from Main to OS.

Will allow specific platforms to override it and avoid blocking on the main/GUI thread.
Ground work to allow fixing #38623 in JavaScript platform.
This PR does not change the functionality, it only moves the code to the OS class so it can be overridden.
I'll make a separate PR for the overridden JavaScript behaviour.

Thanks!


Configuration Management cartridge for the transport framework

Demo the open source configuration management cartridge that will be published to github that shows how to retrieve configuration from the configuration framework. Discuss the approach, the benefits and cons.

@willemevertse is this project already available? I'd like to have a look as I want to utilize the Transport Framework (automatically).


[WIP] Refactor logins  to cookieLogin of many tests

Remaining tests up to date were refactored, so they now use cookieLogin for faster tests. Only one file was not refactored - group_management.js which failed every time. This will be work rather for new PR.

Please remove every single line containing baseUrl (fixed in ...),
and call cy.cookieReset() from before() in all tests where cookieLogin is used :).
CSRF tokens are single use (single POST), so we can't really rely on being able to log in from the cache after they were used :(.
(It's ok within the test file, the authors can cope then :).)
Or (and given https://github.com/ansible/ansible-hub-ui/pull/747#issuecomment-893937569), we can just skip this PR completely and revisit once api login is in.


support df.to_sql()

I'm playing around with something like the following, trying to create (or populate) a table with trino iceberg connector:
df = pd.DataFrame({
    "version":[1,1,1],
    "value":[1,2,3]
})

df.to_sql('test1',
           schema='eje_test_iceberg',
           con=engine,
           method=None,
           if_exists="replace",
           index=False,
           dtype={"version":Integer(),"value":Integer()}
)

Getting the following error:
NotSupportedError: (trino.exceptions.NotSupportedError)
[SQL: INSERT INTO eje_test_iceberg.test2 (version, value) VALUES (?, ?)]
[parameters: ((1, 1), (1, 2), (1, 3))]

Hello @erikerlandson
Currently trino python client is not support executemany operator. So in pandas df.to_sql you NEED to specify method="multi"

I add a small docs in #38 to help other people face the same issue.

Thanks!


Use codecov for code coverage and add python3.8

Codecov was a nice replacement for coveralls in pymc3. This PR changes the currently used azure-pipelines coverage publisher and reporter tasks to codecov.io instead. We'll get the same nice coverage graphs for PRs and reports as in pymc3.
I also added a python3.8 test environment (as it's basically free because we haven't hit the limit of parallel jobs in azure).

Tensorflow and TFP don't seem to support python3.8 yet... I'll just drop the python3.8 test env entirely until they package TF and TFP for py38

I made an almost empty commit to get the first coverage report uploaded properly to codecov


[Model Request] Mistral Large Instruct 2407

⚙  Request New Models

Link to an existing implementation (e.g. Hugging Face/Github): <!-- Link to the model --
https://huggingface.co/mistralai/Mistral-Large-Instruct-2407

Is this model architecture supported by MLC-LLM? (the list of supported models)

Additional context
<!-- Add any other context that you think would be helpful for the community to add this model --
Hello, could you please add supporting Mistral 2 Large 123B model?>

https://huggingface.co/TNT3530/Mistral-Large-Instruct-2407-q4f16_1-MLC

@TNT3530 @MasterJH5574
Could you add this in mlc-ai huggingface repository?


Make Cargo XDG-compliant (on non-Windows systems)

http://standards.freedesktop.org/basedir-spec/basedir-spec-0.8.html
http://www.freedesktop.org/software/systemd/man/file-hierarchy.html
Strategy for backward-compatiblity:
When checking for the relevant cargo directories, check in the following
order of preference:

Use the environment variable CARGO_HOME.
Use the XDG directories if they exist.
Use the legacy location (~/.cargo) if it exists.
Fall back the XDG directories if everything else fails.

Fixes #1734.

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @huonw (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

Probably doesn't compile on Windows, because the xdg crate probably doesn't: https://github.com/whitequark/rust-xdg/pull/5.

Passes all tests now, ready to get merged!

Since XDG is higher priority than the original one, isn't that going to cause issues? People who work on systems which follow XDG are gonna see their existing ~/.cargo dissapear... no?

The XDG only has higher priority if it exists (~/.cache/cargo). This could help with deprecating ~/.cargo completely in the future.

Thanks for the PR @tbu-! It looks like there was also quite a bit of legwork in getting everything to work across all platforms, so thanks for that as well! Some thoughts of mine:

If we're going to knock this out, then I think it may be good to take care of https://github.com/rust-lang/cargo/issues/1976 along the way as well.
Is it standard to use XDG on systems like OSX and FreeBSD? I'm mostly worry about OSX, but this seems like a very Linux-specific concept. Although it works on OSX, I'm not sure if it's idiomatic.
I'm worried about the fragmentation this causes across platforms. It's no longer easy given an arbitrary system to find out where Cargo has placed its cache directory or where you should place configuration.
It looks like we'd be one of the first package managers to do something like this. None of bundler, npm, pypi, or rubygems seem to do anything related to this. Our target audience isn't always experienced linux folks who expect this behavior but often newbies who may not know where to probe to find Cargo-related files.
It'd be much nicer to use if cfg!(windows) instead of #[cfg(windows)] and it looks like the xdg crate only has one unix-specific import.
The xdg crate is a bit too eager to panic.

I wonder if it would be possible to have this still be opt-in, but perhaps have the opt-in to be very easy to set?

Thanks for looking over the pull request!

If we're going to knock this out, then I think it may be good to take care of #1976 along the way as well.

I suppose, but I don't have a Windows machine right now.

Is it standard to use XDG on systems like OSX and FreeBSD? I'm mostly worry about OSX, but this seems like a very Linux-specific concept. Although it works on OSX, I'm not sure if it's idiomatic.

Yea, the points about OS X and *BSD are fair, I haven't researched the situation there yet.

I'm worried about the fragmentation this causes across platforms. It's no longer easy given an arbitrary system to find out where Cargo has placed its cache directory or where you should place configuration.

Fragmentation isn't really worse, you can find the configuration in ~/.config/cargo and the cache in ~/.cache/cargo, unless you set environment values, like before.

It looks like we'd be one of the first package managers to do something like this. None of bundler, npm, pypi, or rubygems seem to do anything related to this. Our target audience isn't always experienced linux folks who expect this behavior but often newbies who may not know where to probe to find Cargo-related files.

Update the tutorials to point to ~/.config/cargo instead of ~/.cargo/config (With a mention that the legacy location ~/.cargo/config is still supported).

I wonder if it would be possible to have this still be opt-in, but perhaps have the opt-in to be very easy to set?

I think making standard compliance an opt-in is basically not having standard compliance at all. The standards exist to give common behavior across many different programs, and if you have to configure each of them anyway, then the benefit of having that standard is lost.
The issues with the XDG crate (cfg!(windows) vs #[cfg(windows)] and the panic) can certainly be fixed.

Yea, the points about OS X and *BSD are fair, I haven't researched the situation there yet.

I can't tell you about BSD, but for OSX: https://developer.apple.com/library/mac/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html
TL;DR: very much not XDG.

r? @alexcrichton

@tbu-
Ah yeah sorry to be clear I'm not worried about fragmentation within a platform, but rather across platforms. For example we can't really just update the tutorials to list different paths because now it's a different path for every platform. In that sense I think the fragmentation gets worse because as someone who works across OSX/Windows/Linux I've now got to always be conscious of where I'm at if I want to find these directories.

:umbrella: The latest upstream changes (presumably #2154) made this pull request unmergeable. Please resolve the merge conflicts.

So, I researched a little and found out that the BSDs should probably get XDG handling, OS X caches go into ~/Library/Caches/Cargo and config into ~/Library/Cargo/. On Windows it'll be AppData\Roaming for the config and AppData\Local for the caches. What I'm still trying to figure out is where we should put the executables on OS X and Windows. Do you have ideas for that?

I'm personally still worried about the fragmentation problem. It looks like this is basically going to end up with almost a different location for directories per OS rather than "windows" and "non windows", and at some point it seems like the benefit perhaps isn't that large?
This is why I was thinking that an opt-in may suffice for now in some form.

@alexcrichton I guess if we want non-fragmentation, we should probably go for XDG on unixy systems (including Mac), and for AppData on Windows.
This would give us a pretty consistent story that interacts well with the OSs, as well as separating caches from configs.

That seems like not a great situation to be in though, unfortunately. There's still fragmentation between Windows and non-Windows, and Cargo would be favoring Linux/Windows over all other OSes by saying they need to be slotted into one of those buckets. Overall it seems like it doesn't really reduce the net number of issues?

Let's collect a list of advantages and disadvantages:

~/.cargo/ everywhere:

+ Cross-platform consistency
- Very unexpected for Windows users

XDG on Unix, AppData on Windows

+ Cross-platform consistency among unixes
+ Clearly separates cache from config, helps backup tools
+ Uses the XDG standard on Unixes
+ Uses an expected directory on Windows
- Not the current solution -> needs code to maintain backward compatiblity for some time
- Not the preferred solution on Mac (but only on Mac, on BSDs, this is fine)

XDG on Unixes, Apple-specific on Mac, AppData on Windows

Essentially same as 2)
- Less cross-platform consistency among unixes, might be weird when ssh'ing from machine to machine
+ Uses the preferred solution on Mac

So by just looking at the advantages/disadvantage (tell me if I missed any!), I'd say that 2) and 3) are both favorable to 1). In fact, the only advantage of 1) over 2) seems to be that there is cross-platform consistency between Windows and unixy operating systems, which I'd argue is very much not expected for Windows users.

Thanks for working on this! Following XDG is a huge win and it would be much nicer if all applications did this. Primarily the clean separation of cache vs user data (config and data). Especially since cargo does not clean up its old caches, having them separated out for easy & confident removal is a win for the user. (The user will be safer to know it's only cache).

I think that if we take this route we'd want to do the "best thing for the platform" in each case, so I wouldn't take the route of XDG everywhere on Unix (ignoring what OSX conventions are). To me any fragmentation is just as bad as lots of fragmentation, so I'm not worried about the degree of fragmentation along those lines.
I also think that it may not quite be as black-and-white as listing out pros/cons and seeing which bucket is bigger. The existence of fragmentation can have a multiplicative effect where all of Cargo's decisions affect downstream users and such. For example anyone wanting to write a tool against Cargo's directory layout or something like that would end up having to work with all this logic somehow as well to work across platforms.
I'd be curious on some other opinions from @rust-lang/tools as well, I have a feeling that @wycats in particular may have thoughts on this.

For example anyone wanting to write a tool against Cargo's directory layout or something like that would end up having to work with all this logic somehow as well to work across platforms.

Unless Cargo's directory layout is considered a stable interface, wouldn't any such tool have to invoke Cargo or use it as a library anyway?

@alexcrichton I didn't want to suggest to compare the number of pros and cons, as they can certainly be split up in different ways. I do however, still think that the benefits of 2) and 3) outweigh the solution for 1), especially 2) which is basically a pure improvement IMO (I think that 1) is consistency at the cost of Windows users, because there is virtually no program that stores its configuration in something like ~/.appname on Windows).

@whitequark perhaps yeah, but it's not unheard of to write a tool that lives for a few weeks or so (e.g. doesn't live until the end of time) and Cargo's layout would be "stable" within that time frame.

@alexcrichton to rephrase, I feel that this would be best addressed by allowing to reuse Cargo's persistency layer, if a consideration at all

I've been skeptical of using XDG in the past since dotfiles work everywhere, and the spec doesn't provide any motivation. I'd be very curious to know what XDG adoption looks like these days, whether it's a winning or losing standard (I still have lots of dotfiles and no XDG_* variables defined here in Ubuntu 14.04).
I big downside of supporting XDG with dotfile fallback is that users won't know where there stuff is.
I've rejected XDG for multirust before.
My inclination is to keep waiting.

@brson Note that you would normally not have the XDG_* variables set on Linux since the defaults per spec are what most people want anyway.
I can see that pretty much every standard desktop application I use (on Debian) respects XDG, as well as some 3rd-party applications (Sublime Text), although many other 3rd-party ones don't (most games) and of course non-GUI tool authors don't feel compelled to follow XDG at all...

@brson Look in ~/.config, ~/.cache, ~/.local/share and see if there's anything there :smile: A well behaved program should respect it in modern Linux IMO (this is my general opinion, nothing to do with cargo, something I held before cargo existed).

@bluss Ah. On a desktop I do have those directories. On my headless machine only ~/.cache exists with only one file in it.

I'm mildly in favour of this - it seems like an improvement and I would expect each platform to differ in this way so I'm not too worried about the fragmentation effect (it is of course not ideal). I would also be interested to know whether XDG is 'winning' though.

Some links that list support of applications:
https://wiki.archlinux.org/index.php/XDG_Base_Directory_support
https://wiki.gnome.org/Initiatives/GnomeGoals/XDGConfigFolders

Fedora has had a goal to make its desktop applications adhere to it: https://fedoraproject.org/wiki/Features/XdgConfigDirs
So Fedora & GNOME is the bastion of support I guess, even though many others support it too: XDG_Base_Directory_support / Arch Wiki
@brson Main benefits is the user experience. Separating config, user data and caches makes cache and backup management much simpler. Cargo has data of all these three kinds, and a pretty large cache that you don't want to backup
I think the “is it winning” is not the right question to ask for two reasons, 1) there is no alternative standard and 2) creating a better user experience doesn't really have any drawbacks. Separating cache from config and data is something that should be done anyway. The ~/.cache directory is normally automatically skipped in the default configuration of many back up tools.

@bluss I don't think it's 100% accurate to say there are no downsides, the lack of consistency across platforms and not knowing how to find the directory on an arbitrary platform without probing is a downside to me.

Yes, I understand. I wanted to underline that there are clear benefits of a better user experience too.

We chatted about this in the @rust-lang/tools triage meeting today, and the consensus was that we probably want to move forward with this. @nrc brought up an excellent point that in the long run most tools end up doing the most-platform-specific behavior as there's more and more pressure to do so. Additionally, it generally tends to mesh better with user's expectations.
@brson, curious what you think on that?

One part we did talk about though was that we'd want to see the OSX/Windows functionality here fleshed out before landing. @vadimcn I believe had a few more details on what we may want to do on Windows.

That's great to hear.
My plan was to use ~/AppData/Roaming/Cargo/ for the config (this is the directory that gets shared when you log in on different computers on the same domain) and use ~/AppData/Local/Cargo/ for the caches.
On OS X I would use ~/Library/Cargo/ for the configs and ~/Library/Caches/Cargo/ for the caches.
What I couldn't figure out was where to place the executables on either Windows or OS X, so if you have ideas concerning this, please tell me!

Just want to note that on Windows you are supposed to use the SHGetKnownFolderPath API, rather than hard-coding a specific path.
The standard location for per-user executables is $(FOLDERID_UserProgramFiles) which currently resolves to %LOCALAPPDATA%\Programs.  Before Windows 7 there was no standard location, most apps installed themselves somewhere under %LOCALAPPDATA%.
As for the cache directory, I wonder if %TEMP%\Cargo\Cache would be a better location, since it can be automatically cleaned-up by the Disk Cleanup Wizard upon running out of disk space.

@vadimcn Sure, we're not hardcoding the path on Linux either. Thanks for the place for executables!
It seems that %TEMP% cannot be accessed via that API though. What does it typically resolve to? Is it user-specific or systemwide?

@tbu-: for that Windows provides GetTempPath.  Normally, it's per-user, pointing to %APPDATA%\Local\Temp.

Hm. I can't find anything regarding the lifetime of files placed there on the documentation page. Ideally it'd be preserved by reboots, ignored by backup tools and could be cleaned by the Disk Cleanup Wizard.

All of the above is true, in my experience.

@tbu- for binaries on OSX using something like ~/Library/Cargo/bin seems like it should be fine as a fallback at least

@alexcrichton Factored out the platform-specific code into a library, added Windows and OS X support and rebased it onto master.

In dirs, could the errors on Windows be propagated upwards instead of being thrown away?
I also had some concerns above about how the xdg crate is a little eager when panicking, could those be addressed as well?

:umbrella: The latest upstream changes (presumably #2237) made this pull request unmergeable. Please resolve the merge conflicts.

I'm still concerned about the confusion it will cause for minimal benefit. The story for cargo install is going to be more complicated in particular - there are three different places one must know to look depending on platform.
Is there going to be any upgrade path? What happens to the existing .cargo folders?

there are three different places one must know to look

Can we guard against by having a way of finding out where Cargo installed? cargo install --where-did-you-put-my-binary. I much prefer being able to query stuff like this rather than having to know even a single thing.

Is there going to be any upgrade path? What happens to the existing .cargo folders?

Could questions, we should have answers!

Cargo will inform you to add a directory to your PATH if it's not already in there during cargo install, so via that you can discover where everything's being installed (unless you already have it in your PATH in which case it may not be that relevant?).
I do agree though that this puts a lot more pressure on a feature where through the CLI you can learn about the home directory Cargo thinks it's using.
For an upgrade path, this PR currently prioritizes $HOME/.cargo if it exists (e.g. it keeps using it). Only if it doesn't already exist does a new home get used.

Here's another problem. multirust/rustup.exe control $CARGO_HOME. With today's multirust, these directories will not be used. That's fine.
With the design of rustup.exe though, we're expecting all Cargo's to share their metadata, and for rustup.exe to know where that is. This means that either rustup.exe is going to have to preinitialize ~/.cargo to force all cargos to use the old scheme, or that it will have to not be backwards compatible with cargos that don't support the new scheme.
Part of the rustup.exe plan was also to share the $CARGO_HOME directory, putting .rustup under $CARGO_HOME/.rustup (basically, everything Rusty was to go under $CARGO_HOME). With this scheme I no longer think this is a good idea, partly because it's harder and less reliable to find cargo's metadata, partly because it's split out by kind of metadata, so putting other programs dotfiles in one of the various metadata locations doesn't make sense.

@brson I don't know enough about the rustup.exe plan to be sure, but it sounds to me that having "everything Rusty" in one place is not a viable long term plan. People will want strange configurations for all kinds of strange reasons and there will be strange platform-specific requirements which we don't know about yet.
IMO, a programming language should try to accommodate the platform it is running on, not try to layer it's own platform on top. Java tried this and despite being wildly successful, this was a pain point which hindered use and something they moved away from more and more as time went by.

Is there an alternative way to solve the cache directories issue? We want it to be simple to purge cargo cache and to exclude it from backups. For N applications it really is easier if they all use the same cache root than having to add N configuration items to your backup tool.

Is there an alternative way to solve the cache directories issue? We want it to be simple to purge cargo cache and to exclude it from backups. For N applications it really is easier if they all use the same cache root than having to add N configuration items to your backup tool.

For an upgrade path, this PR currently prioritizes $HOME/.cargo if it exists (e.g. it keeps using it).

This may make it difficult to remove ~/.cargo eventually. Another option is to move stuff from ~/.cargo to ~/.cache / ~/.config on the first launch and add some symbolic links for backwards compatibility.

For an upgrade path, this PR currently prioritizes $HOME/.cargo if it exists (e.g. it keeps using it).

This may make it difficult to remove ~/.cargo eventually. Another option is to move stuff from ~/.cargo to ~/.cache / ~/.config on the first launch and add some symbolic links for backwards compatibility.

@matklad That's very intrusive. A better method would be to warn in future if you use ~/.cargo and deprecate it entirely one day.

@brson
Hm yeah that's a good point thinking about rustup.exe plans. I think it may be able to mesh well here, however? For a brand new system, this basically means that Cargo's "home directory" would need to be discovered though the same logic that Cargo has (e.g. this dirs crate). I'd imagine that rustup could either use this or just always set CARGO_HOME whenever it delegates to a Cargo binary.
It may not be particularly crucial that rustup installs itself to a globally known location (e.g. ~/.foo unconditionally) because one of the main points of rustup.exe is "you don't have to worry about this". It'll add itself to PATH as necessary and such.
@nrc
While I agree that we should accomadate the platform at hand, I don't think that should ever come at the cost of user experience. Along those lines I wouldn't take that as an ironclad guiding principle. In this case with Cargo, however, and I think with rustup as well, we can get this kind of configuration with little-to-no cost in terms of experience.

I'm not clear on how .cargo/config works in this scheme. Since this crawls the tree, would the best practice be to use .cargo/config  for override single projects, but use e.g. AppData\Roaming\Cargo\.config for overriding all projects?
How does AppData\Roaming\Cargo\.config behave? In the dotfile world doesn't this file override everything 'beneath' it in the file tree. I would imagine people don't do their development in AppData\Roaming.
If you don't want to deal with the platform-specific config and just put it in ~/.cargo/config is cargo going to get confused about whether it should use ~/.cargo  for all its metadata, or will it ignore ~/.cargo/config when deciding which metadata format to use?

Should I duplicate the path finding functions for the tests or should I make them less fine-grained?

@brson we've actually already got some custom code to handle that case (e.g. the "home directory" is special).
If you put configuration in ~/.cargo/config Cargo will just use it if you're working anywhere under ~ which is pretty likely. That'll just have more precedent than Cargo's platform-specific home directory.

@tbu- I'm not sure I understand? There are no tests here?

The tests are still failing because they check for the old location, e.g. tests/test_cargo_install:48-49. I'm unsure how to fix this, should I call the paths function from the tests or should I replicate that functionality within the tests?

It's fine to just set CARGO_HOME for those tests

:umbrella: The latest upstream changes (presumably #2282) made this pull request unmergeable. Please resolve the merge conflicts.

@alexcrichton I have rebased the pull request and fixed the tests. Should I squash the commits?

:umbrella: The latest upstream changes (presumably #2297) made this pull request unmergeable. Please resolve the merge conflicts.

Ah yes, sorry I meant to get back to this a little earlier. I had a chance to talk with @wycats about this recently and here were some thoughts we had (in addition to what's previously been mentioned here)

It's suspected that the "convention" of putting things in ~/Library on OSX is all-but-nonexistent, and this is likely to extend to other platforms where the "convention" here isn't necessarily universally adhered to because there unfortunately isn't necessarily a convention one way or another.
One very nice part about ~/.cargo is that it's very nice to know how to "blow everything away and start from scratch". With a scheme that puts directories in a few places this gets a little more questionable.
For external tooling, it's likely required to introduce a cargo home command in tandem with this. And something I also just realized is that on Linux there will no longer be a "home directory" for Cargo, right? It's sharded in a few locations? That would make this cargo home command a little more interesting...
Creation and usage of ~/.program-name is almost universal throughout various apps on Linux. This means that flavorful environments (e.g. things like Heroku, docker, qemu, stripped-down-scenarios, etc) which aren't your standard desktop will generally try to ensure that this sort of location "Just Works" to be maximally compatible with existing programs. By moving to a custom location, it becomes less likely that Cargo will work "out of the box" if it tries to put configuration or caches in a location that's, for example, read only, not mounted, etc.
It may not always be expected that the Cargo we ship adheres to these conventions. Arguably the Cargo shipped by Linux distros should be configured to support the various local configuration that is expected, but not necessarily what we ship ourselves. This would entail a variety of ./configure flags, perhaps along the lines of "choose this spec" or "always choose this location" or something like that.

Overall it sounded like @wycats was pretty hesitant to move forward on this, and I think some of the new points brought up here are also quite persuasive.

I don't know about OS X.

One very nice part about ~/.cargo is that it's very nice to know how to "blow everything away and start from scratch". With a scheme that puts directories in a few places this gets a little more questionable.

One very nice part about putting the cache into the folders designated for caches means that existing tools (backup, etc.) work at all together with Cargo. It's true that restarting from scratch might get harder, but if we introduce a cargo home subcommand, then it's not really a problem anymore. Also, what would you use on Windows? Using .cargo is pretty much out of question there (IMO), because that's using a unixy paradigm on a foreign system.

Creation and usage of ~/.program-name is almost universal throughout various apps on Linux. This means that flavorful environments (e.g. things like Heroku, docker, qemu, stripped-down-scenarios, etc) which aren't your standard desktop will generally try to ensure that this sort of location "Just Works" to be maximally compatible with existing programs. By moving to a custom location, it becomes less likely that Cargo will work "out of the box" if it tries to put configuration or caches in a location that's, for example, read only, not mounted, etc.

I really see no reason why the XDG directories would work any less "out of the box" than "~/.cargo". Can you elaborate?

It may not always be expected that the Cargo we ship adheres to these conventions. Arguably the Cargo shipped by Linux distros should be configured to support the various local configuration that is expected, but not necessarily what we ship ourselves. This would entail a variety of ./configure flags, perhaps along the lines of "choose this spec" or "always choose this location" or something like that.

Yes, it's pretty much us ("the Cargo developers") who are expected to make Cargo adhere to standards. E.g.: https://wiki.archlinux.org/index.php/XDG_Base_Directory_support#Supported.

Yeah we definitely agree that there are some benefits (like with backup solutions), but the question is whether it's worth the tradeoffs. If no one's really sure of what happens on OSX, then we should probably continue doing what we're doing today there. On Windows it sounds like we're also a little unsure? There doesn't seem to be a clear answer to "yes this is where the directories should be", but conversely there's also nothing saying "no, you should never put directories there".

I really see no reason why the XDG directories would work any less "out of the box" than "~/.cargo". Can you elaborate?

I think @wycats may be able to add more here, but my understanding is that it's just "one more layer" which may not be guaranteed to work. It's often difficult to imagine these sorts of situations, but there are so many embedded flavors of Linux around that any configuration is bound to exist somewhere, and there are bound to exist configurations where xdg doesn't work but just using the home directory does.
Put another way, the use of XDG only seems "clearly correct" for distributions themselves, not necessarily for any Cargo binary running on a linux kernel.

Yes, it's pretty much us ("the Cargo developers") who are expected to make Cargo adhere to standards. E.g.: https://wiki.archlinux.org/index.php/XDG_Base_Directory_support#Supported.

Unfortunately I don't think link does much to answer the question, though. There's nothing indicating that this shouldn't be an off-by-default but turned-on-by-packagers kind of behavior.

and there are bound to exist configurations where xdg doesn't work but just using the home directory does

But, as used by cargo, both strategies "just use the home directory", at least for the user data. There's nothing special about ~/.local or ~/.config that fundamentally differentiates it from ~/.cargo.

I feel, that this PR is missing a point. Standardized locations aren't used, because they are standard, but because they are convenient:

Windows standard directories aren't meant for human users (look at those horrific paths!), but for utilities (see previous comments) to manage caching, domains and app uninstallation. This is handy, but does not make users' lives much easier.
In contrast, XDG user directories aren't touched by package managers. They are meant for users themselves (e.g. they make it possible to quickly wipe ~/.cache and de-bloat HOME)
I am not very knowledgeable about Mac OS X, but the situation there is, probably, similar; nobody just puts things somewhere because that's standard.

As such, I do not see any reason to have distinct cargo_bin. A user-configurable CARGO_HOME is enough. Moving things to ~/.local/bin just makes them harder to find.
Anyway, what is there do disagree about? All systems, supported by Rust, have symbolic links.
IMO, it makes most sense to leave current layout in place, but replace some of dirs by symlinks to more fitting places (~/.config, ~/.cache etc).
If done, this should be clearly communicated to users and, probably, followed by creation of uninstaller to remove those directories (because simple rm -r ~/.cargo won't do anymore). For this reason, I do not thing, that anything besides cache directory should ever be moved by default or without notifying a user during installation.

@alexcrichton I believe on Windows the situation is clearly: Don't put the application data (caches) into the home directory. AppData is the way to go there, and the added Temp (which might present the uncertainty), is just an extra to ensure that it can be cleaned by the disk something wizard.

Unfortunately I don't think link does much to answer the question, though. There's nothing indicating that this shouldn't be an off-by-default but turned-on-by-packagers kind of behavior.
Well, since Arch Linux generally ships the exact upstream, it's clear that they want upstream to support XDG.

I think @wycats may be able to add more here, but my understanding is that it's just "one more layer" which may not be guaranteed to work. It's often difficult to imagine these sorts of situations, but there are so many embedded flavors of Linux around that any configuration is bound to exist somewhere, and there are bound to exist configurations where xdg doesn't work but just using the home directory does.

I'd like to hear more about that, because currently this is pretty unclear to me. On a normal system, the "XDG" directories are just longer path names, namely "~/.cache/cargo", so it is supported exactly when the home directory is known.

As such, I do not see any reason to have distinct cargo_bin. A user-configurable CARGO_HOME is enough. Moving things to ~/.local/bin just makes them harder to find.

If you have them in ~/.local/bin, you don't have to configure your path to include every programming language package manager you have.

Anyway, what is there do disagree about? All systems, supported by Rust, have symbolic links.

Except for Windows, where they can only be created by administrators.

IMO, it makes most sense to leave current layout in place, but replace some of dirs by symlinks to more fitting places (~/.config, ~/.cache etc).

This sounds like a good compromise to me (except that it still clutters the home directory with .cargo), but still, I really like that idea.

While we can't create symbolic links on Windows, we can create directory junctions, which as far as I can tell are just as good.

Ah, didn't know these.

If you have them in ~/.local/bin, you don't have to configure your path to include every programming language package manager you have.

Sigh. I am unaware of any part of XDG spec, that specifically suggests putting binaries somewhere. I am also unaware of any distribution, adding anything within HOME to default user PATH (please correct me if I am wrong).
Putting binaries in the same place under HOME may be convenient, but only as long as you do not make that into standard, and I would strongly oppose any such standard. It would be as insecure as adding . (e.g. the current directory) to PATH—too easy to screw up. Some well-meant app would cleverly put something there without my knowledge, and the next command I type leads to unpredictable results. There is a reason, why people kept using /usr/local/bin for binaries even when the threat of viruses etc. have been nearly non-existent.
For those reasons I would prefer Cargo to request elevation and put any executables under /usr/local/bin by default, and only symlink there from cargo/bin. If that is not possible/feasible, put them under cargo/bin, but please do not pick any directory path, too long to type with each command or too well hidden to quickly find in file manager.

While we can't create symbolic links on Windows, we can create directory junctions, which as far as I can tell are just as good.

Yes, the exact type of link to use in this case seems irrelevant.

:umbrella: The latest upstream changes (presumably #2339) made this pull request unmergeable. Please resolve the merge conflicts.

@Alexander-- Not part of the XDG spec, but the second link in the PR: http://www.freedesktop.org/software/systemd/man/file-hierarchy.html.

This is an example of possible breakage from following these sorts of environment variables. It could be the case that someone invokes cargo with a new HOME variable expecting output to go in that location, but other environment variables (not specific to cargo) can end up thwarting that.

Mh, fair enough, that's definitely a breakage from starting to follow XDG specifications where you previously did not. "The sooner the better?" Your link might even provide some more motivation, even git is doing it (which definitely isn't a desktop application).

To me, being able to backup your cargo folder without copying cache files is the best reason to want this, and that could be achieved by changing the cache location to be platform-specific, possibly optionally. There's less reason to care where cargo stores its internal cache than its configuration.

It would be as insecure as adding . (e.g. the current directory) to PATH—too easy to screw up. Some well-meant app would cleverly put something there without my knowledge, and the next command I type leads to unpredictable results.

@Alexander-- I like this point, that encouraging $PATH to include somewhere user-writable weakens security (probably, I'm not sure). I assume that there are precedents in dynamic language package managers that default to non-global installation, but don't know that.
We're definitely are encouraging $CARGO_HOME/bin to be part of the search path. Even if it's not, cargo will run anything there that starts with cargo-, and multirust installs binaries to user-writable places. There are several opportunities to inject code into Rust if you have local access.

It'd be strange to use Cocoa conventions on OS X for something that isn't built with Cocoa and isn't pretending to be a native .app.

If no one's really sure of what happens on OSX, then we should probably continue doing what we're doing today there

It'd be strange to use Cocoa conventions on OS X for something that isn't built with Cocoa and isn't pretending to be a native .app.

Yeah, on OSX, ~Library is only used by graphical applications. Command-line applications usually use the same directory structure as on Linux. That is also what brew and brewed command-line tools do.

I've just discovered this PR; on Linux I like the old behaviour better (being able to wipe or backup a single directory) so hopefully it all ends up on an opt-in/opt-out basis.

A use case on an SD based ARM system - operate entirely in ramdisk after decompressing a cargo tarball (.cargo contains  everything incl. overrides) then just wipe the directory. Much faster and doesn't trash the card.

@petevine It's opt-out, you can use the environment variable CARGO_HOME.

@alexcrichton What's the status of this pull request? It seems that there's quite some controversy on changing the Linux behavior. Could we land the Windows version? The situation there is worse than the Linux one: We use the standards from a different platform (dot directories, which don't even interact correctly with the Windows Explorer, e.g. you can't name a file with a leading dot). See also https://internals.rust-lang.org/t/beta-testing-rustup-rs/3316/21.

@tbu- Of course you can name a file with a leading period, you just have to trick explorer into doing it by naming it .foo. and it'll automatically convert it to .foo and work just fine.

@retep998 Oh, nice trick. I did not know that one when I tried to create .gitignores. :)

Some people in this thread have wondered whether Cargo would be the first package-manager to follow the XDG spec for per-user installation, and whether that would cause user confusion. For what it's worth, Python has looked for installed libraries in ~/.local since Python 2.6 (2013), and the Python package manager ("pip") has a ticket for installing there by default. Although that change hasn't landed in the official tree, apparently Ubuntu have already patched their build and Debian will have the same change soon. Even without that change, pip stores its config in ~/.config and caches downloaded packages in ~/.cache (both since the end of 2014).
As for ~/.local/bin not being on the default $PATH, apparently it is in Fedora, there's a ticket to make the same change in Debian.

I think @wycats may be able to add more here, but my understanding is that it's just "one more layer" which may not be guaranteed to work. It's often difficult to imagine these sorts of situations, but there are so many embedded flavors of Linux around that any configuration is bound to exist somewhere, and there are bound to exist configurations where xdg doesn't work but just using the home directory does.

You expect people to be using Cargo, a program that exists to download source code and drive a compiler, on embedded controllers?

@notriddle The standard uses a hardcoded directory .config unless an environment variable is set. It's unclear which of these steps shouldn't work on "embedded Linux".

On OS X, use ~/Library/Caches/Cargo for cache files, ~/Library/Cargo
for config files and ~/Library/Cargo/bin for binary files.

I'm on OS X. How is this an improvement? I don't really care where my cache files end up, but what's the justification for moving my files out of ~/?

The standard uses a hardcoded directory .config unless an environment variable is set. It's unclear which of these steps shouldn't work on "embedded Linux".

I don't understand why people are concerned about cargo working on embedded Linux anyway. You need to be able to run the resulting binaries, but this won't affect them.

@frewsxcv These paths would still be inside your home directory (note the ~, it stands for the home directory of the current user). But you should probably rather look at the RFC for discussion: rust-lang/rfcs#1615.

These paths would still be inside your home directory

I meant directly in the home directory, not a subdirectory.

@frewsxcv,

I meant directly in the home directory, not a subdirectory.

Things are never installed directly in the home directory. Currently they are installed in subdirectory called ~/.cargo. That is the old Unix ad-hoc approach that lead to zillions of .something files and directories in your home. The proposal is to instead put them under ~/Library, which is where MacOS native applications put things for sake of consistency (with other applications on each platform rather than between platforms, because platforms are not consistent with each other anyway). and to avoid adding to that zillion of .something items.

@jan-hudec Please go to rust-lang/rfcs#1615, the discussion is happening there.

Closing in favor of the RFC for now (clearing out the queue)


Add support to "name" Pipeline stages and reference them by name

Motivation
Different stages of a pipeline may have meaningful names associated with them, and logic from within or outside the pipeline may want to access a certain stage's signal by name rather than absolute index.  This helps make refactoring pipelines even easier, since adding a stage will not modify stage names.
Desired solution
Add to or extend functionality of Pipelines to support naming stages.
Additional details
Some thought has to be put into where the name goes and what the type of the name should be.  Should it always be a String or should it be parameterized so that an enum could be used?  The current implementation is a List<List<Conditional> Function(PipelineStageInfo p)>, so modifying the input to Pipelines to accept some new List or a Map would be a significant API change, but maybe it is appropriate so that more functionality can be more easily added in the future.

When creating this, we can also add new capabilities like adding the stall signals as part of the stage themselves instead of as a separate input into the Pipeline abstraction.
Can we extend Function to maintain backwards compatibility or is that not reasonable/possible?


Package>>Add Package menu item disabled?

When I first opened the browser, the Package>>Add Package menu item was enabled and brought up the dialog and saw that I needed to supply a component name ... once I figured out which component name I wanted to used, the  Package>>Add Package menu item was disabled.
Closing and re-opening the project browser, it seems that the add package menu item is only enabled when no project is selected?

Not a priority, I just wanted to use it if I could :)

The conditional logic was backwards. Fixed in the aforementioned commit.


AGENTs not recognized by ROS-Rviz

Hi the Agents of SVL simulators are not being recognized by ROS-Rviz.
I believe there is something missing on ~/shared_dir/autoware-data/BorregasAve/my_launch/my_sensig_simulator.launch script regarding LaserScan data to update the map, specifically Publish data on nav_msgs/OccupancyGrid topic.

The issue with videos can be seen here:
https://github.com/lgsvl/simulator/issues/1401
https://answers.ros.org/question/377308/autowareai-perception-failure-agent-not-detected-in-rviz/
https://get-help.robotigniteacademy.com/t/perception-failure-in-rviz/9699
I believe the solution to have this fixed would be something similar to this:
https://answers.ros.org/question/367056/costmap_generator-workbut-it-topic-semanticscostmap_generatoroccupancy_grid-do-not-have-data/?answer=377423#post-id-377423
Is there a script available to use that launch a publisher to nav_msgs_OccupancyGrid topic with the already converted Velodyne/Point_Cloud to LaserScan data?
Thanks in advance

@marcusvinicius178 Per our [Support Guidelines[(https://github.com/Autoware-AI/autoware.ai/wiki/Support-guidelines), please post unconfirmed bugs and support requests to ROS Answers with the autoware tag.


Resize group when the cgDescription is updated.

I cannot reproduce the error

It wasn't working when I report it. Seems to be fixed, I'm closing.


url update

The url may need be updated to this: https://vital.engineering.nyu.edu/vital/

We have updated the url in the wiki.


Context menu not fully visible when titleBarStyle is "custom"

VSCode Version: 1.25.0
OS Version: Win10 x64 10.0.17134.165

Steps to Reproduce:

Set "window.titleBarStyle": "custom"
Restart so the setting is effective
Open a file that is long enough to fill the whole editor window
Right click in the editor near the bottom

Expected: The context menu appears and is fully visible
Actual: The context menu's top is at mouse pointer location, and is only partially visible due to the location.

Does this issue occur when all extensions are disabled?: Yes/No

duplicate of #52533


feat: scroll current file into the view

Actually we open all the needed folder until the currentFile but we don't scroll until that file to see it in the view
I proposed to use scrollIntoViewIfNeeded unless we are on Firefox as it's not supported and use scrollIntoView instead.

Thank you so much for your contributions to this project; I’ll merge and deploy!
Would you be interested in becoming a maintainer of the project and having direct access to merges? You’re doing excellent work, and this would allow you to quickly make your changes available on npm. I have nothing to add every time!


Need to update Teams icon for MW

Bug Report
Steps
A clear and concise description of steps to reproduce the problem.
Expected Result
The result that you expected.
Actual Result
The actual result that happened 💣
Version
x.y.z
Testcase

@notandrew, do we have already the new icon so that we can update it?

@alinais - I don't think it's in Stardust yet...

It's not in Stardust, but we do have the new icon from design.


Fix for long-running tsan test

Fixes #3934

On my linux workstation, prior to this fix:
time ./bins/tsan/gpr_cpu_test
D1028 14:27:10.358874865    9756 test_config.c:155]          test slowdown: machine=1.000000 build=10.000000 total=10.000000
Saw cores [0,1,2,3,4,5,6,7,8,9,10,11,] (12/12)
real	4m26.233s
user	42m47.855s
sys	0m3.674s
(no wonder it was timing out...)
And after:
time ./bins/tsan/gpr_cpu_test
D1029 10:06:52.988625265   31257 test_config.c:155]          test slowdown: machine=1.000000 build=10.000000 total=10.000000
Saw cores [0,1,2,3,4,5,6,7,8,9,10,11,] (12/12)
real	0m8.637s
user	1m17.743s
sys	0m0.471s


Plugin compilation errors and development suggestions

Hey, I watched your web demo and your plugin is just so cool.
But I encountered the following error when compiling the plugin.
jutils.inc(191) : error 101: fixed dimensions must be after the array name, not on the type
 error 417: cannot read from file: "l4d_info_editor"

I noticed that the contents of the jutils.inc file are missing, did you forget to upload it? Also, can you provide l4d_info_editor.inc file？
Suggestion: I think the number of points that players can earn can be modified with convar, which will allow you to have more flexibility in your plugin, such as adapting to different game difficulties and mutation modes.

My actual development of this plugin is done in my sourcemod-plugins repo folder, so sometimes the dependencies in this repo get over looked and outdated, so take a look there if there's something missing or outdated.
I pushed the l4d_info_editor and updated jutils.
I'm actually planning to entirely redo the points system to be computed live by the webserver instead of incremented in-game but I only work on this periodically. Might be easy to let you configure the weights of every statistic it pulls from a config file, we will see.

Awesome, thanks for explaining in detail, you will do it to the next level

Another error occurred when the plugin was compiling l4d2_stats_recorder.sp, I didn't find a workaround on the web, how do I fix it?
\Souecemod\1.11\left4dead2\addons\sourcemod\scripting\include\stats\heatmaps.sp(270) : error 105: cannot find method or property "Game.name"
//
// 1 Error.
//
// Compilation Time: 0.81 sec

It works!
`//SourceMod Batch Compiler
// by the SourceMod Dev Team
//// l4d2_stats_recorder.sp
//
// D:\YangZhixun\OneDrive - 陕西科技大学\求生之路\Souecemod\1.11\left4dead2\addons\sourcemod\scripting\include\stats\heatmaps.sp(220) : warning 203: symbol is never used: "type"
// Code size:         80912 bytes
// Data size:         40316 bytes
// Stack/heap size:      20604 bytes
// Total requirements:  141832 bytes
//
// 1 Warning.
//
// Compilation Time: 0.89 sec
// ----------------------------------------
Press enter to exit ...`

It works !Thankyou
`//SourceMod Batch Compiler
// by the SourceMod Dev Team
//// l4d2_stats_recorder.sp
//
// D:\YangZhixun\OneDrive\Souecemod\1.11\left4dead2\addons\sourcemod\scripting\include\stats\heatmaps.sp(220) : warning 203: symbol is never used: "type"
// Code size:         80912 bytes
// Data size:         40316 bytes
// Stack/heap size:      20604 bytes
// Total requirements:  141832 bytes
//
// 1 Warning.
//
// Compilation Time: 0.89 sec
// ----------------------------------------
Press enter to exit ...`

It works,thankyou!
`//SourceMod Batch Compiler
// by the SourceMod Dev Team
//// l4d2_stats_recorder.sp
//
// D:\Souecemod\1.11\left4dead2\addons\sourcemod\scripting\include\stats\heatmaps.sp(220) : warning 203: symbol is never used: "type"
// Code size:         80912 bytes
// Data size:         40316 bytes
// Stack/heap size:      20604 bytes
// Total requirements:  141832 bytes
//
// 1 Warning.
//
// Compilation Time: 0.89 sec
// ----------------------------------------
Press enter to exit ...`


fix: Add ability for Netlify to hold API key as environment

Fixed netlify build script. Note that building with netlify env variables need to be outside quotation marks ('').
See self-closed support thread for more context


FR transparency painting (half-blocks, background-color transparency)

This program features layers, includes "alpha" transparency, and allows the user to delete tiles from an image layer to render those areas as "transparent". However, unless I am mistaken, there does not currently appear to be a means of directly selecting "transparent" as a color; it cannot be selected from the color palette for the half-block brush, nor can it be selected as a background color when drawing with shade or character brushes. When it comes to half-blocks, the only apparent means I can find to draw half-block transparency in either orientation (horizontal or vertical) is as follows:

Draw a solid block of foreground color 0 (default: black).
Use the half-block brush to draw a half-block of any other color in either part of the tile, which causes the other half to disappear;
Use the half-block brush to draw the color you want (if you did not already do so), and/or use the Switcher tool to change the half-block from horizontal to vertical.

While this does work, it is obviously not an efficient way to do so. It would be better in this program with image layers if one were able to draw with the "transparent" color directly. I will be happy to be proven incorrect in assuming this feature isn't already in the program, if there's something I'm missing somewhere.

The transparent color in the half block feature was a last minute hack and not a proper feature.
Y transparent color is on the to do list and will surely have it's uses let's say in animations. Would be possible to make awesome effects with that :-).


Full file content search

Add full text search using existing database.
Create a new table with text BLOBS.
Each searched file will have it's own UUID and will be linked to files.uuid using one-to-many.
Read plain text files such as an NFO and have all non-standard characters removed such as borders and multiple tab spacing.

Moved to projects


Nutanix Rancher Node Driver

Integrate Nutanix Rancher Node driver in the default node drivers provided by Rancher.
It should not be enabled by default.

https://github.com/nutanix/docker-machine
We need to add the node driver to rancher https://github.com/rancher/rancher/blob/908854bfedf1f8ddadb87453f4a162aaf37a86be/pkg/data/management/machinedriver_data.go
additionally we will need to define the public and private fields for the driver here https://github.com/rancher/rancher/blob/908854bfedf1f8ddadb87453f4a162aaf37a86be/pkg/data/management/machinedriver_data.go#L35
this will require a UI issue as well to create the forms in the  UI for the driver.

@paynejacob , there is already PR for this which also has Ember UI part linked - https://github.com/rancher/rancher/pull/35348 (should have linked it earlier).
Whether we're doing Vue (dashboard) UI is TBD at this time.

@tuxtof , merged your PR and moved this issue to test. Since your team is handling testing, could you or anyone from your team please test it on v2.6-head and confirm it's working as expected?

@snasovichjust deploy a v2.6-head rancher, driver is here , enabling is OK, deploying cluster create correctly the VM, was just blocked due to some container missing in my env
do we have a doc to fully deploy a working dev branch based instance

@tuxtof , could you please clarify what you mean by a "doc to fully deploy a working dev branch based instance"?
You can do single node Docker install following the docs here: https://rancher.com/docs/rancher/v2.6/en/installation/other-installation-methods/single-node-docker/
Just use rancher/rancher:v2.6-head image to use the latest successfully built image from release/v2.6 branch.

@snasovich
i correctly deploy the builded commit with the classic single node docker approach no problem with that
my question was more to deploy a cluster with this builded branch
as he try to pull a rancher/agent:commit i put everything in a private repo and configure the cluster to use it
but it seems it don't work

that's why i ask if there is a specific doc

@tuxtof , I'm not sure I'm following exactly what you're running into.
Could you please share the exact reproduction steps?
Also, since there seems to be an issue with the agent, could you please share logs from cattle-cluster-agent-... pod?
Lastly, just a few hours ago we've put a change to default v2.6-head Rancher to use v2.6-head agent: https://github.com/rancher/rancher/blame/release/v2.6/pkg/settings/setting.go#L26 - so maybe that will ensure you're using the agent image you're expecting?

@snasovich i just test with v2.6.4-rc6 binary release and all works perfectly
so i think we can close this issue
for info
i also test building f2a4147cf and i have a new issue
kubernetes version dropdown list is empty

@tuxtof , great to hear it's working fine for you.
Regarding the other you're reporting, I'm not seeing it myself. Could you please share more about how you've reproduced it?
k8s versions dropdown values come from request to /settings API call the browser makes and the resulting JSON should have a setting named k8s-versions-current. Could you check this on your setup?

procedure to reproduce it
run on a fresh Ubuntu 21.04/docker 20.10.12
gh repo clone rancher/rancher && cd rancher
git checkout f2a4147cf
make
docker run -d --restart=unless-stopped -p 80:80 -p 443:443 --privileged rancher/rancher:f2a4147cf
a /settings return

for info i test with a more recent commit and no more issue
you can close this issue in all case

@tuxtof , this may be due to Rancher not picking up KDM data yet since your versions data is empty. There is a URL that Rancher polls to get data like k8s versions, so maybe polling didn't happen properly for some reason (e.g. bad URL).
It's configured in settings like shown on screenshot below:

Given that you confirmed it's not reproducible on newer versions and the fact you confirmed Nutanix node driver is working as expected, closing this issue.


New Options in Settings Tab for v1.15 are not translated (x7)

New UI elements up to Atom v1.15 (currently beta) are added to settings page.
New i18n Items are added according to this commit:
settings.cson

core.closeDeletedFileTabs (x2)
desc of core.restorePreviousWindowsOnStart (x1)
core.useProxySettingsWhenCallingApm (x2)
editor.showCursorOnSelection (x2)

progress

[ ] de/settings.cson
[x] es/settings.cson (#48)
[x] ja/settings.cson (#113)
[x] ko/settings.cson (#49)
[x] zh-cn/settings.cson (#54)

#47 and #100 seem to complete the issue, can it become closed?

@polynoman thanks for your hard work 🙏
Will close this after #100 is merged


loose the validation on istioctl to allow users to pass config

With latest 0.8 build on 5/30, I can't get the istioctl work when passing my own config file:
$ istioctl kube-inject --injectConfigFile inject-config.yaml -f bookinfo.yaml
Error: --injectConfigFile and --injectConfigMapName are mutually exclusive

~/Downloads/istio-0.7.1/samples/bookinfo/kube ⌚ 15:16:38
$ istioctl kube-inject --injectConfigFile inject-config.yaml --meshConfigFile mesh-config.yaml -f bookinfo.yaml
Error: --injectConfigFile and --injectConfigMapName are mutually exclusive

i don’t think we need this check as this check will not allow users to specify its own injectConfig file.
I am able to generate the injected config after removing the check.
$ ~/go/out/darwin_amd64/release/istioctl  kube-inject --injectConfigFile inject-config.yaml -f bookinfo.yaml > bookinfo-v2proxy.yaml

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: linsun
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

istioctl/OWNERS [linsun]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/lgtm

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: linsun, mandarjog
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

istioctl/OWNERS [linsun,mandarjog]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@linsun: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-simpleTests.sh
22c48375af4cad03859d1226f3545f9c3473564c
link
/test e2e-simple

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Additional channel configuration

Problem description
Some hosts (e.g. Artifactory) don't seem to serve proper metadata for the zst or bz2 files.
We would like to attach this information to the channel in the pixi.toml so that pixi is forced to fetch the right files.

There is some ongoing work in rattler: https://github.com/mamba-org/rattler/pull/530 (cc @baszalmstra maybe you mulled over it for a bit? :) )

Yeah I think we will have to split this information into seperate objects. FetchChannel that includes both a Channel (for the urls) and extra metadata with regards to which artifacts are not available.

Maybe related to #172?

We are also affected by this issue, it would be great to be able to configure pixi to ignore compressed metadata.

https://github.com/prefix-dev/pixi/issues/172#issuecomment-1968832574

@wolfv This is done right?


Add -HA option in installation and prepare script

code is ready , will pending on review.

Hi @yixingjia, which is the pull request link ?


Laravel 5.5 Support

Hello,
This pull request includes support for laravel 5.5.
Cheers,
Gabriel

Coverage decreased (-6.0%) to 87.515% when pulling 4f22a47ca76be0b234436894e3f2a8a0147d54ad on gtapps:5.5 into fcc6415b21f099cca18eb6311aa6817328597a60 on jarektkaczyk:master.

BTW once you also merge the pull requests on "sofa/hookable" you can edit this current composer.json to not point to my hookable package that also required a few tweaks to support laravel 5.5.

maybe you should rebase on top of master and push it again.
tests are failing

@gtapps Are you planning on moving forward with this PR or not?

Hello guys,
This pull request has a few broken things, there are even more changes required to work with laravel 5.5 after testing it a lot more. So this is not a good base to start with after testing it.


Dash Stream Keeps on buffering using Shaka Player but Works fine on dash.js player

Can you reproduce the issue with our latest release version?
Yes
Can you reproduce the issue with the latest code from main?
yes
Are you using the demo app or your own custom app?
Using demo app
If custom app, can you reproduce the issue using our demo app?
Yes
What browser and OS are you using?
Chrome 113.0.5672.127 and Windows
For embedded devices (smart TVs, etc.), what model and firmware version are you using?
  What is the output of player.getConfiguration()?
Default
What did you do?
Played this MPD file on shaka player demo app and also on dash.js
What did you expect to happen?
Stream should play normally just like
What actually happened?
When I loaded the url on shaka player it cloud make few initial call but later on it kept on buffering
Are you planning send a PR to fix it?
No

Please provide a url of your manifest!

Hey here is manifest url and drm key
manifesturl --- https://org-007-jc.jiotv.com/DASH/c6c85efdd3b94501aad9f13959b40155/1721103366/baseline-std-v4/1556784378_WWE_RAW_MULTI_16072024_eng_baseline-800300010.mpd?contentId=1000283005&cpCustomerId=2408160919156963323&deviceId=1234&partner=JIOTVVOD&partnerId=1556784491&platform=ANDROID_PHONE&user-agent=jiotv&sku_name=Jiotv_feed_to_vod&hdnea=st=1724305314~exp=1724308914~acl=/DASH/c6c85efdd3b94501aad9f13959b40155/1721103366/baseline-std-v4/*~hmac=33e188789d1c8d98c13781142468a5fb3e67d9ccd1886edc1e601b6769f5d4ef
drm - https://wv.service.expressplay.com/hms/wv/rights/?ExpressPlayToken=BwA2T1gfKZcAJDFhZWU2MmNiLTA2YzQtNDFmZC1iZjdkLWRhZDg2NWFlNWNmYwAAAIAfhFpw2MYBPECGwUY7ZiZrTSem39VoRUE2bGI5nyzvg2DuoSPbn6aY4kE_AM2ZHV0dUb4Jt_Kdr61nela6wO4vXHMM2JNSxrmwLAtENXPOyOs54EMzbuX6ZuCPOzi6x7zojoxqySK-CpAj5-yOC8cQcGaBKISBD3uvJ_hiPEiyjFHGKL5Mdk760b1YPhFLHxj7274a

Your stream returns 451...

Seems like stream URL or the HMAC token used to access it is no longer valid. Seems like it expires after a hour.

As a beginner learning about streaming services, I'm trying to understand why dash.js can play stream while Shaka Player fails to do so. Can we draw any conclusions from the static manifest file shared above ?

Maybe related to https://github.com/shaka-project/shaka-player/issues/7174

I noticed that #7174 was merged into the main branch, but I’m still encountering the same issue after building from main.

Regression introduced by https://github.com/shaka-project/shaka-player/pull/7157

I'm encountering an issue with a DASH VOD stream. Although the stream plays successfully on Dash.js, it generates a "Possible encoding problem" error. I would like to know if it is possible to play this stream using Shaka Player as well.
Previously, I was repeatedly facing an issue where the segment end time could not be found, but this was resolved with the recent fix from the #7157 revert.

Hello @avelad , Is it possible to recover from encoding problem ? Any suggestions ?

The encoder problem is just a warning, if your stream works fine there is no problem.

The stream gets stuck, and no further chunk requests are being made.

It looks like your manifest has 2 periods, One period uses SegmentTemplate+SegmentTimeline and one period uses SegmentTemplate with number. The parser is not prepared for this mixture and gives incorrect behavior. I'm going to let @joeyparrish tell you what the best way to proceed is.
(Related to https://github.com/shaka-project/shaka-player/issues/6612)

Hello @joeyparrish I hope you’ve had a chance to review it. Please let me know if you have any questions and what you think is the best way to proceed.

Hello @avelad and @joeyparrish, I am experiencing the same issue with a similar manifest. One period uses SegmentTemplate with SegmentTimeline, while another uses SegmentTemplate with numbering.

@csrinu236 can you share a public stream?

Hey @avelad and @joeyparrish  , I have created a stream in which One period uses SegmentTemplate with SegmentTimeline, while another uses SegmentTemplate with numbering.
Below is the link
https://stream-mpd.netlify.app/v7-Clear/output.mpd

Thanks you @avelad and @joeyparrish for fixing the issue.


rotating package incompatibility

The rotating package is not yet fully compatible with the tagging code (expected, of course). Content in the sideways, turn, and rotate environments and \turnbox command does not show in the structure tree.
Also, the sidewaysfigure and sidewaystable environments are tagged differently than figure and table. I don't know enough to say if the tagging is correct.
Example that shows the issues:
\DocumentMetadata
  {
    lang=en-US,
    pdfversion=2.0,
    pdfstandard=ua-2,
    testphase={phase-III,math,title,table,firstaid}
  }
\documentclass{article}
\usepackage{rotating}

\title{rotating tagging test}

\begin{document}
Normal text

\begin{sideways}
sideways text
\end{sideways}

\begin{sidewaysfigure}
\centering
\includegraphics[alt={example image a}]{example-image-a}
\caption{Some caption text}
\end{sidewaysfigure}

\begin{figure}
\centering
\includegraphics[alt={example image b}]{example-image-b}
\caption{More caption text}
\end{figure}

\end{document}

Generally: when handling boxes then it can matter if you are inside a paragraph, and it can also matter if you use lualatex or pdflatex (the mysteries of attributes ...). As an example:
\DocumentMetadata
  {
    lang=en-US,
    pdfversion=2.0,
    pdfstandard=ua-2,
    testphase={phase-III,math,title,table,firstaid}
  }
\documentclass{article}
\usepackage{rotating}

\title{rotating tagging test}

\begin{document}
Normal text

\begin{sideways}
sideways text A
\end{sideways}

\leavevmode \begin{sideways}
sideways text B
\end{sideways}
\end{document}

pdflatex tagging

lualatex tagging

Thanks for the info. Is adding \leavevmode something that should be left to the user or handled by a future version of the package?

I'm not claiming that \leavevmode is the correct fix - probably sideways should also work in vmode. I only wanted to point out, that has to look at both cases.

probably sideways should also work in vmod

it is like other floats so it should work in the same way, but in vmode (the usual) case, but also in hmode (by migrating out, which it might not do)

@FrankMittelbach

it is like other floats so it should work in the same way

sideways is not a float (that is sidewaysfigure), it is simply a turned hbox:
\def\sideways{%
  \Grot@setangle{90}%
  \setbox\z@\color@hbox\ignorespaces}
\def\endsideways{%
  \unskip\color@endbox
  \Grot@x\z@
  \Grot@y\z@
  \Grot@box
}

and internally \Grot@box issues a \leavevmode, so it probably wouldn't harm if that is added before the \setbox? @davidcarlisle

Ah right my bad


Msgpack roundtrips python 3 strings to bytes

Possibly related to https://github.com/pydata/pandas/issues/13591.

In [3]: s = Series(['a','b'])

In [5]: pd.read_msgpack(s.to_msgpack())
Out[5]:
0    a
1    b
dtype: object

In [6]: pd.read_msgpack(s.to_msgpack()).values
Out[6]: array(['a', 'b'], dtype=object)

further msgpack.* routines are private, AND they do exactly what they say, namely translate object->bytes via roundtrip. So you are simply using them wrong.

In [8]: pd.msgpack.dumps('s')
Out[8]: b'\xa1s'

In [9]: pd.msgpack.loads(pd.msgpack.dumps('s'))
Out[9]: b's'

These are the public functions which dask uses.
In [1]: pd.msgpack.loads?
Docstring:
unpackb(packed, object_hook=None, list_hook=None, bool use_list=1, encoding=None, unicode_errors='strict', object_pairs_hook=None, ext_hook=ExtType, Py_ssize_t max_str_len=2147483647, Py_ssize_t max_bin_len=2147483647, Py_ssize_t max_array_len=2147483647, Py_ssize_t max_map_len=2147483647, Py_ssize_t max_ext_len=2147483647)

Unpack packed_bytes to object. Returns an unpacked object.

Raises `ValueError` when `packed` contains extra bytes.

See :class:`Unpacker` for options.
Type:      builtin_function_or_method

In [2]: pd.msgpack.dumps?
Signature: pd.msgpack.dumps(o, **kwargs)
Docstring:
Pack object `o` and return packed bytes

See :class:`Packer` for options.
File:      ~/miniconda/envs/py3.5/lib/python3.5/site-packages/pandas/msgpack/__init__.py
Type:      function

In the dask.distributed protocol we manage this by using the use_bin_type and encoding keyword arguments
In [1]: import pandas as pd

In [2]: pd.msgpack.unpackb(pd.msgpack.packb("a"))
Out[2]: b'a'

In [3]: pd.msgpack.unpackb(pd.msgpack.packb(u"a", use_bin_type=True), encoding='
   ...: utf8')
Out[3]: 'a'


Silent truncation of SlotNo values in constructor for Ptr

While upgrading cardano-wallet to the latest node version, we discovered some odd behaviour in our property tests w.r.t. the Ptr type.
To construct and deconstruct values of type Ptr, we were using the pattern synonyms defined here and here, which have the following types:
-- "Constructor"
pattern Ptr :: SlotNo -> TxIx -> CertIx -> Ptr

-- "Deconstructor"
viewPtr :: Ptr -> (SlotNo, TxIx, CertIx)

The types of these functions give the impression that it ought to be possible to construct a Ptr and then deconstruct it without losing information.
However, within the constructor, values of SlotNo (which is a Word64) are silently truncated, removing the highest 32 bits. It turns out that internally, a Ptr is only 64 bits wide, so the constructor must throw information away in order to fit everything in.
This caused one of our property test coverage checks to mysteriously fail, since:

our generator for Ptr reuses our generator for SlotNo;
our generator for SlotNo generates across the full range of a Word64;
our coverage check for Ptr reuses our coverage check  for SlotNo;
our coverage check for SlotNo expects to find values across the full range of a Word64, including values close to maxBound :: Word64.

But this last coverage check can never succeed, because values of SlotNo close to maxBound :: Word64 are always silently truncated if they're included in a Ptr.
It was only after quite a bit of digging that we discovered this.
I can understand the intent here: it'll be many years before we reach a slot number greater than maxBound :: Word32, so throwing away the top bits probably won't cause an error (for a few years, at least!).
However I can't help wondering: could we make this clearer in the types?
Perhaps introducing a SlotNo32 type would allow us to rewrite the above pattern like this:
pattern Ptr :: SlotNo32 -> TxIx -> CertIx -> Ptr

This would make it obvious to callers that they need to perform some kind of conversion to get from a SlotNo to a SlotNo32.
For convenience, we could even provide a function that does this:
toSlotNo32 :: SlotNo -> Maybe SlotNo32

Is this something that's feasible? It might help others to avoid running into this issue.
Many thanks!
Jonathan

@jonathanknowles Thank you for bringing this up! This optimization will be disabled for now in #2875, so this ticket will not be valid until a bit later. Future planned fix is to introduce function:
mkPtr :: SlotNo -> TxIx -> CertIx -> Maybe Ptr
  | slotNo > fromIntegral (maxBound :: Word32) = Nothing
  | otherwise = ...

and making the Ptr pattern unidirectional. I think that will be better than introducing a whole new type SlotNo32 that can only be used for Ptr. But the affect will be the same, it'll be safe :wink:


Missing Time Zone errors

In PVWatts and detailed PV models, if the time zone is missing, annual energy will return 0 or negative. In at least one CSP model, if time zone is missing, an unhandled exception is thrown.

Closed in: 363a3049cc02829bf23ca073a9146430ac61aed4


Will this ever work with windows?

I am unable to build any package on windows that imports your package...
Any plans to support windows platforms?

I don't have a windows machine around, but I just merged a PR to disable build on windows so it should fix your dependency issue.