Update TS130f covers quirk

A couple of changes here:

remove the duplicated quirk definition TuyaMoesDiyRf433TS130F (exactly the same as TuyaTS130FTI2)
add a new TuyaTS130Double_GP quirk

Fix: #1582

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 79.981%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
5937

Relevant Lines:
7423

💛  - Coveralls

Codecov Report
Base: 79.98% // Head: 79.98% // No change to project coverage :thumbsup:

Coverage data is based on head (d92f47e) compared to base (2cd9f10).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@           Coverage Diff           @@
##              dev    #1807   +/-   ##
=======================================
  Coverage   79.98%   79.98%
=======================================
  Files         239      239
  Lines        7423     7423
=======================================
  Hits         5937     5937
  Misses       1486     1486

Impacted Files
Coverage Δ

zhaquirks/tuya/ts130f.py
83.01% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

The files compare is not helping here.
I have moved the TuyaTS130FTI2 upwards to the TuyaMoesDiyRf433TS130F definition (and I have replaced it).
And github is comparing the new TuyaTS130Double_GP against the moved TuyaTS130FTI2, but the TuyaTS130Double_GP is fully new definition.

OK i understand the view is telling its updated the device class and in the real (if expanding all the quirk) its one new class "made" of one duplicated device class.
Sorry for making trouble and god work done as normal !!

No problem. It is great to have other eyes that review what I do.
Thank you. 🙇🏻♂


Implement Reminder System for Expiry and Low Stock

Create a reminder system that alerts users when their prescriptions are close to expiry (e.g., 7 days before) or when the stock is running low (e.g., 10 left). This system should use a separate window or UI indicators for prescriptions that fit these criteria.

User stories:
As an organized patient,
I can get a reminder when certain pills are running low/expiring
so that I know when to visit the pharmacy to restock.


chore: bdd-gh-1583759461 to 0.0.1

chore: Promote bdd-gh-1583759461 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

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


Demo editor - Cursor out of text area after select all and backspace

On Demo page:

Open https://demo.umodoc.com/editor?lang=en-US&pane=hide&theme=light
Click select all button on toolbar
Press backspace key

Behavior:
Cursor is at the top corner of page and sometimes you can even type there

The issue you're encountering with the cursor behavior after pressing backspace has been addressed in version 4.5.0 of Umo Editor. Please update to the latest version to resolve this problem.


Could not parse this expression for CASE WHEN Query in .moor File

I have a problem when doing a Query using the CASE WHEN condition, a problem that appears with the message "Could not parse this expression. Note: This is a reserved keyword, you can escape it in double ticks".
Example of the query:
CASE WHEN (        SELECT A.tittle FROM todo A ) IS NOT NULL  THEN  CASE WHEN (       ........ ) END
Please help for this problem ...

On which position in the query does that error occur? I  couldn't reproduce this from the snippet you posted (the following parses just fine):
SELECT
CASE
  WHEN
    ( SELECT A.tittle FROM todo A ) IS NOT NULL
    THEN 1
  ELSE 0
END

When parsing queries, moor is a bit more strict than sqlite. Sqlite allows some keywords to be used as column names in queries if that doesn't make the query ambigous. Moor doesn't, so if you want to use a column name that's a reserved keyword, you need to wrap it in double ticks: SELECT a."start" FROM a;.
If you can post the full query, I can help you find the error and how to fix it. But the error message from the generator should point towards the right position.

Hi @simolus3,
Thanks for your advice  for this case, I don't know what the problem is in my query, but when it runs on sqlite everything works fine, maybe you can provide a solution, please help me to solve this problem..
   I've fixed the parsing bug in sqlparser. Until the next update, you could wrap the nested CASE expressions in parentheses as a workaround. E.g. IS NOT NULL THEN (CASE WHEN ... )

Wow your very fast in responding to problem, thank you very much for your help, happy to use your library.
I will wait for the update.
Thanks @simolus3

One more question @simolus3,
I have problem in this sub query for this Table Stock is undefined maybe in clause
WHERE A.td_pcode = stock.p_code
SELECT (SELECT td_qtypcs FROM transaction_detail A WHERE A.td_pcode = stock.p_code) AS transactions FROM (SELECT A.*, B.ps_qty FROM product_master A LEFT JOIN product_stock B ON A.p_code = B.ps_code WHERE B.ps_qty > 0) AS stock
Any solution for this case @simolus3 Please help me ...

Can you post the table definitions? That would make it easier for me to reproduce this, thanks.

Piggybacking on this question, @simolus3 is there a recommended way to do CASE WHEN using moor directly instead of using raw SQL.
Basically, I have a bunch of fields like this:
TextColumn get name => text()();
DateTimeColumn get nameUpdatedAt => dateTime().withDefault(currentDateAndTime)();
BoolColumn get deleted => boolean().withDefault(const Constant(false))();
DateTimeColumn get deletedUpdatedAt => dateTime().withDefault(currentDateAndTime)();

And I want to do an upsert, and only update both name and nameUpdatedAt if the new nameUpdatedAt is bigger, something like this:
into(tags).insert(tag,
        onConflict: DoUpdate((old) => TagsCompanion.custom(
              name: (old.nameUpdatedAt > tag.nameUpdatedAt) ? old.name: tag.name,
              nameUpdatedAt: (old.nameUpdatedAt > tag.nameUpdatedAt) ? old.nameUpdatedAt: tag.nameUpdatedAt,
              ...
            )));

but this is invalid. Any idea of how to write this correctly?  I checked the expression documentation but didn't find the answer.
I think I can use CustomExpression but I want to prevent that if possible.
ps. awesome library btw.

@sainoba #806 looks like the right issue to use CASE WHEN in the Dart api, I'll take a look at that now.


Version upgrade to CUDA 11.4

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

#39 just merged! this PR now needs to be rebased/updated, thanks!

Thanks a lot @xmnlab. Just pushed the update.


mbuffer: 20171011 -> 20180318

Semi-automatic update generated by https://github.com/ryantm/nix-update tools.
This update was made based on information from https://repology.org/metapackage/mbuffer/versions.
These checks were done:

built on NixOS
ran /nix/store/sjlbs2k9114xlxalqcz2n0jj90lvik07-mbuffer-20180318/bin/mbuffer -h got 0 exit code
ran /nix/store/sjlbs2k9114xlxalqcz2n0jj90lvik07-mbuffer-20180318/bin/mbuffer --help got 0 exit code
ran /nix/store/sjlbs2k9114xlxalqcz2n0jj90lvik07-mbuffer-20180318/bin/mbuffer -V and found version 20180318
ran /nix/store/sjlbs2k9114xlxalqcz2n0jj90lvik07-mbuffer-20180318/bin/mbuffer --version and found version 20180318
found 20180318 with grep in /nix/store/sjlbs2k9114xlxalqcz2n0jj90lvik07-mbuffer-20180318
directory tree listing: https://gist.github.com/5b88f842903984d6134c96d89c2169de

cc @tokudan for review

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

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

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

Success on aarch64-linux (full log)
Attempted: mbuffer
Partial log (click to expand)
/nix/store/c8bwnx988ckbw2igggv41s1mbd0v743m-coreutils-8.29/bin/install -c -m 644 mbuffer.1 /nix/store/bw00cvvj36sl0smrkgrb59a47s9j2dzr-mbuffer-20180318/share/man/man1/
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/bw00cvvj36sl0smrkgrb59a47s9j2dzr-mbuffer-20180318
shrinking /nix/store/bw00cvvj36sl0smrkgrb59a47s9j2dzr-mbuffer-20180318/bin/mbuffer
gzipping man pages under /nix/store/bw00cvvj36sl0smrkgrb59a47s9j2dzr-mbuffer-20180318/share/man/
strip is /nix/store/3zq400fri5dv7d30lpxlqm2v9y1iis6j-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/bw00cvvj36sl0smrkgrb59a47s9j2dzr-mbuffer-20180318/bin
patching script interpreter paths in /nix/store/bw00cvvj36sl0smrkgrb59a47s9j2dzr-mbuffer-20180318
checking for references to /build in /nix/store/bw00cvvj36sl0smrkgrb59a47s9j2dzr-mbuffer-20180318...
/nix/store/bw00cvvj36sl0smrkgrb59a47s9j2dzr-mbuffer-20180318

Success on x86_64-linux (full log)
Attempted: mbuffer
Partial log (click to expand)
/nix/store/qrxs7sabhqcr3j9ai0j0cp58zfnny0jz-coreutils-8.29/bin/install -c -m 644 mbuffer.1 /nix/store/sjlbs2k9114xlxalqcz2n0jj90lvik07-mbuffer-20180318/share/man/man1/
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/sjlbs2k9114xlxalqcz2n0jj90lvik07-mbuffer-20180318
shrinking /nix/store/sjlbs2k9114xlxalqcz2n0jj90lvik07-mbuffer-20180318/bin/mbuffer
gzipping man pages under /nix/store/sjlbs2k9114xlxalqcz2n0jj90lvik07-mbuffer-20180318/share/man/
strip is /nix/store/fzcs0fn6bb04m82frhlb78nc03ny3w55-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/sjlbs2k9114xlxalqcz2n0jj90lvik07-mbuffer-20180318/bin
patching script interpreter paths in /nix/store/sjlbs2k9114xlxalqcz2n0jj90lvik07-mbuffer-20180318
checking for references to /build in /nix/store/sjlbs2k9114xlxalqcz2n0jj90lvik07-mbuffer-20180318...
/nix/store/sjlbs2k9114xlxalqcz2n0jj90lvik07-mbuffer-20180318

@ryantm looks good to me! :)


Tokens upgrade

This MR will update the tokens from the design system package.
Changes made:

All references to non existing tokens are fixed with a new reference.
Added fonts
Fix for the crackle bundler which removes client directives from components

Not sure how precise we are trying to be in this PR, but here are some inconsistencies I noticed:
Combobox arrow doesn't chance colors in dark/light mode like the Select component  NumberField color do switch, but I think the tag colors and the arrow button colors may be flipped?  TextField and TextAreaField tag colors look like they may be flipped as well  Tag close buttons are not visible in dark mode  Table background colors are not very visible in dark mode
I'm also not seeing the glass effect. Are we no longer using transparent backgrounds? @isaozler

Considering the tag and combo box, I agree. The glass effect is part of a larger refactoring that is currently breaking. I am working to resolve all the issues.

@KristinaSpasevska, great comments. I'll will fix the tooltip's background color.
For the icons, we have a story in our sprint to replace the old icon package with the new one. We will start in the tools app and then do the other apps/libs after. @sanderlooijenga This will also fix your comment send via Slack.


