Fails in Cygwin due to prepending C:\ to path

Build/Submit details page URL
No response
Summary
It fails with the error:
Compressing project files and uploading to EAS Build. Learn more: https://expo.fyi/eas-build-archive
    Error: ENOENT: no such file or directory, lstat 'C:\cygdrive\c\Projects\MyApp'

The correct path in the case of Cygwin though, is /cygdrive/c/Projects/MyApp (without the C: at the front)
Interestingly npmGlobalPackages is empty when run from this machine, but not on my Linux machine. But this is the same whether within Cygwin or not, and outside of Cygwin, building with EAS works fine.
Also notable is that somehow npm has ended up within the node_modules here, but again, it doesn't appear to have any bearing on the issue.
Managed or bare?
Managed
Environment
expo-env-info 1.0.5 environment info:
System:
OS: Windows 10 10.0.22000
Binaries:
Node: 16.18.0 - C:\Program Files\nodejs\node.EXE
Yarn: 1.22.16 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
npm: 7.24.2 - C:\Projects\MyApp\node_modules.bin\npm.CMD
Expo Workflow: managed
Expo Doctor (invalid modules are caused by Expo itself)
Expected package<EMAIL_ADDRESS>|| ~0.9.0
Found invalid:
<EMAIL_ADDRESS>  (for more info, run: npm why expo-modules-autolinking)
Some dependencies are incompatible with the installed expo package version:
 - expo-updates - expected version: ~0.13.4 - actual version installed: 0.13.3
Your project may not work correctly until you install the correct versions of the packages.
To install the correct versions of these packages, please run: expo doctor --fix-dependencies,
or install individual packages by running expo install [package-name ...]

Error output
Compressing project files and uploading to EAS Build. Learn more: https://expo.fyi/eas-build-archive
    Error: ENOENT: no such file or directory, lstat 'C:\cygdrive\c\Projects\MyApp'

Reproducible demo or steps to reproduce from a blank project
N/A - Apparent environmental support problem

Any update on this case?

Any update on this case? The same thing is happening to me, when executing the eas build command, it fails because the path where I am standing is appended to C:\cygdrive

Fixed by completely removing Cygwin, the issue happened specifically when running the 'npx eas build' command

Any update on this case? The same thing is happening to me, when executing the eas build command, it fails because the path where I am standing is appended to C:\cygdrive

Fixed by completely removing Cygwin, the issue happened specifically when running the 'npx eas build' command

Fwiw removing Cygwin is not an option for us. I haven't retested this with any later versions .


Give option to suppress print statements

Currently there is no option to disable print statements originating from the library, for example "Running pairwise ranking..".

Done, play with the log_level keyword to see current or future messages
ranker = Ranker("ms-marco-MultiBERT-L-12", log_level="DEBUG")


for fast response, there should be a cache storage possibility

for fast response, there should be a cache storage possibility,
which can be set to a ssd persistent storage.
It should be set to max usage, like 256GB, or max file count, everything tenant independed.

implemented


Expiring cache

We liked your gem and we needed expiration so I've added this. If you like it you can merge it. I'll totally understand, though, if you think it is out of scope for your gem.

Hello,
I have a implementation I would like to propose as an expiring/TTL cache for the library.  The implementation is similar to what @DylanGriffith suggests near the end of his last reply.  You can see the implementation here: https://github.com/Seberius/cache_lib/blob/master/lib/cache_lib/ttl/cache.rb
I would like to address how the proposed implementation handles some of the issues @SamSaffron  raised.

This implementation is only evicting keys on access, so potentially you can have large amount of keys still retained after the expiry date.

A separate ordered list of time values is stored (TTL list).  On access, the TTL list is iterated over from the oldest value until a 'live' value is found, evicting expired entries as it goes.  The advantage is that you always are only storing 'live' values when access completes and LRU eviction will never drop a 'live' value over an expired one.

General pattern would be to add a bg thread to purge out keys (which should probably be an option)

A method called #expire is provided that will trigger a TTL eviction (the same that occurs on access).  This, I believe, could be accessed by a thread to provide the functionality described (I don't have very much experience with cron-like jobs in Ruby).
A couple additional notes about the implementation.

The cache functions identically to the LRU cache, but with time functions (or exactly alike, if you set the ttl to :none).
The ttl eviction time is determined at eviction.  That is, the cache stores entry times, not eviction times.  The advantage of this is that if you change the ttl on a live cache, the currently stored values will be evicted under the new ttl, not the one they were entered under.

If you are interested in that implementation, I have a question regarding pre-1.9 support.  Is support for Ruby 1.8 on a new cache wanted?  It can be implemented fairly efficiently (double doubly-linked list!), but will require a bit of extra work write and increases the support overhead.
Thanks!

I really like this implementation, let's pull it in.
Can you add some tests for it and bring it in?
I do not think we need to worry about 1.8 here, 1.8 is mostly dead now.

