m.attr

Putting this here as a placeholder. Need to sort out the line endings to make the diff work, but all the tests pass as relates to the conversation #545.

The diff replaces the whole file. I'm afraid you accidently changed the line endings :-/

Finally sorted that out via #588 (which is merged into this PR, but needs highlighting as a separate issue). This PR is functionally good to go, pending arguing about the functional & API merits.

As it is, m.attr() is write only. What if you want several plugins to work on the same attribute (provided they regenerate it)?
Since it is just a setter wrapper, you could expose the transformations object directly as m.attr.
Or maybe, keeping the current implementation, plugins shouldn't call m.attr() and let the client code register them, composed if needed?

I like where you're heading with that idea — there's no reason not to give the application author full control of the transformation registry (although multiple transformations on the same key sounds like a bad idea to me). This somewhat offsets the responsibility for the mechanism to provide a complete opinionated DSL for package management. I think exposing the registry object as m.attrs, allowing people to write transformations as simple functions (just like components are simple objects), is much cleaner, and leaves less ambiguity as to who should bind what, where and how.

Composition may not be a good idea, but having global attr filters isn't either IMO.
It precludes one from using them in reusable components, for example. The spy pattern discussed in #545 allows precise scoping, on the other hand.

Fork the fork?

Composition may not be a good idea, but having global attr filters isn't either IMO.
It precludes one from using them in reusable components, for example. The spy pattern discussed in #545 allows precise scoping, on the other hand.

I'm not sure I understand this. Could you elaborate?

Let's be clear: there's nothing stopping you from applying any number of custom attributes on a single DOM element. I kind of demonstrate this with my composeable components fiddle (which this aims to supercede in large part).
AFAICT the spy pattern proposal doesn't offer any kind of observable registration mechanism. Meanwhile with your suggestions for m.attrs we can adopt the jQuery plugin method, whereby plugins attach themselves to a key of their choice on an object provided by the host library.
We can use this in combination with the UMD pattern to provide a generic method for packaging custom attribute plugins:
(function (factory) {
    if (typeof define === 'function' && define.amd) {
        define(['mithril'], factory);
    } else if (typeof exports === 'object') {
        module.exports = factory(require('mithril'));
    } else {
        factory(m);
    }
}(function (m) {
    return m.attrs.bidi = function () {};
}));

In the code above I've tweaked the factory function to return the transformation function. This means you can always get a reference via your import mechanism of choice, so you can rebind dynamically.
Regarding collision: unique names will always be a problem to some degree. No package registry or import mechanism is free from this. The question is how to make this manageable when it does happen.
The idea that the user should be forced to acknowledge this potential problem and explicitly wire things up themselves is an unnecessary barrier to entry though: the boilerplate involved is pretty much what they'd have to do if they were rebinding anyway, so why not just make plugins plug-and-play, and let them rebind if they really want to?
Regarding composition, the idea that somebody would want 2 distinct transformations to have the same key and input values sounds incredibly contrived to me: it would lead to ambiguous application code. But again, it's possible — assuming an ES6 environment:
import bidi1 from 'barneycarroll/bidi'
import bidi2 from 'pygy/bidi'

export default m.attrs.bidi = ( ...args ) =>
	bidi1( bidi2( ...args ) )

CommonJS (Node/Browserify):
var bidi1 = require( 'barneycarroll/bidi' )
var bidi2 = require( 'pygy/bidi' )

module.exports = m.attrs.bidi = function( node, prop ){
	node = bidi2.apply( undefined, arguments )
	node = bidi1( node, prop )

	return node
}

…using plain old HTML:
<script src="lib/barneycarroll/bidi.js"></script>
<script>
	var bidi1 = m
	attrs.bidi
</script>
<script src="lib/pygy/bidi.js"></script>
<script>
	var bidi2 = m.attrs.bidi

	var bidi = m.attrs.bidi = function( node, prop ){
	node = bidi2.apply( undefined, arguments )
	node = bidi1( node, prop )

	return node
}
</script>

Regarding composition, the idea that somebody would want 2 distinct transformations to have the same key and input values sounds incredibly contrived to me

I've run into that issue w/ jQuery actually, with $.fn.button (when including jQuery UI and Bootstrap on the same page)

@lhorie you wanted both jQueryUI and Bootstrap to be invoked with the same signature?

@barneycarroll basically, both jQuery UI and bootstrap plugins call $(something).button() in library space (and sometimes asynchronously). So the only workaround is to fork the libraries and replace calls, which is extremely fragile.

@lhorie forking isn't necessary – I explain how to deal with that in depth in the comment immediately above. FWIW I think it was misguided of Bootstrap to override a known canonical method – the notion that anybody using Bootstrap would have ditched jQuery UI was a touch arrogant (especially as everywhere in the CSS, a button is referred to as btn).

@barneycarroll I was talking about the jQueryUI/Bootstrap case when I mentioned forking. But the same would apply here for the same reasons that were raised early in the components branch development. The problem isn't disambiguation in application space (which is what your snippet covers), the problem is disambiguation in library space, where the library developer doesn't expect others to overwrite the library's internally used public APIs (due to misguidedness or lack of foresight or whatever other reason)
This can be worked around in a few ways:

spy: this lets you arbitrarily shadow and fork the global m(). The downside, as you mentioned, is that this is little more than a straight up monkeypatch
namespacing: still risks collision, but it's far less likely that a namespace would also collide. The downside is that the namespacing tends to look noisy

Riiight — both libraries rely on dynamic resolutions to $.fn.button internally.
And now I realise what you're getting at: if I include 2 components that rely on different bidi attribute definitions, you're screwed. The rebinding would have to happen in each component's views.
Or, you say attributes are the exclusive preserve of application space, and anything packaged as a plug and play 3rd party Mithril plugin shouldn't make use of attributes.
But in any case, you're relying on the wisdom of users and plugin components to be judicious. And you're not exactly giving people a loaded footgun. jQuery UI and Bootstrap are monolithic kitchen sink frameworks — I think Bootstrap were wrong to use $.fn.button and arguably it was a bad call to use 2 such monolithic frameworks in your application (all your eggs in 2 baskets, and 1 in both!). In a more credible situation of this coming up with Mithril components + attributes, you'd expect this conversation to be had between the users and the offending plugin maintainers. We live in a more conscientious and democratic ecosystem these days.
I still reckon m.attrs is a good call — and in the worst case scenario I wouldn't have a problem forking small components with search and replace if and when they conflicted.
Could you go over the spy and namespace options again WRT to these issues?

How about this: m.attrs is designed as a terse and intuitive way of attaching extra magic to Mithril views. It's ultimately designed for application space: you've got your application and you want to be thinking about what it does, not how generic functionality is implemented.
That's not the case for plugins designed for public consumption: with these you want to do one thing well in a way that makes it as robust and painless as possible for others to adopt. If I'm writing a plugin which consumes structured models and outputs self-validating forms, or I've developed a widget that uses a lot of form inputs, I may want to use implementation X of bidi, but ultimately I don't have the same mandate as a holistic application developer in keeping my source that trim — if I need to chuck in a bit of extra boilerplate to keep my plugin safe and trustworthy, I'll do it.
The solution then is to invoke m.attrs as  micro-components. So whereas an application developer would go for
m( 'select.ccExpiry',
  { bidi : ccExpiryProp },
  tenYearsFromNow.map( year =>
    m( 'option', year )
  )
)

…the responsible plugin destined for 3rd party use would write this as:
bidiComponent(
{ key },
m( 'select.ccExpiry',
  tenYearsFromNow.map( year =>
    m( 'option', year )
  )
),
ccExpiryProp
)

I'll go over the composeable components fiddle tomorrow morning to demo the proof of concept with this fork re-based to 0.2.0. Think this might just work.

Proposed structure of a 'safe' custom attribute plugin:
( function package( factory ){
	if( typeof define === 'function' && define.amd ){
		define( [ 'mithril' ], factory )
	}
	else if( typeof exports === 'object' ){
		module.exports = factory( require( 'mithril' ) )
	}
	else{
		factory( m )
	}
}( function define( m ){
	function bidi( node, prop ){
		var type = node.tag === 'select'
			? node.attrs.multi
				? 'multi'
				: 'select'
			: node.attrs.type

		// Setup: bind listeners
		if( type === 'multi' ){
			node.attrs.onchange = function(){
				prop( [].slice.call( this.selectedOptions, function( x ){
					return x.value
				} ) )
			}
		}
		else if( type === 'select' ){
			node.attrs.onchange = function( e ){
				prop( this.selectedOptions[ 0 ].value )
			}
		}
		else if( type === 'checkbox' ){
			node.attrs.onchange = function( e ){
				prop( this.checked )
			}
		}
		else {
			node.attrs.onchange = node.attrs.oninput = function( e ){
				prop( this.value )
			}
		}

		if( node.tag === 'select' ){
			node.children.forEach( function( option ){
				if( option.attrs.value === prop() || option.children[ 0 ] === prop() ){
					option.attrs.selected = true
				}
			} )
		}
		else if( type === 'checkbox' ){
			node.attrs.checked = prop()
		}
		else if( type === 'radio' ){
			node.attrs.checked = prop() === node.attrs.value
		}
		else {
			node.attrs.value   = prop()
		}

		return node
	}

	bidi.view = function( ctrl, node, prop ){
	  return bidi( node, prop )
	}

	return m.attrs.bidi = bidi
} ) )

The conflation between issue / thread / PR / branch is irritating. This should really be m.attrs.

Could you go over the spy and namespace options again WRT to these issues?

spy is basically the same thing as the extending view language article, in terms of scoping the extensions. Basically extensions are lexically scoped to a variant of m.
//in a nutshell
x = spy(m, bidi)
m(".foo", [
  x("input", {bidi: ctrl.something})
])

Namespacing is what Angular and Web Components do.
//in a nutshell
m(".foo", [
  m("input", {"mx-bidi": ctrl.something}) //less likely that two projects use the same namespace AND attribute (but technically not bulletproof)
])

Another idea:
m(".foo", [
  m("input", {mixin: bidi(ctrl.something)}) //here, bidi is requireable and lexically scoped
])

The key for a solution is lexical scoping. spy achieves that by lexically scoping the virtual dom construction call (the m variant x). The mixin idea lexically scopes the extension itself.
m.attr and namespacing run into issues because they dynamically scope the name of the extension (which is exactly what makes the this keyword confusing in core javascript).

 As you say they make collision (unquantifiably) less likely, but they make the application code suffer for it. Everything ends up harder to read and more black magic boilerplatey.
