work in SML/NJ, but not in SML#

Hi, I'm looking for a ML-family language which supports record subtyping and thanks for your project :p
I saw "SML# is compatible with SML/NJ."
https://github.com/juniorxxue/tapl/blob/main/ImperativeObjects.sml
Here's my code, which works in SML/NJ
It pops some error in SML#:
ImperativeObjects.sml:6.33(88)-6.33(88) Error:
  (name evaluation "190") unbound variable: !
ImperativeObjects.sml:7.35(127)-7.36(128) Error:
  (name evaluation "190") unbound variable: :=
ImperativeObjects.sml:7.40(132)-7.40(132) Error:
  (name evaluation "190") unbound variable: +
ImperativeObjects.sml:7.42(134)-7.42(134) Error:
  (name evaluation "190") unbound variable: !
ImperativeObjects.sml:23.30(318)-23.30(318) Error:
  (name evaluation "190") unbound variable: !
ImperativeObjects.sml:24.32(354)-24.33(355) Error:
  (name evaluation "190") unbound variable: :=
ImperativeObjects.sml:24.37(359)-24.37(359) Error:
  (name evaluation "190") unbound variable: +
ImperativeObjects.sml:24.39(361)-24.39(361) Error:
  (name evaluation "190") unbound variable: !
ImperativeObjects.sml:34.30(482)-34.30(482) Error:
  (name evaluation "190") unbound variable: !
ImperativeObjects.sml:35.32(518)-35.33(519) Error:
  (name evaluation "190") unbound variable: :=
ImperativeObjects.sml:35.37(523)-35.37(523) Error:
  (name evaluation "190") unbound variable: +
ImperativeObjects.sml:35.39(525)-35.39(525) Error:
  (name evaluation "190") unbound variable: !
ImperativeObjects.sml:36.34(563)-36.35(564) Error:
  (name evaluation "190") unbound variable: :=

I haven't found enough examples to compare the diff between syntax of SML# and SML/NJ.
Do you have any suggestions for me?
Thanks for your time.

I suggest you to run your program in the interactive mode of the SML# compiler. Similarly to SML/NJ, you can use the "use" feature in the interactive mode like this:
$ smlsharp
SML# 4.0.0 (2021-04-06 05:12:50 JST) for x86_64-apple-darwin20.3.0 with LLVM 12.0.0
# use "ImperativeObjects.sml";
type Counter = {get: unit -> int, inc: unit -> unit}
val c = {get = fn, inc = fn} : {get: unit -> int, inc: unit -> unit}
val newCounter = fn : unit -> {get: unit -> int, inc: unit -> unit}
val newResetCounter =
  fn
  : unit -> {get: unit -> int,     inc: unit -> unit,     reset: unit -> unit}
val inc3 = fn : {get: unit -> int, inc: unit -> unit} -> unit
val rc =
  {get = fn, inc = fn, reset = fn}
  : {get: unit -> int, inc: unit -> unit, reset: unit -> unit}

To generate a standalone executable file, an interface file (ImperativeObjects.smi) is needed to tell the compiler that your code uses the basis library.  The content of ImperativeObjects.smi should be the following:
_require "basis.smi"

thanks, work for me


first and last day columns for the general ledger model

Is there an existing feature request for this?

[X] I have searched the existing issues

Describe the Feature
I think it would be a good idea to add the 'period last day', and 'period first day' columns to the GL table.
I find it more efficient/useful to work from the GL table, as opposed to the GL by period table, so I have the detail/drill through. Since most reporting is done on a monthly basis and the Profit and Loss model is currently all rolled up to the period_first_day, I think it would be a helpful feature to just have these columns included in the GL as it allows for easier reporting.
Describe alternatives you've considered
I am currently just adding the column myself in snowflake, when I push to our production database
CREATE OR REPLACE TABLE GL AS
SELECT *,
DATE_TRUNC('MONTH', TRANSACTION_DATE) AS PERIOD_FIRST_DAY,
CASE WHEN LAST_DAY(TRANSACTION_DATE) = TRANSACTION_DATE THEN TRANSACTION_DATE
ELSE LAST_DAY(TRANSACTION_DATE)
END AS PERIOD_LAST_DAY
FROM (SELECT *
FROM PC_FIVETRAN_DB.QUICKBOOKS_QUICKBOOKS.QUICKBOOKS__GENERAL_LEDGER
WHERE 1=0);
INSERT INTO GL

Are you interested in contributing this feature?

[X] Yes.
[ ] Yes, but I will need assistance and will schedule time during your office hours for guidance.
[ ] No.

Anything else?
No response

Hey @caffeinebounce, thank you for your engagement in our Quickbooks package!
I just wanted to make sure I understand your request properly. To confirm, are you requesting that we add two additional columns to our quickbooks__general_ledger model -- one that is the first day of the month of the transaction and one that is the last day of the month of the transaction?


Remove note about language server fork

My understanding of https://github.com/jupyter-lsp/jupyterlab-lsp/issues/272#issuecomment-891286446 is that these changes how now been merged into the python-lsp conda package and there is no need to install the forked language server separately, is this correct?
Does that mean that the recommended way to install jupyterlab-lsp including all the speed-ups is just:
conda install jupyterlab-lsp python-lsp-server

And there is no need to disable Jedi, since the updates to the pylsp also improved the slow Jedi calls?
I have some issues with completion speed and can open a ticket with more info, but I just wanted to make sure that I followed the recommended installation procedure first.

Not all changes were merged but indeed for now it's better to remove this note


Can't UnArchive file small than 74 byte

You can create a txt just with one word "Hello",then Archive it to 1.zip,ssziparchive can't unArchive it.

Please create a PR with the related improvements. Thanks!

I test it with 5 byte Archive file and it's unArchive it ,without any problem
please accept my pull request that have a test of this case

In #154.


chore: fix cspell errors and enable spell-check in planning directories

Description

fix all cspell errors in planning directories
enable spell-check-partial for planning directories

Tests performed

build test by GithHub Actions
spell-check-partial by GitHub Actions

Effects on system behavior

None
Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.

After all checkboxes are checked, anyone who has write access can merge the PR.

@TakaHoribe @rej55 @mkuri
Could you review as code owners of motion_velocity_smoother?

@HansRobo Sorry for late review. Thank you for fix!


Open with remote container from "code" command

When working with a remote container on my WSL machine, I run code . to open the project, then I need to open the command palette and then select the "Remote-Containers: Reopen in Container" command.
This seems like a waste of time. It would be better if running code . or code --remote . could detect the presence of a devcontainer.json file and open in the container rather than in WSL.

Duplicate of https://github.com/microsoft/vscode-remote-release/issues/4684


Feature/check application exists

Problem
What problem or issue does this pull request solve [Jira](https://cruzhacks-dev.atlassian.net/jira/software/c/projects/C2D/issues/
C2D-48
Solution
What I/we did to solve this problem

I created an endpoint to check if an application exists or not and the status of that application
Created unit tests to test responses of endpoint

Change Summary:

Created /checkApp endpoint
Created Unit tests for endpoint

Dev-Ops
If you added an ENV variable, please check off that you've updated the following

[ ] GCP Secret Manager (Both development and production)

Images/Important Notes (optional):

Insert any notes/issues, dependencies added or removed, or images

@Alperdec That .get() shouldn't be returning a promise so it should be fine. I ran tests before and it worked so it should be fine. If .get() is just resolving really quickly and is actually a promise, we can add await before it.


Add Prettier dependency and create config file

To define the formatting rules for everyone and keep code clean and consistent.

Go for it


1.6 Preview 1: Breaks resource lookups from referenced libraries using full resource paths. Exception: 'ResourceMap Not Found'.

Describe the bug
Apps that reference libraries or library projects that contain either resx or resw resource files can no longer do resource lookups using their full paths.
Resource lookups via ResourceLoader.GetForViewIndependentUse() and passing a resource path such as "App1Library/Resources" throw the following exception:

System.Runtime.InteropServices.COMException
HResult=0x80073B1F
Message=ResourceMap Not Found.
ResourceMap Not Found.
Source=WinRT.Runtime
StackTrace:
at WinRT.ExceptionHelpers.g__Throw|38_0(Int32 hr)
at ABI.Windows.ApplicationModel.Resources.IResourceLoaderStatics2Methods.GetForViewIndependentUse(IObjectReference _obj, String name)
at Windows.ApplicationModel.Resources.ResourceLoader.GetForViewIndependentUse(String name)
This exception was originally thrown at this call stack:
WinRT.ExceptionHelpers.ThrowExceptionForHR.__Throw|38_0(int)
ABI.Windows.ApplicationModel.Resources.IResourceLoaderStatics2Methods.GetForViewIndependentUse(WinRT.IObjectReference, string)
Windows.ApplicationModel.Resources.ResourceLoader.GetForViewIndependentUse(string)
AIForged.Helpers.ResourceExtensions.GetLocalized(string, string) in Tools.ResourceExtensions.cs
This even affects controls from vendors such as Syncfusion.
Steps to reproduce the bug

Create a WinUI 3 class library with WindowsAppSDK 1.6 Preview 1 and call it App1Library.
1.1 Add a resource (resx or resw) file and add some strings to it.

Create a WinUI 3 desktop app with WindowsAppSDK 1.6 Preview 1.
2.1 Add a reference to App1Library
2.2 Attempt to retrieve a resource via ResourceLoader.GetForViewIndependentUse() using the full resource path such as "App1Library/Resources".

Expected behavior
This worked in 1.5 and earlier versions.
Screenshots

NuGet package version
Windows App SDK 1.6 Preview 1: 1.6.240807006-preview1
Packaging type
Packaged (MSIX), Unpackaged
Windows version
Windows 11 version 22H2 (22621, 2022 Update)
IDE
Visual Studio 2022
Additional context
No response

Potentially the same as, or related to, #4649.

This should be fixed with the change for #4649. Please let us know if you still repro this with 1.6-preview2.


Add Python 3.12

This PR will address issue https://github.com/apache/openwhisk-runtime-python/issues/149

@dgrove-oss fixes applied 👍


Changing the test for hasOwnProperty for a safer method

I encountered an error when I passed in an object automatically created by Restify. Apparently that object did not inherit from Object.prototype.

Correction, the object that was produced was produced by SugarJS. At any rate, hopefully you merge this push :)

Thanks for the PR.
Cheers


kAudioUnitErr_TooManyFramesToProcess when screen is locked

