Numbers not typing

Hi. Please in trying to implement the package, I encountered an error whereby the first character of the pin field is not accepting numbers, only special characters. And this happens only on Android, on iOS it's working fine.
https://user-images.githubusercontent.com/61969550/211009383-15f69df0-400e-423e-b5e4-490c486ef552.mp4

Hey @descobee, do you use any inputFormatters ?

No @Tkko I'm not.

@descobee could you share small reproducable snippet

https://user-images.githubusercontent.com/59657947/213692952-a2034e2b-43f5-41c3-84ea-5a6eeef66fba.mp4
experiencing the same issue here,
 final pinController = TextEditingController();

Pinput(
                onCompleted: (value) {
                  if (buttonFunction != null) {
                    buttonFunction!(int.parse(value));
                  }
                },
                length: 4,
                controller: pinController,
                defaultPinTheme: defaultPinTheme,
                focusedPinTheme: focusedPinTheme,
                followingPinTheme: followingPinTheme,
              ),

              final defaultPinTheme = PinTheme(
  height: 56,
  width: 56,
  textStyle: titleMedium(),
  decoration: const BoxDecoration(
    border: Border(bottom: BorderSide(width: 1.0, color: Colors.transparent)),
  ),
);

final focusedPinTheme = PinTheme(
  height: 56,
  width: 56,
  textStyle: titleMedium(),
  decoration: const BoxDecoration(
    border: Border(bottom: BorderSide(width: 1.0, color: Palette.primaryColor)),
  ),
);

final followingPinTheme = PinTheme(
  height: 56,
  width: 56,
  textStyle: titleMedium(),
  decoration: const BoxDecoration(
    border: Border(
        bottom: BorderSide(width: 1.0, color: Palette.secondaryOffWhiteColor)),
  ),
);

is everything I have used for the widget
for the entire code please checkout my repo:
Otp_Box.

@vaidic-dodwani, does it work properly on Android emulator? Which device are you using?
Could you share the output of flutter --version command?

@vaidic-dodwani, does it work properly on Android emulator? Which device are you using? Could you share the output of flutter --version command?

flutter --version output
Flutter 3.3.10 • channel stable • https://github.com/flutter/flutter.git
Framework • revision 135454af32 (5 weeks ago) • 2022-12-15 07:36:55 -0800
Engine • revision 3316dd8728
Tools • Dart 2.18.6 • DevTools 2.15.0

Device Using: OnePlus 7T
Android Version:11
Same behavior on Android Emulator

@vaidic-dodwani Check if the same behavior exists in Standard TextFormField
    TextFormField(
      controller: pinController,
      keyboardType: TextInputType.number,
      inputFormatters: [
        LengthLimitingTextInputFormatter(
          4,
          maxLengthEnforcement: MaxLengthEnforcement.enforced,
        ),
      ],
    );

Yup same behavior on TextFormField
should I send the corresponding video?

@vaidic-dodwani Now try and remove inputFormatters.
I'm not sure what but something is wrong with EditableText which is an underlying widget of both TextFormField and Pinput

@vaidic-dodwani Now try and remove inputFormatters. I'm not sure what but something is wrong with EditableText which is an underlying widget of both TextFormField and Pinput

Still the same behavior

@vaidic-dodwani Yeah, it's seems like an Flutter issue, I advice you to create a separate issue on Flutter repo, and share the url here.
Thanks


.xprofile is being sourced twice

Describe the bug
I'm not sure exactly what is causing this issue, but it looks like .xprofile is being called twice as of recently. I'm on unstable, running sddm and xmonad. I do not have other .xsession or .xinitrc files.
To Reproduce
To debug the issue, I placed this in my .xprofile
#!/usr/bin/env bash
{
  printf '%(%s)T\n$0=%s\n' -1 "$0"
  ps -f -p "$BASHPID" -p "$PPID"
  pstree -ps "$BASHPID"
} >> /tmp/out.log

/tmp/out.log follows
1618464740
$0=/nix/store/vgfg2cr7cwjak93x4b1wp3w6s9m0cjgv-xsession-wrapper
UID          PID    PPID  C STIME TTY          TIME CMD
root       17173    1111  0 11:02 ?        00:00:00 /nix/store/97gym94qjpzhr53ri06zjwld6gwbsl94-sddm-0.19.0/libexec/sddm-helper --socket /tmp/sddm-autha60e02a9-9a85-4d50-96bc-c51eaed3e794 --id 2 --start /nix/store/r9jajxg8laz7aampmvhx99x3nm3b963y-xsession --user kiyengar
kiyengar   17218   17173  0 11:02 ?        00:00:00 /nix/store/jdi2v7ir1sr6vp7pc5x0nhb6lpcmg6xg-bash-4.4-p23/bin/bash /nix/store/vgfg2cr7cwjak93x4b1wp3w6s9m0cjgv-xsession-wrapper /nix/store/r9jajxg8laz7aampmvhx99x3nm3b963y-xsession
systemd(1)---.sddm-wrapped(1111)---.sddm-helper-wr(17173)---vgfg2cr7cwjak93(17218)---pstree(17224)
1618464740
$0=/nix/store/vgfg2cr7cwjak93x4b1wp3w6s9m0cjgv-xsession-wrapper
UID          PID    PPID  C STIME TTY          TIME CMD
root       17173    1111  0 11:02 ?        00:00:00 /nix/store/97gym94qjpzhr53ri06zjwld6gwbsl94-sddm-0.19.0/libexec/sddm-helper --socket /tmp/sddm-autha60e02a9-9a85-4d50-96bc-c51eaed3e794 --id 2 --start /nix/store/r9jajxg8laz7aampmvhx99x3nm3b963y-xsession --user kiyengar
kiyengar   17218   17173  0 11:02 ?        00:00:00 /nix/store/jdi2v7ir1sr6vp7pc5x0nhb6lpcmg6xg-bash-4.4-p23/bin/bash /nix/store/vgfg2cr7cwjak93x4b1wp3w6s9m0cjgv-xsession-wrapper /nix/store/r9jajxg8laz7aampmvhx99x3nm3b963y-xsession
systemd(1)---.sddm-wrapped(1111)---.sddm-helper-wr(17173)---vgfg2cr7cwjak93(17218)---pstree(17226)

Not sure if this is relevant, but here's a snippet from my configuration.nix
    displayManager = {
      defaultSession = "none+xmonad";
      sddm = {
        enable = true;
      };
      autoLogin = {
        enable = true;
        user = "kiyengar";
      };
    };

