MM-11567: Autocomplete search in: for DMs and GMs

Summary
Autocomplete search in: for DMs and GMs
Ticket Link
MM-11567
Depends on mattermost/mattermost-server#9430
Checklist

[x] Has UI changes
[x] Includes text changes and localization file updates

Device Information
This PR was tested on: [One Plus 5, Android 8.1]

Does this need a version check to prevent the autocomplete showing up for older servers? What happens if you try to search in a DM or GM channel on an older server?

Older servers wouldn't be a problem, the problem could be new server with old native app.

Does it show the autocomplete for DM channels on when you have a new app on an old server though? We don't want to offer the user to use something that doesn't work.
New server with old app should be fine as long as the new server isn't breaking the existing API

If you have the new application with an old server, you use the old endpoint, so It will work as expected for old server. If you have an old RN app, with the new server, you still use the old endpoint (working as expected). I think we are covered here.

It won't cause any errors, but the user will be shown a new feature that doesn't work because it won't return any results. Like this is what it looks like when I try to use it on an older server

before this, the autocomplete for search list was autocompleting with all public channels, so, you had this kind of things easily. But, I can change that to detect old servers and do not complete that.

@hmhealey Now it only shows direct messages for mattermost server V5.4 or greater

@enahum In this case I'm explicitly avoiding to get the channel from the selector, because i receive the channel display_name from the server populated (for autocomplete search results), if I use the getChannel selector, it populates automatically the display_name for the DirectMessage channel.

@jespino can you create a specific selector for that?


IE11: webpack-hot-middleware's client requires EventSource to work

Describe the bug
IE11 doesn't hot reload as you make changes.
To Reproduce
Steps to reproduce the behavior:

Get setup:

git clone https://github.com/storybooks/storybook.git
cd storybook
yarn install
yarn bootstrap --core
cd examples/official-storybook
yarn build-now
yarn storybook

In Chrome and IE11, visit http://localhost:9011/?path=/story/addons-backgrounds--overriden
Edit stories/addon-backgrounds.stories.js and change the overridden story from

  .add('overriden', () => <BaseButton label="This one should have different backgrounds" />, {
    backgrounds: [
      { name: 'pink', value: 'hotpink' },
      { name: 'blue', value: 'deepskyblue', default: true },
    ],
  })

to
.add('overriden', () => <BaseButton label="This one should have different backgrounds" />, {
    backgrounds: [
      { name: 'pink', value: 'hotpink', default: true },
      { name: 'blue', value: 'deepskyblue' },
    ],
  })

In Chrome, the background changs from blue to pink. IE11 fails to update.

Expected behavior
IE11 should automatically update via HMR like Chrome does.
System:

OS: Windows 10
Device: Dell Precision laptop
Browser: IE11
Framework: react
Version: 5.0.0

Additional context
IE11 developer tools shows the error:
webpack-hot-middleware's client requires EventSource to work. You should include a polyfill if you want to support this browser: https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events#Tools
I've tried yarn add event-source-polyfill and then import 'event-source-polyfill'; in config, but the error  persists.

This isn't an issue with backgrounds addon -- it's just a handy minimal example. Any storybook will fail to update in IE11 due to the missing EventSource polyfill.

This is still an issue as of 5.0.6

@ZebraFlesh can you try adding it to addons.js?

@shilman I tried it out in the addons.js file, this is not working. For example both of these fail:
Following event-source-polyfill documentation:
import {NativeEventSource, EventSourcePolyfill} from 'event-source-polyfill';
const EventSource = NativeEventSource || EventSourcePolyfill;

Following @ZebraFlesh's above example.
import 'event-source-polyfill';

Can you try adding that to config.js ?

Adding this line to addons.js worked for me:
import 'eventsource/lib/eventsource-polyfill';

I don't know if it matters, but I used the polyfill package mentioned in the link from the webpack HMR error message, instead of the one that @ZebraFlesh used.
In other words:  I used eventsource (from the mozilla link) instead of event-source-polyfill.

I spoke too soon.  Now the error is in the console and in the "actions" panel (and HMR still not working), but it's not giving me the original popup error anymore.  (maybe I suppressed it somehow)

this seems to work :crossed_fingers:
in config.js:
import { NativeEventSource, EventSourcePolyfill } from 'event-source-polyfill';
global.EventSource =  NativeEventSource || EventSourcePolyfill;


Implement real /api/data-ingests/latest-timestamp endpoint

Describe the task here and link or add dependencies to any applicable issues...
This task is done when...

[ ] criteria 1
[ ] criteria 2

Add additional labels (design, dev, compliance, BUG, etc) and size before
submitting.

Closed, see #84

Whoops, wrong one


Accepting DELIMITER syntax on MySQL and MariaDB

Folks,
Imagine a situation where we need to manage huge scripts with DELIMITERS, once the MySQL 5.6 does not accept commands like ALTER TABLE tableName DROP FOREIGN KEY IF EXISTS fkName. In this case, the solution would be to create an IF statement like this:
    DELIMITER $$

    IF EXISTS(
        SELECT * FROM information_schema.table_constraints
        WHERE
            table_schema    = DATABASE()                    AND
            table_name      = 'tableName'         AND
            constraint_name = 'fkName'  AND
            constraint_type = 'FOREIGN KEY')
    THEN
              ALTER TABLE tableName
         DROP FOREIGN KEY fkName;
    END IF $$

    DELIMITER ;

The fact is that vscode-sqltools does not accept DELIMITER syntax. We get an error like this:

Now I have to use Workbench because of it, but I really prefere to use vs code instead.
So here it is my recommendation for this project: Start accepting DELIMITER syntax.
I still have no idea of how to make it, but I believe we can find the logic inside some forks from mysql.

I was having the same problem!
Very nice Issue!

Please, take a look at this issue: https://github.com/mysqljs/mysql/issues/1683
Apparently DELIMITER is a command to mysql-cli and not a mysql syntax, so it's not part of the driver we are using.
I found this library https://github.com/sidorares/node-mysql2 that I believe that works with the delimiter syntax, also I've found some guys mentioning that if we just remove the DELIMITER line the query would work.
I'll try mysql2 driver and see what happens, because I don't like the idea of transforming the query we run.

@Maransatto Did you tried something like this?
/*!50110 ALTER TABLE tableName DROP FOREIGN KEY IF EXISTS fkName */;

According to MySQL documentation, it seems helpful to your case?

If you add a version number after the ! character, the syntax within the comment is executed only if the MySQL version is greater than or equal to the specified version number. The KEY_BLOCK_SIZE keyword in the following comment is executed only by servers from MySQL 5.1.10 or higher:
CREATE TABLE t1(a INT, KEY (a)) /*!50110 KEY_BLOCK_SIZE=1024 */;

@mtxr Hopefully you have noticed my comment in mysqljs/mysql#1683. In my opinion, unfortunately transformation must be happen before sending the query to server. Either the driver provided that transformation functionality or we implement our own.

my vscode isn't accept the DELIMITER, someone help me?


Add language identifiers

Verified.
@NextTurn - Thanks for submitting the updates. Note that smaller pull requests are easier to review. In diff view, after a few hundred files (exact number unknown--appears to be around 300), all subsequent files are collapsed and must be manually opened to view diffs:

Just a tip that would make things easier on this end. :) Thanks again.


Feat/Adapt Trade Intensity Indicator to Use Trade Events

Before submitting this PR, please make sure:

[x] Your code builds clean without any errors or warnings
[x] You are using approved title ("feat/", "fix/", "docs/", "refactor/")

A description of the changes proposed in the pull request:
Stores the most recent trades in the order book class and makes them available to strategies.
Replaces simulation in trading intensity with real trades from the exchange.
Update of the Avellaneda-Stoikov strategy to use the new sampling.
Tests performed by the developer:
Ran the Avellaneda-Stoikov strategy in this branch side by side with the version in the development branch and compared their behavior as well as calculated trading intensity variables.
Ran unit tests.
Tips for QA testing:
The version in this branch should give roughly the same results as the version in the development branch, but not necessarily exactly the same. Namely the orders placed in the market should be roughly the same, and the variables order_book_intensity_factor and order_book_depth_factor should be roughly the same.

