bin/dev: 8: exec: foreman: not found

I get this error when I run bin/dev in the terminal

/home/test/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/foreman-0.87.2/bin/foreman start -f Procfile.dev
That's what ended up working for me in case anyone else has the same problem, however yours might look slightly different becaue this is the route for my laptop

@Michael-Mehta try running rbenv rehash if that doesn't fix your issue then there might be problem with your rbenv installation.

Using rbenv rehash  works for me


Unify plugin publishing for test and stable version

Description of the PR
Adds a workflow that gets triggered by a new release. This is very similar to the existing workflow that gets triggered by a pre-release, except that it publishes to the stable channel instead of the test channel. Closes #310.

unit
integration
manual

- [ ] new unit tests created
- [x] all unit tests pass

- [ ] new integration tests created
- [x] all integration tests pass

- [ ] manual testing went well

Have you updated the TESTING.md or other relevant documentation?

[ ] Yes
[ ] Not yet. I will do it next.
[x] Not relevant

As far as I understand something of this, looks good. +1
Can we go through once more, how are releases triggered? It's git tags, right? And is naming of tags significant in whether or not they are considered pre-release?

Sure!
Yep, it's Git tags. If you open the GitHub menu for creating new tags, there is an option for whether the release is a pre-release or a normal release (you can look at the v1.7 tag to see what a pre-release looks like), so naming should not have anything to do with it. (I'm not sure what this pre-release option corresponds to in Git tags). Then simply editing the tag and changing that option from pre-release to normal release should trigger the release event.
My only uncertainty here is that checkout action, but from it's documentation:

When checking out the repository that triggered a workflow, this defaults to the reference or SHA for that event. Otherwise, uses the default branch.

As I understand it, we are checking out from the repository that triggered the workflow, so the reference should be the (pre-)release event.

Sure!
[...]

Perfect. Thank you! 👍


Review and Close out GH Issues from 2015, 2016

It's 2019

Good - but some still need action

Closing this ticket in favor of using the "is this still a thing" GitHub Issue Label


My editor has crashed and won't reload

I have no idea how to recreate it.

Try atom --clear-window-state Note: This will clear the unsaved state of ANY project you had opened in Atom
See: http://flight-manual.atom.io/hacking-atom/sections/debugging/#clearing-saved-state for more information

Because we treat our issues list as the Atom team's backlog, we close issues that are questions since they don't represent a task needing to be completed. For most questions about Atom there are a lot of options, check out:

The Atom Flight Manual
The Atom FAQ on Discuss
Discuss, the official Atom and Electron message board
Join the Atom Slack team

On Discuss and in the Atom Slack team, there are a bunch of helpful community members that should be willing to point you in the right direction.


Not working

Hello Team,
Your library is very useful. I have been using last 6 months and helped me so much to reduce my writing work.
As I was working some conversion but it's not working. Then I looked for console log for website then found some error if user clicked on "Preview" or "Zip" buttons, it shows not found.
Please get attached image which has error.

This works find for me in Chrome 68 and Firefox 61.

Are you accessing this through some kind of proxy that is messing with the responses?

@joelittlejohn I have chrome version Version 68.0.3440.106 (Official Build) (64-bit) and also tested on Firefox having Version 61.0.1 (64-bit). It's not working on both browsers.

Could you test this in a private/icognito browsing window? Also disable all extensions like adblock that might be messing with the page content.

An Issue is resolved. Now it's working fine.


Add travis support for OSX

This fixes a thing in the OSX backend so it builds fine on Travis, changes a bit the .travis.yml, and disables the test on OSX.
Only five of them pass currently, and I don't know how to disable only a few test using autoconf and automake and all.
@kinetiknz, does that look reasonable?

LGTM


Update changelog and version

Coverage increased (+0.1%) to 94.231% when pulling ee9bae3e14d1dff55f362e5c4cd29ae9399e1798 on release/0.25.0 into 4cb1a0a781e21fb7fed9debb0f1b9f28f1adf446 on main.


Practice problems Unit 2 Pathway 1: Android Basics with Compose

A ---
name: Practice problems unit 2 pathway 1 issue template
about: Issue template for Unit 1 | Pathway 1 | Practice Problems
title: 'Practice problems Unit 2 Pathway 1: Android Basics with Compose'
labels: ''
assignees: ''

URL of codelab
https://developer.android.com/codelabs/basic-android-kotlin-compose-kotlin-fundamentals-practice-problems?continue=https%3A%2F%2Fdeveloper.android.com%2Fcourses%2Fpathways%2Fandroid-basics-compose-unit-2-pathway-1%23codelab-https%3A%2F%2Fdeveloper.android.com%2Fcodelabs%2Fbasic-android-kotlin-compose-kotlin-fundamentals-practice-problems#3
In which task and step of the codelab can this issue be found?
Task 4 - Temperature Converter
Describe the problem
In the provided code the names of the properties do not match the names used in the println() statement.
initialTemperature should be initialUnit; and;
finalTemperature should be finalUnit.
Steps to reproduce?

Copy code into playground
Complete missing code in main() function - e.g. printFinalTemperature(27.0, "Celsius", "Fahrenheit") {9.0/5.0 * it + 32}
Click on button to run
See errors:

Unresolved reference: initialTemperature
Unresolved reference: finalTemperature

Versions
Android Studio version:
API version of the emulator:
Additional information
Include screenshots if they would be useful in clarifying the problem.

@mrpwilliams80
Thank you for reaching out to us. The issue is fixed and will be published soon.
`fun main() {
// Fill in the code.
}
fun printFinalTemperature(
initialMeasurement: Double,
initialUnit: String,
finalUnit: String,
conversionFormula: (Double) -> Double
) {
val finalMeasurement = String.format("%.2f", conversionFormula(initialMeasurement)) // two decimal places
println("$initialMeasurement degrees $initialUnit is $finalMeasurement degrees $finalUnit.")
}`


Update the default alerts

We should add more interesting default alerts that better showcase the power of Watchdog

Great idea and I love the ones you've pulled in so far!

Done in 1952818b8edeae87439edd529d663605680a9024


How many  times WebSocket handshake?

In these code:
private boolean decodeHandshake(ByteBuffer socketBufferNew) {
 ...
            if (handshakestate == HandshakeState.MATCHED) {
                ...

                  write(d.createHandshake(
                      d.postProcessHandshakeResponseAsServer(handshake, response)));
                  draft = d;
                  open(handshake);
                  return true;
                }
}

Why server accept handshake, the WebSocket open directly. Isn't it three-way handshake?

just read   1.3

Closing as there is no specific issue - the current implementation conforms to the spec and has been tested carefully.


broadcast_key: Insert wallet into script wallets iff broadcast is successful

broadcast_key inserts the input private key derived wallet into state.script_wallets even if it fails due to failed internal call to broadcast.
This PR changes broadcast_key to insert the wallet iff the internal call to broadcast succeeds.
Motivation
The change ensures duplicate wallets are not accidentally inserted into state.script_wallets after one or more failed calls to broadcast_key.
Solution
Only insert wallet into state.script_wallets iff internal call to broadcast succeeds.

@4meta5 will you have time to rebase this?


Schema: Remove redundant xs declaration

This pull request derives from #472. So needs to be handled after that.

This pull request just removes unnecessary datatypes declaration. (replaces xs with predeclared xsd)
Test
There already is a basic test for the schema:
https://github.com/xspec/xspec/blob/d333c7af0868ef2fbbe9e7ce03148be047c8a09e/test/xspec.bats#L665-L677

@galtm
This will conflict with #475, but the conflict will be very trivial. Just FYI.

@cirulls
Merged this simplification of schema. Nothing is actually changed.

This will conflict with #475, but the conflict will be very trivial.

@AirQuick , I uploaded 13fa7881fe346d5103361b23d22a285723ad6f98 to #475.


Chinese is not displayed completely in the TextField with singleLine=true

without singleLine

with singleLine=true

What is expected behavior?

The first screenshot is the expected behavior even when singleLine=true.  Notice in the first chinese character, the first screenshot includes the horizontal line at the bottom of the character.  That horizontal line is part of the character, and drawing that character without the horizontal line is incorrect.  The other second character is also cut off (missing some pixels), but it's a little less obvious at first glance.

The same issue. When will it be fixed？

This is not only for Chinese, Latin letters are also cut - see L on the screenshot

Has the issue been fixed?

yes, we use another font now. Do you still have this issue?

I have solved the problem after upgrade the dependency.
Thank you. This issue should be closed.

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


Does this compile with ghc 7.6.3?

I can compile just fine with 7.8.3 but not 7.6.3.
Something goes wrong in preprocessing right off the bat
Building text-<IP_ADDRESS>...
Preprocessing library text-<IP_ADDRESS>...

Data/Text.hs:12:52:
     warning: missing terminating ' character [-Winvalid-pp-token]
-- Copyright   : (c) 2009, 2010, 2011, 2012 Bryan O'Sullivan,
                                                   ^

Data/Text.hs:93:12:
     warning: missing terminating ' character [-Winvalid-pp-token]
        , foldl'
               ^

Data/Text.hs:95:13:
     warning: missing terminating ' character [-Winvalid-pp-token]
        , foldl1'
                ^

Data/Text.hs:156:14:
     warning: missing terminating ' character [-Winvalid-pp-token]
        --, lines'
                 ^

Data/Text.hs:279:15:
     warning: missing terminating '"' character [-Winvalid-pp-token]

and it goes on like that and gives up:
fatal error: too many errors emitted, stopping now [-ferror-limit=]
29 warnings and 20 errors generated.

My system is Mac OX Yosemite (10.10.4)
Xcode 7 beta 4  and it's command line tools
gcc installed from brew
gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.4.0
Thread model: posix

I imagine it has something to do with my system config?

This is due to bugs in GHC 7.6 on OS X. Use a newer compiler.


makefile: add test scripts for local testing

Hi!
I was wondering what tests to include in "local testing".
Thanks!


Bring back docking toolbars

Description of the new feature / enhancement
In a previous version we were able to dock toolbar on any side of any screen.
This way we could simply hover a toolbar, have it expand and we could navigate
Scenario when this would be used?
When developing code or doing any admin support I can have a direct access and layout my screen border in a logical way to access information.  I would not be tie to single point of entry ( start menu)
Supporting information
No response

Great feedback for the taskbar team /feedbackhub


Not receiving syslog from server with RHEL 6.10 OS Version