Expected behavior
The .xprofile script should be called just once.
Metadata
 - system: `"x86_64-linux"`
 - host os: `Linux 5.11.11, NixOS, 21.05pre282432.311ceed827f (Okapi)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.10`
 - channels(root): `"home-manager, nixos-21.05pre282432.311ceed827f, nixos-stable-20.09.3824.dec334fa196, nixos-unstable-21.05pre282432.311ceed827f, nixpkgs-unstable-21.05pre282548.4c87cb87a2d"`
 - channels(kiyengar): `"nixpkgs-unstable-21.05pre281282.4cb48cc2562"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

I have the same issue. I'm using dwm and sddm, although I checked that the problem occurs also with lightdm and i3, or any combination thereof.

@ilikeavocadoes - This disappeared when I went back to 20.09. Are you on unstable/21.05?

Right. Forgot to mention it. This problem appeared when I switched from 20.09 to 21.05.

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/xprofile-being-sourced-twice-after-updating-to-21-05/13619/1

I also have this issue after upgrading major releases.
Using lightdm. Happens on both DWM and Gnome sessions.

https://github.com/NixOS/nixpkgs/blob/8284fc30c84ea47e63209d1a892aca1dfcd6bdf3/nixos/modules/services/x11/display-managers/default.nix#L42
This is where it is sourced once, not sure where it's sourced the second time

I removed the line I pointed out above and it was being sourced 0 times. Adding some test code to the xsessionWrapper I discovered the entire wrapper is being called twice. So the bug is in what calls the xsessionWrapper not within the wrapper itself.

Adding similar logging code to the xsessionWrapper results in exactly the same thing as adding the logging code to the .xprofile (because the wrapper sources the .xprofile). For the record on my machine with lightdm it produces this:
$0=/nix/store/f6fpnylihz63k7nsfp7xpwv35bib67xj-xsession-wrapper
UID          PID    PPID  C STIME TTY          TIME CMD
root       13312   13251  0 21:14 ?        00:00:00 lightdm --session-child 12 19
sage       13321   13312  0 21:14 ?        00:00:00 /nix/store/kxj6cblcsd1qcbbxlmbswwrn89zcmgd6-bash-4.4-p23/bin/bash /nix/store/f6fpnylihz63k7nsfp7xpwv35bib67xj-xsession-wrapper /nix/store/9mqvbr2fkxqkbpiqdk5zb243cpljhkk0-xsession
1625364847
$0=/nix/store/f6fpnylihz63k7nsfp7xpwv35bib67xj-xsession-wrapper
UID          PID    PPID  C STIME TTY          TIME CMD
root       13312   13251  0 21:14 ?        00:00:00 lightdm --session-child 12 19
sage       13321   13312  0 21:14 ?        00:00:00 /nix/store/kxj6cblcsd1qcbbxlmbswwrn89zcmgd6-bash-4.4-p23/bin/bash /nix/store/f6fpnylihz63k7nsfp7xpwv35bib67xj-xsession-wrapper /nix/store/9mqvbr2fkxqkbpiqdk5zb243cpljhkk0-xsession

confirmed happening on gdm as well

As a little workaround, you can add "include guards" to your .xprofile:
if [ -z $_XPROFILE_SOURCED ]; then
  export _XPROFILE_SOURCED=1

  # everything goes here

fi

Any code in the if block will only be executed once. Not ideal but it works until this bug gets fixed.

My workaround was to make sure my .xprofile is idempotent. It was a good exercise 😅

Same here. Running lightdm with i3 on NixOS 22.11.

This is still ongoing in 24.05pre


Change the content of a minimized header

Hello and thank you for your module!
Is it possible to change the text displayed as title for a minimized window?

So instead of Folder-name + Journal name it will show only the latter.
I've managed to change the width of the element, but was unable to change the content.

It is a very annoying problem, so I fixed it on my side. Until the issue is fixed properly, you can replace the method curateTitle() in windowControls.js by this one. It will strip the folder name from the minimized window.
static curateTitle(title) {
const curatedTitle = title.replace("[Token] ", "~ ").replace("Table Configuration: ", "");
const titleAndFolder = curatedTitle.split(':');
return titleAndFolder[titleAndFolder.length-1].trim();
}


refactor: Upgrade to node 16 ?

Hello,
I made the update for node16, it passed the test in local so guess it should work but unsure as I don't know the full process behind.
Also added a Devcontainer for VSCode to have an easy reproductible environment but if you think it as a negative impact on the project, I will remove it.

Commit removed !
Thanks for the review :)

released in 1.3


[Performance] Reduce ElementFeatureCollection calls

Is your feature request related to a problem? Please describe.
This is only a performance report of something I noticed during profiling.
Describe the solution you'd like
A recent profiling session of a simple XML file with ~100_000 lines (by ~10 columns) showed that https://github.com/dotnet/Open-XML-SDK/blob/55f916df3dce862c71a16c59dd579b8d0d5fc152/src/DocumentFormat.OpenXml.Framework/Features/FeatureExtensions.cs#L19 takes ~25% of the time of the actual WriteTo calls.

I expect that the time is simply that much as it is called for each cell multiple times, each individual call is likely very short, but it simply adds up.
Describe alternatives you've considered
n/a
Additional context
n/a

Thanks for the report. Can you provide a repro we can add to our benchmarks?

I'll see what I can do, I have yet to reproduce IT standalone.

I managed to repro it and it's a bug in the code I was profiling.
For each cell, it tried to get the current Column via:
   uint index = (uint) columnIndex + 1;
   column = columns.ChildElements.OfType<Column>().SingleOrDefault(a => a.Min! == index);

and apparently a new instance of OpenXmlElementList is returned each time and something in there triggered all these calls to GetRequired.
The obvious solution was to move the column logic out of the inner loop.
I apologize for the noise.


Adding Getting Started section to README

README Update
Please add a getting started section to the README.

Added Getting started section in README file


Nelder-mead algorithm yields: TypeError: '>' not supported between instances of 'float' and 'NoneType'

<<Please describe the issue in detail here, and for bug reports fill in the fields below.>>
I have an extremely complex code (I run FEniCS) to which I apply a minimization process using the nelder-mead algorithm provided by scipy.
I use the command
results = minimize(some_func, initial_guesses=(the_variable), method='nelder
     -mead', options={'fatol':4e3, 'xatol':4e3})

After some minutes the code returns the following error message:
Error message:
Traceback (most recent call last):
  File "enormously_complex_code.py", line 2030, in <module>
    results = minimize(some_func, initial_guesses=(the_variable), method='nelder
     -mead', options={'fatol':4e3, 'xatol':4e3})
  File "/usr/lib/python3.6/site-packages/scipy/optimize/_minimize.py", line 591, in minimize
    return _minimize_neldermead(fun, x0, args, callback, **options)
  File "/usr/lib/python3.6/site-packages/scipy/optimize/optimize.py", line 571, in _minimize_neldermead
    if fxr < fsim[0]:
TypeError: '>' not supported between instances of 'float' and 'NoneType'

Scipy/Numpy/Python version information:
1.1.0 1.14.3 sys.version_info(major=3, minor=6, micro=5, releaselevel='final', serial=0)

Traceback seems to point to the line if fxr < fsim[0]. Quickly looking at the code, both variables fxr and fsim seem to be results of some evaluations of the user-provided function, https://github.com/scipy/scipy/blob/master/scipy/optimize/optimize.py#L552 and https://github.com/scipy/scipy/blob/master/scipy/optimize/optimize.py#L568
This way, it's likely that the issue is caused by your some_func returning None in some cases. Do you have a standalone reproducer? Since it's a pure python code, the easiest way to debug the issue seems to be to patch up your local scipy install (or even your function) with an import pdb; pdb.set_trace() and looking why and what generates Nones.

Apparently your objective function some_func is returning None.  Here's a simple example that produces the same error:
In [16]: minimize(lambda x: None, 3, method='nelder-mead')
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-16-fbb11c9ee653> in <module>()
----> 1 minimize(lambda x: None, 3, method='nelder-mead')

~/miniconda36b/lib/python3.6/site-packages/scipy/optimize/_minimize.py in minimize(fun, x0, args, method, jac, hess, hessp, bounds, constraints, tol, callback, options)
    589                       callback=callback, **options)
    590     elif meth == 'nelder-mead':
--> 591         return _minimize_neldermead(fun, x0, args, callback, **options)
    592     elif meth == 'powell':
    593         return _minimize_powell(fun, x0, args, callback, **options)

~/miniconda36b/lib/python3.6/site-packages/scipy/optimize/optimize.py in _minimize_neldermead(func, x0, args, callback, maxiter, maxfev, disp, return_all, initial_simplex, xatol, fatol, adaptive, **unknown_options)
    569         doshrink = 0
    570
--> 571         if fxr < fsim[0]:
    572             xe = (1 + rho * chi) * xbar - rho * chi * sim[-1]
    573             fxe = func(xe)

TypeError: '>' not supported between instances of 'float' and 'NoneType'

Because this is apparently a problem with your code, I'm closing the issue.  If you think I'm mistaken, please comment, and we can reopen the issue if  necessary.
P.S. @ev-br got his comment in just as I was about to click "Close and comment"!

P.S. @ev-br got his comment in just as I was about to click "Close and comment"!

Huh, correlation does not mean causation, as they say :-).

What you explained seems to make sense, because when I try another minimization algorithm, such as BFGS, I get a similar error message. I have never seen my some_func function return a "None" though, but I guess I introduced some bugs that might have caused it to return None.


Dynamic testcase parameters

The test operator may want to run a testcase with various dynamic parameters to control the running of the testcase. For example, some testcases are purely observer testcases and evaluate the SUT values for an indeterminate length of time: the test operator may want to specify the length of time the testcase should run. Such parameters should appear in the test report to qualify the test verdict.

the GUI allows the editing of the TC.param


das: Implement DASSub to be able to wait until <height> has been successfully sampled

This idea was born out of a conversation @Wondertan and I had surrounding how we can better test the DASer:

It is a nice to have, but it would be a good first issue as the scope is limited.

ref #848


Use pathdiff instead of strip_prefix (fixes #8)

r? @alexcrichton
would be nice to have a version bump too so that we can start using this in gecko

Thanks!


Tempmutes turn into Perma mutes

A player is muted for a temporary amount of time, but after server restarts, that player is perm muted over and over again.

The root of the issue is here. When a temp mute is created, the duration information is only used to create a delayed task - it's not stored anywhere. When the server restarts, no delayed tasks are started for the mutes which were persisted in the database.

@Aaron1011 Thanks, I'll fix this soon


Test PR: Move upload-artifact outside of the container

Description
[Describe what this change achieves]
Related Issues
Resolves https://github.com/opensearch-project/job-scheduler/issues/698
Check List

[ ] New functionality includes testing.
[ ] New functionality has been documented.
[ ] API changes companion pull request created.
[ ] Commits are signed per the DCO using --signoff.
[ ] Public documentation issue/PR created.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Close this in favor of PR #700 as we do not need to alter the yml file too much.
Thanks.


feat: add git repos for testing and enhance detection (#110)

it resolves #110

@jeffmaury yes it prints out if it fails something otherwise you only see a generic "ok"


refactor(config): Remove redundant options with schemastore defaults

This pull request removes configuration options that is already default settings provided by Prettier's schemastore

Sorry that somehow I messed up the merge conflict resolving process and closed the PR.
I've added back the commit log manually in https://github.com/vuejs/create-eslint-config/commit/2378e2f33d60d98a2969491717a5fceb1d507098


Refactor magic methods, test massive assignment and validation

I'm going to try the same refactoring on __isset() and __unset() so don't merge just now

the new magic methods all seem to work. the PR is ready for review!


Better support for data in web component

Right now, JSON must be passed to the data.  It would be cool if you could pass a url, csv, or whatever to the data attribute and have it interpret the data correctly.  Url seems like the best.

For now innerHTML is treated as raw JSON.  When innerHTML change, the data will change.  In the future an attribute that declares data type and support for more string formats should be provided.


MEN-2739, MEN-2740: Document Enterprise installation procedure.

Multi tenancy is also explained along the way.
Signed-off-by: Kristian Amlie<EMAIL_ADDRESS>

This is missing the testing parts of the documentation, which is why the tests are failing. The content can be reviewed, however.

@estenberg: Also the use of "tenant" and "organization" is a little bit mixed. We cannot avoid the term "tenant token" for historical reasons. I've tried to use it as consistently as possible though, sticking to organization as much as possible, except when talking about "multi tenancy" and "tenant tokens".

Aside from the comments I think we should make the Enterprise installation the default (top level). One of the tutorials (open source or enterprise) need to reference the other and this makes one of them slightly more tricky to follow. I think the Enterprise one should be the easiest to follow as it is the supported one for customers, but there are obviously tradeoffs here.

Indeed, good thinking. I actually went even further, and merged the two guides together completely, which I think made it simpler. It also means that your comments about jumping around are now moot. There are still jumps, but all of them are the skip-forward type.
I fixed the other small issues as well, and added the changes as new commits, so you can see the difference.

Updated and finally passed all tests, including Enterprise tests!
Leaving it open, since we need to merge it together with the feature. Creating dedicated merging task in MEN-2804 so that we can close this.


Update all.json

Site
URLScan link

imtokens.news
https://user-images.githubusercontent.com/49607867/163696364-50096eab-9029-41e9-90b1-7f51e313183f.png

auth-jog.com
https://user-images.githubusercontent.com/49607867/163696474-d8751a5e-7c4f-4432-9ad9-0f57512fce61.png

bcnodecenter.net
https://user-images.githubusercontent.com/49607867/163696403-2164983b-f64c-469b-a32f-e2a92d887c69.png

bitwayplus.com
https://urlscan.io/result/69f28098-acdb-41f0-b9b8-f6aa029fc189/dom/

dapp-smartdefitoken.online
https://user-images.githubusercontent.com/49607867/163701755-9abb1c67-ef5f-4882-8af6-5b916411e7ab.png

	"imtokens.news",

	"auth-jog.com",

	"bcnodecenter.net",

	"bitwayplus.com",

            "dapp-smartdefitoken.online",

i didnt know how to rebase so deleted the old one and made a fresh one
i hope it knows not to do it "out of order" this time
also last mine were mine, so i have no idea why rebasing was needed in the first place (sorry i am dumb)

Please no rebasing 🧿📿

All good. I just recommend rebasing since there's a conflict, but it's better create a new PR since you need to know what you're doing when rebasing (as it rewrites history).

Thank you and sorry for the trouble.


New release version

The latest version in npm is 2.26.0, which is released 6 monthes ago and many new featrues in the readme is not released.
When will new release be published?

There's no timeline for releases. Check documentation for the tagged release you're using instead of master/main.
Duplicate of #2539. Duplicate of #2567.


feat(deps): upgrade runtime dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-runtime-dependencies-1.x" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 1174

Questions ?
Please refer to the Backport tool documentation


Added tests with github api

Please do not merge until you fix the issue with github actions @Diegocortes15

👋 Hello, I did some few changes. One on them was remove the word 'token' from Authorization in the test called ´´´ Via OAuth2 Tokens by Header ´´´ since was this who was throwing an error with github actiosn but not with local way. I just want check if that change is right. Thank you so much for all!


Create buildpack for foundry

Refer to:
https://buildpacks.io/docs/buildpack-author-guide/create-buildpack/

it cost 8 hour.


⚠ AGEG website (redirect) has degraded performance

In 30838bc, AGEG website (redirect) (https://ageg.ca/) experienced degraded performance:

HTTP code: 200
Response time: 2410 ms

Resolved: AGEG website (redirect) performance has improved in 6f499c8.


Create a FeedViewController class

News and Chatter share tons of code - abstract it in a parent class

merged, tested


How to generate netconf-confirmed-commit notification

sh-5.1# sysrepoctl -h
sysrepoctl - sysrepo YANG schema manipulation tool, compiled with libsysrepo v2.1.84 (SO v7.8.10)
sh-5.1# netopeer2-server -V
netopeer2-server 2.1.36
Use netopeer2-cli to connect server and execute "subscribe" to receive notifications. I modify the candidate data and execute "commit --confirm-timeout 120". I can see the "netconf-config-change", but here is NO "netconf-confirmed-commit ",
After this, I execute command "commit --confirmed-commit", there is still NO "netconf-confirmed-commit "
Am my procedure WRONG? or the "netconf-confirmed-commit" notification is NOT support in the laster code?

Actually, we have completely missed this notification and it is not implemented and never sent. It is not a priority but I have noted it and we will implement it once there is some spare time, will reply here.

Hi Michalvasko,
Thanks for your response, I got it

Sending netconf-confirmed-commit notifications has been implemented. Please try it by updating Netopeer's devel branch.


Store layering metadata in OSv3 (fixes #329)

Rather than storing the base image ID and name in a dict in one "base-image" label, a separate label is used for each field, allowing for label-based queries for either value.
I've used hyphens instead of underscores in the names to be consistent with rpm-packages, although it is inconsistent with commit_id.
This hasn't been tested with a real build yet.

Should be OK now.

LGTM (I think we can merge and test on a real build later -- that's what I'm planning to do this week anyway)


Train issues

Hello, thank you for your outstanding work. I apologize for disturbing you. After running the training code, I only obtained the following results. Is this normal? I noticed that the epoch is 0/16, and my training stopped at 15/16 by itself. I obtained this output. Could you please confirm if it didn't complete the full run?

Yes, you made a full training process. We start from 0 and end with 15, which cover 16 epochs totally.

Yes, you made a full training process. We start from 0 and end with 15, which cover 16 epochs totally.

Sincerely appreciate your reply. With the upcoming Chinese New Year, I wish you and your family happiness and a joyful New Year!


AFHTTPRequestOperationManager doesn't support post request with httpbody but only parameters

Simetimes I need encode parameters by sepical rules, but AFHTTPRequestOperationManager doesn't support post request with httpbody

I need to set httpbody directly

This is not a support forum. For usage questions, please try Stack Overflow.


How to use semantic addresses in detail?

Short
Can't access microservices using  semantic addresses.
Proposal
Solution
Status
I deployed an application in oakestra which consists of 2 microservices, I assigned them with rr_ip like <IP_ADDRESS> and <IP_ADDRESS>. Howerver I can't access it, for example ,when I type http://<IP_ADDRESS>:80 in browser, I can't see my front page, and I have to use my NodeIP like http://<IP_ADDRESS>:80 to see it. What's more, when I use axios post to post http request to http://<IP_ADDRESS>/index,
it fails too. Please tell me how to use semantic in detail?
Checklist

[x] Discussed
[ ] Solved
[ ] Tested

Hello @skyrimforest thanks for your issue.
Semantic IP addresses can be used only for service to service communication. So Microservice A can use rr_ip <IP_ADDRESS> to communicate with Microservice B. But you as external client from your browser can only use the NodeIP as you did, correctly. A good alternative strategy for your usecase would be to deploy a proxy/gateway microservice that then dispatches the requests to an internal rr_ip. E.g.
               node1:80
                   |                                                                                +---> [microservice_A_instance_1]
                   |                                                                                |
client ------>[proxy microservice]----rr_ip_microservice_A-------+-> [microservice_A_instance_2]
                   |                                                                                |
                   |                                                                                +---> [microservice_A_instance_n]

Hello @skyrimforest thanks for your issue. Semantic IP addresses can be used only for service to service communication. So Microservice A can use rr_ip <IP_ADDRESS> to communicate with Microservice B. But you as external client from your browser can only use the NodeIP as you did, correctly. A good alternative strategy for your usecase would be to deploy a proxy/gateway microservice that then dispatches the requests to an internal rr_ip. E.g.
               node1:80
                   |                                             +---> [microservice_A_instance_1]
                   |                                             |
client ------>[proxy microservice]----rr_ip_microservice_A-------+---> [microservice_A_instance_2]
                   |                                             |
                   |                                             +---> [microservice_A_instance_n]

Thank you! I will give it a try!

Hello @skyrimforest thanks for your issue. Semantic IP addresses can be used only for service to service communication. So Microservice A can use rr_ip <IP_ADDRESS> to communicate with Microservice B. But you as external client from your browser can only use the NodeIP as you did, correctly. A good alternative strategy for your usecase would be to deploy a proxy/gateway microservice that then dispatches the requests to an internal rr_ip. E.g.
               node1:80
                   |                                             +---> [microservice_A_instance_1]
                   |                                             |
client ------>[proxy microservice]----rr_ip_microservice_A-------+---> [microservice_A_instance_2]
                   |                                             |
                   |                                             +---> [microservice_A_instance_n]

@giobart Hello! I tried the architecture as you drawed upon, it is nice to see that I can access my Fastapi project from a porxy! However, when I am trying to deploy more services(for example like the microservice_A on the picture), I can get microservice_A_instance_1, microservice_A_instance_2 and so on.

I try to print all logs of the instances, where I showed their host name. But I can only see the hostname of the first instance.

What's happening? Does the rr algorithm really take effect?

Hello, sorry for the late response, I did not notice this issue.
What is the current setup? Is fastapi01 using RR address to contact fastapi02?
Moreover, for general questions like this I would recommend using our Discord channel https://discord.gg/7F8EhYCJDf
Over there we're generally more reactive :D

Hello, sorry for the late response, I did not notice this issue. What is the current setup? Is fastapi01 using RR address to contact fastapi02? Moreover, for general questions like this I would recommend using our Discord channel https://discord.gg/7F8EhYCJDf we have a dedicated support forum. Over there we're generally more reactive :D
@giobart Thank you and I have joined this forum, for more info about my setup I will show you later. Appreciate your help!

您好，您的邮件我已收到！


Generic types

How do I type a function with a type variable in rtype?
Example: map function
In functional languages you write something like this:
map :: Functor f => (a -> b) -> f a -> f b
map f a = ...

In TypeScript you use generics (ramda.map):
map<T, U>(fn: (x: T) => U, list: T[]): U[];
map<T, U>(fn: (x: T) => U, obj: any): any; // used in functors
map<T, U>(fn: (x: T) => U): (list: T[]) => U[];

So you want the signature of Array.prototype.map?

Yes, whereby the map function that I described takes the array as second parameter.

IMO, if you put too much inline, it becomes hard to read. I suggest splitting it:
Transform(a: Any) => b: Any
Map(arr: [], fn: Transform) => newArray: []

Since Transform takes and returns Any I loose type information, right? Thus, this error is not recognized:
map( (text: String) => text.length, [1, 2, 3] )

Yep, but my map() signature example is intentionally generic to allow for any kind of transform Bring your own Transform is implied. Do you have an alternative suggestion that works for every possible Transform without losing type information?

intentionally generic means intentionally error-prone. It's like a leak in the type system. Everything that depends on the undefined type variable is untyped and can not be analyzed.
I already mentioned two examples of other type systems. TypeScript uses generics, but I'm not sure if it is the way we should go. I really like the way of functional type systems (simple, clear and expressive), but I'm not sure how compatible it is with the existing rtype system. I mentioned those examples, since TypeScript and Haskell are mentioned in About Rtype:

Standing on the shoulders of giants: ES6, TypeScript, Haskell, Flow, & React

@maiermic I think you missunderstood @ericelliott's comment.

MY map() signature example is intentionally generic to allow for any kind of transform.

Meaning he supplied a generic function, You can supply a typed function.
Transform(a: String) => b: String
Map(fn: Transform, arr: [String]) => newArray: [String]

I think you missunderstood @ericelliott's comment.

:+1:

@maiermic It's also worth noting that Haskell is polymorphic and generic programming is common in Haskell. https://wiki.haskell.org/Generics

More to your original point: currently, we don't support type variables like TypeScript's generics in function signatures, and the TypeScript syntax feels like an assault on my senses.
I'm open to the idea of adding this feature, if we can come up with syntax that doesn't make me want to claw out my eyes. I'll repeat my invitation for you to help:

Do you have an alternative suggestion that works for every possible Transform without losing type information?

It's also worth noting that just because a type isn't in a signature does not mean that the variable is untyped, and the Haskell docs actually show a map example to demonstrate:
map :: (a -> b) -> [a] -> [b]
Char.ord :: (Char -> Int)

For the expression map ord the type checker finds out that the type variable a must be bound to the type Char and b must be bound to Int and thus it concludes:
map ord :: [Char] -> [Int]

IMO, type inference should be favored as much as possible. Trying annotate every little thing can add a lot of noise.

type inference :+1:

Meaning he supplied a generic function, You can supply a typed function.

Maybe I still mispreceive it. Let's try to clear up misunderstandings:
Someone wrote a library with a intentionally generic function map, i.e. he types map like that:
Transform(a: Any) => b: Any
Map(fn: Transform, arr: [Any]) => newArray: [Any]

Now someone else likes to use this function like that:
var a = map( (text: String) => text.length, ['example', 'input'] );
var b = map( (x: Number) => x > 6, a );
var c = map( (text: String) => text.split('p'), b );

In case a map is used with types
Transform(a: String) => b: Number
Map(fn: Transform, arr: [String]) => newArray: [Number]

In case b map is used with types
Transform(a: Number) => b: Boolean
Map(fn: Transform, arr: [Number]) => newArray: [Boolean]

In case c map is used with types
Transform(a: String) => b: String
Map(fn: Transform, arr: [Boolean]) => newArray: [Number]

Since Any is compatible with any type (including Boolean, Number and String) those type definitions are all compatible with the original type
Transform(a: Any) => b: Any
Map(fn: Transform, arr: [Any]) => newArray: [Any]

Thus, the type conflict in case c is not recognized. Who should supply a typed function? Author or user? Where and how should it be supplied? It would be an imposition and error-prone for the user to add a concrete type signature before each usage of map. Therefore, we need type variables the author can use.

Do you have an alternative suggestion that works for every possible Transform without losing type information?

TypeScript uses generics to define type variables
map<T, U>(fn: (x: T) => U, list: T[]): U[];

You can pass type variables to other gerneric type definitions:
Transform<T, U>(x: T) => U
map<T, U>(fn: Transform<T, U>, list: T[]): U[];

You don't need to specify generic types on each call just in the definition.
Generics are widespread and established, but they are considered to be quite complex.

TypeScript syntax feels like an assault on my senses

What do you not like? Maybe we can find a better solution, if you describe your feelings in more detail.
By the way, we already use generics under the hood to describe arrays, don't we? String[] is the same as Array<String>.

By the way, we already use generics under the hood to describe arrays, don't we? String[] is the same as Array<String>.

Yes, and I even considered TypeScript's generic syntax for that purpose, but I think there's something about the angle brackets that drives me crazy. Reminds me of C++ templates or something (which I have bad memories of).
Are there any other generic syntaxes we could use as inspiration?

:-1: For angle brackets

Scala uses square brackets:
def map[T,U](fn: T => U, list: List[T]): List[U] = ...

:-1:  for the long version
We shouldn't use the constructor for that: it's too confusing.
:+1:  for the short version

We shouldn't use the constructor for that: it's too confusing.

Array is not the constructor. It is the type interface Array. The constructor Array is a function with type
function Array[T](...elements: Array[T]): Array[T] { ... }

But I would say that is even more confusing :wink:
We could use another name ArrayInstance or IArray for the type interface of an array to avoid misunderstandings (see example of the documentation):
function Array[T](...elements: ArrayInstance[T]): ArrayInstance[T] { ... }

or
function Array[T](...elements: IArray[T]): IArray[T] { ... }

Whereby the short syntax is more readable, but less explicit (special case)
function Array[T](...elements: [T]): [T] { ... }

We characterize the naming conventions. That's why should think carefully about naming predefined types. ArrayInterface may be considered, too.
Some more examples of generic types (not considering one of these naming conventions):
Stream[T]
Map[K, V]
Object[K, V] // Object that is used like a map (might be controversal, but is common in JS world)
Pair[A, B]

I like the square bracket syntax MUCH BETTER. I'm OK with this:
Stream[T]
Map[K, V]
Object[K, V] // Object that is used like a map (might be controversal, but is common in JS world)
Pair[A, B]

I don't think we should reuse square brackets since in JS it's for arrays.
We need a new syntax that conveys inclusion but doesn't use either (), {} or [].
I don't like <> either but it has the advantage of not being confusing.
Promise::String::
Would that work?

Wouldn’t square brackets mentally collide with our syntax for typed arrays? Object[] vs Object[String, Number] vs Object[String, Number][].
Elm just uses spaces for that. Similarly to Haskell, it has lowercase for generics and uppercase for concrete types::
Stream t
Map k v
Object k v
Pair a b

Transform t u (x: t) => u
Map t u(fn: Transform t u, list: t[]) => u[]

This is my favorite suggestion so far. :+1: @tomekwi
Advantages:

No ambiguity with arrays
No jarring angle brackets
Clean, readable syntax
Follows existing conventions (Elm, Haskell)

Woohoo :tada:! Let’s wait what the others say.

@tomekwi love your suggestion. I'm a fan of the Hindley-Milner type system. (https://en.m.wikipedia.org/wiki/Hindley–Milner_type_system)

Whooah, looks hardcore! :wink:

So simple yet so clear.
:+1: on space

The following looks very bright and logical. Although, rather unreadable. Let me explain.
Stream t
Map k v
Object k v
Pair a b
Transform t u: (x: t) => u
Map t u: (fn: Transform t u, list: t[]) => u[]

Thousands of C++/Java/C# developers are currently being converted to JS developers, you all know that. Students in (high)schools study the C++/Java/C#. I would recommend to make sure these people can read rtype easily without browsing the documentation (JSDoc is quite readable, btw, thus popular).
Haskell is known but an exotic language yet. For C++/Java/C# developers it is counter intuitive that the space symbol have a special syntactic meaning. Frankly speaking, I still do not understand what's that: Transform t u: (x: t) => u.
I would recommend to level the readability up to the highest level possible, gentlemen.
Haskell is still not readable unfortunately. TypeScript syntax is readable to most developers. They would easily understand that:
Transform(a: T) => U
map<T, U>(fn: Transform, list: T[]) => U[]`