PRP: https://snapshot.org/#/hbot-prp.eth/proposal/0x645eab7e59b4b1de4e9ef69e67451ab4f09ace92f8568b8c659d3c42adc4d382

Hi @mhrvth, please fix github tests which are failing. Thanks!

@JeremyKono  Hi, it's fixed now.


Prototype slow-tests.gradle and test-output.gradle in Kotlin

This is not going to be merged as approved. A separate PR into config repository would be created.

Closing this draft as it's approved and an associated PR into config repository is created.
See Migrate slow-tests.gradle and test-output.gradle to Kotlin


python311Packages.litellm: 1.20.9 -> 1.22.3

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python311Packages.litellm is: Use any LLM as a drop in replacement for gpt-3.5-turbo. Use Azure, OpenAI, Cohere, Anthropic, Ollama, VLLM, Sagemaker, HuggingFace, Replicate (100+ LLMs)
meta.homepage for python311Packages.litellm is: https://github.com/BerriAI/litellm
meta.changelog for python311Packages.litellm is: https://github.com/BerriAI/litellm/releases/tag/v1.22.3
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.22.3 with grep in /nix/store/28664f3lqxfn3na7py8aycr66km9880n-python3.11-litellm-1.22.3
found 1.22.3 in filename of file in /nix/store/28664f3lqxfn3na7py8aycr66km9880n-python3.11-litellm-1.22.3

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

3 package rebuild(s)

First fifty rebuilds by attrpath
open-interpreter
python311Packages.litellm
python311Packages.open-interpreter

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/28664f3lqxfn3na7py8aycr66km9880n-python3.11-litellm-1.22.3 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python311Packages.litellm https://github.com/r-ryantm/nixpkgs/archive/abcaa59fd26567fd8ed273916d66599aa752bcbe.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/abcaa59fd26567fd8ed273916d66599aa752bcbe#python311Packages.litellm

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/28664f3lqxfn3na7py8aycr66km9880n-python3.11-litellm-1.22.3
ls -la /nix/store/28664f3lqxfn3na7py8aycr66km9880n-python3.11-litellm-1.22.3/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

2 packages built:

open-interpreter (python311Packages.open-interpreter)
python311Packages.litellm

Maintainer pings
cc @happysalada for testing.

I'm going to make a follow up PR


Ideas for lit-html 2.0

lit-html 1.x has been out for about a year and a half now. It's seen good uptake, and it's still among the fastest, smallest, and arguably simplest DOM rendering libraries out there. The API is extremely flexible and has worked well for a wide variety of use cases - we haven't seen a lot of places where we want to drastically change the API based on current usage. There are some long-standing requests - like static bindings and spread expressions - that still pop-up every once and awhile, but don't seem to be urgent deal-breakers for most users.
So we're in a good place and are not out looking for reasons to release a new major version - we really value API stability! - but we have some new goals, the browser landscape is changing, and we've been able to see what the common usage patterns are. We have a chance to integrate this and make an even better lit-html.
The team has been experimenting with some ideas for a lit-html 2.0, and it seems like a good time to write down some of the goals and possibilities to get feedback on them. Note that nothing is set in stone, and some of the changes we might be able to back-port into lit-html 1.x
Goals
Backwards compatibility for most users
The simplicity of the main public APIs - html and render - has worked really well, and has even been adopted by other libraries. So we want to keep that, and want API changes to be backward compatible for most users. This also includes users of directives: the built-in directives should be backwards compatible. Far fewer developers write directives though, so we're willing to consider breaking changes there.
Backwards compatibility is especially important for internal Google use. Google's monorepo only allows one version of a library, so we'll have to update all of Google at once.
Performance
We always want to be as fast as possible :) Some changes that can make us faster are technically breaking though, and require a new major version. Ideas for improving perf range from removing abstractions, to doing less DOM work on template prep, to building an optional template pre-compiler. We also want to drive down the cost of template composition as much as possible, and optimize more for first render over updates.
Memory efficiency
lit-html is already decent with respect to memory consumption, but we can do better. Our architecture inherently requires memory usage between renders to store information for expressions (what we call "parts"). We can reduce this with API changes that let us keep fewer objects with fewer fields around. We especially want to optimize for the more common case of single-valued bindings.
Size reductions
lit-html is currently weighing in at ~3.4KB minzipped. We would love to get this back under ~3K. Removing some abstractions and browser bug workarounds can help, as well as exporting fewer public symbols so minification can work better. More concise modern DOM APIs are available if we can change browser support.
In addition, we can look at publishing a minified, bundled build so that we can crank the minifier settings to 11 and ensure the result works correctly. While we believe minification is ideally an app concern, we realize that apps won't know all the transforms that can be safely applied to our code.
Developer Experience
We would like to improve error messages, and not let publishing minified code negatively impact development. We'll look into producing both production and development builds.
Easier SSR
We are still working on SSR with the 1.x codebase, but we have learned a lot about how parts of the API make it easier or harder to implement SSR. The largest impediment is the sheer amount of flexibility our API gives developers. lit-html is in some ways more of a template library construction kit than just one template library. With pluggable template factories, template processors, polymorphic template results, and the ability to dynamically construct and insert parts into the DOM, we can't guarantee that we can represent all templates when SSR'ing, or understand how to reconstruct the JavaScript relationship between template constructs when hydrating.
Our SSR system will only be reliable when using a pretty non-customized version of lit-html, as the vast majority of users do. We've seen very little usage of these customization features, but their existence limits us, so we're going to explore removing some of them. We especially need to hear from developers using these features first though.
 To be server-renderable, directives currently need to stick within a subset of the API during first-render. We want a new directive API clarifies the allowable APIs and works on the server by default.
Better compile target
Some partners have existing template systems they may be interested in compiling to lit-html. Some new features would be useful for this, like unbalanced tags, statically verifiable spread attribute bindings, tag-name position bindings, and XSS-safe CSS bindings.
New features
Long-standing requests like static and spread bindings should be looked at, especially now that all current browsers correctly implement tagged template literals (which was preventing static bindings before now).
API cleanup
Some parts of the API are less-than-ideal and we shipped 1.0 knowing that we'd like to improve them. The directive and part APIs are prime examples. We want to make directives easier to write, and as mentioned, make them SSR compatible by default.
Potential Changes
Reduce the API surface
We see very little evidence of broad usage of extension and customization points like TemplateProcessor, TemplateFactory, and freely constructible Parts. Removing these abstractions would eliminate code, allow some APIs to be minified that weren't before, and reduce function calls and indirections in very hot code paths.
As noted in goals, we want the vast majority of existing templates to work as-is in lit-html 2.0.
Prod and dev builds
We don't want minified code to make debugging more difficult, so we should create an unminified development build with nice error messages and maybe even more template validation. We'll publish the production build by default so that apps don't accidentally deploy the dev build, and allow the development build to be used via various module replacement / aliasing tools, such as @rollup/plugin-alias.
Remove the workaround for broken template literals in Safari
Safari 12 had a bug where it would occasionally garbage collect template literal strings that shouldn't have been. This caused lit-html's caching to fail and re-render DOM that should have been updated. Our workaround was to use a secondary cache keyed by the joined strings of the template. This works without UA sniffing, but this has a perf and memory impact for all browsers. We should remove the workaround and consider Safari 12 to be a browser that doesn't support ES6 properly.
Simplify template caching by not allowing template tags to be dynamic.
Currently we cache by both the tag type (svg or html) and the template strings object. This lets you dynamically switch the template tag, but… who does that? We can eliminate a cache lookup completely by only caching by the template strings object.
Better HTML scanning
Before templates are parsed by the browser, lit-html prepares the HTML string by inserting markers where expressions are. We need to insert comments in some places, like text nodes, and non-comments in others, like attribute values. Our current scanner is good, but sometimes thinks that an expression is in an attribute when it's in text. This means we have to search all text nodes for markers, which has a high cost in template prep. If we can make a more precise scanner, so that we always insert comment markers in text nodes, we can skip processing them (except for raw text nodes like <script>, <style>, and <textarea>) and speed up template prep and thus first render.
There is a careful balance here because the current scanner is so small and we want to reduce code size overall. We'll have to be lucky and/or good to make this work. If it does work we'll be able to support new binding types like spread and tag-name - or at least we'll be able to produce better error messages when people try to write them.
Spread bindings / Attribute position bindings
Attribute directives are very useful for running some logic on an element because the reference to the element is inherent in the template syntax, and the directive is run after the element is created. Sometimes you just need logic on the element and don't need to bind to an attribute, but in lit-html 1.x you need to invent an attribute name to place a binding. We've seen this when MWC used a directive for ripple:
html`<button .ripple=${ripple()}>${label}</button>`