[release-1.9] fix discoveryAddress in configmap template

Manual cherrypick required.
#30483 failed to apply on top of branch "release-1.9":
Applying: fix discoveryAddress in configmap template
Applying: deploy remotes with istiod by default in integration tests
Using index info to reconstruct a base tree...
M	pkg/test/framework/components/istio/config.go
M	pkg/test/framework/components/istio/flags.go
M	pkg/test/framework/components/istio/operator.go
M	tests/integration/iop-integration-test-defaults.yaml
Falling back to patching base and 3-way merge...
Auto-merging tests/integration/iop-integration-test-defaults.yaml
Auto-merging pkg/test/framework/components/istio/operator.go
Auto-merging pkg/test/framework/components/istio/flags.go
CONFLICT (content): Merge conflict in pkg/test/framework/components/istio/flags.go
Auto-merging pkg/test/framework/components/istio/config.go
CONFLICT (content): Merge conflict in pkg/test/framework/components/istio/config.go
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0002 deploy remotes with istiod by default in integration tests
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Closed by https://github.com/istio/istio/pull/30524


Add styled components - Let's talk

Add styled components - PoC
Update
Let's talk about what is "wrong" / "right" about our current implementation for styling, and what styled-components will bring to the table. If we're not going to see any real benefit I think we should hold this off.

and what styled-components will bring to the table

Honestly, I do not understand how this will help? Can you explain the pros and cons?

@lex111 well this is what this issue is for. We talked about this briefly on Gitter so I wanted to move this here so everybody can share its opinion.

Disclaimer: I've barely used styled-components, and most of what I know is from the documentation.
Current Styling
Pros
1. Concise
All of our styles are already in their respective component file meaning we don't have any extra styling-only files.
2. Explicitly showing styles
The current implementation is easy to follow because we provide every component that needs a style with a style property.
Cons
1. Too concise
Everything is in one file. This can be good (see Pro 1), but can also lead to readability issues. Cutting out the styles into new files might be beneficial.
2. Using StyleSheet.flatten()
We're using StyleSheet.flatten() in several places, which isn't always super nice. It would be good to try to avoid using this, as it can lead to confusing styles, especially when they begin to override each other.
Styled Components
Pros
1. Easy linting
This looks like one of the biggest pros. Keep our styling in a consistent format with their super nice linting tool.
2. Writing actual CSS
CSS in objects can get a little weird, especially when it comes to using dashes. With styled-components, we're writing actual CSS instead of weird object CSS.
3. Syntax highlighting
While not a huge pro, this is still really nice for people who do a lot of CSS work.
4. Enforces consistent styling
If we have a style for a specific type of component, styled-components makes it very easy (and preferred) to reuse that style in as many places as possible. This way, the styling throughout the app can stay very similar without rewriting a bunch of CSS.
Cons
1. Have to rewrite all CSS
While this can be done in increments, it's still a lot of work.
2. Probably won't solve everything
I'm guessing there's still places where we'll need to fallback to regular CSS.

This video is a little long (it is actually a workshop) but the talk is given by https://github.com/mxstbr the co-creator of styled-components. Really useful in comparing the different types of styling solutions in react (not focused on react-native but IMO still applies here). The questions at the end are also very good in bring some reasons why CSS styling is good, but how styled-components either has the same features or does it better.
https://www.youtube.com/watch?v=ftSzsghg2io
This video convinced my team to start using styled-components in our application and it has made our development and testing much more declarative (IMO)

I don't know if we should be using styled-components or not (I didn't try them yet to see real-life benefits), but I know something for sure: we need to rethink how our global design is laid out.
Currently, every component/screen define its own styles, and it can sometimes leads to inconsistencies (different margins/paddings/sizes). Button were re-designed from scratch everywhere they were used before rolling up our own <Button /> component and using it everywhere.
Also, with our current implementation, introducing themes (#59) is not doable in a maintainable way.

Thanks for your feedback guys!
I think styled-components will be a good upgrade to our current stack if we think about the future, what @machour mentioned about #59 will be quite complicated to achieve using what we have right now.
Also, I think that by using styled-components we will make our codebase a little more easy to understand to newcomers or people with only css knowledge.
Since migrating everything to styled-components in 1 single PR will be huge, we can start migrating slowly and create good for beginners issues so we attract new people to the repo.
Thoughts?

@alejandronanez Sounds good! I totally agree with a slow approach on this, not one huge PR.

@alejandronanez sounds good to me too.
I'm just wondering if we will be separating styles from components (i.e have a styles/ directory with all styles and requiring the needed ones from components)

So I've always for some reason thought that because React Native already uses JS for locally scoped component styles as opposed to React for the web, styled-components wouldn't really be beneficial.
Reading this article and the video you linked @ericadamski - I think I'm sold 👍
@alejandronanez the plan you laid out sounds perfect. Incrementally moving forward updating all of our styles slowly will be nice. Moreover, definitely don't mind including a mention in CONTRIBUTING.md to note future styles should leverage styled-components wherever possible if everybody thinks thats a good idea

@machour that's a good point. I'm in favour with keeping it within the same file personally to keep the small-components and locally-styled mentality.

@housseindjirdeh another solution we employ is to keep small locally-styled components in a file called .styled.js to show the relation to the main component but keep the bulk of boilerplate and non-logic code outside the main jsx file. Just a potential solution 😄

@ericadamsk Thank you, I literally just finished having a chat with someone in work about how to structure things.
I'm sorry, I spoke too soon there without being more clear. Keeping things within the same file seems easier for now because that's how I've sort of built each of the components/screen. I agree you're on to something better @ericadamski. Ideally I think having a folder structure for every component might be something we need to move towards. For example:
- Button/
  - button.component.js
  - button.styled.js

And our container components (our "screens")
- Notifications
  - notifications.component.js
  - notifications.styled.js
  - notifications.container.js
  - notifications.action.js
  - notifications.reducer.js
  - notifications.type.js

Thinking in this pattern we can use recompose in our container files to make things more streamlined. Now I know I'm going way overboard but with that being said, a good starting point would be at least making our components folder driven and keeping our styled files separate :O
Let me know what everyone thinks 🙌

Hey @gitpoint/maintainers I'm glad you like the idea of using styled-components let me add a PR with the dependency and create an initial PR for a random component, then we can start creating more issues for beginners.
About the implementation details, it looks a little weird to me to have the style separated from the main component file (since we're not reusing those styles I think we don't need to move them to another file).

@alejandronanez I think it is a tradeoff. If styles are not reusable not very long, then we can keep it in the same file. Otherwise, we need separate it out.

There you go. First styled components PR https://github.com/gitpoint/git-point/pull/495

@housseindjirdeh I think that is a great idea! Scoping components and their associated parts (styled, actions, reducers, selectors) helps (IMO) large projects scale.
@alejandronanez awesome PR! 🦄

Nice thank you folks <3
Okay, let's keep things in the same file for the meantime as that's how things currently are. Opened a separate issue to really start exploring a modular folder structure #506 🕺

Quick question about styled components. From what I've seen, you declare Components with its own, encapsulated style. This seems fantastic, but how would we deal with styles and themes across the app?
For example, if we want all titles and headers to have the same font and color and nothing else, we could have an easy CSS rule for, say, className="titleStyle". And add it to those titles and headers. How could we do something similar with styled components? Would we declare headers somewhere else and import them where we need them?
Same question would go for CSS variables and the such, how do we address those?

@SammyIsra the idea behind component architecture and therefore styled components is that creating many small isolated chunks of a system (in the case of styled a frontend UI) and reusing the small isolated chunks allows consistency and simplicity when building large applications.
Your suggestion for a CSS rule like className="titleStyle" is actually a component style architecture on its own, its small, manageable isolated chunk of logic that can be easily reused. Styled components outlook/solution to this problem just allows that same pattern you are suggesting but in a declarative, more HTML familiar manor.
For example, consider a page header that contains a title, a sub-title and some container elements to allow some funky styling. Using class names as your component driver you will have something that looks like this: (NOTE: this is not react native but react, the same ideas apply to both)
const Header = () => {
    return (

Title

                         Sub Title

    )
}

If you contrast above with a styled components approach and notice the more declarative nature of the render method:
import { Container, Inner, Title, SubTitle } from 'styled.js';

const Header = () => {
     return (
          <Container>
               <Inner>
                    <Title>Title</Title>
                    <SubTitle>SubTitle</SubTitle>
               </Inner>
          </Container>
     )
}

Take <Title/> for example: we have just encapsulated the styles into a more human readable component that no one how uses it should actually care about the className or the styles that make it work, just as if you were to apply that className titleStyle
Beyond that, say you have to change the colour of the title if it is used as a primary title or a secondary title, this would involve 2 extra classes that override the parent style and now we have to consider collisions and silly CSS precedence. With styled components you can just pass props and use JS logic to apply it directly in the component, for example:
const Title = styled.h1`
     display: block;
     font-size: 2rem;

     color: ${props => {
          if (props.primary) return 'red';
          if (props.secondary) return 'blue';

           return 'white'; // default
     }};
`; // the simple styled component

// in use
<Title primary>Primary Title</Title>
<Title secondary> Secondary Title</Title>

Since this is all jS managing CSS variables becomes just managing JS variables like having a colours object that has the specified global colours:
const colors = {
    black: '#000',
};

// and we can use it in a styled component like
const Title = styled.h1`
    color: ${colors.black};
`;

The power of styled components matches if not exceeds that of plain CSS or even SASS/LESS and allows a more declarative style of writing react.

Since we all decided that this is the way to go, I'm going to lock down this issue. If you think it's still worth discussing anything else, feel free to unlock it.


sc-slots: Cleanup

Calculate remaining proposal duration once and also use proposal time as timeout for creating the inherent data.

Calculate remaining proposal duration once and also use proposal time as timeout for creating the inherent data.

Nit: slight mismatch between description and the code. Remaining proposal duration is calculated twice, did you intend to pass it to create_inherent data?

Calculate remaining proposal duration once and also use proposal time as timeout for creating the inherent data.

Nit: slight mismatch between description and the code. Remaining proposal duration is calculated twice, did you intend to pass it to create_inherent data?

No the code is as intended ;) I more meant calling the remaining_proposal_duration function :D