But not many would understand this (hopefully I understood it correctly):
Transform t u: (x: t) => u
Map t u: (fn: Transform t u, list: t[]) => u[]

C++/Java/C#/TypeScript languages have so called "generics". I'd recommend utilizing it's syntax - i.e. chevrons < and >.

Let me list "arguments" agains angle brackets you have expressed:

... something about the angle brackets that drives me crazy. Reminds me of C++ templates or something (which I have bad memories of).

> :-1: For angle brackets

> I don't like `<>` either

> No jarring angle brackets
Do you feel like those are far from being an argument? :)

Converted by force?
I think we should concentrate on our community needs.
The newcomers already added class to ES, that's plenty enough in my opinion.

Those "converted" people are also our community.

Do you feel like those are far from being an argument?

I used C++ and Java for years, and I never got accustomed to angle brackets for templates or types. I can't express in a way that sounds like a just argument except that to my brain, they are extremely noisey to the point that it makes it really difficult for me to read.
For some reason, angle brackets don't bother me for HTML/JSX, but when they're mixed in with the rest of the syntax noise of a function signature, they scramble my brains.
On the flipside, I find the lack of syntax noise here produces crystal clarity without any loss of meaning:
Transform t u: (x: t) => u
Map t u: (fn: Transform t u, list: t[]) => u[]

