System.import dynamic chunks

I am creating a React component which has a select drop down. The data in the drop down depends on the props provided.
<Range country="GB" />
In the component I have
System.import(/data/${country}).then( (range)=>{/**--**//})
Data directory has around 100 files like GB.js, AU.js etc. It works perfectly fine while developing the component and its on Example.js where I import the source file of the component. Config as follows.
entry: {
		RangeSelector: "./src/components/RangeSelector.js"
	},
	output: {
		path: "dist/lib",
		filename: "[name].js",
		chunkFilename:"[name].js",
		libraryTarget: "umd",
		library: "[name]"
	},

However, when it is taken from the npm (private) and installed in a new project, the chunks are not getting loaded. (where i import Range from '@p/range'; )(for example 3.js missing etc). The only solution as of now is manually copying the chunks from the node_modules/rangepackage/dist/*.js to the dist of the project.
Is there a solution for this or I am missing something here.

This needs a webpack 2 label.
The end result to happen is, when we import a library, the main of the library gets added to the bundle, and the dynamically loaded chunks copied to the dist folder or System.path to node_modules/library/dist.
For example, import Range from '@p/range' where @p/range has dynamic chunks where 1.js, 2.js etc, they should get copied to the dist folder or resolve the node_modules/@p/range/dist for loading the 1.js, 2.js etc. I am not sure whether the purpose for System.path is for that or not, or this scenario is covered in specs. Anyway, as just manually copying these files resolves the issue, but not elegant when published for public consumption in npm.


Set different expiration times based on URL patterns

Follow-up from #108. I would like to add support for setting expiration times based URL patterns. Specifically, glob patterns for base URLs (*.site.com, etc.). This would be implemented as an init parameter for CachedSession, something like:
session = CachedSession(expire_after_patterns={
    'github.com/*/*/issues/': 120,
    '*.site.com': 360,
    'site.com/content-that-never-gets-updated': None,
})

Implemented this in https://github.com/JWCook/aiohttp-client-cache/pull/27; it will need some modifications to work for requests-cache, but otherwise the logic should be the same.

Part of the prep work needed for this will be done in #187, which may take several more days. Planning to work on this one afterward.


Improve usability of versions table during overflow

Is your feature request related to a problem? Please describe.
When the screen size is below some number or zoom has increased element size the Versions tab of a workflow or tool can become difficult to use. It can be difficult to find the scrollbar when the table overflows.  This is especially problematic on the my-workflows pages since the Actions button can be hidden by the overflow.

Describe the solution you'd like
A responsive table that removes some columns on smaller viewports.
Describe alternatives you've considered
Make the scrollbars always visible if it overflows the viewport
Move the actions button to the left so it won't end up in the overflow
Redesign table to use icons more akin to GitHub "branches" UI?
Additional context
This came up during the WDL bootcamp
┆Issue is synchronized with this Jira Story
┆Epic: Make dockstore more responsive - smaller screens
┆Fix Versions: Dockstore 1.17
┆Issue Number: DOCK-2426
┆Sprint: Backlog
┆Issue Type: Story

Coming back because I almost logged this again today

Coming back because a user brought this up to me when working on bringing in Galaxy ML tools thanks @paulocilasjr


[Display Placer] ...

Extension
https://www.raycast.com/eluce2/displayplacer
Description
Errors out any time its triggered since recent mac os updates
Steps To Reproduce
Errors out any time its triggered since recent mac os updates
Current Behaviour
No response
Expected Behaviour
No response

which version of macos are you running? I'm unable to replicate with 13.5.2


When simulating, does docker's requirement for ubuntu14.04 system be 64-bit? Is the 32-bit system not possible?

We appreciate you go through Apollo documentations and search previous issues before creating an new one. If neither of the sources helped you with your issues, please report the issue using the following form. Please note missing info can delay the response time.
System information

OS Platform and Distribution (e.g., Linux Ubuntu 14.04):
Apollo installed from (source or binary):
Apollo version (1.0, 1.5, 2.0, 2.5, 3.0):

Steps to reproduce the issue:

Please use bullet points and include as much details as possible:

Supporting materials (screenshots, command lines, code/script snippets):

@Shining10 you do need a 64-bit system to build Apollo. Let me know if you have any additional questions. Thanks!


New Scalapb Plugin

This pr resolves #98
I'm not entirely sure if everything was correctly implemented. However I was able to test this with the alpha plugin release process and saw that it generates code correctly. Let me know if there are any changes that need to occur, more than happy to make them. Thanks!

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.0 out of 2 committers have signed the CLA.:x: 11Dimensions:x: Luka JurukovskiLuka Jurukovski seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


VHD

I want to boot into VHD files for instance, Upload and boot into a file called Windows XP.vhd. I have a VHD file to boot into. When I upload it, it says Invalid Boot Device with 512 MB of RAM, 32 MB Video RAM. Can you help

VHD is not supported. You may be able to convert it by using qemu-img image.vhd -f raw image.raw.


show progress for nixos-rebuild

considering that upgrades can be quite huge (especially when changing from a channel to git) it would be nice to indicate how many packages have to be installed and how many are already installed

There was some WIP on a curses UI, but it seems stalled https://github.com/qknight/nix-build-view/

this wouldn't need ncurses, it could simply dump that info after each installed package, or behave a bit like apt-get

Seems like most of the progress we care about would be coming from nix-build and/or nix-env. nixos-rebuild would get it for free if those could provide it.

Thinking of it, that linked project probably didn't use ncurses, just terminal commands.

I've looked up, the linked project uses ncurses, but at the moment it doesn't work and has only an inbuild example.  Besides that, it looks much more pleasing than plain nix.