[#339] TckRecoveryTests Arquillian URL injection adjustment

fixes #339
Adjusting the URL injection by Arquillian to be done after the deployment happens. This fixes a trouble for some adapters to inject URL as null.

@xstefank @mmusgrov some possibility to merge this?


Array.indexedMap's index is 1023 maximum

Here is the issue:
import Array
import Array (Array)
import Text (asText)

testArray: Array number
testArray = Array.initialize 3000 identity

mapArray: Array a -> Array a
mapArray array =
    Array.indexedMap (\i el ->
        -- here max i == 1023
        case (Array.get i array) of
            Just x -> x
            otherwise -> el
    ) array

main =
    testArray |>
    mapArray |>
    asText

mapArray should just return array itself with values 0..2999, but it returns 0..1023, 0..1023, 0..951.
I've found that index in function passed to indexedMap reaches 1023 maximum.
I suggest the problem is in Array.js indexedMap_ function:
    function indexedMap_(f, a, from) {
      var newA = { ctor:"_Array", height:a.height, table:new Array(a.table) };
      if (a.height > 0) { newA.lengths = a.lengths; }
      for (var i = 0; i < a.table.length; i++) {
        newA.table[i] = a.height == 0 ? A2(f, from + i, a.table[i])
                                      : indexedMap_( f, a.table[i]
                                                   , i == 0 ? 0 : a.lengths[i - 1]); // should be i == 0 ? from : from + a.lengths[i-1]);?
      }
      return newA;
    }

Do you mind retargeting this issue to this repo? It seems like the Array library is in need of a careful review because there are a couple problems floating around like this.

Also, sorry for the slow response, and huge thank you for reporting this error with an example that makes things easy to reproduce!

Okay, moved it over to https://github.com/elm-lang/core/issues/271
Thanks again!


TS-4976: Regularize plugins - ssl_sni_whitelist.

Standard changes, removed TS_USE_TLS_SNI conditional.

Linking #2431


Async computation hanging in lastest F# 4.1 builds

While going through the discussion in #3219 I noticed that a particular computation seems to be hanging when run in F# Interactive 4.1
cc @matthid
Repro steps
In F# Interactive 4.1
open System
open System.Threading
open System.Threading.Tasks

let test() =
    let tcs = new TaskCompletionSource<int>()
    let cts = new CancellationTokenSource()
    let _ = cts.Token.Register(fun () -> tcs.SetResult 42)
    async {
        cts.CancelAfter 500
        let! result = tcs.Task |> Async.AwaitTask
        return result
    } |> fun a -> Async.RunSynchronously(a, cancellationToken = cts.Token)

function test does execute as expected.
Expected behavior
Should fail with OperationCanceledException
Actual behavior
Hangs indefinitely
Related information
This only occurs in F# interactive 4.1 (32bit and 64bit builds) in both windows and mono/linux. It does not happen in console applications running FSharp.Core <IP_ADDRESS>. I can't reproduce the issue in F# Interactive 4.0.

@eiriktsarpalis If you want I can take care of this as well, as I'm already looking at the code and writing some tests. Even if we don't want to accept my PR as a whole we can probably cherry-pick this fix afterwards (or I can send a separate PR after the discussion)...

Hm I can't actually reproduce this. I have Microsoft (R) F# Interactive version 4.1 with
> typeof<option<_>>.Assembly.FullName;;
val it : string =
  "FSharp.Core, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"

> test();;
System.OperationCanceledException: The operation was canceled.
   at Microsoft.FSharp.Control.AsyncBuilderImpl.commit[a](AsyncImplResult`1 res)
   at Microsoft.FSharp.Control.CancellationTokenOps.RunSynchronouslyInAnotherThread[a](CancellationToken token, FSharpAsync`1 computation, FSharpOption`1 timeout)
   at Microsoft.FSharp.Control.CancellationTokenOps.RunSynchronously[a](CancellationToken token, FSharpAsync`1 computation, FSharpOption`1 timeout)
   at Microsoft.FSharp.Control.FSharpAsync.RunSynchronously[T](FSharpAsync`1 computation, FSharpOption`1 timeout, FSharpOption`1 cancellationToken)
   at <StartupCode$FSI_0040>.$FSI_0040.main@()
Stopped due to error

Should fsi use another FSharp.Core version?

@matthid as a general rule in this project: please split things up in very very small parts. That increases the chances to get something in in time. Bug pull requests often rot for very long time since people are afraid to merge.

@forki Yeah I know, it's just for discussion and POC once we decide what is acceptable and what not I can split it up. Because this might mean doing things differently...

@matthid, @eiriktsarpalis I can reproduce this with the latest master starting fsi any cpu in debug mode.

@eiriktsarpalis I can now reproduce in a unit test :)

Weird, but it looks like I cannot reproduce when I launch fsi from the command line, only from Visual Studio. I can't reproduce in ionide on windows, but I it happens consistently in ionide on mono. Strange...

@eiriktsarpalis We need a version dif because it looks like this bug was introduced after the last update for the fsi on windows.

@realvictorprm Does VF# run a different build of fsi 4.1 than the one installed in the dev tools? Running
System.Reflection.Assembly.GetEntryAssembly().Location

seems to indicate that VF# launches some temp copy
C:\Users\eirik\AppData\Local\assembly\dl3\OW481XT9.V2P\5H7WMBY5.CXB\89e45b56\fa90b7d2_1becd201\fsiAnyCpu.exe (SHA abf85160c0cfbe880497a9990ee0748e3c14f64a)

whereas cli and ionide give the expected path
C:\Program Files (x86)\Microsoft SDKs\F#\4.1\Framework\v4.0\FsiAnyCpu.exe (SHA cbb55cae8752ea1525ec4aa0165e5ee51850f6c9)

@realvictorprm My linux box uses the latest fsharp OSS built from source, which seems consistent with a recent bug causing this.

@eiriktsarpalis With the Visual F# solution you will always use the latest version.
However if you're installing the Visual F# tools you're going to use the installed sdk stuff (so far I know).

Darn I don't know who I should ping :smile:
@eiriktsarpalis can you give the output of fsi after startup (there should be the version included).

@realvictorprm confirming that this reproduces with the latest master in F# OSS (commit 4f50d4f22e090a59889412f96fdefa0cc209a1c9). There's no version number as such printed in fsi other than the obvious (4.1)

@eiriktsarpalis I realized so too 😢 Currently trying to figure out the version of fsi on my pc. I do know that the last change to the file has been made on 10th May 😄

@eiriktsarpalis Problem is probably here: https://github.com/Microsoft/visualfsharp/blob/master/src/fsharp/FSharp.Core/control.fs#L1560
What the cancellationToken does at this place is cancel the Task which is RETURNED by ContinueWith which means the continuation is never called. I'd remove this parameter.
Bug was introduced here: https://github.com/Microsoft/visualfsharp/commit/7dfa68941ce9f6ccfe99575012943eaf95d46c0f

Btw it's a bit strange to call different overloads of ContinueWith depending on compiler directives. The helper function continueWithExtra even has different signatures as far as I can see...

Fixed - a huge thank you to both of you @matthid  and @eiriktsarpalis


AttributeError: module 'openai' has no attribute 'error' in ChatMOF

Dear Yeonghun:
I am encountering an error when running the ChatMOF tool. The error occurs due to the openai module trying to access a non-existent openai.error.Timeout attribute. Below are the steps to reproduce and the full stack trace.
Steps to Reproduce:

Run the chatmof -T run command.
Enter the question: What are the MOFs with 20A or more LCDs and 15A or less PLDs?.

Expected Behavior:
The tool should execute and provide the necessary information about MOFs with specified LCD and PLD values.
Actual Behavior:
An AttributeError is raised, indicating that the openai module has no attribute error.
Stack Trace:
(chatmof_arm) zhangyichen@zhangyichendeMacBook-Pro ~ % chatmof -T run
>>> Console logs (under WARNING level) are disabled.
WARNING:root:File logs (under WARNING level) are disabled.
Warning: The internet tool does not work - 1 validation error for GoogleSearchAPIWrapper
__root__
  Did not find google_api_key, please add an environment variable `GOOGLE_API_KEY` which contains it, or pass  `google_api_key` as a named parameter. (type=value_error)
##################################################

Welcom to ChatMOF!

########## Question ##############################
Please enter the question below >>
What are the MOFs with 20A or more LCDs and 15A or less PLDs?

> Entering new ChatMOF chain...