I'm completely baffled that you find this harder to read.
I'm tempted to HARD VETO the angle brackets, but I don't want to shut down the discussion. =)
I'll just leave you with a reminder of my original stance on TypeScript's syntax:

"TypeScript syntax feels like an assault on my senses."

That hasn't changed, and no amount of logical argument is going to change it if 15 years' exposure to similar syntax hasn't made it any more bearable.

Those "converted" people are also our community.

IMO, they deserve a break from the angle bracket torture. ;)

TypeScript syntax feels like an assault on my senses.

Agreed. I enjoy reading well written JavaScript. TypeScript is horrendous mutation.

If rtype does need wide adoption then go ahead, use spaces. :)
Transform t u: (x: t) => u remove u
Transform t: (x: t) => u remove t
Transform: (x: t) => u why there is double colon?
Which is correct Transform: (x: t) => u, Transform (x: t) => u, or Transform(x: t) => u and why?
Why some types in rtype are upper case, but the u and t above are lower case?
Now, let me embed Transform into the map function:
Map t u: (fn: Transform t u: (x: t) => u, list: t[]) => u[]

^ First of all those double colons frustrate me.
Second, what if I don't need the Transform function at all and want to make it all single line? Is the following correct?
Map t u: (fn: t u: (x: t) => u, list: t[]) => u[]

"TypeScript is horrendous mutation."

I wouldn't go that far. TypeScript has tons of cool ideas & it's been a major source of inspiration for this project.  First generic argument of it would be string, and second would be a function which take and returns strings.
F(map: Map String (str: String) => String) => Map String (str: String) => String

^ see the => arrow chaining. So you still think that's readable?
Borrowing most of the syntax from JS and Flow you borrowed an incompatible Haskel/Elm syntax.

Good questions, @koresar. Let's clean this up and align it more with our existing syntax:
Map t u: (fn: Transform t u, list: t[]) => u[]

IMO, this should be:
Map t u (fn: Transform t => u, list: t[]) => u[]

Which translates to:
Signature Map uses type variables t, and u which do not exist outside the scope of this signature. The first argument is a Transform function from type t to type u, and a list of type t. Map's second argument is an Array of type t, and it returns an array of Type u.
As with JavaScript, I think if the function needed more than one parameter, it should use parens around the arguments, so this should also be a valid representation of Transform: Transform (t) => u.

Transform (x: t) => u, or Transform(x: t) => u

Both of these seem fine to me. IMO, the space should be allowed specifically because I find this clear:
Map t u (fn: Transform t => u, list: t[]) => u[]

... and this a little less clear:
Map t u(fn: Transform t => u, list: t[]) => u[]

(Note the absence of the space after u, which makes it look to me like u is the function name).

Why some types in rtype are upper case, but the u and t above are lower case?

Visual disambiguation between concrete types and type variables.

Now, let me embed Transform into the map function:

Map t u: (fn: Transform t u: (x: t) => u, list: t[]) => u[]

The t u after Transform shouldn't be necessary, because the type variables are in scope from the Map declaration:
Map t u (fn: Transform t => u, list: t[]) => u[]

First of all those double colons frustrate me