Sure, I will pull over the tests from the linked example.  I will need to add Timecop as a development dependency for TTL testing.
I would like to do it as two pull requests.  The first will be a performance improvement (#shift is much faster in Ruby 2.1+), some refactoring (e.g. changing ThreadSafeCache to use a mixin), and some very minor fixes.  The second would be the TTL cache implementation + tests + docs.

@Seberius  also I have given push access to you for this repo just in case you need it. (we should still do PRs for these bigger changes though)

Looks like this is no longer needed.


source.on not a function , send mail with attachment

solution?

Had this problem when was passing attachment as blob. Even though it is available in the type definitions, it does not look Mailgun supports it. For me after converting Blob to Buffer - it started to work:
        const arrayBuffer = await blob.arrayBuffer();
        const buffer = Buffer.from(arrayBuffer);


please widen dependencies on googleapis + googleapis_beta

  googleapis: '>=0.2.0 <0.11.0'
  googleapis_beta: '>=0.3.0 <0.15.0'

Can you please send over a pull request?

Thanks for the hint.
It requires us to publish anyway, so I went ahead and widened the constraints.

@sethladd I tried, but run into obstacles when running the tests and went with the issue instead.

Thanks for giving it a shot!


Remove unneeded filter on joy_axis()

Currently, the Input::joy_axis() function ensures that joystick events are only sent if the change is greater than or equal to 0.01. However, changes are only sent to the joy_axis() function in steps of 0.004 or 0.008; so the filter is unneeded and results in reduced precision; as identified by @DJKero and explained in #42876.
This PR removes the unneeded filter. Credit to @zyp for identifying the source of the problem.
Fixes #42876

I suppose the filter is also no longer necessary now that we have input event accumulation since Godot 3.1.

For the reference, this was added in af633c79417 in 2015. @27thLiz Do you remember why it was needed back then?

Thanks!


Is assignment of lookup value to a sales document depending on status of document?

At this very moment the Lookup Value Code field on a sales document can be changed at any time. Is this what it should be as on many standard fields the status of the document is verified - using method TestStatusOpen - to be open?

Should the business logic be updated to be in line with standard fields?
Irrespective of the first point tests should be added to verify the field change for different statuses.

reported by<EMAIL_ADDRESS>

Should the business logic be updated to be in line with standard fields?

This was indeed not part of previous requirements, and has also not be addressed in the 2nd edition of the book.
Requirement: Lookup Value Code field can only be updated when the status of the document is Open, i.e. method TestStatusOpen does not error.

Irrespective of the first point tests should be added to verify the field change for different statuses.

This is clearly an omission in the test plan

On ...

Should the business logic be updated to be in line with standard fields?

Not all fields do have a call to TestStatusOpen in its OnValidate trigger. It is not clear (yet) to me what is the logic behind tat determines to have a call to it or not.


Rename SOI to Analyst Service

SOI is too difficult to know what it is meaning, so I change to Analyst Service

The reason why I need to change it for now? because when I write document, I need to make sure the terminology is consistent


Backport: Emited IBC errors should also be logged

What is the purpose of the change
After huckleberry, IBC redacts emitted events if the ack is a failure. This means that the user cannot see those. To get around that, we can add the error context to the logs as well.
Eventually we can fix this properly with error-events in the sdk
Testing and Verifying
all tests pass
Documentation and Release Note

[ ] Does this pull request introduce a new feature or user-facing behavior changes?
[ ] Changelog entry added to Unreleased section of CHANGELOG.md?

Where is the change documented?

[ ] Specification (x/{module}/README.md)
[ ] Osmosis documentation site
[ ] Code comments?
[x] N/A

we can backport it, but since this is on osmoutils we would also need to update the commit hash in go.mod.
After double checking this, it doesn't seem like the removal was backported to ibc 4.3, so this becomes more of a safety for when we upgrade ibc


Documentation for setting the BASE_URL

Documentation for setting the BASE_URL
This adds the information to the main readme for the usage of the BASE_URL setting
Ticket URL: https://projects.torchbox.com/projects/wordpress-to-wagtail-importer-package/tickets/93
WAGTAIL_WORDPRESS_IMPORTER_BASE_URL is renamed to WAGTAIL_WORDPRESS_IMPORTER_SOURCE_DOMAIN

Testing

[x] CI passes

Documentation.

[x] This PR adds or updates documentation

@nimasmi The changes are in place now.


Include response for Route Information Packets (0x8d)

This packet can be sent back by each hop during a Transmit Request to inform the sender of the route that was taken to deliver to the destination.
I used the example packet from pg. 130 of http://www.digi.com/resources/documentation/digidocs/pdfs/90001477.pdf

Thanks for contributing @spicybits all looks good. Thank you also for adding a test.


Xcode 9 beta 5 build failed

Xcode 9 beta 5, swift 3.2 with carthage version 0.23.0, currently using "kylef/JSONWebToken.swift" "2.1.0" version. fails building CryptoSwift

got it, confused with swift 4 complier. using "master" solved it

but "2.1.0" should compile in xcode 9 right. will there be any fix for this error? Build Failed Task failed with exit code 65:, This usually indicates that project itself failed to compile.

https://github.com/kylef/JSONWebToken.swift/releases/tag/2.2.0 works with Swift 4.


Cannot resolve the reference

Hi Adam,
I am using NewtonSoft.Json 12.0.1, RestSharp 106.5.4 and RestSharp.Newtonsoft.Json 1.5.0 in my application. IOS is working properly in simulator. I get an error when I want to try the iPhone. First, I tried the NewtonSoft version 11.0.2 and got the same error. The problem is fixed when I make the version 12.0.1 and lower the RestSharp version to 106.0.1. Because the error message 106.0.1 has given warning. I hope I can tell in a clear way.
Error message

Error MT2101: Cannot resolve the reference 'System.Void RestSharp.RestRequest ::. Ctor (System.String)', referenced from the method 'System.Void RestSharp.Serializers.Newtonsoft.Json.RestRequest ::. Ctor (System .String) '' RestSharp, Version = <IP_ADDRESS>, Culture = neutral, PublicKeyToken = 598062e77f915f75 '. (MT2101) (crmmobile.iOS)

It looks like this has been an issue others have experienced as well directly with RestSharp. However I am able to upgrade to the latest versions as you mentioned above and I'm able to build the project and run all unit tests.
https://github.com/restsharp/RestSharp/issues/1198
Some solutions they mention to try:

Uninstalling the package and reinstalling
If the RestSharp dependency is directly installed in your solution, remove it and only rely on the NuGet package dependency.

RestSharp.Serializers.Newtonsoft.Json.RestRequest is just a convenience wrapper that extends RestSharp.RestRequest and automatically applies the Newtonsoft serializer. It is optional to use since you can set it in an alternate way as mentioned in the docs.
Regardless, I published release 1.5.1 and recompiled against the latest RestSharp version to ensure they are both consistent.
https://github.com/adamfisher/RestSharp.Serializers.Newtonsoft.Json/releases/tag/1.5.1

The problem is resolved with the latest version. Thanks...


tdesktop: enable on other platforms

Motivation for this change
It works on armv7l-linux once the SSE2 assumption is patched out.
Things done

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

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: tdesktop
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on aarch64-linux (full log)
Attempted: tdesktop
Partial log (click to expand)
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/lz6fbrwkbj1qdg2sag4x7ydzf7cysnw2-telegram-desktop-1.2.17
shrinking /nix/store/lz6fbrwkbj1qdg2sag4x7ydzf7cysnw2-telegram-desktop-1.2.17/bin/telegram-desktop
strip is /nix/store/jk6j4lh9v5mvjdbdc35sj0zffhhf6s56-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/lz6fbrwkbj1qdg2sag4x7ydzf7cysnw2-telegram-desktop-1.2.17/bin
patching script interpreter paths in /nix/store/lz6fbrwkbj1qdg2sag4x7ydzf7cysnw2-telegram-desktop-1.2.17
checking for references to /build in /nix/store/lz6fbrwkbj1qdg2sag4x7ydzf7cysnw2-telegram-desktop-1.2.17...
postPatchMkspecs
postPatchMkspecs
/nix/store/lz6fbrwkbj1qdg2sag4x7ydzf7cysnw2-telegram-desktop-1.2.17

Success on x86_64-linux (full log)
Attempted: tdesktop
Partial log (click to expand)
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/nwakm87pmm35varggq6gv00ik7ndrk63-telegram-desktop-1.2.17
shrinking /nix/store/nwakm87pmm35varggq6gv00ik7ndrk63-telegram-desktop-1.2.17/bin/telegram-desktop
strip is /nix/store/j75dgadrff2d1fyc4fczmcgqkid2imdx-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/nwakm87pmm35varggq6gv00ik7ndrk63-telegram-desktop-1.2.17/bin
patching script interpreter paths in /nix/store/nwakm87pmm35varggq6gv00ik7ndrk63-telegram-desktop-1.2.17
checking for references to /build in /nix/store/nwakm87pmm35varggq6gv00ik7ndrk63-telegram-desktop-1.2.17...
postPatchMkspecs
postPatchMkspecs
/nix/store/nwakm87pmm35varggq6gv00ik7ndrk63-telegram-desktop-1.2.17

cc maintainers @primeos @abbradar @garbas

This has been fixed in https://github.com/grishka/libtgvoip/commits/01f70942/libtgvoip.gyp and made its way into telegram-unstable (1.0.21), but not into telegram-stable (1.0.17).

IMO it would make more sense if we add it conditionally (something like: !stdenv.isi686 && stdenv.lib.versionOlder version "1.2.19").
Then we could merge it and backport it to stable.
@orivej What do you think of that solution?

I'm not a fan of making it conditional on the system. AFAIK most of nixpkgs doesn't assume SSE2 support on i686 either, so it would be inconsistent as well. And if that's the case, it still makes sense to patch it out even on i686. It's not a hill I'll die on though, if everyone else prefers to make it system-dependent then sure.


Create a PF4J logo

PF4J should have its unique logo for use in presentations etc. I'm presenting on PF4J and Solr next week and created a simple logo proposal and added it on top of README.md
The icon is in the Public Domain (CC0):
https://pixabay.com/en/building-block-brick-toy-puzzle-148068/
The font used is Google's "Audiowide" font, licensed under OpenFont license:
https://fonts.google.com/specimen/Audiowide
The PNG and SVG versions are produced from a Google Drawing:
https://docs.google.com/a/cominvent.com/drawings/d/1xvT412U4iwfdWiQAEjBTeJByespTq9AXfV-15xEprHE/edit?usp=sharing

See result at https://github.com/cominvent/pf4j/tree/logo
Please use "Squash and merge" when merging :)

Nice!

Please use "Squash and merge" when merging :)

Always when a merge a PR I use "Squash and merge" to not pollute the git log.


The incorrect text pops up is shown after the user is registered

Steps to reproduce:

Go to the https://ita-social-projects.github.io/GreenCityClient/#/auth/sign-up
Fill in with the valid data fields: 'First Name', 'Last Name', 'Email', 'Password', 'Password Confirm'
Click the 'Sign-up' button
Look at the pops up text
Expected Result:
The following text pops up is - 'You successfully registered on this site. Please verify your email address in email box'
Actual Result:
'You have successfully registered on the site. Please confirm your email address in the email box' text pops up is shown
Environment: Chrome Версія 80.0.3987.122 (Розробка) (64-розрядна версія) Windows7 Ultimat

All texts were given for us by experts.
Your example of the sentence is not correct:
"You successfully registered on this site. Please verify your email address in email box'"