> Entering new AgentExecutor chain...
Traceback (most recent call last):
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/bin/chatmof", line 8, in <module>
    sys.exit(main())
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/lib/python3.9/site-packages/chatmof/cli/main.py", line 72, in main
    f(args)
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/lib/python3.9/site-packages/chatmof/cli/run.py", line 76, in run
    main(model=model, temperature=temperature, **kwargs)
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/lib/python3.9/site-packages/chatmof/main.py", line 62, in main
    output = chatmof.run(question, callbacks=callback_manager)
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/lib/python3.9/site-packages/langchain/chains/base.py", line 440, in run
    return self(args[0], callbacks=callbacks, tags=tags, metadata=metadata)[
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/lib/python3.9/site-packages/langchain/chains/base.py", line 243, in __call__
    raise e
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/lib/python3.9/site-packages/langchain/chains/base.py", line 239, in __call__
    else self._call(inputs)
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/lib/python3.9/site-packages/chatmof/agents/agent.py", line 32, in _call
    output = self.agent.run(query)
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/lib/python3.9/site-packages/langchain/chains/base.py", line 440, in run
    return self(args[0], callbacks=callbacks, tags=tags, metadata=metadata)[
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/lib/python3.9/site-packages/langchain/chains/base.py", line 243, in __call__
    raise e
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/lib/python3.9/site-packages/langchain/chains/base.py", line 237, in __call__
    self._call(inputs, run_manager=run_manager)
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/lib/python3.9/site-packages/langchain/agents/agent.py", line 994, in _call
    next_step_output = self._take_next_step(
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/lib/python3.9/site-packages/langchain/agents/agent.py", line 797, in _take_next_step
    output = self.agent.plan(
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/lib/python3.9/site-packages/langchain/agents/agent.py", line 443, in plan
    full_output = self.llm_chain.predict(callbacks=callbacks, **full_inputs)
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/lib/python3.9/site-packages/langchain/chains/llm.py", line 252, in predict
    return self(kwargs, callbacks=callbacks)[self.output_key]
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/lib/python3.9/site-packages/langchain/chains/base.py", line 243, in __call__
    raise e
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/lib/python3.9/site-packages/langchain/chains/base.py", line 237, in __call__
    self._call(inputs, run_manager=run_manager)
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/lib/python3.9/site-packages/langchain/chains/llm.py", line 92, in _call
    response = self.generate([inputs], run_manager=run_manager)
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/lib/python3.9/site-packages/langchain/chains/llm.py", line 102, in generate
    return self.llm.generate_prompt(
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/lib/python3.9/site-packages/langchain/chat_models/base.py", line 230, in generate_prompt
    return self.generate(prompt_messages, stop=stop, callbacks=callbacks, **kwargs)
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/lib/python3.9/site-packages/langchain/chat_models/base.py", line 125, in generate
    raise e
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/lib/python3.9/site-packages/langchain/chat_models/base.py", line 115, in generate
    self._generate_with_cache(
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/lib/python3.9/site-packages/langchain/chat_models/base.py", line 262, in _generate_with_cache
    return self._generate(
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/lib/python3.9/site-packages/langchain/chat_models/openai.py", line 371, in _generate
    response = self.completion_with_retry(messages=message_dicts, **params)
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/lib/python3.9/site-packages/langchain/chat_models/openai.py", line 313, in completion_with_retry
    retry_decorator = self._create_retry_decorator()
  File "/Users/zhangyichen/miniforge3/envs/chatmof_arm/lib/python3.9/site-packages/langchain/chat_models/openai.py", line 302, in _create_retry_decorator
    retry_if_exception_type(openai.error.Timeout)
AttributeError: module 'openai' has no attribute 'error'

Environment:

Python 3.9

Thank you for looking into this issue.

Hi @zyc2806,
Thank you for your interest in my research. I checked the error you sent me and found that there is a problem with the dependency of openai. I have added the dependency and released chatmof version 0.2.1. I would appreciate it if you could test it after a  reinstallation.

Additionally, when I tested the question you mensioned, I found that it throws a TOKEN LIMIT ERROR. This happens when more posts are written than the data provided by OPENAI, because there is a lot of data that falls under that conditional statement. If you modify the question to be specific and include the appropriate amount of data, you should be able to use it without error.


feat: Add mlflow-ai-gw-image module and update mlflow to 2.17.0

Describe your changes
Add mlflow-ai-gw-image module that builds mlflow Docker image and pushes to ECR.
The image hosts a MLFlow AI Gateway server.
Next steps:
We need to decide how we want to use the Docker image. We could put it in a Lambda+API Gateway to really have an AI API Gateway. Or we could link it to the rest of the modules of mlflow and deploy it as an ECS task
Checklist before requesting a review

[x] I updated CHANGELOG.MD with a description of my changes
[x] If the change was to a module, I ran the code validation script (scripts/validate.sh)
[ ] If the change was to a module, I have added thorough tests ---> just CodeBuild, no actual cdk app
[x] If the change was to a module, I have added/updated the module's README.md
[x] If a module was added, I added a reference to the module to the repository's README.md
[X] I verified that my code deploys successfully using seedfarmer apply

-[X] I pulled the image from ECR and then built the server locally
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

AWS CodeBuild CI Report

CodeBuild project: AIOpsModuleTestsInfrastruct-doMLXEYsnmxr
Commit ID: c87c905796209c5a1552458b4170b4832ccdd5d7
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: AIOpsModuleTestsInfrastruct-doMLXEYsnmxr
Commit ID: f6181b2db28123d9ef26701d1c2242fb53a63335
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: AIOpsModuleTestsInfrastruct-doMLXEYsnmxr
Commit ID: eddfd92e9a47a81bf08944b9c88066b476265c37
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: AIOpsModuleTestsInfrastruct-doMLXEYsnmxr
Commit ID: a2901df2e4a458cec5b1f680e089d1ca1803bb70
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository


WinformsResultProvider not picking all the IUpdaters

WinformsResultProvider for Analzye command is only picking one the WinformsUpdater and not all of them.

@brandonh-msft can you share the piece of code related to this?
The analyze command for uwp extension is not working as expected as of now. I do not think it is because of this issue though.

The area of code where it needs to pick all the source updaters for analyze async only one of them is picked
https://github.com/dotnet/upgrade-assistant/blob/main/src/extensions/windows/Microsoft.DotNet.UpgradeAssistant.Extensions.Windows/WinformsResultProvider.cs#L62

Thanks @sunandabalu - I'm not seeing where in that code we get a collection of things, though... We do loop through the results that come back from the upgrader here, though
https://github.com/dotnet/upgrade-assistant/blob/7759eb9451dd85d20ac83e8001e549ce74ede68d/src/extensions/windows/Microsoft.DotNet.UpgradeAssistant.Extensions.Windows/WinformsResultProvider.cs#L74
I'll touch base w/ you offline :)


Added a start screen to the game, made it look cool, and made PixeloidMono the default font for everything in CSS.

the "play" button area is a little big, otherwise amazing and extremely true to the mock-up


Update slf4j-api to 1.7.35 in series/0.22

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

Files still referring to the old version number
The following files still refer to the old version number (1.7.33).
You might want to review and update them manually.
website/src/hugo/content/changelog.md

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.slf4j", artifactId = "slf4j-api" } ]

labels: library-update, early-semver-patch, semver-spec-patch, old-version-remains, commit-count:1

Depending on this at all is a vestige from when we aspired to explicit dependencies, not declared dependencies.  If we stop bumping it, we could get it out of the build in later branches.

If we stop bumping it, we could get it out of the build in later branches.

Why is that?

We're already newer than what the transitive dependencies give us, so removing it now would be a downgrade.  If a transitive dependency catches up (I can make this happen with log4s), then we can drop it.
Alternatively, we could say explicit dependencies are good.  But trying to enforce them made me unpopular.

Yay or nay on keeping this explicit.  I want to do a release today, and this one is a layup if we keep it.


Users can't say "No Thanks" to notifications

After a user completes a set of calls for the first time, we ask them if they want to get notifications about new issues. The choices are:

All Issues
Important Issues
No thanks

Only 1 and 2 launch the notification prompt, and saying "No thanks" doesn't set any value that we can check in the future so we ask every single time when the user doesn't want notifications.
Lets be less annoying and only ask once every month if a user says "No thanks".

I'll take this one.

Closed with #252


chore: apply cs-fixer changes to v3 branch

$ composer cs-fixer
> php-cs-fixer fix
PHP CS Fixer 3.54.0 15 Keys Accelerate by Fabien Potencier, Dariusz Ruminski and contributors.
PHP runtime: 7.4.3-4ubuntu2.20
Loaded config default from "/home/phil/git/sabre-io/xml/.php-cs-fixer.dist.php".
 40/40 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%

   1) tests/Sabre/Xml/Element/XmlFragmentTest.php
   2) tests/Sabre/Xml/ServiceTest.php
   3) lib/Deserializer/functions.php
   4) lib/Reader.php
   5) lib/LibXMLException.php
   6) lib/Service.php

Fixed 6 of 40 files in 2.147 seconds, 20.000 MB memory used

I really like the explicit nullability. thank you

you can thank cs-fixer - it applies it automagically now.


How do you interpret key values?

I'd like to read the arrow keys, but it seems that they come in as a strange combination of 3 bytes, meaning I have to call take!(t.stdin_channel) 3 times and put the values together. What kind of data can I generally expect to come out of stdin in "raw mode"?

Thanks for the quick response!


Add with-svelte-injected-style example

Ooh noice! I wonder if we should separate this into its own example, or couple it into the with-svelte :-?

Hey! I made this draft to show a working example for the changes introduced on https://github.com/PlasmoHQ/plasmo/pull/955 to @avi12.
I guess we could add it to with-svelte if you consider this to be the default behavior!

IMO it should be in with-svelte
Using Svelte's CSS injection renders Plasmo's getStyle useless

Awesome, then i'll add the changes to the with-svelte example and update the PR.

Hey there! Just updated the PR with what we discussed. Let me know if you want to add/remove anything else.

To be honest, it's a good practice to be able to use getStyle if you wish to apply CSS globally
For example, in my extension I'm using it to switch between CSS variables related to dark and light modes, and the advantage is that I only need to edit in one file to affect every other component

I agree, that's why I left the getStyles call for plasmo container styling. I just moved the component styles into the component


[WIP] Add support for poly_radial_5 and poly_radial_7

UndistortPolyRadialX should be for the backward transformation (distortPolyRadialX would be for the forward transformation)

This depends on https://github.com/LI3DS/pointcloud/pull/76, which should be merged first.

Closing this for. We'll add them when we need them.


delete source dir

can i add option "--delete-empty-src-dirs" i cant find in the setting

It seems like a feature that can add some options to copy/move/delete operation.


Add extra cbloader features: order, icons and tips!

Add extra features to avalon.tools.cbloader:

Loaders can now be sorted by an .order attribute on the Loader plug-in. This will influence how they are listed under the right-mouse context menu in the loader.
Loaders can now have custom icons using a .icon string attribute, these should be font-awesome icon names.
Additionally the icons can be colored using a .icon_color attribute. A string specifying a Qt color, this can also be hex formatted.
The Loader's docstring is now also added the action's tool- and status-tip.

Functionality
class CustomLoader(api.Loader):
    """This docstring is the tooltip AND statustip!"""

    families = ["colorbleed.model"]
    representations = ["ma"]
    label = "Custom label"      # label shown on the action
    order = -10                 # sorting order of the actions menu for loaders
    icon = "code-fork"          # font-awesome icon name
    icon_color = "orange"       # qt color name or hex formatted string

Example
Here's an example image with corresponding loaders in the code below.

class ModelLoader(LogDebugLoader):
    """Load a model"""
    families = ["colorbleed.model"]
    representations = ["ma"]
    label = "Reference model"
    order = -10
    icon = "code-fork"
    icon_color = "orange"

class GpuCacheLoader(LogDebugLoader):
    """Import a GPU cache"""
    families = ["colorbleed.model", "colorbleed.animation"]
    representations = ["abc"]
    label = "Import GPU cache"
    order = -1
    icon = "download"
    icon_color = "white"

How about just 'color' for the icon color?

How about just 'color' for the icon color?

Could work, but might be confusing as it could refer to the font/label color?

I'm thinking it may be more than just the color of the icon; it'd be the color associated to this Loader. Could be used for more than its icon.

I'm thinking it may be more than just the color of the icon; it'd be the color associated to this Loader. Could be used for more than its icon.

In that case, interesting! Not sure where this could be visually represented, but I'm liking this idea. :)

Cool. :) And I wouldn't worry about confusing it for the text-color. It'd be part of it's identity, rather than a direct connection to anything we've coded. Like it's label. The user chooses an appropriate label, we decide where a label is appropriate to use.