At this point I'm thinking global custom attributes with simple keys are the most  intuitive and legible way of extending the view language. There's a clear contract at work, but it has risks — namely collision. I think offering a micro-component with each custom attribute plugin solves that problem. It's more developer overhead, but it should be easy to copy paste the boilerplate. This way you get the convenience method for free but when your codebase gets conflicted, or you just want to make things as unambiguous as possible, you can break out lexically-scoped component references with a minor tweak in invocation grammar.
Custom attributes offer a huge convenience for simpler applications, but should always be available in the plain-old-0.2 component flavour as well.
What do you think?

Working on this here. Will post examples of different use cases when I find time.

So I've published a bidi plugin on NPM and Bower. Does this feel right as a way of packaging Mithril plugins?

IMHO, wrapping it in a component feels overly complicated, both from the plugin development standpoint and from the plugin consumption standpoint. There's nothing inherently stateful about these plugins, they're not about encapsulation either, and refactoring from one form to the other requires significant code changes, so I think components are not a good tool to fall back on.
I'm thinking of something like "path" namespaces. So, by default, a plugin is just registered in the global namespace, e.g.
//declare
m.attr("bidi", bidi)

//use in library
m("input", {bidi: foo}) //in library

//use in app
require("bidi")

m("input", {bidi: foo}) //in app (same syntax for both)

And if there's a conflict, then the library author could then add a namespace
//declare
m.attr("my-ns", "bidi", bidi)

//use in library
m("input", {"my-ns:bidi": foo}) // s/bidi:/"my-ns:bidi":/

//use in app (no conflict)
require("bidi")

m("input", {bidi: foo}) //use what's available

//use in app (conflict)
require("bidi")
require("something-that-also-has-bidi")

m("input", {"my-ns:bidi": foo})
m("input", {"the-other:bidi": foo})
m("input", {bidi: foo}) //this is the other bidi by virtue of order of inclusion
``

Thoughts?

Looks good, maybe namespaces should be mandatory to avoid conflicts before they arise.

@lhorie you're right, mandating the module function overload as a { view } is pretty horrible. It's confusing and non-trivial boilerplate for developers and users.
It strikes me we don't need to extend the API to provide namespacing. Up here I was doing variable assignments, when custom attr users are ultimately not that interested in the transform function itself – they just want Mithril to use it when they reference it. I think extending the signature doesn't really do anything, and colons in keys look like magic but aren't really ;P
If we leave the implementation as it is in my plugin (golfing your example):
//declare
m.attrs.bidi = foo

//use in library
m.attrs.thislibrary_bidi = require( 'bidi' )

m("input", {m.attrs.thislibrary_bidi: foo})

//use in app (no conflict)
require("bidi")

m("input", {bidi: foo}) //use what's available

//use in app (conflict)
m.attrs.bidi1 = require("bidi")
m.attrs.bidi2 = require("something-that-also-has-bidi")

m("input", {bidi1: foo})
m("input", {bidi2: foo})
m("input", {bidi: foo}) //this is "something-that-also-has-bidi" by virtue of order of inclusion

@webcss every registry system has this problem at some point. Telling people to come up with "unique enough" references isn't a good system IMO – it just makes things less sensible in application space.

maybe namespaces should be mandatory

It could be documented as a best practice convention for library authors, but I don't really see the point of making it mandatory (as in, throw an error if not present) if people just end up doing silly things like m.attr("ui:bidi", bidi) (or some equally conflict-prone generic-sounding namespace).
@barneycarroll I'm not a fan of the re-binding-in-app-space idiom. It should either always be the app developer's responsibility to disambiguate extensions (as would be the case w/ lexical scoping proposals), or it should always be the library author's responsibility to make their extensions unique (w/ registry-based proposals), but not both.
It's always possible to alias an registry-based extension in app space, but I think that should be considered a hack. Adding to the registry is the root of the collision problem to begin with, so the solution shouldn't involve deliberately using that mechanism in an ad-hoc fashion.

@lhorie sure, polluted registries are bad. You may regret having bidi1, bidi2 and bidi3 at the end of the day — it doesn't make things any clearer.

silly things like … "ui:bidi"

I'm not sure how silly that really is. In my book, this looks sillier:
m( "input", { "barneycarroll:bidi" : prop } )

it should always be the library author's responsibility to make their extensions unique

Yes. Again, Bootstrap were clearly in the wrong.

Adding to the registry is the root of the collision problem, so the solution shouldn't involve deliberately using that mechanism in the same ad-hoc fashion that caused the problem to begin with.

How ad-hoc is it? We're talking about different levels of responsibility. As an application developer, you should be responsible for what you bring in to your execution environment and how you handle it. Your preference for quoted keys with colons is your business, as is the number of plugins you throw in, and generally how you decide to write your app.
If I release a plugin that invokes 2 custom attributes with the same key and I resolve the confusion internally by rebinding using that same key, I'm an irresponsible person who may end up causing grief to my users. I hope I get taken to account.
But as an end user, this is horrible. At least with every other package manager you get to separate external and internal references.
My application initialisation does a fair bit of tweaking to get my application play nice with it's libraries. I override m.request to throttle XHR, I patch a URIjs method to play nice with m.route. I piggy back on an authentication widgets initialisation methods to make sure it doesn't blow up and clog the page with custom styles. If I want the convenience of custom attributes but their naming convention is bloated by concerns external to my application, I'll probably rebind them here.
Why shouldn't I?

How ad-hoc is it?

It's about as ad-hoc as it gets. The only namespacing thing that I know of that adds pollution to the registry is this, and honestly I think the fact that they put warnings about known problematic use cases right on the homepage speaks volumes.

Your preference for quoted keys with colons is your business

I disagree. If disambiguation is going to be solved by a convention, then everyone should follow the same convention.
More importantly, if, for example, I join your team, I'd like to know that "ui:bidi" is the same "ui:bidi" library I used in my previous company, rather than have to guess than bidi2 means "ui:bidi". I'd also like to know that I can't claim "ui:bidi" for my own extension: if your library publically exposes "bidi" but uses "ui:bidi" internally, then I, as a library consumer, need to be aware that both of these names are taken. This is why I mentioned the "ui" namespace is silly. It's probably the first namespace anyone's going to come up with if they don't have a good one in mind, which negates its "hashing" purpose.
Re: the syntactical point: Angular actually has flexible namespacing conventions (i.e. you can use ng-model or ng:model), so there you can actually setup whatever conventions you want, but frankly that strikes me as a recipe for inconsistencies.

But as an end user, this is horrible. At least with every other package manager you get to separate external and internal references.

Yes, via lexical scoping. If you as an app dev want to bind "ui:bidi" to a local lexically scoped variable bidi2, that's fine, since the binding is explicit at the top of the file, but it shouldn't dynamically modify the registry for the entire app. This may seem pedantic but it's the difference between how namespaces are supposed to work vs a hack that just happens to work in javascript while setting up a minefield behind it.

Summing up my gitter criticism of this proposal:
If I write a library that I want to share, I can't rely on m.attrs transformer because if I register one for my code, it may step on the toes of the lib user.
Alternative solutions.
m.spy = function (m) {
    var plugins = type.call(plugins) === ARRAY ? plugins : [plugins];
    function res() {
        var vdom = m.apply(null, arguments)
        for (var i = 0, N = plugins.length; i < N; i++) {
            plugin[i](vdom);
            // or maybe this?
            // vdom = plugin[i](vdom) || vdom;
        }
        return vdom;
    }
    for (var k in m) if (m.hasOwnProperty(k)) res[k] = m[k];
    return res;
}

;(function(){
var mx = m.spy(m, [plugin1, plugin2])
})();

The thing is, you don't want to overwrite m globally, and JS makes it surprisingly hard to name a local variable after a global or a variable in a parent scope.
If you want to opt in locally into an extended m, in an existing template, you must either do ugly IIFE-based things to get a local m name, or use an alias for the extended version, and remember to update m to mx in the relevant places.
Using mx from the get go would be less annoying.
Alternatively:
m.spy = function (m, plugins, executor) {
    var plugins = type.call(plugins) === ARRAY ? plugins : [plugins]
    function res() {
        var vdom = m.apply(null, arguments);
        for (var i = 0, N = plugins.length; i < N; i++) {
            plugin[i](vdom);
            // or maybe this?
            // vdom = plugin[i](vdom) || vdom;
        }
        return vdom;
    }
    for (var k in m) if (m.hasOwnProperty(k)) res[k] = m[k];
    executor(res);
}

m.spy(m, plugin, function(m){
    ...
}

m.attrs
Had some good back-and-forth with @pygy on Gitter thrashing out the implementation and API issues with various extension methods in different environments. My takeaway observations:

Leo & Pierre-Yves are right: my current implementation of m.attrs is too dangerous in that extensions can't be scoped.
…but the API beats the others by a country mile in terms of semantics and readability.
All the counter-proposals chuck in too much of a cognitive burden on API users, and make for ugly code.

The ideal solution would keep the end user API of this implementation and take care of dependency injection / closuring (thereby keeping custom attributes local to a view) procedurally. Turns out Mithril already provides dependency injection and closures via components.
How about the component (the fundamental molecule for Mithril) takes responsibility for defining the transformations the view requires? When a component defines an attributes property, the referenced transforms map is loaded into a local m which is prepended to the view signature. Maximum clarity, minimum effort, total safety:
var component = {
	attributes : {
		bidi     : function( node, attrValue ){
			/* ... */
		},
		disabled : function( node, attrValue ){
			/* ... */
		},
		lazyload : function( node, attrValue ){
			/* ... */
		}
	},
	controller : function(){
		/* ... */
	},
	view       : function( m, ctrl, ...rest ){
		/* local m comes with custom attributes */
	}
}

I think m.attrs is a great idea if you simply make the app developer the one responsible for "importing" plugins.
Following the previous examples:
// Use in library
// -- Libraries should *never* extend m.attrs --
module.exports = function (node, prop) {
  // ...
}

// Use in app
// This would be copy/pasted from the library's README.md
m.attrs.bidi = require("bidi")

m("input", { bidi: foo }) // No problem!

// Use in app (conflict)
m.attrs.bidi1 = require("bidi")
m.attrs.bidi2 = require("something-that-also-has-bidi")

m("input", {bidi1: foo})
m("input", {bidi2: foo})
// m("input", { bidi: foo }) // This does not exist, since the app developer never set it.

To me, m.attrs is too pleasant a convenience to miss out on. If we keep m.attrs an application-space-only feature by setting the convention "libraries should never extend m.attrs", I think everything would work out perfectly.

@mindeavor love it!

The view function is definitely the right place to introduce a new scope, but this breaks backwards compatibility, which Leo may not like...
A backwards compatible way to introduce it would be to bind the augmented m to this in the view. Not very nice, though...
Regarding the implementation, after back and forth with @barneycarroll, I came up with this:
var own = {}.hasOwnProperty
m.extend = function (extensions) {
    function res () {
        var vdom = m.apply(null, arguments)
        for (var name in vdom.attrs) if (
            own.call(vdom.attrs, name)
         && vdom.attrs[name] != null// so that {fooAttr:foo()} can disable fooFilter?
         && own.call(extensions[name])
        ) {
            vdom = extensions[name](vdom, name) || vdom;
        }
        return vdom;
    }
    // augment res with `m.*` properties?
    return res
}

mx = m.extend({
    bidi: bidi,
    j2c: j2c
})

@mindeavour keeping the API as it is certainly makes everything incredibly easy. Especially as the implementation is ready to go ;)
A few thoughts on safety:

In future (or now depending on their toolchain), developers of Mithril code intended for public consumption will be able to circumvent the ban by assigning custom attributes to ES6 Symbols [1]
We could also increase safety of invoking third party code which may or may not invoke conflicting attributes by recommending that custom attribute authors implement attribute definitions with get and set via Object.defineProperty. The setter could then throw a warning when any given custom attribute key is reassigned.

@pygy the extended view signature would only apply to components that had explicitly defined a custom attributes map, so backwards compatibility is ensured. IMO this is far less confusing than constructing and assigning your own extended m variant, which to my mind exposes the same kind of author implementation responsibility as pre-0.2 component instantiation.

Very good points.
I suppose you'd cache the enhanced m instance with the component controller.
So we end up with an internal function that looks like this:
var own = {}.hasOwnProperty
function extend(extensions) {
      filters = {}
      ;
    for (var k in extensions) if (own.call(extensions, k)) {
        filters[k] = extensions[k];
    }
    function res () {
        var vdom = m.apply(null, arguments)
        for (var name in vdom.attrs) if (
            own.call(vdom.attrs, name)
         && vdom.attrs[name] != null // so that {fooAttr:foo()} can disable fooFilter?
         && own.call(filters[name])
        ) {
            vdom = filters[name](vdom, name) || vdom;
        }
        return vdom;
    }
    for (var k in m) if (own.call(m, k)) {
        res[k] = m[k];
    }
    return res;
}

@mindeavor
Even in that use case, a global m.attrs filter may mess up a third party component that relies on custom attributes.

One last issue with this proposal is the lack of control on the order of execution of the filters.
What about this?
var component = {
    extensions : [
        {
            attribute:"bidi",
            filter: function( node, attrValue ){
                /* ... */
            }
        }
    ],
    controller : function(){
        /* ... */
    },
    view       : function( m, ctrl, ...rest ){
        /* local m comes with custom attributes */
    }
}

///// ----------- /////

var own = {}.hasOwnProperty
function extend(extensions) {
    extensions = extensions.slice(0)

    function res () {
        var vdom = m.apply(null, arguments)
        for (var i = 0, ext; ext = extensions[i]; i++){
            var attr = ext.attr;
            if (own.call(vdom.attrs[attr]) && vdom.attrs[attr] != null) {
                vdom = ext.filter(vdom, attr)
            }
        }
        return vdom;
    }
    for (var k in m) if (own.call(m, k)) {
        res[k] = m[k];
    }
    return res
}

So, @barneycarroll proposed this as a terser syntax, an I like it too :-)
component.attributes = [
    [ key, transform ]…
]

One thing still bugs me, though: the use of attributes for this feature. Attributes are the trigger, we're really dealing with plugins/filters/transformers/extenstions, here.

@pygy I think it's important to keep this all user-land focussed. One of the problems with spy, for instance, is that the public API language is too concerned with an implementation mechanism which should be under the hood.
So are these really filters or transforms? Who knows?
If we look at Mithril under the hood, the generic processing behaviour on the properties of what is referred to internally as attrs is to first see if the property is available on the built DOM element and assign the value directly to that property, and if not assign it as an attribute. The semantic distinction between 'property' and 'attribute' is important in terms of the DOM (me and @farzher have both repeatedly been bitten by trying to 'disable' anchor elements – you just end up setting the value of an attribute, which is not at all the desired effect) – but the user really doesn't want to have to worry about this.
To get a bit meta about things, this is what the 'bidi' custom attribute attempts to solve: papering over low-level semantic distinctions which are more of a confusing hindrance than an advantage when you're trying to write procedural views (what's the input handler? how do I get a hook on the value?). What bidi is – ie what it really does under the hood – is really not something you should have to worry about.
Going back to Mithril core, there are some special considerations: attrs properties whose key starts with 'on' and whose value is a function will be decorated such that they trigger a redraw. config is a special case. How would we describe that? It's a custom attribute that's part of core.

I agree that the naming should be user-focused, but I don't undestand your concern.

So are these really filters or transforms? Who knows?

They are definitely not attributes. They are functions triggered by the presence of one, ...
... view add-ons (plugins/extensions) that act on vDOM objects in order to modify (filter/transform) them.
That's their intended purpose, at least.

Sorry if I'm moving the carpet again, but I've been thinking of adding a namespace resolution magic attribute, which would work like this:
////library.js
module.exports = {bidi: function() {...}} //libraries never touch m.attrs map

//-------

////in app (no collision)
//app configuration file
console.log(m.attrs) // {} - this is the default namespace
m.attrs = require("./library") //app dev defines what goes in the default namespace

//in views
m("input", {bidi: foo}) //does what you expect

//----------

//or with multiple library (again, no collision)
//app configuration file
m.attrs = Object.assign(m.attrs, require("./library"), require("./another"))

//----------

//with collision
//app configuration file
m.attrs = Object.assign(m.attrs, require("./library"), require("./another"))
var another = require("./something-with-bidi") //here, the app dev imports the colliding module into a different namespace

//in views
m("input", {bidi: foo}) //use default namespace
m("input", {bidi: foo, ns: another}) // use bidi from something-with-bidi module

@lhorie module closuring doesn't clone the export — extensions to an imported module will persist in other modules. The dreaded $.fn.button problem will persist with AMD, SystemJS, CommonJS and the rest. This is pretty much how the canonical jQuery-plugin-as-module works.

@barneycarroll I know that. What's your concern?

@lhorie sorry I clearly misunderstood your proposal. Walk us through it in more detail (maybe on Gitter)?

To summarize, ns allows you to override the extensions that were defined in m.attrs with an arbitrary set of extensions, on a per-element basis.
So as an app dev, you can dump all the extensions you want into m.attrs in a configuration file, and you can optionally use a different map on the rare case where two attributes have a name collision.
As a library author, you can always use the ns attribute to use extensions in your library, while keeping the m.attrs map hygienic.

The whole namespace idea seems quite convoluted IMO. A subtle but important difference in the @mindeavor implementation is that each library is responsible for exporting a single function, which the application developer then has complete control on how to wire it up. I realize @lhorie may be trying to get away from the responsibility this puts on the application developer to have to name the attr, but no other solution presented comes close in terms of brevity and clarity. It just seems like the right level of abstraction. No magic, clear contract.

We had a long discussion in the chat, and determined that if an app developer extended m.attrs, that would leak into libraries, potentially stepping on other code.
But it just occurred to me, this would only happen if the app developer extended on a name that already existed, e.g. m.attrs.onclick = myFunction. Would this leaking be resolved if Mithril disallowed m.attrs on standard DOM attributes?

Would this leaking issue be resolved if Mithril disallowed m.attrs on standard DOM attributes?

Not really – Mithril doesn't have an internal map of standard attributes, they just so happen to behave a certain way internally. Besides, if someone wants to attach special behaviour to disabled (to make it work on non-form elements, for example), I don't think that's a problem. Likewise if I want to redefine onclick that's kinda nuts, but I don't think it's Mithril's duty to intervene and stop me. Having said this, I should change the implementation so that it doesn't delete the custom attribute after capturing its value – that should be a job for the transformation, if it's desirable.

This PR is superseded by #628. Let's carry on the conversation over there.

We had a long discussion in the chat, and determined that if an app developer extended m.attrs, that would leak into libraries, potentially stepping on other code.

Libraries would never extend m.attrs. I think m.attrs is most powerful when treated as repository of view abstractions managed by the app developer. As a mithril app grows organically, common view patterns will arise, and it is this type of code is perfect to abstract into m.attrs - as it allows the developer to express view logic in a very concise manner while still being intimately aware of what is going on under the hood. It is a powerful abstraction layer to compose and digest your view. It is a great api to naturally extend the view language without excessive magic because everything is done in application land.
Because m.attrs is simple a repository of "helpers" defined by the app developer, there is no need to worry about conflicts. For plugin encapsulation, a variation of what @lhorie was getting at:
// mithril.bidi.js
module.exports = function bidi(node, prop) { ... }

// application.js
m.attrs.bidi = require("mithril.bidi");

view() {
    return [
        m("input", { bidi: foo }), // Global bidi
        m("input", { bidi: bar, alias: { bidi: require("mithril.bidi2") } }), // Custom bidi
    ];
}

The problem is that the virtual DOM returned by a library may be altered in unexpected ways by a m.attrs handler registered by an app developer.


SteamDB Extension causes infinite loop on Steam Age Check

Hello,
Only SteamDB v1.5.7 extension on empty/clean FireFox profile when visiting an age check required Steam page like http://store.steampowered.com/app/447040/ (WD2) causes page load stuck at http://store.steampowered.com/agecheck/app/447040/ indefinitely. For trying this your Steam cookie must not have verified age check, otherwise it goes smooth after it is recorded in cookie. So either clean cookies or try it on new clean profile.
As a workaround, extension can be turned off/on on the fly without restart to go through age check successfully. Hoping this will get addressed on next release.
Regards.

Pretty sure it was already updated...
https://addons.mozilla.org/en-US/firefox/addon/steam-database/versions/?page=1#version-1.5.8


I discovered F-19 and F-117A during my young years and I am in the process of replaying some of these good flight simulation games of the 90s.
I am barely a developer but I am working on a AHK v2 script that allows to use the mouse cursor to click on the cockpit buttons of F-117A Nighthawk Stealth Fighter 2.0.
For the moment, if I have been able to use the mouse cursor to click on cockpit buttons, I haven't found the way to display the mouse cursor itself (because of DOSBox that "catches it" as soon as you click on its window). I am investigating the possible solutions to remedy this issue, such as using DOSBox-X.
I don't know if this is possible but another solution would be to mod the game so that it is possible to display the ingame mouse cursor over the cockpit view (and not only while navigating the game menus (briefing, weapons selection, etc)).
👉 Do you know if it's possible to display the game cursor (the one that we see on the briefing screen) over the cockpit and HUD?
Mock-up:

Hi, sorry for the late reply ...
Yes it should be possible - the game itself shows and hides the mouse cursor as needed after all.
A quick search here tells me that to access the mouse cursor services in DOS, you need to call int 33h
1/ with the value 1 in the AX register, to show the cursor
2/ with the value 2 in the AX register, to hide the cursor
Not sure how you would call this from Autohotkey though.

Hi. Thank you for your answer. I will investigate your solution. Thank you very much.
btw, I managed to display a mouse cursor with my AHK script.