Me too. Consider them gone.

what if I don't need the Transform function at all and want to make it all single line? Is the following correct?

`Map t u: (fn: t u: (x: t) => u, list: t[]) => u[]`

Type names are optional if you're not reusing them, so this is probably the shortest valid expression of Map:
Map t u (t => u, list: t[]) => u[]

Both of these seem fine to me. IMO, the space should be allowed specifically because I find this clear:

Map t u (fn: Transform t => u, list: t[]) => u[]

IMO it should be mandatory in that case.

I want to make function F to accept and return the same type Map. First generic argument of it would be string, and second would be a function which take and returns strings.

This example doesn't make sense and probably shouldn't be considered valid because String is not a type variable, and your desired signature doesn't need type variables. If I understand you correctly, it should be written like this:
F(Map(str: String) => String) => Map(str: String) => String

But this violates DRY, and should instead by written like this:
Map(str: String) => String
F(Map) => Map

Which looks perfectly clear to me. Is it possible to write confusing signatures with the syntax we have now? Sure. But it's also possible to take that same signature and write it in a way that looks clean and sane.

@Mouvedia

IMO it should be mandatory in that case.

:+1: I agree, that seems like a reasonable style rule.

Thanks Eric for that:
F(Map(str: String) => String) => Map(str: String) => String

Map(str: String) => String
F(Map) => Map

But there is a mistake. Please read:

First generic argument of Map would be string, and second would be a function which take and returns strings.

Map is a key->value map. Where key is string and value is predicate. Let me attempt to tackle it.
Map String (str: String) => String
F(Map) => Map

Unwrapping:
F(Map String (str: String) => String) => Map String (str: String) => String

Removing the word Map as not needed:
F(String (str: String) => String) => String (str: String) => String

Removing the variable name str.
F(String (String) => String) => String (String) => String

Dropping unnecessary parenthesis:
F(String String => String) => String String => String

Replace String with t to make it more generic as suggested above:
F(t t => t) => t t => t

Is it still valid?
Have I made a mistake at any step?

Consider this:
Map t u (t => u, t[]) => u[]

What if we wanted to map over streams instead of Arrays?
Assuming, Map t u (t => u, t[]) => u[] is short for:
Map t u (t => u, Array t) => Array u

And then these become valid:
Map t u (t => u, Stream t) => Stream u

Map t u (t => u, Promise t) => Promise u

Or did I miss a better implied representation for this idea?

Thanks Eric.Although I'm trying to understand how rtype works. I'm considering it for company-wide usage. Although, this question bothers me very much.
Was I correct in my logic chain above?

First generic argument of Map would be string, and second would be a function which take and returns strings.

This is still confusing me.
"First generic argument of Map would be string" -- if we know it's a String, it's not generic, right? It's not a type variable, it's a known parameter type, String.

and second would be a function which take and returns strings.

And a function which takes and retuns Strings is also not generic, it has the concrete signature: fn: String => String.

Map is a key->value map. Where key is string and value is predicate.
Map String (str: String) => String

Still confused. Where is key? Where is value? Where is the Predicate type (which is built into rtype)?
It sounds like you're describing a data structure rather than a function. If I were translating your English prose to an rtype signature, it would look like this:
interface PredicateMap {
  key: String,
  Predicate
}

Assuming you really do mean a function, it would look something like this:
PredicateMap(key: String) => Predicate // Predicate is a function that returns a `Boolean`

I have no idea what you mean by this. AFAIK, it's not valid rtype:
F(String (String) => String) => whatever

The way I read it, it translates into this nonsense:
F is a function that takes a String as the first parameter. At which point it blows up: "Error: Expected comma and instead got a function signature."

I beg you pardon for my broken English.
Map is a key->value map. Where key is string and value is function which takes string and returns string. In JS it would be this:
var map = {};
map.a = function (str) { return str; };

"a" string is a key. The function is the predicate.
Yes, it is a data structure.
Let's forget about strings and use type t instead. Ok?
Predicate:
Predicate t (t) => t

Data structure (map):
interface PredicateMap t {
  key: t,
  Predicate t
}

The F function:
F(PredicateMap t) => PredicateMap t

Is that correct to your thinking?

I’m a bit confused as well. After the discussion with Eric at https://github.com/ericelliott/rtype/commit/7730287320d00c539052aa922921a5714aa47cbf#commitcomment-15619201 I wanted to apologize and correct my mistake. Instead of
Transform t u: (x: t) => u
Map t u: (fn: Transform t u, list: t[]) => u[]

…I meant rather
interface Transform t u: (x: t) => u
interface Map t u: (fn: Transform t u, list: t[]) => u[]

That could be expressed without the intermediary type:
interface Map t u: (fn: t => u, list: t[]) => u[]
interface Map t u: (t => u, t[]) => u[]

…or as a type annotation and not an interface:
//  map(
//    fn: t => u,
//    list: t[]
//  ) => u[]
const map = (fn, list) => …

And by the way, we could use the generic interfaces to “fill” them with concrete types later on:
//  Transform String Boolean
const isLong = str => (str.length > 5);

@tomekwi can you help me with my trouble above? I can't figure out syntax for my simple case.

@koresar, I’ll try – though the ins and outs of the syntax aren’t very clear to me.
I assume that by using Map before defining it beforehand you mean JS’s native Map. But as it’s not a builtin yet, we need to define it beforehand:
interface Map k v {
  key: k,
  value: v,
}

Then what you called Map in F(Map) => Map is no longer the almost-built-in type Map, but it’s a concrete type (without generics) based on Map:
interface StringMap:
   Map String (String) => String

interface F:
  (StringMap) => StringMap

The shortest way to express that would be:
interface F:
  (Map String (String) => String) => Map String (String) => String

– and I do agree that it’s unreadable and ambiguous. I suggest that we force parens around literals when using them as “arguments” for generic types:
interface StringMap:
   Map String (String => String)

interface F:
  StringMap => StringMap

…and the terse, eye-squelching version:
interface F:
  (Map String (String => String)) => Map String (String => String)

As for your comment about making things more generic, I think it only makes sense when your function/interface really is generic. But if your code really is so abstract then the type annotations are bound to be abstract too:
interface TypeMapTransformer a:
  (Map a (a => a)) => Map a (a => a)

If you ask me, the last example doesn’t look bad or unreadable. It’s complex becuse what you’re trying to express is complex. Try documenting that with jsDoc!

Here’s the DRY version:
interface TypeMap a:
   Map a (a => a)

interface TypeMapTransformer a:
  TypeMap a => TypeMap a

(By the way, if this goes through, I’d take the opportunity to revise builtins. I’m not sure if we need Any, Array and Object if we have generics.)

I disagree with that last comment, it's a common case hence it should be simple and immediately clear.
What you are proposing is not.
Any is also used by Swift and TypeScript.

How about something like the following:
( let t = Any, let u = Any, Transform(x: t) => u )
Map(fn: Transform, list: [ t ]) => [ u ]

or single line case:
( let t = Any, let u = Any, Map((x: t) => u, list: [ t ]) => [ u ] )

Advantages:

This is almost valid JavaScript.
The parenthesis allow logical expressions to be grouped together.
We don't need to make whitespace significant.
Readability (although this is subjective)

Disadvantages:

Lots more text to right compared to Map t u (fn: (x: t) => u, list: [t]) => [u]

@tomekwi thank you very much. I finally understand the proposed syntax.
My conclusion: if we use spaces for generic type delimitation then we should force parens around literals when using them as “arguments” for generic types.
My example would look like this:
interface F:
  (Map String (String => String)) => Map String (String => String)

Type names here are not optional here. Without the Map type name it will be hard to guess either something is a generic type argument or a type name declaration.
I propose using angle brackets:
F(<String, String => String>) => <String, String => String>

It's shorter.
It's more readable to most developers. rtype will get wider adoption!
Less effort needed to visually parse function declaration from type declaration.
No need to name each type (see the F and the Map above).

@koresar Generic types like Map are not just type names. They are type constructors:

type constructor is a feature of a typed formal language that builds new types from old ones
Wikipedia - Type constructor

That means a type constructor is not a type itself, but it describes a class of types. For example, these types are some elements of the type class Map:
Map Number Number
Map Number String
Map String String
Map String Any
// ...

Note: Map String String is not the same type as Map String Any
If you do not pass all type parameters a new type constructor is returned:
StringMap: Map String  // StringMap is type constructor with keys of type String, because the concrete type of the second/last type variable is missing
StringMap Number       // Create concrete type equivalent to: Map String Number
StringMap Boolean       // Create concrete type equivalent to: Map String Boolean

Removing the word Map as not needed
...
Have I made a mistake at any step?

Yes, you can not leave out the type constructor Map:
Map a b // e.g. Map String (String => String)

is not equivalent to
a b // e.g. String (String => String)

because a is not a type constructor that takes one type variable (e.g. String is not generic, so it can not take a type parameter (String => String)).
Maybe it is more clear to you if you use angle brackets:
// Map a b
Map<a, b> // valid

// a b
a<b>    // Error: unresolved symbol a  OR  a is not a type constructor
<a, b>  // Error: missing type constructor

@BerkeleyTrue I'm not sure what you are trying to express with
( let t = Any, let u = Any, Map((x: t) => u, list: t[]) => u[] )

If t and u are equal to type Any they are not type variables. In this case your example is not generic and equivalent to
Map((x: Any) => Any, list: Any[]) => Any[]

Further, let is used to create local variables, but type variables are parameters passed to a type constructor (see my comment above). A type constructor is more like a function that returns a type:
// type constructor Map
function Map(t: Type, u: Type): Type {
  return ((x: t) => u, list: t[]) => u[]
}

@tomekwi

I’m not sure if we need Any if we have generics. Array and Object could be more specific

@maiermic thank mate. I corrected my previous comment.

In rtype the whitespace characters have no actual meaning. Just like in JS.
By introducing space as a syntax operator you would break rtype consistency.

Whitespace characters have an actual meaning. They are seperator symbols. var x and varx are not the same.

Exactly. Whitespaces are separators in rtype. People are trying to give it more syntactical power, and thus introduce ambiguity.

What syntactical power are you talking about?

Space symbol is a delimiter in rtype. People want to make in a generic type declarator as well.