We are trying to collect syslog from a RHEL 6.10 OS. It is an on-prem server. However, we don't see the correct logs in the tcpdump or in the osnix index.
The same syslog configuration works for AIX 5.3, AIX 6 and RHEL 8 as well.
Config file used for RHEL 6 and RHEL 8:
"audit log
imfile #Load the imfile input module
authpriv.* /var/log/secure
/var/log/audit/audit.log
tag_audit_log:
audit_log
info
local6
. @@receivinghostip:514"
Here's the tcpdump from the RHEL 6.10 server:
13:50:28.597040 IP (tos 0x0, ttl 60, id 27717, offset 0, flags [DF], proto TCP (6), length 60)
sendinghostname.44476 > receivinghostname.shell: Flags [S], cksum 0xd4bf (correct), seq 447763177, win 14600, options [mss 1460,sackOK,TS val<PHONE_NUMBER> ecr 0,nop,wscale 7], length 0
The raw data that was received initially for the rhel 6 server :
RAWMSG=\xff\xf4\xff\xfd
PRI=13
MESSAGE=\xff\xf4\xff\xfd
The syslog-ng (version 2.40.0) is configured on a Splunk Heavy Forwarder and the logs collected are sent over to Splunk Cloud indexers via HEC.
Is this a compatibility issue between the OS version and syslog-ng?

@AParida23
This issue is not related to SC4S and hence we are closing this issue.


Top border missing on avatar in user profile

The top border on the avatar in the user profile isn't showing up. We should fix this.

CZO discussion

Hey! @alya  Can you assign me this issue?

@zulipbot claim

@zulipbot claim

@zulipbot claim

@alya Could you please review my PR and merge it

I want to work on this issue please assign me this issue
Thanku,

@zulipbot claim

I want to work on this issue please assign me this issue

@zulipbot  claim

I want to work on this issue please assign me this issue

Hey vijay use  @zulipbot claim  to claim issues

@zulipbot claim

@s4shantanu This issue cannot be claimed, as someone else is already working on it. Please see our contributor guide for advice on finding an issue to work on. Thanks!

I want to work on this issue please assign me this issue !!


Cli installation stuck on shallow-clone

Trying to install the cli and its stuck here for 15 mins now.
C:\AngularProjects>npm install -g @angular/cli
[            ......] / unbuild:shallow-clone: info lifecycle<EMAIL_ADDRESS><EMAIL_ADDRESS>

This seems like a problem with node/npm and not with Angular CLI.
Please have a look at the fixing npm permissions page, common errors page, npm issue tracker, or open a new issue in that issue tracker if the problem you are experiencing isn't known.


testing: no CPU/mem limits on kubedns

Note: I'll be running tests many times, since we're proving a negative. If you see this PR and it isn't running tests (but has passed the last run), run it again!
kubedns seems to freeze up in tests, triggering flakes. In case that's
related to these limits, we removed them. Generally, since this isn't a
production system it might be simpler to let kubedns hog memory when
something goes wrong than have test flakes.
Related to the never ending https://github.com/cilium/cilium/issues/3878

This change is

test-me-please

test-me-please

oh yay, the other flake https://jenkins.cilium.io/job/Cilium-PR-Ginkgo-Tests-Validated/3906/testReport/(root)/runtime/RuntimeValidatedPolicies_Tests_Endpoint_Connectivity_Functions_After_Daemon_Configuration_Is_Updated/

test-me-please