With the better scanner we can add attribute position bindings:
html`<button ${ripple()}>${label}</button>`

Another example is Vaadin's field() directive:
html`
  <vaadin-text-field
    label="Full name"
     ...=${field(model.fullName)}>
  </vaadin-text-field>`

Which could be written as:
html`
  <vaadin-text-field
    label="Full name"
    ${field(model.fullName)}>
  </vaadin-text-field>`

This will let us do nice things like ref and spread directives:
html`<div ${ref((e) => console.log(e))} ${spread(props)}></div>`

More template types
We have seen some need for template types like attr and css.
attr would be a template that just contains attributes (and possibly properties, events, etc), and would enable passing and setting multiple attributes in an XSS-safe manner.
const exampleAttrs = (foo, bar) => attr`foo=${foo} bar=${bar}`;
html`<div ${exampleAttrs('a', 'b'}></div>`

It's really an element partial, which has a number of interesting use cases, from parity with template systems like Closure Templates, to being able to declaratively set host attributes.
css would be for bindings into CSS text in <style> tags and possibly LitElement's styles property. It would make style bindings more XSS-safe by only allowing developer provided and sanitized values to be bound to CSS.
LitElement's css is a bit different from a lit-html template, but if we can combine the two we can share CSS-safe values between them, and enable other component base-classes to use the Constructible StyleSheets-producing system.
Remove template part's two-pass update
Due to how attributes with multi bindings interact with directives, we have a two-pass update process: first all parts in a template have their value set, then all parts are committed. This allows multi-binding attributes to set the attribute value only once. Removing this will reduce code, an entire pass over all parts in an app, and simplify the Part API for directive authors.
Remove attribute part committers
As part of removing two-pass updates we should remove the part/committer split. Currently we have a part for each attribute expression and a single committer shared between parts on the same attribute. This is extra work to setup and incurs extra memory overhead. An early version of lit-html had a multi-valued part type that could update with an array of values. We changed to allow parts to have their value set externally to rendering and to more closely align with the W3C Template Instantiation proposal. We don't want to let parts be updated externally anymore and we should only align with template instantiation once it's more concrete, so we should explore the old design again.
Remove async directives: until(), asyncAppend(), asyncReplace()
Dealing with asynchronicity in components is hard. until() and friends are helpful in some simple cases, but they are actually quite tricky to use correctly. It's pretty easy to generate a new Promise every render and pass it to until() so that the binding it's used in actually updates twice for every render: once for the fallback, and once again with the resolved value.
Async templates are also hard to test if the async values aren't exposed outside the template in some way.
We're not 100% on this, but we suspect that async helpers should be moved up into the component model, leaving templates synchronous. It should still be possible to write an until-like directive, though such directives might require cooperation with a host component that can perform a re-render. TBD.
A better directive API
Directives have a few issues. First, they often directly interact with the DOM, making them difficult to SSR (our SSR library doesn't emulate the DOM). Second the API is stateless, but directives are really only needed when they either mutate the DOM or require state. Directives that require state then have to keep WeakMaps keyed off parts. This is cumbersome. Third, directives don't have a lifecycle, but we've had requests for one, and it could be useful for first-render performance.
We should investigate a stateful, class-based directive API. This may seem to fly in the face of other libraries eschewing classes, but we think we have something nice in the works.
Directives would extend or implement the Directive base class and implement one or more lifecycle methods, currently render() and update(). render() is for the initial render and SSR and can only return a lit-html value (including a template). update() is called only on the client and can access a directive's part.
lit-html will instantiate the directive instance and keep it around between renders. State can be class fields: no more WeakMaps!
/** Renders a count of the number of render calls before the value */
class Count extends Directive {
  count = 1;

  render(value) {
    return html`${this.count}:${value}`
  }

  update(part, args) {
    // mutate DOM here if neccessary
  }
}
export count = directive(Count);

This seems to be easy to implement and already much better for SSR. We'll also investigate a disconnect callback to allow cleaning up any held resources.
Other changes to explore for directives include making it less likely that they need to directly manipulate DOM or Part internals. Handling the nothing sentinel in the core library so that it removes attributes means ifDefined() doesn't need to call removeAttribute(). Adding part state detach and attach methods means cache() and repeat() don't have to move the DOM for a part.
Better animation support
When directives have lifecycles, we may be able to tie them into the host component's lifecycle to better enable animation directives. Animation techniques like FLIP work by measuring layout before DOM changes. If we can get a performant disconnected callback, we might be able to get a performant beforeRender() callback too, which would allow this. Another option would be to let the directive directly get a reference to the host component in its constructor and set a before render callback on the host, an API that would have to be added to LitElement and other component hosts.
Remove support for some data types
lit-html takes care to do nice things with data types like Symbol and arrays in attribute bindings. This costs bytes and exists on the hot paths. We can require developers to use patterns like String(symbol) and array.join(' ') instead. We'll obviously keep array support for text bindings so that array.map((i) => html${i}) still works.
Move IE11 support out of the core library
IE11 usage is dropping and we'd love to drop it, but we probably can't do it quite yet since some of our customers are stuck supporting it for a while. We might be able to change our support policy and move any additional code we need for IE11 and Edge Classic into auxiliary files that are loaded only by the applications that need it. lit-html (and by extension LitElement) wouldn't support IE11 by default then, and apps that don't need IE support wouldn't pay the cost of it, but an app could include a top-level script tag that would patch lit-html and make it work.
We can also use more modern DOM APIs that will save some bytes and just require more polyfills for IE. There are some tricky parts of IE support we might not be able to patch in though. IE and Edge Classic iterate attributes in an undefined order, making it harder to associate them with expressions. In-order iteration isn't polyfillable. IE and Edge Classic also remove style and other attributes with invalid content, which happens when they're bound, so we'll need to still change bound attribute names.
There is a lot of experimentation to be done here.
Remove use of instanceof
Using instanceof to detect lit-html's own objects is problematic in cases where npm installs multiple versions of the lit-html package. It's also slow for false cases as it has to traverse the prototype chain (we need to measure and confirm this). We can move to looking for a sentinel own property on TemplateResult and other objects.
Template pre-compiler
While we think we can bring down template processing overhead a bit, we could possibly eliminate most of the work by pre-compiling templates. We need to let TemplateResult be able to carry a reference to pre-compiled template strings and part metadata, rather than just a template literal strings.
Pre-compiling templates may be an alternative way to supporting Safari 12, IE11, and Edge Classic since it skips some usage of template literals and DOM APIs that are problematic for them.
Next steps
That's a lot of potential changes! We'll be lucky if the majority of them pan out. Some changes, like new features, are potentially in conflict with goals for performance and code size. Other changes, like reducing configurability, may be hard on some customers.
One thing we know we need to do is drive the whole process from science, which means lots of benchmarking. Our current "Shack" benchmark, and the community JS framework benchmarks don't exercise enough of the features and code paths to give us enough information. So we'll develop better benchmarks, and a parameterized benchmark generator to be able to tell where performance tradeoffs start paying off (ie, benchmarks with adjustable mix of static vs dynamic content in a template).
We're experimenting with some of the ideas in this issue already, and need to figure out when, where, and how to integrate the changes into this repo. Details TBD.
Meanwhile, we encourage feedback on these ideas and any more that our users have.

Would you consider shortened urls for error messages in prod?

@bennypowers that's the idea for the errors that remain in prod. Some warnings might require string or DOM introspection that we just don't want to do in the prod build. Things like trying to verify that the template is well-formed. That may be better served still by static analysis with lit-analyzer though.

lit-analyzer

oh ok cool :D

Lack of spread expressions are a big deal for me for design system projects. It's really valuable when designing component to wrap arbitrary components which can lift the props they need.

I saw another member of the Google make a comment on a similarly shaped issue in a repo for a similarly small renderer wherein he implied that said renderer's future version should target being "2kb 2kb 2kb". Would it even be feasible to target a similar goal here? Keeping the library under 3kb would certainly seem easier while targetting getting it down to that level.

I will try to give feedback on some of the things that came to mind.

Reduce the API surface

I always thought this was "rocket science" and there has never been a need to dig deeper, for me. I wouldn't even know where to find further info to unleash the potential maybe buried there. So, I am team reducing the surface. :)

Remove async directives: until(), asyncAppend(), asyncReplace()

My gut reaction was that I find these a good reference point to see how something like this could be implemented. We do not use them, but we used them as kinda reference points to see how we could get where we wanted to get. I have a couple feelings about these:

putting one or two as a kind of recipe in the documentation and remove them from the code
splitting them into an own, "extended" package. not sure that is necessary, but for people using them would provide an update path.
I think it is okay to remove them, because not sure the assumption that Promises are being used is fair. Maybe people would also see use cases for Observables or something else.

Remove support for some data types

Am I reading this correctly? You would remove support for attribute binding if the bound value is an array? I can see this being useful, while in those cases I prefer property bindings. Not sure I would support this change if it can be avoided.

Move IE11 support out of the core library

I agree. I feel the library should not carry fixes for browsers that are not the release target of the ES version. For IE 11 we need to transpile lit-html anyway, so I think making polyfills an addon is fine. On a different note I think the ease of use of the web component polyfills in general could be improved.

Template pre-compiler

So, this is a build step? Would this be opt in or the only way to use lit-html going forward? I think one of the beauties of lit-html is that you can just drop it in and it just works. I would also argue it makes it easier to understand. If I have to understand a template, a library, a compiler and possibly a build chain just to debug a bug it would increase complexity a lot I think. That does not mean I am against an optional webpack plugin or whatever though.

@Westbrook I think we could make a very minimal lit-html in under 2KB, but we can deliver a lot of functionality in another 1KB or so. It's all tradeoffs. For apps there's diminishing returns on removing 1KB out of 100s or 1000s. For individual components it might really matter.
We might be able to make a version of lit-html that only works if you're pre-compiled the templates (and is automatically swapped in), and individual components could use that in a build process to produce the smallest possible output.

Move IE11 support out of the core library

If you'd like another data point, we were just able to finally EOL IE11 in our application -- it took a 1.5 year company-wide effort. So we'd definitely support this! We do however still support legacy-Edge, but are monitoring Edgium uptake closely and hope to fast-track its EOL in the next 6-12 months.

Maybe a renderServer() method for the Directives, can at simplest merely call render(), but signifies that it's meant to be called on the server.
Also +1 on the css - I remember being rather confused that I couldn't import { css } from 'lit-html'.

@Christian24

Remove support for some data types

Am I reading this correctly? You would remove support for attribute binding if the bound value is an array? I can see this being useful, while in those cases I prefer property bindings. Not sure I would support this change if it can be avoided.

This would only be for attributes, where right now we join the array items with a space.

Template pre-compiler

So, this is a build step? Would this be opt in or the only way to use lit-html going forward?

Optional. It would perform the template preparation steps (adding markers, recording part metadata) at build-time.

Thanks for your great work and efforts to keep lit-html one of the most well documented, well maintained, well supported etc. and stabile libraries that I have come across! This issue "Ideas for .." is just yet another example of that! Thanks!!!
I am not using TypeScript - and I believe all you can do to improve the build process especially minifying html, css (less important as it is written more flat already than html nested syntax...) for a pure js ES6+ webpack or roll-up environment will be highly appreciated. Although there are examples it is not straight forward to get started and get a good minified version (which I believe are also more performant) of the render templates.
I am using lit-virtualizer - but ran into the problem that it can't do more than rather simple fixed width listings. As soon as you go for MDC-cards in a grid or a bigger old-fashioned TABLE (where column width per definition are adjusted to actual cell content) - it is a no-go with lit-virtualizer. I have made some attempts with lit-element + Observer and simply re-render new entries to the end of the TABLE as you scroll down - and that works. It is simple and straight forward - however as soon as you reach a few 100 records there is a need to remove hidden previous records to maintain scroll speed and keep performance / memory down. That is more tricky (scroll position needs to be handled etc.) and I haven't got the solution to that (...yet)... However from that work I believe the main speed improvement for lit-html could actually be to guard (optionally) what is actually in the visible part of DOM... not sure whether that is addressed elsewhere, here or?
Streaming contents into a render process is also an area that I believe could be a (potentially more than SSR... or in combination with) performance improvement that could benefit from prepared features around lit-element and lit-html.

@Christian24

Remove support for some data types

Am I reading this correctly? You would remove support for attribute binding if the bound value is an array? I can see this being useful, while in those cases I prefer property bindings. Not sure I would support this change if it can be avoided.

This would only be for attributes, where right now we join the array items with a space.

Okay, let me explain a bit more where I am coming from. My idea has always been that when we write custom elements we, as development team, should provide attributes for our elements, because it is the HTML standard way of doing this. Because quite frankly nobody knows how and with which technology our elements might be used in the future. We are using LitElement, but tomorrow somebody might want to use them with Angular or whatever. That was my motivation for always providing attributes. However, upon further inspection this might have been a bit shortsighted: Since HTML attributes are per spec strings, there seems to be not really a native way to provide array or object attributes anyway. Maybe one could argue that the HTML spec tries to solve arrays more through the template:
<fieldset>
<input type="radio" value="One">
<input type="radio" value="Two">
</fieldset>

So, for element authoring array attribute binding is probably not the way to go anyway. And in lit-html we can always use property bindings.  Not entirely sure, about object attribute bindings, it would kinda be the same thing right?

Template pre-compiler

So, this is a build step? Would this be opt in or the only way to use lit-html going forward?

Optional. It would perform the template preparation steps (adding markers, recording part metadata) at build-time.

Sounds like a good idea.
I am generally excited for the direction lit-html is going.

Template pre-compiler

Would this involve exposing a way at run-time to create instances of a single template programmatically?
In our case, we're struggling to come up with a clean solution whereby we can take rows of data from the backend and render them with a single template on the frontend. Normally, this is easy but in our case which template we use depends on the data which came back (or should...).
This sounds similar SSR i guess, in that SSR has to have some way of instantiating a template (re-using it) with data?
Basically i think the ultimate solution for us is the "template instantiation" RFC ive seen floating around for the past few years. But that won't come any time soon i imagine.
i.e. we want this:
render() {
  return someAlreadyCompiledTemplate.apply({some: "data"});
}

I've been using lit-html for some time now and here are my suggestions :

Drop classes / instanceof checks / internal Weakmap registries. Start using duck typing.
I came across the need to let other developers make templates but not call the render functions themselves. To make it work I had to create a package that store all exports to the globalThis object, export them again and make everyone use my new package. Also Typescript support for these cases is aweful.
As an implementation suggestion, you may use either Symbol.* just like Symbol.observable or expect an object with specific properties like the then of promises.
As a test suggestion. Ensure that given two instances of the library, one render may accept the result of the other html function.

For directives, emphasize on setValue. We should not have access to the underlying element. For cases where HTMLElement manipulation is required (and I have yet to find one), you already support those elements as text binding values.

Again for directives, let them return a function to call on the next render. This would solve the cancellation issues.
An other solution would be to look for functions in a directive object like the custom elements API does.

Change property bindings to transform kebab case to camel case.
Out of the box, you cannot bind to <input .valueAsDate="${...}"``. While it can be done by overriding the template factory and slap a .replace(/-(.)/g, (_,c) => c.toUppercase())to the name. I think this should be the default. And note that it doesn't break make current bindings impossible sincemy--propertywould bind to themy-propertyproperty. This would also make easier things like theclassmapdirective. You would just bind the directive to.class-listand make the changes likepart.value.add('my-class')`

Just like you said, clear the API of its clutter. To me html and render are the key elements and other exports should be Typescript interfaces or constants (reproductible symbols or strings). Let's apply the YAGNI and KISS principles.

I have so little ideas of what SSR imply but to me, hydrated rendering takes it to a whole different level. You would have to inspect what is already there, look for clues to catch up on parts, not mentioning the conditional rendering... I wonder if replacing the whole content would not be faster.
If you use duck typing as I suggested, make SSR support in its own package that would provide its own version of the render function.

@grimly thanks for the suggestions.

Out of the box, you cannot bind to <input .valueAsDate="${...}"

You absolutely can. If you're having an problem with this can you open an issue?

Yay to "Remove use of instanceof"...while it's certainly manageable, it's always a chore and if we get that library all the way down to 2KB 😉 , it won't matter much if there are multiple copies on the page.
With the continued growth of tools like https://medium.com/storybookjs/storybook-controls-ce82af93e430 the need for an updated scanner and native support for spreading objects onto elements is growing as well. Do you see some alternatives to needing to mutate object properties to be pre-fixed with sigils in order to acheive event and property binding? I like the overall drive to reduce layers of unneeded complexity and see this as yet another that it would be great to see a path towards disolving.
Is there anything that an updated scanner or approach to directives could do inorder to increase the compatibility between lit-html and something like Preact's htm pragma? They are very close already, and maybe a compilation step will always be required (particularly for specific feature differentiation, like dynamic tag names), but the flexibility to be able to adopt code/tools from other projects across the boundary would be of particular interest.
On the subject of Preact and in a way the subject of getting down to 2KB (or less?), there is a proposal that would bring a (virtual) DOM diffing approach to templates natively to the browser in a way that could be naively related to what the Template Instantiation proposal also attempts to acheive. While you mention stepping back a little from the Template Instantiation spec while it bakes a little further, do you see any benefit of doing explorations into how lit-html might align with the "DOM Diffing Web API" or other template centric proposals (if they exist) during this time of "reassesment" on the way towards a 2.0 release? It would seem like a good future proofing especially if such investigations were to discover benefits that could be applied to the library or either of the two very exciting spec proposals.
Looking forward to ongoing expirementation!

@grimly thanks for the suggestions.

Out of the box, you cannot bind to <input .valueAsDate="${...}"

You absolutely can. If you're having an problem with this can you open an issue?

Oops. That was an issue of mine and I didn't take the time to look further. I stroke this point.

@Westbrook

Yay to "Remove use of instanceof"...while it's certainly manageable, it's always a chore and if we get that library all the way down to 2KB 😉 , it won't matter much if there are multiple copies on the page.

For the record, I don't think we'll get to 2K. Let's say I'll be happy with a 20% improvement :)