Refactored icon_color to color. Example code:
class ModelLoader(LogDebugLoader):
    """Load a model"""
    families = ["colorbleed.model"]
    representations = ["ma"]
    label = "Reference model"
    order = -10
    icon = "code-fork"
    color = "orange"

class GpuCacheLoader(LogDebugLoader):
    """Import a GPU cache"""
    families = ["colorbleed.model", "colorbleed.animation"]
    representations = ["abc"]
    label = "Import GPU cache"
    order = -1
    icon = "download"
    color = "white"

Orange is the new black!

Mergie mergie?


When side-by-side builds of Visual Studio are installed, build is picking the wrong one

Unsure if this a build.exe issue or a Razzle issue. Based on experiments, Razzle appears to be okay.
Environment
Visual Studio 16.2.0 Preview 4.0 [29018.107.d16.2stg] (installed to C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview)
Visual Studio 16.1 (installed to C:\Program Files (x86)\Microsoft Visual Studio\2019\RTM)
Steps to reproduce

From a Developer Command Prompt For VS 2019 Preview, run:

> .\tools\razzle.cmd
> bcz

Expected behavior
Build to succeed.
Actual behavior
Build fails with:
Starting build...
MSBuild auto-detection: using msbuild version '<IP_ADDRESS>001' from 'C:\Program Files (x86)\Microsoft Visual Studio\2019\16.2\MSBuild\Current\bin'.
All packages listed in packages.config are already installed.
Skipping building appx...
"C:\Program Files (x86)\Microsoft Visual Studio\2019\16.1\MSBuild\Current\Bin\MSBuild.exe" E:\terminal\OpenConsole.sln /t:Clean,Build /m /p:Configuration=Debug /p:Platform=x64 /p:AppxBundle=false
Microsoft (R) Build Engine version 16.1.76+g14b0a930a7 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

Build started 6/19/2019 10:58:30 AM.
     1>Project "E:\terminal\OpenConsole.sln" on node 1 (Clean;Build target(s)).
     1>ValidateSolutionConfiguration:
         Building solution configuration "Debug|x64".
     1>Project "E:\terminal\OpenConsole.sln" (1) is building "E:\terminal\src\cascadia\TerminalApp\TerminalApp.vcxproj.
       metaproj" (2) on node 1 (Clean target(s)).
     2>Project "E:\terminal\src\cascadia\TerminalApp\TerminalApp.vcxproj.metaproj" (2) is building "E:\terminal\src\cas
       cadia\TerminalSettings\TerminalSettings.vcxproj" (6) on node 2 (Clean target(s)).
     6>E:\terminal\src\cppwinrt.build.pre.props(45,3): error MSB4019: The imported project "C:\Program Files (x86)\Micr
       osoft Visual Studio\2019\16.1\MSBuild\Microsoft\VC\v160\Microsoft.Cpp.Default.props" was not found. Confirm that
       the path in the <Import> declaration is correct, and that the file exists on disk. [E:\terminal\src\cascadia\Ter
       minalSettings\TerminalSettings.vcxproj]

The build is failing because its using/looking in the wrong location for these targets files.
The first line says that its picked up the correct MSBuild ("16.2"):
MSBuild auto-detection: using msbuild version '<IP_ADDRESS>001' from 'C:\Program Files (x86)\Microsoft Visual Studio\2019\16.2\MSBuild\Current\bin'.

But a few lines down, you can see that its picking up MSBuild from the 16.1 folder:
"C:\Program Files (x86)\Microsoft Visual Studio\2019\16.1\MSBuild\Current\Bin\MSBuild.exe" E:\terminal\OpenConsole.sln /t:Clean,Build /m /p:Configuration=Debug /p:Platform=x64 /p:AppxBundle=false

Actually, I think that build.exe isn't respecting any of the Developer Command Prompt environment at all if I run from 16.1:
Starting build...
MSBuild auto-detection: using msbuild version '<IP_ADDRESS>001' from 'C:\Program Files (x86)\Microsoft Visual Studio\2019\16.2\MSBuild\Current\bin'.

This should say:
MSBuild auto-detection: using msbuild version '<IP_ADDRESS>001' from 'C:\Program Files (x86)\Microsoft Visual Studio\2019\16.1\MSBuild\Current\bin'.

If you look at bcz.cmd, you'll see there are two steps here that are picking up different msbuild versions. There's a nuget.exe call, to restore dependencies, which is the one that's auto-detecting msbuild <IP_ADDRESS>001. Then, there's a second step that actually builds the solution, which uses the msbuild that was found by vswhere in razzle.cmd.
Presumably, changes could be made to razzle.cmd that could enable it to not lookup msbuild if it can tell it's already running in a developer command prompt.

This is, unfortunately, an issue thatseems to have always existed in NuGet. There isn't terribly much we can do about it without tying our hands unnecessarily. I know nuget supports -msbuildversion, but producing the right value to supply to that argument is challenging.

@DHowett-MSFT Can you help me dig into "there isn't terrible much we can do about it  without tying our hands unnecessarily."? Lots of teams have solved this, so trying to understand that statement.

@davkean I almost certainly spoke before thinking :smile: Sorry about that.
I'm honestly not sure how best to solve this. I feel like we should not be depending too heavily on trying to detect the actual VS version in use and string-splitting that to pop it into -msbuildversion for NuGet's sake... especially since it doesn't support three-part versions (it fails for -msbuildversion 15.9.11 but succeeds for 15.9. I think it fails for 15.0).
I can't find an environment variable present in devcmd that specifies the minor version in use (%VisualStudioVersion% reports 15.0, but i think that fails as above)

You know, maybe our guidance should just be "If you want to build the Terminal from 'Developer Command Prompt', just don't use `tools\razzle" but then I went ahead and just did the msbuild detection because that's easier


Investigate implementing an ECMA 402-based internationalization library

 Issue by alexcrichton
Wednesday May 28, 2014 at 18:11 GMT
For earlier discussion, see https://github.com/rust-lang/rust/issues/14494
This issue was labelled with: A-libs, P-high in the Rust repository

We have been told that internationalization is pretty standardized at this point on the web and many languages are starting to follow along. The authoritative spec for this is located here, and it sounds like we shouldn't deviate from that spec much (as it's what everyone is expecting).
Nominating, but I do not believe this is a 1.0 issue.

I actually attempted to start work on this as part of my learning Rust. I wasn't successful at that time but would like to get back to this idea soonish.

@steveklabnik @alexcrichton any thoughts on why this ECMAScript proposal is the preferred model for an i18n API in Rust instead of, for example, ICU, Java, or C#?
The idea of implementing an ECMAScript API in Rust never occurred to me.

The 2nd edition of ECMA-402 was published in June 2015:
Web
PDF

I'd like to take a stab on this, converting the locale crate (it is basically useless at the moment and that is the most suitable name).
@listochkin, do you have remains of your attempt anywhere for inspiration?
@mrhota, the adding of toLocaleString method (in Rust conventions it will be to_locale_string) to the types that have locale-specific formatting, via trait, seems like the correct Rust way, following the suit of many existing ToSomething traits and to_something methods.
However, there will have to be some differences. I have not read the ECMA-402 standard to as much detail, but:

It seems to pass around locale as just names everywhere. I would prefer passing objects.
The formatting, and parsing, functions need to be actually implemented on such locale object or its subobjects (C++'s std::locale::facet style)

I am also not sure about the NumberFormat and DateTimeFormat objects. I thought just the TR#35 patterns should be enough (they should be able to define everything needed) and it would leave smaller compatibility surface. However, once we add a feature to the pattern, we have to support it anyway and the we can add setters to the pattern object just fine and the fields don't have to be exported, so we can add features without breaking compatibility just fine.
And with an impl ToNumberFormat for str there would be no inconvenience in the common use-case.

@jan-hudec I'll help with this effort. I'm excited someone else has an interest in this!
I gather that the desire here is to have a library inspired by this spec, since a Rust "implementation" would be ... strange and unidiomatic.

Thank you, @mrhota. First thing will be to come up with reasonable design and name things.
My key requirement is, that formatting for new types can be easily defined. So we will have a trait, similar to Display, but only one and taking a formatting specification, because localization substitutes to dynamic strings, so compile-time checking like std::fmt is not possible.
Rust already uses separate types for times, so time formatting will be triggered by using them and I want similar approach to money, i.e. instead of passing a number and format string indicating monetary format you will pass something like 5 * USD  (or 2.5 * EUR or 22 * CZK etc) and that will trigger money formatting, including comparing the currency to the local one and fetching suitable symbol if available (so 5 * GBP will come out as £5.00 is en_GB locale, but as 5.00 GBP in most others.
I also often work with other kinds of dimensional quantities. CLDR contains unit names and abbreviations for various locales, but I haven't seen it integrated in any localization library. And I don't want to integrate it either. I just want to make it easy for application that wants it to extract the necessary bits from CLDR, store it in its translation catalogue or somewhere, and define appropriate formatting for its dimensional quantity type, so it can format 5000 * metre with format ###@@ and get 5.0 km back.

ECMA-402 is a good place to start, then. it's suitably abstract for a
starting point, and I think we can probably arrive at a reasonable
first-pass design for i18n components (i.e. locale objects) by "rustifying"
(oxidizing?) the basic string stuff from the spec.
By the way, someone else "owns" the i18n crate name on crates.io. I was
thinking either get that person involved so we can use the name, or go with
"Intl", like the spec.

Look at the referencing issue (https://github.com/ogham/rust-locale/issues/7). I've put some outline (without much names yet) already.
Regarding i18n, I think locale, as the traditional name, is better for this. The backends will probably get long names, since they will be mostly internal matter and I was thinking about msgfmt or message_format for the formatting layer and either gettext or intl (because the gettext runtime part is called libintl) for the gettext component.

The more I think about this, the less I see ECMA-402 as particularly reasonable inspiration for this. I have done internationalization support in work projects, have a pretty good idea of features it should have and I don't see them in the JavaScript version. The C++ locale seems like much better inspiration.

I saw your post on the user forums about forward compatible locale design. I think github is probably the better place to continue that topic and to combine it with the above discussion. What do you think?

Ah, never mind.
For future visitors to this issue, it looks like we'll just continue discussions over at ogham/rust-locale#7, like @jan-hudec  already started doing. :smile:

Have there be any efforts towards this end, lately?

@alexreg, I am slowly making some progress on https://github.com/rust-locale/rust-locale/tree/next, but there is still a lot work left. Including the main ECMA-402 bit, trait adding to_local_string and similar methods to various types that need it.

@jan-hudec Oh, cool. It looks like you're using the C++ stdlib approach of facets + locales then, eh? Let me know if I can help with development!

(Silly me thought that project was dead just because the master branch was stale, by the way...)

@alexreg, well, it's a mix of the C++, the Java and the JavaScript approach, really. I use the term facet from C++ (which I am most familiar with). But instead of storing them in the locale object as C++ does I have them in a static map keyed on the Locale and construct them on demand with a factory, which is closest to how Java works. The advantage is that is can be more easily extended by overriding some of the factories (which is not yet implemented, but shouldn't be hard) and by creating new types of facets—because I have idea that there will be domain-specific extensions (I can think of units and transliterations as possible ones, but there are probably some more).

(Silly me thought that project was dead just because the master branch was stale, by the way...)

It's not dead, but it's been progressing really slowly. I first started and got stuck half way in the exponential numbers. Then it slept for some time and then got a redesign that introduced the inverted objects and RFC5646 language tags, then then got reduced to more appropriate RFC4647 ones. But then I got stuck on the CLDR data and also still had some glitches in the numbers. So around new year I at least published the helper crate locale_config for obtaining the system configuration and couple of weeks ago I finally managed to finish the numbers.
To make a release, I would like to add date and time and add a facet (Localised) with the ECMA-402-like methods for formatting via appropriate facet, so the functions currently used in https://github.com/ogham/exa can be replaced with appropriate new version.
I would definitely welcome some help; we can discuss what in an issue on the https://github.com/rust-locale/rust-locale/ project.

@jan-hudec Okay, sounds fair. I already created an issue on there, if you can see it... we can also speak on IRC, if you're on there.

Incidentally, I'm not a big fan of this static map/factory design. It sounds like over-engineering. But maybe we could discuss this.

@alexreg

Incidentally, I'm not a big fan of this static map/factory design. It sounds like over-engineering. But maybe we could discuss this.

What I want here is to have a base locale package providing decimal numbers, dates and times, collation, perhaps money and some basic message catalogue, and then add-on packages providing rule-based numbers (i.e. as words, which is often used on bills as tamper-proofing, and non-decimal systems like roman numerals), quantities (with automatic conversion between metres, kilometres, feet, miles, litres, pints, gallons, degrees Celsius and Fahrenheit etc.), transliteration and other features, and add-on packages using alternate sources of the locale data (to reuse something that might be already installed in the system).
And the static map/factory design makes it trivial to add new facets and quite simple to replace existing ones with more advanced version (the later needs explicit initialisation for now).

Oh right, I see your motivation better now. Fair enough then.
Just to clarify: when a Locale wants to create its facets, it will look to the factory, and get it to generate the facets. This may just be the default facets (for numbers, currency, date-time, etc.), or they may be "advanced" versions of the facets provided by alternative crates. These alternative crates would override the factory, perhaps by specialisation?

@alexreg, yes.
Overriding factories for existing facets will have to be done by registering function pointers, because there are no new types involved. For new types of facets, providing suitable impl is enough.

Sounds fair enough. I'm sure you've thought this out anyway, and will continue to tweak it where appropriate, to make the developer interface as simple as possible. :)

In the mean time there is also https://github.com/projectfluent/fluent-rs

Thanks @kud1ing. Looks interesting. Does the library support numeric, datetime, everything?

Hi all!
We just released https://crates.io/crates/intl_pluralrules which brings one of the foundations for any decent intl/l10n API. You can read about it here: https://blog.mozilla.org/l10n/2018/08/03/intl_pluralrules-a-rust-crate-for-handling-plural-forms-with-cldr-plural-rules/
As for l10n - I just released fluent-rs 0.3, which gets closer to be a complete l10n solution. It's still raw and doesn't have any syntactic sugar like macros, but it gets the job done the right way.
As for intl - with plural rules ready, we can start talking about CLDR based date/time formatting, number formatting and units. Maybe collation?
I'm one of the core contributors to ECMA402 (JS Intl) and would be happy to help anyone willing to drive the implementation.

Does the library support numeric, datetime, everything?

It's ready to support it (which is non-trivial - gettext for example will never be on the syntax level). Once Rust gains any intl date/time/number formatting library, we can plug it into Fluent.

@zbraniecki Sounds good. Does your project have an impedance mismatch of some sort with @jan-hudec's library, or would you consider using it? I believe his might be further along on things like numerics and datetimes.

Not sure yet. I think the ultimate goal is aligned - get ECMA402-like basic internationalization features:

Date/Time
Number
Collation

and with time advanced ones:

Units
RelativeTime
ListFormatting

But based on my experience working on CLDR, ECMA402 and Rust, I'm more prone to follow the rust-unic approach of building an array of specialized crates/APIs rather than trying to follow POSIX approach of building some unified locale crate.
There's another difference I noticed. @jan-hudec's crate follows the (once again - POSIX?) approach of using the OS APIs to internationalize data. In my experience this approach has many shortcomings that make most major projects move away from it. In fact, Firefox used to do that, until around 2 years ago we moved away to bundle CLDR/ICU package and unify our internationalization API around it.
intl_pluralrules follows that approach - it bundles the CLDR data making it universal across platforms and independent of them.
I'll investigate upstreaming the crate to make it part of rust-unic, and I'd be interested in pursuing CLDR based intl_datetime, intl_number, intl_list and so on.
As for fluent-rs - this crate can plug into any formatter, including OS-wrapper like @jan-hudec's crate.

Also, in ECMA402 we're currently standardizing core Intl.Locale crate [0] and in Rust I wrote a very similar crate fluent-locale-rs [1] which handles basic BCP47 language tag manipulation and language negotiation (based on RFC4647, but customized).
I'm interested in upstreaming at least the core manipulation portion of it to unic since it is part of Unicode.
[0] https://github.com/tc39/proposal-intl-locale
[1] https://crates.io/crates/fluent-locale

I submitted a request to update arewewebyet - https://github.com/bashyHQ/arewewebyet/issues/120

@zbraniecki, I basically got into analysis paralysis and got nowhere with the locale crate. Exactly because putting it in one crate is ultimately the wrong way, because there are too many options and most programs won't need much of that anyway.
The plan with locale was changed from using the system API to doing it myself—except it is too much work—and eventually to binding ICU. Which I started, but didn't get around to compiling it when there is no system one available yet (their system for bundling the data is Insane™ and cross-compilation-unfriendly).
There is one think of it I think is in useful state, the locale_config, which reads the user locale from system configuration (supporting POSIX, Windows (old api) and CGI). It returns basically a BCP47 tag, but extended with category locales to be able to represent the POSIX locale categories and the separate UI language setting.
There are also already two libraries for manipulating the BCP47 tags: language-tag and language-tags; it would perhaps be nice to avoid duplication here.

@zbraniecki Sounds like a fair approach. I'm no expert on internationalisation presently, but if you want to get things moving in Rust, I could potentially contribute to this efforts (especially *intl_numberandintl_datetime– I don't know whatintl_list` is). I had planned to contribute to @jan-hudek's project previously, but sadly got very busy at that time (sorry!). That said, it looks like Jan has just written a good analysis (or brief post-mortem, if you can call it that) on his library, and can be salvaged from his and other's work. It makes sense to me.

I basically got into analysis paralysis and got nowhere with the locale crate.

Hahah, every software engineer has their own skeleton closet, right? :)

(their system for bundling the data is Insane™ and cross-compilation-unfriendly).

Yeah, for that reason, both in ECMA402 and in Rust, I'm leaning toward centralizing around CLDR which is a very well maintained database.

It returns basically a BCP47 tag, but extended with category locales to be able to represent the POSIX locale categories and the separate UI language setting.

That's cool! I'm wondering if it should be two smaller crates then: posix-bcp47-converter and os-locale? I see more scenarios where you may want to convert the POSIX extensions to BCP47 unicode extensions and variants.
On the other hand, os-locale may want to read the POSIX and not convert it to BCP47.

it would perhaps be nice to avoid duplication here. Though I see you did get further—I don't think either of them actually does matching.

Yeah, I'm not sure what's the difference between those two. I evaluated the language-tags and reported a small bug I found. Overall the crate works well and I'm not sure what does language-tag brings to the picture.
I would hope that with some sort of intl_locale create (similar to ECMA402 Intl.Locale) we will be able to reduce this crate (and my fluent-locale) to language negotiation role.

I don't know what intl_list is

Internationalized list formatting, think of cases like Anna, John and Mary (standard list), or 2 feet, 10 inches (unit list). It's very useful later in combination with unit formatter, date formatter ("2 hours and 10 minutes") or relative time formatter ("in 2 hours and 22 minutes").

Anyway, let me know if you want to discuss this at some point.

Sure! I'm mainly focused now on finalizing Fluent 1.0 and its rust port, so not much time for intl, but I think the next step can be one of:

take intl_pluralrules and merge it into UNIC
take fluent-locale-rs and extract intl_locale out of it based on https://github.com/tc39/proposal-intl-locale
kick off intl_datetime based on ECMA402's Intl.DateTimeFormat

I would recommend to wait with intl_number just because ECMA402 is working on a new revision based on the second iteration of ICU NumberFormat and it may make sense to wait for them to settle things.
I'm unlikely to kick off anything until Fluent 1.0, but I'll be happy to advise and contribute code :)

@zbraniecki, @alexreg, actually I now remember why I didn't select a set of separate crate for each facet (numbers, datetime etc.): to make the formatting extensible, there should be one trait for formatting things—defining the toLocaleString method—but due to the orphan rules the crate that introduces it must immediately implement it for any standard types that should have it, which means all built-in numeric types and also the std::time::SystemTime (for date+time).
Of course if the toLocaleString method would have different options for each category (number, time etc.), it can be implemented by separate crates, but then the formatting options can't be taken from the formatting template—which may not be a problem, because they have no business being there, it's just (false) convenience.

@zbraniecki,

(their system for bundling the data is Insane™ and cross-compilation-unfriendly).

Yeah, for that reason, both in ECMA402 and in Rust, I'm leaning toward centralizing around CLDR which is a very well maintained database.

Well, ICU is CLDR based and already implements most of the things, so binding it should be faster route to something working. And while their data bundling is pretty weird, I actually think when statically linking with Rust, we can simply include! the .dat file in a Rust source defining appropriate extern symbol and things should work. So it's not that insurmountable.
I have three issues why I see it more as a temporary solution than a final one:

The data pack, even if we discard the unicode tables (which Rust already has elsewhere), is something like 20MB and cutting it further down to drop more obscure functionality is not really possible. 20MB statically linked into everything is a lot (with system ICU it's not a problem though). I suspect a better format taking advantage of the inheritance could do better.

While their message formatting should actually support most of the things fluent aims to (they have choice by plural or by property in the template), it does not seem to be extensible in the way of defining new types of parameters, so we can't make it go through the Rust trait for formatting the parameters. But there is a reimplementation of that already—and you'll want the fluent format anyway.

The number formatting seems to only be able to specify precision via the patterns, but they are unwieldy.

It returns basically a BCP47 tag, but extended with category locales to be able to represent the POSIX locale categories and the separate UI language setting.

That's cool! I'm wondering if it should be two smaller crates then: posix-bcp47-converter and os-locale? I see more scenarios where you may want to convert the POSIX extensions to BCP47 unicode extensions and variants.

It is more than BCP47 unicode extensions and variants. In POSIX, you can set e.g. LANG=cs_CZ LC_MESSAGES=en_GB and it will translate it as cs-CZ,messages=en-GB. POSIX has other categories too, but separate messages category exists on Windows too and I believe other systems and users do tend to have mixed locales.
It might make sense to extract the little bit that reads the POSIX environment variables, but it's just that—a bunch of environment variables. And they are not really well defined, so you either convert them to BCP47, or you let setlocale("") interpret them and that's about all you can do with them, so I am not sure it's actually worth it.

Well, ICU is CLDR based and already implements most of the things, so binding it should be faster route to something working.

Sure, if you're good with "something working" :) My point is that ICU is a massive codebase with quite significant technical debt. I'd argue that CLDR has very little of it.
For that reason, I'd prefer to invest resources (hah, I mean, suggest for us to focus on) in implementing similar APIs in Rust, rather than wrapping C.
I understand that there's work to be done, but quite frankly, to get the basics (date/time/number) it feels quite feasible.
The added benefit is that slicing CLDR is relatively easy and we can make our crates handle data selection both by locale selection and table selection, much easier.

@jan-hudec Sounds fair to me with regards to keeping it in one crate. Not sure what @zbraniecki thinks though...

@zbraniecki

Sure! I'm mainly focused now on finalizing Fluent 1.0 and its rust port, so not much time for intl, but I think the next step can be one of:

Fair enough. Let me know when you're done with that though.

take intl_pluralrules and merge it into UNIC

As a new crate you mean? Something like unic-pluralrules? I guess we'd want to get that accepted by the UNIC project developers. Do confirm it belongs there, however.

take fluent-locale-rs and extract intl_locale out of it based on https://github.com/tc39/proposal-intl-locale

Can you elaborate on this maybe?

kick off intl_datetime based on ECMA402's Intl.DateTimeFormat

Yep, this is the first big task, once the smaller things are out of the way!

I was wondering, if the plans you are making will allow for compiling to WASM and using in the context of a single page web application. This requires a) a pure Rust implementation, that does not wrap a pre-compiled library (say C or C++) b) a manageable download size of the internationalization libraries.

intl_pluralrules 1.0 has been released - https://crates.io/crates/intl_pluralrules

Can you elaborate on this maybe?

It would be great to have a low-level BCP47 language tag manipulation library that can parse/operate and serialize language tags as locale objects.. `ECMA402 Intl.Locale is just that, so it's likely a good start.

@zbraniecki Okay, I'd be happy to work on this, if you think it's easier than one of the above tasks you suggested? Maybe get on Discord/IRC?

if you think it's easier than one of the above tasks you suggested

I think it is definitely easier than date time formatting, and lays foundation for it. You could start by taking the fluent-locale-rs crate and extracting just the Locale struct and its parsing/serializing. Add the impl methods that ECMA402 Intl.Locale has and call it unic-locale.
I'm not sure how to fit it into unic crate system, but I hope @behnam can help with that.

Sorry for the delays on UNIC-related work. I'm trying to fit the work in my schedule. I'm starting by putting the core data into standalone repos, to make it easier to define a maintainable Locale implementation in UNIC. I'll give more updates on that as soon as I can.
Regarding, ECMA-402-based int'l library, I think it would be a great thing to have, specially to be able to backport for older JS environments. But what we're trying to do in UNIC (and other implementations that are not open-source yet) is to create a more modern API. Again, more on that soon.

It would be great to have a low-level BCP47 language tag manipulation library that can parse/operate and serialize language tags as locale objects.

There are two or three on crates.io already. In various state of completeness.

There are two or three on crates.io already. In various state of completeness.

I only saw crates handling accepted-headers and nothing related to manipulation and serialization of langage tag objects.
In other words, if you mean language-tags crate, then I don't think that's what we're looking for. Same with accept-language.
We're looking for something similar to ECMA402 Intl.Locale and more modern version of ICU's Locale.
Example of usage:
let loc1 = Locale::from_string("en-us-u-hc-h24");
assert_eq!(loc1.get_region(), "US");
assert_eq!(loc1.get_extension_value("unicode", "hourCycle"), "h24");
loc1.set_script("latn");
loc1.set_extension_value("unicode", "hourCycle", "h11");
loc1.set_extension_value("unicode", "calendar", "buddhist");
assert_eq!(loc1.to_string(), "en-Latn-US-u-ca-buddhist-hc-h11");
assert_eq!(loc1.matches_language("en-GB"), true);
assert_eq!(loc1.matches_locale("en-US-u-ca-buddhist-hc-12"), true)

and so on.

@zbraniecki, no, I mean primarily language-tag with no s at the end. That one does do the parsing, though I think it's not complete as far as matching goes (and there are two kinds of matching and both are needed).

Oh, yeah, this one looks similar. So yep, some merge of this and fluent-locale seems like the right direction. I'd prefer to call the struct locale over langtag, but that's purely a preference.

So, what we need to do now is the following, regarding a unic-locale crate, as I understand:

Include a Locale type.
Try to reuse parsing code from fluent-locale crate.
Try to reuse parsing code from language-tag crate. (Is this for a different purpose?)
"Add the impl methods that ECMA402 Intl.Locale has" -- you mean take the listed operations on locale from the ones listed in the standard?

Correct me if I'm wrong on any of the above. I have a bit of time to work on this now, but I do want to make sure I'm not going to waste effort.

This list looks good! fluent-locale and language-tag crates may have different parsing approaches (one seems to be a parser generator, the other is written by hand), but this should be an implementation detail. I'd expect the hand written to be faster, but you can probably benchmark and use whatever is easier - swapping it later will be backward compatible.
For the Ecma402 Intl.Locale - it's worth checking the API there and applying it onto the class. It'll likely come useful in Rust just as much. :)
Happy to provide feedback and/or review, but you may want to also check with @behnam - he seems to be interested in this effort as well and has some experience from his recent work in Python.