Boo. This was a DNS failure (but it also couldn't collect logs correctly) https://jenkins.cilium.io/job/Cilium-PR-Ginkgo-Tests-Validated/3911/consoleFull


Make cell currents a model output

HNN GUI saves cell currents for 'L2Pyr_soma' and  'L5Pyr_soma' to the file i.txt, but doesn't currently plot them. Adding the functionality to hnn-core to calculate these currents would allow us to explore ways to represent/plot this data in the future.
Function to record currents (called for L2Pyr and L5Pyr):
https://github.com/jonescompneurolab/hnn/blob/bd2abe4007160a5186856bc17dd87ae62055b383/cell.py#L180-L194
Needs to be aggregated for each type of cell: https://github.com/jonescompneurolab/hnn/blob/bd2abe4007160a5186856bc17dd87ae62055b383/network.py#L370-L387
The above function is called after a simulation completes:
https://github.com/jonescompneurolab/hnn/blob/d4c4cf94aa1db8517b99b0e344aa852c16125f50/run.py#L435
After this functionality exists to retrieve currents as a model output (same mechanism as somatic voltages?), the code to save the output to i.txt can be added back to HNN GUI. It would be a cleaner version of this code:
https://github.com/jonescompneurolab/hnn/blob/d4c4cf94aa1db8517b99b0e344aa852c16125f50/run.py#L140-L145

#190 Is very similar with somatic voltages. It is not clear to me if this should be included in the same PR. The end goal is for cell level information to be accesible in a clean API as @jasmainak laid out:
>>> net = Network(...)
>>> net.cells[50].spikes
>>> net.plot_spikes()
>>> `net.cells[50].vsoma
>>> plt.plot(net.cells[50].vsoma)

I anticipate the diff in #190 to become large-ish. So, in the interest of an easier review, I suggest deferring this to another PR. You'll know what to do after #190 :-)

@ntolley can you update this your thoughts on moving forward with this? I know it is not required for hnn integration, but was curious if you had plans for adding this at a later time?

The last commit to the somatic currents PR achieves this goal. It's implemented in largely the same way as the voltages such that spikes.isoma is a dictionary indexed by gids.
There were several improvement ideas that came up in the somatic voltages PR. We were thinking of tacking them onto the somatic currents PR. If you were interested in incorporating currents into the GUI I can open a separate PR specifically for improvements to the Spikes class.
Any thoughts @jasmainak? It might make sense to just have a coherent discussion on the new Spikes API in an independent PR.

I see, thanks for catching me up. I don't want to go crazy adding more things to the GUI. So I may check that the API is sufficient and make suggestions. That's fine to do in a separate PR.
We can let the use case for somatic currents in hnn-core drive what (if any) visualization features should be added to the GUI.

yeah I agree with @blakecaldwell that let's get MVP for the GUI.
For the Spikes PR let's do simple and easy stuff first -- rename to CellResponse seems straightforward, add test to check agreement between spiketimes and voltages etc and maybe clean up some of the functions. Your to-to list looks about right. Smaller PR will be easier and faster to merge. So ideally keeping diff under 200-300 lines (red + green) helps.

Sounds good to me. Once it's merged the most logical thing to tackle is storing CellResponse as a list. I'm going to wait until that's done before adding new visualization as that will require some pretty big changes to the existing member functions of Spikes. For example, should mean_rates() be moved to the Network class if CellResponse is stored as a list?
In any case we can discuss the details once that PR has been started.


contradictory information

The part about Azure AD team is contradictory:
"A new property has been added to the security role definition to provide special team privileges when the role is assigned to group teams. This type of security role allows team members to be granted User/Basic-level privileges as if the security role is directly assigned to them. Team members can create and be an owner of records without the need to have an additional security role assigned.
A group team can own one or more records. To make a team an owner of the record, you must assign the record to the team.
While teams provide access to a group of users, you must still associate individual users with security roles that grant the privileges that they need to create, update, or delete user-owned records. These privileges can’t be applied by assigning a nonmember’s privilege inherited security role to a team and then adding the user to that team. If you need to provide your team members the team privileges directly, without their own security role, you can assign the team a security role that has member’s privilege inheritance."
paragraph 1 says that members of teams can inherit user level permissions so they don't need individual roles, paragraph 3 says users still need individual roles

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: bbd4b06c-0b9f-84a0-c82e-62498a193829
Version Independent ID: 81e8d2d1-fb7f-39dd-3d98-cfac068093b8
Content: Manage Dynamics 365 for Customer Engagement apps teams
Content Source: ce/admin/manage-teams.md
Service: crm-online
GitHub Login: @jimholtz
Microsoft Alias: jimholtz

@joellindstrom
Thanks for the feedback. The 3rd paragraph calls out that you need to assign the team with a member’s inheritance role otherwise the individual team member will require a security role of their own.


Error running esy on fresh ppx project

So I created a new ppx project with
spin new ppx testing_ppx

and after running esy inside the directory I immediately got the following error:
$ esy
info esy 0.6.2 (using esy.json)
File "test/dune", line 6, characters 2-23:
6 |   (pps testingppx.lib))
      ^^^^^^^^^^^^^^^^^^^^^
Warning: .merlin generated is inaccurate. Cannot mix preprocessed and non
preprocessed specificiations.
Split the stanzas into different directories or silence this warning by
adding (allow_approximate_merlin) to your dune-project.

I solved the issue with rm -rf test but this doesn't seem like the right approach. Can I get some advice on how to solve this? Thanks in advance!

Hi @dylanirlbeck!
Thanks for reporting the issue. The problem seems to be that the executable defined in test/dune does not have the preprocess stanza, whereas the library does. Apparently, dune handles this just fine, but merlin format is limited and can't find a way to represent this.
I made a PR to fix this, but I'm going to wait a bit before the next release of Spin. In the meantime, to remove the warning, you can add
 (preprocess
  (pps testingppx.lib))

to the executable stanza in test/dune.

Great, thanks!


Problem in responsive mode using table and panel

Hello.
At first, thank you very much for spectre.css
I have a problem when using panel and table in a same class columns, here is my code: https://jsfiddle.net/2cwna3vh/
If I am on PC, it's ok:

But on smartphone, here is the result!

Does I use correctly the component (and is it a bug) or not?
Thank you.

@Kcchouette Checking this issue.

@Kcchouette

...

...

Indeed, using col-sm-12 fix my problem. Thank you for the help @picturepan2


[Type system] Infer 'Any' for array elements and dictionary values an…

What's in this pull request?
This pull request implements a defaulting rule for the elements of array and dictionary literals.
The id-as-Any work regressed cases where Swift code could specify heterogeneous collection literals, e.g.,
    var states: [String: Any] = [
      "California": [
        "population": 37_000_000,
        "cities": ["Los Angeles", "San Diego", "San Jose"],
      ],
      "Oregon": [
        "population": 4_000_000,
        "cities": ["Portland", "Salem", "Eugene"],
      ]
    ]

Prior to this, the code worked (when Foundation was imported) because we'd end up with literals of type [NSObject : AnyObject].
The new defaulting rule says that the element type of an array literal and the key/value types of a dictionary literal can be defaulted if no stronger type can be inferred. The default type is:

Any, for the element type of an array literal or the value type of a dictionary literal, or
AnyHashable, for the key type of a dictionary literal.

The latter is intended to compose with implicit conversions to AnyHashable, so the most-general inferred dictionary type is [AnyHashable : Any] and will work for any plausible dictionary literal.
To prevent this inference from diluting types too greatly, we don't allow this inference in "top-level" expressions, e.g.,
  let d = ["a" : 1, "b" : "two"]

will produce an error because it's a heterogeneous dictionary literal at the top level. One should annotate this with, e.g.,
  let d = ["a" : 1, "b" : "two"] as [String : Any]

However, we do permit heterogeneous collections in nested positions, to support cases like the original motivating example.
Resolved bug number: (rdar://problem/27661580)

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

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

A smoke test on macOS does the following:

Builds the compiler incrementally.
Builds the standard library only for macOS. Simulator standard libraries and
device standard libraries are not built.
lldb is not built.
The test and validation-test targets are run only for macOS. The optimized
version of these tests are not run.

A smoke test on Linux does the following:

Builds the compiler incrementally.
Builds the standard library incrementally.
lldb is built incrementally.
The swift test and validation-test targets are run. The optimized version of these
tests are not run.
lldb is tested.

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

Lint Testing
    Language     | Comment
    ------------ | -------------
    Python       | @swift-ci Please Python lint

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

…d 'AnyHashable' for dictionary keys.
The id-as-Any work regressed cases where Swift code could specify
heterogeneous collection literals, e.g.,
var states: [String: Any] = [
  "California": [
    "population": 37_000_000,
    "cities": ["Los Angeles", "San Diego", "San Jose"],
  ],
  "Oregon": [
    "population": 4_000_000,
    "cities": ["Portland", "Salem", "Eugene"],
  ]
]

Prior to this, the code worked (when Foundation was imported) because
we'd end up with literals of type [NSObject : AnyObject].
The new defaulting rule says that the element type of an array literal
and the key/value types of a dictionary literal can be defaulted if no
stronger type can be inferred. The default type is:
Any, for the element type of an array literal or the value type of a
dictionary literal, or
AnyHashable, for the key type of a dictionary literal.
The latter is intended to compose with implicit conversions to
AnyHashable, so the most-general inferred dictionary type is
[AnyHashable : Any] and will work for any plausible dictionary
literal.
To prevent this inference from diluting types too greatly, we don't
allow this inference in "top-level" expressions, e.g.,
let d = ["a" : 1, "b" : "two"]
will produce an error because it's a heterogeneous dictionary literal
at the top level. One should annotate this with, e.g.,
let d = ["a" : 1, "b" : "two"] as [String : Any]
However, we do permit heterogeneous collections in nested positions,
to support cases like the original motivating example.
Fixes rdar://problem/27661580.

@swift-ci please test

@swift-ci please test

@rudkx can you review?

@DougGregor LGTM!

@swift-ci please test Linux

@swift-ci please smoke test and merge

Now that I've committed the basic 'meet' operation, this no longer regressions anywhere I've seen.

Grrrr. That Linux failure is the same LLDB issue that's been failing for 7 hours.


Add size limit report

Adds PR size report for lexical core, plain and rich text packages

Looking into failed "size" GH action, it seems like it tries to switch to main branch and run size limit as well which fails as we don't have it in main yet. So we probably will need to merge this PR to get proper size report

dangerJS

Don't see it anywhere


Add support for Django 3.1 and drop support for EOL 1.10-2.1

For https://github.com/groveco/django-sql-explorer/issues/392 and https://github.com/groveco/django-sql-explorer/issues/376.
Not sure if it closes those, there's also https://github.com/groveco/django-sql-explorer/pull/377 to check. At least the CI passes with 3.0 and 3.1!

@hugovk Sorry just seen this - I've caused you some conflict while I've been doing some release prep for a 2.0 bump.

Resolved!


Extends support for enum declarations

Feature Request 🛍
Add the ability to extend an existing enum declaration.
Use Case
namespace<EMAIL_ADDRESS>
enum VehicleStatus {
   o STARTED
   o STOPPED
}

concept Vehicle {
   o VehicleStatus status
}

And then...
namespace<EMAIL_ADDRESS>import {VehicleStatus} from<EMAIL_ADDRESS>
enum AcmeVehicleStatus extends VehicleStatus {
   o IDLING
}

A valid instance (IFF the<EMAIL_ADDRESS>namespace is imported into the model manager):
{
   "$class"<EMAIL_ADDRESS>   "status" : "IDLING"
}

Possible Solution
Allow enum declarations to be extended with new enum values.
Make properties of concepts that are enums "polymorphic" in the JSON validator: searching all enum declarations that extend the field type, and taking the union of all their values.
Context
User wants to extend the values of an enum without incrementing the model version of the concept that is using the enum declaration.
Detailed Description
Note that this does complicate namespace resolution, as the transitive closure of all models required by a namespace is now no longer explicit, even in strict mode. Before validating incoming JSON the model manager must be explicitly populated with all the namespaces that extend an enum declaration.

Are you proposing a Liskov substitution semantic, or is this just syntactic sugar for creating a new enum type that shares values with another type?

Closer to the former. The line
o VehicleStatus status

Is saying, "expect an enum value here, coming from the VehicleStatus enum declaration, or any enum declaration that extends VehicleStatus. We would have to add logic to enum declarations to check that they were not redeclaring enum values from a super type...

I'm having some déja vu!
https://github.com/accordproject/concerto/issues/291


ToDo list for logging

Meta issues:

[x] Log files need to have descriptive words in titles, e.g., the log file with activities should have ActivityLog in the file name (#3735)
[x] Old log files should be cleaned up (#3817)

Components/modules/things that need to be logged, in priority order:

[x] ActivityLog - new activities and final updates (#3732) (as of 1/4/2021, does not include: long running table ops, file share stats, blob emulator delete, etc.)
[x] Azure API requests and responses (#3733)
[ ] Information about new process startup (#3734)
[ ] LHS tree view expanding/collapsing
[ ] Changes to settings
[x] Changes to app state (window size, minimized, maximized, etc) [#4321]
[ ] ActivityLog - updates to activities
[x] Other Internal errors

If an issue does not exist as you work on something, please make it.
This issue should move to the next milestone until all work is done.

Closing this issue for now. I think we are done with it.


gmic{,-qt}: enable OpenCV, OpenMP (Clang) and X11

Description of changes
fixes #265966
Result of nixpkgs-review run on x86_64-linux 1

10 packages built:

ansel
darktable
gimp-with-plugins
gimpPlugins.gmic
gmic
gmic-qt
gmic.dev
gmic.lib
gmic.man
photoprism

Result of nixpkgs-review run on x86_64-darwin 1

7 packages built:

darktable
gimpPlugins.gmic
gmic
gmic-qt
gmic.dev
gmic.lib
gmic.man

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[x] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[x] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/2006


scroll-out in secondary console buffer pollutes main scrollback buffer

Windows Terminal version
1.22.240823002-preview
Windows build number
10.0.19045.4780
Other Software
No response
Steps to reproduce

Ensure there's some content at the scrollback of the (main) terminal buffer.
Run an application which creates a new buffer using CreateConsoleScreenBuffer and then activates it using SetConsoleActiveScreenBuffer.
The application writes some lines to the new buffer until it starts scrolling (more lines than the window height can keep visible).
The application switches back to the main buffer and exits.

Test program which: prints 100 lines to the main buffer, then creates and activates a new screen buffer, then writes 40 lines to the new buffer, then activates the original buffer and exits:

scrollbuf.c
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <windows.h>

#define writecon(h, s) WriteConsole(h, (s), strlen(s), 0, 0)
#define ERR_EXIT(...) (fprintf(stderr, __VA_ARGS__), exit(1), 0)

void write_n_lines(HANDLE h, const char* prefix, int n)
{
	char buf[64];

	for (int i = 1; i <= n; ++i) {
		writecon(h, prefix);
		sprintf(buf, "%d\n", i);
		writecon(h, buf);
	}
}

int main(int argc, char **argv)
{
	int mode = argc > 1 ? atoi(argv[1]) : 0;

	HANDLE hcon = GetStdHandle(STD_OUTPUT_HANDLE);
	if (hcon == INVALID_HANDLE_VALUE)
		ERR_EXIT("can't get stdout handle\n");

	if (!writecon(hcon, "orig screen buffer\n"))
		ERR_EXIT("can't write to stdout console\n");

	write_n_lines(hcon, "origbuf ", 100);

	HANDLE hnewbuf = CreateConsoleScreenBuffer(
		GENERIC_WRITE, FILE_SHARE_WRITE,
		0, CONSOLE_TEXTMODE_BUFFER, 0);

	if (hnewbuf == INVALID_HANDLE_VALUE)
		ERR_EXIT("can't create new screen buf\n");

	if (!SetConsoleActiveScreenBuffer(hnewbuf))
		ERR_EXIT("can't activete new screen buf\n");

	if (!writecon(hnewbuf, "new screen buffer\n"))
		ERR_EXIT("can't write to new screen buf\n");

	write_n_lines(hnewbuf, "newbuf ", 40);

	Sleep(1000);

	if (!SetConsoleActiveScreenBuffer(hcon))
		ERR_EXIT("can't restore orig screen buf\n");
	CloseHandle(hnewbuf);

	return 0;
}

Expected Behavior
The original scrollback buffer is restored without traces of content which was printed to the new/secondary console buffer.
Actual Behavior
Lines which were printed to the new (secondary) buffer buf were scrolled out of view become part of the scrollback of the main buffer.
With the test program above (which prints 40 lines to the secondary buffer), if the terminal height is less than 40, for instance 30 lines, then the first 10 lines printed to the secondary buffer will be added to the scrollback of the main buffer.
After the program exits, one needs to scroll up (e.g. using the mouse wheel) to ovserve the lines from the secondary buffer.
Additional notes:

This does not seem to be a recent regression. I reproduced it also with Windows Terminal 1.15 (the oldest version I have locally), 1.22-preview, and git master artifacts build from a day or two ago (with #17817 already fixed).
There is no issue in OpenConsole.exe and also no issue in the native win10 conhost (i.e. the main scrollback buffer is unaffected by overflow at the secondary buffer).

EDIT:
The issue manifests when using less.exe for windows in Windows terminal, e.g. less some-file.c and then scrolling down using the down-arrow, then after less exits then the scrollback buffer has content which was scrolled out-of-view in less (but no issue in OpenConsole or conhost).

The bot suggested #17669 might be similar, and it is similar, but not the same: #17669 is about the main buffer polluting the secondary buffer, while this is the other way around.
Also, this issue still exists, while #17669 is presumably already fixed.

No matter whether or how we fix it (pages perhaps? but that only works for WT), less should use the alternative screen buffer on Windows on versions that support it.

less should use the alternative screen buffer on Windows on versions that support it.

Maybe, but that's work that someone will have to do, and with more code paths which have to be maintained and tested, and while code which uses CreateConsoleScreenBuffer already exists and not supposed to be broken.
(similar *nix code which uses alt-screen does exist in less, but can't be shared easily with windows code because it uses terminfo db for the sequences etc, and it's also hacky because using alt-screen is not bullet-proof like SGR sequences)
I believe the micro text editor does the same without switching to the alt screen buffer using VT escape sequences, and I'm sure there are many existing application which might not be very actively maintained and which do use CreateConsoleScreenBuffer.

FWIW the less shipped by msys2 (e.g. git-for-windows) works correctly, because it uses cygwin and so it uses the alternate screen buffer.

Now sure what "only works for WT" means.

I wrote it as a comment targeted to the other maintainers. We received an implementation for VT pages a while ago (#16615). It allows you to have multiple "pages" (= similar to console buffers, but more limited) at the same time, instead of just the two usual ones (main and alt buffer). That would allow us to improve our CreateConsoleScreenBuffer translation. However, most terminals don't support these sequences AFAIK and so we cannot always use them. That's what I meant with "only works for WT".

Maybe, but that's work that someone will have to do, and with more code paths which have to be maintained and tested

To be fair, that's also true for us. But I understand that we should bear the burden here.
However, unlike less, etc., we cannot make the VT translation perfect. That's something I'll get into more detail below.

I believe the micro text editor does the same without switching to the alt screen buffer using VT escape sequences

Similarly, it would be nice if micro could switch over to using the alt buffer. Windows had support for it for about as long as micro has existed.

and I'm sure there are many existing application which might not be very actively maintained and which do use CreateConsoleScreenBuffer in order to keep the main buffer (and its scrollback) clean of temporary full-screen TUI content.

Such existing applications should be translated to VT to the absolute best of our abilities of course. It's not their fault that Windows changed its focus from the old console APIs over to VT sequences over the last decade. However...

...our abilities to do that translation are limited. There are multiple problems:

Pages are not necessarily supported by your favorite terminal (e.g. wezterm).
The number of pages is finite, while the number of console screen buffers is infinite.
Each console buffer can specify a buffer size (dwSize) on top of a window size (srWindow). I.e. the application can specify your scrollback size, not you. That's a concept that (mostly?) doesn't exist in the VT world (certainly not outside of VT pages).
Each console buffer may have different size. We can translate that to CSI t (resize window sequence) but that may be ignored by the hosting terminal. That's definitely true for Windows Terminal: we don't want to allow hidden tabs to randomly resize your window. If the resize is ignored, console applications often break, because they don't check if the size actually changed. CSI t also doesn't address the problem that console buffers may have a custom scrollback size.

But most importantly:
SetConsoleActiveScreenBuffer of a console buffer with existing contents is a lossy operation and some of your screen contents may be permanently lost, because we cannot know what custom VT sequences your favorite terminal supports so we cannot save them either. Since SetConsoleActiveScreenBuffer is used by less (and micro?) to switch back to the main buffer, this issue will always affect you when using these applications.
We're expected to support complex VT, complex Unicode, and complex console APIs simultaneously. But the only thing Windows historically supported was the latter, while the former two are obviously incompatible with that: CHAR_INFO does not support complex VT attributes nor Unicode, buffer read-back doesn't exist in the VT world, and SetConsoleActiveScreenBuffer cannot be cleanly translated to any VT. There's a conflict here and the saying "You can't have your cake and eat it too" comes to my mind.
The solution appears to introduce a VT sequence that represents CreateConsoleScreenBuffer and SetConsoleActiveScreenBuffer perfectly, but then we need to get that new sequence supported by other terminals, including those on Linux (so you can SSH into Windows). At that point the question is: Why should all terminals support the new sequence as opposed to terminal applications not using ReadConsoleOutput and SetConsoleActiveScreenBuffer anymore?
In any case, we'll always try to do our absolute best, and perhaps we can improve the symptoms of your issue. But I don't believe it's fair to expect us to make two completely conflicting technologies fit perfectly.

Yeah, I totally understand the main issue and that's console buffer has many features which don't have an equivalent in the unix terminal world, or not enough terminals support enough features to implement many of those in the VT world, so that it can be expected to work fully inside some 3rd part terminal emulator.
That being said, I'd guess one goal of the windows terminal is to provide an environment in which windows console application can behave as if they run in conhost, so I'd think that console screen buffer would need to work somehow, including many/most/all of its features which don't have an equivalent in the VT world.
That may or may not extend to arbitrary conpty clients, but obviously prefably it does extend.
Specifically though, "less" for windows uses the console buffer like alt screen. I.e. it doesn't use a custom size (it does set size, but copies it from the main buffer), and it doesn't do read-back (that I know of, but I think it doesn't), and VT alt-screen also doesn't spill scrolled-out content into the main buffer scrollback, so at least at this specific use case, I don't think it requires features which "normal" alt-screen doesn't have. I.e. I'd think that it could be exposed as normal alt-screen to conpty clients and it would work as expected.
Admittedly I don't know most of the specifics about implementation details with the windows terminal, but I'm now getting the impression that it's a pure VT (conpty) app, probably like other 3rd party windows VT terminals (wezterm, alacritty, etc) and which operates mainly or exclussively using VT sequences?
I understand the issues this approach poses, but also think there's a non-negligible need to support existing console apps which might not get updated to use the VT interface.
Maybe conhost/OpenConsole can identify that a console app uses some features which translate to VT sequences which are not commonly supported by 3rd party terminals, and issue a warning (once-ish per app) that 3rd party terminals might not be compatible with this application (while the windows terminal would support it via extended sequences which emulate the console buffer fully, etc).
It's not my place to suggest solutions here and I'm unaware of the constraints you work with, but I do think that at least the windows terminal should be a good environment for legacy console apps, even if they use features which translate to VT sequences which are not universally supported.
Isn't that right?

Does this await resolution?

That being said, I'd guess one goal of the windows terminal is to provide an environment in which windows console application can behave as if they run in conhost [...]

I fully agree with this, which is why I made the following plan: https://github.com/microsoft/terminal/blob/main/doc/specs/%2313000 - In-process ConPTY.md
That will need at least another year or so to be done though.

[...] but I'm now getting the impression that it's a pure VT (conpty) app, [...] which operates mainly or exclussively using VT sequences?

Yep, currently Windows Terminal operates exclusively via VT sequences. The above plan would change this: Windows Terminal would then be a native console server (like good old conhost), while we would still only use pure VT for windows applications run under WSL, as well as SSH and some other tools.
I think that approach has the best trade-off of being relatively easy to implement (by us and others), it's performant and robust. The only downside is that it'll take a while to get there.

I fully agree with this, which is why I made the following plan: https://github.com/microsoft/terminal/blob/main/doc/specs/%2313000 - In-process ConPTY.md
That will need at least another year or so to be done though.

Can't say I entirely or even mostly grok it, but out of curiosity, would that mean that the windows terminal would be a good env for "legacy" console apps, but those same apps would run less good in 3rd party terminal emulators, because those work exclussively via VT sequences, and then some APIs can't be translated well enough (like is the case now with the windows terminal)?
And specifically about this issue, does that mean that it won't be fixed until this transition is complete?
Because:

Specifically though, "less" for windows uses the console buffer like alt screen. I.e. it doesn't use a custom size (it does set size, but copies it from the main buffer), and it doesn't do read-back (that I know of, but I think it doesn't), and VT alt-screen also doesn't spill scrolled-out content into the main buffer scrollback, so at least at this specific use case, I don't think it requires features which "normal" alt-screen doesn't have. I.e. I'd think that it could be exposed as normal alt-screen to conpty clients and it would work as expected.

I'd imagine that console buffer would be implemented/exposed using alt-screen, and as such, the issue shouldn't exist, because content which scrolls out of the alt-screen doesn't normally pollute the main scrollback buffer in any *nix terminal, right?
IOW, I'd think that this specific issue, depending on implementation details, does not actually need this planned architechture change?

Can't say I entirely or even mostly grok it, but out of curiosity, would that mean that the windows terminal would be a good env for "legacy" console apps, but those same apps would run less good in 3rd party terminal emulators, because those work exclussively via VT sequences, and then some APIs can't be translated well enough (like is the case now with the windows terminal)?

No, because over SSH these apps will be broken in Windows Terminal just as before, just like they're broken in conhost right now. Further "no", because the linked proposal can be implemented by any other terminal - it's not a proposal specific to Windows Terminal. And lastly, if we were to introduce a new sequence for translating console screen buffers instead, it would still take years for any other terminal adopt it. Given other precedent, what's most likely is that no other terminal will ever adopt it.

And specifically about this issue, does that mean that it won't be fixed until this transition is complete?

Unfortunately, yes. As I outlined above, "pages" VT sequences aren't supported by other terminals and also don't perfectly map console buffers, so even if we were to use them, someone would likely soon find another bug with them. Custom VT sequences would similarly not be supported by other terminals. Lastly, implementing a solution with VT sequences now will take just as long to implement as implementing the linked proposal above, because Windows Terminal currently doesn't support more than 2 text buffers (outside of VT pages), etc.

I'd imagine that console buffer would be implemented/exposed using alt-screen, and as such, the issue shouldn't exist, because content which scrolls out of the alt-screen doesn't normally pollute the main scrollback buffer in any *nix terminal, right?

I don't want to do any such translations at the moment because they're "risky". Any edge cases around console buffer switching would need to be fixed by me. Since Windows has had supported for the xterm alt buffer for almost a decade now, I think it's instead on these still fully maintained applications to switch over to using the alt buffer.
I would understand it, if this issue was a major one (like a crash), but it's really more of a really annoying edge case, wouldn't you agree? Basically, I just don't want to invest 50% of the time now to get a quick hack in that solves 10% of the problem, when I can also just wait 100% of the time and fix the problem 100%.
Personally, I'm just kind of tired of using software that's a hundred quick hacks glued together under a single trench coat (I'm sure you can imagine a lot of examples, including from Microsoft). For now, I just want to write some quality software. I hope you understand. 🙁

if we were to introduce a new sequence for translating console screen buffers instead, it would still take years for any other terminal adopt it. Given other precedent, what's most likely is that no other terminal will ever adopt it.

We're guessing, but my guess would be the same as yours.

Unfortunately, yes. As I outlined above, "pages" VT sequences aren't supported by other terminals and also don't perfectly map console buffers, so even if we were to use them, someone would likely soon find another bug with them. Custom VT sequences would similarly not be supported by other terminals.

I agree. I don't think solving it with custom or uncommon sequences is great.

I'd imagine that console buffer would be implemented/exposed using alt-screen, and as such, the issue shouldn't exist,

I don't want to do any such translations at the moment because they're "risky". Any edge cases around console buffer switching would need to be fixed by me. Since Windows has had supported for the xterm alt buffer for almost a decade now, I think it's instead on these still fully maintained applications to switch over to using the alt buffer.

Well, I was guessing that console buffers are already getting translated to alt-screen, and if that were the case then I thought the issue shouldn't exist already currently, but judging by this statement, that's not the case.
May I ask what happens currently, implementation-wise (but high level), which causes text which scrolls out of a (non-main) screen buffer to reach the terminal's scrollback?

I would understand it, if this issue was a major one (like a crash), but it's really more of a really annoying edge case, wouldn't you agree?

I do agree, but for me it's annoying enough to get back to conhost or openconsole, because I do use "less" a lot, and I do value my scrollback history, but if everytime I use "less" it adds pages of junk to my scrollback, then it will be too annoying.
(or I might implement alt-screen in "less" when VT is supported, because I already contribute to "less", but that's orthogonal to the issue here IMO)
In fact, I already did just that for a long while (using OpenConsole rather than windows terminal), and tried to get back to the terminal recently, and noticed some console buffer issues.
Believe it or not, my main issue with OpenConsole is that shift-mouse-select is unsupported (when quick-edit is disabled, e.g. because the application wants to capture mouse events). Other than that OpenConsole is quite great for me (though I do value the nice features of Windows Terminal too, but for me they're more nice to have than essential, maybe except scrollback search which is very useful).
Shall I open a feature request to support shift-mouse-select in OpenConsole to override disabled-quickedit?

Personally, I'm just kind of tired of using software that's a hundred quick hacks glued together

Completely agreed, though many times unavoidable in practice, because such is life. But if you do get the chance to avoid yet another hack, without great cost, I agree you should.

I just want to write some quality software

Not doing too bad so far, if I may say so.

I suspect #17949 is a dupe of this.?

Well, I was guessing that console buffers are already getting translated to alt-screen, and if that were the case then I thought the issue shouldn't exist already currently, but judging by this statement, that's not the case.

Yeah exactly. As I said, I objectively don't think we should try to map it to the alt-screen as it's high risk with low reward, in particular if there's a perfect solution available (the in-process ConPTY spec linked above).

May I ask what happens currently, implementation-wise (but high level), which causes text which scrolls out of a (non-main) screen buffer to reach the terminal's scrollback?

Since Windows Terminal is currently a pure VT terminal (like on UNIX), it doesn't have "console screen buffers". As a consequence, if you use SetConsoleActiveScreenBuffer, you never leave Windows Terminal's main screen either. Instead, ConPTY (the Console API --> VT translation layer) writes the new console screen buffer contents straight to the main buffer of Windows Terminal. When you switch back to your original console screen buffer it again writes the original's contents to Windows Terminal's main buffer. This gives the impression as if you had multiple console buffers in Windows Terminal, but in reality, it's ConPTY which turns the contents to pure VT.
So, when you change the font size, etc., you zoom the entire contents of Windows Terminal's main buffer including scrollback and that breaks the illusion.
Or, as with your issue, when you scroll in less it assumes that it's in the alternate screen buffer without scrollback. It then writes more text than fits on the screen, but Windows Terminal is not in the alternate screen buffer and so it writes to the scrollback accidentally.

Shall I open a feature request to support shift-mouse-select in OpenConsole to override disabled-quickedit?

Please do!
The console API supports reporting shift when mouse input is enabled: https://learn.microsoft.com/en-us/windows/console/mouse-event-record-str
So, to not conflict with that, I think we'll have to check whether ENABLE_MOUSE_INPUT is set. Otherwise, I think we should be able to support that. 🙂

I suspect https://github.com/microsoft/terminal/issues/17949 is a dupe of this.?

It's not strictly related. 🙂 Let's continue talking about your issue over there.

if you use SetConsoleActiveScreenBuffer, you never leave Windows Terminal's main screen either. Instead, ConPTY (the Console API --> VT translation layer) writes the new console screen buffer contents straight to the main buffer of Windows Terminal. When you switch back to your original console screen buffer it again writes the original's contents to Windows Terminal's main buffer. This gives the impression as if you had multiple console buffers in Windows Terminal, but in reality, it's ConPTY which turns the contents to pure VT.

Thanks. This indeed explains why this issue happens.

Shall I open a feature request to support shift-mouse-select in OpenConsole to override disabled-quickedit?

Please do! The console API supports reporting shift when mouse input is enabled: https://learn.microsoft.com/en-us/windows/console/mouse-event-record-str So, to not conflict with that, I think we'll have to check whether ENABLE_MOUSE_INPUT is set. Otherwise, I think we should be able to support that. 🙂

Unfortunately, the case where shift-mouse-select is required for override is exactly when ENABLE_MOUSE_INPUT is set (where the app also disables quick-edit, because otherwise some mouse events don't reach the app), but in windows terminal shift-mouse-select seem to work also in this specific case - which is what I hoped would be possible to do with OpenConsole as well. But this is off topic for this issue. I'll open a feature request (not sure when) and let's see there.
Thanks for the info.

Other than maybe performance issues, and assuming this is not too hard to do, and that I roughly get the kinds of translations which happen under the hood, would these translations of "scroll in non-main console buffer due to print when cursor is in bottom-right" work?
Two suggesitons when such scroll is identified:

cursor to top-left, print the content of 2nd line, 3rd line... last line (so it looks like it scrolled, but it shouldn't enter the scrollback), clear the bottom line, cursor to bottom-left. This probably requires more bandwidth than we want, but maybe it's OK, and it's simple.
cursor to top-left, print the content of 2nd line (so the first two lines just got "scrolled", but without affecting the scrollback), set scrolling region from line 2 (CSI 2 r), scroll one line (CSI S) - (scrolls 3rd...last lines, and the bottom line should be cleared by the scroll), restore default scrolling region, cursor to bottom left.

Am I roughly in the ballpark of how these VT translations work and what they're capable of?
Should that work if someone implemented it?

Am I roughly in the ballpark of how these VT translations work and what they're capable of?

Doesn't less enable ENABLE_VIRTUAL_TERMINAL_PROCESSING? So, it'd be more like a VT -> VT translation, if anything. We can influence that, but certainly not accurately. For regular console APIs (without VT processing being enabled), we can do almost arbitrary translations, like those you mentioned.

Doesn't less enable ENABLE_VIRTUAL_TERMINAL_PROCESSING?

It does, but it's not used normally. By default the console API is used (SetConsoleTextAttribute, SetConsoleCursorPosition, etc). VT would get used if the internal "VT to Console API translation" layer doesn't identify the escape sequence (and the console supports VT mode), like currently with 256/true colors sequences, or if the user uses a flag to bypass the internal translation and passthrough everything to the console - -Da (and it supports VT). But it's still not used for positioning - only for SGR sequences and maybe OSC 8. Other console control don't go through this internal traslation layer. This mixed VT/Console API does work with conhost/openconsole.
However, while I initially observed the issue with "less", and it would be nice to get conhost behavior of "less" work correctly also at the Terminal, the goal of this issue was to improve the behavior of the terminal with application which use conhost, and specifically to not pollute the main scrollback buffer when a non-main console screen buffer scrolls content out of view.
Initially you said that it might require missing/uncommon features which most terminals don't support, and we agree it won't be a great solution, but now I suggested a translation which I think should work in all terminals, and which is hopefully not too hard to implement (identify the trigger, translate it accordingly).

So, it'd be more like a VT -> VT translation, if anything. We can influence that, but certainly not accurately

Implementation wise, I clearly don't know the details, but I would have guessed that it wouldn't matter (much), because if the non-main screen buffer is about to get scrolled, does it matter whether the trigger was WriteConsole or some normal print in VT mode? (of normal text, or whatever). Both end up scrolling the console buffer, and that's the event which should be identified ideally - not the source which caused it. Am I wrong? (at least theoretically, but practical considerations do have a way to make it different than theory...)
I get that apps which use mixed Console/VT API may be harder to translate, but let's start with Console API, and hopefully VT input would still mostly work like it does with conhost?

Implementation wise, I clearly don't know the details

But you do! mind pointing me to the file[s] where this translation to VT happens? I don't mind giving it a look, maybe I can grasp something (for curiosity).

Initially you said that it might require missing/uncommon features which most terminals don't support, and we agree it won't be a great solution, but now I suggested a translation which I think should work in all terminals, and which is hopefully not too hard to implement (identify the trigger, translate it accordingly).

I also mentioned before that the reason for needing the missing features is because such a translation is excessively difficult. I'll not implement such a translation within the current ConPTY architecture for the aforementioned reasons.

Implementation wise, I clearly don't know the details, but I would have guessed that it wouldn't matter (much), because if the non-main screen buffer is about to get scrolled, does it matter whether the trigger was WriteConsole or some normal print in VT mode?

WriteConsole can be used with VT mode, but I know what you meant. We currently don't do VT -> VT translation at all. Since less uses both console APIs and VT simultaneously, emulating it correctly would require us to parse and translate not just all console APIs but in addition also all VT sequences. This would not just be similar but identical to implementing tmux within ConPTY - a very complex project. There are also no shortcuts when correctness is the goal. Just imagine for instance how sixels would need to be implemented in such a setting. It would take years upon years of my life to sand away on the edge cases that this would cause. I have to outright tell you that I'd not spend time on this myself, even if I was asked to do at the threat of being fired. That's how much I think this would be a mistake, in the most objective way.
The correct approach is the previously mentioned in-process ConPTY. It'll be easier to implement, easier to maintain, and be more correct.
The relevant VT translation functions are here: https://github.com/microsoft/terminal/blob/4386bf07fd65f763693132ee5e4c43a2a571dc76/src/host/VtIo.hpp#L32-L47
You can find the implementation and the .cpp file and their usage throughout the project.

Thanks for the lively discussion here! We're not going to be investing in fixing this with VT, but with the new ConPTY architecture. Feel free to continue discussing, but I'm going to close this issue as it's not currently actionable for us.

If it makes it any better, I'm planning to work on the new architecture early next year. This will fix the issue for Windows Terminal and under most circumstances. I'll also work on bringing this to other terminals.


Bump all IdentityModel nuget packages to 5.2.0 for next release

Users seem confused by the versioning (I know I am).
M.IM.Logging 1.x
M.IM.Protocols 2.x
M.IM.Tokens 5.x
For the next release bump them all to 5.2.0.
@PinpointTownes @leastprivilege @Tratcher @brockallen  OK?

Yes please

@brentschmaltz assuming there's no breaking change, yeah, that's fine.

committed into wsfed topic branch


RedissonSpringCacheManager creates new cache on  each getCache call

Currently RedissonSpringCacheManager creates new cache on each getCache call. But it should reuse existing caches if there are. Otherwise, Spring cache interceptor retrieves new cache at each time.
This behaviour can be implemented by just extending from  org.springframework.cache.support.AbstractCacheManager and overriding getMissingCache method as implemented in current getCache method.

Done


Allow html in labels

Fixes #817

This doesn't allow html in buttons - if we want to do that, let's make a different ticket?

Html in buttons are a good way to give the opportunity to break layout and all. I am not sure this is a good idea.

I am not sure this is a good idea.

html in labels, or buttons, or both?

Buttons would be more dangerous than labels.


Fixes for Vagrantfile to be able to launch from Windows machine

Hi, I added a fix to the Vagrantfile, so I can build and run blockade from Windows.
I also updated docs. Merge it if you like the changes.

This actually breaks vagrant on linux now, since tox is run in the homedir instead of /vagrant. But that's an easy fix. I'll merge and follow up with my own commit.
Thanks for the contribution! I wasn't able to try it on windows, but I'll try to be careful to preserve your changes across future tweaks the the vagrantfile.


fix: prevent command prompts pop-ups in Windows

In some instances (like running nexrender-workers with pm2), a command prompt (cmd.exe) window would pop-up every time an external process was spawned (like aerender or ffmpeg).
To, workaround this problem (which can be quite annoying), I've added the windowsHide parameter to all the spawn calls. This will:

Hide the subprocess console window that would normally be created on Windows systems

(Source)
Related: Unitech/pm2#2182

Thanks for the cool fix @abhineet97! 🎉


fix playlist resolving collectionurls

Fixes
Issue Number: fixes #7122

What is the current behavior?
Currently previews do not show up when hovering over a playlist thumbnail untill you open     it up and then go back.
What is the new behavior?
Now previews do show up without having to open the playlist.
Other information

PR Checklist

Toggle...
What kind of change does this PR introduce?

[X] Bugfix
[ ] Feature
[ ] Code style update (formatting)
[ ] Refactoring (no functional changes)
[ ] Documentation changes
[ ] Other - Please describe:

Please check all that apply to this PR using "x":

[X] I have checked that this PR is not a duplicate of an existing PR (open, closed or me    rged)
[X] I added a line describing my change to CHANGELOG.md
[X] I have checked that this PR does not introduce a breaking change
[ ] This PR introduces breaking changes and I have provided a detailed explanation below

Hey @bradley-ray , nice to see you contributing to this repo also! We'll get a review on this soon.
Similar to last time, can we show you some appreciation?


AMBARI-23105. Exception caught while installing Timeline Service V2.0

Workaround solution for below issue. The jira to solve this properly will be created. Since this blocks us badly. For now the workaround gonna be committed

Caught an exception while executing custom service command: <type 'exceptions.Exception'>: Command requires configs with timestamp=1519782088331 but configs on agent have timestamp=1519783511993; Command requires configs with timestamp=1519782088331 but configs on agent have timestamp=1519783511993

Second issue:

File "/usr/lib/ambari-agent/lib/resource_management/libraries/functions/namenode_ha_utils.py", line 178, in get_property_for_active_namenode
name_service = name_services(hdfs_site)[0]
TypeError: 'list' object is not callable

Since this blocks CI. I ran tests manually and made sure it works. So committing with this without jenkins results. To move on CI quicker

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/859/
Test FAILed.
Test FAILured.


Parsing Input/Output Coorelation

In the meeting ~1 week ago, we discussed this problem:
The parsing image takes in a folder (containing potentially multiple files), and parses into (potentially multiple) output portfolios. This means we don't have (a) a mapping between input files + output portfolios, and (b) we lack a good name for the output portfolios.
Ideally, alongside the output portfolios, the parsing image would create a JSON file (or similar) with a structure like:
[
  {
     "output_portfolio_file_name": "uuid-1.txt",
     "number_of_elements": 123, // Or something similar + nonsensitive to help distinguish at a glance.
     "portfolio_name": "the name of the portfolio from the file"
      "input_file_name": "path_of_file_derived_from.txt"
   } ...
]

@AlexAxthelm Could you add something like this to the parsing image? Without it we're stuck naming portfolios UUIDs, which is not ideal from the user's perspective.

Oh yeah 100% agree that this should be within the image. I don't want multiple systems parsing the file (and potentially with differing results). My point was more that this logic should be used for all files/portfolios, not just the ones that have multiple portfolios in one file.

OK great - same page.

FYI, the Portfolio.Name column is/should be optional. It is only there to facilitate multi-portfolio CSVs.

Hodie, that all sounds good to me - we have a strongly unique ID that we assign during upload that is opaque to the user and globally unique, and then we have the user-settable (and user changeable) portfolio name. Our system will almost exclusively deal with the ID, but the UI will almost exclusively use the Name.
It also sounds like we're on the same page w/r/t initial naming: if there are multiple portfolio_names in a file, use that. If there are no portfolio_names in a file use the file name sans extension.
@AlexAxthelm @cjyetman Could y'all work on providing us with that mapping when you get the chance? Once we have that we'll have the portfolio upload + parsing + standardization process done.

@gbdubs for the metadata JSON, I'm running into a few issues that are proving thornier than expected.
(cc @cjyetman)
Issue 1: undefined portfolio names
Portfolios may not have a "portfolio name" defined in the file, or there may be multiple (logical) portfolios that have the same name. In these cases, I can create a portfolio name based on the file name, but I don't know if that's necessarily the way we want to go (cc @hodie).
For example
Example 1
"isin","market_value","currency"
"GB0007980591",10000,"USD"

if this was foo.csv, then we would get <uuid>.csv out, and the json would would be something like
[{
  "portfolio_name": "foo"
  ...
}]

Example 2
Investor.Name,Portfolio.Name,ISIN,MarketValue,Currency
Investor A,Portfolio A,GB0007980591,10000,USD
Investor B,Portfolio A,GB0007980591,10000,USD

if this was foo.csv, then we would get <uuid>.csv out, and the json would would be something like
[
  {
    "portfolio_name": "Portfolio A - Investor A"
    ...
  },
  {
    "portfolio_name": "Portfolio A - Investor B"
    ...
  }
]

this one is probably okay, but I feel a little weird putting the investor name in the portfolio name field (I might be a bit paranoid on this though). Another option would be to do simple sequencing (foo-1, foo-2), but that makes it difficult/impossible to tie back to the original contents (which is both the point and the problem).
Issue 2: JSON structure
Looking at the JSON sample you provided above, it looks like your working assumption is something along the lines of
[
  {exported-portfolio-1},
  {exported-portfolio-2},
  {exported-portfolio-3},
  ...
]

Would it be okay to change the top-level structure to center the input files as the grain? My thinking here is that in the case of an export failure, we can add diagnostic messages for the user, even though there isn't a exported portfolio.
Format 1:
[
  {
    "input_filename": "1.csv",
    "output_files": [
      {portfolio-1},
      {portfolio-2}
    ]
  },
{
    "input_filename": "2.csv",
    "output_files": [
      {portfolio-3},
    ],
    "warnings": [
      "extra column 'notes' detected. This information will not be available in PACTA"
    ]
  },
  {
    "input_filename": "3.csv",
    "output_files": [],
    "errors": [
      "Required column 'ISIN' not found.",
      "No holdings data found in file"
    ]
  },
]

Format 2: Separate files
Alternately, we could have a portfolios.json file with the metadata for exported portfolios, and then a messages.json that has all the info about failed exports
Issue 3: Non-unique portfolio names
Since the parser that I'm writing is stateless, there isn't a way to check if a user has already created a portfolio with that name before. Example here is uploading a portfolio with some name, and then 6 months later uploading a file with the same name (same or different contents). Do we have a way in the UI for the user to distinguish between them?

Sorry Alex, I clearly missed your last post somehow. I think we're now on the same page as of the doc we just talked about yesterday. Does that match your understanding? Can we close this out?

Example 2
Investor.Name,Portfolio.Name,ISIN,MarketValue,Currency
Investor A,Portfolio A,GB0007980591,10000,USD
Investor B,Portfolio A,GB0007980591,10000,USD

if this was foo.csv, then we would get <uuid>.csv out, and the json would would be something like
[
  {
    "portfolio_name": "Portfolio A - Investor A"
    ...
  },
  {
    "portfolio_name": "Portfolio A - Investor B"
    ...
  }
]

this one is probably okay, but I feel a little weird putting the investor name in the portfolio name field (I might be a bit paranoid on this though). Another option would be to do simple sequencing (foo-1, foo-2), but that makes it difficult/impossible to tie back to the original contents (which is both the point and the problem).

I know I'm late to the party, but... the Investor.Name/investor_name column is/should be optional too. It's not used by the PACTA code at all, it's a holdover from former times.
Additionally, I can't think of any use case where a multi-portfolio run would have different Investor.Name/investor_name values, at least not in the way it was ever intended to work on the web app. Investor.Name effectively equals .

@cjyetman I think this is a discussion for another repo, but in the 3/5 column layouts, that's accurate. If we accept 4 column portfolios, then the 4th column could be either investor name or portfolio name. It's not hard to imagine a situation where someone working as an outside analyst would have multiple portfolios from different investors.
In any case, workflow.portfolio.parsing writes the 3-column version to csv, and the investor and portfolio names are captured in the metadata json alongside.


Move CryptoFactory from SrverHandshake to FizzServerHandshake

This is moving some fizz specific part of the server handshake in FizzServerHandshake, following a similar pattern as what was done for the client.
Depends on #161 and #160

This one seems containing some duplicates from #160 ?

@yangchi This is stacked on top of #160 and #161 . Unfortunately, github really suck at stacked diffs and will show you the whole thing by default.

lgtm

#160 and #161 are closed. I think this is ready for a proper rebase.

Rebased


config.yml for multi db

Hey there,
This is pretty cool. I intended to write something like this but you already have done a great job 👍
How about configuration? Something like config.yml would be great.

Thanks, I'm glad you liked it!
Are you thinking about having different connection URLs per environment (test, development, production)?
If that's the case, my first impression is that those environments are something your application should know about, but probably not this tool. If we had a micrate-specific configuration file then any app that uses micrate should do one of the following:

Duplicate that configuration to set up their database for normal app usage
Be forced to read it's DB configuration from micrate's file

In that case I believe it's probably better to have your application be configured any way you want, and have it set up micrate doing something like this:
# You could let the user configure your API any way you want
Micrate::DB.connection_url = MyApp::Settings.database_url

# Run CLI
Micrate::Cli.run

# OR use programatic API
Micrate::DB.connect do |db|
  Micrate.up(db)
end

I think this gives apps/frameworks that use this tool more flexibility. Am I missing something?
Are you thinking about a specific setting that cannot be expressed in the connection URL?

At second thought, you are right 👍
It's applications' responsibility to know about the environment and not Micrate.


Auto Imports not working correctly on Linux

VSCode Version: 1.34.0-insider
OS Version: Manjaro 18.0.4

Tested on Stable + Insiders on Manjaro. Works fine on Windows
Steps to Reproduce:

Install an npm package in a TypeScript project (both Windows and Manjaro)
Try to auto-import something from that package on Windows. It will work.
Try to auto-import something from that package on Manjaro. It will not show up.

Note: Almost every Angular module/directive is not shown in the IntelliSense menu, along with rxjs, fs-extra, etc. It does appear that auto-importing built-in node modules like fs work fine.

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

April 27 5pm: Testing to see if this is an issue in Ubuntu as well

Closing because this seems to be an issue only on my system.


How to use with others directives?

Do you have any idea how to use with vee-validator?
<masked-input type="text" v-model="birth_date" mask="11/11/1111" v-validate data-vv-rules="required" />

Tested your code, works fine for me. What do you mean by "how to use"?

if you use {{ errors.has('birth_date') }} for example in your code, the Errors objects return undefined.

In your code returns undefined? thanks for support ;)

Well, the problem is on the vee-validate's side. Vee-validate gonna work like that even if you use it with super basic custom input component like this one:
<template>
  <input ref="input"
    :value="value"
    @input="$emit('input', $refs.input.value)"
  />
</template>

<script>
export default {
  name: 'MaskedInput',
  props: {
    value: {
      type: String
    }
  }

}
</script>

So that's not possible to fix inside the package.


\p{Sc} fails to compile

What version of regex are you using?
1.7.1
Describe the bug at a high level.
The syntax of regex seems to follow the ECMAScript spec. Upon checking, I noticed that 3 General Categories are not supported that work in other regex engines:

Surrogate
Cs (abbreviation for Surrogate)
Sc (abbreviation for Currency_Symbol)

But while the lack of support for Surrogate may be intentional, \p{Sc} should work, and does work when not abbreviated. It also works when prefixed with gc= or General_Category=:

Regex
compiles?

\p{Currency_Symbol}
yes

\p{Sc}
no

\p{gc=Sc}
yes

\p{GC=Sc}
yes

\p{General_Category=Sc}
yes

This bug might be related to the Script/sc property (e.g. \p{sc=Greek}), which happens to have the same abbreviation as the Currency_Symbol General Category.
I noticed that Unicode properties are case insensitive in regex, which is in violation of the ECMAScript spec. But since changing it would be a breaking change, it's probably not worth it.
What are the steps to reproduce the behavior?
Try to compile \p{Sc}
What is the actual behavior?
error: regex parse error:
    \p{Sc}
    ^^^^^^
error: Unicode property not found

What is the expected behavior?
It should work.

Thanks for the report. This is a duplicate of #835, although that's only about the Sc abbreviation. I have it fixed in some ongoing work that I hope to get merge at some point soon.
With respect to Surrogate, it is excluded explicitly. The regex crate only supports Unicode scalar values, which correspond precisely to the subset of all codepoints that exclude the surrogate codepoints. The reason for doing that is that surrogate codepoints are unrepresentable in UTF-8, and this crate only supports UTF-8. Since regex compilation converts Unicode classes into UTF-8 automata and since surrogate codepoints cannot be encoded in UTF-8, there is no way to proceed there. Either classes that contain surrogates should fail to compile, or they would otherwise have to be silently removed. The regex crate chooses the former behavior.
Popping up a level, what are you hoping to achieve with the \p{Surrogate} class?

The syntax of regex seems to follow the ECMAScript spec.

Could you please say what you gave that impression? I'd love to fix it, because it is most certainly not true.

I noticed that Unicode properties are case insensitive in regex, which is in violation of the ECMAScript spec. But since changing it would be a breaking change, it's probably not worth it.

Again, this is intentional and it is even explicitly documented in the Unicode support documentation:

In all cases, property name and value abbreviations are supported, and all names/values are matched loosely without regard for case, whitespace or underscores.

Indeed, it is actually ECMAScript that does not follow UTS #18.

With respect to Surrogate, it is excluded explicitly

That is what I assumed, and it makes perfect sense since a surrogate is not a Unicode scalar value. I just noticed it because I iterated over all General Categories to see which are supported by regex.

Popping up a level, what are you hoping to achieve with the \p{Surrogate} class?

Nothing. I just needed to know which properties are supported, so I can emit an error in Pomsky when an unsupported property is used.

The syntax of regex seems to follow the ECMAScript spec.

Could you please say what you gave that impression?

The syntax just looks similar, but upon second thought there aren't that many similarities. I think what animated this statement was my realization that Rust and ECMAScript support almost the same set of Unicode properties and use the same syntax to match them.

The syntax just looks similar, but upon second thought there aren't that many similarities.

Ah yeah, most regex flavors are quite similar, but can diverge in interesting and surprising ways. Some are definitely more similar than others.

I think what animated this statement was my realization that Rust and ECMAScript support almost the same set of Unicode properties and use the same syntax to match them.

Yeah, the key there is the common inspiration: UTS#18.

I'm going to close this because I think the Surrogate question is answered, and the Sc bug is tracked by another ticket and should be resolved soon.

@BurntSushi I found another one: \p{LC} doesn't work, but \p{gc=LC} does. Not sure how I missed this before. LC (short for Cased_Letter) combines Uppercase_Letter, Lowercase_Letter and Titlecase_Letter.

Nice find! I have a fix incoming for that now too. The main issue is that lc is an abbreviation for both Cased_Letter and Lowercase_Mapping. Since we don't support the latter (but it is in the regex's Unicode table of property name aliases), I added a manual case for it to be mapped to Cased_Letter. (Just like I've done for cf and sc.)


Response must use 4xx status code when sent because of decoding error

Motivation:
A 4xx status code must be used when sending a response caused because of an decoding error: https://www.ietf.org/archive/id/draft-ietf-ohai-ohttp-10.html#section-5.2
Modifications:
Use a 4xx status code when exception is caused because of decoding
Result:
Follow the spec

/cc @thomdev


Problems writing after NS 6 + NS-BLE Beta update

Hello, I would like some help regarding the write() function.
It worked awesomely right before updating to NS6 and the nativescript-bluetooth@beta but now I am getting this error:
JS: write error: { JS:   "msg": "error_function_call", JS:   "method": "write", JS:   "status": 138, JS:   "args": { JS:     "peripheralUUID": "D0:CF:5E:1B:B0:76", JS:     "serviceUUID": "d8b5a80c-17c5-11e8-b642-0ed5f89f718b", JS:     "characteristicUUID": "d8b5aa1e-17c5-11e8-b642-0ed5f89f718b", JS:     "value": "0x05" JS:   } JS: }
I double checked everything and seems like the call is broken on the framework or something. What does the status 138 mean?
Best

@AsgerCode Using the beta sending "0x05" wont work anymore. Just send 0x05
Now for your error. I suppore you are on andoird ? (please always mention all versions you are using...) It seems 138 is GATT_MORE which is an undocumented error...
Maybe sending the value in the right format will be enough.

@farfromrefug Thanks for clearing that up. A few calls are now working as intended. Yes I am developing for Android.


[Polkadot] Staking message fix

it's changed once after our integration

Staking msg tests updated, created valid messages  #1265 .

Staking msg tests updated, created valid messages  #1265 .


Add English comments

The comments in the code are in German unlike the English README, please add English comments either with or replacing the German comments

the code is not online yet :open_mouth: You mean assembly, right?

the code is not online yet 😮 You mean assembly, right?

Oh, I was looking for the paths and code, but the assembly files have comments in German, as I respect other languages, you can keep them if it’s easier for you, but adding translations in English should let other programmers understand due to being the lingua franca of programming, the internet, and Earth itself.


Misplaced space(s) around '=' sign.

If the '=' is in a string it should not be detected as a coding style error.

Unfortunately NormEZ doesn't use a real parser and instead checks for coding style mistakes with a regex parser. Without an advanced parser, NormEZ can't accurately make the difference between strings/comments & code.


Fixed error because system used comma as decimal separator and z1 was…

… used to measure point instead of z2

Nice catch on the Z1 vs. Z2 (and feed speed) thing.  Those differences were from the earliest prototyping code (when I was adding G-code nearly at random 😄 ) and I don't have a strong reason for preferring one over the other.  Unifying them sounds good.
For the decimal separator, this is a partial fix that breaks some cases and fixes others... but on the whole it should fix more than it breaks.
The issue is that the printer's firmware has its own decimal separator preference separate from the host OS.  I've already heard from a user with a Polish version of Windows (comma separator) but an English printer firmware (dot separator).  Hopefully those cases are rarer than matched separators, but the longer-term answer is to offer an option in the UI, perhaps trying to auto-detect first so the user doesn't have to worry about it unless we get it wrong.
I haven't taken the time to think it through, but my gut reaction is that this line creeps me out because we've got decimal separators in very close proximity to list separators.  I'd have to sit down and try a few combinations to convince myself it's fine, but if it's working on your side--I don't have access to a non-comma decimal separator OS or printer firmware--I'll take it on faith for now.
Nice work!

Yeah, kind of naive implementation. My problem was as you describe that my system use comma as decimal separator (Sweden) while printer firmware is in English and uses dot as decimal separator. Solution totally misses if the firmware does not use dot as a comma separator. So not a complete solution but thought it would be a waste to just throw it away ;)


Impossible to assign object ref to Formik's innerRef - v2.1.2 regression

🐛 Bug report
Current Behavior
It's not possible to assign object ref (created with useRef) to innerRef property of Formik. I need this to be able to trigger submit outside of the formik, without creating wrappers that translate object ref to functional ref.
Expected behavior
innerRef should accept both functional and object-based refs.
Reproducible example
https://codesandbox.io/s/formik-inner-ref-vr0fi
Type 'MutableRefObject<FormModel | undefined>' is not assignable to type '((instance: any) => void) & MutableRefObject<FormModel | undefined>'.
  Type 'MutableRefObject<FormModel | undefined>' is not assignable to type '(instance: any) => void'.
    Type 'MutableRefObject<FormModel | undefined>' provides no match for the signature '(instance: any): void'

Suggested solution(s)
Formik should accept React.Ref<FormikProps<T> | undefined>?
Additional context
Regression was introduced in 2.1.2 - you can play around with version in the sandbox
Your environment

Software
Version(s)

Formik
2.1.4

React
16.13.1

TypeScript
3.9.6

Browser
Edge

npm/Yarn
yarn

Operating System
Ubuntu 20.04 @ WSLv1

Same here, I solved it adding as any after useRef :
  const formRef = useRef<FormikValues>() as any;
I know it's not a good way to solve the problem, but it actually works.

I wouldn't say it solves the problem, you're basically opting out from type checks completely.
Instead, you can wrap object ref to a functional one, to maintain type safety.
But the fact is that library's types are broken

This type is incorrect:
const ref = React.useRef<FormModel>();

Formik's ref accepts a type of FormikProps<FormModel>. Additionally, React's own typing between a ref used for an element and useRef (used for any value) is different in that createRef requires a null value rather than an undefined value whereas useRef accepts undefined or null or any other value. Therefore, when you do React.useRef<FormikProps<FormModel>>();, the actual type of this ends up being a ref of FormikProps<FormModel> | undefined" which is not compatible with an element ref which must be FormikProps<FormModel> | null. This is easily solved by passing null as the instantiator to your useRef:
// works fine
React.useRef<FormikProps<FormModel>>(null);

https://codesandbox.io/s/formik-inner-ref-forked-11ygj?file=/src/App.tsx

I added a few elements to my codesandbox above to show this is not a Formik issue and a useRef without null will always cause an error in React.


Cannot pass yaml as --data cli argument

Describe the problem
I am trying to pass a list as a --data cli argument while generating the project like:
copier --force --data 'layers=[data, domain]' --vcs-ref HEAD copy <my template dir> <my target dir>

Within the copier.yaml file the layers question is defined as follows:
layers:
  type: yaml
  help: Which layers do you need?
  default: [data, domain]
  choices:
    data & domain: [data, domain]
    data: [data]

To Reproduce

Run copier --force --data 'layers=[data, domain]' --vcs-ref HEAD copy <my template dir> <my target dir>
See error

Logs

```
Traceback (most recent call last):
  File "/usr/local/bin/copier", line 8, in
    sys.exit(copier_app_run())
  File "/usr/local/lib/python3.10/site-packages/plumbum/cli/application.py", line 639, in run
    inst, retcode = subapp.run(argv, exit=False)
  File "/usr/local/lib/python3.10/site-packages/plumbum/cli/application.py", line 634, in run
    retcode = inst.main(*tailargs)
  File "/usr/local/lib/python3.10/site-packages/copier/cli.py", line 68, in _wrapper
    return method(*args, **kwargs)
  File "/usr/local/lib/python3.10/site-packages/copier/cli.py", line 295, in main
    ).run_copy()
  File "/usr/local/lib/python3.10/site-packages/copier/main.py", line 697, in run_copy
    src_abspath = self.template_copy_root
  File<EMAIL_ADDRESS>line 981, in __get__
    val = self.func(instance)
  File "/usr/local/lib/python3.10/site-packages/copier/main.py", line 670, in template_copy_root
    subdir = self._render_string(self.template.subdirectory) or ""
  File "/usr/local/lib/python3.10/site-packages/copier/main.py", line 644, in _render_string
    return tpl.render(**self._render_context())
  File "/usr/local/lib/python3.10/site-packages/copier/main.py", line 249, in _render_context
    "answers_file": self.answers_relpath,
  File<EMAIL_ADDRESS>line 981, in __get__
    val = self.func(instance)
  File "/usr/local/lib/python3.10/site-packages/copier/main.py", line 430, in answers_relpath
    return Path(template.render(**self.answers.combined))
  File<EMAIL_ADDRESS>line 981, in __get__
    val = self.func(instance)
  File "/usr/local/lib/python3.10/site-packages/copier/main.py", line 385, in answers
    answer = question.parse_answer(result.init[var_name])
  File "/usr/local/lib/python3.10/site-packages/copier/user_data.py", line 420, in parse_answer
    choice_values = {
  File "/usr/local/lib/python3.10/site-packages/copier/user_data.py", line 420, in
    choice_values = {
TypeError: unhashable type: 'list'
```

Expected behavior

Screenshots/screencasts/logs

Environment

OS: Mac
Copier version: copier 7.1.0
Python version: 3.10
Installation method: pip

That was a fast fix! Thank you very much :)


feat(fiatconnect): add timeout to fiat connect requests

Description
react-native's fetch implementation doesn't have a default timeout option and requests can hang for a long time. This PR uses the latest fiatconnect-sdk (which supports timeouts) to set a timeout on all fiatConnect and IHL requests. The timeout is configurable through firebase remote config
Other changes
N/A
Tested
Unit tests, manually by setting a low value for timeout (500ms) and checking if selecting a quote for a provider, which should trigger a login with the provider, errors out with an AbortError .
How others should test
N/A
Related issues

Fixes ACT-499

Backwards compatibility
Yes

^ that bot was me. Forgot to logout 😅


Farmer Profile

Is this the same as the user stories? Or specific explanations of the types of growers? (liking the term growers > farmers atm)


Change True/False strings in cfg yaml

Under ROS Humble, and the latest installed version from April repo, the launch file fails by inability to convert {int} to {bool}.
This resolved the issue.
1 - is treated  as int
"True" - is treated as string
True - as treated as bool

Hi Daniel, nice to see you again :-)
Indeed, running ros2 launch apriltag_ros v4l2_36h11.launch.yml from the upstream branches gives me parameter 'detector.refine' has invalid type: Wrong parameter type, parameter {detector.refine} is of type {bool}, setting it to {integer} is not allowed..


Script Hoisting

Vue version
3.2.40
Link to minimal reproduction
https://sfc.vuejs.org/#eNp1Uk2PmzAQ/StTqxIkSrD2GpFIVS/dw14qVb34wsIQWIFt2YYeEP+9z7CkqKu9oPF8PN57M5P4Zm02DiwuIvela20gz2GwN6Xb3hoXaCLH9YmMfjGDDlzRTLUzPSWYSh5d301v3/OZjI8IirLSpdE+UO/vdI1IafKDu87Qb+O66ktyUFoej6T0kZ6pKUamoizZewqG6kGXocX4ChwaplcTAsJWU8OOCXOFrohH1hGb/HAvHLCk0g++adGxC788uxd/x+/2pfRwvQHMDuEn11ltysGnh6VH6VyufsAJPHYxbcY0704oAa1KoAI+q9wNE5q/RtF66DrgPiTRnlR6mOIshvFZCqkSA2pKxJn5I5vAve2KwIQnUd48Ed2maTF5nnPZPK35hQWN595U3F2VQF2JaBTijSESa3NcmkSYyw39Jk5i1XruC5u9eaNxJgtXzC8Fr8SFVvabDRcETQjWX6T0dRnv4M1nxt0loszB+LbnjH1/fnXmD1QCWInTDkMiObI7O9YVtgwbPsf8r/UDboSFgTOkbFcJDTsLF0Ofk3694G31/yyY/wJYqRZS
Steps to reproduce
Just open the link to the page
What is expected?
I expected the <script  setup> block to be the first script to be executed and then the script created after it to have to export default an object and then the options would be merged that way.
What is actually happening?
When the two scripts have merged the code from the  script  blocks is hoisted to the top of the overall script that is generated. The  code from <script setup> is written to the bottom of the screen it allows. The code that is written in <script setup> has access to the code that is written in every other script. This is not good behavior. I was going to ask for a <script components> block but didn't think it was possible. Even though I like this behavior since I don't have to register components anymore. I can also  split my components into many pieces and avoid creating huge templates. The way this works is not good.

<script setup> should not have any access to code written in other script blocks
If another script block is used the developer should control whether or not it should have access to what is returned inside of setup
Ideally there should only be an export default block and a script block.
The setup block and any other script blocks should be isolated from each other.
When it comes to Component Registration When I create a component inside of an export default block It should only be avaliable to the component that it is being called inside of

System Info
No response
Any additional comments?
I ran into this while creating an Astro project for myself. I wanted to practice creating sites. I was refactoring the app so that I could then look at the code base and read the code better when I go back to reading it. I can understand it. I wanted to try to split my components into pieces and then I found out that my components were working even though I did not register them.
I gave suggestions on how to fix this problem. But to reiterate. Even though I like the fact That I can easily split components into pieces and bring them back together in the form of components. I would like it. If the blocks are separated from each other and one block has no access to the code written in another block. You can wrap Each script Block in An IIFE to prevent leakage.

https://github.com/vuejs/core/discussions/6842#discussioncomment-3840648

All of the points you want ro see changed where purposely designed this way see RFC and for obvious reasons will not change now.
You are free ro start a discussion about a different approach in the rfcs repo, bur dont expect it to be implemented unless your proposal introduces a major added benefit.

both can go into the setup block though.


Remove version: Tencent.COSBrowser version 2.11.12

[Automated] It returns code over 400 in all urls
Microsoft Reviewers: Open in CodeFlow

URL: https://cos5.cloud.tencent.com/cosbrowser/cosbrowser-setup-2.11.12.exe
Response status code does not indicate success: 404 (Not Found).
(Automated message - build 896)