With the continued growth of tools like https://medium.com/storybookjs/storybook-controls-ce82af93e430 the need for an updated scanner and native support for spreading objects onto elements is growing as well.

Can you clarify? I see the need to set properties based on the "arguments", in our case the component's public properties. But why would spread bindings in lit-html help? Seems like the controls system could just set properties on the components directly, independent of lit-html.

Do you see some alternatives to needing to mutate object properties to be pre-fixed with sigils in order to achieve event and property binding?

What I've been experimenting with is two things: 1) The ability to have attribute-positioned expressions. Directives placed there could then do whatever they want in terms of setting properties, attributes, etc. (module the restrictions we want to ensure SSR compatibility. TBD). 2) an attr template tag that looks like:
attr`foo=${foo} bar=${bar}`

This is nice because it's statically analyzable, doesn't require imperative DOM calls, and should be SSR-friendly. It could be used directly by template authors or produced by directives, but doesn't allow for dynamic bindings.
For the case of turning objects into attribute bindings, I'd want to make that SSR-compatible, and without requiring custom SSR implementations for the directives. I'm not sure how possible that is without some tough code size/complexity tradeoffs. We'll see. It could be that for a lot of use-cases we're either fine with the more static attr approach, or don't need SSR at all. Maybe Storybook is one of those cases.