Okay, sure. Let's see what @behnam has to say, then I can get going hopefully. :-)

Okay, some updates are coming soon to UNIC, but it will take longer to build the Locale crate. To start, I'm first making a Territory model, which will be responsible for the region part of BCP-47 codes, as well as the sd extension. See https://github.com/open-i18n/rust-unic/issues/234 for more details.
Having the Territory model, then the next focus will be the Language model. And then building Locale on top of those.
The general idea is to not use &str/String for representing i18n data. The top reason is to not hide all the problems under the rug. For example, if a country code goes out of use, the code having conditions against that country code should get compile errors. IMHO, this is necessary for getting a solid i18n library that doesn't require playing whack a mole with bugs down the road.
As we have mentioned over the past year or so, UNIC is still experimenting with how to improve i18n architecture. For any application that doesn't want to get into this experiment, I would recommend using ICU-based solutions, which would work with all of these as strings.
What do you think?

I like the idea of the compiler catching stuff a lot. Specifically in the example you are giving of a country code going out of use though, I believe it should not refuse compiling. Instead it should compile with a warning, so that code that once did compile but needs a change somewhere (say a critical security fix) will continue to compile and run the way it did before (say interfacing with another system, that has not been updated).

@zbraniecki
Just to update i18n discussion on Rust - new library being developed at https://github.com/unicode-org/icu4x. It's based on Ecma402 API and implemented in Rust.
We are currently at the early stages of development.

An update. ICU4X is now in a stable version 1.1 - https://github.com/unicode-org/icu4x - ready for adoption, and it supplies basic ECMA-402 functionality.
It would be great to see an experiment to use icu4x to supply the needs of this issue.


Feature Request: line object

Feature Requested
Could we add a line object similar to vim-textobj-line?
Relevant Screenshot
No response
Checklist

[X] The feature would be useful to more users than just me.

Nope – vim already has a line text object, so there is no need to add one: https://github.com/chrisgrieser/nvim-various-textobjs/issues/14#issuecomment-1451873159

Huh. Yeah, I guess I can get vil for a line by doing vim.keymap.set("x", "il", "^og_"). Alrighty. Cheers.

I do when operating on an entire line. I use il to operate on line contents sans-whitespace.

ah, so dd would delete the line, while dil would delete the line content, not changing the line number?

Added as lineCharacterwise textobj in the latest update 🙂

Right. It leaves the newline and indentation. 👍


[lexical-playground][lexical-react][lexical] Feature: Theme class added to horizontal rule node

Description
This PR adds theme class support to HorizontalRuleNode so that it can be targeted from the theme object in the editor config instead of through CSS workarounds. The selected class is still added/removed upon selecting the HR node and relevant tests have been updated to include the theme class.
Closes: https://github.com/facebook/lexical/issues/4336

Reopened without unwanted rename changes: https://github.com/facebook/lexical/pull/6090


Dead link https://www.visualstudio.com/en-us/get-started/share-your-code-in-GIT-vs

Found in release-notes/2012/aug-13-team-services.md

Fixed


WIP remove logind backend

Rely on libseat instead.
See https://github.com/swaywm/wlroots/issues/2755

Any reason why this is WIP?

Any reason why this is WIP?

Just to avoid premature merge while 0.13.0 was being hashed out.

Marking as breaking change as this removes WLR_HAS_SYSTEMD and WLR_HAS_ELOGIND.


default options

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
214

Relevant Lines:
293

💛  - Coveralls


[release-4.15] OCPBUGS-29213: Remove SigstoreImageVerification feature gate

The CRD ClusterImagePolicy for image verification feature hasn't been implemented OCP 4.15. We plan this feature for 4.16

/jira refresh

/jira refresh

https://redhat-internal.slack.com/archives/CE4L0F143/p1707764812750449 We corrected the document featuregate list to not have SigstoreImageVerification. Close this PR since including this is safe from the code perspective.