Any example where this results in ambiguity/conflicts with ECMAScript 2015 syntax? I already thought about that issue, but no example came into my mind yet. Thus, I didn't complain.

As a side not: Any syntax addition might result in ambiguity/conflicts with future ECMAScript versions. But that's not even the point. rtype is meant to be a domain specific language (DSL). rfx does not pursue the goal to extend JavaScript syntax:
import r from 'parse-rtype';  // parser of rtype DSL

export const myInterface = rfx({
  type: r`
    myFxName(
      param: String,
      otherParam: [x: Number, y: Number, z: Number],
      options?: {beep = false: Boolean},
    ) => Number
  `,

  description: /* ... */,
  doc: /* ... */,
  example: /* ... */,
  fn: myFunction,
})

Any example where this results in ambiguity/conflicts with ECMAScript 2015 syntax? I already thought about that issue, but no example came into my mind yet.

I thought of it too. No examples came too. My main concerns are readability and rtype popularity.
Personally, I fell comfortable with space symbols for generics declaration. It's a good solution. Just not the best.

@tomekwi

I’m not sure if we need Any if we have generics. Array and Object could be more specific

Not everything is an Object in JavaScript. Generics describe objects (including functions). Thus, Any is not equivalent to Array, Object or any generic. Instead Any is a union type of all existing types. Since existing types depend on the environment (browser, node, ...) it is unreasonable to list all existing types in a custom union type to redefine Any.
Since Any accepts values of any type, it should be used carefully and should be avoided in most cases. You should only use Any if you do not need or know type information. Otherwise a more specific type is prefered. console.log is a prominent example of a function that does not need specific typed paramerters:
(message?: Any, ...optionalParams: Any[]) => void

Another common use case of Any is anything (for example a global variable) that is not explicitly typed and where type inference is not possible (for example if you use/import a library that is not explicitly typed and where no type interface is provided).

In some of the previous comments are several usages of
Map String (String) => String

which is equivalent to
(Map String String) => String

but meant is
Map String (String => String)

The same applies to
Map String (str: String) => String

which is a syntax error. Correct is
Map String ((str: String) => String)

I assume that by using Map before defining it beforehand you mean JS’s native Map. But as it’s not a builtin yet, we need to define it beforehand:

interface Map k v {
  key: k,
  value: v,
}

This interface does neither describe the ECMAScript 2015 Map type nor an object used like a map (Object k v). It is just an object with two properties key and value.
This is a type definition of Map in TypeScript:
interface Map<K, V> {
    clear(): void;
    delete(key: K): boolean;
    entries(): IterableIterator<[K, V]>;
    forEach(callbackfn: (value: V, index: K, map: Map<K, V>) => void, thisArg?: any): void;
    get(key: K): V;
    has(key: K): boolean;
    keys(): IterableIterator<K>;
    set(key: K, value?: V): Map<K, V>;
    size: number;
    values(): IterableIterator<V>;
    [Symbol.iterator]():IterableIterator<[K,V]>;
    [Symbol.toStringTag]: "Map";
}

Object k v has to be a special build-in type as well as Array t. In the current version of rtype we use Object and Array without explicit specification of concrete types. I am sure we like to keep them or at least Object since the special notation Any[] is prefered to Array.
Proposal:

keep Object as short version of Object Any Any or Object (String | Symbol) Any
keep Arrayas short version of Array Any
Array T is equivalent to T[]

We are missing a common syntax to declare a generic type. This caused/causes confusion like:

Map t u: (fn: Transform t u, list: t[]) => u[]

IMO, this should be:

Map t u (fn: Transform t => u, list: t[]) => u[]

Proposal: Declare type variables in header of an interface:
interface Transform t u {
  (t => u)
}

interface Map t u {
  ((fn: Transform t u, list: t[]) => u[])
}

IMO an interface is just a type alias. As a consequence, interface and parameter names do not matter. Therefore, the following interfaces are the same as the previous mentioned Map definition:
interface Map t u {
  ((Transform t u, t[]) => u[])
}
interface Convert t u {
  ((Transform t u, t[]) => u[])
}

Another syntax proposal:
We could use parentheses like this:
interface Map(t, u) {
  ((Transform(t, u), t[]) => u[])
}

With named parameters:
interface Map(t, u) {
  ((fn: Transform(t, u), list: t[]) => u[])
}

Advantages:

it looks similar to a function declaration
it behaves similar to a function declaration: defines a type constructor (= function) that takes types as parameters and returns a type

Alright I think this is too much for this issue.
If you have several competing proposals then either open several PRs or one issue with all of them listed and compared. In short just take your last comments and transform them in something concrete without all the noise we might have here. You are invited to link them/it on this issue.
The discussion is sometimes side-tracked; we now have enough for some proposals. The conversation is not locked, you can continue elaborating the edge cases if you consider it not ready.

@Mouvedia What should be covered in a PR?

one issue with all of them listed and compared

Do you mean a summary of all proposed syntaxes in this issue? Wouldn't that lead to a continuation of the current discussion in the new issue? Is this preferred?
Aspects that have not been discussed yet:

variance (covariant, contravariant and invariant)
type restrictions

Where should they be discussed?

You can continue here but I consider that, if these 2 points are not blockers, you have enough to make a proposal issue.
Concerning the PR, that depends on your tendencies. If you choose that road, fork or create a branch.

Disadvantages of the last @maiermic proposal:
Disadvantages:

it looks similar to a function declaration
it behaves similar to a function declaration: defines a type constructor (= function) that takes types as parameters and returns a type

Sorry for trolling like messages. That's my personal opinion. We should lean towards readability. Using parenthesis for everything damages readability significantly. (One of the reasons to not like Lisp is the parenthesis bloat.)
All the rest proposals are looking very good though. Thanks for the hard work @maiermic !

@tomekwi  Some clarification. We're all making syntax mistakes in our examples, which is confusing the conversation. Thanks to @maiermic for the great clarifications:

The interface keyword is implied function signatures.
Colons are not required after root level interface names.

In other words, the following example:
interface Transform t u: (x: t) => u
interface Map t u: (fn: Transform t u, list: t[]) => u[]

Corrected version:
Transform t u (x: t) => u
Map t u: (fn: Transform t u, list: t[]) => u[]

That could be expressed without the intermediary type:

interface Map t u: (fn: t => u, list: t[]) => u[]

Yes it can, but let fix this to remove the interface and :.
Map t u (fn: t => u, list: t[]) => u[]

Note: Colons after interface names aren't needed. I used them (perhaps confusingly) in the README for clarity in the interface literal example:
interface Name: /\w+/

But that may have been a mistake. Is this as clear/more clear?
interface Name /\w+/

Or should we make them optional and recommend using it for the single line literals, and not using it for signatures, to maintain the most possible consistency with JS?
Annotation vs Interface?

…or as a type annotation and not an interface:

This spec intentionally is not about how annotations are added to real code. It's OK to add them with comments, but it's recommended to add them as real JavaScript strings using ES6 template string syntax and a tool like rfx.
Either way, an "annotation" is just an interface associated with some real code in some way. There is absolutely no difference in syntax or semantics.
However, this raises an interesting point:
If we give lowercase the special meaning of type variables, and uppercase the special meaning of concrete types, the correct form would be:
//  Map t u (fn: t => u, list: t[]) => u[]
const map = (fn, list) => …

Which could be confusing, since there's a mismatch between the interface name and the function name. Alternatively, we could just say that the interface name is REQUIRED when using type variables, so a signature can never start with an interface variable. That way you could eliminate the uppercase/lowercase requirement and do this:
//  map t u (fn: t => u, list: t[]) => u[]
const map = (fn, list) => …

How Type Variables are Used
I find this example confusing:
interface StringMap:
   Map String (String) => String

interface F:
  (StringMap) => StringMap

Remembering that (in this case) Map is defined as:
interface Map k v {
  key: k,
  value: v,
}

Shouldn't it look like this?
interface StringMap String String

F(StringMap) => StringMap

Alternatively, we could use JS function-style invocation to make it really obvious when you're trying to create a concrete type from a generic type:
interface StringMap(String, String)

F(StringMap) => StringMap

map t u (fn: t => u, list: t[]) => u[]

If map is an interface, that's wrong. Here's why: a parameter can be nameless:
is(Any) => Boolean

Which means that—as explained here—the interfaces needs to be capitalized to be able to detect a parameter that is missing a type.  I am not even talking readability here, but it would drop significantly.
// this is wrong, word is not a type (the parameter is probably missing a type > it's an error)
(word) => Example

@Mouvedia

"; since a parameter can be nameless and parameters are always camelcased, all interfaces must be capitalized:"

I must have forgotten that addition to the spec... regardless, it's broken. I see a couple problems with it:

Parameters are not always camelCased -- that would force undue restrictions on how people write their JavaScript code, and force them to change existing code in order to use rtype. Remember, due to the support for ES6 destructuring syntax, parameter names MUST MATCH the variable names in code, so that rule is a total non-starter. I'm enforcing VETO and I've already deleted the line from the README.
Undefined types can be caught by a simple lint tool and error reports generated.

If a parameter has the same name as an existing type, and you don't want your parameter to be that type, you can easily specify both the parameter name and a type to disambiguate:
interface Foo {
  bar: String
}

// Valid, interpreted as an unnamed param of type Foo...
capitalize(Foo) => String

// but what if we want Foo to be a parameter of type String? Easy...
capitalize(Foo: String) => String

Given that, your example doesn't need disambiguation, because it's already invalid:
Error: Undefined type, "word":

(word) => Example
 ^

Names are optional, but types are not. If you want "untyped" param, use Any:
(Any) => Example

See Matching Names in Code for my reasoning about why I think it's a bad idea to give uppercase/lowercase special meaning.

I find this example confusing:

interface StringMap:
   Map String (String) => String
>
interface F:
  (StringMap) => StringMap

Lets revise the example description to get rid of any misunderstandings:

I want to make function F to accept and return the same type Map. First generic argument of the Map would be string, and second would be a function which takes and returns strings.

Later Map was specified as a data structure that is an Object:
var map = {};
map.a = function (str) { return str; };

Therefore, Map k v is equal to Object k v: An Object where keys (property names) are restricted to type k and values (of properties) are restricted to type v. We will come back to this soon.

Remembering that (in this case) Map is defined as:

interface Map k v {
  key: k,
  value: v,
}