"verify" - is not correct in this case, because user must confirm the registration (not only verify)
phrase "You have successfully registered" - is correct because a Present Perfect Tense must be used (https://grammarway.com/ua/present-perfect)  instead of Past Indefinite (https://grammarway.com/ua/past-simple)
"in the email box" - is correct, because (a\the) must be before the noun (https://grammarway.com/ua/article)


Display drivers for '429-Discovery

Hi,
there are two different drivers for the display on the '429-Discovery board:

in 'components' (ILI9341 - serial mode)
in 'utils' (LTDC mode)

I think some hints in the file headers or in a readme file ('what do I find in this or that file') would be helpful.
BTW, the name of the directory 'utils' is somewhat misleading. I would expect some tools (e.g. a converter for character sets or something like that...) in a directory named 'utils'. The LCD related files are clearly drivers. I must admit that I haven't found a better directory name for the rest of the files yet.

Agreed, on both points.
The component driver is very low-level, and limited in scope. The LTDC interface does more, and will eventually be revised to be in terms of the component driver.
We considered "ancillary" instead of "utils" (among others) but have yet to find a good name.  It may be that we need to break up the contents to find a good name.
Thanks for the comments!

Probably I should move the STM32F4.* packages from utils/ to drivers/ and thereby simplify things a little. Originally the drivers/ dir was strictly for actual devices described by the RM, but that may be more narrow a definition than necessary.

LTDC

hi, from what I see and understood about LTDC, the driver should be indeed in drivers.
But not in this current form as it seems to be a mix between low-level driver and middleware.
I would see the peripheral driver layer in 'drivers' and the layer using SPI and GPIO in 'utils' folder.
by the way, 'utils' isn't so badly named and is often used to place utility services which act in the inter-layers, ie not ll driver, not middleware but useful to app developer. Middleware are usually services like an usb stack, a filesystem management, a graphic layer etc...

Yes, the LTDC is a bit of a mixture at present.  It was written prior to the ILI9341 component driver so we envision it being revised accordingly, at some point, and made more independent of the board.
I agree that utils is a good name as long as that's what is in there.

The LTDC driver (and more generally framebuffer display) have been greatly refactored in the 'svd' branch. In particular:

stm32-ltdc.ads now only configures the LTDC peripheral
stm32-dma2d also only configures the peripheral
a new HAL.Framebuffer interface has been introduce to handle framebuffer displays
this interface is partially implemented in boards/common_stm32/ltdc/framebuffer_ltdc.ads.
a new HAL.Bitmap type has also been introduced to perform operations on bitmap surfaces,
a specialized version bitmap_dma2d allows hardware acceleration.
all those interfaces are fully implemented at the board levels.

This is now integrated into the master branch. So I'm closing this issue, feel free to open a new one if you see ways to improve the current architecture  (even better if you can contribute changes: we're very open to your participation to this project)!
Best regards,

Jerome


data/partisan-lean/fivethirtyeight_partisan_lean_STATES.csv

New Hampshire is given a partisan lean of R+33. For comparison, NH-1 is R+4 and NH-2 is D+1. If NH were actually 33 points more Republican than the nation, their state legislative election results would have had to have been 138 points more Republican (which is nonsensical).

The only thing that makes sense to me is that it's a typo, instead of being R+3, they typed R+33.

The only thing that makes sense to me is that it's a typo, instead of being R+3, they typed R+33.

That's probably it. It'd be nice is they gave us the state legislative elections data they have so it'd be easier to verify.

Sorry about that, it was indeed a typo. It should be R+2. That's now fixed


[joy] Refine the default theme

closes #35788
closes #37663
closes #36782
closes #37663
closes #37967
Migration docs: https://deploy-preview-36843--material-ui.netlify.app/joy-ui/migration/migrating-default-theme/
New Tabs design: https://deploy-preview-36843--material-ui.netlify.app/joy-ui/react-tabs/
Try it out
We really appreciate it if you could try the new changes in your existing Joy UI project.

Replace the @mui/joy version in your package.json with this:
- "@mui/joy": "5.0.0-alpha.x"
+ "@mui/joy": "https://pkg.csb.dev/mui/material-ui/commit/945e4a0b/@mui/joy"

run yarn install (you might have to run it twice because the first time might see an error).

Follow the migration docs

Review recommendation
Better to go through the migration docs because it is the source of all breaking changes.
Changes
Tokens removed

palette.info
letterSpacing

Typography
h1
h2
h3
h4
- h5
- h6
- body1
- body2
- body3
- body4
- body5
+ title-lg
+ title-md
+ title-sm
+ body-lg
+ body-md
+ body-sm
+ body-xs

The composition of title-* and body-* is improved. When using them together with an icon, there is no need to add extra margin at all. For example:
// Before
<SvgIcon sx={{ mt: '2px' }}>

  <Typography fontWeight="lg" mb={0.25}>Title</Typography>
  <Typography level="body2">Description</Typography>

// After
<SvgIcon>

  <Typography level="title-md">Title</Typography>
  <Typography level="body-sm">Description</Typography>

Before
After

Templates

Before
After

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

Sorry @siriwatknp, I got carried away and ended up committing all the changes once 😅
I've let some comments on the changes, but it'd be nice to review everything and reassure that I didn't do anything wrong.
Besides the comments I left in the file, I'd like to ask a few more things:

How/where is defined the placeholder texts?
How should we remove the "info" palette?
Could we have more semantic names for texts sizes? I think it'd improve the user experience, providing names like "Title-xl", "Title-md", "body-sm", and so on. What do you think?

How/where is defined the placeholder texts?

We don't have a theme token that is specific to the placeholder text. They can be configured through component variables, for example, the Input:

How should we remove the "info" palette?

I can help with that.

Could we have more semantic names for texts sizes? I think it'd improve the user experience, providing names like "Title-xl", "Title-md", "body-sm", and so on. What do you think?

Do you mean in theme.typography? The benefit I see is that they are more explicit than body1, 2, 3 (who knows if 1 is bigger or smaller than 2). However, we should do the POC of the typography set with demo components and templates too validate that they are useful and intuitive.

We don't have a theme token that is specific to the placeholder text. They can be configured through component variables, for example, the Input:

Would it be possible to have a token for it? I think opacity could be a bit tricky to contrast when dealing with so many variables.

Do you mean in theme.typography? The benefit I see is that they are more explicit than body1, 2, 3 (who knows if 1 is bigger or smaller than 2). However, we should do the POC of the typography set with demo components and templates too validate that they are useful and intuitive.

I'm not sure if it'd be in theme.typography, but the idea is to have something like <Typography level="body-lg">Hello, World!</Typography>, instead of  <Typography level="body1">Hello, World!</Typography>. I reckon this would really help in moments where the user needs a smaller text, and could just add a sm instead of remembering which body to use. But yeah, definitely should try on POCs before.

Would it be possible to have a token for it? I think opacity could be a bit tricky to contrast when dealing with so many variables.

What do you think about adding the token to palette.text.placeholder?

What do you think about adding the token to palette.text.placeholder?

I was testing the contrast here and probably we would have to have one for each variant (plain, solid,soft and outlined). What do you think we could do then?

Opportunities for improvement:

Line height seems wrong (using rem) 👉 /experiments/joy/prose/
Disabled state 👉 /experiments/joy/global-variants/
?neutral can be darker 👉 /experiments/joy/global-variants/
more typography levels

I was looking at the components at /experiments/joy/global-variants/ and the only thing that still needs major adjustments is the primary warning card. Isn't it following the tokens set on extendedTheme?

@siriwatknp I've updated the typography according to what we discussed on the Figma file.
Also, I was making some tests at /experiments/joy/global-variants/ and I think we could bump up a bit the opacity of placeholders. I tried 0.7, and I think it's a sweet spot between being recognized as a placeholder, but still being able to be differentiated from the filled label.

@siriwatknp I tweaked the shadows, surfaces, some icon colors, and the disabled button. Also, I updated the email template to remove the custom styles to make it closer to the default as possible.

@zanivan I adjust the global variant tokens a bit (disabled and some neutral palette tokens). I think the before version is too light and too close to the disabled state, so I increase the contrast a little bit more and also make the disabled state lighter. Let me know what you think!
Before:

After:

@zanivan Also, I tried the global variant icon tokens but I don't think it is going to work well in most cases (with +60 tokens on the CSS bundle size).
For example, on the Select component. There is an icon on the left (from the consumer) and an expand icon on the right (from Joy UI). With the global variant icon tokens, both of them will behave the same like when you hover on the Select. It does not feel right to me with this approach.
Instead, I think it might be better to add one more token for the icon to theme.vars.palette.text.icon as a default color for icons and then each component decide what color the icons should have based on their states.

it doesn't work like it should—specifically on the disabled checkbox. Any idea why this is happening?

I don't quite get it. Which part that you mean "it does not work as it should"? Can you attach a screenshot or a recording?

In the preview, some tokens aren't being applied properly:
Preview link:

Running it locally:

@zanivan There are some questions related to the default variant of each that I wonder if we need to change:

IconButton: from variant="soft" color="primary" to variant="plain" color="neutral"
Card: from variant="plain" to variant="outlined"
Chip: from variant="solid" color="primary" to variant="soft" color="neutral"

IconButton: from variant="soft" color="primary" to variant="plain" color="neutral"

I don't know about this one, while I was reviewing, sometimes it felt like the button was disabled. Would it be too bad to roll back to icon following the text color?

Card: from variant="plain" to variant="outlined"

Agreed ✅

Chip: from variant="solid" color="primary" to variant="soft" color="neutral"

Agreed ✅

@siriwatknp, while reviewing the docs and components, I came across a few things I'd like to ask/confirm with you:

The warning color inversion doesn't seem to be working. Could it be because we used to have inverted values for warning as the default?
Is there a specific reason we're using a different sandbox to showcase the Button on the Getting started/Usage page?
Some variants that use placeholders, particularly solid and soft, are a bit difficult to read due to the opacity. Should we bump up a bit the opacity, maybe to 0.7?
What are your thoughts on keeping the solid style of the slider thumb for plain and soft variants?
The chip and switch components are a bit odd in the plain variant. Would it be possible to add a plain white/black (light/dark) background to the chip component, and the same for the switch's track?
I believe the selected/unselected List items could have more differentiation in styles than just the color. Similar to what we discussed for the toggle button, using an active state for the selected list item could be a good approach. Also, I noticed that in almost all examples and usages, we added a border radius to it. Should we establish a default value for border radius on the List?
Solid variations on the Modal and Menu components are a bit hard to read. Would it be possible to use inverted colors by default for those?

while reviewing the docs and components, I came across a few things I'd like to ask/confirm with you:

Fixed
The Sandbox will be updated after we merge this PR and release it as a new version.
Good point, bump soft and solid to 0.7
I would not do that for now because it will defeat the purpose of the global variant. I think if the styles do not make sense we can consider having just the solid variant for the slider.
Added background.surface as a default background.
Added the active styles when it is selected (this also affects Select and Autocomplete option)
I would not go that far for now because I am still reluctant if we should make color inversion opt-in or not. For now, developers can workaround on their end:

<Menu variant="solid">
  <MenuItem variant="solid">
  …
</Menu>

Wow, that was fast—amazing work as always, Jun!
About the points:

Agreed, let's keep the styles as it is then.
I don't know if it's intentional, but the switch thumb on plain variant is currently dark gray—shouldn't it follow the colors?
Ok, I think we can skip this for now.

@zanivan Hey, Victor. I decided to move the Tabs design changes to this PR to make this one a single-breaking change.
https://deploy-preview-36843--material-ui.netlify.app/joy-ui/react-tabs/
Most of the styles follow the design but for the underline, I think it makes more sense to move it out of the global variant so that it can be customized separately.

The new outlined tab variant causes the contents of the tabs to shift around. This is especially noticable with vertical tabs.
Additionally I feel like the solid tabs should use a different color scheme? The background should be just the same as used elsewhere for buttons, chips, etc. with the line taking the darker color of the background it has right now. Right now it feels a bit to dark compared to all other UI elements.
Is there a reason why the info color is being removed?
There appears to be something wrong with the menu demo:

The new outlined tab variant causes the contents of the tabs to shift around. This is especially noticable with vertical tabs.

You are right. In the real application, think you will need to set border: 1px solid transparent to the unselected Tab. I don't want to mislead the demo so I think the shift is fine.

Additionally I feel like the solid tabs should use a different color scheme? The background should be just the same as used elsewhere for buttons, chips, etc. with the line taking the darker color of the background it has right now. Right now it feels a bit to dark compared to all other UI elements.

For consistency, the selected Tab uses active variant styles, e.g. palette.{color}.activeBg. That's why it displays as dark background. I think most cases you would use plain variant. I will try to find real usage of the solid variant but for now I think we should keep the consistency.

Is there a reason why the info color is being removed?

We like to keep the default theme as lean as possible and from our experience building templates and demos, the info color is rarely used. We will provide a customization doc if you like to have the info color as an extra palette.

There appears to be something wrong with the menu demo:

Thanks for noticing it! will fix it.

You are right. In the real application, think you will need to set border: 1px solid transparent to the unselected Tab. I don't want to mislead the demo so I think the shift is fine.

But should this not be fixed within Joy? It's kinda weird to expect developers to implement what is basically a bugfix if they want to use a component.

For consistency, the selected Tab uses active variant styles, e.g. palette.{color}.activeBg. That's why it displays as dark background. I think most cases you would use plain variant. I will try to find real usage of the solid variant but for now I think we should keep the consistency.

It sometimes feels like they exist for consistency's sake. Another example of this is - in my opinion - the progress bar/circle solid variant. I've never had an instance where I wanted a color progress bar that gets white as it progresses. Meanwhile, there is no border-less variant that uses the main color and a white background (basically the inverse of a solid progress bar), something I personally use most of the time.
I get why it is the way it is, but it often feels like it was just made to tick off a box rather than with the component in mind.

We like to keep the default theme as lean as possible and from our experience building templates and demos, the info color is rarely used. We will provide a customization doc if you like to have the info color as an extra palette.

I feel like that is primarily because the primary color of Joy, and as a result the templates and demos, are all blue? This isn't the case for all applications. The primary color in some of my apps doesn't realy match with the idea of "this is an informative alert" for example. Most of these apps use Joy's default primary color palette as info.

I really appreciate the feedback @Studio384 — those are all great points!
First, you're absolutely right, the components' variants shouldn't be just for consistency’s sake! I'll review the tabs and circular progress. Are there any other components' variants that you fell that are a bit off? We're using this PR to polish these out as well!

Allow me to try briefly explain our rationale behind the removal of the info palette—besides making the default theme leaner. When we were polishing out the default theme, we wanted to have the most consistent and cohesive experience, with a less opinionated design, that would look clean and soft as well.
So, our color palette had the primary color (or the brand color) to be used as the identity for applications and main CTAs; Also, we had the accent colors to be used for states, like success, warning, info, and danger; And the neutral color for surfaces and neutral states.
However, when we started applying these into contexts, and fleshing out the components, we realized that there was an overlap between neutral state and info state. For this reason, we decided to remove the info palette, and instead start using the neutral colors as an info state, since it fits better with the semantic of an informational state.

I really appreciate the feedback @Studio384 — those are all great points!
First, you're absolutely right, the components' variants shouldn't be just for consistency’s sake! I'll review the tabs and circular progress. Are there any other components' variants that you fell that are a bit off? We're using this PR to polish these out as well!

Things that come to mind:

Afformentioned Tabs,  CircularProgress, and LinearProgress in solid.
Tables has in my opinion a number of issues with this

solid tables border color is near-invisible in the tbody (I honestly only just noticed that there was a different color for it at all), also feels to me like the thead and footer should also follow the color (in a different tone?).
When stripe is set, pretty much all variants in all colors look weird. I'd expect the striped rows to follow the color too, and in solid and soft's case also better match the background. Right now it feels like only neutral gives the expected result, but only in plain and outlined.
I would expect the table borders to always follow the color I give the table, right now this only happens when the table is set to outlined.

The Menu demo is broken so I'm not sure if it has been changed in this PR, and I have made an issue about this before in #36876, but I remain of the opinion that it's silly that the menu items don't follow the theme set by the menu itself without setting invertedColors. Especially given that since then the ButtonGroup component was added and does exactly that.

This is more a bug related to colors, but:

In a Modal when the color is set to neutral and the variant to solid, the ModalClose button becomes much darker compared to the background.

I know this isn't really on-topic right now, but a few things I found in the demos while I was looking around:

Card doesn't have a demo for colors at all.
After having clicked through so many demos, I really feel like variant should be Chips instead of a Select. 🙃
I've opened 2 other pull requests to fix bugs I noticed in the Table playground (#37816) and Link playground (#37817).

Allow me to try briefly explain our rationale behind the removal of the info palette—besides making the default theme leaner. When we were polishing out the default theme, we wanted to have the most consistent and cohesive experience, with a less opinionated design, that would look clean and soft as well.
So, our color palette had the primary color (or the brand color) to be used as the identity for applications and main CTAs; Also, we had the accent colors to be used for states, like success, warning, info, and danger; And the neutral color for surfaces and neutral states.
However, when we started applying these into contexts, and fleshing out the components, we realized that there was an overlap between neutral state and info state. For this reason, we decided to remove the info palette, and instead start using the neutral colors as an info state, since it fits better with the semantic of an informational state.

Mind you, I don't think it really a problem, just an odd thing to remove given that many other libraries do include it. I have extended the color palette far beyond what is included in-box, so I don't really mind adding 1 more.
I do want to, once again, bring some attention to providing some kind of tool that can generate a proper color palette based on a given color, tho, while I'm at it. :)

@Studio384

But should this not be fixed within Joy? It's kinda weird to expect developers to implement what is basically a bugfix if they want to use a component.

Okay, I found a way to make this work without extra customization. Added placeholder border (1px solid transparent) by default.

It sometimes feels like they exist for consistency's sake. Another example of this is - in my opinion - the progress bar/circle solid variant. I've never had an instance where I wanted a color progress bar that gets white as it progresses. Meanwhile, there is no border-less variant that uses the main color and a white background (basically the inverse of a solid progress bar), something I personally use most of the time.

I get why it is the way it is, but it often feels like it was just made to tick off a box rather than with the component in mind.

I have that feeling too. Maybe what we should do is remove variants that do not make sense for a specific component. cc @zanivan

In a Modal when the color is set to neutral and the variant to solid, the ModalClose button becomes much darker compared to the background.

At first, I thought that the buttons should have a darker background for neutral-solid combination but seems like it does not work well and might create confusion so I reverted the changes. It should look better now. cc @zanivan

Card doesn't have a demo for colors at all.

Added variants, colors, and sizes demos.

I do want to, once again, bring some attention to providing some kind of tool that can generate a proper color palette based on a given color, tho, while I'm at it. :)

I recommend checking out https://uicolors.app/create, it is nicely designed and easy to use.
https://github.com/mui/material-ui/assets/18292247/a08317d0-2276-4294-87d2-ed80a20758fc
@zanivan I wonder if we should have 950 token, so that we can leverage the existing tool out there that works with Tailwind?

@siriwatknp I know about this tool and have actually used it to help generate the colors I use. However, while this does give a good starting point for a colorscale, it still requires quiet a bit of work to get it right (which eventually made me use GitHub's Primer Prism). For starters, Color UI does not allow you to set which token is the baseline, but Joy always assumes 500 to be the base color.
But for custom colors (as far as I can tell, so I'm happy if you'd point out if I overlook something here 🙂) all the various variables have to be generated as well to properly use them in components. In my case I've copied the createDarkModeVariantVariables and createLightModeVariantVariables from Joy into my own project. I then also had to duplicate those 2 functions and apply the different token assignments from warning to be able to use light colors (both for extending the color scheme, as well as replacing the built-in tokens, e.g. my success color is a lighter softer green).
It would be great if at least functions like createLightModeVariantVariables are exposed for use by developers, or even better tools are included that can detect of a color is light or dark and use the correct variable set based on that.

It would be great if at least functions like createLightModeVariantVariables are exposed for use by developers, or even better tools are included that can detect of a color is light or dark and use the correct variable set based on that.

Got it! so basically a tool that receives a value (the main color) and generates all of the tokens that work well with Joy. I'd love to see it ❣

@siriwatknp I know about this tool and have actually used it to help generate the colors I use. However, while this does give a good starting point for a colorscale, it still requires quiet a bit of work to get it right (which eventually made me use GitHub's Primer Prism). For starters, Color UI does not allow you to set which token is the baseline, but Joy always assumes 500 to be the base color.
But for custom colors (as far as I can tell, so I'm happy if you'd point out if I overlook something here 🙂) all the various variables have to be generated as well to properly use them in components. In my case I've copied the createDarkModeVariantVariables and createLightModeVariantVariables from Joy into my own project. I then also had to duplicate those 2 functions and apply the different token assignments from warning to be able to use light colors (both for extending the color scheme, as well as replacing the built-in tokens, e.g. my success color is a lighter softer green).
It would be great if at least functions like createLightModeVariantVariables are exposed for use by developers, or even better tools are included that can detect of a color is light or dark and use the correct variable set based on that.

@DavidCnoops perhaps this could be a good initiative to keep an eye on for the future

@zanivan I wonder if we should have 950 token, so that we can leverage the existing tool out there that works with Tailwind?

I don't know if this is really necessary. Having it from 50 to 900 is currently working for Joy, and many other libs and resources like Untitled UI, GitHub's primer, Mantine and a few others uses values from 50 to 900 as well.
That said, I'm open to adding a 950 tone—it'd be very handy mostly on the neutral palette because it'd be one more value to use on our surfaces, making the curve of the dark bg leaner. One thing, though, is that our current 900 is very close to what they have as 950 on Tailwind. So, to add a 950, we'll likely have to insert an intermediary tone between the current 800 and 900 to be the new 900—and the current 900 would be the new 950.

I don't know if this is really necessary. Having it from 50 to 900 is currently working for Joy, and many other libs and resources like Untitled UI, GitHub's primer, Mantine and a few others uses values from 50 to 900 as well.

That said, I'm open to adding a 950 tone—it'd be very handy mostly on the neutral palette because it'd be one more value to use on our surfaces, making the curve of the dark bg leaner. One thing, though, is that our current 900 is very close to what they have as 950 on Tailwind. So, to add a 950, we'll likely have to insert an intermediary tone between the current 800 and 900 to be the new 900—and the current 900 would be the new 950.

Okay, thanks for the info. If we are reluctant about it then may be not now.

@siriwatknp I reviewed the docs one more time to be certain we're not missing anything before the merge. I made some tweaks, and found some other things that we might need to address.
Playground Demo

For some reason, the playground demo's from Tabs and ToggleButton are using the select for variants instead of the chips:

Shouldn't the color selectors be fully rounded?

Radio Button

I don't know if it's a bug, but the default radio button color here is neutral and turns to primary when checked. Shouldn't it stay neutral—or primary—in all states?

Table

When in dark theme, the table rows present no contrast

Current
New theme

Tabs

While reviewing the Tabs docs and demos, I started wondering if we shouldn't use the title-md and title-lg for the tabs' labels. I believe it'd increase the affordance and be more consistent with the other CTAs, like the button, for instance.

Approaches

On the theming section of the approaches page, there's this bug with the button and the select when in dark mode

Customization

This demo  should identify if it's currently in dark or light mode, but the label doesn't change at all

@zanivan

Fixed Playground Demo
Radio Button: I tried it before but does not look good. I found that it is more common for the default checked radio to be primary.
Fixed Table by increasing the background level.
Tabs: the button is a special case at this moment, it does not use theme.typography directly. When the size is md, the font-size is sm.
Fixed Approaches demo.

@zanivan When soft variant is used, I think neutral[200] is too light and neutral[300] is too dark, what do you think about adjusting them a bit?
Current
https://github.com/mui/material-ui/assets/18292247/3e7ffa04-1d88-4931-a93a-41e4dbcee9dc
What I expect
https://github.com/mui/material-ui/assets/18292247/ee256cc9-2ae0-4adf-b03d-e5b3adf7773c

@Studio384 @td5999 Would you mind checking the "Try it out" in the PR description? Would love you to see if there is anything missing before we merge this PR.

@Studio384 @td5999 Would you mind checking the "Try it out" in the PR description? Would love you to see if there is anything missing before we merge this PR.

Looks great! Thanks for the effort!

@siriwatknp When do You plan to merge it? I could really use to this changes.

@siriwatknp When do You plan to merge it? I could really use to this changes.

@td5999 This week! the release will be next week v5.0.0-beta.0.

These changes are great. It's exciting that Joy is moving to beta!

@Studio384 @td5999 Would you mind checking the "Try it out" in the PR description? Would love you to see if there is anything missing before we merge this PR.

I generally like the changes, I do prefer the old grey scale tho, so definitly going to restore that in the implementations we use (or at least the blue shine in it). :) Anyways great work!

@Studio384 @td5999 Would you mind checking the "Try it out" in the PR description? Would love you to see if there is anything missing before we merge this PR.

I generally like the changes, I do prefer the old grey scale tho, so definitly going to restore that in the implementations we use (or at least the blue shine in it). :) Anyways great work!

Thanks for the feedback! in that case you can take a look at this migration doc on how to use the previous neutral and primary colors.

I tried it for a while. And I notice some things that we might want to improve.

Default icon color - Should --joy-palette-text-icon be darker instead? It looks a bit out of place.

BG color in light color scheme - body and level1 shares the same color code, unlike dark color scheme.

The default body text color becomes --joy-palette-text-secondary instead of --joy-palette-text-primary.

@mwskwong Thanks for the feedback!

Default icon color - Should --joy-palette-text-icon be darker instead? It looks a bit out of place.

I feel like the icon color should be lighter than the text to be complementary. That's why I choose neutral.400 as a default icon color.
Some inspiration:

https://tailwindui.com/components/application-ui/application-shells/sidebar

No worry if you want to change it, you can override it via the theme:
extendTheme({
  colorSchemes: {
    light: {
      palette: {
        text: {
          icon: 'var(--joy-palette-neutral-600)',
        }
      }
    },
    dark: { … },
  }
})

BG color in light color scheme - body and level1 shares the same color code, unlike dark color scheme, not sure if that's intentional.

Yes, that's intentional.

The default body text color becomes --joy-palette-text-secondary instead of --joy-palette-text-primary.

Yes, the previous version does not have much contrast between texts. I feel like the new version looks a lot better.

I didn't have the time to comment when this PR was open, I put together all the opportunities that I could spot in https://www.notion.so/mui-org/Olivier-design-review-on-Joy-Design-3ada9a7bcfa44b9fab1fe5032dfb33bb and public link.

I'm not sure if this was the change that caused it, but some recent design changes seemed to break my existing project, and event some of the examples, for example the solid card design doesn't look quite right.

@clarkmcc Hey! Feel free to open an issue in case we can help with any issues due to recent Joy UI updates ⎯ anyhow, it's super cool you're using it; appreciate you giving it a shot!
In this case, although it definitely doesn't look nice, it's not technically broken. That's due to Joy UI's global variants feature, which allows all components to have the same variant set, and their styles to be defined in one place only. It's conceptually a sweet feature and, overall, works fine. But, there are many cases, such as this Card one, where certain variants simply don't make sense (or even look broken, as you pointed out). The tentative solution we're flirting with is "turning off" non-sensical variants for specific components, which still allows us to keep the benefits of globally defined variant styles. There are also other options in the table and it's generally something we want to sort through before the stable version ⎯ so, keep an eye out!


Mod Presets

Is your feature request related to a problem? Please describe.
Depending on who I am playing with (alone, my kids, friends, that other dude, …) I want/need a different set of mods, or even a subset of the same mods, but in a different version.
Describe the solution you'd like
It would be great if I could define separate presets for the same game. Bonus points for an option to toggle between tracking the “default” version of mods (or specific mods!) and keeping a preset-specific one around.
Describe alternatives you've considered
Well … since Lamp keeps everything in the working directory rn (unless that has been stealth-patched?) I have been considering keeping separate configuration directories. Which does do the same thing, basically, but it would be cleaner to have it integrated into the tool. Plus the version tracking thing.
Additional context
BG3MM allows to have different presets for the load order, but not the … uh … “active mods”. So anything that overrides files for just being in the Mods folder has to be manually moved in and out of the folder. Lamp’s deployment approach deals with that problem; it would be nice to have it also support presets, then.

One of my goals is to add Profile support to Lamp, this should.. be
feasible within the next patch, however it requires a rewrite in the way
lamp save an loads modlists so 1.0.8 may take some time.
On Tue, 26 Sept 2023, 06:50 alterNERDtive, @.***> wrote:

Is your feature request related to a problem? Please describe.
Depending on who I am playing with (alone, my kids, friends, that other
dude, …) I want/need a different set of mods, or even a subset of the same
mods, but in a different version.
Describe the solution you'd like
It would be great if I could define separate presets for the same game.
Bonus points for an option to toggle between tracking the “default” version
of mods (or specific mods!) and keeping a preset-specific one around.
Describe alternatives you've considered
Well … since Lamp keeps everything in the working directory rn (unless
that has been stealth-patched?) I have been considering keeping separate
configuration directories. Which does do the same thing, basically, but
it would be cleaner to have it integrated into the tool. Plus the version
tracking thing.
Additional context
BG3MM allows to have different presets for the load order, but not the
… uh … “active mods”. So anything that overrides files for just being in
the Mods folder has to be manually moved in and out of the folder. Lamp’s
deployment approach deals with that problem; it would be nice to have it
also support presets, then.
—
Reply to this email directly, view it on GitHub
https://github.com/CHollingworth/Lamp/issues/38, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ARGLQVJL253ATTP723XETDTX4JUJZANCNFSM6AAAAAA5HEGEKU
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


Deleting alarm attributes from the modeling

Latest testing showed that none of the devices under test is supporting alarms in the PureEthernetStructure and the HybridMwStructure.
Vendors not participating in the tests also confirmed that their devices don't implement alarms on these interfaces.
Proposal:
It should be considered to remove:

HybridMwStructureCapability::supportedAlarmList attribute
HybridMwStructureConfiguration::problemKindSeverityList attribute incl. ProblemKindSeverityType datatype and SeverityType enumeration
HybridMwStructureConfiguration::g826ThresholdCrossAlarmList attribute incl. G826ThresholdCrossAlarmType datatype and G826Type enumeration
HybridMwStructureConfiguration::clearingThresholdCrossAlarmsIsOn attribute
HybridMwStructureCurrentProblems class incl. HybridMwStructureCurrentProblemType datatype and CurrentProblem class

Decision at the 5G-xhaul call on Tuesday 2nd of September 2020:
The following elements shall be removed:

HybridMwStructureCapability::supportedAlarmList attribute
HybridMwStructureConfiguration::problemKindSeverityList attribute incl. ProblemKindSeverityType datatype and SeverityType enumeration
HybridMwStructureConfiguration::g826ThresholdCrossAlarmList attribute incl. G826ThresholdCrossAlarmType datatype and G826Type enumeration
HybridMwStructureConfiguration::clearingThresholdCrossAlarmsIsOn attribute
HybridMwStructureCurrentProblems class incl. HybridMwStructureCurrentProblemType datatype and CurrentProblem class

Updating UML and YANG required.

Based on the fact that 1+1 protection implementation by one vendor requires the implementation of alarms, PM and its configuration, the decision from Sep2 2020 is reverted.
As a consequence the vendors should implement the default values stating that the related implementation is not supported.

No change required at the modeling. Issue => closed


Add sass/scss generators

ref https://github.com/sass/sassc-rails/issues/74
This is just copies of rails/sass-rails's generators.
But this works correctly.

should maintainer closed it?

Just came across this. Is there a reason why this PR hasn't been merged for almost 18 months?

sorry but something went wrong there, rails g scaffold with gem "sassc-rails" installed doesn't works with same error scss problem.
If this project is abandonned/deprecated, just tell it and we will forget it.
thank you for your great communication

I see you are close this, but no communication has been made.
Could you find someone able to communicate something before to close please ?
it should be informative and nice


Added Zsh Support

Support for Zsh users.

Thanks @oleg-alexandrov , just pushed a typo fix

Thank you.
Running configure.sh will each time add more lines to .zshrc. I hope you can test if that is the case. Then note the logic used with .bashrc where a grep call first checks if the desired line is already in. Maybe you can do something similar and test that this time it does not add lines to .zshrc if already present.

Yes indeed! I'll add that check in and re-push, thanks for the feedback @oleg-alexandrov and @marinagmoreira!

Updated :)