[BugFix] Avoid repeatedly adding tablet to pending queue

What type of PR is this：

[x] bug
[ ] feature
[ ] enhancement
[ ] refactor
[ ] others

Which issues of this PR fixes ：

Fixes #7871
Problem Summary(Required) ：

    // Under no circumstance should we repeatedly add a tablet to pending queue
    // to schedule, because this will break the scheduling logic. Besides, with current design,
    // we have to maintain the constraint that `allTabletIds = runningTablets + pendingTablets`.
    // `allTabletIds` and `runningTablets` are defined as unique container, if we schedule a
    // tablet with different `TabletSchedCtx` at the same time, the reference in `runningTablets`
    // can be messed up.
    // `force` here should only mean that we can exceed the size limit of
    // `pendingTablets` and `runningTablets` if there is too many tablets to schedule.

we check pendingList before add a new tablet to it.

run_fe_unittest

[FE PR Coverage check]
:disappointed: fail : 0 / 14 (00.00%)
file detail

path
covered line
new line
coverage

:large_blue_circle:
com/starrocks/clone/TabletScheduler.java
0
13
00.00%

:large_blue_circle:
com/starrocks/clone/TabletSchedCtx.java
0
1
00.00%

run_fe_unittest

[FE PR Coverage check]
:disappointed: fail : 0 / 18 (00.00%)
file detail

path
covered line
new line
coverage

:large_blue_circle:
com/starrocks/clone/TabletScheduler.java
0
17
00.00%

:large_blue_circle:
com/starrocks/clone/TabletSchedCtx.java
0
1
00.00%

How did you test this bug and where are the test cases?

How did you test this bug and where are the test cases?

I tested in a test deployment, acutally it's more like a refinement than bugfix, because the code logic currently won't add two tablet with the same id into pending list. But the meaning of  force argument here is vague, we may accidentally do stupid things in the future, i think we should make some prevention.
Anyway, i shall look into our integration test repo and see how to add some tests there.

[FE PR Coverage check]
:disappointed: fail : 0 / 18 (00.00%)
file detail

path
covered line
new line
coverage

:large_blue_circle:
com/starrocks/clone/TabletScheduler.java
0
17
00.00%

:large_blue_circle:
com/starrocks/clone/TabletSchedCtx.java
0
1
00.00%


Locate ruff executable in 'bin' directory as installed by 'pip install --target'.

Fixes #11246

Summary
This change adds an intermediate additional search path for find_ruff_bin.
I would have added this path as the last one, except that the last one is the one reported to the user, so I made this one second to last.
Test Plan
It's shown to work with this command:
 ~ @ pip-run git+https://github.com/jaraco/ruff@feature/honor-install-target-bin -- -m ruff --version
ruff 0.4.4

I tried running the same command on Windows, which should work in theory, but building ruff from source on Windows is complicated. Even after installing Rust, ruff fails to build when libmimalloc-sys fails to build because gcc isn't installed (and the error message points to a broken anchor). I was really hoping Rust would get us away from the Windows as second-class-citizen model :(.

Windows test failures are reported in https://github.com/astral-sh/ruff/issues/11439.


[GJ-56] Enable Columnar Shuffle

This pr:

ported the latest Columnar Shuffle from Gazelle, based on Gazelle commit. With this change, Columnar Shuffle can be enabled with below config:
--conf spark.shuffle.manager=org.apache.spark.shuffle.sort.ColumnarShuffleManager

restructured the CPP files

the support for hash partition will be added in following PR

Closes https://github.com/oap-project/gazelle-jni/issues/56.

@zzcclp I push one commit to load Gazelle-JNI's native library. Please take a review on that, thanks.

LGTM, verified locally with CH lib, it worked.


Cannot login demo grafana

Describe the bug
A clear and concise description of what the bug is.
Cannot login demo grafana with test/test (README described)
To Reproduce
Steps to reproduce the behavior:

Go to 'https://app-259373083972538368-3002.ars.teamcode.com/login'
Login with test/test

Expected behavior
Login success
Screenshots

Sorry for you inconvenience, seems like someone changed the password.
We had already reset the account, please try again.

@klesh Thanks. Login successed


[Flaky Test] CAPM3 deployment is not ready

Which jobs are flaking?
Only :
Clusterctl upgrade main
Which tests are flaking?
metal3-periodic-e2e-clusterctl-upgrade-test-main When testing cluster upgrade from releases (v1.7=>current) in the STEP: [0] Upgrading providers to the latest version available
Since when has it been flaking?
First seen on Jul 10, 2024, 10:10:00 PM
Jenkins link
https://jenkins.nordix.org/view/Metal3 Periodic/job/metal3-periodic-e2e-clusterctl-upgrade-test-main/77/consoleFull
Reason for failure (if possible)
Not sure just pasting the error logs
16:51:00    < Exit [AfterEach] When testing cluster upgrade from releases (v1.7=>current) [clusterctl-upgrade] @ 07/18/24 13:50:54.088 (5m1.138s)
16:51:00  • [FAILED] [3413.643 seconds]
16:51:00  When testing cluster upgrade from releases (v1.7=>current) [clusterctl-upgrade] [It] Should create a management cluster and then upgrade all the providers
16:51:00  /home/metal3ci/go/pkg/mod/sigs.k8s.io/cluster-api/test@v1.7.0-rc.0.0.20240618172153-54c8e46eeb48/e2e/clusterctl_upgrade.go:253
16:51:00
16:51:00    [FAILED] failed to run clusterctl upgrade
16:51:00    Unexpected error:
16:51:00        <*errors.withStack | 0xc001bb3848>:
16:51:00        deployment "capm3-controller-manager" is not ready after 5m0s: failed to connect to the management cluster: action failed after 0 attempts: context deadline exceeded
16:51:00        {
16:51:00            error: <*errors.withMessage | 0xc001fecde0>{
16:51:00                cause: <*errors.withStack | 0xc001bb3818>{
16:51:00                    error: <*errors.withMessage | 0xc001fecdc0>{
16:51:00                        cause: <*errors.withStack | 0xc001bb37e8>{
16:51:00                            error: <*errors.withMessage | 0xc001fecda0>{
16:51:00                                cause: <context.deadlineExceededError>{},
16:51:00                                msg: "action failed after 0 attempts",
16:51:00                            },
16:51:00                            stack: [0x3113ac5, 0x3132326, 0x31198b0, 0x24afe72, 0x24afccd, 0x24b0185, 0x31196f3, 0x3119673, 0x3119507, 0x314108b, 0x313ec45, 0x315aa8d, 0x326dc48, 0x3272d08, 0x34d627a, 0x192c193, 0x194036d, 0x148fe21],
16:51:00                        },
16:51:00                        msg: "failed to connect to the management cluster",
16:51:00                    },
16:51:00                    stack: [0x313233c, 0x31198b0, 0x24afe72, 0x24afccd, 0x24b0185, 0x31196f3, 0x3119673, 0x3119507, 0x314108b, 0x313ec45, 0x315aa8d, 0x326dc48, 0x3272d08, 0x34d627a, 0x192c193, 0x194036d, 0x148fe21],
16:51:00                },
16:51:00                msg: "deployment \"capm3-controller-manager\" is not ready after 5m0s",
16:51:00            },
16:51:00            stack: [0x31197e8, 0x3119507, 0x314108b, 0x313ec45, 0x315aa8d, 0x326dc48, 0x3272d08, 0x34d627a, 0x192c193, 0x194036d, 0x148fe21],
16:51:00        }
16:51:00    occurred
16:51:00    In [It] at: /home/metal3ci/go/pkg/mod/sigs.k8s.io/cluster-api/test@v1.7.0-rc.0.0.20240618172153-54c8e46eeb48/framework/clusterctl/client.go:202 @ 07/18/24 13:35:57.588
16:51:00
16:51:00    Full Stack Trace
16:51:00      sigs.k8s.io/cluster-api/test/framework/clusterctl.Upgrade({_, _}, {{0xc000de2300, 0x53}, {0xc00063a35d, 0x47}, 0x0, {0xc001a7a300, 0x24}, {0xc00193b640, ...}, ...})
16:51:00      	/home/metal3ci/go/pkg/mod/sigs.k8s.io/cluster-api/test@v1.7.0-rc.0.0.20240618172153-54c8e46eeb48/framework/clusterctl/client.go:202 +0x63d
16:51:00      sigs.k8s.io/cluster-api/test/framework/clusterctl.UpgradeManagementClusterAndWait({_, _}, {{0x41f4178, 0xc000fb1560}, {0xc00063a35d, 0x47}, 0x0, {0x3d27c5b, 0x7}, {0x0, ...}, ...}, ...)
16:51:00      	/home/metal3ci/go/pkg/mod/sigs.k8s.io/cluster-api/test@v1.7.0-rc.0.0.20240618172153-54c8e46eeb48/framework/clusterctl/clusterctl_helpers.go:212 +0x9e8
16:51:00      sigs.k8s.io/cluster-api/test/e2e.ClusterctlUpgradeSpec.func2()
16:51:00      	/home/metal3ci/go/pkg/mod/sigs.k8s.io/cluster-api/test@v1.7.0-rc.0.0.20240618172153-54c8e46eeb48/e2e/clusterctl_upgrade.go:582 +0x38ba

Anything else we need to know?
clusterctl was failing because of other issue the got fixed recently and this flake can be also because of infra also it is frequent
Label(s) to be applied
/kind flake

triage/accepted

/label triage/accepted

/triage/accepted

@mboukhalfa is this still an issue?

seems no the clusterctl did not fail for long

we are not seeing this flake anymore. Closing this issue.


feat: Friuli Venezia Giulia

I made a single PR as they all share the same website as source

Could you merge this when you have time please?

Please address/fix issues outlined in the review comments. Then squash the history and force push to PR branch.

I don't see any comments, have you published them?

I don't see any comments, have you published them?

Yup. Not sure why you don't see them above. Any chance you somehow managed to collapse the comments? Direct link to review is here.

No I can't see any comment. Could you send them again please?

in: lib/tools/turismofvg.js

re: toTitleCase It's not needed: seems like the lift names are already properly capitalized in HTML.
re: fn It's not needed: 'close' and 'open' should be coerced automatically - pretty sure fn is not needed here

done thanks


Fix where "make pre-commit" fails without changes

Description
With latest golangci-lint, resolve new messages
Fixes # (issue)
Type of change
What is it?

[X] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Documentation update
[ ] Tests update
[ ] Refactor

Checklist:

[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[X] I run make pre-commit to check fmt/vet/lint/test-no-fdo

Codecov Report
Base: 37.44% // Head: 37.47% // Increases project coverage by +0.03% :tada:

Coverage data is based on head (907ca8e) compared to base (577ab92).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1625      +/-   ##
==========================================
+ Coverage   37.44%   37.47%   +0.03%
==========================================
  Files          66       66
  Lines        8803     8803
==========================================
+ Hits         3296     3299       +3
+ Misses       5108     5106       -2
+ Partials      399      398       -1

Impacted Files
Coverage Δ

main.go
0.00% <ø> (ø)

pkg/routes/devicegroups.go
32.69% <ø> (ø)

pkg/routes/images.go
25.09% <ø> (ø)

pkg/routes/thirdpartyrepo.go
34.45% <ø> (ø)

pkg/services/consumers.go
16.34% <ø> (ø)

pkg/services/images_build/main.go
0.00% <ø> (ø)

pkg/services/images_iso/main.go
0.00% <ø> (ø)

pkg/services/devices.go
50.37% <0.00%> (+0.32%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Add Histogram Sum Aggregation

Implement Sum Aggregation as Part of #31

@zeotuan How did you generate it? There is a make generate_code that also apply linting rules and with it diff should be less.


Compilation errors on Android

I have built the OpenNI libs for android successfully and the files were "libOniFile.so","libOpenNI2.so",
"libPS1080.so","libPSLink.so","libusb.so".
That's what I want.
But I failed while trying to build the jni module from the source in "Wrappers" folder by NDK
I got errors  like:
jni/org_openni_NativeMethods.cpp:34:2: error: 'XnBool' does not name a type
XnBool m_bShouldDetach;
^
...
jni/org_openni_NativeMethods.cpp:58:48: error: 'XnUInt64' has not been declared
void SetOutArgLongValue(JNIEnv*env, jobject p, XnUInt64 value)
...
I tried to add some macro defination such as  #define XN_PLATFORM XN_PLATFORM_ANDROID_ARM but it makes no difference.
Are those source files available on android?
Or how can I fix it?

Hi!
could you tell me how to build the jni module？
I have no idea.
l just want to run it in Android apk.
thankyou!


feat: include Normalize.css in bundle

Checklist:

[ ] I have read freeCodeCamp's contribution guidelines.
[ ] My pull request has a descriptive title (not a vague title like Update index.md)

Closes #XXXXX

Sure no problem.


feat: Add support for Neptune cluster networking

Description

Adding support for Neptune cluster networking. Basically duplicating the existing support for RDS and adding it for Neptune.
Motivation and Context

Neptune is a relatively new AWS database offering. Without top-level support for Neptune networking in the VPC module, the alternative is re-using database (RDS) networking infrastructure. Which isn't a problem, but isn't necessarily ideal.
Breaking Changes

I don't think any of these are breaking changes, just minor version changes since there are new properties being added. No existing properties are being changed.
How Has This Been Tested?

[x] I have tested and validated these changes using one or more of the provided examples/* projects

This is the tf apply output after running the complete example on master and then on this PR branch:
collapsed

$ tf apply

...

Terraform will perform the following actions:

  # module.vpc.aws_neptune_subnet_group.neptune[0] will be created
  + resource "aws_neptune_subnet_group" "neptune" {
      + arn         = (known after apply)
      + description = "Neptune subnet group for complete-example"
      + id          = (known after apply)
      + name        = "complete-example"
      + name_prefix = (known after apply)
      + subnet_ids  = (known after apply)
      + tags        = {
          + "Environment" = "staging"
          + "Name"        = "complete"
          + "Owner"       = "user"
        }
      + tags_all    = {
          + "Environment" = "staging"
          + "Name"        = "complete"
          + "Owner"       = "user"
        }
    }

  # module.vpc.aws_route_table_association.neptune[0] will be created
  + resource "aws_route_table_association" "neptune" {
      + id             = (known after apply)
      + route_table_id = "rtb-01b3308216a92ccac"
      + subnet_id      = (known after apply)
    }

  # module.vpc.aws_route_table_association.neptune[1] will be created
  + resource "aws_route_table_association" "neptune" {
      + id             = (known after apply)
      + route_table_id = "rtb-01b3308216a92ccac"
      + subnet_id      = (known after apply)
    }

  # module.vpc.aws_route_table_association.neptune[2] will be created
  + resource "aws_route_table_association" "neptune" {
      + id             = (known after apply)
      + route_table_id = "rtb-01b3308216a92ccac"
      + subnet_id      = (known after apply)
    }

  # module.vpc.aws_subnet.neptune[0] will be created
  + resource "aws_subnet" "neptune" {
      + arn                             = (known after apply)
      + assign_ipv6_address_on_creation = false
      + availability_zone               = "eu-west-1a"
      + availability_zone_id            = (known after apply)
      + cidr_block                      = "<IP_ADDRESS>/24"
      + id                              = (known after apply)
      + ipv6_cidr_block_association_id  = (known after apply)
      + map_public_ip_on_launch         = false
      + owner_id                        = (known after apply)
      + tags                            = {
          + "Environment" = "staging"
          + "Name"        = "complete"
          + "Owner"       = "user"
        }
      + tags_all                        = {
          + "Environment" = "staging"
          + "Name"        = "complete"
          + "Owner"       = "user"
        }
      + vpc_id                          = "vpc-070f54dfd8cdea070"
    }

  # module.vpc.aws_subnet.neptune[1] will be created
  + resource "aws_subnet" "neptune" {
      + arn                             = (known after apply)
      + assign_ipv6_address_on_creation = false
      + availability_zone               = "eu-west-1b"
      + availability_zone_id            = (known after apply)
      + cidr_block                      = "<IP_ADDRESS>/24"
      + id                              = (known after apply)
      + ipv6_cidr_block_association_id  = (known after apply)
      + map_public_ip_on_launch         = false
      + owner_id                        = (known after apply)
      + tags                            = {
          + "Environment" = "staging"
          + "Name"        = "complete"
          + "Owner"       = "user"
        }
      + tags_all                        = {
          + "Environment" = "staging"
          + "Name"        = "complete"
          + "Owner"       = "user"
        }
      + vpc_id                          = "vpc-070f54dfd8cdea070"
    }

  # module.vpc.aws_subnet.neptune[2] will be created
  + resource "aws_subnet" "neptune" {
      + arn                             = (known after apply)
      + assign_ipv6_address_on_creation = false
      + availability_zone               = "eu-west-1c"
      + availability_zone_id            = (known after apply)
      + cidr_block                      = "<IP_ADDRESS>/24"
      + id                              = (known after apply)
      + ipv6_cidr_block_association_id  = (known after apply)
      + map_public_ip_on_launch         = false
      + owner_id                        = (known after apply)
      + tags                            = {
          + "Environment" = "staging"
          + "Name"        = "complete"
          + "Owner"       = "user"
        }
      + tags_all                        = {
          + "Environment" = "staging"
          + "Name"        = "complete"
          + "Owner"       = "user"
        }
      + vpc_id                          = "vpc-070f54dfd8cdea070"
    }

Plan: 7 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

   Resources: 7 added, 0 changed, 0 destroyed.

Outputs:

...

ping @antonbabenko let me know if you need anything more from me for this PR.

@antonbabenko i wonder if we should have a generic "subnets" submodule (inline with vpc endpoints) to reuse (at least for new stuff) as there seems to be a lot of copy/paste for each of these (redshift, neptune, any new service)
this would make maintenance easier
also @bryantbiggs opinion appreciated

Subnets are different from VPC endpoints because subnets are heavily used in all other resources as arguments, so I don't think it will make a lot of sense to make it a reusable submodule.
I think we should be good to have prescribed types of subnets available like we have now plus add those for the services that have extra resources (eg, Neptune has aws_neptune_subnet_group). This PR is pretty good, I will queue it for review.
We can also add support for generic subnets if users want to create some for any reason (eg, their custom requirements). I think it can be developed at the same time as this - https://github.com/terraform-aws-modules/terraform-aws-vpc/pull/535 .

@antonbabenko I have rebased this PR and re-run pre-commit. Ready for review again at your convenience, assuming you want to move forward with this prior to extracting more generic subnet modules.


Does not work properly in IOS master detail page

Issue 1.
The control is really nice but I have some issues. On android if you put this control in the detail of a master detail page it works all fine. This is because you have to slide open the menu from the left side. On IOS however you can slide open the master menu from any place in the screen by swiping to the right. So if you swipe the slider to the right it will move a small portion. Then it locks and the menu starts appearing and moving to the right. It seems that the swiping gesture of the menu has preference above the swiping on your control and this is wrong. With a normal slider in the detail it does work fine though.
Issue 2.
I need one slider but I want the number above the slider. So I show the number above and hide the min thumb. The min thumb is hidden but the number above it is still visible in IOS. I would expect that if you hide a thumb the number above it is hidden too.

@michelmoorlag

For the first issue I can only recommend setting IsGestureEnabled to false.
https://github.com/halkar/xamarin-range-slider/issues/48#issuecomment-277507653
I will try to fix it but can't guarantee any positive results.
Thanks! I'll fix it ASAP.

@halkar
To reproduce issue 1 just create a basic XF master detail page and put the range slider in a detail page.
I could disable the IsGestureEnabled on the master but I really like this feature.  So if you can make this work within a master detail configuration you will be my best friend ... ever :)

Both fixed in 0.6.16

Hello, I think there has been a regression, at least on Android 7.1.1.
Putting a RangeSlider in the Master (sidebar) page of a MasterDetailPage makes the slider unusable, touching either of the thumbs closes the sidebar, and puts the thumb you were touching to the maximum value.
I think, from testing, that it's because of setting IsGestureEnabled to false. You can make an auto closing sidebar by adding a IsPresentedChanged handler to the MasterDetailPage that toggles the IsGestureEnabled.
I have no idea how to fix this or if fixing it would break other versions, but for now I'm stuck while writing an app because of this :/


string manipulation and algo

Hello @shivamranj ,
I'd recommend the following :

Document the algorithm, the purpose of the repo is to explain a newbie what's going on in a lucid way. Explain what a function or code block does.

Use a code editor, and don't mix space and tabs. Indent it well.

Use a .gitignore file to avoid uploading binary/unwanted files, if you are aware of their extensions. (For e.g. *.exe, *elf etc.).

Looking forward to your contribution.
Regards,
Pranjal

Hello @shivamranj ,
I'd recommend the following :

Document the algorithm, the purpose of the repo is to explain a newbie what's going on in a lucid way. Explain what a function or code block does.

Use a code editor, and don't mix space and tabs. Indent it well.

Use a .gitignore file to avoid uploading binary/unwanted files, if you are aware of their extensions. (For e.g. *.exe, *elf etc.).

Looking forward to your contribution.
Regards,
Pranjal


my device-key changed but the device-id is the same. i did neither reinstall nor logout riot (on my android device). i may only have upgraded it.

reported by @mekeor:asra.gr
https://github.com/matrix-org/riot-android-rageshakes/issues/228

@ylecollen the link is dead. could you correct it? :)

@mekeor:asra.gr : the link is correct but you have no access to this git repository.

@ylecollen why isn't it public? because of security concerns?

@mekeor
Right, because of  security concerns.


Context-Broker not recognizing the mapping of same relationship type to multiple objects using python-ngsild-client

Dear Python-ngsild Developer,
Please, I am having some constraints in properly passing the same relationship type referenced to multiple object via my context broker.
For example:
entyi = Entity("Vehicle", "A456742")
entyi.rel("isParked", ["OffStreetParking:Downtown4", "OffStreetParking:Downtown5", "OffStreetParking:Downtown6"]).
This example successfully creates the mapping of "isParked" to the multiple object types in my python script. However, when I try to create the entity in my context broker (stellio-context-broker) using "client.create(entyi)", it only recognizes the first entity "OffStreetParking:Downtown4" and ignores the rest objects that are supposed to be created. Attached to this complaint is the image of my script and graph representation in Neo4j since stellio is backed by the Neo4j database. I would appreciate your feedback to overcome this obstacle. Thank you.

Dear Miracle,
Fortunately I'm just working on the multiple-attr support.
ETSI specs have changed since I wrote this part of the library.
I've just committed to github.
May be you can try it directly from github : pip install git+https://github.com/Orange-OpenSource/python-ngsild-client
from ngsildclient import *

ctx = [
    "http://example.org/ngsi-ld/latest/commonTerms.jsonld",
    "http://example.org/ngsi-ld/latest/vehicle.jsonld",
    "http://example.org/ngsi-ld/latest/parking.jsonld",
    "https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context-v1.5.jsonld",
]

e = Entity("Vehicle", "A4567", ctx=ctx).prop("brandName", "Mercedes").rel("isParked", ["OffStreetParking:Downtown4", "OffStreetParking:Downtown5", "OffStreetParking:Downtown6"])

That way "object" is not repeated alone but the whole relationship is. Hope it could solve your issue.
You could also pass arrays for metadata.
For example :
e = Entity("Vehicle", "A4567", ctx=ctx).prop("brandName", "Mercedes").rel("isParked", ["OffStreetParking:Downtown4", "OffStreetParking:Downtown5", "OffStreetParking:Downtown6"], datasetid=["source1", "source2", "source3"])
An alternative way is to create a single relationship and then convert to an array.
e = Entity("Vehicle", "A4567", ctx=ctx).prop("brandName", "Mercedes").rel("isParked", "OffStreetParking:Downtown4").rel(Rel.PROVIDED_BY, "Person:Bob", nested=True)
parked = e.arrayify("isParked")
# Update the Python dictionary
parked["object"] = "urn:ngsi-ld:OffStreetParking:Downtown5"
parked["providedBy"]["object"] = "urn:ngsi-ld:Person:Alice"
# Update the entity
e.append("isParked", parked)

Let me know if it's better.
It's still work in progress.
Regards

Dear Fabien,
First of all thank you for the response. Please I want to inform you that the second alternative which you provided worked fine. However, the "datasetid" with "source1, source2, and source3" is not clear to me. I checked the documentation I could not see a detailed description of its use and function. Please can you provide me with some clarification on these concepts.
Secondly, I tried the first approach you suggested, it was able to create the several mapping to the different object with the same relationship. However, when parsing them to the stellio context broker it generated an error as shown in the image attached below. Thank you.

Dear Miracle,
Depending on features, brokers have different implementations of the ETSI specifications.
I tested your code against the Orion broker. It works.
But Stellio complains that there are duplicates.
It happens to work by specifying a distinct datasetId field for each attribute (should be optional according to chapter 4.5.5 - Multiple Attribute Support).
You can try this :
e.rel("isParked", ["OffStreetParking:Downtown4", "OffStreetParking:Downtown5", "OffStreetParking:Downtown4"], datasetid=["datasource4", "datasource5", "datasource6"])

Multiple-Relationship support added in v0.1.10.


How to use multiple where condition using fetch()

Below my code i have a error  can you please solve my issue,
Select.from(SeasonMasterDB.class).where("state LIKE '%" + "inprogress" AND "currentprogress" + "%'").fetch()

You have a syntax error in your code when you concatenate the string. Correct version:
Select.from(SeasonMasterDB.class).where("state LIKE '%" + inprogress" AND " + currentprogress + "%'").fetch()

I also assume you have an incorrect SQL-query.

inprogress and cureentprogress is string its a filter variable , how do i set your query

please help me single column and multiple value


Rename quix to quix-incubator

btw https://trino.io/resources.html#ui and https://prestodb.io/community.html point to the old repo and the link is broken now

btw https://trino.io/resources.html#ui and https://prestodb.io/community.html point to the old repo and the link is broken now

Opened Issues:
https://github.com/trinodb/trino.io/issues/414
https://github.com/prestodb/prestodb.github.io/issues/210


exception with custom composer vendor-dir in 2.7

E.g. in project/composer.json
    "config": {
        "vendor-dir": "lib/vendor"
    },

to install files into project/lib/vendor throws:
phpDocumentor expected to find an autoloader at "<..>/project/lib/vendor/phpdocumentor/phpdocumentor/src/phpDocumentor/../../vendor/autoload.php" but it was not there. Usually this is because the "composer install" command has not been ran yet. If this is not the case, please open an issue at http://github.com/phpDocumentor/phpDocumentor2 detailing what installation method you used, which path is mentioned in this error message and any other relevant information.

It seems that phpDocumentor\Bootstrap::findVendorPath expects composer.json and vendor-folder always to be in the in the same directory, which is not necessarily the case.

This issue remains in v2.8.5. Is there any plan to resolve this? It would appear that after the revert to correct #1451, this issue was left closed and no further activity has been recorded.

Hi there, just wondering if there's been any update to this issue?
I'm still getting this error using v2.9.0:
PHP Fatal error:  Uncaught exception 'RuntimeException' with message 'phpDocumentor expected to find an autoloader at ...
We have a custom location for the vendor dir in the config block of our composer.json file:
"config": {
        "vendor-dir": "app/vendor"
}


Detected Package Downgrade

Operating System
OSX
What's not working?
Nuget Restore on this repo
Commands
cd Microsoft.VisualStudio.Services.Agent/
dotnet restore
Output
/Users/d748115/source/vstsagent/src/Microsoft.VisualStudio.Services.Agent/Microsoft.VisualStudio.Services.Agent.csproj : error NU1605:  Microsoft.VisualStudio.Services.Agent (>= 1.0.0) -> Microsoft.NETCore.App (>= 1.1.2) -> System.Net.Http (>= 4.3.2)
/Users/d748115/source/vstsagent/src/Microsoft.VisualStudio.Services.Agent/Microsoft.VisualStudio.Services.Agent.csproj : error NU1605:  Microsoft.VisualStudio.Services.Agent (>= 1.0.0) -> System.Net.Http (>= 4.3.0)
Restore failed in 27.46 sec for /Users/d748115/source/vstsagent/src/Microsoft.VisualStudio.Services.Agent/Microsoft.VisualStudio.Services.Agent.csproj.```

Ultimately this is just in the way of my exploration into doing a custom build of the VSTS agent for ARM CPU devices, specifically a Raspberry Pi 3. Is it possible to run the agent on a Raspberry Pi 3?

I think you might need netcore 2.0 in order to make ARM works. We are in the process of moving agent from netcore 1.1 to netcore 2.0 right now.
but even we finish the move, you still need some extra work to make it actually working for ARM.
check the following branch for some hint.
https://github.com/Microsoft/vsts-agent/tree/users/edgedevs/v2arm

I know this is closed, but it is the only thread I found talking about ARM / Raspberry Pi... which makes me wonder, how does everybody else automate deployment to ARMv7 / aarch64 machines?


Update code of conduct server link

Code of conduct discord server link to contact anyone is using the old (and abandoned) server.

Fixed by #166


Support cell set / categorical colors in the legend of the scatterplot/spatial views

User story
We currently have legends for quantitative colormaps:

Preferred solution
We could do something like this which we implemented for polyphony

Fixed by https://github.com/vitessce/vitessce/pull/1581


Add BridgelessCatalystInstance as a placeholder for backwards comptability of legacy APIs of CatalystInstance

Summary:
In order to make the legacy APIs of Catalyst Instance backwards compatible, introducing a regular class that implements CatalystInstance so as to make these APIs available for folks in Bridgeless mode as well.
Changelog:
[Internal] internal
Differential Revision: D54093013

64b0c9cba48c6d827d7eafdcc2f5da18cffd1ea6


Missing/incorrect structure info for function named "string"

plugin version: 0.63
Description
The structure info should show string rather that s (the first parameter of string).  This seems specific to this exact function name; a function named string2 works as expected.

Yes, I know why, but I won't fix it.
Better to not use a keyword to name your functions (even if it's possible)

I'm reconsidering it

0.67.2


Stop rendering subcomponent indicator on some specific rows

Hi,
Thank you for this great component, I just wonder if there is a possibility to not render SubComponent indicator on some specific rows or not where i know that don't have any sub row.
My Bests,
Hung Tran

I've figured out a workaround that involves defining a custom expander:
            {
                expander: true,
                Header: () => "",
                width: 65,
                Expander: ({ isExpanded, original, row }) => {
                  if (shouldNotShow) {
                    return null;
                  }
                  return (

                      {isExpanded ? (
                        ⊙
                      ) : (
                        ⊕
                      )}

                  );
                }
              },

The cell still has the rt-expandable class put on it, though, so you still get a pointer-cursor when you hover.

👍


Rename "FYRO Macedonian" in to "Republic of North Macedonia"

Please, rename "FYRO Macedonian" in to "Republic of North Macedonia" in source code of jsPDF localization due to Macedonia changed its name in 2019

Can you prepare a pull request? Thanks.

Hi,
I am trying to raise a PR to the Repo but am not able to push my changes. Getting 403 error. Could you please help out with this?


api: uart: Add configure functions for UART.

Allow UART configuration to be altered during runtime.
This PR is follow up to #10820 it adds configuration part of it.

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@6f98ae3). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master   #11185   +/-   ##
=========================================
  Coverage          ?   53.11%
=========================================
  Files             ?      218
  Lines             ?    26871
  Branches          ?     5952
=========================================
  Hits              ?    14273
  Misses            ?    10163
  Partials          ?     2435

Continue to review full report at Codecov.

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

@qianfan-Zhao , you  might be interested

@Mierunski, ping, any news on docstrings updates?

@galak ping

For those who may miss it, first implementation of these APIs went for review: https://github.com/zephyrproject-rtos/zephyr/pull/11577

@qianfan-Zhao
The current STM32 driver still does not support LINE_CTRL, can you merge your version to support LINE_CTRL?
https://github.com/zephyrproject-rtos/zephyr/blob/794d382bb925d58754bc8377bb6fa7473e1e4832/drivers/serial/uart_stm32.c#L324-L327


Add Non Functional Requirements

Fixes #3

Codecov Report

Merging #11 (53e2f9f) into master (4b78a6b) will not change coverage.
 Consider uploading reports for the commit 9d8d09e to get more accurate results

@@            Coverage Diff            @@
##             master      #11   +/-   ##
=========================================
  Coverage     72.15%   72.15%
  Complexity      399      399
=========================================
  Files            70       70
  Lines          1232     1232
  Branches        125      125
=========================================
  Hits            889      889
  Misses          311      311
  Partials         32       32

Continue to review full report at Codecov.

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


include init_score in predict method

Actually it seems not possible to seamlessy include the init_score  in prediction. It would be nice the predict method to handle an init_score, if given. E.g. I am boosting a model with an apriori predictiction:

using a general model to calculate base predictions in raw scale
#calculating initial raw score base_fraud_raw= lgb_general_model.predict(X, raw_score=True)

then i (re)create train and test sets
#recreating train and test sets X_train, X_tmp, y_train, y_tmp, rw_train, rw_tmp = train_test_split(X, y,base_raw_score, test_size=0.3, stratify=y) X_valid, X_test, y_valid, y_test, rw_valid, rw_test = train_test_split(X_tmp, y_tmp,rw_tmp, test_size=0.5, stratify=y_tmp) del X_tmp,y_tmp,rw_tmp

then I create the lgb Datasets and tune the model
#defining lgb Dataframes(s) lgb_full_categorical_predictors=binarized_predictors_generic+categorical_predictors_generic+binarized_predictors_30+categorical_predictors_30 lgb_train_30 = lgb.Dataset(data=X_train.values, label=y_train.values, feature_name=X_train.columns.tolist(),categorical_feature=lgb_full_categorical_predictors, free_raw_data=False,init_score = rw_train) lgb_valid_30 = lgb.Dataset(data=X_valid.values, label=y_valid.values, reference=lgb_train,feature_name=X_valid.columns.tolist(),categorical_feature=lgb_full_categorical_predictors, free_raw_data=False,init_score = rw_valid) lgb_full_30= lgb.Dataset(data=X.values, label=y.values, reference=lgb_train,feature_name=X.columns.tolist(),categorical_feature=lgb_full_categorical_predictors, free_raw_data=False,init_score = base_raw_score) #tune the models lgb_model_30= lgb.train(params=lgb_general_params,train_set=lgb_train_30,valid_sets=[lgb_valid_30],early_stopping_rounds=10)

then I calculate predictions (using the raw scores)

`
#function to get probabilities from raw
def softmax(x):
"""Compute softmax values for each sets of scores in x."""
e_x = np.exp(x)
out = e_x / (1+ e_x)
return out
#predict using raw score
raw_temp=lgb_model_30.predict(X_test, raw_score=True)+rw_test
proba = softmax(raw_temp)
#caculating performance
my_roc_auc_score= roc_auc_score(y_test,proba)
`
If init_score could have been prodived as supplementary parameter to lgb_model_30.predict method, I wold have avoided the need to know the right transformation (what is in gamma regression, in poison one in box cox ones,...) and to performa the calculation in the probability scale manually.
Is it possible to integrate init_score in the predict method.
This issue is related to #1778 and #1969

How do you integrate the init_score with prediction in regression (gamma, l1, l2) for now?

Closed in favor of being in #2302. We decided to keep all feature requests in one place.
Welcome to contribute this feature! Please re-open this issue (or post a comment if you are not a topic starter) if you are actively working on implementing this feature.


CGA Combinations not handled correctly (imported as skills with no level)

It appears that GGA doesn't handle Combinations (at least when loaded up from a GCA character sheet).  They are listed as skills, but with no skill levels and they also don't appear in Token HUD.
Is there a way to get Combinations recognised and working or do we just need to create a macro to simulate them for now?

Can you attach a zipped up copy of your character?

Please see attached (GCA version and GCA -> FVTT Export.
Alisha Dhovi.zip

Since GCS doesn't support combinations, I'm not sure how GGA would handle them. Even if the exporter was updated to output the skill level, it would have a level like X+Y or X+Y+Z, which likely doesn't fit anyone's model.

The way I'd envisage this working is that GGA currently picks up "combinations" as a line item in skills, but it doesn't resolve the skill level.  If it could parse those lines (which always start with "combination" and produce a header line on the GGA character sheets, and then 2 or 3 child lines that are the related skills (which are in the GCA "combination") that are parsed as normal skills, and roll the 2 or 3 skills when clicking or OTFing the parent "combination" line, then combinations would work in GGA.
So there's not a lot to change in GCA that I can see, if GGA can parse the combination lines and turn them into a special category.  This would add a lot of convenience.
Of course, we can currently write an OTF to call each part of the combo, but it can't be clicked on either the GGA character sheets or from Token Hud.
Ideally, it would also understand that anything in the ADD should be kept sticky for 2 or 3 rolls (otherwise the mods would be lost after the first roll).  Again, it can be done through OTFs and macros, but perhaps it's possible to provide greater integration.  Of course, maybe it's not (or it's not worth the time and effort to do it).

Give me a realistic example of a combo and the "sticky" parts of the ADD, please. That would give me something to think about.

So if you have a combo that is punch/punch or punch/kick/punch it really is the same in terms of what would be good to keep sticky for multiple damage rolls.  That would be the location, any overrides for DR (this is used typically when dealing with layered armour or the GM applying DR on the fly for a mook), any special situation modifiers, and any other manual modifiers that you need to apply to all the hits (because they're hitting the same target and same location).  It would just be nice to do it once.  Also, anything flowing through from the Mod Bucket (extra effort for damage or AoA for damage and so on) although those would be handled in the damage roll before the ADD.  Actually, the Mod Bucket would also be nice to have sticky for combos so the attack rolls all have the same modifiers.
It's about the GM only having to make modifiers once and apply them to all the rolls for damage from the combo.  I don't think there's a way to current do that?  And on the Mod Bucket side, it's for the players (or GM controlling an NPC) to again only have to set the mods once and have them apply to all the rolls to hit for the combo.
Am I explaining that clearly?  Makes sense in my head!

Perfect example. Just FYI, I plan to make (eventually) the ADD options persistent based on attacker token and target token. That is, the options chosen for each unique combination of attacker and target will be used in future Damage rolls by that same combination.
This is based on my experience that the same attack is used over and over by the attacker.

That would be fantastic, @mjeffw !  The other thing that's related is in the Mod Bucket you can't set your "to hit" and "damage" modifiers in the same pass, or they pluses all get applied to the first roll you make.  It would be great if skill checks pulled non-damage mods from the bucket and damage rolls pulled damage mods, so you could set it all up at once (manually or with a macro) and then it would apply appropriately (either persistently when sticky/magnet, or "one and done" otherwise).  And finally, if hit location selected in Mod Bucket made it through to the ADD that would also be great.  Combine that with your attacker/target persistence and I think the whole thing becomes really seamless and fast.
As always, thanks so much for all the work on this!


Master to Live

Docs Build status updates of commit 3bf7537:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

.openpublishing.redirection.json
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


List supported properties/functionality in README file

Does this plugin only support indentation (in both view and edit mode)?
If so indent_style/indent_size (and possibly tab_width) should be listed as supported in the README file (similar to the way the other plugins list support).

Nope, it supports all the properties except as for charset and end_of_line which are controlled by Github anyway.


100% CPU usage in windows with node

Please tell us about your environment:

Angular version: 2.0.0-rc.4
Browser: [ Chrome ]
-OS : Windows

Problem:
I am using this project as baseline to setup a new project. After starting the node using webpack dev server , CPU usage in my windows machine is going to 100%. I have 16GB RAM. Has anyone faced this issue and know the solution?

I've noticed the same thing. I didn't dig deeper, but the CPU usage did drop immediately as soon as a shut down node and Chrome.
Were you using HMR by any chance? I was...

@Martaver - Nope I am not using the HMR. I am using npm run server:dev which is actually "webpack-dev-server --config config/webpack.dev.js --inline --progress --profile --colors --watch --display-error-details --display-cached --content-base src/" . I am sure this is because of web pack dev server running on node but not sure what is the solution for this.

I found out that it was happening because of webpack dev server watchOptions. If you increase the poll time then CPU usage goes down.

For anyone who finds themselves here in 2019, https://github.com/JeffreyWay/laravel-mix/issues/1418. This worked for me although I'm not using Angular.


NUL characters at end of nlcg.out file

I noticed that in some cases, the nlcg.out file has lots of NUL characters at the end of the file
example copied from a running calculation

Thanks! I haven't seen this before, also not for running calculations. The file is written using the stdlib (iostream). Is there anything special about the system you are running the calcuations?
Could you please send also the stdout of the calucation and the input files if you have them at hand? There seems some other problem too: the calculation is stopped at a high residual, because no descent direction could be found anymore.

Cheers, will send you via email.

the calculation is stopped at a high residual

When you say "stopped" you mean it stopped and then continued?
At least the overall QE calculation is still running.

Thank you for the files. The nlcg did not converge to the desired accuracy.  It seems there is a bug in sirius for vc-relax, it should abort in case a single ionic step didn't converge, sicne scf_must_converge defaults to true. I'll check this and let you know when it is fixed.

Great, thanks! That does indeed sound like a rather important fix ;-)
Will apply it as soon it's available.
In general, since @mbercx and me are now playing around with this: are there any default settings that we may want to change?
I.e. may it even make sense to set scf_must_converge to false?
Our final goal is to have a vc-relax that is as stable as possible, while being no more expensive than necessary.
On the AiiDA level, I assume that we may want to start with the default relaxation workflow and switch to direct minimization once we realize that the scf does not converge with the standard approach ('plain' diagonalization with Broyden charge-density mixing).


string collection refactor

about to break stuff.
placeholder for issues created.

case-conversion renames complete.

dupes of trim, trim-right, trim-left, trim-new-lines, pad-right, pad-left, clipLeft, etc. need to resolve and purge.

most dupes resolved.
need to remove relocate some files, rename others, start tests

tests started.

approx 20 more tests to go. whew!

getting everything to 100% coverage. think all test are done though.

on hold at the moment.

done internally.


Post-merge block reward amounts incorrect

Since the Paris upgrade, the 2 ETH block reward is gone and the only reward validators get is the miner tips from 1559.
You just need to remove the 2 ETH constant value and subtract the burnt fees from the total fees.
Etherscan vs otterscan screenshots for reference.

Hey, sorry for the delay, was at devcon.
I've noticed that too, I should take a look at it next week after I cut next release.

This issue stems from Otterscan fetching block rewards from the PoW ethash AccumulateRewards consensus function in Erigon.
Here's a PR into ots2-alpha4 that solves the problem by checking for the merge into PoS in the same way as the trace filter API, which also calculates block rewards: https://github.com/ledgerwatch/erigon/pull/9113

Should be fixed in Erigon >= 2.60 (to be released soon) or in the current Erigondevel branch.


Write educational content

If there is any subject that you have expert knowledge on and would be a good fit for the Revoke.cash Learn section, please contribute it. I recommend checking in here first to see if we agree that the topic matches with what we'd like to see.
I recommend only contributing educational content if it is about a topic that you already have good knowledge of so that the content is of the highest possible quality.

hey! @rkalis , i have a few topics that overlap with RevokeCash's ideologies
1)Evolution of token approvals and risks/traps associated(like airdrop taps,token sales)
2)Best practices for wallet security(from intermediate to advanced security-using hardware wallets,multisig wallet)

Hey @hoysal08 and @tanyas-codes, thanks for your interest!
I think the best articles are very simple and clear, so as you mentioned @hoysal08 "Hot Wallets vs Cold Wallets" would be a great topic, but perhaps "How to Keep Your Wallet Safe" is a bit too broad, since there is a lot of different things to discuss there.
@tanyas-codes I think your topics sound good, but also as I said above, it's probably good to keep them very focused on 1 topic at a time, like maybe pick 1 specific type of scam or 1 specific best practice that you want to write about. For example, the "Three Address Protocol" (https://twitter.com/punk6529/status/1701623475725533524) could be one of those best practices, or one of the best practices that you mentioned.

thanks, @rkalis for the feedback. I will get started on the"Hot Wallets vs Cold Wallets" article.
By "How to Keep Your Wallet Safe", What i means was while interacting with any application on chain, what are things the do's and don'ts. Let me what you think of this.


[Announcement] Removal of outdated pre-release wheels from PyPI

Currently, we are distributing CuPy binary packages (cupy-cudaXXX wheels) via PyPI. As the size of CuPy wheels is relatively large compared to other packages, we are starting to occupy a non-negligible space quantity of PyPI storage.
To help keep the PyPI ecosystem healthy, we are now planning to remove wheels of outdated pre-releases (alpha/beta/release candidate) from PyPI. This does not affect users relying on wheels of stable versions.
Pre-release wheels of v6.0.0rc1 or earlier will be removed from PyPI on 2021-01-28. Removed wheels are re-published to the Assets section of each release on GitHub so they can be manually downloaded and installed. For example, if you need cupy-cuda101 v6.0.0rc1:
pip install --pre cupy-cuda101 -f https://github.com/cupy/cupy/releases/v6.0.0rc1

I've synchronized pre-release wheels on PyPI to GitHub releases (FYI, tool here). Updated the issue description.

Done. Freed up approx. 58 GB space on PyPI 😃

Done. Freed up approx. 58 GB space on PyPI 😃


If the server in the paper server starts the fake mining, the structure block will not be obtained

If the server in the paper server starts the fake mining, the structure block will not be obtained

dafuq are you talking about?


Colors needs triming before parsing

Why does the theme have whitespace around the color? Can you point to the problematic theme?

Don't remember the exact theme I was using at the point, probably toner-v2
https://cloud.maptiler.com/maps/toner-v2/


[FLINK-4361] Introduce Flink's own future abstraction

Flink's future abstraction whose API is similar to Java 8's CompletableFuture.
That's in order to ease a future transition to this class once we ditch Java 7.
At the moment, the current future implementation is backed by Scala's futures.
The current set of operations comprises:

isDone to check the completion of the future
get/getNow to obtain the future's value
cancel to cancel the future (best effort basis)
thenApplyAsync to transform the future's value into another value
thenAcceptAsync to register a callback for a successful completion of the future
exceptionallyAsync to register a callback for an exception completion of the future
thenComposeAsync to transform the future's value and flatten the returned future
handleAsync to register a callback which is called either with the regular result
or the exceptional result

Additionally, Flink offers a CompletableFuture which can be completed with a regular
value or an exception:

complete/completeExceptionally

Thanks for your review @KurtYoung. Will address your comments.

The naming is not super nice, I agree. But there is a clear benefit for Java 8 familiar people to stick with something established.
+1 for this from my side.
Next time we get involved in the Java community processes, to make sure they have better names ;-)

Thanks for the review @KurtYoung, @mxm and @StephanEwen. I will merge this PR to the flip-6 branch.


Change puzzle uniqueness to include both the title and the URL

Right now, if you make a puzzle with the same URL as a previous puzzle, we get an error from the DB. In case Galactic does something crazy that requires us solve a puzzle on the exact same page again, we want to be able to create a separate Smallboard entry for the later versions.

I wonder if the potential benefits of relaxing this are worth the drawbacks of getting duplicate puzzles. What do you think? If need be we could always add blank anchors or query parameters to the puzzle url to get around the uniqueness check right now.

I wonder if the potential benefits of relaxing this are worth the drawbacks of getting duplicate puzzles. What do you think? If need be we could always add blank anchors or query parameters to the puzzle url to get around the uniqueness check right now.

Per our discussion offline, there are workarounds (adding # to the end of URLs, etc)

Per our discussion offline, there are workarounds (adding # to the end of URLs, etc)


How does cartographer fuse imu with laser scan?

is it use imu to improve the initial guess for the optimization problem?

If you have already created a pbstream map, you can set the initial position by modifying the code.
http://www.4k8k.xyz/article/qq_40234479/115293873?fbclid=IwAR0lSMDBWFxOu7zj8Nl-Q3IDGBOZbnmE4yk7Gr6Bv6SO3ev1Co_CZBEpQqg


[DNM]*: remove async batch snap

What have you changed? (mandatory)
The PR removes async batch snapshot API, it's complicate and the local reader is able to do the same thing in an elegant way.
What are the type of the changes? (mandatory)

Improvement (non-breaking change which is an improvement to an existing feature)

How has this PR been tested? (mandatory)
Unit tests.
Does this PR affect documentation (docs/docs-cn) update? (mandatory)
No.
Does this PR affect tidb-ansible update? (mandatory)
No.
Refer to a related PR or issue link (optional)
#2107 and #3551
Benchmark result if necessary (optional)
TBD.

Why mark as DNM?

It is based on https://github.com/tikv/tikv/pull/3551 which is not meged yet.

PTAL, thanks!


Register Mod's Entities, Items, Blocks for Jobs

How could I add them to the available jobs in game?
I was trying to add mod's custom entities to hunter.yml but it's not worked !

You have default jobs with some examples and preset for entities, blocks or items. You can use that as basis for your own needs.


Target both .NET5 and .NET6

Issue #53
I cloned the repo, updated a couple NuGet packages and Targeted both .NET5 and .NET6

Ok, I made the change and committed it to my branch.
How do I put this change into the "pull request"?
Sorry, I'm fairly new to contributing to other projects.

Hi @tforsberg it seems you already figured it out 😉 just pushing your changes will make them show up here too.
PR looks good, thank you for your contribution!


Set the peer as warm before monitoring

The peer status must be set to PeerWarm before we start the monitoring
thread.
Previously we started the monitoring thread first which meant that it
was possible for the monitor thread to notice an error and set the peer
status to PeerCold only to have it overwritten with PeerWarm. This
caused peers to get stuck in warm/hot without a corresponding
connection.

It looks good, just please squash the review commit.

p2p-governor test failure

bors r+


Extended to include all parameters and support ChirpStack

I needed a version for my ChirpStack server and thought it might be useful to others.
Although I originally created a separate ChirpStack decoder file I have now merged it back into the original and added a wrapper function to translate Decode(port, bytes) into Decode(bytes, port) so now the same decoder will work on both platforms without modification.
To avoid confusion I removed "ttn" from the name of the file since it is now not strictly relevant. Please feel free to reinstate it if that causes problems.
I've extended support to include all the parameters in the current spec (including acceleration) and kept to the same style so that unwanted parameters can simply be commented out or deleted as required.
I've also included a hex dump of the payload for diagnostic/debugging purposes which again can (and probably should) be deleted for production use.
Still learning GitHub so apologies if I'm breaking protocols or treading on toes.

This is great work, thank you!


.NET 4.0

Can Jil target .NET 4.0?

+1 and .NET 3.5?

+1
I looked for code and found, that main issues only with reflection methods (can be rewrited) and AggressiveInlining attribute.

Yep, that's why I'm asking
I'll try measure performance impact of these changes and will inform about results asap

I've done some minimal benchmarking. Seems performance was not seriously affecter by removing 'AggressiveInlining' MethodImpl options. However, it should be retested more carefully (if author will approve migration/fork to .NET4).

Per https://github.com/kevin-montrose/Jil/pull/198 ; not at this time, but will revisit once core-clr settles down.


(config): improve VS Code workspace configuration for formatting and linting

-Set Prettier as the default formatter for all supported file types (typescript, javascript, json, svg, etc.).
-Enabled formatOnSave for seamless code formatting.
-Disabled built-in formatters for html and json to avoid conflicts with Prettier.
-Configured TypeScript settings to use non-relative imports and single quotes for consistency.
-Improved ESLint integration: -Enabled source.fixAll.eslint on save to automatically fix linting issues.
Defined working directories for monorepo structure (apps/, libs/, etc.).
Set the package manager to Yarn for compatibility with project tooling.
-Added comments and grouped related settings for better readability and maintenance.

🟡 Heimdall Review Status

Requirement
Status
More Info

Reviews

🟡
0/1

Denominator calculation

Show calculation

1 if user is bot
0

1 if user is external
0

From .codeflow.yml

1

Additional review requirements

Show calculation

Max
0

0

From CODEOWNERS

0

Global minimum
0

Max

1

1

1 if commit is unverified
0

Sum
1

@SIR-DG
Thank you! Please see comment here on why we will forgo these changes at this time 🙏


Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 76.07%. Comparing base (6ea4370) to head (0a4595e).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3339      +/-   ##
==========================================
- Coverage   78.98%   76.07%   -2.92%
==========================================
  Files          88       88
  Lines        3403     2897     -506
==========================================
- Hits         2688     2204     -484
+ Misses        641      612      -29
- Partials       74       81       +7

Flag
Coverage Δ

Linux
?

Windows
?

macOS
76.07% <100.00%> (ø)

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


got frustrated about no claim id on channels and went wild

@seanyesmunt @tzarebczan wanted total publishes displayed and this was an easy place to put it
I'm in favor of putting this somewhere else when there's time to be more thoughtful about it though

I think it makes sense to put it there, at least for now. Checking it out


Fix false positives for symbols in regexp/prefer-quantifier rule

Pull Request Test Coverage Report for Build 606021176

13 of 13 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.04%) to 98.025%

Totals

Change from base Build 605909360:
0.04%

Covered Lines:
643

Relevant Lines:
650

💛  - Coveralls