I tried background playing. However, when I locked my screen. I got the following errors:
2018-12-17 17:03:15.748156-0500 TestSGPlayer[12652:8357908] kAudioUnitErr_TooManyFramesToProcess : inFramesToProcess=3763, mMaxFramesPerSlice=1156
In addition, the background playing paused when the screen is locked.
How do I solve it?

If l locked the screen when not playing video, I got the following errors:
2018-12-17 17:29:03.497014-0500 TestSGPlayer[12808:8372523] dnssd_clientstub write_all(4) DEFUNCT
2018-12-17 17:29:03.499384-0500 TestSGPlayer[12808:8372523] dnssd_clientstub deliver_request ERROR: write_all(4, 73 bytes) failed
2018-12-17 17:29:03.499827-0500 TestSGPlayer[12808:8372523] dnssd_clientstub write_all(4) DEFUNCT
2018-12-17 17:29:03.582836-0500 TestSGPlayer[12808:8372534] [avas] AVAudioSessionPortImpl.mm:56:ValidateRequiredFields: Unknown selected data source for Port Speaker (type: Speaker)


add a little more detail to README.md

hi,
how will it help the students and mentors with their tasks?  Please tell something about it too. Thank you

especially can you tell more about what tasks it will perform in order to help the students and mentors :smile:

Sure. Some info is there under features. At the moment the main plan is to help students with git. For example with students website. It's on GitHub pages. So to add ones information they have to make a git commit. Though it's fun using git with a terminal emulator maybe it's easier with a graphical interface. 😀
Moving on we can allow students and mentors manage there GitHub repositories. Desktop notifications for GitHub events, managing licenses and readmes.
We can also use the api of codein.withgoogle.com for mentors. I will add those info with time.

@roonyh how will we solve the binaries problems for electron and nodegit? If I am right, nodegit has separate binaries for each platform, can electron take care of that as well?

@roonyh how about focusing on UI and front end with electron and using nodegit at a backend? It will save us hassle of replying why's and why nots?

i am just asking would it be a viable option to keep nodegit at the backend? :smile:

We don't need to worry about the correct binary. see http://www.nodegit.org/guides/install/electron/
npm install will fetch the correct binary based on the entry for engine. yay!
But I noticed that having the same node version as the electron version (5.1.0 for latest electron) is important. Maybe npm install builds nodegit locally. All in all its not a problem.

I assume backend = main process and frontend = renderer process.
So you suggest that we start a node server and make ajax requests to it from renderer processes? Hmm yes that would be ideal. But development would be easier the current way. And we will use seperate modules to keep nodegit seperated from frontend so if the need arises we will do it that way.
At the moment I am excited about making a usable app than worrying too much about the architecture. I don't think the electron community themselves clear conventions about those things :)

@roonyh seems cool! thanks for clearing out


Const/static type annotation elision

A proposal to allow elision of type annotations in many cases for const and static items, as part of the ergonomics initiative
Rendered

:-1: , for several reasons:

It would introduce an inconsistency with other items living at the same level as const's and statics, fn's. The type of functions can't be elided.
It would make the language harder to learn as you now need to know when you can omit the type and when not. The current rule is strict and simple. Yet another scary area for beginners to not know about!
Like proposals that want to introduce the elision of function signature types via their bodies, its bad on the reader to force them to go through another layer of implementation and check the type. Especially as it may mean the reader may have to follow several layers of function definitions, e.g. you have const FOO = (Foo { i: 2}).bar().baz().boo(), and each of bar, baz and boo were complicated functions returning generic types that themselves depend on trait impls.
The RFC author claims that IDEs can help with the aforementioned issue, but IDEs can also help to put the type annotation into place automatically for those who feel its too much a burden (see more on that below). You shouldn't be forced to use an IDE when reading code! I regularly read code on Github for example, and don't want to clone something locally just so that I can find out which type a const has. That's not more ergonomics, thats less of it.
The ergonomics with consts is just fine. Usually you have to make one const or two per crate, then its bearable to type out the type annotation. Sometimes you also need to do more const elements, but then their type is usually the same and you can just do a macro to define them. You'll arrive at a much smaller character count with a well engineered macro as with the proposal, as you won't have to type out "const" each time!
There is nothing gained in raw character count by writing const FOOBAR = 43i32; instead of const FOOBAR: i32 = 43; (I'm not proposing that for integers/floats the default type is chosen, in fact I dislike this RFC less in the current form). The only place where you spare characters is when you type const FOO = (Foo { i: 2}).bar().baz().boo(), as that may return an arbitrarily complicated type. But these cases are precisely those where points 3 and 4 are extremely relevant. Limiting the functionality of this RFC to literals only solves the issues 3 and 4, but (except for &str and ()) not this issue.

@est31 as you laid this out, I see something that I think might be interesting: impl Trait for consts.

A more conservative alternative would be to allow the type to be elided only when the RHS consists entirely of literals. So for example you could write const FOO = Foo { x: true }; instead of const Foo: Foo<bool> = Foo { x: true };, because in that case the type is completely obvious "from the definition itself", and in a sense redundant. The difference relative to the RFC would be that if the definition of the const refers to other consts (resp. statics) or const fns, then a type annotation would still be required. This would more-or-less address the objection of having to track down various definitions manually to be able to reconstruct in your head what type the compiler will infer, and also the one where changing an item in the API could otherwise have "non-local effects" where it would result in the types of other items also silently changing.
(This would presumably be true only for monomorphic literals, so for example 5 and None would still require an explicit type. An interesting question is whether e.g. given struct Bar(Foo);, you would be allowed to write const BAR = Bar(FOO);, that is whether references to other consts would be allowed if it can't affect the type of the const itself, but probably still no for simplicity and consistency's sake.)

@est31 Regarding functions, this proposal is more like inferring the return type of a function, but not its argument types (perhaps that's what you meant). However, constants are most often very simple things where the type is obvious, while functions tend to be much harder to mentally type-check at a glance.
Generally, I expect most constants/statics will be simple expressions with an obvious type, and even the use of constant functions will likely be more for things like AtomicUsize::new(0) than something like (Foo { i: 2}).bar().baz().boo(). In those cases where the expression is more complicated and where documenting the code is important, developers should be encouraged to leave the type annotation in.
I agree that the complexity of when an annotation can be elided or not is problematic, and this is probably the biggest downside of the proposal. Ideally we eventually find that there's little harm in allowing the fallback rules to apply here and change the rule to always allow type elision. This proposal would be a conservative step towards that, but admittedly there's no guarantee it happens. In the meantime, I think good error messages could ease this pain for beginners.

@glaebhoerl Leaving aside const functions for a moment, would you say that even using other constants in the definition of a constant makes its type hard to determine in real programs? I would think in most cases where this happens the referenced constant's type would be obvious (by context and/or by the constant's name and/or because it's a well-known constant), but my experience is limited.

FWIW, we have the compiler infrastructure to determine the type of a global by type-checking its body and you get automatic cycle detection, enforcing a DAG between such global items.
We'll need to do something like that if we want to add typeof too.

In my opinion, this should be consistent with the rules of global items always requiring annotations, but allowing inference for function-local items.
Under this rule, we could allow inference for consts that are local to a function. This would also help with the ergonomics of using const fn for forcing compile-time evaluation.

@crumblingstatue Items, placed in a function, are still quite global, e.g. you can use them in an impl of a public trait for a public type, that is placed within the same function.

@eddyb Oh, never mind then.
Just curious: Is there any legitimate use case for impling an outside item inside of a function?

It's not explicitly supported - it just results from the fact that everything that can go directly in a module also can be inside any block expression - yes, this includes extern crate and nested mod.

@schuster

Leaving aside const functions for a moment, would you say that even using other constants in the definition of a constant makes its type hard to determine in real programs?

I don't really have an opinion. My comment was just like "if we think that's a problem, then another option is..."

@crumblingstatue
Sure. e.g. if a function wants to do a visitor pass, then we can create the visitor and its impls inside that function instead of in the module, e.g. this: https://github.com/rust-lang/rust/blob/master/src/librustc_mir/transform/mod.rs#L74 - this is more useful if your functions are impl-items, so you would have to add the struct outside of the impl.

Thanks @schuster for the RFC, and thanks to those who've commented so far!
It seems opinions thusfar have been mixed. Let me start by covering what are, in my mind, the most important drawbacks raised so far.

Moving away from the rule that "all top-level items are fully type-annotated".

The stated downside here is that the language becomes less consistent, and harder to learn, because the need for type annotations varies in a more subtle way.
There is, however, a simple counter-argument. If we allow statics and consts to leave off type annotations, then they come to resemble let bindings, leading to a simple rule: forms that bind variable names do not require type annotations; forms that define functions do.
More generally, I don't think that most people, when learning static and const definitions, think immediately in terms of the top-level items rule above; that's a pretty sophisticated generalization. Rather, they learn: "this is how you declare a constant".

Having type annotations be sometimes required is again a source of inconsistency or unpredictaility.

Undeniably true! However, again thinking by analogy to let, this is already the case with type inference. In isolation, let x = None; fails to compile and requests a type annotation. The situation with constants and statics would be identical. There is, however, an argument that integer fallback should be allowed, to make the match between let, const, and static more complete.

I think the above are the most significant drawbacks, so I'll stop there for the sake of keeping debate focused.
On the positive side, to me a pain point is the need for inelegant, noisy stuttering:
static COUNT: AtomicUsize = AtomicUsize::new(0);
const USER_VISIBLE: Flags = Flags { /* ... */ };

In cases like these, readability is helped by leaving off type information, because it's easier to quickly see the relevant information and not have to skip over stuttering.
I'd love to see examples from real code where it would be possible to leave off a type annotation, and that would significant impair the reader's ability to determine the type.

@aturon I think one potentially-scary-seeming drawback is that you might modify one part of your public API, and accidentally end up changing another part of it as well, because the type of the second was inferred from the first. I honestly don't have any idea whether this would be a thing that actually happens in practice. Has anyone had any experience where they changed the type of a thing in their API, got a type error on a const or static definition whose type depended on it (because the existing ascribed type was now incorrect), and thought "oh crap, I forgot that would also be affected", rather than "oh jeez I forgot to update that type accordingly"?
For that matter, it could happen cross-crate as well.

Wouldn't that "unexpected" change be what you'd intend to do anyway?
Accidental semver changes on constants are a very unlikely problem that can be discovered by automated tools. As much as I'm against giving programmers more decisions, in this case I support elision. You can let the author decide whether they want the type inferred or not, same as with locals.

You can still teach this in parallel with eliding type annotations for let even if you require type annotations on exported const and static.  Also, any exported const defaulting to i32 over usize will create problems.

@le-jzr

Wouldn't that "unexpected" change be what you'd intend to do anyway?

That's what my question ("Has anyone had any experience where ...") was about.

@glaebhoerl To make this concrete, you're proposing a scenario like the following, right? Somewhere in a crate, we have:
const FOO: i32 = 5;

and elsewhere (in this crate or in another one that imports the first) we have:
const BAR = (FOO); // inferred type is (i32)

Then if someone changes the annotation on FOO to i64 instead, BAR's inferred type would change to (i64), even though we didn't touch BAR's definition.  The problem being that this could break uses of BAR somewhere down the line.
I agree with @le-jzr that this seems unlikely in the cross-crate scenario, which seems like the more dangerous of the two (because the person who makes the change and the person who notices a problem are not the same). But like you, I'm also curious if anyone has had the kind of experience you're asking about.

cc @rust-lang/lang, it'd be good to start getting some additional thoughts on the tradeoffs here. I've written up a summary with my own thoughts about some of the arguments.

@aturon
To my mind, you hit the nail on the head with this observation:

There is, however, a simple counter-argument. If we allow statics and consts to leave off type annotations, then they come to resemble let bindings, leading to a simple rule: forms that bind variable names do not require type annotations; forms that define functions do.

In particular, I've been trying to put my finger on why this RFC feels like such a win to me, whereas eliding return types on functions does not. I think it is precisely a question of the analogy with let, and the fact that I am accustomed to declaring values without having to state their types.
I also frequently find that I am making constants that are not "top-level constants" but rather constants within a function. In that context, they are technically nested top-level items, but my brain does not process them that way:
``rust
fn process_items(vec: &[i32]) {
const CHUNK_SIZE = 32; // requiring : usize = 32 doesn't feel like a win here
for chunk in i.iter().windows(CHUNK_SIZE) { ... }

}

On the *other* hand, this example raises an interesting point. =) In particular, *that* bit of code would not work with this RFC, since I believe it would require a type annotation and, even if it didn't, it would presumably infer to `i32`, which is not what I want here. That's disappointing, as I think integral constants are pretty dang common.

Regardless, there are other examples (e.g., string constants, or more complex constants) that fit the mold.

I've checked my code,

Almost all const/static used are integers or integer arrays (usize, [u32; N] etc), so this RFC won't help at all.
Most complex types (Regex, HashMap etc) appear in lazy_static which is not able to benefit from this RFC.

How crazy can one get with initialization expressions?  Are they full expressions?  I assume that, the same way the goal is to eventually allow more and more in a const fn, a const initializer could get arbitrarily complex.  So I could imagine this being legal, but where I don't think omitting the type would be a win:
const FOO: String = {
    let mut n = other::bar();
    let mut x = Default::default();
    while n > 0 {
        n -= 1;
        x += &n.to_string() as &str;
    }
    x
};

My intuition is towards some sort of restriction here to the inelegant, noisy stuttering cases.
This doesn't need to be done all in one go, right?  Maybe we just start with "if it's a struct literal with fully-specified type or a method call that returns Self on a fully-specified type".  Other restrictions can always be lifted later.

You could solve that "latex style" with a macro by including the value with include_bytes! or include_str! and building that file when running tests.  I'm not sure how you'd make those tests run first though.  Also if you're avoiding lazy_static! then those computations might be slow enough that you'd want a separate generate feature.

@nikomatsakis In that example, what's the benefit in marking CHUNK_SIZE as const? Seems to me like let does the same thing, but maybe I'm missing something.

@kennytm Hmm, that's too bad, I had hoped this would be more widely applicable. Did you get the sense for how many of those integer constants were i32 (and therefore would be okay if we used the standard fallback rule), or whether any of the constants were unused in their crate?
@scottmcm Constant expressions are indeed restricted. For instance, you can't use assignment, loops, or non-const function calls. According to my research, constants/statics can include only:

literals
(module) path expressions
tuples, structs, tuple structs, and unit structs
const function calls
field references from a struct
arrays
index expressions
range expressions
unary and binary operator expressions
blocks that include the above and any items that can appear in a struct (e.g. other consts, functions, struct definitions, impl blocks, etc. (although I'm not sure why you would want to use those in this context))
variables

So, I think it might already be restricted the way you want?

@schuster Those restrictions are implementation limitations, also see https://github.com/solson/miri.

So, I think it might already be restricted the way you want?

What qualifies as constant expression will be expanded in the future, so just relying on "its a constant expression" is not enough.

@schuster None of the numbers are i32 😢. All of them are used internally, but I don't think it matters.
My code
custom_keylayout/src/args.rs
10:const USAGE: &'static str = "
37:const LONG_HELP: &'static str = "

custom_keylayout/src/fsm.rs
8:pub const EMPTY_STATE: FsmState = 0;

custom_keylayout/tests/test_parse_compose.rs
6:const TEST_COMPOSE_FILE: &'static str = r#"
34:const TEST_RESULT: &'static str = "\

extprim/src/i128.rs
21:pub const BITS: usize = 128;
24:pub const BYTES: usize = 16;
27:pub const MIN: i128 = i128(u128 { lo: 0, hi: 0x8000000000000000 });
30:pub const MAX: i128 = i128(u128 { lo: !0, hi: 0x7fffffffffffffff });
33:pub const ZERO: i128 = i128(::u128::ZERO);
36:pub const ONE: i128 = i128(::u128::ONE);

extprim/src/u128.rs
24:pub const BITS: usize = 128;
27:pub const BYTES: usize = 16;
30:pub const MIN: u128 = u128 { lo: 0, hi: 0 };
33:pub const MAX: u128 = u128 { lo: u64::MAX, hi: u64::MAX };
36:pub const ZERO: u128 = MIN;
39:pub const ONE: u128 = u128 { lo: 1, hi: 0 };

mbox/src/placer.rs
22:pub const MALLOC: MallocPlacer = MallocPlacer(());

mbox/src/internal.rs
56:pub const NON_MALLOC_PTR: *mut c_void = 1 as *mut c_void;

qrcode.rs/src/bits.rs
607:static DATA_LENGTHS: [[usize; 4]; 44] = [

qrcode.rs/src/ec.rs
234:static EXP_TABLE: &'static [u8] = b"<snip>";
237:static LOG_TABLE: &'static [u8] = b"<snip>";
248:static GENERATOR_POLYNOMIALS: [&'static [u8]; 70] = [
330:static EC_BYTES_PER_BLOCK: [[usize; 4]; 44] = [
392:static DATA_BYTES_PER_BLOCK: [[(usize, usize, usize, usize); 4]; 44] = [

qrcode.rs/src/optimize.rs
582:static STATE_TRANSITION: [(State, Action); 70] = [

qrcode.rs/src/canvas.rs
478:static ALIGNMENT_PATTERN_POSITIONS: [&'static [i16]; 34] = [
824:static VERSION_INFO_COORDS_BL: [(i16, i16); 18] = [
833:static VERSION_INFO_COORDS_TR: [(i16, i16); 18] = [
842:static FORMAT_INFO_COORDS_QR_MAIN: [(i16, i16); 15] = [
848:static FORMAT_INFO_COORDS_QR_SIDE: [(i16, i16); 15] = [
853:static FORMAT_INFO_COORDS_MICRO_QR: [(i16, i16); 15] = [
858:static VERSION_INFOS: [u32; 34] = [
1560:static FORMAT_INFOS_QR: [u16; 32] = [
1567:static FORMAT_INFOS_MICRO_QR: [u16; 32] = [
1823:static ALL_PATTERNS_QR: [MaskPattern; 8] = [
1830:static ALL_PATTERNS_MICRO_QR: [MaskPattern; 4] = [

libimobiledevice-rust/libplist/src/internal.rs
10:pub const TIMESTAMP_OFFSET: i64 = 978307200;

Types which can be elided by this RFC are (seems to be 49% of total):

Strings.
Some byte strings? But byte strings are inferred as &[u8; N], so it won't benefit that [&[u8]; 70] thing.
Enums (MaskPattern, State, Action)
Structs (u128, i128, MallocPlacer)
That cast expression 1 as *mut c_void.

@kennytm Well, the internal use tells me it might at least be safe to use the i32/f64 fallback rules. Obviously that doesn't help your case too much, but it could simplify the overall elision rules.
Still, I'm glad at least a fair number of your types could be elided.

In that example, what's the benefit in marking CHUNK_SIZE as const? Seems to me like let does the same thing, but maybe I'm missing something.

Nothing really. I just like to write const when it's a compile-time constant. And if I write let CHUNK_SIZE = 64 the lints whine at me. =)

@glaebhoerl @scottmcm

A more conservative alternative would be to allow the type to be elided only when the RHS consists entirely of literals.

This seems a bit too restrictive to me, but I do think there might be room to do something more syntactically targeted to start. I wonder if that would wind up feeling even more confusing though (why do I need a type here but not there?).

@nikomatsakis

Nothing really. I just like to write const when it's a compile-time constant. And if I write let CHUNK_SIZE = 64 the lints whine at me. =)

Oh, hmm. That kind of const would be inaccessible from outside the function, right? That makes me think that const/static items declared inside functions like that (but not further nested into an impl block or other non-function items) should use the same non-local inference rules as let-bound variables. After all, in this case the scoping rules would appear to be the same. Then the general rule would be "elision is okay in a function context whenever it's okay for let, and okay outside of a function context as long as local inference without fallback rules can find a unique type".
Perhaps that's enough of a change that it should go into a separate RFC, though. Thoughts? (on whether it's a good idea, and whether it should be an independent RFC?)

A bit of motivation: This would remove boilerplate when using associating constants, e.g.:
trait Bit {
    const VALUE: bool;
}

impl Bit for T {
    const VALUE: bool = true;
}

Here, having to repeat the type of the constant is just annoying as it is obvious from the trait definition.

@mglagla In trait impls we could theoretically allow it even for methods.

In my opinion, allowing elision should be context-dependent, where it's allowed in cases like @mglagla's example, and not allowed in contexts where it would either require global inference, or make an API less obvious (e.g. eliding them for module-level consts, or "using them in an impl of a public trait for a public type").
The ergonomic wins are too big to miss out on in some cases, but can make inference suffer, and public APIs less obvious in others. It would be worth the extra complexity to "smart-allow" them in cases where they wouldn't have these drawbacks.

@crumblingstatue Can you give examples of cases where this RFC would make APIs less obvious (like your module-level constants or public-trait/public-type cases)?

@schuster Never mind, I completely misunderstood the RFC when I wrote that. "Obviousness" is not a problem with the inference rules that this RFC describes.

I'm trying to figure out how best to make progress here. It seems like the issues up for debate are, roughly:

Should we be less conservative with the fallback rules, and basically make the behavior match that of let (modulo local inference)?

Within function bodies, etc, should const behave exactly like let, i.e. take local inference context into account?

@schuster, what are your thoughts on these issues currently?

In addition there is also my suggestion to not do the change at all (which I prefer first), and the suggestion by @glaebhoerl to be more conservative and only allow the type to be inferred if only literals are involved (which I prefer second), no functions or anything else, see our two comments at the start of this thread.

@est31 Heh, yes the "null alternative" is always an option. I wasn't clear in my comment; I meant possibilities for evolution of this particular proposal, as compared to "big" alternatives like @glaebhoerl's.
I am curious what folks think of the principle that const should work as much like let as possible, and in a function body be identical (in terms of required type annotations)?

@aturon:

Should we be less conservative with the fallback rules, and basically make the behavior match that of let (modulo local inference)?

Yes, at this point I'm thinking we can be less conservative here. It sounds like most people who support the overall elision idea would like to have that as well, and the risk seems low. It also simplifies the rules programmers have to remember about when the type can be elided.

Within function bodies, etc, should const behave exactly like let, i.e. take local inference context into account?

I still think this is a good idea, but can someone confirm for me that a const inside a function body has the same scope as a let-bound variable? I don't know Rust well enough to say that for sure. If the scope is different, that might change my answer.
I'm also going to try downloading everything on crates.io and see if some simple grepping can get some hard data on how consts and statics are currently used.

@schuster

I still think this is a good idea, but can someone confirm for me that a const inside a function body has the same scope as a let-bound variable?

The scope is different (the whole block), same as for other items:
fn main() {
    let x = X;
    let y = f();
    println!("{} {}", x, y);

    const X: u8 = 10;
    fn f() -> u8 { 11 }
}

@petrochenkov That example seems okay, although this one I just found is a little more troubling:
fn main() {
    const X: i32 = 1;
    let y = 2;

    struct A {}

    impl A {
        fn foo(&self) {
            // X is in scope here, but fns cannot capture the dynamic environment,
            // so the compiler gives an error for y
            println!("inside bar: {}, {}", X, y);
        }
    }

    A{}.foo();
}

The scope still appears to restricted to the inside of the function, though (e.g. there's no way to say something like main::X from another function), so perhaps it's okay? It also seems unlikely a constant used in that context wouldn't be used in the immediate function body, and since it also wouldn't be part of a public API in that position, the type doesn't matter as much. So I think I've convinced myself even that case should allow elision.

If the ergonomic initiative wins on this front despite the opposition, my harm mitigation strategy would be similar to what was proposed by @glaebhoerl  - make this elision a very syntactic desugaring, without any type inference.
Parser would match the constant/static initializer expression with the next table and "copypaste" the type from the right side to the left side.
DESUGAR:
"xxx" => &'static str
b"xxx" => &'static [u8; len(b"xxx")]
b'x' => u8
'x' => char
10usize => usize // or other integer suffixes
10 => i32
10.0f32 => f32 // or other fp suffixes
10.0 => f64
true => bool
expr as TYPE => TYPE
expr: TYPE => TYPE
PATH { /*fields*/ } => PATH // note, no inference for generic parameters

Maybe, but questionable:
&expr => &'static DESUGAR(expr)
&mut expr => &'static mut DESUGAR(expr)
(expr) => DESUGAR(expr)
(expr1, expr2) => (DESUGAR(expr1), DESUGAR(expr2))

Even more questionable:
expr1 .. expr2 => ops::Range<DESUGAR(expr1)> // requires DESUGAR(expr1) == DESUGAR(expr2)
[expr1, expr2] => [DESUGAR(expr1); len([expr1, expr2])] // requires DESUGAR(expr1) == DESUGAR(expr2)
[expr; usize_or_unsuffixed_literal] => [DESUGAR(expr); usize_or_unsuffixed_literal]

This should happen even before macro expansion, because
const C = macro_that_can_expand_to_anything!();

is as bad as
const C = const_fn_that_can_return_anything();

@petrochenkov What makes you say the questionable cases are questionable? To my eye, the inferred type for those expressions seems just as obvious as the less questionable ones. Is it that having all of the structure around the expressions makes it harder to mentally infer the type than just reading an annotation like ops::Range<i32>?
Also, by no inference for generic parameters, do you mean that for example Some(true) would not infer to Option<bool>? I can see how that's a problem for a case like None, but in many cases that seems like an okay inference to make.

@schuster

What makes you say the questionable cases are questionable?

I've tweaked the table a bit and added comments.

Also, by no inference for generic parameters, do you mean that for example Some(true) would not infer to Option?

No, I mean const C = GenericStruct { field: 0u8 }; desugars into const C: GenericStruct = GenericStruct { field: 0u8 }; and not const C:  GenericStruct<u8> = GenericStruct { field: 0u8 };.
Option<bool> is obviously not inferred too, the goal is to have the type explicitly specified either on the left or on the right side of the item, and I don't see Some(true) saying Option<bool> anywhere.

I would rather see the annotation rules relaxed to: all publicly visible types must be annotated, otherwise they may all be inferred (including function arguments, but excluding trait definitions). This would prevent unfortunate cases where public APIs might change based on the implementation, unbeknownst to the author.

@petrochenkov Oh, now I see what you mean - you're really saying syntactically, meaning even ignoring whether we know whether a struct takes generic types or not. That GenericStruct example clears up my confusion, thanks.
Two interesting implications I notice from that proposal:

Some inferred types might not be valid types at all in that program, regardless of whether they're the correct type for that expression.
types for enums would not be inferred, which is consistent with not wanting to infer a type for an arbitrary name, other than a type-path

I'm still not convinced using the types from other known names would lead to a significant mental burden, but if it does come down to that, something closer to this could be a viable approach.

As a shepherd for the field of embedded applications, I would highlight one specific pattern:
static mut FOO_BUFFER: [u8; 1024] = [0; 1024];
do_something(unsafe { &mut FOO_BUFFER });

The reason this memory-unsafe pattern is extremely common is simple:

There is often no heap.
There are typically no mutable statics (other than the above).
The amount of RAM is small, so growing stack will eventually clash into constant data.
If you cannot detect stack overflows then you will get just extremely bizarre behavior as constant data is rewritten. If there are vtables then PC/LR may point into nowhere, which breaks debuggers.
Even if you can detect stack overflow at runtime, the ergonomics of this are atrocious: you would have to ensure that stack overflow detection works on your platform (which might involve writing assembly against undocumented LLVM stack probe function ABI and/or implementing the checks for LLVM on the target platform), and that you can separate it from other kinds of faults.

Conversely, allocating large (>> 16 bytes) buffers as mutable statics is a lot easier:

When a linker script is used, the buffers can be placed wherever convenient (e.g. sometimes there are several kinds of RAM).
When the buffers are larger than the area selected for them, the linker will immediately complain with an error specifically mentioning the offending buffer.
Sizes of various buffers may be estimated as easily as a single objdump invocation, even if they're derived from a configuration flag, const fn invocation, or the like.

Of course, such code is non-reentrant. However, in many applications, buffers are bound to a global resource, e.g.: ADC and a DMA ADC buffer, the single TCP socket the application has and its RX/TX buffers, and so on. Therefore it is trivial to verify that only one &mut to the buffer would exist.
cc @japaric who might have an opinion on this also.

@whitequark _ in an expression position doesn't already exist, whereas _ as a type and the omission of a type already exist. The former requires const generics (which add const inference variables) to work.

I finally got around to grepping through the existing crates in cargo (as of early July) to get some rough quantitative data on the use of constants. Keep in mind that since this is using some basic regex-matching rather than full parsing, the numbers could be a little off, but I think the ballpark figures should be representative.
I found 237,023 const items total. Of those, there were:

187,604 unsuffixed decimal literals (i.e. without a u8, i32, etc. suffix)
3,402 unsuffixed hex literals
224 unsuffixed octal literals
108 unsuffixed binary literals
79 byte literals
345 unsuffixed float literals
3,230 numeric literals of various types with a suffix
1,569 string literals
28,340 boolean literals (all but 79 seem to be an auto-generated MASK constant)
4,826 tuple-structs or function-call expressions (it's hard to tell these apart with just grep). The vast majority appear to be tuple-struct items of the form const SOME_CONST: SomeStruct = SomeStruct(...)
1,368 array literals (of various types; I haven't analyzed to see what type they are or how easy/hard each would be to infer a type for)
363 path expressions (i.e. expressions of the form foo::bar::baz, including just variables like foo)
1,110 uses of the "as" operator (distinct from all of the other categories)
312 struct literals. Of those, 45 have type parameters, and it seems none of them name that parameter on the right-hand side (which could make inference trickier)
4.269 "other" items. From a brief manual scan, the most notable category here is small math/bit-wise expressions like 1.0 / 3.0 and 1 << 6, but there are lots of other reasons an expression might be here - mostly more complicated syntax that grep couldn't handle easily. Lots of multiline strings got dumped in this category, too, because of the limitations of grep.

For the decimal literals, the type-breakdown is as follows:

168,441 u8 (although all but 336 of them are auto-generated MASK or OFFSET constants for different embedded platforms)
4,336 u16
3,883 usize
3,186 u32
1,923 PosixErrorNumber
1,861 ::c_int
886 ::libc::c_uint
846 c_int
468 i32
336 other uses of u8
154 speed_t
127 c_uint
126 ::libc::c_int
109 tcflag_t
all others had < 100 uses

For hex literals:

477 c_int
358 tcflag_t
353 u8
257 ::c_ulong
231 usize
221 c_ulong
203 u32
144 libc::c_ushort
138 VKCode
137 c_long
133 types::GLenum
111 ::tcflag_t
101 ::c_int
all others had < 100 uses

For floats:

219 f64
98 f32
< 10 for all others (various type aliases)

So far, this data tells me that the numeric literals used on their own are used in a wide variety of contexts; we can't assume that most places use the default of i32 or f64. That doesn't necessarily mean we shouldn't use the "default to i32/f64" rule, but at least for these cases it would seem to have limited benefit. Whether it could help with something like arrays is another story - I'm not sure how to easily analyze those cases.
What other information of this form would people like to see? For instance, I might be able to find the forms of the most frequent mathematical expressions and do some kind of analysis on those to see what arguments they take and what the expected type is.

Thanks for collecting this data!
I can't help but notice that autogenerated code seems to have significantly affected the weight of different types. I notice from what you've said:

237,023 const items total
28,340 boolean literals (all but 79 seem to be an auto-generated MASK constant)
168,441 u8 (although all but 336 of them are auto-generated MASK or OFFSET constants for different embedded platforms)

At minimum 196,366 of the 237,023 constants (or about 83% of them) are autogenerated. I imagine that some of the other types are autogenerated as well, though. Could you present the data without that autogenerated code so we can get a sense of the breakdown of types in code written by humans?

That's a good idea. I filtered out all entries from the auto-generated projects listed here (these all appear to be uses of svd2rust):

lpc43xx
nrf51
s32k144
stm32f072x-memory-map
stm32f0xx
stm32f100xx
stm32f103xx
stm32f303x-memory-map
stm32f30x-memory-map
stm32f30x
stm32f40x
stm32f429x
stm32l4x6-memory-map
stm32l4x6
tm4c123x
tm4c129x

That appears to have gotten rid of the main autogen constants that threw off the data. Here's what's left (some of the numbers actually increased slightly, probably due to performing the grep slightly differently):

12,305 unsuffixed decimal literals (i.e. without a u8, i32, etc. suffix)
3,249 unsuffixed hex literals
224 unsuffixed octal literals
102 unsuffixed binary literals
79 byte literals
344 unsuffixed float literals
56 numeric literals of various types with a suffix
1,527 string literals
77 boolean literals
4,820 tuple-structs or function-call expressions (it's hard to tell these apart with just grep). The vast majority appear to be tuple-struct items of the form const SOME_CONST: SomeStruct = SomeStruct(...)
1,369 array literals (of various types; I haven't analyzed to see what type they are or how easy/hard each would be to infer a type for)
358 path expressions (i.e. expressions of the form foo::bar::baz, including just variables like foo)
1,095 uses of the "as" operator (distinct from all of the other categories)
324 struct literals. Of those, 54 have type parameters, and still none name that parameter on the right-hand side
3,602 "other" items. Still appears to be the same distribution of other kinds of items as in the previous post.

Aside from the known differences in the decimal and boolean literals, the biggest change is in the numeric literals with suffixes: there are almost none now compared to the overall number of numeric literals.
New type breakdowns for unattributed numerics:
Decimals:

3,870 usize
1,923 PosixErrorNumber
1,861 ::c_int
886 ::libc::c_uint
846 c_int
462 i32
336 u8
263 u32
154 speed_t
127 c_uint
126 ::libc::c_int
109 tcflag_t
< 100 uses for all others

Hex literals:

477 c_int
358 tcflag_t
353 u8
257 ::c_ulong
221 c_ulong
203 u32
144 libc::c_ushort
138 VKCode
137 c_long
133 types::GLenum
111 ::tcflag_t
101 ::c_int
< 100 uses for all others

Floats:

218 f64
98 f32

So the numbers for decimal literals changed quite a bit, but the others are similar. This still supports the overall conclusion that defaulting to i32/f64 has limited benefit for the just-a-single-literal cases (which is where it's most likely to be unconstrained). Personally, I think it would still be better to use that default just to be consistent with other parts of Rust. What do others think (of that aspect and any other parts of this data)?

Personally, I think it would still be better to use that default just to be consistent with other parts of Rust. What do others think (of that aspect and any other parts of this data)?

I think the defaults are weakly documented, and having to know them wouldn't be nice from a learnability perspective. I think its harder to remember what the defaults are than remembering that you have to put type annotations on number literals.

If RFC 2071 "Add impl Trait type alias and variable declarations" ends up with the less conservative alternative (underlying type of impl Trait is revealed in the current module), it would be more or less equivalent to one variation of this RFC - type inference for private consts/statics.
$vis const C = init_expr;

could be then desugared into
trait Anything {}
impl<T> Anything for T {}

$vis const C: impl Anything = init_expr;

If C is used in the current module, it's type is not hidden.
If $vis is large enough for C to be nameable from other modules, it will be barely usable from there due to its anonymized type.
So the property of const signatures being "interfaces", like fn signatures, is kept, but only for outer modules.
cc @cramertj

@petrochenkov Which part of either RFC would allow the creation of a new alias like that? This one would only allow type elision if a unique type can be inferred locally, whereas many types could be inferred for your example (e.g. impl Anything1, impl Anything2, etc.). The other RFC doesn't seem to elide type annotations at all (unless I missed something; I didn't read it too closely).
So if both RFCs were accepted and implemented, I would expect your example (before desugaring) to result in a compiler error. I wouldn't expect the compiler to generate both a new trait and a new impl for it as part of type inference. Have I missed something?

@schuster

The other RFC doesn't seem to elide type annotations at all (unless I missed something; I didn't read it too closely).

It doesn't, but it provides all the underlying mechanisms. Adding type elision through desugaring into impl Trait would be a  trivial addition then.

I wouldn't expect the compiler to generate both a new trait and a new impl for it as part of type inference.

Right, Anything should live somewhere in the standard library.

const NAME: TYPE = VALUE;
When reading code, the TYPE matters more than VALUE. The later does not help a lot to understanding code. If TYPE is elided, I (the reader, the programmer) must infer it myself, it's not obvious in some cases, and the compiler can't help me here (though rustc will infer it too).

A question from me: Would this RFC potentially allow the following?
const FOO = |a, b| a + b;

I'm not sure if I'd be in favor or against this being permitted. On the one hand, it makes perfect sense syntactically - if you don't need to name the type an unnameable type is no problem, and the closure would syntactically only be able to capture const and statics.
On the other hand, it would enable a much more terse syntax for declaring functions, one which I am not especially in favor of; see my objections to a request for such a syntax

const FOO = |a, b| a + b;

nice idea!!! I would be greatly in favour of allowing this; it would allow easy migration of code between lambdas and functions. For another take on this , see the path being pursued in the JAI language, his idea is to make evolving code easy ('code goes through a maturation cycle')

@rfcbot fcp postpone
I'm moving to postpone the RFC. Overall, while I still think that there's a problem here to be solved, I'm not sure that we've quite found the right formula for doing it. I think we should put this off and return to it in the future, once some of the dust has settled.
One point that sticks out in my mind is that, based on the data that @schuster gathered, it looks like enabling i32 fallback would basically always pick the wrong type for simple things like const FOO = 22. This means you would still have to annotate cases of simple integer literals, and yet those appears to be the vast majority of constants!
On the other hand, there are two other non-trivial cases that would be helped:

The const SOMETHING: Foo = Foo { } and const SOMETHING: Foo = Foo(...) repetition (fairly common, based on @schuster's statistics).
Array literals where you have to say the length const Foo: [u8; 3] = [...]; often you can do const Foo: &[u8] = &[...] instead here though.

The alternatives I see:

Broader inference could help with integers, but I'd not want to go there just now. Maybe later, after we gain more experience in other areas (e.g. impl Trait), where it appears that broader inference will be needed.
Perhaps something syntactic like @petrochenkov suggested would be better, but that feels kind of scary to me. It's not something we have precedent for. I don't think we have a good idea what it's corner cases are, or how it would feel to have two distinct kinds of inference co-existing in the compiler.

For anyone who tries to tackle this in the future, here are the two main sticking points I see:

Inference for numeric literals. Given the stats above, it appears the fallback rule would not help in most cases, so there's room for a better option. Like @nikomatsakis said, perhaps some broader kind of inference could be helpful (although that makes it more difficult to determine the item's type by looking at the item alone).
Whether type inference for const/static items can use the types for bound names (e.g. structs, tuple structs, and functions). The main difference between the approach suggested in this RFC and @petrochenkov's "syntactic" approach is that the RFC allows those those types to be used, while the syntactic approach does not. The concern seems to be that the non-local nature of those types could make it harder to read a const/static expression and infer its type in your head.

This RFC has been closed as postponed. While the lang team believes that there is room for improvement here, it's proven to be a much more complicated design space than hoped, and the payoff doesn't appear worth the complexity at this time.
Thanks, @schuster, for writing and shepherding the RFC!

What's the current status on this?

@alexreg I don't believe anything has changed here since the FCP proposal and sticking points comments above.  That said, I wouldn't be surprised if there were a few cases of narrower proposals that could be interesting, like how eliding 'static was allowed in Rust 1.21.0.


chore: switch to hatchling

Quick examples of moving to hatchling. Slightly less config, 2 seconds faster, less verbose build messages, reduced chance of version conflicts, and slightly cleaner output. Other packages using hatchling include pipx, black, tox4, etc.
Just thought I'd throw it out there. Current system is completely fine too. Mostly making the PR since I tried it out and already had it. One benefit of PEP 621 is that it's easy to switch to the best performing backend. :)
PS: It occurred to me on the version conflicts (some packages limit setuptools < 60), that you don't have hatchling or setuptools when you have a wheel, so that should never be a problem. This is very much just a developer choice.
From #655.

@ofek, I just swapped from setuptools to hatchling, and the tox_to_nox extra (which is declared that way and used that way) is getting normalized to tox-to-nox, which causes it to silently start failing. I don't see any way to provide a backward compatible tox_to_nox extra. AFAICT, this is more likely Pip's issue, since PEP 685 was accepted? I see no mention there of PEP 685 support.

https://hatch.pypa.io/latest/config/metadata/#allowing-ambiguous-features

Other packages using hatchling

See https://hatch.pypa.io/dev/users/

The pyproject.toml formatter is insisting the comment be removed.

https://github.com/tox-dev/pyproject-fmt/issues/16

Nice, looks like this is basically ready to go?

Yes, except for the issue with pyproject.fmt not allowing a comment.

Looks like the recent fail is just adding an extra newline?


multiple autoform with one submit button

hi, i'm using autoform with one project . i want multiple autoform with one submit button , have any good option ?

You can make the button type="button", handle the button click yourself, and call $('form1').submit(), etc. for all forms in the click handler.

thank you for reply , but what should i do if  form1 validation  error and form2 should be not work too ?

There may not be a perfect way, but you can validate each field manually using AutoForm.validateForm before you call submit for any of them, and submit them all only if all are valid.

thank you every much for info :) !


implemented usd/currency with localstorage save

Pull request template
Checklist

[ ] I have read the CONTRIBUTING guide
[ ] branch rebased on master
[ ] styleguide check npm run validate
[ ] good naming
[ ] keep simple
[ ] video or screenshot attached
[ ] testing instruction attached
[ ] check your PR once again

Description

Video or screenshot

What and how to test

To test it locally run git fetch && fit checkout twelveWordsCreateBug where twelveWordsCreateBug is a name of this branch (see under title) OR git fetch origin refs/pull/2590/merge:pr2590 && git checkout pr2590 where 2590 is number of this pull request
npm i && npm run build:mainnet then run MultiCurrencyWallet/build.mainnet/index.html in browse

https://drive.google.com/file/d/1SzNjlkObzbKm-xVTB8lwLCk3amXpMzxU/view

[ ] ошибки не красиво https://screenshots.wpmix.net/chrome_D4QM3pRYW9IncSdPaxLtisIUWKfH3qYh.png


⚠ BCR Bot has degraded performance

In bf589b8, BCR Bot (https://bcr.alternativasinteligentes.com/BCRApi/web/chatbot) experienced degraded performance:

HTTP code: 200
Response time: 859 ms

Resolved: BCR Bot performance has improved in eb65de3.


Swbs/tensor ricap mods v0.1

Resolve the Bug in RICAP Tensor Host
Remove the unused argument

lgtm


U/jrbogart/diffsky integrate2

Streamline interface to DiffskySedGenerator class
Make small script create_diffsky_sed.py  to just create diffsky SEDs
Other lesser, largely cosmetic changes.

v1.1.2 is not yet available on the master branch of GCRCatalogs so I don't think skyCatalogs should have a hard-coded dependence on it.  The data are in the shared data area, however, so it's just a matter of merging the yaml file for the catalog into the master branch.


Fix a regression with unsafe packages for --allow-unsafe

Closes #1786
Contributor checklist

[x] Provided the tests for the changes.
[x] Assure PR title is short, clear, and good to be included in the user-oriented changelog

Maintainer checklist

[x] Assure one of these labels is present: backwards incompatible, feature, enhancement, deprecation, bug, dependency, docs or skip-changelog as they determine changelog listing.
[x] Assign the PR to an existing or new milestone for the target version (following Semantic Versioning).

@atugushev is it correct? https://github.com/jazzband/pip-tools/issues/1786#issuecomment-1364582961


Displaying two jupyter notebooks side-by-side disables keyboard interaction with both notebooks

Issue Type: Bug
Steps to reproduce:

Start jupyter notebook server
Launch two notebooks (can be existing or new)
Drag one notebook tab to the other side to view both notebooks side by side
Both notebooks can now be viewed.  It is possible to scroll and click on buttons within the notebook (i.e., restart the kernel, move cells) but keyboard functionality does not work in either edit mode or command mode.
Dragging the notebooks back to the same window allows interaction again.

Extension version: 2020.6.89148
VS Code version: Code 1.46.1 (cd9ea6488829f560dc949a8b2fb789f3cdc05f5d, 2020-06-17T21:13:20.174Z)
OS version: Windows_NT x64 10.0.19041
Remote OS version: Linux x64 4.19.104-microsoft-standard

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz (8 x 2112)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: disabled_offprotected_video_decode: enabledrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledviz_display_compositor: enabled_onviz_hit_test_surface_layer: disabled_off_okwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
15.75GB (5.80GB free)

Process Argv
--folder-uri=vscode-remote://wsl+Ubuntu-18.04/home/kdorosch/Palix%20Big%20Bits --remote=wsl+Ubuntu-18.04

Screen Reader
no

VM
0%

Item
Value

Remote
WSL: Ubuntu-18.04

OS
Linux x64 4.19.104-microsoft-standard

CPUs
Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz (8 x 2112)

Memory (System)
12.29GB (11.18GB free)

VM
0%

Can you elaborate a bit more? For me keyboard functionality for say shift+enter works fine. You have to give the notebook focus, but otherwise all keyboard shortcuts I tried worked.
Which keys don't work?
Do either of the two notebooks have the input focus?

Ah it does behave strangely if I just click the 'tab' for the notebook. Although I repro this problem with a single view group as well.
This may be related to this bug here:
https://github.com/microsoft/vscode-python/issues/11808

Oddly, shift+enter doesn't work either, although I do think it could be related to the bug you've referenced, i.e., perhaps it's not really changing focus even if it looks that way in the UI.
Even the original notebook that appears to have focus does not have keyboard functionality (neither shift+enter nor other keyboard commands). When I attempt to change the focus to any tab with a jupyter notebook, it's really fighting me and doesn't want to change. If I do manage to change the focus, it still behaves as though it's not in focus.
Here's a quick gif of what happens when I try to focus the tab:

Realized I didn't answer all questions specifically.
Re: which keys, I tried every command I could think of off the top of my head -- a, dd, m, r, x, etc. in addition to the key combinations like shift+enter, alt+enter, etc. No luck.
Re: which/either of the tabs having focus. It appears like the left tab has focus (I dragged a notebook from left to right), but neither responds until I drag them back to the same window.

Thanks for verifying. I'm going to close this as a dupe of #11808. Sounds like the same thing. We're waiting on a fix from VS code for that issue:
https://github.com/microsoft/vscode/issues/97992


python311Packages.asyncstdlib: 3.12.0 -> 3.12.1

Diff: https://github.com/maxfischer2781/asyncstdlib/compare/refs/tags/v3.12.0...v3.12.1
Changelog: https://github.com/maxfischer2781/asyncstdlib/releases/tag/v3.12.1
Description of changes

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

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

Result of nixpkgs-review pr 292982 run on x86_64-linux 1

4 packages marked as broken and skipped:

python312Packages.icontract
python312Packages.icontract.dist
python312Packages.pylddwrap
python312Packages.pylddwrap.dist

13 packages built:

home-assistant-component-tests.denonavr
python311Packages.asyncstdlib
python311Packages.asyncstdlib.dist
python311Packages.denonavr
python311Packages.denonavr.dist
python311Packages.icontract
python311Packages.icontract.dist
python311Packages.pylddwrap
python311Packages.pylddwrap.dist
python312Packages.asyncstdlib
python312Packages.asyncstdlib.dist
python312Packages.denonavr
python312Packages.denonavr.dist


minor ux fixes

Codecov Report

Merging #106 (970db9a) into master (b425a4f) will increase coverage by 80.23%.
The diff coverage is 0.00%.

@@             Coverage Diff             @@
##           master     #106       +/-   ##
===========================================
+ Coverage        0   80.23%   +80.23%
===========================================
  Files           0      118      +118
  Lines           0    11012    +11012
  Branches        0     1173     +1173
===========================================
+ Hits            0     8835     +8835
- Misses          0     2177     +2177

Flag
Coverage Δ

unittests
80.23% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

packages/lib/components/tabs/tab-headers.tsx
73.15% <0.00%> (ø)

packages/lib/components/list/list.tsx
91.07% <0.00%> (ø)

packages/lib/components/menu-bar/item.tsx
98.21% <0.00%> (ø)

packages/lib/components/menu/menu-overlay.tsx
98.09% <0.00%> (ø)

packages/lib/components/carousel/carousel.tsx
85.89% <0.00%> (ø)

packages/lib/icons/circle.tsx
35.00% <0.00%> (ø)

packages/lib/icons/error.tsx
100.00% <0.00%> (ø)

packages/lib/components/list/list-items.tsx
96.45% <0.00%> (ø)

packages/lib/components/dropdown/dropdown.tsx
99.19% <0.00%> (ø)

packages/lib/postcss.config.js
100.00% <0.00%> (ø)

... and 109 more

Continue to review full report at Codecov.

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


ui: Slightly adjust app bar and scaffold-background, to align with web

These colors are known in the web app as (in order of appearance):
--color-background-navbar
--color-navbar-bottom-border
--color-background
(The nav-bar border color is unchanged, or changed within a rounding error.)
The colors we had before this were reasonable, since they were taken from the Figma. But the Figma is now over a year old, and it seems at least as reasonable to follow the web app, especially since they're only slightly different. Moreover, we want to implement dark theme soon (#95), and it'll be best to take the light and dark styles from the same source. That currently has to be the web app, since the Figma doesn't have a dark theme.

Screenshots coming soon.

Before
After

Closing as superseded by #687; see discussion linked from there.


Relax version specifiers for tests.

Using pytest >=4.1 and pytest-qt <2.4.0 at the same time caused problems with CI.
This change constrains the requirements to a minimum/flexible configuration and avoids pinned versions.
This commit (released in pytest-qt 2.4.0) introduced some fixes for pytest 3.6+ compatibility (deprecation of pytest's get_marker and removal in pytest 4, which caused the error we saw), but in CI we used only 2.2.1, therefore with pytest 4+, there was an incompatibility.
While strictly pinned versions solve this specific problem by avoiding the broken version set, it will probably cause further problems down the line for people not being able to fulfill the strict requirements (e.g. by two libraries pinning to two different pytest versions). A version constraint that is only as strict as necessary is generally preferable, and is proposed here.
By the way, this line shows how in the pip section of the requirements.yml, current pytest 4 gets dragged in (which actually surfaced this problem) despite 3.1.1 being specified and installed in the conda install step. That pip installs dependencies greedily is an interesting detail of requirements files to be aware of. In light of this, maybe it's worth it to keep one parallel build on more recent versions (instead of hard-pinning with requirements.yml), to be able to gracefully deal with changes in our dependencies?

Thanks @bilderbuchi for raising this. The original test had the pytest-qt version pinned, while the pytest version was flexible. I chose pinning both to ensure that as long as those versions are available, we can rely on consistent behavior. I agree that being more flexible has its advantages for people with existing environments and potential version conflicts -- let's make this change.
It is interesting that pytest gets installed and reinstalled in the same conda env create command. I think this is a bug in conda, which should be addressed upstream. We could drop the pytest requirement in the conda section, and rely on pytest-qt in the pip section to install it as a dependency.

Thanks. I suspect that this is a shortcoming of having to use two different package managers - pip is just not aware of pytest already being available via conda, so I think that actually it seems more like a pip bug.
Another solution would be to add the conda-forge channel durin CI setup, as pytest-qt is available there.

I think using conda-forge is a good suggestion. We could move both pyvisa and pytest-qt off of pip. We already have conda-forge in conda-3.5.yml. Do you want to put up a PR?


Slack bridge file shuffle

Summary
Distributing the source of the Slack bridge across multiple files to
increase readability and as a prelude to various refactors and
clean-ups.
This is part of work for #510.
Functionality / semantics changes
There are no code changes in this PR, just copy-paste of existing code.

Looks good. Should I merge this or are you going to add more commits?

Please merge. Have already most of the work done but will create a successive smaller PRs. Makes reviewing lighter for you and easier to contextualise changes.


Out of date

[Enter feedback here]
Create Data Factory has different options than some of what's mentioned on this page.  Specifically, it now asks for information about a Git repository.

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

ID: 2e218b24-88cc-2c51-1ccc-7718cf0ffb33
Version Independent ID: 0cf3bb9b-c822-b0a6-35d8-785ebcefb4f3
Content: Introduction to Azure Data Factory - Azure Data Factory
Content Source: articles/data-factory/introduction.md
Service: data-factory
GitHub Login: @djpmsft
Microsoft Alias: daperlov

@ysid-airbus
Thanks for the feedback and bringing this to our notice. At this time we are reviewing the feedback and will provide an update as appropriate.

@ysid-airbus  : You are correct , but then that is called out in the document .
"Data Factory offers full support for CI/CD of your data pipelines using Azure DevOps and GitHub. " .

We are closing this issue as we have not heard back from you  , you can always re-open the issue if you think that appropriate .


Update object server tests to work with ROS v2.0

ROS v2.0 has different packaging and command-line interface than ROS v1.0. We need to update our test harness to accommodate the differences in order to continue to test against current versions of sync.
Work that still remains to be done:

[ ] Enable testReadAccess test. Fixed by https://github.com/realm/ros/pull/475
[ ] Enable testWriteAccessViaUsername test. Fix forthcoming in next ROS per https://github.com/realm/ros/issues/426
[ ] Enable testDeletingPermission test. This test passes in isolation but fails when run in the middle of the entire suite. It's possible that https://github.com/realm/ros/issues/437 is the cause.
[ ] Enable testDeleteRealmUponPermissionDenied test. Fixed by https://github.com/realm/ros/pull/475
[ ] Write a test to check against https://github.com/realm/ros/issues/430.
[x] All other permissions tests need to be re-enabled and ported over.
[x] Fix how admin users are created; re-enable tests that depend on admin users (testRetrieveUserInfo) - #5341
[x] Fix and re-enable the password change tests (testUserChangePassword, testOtherUserChangePassword) -- #5341
[x] Fix and re-enable the test that opens a Realm with the admin token (testOpenRealmWithAdminToken) -- _https://github.com/realm/realm-cocoa/pull/5332_
[x] Fix and re-enable the test that logs in a user based on the admin token (testAdminTokenAuthentication) -- _https://github.com/realm/realm-cocoa/pull/5332_
[x] Fix the sync error handler test (testSyncErrorHandlerErrorDomain) -- #5333

Work that needs to be done

[ ] All permissions tests need to be re-enabled and ported over.
[ ] Fix how admin users are created; re-enable tests that depend on admin users (testRetrieveUserInfo)
[ ] Fix and re-enable the password change tests (testUserChangePassword, testOtherUserChangePassword)
[ ] Fix and re-enable the test that opens a Realm with the admin token (testOpenRealmWithAdminToken)
[ ] Fix and re-enable the test that logs in a user based on the admin token (testAdminTokenAuthentication)
[ ] Fix the sync error handler test (testSyncErrorHandlerErrorDomain)

@austinzheng Will you update status on this please with latest alpha.35?

A number of items were fixed by upgrading to alpha 35 and making corresponding changes; they are contained in this PR. We put together this list after that PR was merged; I can add the items that PR fixed to the list if you'd like.

I have updated this issue with a fine-grained description of work remaining to be done. There are a number of issues other bindings have uncovered with ROS that our tests don't cover; it would be nice (but not mandatory) to write tests for those as well as they're fixed in time for the 3.0 release.

Updating Cocoa's ROS dependency to rc-1 is blocked on https://github.com/realm/ros/issues/472.

Looks like realm/ros#472 is not blocking anymore @austinzheng ?

It's not blocking, but now https://github.com/realm/ros/issues/438 is blocking it.


Fixed this-pointer check in XLCell

The exception is misleadingly thrown because the de-referenced this-pointer has no '!'-operator. The check should be if this-pointer itself is NULL.

These checks were leftovers from a different implementation and have been removed completely in the May 2024 Update.
This pull request is therefore no longer applicable. Thank you for pointing it out, thought! :)


Update go perun to v0.4.0

Description

Update go-perun library to  v0.4.0.
Category

Implementation Task
Relevant issue

Closes #58.
Testing

Added  new tests. Test no.1 & 5 (in steps) relate to update of go-perun library.
Other tests (2, 3 & 4 in steps) improve the existing code.
Steps to run the tests

Checks if an error in commBackend.NewListener is handled in client.New. ganache-nodeshould be started before running this integration test using the command: (as stated inclient_integ_test.go`)

# start ganache-cli node
ganache-cli --account="0x1fedd636dbc7e8d41a0622a2040b86fea8842cef9d4aa4c582aad00465b7acff,10000000000000000000"

# run the test
go test  -tags=integration -count=1 github.com/direct-state-transfer/perun-node/client -run ^Test_Integ_NewEthereumPaymentClient/err_invalid_listener$ -v

Check if the funder returned by ethereum.ChainBackend is not nil.

go test  -count=1 github.com/direct-state-transfer/perun-node/blockchain/ethereum/internal -run ^Test_ChainBackend_NewFunder$ -v

3.Check if the adjudicator returned by ethereum.ChainBackend is not nil.
go test  -count=1 github.com/direct-state-transfer/perun-node/blockchain/ethereum/internal -run ^Test_ChainBackend_NewAdjudicator$ -v

Check if the client.Client implements perun.ChannelClient interface.

go test  -count=1 github.com/direct-state-transfer/perun-node/client -run ^Test_ChannelClient_Interface$ -v

Check if client.Close is properly implemented.

go test  -count=1 github.com/direct-state-transfer/perun-node/client -run  ^Test_Client_Close$ -v

Checklist

[x] Name is added to the NOTICE file, if it is not present already.
[x] Changes are rebased onto the target branch.

How did you fund the addresses that deploy the contracts? The integration test user does not have funds in my ganache-cli setup.

@ggwpez,
Did you use the command to start the ganache-cli node as stated in the comments in client_test file ?.
ganache-cli --account="0x1fedd636dbc7e8d41a0622a2040b86fea8842cef9d4aa4c582aad00465b7acff,10000000000000000000"

The private key string in the command corresponds to on-chain account of user when seeding the rand source with 1729. That is how i fund the addresses.
I will also update this in the pull request description.

Did you use the command to start the ganache-cli node as stated in the comments in client_test.go file ?.

No :sweat_smile: i just tried it like in the MR description, thanks for amending it.

I think we should also run the integration tests in the CI, can i create an issue for that? @manoranjith

I think we should also run the integration tests in the CI, can i create an issue for that? @manoranjith
Hi @ggwpez,

Sure. That would be nice. You can create an issue describing the necessary steps.

@ggwpez I have addressed the review comments and rebased the branch onto latest develop.


Left Menu Don't Work After Segue From AnotherViewController

Hello, All work fine, but after i perform segue from UIAlertView from AnotherViewContoller, left navigation button is tapped but slideMenu not open... can you help me?

Hey guys, seriously, when I do
let alertController = UIAlertController(title: "Order shipped" message: "Your order has shipped, We will contact You within 5 min.", preferredStyle: .Alert)
let okButton = alertController.addAction(UIAlertAction(title: "OK", style: .By default, handler: { _ in
let storyboard : UIStoryboard = UIStoryboard(name: "Main", bundle:nil)
let secondViewController = self.the storyboard?.instantiateViewControllerWithIdentifier("MainViewController") as! HomeViewController
self.navigationController?.pushViewController(secondViewController, animated: true)
}))
HomeViewController not to open the slideMenu, but the buttons to press!
What could it be?


raft: (re-)introduce TestRecvMsgPreVote

TestRecvMsgPreVote was intended to be introduced in https://github.com/coreos/etcd/pull/6624 but was uncapitalized (search for testRecvMsgPreVote instead) and then subsequently removed due to it being unused.

@heyitsanthony: can you re-trigger the build? Unsure of why it's failing, but seems unrelated.

@irfansharif raft tests already go through travis. Not worried about other failures since they'll be unrelated, but I kicked off a semaphore build just in case


Update dependencies

You can preview this change here:
Built with commit a527e30b7b675170a52761ee7628284a202792df
https://deploy-preview-644--govuk-design-system-preview.netlify.com


[Display news: List view] Incorrect size and alignment of UI elements  on 'List view' page (1440 resolution)

Environment:
Microsoft Windows 10 Home, Version 10.0.19041
Google Chrome Version 86.0.4240.198 (Official Build) (64-bit)
Reproducible: always
Build found: 2020-11-21
Preconditions

Go to Green City https://ita-social-projects.github.io/GreenCityClient/#/welcome

Steps to reproduce

Click on the 'Eco news' button
Click on the 'List view' icon
Verify UI elements size and alignments of the news item on 1440  resolution with dev tool help.
Pay attention to the result.

Actual result
The size of the 'Greencity' logo is 136x36

The size of the 'Search' control is 16x16

The seize of the 'language' dropdown list is 16x44

The heights of the user name field is 16px

The size of the 'Create news' button is 185x40

The size of the 'Create news' button label is 99x16

The size of the 'Eco news' title is 227x30

The size of the 'Filter by' label is 97x42

The size of the 'Greencity' logo in the footer is 206x48

The size of the 'Copyright' label in the footer is 1440x16

The size of the 'Follow us' link in the footer is 61x16

Expected result
The size of the 'Greencity' logo is divided into two parts  36x36, 94x12

The size of the 'Search' control is 11x11

The seize of the language dropdown list is 17x19

The heights of the user name field is 12px

The size of the 'Create news' button is 183x40

The size of the 'Create news' button label is 96x16

The size of the 'Eco news' title is 256x48

The size of the 'Filter by' label is 99x24

The size of the 'Greencity' logo is divided into two parts  48x48, 141x18

The size of the 'Copyright' label in the footer is 194x16

The size of the 'Follow us' link in the footer is 62x19

User story and test case links
E.g.: "User story #460
Test case https://jira.softserve.academy/browse/GC-720

please check this again, and divide the test cases into different areas (header, footer, eco-news) because it is impossible to work with it

please check this again, and divide the test cases into different areas (header, footer, eco-news) because it is impossible to work with it

Defect is not fixed
Is fixed only size of the 'Create news' button (see attachment with result)

Defect is not fixed
Is fixed only size of the 'Create news' button (see attachment with result)


add ability to animate LineString

fixes #232
This PR adds the ability to animate LineStrings in a manner very similar to animating polygons. The documentation has been updated, but the short version is the following:

features of geometry type LineString give a 2D string of coordinates for id fromID
adding the animateTo attribute with id toID animates from the start date of fromID to the enddate of fromID, adding any additional points from toID to the line as the time progresses.
no error checking is done except to ensure that toID has equal or more number of line vertices as fromID
the coordinates of the endpoint(s) of the added line segments are interpolated based upon the point in time being displayed. For example, if toID adds one vertex, and fromID animates from January 1 to December 31, then the added line to the end of fromID's linestring moves 1/365th of the distance for every day being animated.
this interpolation is not perfect given a Cartesian coordinate system, but is sufficient for our current purposes
if multiple vertices are added to fromID from the end of the toID line string, then they are added along a similar interpolation progression, using degrees of distance to estimate the interpolation. For example, if three new vertices are added, one 1 degree to the west, the next 1 degree to the south, the 3rd 1 degree to the west, then only the first vertex is added (progressively moving farther west) during the first 1/3 of the time progression, then the second vertex is added (progressively moving farther south) during the next 1/3rd, etc. Degrees of distance in longitude vary greatly based upon latitude, but these subtleties are not in the current calculation, and this is again considered sufficient for our current purposes.

Signed-off-by: Scott Johnson<EMAIL_ADDRESS>

See the documentation on the geoJson augmentations for examples of the line animation


Surprising behavior of ValueNotifier (doesn't notify on certain changes)

ValueNotifier, for example, doesn't notify in the case that
SomeProto a = new SomeProto();
a.setSomeInt(5);
SomeProto b = new SomeProto();
b.setSomeInt(5);
valueNotifier_ = a;  // listeners are notified.
valueNotifier_ = b;  // listeners are not notified.

The cause of this surprising behavior is that ValueNotifier uses the == operator of the contained object to determine whether the value has changed.
The description of ValueNotifier says "When the value is replaced, this class notifies its listeners", which suggests that this is not the intended behavior in this case (and, indeed, if the notifier were supposed to be triggered only on inner content changing then the current behavior also fails at that, since
valueNotifier_ = a;
a.setSomeInt(6);

would not provoke a notification.)
I have a patch that fixes this and adds a test, will make a PR shortly.

SomeProto is overriding == operators, right?
I think that it is correct behavior not to notify because "a" and "b" is the same value and are not "replace".

Yes, SomeProto in this case overrides == operators. I think "value" refers to the 'value' contained by the ValueNotifier though, which is replaced, just by something which the == operator says is similar.
If the intent is to notify when ValueNotifier.value's == operator against its previous value would return false, under the current implementation that intent is also unsuccessful, as described in the original report, because valueNotifier_.someSubValue = [a new value] does not trigger a notification.
I can't think of any case where one would specifically want to not be notified that a value has been replaced with a similar value (but has a different instance), and also not be notified if the inner contents of the value have changed.
But I did encounter an existing use where the behavior was the unexpected thing, resulting in a button being unresponsive if pressed more than once without a different button being pressed in between, which is how I came to be looking at this code in the first place.
Note, in the case that "a" and "b" are actually the same value, not just operator== similar, eg.
SomeProto a = new SomeProto();
a.setSomeInt(5);
SomeProto b = a;
valueNotifier_ = a;
valueNotifier_ = b;

Then I would agree that it's correct not to notify (and my PR matches that behavior). But if a and b are distinct, even if similar, then I would contend that the value was definitely replaced.
I would be open to a counterproposal that instead of changing the behavior, the comment for ValueNotifier could be updated to say "when the value is replaced with a value for which operator== doesn't match the previous value..." but I don't think the current behavior matches the described behavior. To me the current behavior looks more like a result of just not having considered the impact of operator== overrides, rather than an explicitly intentional behavior, because operator== is usually the same thing as calling identical() (and a lot of us would habitually treat it as equivalent from other languages).

ValueNotifier implies value semantics, which means that operator.== is the correct choice. If you've overriden operator.== incorrectly you are absolutely in for a world of pain, regardless of what the behavior of ValueNotifier does.

because operator== is usually the same thing as calling identical()

This is not true in my experience. Overriding operator.== is how one creates value class like behavior.

Hm, implied value semantics from the term 'value' is a pretty good argument for using ==. But then, again, ValueNotifier fails at that implied contract because changing the value without reassigning it to valueNotifier_.value (or even changing the value in place and reassigning it to that new value) will not notify the listeners.
Also I don't think ValueNotifier very strongly implies value semantics, because it's not at all clear what you'd call this template if you meant "content reference change notifier" which is what this mostly already is, apart from the not notifying if the content reference changes and the value doesn't.
Which is to say, the current behavior is:
Reference changes and value changes because the newly referenced object is different: notify
Only value changes: do not notify
Only reference changes: do not notify
Nothing changes: do not notify
Reference changes and value changes, but not at the same time: do not notify
Example of that last case, because it's not very clear, where SomeContainer is a class with the obvious overridden ==:
var a = SomeContainer(5);
var b = SomeContainer(6);
valueNotifier_ = a;  // A notification happens, assuming the previous value did not == someContainer(6).
a.contents = 6;  // No notification of this change, valueNotifier_.set value isn't even entered.
valueNotifier_ = b;  // No notification because 'previous' [silently updated] value a now == b.

If you're comfortable with that being the behavior then by all means reject my PR and I'll drop it, but it looks like an unhelpful, unexpected, and error-prone behavior to me. (At least error-prone enough that I found it in someone else's erroneous use of it!)
(NB. the erroneous case was not "overriding operator== incorrectly", but it probably was abusing ValueNotifier as a communication channel. Unfortunately I think that's quite common in web development and frameworks - Polymer, for example, encourages a very similar pattern.)

var a = SomeContainer(5);
var b = SomeContainer(6);
valueNotifier_ = a;  // A notification happens, assuming the previous value did not == someContainer(6).
a.contents = 6;  // No notification of this change, valueNotifier_.set value isn't even entered.
valueNotifier_ = b;  // No notification because 'previous' [silently updated] value a now == b.

This is not strange for me. Expecting notification with this code, is a mistake of how to use ValueNotifier.

ValueNotifier fails at that implied contract because changing the value without reassigning it to valueNotifier_.value (or even changing the value in place and reassigning it to that new value) will not notify the listeners.

Values types should not be mutable though, like how "a" + "b" gives a new String and 1 + 2 a new number. Though I fully admit the language does not give us good guidelines here because currently the contract for ValueNotifier is not really expressible via the type system, and it is under-documented compared to the functionality it exposes.

value types should not be mutable though

Is that a thing in Dart? It's not a thing of value types. Structs are value types in C, C++ and C# and are very much mutable. Java proponents sometimes say that value types shouldn't be mutable, but it's not generally a constraint. The + operator not mutating its parameters isn't really demonstrative of the parameters not being mutable. Dart strings are explicitly immutable, it's not a property associated with value types.
Also oops, edited my example above to say valueNotifier_.value = instead of the mistaken valueNotifier_ = as quoted. Not sure if that correction makes any difference to najeira's response.

A value type is not something that is enforced by the type system, nor are there any affordances to make designing them easier in Dart. Consider the lint hash_and_equals. If you implement a type with operator.== you should generally also create hashCode.  Likewise, if your hashCode doesn't take into account the fields of your class, then equal objects might have different hashCodes.
This implies a much narrower definition of value type than just a struct.

I would suggest if you want these semantics, you should either override == for that object, or create a new (subclass) of ValueNotifier that operates on reference equality.
This would be a massively breaking change.

@dnfield any reason why you reopened this?

Mistake.


Fixed bug with long course titles

Motivation and Context
Fixes UI bugs with long titles.
Description
Text will now be cut off if it's too long and only be shown on mouse hover.
Screenshots

Looks good to me. Would it be a good idea to add "overflow-hidden" to all elements? Because this problem occurs anywhere...

Maybe we can do this in an enh branch, but as a quick fix for this issue, this works for the lecture title. What do you think about this?


Adding network partitions for CLI (UpdateNetworkPartition)

Adding network partitions for CLI (UpdateNetworkPartition)

@dinithis There are some merge conflicts in this pull request, can you please resolve them?
CONFLICT (add/add): Merge conflict in components/org.apache.stratos.cli/src/main/java/org/apache/stratos/cli/commands/AddNetworkPartitionCommand.java
CONFLICT (content): Merge conflict in components/org.apache.stratos.cli/src/main/java/org/apache/stratos/cli/RestCommandLineService.java


How can i get latlng from clickevent when kml layer is on the map?

When I add a Kml layer on the map and click on a point where this layer is drawn, the GoogleMap click event is not triggered. How can I solve this? I would like to receive the same LatLng that I receive when GoogleMap's onMapClick is triggered.

I am also interested in how this can be achieved. I have for now resorted to using long click to capture the position.

Click event on KML layer can be triggered via geojson functions.
Click event on map(marker) is not related to KML layers.


Deleting NIC resource by ID causes NoRegisteredProviderFound error message.

Switched existing code to use the updated API (v11.1.1-beta from 7.0.0-beta). Were some breaking changes, but as far as I can tell, the method to delete a NIC shouldn't have changed? (despite the channels).
Source code:
nic := *(*vmProps.NetworkProfile.NetworkInterfaces)[0].ID
resChan, errChan := resourcesClient.DeleteByID(nic, nil)
select {
  case err = <-errChan:
    log.Printf("Could not delete NIC %s: %s", nic, err)
    return err
  case _ = <-resChan:
    log.Printf("NIC Deleted: %s", nic)
}

Output:

2017/10/29 12:42:32 Could not delete NIC /subscriptions/xxxxxxxxxxxxxxxxx/resourceGroups/ResGroup1/providers/Microsoft.Network/networkInterfaces/NIC-Something-1: resources.GroupClient#DeleteByID: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="NoRegisteredProviderFound" Message="No registered resource provider found for location 'uksouth' and API version '2017-05-10' for type 'networkInterfaces'. The supported api-versions are '2014-12-01-preview, 2015-05-01-preview, 2015-06-15, 2016-03-30, 2016-06-01, 2016-07-01, 2016-08-01, 2016-09-01, 2016-10-01, 2016-11-01, 2016-12-01, 2017-03-01, 2017-04-01, 2017-06-01, 2017-08-01, 2017-09-01'. The supported locations are 'westus, eastus, northeurope, westeurope, eastasia, southeastasia, northcentralus, southcentralus, centralus, eastus2, japaneast, japanwest, brazilsouth, australiaeast, australiasoutheast, centralindia, southindia, westindia, canadacentral, canadaeast, westcentralus, westus2, ukwest, uksouth, koreacentral, koreasouth'."

Somehow seems to be using an invalid API version? (2017-05-10 isn't in the list?).

Oh, just noticed https://github.com/Azure/azure-sdk-for-go/issues/741. Might be duplicate