Looks good to me. Did you test that the .zshrc gets updated, and only once?

Yes, it did not add anything else to my .zshrc. I also modified the check for Zsh, to only set it if the user $SHELL is Zsh

Sounds good. I will leave it up to Marina to approve and bring in the change.

@marinagmoreira should this be merged? or waiting for @oleg-alexandrov ?


Docker image

Hi the project good :) Any plans for adding a docker image?

Yes! planning to make a public docker image. ATM there's a dockerfile in the server directory as well.

Added a section to the docs that link to the official self hosting docs, and now have a directory titled "docker-images" where I'll be adding more and more images for just self hosting what you need, and not what you dont.


Revert "Explicitly disallow network pluginv1 creation in swarm mode."

This reverts commit 0b0e2a4bd9006c97356989abffa184f51a0058bb.
I realized this PR was merged directly to bump_v1.13.1, but it should have been opened against master and cherry-picked afterwards. Also @anusha-ragunathan mentioned that there are some additional fixes to add. We'll take care of these in a new PR and then cherry-pick everything.
cc @mavenugo

LGTM

Master PR https://github.com/docker/swarmkit/pull/1899


doesn't work

hi
Keeps saying:
GrabVer - No save task detected
MAJOR=1
MINOR=0
PATCH=56
PRE_RELEASE=
incrementOn=
BUILD=3
CODE=3