@knupfer You could use -Q with nix-env or nix-build.
The linked project has stalled because (as far as I know) changes to have something like the proposed curses UI were rejected on the ML (I wasn't involved in the discussion, just heard about it).

Let's move discussion to the nix repo https://github.com/NixOS/nix/issues/896


Update Employee Role

Update Employee Role
User Story
AS A business owner
I WANT to be able to view and manage the departments, roles, and employees in my company
SO THAT I can organize and plan my business
Acceptance Criteria
GIVEN a command-line application that accepts user input
WHEN I choose to update an employee role
THEN I am prompted to select an employee to update and their new role and this information is updated in the database

The updateEmployeeRole function and corresponding query have been added to the application and tested.


ClusterConfiguration should support tolerations

ClusterConfiguration should support tolerations
Run Ray clusters (especially the worker pods) on tainted nodes.
Description of Problem the Feature Should Solve
You cannot create a Ray cluster with tolerations using the CodeFlare SDK
cluster = Cluster(ClusterConfiguration(...))
Often, machine nodes are tainted to prevent unwanted workloads.  This is especially the case in GPU nodes which are often tainted.  In addition different nodes will have different sized gpus, which would also use taints to make sure the correct workers land on the correct nodes.
You might also want to add a toleration to the headGroupSpec
Describe the Solution You Would Like to See
Add worker_tolerations and head_tolderations as optional parameters for ClusterConfiguration
cluster = Cluster(ClusterConfiguration(
    head_tolerations=[key, operator, effect],
    worker_tolerations=[key, operator, effect]
))

Describe Alternatives You Have Considered
Editing the yaml file and just using kuberay directly.  You can currently manually edit an AppWrapper yaml to include a toleration for these taints.
workerGroupSpecs:
  - spec:
        tolerations:
          - key: nvidia.com/gpu
            operator: Exists
            effect: NoSchedule

Since I've submitted this, I've come across the need to add other fields, such as nodeSelectors, schedulerName, annotations, etc to my ray clusters.  As I don't think we can anticipate all the needs of the user, I think we should build in more flexibility into cluster creation.  I'd like to be able to read the ray cluster specs and submit a python dictionary to update the ray cluster.
For example
update_dict = {
    "spec": {
        "workerGroupSpecs": [
            {
                "groupName": "small-group-raycluster",
                "template": {
                    "spec": {
                        "tolerations": [
                            {
                                "key": "nvidia.com/gpu",
                                "operator": "Exists",
                                "effect": "NoSchedule"
                            }
                        ]
                    }
                }
            }
        ]
    }
}

That way I could update not just tolerations, but any other field I need to change, such as nodeSelector or schedulerName

I totally agree the current API design is not flexible enough.
I really like your suggestion to offer the option for users to provide their own patch.
We could try to be in line with the different patching mechanisms that are well known in Kubernetes already: https://kubernetes.io/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/.

We could add two keyword arguments, one to provide the Pod template for the worker nodes, another one for the head node Pod template, using official Kubernetes Python client types so auto-complete works, e.g.:
form kubernetes import V1PodTemplateSpec, V1PodSpec

cluster = Cluster(ClusterConfiguration(
    num_workers=N,
    worker_template=V1PodTemplateSpec(
        spec=V1PodSpec(
            tolerations=[client.V1Toleration(
                key="nvidia.com/gpu",
                operator="Exists",
                effect="NoSchedule",
            )],
            node_selector={
                "nvidia.com/gpu.present": "true",
            },
        )
    ),
    head_template=V1PodTemplateSpec(...),
))

These types from https://github.com/kubernetes-client/python provides a to_dict method that we could use to merge these user-provided templates.
@cfchase let us know if that's close enough to what you had in mind.


Add persistent volume option for zookeeper

When deploying ClickHouse with Persistent Volumes (PV) and the default ZooKeeper, if the ZooKeeper pod crashes before the ClickHouse pod does, ClickHouse will automatically switch the table to a READONLY state. This sequential occurrence leads to the ClickHouse pod encountering repeated crashes, because the data stored in ZooKeeper is entirely lost in the event of its crash.
In this PR, we add persistent volume option for zookeeper for user when they want to enable PV for ClickHouse to prevent above issue.
resolves #387

/theia-test-e2e

/theia-test-e2e


ci: pass --locked

We were updating the lockfile in some CI workflows which breaks if e.g. Alloy has breaking changes

This currently does not fix the merge queue issues because of https://github.com/paradigmxyz/reth/blob/6e5176221ff8b5cacea12c86dc52feba0de1593a/.gitignore#L54-L55

the arg is also provided multiple times

This actually won't unblock CI as is, but will unblock CI for #11986. We should probably just roll the path patch into that PR 🙃 Alternatively we can force merge this and rebase that PR on top, but it's blocked by revm release

Rolled into the alloy bump pr


literal match misclassified

Rasa NLU version: 0.10.6
spacy: 1.8.2
Operating system: ubuntu
Used backend / pipeline: spacy_sklearn
Issue:
Even when I try an input message that literally matches a known example, it is somehow misclassified.
nlu.md:
## intent:literal_match
- hi
- foo

## intent:irrelevant
- bar
- baz

config:
{
  "pipeline": "spacy_sklearn",
  "path" : "./models",
  "data" : "./data/nlu.md"
}

After training and serving, I try it out: curl -XPOST localhost:5000/parse -d '{"q":"hi"}'.
The result I get is as follows: {"entities": [], "intent": {"confidence": 0.7500297328927935, "name": "irrelevant"}, "text": "hi", "intent_ranking": [{"confidence": 0.7500297328927935, "name": "irrelevant"}, {"confidence": 0.24997026710720655, "name": "literal_match"}]}.
It appears that despite hi literally matching an explicit training example in category literal_match, category irrelevant is nevertheless considered a significantly closer hit.
This is a minimum repro of my initial encounter of this problem, which had more realistic input data, yet similarly failed to recognize even literal matches.
Perhaps one would normally use more input data than this, but I'm still surprised -- shouldn't a trivial example be easy?
This issue appears to be a minimum reproduction of #767.
Suggestions in that thread have included using Spacy 1.x and (re-)linking spacy's web_md. I was already on 1.x, and tried relinking the corpus, but the behavior appears to persist for me.

Thanks, seems that was it, I'll close then!


"child" and "children" add a lot of value

There's an assertion in https://github.com/munificent/ui-as-code/blob/master/in-progress/parameter-freedom.md that the "child" and "children" named arguments should become unnamed because they don't add value.
There is nothing special about "child" or "children"; not all widgets use those names, e.g. MaterialApp (the first widget people come across) uses "home", while Scaffold and AppBar (the next two predefined widgets they come across) use "body" and "appbar" and "leading" and "title" and so on.
Having the clear distinction of "child" and "children", and of other common names like "builder", is important to convey how many children a widget takes, what role the child has, how it should be expressed (e.g. static widget vs closure), and to make a clear link from the parameter in the constructor to the property on the widget. It also makes it much easier to reference the parameter in documentation.
In conclusion, I do not believe we would make that change even if the language made it easy to do so. We have in the past experimented with using unnamed arguments (e.g. for a while the child was always the first argument, unnamed), and we moved away from this very purposefully.

There actually is something special about child and children, but it's not a technical feature, but how these arguments are used. Namely, they predominantly come as the last argument in the argument list. This likely means that in developers' minds child widgets are conceptually separate from "properties", so they put them last. This holds even in Flutter's own code.
However, I'm not arguing that rest args is the right solution for this problem. Rest args is a useful language feature, just not for ui-as-code. I think we should keep looking for a solution, one that's applicable beyond single-slot child models, and includes "home", "body", "leading" and so on.

This likely means that in developers' minds child widgets are conceptually separate from "properties", so they put them last.

Yes! One of the reasons I was interested in exploring a JSX-like syntax is because that notation gives you a very explicit visual distinction between attributes and children. Unfortunately, I was never able to come up with a syntax I liked that worked well with named single arguments (child, body, etc.), named collection arguments (children, actions, etc.), and positional arguments.
I also spent a lot of time exploring a block-based syntax but couldn't figure out a syntax that I felt covered enough of the bases to be worth the additional complexity and switching costs. In particular, a block based syntax that still requires you to two sets of brackets to specify a list of children seems unsatisfactory to me:
Row {
  children: [
    item,
    item
  ]
}

I noodled some on being able to hoist those out of the outer brackets:
Row() children [
  item,
  item
]

Syntactically, I think this might actually work. But I'm really worried it's just too weird. It's not totally unexplored territory. Grace supports something similar. It would take a lot of time to investigate this and see if something hangs together. There's a good chance it falls apart once you try to figure out how it interacts with things like method chains, subscript operators, etc.

a block based syntax that still requires you to two sets of brackets to specify a list of children seems unsatisfactory to me

I wonder if we are thinking about child widget properties backwards. These properties indicate "slots" inside a parent, but at the technical level we chose to use parameters to express them. So this argument bias keep following us into all of our proposals. Let's consider the Scaffold widget. I has multiple slots, but let's focus on body and persistentFooterButtons for a moment.
Currently you would use Scaffold like this:
Scaffold(
  body: Home(
    ...
  ),
  persistentFooterButtons: [
    FlatButton(
      ...
    ),
    RaisedButton(
      ...
    ),
  ],
);

While these slots are technically properties (passed as arguments), perhaps conceptually they are actually widgets, even though we do not have an explicit widget classes for them. This might sound weird, but in the HTML world (including Angular, JSX, etc) you might express this as:
<scaffold>
  <body>
    <home>...</home>
  </body>
  <persistentFooterButtons>
    <flat-button>...</flat-button>
    <raised-button>...</raised-button>
  </persistentFooterButtons>
</scaffold>

So if HTML elements are like Flutter widgets, then "body" and "persistentFooterButtons" elements are also "widgets". If we syntactically translate this back to the block proposal, what we get is this:
Scaffold {
  body {
    Home {
      ...
    }
  };

  persistentFooterButtons {
    FlatButton {
      ...
    };
    RaisedButton {
      ...
    };
  };
};

I admit, I have no idea how something like this can fit into the language. But I like how it looks! And the extra brackets are actually useful.

amusingly, it was the result of exactly the opposite line of reasoning that led to where we are now. we started with html, then web components. in a world with aggressive composibility, there's really nothing special about a slot taking a particular type of widget, or a slot taking an arbitrary widget, or any other kind of argument. Flutter certainly commonly uses widgets, but there's no reason why you have to use them as your child of your widget... for example we sometimes use TextSpan objects as children. Indeed in Flutter Sprites you transition to an entirely different class hierarchy.
A lot of our design is drawn from trying to avoid the design limitations that we saw on the web as a result of the approach you describe above.

That's why I wrote "widgets", and not widgets :) They don't have to be instances of sub-classes of Widget. So TextSpan would qualify. I'm also not trying to argue that HTML as a whole is good UI language. It just happened to work for this particular case. HTML attaches a lot of undesired semantics to that syntax, in addition to the semantics that developers and framework authors want, and there's plenty that it can't do that developers do want, leading to awkwardness (see Angular's "directives" and the numerous annotations for binding to HTML). There are plenty of non-HTML examples btw, such as Anko - a DSL for Android layouts for Kotlin, or QML that uses block syntax not just for building widget hierarchies, but also for state machines.
I think a language's job is not only to provide a sufficient number of nouns and verbs for developers to express logic, but also provide syntactic visual cues that can be used by libraries and frameworks to guide the developer when they read and try to understand code. For example, visual locality and isolation of related logic is very powerful for code understanding. That's why we have functions, closures and classes. Blocks simply extend that to anonymous non-reusable pieces of related logic (for example, initializing arguments, writing unit-tests), and they do that without any extra runtime cost. For example, they do not allocate objects.
However, we definitely need to make sure there is place in the framework where new syntax actually provides useful guidance.  Widgets created inside build methods are one obvious place. But that's not enough. It should be applicable in more places. Hence the idea above.
Perhaps the defining characteristic of what should use the special syntax is when something takes up space on the UI (think layout), something you can point at on the screen, give it a name and that name will coincide with a name used in the code. Think Padding, FlatButton, children, home, TextSpan, builder. I would also expect it to be something that has a lifespan. It's not just a paint operation, like drawRect, but either an object by itself (e.g. a widget), or owned by an object (e.g. a property of a widget). So the visual cue of the name { } brackets implies a UI building block, and sets it apart from name() and name = .