Thanks for the transparency in this thread, really appreciate it. Love all of it! Here's some of what we're doing with lit:

Here are the lit-html internals that we're using currently to customize lit for our projects. Mainly this comes down to us using our own TemplateProcessor on top of the default one (note the OptionallyBinding... parts):
export class AdornisTemplateProcessor implements TemplateProcessor {
  /**
   * Create parts for an attribute-position binding, given the event, attribute
   * name, and string literals.
   *
   * @param element The element containing the binding
   * @param name  The attribute name
   * @param strings The string literals. There are always at least two strings,
   *   event for fully-controlled bindings with a single expression.
   */
  public handleAttributeExpressions(element: Element, name: string, strings: string[], options: RenderOptions): Part[] {
    const prefix = name[0];
    if (prefix === '.') {
      const propCommitter = new OptionallyBindingPropertyCommitter(element, name.slice(1), strings);
      return propCommitter.parts;
    }
    if (prefix === '@') {
      if (name[1] === '~') return [new SubjectEventPart(element, name.slice(2), options.eventContext)];
      return [new EventPart(element, name.slice(1), options.eventContext)];
    }
    if (prefix === '?') {
      return [new OptionallyBindingBooleanAttributePart(element, name.slice(1), strings)];
    }
    if (prefix === '$') {
      return [new ReferencePart(element, name.slice(1))];
    }
    const comitter = new OptionallyBindingAttributeComitter(element, name, strings);
    return comitter.parts;
  }

  /**
   * Create parts for a text-position binding.
   * @param templateFactory
   */
  public handleTextExpression(options: RenderOptions) {
    return new OptionallyBindingNodePart(options);
  }
}

export const html = (strings: TemplateStringsArray, ...values: any[]) =>
  new TemplateResult(strings, values, 'html', new AdornisTemplateProcessor());

we enable refs. That's obsolete with the changes you're proposing
we enable lit to subscribe to (and unsubscribe from) rjxs observables. That has been a game-changer for our framework because the data layer is written in rxjs (network updates are mirrored immediately in the UI without weird bindings)
something you don't see in the code snippet: we've enabled the style attribute to use emotion.js Interpolations. Basically you get CSS in JS just by style=${{...}} without writing the misleading class=${css({...})} every time.

also, we use directives heavily.
For example, we do virtualization with a directive that loads and unloads the content depending on an automatically spawned IntersectionObserver. We just started using this, needs a lot of improvement but I really like the API using directives for this.
export const virtualize = directive( (actualTemplateResult: TemplateResult) => (nodePart: NodePart) => {
    const node = nodePart.startNode.parentElement!;

    const render = () => {
        ...
    };

    const unrender = () => {
        ...
    };

    requestAnimationFrame(() => {
      const intersectionObserver = new IntersectionObserver(
        x => {
          if (x[0].isIntersecting) render();
          else unrender();
        },
        { rootMargin },
      );
      intersectionObserver.observe(node);

      // register unmount listeners // TODO not 100% sure if this works
      (nodePart as OptionallyBindingNodePart).subscription.add(() => {
        intersectionObserver.unobserve(nodePart.startNode.parentElement!);
        intersectionObserver.disconnect();
      });
    });
  },
);

Another example where we use directives is a preloader that spawns all components and sets style so that you can seamlessly switch between templates without a render flicker. That could probably be done with a standard web component as well though.
Really excited to see where lit is going. Glad to provide feedback and beta testing at any time.

Thanks for the info @yorrd! Hopefully you'll be able to handle the removal of TemplateProcessor ok. At a glance it seems like directives and "spread parts" (we need a better name, since it's not just spread) should handle those cases ok.
We'll publish preview builds relatively soon. They'll have some missing features and won't have full browser support at first, but hopefully you can see how your needs fit.

Couple of things im sure you're already aware of but these are what we've been hoping for:

Some way of spreading bindings (you mention this in your original post, it'd be great for completing the storybook integration of web components)
A directive or fix for the old select problem you and i have discussed before - where if a select has children computed dynamically, they get appended after the select's bindings are processed which means you can't possibly set value since the options won't yet exist at that point
A way to render to light DOM as well as shadow so we don't have to choose one or the other (you mentioned this once before so im sure you have it on a branch somewhere)

Is there anywhere we can read about what work you've been doing in regards to SSR too? it would be nice to have an explainer of how you're looking to make it work so we're prepared/can track it.

Some way of spreading bindings (you mention this in your original post, it'd be great for completing the storybook integration of web components)

Coupling this kind of feature with directives may be dangerous. What if a second commit from a directive does not spread a previously given attribute ? Remove it ? Let it as is ?

A directive or fix for the old select problem you and i have discussed before - where if a select has children computed dynamically, they get appended after the select's bindings are processed which means you can't possibly set value since the options won't yet exist at that point

For the select problem itself, you have the selected attribute on the options.
As for this as a general issue, maybe committing the values in reverse order of their declaration might be a solution since attributes of a parent element always precede the element's children.

A way to render to light DOM as well as shadow so we don't have to choose one or the other (you mentioned this once before so im sure you have it on a branch somewhere)

Are you talking about lit elements ? I can't find the use case otherwise.

Is there anywhere we can read about what work you've been doing in regards to SSR too? it would be nice to have an explainer of how you're looking to make it work so we're prepared/can track it.

There are a lot of new branches. Have a look in the commit network
As for new suggestions :
- export const nothing = {};
- export const noChange = {};
+ export const nothing = undefined;
+ export const noChange = Symbol.noChange = Symbol.for('noChange');

as @43081j already mentioned, I like to vote +1  to know a little more on the SSR and how would lit-element leverage this would be great.

@justinfagnani thanks for your take on this. Appreciate the insight. We'll definitely beta-test as early as possible :)
As for rxjs parts: I'm not sure whether directives are the way to go there just because you end up writing a whole lot more (s and )s. We tried, it does make a real difference to readability. But hey, we'll figure something out - worst case we'll do a fork. Looking forward to testing!

+1 to clarifying the type of nothing so that it's easier to return from a template function

Are there any plans for implementing this #1143 in the new Directives API? This would be useful in lit-element when we need to make directives aware of the custom element they are used in.

Just tried version 2.0
Dont know if Im doing something wrong, but version 2.0 does not handle null/undefined with .valueAsDate.
  <div>
      <input type="date" .valueAsDate=${null} />
      <input type="date" .valueAsDate=${undefined} />
      <input type="date" .valueAsDate=${new Date()} />
    </div>

Use this and set to version 2.0.0-pre3
https://codesandbox.io/s/lit-html-forked-njyi8?file=/index.html

Question about my last comment.
Should I create a seperate issue about this ?
I use lit-html in some projects now with a custom wrapper abound it.
Love it, its fast any only had one issue so far with unpredictable behavoir before 2.0 alpha. So thats a win in my book.
Really want 2.0 to be better and faster :-)

For issues on the prerelease, please file an issue with the prefix and/or label [lit-next], thanks.

The 2.0 release is imminent... thanks for the ideas!


[Question] cutomlogger example.

I modified the example to experiment. zap is good if used along the published cases, but not friendly on customization.
What I am expecting is that since zap has parent and child logger relationship, I would expect the settings being passed down if they belong to the same descendants paths.
While it looks like the case in first half of example, but it does not look like the case for zap.WrapCore (prints debug and info messages after  // ****** )
Know that WithOptions is just cloning, so it is probably doing the right thing, and not the right method to call. But then how can I do that?
	cfg := zap.Config{
		Encoding:         "json",
		Level:            zap.NewAtomicLevelAt(zapcore.DebugLevel),
		OutputPaths:      []string{"stderr"},
		ErrorOutputPaths: []string{"stderr"},
		EncoderConfig: zapcore.EncoderConfig{
			MessageKey: "message",

			LevelKey:    "level",
			EncodeLevel: zapcore.CapitalLevelEncoder,

			TimeKey:    "time",
			EncodeTime: zapcore.ISO8601TimeEncoder,

			CallerKey:    "caller",
			EncodeCaller: zapcore.ShortCallerEncoder,
		},
	}
	logger, _ = cfg.Build()
        childlogger := logger.With(zap.String("logger", "child generation 1"))

	logger.Debug("This is a DEBUG message")
	logger.Info("This is an INFO message")
	logger.Info("This is an INFO message with fields", zap.String("region", "us-west"), zap.Int("id", 2))
       // ****** Child logger also has the same logging level settings ****
       childlogger.Debug("This is a DEBUG message from child logger")
       childlogger.Info("This is an INFO message from child logger")

	fmt.Printf("\n*** Same logger with console logging enabled instead with Info level now\n\n")

	logger.WithOptions(
		zap.WrapCore(
			func(zapcore.Core) zapcore.Core {
				return zapcore.NewCore(zapcore.NewConsoleEncoder(cfg.EncoderConfig), zapcore.AddSync(os.Stderr), zapcore.InfoLevel)
			})).Debug("This is a DEBUG message, but should not be printed")

     // ****** new settings no longer honored after this line ****
    logger.Debug("This is a DEBUG message, but should not be printed")

    childlogger.Debug("This is a DEBUG message from child logger")
    childlogger.Info("This is an INFO message from child logger")

Yes, I encountered this. In my project, I am approaching this problem of independent child loggers differently. I will have an example out by this weekend. Thanks for your input!


Building/Crosscompiling for Linux ARM/ARM64

It may already be possible but i'm not sure I was wondering if support could be added to build and crosscompile appimages for arm/aarch64 on linux?

It's not possible yet. To make it possible we either need https://github.com/go-flutter-desktop/go-flutter/issues/363 or the flutter team uploads the needed engine files.

I opened an issue on the flutter repo here https://github.com/flutter/flutter/issues/60678

I'm also interested in this feature for a new project so I'm going try to setup some CI that builds the engines and make hover compatible.

@NO-ob

It doesn't support cross compiling so the end goal is to build the app with go flutter on the pinephone for the pinephone

This currently true, but adding cross-compile functionality is mandatory for easy development so that will be included when I add the feature to hover

After reading some issues and PRs in the flutter repo it seems like there are already people working on supporting arm64 targets in flutter with all the required infrastructure. So it's better to wait for the engines to become available than trying to compile them ourself.

The arm64 engine changes have been merged now I think https://github.com/flutter/engine/pull/20254#issuecomment-694546839

Then we need support for engines in https://github.com/flutter-rs/engine-builds . I'll ask them and update this issue when something changes

https://github.com/flutter/flutter/projects/181#card-48274867

Duplicate (or related) to https://github.com/go-flutter-desktop/go-flutter/issues/363


Cyleaflet performance and mouse position mismatch

About
This PR fixes #210 and adds a partial solution for #212
Description of changes

#210:

Adds debounce to update elements event to improve performance. See my comment in #210:

The event ('dragfree add remove') gets trigger for each individual node added. So initially it would get triggered 1000 times for this code you have provided. Adding a debounce should fix this without changing any functionality.

#212:

Adds calls to cy.resize() to refresh the position of the mouse on cytoscape component every time that the viewport changes or the elements are dragged. With this solution only the first interaction will have the wrong position of the mouse and it should be correct afterwards. See my full comment in 212.

Pre-Merge checklist

[ ] The project was correctly built with npm run build:all.
[ ] If there was any conflict, it was solved correctly.
[ ] All changes were documented in CHANGELOG.md.
[ ] All tests on CircleCI have passed.
[ ] All Percy visual changes have been approved.
[ ] At least one person has :dancer:'d the pull request.

Reference Issues
Closes #210
Partial fix for #212

Debounce looks good! 💪 Do you have any performance numbers for load time before & after adding the debounce?
For the click position mismatch, what if if instead of attaching it to the dragfree add remove events, you attach it to the click event, but give it a really long debounce time, like 2-5 seconds? Then it's triggered only when the user actually clicks on the canvas (not when nodes are added), and resize doesn't get called overly often.
Any idea what is the performance impact of calling cy.resize()? Depending on how long that function takes to execute, that determines how careful we have to be about calling it.

Debounce looks good! 💪 Do you have any performance numbers for load time before & after adding the debounce?

For 4000 nodes it takes +90s to fully load without debounce and about 2 seconds with debounce.

For the click position mismatch, what if if instead of attaching it to the dragfree add remove events, you attach it to the click event, but give it a really long debounce time, like 2-5 seconds? Then it's triggered only when the user actually clicks on the canvas (not when nodes are added), and resize doesn't get called overly often.

The click event wouldn't really work since dragging wouldn't trigger it. But I like the idea. The tapstart event should do give the expected behaviour. I think having a really long debounce time would defy the purpose of the resizing since the user  would have to wait 2-5 seconds for the mouse position to be correct.

Any idea what is the performance impact of calling cy.resize()? Depending on how long that function takes to execute, that determines how careful we have to be about calling it.

In my computer it takes around 0.13 ms to execute so it should be safe.


print runtime updated and restart kernel in RED color

As a pixiedust user, I want to see that kernel restart in different color so that user can see easily and then they can restart after "import pixiedust" statement. (make this the title)
Expected behavior
Actual behavior
Steps to reproduce the behavior

https://github.com/pixiedust/pixiedust/pull/746


Nose to pytest

Migrating test suite from the old nose to the new pytest, keeping coverage results (aggregated) and duration display.
Inspired by @monkut in https://github.com/zappa/Zappa/pull/1231#issuecomment-1529344242
This PR goes after this one: https://github.com/zappa/Zappa/pull/1238
in order to preserve style formatting there and use it from now on.

thanks for the hard work!
Looks like isort/black needs to be run.

@monkut need to merge this one first, so we can fix the linting before everything else 😉

Coverage: 74.375% (-0.2%) from 74.547% when pulling 0afc9898a894fee29f2960eb0c03f07be7529571 on dennybiasiolli:nose-to-pytest into 73ee393dd48500d321d65e92aba31a5fd83e93ab on zappa:master.


Wildcard hostnames

What would you like to be added?
Ability to specify hostname like
    osiris.deislabs.io/ingressHostname: "*.example.com"

Why is this needed?
In our case there is no set list of hostnames - when you create account and get a new subdomain. It is impossible to list them all, adding wildcard support would solve it.

Not an issue anymore: I realised a hostname must be unique for each instrumented services


Incorrect number / timeout

With just email and password set, the app only retrieves 181 vines. With --likes set, it times out. I have 995 posts and 11,940 likes.

Unable to reproduce without your Vine user name. Maybe you should try the --list option.

--list still gives me 181 vines. My user ID is<PHONE_NUMBER>95905280.

Vine api is not responding anymore, so I"m closing this.


Add metrics for how many nodes are failing for write/fetch requests

cc @xichen2020 @martin-mao @cw9 @kobolog
This change adds metrics for how many nodes are responding with errors.  It also allows for callers of client methods to determine which shard an ID belongs to so they can drill down into which shards are likely affected during times when write/read operations begin failing frequently (likely due to nodes responding with success not meeting consistency requirements).

Coverage increased (+0.1%) to 78.33% when pulling 5fbbf352b36ff4231c04078e8f3f13c3df7beaef on expose-errors-and-shard-id into 7d50e213d06f408bc67b951cd59367efd15d3525 on master.

Coverage increased (+0.1%) to 78.337% when pulling 0d1347fe4fd8de424477b8c5cfc3197ce9b06f0b on expose-errors-and-shard-id into 7d50e213d06f408bc67b951cd59367efd15d3525 on master.


Fix Richtext Issue 228 and 230

https://github.com/dtjohnson/xlsx-populate/issues/230
https://github.com/dtjohnson/xlsx-populate/issues/228


added tx-sender assert for tokens

Closes #120

Chan, [02.09.21 20:41]
We need two things:
(1) asserts tx-sender == sender in token.transfer (done)
(2) any use of transfer in other contracts then have to be reviewed/re-written to make sure (1) is respected  (for example, at the moment pools transfer from alex-vault to tx-sender, which shouldn't be allowed without authorisation of alex-vault)

I don't think (2) is implemented?

No (2) is not implemented yet. I was just adding a PR to the issue.


added support for make html-noapi and html-quick for the docs build

🚀 Pull Request
Description
Small quality of life change when working on improving the Iris documentation (developers use only).  I would typically comment out the iris docs sphinx extensions when editing the documentation and skip the gallery builds to allow for faster builds.  I would still of course do a complete clean and full build as a final test.
The PR introduces to new make targets for the Iris docs:

make html-noapi.  This will skip the API doc creation
make html-quick.  This will skip the API doc creation and also skip the gallery creation.

Consult Iris pull request check list

Nice - I often build the docs just to check I haven't messed up the whatsnew syntax!  I had found the html-noplot option, but this will be better 😃


Replace debug with log-level flag

Adds log level support

Alright, I've removed the API endpoints and will add them in another PR.
I've also changed the flags a bit to go in order.
The debug flag is different between agent/server, it's a boolt (bool flag defaulting to true) in the agent, but just a normal bool flag in the server.
The logging level starts out as warn (the previous default), moves to debug if the debug flag is true (and sends a deprecation warning if the flag was actually set), and finally passes through the new log-level flag, setting the global log level after those steps are complete.

Yeah, fine with me. I wanted to limit the call site, but this is probably clearer. 🙂


Move to Grid JS GitHub Organization

Would you be open to moving this project to the Grid JS GitHub Organization?
CC @afshinm

Sure! why not

Is this move going to be happening?

not yet


Emails to the committer are better than emails to me :+1:

@homu r+

:pushpin: Commit cf91531 has been approved by segiddins

:zap: Test exempted - status


Project status/passing action to notify callback

I see there are three open PRs for passing the action being dispatched to the notify callback (#6, #13, #17) - any updates about your thoughts regarding a change like that?
This enhancer gives us great perf wins for our application, but there are a handful of actions dispatched by keyboard input that we need to notify subscribers immediately or things get laggy and cause other input issues.
Please don't take this as being critical or nagging, I know everyone is busy and OSS projects can easily become time sinks, I'm just looking to see whether I should maintain a separate fork or your goals are to continue maintaining this project.

I havent had time recently to focus on this project but I plan on getting back to it soon.
I had originally not wanted to add support for passing the action to the notify callback because it deviated from how subscribe handlers currently work.
After thinking about it some more and looking at the number of requests + forks, I think its a good thing to have.

Thanks for the reply. I'll watch for updates and switch back to main version once something like that lands


Heroku deployment

All dynos are currently failing on boot with:

LoadError: Please install the mysql2 adapter: gem install activerecord-mysql2-adapter (can't activate mysql2 (~> 0.3.10), already activated mysql2-0.4.9. Make sure all dependencies are added to Gemfile.)

All seems to be working.


Cleaning up issues

Could I suggest going through all the issues, if they are marked as "solved, please test" and the user hasn't responded within a month or so, close the issue with a message of "Closing the issue due to lack of response, reopen if is not solved", or something similar.
The fact that there are over 260 issues, makes it look like this repo lacks support.

:+1:

:+1:
Отправлено с iPhone

17 марта 2016 г., в 9:05, Mathias Rangel Wulff<EMAIL_ADDRESS>написал(а):
Closed #628.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub


Use three way merge for unstructured objects

Based on work of wxdao<EMAIL_ADDRESS>in the same issue, supersedes #9938. Basically just adds tests.
closes #9937

What this PR does / why we need it:
Special notes for your reviewer:
If applicable:

[x] this PR contains user facing changes (the docs needed label should be applied if so)
[x] this PR contains unit tests
[ ] this PR has been tested for backwards compatibility

Hello @p-se your PR has the DCO missing please fix this as we can then take a look at it.

@gjenkins8 I think I have addressed all the comments. Is there anything else I can do?


Install script returns exit code 0 even when it fails

$ root@zulip:~/zulip# ./scripts/setup/install
...
...
++ /root/zulip/zulip_tools.py make_deploy_path
+ deploy_path=/home/zulip/deployments/2015-09-30-02-19-01
+ mv /root/zulip /home/zulip/deployments/2015-09-30-02-19-01
+ ln -nsf /home/zulip/deployments/next /root/zulip
+ ln -nsf /home/zulip/deployments/2015-09-30-02-19-01 /home/zulip/deployments/next
+ ln -nsf /home/zulip/deployments/2015-09-30-02-19-01 /home/zulip/deployments/current
+ ln -nsf /etc/zulip/settings.py /home/zulip/deployments/2015-09-30-02-19-01/zproject/local_settings.py
ln: failed to access ‘/home/zulip/deployments/2015-09-30-02-19-01/zproject/local_settings.py’: Too many levels of symbolic links
root@zulip:~/zulip# echo $?
0

This was fixed in 0608e32eeb0ad52e3f9fe8c9bb3e79f8eb6d4125


Adding support for ATAC-Seq experiments in the metadata specification.

Merging with master following discussion in IHEC Ecosystem meeting on 2018-06-05.


Saving / deleting / modifing data using EF Core 2.0 give random results

Dear All,
We are experiencing very unstable behaviour of our application since we migrated to EF Core 2.0. For example our users has to press 2 to 3 times a save button in the UI to get data saved in the database. After investigation we end up using the following command to tell the EF that we want to save, delete or update. Without those command it is working randomly. With EF core 1.0 those command were not necessary.
misContext.Entry(expense).State = EntityState.Added;
misContext.Entry(expense).State = EntityState.Modified;
misContext.Entry(expense).State = EntityState.Deleted;
Best regards
Sebastien
Here is an expemple of code that save an object expenseTranfer to a table Expense in our database.
[HttpPost]
        [Route("saveExpense")]
        public void SaveExpense([FromBody]ExpenseTransfer expenseTransfer)
        {
            Expense expense = misContext.Expense.Where(p => p.ExpenseId == expenseTransfer.ExpenseId).FirstOrDefault();

            bool isAdd = false;
            if (expense == null)
            {
                isAdd = true;
                expense = new Expense()
                {
                    UserAdded = currentUser.UserId,
                    DateAdded = DateTime.Now,
                    ExpensePlatoStatusId = misContext.ExpensePlatoStatus.Where(p=>p.ExpensePlatoStatusName == "Temporary").Select(p=>p.ExpensePlatoStatusId).FirstOrDefault(),
                };
            }
            else
            {
                expense.DateMod = DateTime.Now;
                expense.UserMod = currentUser.UserId;
            }

            expense.ActivityId = expenseTransfer.ActivityId;
            expense.ExpenseName = expenseTransfer.ExpenseName;
            expense.BudgetLineId = expenseTransfer.BudgetLineId != 0 ? expenseTransfer.BudgetLineId : (long?)null;
            expense.ExpenseTypeId = expenseTransfer.ExpenseTypeId != 0 ? expenseTransfer.ExpenseTypeId : (long?)null;
            expense.ExpenseAmount = expenseTransfer.Amount;
            expense.ExpenseNote = expenseTransfer.ExpenseNote;
            expense.UserIdOwner = expenseTransfer.OrganiserId != 0 ? expenseTransfer.OrganiserId : (long?)null;
            expense.ExpenseStartDate = expenseTransfer.StartDate;
            expense.ExpenseEndDate = expenseTransfer.EndDate;
            expense.RecurrenceId = expenseTransfer.RecurrenceId != 0 ? expenseTransfer.RecurrenceId : (long?)null;
            expense.CapacityLevelId = expenseTransfer.CapacityLevelId != 0 ? expenseTransfer.CapacityLevelId : (long?)null;
            expense.ExpenseIsPriority20 = expenseTransfer.IsPriority20;
            expense.ExpenseIsPriority80 = expenseTransfer.IsPriority80;

            expense.MeetingDuration = expenseTransfer.MeetingDuration;
            expense.MeetingNumIntParticipants = expenseTransfer.MeetingNumIntParticipants;
            expense.MeetingNumExtParticipants = expenseTransfer.MeetingNumExtParticipants;
            expense.LocationCity = expenseTransfer.MeetingLocationCity;
            expense.LocationId = expenseTransfer.MeetingLocationId != 0 ? expenseTransfer.MeetingLocationId : (long?)null;

            expense.ProcConTypeId = expenseTransfer.ProcContractId != 0 ? expenseTransfer.ProcContractId : (long?)null;
            expense.ProcTypeId = expenseTransfer.ProcTypeId != 0 ? expenseTransfer.ProcTypeId : (long?)null;
            expense.ProcComment = expenseTransfer.ProcComment;

            expense.SpdKeyOutputId = expenseTransfer.SpdKeyOutputId != 0 ? expenseTransfer.SpdKeyOutputId : (long?)null;
            expense.SpdObjectiveId = expenseTransfer.SpdObjectiveId != 0 ? expenseTransfer.SpdObjectiveId : (long?)null;

            if (isAdd)
            {
                misContext.Add(expense);
                misContext.Entry(expense).State = EntityState.Added;
            }
            else
            {
                misContext.Entry(expense).State = EntityState.Modified;
            }

            misContext.SaveChanges();

            //Save FTE link to this expense
            SaveStaffList(expenseTransfer.ExpenseStaffList, expenseTransfer.ExpenseId, currentUser.UserId);

            //Added to fix a saving bug. Had to click 3 times save to saved
            misContext.Entry(expense).State = EntityState.Modified;
            misContext.SaveChanges();
        }

@seb999 What is the lifetime of misContext?

Hello Arthur,
I'm loading the context in the startup page :
public void ConfigureServices(IServiceCollection services)         {             services.AddDbContextPool<MISContext>(options =>                 options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));
Then in my class constructor, passing it with Dependency Injection:
`private readonly MISContext misContext;
private readonly UserApplication currentUser;
private readonly ILookupUser lookupUser;
private readonly ILookupRepository lookupList;
private readonly IHostingEnvironment hostingEnvironement;
private readonly LogService logService;
    public PlatoController([FromServices]MISContext misContext, LogService logService, ILookupUser lookupUser, ILookupRepository lookupList, IHostingEnvironment server)
    {
        this.misContext = misContext;
        this.currentUser = lookupUser.CurrentUser;
        this.lookupUser = lookupUser;
        this.lookupList = lookupList;
        this.hostingEnvironement = server;
        this.logService = logService;
    }`

With my colleague we investigate the situation a bit last evening. Whouldn't be a problem with AddDbContextPool combined with LINQ where clause ? We found this https://stackoverflow.com/questions/14720143/are-find-and-where-firstordefault-equivalent
If you read the first answer it appears that using "where clause" load the entity from the memory and not from the database. Can it be the problem here ?
Best regards
Sebastien

@seb999 We're probably going to need a full project or complete code listing that reproduces the issue before we can fully investigate. Is the behavior the same if you use AddDbContext instead of AddDbContextPool?

Did you get any error in debug mode? Your codes is not look fault. You should check your model configuration or you look to data transfer object values in debug mode. This problem does not belong to entity framework concepts.

Hello, we didn't get any error in debug mode. It would be difficult to send you the entire project with the database.
For now on, we managed to get ride of this by aadding
misContext.Entry(object).State = EntityState.Added; for add operation
misContext.Entry(object).State = EntityState.Modified; for update operation
misContext.Entry(object).State = EntityState.Deleted; for delete operation


Autocomplete / suggestions popup for TextEdit

Hello! Is it possible to something like this

with TextEdit?
I would like to show some matching suggestions when a user enters text into the TextEdit.

There is nothing like this for TextEdit in particular, but I've added a helper function for you: egui::popup::popup_below_widget. Good luck!

There is nothing like this for TextEdit in particular, but I've added a helper function for you: egui::popup::popup_below_widget. Good luck!

Oh! That is really nice of you. Thank you very much!

Oh! That is really nice of you. Thank you very much!

Seconding @crumblingstatue  comments, I'm trying to implement a game console lib, and feeling blocked by not being able to set the cursor position.


⚠ TorrentLeech has degraded performance

In b468bd2, TorrentLeech ($TL) experienced degraded performance:

HTTP code: 200
Response time: 4782 ms

Resolved: TorrentLeech performance has improved in e7b6493 after 6 minutes.