How we can display version name in  controller.

Sorry guys, all is written in the README usage section.


How to train the model？

Hello, how to train the new model, can you explain the steps of data processing and training model in detail? Want to replicate your approach.

Thanks for asking. Please check our updated README


Visualization sometimes shows wrong item-rate

If an item is produced by multiple recipes, the visualization will show the wrong rate for it.

Fixed in a70654acab5ca640ca58f2ff00e1cc4ba0ffbf7c.


Registry not storing actor names.

This is likely a supervision issue, but in case it's not I'm starting here first... and either way, this affects usage of Celluloid::Actor[] ... working on reproductions, but not seeing consistent failure/success yet.

@digitalextremist - beware - registry appears twice in the Celluloid tree (the 0.17-x branch with logging/namespace thing). And as far as I know, actors can be "renamed" accidentally through the registry (via a NamingRequest).

@e2 that got cleaned out yesterday?

@digitalextremist - how was I supposed to know?

Revision of problem: Items are stored, but somehow they are being cleared from the registry.

Something @niamster did in #585 resolved this!


Fast rotation for 90, 180, and 270 degree

🚀 The feature
90, 180, and 270 degree rotation can be done without interpolation by simply re-arranging the data. This is significantly faster, especially for high resolution image.
 Currently PyTorch already has torch.rot90(), which is significantly faster than torchvision.transforms.v2.functional.rotate(). In some applications, it is acceptable to use only 90, 180, and 270 degree rotation for augmentation (cross-ref #566).
Perhaps torchvision.transforms.v2.functional.rotate() can check for 90, 180, and 270 specifically, and call torch.rot90()?
Alternatives
A workaround is to write a custom transform to use torch.rot90().
Additional context
Micro-benchmark results
import torch
import torchvision.transforms.v2.functional as TF
import time

N = 100

input = torch.randn(3, 1024, 1024)
output1 = TF.rotate(input, 90)
output2 = torch.rot90(input, k=1, dims=(1, 2))

torch.testing.assert_close(output1, output2)

def benchmark(fn, *args):
    time0 = time.perf_counter()
    for _ in range(N):
        fn(input, *args)
    return N / (time.perf_counter() - time0)

print(benchmark(TF.rotate, 90))
print(benchmark(torch.rot90, 1, (1, 2)))

Function
Throughput (it/s)

TF.rotate()
52.95

torch.rot90()
10,748.12

Thank you for the feature request @gau-nernst . This is indeed something we should consider for inclusion. Let us know if you're interested in submitting a PR for this.

@NicolasHug Sure, I can give it a try.

Thanks! Let's try to add that functionality only to torchvision.transforms.v2.functional.rotate (i.e. you do not need to worry about torchvision.transforms.functional.rotate)


Revert "Make Sorbet faster to start in debug build (#8050)"

This reverts commit 5101acfc7268f63cbab1ca714c19529bf432b665.

Motivation

Somehow this caused CI to become flaky?
Test plan

bazel test --config=buildfarm-sanitized-linux --test_summary=terse --build_tests_only //test/lsp:multithreaded_protocol_test_corpus --runs_per_test=200

This failed with a 7% rate on my devbox with the changes in #8050, and didn't
fail at all without those changes.

Do you have the energy to try to reland individual changes, so maybe we can bisect on master?

I'm already working on this, it just takes 30 minutes to run the test to bisect because the multithreaded test is slow and the failures are so rare to reproduce.


Adding knapsack DP for java and pythom

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is.
https://github.com/Algo-Phantoms/Algo-Tree/tree/main/Algorithm/DP the solution for java and python are missing.
I want to work on this.
Describe the solution you'd like
A clear and concise description of what you want to happen.
Do you want to work on it
Mention the one language you want to be assigned for this issue.

Assign me please

@tarun26091999 please assign this issue to me in C++.

Note you have to create one two different PRs for different languages

I want to do it in c++ @rish-singhal

Hey @rish-singhal  Can you add level 3 if you feel so. As I opened this issue for java and python for medium difficulty DP problem

Isn't knapsack dp a standard dp problem?

Also you have to submit 2 different PRs for each language


Custom python decorator with class methods

See #574
from boa3.builtin import CreateNewEvent, public

x = SomeClass()

@x.onlyOwner
@public
def withdraw() -> bool:
    pass

Only decorators that calls class functions is going to be implemented in this issue

https://app.clickup.com/t/2ewf04r


how to upgrade to EAP 1.1.4

between this file https://github.com/Kotlin/kotlin-fullstack-sample/blob/master/build.gradle and https://github.com/Kotlin/kotlin-fullstack-sample/blob/master/frontend/build.gradle there are 12 versions:

ext.kotlin_version
kotlin-gradle-plugin
kotlin-frontend-plugin
html_version
ktor_version
squash_version
kotlin-stdlib-js
kotlin-test-js
kotlinx-html-js
kotlinx-html-js (replaceVersion)
kotlinx-html-shared (replaceVersion)
kotlin-js-library (replaceVersion)

I'm trying to update to EAP 1.1.4 but it's very confusing which versions to update and get it to still build. Can anyone make a PR with this fullstack sample using the latest and greatest version?

It's not so easy for now as many things need to be in-sync. At least custom repositories need to be added,ext.kotlin_version and kotlinx-html-js should be amended.


Events sent over /sendToDevice never arrive

The sliding sync proxy seems to have support for to-device messaging via the extensions field in the sync response. Sadly that field never seems to contain an events field nor any events.

The left side shows the capture of mitmproxy script that outpus the current pos and the to_device field of sync responses a client receives.
The right side shows how we're sending two m.dummy events to the server, once for the specific device that is using sliding sync, and once a wildcard is used to send the event to all devices. Neither event is received over sliding sync.
Element web received the * message just fine:

For completeness, here's the mitmproxy script that was used to output the log in the left window:
import json

from mitmproxy import http, ctx

log_file = open("/home/poljar/to-device.log", "wt")

def response(flow: http.HTTPFlow) -> None:
    if flow.request.path.startswith("/_matrix/client/unstable/org.matrix.msc3575/sync"):
        if flow.response.status_code == 200:
            try:
                body = json.loads(flow.response.content)

                to_device = body["extensions"]["to_device"]
                pos = body["pos"]

                line = f"Received a sync response pos {pos}, to-device field {to_device}"

                ctx.log(line)
                log_file.writelines(line + '\n')
                log_file.flush()

            except KeyError as e:
                ctx.log(f"Error finding to-device {e}")

running the latest sliding-sync proxy locally, I can see we receive to-device events (with jack-in the matrix testing client), but not over ROSA... I can confirm this seems to be a problem on the public setup.

Are you using different access tokens when testing? If you reuse the access token the proxy is using in say Element-Web then you may end up not seeing to-device messages as they will be racing with each other.

Are you using different access tokens when testing?

jack-in has its own login now, so they are separate access tokens now.

Have you tried logging out the access token used in the proxy and then logging in again with a fresh access token? I did play around with the database a few days ago when updating versions so it's possible that the device in question isn't polling.

Whoops, failed to clicked comment :/

Have you tried logging out the access token used in the proxy and then logging in again with a fresh access token? I did play around with the database a few days ago when updating versions so it's possible that the device in question isn't polling.

Tests were made with a fresh, never used access token. E2EE won't work with access tokens that Element has used.

Can you please:

test it again, and let me know the timestamps (UTC).
Include the output of https://slidingsync.lab.element.dev/client/server.json from when you did the test.

Follow up Qs:

Is this 100% reproducible? It sounds like it is? As in, no to-device messages get to the client at all.
Exactly what is your /sendToDevice request? I'll need this to add a regression test.

Can you please:

Sure.

Follow up Qs:
Is this 100% reproducible? It sounds like it is? As in, no to-device messages get to the client at all.

Correct, I tried this out some 3-5 times, every time the same behavior was observed. I don't see any traffic arriving over to-device at all, I left it on for an hour and no traffic ever arrived. The token never changes either.

Exactly what is your /sendToDevice request? I'll need this to add a regression test.

Well I tried this in combination with Element first, which sent m.room.encrypted events that seemingly don't arrive. After being confused I confirmed my suspicion that E2EE is broken because to-device traffic isn't arriving. I tried to send m.dummy events like it's shown in the above pictures using the following command line:
https -A bearer -a "$ACCESS_TOKEN" PUT https://matrix.org/_matrix/client/v3/sendToDevice/m.dummy/"$(shuf -i 1-100000000 -n 1)" messages:='{"@poljar:matrix.org": { "*": {} } }'

https is httpie: https://github.com/httpie/httpie. I used the access token from Element for the command, but that should hardly matter since I'm using a wildcard recipient as the device anyways.

Few more Qs:

when you say it works locally, what is running locally? Just the proxy or a proxy and a local synapse?
if you do an initial (no ?pos request), do those messages arrive?

when you say it works locally, what is running locally? Just the proxy or a proxy and a local synapse?

proxy only, against matrix.org

What proxy version is shown at startup?

sliding-sync-sliding-sync-1  | Sync v3 [0.5.2] (37d3937f9502cc635bf37da3e968c054c58d5257)
sliding-sync-sliding-sync-1  | 11:13:07 INF creating handler
sliding-sync-sliding-sync-1  | 11:13:13 INF retrieved global snapshot from database
sliding-sync-sliding-sync-1  | 11:13:13 INF listening on <IP_ADDRESS>:8008
sliding-sync-sliding-sync-1  | 11:13:13 INF StartV2Pollers num_devices=2

if you do an initial (no ?pos request), do those messages arrive?

To, clarify you mean: the proxy is running, to-device is sent, the sliding-sync client is starting and fetching initially? Do they arrive? No.

sliding-sync-sliding-sync-1  | 11:16:19 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:21 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:21 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:23 INF created new connection conn_id=5825900661df909b469444168e23c413a41de4384b584155123800a0a0e62fd9 user=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:24 INF  ag=18 d=1 duration=986.932024 p=0 q=1 r=21 size=158482 status=200 u=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:24 INF  duration=376.807044 p=1 q=2 r=20 size=143638 status=200 u=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:25 INF  duration=87.620768 p=2 q=3 r=20 size=148315 status=200 u=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:25 INF  duration=579.47338 p=3 q=4 r=20 size=140547 status=200 u=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:26 INF  duration=193.19893 p=4 q=5 r=20 size=43922 status=200 u=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:26 INF  duration=169.465957 p=5 q=6 r=20 size=24934 status=200 u=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:26 INF  duration=157.550752 p=6 q=7 r=20 size=23771 status=200 u=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:26 INF  duration=103.35003 p=7 q=8 r=9 size=9172 status=200 u=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:27 INF  duration=812.212366 p=8 q=9 r=140 size=665884 status=200 u=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:32 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:35 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:35 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:36 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:36 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:37 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,1,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:39 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:46 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:46 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:47 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:47 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:48 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,1,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:50 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:50 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:52 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:54 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:57 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:16:57 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:17:00 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:17:00 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:17:02 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:17:03 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:17:03 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,1,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:17:04 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:17:05 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:17:10 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:17:10 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:17:11 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:17:11 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:17:14 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:17:17 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:17:17 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:17:18 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:17:19 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:17:20 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:17:21 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,1,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:17:22 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:17:22 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:17:24 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:17:27 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:17:27 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:17:28 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:17:29 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org

The only scenario that works for me locally:

have proxy running
start sliding sync (jack-in), waiting for sync
send https as described above to synapse
await in sliding sync to tell me:

 │13:18:23:TRACE:matrix_sdk_base::sliding_sync:crates/matrix-sdk-base/src/sliding_sync.rs:48:1 ToDevice Events found                                │

Regardless of that, the proxy never shows any log with to_device=1 ...

building latest git main now:
sliding-sync-sliding-sync-1  | Sync v3 [0.5.2] (37d3937f9502cc635bf37da3e968c054c58d5257)
sliding-sync-sliding-sync-1  | 11:21:48 INF creating handler
sliding-sync-sliding-sync-1  | 11:21:52 INF retrieved global snapshot from database
sliding-sync-sliding-sync-1  | 11:21:52 INF listening on <IP_ADDRESS>:8008
sliding-sync-sliding-sync-1  | 11:21:52 INF StartV2Pollers num_devices=2

Seems to be identical: Nothing at startup (or it runs by too fast, inline logs) but I see it if I trigger it via https.
Switching to ROSA: no 1 ToDevice in my jack-in logs :( .

To, clarify you mean: the proxy is running, to-device is sent, the sliding-sync client is starting and fetching initially? Do they arrive? No.

So there's 3 scenairos I'm interested in:
Initial login:

/login with a new device ID
On another account send to-device to this device ID.
Hit proxy for the first time (login) -> do you get it? Sounds like no.

Polling:

/login with a new device ID
Hit proxy for first time (login) - begin polling.
Send to-device -> do you get it? Sounds like yes locally only.

Initial proxy connection:

/login with a new device ID
Hit proxy for first time (login) - begin polling.
Stop your polling loop on the client, proxy poller is still running.
Send to-device -> start polling with no ?pos= set -> do you get it? Sounds like yes locally only.

I offer the:

Totally fresh local proxy
totally fresh local login for sliding-sync
first start against the local proxy - see's 0 pending to-device messages

sliding-sync-sliding-sync-1  |  github.com/matrix-org/sync-v3/cmd/syncv3/main.go:123 +0x10c5
sliding-sync-sliding-sync-1  | Sync v3 [0.5.2] (f6a482154f28cae2e73788204b41a730e052fc7f)
sliding-sync-sliding-sync-1  | 11:36:35 INF creating handler
sliding-sync-sliding-sync-1  | 11:36:35 INF retrieved global snapshot from database
sliding-sync-sliding-sync-1  | 11:36:35 INF listening on <IP_ADDRESS>:8008
sliding-sync-sliding-sync-1  | 11:36:35 INF StartV2Pollers num_devices=0
sliding-sync-sliding-sync-1  | 11:36:35 INF StartV2Pollers finished
sliding-sync-sliding-sync-1  | 11:37:45 INF EnsurePolling: new request user=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:37:45 INF EnsurePolling: request finished user=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:37:45 INF EnsurePolling lock acquired device=f325848532b0919714a3945a6422dfefc4e86aa0a5c966ae04dff69526c4ad53 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:37:45 INF Poller: v2 poll loop started since= user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:39:13 INF Poller: valid initial sync response received user_id=@gnunicorn:matrix.org
qsliding-sync-sliding-sync-1  | 11:39:26 INF Poller: accumulated data rooms [invite,join,leave]=[0,150,0] storage [states,timelines,typing]=[150,150,51] to_device=0 user_id=@gnunicorn:matrix.org

content of the sliding-sync response, see's 0 pending to-device messages.
sending message via httpie. Client sees it - proxy does not report sending it.

│13:40:56:DEBUG:matrix_sdk_base::sliding_sync:crates/matrix-sdk-base/src/sliding_sync.rs:228:ready to submit changes to store                      │
 │13:40:56:DEBUG:matrix_sdk_base::sliding_sync:crates/matrix-sdk-base/src/sliding_sync.rs:232:applied changes                                       │
 │13:40:56:TRACE:matrix_sdk_base::sliding_sync:crates/matrix-sdk-base/src/sliding_sync.rs:48:2 ToDevice Events found                                │
 │13:40:56:DEBUG:matrix_sdk_base::sliding_sync:crates/matrix-sdk-base/src/sliding_sync.rs:228:ready to submit changes to store                      │
 │13:40:56:DEBUG:matrix_sdk_base::sliding_sync:crates/matrix-sdk-base/src/sliding_sync.rs:232:applied changes

Proxy:
sliding-sync-sliding-sync-1  | 11:40:56 INF  duration=10001.106336 p=20 q=21 r=0 size=157 status=200 u=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:40:56 INF  duration=0.151767 p=20 q=21 r=0 size=157 status=200 u=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:40:56 INF  d=2 duration=2.676434 p=21 q=22 r=0 size=1777 status=200 u=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:40:58 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:40:59 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:40:59 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:41:07 INF  duration=10001.866494 p=22 q=23 r=0 size=157 status=200 u=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:41:07 INF  duration=0.144705 p=22 q=23 r=0 size=157 status=200 u=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:41:09 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:41:09 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:41:10 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,0] to_device=0 user_id=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:41:17 INF  duration=10001.076636 p=23 q=24 r=0 size=157 status=200 u=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:41:17 INF  duration=0.230116 p=23 q=24 r=0 size=157 status=200 u=@gnunicorn:matrix.org
sliding-sync-sliding-sync-1  | 11:41:19 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org

shutting down client. sending message. wait 2s. starting client with new login: liding_sync:crates/matrix-sdk-base/src/sliding_sync.rs:48:0 ToDevice Events found
shutting down client. sending message. wait 2s. start client with existing login:

base::sliding_sync:crates/matrix-sdk-base/src/sliding_sync.rs:48:0 ToDevice Events found

keep client running, sending message: rc/sliding_sync.rs:48:1 ToDevice Events found

With the proxy kept running, all local. On remote, as said, we don't see any to-device make it through, no matter if fresh or old login.

proxy does not report sending it.

The cryptic keys do report 2 to-device messages sent from the proxy to the client:
11:40:56 INF  d=2 duration=2.676434 p=21 q=22 r=0 size=1777 status=200 u=@gnunicorn:matrix.org

d is the number of to-device events, p and q are the sent/next positions, r is the number of rooms in the top-level rooms JSON, u is the user. There's a bunch more as well for device list changes, etc.
So it sounds like everything works fine locally then? Is that correct?

ah, okay. that was non-obvious. I was looking at this, which never turns non 0:
sliding-sync-sliding-sync-1  | 11:41:09 INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org

So it sounds like everything works fine locally then? Is that correct?

I am not clear for how long to-device messages are meant to be held by sync before discarding them - so if we aren't connected, we don't see them. But I guess that is correct? Then yes, locally, it seems to work fine.

I am not clear for how long to-device messages are meant to be held by sync before discarding them

Indefinitely as they may contain keys.

so if we aren't connected, we don't see them.

You should see them, assuming Synapse gives them to us.
INF Poller: accumulated data rooms [invite,join,leave]=[0,1,0] storage [states,timelines,typing]=[0,0,1] to_device=0 user_id=@gnunicorn:matrix.org is what the proxy received from the normal /sync request, so it never received to_device events.

I am not clear for how long to-device messages are meant to be held by sync before discarding them - so if we aren't connected, we don't see them. But I guess that is correct? Then yes, locally, it seems to work fine.

They are kept in the inbox until the Client confirms that it has received the sync response containing them. In other words, once the client uses the next_batch token that was received in the sync response containing a given to-device message, the server can discard the to-device event.

Regression tests added in https://github.com/matrix-org/sliding-sync/commit/52648b000f0c4ba34ea71cca66ba9ae7a247c3e8 (note sad red X)
Fixed in https://github.com/matrix-org/sliding-sync/commit/59f67d9b6a0bb726ca304c91c356425857c8eacc (note green tick)
Thanks for the detailed report and prompt feedback, as this really helped me nail down the issue!


Weird behavior of stargaze node

During normal node operation as API node (not validator) notice weird error about db corruption:
Mar 10 19:08:59 stargaze-api cosmovisor[108670]: 7:08PM INF minted coins from module account amount=174289265ustars from=mint module=x/bank
Mar 10 19:08:59 stargaze-api cosmovisor[108670]: 7:08PM INF executed block height=1948953 module=state num_invalid_txs=1 num_valid_txs=1
Mar 10 19:08:59 stargaze-api cosmovisor[108670]: 7:08PM INF commit synced commit=436F6D6D697449447B5B323534203232362031313720393920313034203436203138392036302031373120313234203131203135382037312031392039332031303120323138203536203135362038392039322031313420383220313632203130372031393620393720313532203135352031343220313539203131375D3A3144424431397D
Mar 10 19:08:59 stargaze-api cosmovisor[108670]: 7:08PM INF committed state app_hash=FEE27563682EBD3CAB7C0B9E47135D65DA389C595C7252A26BC461989B8E9F75 height=1948953 module=state num_txs=2
Mar 10 19:08:59 stargaze-api cosmovisor[108670]: 7:08PM ERR failed to index block err="leveldb/table: corruption on data-block (pos=70628): checksum mismatch, want=0xaa3b782f got=0x5c78c494 [file=5117300.ldb]" height=1948953 module=txindex
Mar 10 19:08:59 stargaze-api cosmovisor[108670]: 7:08PM ERR failed to index block txs err="leveldb/table: corruption on data-block (pos=70628): checksum mismatch, want=0xaa3b782f got=0x5c78c494 [file=5117300.ldb]" height=1948953 module=txindex

Mar 10 19:09:06 stargaze-api cosmovisor[108670]: 7:09PM INF executed block height=1948954 module=state num_invalid_txs=1 num_valid_txs=15
Mar 10 19:09:06 stargaze-api cosmovisor[108670]: 7:09PM INF commit synced commit=436F6D6D697449447B5B32333520323239203137312031323520313620383320313530203132342032333720313036203130203132322031373820313135203834203234362031313620393520323237203334203235322032333820323531203230312037362039203138302032323020383820353720323530203139355D3A3144424431417D
Mar 10 19:09:06 stargaze-api cosmovisor[108670]: 7:09PM INF committed state app_hash=EBE5AB7D1053967CED6A0A7AB27354F6745FE322FCEEFBC94C09B4DC5839FAC3 height=1948954 module=state num_txs=16
Mar 10 19:09:06 stargaze-api cosmovisor[108670]: 7:09PM ERR failed to index block err="leveldb/table: corruption on data-block (pos=70628): checksum mismatch, want=0xaa3b782f got=0x5c78c494 [file=5117300.ldb]" height=1948954 module=txindex
Mar 10 19:09:06 stargaze-api cosmovisor[108670]: 7:09PM ERR failed to index block txs err="leveldb/table: corruption on data-block (pos=70628): checksum mismatch, want=0xaa3b782f got=0x5c78c494 [file=5117300.ldb]" height=1948954 module=txindex
Mar 10 19:09:12 stargaze-api cosmovisor[108670]: 7:09PM INF minted coins from module account amount=174289265ustars from=mint module=x/bank
Mar 10 19:09:12 stargaze-api cosmovisor[108670]: 7:09PM INF executed block height=1948955 module=state num_invalid_txs=0 num_valid_txs=0
Mar 10 19:09:12 stargaze-api cosmovisor[108670]: 7:09PM INF commit synced commit=436F6D6D697449447B5B39382038392033362032203134362031313520313435203138332032203235342032323420313233203133392031302032313720323031203136302037342036352038362037372032313420363120343720323330203234302031343420313938203138342031333320323230203131325D3A3144424431427D
Mar 10 19:09:12 stargaze-api cosmovisor[108670]: 7:09PM INF committed state app_hash=62592402927391B702FEE07B8B0AD9C9A04A41564DD63D2FE6F090C6B885DC70 height=1948955 module=state num_txs=0
Mar 10 19:09:12 stargaze-api cosmovisor[108670]: 7:09PM ERR failed to index block err="leveldb/table: corruption on data-block (pos=70628): checksum mismatch, want=0xaa3b782f got=0x5c78c494 [file=5117300.ldb]" height=1948955 module=txindex

I'm not very sure if that should be considered as bug, but normally cosmos nodes crash after such error.
But in my case node continued sync and work well after service restart.

seems like the corruption ocurred at the index.db, and that why it continued to work since is not really necessary for its functionality (you can disable indexing and remove the file), does performing any tx search work ?
starsd q tx [hash]

seems like the corruption ocurred at the index.db, and that why it continued to work since is not really necessary for its functionality (you can disable indexing and remove the file), does performing any tx search work ? starsd q tx [hash]

yep, i'm able to query transactions from cli, but node at the same time not showing any level-db related errors at the moment
is there something else we may discover\test on that node?


Update langchain-pinecone dependency and add Pinecone API key

Hi again, I re-deploy langchain but I still get this error

I don't think it has been fixed. Am I doing something wrong?
Thanks


Prepare weather widget support for multiple languages

Branch location:

https://code.google.com/r/claudio-dashclock-clone/

Revisions:

Relevant changes where done in f2dded16c3c5 and 5d37125ca826

Reason for request:
Yahoo weather only offers english condition descriptions. As the condition can
also be determined by using the condition code I did move the descriptions into
a resources file. This can now easily be translated into any language by
translating weather_condition_code.xml.

Original issue reported on code.google.com by<EMAIL_ADDRESS>on 14 Feb 2013 at 4:20

Reason for closing? :)