Like I pointed out in this comment it is not the wanted type. Nevertheless, it is a valid type definition that could be used in the context of the example, since it has the same type signature Map k v.

Shouldn't it look like this?

interface StringMap String String
>
F(StringMap) => StringMap

F is correct. Since it is a function it should be written without interface and colon. It takes and returns the same type of Map called StringMap. Hence, it satisfies the first sentence:

I want to make function F to accept and return the same type Map.

It remains the second sentence that StringMap must satisfy:

First generic argument of the Map would be string, and second would be a function which takes and returns strings.

StringMap is just an alias type of a Map k v (object not function) with concrete types. The first generic argument k should be String. The second generic argument v should be String => String ("a function which takes and returns strings"). Like I pointed out in this comment it should be:
interface StringMap:
   Map String (String => String)

Your suggestion
interface StringMap String String

should results in a syntax error. StringMap undoubtedly is the interface name.

Note: Colons after interface names aren't needed.

Where would you insert the colons?
interface StringMap: String String  // Error: String is not generic, does not take a type argument (in this case the second token String
interface StringMap String: String  // String is the name of a type variable. The definition is equal to:
interface Alias T: T  // "Alias T" equals type T. Thus, "Alias String" equals String. Consequently, "StringMap String" equals String.
interface StringMap String String:  // Error: missing definition/body

Conclusion: The solution of the example looks like this:
interface Map k v:
    Object K v  // alias

interface StringMap:
    Map String (String => String)

F(StringMap) => StringMap

or the short version without aliases:
F(Object String (String => String)) => Object String (String => String)

Colons are not required after root level interface names.

If I understand correctly
interface MyObject x: Number

equals
interface MyObject {
  x: Number
}

If that is correct, whitespace syntax for generics is ambiguous.

** off topic **
@ericelliott Can interfaces be not capitalized?

@ maiermic

If I understand correctly

No. Sorry for the misunderstanding. Probably my fault.
interface MyObject x: Number

This is not a valid shortcut. The shortcut you're referring to was devised for type literals. It is not meant to represent objects with specified properties, e.g.:
// only the literal values, 9, 10, or 11 are valid members of this type
interface X: 9|10|11

@Mouvedia
Currently, there are no capitalization rules for interfaces. It has been proposed in this thread that we could introduce a convention to give capitalization meaning. I don't think it's a good idea for these reasons.

@maiermic
Ah, took me a while to parse this:
interface StringMap:
    Map String (String => String)

In prose:
StringMap invokes the generic Map type constructor with two arguments, String, and a function (in parens for grouping): String => String.
Would this be more or less clear? More or less ambiguous?
interface StringMap:
    Map(String, String => String)

Possible ambiguity with:
interface StringMap v (String, String => String) => Any

But there are a few distinguishing features:

Map is a type constructor, which can't be used as the name of a type variable, so it can't be confused with one.
No return value is specified in the invoked type constructor, which distinguishes it from signatures, where return values MUST be specified.
We could say that the colon : is not allowed in a signature declaration, which could indicate that interface StringMap: is not declaring a signature directly, but declaring a literal value, or invoking a type constructor. That would save lookahead, the parser would not need to look for a return value for disambiguation.

Keeping in mind that our guiding design goal is to make the syntax immediately familiar and intuitive to people who are familiar with JavaScript, does it make more sense to make type constructor invocation look like a JavaScript function invocation?

Ah, took me a while to parse this:

interface StringMap:
    Map String (String => String)

Yeah. That's what I'm talking about. Readability. :)
I still think angle brackets would serve better:
interface StringMap:
    Map<String, String => String>

@koresar My primary concern is readability for JavaScript developers. I'll repeat the question:

Keeping in mind that our guiding design goal is to make the syntax immediately familiar and intuitive to people who are familiar with JavaScript, does it make more sense to make type constructor invocation look like a JavaScript function invocation?

In my view no, it doesn't.
I don't think there should be a thing called "type constructor invocation" at all. I'd better call it "type annotation".

I'd better call it "type annotation".

I'm confused. A type annotation is association of type metadata with code. Essentially, everything in this entire spec, assuming that it gets associated with some working code, could be used as "annotations".
For example, in Java, you can associate extra type metadata inline using the special annotation syntax @TypeName, which is essentially like mixing in extra type metadata to whatever you're doing (function definitions, variable assignments, etc...).
...which fails to make the distinction that a generic function type must be translated into concrete typed versions in order to provide analysis capabilities.
Using a generic type is just like applying a generic type function to its type arguments (quite literally, in many cases, as with C++ templates). This is very analagous to calling a function in JavaScript. I don't see a good reason why it should not resemble that here.
In other words, in the actual parser:
interface StringMap:
    Map String (String => String)

May be parsed to actual JavaScript code like this during the parse/compile step:
const StringMap = Map(String, StringStringFunction);

Where Map is a function that takes type values and returns an rtype concrete interface object.
So, since we don't have to worry about ambiguity between actual function definitions and function calls because this doesn't get mixed directly into source (precisely because it's not actually an annotation as the Java/TypeScript examples often are), I don't see a good reason to use the alternative Foo<t1, t2> syntax to express it.

All are valid points. Yeah. "annotation" is really not the right terminology.

In case of a single-parameter-function as concrete type argument readability is decreased with angle brackets notation due to the fact that a closing angle bracket is used as arrow head:
MyInterface<String => String>   // angle bracket syntax

MyInterface<(String => String)> // angle bracket syntax, IMO parentheses don't increase readability in this case

MyInterface (String => String)  // whitespace syntax (type argument has to be enclosed in parentheses, otherwise it would be equal to `(MyInterface String) => String`

MyInterface(String => String)   // parentheses/function syntax; Note: Could also be written like whitespace syntax in this case: `MyInterface (String => String)`

This case is a common one. It could be bypassed with a function alias
interface StringStringFunction:
    String => String

but you don't always like to do that.
To be fair, there may be awkward examples in other syntaxes, too. Please comment if anything comes into your mind.

@maiermic

Since Any accepts values of any type, it should be used carefully and should be avoided in most cases. You should only use Any if you do not need or know type information. Otherwise a more specific type is prefered. console.log is a prominent example of a function that does not need specific typed paramerters:

(message?: Any, ...optionalParams: Any[]) => void

That makes sense. I meant that could be expressed by generics like this:
(message?: a, ...optionalParams: b[]) => Void

– but on second thoughts, it only makes the thing more obscure. Generics only really make sense in interface definitions. Literals should only allow concrete types like those in your example.

(message?: Any, ...optionalParams: Any[]) => void

and
(message?: a, ...optionalParams: b[]) => Void

are not the same. The function (console.log) takes values of arbitrary types as optionalParams that have no common super type b except Any.
What should be the type of b in this example?
console.log("arbitrary values", true, 42, "string", [1, 2, 3], { property: "value" });

I did not pass a value of every existing type, but it would be possible. Hence, b is Any.

Definitely :+1:

@maiermic
Struggling to see what is awkward about your example above. If we adopt the function call syntax, is there any difference in parsed meaning between these two examples?
MyInterface (String => String)  // whitespace syntax (type argument has to be enclosed in parentheses, otherwise it would be equal to `(MyInterface String) => String`

MyInterface(String => String)   // parentheses/function syntax; Note: Could also be written like whitespace syntax in this case: `MyInterface (String => String)`

Even if there was confusion, and somebody mistakenly used the grouping syntax MyInterface (String => String) it has the same parsed meaning as the function call syntax, MyInterface(String => String) -- so no harm done, right?
Or am I missing some other ambiguity or interaction with other interface syntax?

@maiermic
Ah, I think I see your point:
MyInterface (String => String)

May be interpreted as:
MyInterface(String) => String

Of course, if MyInterface was already declared, we could detect it and figure out that it's intended as a function call syntax to form a concrete type:
MyInterface(String => String)

Looks like there are ambiguity and readability problems with all of the syntax proposals so far.
Which one has the best readability + disambiguation solution?

MyInterface (String => String)

May be interpreted as:

MyInterface(String) => String

No, it isn't, but
MyInterface String => String

may is interpreted as
(MyInterface String) => String

because of the higher binding of an interface declaration (I should have mentioned that earlier :disappointed: ), which results in
MyInterface(String) => String

There is no such ambiguity.
MyInterface (String => String)

is a different type. It is a concrete type. It is not an interface declaration, because it would be missing an interface body.

Ah, yes, thanks for the reminder.
In that case, I think I'm happy with the function call syntax. Are you?

May be interpreted as:

Even Eric is confused.
Think of that. Every one here got confused on how the new "function call" syntax actually works. Add several other confusions we had above. And imagine thousands of other people being confused.
Surprisingly, none in this thread got confused with the "angel brackets" syntax.

@koresar Maybe. Keep in mind that none of us are familiar with the existing syntax, and we are familiar with other type system syntax, so it's easy for our brains to jump to more familiar constructs to try to parse proposal examples.
I think being confused about these examples says something, but I think that a little familiarity will go a long way toward reducing confusion in the future, whereas being familiar with angle bracket syntax with inline signature annotations more than a decade has never made them much easier for me to parse when they're intermingled, as in C++ templates... So I'd really like to avoid that.
To reiterate, what really confuses my brain about angle bracket syntax is when it's mixed with function signatures, as in the type constructor declarations. For the purposes of the signature demonstration, I'll return to the map function example rather than the map data type example:
map<t, u>(fn: (x: t) => u, list: t[]) => u[];

IMO, this is even worse than the C++ & Java versions because of the arrow functions. Note how the closing angle bracket for the type parameter declaration looks visually very similar to the arrows in the arrow functions. My brain tries to match them up.
My brain also struggles with the groupings of type parameters and function parameters, mostly lost in the syntax noise.
I strongly prefer this version for declaration. Because the syntax noise from the angle brackets is gone, it lets the type parameters take a supporting role, rather than making them the noisiest part of the signature:
map t u (fn: (x: t) => u, list: t[]) => u[]

That allows my brain to much more easily focus on the important parts of the signature: the positions of the types within the signature body itself.
This is more important than it might seem at first, I think. Imagine you're driving a car, and there's some really important information in the dashboard about your engine overheating, warning you that the car's RPMs are 3x higher than the safe level. The trouble is, it's not flashing. It's not red. There's no motion drawing your eye to it.
You're driving a fancy new car with a GIGANTIC display off to the right. Normally that big display is showing you something innocuous like the name of the current track playing on your car stereo but right now it's flashing a bright red cryptic message at you -- you may be distracted and not notice the critical information tucked away in the dashboard dials.
In my brain, angle brackets mixed into function signatures has that effect. It draws my eyes and my brain's attention away from the signature itself, and to the angle brackets -- not even the contents of the angle brackets, but the brackets themselves. The thing is, in the context of the function signature, I don't believe that the brackets need to be there in the first place. In fact, I really like this form we discussed earlier:
map t u (fn: (x: t) => u, list: t[]) => u[]

So now that we've established that the space separated style might not work as well for invocation, I still want to have my cake and eat it, too.
Does it make sense to mix and match spaces for declarations and angle brackets for invocation?
map t u (fn: t => u, list: t[]) => u[]

interface mapStringsToStrings:
  map<String, String>

As @maiermic pointed out, part of the visual confusion still exists because you can pass an arrow function signature as a concrete type:
interface StringStringThing:
  MyInterface<String => String>

Which visually looks a bit like this:
interface StringStringThing:
  MyInterface<String => // wtf is the rest of that nonsense?

Which is why I like this version:
interface StringStringThing:
  MyInterface(String => String)

I was only worried for a moment because I thought it may be confused with this signature declaration:
MyInterface(String) => String

But in order to interpret MyInterface(String => String) as a constructor call, it's missing a bunch of stuff, like the interface keyword (only signatures are allowed to leave it off), the new interface name, and even the : could provide a clue if we disallow them in signatures. (see the previous example). In other words:
// Error: Unexpected token, `:`
MyInterface:(String => String)
           ^

Conclusion & Proposal

Parameter groupings are NOT required for type variable declarations (no need to mix  <> & () in function signatures). Hence, we should not use or allow them.
Parenthesis do NOT produce ambiguity in type constructor invocations. Hence, we should use () for invocations. They should be required, even if there is only one parameter, and no need for grouping.
I don't see the need for <>, and only @koresar seems to be championing them.

Questions:

Would anybody other than @koresar like to weigh in in favor of <> with any justifications we haven't already considered?
Am I missing any other ambiguities or issues with this proposal?

P.S. "Even Eric is confused."
This happens a lot, and should not be taken as evidence of anything particularly interesting. ;)