Broken link to "mapping change with zero downtime" on readme

Change the mapping and re-index you data from cassandra with zero downtime, see Mapping change with zero downtime: (link is broken)
https://github.com/vroyer/elassandra/blob/master/Mapping-change-with-zero-downtime

anchor link fixed.


Add a search page

Is your feature request related to a problem? Please describe.
This is a front end component, please refer to the Figma on the wiki for the current design. If there is no design, feel free to add your own to fit the criteria.
(This is WIP, so we haven't decided on the full details yet)
The user should be able search some term and see the results for every user and post that matches
Describe the solution you'd like

A search bar (possibly as a text input inside a CustomizableHeader component)
Bottom navigation footer
User results and post results should be separated into tabs
User results can be SimpleUserDetails
Post results can be condensed Posts with no replies shown

Describe alternatives you've considered
N/A
Additional context
N/A

closed by https://github.com/SE701Team2/Updog/issues/206


Author page does not have proper twitter card

https://twitter.com/Syknapse/status/1136530592395399168

Instead of including default header template on author page, we can use the one with proper meta tags? Can it be achieved this way or is there any better way?

yes that is a good approach @sunnyssr.  we just need to have a name="twitter:image" meta tag. I think we should  repost this issue on ghost's issue tracker since the whole ghost community could benefit from a fix to this issue.

Hey,
Any update on this one?

Hi @sunnyssr,
Updating the cover photo cover  for each author would cause result in the addition of the correct meta tags.
the reason that they have not added a fallback is to ensure good resolution for the twitter card image.
https://github.com/TryGhost/Ghost/issues/10988#issuecomment-518280508

@ahmadabdolsaheb
Can we show the author profile image instead of cover photo?


Fix incomplete javadoc for TracedResponseObserver or change behavior

I accidentally left incomplete javadoc for the TracedResponseObserver class. It was supposed to read
 * <p>The operation will be marked as complete before notifying the wrapped observer. Which means
 * that the span of the instrumentation will not include processing of the innerObserver's
 * onComplete.
 *

However, while trying to remember my intent when writing that class, I'm not sure if this is the desired behavior. My original intention was to try exclude the caller's processing from metrics gathered callable chain below. However looking at it with fresh eyes, I dont think that. possible because there many callbacks of onResponse that will invoke observers callable above. So now it seems arbitrary to exclude onComplete from the span.
I'm not sure if this behavior should be changed or just documented. I would like a second opinion before making the change

Just documenting the behavior SGTM.

+1
Unless the current implementation is fundamentally wrong, I think just making the documentation match the implementation is better.
Documenting is easier.
Also, sometimes "fresh eye" view could be an indication of forgetting something important from the past which actually caused you make the original implementation. I.e. just making documentation match the implementation also looks safer.
doc vs implementation -> 2:0.

Ok, I'll update the docs

Ok, I'll update the docs


Form action set as insecure by google chrome.

Fixes issue #349
When accessing a website with https, the forms action="" that are not https:// are set as insecure by Google Chrome Google Chrome Docs.
The new form action on @solidjs/router renders the markup like this:
<form method="post" action="action:signUpForm">...</form>
This PR changes the action to:
<form method="post" action="https://action/signUpForm">...</form>
Preventing Google Chrome from seeing the action as unsafe.

Hmm.. only thing I'm wondering is if we are lying here if the protocol for the site isn't https..  Then again this whole thing is a lie in a sense as we never actually submit the form. I'm just wondering if we just used /action without the https would this still work on an https site.
I guess the biggest issue there would be eliminating the base URL. Or I guess using the attribute value instead of the property value.
I can merge the PR and play with it. I guess there is no easy way to test this locally.

Hello @ryansolid,
I can make that change, no worries; I got the setup done already. Because we are attaching an event doing preventDefault, it won't conflict with a real route starting for /action (I hope :D)
Let me amend the change and check if it works properly.


Add new ARGILLA_HOME_PATH environment variable

This PR adds ARGILLA_HOME_PATH new environment variable with a default value equal to ~/.argilla.
After that ARGILLA_HOME_PATH is used to define the default value for ARGILLA_DATABASE_URL.
I have added these changes to _const.py file but maybe we should create a settings.py file or something similar.

We are using this https://docs.pydantic.dev/usage/settings for managing app settings from environment vars.
I think (need to validate) this is also compatible with the idea of an environment file (json, ini or whatever) containing all the application settings (See https://docs.pydantic.dev/usage/settings/#adding-sources)
So, maybe we can add these new env vars to the common app settings that we have already defined in https://github.com/argilla-io/argilla/blob/develop/src/argilla/server/settings.py#L28


fix containerd running critest on wrong commit and make default critest show version

first commit shows version information by default for critest runs
second commit will fix containerd git hub actions
Signed-off-by: Mike Brown<EMAIL_ADDRESS>

/hold
For the second commit?

/hold
For the second commit?

yes sry working it... needed another change for version
had to make it print version always and exit if version is the option
this shows the failure...

ok.. note critest does not output version for containerd but does for the others..

Fix for ^ should be here: https://github.com/containerd/cri/pull/1128

/hold cancel

Looks like prow did not wait for all jobs to be finished successfully 🤔


feat: upgrade Ava

[x] Upgraded ava from 1.x to 2.x which brings lots of breaking changes.

Thanks for the pr, it looks good, the conflict needs to be resolved.

Resolved conflicts

@clarkdo : any thoughts on merging this?

Sorry for the delay due to my device issue, I’ll check this as soon as it’s back to work

@clarkdo it's cool 😎

Uhh. Hi!


Update README to add pandas as dependency

Add pandas to README as dependency

Codecov Report

Merging #250 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master    #250   +/-   ##
======================================
  Coverage    86.3%   86.3%
======================================
  Files          33      33
  Lines        1935    1935
======================================
  Hits         1670    1670
  Misses        265     265

Continue to review full report at Codecov.

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


Add example featuring negative constraints in replication zones

We mention negative constraints [here](https://www.cockroachlabs.com/docs/stable/configure-replication-zones.html#types-of-constraints}, but we should add an example or two.
cc @robert-s-lee

We now have at least a few examples on the replication zones page:

An example showing a negative/prohibited zone config in the Types of constraints section:

Define a required and prohibited definition for the same key-value pair. For example, constraints = '[-region=west, +region=west]' will result in an error.

There is also an example of a negative constraint in the Scope of constraints section:

constraints = '[+ssd, -region=west]'

Closing this issue, but please re-open if you disagree


post rake module release, metadata.json version and git tag are not in sync

When we use rake:release
https://github.com/voxpupuli/puppet-blacksmith/blob/master/lib/puppet_blacksmith/rake_tasks.rb#L87
release_dependencies = @build ? [:clean, :build, :tag, :push, :bump_commit] : [:clean, :tag, :bump_commit]
It is doing tag first and them bumping metadata.json via bump_commit.
Ideally we should update the metadata.json file and add it , commit it and then tag it and push it to remote.
release_dependencies = @build ? [:clean, :build,  :bump_commit, :tag, :push,] : [:clean, :bump_commit, :tag]
so that
$ git tag | tail -1
v0.1.5
$ grep '"version":' metadata.json
"version": "0.1.5",
are same on github when module is released?
Correct?

version in git is always ahead of last tag. After tagging development starts in the next version
This is so you inadvertently don't use a development version instead of a release version.


Issues with Material skin in Fully Kiosk Browser

I have been trying to use Fully Kiosk browser on Android 8.1 to view the Material Skin and it will eventually freeze or have rendering errors.
08:39:12.791 -- [ERROR] Uncaught ReferenceError: storeClickOrTouchPos is not defined -- on line 762 of http://<IP_ADDRESS>:9000/html/js/material.min.js?r=4.3.3
08:39:12.847 -- [ERROR] Uncaught ReferenceError: storeClickOrTouchPos is not defined -- on line 761 of http://<IP_ADDRESS>:9000/html/js/material.min.js?r=4.3.3
08:40:55.412 -- [ERROR] Uncaught ReferenceError: storeClickOrTouchPos is not defined -- on line 762 of http://<IP_ADDRESS>:9000/html/js/material.min.js?r=4.3.3
08:40:55.466 -- [ERROR] Uncaught ReferenceError: storeClickOrTouchPos is not defined -- on line 761 of http://<IP_ADDRESS>:9000/html/js/material.min.js?r=4.3.3
08:45:45.942 -- [ERROR] Uncaught ReferenceError: storeClickOrTouchPos is not defined -- on line 762 of http://<IP_ADDRESS>:9000/html/js/material.min.js?r=4.3.3
08:45:46.001 -- [ERROR] Uncaught ReferenceError: storeClickOrTouchPos is not defined -- on line 761 of http://<IP_ADDRESS>:9000/html/js/material.min.js?r=4.3.3
08:46:45.060 -- [ERROR] Uncaught ReferenceError: storeClickOrTouchPos is not defined -- on line 762 of http://<IP_ADDRESS>:9000/html/js/material.min.js?r=4.3.3
08:46:45.108 -- [ERROR] Uncaught ReferenceError: storeClickOrTouchPos is not defined -- on line 761 of http://<IP_ADDRESS>:9000/html/js/material.min.js?r=4.3.3
08:47:36.020 -- [ERROR] Uncaught ReferenceError: storeClickOrTouchPos is not defined -- on line 762 of http://<IP_ADDRESS>:9000/html/js/material.min.js?r=4.3.3
08:47:36.143 -- [ERROR] Uncaught ReferenceError: storeClickOrTouchPos is not defined -- on line 761 of http://<IP_ADDRESS>:9000/html/js/material.min.js?r=4.3.3

And why is the issue with the skin not the browser? Works everywhere else.

I’m not saying the issue is with Material Skin, it’s very likely in the browser.  I am just trying to understand the error in the java script.
From: CraigD @.>
Sent: Friday, March 8, 2024 09:15
To: CDrummond/lms-material @.>
Cc: Patrick Mendiuk @.>; Author @.>
Subject: Re: [CDrummond/lms-material] Issues with Material skin in Fully Kiosk Browser (Issue #858)
And why is the issue with the skin not the browser? Works everywhere else.
—
Reply to this email directly, view it on GitHubhttps://github.com/CDrummond/lms-material/issues/858#issuecomment-1986090449, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BAHJGN54BU6HVFLB4O4FMXLYXHWX5AVCNFSM6AAAAABENEBLNWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBWGA4TANBUHE.
You are receiving this because you authored the thread.Message ID<EMAIL_ADDRESS>