I did toy with a syntax similar to what you have here, and also played around with something like:
Scaffold {
  body: Home {
    ...
  }

  persistentFooterButtons:
  FlatButton {
    ...
  };
  RaisedButton {
    ...
  };
};

It got weird pretty fast and I couldn't come up with anything that I felt held together. With your syntax, what are the actual semantics you have in mind? It seems like you use a postfix block to mean two different things in different contexts. In some places, it's an argument block where the name is a constructor/function and in others the name is a named parameter and the block is the list of values for it.
Is that what you had in mind? How would the language reliably know which behavior you intend in any given context?

With your syntax, what are the actual semantics you have in mind?

For Scaffold { ... } it's the AIB as in the current proposal. For body { ... } and persistentFooterButtons { ... } the closest thing I can think of is initializer lists from C++. For example, the nlohmann JSON library uses them as DSL for expressing JSON:
// create an empty structure (null)
json j;

// add an object inside the object
j["answer"]["everything"] = 42;

// add an array that is stored as std::vector (using an initializer list)
j["list"] = { 1, 0, 2 };

// add another object (using an initializer list of pairs)
j["object"] = { {"currency", "USD"}, {"value", 42.99} };

// instead, you could also write (which looks very similar normal JSON)
json j2 = {
  {"pi", 3.141},
  {"happy", true},
  {"name", "Niels"},
  {"nothing", nullptr},
  {"answer", {
    {"everything", 42}
  }},
  {"list", {1, 0, 2}},
  {"object", {
    {"currency", "USD"},
    {"value", 42.99}
  }}
};

(source)

It seems like you use a postfix block to mean two different things in different contexts. In some places, it's an argument block where the name is a constructor/function and in others the name is a named parameter and the block is the list of values for it.

Right. We already use { } for all kinds of things: classes, maps, named parameters, methods, functions, switch statements, etc. This just continues the trend.

How would the language reliably know which behavior you intend in any given context?

Haven't thought about it that far yet :) Borrowing from C++ initializer lists, the type of the LHS "expression" could be used. The language knows that body is a parameter of type Widget which inside an AIB can only be assigned to, therefore body { ... } can be treated as assignment. persistentFooterButtons is the same, except its a List and so the language treats persistentFooterButtons as a "list initializing block". Obviously, we'll need to introduce this "list initializing block" in the first place. I'm guessing it will differ from the normal "block", as in, it's not a list of statements (otherwise we'll need something like yield, which is a no go). Perhaps a list of expressions is sufficient, if it can also be supported by the control flow proposal. Optional semi-colons and optional commas could help here so users do not have to think about the different kinds of punctuation.

I do like that you're pushing on this

+1
This is a very useful discussion.

I posted it before in another thread, but this is the more appropriate place.
The main idea (or conjecture, if you will) is that while scanning the line, our eye gives disproportionate attention to the first character. I would say, extremely disproportionate. Unfortunately, I don't know how to measure it exactly, but let's assume this is true, just for the sake of argument. What immediately follows is that while writing parameters/children in this literals, we need a good first character that triggers some neurons the brain, so to speak.
Card{
    .color= Colors.white;
    +Center{
        +Column{
            .mainAxisSize = MainAxisSize.min;
            .crossAxisAlignment = CrossAxisAlignment.center;
            +Icon(choice.icon, size: 128.0, color: textStyle.color);
            +Text(choice.title, style: textStyle);
        }
    }
}

Of course, you can write any procedural logic in the initialization block, and with prefixes, it remains readable
Card{
    .color= Colors.white;
    +Center{
        +Column{
            .mainAxisSize = MainAxisSize.min;
            .crossAxisAlignment = CrossAxisAlignment.center;
            +Icon(choice.icon, size: 128.0, color: textStyle.color);
            for (int i=0; i<10; i++) {
              +Text("line${i}", style: textStyle);
            }
        }
    }
}

In my opinion, this format is just "good enough" for the eye. Whether dart can accommodate it naturally is another issue, but I think it's just a minimal addition to the proposals discussed above. Except "child". For "child", we also need plus, and I don't know how to formally justify it for a single-valued parameter.

In attempt to find a scientific justification for my "first character effect" claim, I did some research on internet and found this post.
https://www.creativebloq.com/ux/how-human-eye-reads-website-111413463
The article claims that the first scan of the document is vertical: the eye is looking for the points of interest. I tried to conduct an experiment: opened several Flutter examples to see how I scan them. Indeed, I scan them vertically, and the points of interest (at least for me) are nested widgets. Attributes don't matter much at that point. At the first scan, my eye is focused only on the leftmost part of the code. But with the current way of presentation, the points of interest are hidden. There's too much noise in the code (esp. 'child' and 'children'), and nothing in particular really stands out. So the initial scan completely fails to identify the structure. If we are concerned about the ease of reading - then emphasizing the points of interest should be the first step IMO.
The trick with plus and asterisk helps with that. But leading dots in the names of attributes - I'm not sure about them.  If the idea of "initialization block" gets any traction, these dots might be good for disambiguation (in case of name collisions with the local variables), but on the other hand, they might create too many "points of interest".
Is there anybody who likes the idea of asterisk and plus symbols? They are easy to explain:
\*X is simply a shortcut for child=X, and +X - shortcut for children.add(X). There;s nothing magic about the names child/children - it can be any attribute, appropriately annotated.

@tatumizer That is an intriguing idea. Certainly looking at your examples, despite my eyes untrained to such syntax, I can tell properties apart from child widgets. So I think the "first character" effect works. I bet if we add syntax highlighting it can be even clearer.
Having said that, it does not seem to solve the "child" vs "children" vs "home" vs "persistentFooterButtons" problem, i.e. it does not have child slots that many widgets have.

@yjbanov : Glad to hear that! :)
For persistentFooterButtons and other things that don't fit, let's take a hammer and make it fit :)
E.g. persistentFooterButtons may be redefined as WidgetContainer<Button> (introduce a new class, if needed) or something (*), and suddenly, we have "children". This would be good for pedagogical purposes anyway (uniformity!). How about that?
(*) I'm not familiar with current Flutter taxonomy, have to make things up, sorry.

Here's another (better?) idea:

retrofit every List with a constructor accepting vararg  parameter "...items"
general rule: for every vararg parameter, by default allow "+" notation in the initialization block, so the declaration will look like

Scaffold {
  body: Home {
    ...
  }
  persistentFooterButtons: List<Button> {
    +FlatButton {
     // ...
    }
    +RaisedButton {
      //...
    }
  }
}

As a consequence, the list types that require some other arguments (e.g. growable: true) will fit in the same template, with extra named parameter, e.g.
var foo = List<Button> {
  growable: true
  +FlatButton {
     //...
  }
  +RaisedButton {
     //...
  }
}

For "body", I'm not sure about its role, but: whether the asterisk is allowed or not, is determined based on special annotation (no general rule), so maybe "body" parameter can be annotated with "@enableAsteriskNotation", so we still get the same format
Scaffold {
  *Home {
    ...
  }
  persistentFooterButtons: List<Button> {
    +FlatButton {
     // ...
    }
    +RaisedButton {
      //...
    }
  }
}

There are other possibilities, of course :)
What's important is that the format eliminates the noise almost entirely: if the proposal of optional semicolons is accepted, the above notation will be completely free of semicolons and commas; instead of 3 types of brackets (..), [...] and {...} we will have only one {...}; we replace identifiers like child and children with easily recognizable symbols... I think the users will appreciate it :)