I don't plan on adding any new functionality to existing extensions unfortunately :( There are a ton of better weather extensions out there today.


examples: Upgrade self-hosted Kubernetes to v1.5.1

Update bootkube version to stop requiring the forked binary; bootkube now allows DNS names
https://github.com/kubernetes-incubator/bootkube/pull/151

cc @aaronlevy

One note about version skew, but otherwise lgtm

Updated to bootkube v0.3.1 and ran tests again.


setting api_key on workos instead of workos_client ?

Hi there,
I'm using workos v1.21.0 on python 3.8.16 with fastapi 0.89.1
I've been following this guide:
https://workos.com/docs/magic-link/1-add-magic-link-to-your-app/create-a-passwordless-session-and-email-the-user
And noticed that to add the api_key and client _id we need to do:
from workos import client as workos_client

workos_client.api_key = "123"
workos_client.client_id = "123"

I haven't been able to add my api keys this way and instead had to do:
import workos

workos.api_key = "123"
workos.client_id = "123"

If you view the following lines https://github.com/workos/workos-python/blob/9f9a90a6bb4982cf0f34e6039f842c5a57f69aa2/workos/utils/validation.py#L44-L52
You'll see that getattr is done on workos directly (which has the api_key and client_id) https://github.com/workos/workos-python/blob/c337704900fa6698e7cfc1f172104717aae8ecdf/workos/init.py#L6-L7
So I'm wondering if I'm doing something wrong or if it's an issue with the docs