Looks like our brains work in a different ways.
To make the best decision we need to survey other people in order to understand how the majority of the developers' brains work.
Could you create a poll with a single question "What's more readable to you?" and three examples of the proposed syntax (space delimited, function-like, and angle brackets)?

I already started working on a survey of generic syntaxes. I'd like to give an overview of each syntax with description and examples. Further, I try to point out advantages and disadvantages as objective as possible.
Sadly, I'm really busy in the next weeks. Thus, it may take some time. Please be patient.
The examples are intended to cover all basic use cases of generics: functions, objects, methods (with additional generic types that depend on the parameters and are not defined on the object interface itself), considering type restrictions/bounds and declaration-site variance annotations. Am I missing something? They should be preferably familiar and not unnecessary complex. I'm open for suggestions. I miss good examples for type restrictions/bounds and declaration-site variance annotations yet. Any ideas?

If you do that just select an use case that is common for the examples.

Status RFC:
In the future, the rtype library will parse rtype strings and return a predicate function for type checking.

Given a generic interface (here written in function/parentheses syntax):
interface Collection(T) {
  // ...
}

How can we check the generic type at runtime?
import rtype from 'rtype';
// I don't know how type checking will look like. Thus, I define it like this:
/**
 *  Returns `true` if `a` is of type `t`, else `false`.
 *  (t: Rtype, a: Any) => Boolean
 */
const isOfType = rtype.isOfType;

// Collection(Any) => Void
function (c) {
  if (isOfType(Collection(Number), c)) {
    // ...
  } else {
    // ...
  }
}

In other words: How can we implement reified generics?
Note: Syntax does not really matter in this case.

@maiermic, my first-pass naive plan is essentially this:
Generics are parameterized functions which get compiled to concrete types based on the type parameters passed to them. Here's a naive first pass at the runtime compiler output for each type:
interface TypeChecker {
  interfaceName: String
  interfaceString: InterfaceString,  // original, unmodified interface string here
  isType?: Predicate, // For non-function types, a synchronous predicate returns true if input matches interface shape, false otherwise
  wrapper: WrapperFunction   // for functions, the wrapper optionally monitors arguments, return values, throws, and warns if they deviate from the described interface
};

For generics, the type parameter information could be included in the TypeChecker interface, but I thought it would be enough to fix them inside isType and/or wrapper.
If you see problems with that approach, I'd love to hear them.
See also https://github.com/ericelliott/rtype/issues/62

How does the corresponding JavaScript function isType of String[] and Number[] look like?

@maiermic
A runtime check would iterate through the Array and check that every element satisfies the .isType() check for String, or Number, respectively. Of course, that would be slow, which is why it's a good idea to turn off runtime checking in production.
Is it possible to combine compile time static analysis & runtime analysis to compile optimize runtime checking strategies?

How about empty arrays?
Pseudocode:
var a: String[] = [];

if (a is Number[]) {
  a.push(666); // `Number` is inserted into `String[]`
}

If there are no elements, then "every element" satisfies the .isType() check -- meaning there are no failing elements in the array... correct? =)

Sorry, I am short of time, but I try to explain the issue more clearly:
If array [] satisfies the runtime type check of Number[] and String[], we might push a Number into the array, because we think it is of type Number[], but a variable somewhere else, that stores that array, has been specified as String[]. Thus, we can unnoticeably store impermissibly a Number in String[].

Ah, I see what you mean. Yes, [] will satisfy the runtime check of Number[] and String[], but if there is an error, it would be caught the first time you type check the array with any value in it. Aside from that, though, a static analysis may be able to catch the error at compile time before it ever gets to runtime checks. =)

Static analysis is not able to catch the error :worried:  Runtime checks are only used if static analysis does not provide (enough) detailed type information (for example type is Any). Otherwise, a runtime check wouldn't be necessary.

Further discussion can be found in the RE: generic types syntax can be found in #80.


DV plan vs testplan

https://docs.opentitan.org/doc/project/hw_stages/#hardware-design-stages mentions things like "DV Plan available, testplan completed and reviewed". What's the difference between a DV plan and a testplan? Can we document that somewhere or link to it if this documentation already exists?
(And we should standardize in this document on "test plan" vs "testplan".)
CC @sriyerg @sjgitty

Done - #2071.


Bump DALI version to 1.22

Signed-off-by: Rafal<EMAIL_ADDRESS>

CI MESSAGE: [7063727]: BUILD STARTED

CI MESSAGE: [7063727]: BUILD PASSED

CI MESSAGE: [7188991]: BUILD STARTED

CI MESSAGE: [7188991]: BUILD PASSED


NaN handling problems in plots?

@e-koch this is referencing https://github.com/camelot-project/database/pull/107
Are there problems handling nan entries in tables when plotting?

@keflavich - Wrong repo? I thought it would be, but matplotlib seems to be handling it.

....yes, wrong repo... don't know how that happened, thanks.


[firebase_analytics] Plugin does not properly report all types of route changes

If you replace or remove the current route, I would expect it to be reported by FirebaseAnalyticsObserver; however, that class does not observer didRemove nor didReplace.

@alanrussian
The issue at https://github.com/flutter/flutter/issues/20452 has been closed and moved here. Future collaboration on this issue will be done here.

Given the age of this issue and lack of activity; I'm going to close this issue in favour of trying the latest release.


[Discussions] Cache image in Android

Content
I cannot enable the cache of network images in Android. When the cache is set to True, the image will be an error because it did not find the local cache file

any error log or a runnable simple demo?

Hello @zmtzawqlp,
This is my code:
    return ExtendedImage.network(       Network().getFile(         url,         thumbnail: thumbnail,         isProfile: isProfile,       ),       cache: true,       cacheMaxAge: const Duration(minutes: 5),       cacheKey: url,       loadStateChanged: loadStateChanged ?? defaultLoadStateChanged,       constraints: constraints,       fit: boxFit,       shape: shape,       borderRadius: borderRadius,       clipBehavior: Clip.antiAliasWithSaveLayer,       border: border,       // cache: false,     );
And error logs:

__I/flutter ( 9866): PathNotFoundException: Cannot open file, path = '/data/user/0/com.example.vifa_client/cache/cacheimage/u/89/9734efaa-8595-56ff-b26b-10765d79fa24.jpg' (OS Error: No such file or directory, errno = 2)
I/flutter ( 9866): Bad state: Cannot add event after closing

please provide more info about this issue, i can't reproduce it at my side


Remove version: OmegaT.OmegaT version 6.0.0

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

URL: https://sourceforge.net/projects/omegat/files/OmegaT - Standard/OmegaT 6.0.0/OmegaT_6.0.0_Windows_64_signed.exe/download
OK
(Automated message - build 923)

URL: https://sourceforge.net/projects/omegat/files/OmegaT - Standard/OmegaT 6.0.0/OmegaT_6.0.0_Windows_64_signed.exe/download
OK
(Automated message - build 923)

URL: https://sourceforge.net/projects/omegat/files/OmegaT - Standard/OmegaT 6.0.0/OmegaT_6.0.0_Windows_64_signed.exe/download
OK
(Automated message - build 923)

URL: https://sourceforge.net/projects/omegat/files/OmegaT - Standard/OmegaT 6.0.0/OmegaT_6.0.0_Windows_64_signed.exe/download
OK
(Automated message - build 923)

URL: https://sourceforge.net/projects/omegat/files/OmegaT - Standard/OmegaT 6.0.0/OmegaT_6.0.0_Windows_64_signed.exe/download
Status Code: 200
(Automated message - build 900)


PL-464 remove micrometer-atlas dependency

Remove micrometer-atlas dependency.
It is causing issues in Spring as it autoconfigures use of Atlas registry which may not be present and causes attempts to send metrics that fail with warnings.
It was added by mistake and not actually needed.
Checklist

[ ] Documentation (if applicable)
[X] Changelog

@rkolesnev any idea when the next release will be available?

@rkolesnev any idea when the next release will be available?

@krvajal - can't give a specific date, but we should have it released soon - mainly a bugfix realease.