@Hixie: as our discussion progressed (above), the definitions gradually became more general, so it's not child vs children dichotomy any more. Instead, it's this:  if your constructor has vararg parameter List<Foo> ...slivers , it allows the syntax  with the "plus" sign in the initialization block. Maybe it needs a special annotation for that, But the name of the parameter can be anything. The alternative is to declare it simply as a list (not vararg) named parameter `List slivers, but then, the List itself, being retrofitted with vararg parameter, allows the notation like this:
Foo {
   //...
  slivers = {
    +Sliver {
        //..
    }
    +Sliver {
      //..
    }
  }
}

Plus signs are important for reasons that are not logical, they are here to trigger some properties of the eye, which you need to be a neuroscientist to explain, and even that I'm not sure.
"There are more things in heaven and earth, Horatio,
Than are dreamt of in your philosophy"
(Hamlet 1.5.167-8)
Do you agree? :)

There's a few symbols that seem to work as well as plus. The best I found so far is a right-pointing triangle. Not sure whether (and how) text editors can support it, but this one on github displays it correctly
Card {
  color= Colors.white;
  ▷Center {
    ▷Column {
      mainAxisSize = MainAxisSize.min;
      crossAxisAlignment = CrossAxisAlignment.center;
      ▷Icon(choice.icon, size: 128.0, color: textStyle.color);
      ▷Text("line${i}", style: textStyle);
    }
  }
}

Leaving this here as a data point: https://devrant.com/rants/1897404/i-really-do-like-flutter-dart-but-i-just-cannot-be-the-only-who-thinks-that-the

It's all subjective, but to fully appreciate new syntax, you have to see it in IDE, which shows vertical indent guides that get appropriately highlighted when you click on a section of your literal. Unfortunately, github markdown renderer doesn't show them. This may, or may not, convince you, but please give it a try.

I am more concerned with what code looks like in a YouTube video or on a slide deck or a GitHub gist or a reddit post, than I am in what it looks like in an IDE. IDEs can always be made to mechanically convert whatever syntax we use to whatever syntax you prefer to make things Just Work. YouTube videos and the like can't be changed, and it's those where the readability is paramount (because that's what the people least familiar with the code will be looking at).

I would not be a fan of this change.
As soon as optional things start to depend on the order of definition, bad things happen for forward/backward compatibility.  See, for example, https://github.com/flutter/engine/pull/5275#discussion_r188770256.  If we could have additionally added named parameters to that it might have been slightly better, but all of the sudden it becomes a ton of cognitive overhead ("is this one of the ones I have to put in the right order or that I have to name?") - it really would have been better if they were all just named parameters to begin with, as you can then more easily and clearly add or remove/deprecate parameters as necessary for future revisions.  This also means that I would generally look to avoid using "rest" parameters in exposed methods on the framework, except for maybe something like "hashValues" from dart:ui.
It seems like it would be even worse to start trying to automagically determine which parameters are "content" and which are "attributes".  I could see some value in having annotations for that, e.g.:
class FooWidget extends StatelessWidget {
  FooWidget({
    @attribute this.color,
    @attribute this.elevation,
    @content this.child,
  });
  ...
}

Which could then be used by an IDE to provide more context/better rendering without harming the actual code that's written - and which, I think, is pretty clear when written properly and not nested too deeply (instead composing the tree from smaller functions/classes).

The distinction between "attribute" and "content" is a really loose one which I don't think makes much sense in Flutter anyway.

The distinction between "attribute" and "content" is a really loose one which I don't think makes much sense in Flutter anyway.

I'm not yet fully convinced by this argument. To me it sounds like saying that the difference between a widget and render object is small because they are just objects. If something has a specific role and semantics, is frequently used, and code readability benefits from that thing to stand out in the code, it may be worth investigating specialized syntax for it.
I see attributes vs content dichotomy similar to other precedents where language research concluded it is beneficial to use special syntax and semantics:

Value types vs classes
Lists vs tuples
Pattern-matching vs if/else
Methods vs operators

And yes, many UI toolkits have opted into providing two languages: Angular (code vs templates), Android/iOS (controllers vs layout XML), React.js (code vs HTML literals), Qt (code vs QML). I hope we don't end up in that situation, and instead solve the issue inside the main language.
I think our developers want their UI layout code to stand out from the rest, and they also want a nice syntax for it. We just need to spend some time understanding what "UI layout code" is and how much code would fall into this category to benefit from whatever alternative syntax is offered. While I agree that rest arguments is not a great solution, I do believe the problem is real, and that we should invest in researching it.

The distinction between "attribute" and "content" is a really loose one which I don't think makes much sense in Flutter anyway.

Although it can be a valid philosophical point, this distinction constitutes the basis of XML (and HTML) notation. Everybody got used to it already, so the issue is hardly controversial. IMO, It would be wise for dart to capitalize on this already well-developed intuition, rather than to fight against it.
It's just a matter of HOW :)

Maybe we reached the point where it would be worthwhile to consider some radical alternatives?
Let's forget for a second about Flutter and widgets. Suppose are writing a program that simply computes something, but the calculations are complicated, so we have a function that depends on 10 parameters, each of the parameters in turn depending on other parameters, etc.
My question is: how would you write the invocation of such function? Would it be a single, 50-line-long, deeply nested construct? Probably not. To keep things manageable, we need intermediate variables - perhaps lots of them, but that's the only way for a reader (and ourselves, too) to make sense of our program.
The question I'd like to ask is: maybe in our quest for the best notation for Flutter literals we are barking the wrong tree? Maybe we are trying to solve a problem that doesn't really exist? We got fixated on monolithic literals whereas the solution is trivial: just decompose a complex thing into a number of simpler things?
There are some examples of Flutter code of extraordinary complexity found in Bob's write-ups. Consider this code.
Probably there's someone who can understand it, but it's not me. Faced with the perspective of maintaining such code, I would have no choice but to take it apart, defining one small thing at a time and gradually working my way up (in fact, I had to do that in real life while fixing problems in some clever javascript code). I tried to do the same for the Flutter snippet in question, and here's the sketch of what I've got:
var cupertinoTabScaffold = CupertinoTabScaffold(
   tabBuilder: (BuildContext context, int index) => cupertinoTabView(context, index)
);

cupertinoTabView(BuildContext context, int index) => CupertinoTabView (
  builder: (BuildContext context, int index) => cupertinoPageScaffold1(context, index)
);

cupertinoPageScaffold1(BuildContext context, int index) => CupertinoPageScaffold(
  navigationBar: CupertinoNavigationBar(
    middle: Text('Page 1 of tab $index')
  ),
  child: nextPageButton(context, index)
);

nextPageButton(BuildContext context, int index) => Center(
  child: CupertinoButton(
    child: const Text('Next page'),
    onPressed: () => onNextButtonPressed(context, index),
  )
);

onNextButtonPressed(BuildContext context, int index) => Navigator.of(context).push(
  CupertinoPageRoute<Null>(
    builder: (BuildContext context) => cupertinoPageScaffold2(context, index)
  )
);

cupertinoPageScaffold2 (BuildContext context, int index) => CupertinoPageScaffold(
  navigationBar: CupertinoNavigationBar(middle: Text('Page 2 of tab $index')),
  child: backButton(context)
);

backButton(BuildContext context) => Center(
  child: CupertinoButton(
    child: const Text('Back'),
    onPressed: () => Navigator.of(context).pop()
  )
);

The size of the program is about the same as the original. Most of the nested blocks are gone. Sub-components acquired recognizable names. What not to love here? (someone can prefer writing the functions in a different order: from bottom up instead of top down - this a matter of taste)
The only downside I see is: we have to pass BuildContext around. Not sure this is a big deal. Someone can even argue it makes the dependency on BuildContext more explicit, which is a plus. But a huge advantage (other than reducing complexity) is that we can use control flow freely in any of these intermediate functions, which is very hard to achieve with literals.
I don't know the reasons for Flutter tutorials to prefer single monolithic literals, can't speculate. But what if we just tell the truth instead: there's only so much complexity such literals can handle. Beyond certain point  - we need decomposition.
How about that?

As an abstract exercise, if we were allowed to implement DSL, what would it look like?
Here's an (original?) idea: to write the structure of the widget in a manner that lends itself to human understanding, we need to first create a concise bird's-eye view, representing only the child-parent and sibling relations. Then we can fill the details.
Relation of "A is a parent of B" can be represented as multiplication A*B;
Relation of "X is a sibling of Y" - as a sum X + Y.
Example:
BEFORE:
Card (
  color: Colors.white,
  child: Center (
    child: Column (
      mainAxisSize: MainAxisSize.min,
      crossAxisAlignment: CrossAxisAlignment.center,
      children: [
        Icon(choice.icon, size: 128.0, color: textStyle.color),
        Text(choice.title, style: textStyle)
      ]
    )
  )
}

AFTER:
Card card * Center center * Column column * (Icon icon + Text text) where
   card = (color: Colors.white),
   column = (minAxisSize : MainAxisSize.min, crossAxisAlignment: CrossAxisAlignment.center),
   icon = (choice.icon, size:128.00, color: textStyle.color),
   text = (choice.title, style: textStyle)

My theory is:

The readability of the expression is higher than that of all popular alternatives (including JSX)
Adding/removing components is trivial (in contrast with the current notation)

This is a raw idea so far, needs more work to accommodate some use cases.

A better choice would be: ">" instead of "*", so the expression will look like
Card card > Center > Column column > (Icon icon + Text text) where
   card = (color: Colors.white),
   column = (minAxisSize : MainAxisSize.min, crossAxisAlignment: CrossAxisAlignment.center),
   icon = (choice.icon, size:128.00, color: textStyle.color),
   text = (choice.title, style: textStyle)

More complicated example:
BEFORE:
CupertinoTabScaffold(
  tabBuilder: (BuildContext context, int index) {
    return CupertinoTabView(
      builder: (BuildContext context) {
        return CupertinoPageScaffold(
          navigationBar: CupertinoNavigationBar(
            middle: Text('Page 1 of tab $index'),
          ),
          child: Center(
            child: CupertinoButton(
              child: const Text('Next page'),
              onPressed: () {
                Navigator.of(context).push(
                  CupertinoPageRoute<Null>(
                    builder: (BuildContext context) {
                      return CupertinoPageScaffold(
                        navigationBar: CupertinoNavigationBar(
                          middle: Text('Page 2 of tab $index'),
                        ),
                        child: Center(
                          child: CupertinoButton(
                            child: const Text('Back'),
                            onPressed: () { Navigator.of(context).pop(); },
                          ),
                        ),
                      );
                    },
                  ),
                );
              },
            ),
          ),
        );
      },
    );
  },
)

AFTER:
@DSL CupertinoTabScaffold * CupertinoTabView * CupertinoPageScaffold *
  (navigationBar(CupertinoNavigationBar bar1) + Center * CupertinoButton btn1 * Text nextPage)
where
  bar1 = (middle: Text('Page 1')),
  btn1 = (
    onPressed: () => () {
      Navigator.of($context).push(
        @DSL CupertinoPageRoute<void> * CupertionPageScaffold *
          (navigationBar(CupertinoNavigationBar bar2) + Center * CupertinoButton btn2 * Text prevPage)
        )
    }
  ),
  bar2 = (middle: Text('Page 2')),
  btn2 = (onPressed: () { Navigator.of($context).pop(); },
  nextPage = ("Next page"),
  prevPage = ("Back"),

NOTE: I tried to use ">" instead of "*", but it didn't work because the precedence of "+" is higher than ">", which makes ">" a non-starter.
In the code above, I assumed that context can be passed automatically as $context, so there's no need to write an explicit builder.
Not sure this assumtion is correct though.
Does anyone like the notation?

Does anyone like the notation?

This is similar to Rust's generic bound constraint notation. I think this notation works when you want to declutter a long declaration or expression by moving non-essential details out of it. This works for generics because when you read a function declaration the first thing you usually want to parse out is the overall signature. However, Java-style generic syntax that inlines the generic bounds tends to obscure the signature. This makes it especially hard for new programmers to read. So I think this notation works there.
However, widget properties are not clutter and their locality to the construction invocation improves code readability. If you need to inspect/change the middle or onPressed property you don't have to look hard to find it.

You don't have to look especially hard to find the details: IDE will help you to jump to the right place.
Speaking of clutter: the whole point of the notation is to get rid of a real clutter - overwhelming amount of punctuation (different types of braces, parens etc.).
As with every notation, there are PROs and CONs. This notation addresses major pain points discussed in the write-up (poor utilization of horizontal space, proliferation of braces, poor readability in general). The trade-off is some modest amount of non-locality introduced in the code, which is quite normal in programming. I think the users would appreciate it, but it's hard to speculate without experimentation.

IDE will help you to jump to the right place.

Yes, but not Github, StackOverflow, code review tools, and many others.

real clutter - overwhelming amount of punctuation (different types of braces, parens etc.)

I agree that excessive punctuation is a problem. However, I'd first verify if we can fix it with less drastic language changes, such as the optional semicolons proposal.

I think optional semicolons issue is absolutely orthogonal to the one this notation aspires to address. In fact, in the unwieldy CupertinoTabScaffold expression (BEFORE), I was able to locate just 5 semicolons (over 37 LOC), and after removing them, the new code looks exactly like the old one, readability-wise - at least for my eye :)

Yes, but not Github, StackOverflow, code review tools, and many others.

This argument applies to just everything. You have function foo defined in one place and called in another place - sometimes in a different module; you have an uninitialized instance variable which gets defined 100 lines later, etc. In the DSL above, the stuff is still local, it's just 5 lines below. You don't need IDE to find it.
Anyway, if somebody likes the idea, maybe it makes sense to brainstorm it? E.g. by opening another thread? There can be a lot of potential in there, would be too bad to throw it away out of hand, without even exploring it.

Couldn't some of this just be solved by following conventions around this?  Perhaps with analyzer lints to help enforce them (e.g. a lint to check how deeply nested an in-line declaration is, or a lint to enforce that arrays not be specified inline, or perhaps even a configurable lint that takes types and parameter names and checks that they're done in or out of line).
E.g. rather than:
return SomeWidget(
  helpfulInline: Colors.blue,
  children: <Widget>[
    AnotherWidget(...),
    // more definitions
  ],
);

Use
final AnotherWidget another1 = AnotherWidget(...);
...
final List<AnotherWidget> children = [another1, ..., ..., ....];

return SomeWidget(
  helfpulInline: Colors.blue,
  children: children,
);

@dnfield: that's exactly what I did! I could stare into CupertionTabScaffold for hours, unable to make any sense of a single line. Then, in complete desperation, I decided to cut it into a bunch of macaroni, as you suggested, which resulted in this post of mine
Voila! Now I could perfectly understand each line, but my joy proved to be premature: macaroni didn't want to fuse back into a clear view of the whole cupertiono scaffold. Or, rather, there was a kind of scaffold, certainly, but the one that didn't want to stand on a firm ground - instead, it kept floating in the air as a blurred blob of varying proportions.
The problem, as far as I realize it, is that my brain doesn't appear to be well-suited for understanding of deeply nested constructs, no matter how they are laid out.
And then, when all hope seemed to be lost, came the discovery: DSL notation! I saw it in my dream! With multiplication for nesting and plus for siblings! I woke up in utter excitement and rushed to my computer to put it on paper and send to this thread before I forget the whole thing. Because I had a similar clairvoyance experience in the past: I once had a dream of newly discovered John Lennon's song, I could hear the melody in finest detail - it started out plainly, as usual for the great composer, but then,
all of a sudden, modulated into a different key, and the thing was of such unearthly beauty that I immediately woke up overflowed with deep emotions, my first impulse being to
urgently rush towards Bosendorfer piano in my studio to embellish the melody by adding a bit of pizzicato here and there, write it all down and send to the recording company.
Unfortunately, at that moment, as the sense of reality began to ooze into my mind, it dawned on me that I don't have Bosendorfer piano 😢 In fact, I don't even have a studio - apparently, it came from another dream I had a week earlier. And frankly, I don't quite know how to play piano beyond "Fur Elise" by L. van Beethoven - highly controversial piece that evokes some disturbing memories of my childhood. 🤢
Totally disappointed, I rolled over, fell asleep again, and when I woke up a couple of hours later, I couldn't remember a single note from the never-written J. Lennon's song.
Now, the idea: what if we call it "John Lennon's notation"? Think about it: it's beautiful, concise notation, which is elegant and sophisticated at once - just like John Lennon's songs, isn't it?

Records could be used for the "slot" issue
Scaffold(
     color: x,
     background: y,
     (
       body: Body(),
       floatingActionButton: FloatingActionButton(),
     )
)

Records could be used for the "slot" issue, when there are multiple slots instead of one child / children

This is a clever idea! I'll think about this more. :)


undercloud.qcow2.md5 should not contain absolute path

As documented at [1], it's a good idea to verify the md5sum of the downloaded undercloud image. However, when executing md5sum -c undercloud.qcow2.md5, the check will fail:
[root@rdo mitaka]# md5sum -c undercloud.qcow2.md5
md5sum: /tmp/oooq-images/undercloud.qcow2: No such file or directory
/tmp/oooq-images/undercloud.qcow2: FAILED open or read
This is, because the undercloud.qcow2.md5 file [2] includes an absolute path after the checksum:
6c7dc0e0b14b7b3deff0da284594d778  /tmp/oooq-images/undercloud.qcow2
Instead of just the file name as expected, like this:
6c7dc0e0b14b7b3deff0da284594d778  undercloud.qcow2

[1] https://www.rdoproject.org/rdo-manager/
[2] https://ci.centos.org/artifacts/rdo/images/mitaka/delorean/stable/undercloud.qcow2.md5

proposed fix:
https://review.gerrithub.io/#/c/264886/

fix merged, but it will take a newly promoted repo in order to get a new md5


CI: test on beta

also recommend readers to use the beta channel
r? @rust-embedded/resources (anyone)

bors r+


Case service incorrectly configured

The case service was incorrectly configured to process only 50 cases every .5 seconds and the rabbit queue is only using a single thread as consuming threads.
changes to case distribution process count and delay and rabbit queue consuming threads. This is it now configurable as a part of the deployment.

/deploy sinhaa

/deploy sinhaa


New Homestead Brownout quest/mission

The mission for the brownouts in New Homestead is not starting.

Details
The brownout mission/quest in New Homestead is not triggering/being added to my mission log. I spoke with the Joyce Osaka npc, went through all the dialogue, and the quest did not start when I finished speaking with her. I do not have any mods that would or should interfere with this quest.
Game Version
<IP_ADDRESS>
Language
English (EN)
New Game
No
Reproduction Steps
Enter New Homestead and speak with Joyce Osaka.

Not able to replicate the bug on my end, but looking it up online, this seems like quite a common one. Can you perhaps send your save file?

This is reportedly fixed officially in 1.14.


Link to special OSM editor to update pump status

We build a special MapComplete Theme that allows to view and edit the OSM date of Berliner Straßenbrunnen in an easy/easier way.

Example https://mapcomplete.osm.be/theme?lat=52.47525&lon=13.44245&userlayout=https%3A%2F%2Ftordans.github.io%2FMapComplete-ThemeHelper%2FOSM-Berlin-Themes%2Fman_made-walter_well-status-checker%2Ftheme.json&language=de#node/760002892
Code https://github.com/tordans/MapComplete-ThemeHelper/tree/main/OSM-Berlin-Themes/man_made-walter_well-status-checker

It would be great if we could link this editor from the Straßenpumpen Infopanel:

I wanted to contribute a PR but now I see that the info panel is on hover, so it's not just adding a link in the panel.
Please let me know if this feature is a good fit for the project / would be accepted.
And your thoughts on how to add it.
My first take is, to add an info text inside the hover info panel saying "Double click the Straßenbrunnen-Circle to open a special OpenStreetMap editor and update the Pump status and check data."
What do you think?

Hi @tordans! Great editor! This will make it way easier for people to contribute to better pump information! Thx a lot!
I created a PR #461 based on your comment but with a slightly different UX. Instead of double clicking (Which is IMHO not very intuitive), the tooltip can be stuck by clicking once on a pump. This way the new link "Edit this OSM info" in the tooltip can be reached.
Let me know what you think! :)
https://user-images.githubusercontent.com/2759340/175332165-cea1b869-32c2-4861-adea-fb15821c405a.mov

@vogelino thanks, this looks great!
I have two comments:
Link
const OSM_PUMP_EDITOR_URL = https://mapcomplete.osm.be/theme?z=14&lat=52.51486&lon=13.44662&userlayout=https%3A%2F%2Ftordans.github.io%2FMapComplete-ThemeHelper%2FOSM-Berlin-Themes%2Fman_made-walter_well-status-checker%2Ftheme.json&language=de#node`;`
https://github.com/technologiestiftung/giessdenkiez-de/pull/461/files#diff-de388be53c7c138eee97b7cc7868b884d8b1cbe605ca474388d8f5d426caef81R33
The URL has the lat/lon/zoom hard coded which will make the map jump and reload data AFAIK.
Do you have access to the those map props inside the panel? We could then do something like…
const mapCompleteURL = ({lat, lon, zoom, nodeId}) => {
  const mapcompleteUrl ='https://mapcomplete.osm.be/theme'
  const params = new URLSearchParams()
  params.set('userlayout', 'https://tordans.github.io/MapComplete-ThemeHelper/OSM-Berlin-Themes/man_made-walter_well-status-checker/theme.json')
  params.set('lat', lat)
  params.set('lon', lon)
  params.set('z', zoom)
  params.set('language', 'de')
  const selectedPump = `#node/${nodeId}`
  return `${mapcompleteUrl}?${params.toString()}${selectedPump}
}

Wording

OpenStreetMap PumpenInfos bearbeiten

https://github.com/technologiestiftung/giessdenkiez-de/pull/461/files#diff-de388be53c7c138eee97b7cc7868b884d8b1cbe605ca474388d8f5d426caef81R736
I think we can focus this a bit more on the operational status of the pump, since this theme will only allow editing those fields to keep it simple.
How about

Status in OpenStreetMap aktualisieren

or

Status und check in OpenStreetMap aktualisieren

Ping @supaplexosm FYI

@tordans thx for your feedback. These are very good points.
I think we do have those coordinates at this point and we should be able to encode them into the url as suggested.
I also agree with your wording feedback and I root for the first suggestion. @Esshahn what do you think?
I will take care of it next week but feel free to do a PR against staging if you wish us to accelerate the process.
Have a nice weekend!

Hi @tordans. I changed the wording and ported your URL function to our code. However, wenn encoding the latitude and longitude into the URL, the OSM page doesn't load the pumps initially when opened via link but does when entered in the browser search bar. I cannot figure out why this happens. When omitting the lat/lng/zoom, the page loads correctly when opened by zoom. Any idea why this happens?
PS: This PR #466 includes the changes

I tested with https://mapcomplete.osm.be/theme.html?userlayout=https%3A%2F%2Ftordans.github.io%2FMapComplete-ThemeHelper%2FOSM-Berlin-Themes%2Fman_made-walter_well-status-checker%2Ftheme.json&language=de#node/5907103888 and it looks like, the lat/lng is not needed at all. I think MapComplete does a lookup of the node first (or early on during render) and then moves the map to this lat/lng right away.
So it look like this is all we need, right (AKA the PR is fine this way)? — I might be missing something …

PS: Is the staging URL public so I could test it there (later)?

Cool! I see it the same way. Yes the PR is fine. I will merge it and then you should be able to test it. I'll let you know!

FYI, I just twittered about this https://twitter.com/osmberlin/status/1546020018856534016.
And this OSMCha list shows all edits made with the editor. RSS


Player Automatically Accepts Invitation When Push Notification Selected

I am using your repository for a project of mine, and I am observing the following behavior:
In a game created with a specific opponent to invite, after the first turn is sent, the opponent player receives two push notifications simultaneously: first, a 'Game Center Invitation', then a 'Game Center Turn'. If one of the two push notifications is touched, the app is entered and the invite is accepted. If I launch the app manually, the game properly appears in "Invited by opponent".
This could be something I'm doing wrong, but I have yet to find the solution and was wondering if this is being observed by yourself as well.
Is there a specific method called when the user selects one of these push notifications? Maybe I'm just not handling properly.
Any information would be appreciated, even if it's just that I'm doing something wrong. Thanks!

In the func playFirstTurn(match: GKTurnBasedMatch) there is a sendReminder method called:
GameCenterSingleton.sharedInstance.sendReminder(match, completion: {                 _ in             })
If you remove that it should fix the problem.
GameCenter does not always inform the opponent for the new game and sendReminder was a hack to allow for the opponent to receive the notification.

Thank you for your response.
Removing the line you suggested prevents the second push notification, but I am still seeing that issue that selecting the push notification for the Invitation launches the game and automatically accepts the invite.  The way the project is designed, I imagine selecting this push notification should open the app but still leave the match in the "Invited by opponent" state.

I see what you're saying. Well, from my understanding, selecting the push notification is like accepting the invitation. I have no control over what method is called when the push notification is tapped. The method that accepts the invitation is automatically run by GameCenter. Thus, I suppose that this is indeed the intended behavior.

Okay, thank you! I consider the issue closed in that case. Thanks for this project, it has helped me a lot.


Cloogle does not seem to find entries from SoccerFun

On Windows, independent from browser, having selected the StdEnv and SoccerFun library in the Miscelleneous section, does not seem to find entries from SoccerFun. Attempted queries: 'type Footballer' and 'class dist'.

You need to enable "include apps" in the advanced search options. Results from SoccerFun, clean-compiler, clean-ide and other applications are hidden by default as they are not useful unless you are working on that particular application.

Ah, I see. I notice that if you hover the mouse sufficiently long over the (app) description, you actually get a notice that tells you that you might want to tick the include apps box. However, my attention got distracted because almost as soon as you hover the mouse over the (app) description, an i marker shows up, which led me to click on that, showing the SoccerFun homepage. After that, I didn't go back to the (app) description.
How feasible would it be that if a user selects a category that requires (app), to also select the Include apps option? Or perhaps, change the text of (app) into (requires Include apps)?

This issue was moved to clean-cloogle/cloogle.org#212


Error on get install by composer

Hi Guys !
Following the installation guide, I was unable to install Slim via Composer.
I used the following command:
Composer require slim / slim "^ 3.0"
And the following error occurred:
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- The requested package slim / slim No set (parsed as 1.0.0) is satisf
Iable by slim / slim [No version set (parsed as 1.0.0)] but these conflict with you
R requirements or minimum-stability.
Best Regards,
Charles

Did you write slim / slim?
To install slim via composer you have to write slim/slim ;-)

I typed:  composer require slim/slim
But the error is:
Problem 1
- The requested package slim/slim No version set (parsed as 1.0.0) is satisf
iable by slim/slim[No version set (parsed as 1.0.0)] but these conflict with you
r requirements or minimum-stability.
Installation failed, reverting ./composer.json to its original content.

remove what you have in composer.json for slim and retry

No worked. I think is my PHP.ini is not configured properly. What i need enable to use slim?

What does php -v output?

The output is:
PHP 5.6.31 (cli) (built: Jul  5 2017 22:25:43)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies

I would try the following:
$ composer self-update
$ composer clear-cache
$ mkdir test
$ cd test
$ composer require slim/slim

I am going to close this as I know composer install of slim works given that I use it daily for production updates. Please reopen if you are still having issues.

Still came across same issue. managed to sort by re-configuring my .phar file, but important to trace the exception trace - use the vvv flag. Check your permission structure


Parity: I just checked in a change to the feedback the JSONResponseValidator gives for errors

https://github.com/Stevenic/alphawave/commit/b829f475d21b859dee1d00b17ff6f0412a242651
I had a situation where gpt-3.5-turbo returned a JSON object where it had changed a string property into an array of strings. I wasn't able to fix this with the existing feedback. The issue turned out to be the passive nature of the error messages returned by the JSON schema validator.  I was returning feedback like:
The JSON returned had the following errors:
"instance.thoughts.plan" is not of a type(s) string

Return a JSON object that fixes these errors.

And the model would just kick back the same object it gave me before with the same issue. I ultimately got it to correct the error in playground by changing the feedback to this:
The JSON returned had errors. Apply these fixes:
convert "instance.thoughts.plan" to a string

By changing the feedback to be a list of instructions, the model happily corrected the mistake. So I basically went through the code for the JSON Schema Validator I'm using and generated repair instructions for every error that made sense.  Some things like minimum, maximum, contains, etc.  I focused on the ones I thought it could do a good job at and for the rest I just return the more passive error message and tack a "Fix it." instruction on to the end.

mostly copied over


golden-cheetah: add AppImage derivation

Description of changes
Upstream bakes their API tokens for external services (like Strava) in its source. When users want to connect golden-cheetah to the external services, they fail and there is no option to add own API keys during runtime.
So either the user modifies the derivation to add their own API keys during build, or we add the pre-build AppImage to NixOS. This has the developers API keys built-in, so the connection to external services work as expected.
Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

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

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.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
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/1643

@adamcstephens : Please have a look and help decide, which is better. This now changes your derivation and doesn't just add a different one.
Without using the AppImage, essential integrations like Strava will not work, since the API Key is baked in the binary. Therefore I personally think it is more useful in the AppImage form (as it then uses the API keys of the developers)

Hi! Sorry, I didn't see this when doing my upgrade. My personal preference would be to split this into a second page, something like golden-cheetah-bin. I have no need for any of the cloud services and thus would prefer the nixpkgs-native build. There are other examples of this, such as osu-lazer and osu-lazer-bin.
I'd be happy to help maintain that version if you want to include me though. Thoughts?

@adamcstephens that was my initial idea and PR (to include both derivations), but @SuperSandro2000 preferred a single derivation.
I'm fine either way and would be happy to maintain the AppImage derivation

@adamcstephens could you have a look? I reverted to the initial PR (and changed the name for the new derivation to golden-cheetah-bin )

Good catch!

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

That is only done if there is a real difference and the compiled binary cannot match the precompiled one. Is that the case here?

The pre compiled binary only exists for x86_64-linux. The app compiles and runs on aarch64 but there is no app image.


Cow: Watch evolution.org.ua

Cow requests the watch of the watch_keyword evolution\.org\.ua. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

evolution\.org\.ua has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Jesse in Charcoal HQ


⚠ Bofrost.lu has degraded performance

In 0ab0ab1, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 2025 ms

Resolved: Bofrost.lu performance has improved in 5924fa0 after 50 minutes.


indentation of parameters in devise controllers

PS: this PR does not pass in the CI because this branch did not have the configuration yet


Performance issue with CResourceHandler::makePackageResourceID

The use of std::max_element in CResourceHandler::makePackageResourceID makes the time complexity of this method O(n) which results in making IDs for all resources in a package O(n2) i.e. quadratic.
This is a performance regression over older versions of lib3mf.
If there is a need to get the biggest ID, then it is better to make m_resourceIDs an (ordered) std::map instead of std::unoredered_map.
That way m_resourceIDs.rbegin()->first will give the biggest ID in constant time.
This will reduce the time complexity of CResourceHandler::makePackageResourceID to O(log(n)). There are other std::map look ups in that method, but log(n) is much better. Overall ID creation in entire package will be O(n * log(n)).
There will be a side effect of this change on 2 other methods of CResourceHandler - findResourceIDByUniqueID and removePackageResourceID. Their time complexities will increase from constant to O(log(n)). But overall performance of lib3mf should still be better.
This above fix could be implemented with minimal changes - replace unordered_map with map and max_element with rbegin()->first.
However, if the side effects are not acceptable, then it is best to maintain biggestID separately rather than finding it in linear fashion every time we make a new resource ID.
@martinweismann Any thoughts on this?

Link to problem code:
https://github.com/3MFConsortium/lib3mf/blame/master/Source/Model/Classes/NMR_PackageResourceID.cpp#:~:text=UniqueIDPackageIdMap%3A%3Aconst_iterator biggestId,})%3B
Instead of m_resourceIDs.rbegin() suggested above, we could use m_resourceIDs.crbegin().
m_resourceIDs.rend() can be used to check for empty map.

@feliperoos Tagging you as I see you commit in this area of code.


Fix WP Links Plugin

@heldyboy  I have found an alternative of WP Links plugin. Its called "Simple Link Directory Plugin" You can see the below screenshot and we can now add links and create a list of links and display on that specific page.


[FEATURE] skip videos based on video duration

[x] Verified and I assure that I'm running youtube-dl 2017.04.28
[x] At least skimmed through README and most notably FAQ and BUGS sections

Purpose of this issue?

[x] Feature request (request for a new functionality)

Description:
in Video Selection:
Adding options to skip download of videos which are too long or too short.
--max-duration SEC
--min-duration SEC
With support of 1m for 1 minute and 1h for one hour.
as a time counterpart of
--min-filesize SIZE
--max-filesize SIZE

Use --match-filter option.

Thanks @Tithen-Firion. He/She is definitely right.


CSS only Popup doesn't appear above disabled button

Pretty simple issue, if there is a button defined as disabled:
<button class="ui disabled button" data-tooltip="Not available yet">Do Action</button>
The css only popup doesn't show. It might have been originally a feature, but I don't see why a popup would be disabled together with a button, meanwhile its a perfect case for showing 'Do something to make it available' tip

Disabled buttons have pointer-event: none preventing :hover
You'll have to add pointer-events: auto to your custom css.


Added TLS support for cm_shell

There is now a new command line option (-t or --tls) that will enable TLS for the connection to the Cloudera Manager API. Note that enabling TLS will not automatically change the port the client connects to CM on, so -p 7183 (default CM TLS port) needs to be added to the command line for the connection to succeed.
jims-air:cm_shell jhalfpenny$ ./cmps.py -H test-cluster.cloudera.com -p 7183 -t
Enter Username: admin
Enter Password:
Welcome to the Cloudera Manager Console
Select a cluster using 'show clusters' and 'use'
cloudera>

Merged in 5.4. Thanks!


refactored the code into smaller methods

Issue #:
https://github.com/bcgov/met-public/issues/572
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the met-public license (Apache 2.0).

Codecov Report

Merging #1185 (f856ff3) into main (57805c2) will increase coverage by 0.07%.
The diff coverage is 85.71%.

@@            Coverage Diff             @@
##             main    #1185      +/-   ##
==========================================
+ Coverage   73.18%   73.26%   +0.07%
==========================================
  Files         267      267
  Lines        7615     7637      +22
  Branches      538      538
==========================================
+ Hits         5573     5595      +22
  Misses       1963     1963
  Partials       79       79

Flag
Coverage Δ

metapi
79.46% <85.71%> (+0.11%)
:arrow_up:

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

Impacted Files
Coverage Δ

met-api/src/met_api/models/engagement.py
70.06% <85.71%> (+5.26%)
:arrow_up:


toolz install failing with conda install toolz 0.8.2 - force 0.8.0

fix travis build for now by forcing toolz 0.8.0 until the condas dependencies/availabilities are straightened out

Coverage remained the same at 96.838% when pulling b826b0db0a8472ff11f41ef12f91e0abac5a0b1d on toolz into 1718c003d435759eec1456bb029dc4c133dc17f1 on master.


Passing the correct object to the validator.

Since this is just a typo I expect that I do not need to create a test that fails. Every call to zipcelx fails because the validator checks for .filename etc. on the array config.sheet.data instead of the object config. Afterwards it works perfectly, thanks for the library!

That's odd. Thank you for fixing.

Published @ 1.1.2


Add another Rating Star Lib

Please check the below Lib. I am using it and its awesome
https://github.com/hsousa/HCSStarRatingView

Any update on this ?

Hi @singhdd93! Feel free to open a Pull Request. We have a subcategory for this kind of UI component. :)

Hey @singhdd93, sorry for the delay. I just added the lib.
Thanks for contributing 😄


Support for decryption of messages with hidden recipient

As @tomholub noted:

Definitely, this is particularly useful in two cases:

when there is a key mismatch error - I'd like to know which key is the thing encrypted for
when the keys I'm using are encrypted with a pass phrase themselves. Decrypting a private key is an expensive operation - in fact I may need to ask the user for the pass phrase before decrypting the key. The user may have several keys. I need to know which key to ask the user to give me pass phrase for, and then I can actually decrypt the message.

An interesting quirk here is that while normally the key id is properly included, sometimes the sending client may have instead included a wildcard \x0000000000000000 meaning that they don't want to disclose the key id for privacy reasons. The pgpainless should understand this situation, which means to attempt with all provided keys (in case you filter provided keys based on this information before trying to decrypt. if you don't, then it probably doesn't matter).

Decrypting messages for hidden recipients will probably fail at the moment. We should add support for that.

Messages that were encrypted using hidden recipients can now be successfully decrypted :partying_face:
Next we should add a way to make the user aware of hidden recipient keys maybe?

Messages that were encrypted using hidden recipients can now be successfully decrypted :partying_face:
Next we should add a way to make the user aware of hidden recipient keys maybe?

Next we should add a way to make the user aware of hidden recipient keys maybe?

As long as I can pull out a list of longids, if one of them is 0x000... that's enough. I don't think we need anything more for that, it's an edge scenario.

Next we should add a way to make the user aware of hidden recipient keys maybe?

As long as I can pull out a list of longids, if one of them is 0x000... that's enough. I don't think we need anything more for that, it's an edge scenario.


Override lucene's default for min/max gram size on ngram tokenizer

Updates the default ngram tokenizer configuration so that the default for minGramSize is 3 and for maxGramSize is 7.
Adds a generic limit on the number of bytes we will index for a given term. I set the default to 5 kb, which is the same value we have for frozen collections right now.
Adds logic to reject writes at the coordinator when one of their columns exceed the configured max for an SAI index

what is this blocked on?

This stalled because I thought we wanted to add guardrails, but I wasn't sure how that would work. We could probably merge this as is (once I fix conflicts) and then do guardrails in its own PR.

what do you need to make progress on guardrails?

I think we use soft/hard for those elsewhere.
Can use two approaches to find a hard cap:

commit something we know is safe, wait for people to complain that it should be higher
do our best to push it in the lab until it starts breaking, then back off a bit from there

Those options make sense. I think option 1 is going to be easiest to ship quickly.
Another question: how do we know what is safe? My understanding for ngram filters is that calculating how expensive they are depends on the length of the document, which we don't know when configuring the index. Without being familiar with how ngrams are used, it seems like 3 and 7 could be dangerous for columns with very long text.

Do we need a limit on indexed column size too?  (This may already exist.)

It seems like that would help, but I'm not sure how we would implement that when creating an index when the table already has data for a column. Is it acceptable to fail as we build the index?

what we are doing elsewhere is log a warning, ignore the problem values, and index everything else

Okay, that's helpful. I can take another pass at this now that I have those details cleared up.

what we are doing elsewhere is log a warning, ignore the problem values, and index everything else

In the context of analyzers, we have a few options. Place a row limit on the a) number of tokens, b) cumulative bytes of the tokens, c) effect bytes size when the tokens are indexed in the trie. I think (c) is prohibitively expensive and (a) is too naive. My preference is (b).
As for putting limits on the config, I think the most meaningful rule is to limit the difference between the max and the min gram size. The defaults @qzg proposed have a difference of 4. That will lead to more explosion than using something like 3 and 4 as our min and max. We could have warn and failure guardrails based on these differences.

I think that's fine, and that's potentially a good way to think about the guardrails ("small enough that materializing all the terms doesn't cause heartburn").

@jbellis - this is now ready for review, please take a look

CI didn't complete after Friday's commit. Merging in vsearch to see if that helps.


Is there a limit to file size that can be shared?

Hi Muaz,
Is there a limit to file size that can be shared? Tried a pdf file which is about 8mb and the peer connection dropped. I dont see any errors in browser console. Any pointers on what could be wrong and how i can debug this issue?

There shouldn't be a hard limit on file size, however i believe that the file is saved into recipient's ram before appending into a complete file when operation completes. File connection will drop once ram limit reaches on recipient side.

I was trying it on a system with 16gb ram, and the file size was about 8mb. Its unlikely that ram was a constraint in my case.


Expire OAuth authorization when removing/updating the authorization for an org

Just leaving it as a notice for the future. If we remove an oauth_app_organization, we should probably invalidate all existing oauth_app_users related to that organization if the app is restricted. Similar checks if an app changes from normal to restricted, etc.

cc @alrocar in case you are interested in pursuing this

Closing in favor of https://app.clubhouse.io/cartoteam/story/83528/expire-oauth-authorization-when-removing-updating-the-authorization-for-an-org


fix: Issue 1127 configs dir fails with more than 40 files

HI,
data validator built all the configurations before calling a validation. "Building" a configuration involves creating a data_client, which connects to the database. When data-validation was called with configs run -cdir <dirnname> it opens a database connection for each file in the directory before calling the first validation.  This results in running out of Shared memory in the case of Oracle (limit seems to be 40 open connections)
Code changed to call a validation immediately, each time after reading the yaml file from the directory. Tested this change on the same directory causing issues with the develop DVT branch. This does not run into Shared memory issues on Oracle. However, not entirely clear how this works - as data-validation does not appear to disconnect from each Oracle connection.
Sundar Mudupalli

/gcbrun

/gcbrun

LGTM. I'm assuming the connections get garbage collected after the client.execute() is called in SQLAlchemy. Probably something to investigate further in the future.

/gcbrun


Azure Automation: 2022-06-30-preview API for Runtime resource

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Azure 1st Party Service can try out the Shift Left experience to initiate API design review from ADO code repo.  If you are interested, may request engineering support by filling in with the form https://aka.ms/ShiftLeftSupportForm.
Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[x] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
If updating an existing version, please select the specific language SDKs and CLIs that must be refreshed after the swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[ ] No refresh required for updates in this PR

Contribution checklist:

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[x] Check this box if any of the following appy to the PR so that the label "ARMReview" and "WaitForARMFeedback" will be added by bot to kick off ARM API Review.  Missing to check this box in the following scenario may result in delays to the ARM manifest review and deployment.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you are using OpenAPIHub to initialize the PR for adding a new version. More details, refer to the wiki.

[x] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[x] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in a stable version
[ ] Removing properties in a stable version
[ ] Removing API version(s) in a stable version
[x] Updating API in a stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

I have added a few minor comments and signed off. Please make sure to fix them before checking in. Let me know if there are any further clarifications requried on those comments.

/azp run

@msyyc for advice on python sdkautomation.
@tadelesh for advice on go sdkautomation.

I have added a few minor comments and signed off. Please make sure to fix them before checking in. Let me know if there are any further clarifications requried on those comments.

Please merge the PR as I do not have permissions for the same.

all SDK generation fails with similar error:

Please check the swagger definition with log.

Sorry for the late response. Python failure is not related with https://github.com/Azure/azure-rest-api-specs/pull/20357 and we may need some time to fix it. If python is the only blocked item, it is ok to force merge it.

Approved breaking for Go. @Alancere You need to add -alwaysSetBodyParamRequired to build.go to resolve this breaking.