The Docs have been updated to align with the SDK:


SequenceFormula silently fails on math error

When a formula cannot be calculated on a particular nonnegative integer, for example because of division by 0, Numberscope silently fails, and the formula is not selected, but there is no feedback to the user.
To reproduce: Start Numberscope, select "Sequence by Formula", enter floor(100/n), and click "Save Changes". The formula entry window disappears, but no Sequence is selected, and there is no feedback about the error.
I believe the plan to address this issue is to perform formula calculations in the backend and cache the initial nonnegative range that the formula produces (integer) values for (if any), and then use that as the range for the resulting Sequence object.

Similar problematic behavior occurs if the formula produces finite non-integer values.


feat(plugin-chart-echarts): bar chart which includes two types(time-series and non-time-series)

Bar chart combines time-series scenes and non-time-series ones, can be toggled to render each one separately.
time-series

non-time-series

The codebase on this repo has been moved to the main Apache Superset repo, and consequently the repo is in the process of being archived. See the Superset Improvement Proposal for details: https://github.com/apache/superset/issues/13013 . While all currently open issues and PRs will be closed, we encourage you to reopen this PR on the main repo, which should be as simple as moving over any code changes as follows:

core packages: packages/** (this repo) -> superset-frontend/packages/** (main repo)
plugins: plugins/** (this repo) -> superset-frontend/plugins/** (main repo)

If you need help with the migration, please post a message on the SIP or reach out on the community Slack.


Fix some memory management issues [AUTOZIP]

Small issues with memory leaks and double-free

Download:
Environment: QT=5.12, ARCH=32, CONFIGURATION=release, QTIFW=C:\Qt\Tools\QtInstallerFramework\3.1
trik-studio-master-i686-auto.zip