Discussion: should we deprecate the old proxy event syntax?

This follows on from the discussion on #1146 - see in particular feedback from @thomsbg (https://github.com/ractivejs/ractive/pull/1146#issuecomment-53526330) and @unity (https://github.com/ractivejs/ractive/pull/1146#issuecomment-54030188).
As of 0.5.6, we have two ways of dealing with events:
Direct method call (new style)
<button on-click='set("selected",foo)'>select foo</button>

Triggering a proxy event, and handling it separately (old style)
<button on-click='select:{{foo}}'>select foo</button>

ractive.on( 'select', function ( event, selected ) {
  this.set( 'selected', selected );
});

These two are functionally identical, but semantically very different - the new syntax is far more concise and convenient, but introduces a coupling (between the event and the action) that wasn't there previously. For example, if you were using a Flux-style architecture, you wouldn't want to set() data directly.
Option 1: deprecate
If we did deprecate the old syntax entirely, you can still maintain that decoupling:
<!-- this... -->
<button on-click='fire("select",event,foo)'>select foo</button>

<!-- is identical to this: -->
<button on-click='select:{{foo}}'>select foo</button>

You can also call custom methods so that you're not blindly setting data, but calling the same API that you'd call programmatically:
var TodoList = Ractive.extend({
  add: function ( description ) {
    // any validation etc goes here...
    this.push( 'todos', { done: false, description: description });
  }
});

Pros:

eliminates code from the codebase - makes it slimmer, more maintainable
reduces the amount of stuff newcomers have to learn
removes potential confusion
we don't lose any expressive power

Cons:

on-click='fire("select",event,foo)' is more verbose than on-click='select:{{foo}}'
'Proxy events' (i.e. 'click means select') are second-class citizens - some people prefer the proxy event style

Option 2: Keep both syntaxes
Pros:

Keeps existing users happy, means no breaking changes down the line
Keeps proxy events as first-class citizens

Cons:

Codebase size and maintainability
Potentially confusing for newcomers

Option 3: Keep old syntax, but disallow arguments
One idea we briefly tossed around was keeping on-click='foo' as a short version of on-click='fire("foo",event)', but disallowing additional arguments. This alleviates the problem of situations like
<widget on-foo='bar:{{these}},{{are}},{{ignored}}'>...</widget>

In that example, the bar handler receives the original foo event's arguments - the additional arguments are ignored. We don't have a particularly good way around this. Disallowing arguments masks this problem rather than solving it, but maybe there's some value in it.
Pros/Cons:

Erm... not quite sure

Option 4: Modify old syntax
If you think about it, the curly braces are fairly redundant. For data-binding, they serve as delimiters - it says...
{{ <!-- references to the viewmodel are allowed in here --> }}

...but with method calls, the directive itself serves that purpose:
<button on-click='doSomething( /* references are allowed in here */ )'>click me</button>

We could apply the same logic universally and just do away with the curlies...
<button on-click='select:foo'>select foo</button>

...though for the sake of avoiding total confusion, it'd probably be better to go with something different, such as...
<button on-click='select[foo]'>select foo</button>

<!-- If there we no arguments, syntax would be as currently is: -->
<button on-click='select'>select</button>

...which I personally find rather appealing. It gives us the opportunity to reverse an earlier mistake (whereby anything that couldn't be parsed was simply treated as a string - so select:xyz meant the same as select:"xyz" - bad API decisions are often made in the name of being 'forgiving' and 'flexible'. Mea culpa), and works equally well for decorators and transitions.
Pros:

The 'array syntax' (let's call it that) is more compact than existing syntax
Easy to parse using same mechanisms as method calls, so still gives us opportunities for code removal
The arguments look like valid JavaScript! (Because they are)
We don't need to do any data-binding - there's actually a small performance win with this approach (values only need to be got when the event actually happens), less state to manage and observe
Proxy events are still first-class
Adapts to decorators and transitions

Cons:

Still involves two separate concepts for newcomers to learn
Will be a breaking change when support for existing syntax is finally turned off

So: would love to know what everyone thinks. Options 1 and 4 are my personal favourites, but your needs may well differ from mine. One thing I will say - I don't think we should worry about deprecating things. Ractive is still relatively young, and it's better that we take opportunities to get things right rather than trying to prevent the pain of updating existing templates. Deprecations can be well signposted with appropriate console warnings etc.
Thanks everyone.

It'd be nice if it was more clear in the docs that : has a special meaning in event names. I was bashing my head at why trigger:open was only showing up as trigger.

The new proxy event syntax is disappointingly similar to the native "on" attributes of yesteryear that I also find "repulsive" (re: the thread from a bit ago). I fail to see how this is a step forward and also how this "new" syntax can be considered "proxy events".
The "old" version was a very elegant and flexible solution to a common problem (and, in fact, was one of the things I liked so much about Ractive). For these reasons I humbly request that the syntax is not deprecated entirely, at least.

@jarofghosts Agreed on both points. The fire() syntax is unnecessarily messy and obscures the function being called. The only thing I'd change is that the mustaching in the call seems unnecessary. That is:
<button on-click="select: {{ something }}">

should just be:
<button on-click="select: something">

There are no other "vars" / properties to reference here.
@Rich-Harris

the new syntax is far more concise and convenient

Nope.

Oh, I see that that my suggestion was option 4. I really should read things.

The other thing I could see doing is making an event reference optional. I think newbies would find this MUCH more comfortable:
<button on-click="select(something)">

Need the event passed? No worries, make a locally scoped variable e available for function calls.
<button on-click="select(e, something)">

Now it looks like everything a JavaScript developer is used to. And it should directly call functions within the ractive, rather than having to set ractive.on("select") The listener pattern doesn't really make sense (unless these events bubble through components, which may be the case - I'm not yet a Ractive expert).

unless these events bubble through components

Yep, that's the main reason to use events vs methods.
Given the introduction of this.event, I'd say there's even less of reason to need event arguments.
So after almost a year, I have to say I now think Option 3 is the way to go. Use methods but allow the simple event synax: on-click='foo' as a short version of on-click='fire("foo",event)'

I'd say there's even less of reason to need event arguments.

Wait, what? I use event arguments all the time. How does this.event solve that?

I think he meant the event argument, not general event args.

I misread both the previous, apparently...
I'm for option 3 still too. Having this.event makes manually passing the special named event argument less painful because if you need it, it's just a context property away. It makes the transition from foo:{{var1}},{{var2}} to a method call a lot bit if you don't mind having event only methods on your instance (foo(var1, var2)). Literals are also a bit confusing in for args in the proxy syntax.
I also think fire should automatically propagate the event if it's called as a method event handler and there isn't an event argument in the appropriate position.

This issue is something I'd like to see a resolution to before the 0.8
release, one way or another.
After a year of working with ractive in a large application, I vote for any
option that has a unified and consistent syntax between event handlers,
decorators, and any other specially handled attribute. .
As much as possible, I'd like to limit the number of different syntaxes and
concepts in templates. Have an opinion and stick to it. If it means that
certain paradigms like proxying events become more verbose, than so be it.
At first, I thought the event proxying syntax was elegant and one thing
that made ractive different than other libraries (in a good way). But in
practice, I have made little use of event proxying.
90% of event handlers relate to behavior local to the component, so making
the 10% case more verbose is fine with me.
IMO, we should promote isolation between components over sharing data and
bubbled events. While useful tools, those concepts lead to messy code in
larger applications in my experience.
On Sat, Aug 29, 2015 at 8:43 PM Chris Reeves<EMAIL_ADDRESS>wrote:

I misread both the previous, apparently...
I'm for option 3 still too. Having this.event makes manually passing the
special named event argument less painful because if you need it, it's just
a context property away. It makes the transition from
foo:{{var1}},{{var2}} to a method call a lot bit if you don't mind having
event only methods on your instance (foo(var1, var2)). Literals are also
a bit confusing in for args in the proxy syntax.
I also think fire should automatically propagate the event if it's called
as a method event handler and there isn't an event argument in the
appropriate position.
—
Reply to this email directly or view it on GitHub
https://github.com/ractivejs/ractive/issues/1172#issuecomment-136066639.

A few quick thoughts:

Completely agree with @thomsbg that a unified syntax makes sense. The status quo (multiple ways of doing the same thing) is needlessly confusing
From an implementation perspective – and I'm particularly sensitive to this after re-implementing it for #2022 – the current situation is crazy. There's a lot of code that just doesn't need to exist
Again with my implementer's hat on, using curlies inside directives (select:{{foo}},{{bar}}) is infuriating. The reasons are historical – at the (very early) time proxy events were introduced, Ractive didn't have an expression parser, so using the data binding machinery made sense. But it's a hell of a lot easier if you bookend everything after the colon with [,] and run it through the expression parser – you get a function that (given the current values of foo and bar) simply returns the parameters
Aesthetically, we're much better off without the curlies (e.g. intro='fade:{delay:i*50}' instead of the unreadable gubbins that happens when you mix object literals with mustache syntax)
The method call syntax is the most flexible, and in my experience produces by far the most readable code (all the custom methods live in a single, obvious place, and a lot of the time you're calling built-in methods anyway! It's much more compact). When I need events to bubble, I find myself using on-tap='fire("select",id)' over select:{{id}} – it looks like regular JavaScript rather than some wacky DSL, and there's no weirdness about the event object being unshifted onto the list of arguments. (By the way, bubbling works fine in this scenario – http://jsfiddle.net/rich_harris/fvqew14a/)
As a minor aside, components with custom methods work much better from a composition/inheritance perspective than components that depend on a lot of this.on({...}) set-up work.

I know that not everyone feels the same way about the proxy event syntax, but I'd implore you to try and look at it from the perspective of someone new to Ractive. They can either use a familiar function call syntax, or learn a (let's face it, fairly weird) Ractive-specific way of doing things.
So in summary my inclination is basically option 1 – move over to the method-call syntax, and (gradually – probably not as part of 0.8) deprecate the old way.
While I'm here
The one place where I'm continually frustrated with Ractive's event handling is with components:
<!-- this is impossible... -->
<TodoList on-createTodo='persist(id,newTodo)'/>

We don't have a way to use the event arguments in the component's directive, which makes effective composition really difficult. It occurs to me that we could do something like this:
<!-- supposing the `createTodo` event is fired with `id` and `newTodo` arguments -->
<TodoList on-createTodo='persist($1,$2)'/>

<!-- or if it's just fired with the `newTodo` argument -->
<TodoList on-createTodo='persist($1.id,$1)'/>

In other words, arguments like $1 and $2 are understood to have special values, the same way an event argument is replaced with this.event when the method is called.

I'd implore you to try and look at it from the perspective of someone new to Ractive

That's a good point; the colon / curly brace syntax of firing events took a bit to get used to. And direct method calls would be great for situations like:
<input type="checkbox" twoway="false" checked="{{ something < 2 }}" on-change="set(this.keypath, this.value ? 2: 0)" />

Or however that's written, but some way to deal with simple binding variations or type casting. (Incidentally, is that possible currently?)

@matthew-dean you can do this sort of thing:
on-change="set('isChecked', event.node.checked ? 'yep' : 'nope')"

http://jsfiddle.net/rich_harris/4vqqca5h/

@Rich-Harris Nice!!  ** Hurries to immediately implement **

Totally agree with all of those thoughts @Rich-Harris.
I like the thought behind $1 and $2 arguments. It's not particularly pretty, but gets the job done. I wonder if would be useful to support $@ as the events arguments as an array. That combined with an ES6 style spread operator allows you to pass on all the arguments, without having to know how many there are.
<todo-list on-newTodo="save(...$@)">

I usually turn my nose up at such perl-isms, maybe there's a more natural syntax.

@thomsbg I like the thinking – what about on-newTodo="save(...arguments)"? That's valid and idiomatic ES6.

Yeah totally. Seems obvious now :)
On Sun, Aug 30, 2015 at 12:51 PM Rich Harris<EMAIL_ADDRESS>wrote:

@thomsbg https://github.com/thomsbg I like the thinking – what about
on-newTodo="save(...arguments)"? That's valid and idiomatic ES6.
—
Reply to this email directly or view it on GitHub
https://github.com/ractivejs/ractive/issues/1172#issuecomment-136159638.

I should mention, for anyone pulling a O_o face at the $1,$2 suggestion, that it is based on an existing JS convention :-)
( 'this is a test string' ).replace( /this is a (\w+) (\w+)/, '$1 $2 $1 $2' );
// -> 'test string test string'

I've written lots of boiler-plate code in last couple of months due to not having full component events args, so it's high on my priority list. I like the ...arguments. Do we just stick with arguments[0], arguments[1] for individual access?

I'd go with option 3. I use proxy events a lot (I like the separation of code (JS) and presentation (template)) and the eábillity to register multiple listeners on the same event. But I never ever use them with custom arguments.
It's just like you would use custom events in other libs (e.g. jQuery) most of the time and I find them really straightforward to use.

@Rich-Harris Only after you commented on #2176 did I realize I was actually working with "new syntax" and "old syntax" simultaneously. No wonder I was confused. I thought all 3 function calls were slightly different with different use cases. I didn't really grok that one was replacing another.
I guess I use a mix of old and new, after learning I could do some of the "new". Passing arguments is easier with "new". Writing a bunch of methods to trigger is easier with "old" because I consider ractive.on a much cleaner and intuitive approach. That is, I would prefer to "define" using "old syntax" and "call" using new syntax. Either that or have an "on" property in the initial ractive instance definition (looks like that was mentioned by @martypdx).
One other thought, I think some of the visceral negative reaction to doing the smart thing and replacing "on-click" with "onclick" and calling methods directly, as it's "similar to yesteryear" is more about the reaction then then this suggestion now. The reaction against all that, and the cry for people to "separation content from presentation and content from behavior" was, on the one hand, a good idea for the maturity for the web platform, but in many, many cases, we threw the baby out with the bath water. There are plenty of times when specifying what update is going to take place or what's going to be fired as a result of the click is best in the template, just like sometimes it makes sense and is more maintainable to add inline styles. So, we're saying it's bad now, because it looks like then, and we said it was bad then, so it must be bad. But a lot of the reasoning for why it was "bad" was flawed at the time. It's actually less inutitive for newbies why Ractive insists that firing something on a click should be defined with "on-click" instead of "onclick". It's one of those places where people who know the internals of Ractive say, "Yeah, but they're different", to which I say that a newbie to Ractive cannot tell the difference.  So, for newbies, it's an arbitrary new syntax, even though it seems like it's doing the same thing: e.g. firing a method as a result of an interaction. And then later, when you learn that Ractive parses those elements and outputs something different anyway, the distinction between "on-click" and "onclick" actually feels more confusing and arbitrary.
So my suggestion: instead of avoiding what's familiar, build on what's familiar to web developers, and just make the behavior and result transparently better. Use what people know. Don't put up barriers to adoption because you have an aversion to an early stage of web development.
This is why syntaxes like Less and TypeScript (and the later syntax of Sass: SCSS) have flourished. They start with what people already know and use, and build on that knowledge in familiar ways.
Final thought: I think some of the reason there's repeated "inline" methods needed is that components are difficult to use, but that's probably a separate issue.

Before deprecating anything, documentation and tutorials on ractive.org need to be updated.
The tutorials don't mention direct method call in events at all. At least they don't in the events section, where proxy events are the only type of event handling being taught.
Second, I've been search for more than an hour to find how so achive this:  on-click="toggle(@keypath+'.exclude')". I've not found a single example, which shows how to set a keypath in a direkt method call event handler, which is not a root key, not even in the discussion right here. All examples are too simplified to handle this, and at least to me the solution was not straight forward.
For proxy events this is show in many examples and as @matthew-dean mentioned above it's pretty familiar for developers coming from jQuery for example, at least without the event:{{prameter}} extra parameter syntax.

I came across this issue while looking to see if somebody else had reported https://github.com/ractivejs/ractive/issues/2303 already.
I've been using events lately as a way to set up observables and do FRP stream things.  I like events because I can write a template for a component, and then have generalized functions that I can use to compose things into streams.
For example, in my template I might do something like on-change="user-did-thing-that-requires-server-interaction:thing,{{someObjectInScope}}".
In my code, say in my complete function, I can do something like makeABaconJsStream(this, 'user-did-thing-that-requires-server-interaction').map(someOtherFunction).map(etc).
I can't replace this with function calls without changing my paradigm around quite a bit.
I value being able to pass a Ractive object to functions that can watch for certain events without them having to be concerned with anything but the events that will be emitted, and what the arguments will be.

My brain completely skipped over the fire usage somehow - after Rich enlightened me in https://github.com/ractivejs/ractive/issues/2303#issuecomment-162256308 I think I'm good to go with option 1.
I would suggest that using
on-change="user-did-thing-that-requires-server-interaction:thing,{{someObjectInScope}}"

should produce the warning

event proxies are deprecated.  Replace with on-click="fire('user-did-thing-that-requires-server-interaction','thing',objectOnScope)"`

for maximum copy/paste handiness.
I am curious how long you would leave the warning in before removing the deprecated functionality?

Historically we've been pretty slow to remove deprecation warnings. If we got this into 0.8* it certainly wouldn't be removed before 0.9.
*getting it into 0.8 would consist of converting old-style event directives to new-style method calls at parse time. AFAICT the only cases where that would be impossible (or at least too difficult to bother with), i.e. a breaking change rather than a nuisance warning, is if you had sections in the directive, e.g. on-click='foo:{{#each list}}{{this}}{{/each}}'. Which I'd have thought was a pretty rare case

I've been looking at parsing for directives, mostly for decorators, but the comment in processDirective is not far off when it says 'shocking'. Between this issue, issues regarding the location of event handling functions, unification of syntax, and state support, I have yet another proposal to throw out.
Cases
It seems that there are two flavors of directive parameters to accommodate: static naming and dynamic naming, both with optional arguments. For events, dynamic naming could be punted to the method flavo(u)r using fire, but that doesn't really work for decorators and transitions. So, I'll say that leaves both cases fully intact.
Considerations
Method-style events, while much more convenient for arg-passing, have been the source of a fair amount of confusion regarding what exactly they can and will call. Some people expect them to bind like normal mustaches and call methods in the current context. They also look like a regular method call, so there is the temptation try to do things like <a on-click="do.something(withParam).andThenCallMe()">, which is not really unreasonable and is entirely unsupported.
There's also parsing to consider. There is currently a bunch of funky special-cased logic in directive parsing that bends over backwards to parse stuff out of a string that has already been parsed as a plain text attribute value. I intend to address that with #2369, should that be accepted. While doing the refactor though, I'm going to have to keep a lot of nuanced code around to handle legacy/deprecated cases.
Starting with 0.8, we will have a handy new special ref available that lets you get at Ractive instance methods as @ractive.${method}. @martypdx has opened #2345, which takes the special refs a step further and allows then ractive. portion to be left off, as long as what follows is not one of the reserved special refs.
Finally, I think Ractive is almost to the point of being feature complete for a 1.0 release. This is one of the last big things on my list to get resolved before moving to get a 1.0 with longer-lived support out there. As it stands now, there has been so much churn between most releases that backporting fixes is nigh impossible without more bodies. I think that starting with 0.8 and its model refactor that there's not really another giant (practically) rewrite to be done. Also, the code has evolved into a structure that is easier to follow, which will hopefully be more attractive to contributors. Segue aside, I think it's time to knock out the breaking changes and get a final syntax out.
Proposal
Given those cases and considerations, I would like to propose the we move entirely to two flavo(u)s of method-call syntax to handle events.
The first is a rework of static-naming that is currently handled by the existing method-call syntax. Instead of limiting this to a method on the Ractive instance, I propose that we make this a plain old expression and resolve and execute it when the triggering event fires. This would open event handling up to more styles programming with regards to data. For those like rich (fat) objects in their data, they could call methods on their models e.g. {{#each users}}<a on-click=".disable()">Disable User</a>{{/each}}. For those who like data-only models, they can call methods on their Ractive instance or even globals e.g. <a on-click="@ractive.disableUser(.)"> (with #2345 <a on-click="@disableUser(.)">) or <a on-click="@global.disableUser(.)">. Since they're just expressions, this would also open up chained calls as mentioned above e.g. <a on-click=".getHelper().doSomething(@keypath, 'some string')">. Also, I just wanted to throw this out because moving an item in a list is currently more code than I think it should be: <a on-click="@push('items', @splice('items', @index, 1).result[0])">, where I've added a result property
to Ractive.splice's returned Promise to avoid the asynchrony-for-transitions issue here.
Extra note for method-call events: they currently support passing args through via $ params, and that would continue to be the case. In fact, I would add support for using $ refs with the usual resolution process here (only for events) a la #2311.
The second, for dynamic names, is basically a variation of the existing proxy/decorator/transition syntax mangled slightly to make it easier to parse (both programmatically and in my head). For events, this would always fire the event name with the event object supplied, as currently done by proxy events, followed by any args. The construct looks like this pseudo-BNF: SIGIL(MUSTACHE|NAME)['('{ EXPRESSION, ',' }')']. The SIGIL can be any character that makes sense. I propose # and perhaps even to make it configurable so that things that stand out more like 🔥(fire) could be used, perhaps as a list so that decorators and transitions could stand out too like 🎍(misc decoration) and 🏇(horse racing). The following MUSTACHE|NAME means that you can use a relaxed name for the event or you can resolve a string using a mustache. That is then followed by an optional args list in a regular function-callish form surrounded by parens. Here are the results of some of the various proxy scenarios (wrap each scenario in <a on-click=${scenario}> and feel free to swap # with 🔥, because unicode):

Current
New

"proxied"
#proxied"

"{{ foo ? foo.name : 'bar' }}"
"#{{ foo ? foo.name : 'bar' }}"

"proxied: stringArg"
#proxied('stringArg')

"proxied: {{ notStringArg }}"
#proxied(notStringArg)

"proxied: {{ 'stringArg' }}, {{ { some: { obj: 'settings' } } }}"
"#proxied('stringArg', { some: { obj: 'settings' } })"

"{{ foo ? foo.name : 'bar' }}: stringArg"
#{{ foo ? foo.name : 'bar' }}('stringArg')

"{{ foo ? foo.name : 'bar' }}: {{ notStringArg }}"
#{{ foo ? foo.name : 'bar' }}(notStringArg)

"{{ foo ? foo.name : 'bar' }}: {{ 'stringArg' }}, {{ { some: { obj: 'settings' } } }}"
"#{{ foo ? foo.name : 'bar' }}('stringArg', { some: { obj: 'settings' } })"

Unification
Decorators and transitions also use the current proxy syntax for their names and args, and I would propose that they continue to do so with the new syntax. The one exception would be named decorators as implemented in #2369, where the name and parens would be left off, leaving just the args list e.g. <div as-aceEditor> and <div as-aceEditor="'value', .options, 'otherArg'"></div><input type="checkbox" checked="{{.options.vimMode}}" /><input type="checkbox" checked="{{.options.wrap}}" />. The current decorator syntax would also be supported e.g. <div decorator="#aceEditor('value', .options, 'otherArg')"> for having dynamically named decorators.
Thanks for reading! I'd love to hear your thoughts on this because if it works, I'd like to go ahead an start a branch shooting for a 0.9 PR.

:+1:

I propose that we make this a plain old expression and resolve and execute it when the triggering event fires.

YES!!! but the current on-click="method()" (without @) would be supported yet?

but the current on-click="method()" (without @) would be supported yet?

Yes and no. Expressions resolve in the context in which they live, so without a special ref to link outside the data, there's no way to get to the ractive instance. I guess you could get funky and do something like:
var r = new Ractive({...});
r.set('ractive', r);

I don't think that would destroy the world, but you would then have to prefix everything with wherever the instance was stored. Here're some examples for the proposed method-call replacement (static names and expressions):
window.doSomething = function() { console.log('doing something global'); }

class User {
  constructor(name} { this.name = name; }
  sayHi() { console.log(`hi from ${this.name}`); }
}

var r = new Ractive({
  data: {
    doSomething() { return { action: { lastThing(arg) { console.log(`why? ${arg}`); } } }; },
    users: [
      new User('Joe'), new User('Rich'), new User('Marty')
    ]
  },
  doSomething() { console.log('doing something ractive-y'); }
});

<button on-click="@global.doSomething()">log from the first function - global</button>
<button on-click="@ractive.doSomething()">log from ractive-y function</button>
with #2345 - <button on-click="@doSomething()">log from ractive-y function</button>
<button on-click="doSomething().action.lastThing('because I can')">log why? because I can from data</button>
{{#each users}}
  <button on-click=".sayHi()">will sayHi from current iteration user</button>
{{/each}}
<button on-click="@global.scrollTo(0, 1000)">scroll the window to 1000px</button>

Unfortunately, this doesn't make any fewer places to access stuff, but it does make it consistent with the rest of Ractive's mustachioed things. As mentioned above, it also frees up each person/team to pursue their preferred method of eventing.

@evs-chris:
I really like the strict @ prefixing for event methods. Yes it's breaking change, but then it's very consistent and gives direct access to data functions. My one concern is that unless plumbed via adaptors, ractive won't know about stuff like on-click='myList.add(thing)' ). With more proxy and less ie8 this seems the way to head, but could end up catching people off guard.
Also, I'm in agreement that we should broaden the use of in-template scripting with more complex expressions.
I would rather we not introduce an additional invocation api for decorators and transitions. If I understand correctly, the issue is to move the token with the attribute value can be dynamically secified?.
I would suggest a few (non-mutually exclusive) ideas:

Use the conditional attribute blocking:

<div {{#if shouldDecorate}}as-sortable='{ someOption: true}'{{/if}}
     {{#if foo}} as-tooltip {{else}} as-ariaplus {{/if}} ></div>

Use [transition]-in, [transition]-out, and [transition]-in-out as replacements for intro, outro and intro-outro and same block semantics apply:

<div {{#if foo}}fade-in-out{{/if}}></div>

Only allow the shortcut of single name token to fire an event implicitly:

<div on-click='submit'></div>
<!-- shortcut for -->
<div on-click='@fire( "submit", event )'></div>

I like the consistency over what seems like a rather specialized use of # for doing #handler( someData ) in lieu of @fire( "handler", someData ) (or more specifically @fire( "handler", event, someData ) if you didn't want to use this.event).
However an additional idea I had for the # would be to use it as a general sigil for a "dynamic directive". Perhaps using #(expression) for expressions:
<!-- uses value of foo, view, eventName and transitionName: -->
{{> #foo }}
<#view user='{{user}}'/>
<div on-#eventName='@process()' #transitionName-in-out></div>

<!-- uses result of expression for partial, component, and event names: -->
{{> #(field.type + 'field') }}
<#( mobile ? 'sidebar' : 'navbar') user='{{user}}'/>
<div on-#(foo ? 'click' : 'mousedown')='@process()'></div>

I'm for 1 and 2, too. With directives allowed in conditionals, it seems like the need for dynamic names would diminish significantly. It'd be good to hear a few opinions from those who have actually used dynamically named decorators or transitions though, as I have not.
Dropping dynamic names would allow us to use the expression parser directly inside of directives e.g. <div as-foo="., 'some string', [{ another: 'arg'}]" fade-in="{ delay: 500 }"></div>, which is basically what you said in 1. But that is the sticky issue with parsing for directives right now: one attribute value is being used to handle three cases. Stripping out the dynamic names drops it to two more easily handled cases - plain attributes and args lists for directives.
For 3, I'm starting to think that maybe a library/plugin solution is in order. Since this.event is available, perhaps a proxy method could be added that just refires the event keeping the params intact. It's slightly longer, but there's no longer a special case:
<div on-click="@proxy('submit')"></div>
<!-- instead of the slightly shorter, but much more special -->
<div on-click="submit"></div>

For part 2 of number 3, that's pretty slick. I'd like to throw out that perhaps inline template strings might be a good solution. I'd eventually like to get them supported in expressions, but there's no reason they couldn't also be used in templates for dynamic bindings in the future:
<div class="{{`here is an ${expression.interpolated.template} because yay es2015!`}}"></div>
<div `dynami${foo ? 'c' : 'ism'}Ftw`="{{`this is ${foo ? 20 : 60`}}"></div>

So basically, if the template string is encountered outside of a mustachioed region, it means "this is a dynamic binding". That would come back around to solving numbers 1 and 2, though I would punt on that for now.

Some parsers (Jade, Slim) will not play nicely with # in inline code such as <div on-#eventName='@process()' #transitionName-in-out></div>, so can we think of something else? Plus, it looks kind of gross, hanging on the attribute name like that.

Let's keep in mind that every symbol/behavior added will make it harder to beginners to learn ractive and more things to remember for us. A small and efficient API is more important in the long run. Based on that, I would say to deprecated the old style (proxy) and make it a plain old expression. That would open the door to create something like @evs-chris suggested ( @proxy('submit')) or other (crazier) ways to do it. I went to see how other frameworks do it:

Vue: it doesn't even support something different than method calls in templates: Custom Events

react.js: the whole thing is a mess. Hard to understand the popularity of it.

ember: it seems that the only way of doing it is triggering it inside a method: http://emberjs.com/api/classes/Ember.Evented.html

Personally, I'm phasing out the use of events provided by ractive and implementing a more simple system over top because there's a lot of syntax to deal with. One problem was that I had events with colons in their names already in use before we switched to ractive, so I had to add a conversion step between ractive events and everything else. Working with events coming from components has also been a bit of a pain.

I'm sort of scared of all these new @, # symbols being proposed. Yes, they offer crazy amounts of flexibility but at the huge cost of complexity—both in the mental model of users and the code base.
When I was first learning about ractive I loved that it didn't have a bunch of symbols that I would have needed to learn exactly what each one did. All these symbols make ractive's templates look quite a bit more daunting and scary to the newcomer.
I think @Rich-Harris's original Option 1 (method calls) is perfectly fine for 90% of use cases and should be promoted as the go-to way of doing.
That leaves us with two clean and easy to understand syntaxes
<div on-click="toggle('foo')">

<div on-click="doSomething(foo)"/>

where foo in doSomething(foo) gets resolved as an expression ({{foo}})
The other syntaxes are sometimes convenient, but more often than not are very clunky and hard to move around, like Rich mentioned.

Now for this @ stuff... couldn't you achieve the same result with the existing non-ambiguous reference syntax? Then we wouldn't be introducing new symbols, but using the same mental model from previously introduced ones.
 : (no prefix) ambiguous resolve
.: current scope/iteraton (data)
~/: current prototype
/: global
Then you'd have the same control over which method is called as you do in expressions.
window.doSomething = function() { console.log('doing something global'); }

class User {
  constructor(name} { this.name = name; }
  sayHi() { console.log(`hi from ${this.name}`); }
}

var r = new Ractive({
  data: {
    doSomething() { return { action: { lastThing(arg) { console.log(`why? ${arg}`); } } }; },
    users: [
      new User('Joe'), new User('Rich'), new User('Marty')
    ]
  },
  doSomething() { console.log('doing something ractive-y'); }
});

<!-- call the doSomething from the prototype -->
<button on-click="~/doSomething()">log from ractive-y function</button>

<!-- call the doSomething in data: {} -->
<button on-click=".doSomething().action.lastThing('because I can')">log why? because I can from data</button>
or
<button on-click="doSomething().action.lastThing('because I can')">also works because same method on data and prototype, prefers data</button>

<!-- call the sayHi from the model -->
{{#each users}}
  <button on-click=".sayHi()">will sayHi from current iteration user</button>
{{/each}}

<!-- do the global -->
<button on-click="/scrollTo(0, 1000)">scroll the window to 1000px</button>

@JonDum as of my last response to @martypdx, I'm thinking the #s should go away in the context of this issue.
The special refs with @ are meant to be an evolution of the same concept from Handlebars, where @index is the index of the current iteration, etc. We recently added @ractive, which is a reference to the current Ractive instance, and @glboal, which is a reference to the window or global object depending on the environment. @martypdx has a PR open that basically shortens @ractive.some.path to just @some.path to drop a little of the noise. This gives easy access to non-data state (props, if you will) for those who don't want to taint their data with, for instance, helper methods or third party library handles.
Unfortunately, you're changing the meaning of ~/ in the context of events to mean @ractive, whereas currently it means "the root of the data for this instance" anywhere else. You're also adding a new thing, /, to mean @global.
There has also been a fair amount of misunderstanding of the difference between these and why you can't call the doSomething method from the latter in an event:
new Ractive({
  data: { ... },
  doSomething() { ... }
})

new Ractive({
  data: {
    doSomething() { ... }
  }
})

Ignoring the proxy issue (#s) from my initial proposal, it is an attempt to unify how the various resolutions from data references and events work by simply making them expressions that are executed when the event fires. I was hoping that was less surprising than having to switch contexts just for calling event handlers. To me, at least, it is much more obvious what is going to happen with <button on-click="@ractive.set('foo', 42)"> vs <button on-click="set('foo', 42)">.
In the docs overhaul (I'm bout to start, I swear), having a good once-over on what keypaths can look like and having them be the same no matter where they occur would hopefully reduce beginner intimidation. Then we're just down to normal data refs and special refs.

@evs-chris

you can't call the doSomething method from the latter in an event:

yea you can :P lol
this.on(*, function(re) {
    if (re && re.original && re.original.preventDefault && re.node
        && ((window.HTMLElement && re.node instanceof window.HTMLElement) || re.node instanceof window.Element)
        && re.name && typeof this[re.name] === 'function') {

        return this[re.name].apply(this, arguments);
    }
}

I went to see how other frameworks do it: @guilhermeaiolfi
I'm sort of scared of all these new @, # symbols being proposed. @JonDum

Don't forget Angular and its =, & and @ on directives. So terrible that every time I revisit an Angular project, I have to read up which does what.
Been a long time since I was on this thread, and since then, I have settled with the method call syntax. It's reminiscent of the good ol' inline vanilla inline script calls. A setup like the following is a no-brainer for a newcomer.
A call from an event (the on-*) is a method call
<button on-click="someMethod(arg1, arg2, ...)">Hi!</button>
<component on-click="someMethod(arg1, arg2, ...)">Hi!</component>

A call from a decorator is a decorator setup
<span decorator="i18n(arg1, arg2, ...); lowercase(); ">Hi!</span>

A call from a transition is a transition
<div transition="fade(arg1, arg2, ...); slide(arg1, arg2)">Hi!</div>

Anything between {{ }} prints whatever is evaluated into the template. They resolve to data/computed props. Expressions allowed.
<!-- primitive -->
<p>{{ model.summary }}</p>

<!-- data model (covers cases where data contains functions like getters, setters) -->
<p>{{ model.getSummary() }}</p>

<!-- expressions -->
<p>{{ foo ? 'bar' : 'baz' }}</p>

For references/shorthands, I suggest verbose naming instead of standalone #, @, . etc.

@global - The global object (window on the browser)
@instance - The current instance. All the stuff defined there accessible via this.
@root - The top-level component, same characteristics as @instance.
@parent - The parent of the current instance, same characteristics as @instance.
@whatever - as long as it's not a solo doodad.

@akhoury I can't really tell what is happening there, but I'll go with 'I stand corrected' :laughing:
@fskreuz are those changes you'd like to see, or were you just examining it from a beginner's viewpoint? Just wondering on a few points, cause I'm gathering ideas for a PR:

I'm not opposed to ; delimited expressions, but I've seen opinions expressed in issues that were strongly opposed. I think it'd be kinda nice for event handlers where you want to do two or three quick and simple things like a splice, a toggle, and a set.
Would you stick strictly to calling only Ractive instance methods from event handlers?
How do you feel about as-${decorator}, like as-lowercase and as-i18n="arg1, arg2, ...", and the proposed ${transition}|-in, like slide-in, fly-out, fade-in-out, and fade-in="{ duration: 500 }"?

We could also start using %= on attributes to indicate transclusion during the next digest cycle after the isomorphic cloud synergizes. :wink:

are those changes you'd like to see, or were you just examining it from a beginner's viewpoint?

Both? :smile: I fear that all these Ractive-specific syntax makes it difficult to board devs, given that Ractive has remained faithful to its 99% vanilla look with a touch of Handlebars.
For comparison, ES6+JSX. I have this belief that most of the people who like the React+JSX combo was because it was eerily similar to PHP+Heredoc.
<?php
// This looks like a React component now does it? But it's PHP!
class MyComponent extends Component{
  public function render(){
    $message = 'world';
    return <<<HEREDOC
      <div>Hello {$message}!</div>
HEREDOC;
  }
}

So if Ractive stuck to the vanilla HTML+JS syntax in templates, it's a win. One doesn't need to unlearn anything, change their mental model and so forth.

I think it'd be kinda nice for event handlers where you want to do two or three quick and simple things like a splice, a toggle, and a set.

How do you feel about as-${decorator}, like as-lowercase and as-i18n="arg1, arg2, ...", and the proposed ${transition}|-in, like slide-in, fly-out, fade-in-out, and fade-in="{ duration: 500 }"?

I think there was a discussion on multiple decorators and stuff like that. Was wondering if we could have a common syntax for all. All method-like, all semi-colon-delimited, all supporting multiple operations and sequential operations.
Multiple parallel calls could use semi-colon delimited like multiple inline JS calls.
<div transition="slide({ ... }); fade({ ... })"></div>

For sequential, dot-delimited. It's just like what you'd expect from libraries like jQuery and Lodash.
<!-- sequential animation (notice the dot between, as if it was chained) -->
<div transition="slide({ ... }).fade({ ... })"></div>

as-* wouldn't really tell me that it's a decorator. Probably decorator-*. But then, this means they will either look like prefix-name="arg1, arg2,..." (which is similar to the old syntax) or prefix-name="{ arg1: val1, ... }" which becomes more Angular-y. :scream: And both of which are departures from the method-like syntax of method calls.

Would you stick strictly to calling only Ractive instance methods from event handlers?

This I'm still thinking about. It does make sense in the following:
<button on-click="spamAds(100, emails)">{{ @instance.translate('Hello') }}</button>
<button on-click="spamAds(100, emails)">{{ @methods.translate('Hello') }}</button>

@instance and @methods tell me we're referencing the instance and not the data, making translate not a data function. As long is it looks as verbose as this, and the docs telling people that by default {{ }} references data, and you need to use @ to reference stuff other than data, then it's cool.

We could also start using %= on attributes to indicate transclusion during the next digest cycle after the isomorphic cloud synergizes.

http://dilbert.com/strip/2015-12-20

TL;DR
this is getting out of hands. Sorry. Too much talk. Just one begging: please keep it simple! ...there is already too much around!
...therefore, I'm still in favor of option 1. Please just deprecate the old proxy syntax, it ain't needed anymore.
As for all other proposals, I'm in favor of putting them in separate threads, it's getting too messy/overcrowded here IMHO.

if you really want to growth hack the analytics, perhaps a better way, would be to make a babel transform which reads the developer's mind.

I like option 1 and 4, deprecate old syntax and also try the "array syntax"

Remove the old syntax. One con that is, no pun intended, a growing concern is file size. When more important features find their way in removing useless dead code is mandatory IMO. Force people to change simple as that of they don't like it that's on them. I rather see a decision in favor of the ecosystem not a select few.

Starting with Ractive nearly 4 months ago, I thought proxy events is the "right way" to call a method.
In http://docs.ractivejs.org/latest/method-calls clearly states that "As an alternative to proxy events, you can call any method...". So in my mind  the "method call" stayed as the alternative syntax not the main syntax. As a result my code is now full of
on-click="add_item"
on-click="delete_item"

etc...
I use method calls in templates only when I want to use some ractive methods directly e.g set, push, splice and so on...
If you are planning of removing the proxy syntax you may want to change the docs so that it is clear for newcomers that the "Method calls" syntax is the proposed one and not the other way around.
With that said I agree with @maxgalbu and say that: I'd go with option 1, but without the mandatory event parameter (if possible).

Yeah, since I've learned that proxy events are deprecated for most intents and purposes, I feel like I need to warn everyone when I tell them about Ractive.  "It's great and you should use it but remember to use this fire('event') syntax for events instead of what the docs say"

I use mostly method calls but sometimes proxy events are the way to go because you may not want to call a method on the instance but propagate an event on the parent view. Otherwise you need to call a method which will call this.fire which is extra code and kind of unecessary. Am I missing something?

Otherwise you need to call a method which will call this.fire which is extra code and kind of unecessary. Am I missing something?

There is no need to call a method that will fire your event. You would call @this.fire('eventName', event, data) in your template and that's it.


Unreasonable CitySim Coupled for QN

Ok, so I fixed the QN E+ graphics and they look very reasonable now.
I ran into an issue with the QN CitySim results though: https://www.dropbox.com/s/45roo7vt7qxy1j4/Screenshot 2016-04-15 12.59.21.png?dl=0
Solo CitySim makes sense but the Q(s) output for 1(1):1:Qs(Wh) results in crazy high cooling and NO heating:  https://www.dropbox.com/s/qht2l0sem3yloxz/Screenshot 2016-04-15 13.03.42.png?dl=0

I think this is done, right?


start Crash

python /data/dbus-iobroker-smartmeter/dbus-iobroker-smartmeter.py
2022-11-06 11:29:43,469 root INFO Start
2022-11-06 11:29:43,494 root INFO registered ourselves on D-Bus as com.victronenergy.grid.http_40
2022-11-06 11:29:43,574 root CRITICAL Error at main
Traceback (most recent call last):
File "/data/dbus-iobroker-smartmeter/dbus-iobroker-smartmeter.py", line 277, in main
pvac_output = DbusIobrokerSmartmeterService(
File "/data/dbus-iobroker-smartmeter/dbus-iobroker-smartmeter.py", line 38, in init
self.grid_bought_start = next((x for x in meter_data if x['id'] ==
TypeError: 'NoneType' object is not subscriptable

This is related to the iobroker fork...

This is related to the iobroker fork...

Can I solve the problem?

@B4unty Did u fixed it?


Change requirement to be online for the magnetic-field-calculator

Currently to add default data to the SurveyHeader class, the script needs to be run online for magnetic-field-calculator to lookup and fetch the data.
Change this to a try and default to some reasonable values if run offline.

Closed in #76 where libraries are only imported if they're available and where a None value can be passed with a reasonable default value.


Error Code SIS0463

Hi, I'm trying to make a payment with a token previously generated but the request is being denied, period.
This is the log generated:
{"Ds_Date": "25/01/2024", "Ds_Hour": "18:31", "Ds_Order": "240100000204", "Ds_Amount": "31675", "Ds_Currency": "978", "Ds_Response": "0118", "Ds_Terminal": "001", "Ds_ErrorCode": "SIS0463", "Ds_Card_Country": "724", "Ds_MerchantCode": "336099247", "Ds_MerchantData": "", "Ds_SecurePayment": "0", "Ds_TransactionType": "0", "Ds_ConsumerLanguage": "1", "Ds_AuthorisationCode": "      "}
Here how i'm creating the token:

Here how i'm making second payment:

I did some research and SIS0463 means 'Metodo de pago no permitido', any idea how to solve this?

What Redsys environment are you using with this result? test or production?

test

Hi, do you have any new info about this? @dtorras

Can you share what test card are you using to test it?
After adding the DS_MERCHANT_EXCEP_SCA param, I was able to save a card token and create a recurring payment with this card data in the test environment.
$response = RequestBuilder::newRequest(new RequestParameters(
    amountInCents: $subscription->getTotalAmount(),
    currency: Currency::EUR,
    transactionType: TransactionType::Autorizacion,
+    excepSca: 'MIT',
))->associateWithModel($subscription)
    ->usingCard(
        CofType::Recurring,
        $redsysCard
    )->post();

Número de tarjeta:<PHONE_NUMBER>400004
Caducidad: 12/23
Código CVV2: 123

@jperez8 I'm closing this issue for now. Feel free to reopen it if you have more details.


MVVM Light adds large number of system assemblies to the installer

When targeting .NET 4.5 or later, adding MVVM Light to my WPF project injects a large number of system assemblies to the application folder upon installation.
Here's how to produce this:

Create a new WPF Application project, targeting .NET 4.5 or above.
Add NuGet reference to MVVM Light (or the Lib-only version; doesn't matter).
Add an MSI Setup project to the solution (extension needs to be installed beforehand).
Add Primary Project Output of WPF application to the setup project.

There you go. A long list of System.X.Y will be added to the list. If you build and install the setup project, you'll see all these DLLs in Program Files folder.
The problem does not appear if WPF application targets .NET Framework 4.0 and you add NuGet reference AFTER that. But if you target .NET 4.5, 4.5.1 or 4.6, the long list of dependencies appears again. Think MVVM Light (or NuGet) is having trouble finding the correct package sub-folder.

Did you get a chance to look into this?

Having the same problem - boosts the size of the installer package quite drastically !!

check the "Copy Local" property on the references. It should be False - if True then it will copy that file into the output and use that instead of the system copy of the file.

@CADbloke Which references are you talking about? BCL Assemblies or MVVMLight assemblies? If you're referring to BCL assemblies, know that the assemblies copies to the setup project are NOT even referenced in the project; they still somehow get their way to the installer. If you're talking about MVVMLight assemblies, I don't think I have the liberty NOT to copy them locally. Where would it find them then?

The Assemblies are automatically picked up as Detected Dependencies in the Installer. They are not referenced in the Application. Referencing MVVMLight in the App creates these Detected Dependencies, bloating the Installer!

oh. Darn. I was hoping it was something obvious & easy. But, alas, no, it rarely ever is.

Does the new version (5.4.1) do anything regarding this issue, so that I consider upgrading?

Hi, this is a relatively new issue and was not on the backlog. Since releasing the net standard version was critical, I decided to postpone looking into this particular issue. I will do my best to check what's happening here asap. Change log is always at http://mvvmlight.net/installing/changes

Just tried this again with 5.4.1. Still the same issue :(
New clean WPF Project targetting .Net 4.6.2. Added an Setup Project, and included the Primary Output from the WPF Project. Installer automatically detects no dependencies, which is correct.
Added MVVMLightLibs 5.4.1 with Nuget and the Setup Project now has 65 Detected Dependencies - apart from the 3 Galasoft ones, most of them are System.* assemblies - many duplicated (System.Collections x 2, System.Diagnostic.Debug x 2, System.Globalisation x 2 etc, etc).
Does exactly the same when installing the Libs, the StandardLibs or the full package.

Thanks for trying and reporting again. This is very annoying. I think this is new, correct? At first I thought the culprit was CommonServiceLocator, but if it does the same with StandardLibs, which doesn't have this reference...
I'll ping the .NET guys to ask them if they know what's going on. Unfortunately they are not always very responsive (love you guys, but it's true...)

Thanks Laurent,
Be good to get to the bottom of it. Not sure how 'new' the issue is.
Just tested with a fresh project. If I Nuget MVVMLightLibs <IP_ADDRESS>, the Detected Dependencies of the Installer project behave themselves (2 x Galasoft, Microsoft.Practices.ServiceLocation, System.Windows.Interactivity)
If I update to MvvmLightLibs 5.0.1, the Detected Dependencies immediately jumps to an extra 60+ dependencies.

Hi,
any updates here? I've got the same problem...

Not seen any updates as yet. I really like the MVVMLight framework, but the bloat it's causing to my setup projects is really annoying!

This issue is indeed with Microsoft. It is highlighted here - https://stackoverflow.com/questions/48060230/system-reference-troubles-when-introducing-netstandard-library-dependency


Allow peerDownload config for minion-tasks

Currently, minion-jobs always use zkMetadata downloadURI to download segments from deepstore.
I want to get community's opinion on adding a new optional task-level config allowPeerDownload to allow minion-task during execution to try downloading segment from a server-peer directly once deepstore-retries fails. Currently, the job fails and does not move forward. This also creates a situation of head-of-line-blocking queue for subsequent task-runs if tableMaxNumTasks is specified.
PS: this issue specifically discusses the situation where the zkMetadata has deepstore URI available and is not "" (empty).
There can be multiple reasons for deepstore URI download failures:

Issues with deepstore connection / timeouts
The segment-deepstore-copy getting TTL'ed from deepstore due to other non-Pinot frameworks (we are seeing this for some of our clusters).

For example, we have an upsert-compaction task enabled for a table with following configs:
"task": {
      "taskTypeConfigsMap": {
        "UpsertCompactionTask": {
          "invalidRecordsThresholdPercent": "30",
          "bufferTimePeriod": "0d",
          "schedule": "0 */5 * * * ?",
          "tableMaxNumTasks": "5"
        }
      }
    },

The table has data for more than 60days. There was a TTL enforced on the deepstore-path for 7days.
The following graph shows that there was a drop in row-count (in red circle) when UpsertCompaction first kicked off (at that time I had removed "tableMaxNumTasks": "5" config). But once I added that config there is no task getting executed (not even for newer segments) because it is getting blocked by FileNotFoundException while downloading from deep-store for older segments.

The table has huge potential for cost-savings in terms of compaction and it seems we can use peerDownload to unblock the task.
Another parallel discussion:
There is a framework which periodically checks if zkMetadata URI is empty then upload the jar to deepstore but there is no framework which checks if the path pointed out by zkMetadata URI is actually present or not.

I'm good with the proposal. Maybe renaming to allowDownloadFromServer

Please assign to me. Thanks!

cc @snleee @swaminathanmanish


Bank value missing for Mystic Steam battlestaff(orn), Lava Battlestaff(orn)

Hi I was told to make a issue post about the bank value not displaying properly for certain cosmetically affected items. IE, Mystic Steam battlestaff(orn), Lava Battlestaff(orn). Would it be possible to combine the cost of the ornament+the item together like you do with fury, etc. I understand you lose it but lots of people keep those items forever once they do so.

This can be closed since the plugins purpose is liquid-able value and so this would not be implemented for that reason.


GDScript debugger incorrectly warns about unused exported variables.

Godot version:

master  9d33425
OS/device including version:

Ubuntu 18.04 Linux 5.1
Issue description:

GDScript incorrectly complains that an exported variable is unused despite it being used by another file.
Steps to reproduce:

Declare any exported variable.
Use it in another file.
GDScript debugger will complain.

Minimal reproduction project:

Any project really, I was using the Dodge the Creeps project from Godot's demo projects.

Not really a bug. Variable usage is only tracked within the Class Scope. It can't know you are using it elsewhere. That would require a lot of effort.

Would it not be sufficient to just ignore exported variables when checking for unused?
I mean I can make the warning disappear by just adding a getter, but it would be redundant as an exported variable is already public in a sense.

Just add the comments.
Click the warning triangle in the script editor.

Can anyone still reproduce this bug in Godot 3.2.3 rc4 or any later release?
If yes, please ensure that an up-to-date Minimal Reproduction Project (MRP) is included in this report (a MRP is a zipped Godot project with the minimal elements necessary to reliably trigger the bug). You can upload ZIP files in an issue comment with a drag and drop.

No answer, so closing. Please comment if you can still reproduce it, and make sure that an up-to-date reproduction project is included.


You exceeded your current quota, please check your plan and billing details.  will sleep 60 seconds

这是要给gpt多充点钱的意思吗？

我也遇到了相同的问题

Same issue.


mesh generation of Harvey with BEST track failed with pygeos.GEOSException: TopologyException

Note added by @SorooshMani-NOAA: This issue occurs on the enhance/subset_triangle branch
@SorooshMani-NOAA this is the error I'm getting during the mesh generation step for the BEST track of harvey:
Traceback (most recent call last):
  File "/opt/conda/envs/ocsmesh/lib/python3.9/runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/opt/conda/envs/ocsmesh/lib/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/scripts/hurricane_mesh.py", line 546, in <module>
    main(args, [hurrmesh_client, subset_client])
  File "/scripts/hurricane_mesh.py", line 97, in main
    clients_dict[cmd].run(args)
  File "/opt/conda/envs/ocsmesh/lib/python3.9/site-packages/ocsmesh/cli/subset_n_combine.py", line 113, in run
    self._main(
  File "/opt/conda/envs/ocsmesh/lib/python3.9/site-packages/ocsmesh/cli/subset_n_combine.py", line 657, in _main
    utils.finalize_mesh(jig_combined_mesh)
  File "/opt/conda/envs/ocsmesh/lib/python3.9/site-packages/ocsmesh/utils.py", line 428, in finalize_mesh
    boundary_polys = get_mesh_polygons(mesh)
  File "/opt/conda/envs/ocsmesh/lib/python3.9/site-packages/ocsmesh/utils.py", line 244, in get_mesh_polygons
    res_gdf = polys_gdf[polys_gdf.intersects(pnt)]
  File "/opt/conda/envs/ocsmesh/lib/python3.9/site-packages/geopandas/base.py", line 1559, in intersects
    return _binary_op("intersects", self, other, align)
  File "/opt/conda/envs/ocsmesh/lib/python3.9/site-packages/geopandas/base.py", line 59, in _binary_op
    data, index = _delegate_binary_method(op, this, other, align, *args, **kwargs)
  File "/opt/conda/envs/ocsmesh/lib/python3.9/site-packages/geopandas/base.py", line 43, in _delegate_binary_method
    data = getattr(a_this, op)(other, *args, **kwargs)
  File "/opt/conda/envs/ocsmesh/lib/python3.9/site-packages/geopandas/array.py", line 587, in intersects
    return self._binary_method("intersects", self, other)
  File "/opt/conda/envs/ocsmesh/lib/python3.9/site-packages/geopandas/array.py", line 566, in _binary_method
    return getattr(vectorized, op)(left._data, right, **kwargs)
  File "/opt/conda/envs/ocsmesh/lib/python3.9/site-packages/geopandas/_vectorized.py", line 768, in intersects
    return _binary_method("intersects", data, other)
  File "/opt/conda/envs/ocsmesh/lib/python3.9/site-packages/geopandas/_vectorized.py", line 284, in _binary_method
    return getattr(pygeos, op)(left, right, **kwargs)
  File "/opt/conda/envs/ocsmesh/lib/python3.9/site-packages/pygeos/decorators.py", line 80, in wrapped
    return func(*args, **kwargs)
  File "/opt/conda/envs/ocsmesh/lib/python3.9/site-packages/pygeos/predicates.py", line 764, in intersects
    return lib.intersects(a, b, **kwargs)
pygeos.GEOSException: TopologyException: side location conflict at -92.000761999999995 30.268000000000004. This can occur if the input geometry is invalid.
ERROR conda.cli.main_run:execute(49): `conda run python -m hurricane_mesh harvey 2017 subset_n_combine /lustre/static_data/grid/stofs3d_atl_v2.1_eval.gr3 /lustre/static_data/grid/WNAT_1km.14 /lustre/hurricanes/harvey_2017_82b5052c-bd22-4ec3-8aed-1732c675c0e2/windswath --rasters /lustre/static_data/dem/gebco/gebco_2021_sub_ice_topo_n0.0_s-90.0_w-180.0_e-90.0.tif /lustre/static_data/dem/gebco/gebco_2021_sub_ice_topo_n0.0_s-90.0_w-90.0_e0.0.tif /lustre/static_data/dem/gebco/gebco_2021_sub_ice_topo_n0.0_s-90.0_w0.0_e90.0.tif /lustre/static_data/dem/gebco/gebco_2021_sub_ice_topo_n0.0_s-90.0_w90.0_e180.0.tif /lustre/static_data/dem/gebco/gebco_2021_sub_ice_topo_n90.0_s0.0_w-180.0_e-90.0.tif /lustre/static_data/dem/gebco/gebco_2021_sub_ice_topo_n90.0_s0.0_w-90.0_e0.0.tif /lustre/static_data/dem/gebco/gebco_2021_sub_ice_topo_n90.0_s0.0_w0.0_e90.0.tif /lustre/static_data/dem/gebco/gebco_2021_sub_ice_topo_n90.0_s0.0_w90.0_e180.0.tif --out /lustre/hurricanes/harvey_2017_82b5052c-bd22-4ec3-8aed-1732c675c0e2/mesh` failed. (See above for error)

working directory on NHC_COLAB_2: /lustre/hurricanes/harvey_2017_7515c27c-22f2-49e4-b369-ec7fb89e1ee8
Here is the windswath file for this run.
windswath.zip

I also encounter a different error Negative elem. areas when running BEST track Florence case using the mesh generated from the new ocsmesh.  The workflow crashed at the model spinup stage due to the Negative elem. areas error.
In the error log file, it indicated AQUIRE_HGRID: negative area at 1491512 (see the figure below, the red circle indicates that tiny element; the file is located here: /lustre/hurricanes/florence_2018_nowave_noriver/setup/ensemble.dir/spinup/outputs/nonfatal_000029).

The Harvey issue seems to be due to triangulation of the buffer region, for some reason the triangulation function also triangulates a "hole" in the buffer zones which causes conflict with existing high-res section of the mesh.

This needs further inspection of the triangulation function to figure out why this happens.

Further investigation shows that the feature in previous comment is actually two polygons in a multipolygon that are touching at two points. it's not a single hole touching the sides of a single polygon. This is still valid in shapely, but it causes problem for triangle triangulation package:

The main issue seems to be addressed now in the branch, but now I see some strange triangulations like:

@FariborzDaneshvar-NOAA the original issue is resolved. Please test and let me know if you still run into errors. The new issue with strange mesh patches is something I'm still investigating

For some reason some of the buffer patches do not have hfun defined!

The issue looks to be related to how jigsaw meshes the input! Specifically at:
https://github.com/noaa-ocs-modeling/OCSMesh/blob/6dbd530033a420f539d39faf858d3183151da7cc/ocsmesh/cli/subset_n_combine.py#L289-L293
The geometry looks like this:

And the hfun like:

But the mesh ends up ignoring the patches:

Note that this mesh was generated in a separate iPython session too (from the saved domain and hfun) and still has this issue. The mesh was generated using  ocsmesh's JigsawDriver, maybe let's try to also directly use Jigsaw and see if it differs!

After further investigation, by trying to modify the buffer geom by buffer operation, etc. I still get similar issues. This should be something related to how jigsaw handles separate input polygons.

It doesn't make any sense! For the buffer zone polygons (like above) I have this issue with Jigsaw that it doesn't mesh some of them. If I send a subset of these polygons, I get different set of them unmeshed! I also thought it might be that shapes are too complicated and cause truncation errors, so I buffered the shapes by 10000 meters and simplifyd the shapes by tolerance of 5000 meters, but I still get similar issue. I even tried using a background mesh as size function (so that I know the issue is not the size function):

Then I thought it's just Jigsaw cannot handle multiple polygons with holes, but then trying buffered points for polygon it meshes fine (I used the same background mesh as size function):
m_lo = ocsmesh.Mesh.open('path/to/bg/mesh.2dm', crs=4326)
mlo_hfun = ocsmesh.Hfun(m_lo)
mlo_hfun.size_from_mesh()

pts = points([[-92+i, 20] for i in range(10)])
geom = ocsmesh.Geom(MultiPoint(pts).buffer(0.35).difference(MultiPoint(pts).buffer(0.05)), crs=4326)

dr = ocsmesh.driver.JigsawDriver(geom=geom, hfun=mlo_hfun)
m = dr.run(sieve=0)
m.write('multicircle.2dm', format='2dm', overwrite=True)

Not addressed as a part of the merge!


Build login page

I've started work on a login page.  Can you assign this issue to me?

As you wish. Thanks for your help. Will you be at the meeting tomorrow or the Dojo? If you are willing, it would be helpful if you could walk us through how to make a login page. Even just commenting though could be helpful as well.
BTW thanks for the book, I have found it immensely helpful.
Sne
On Monday, April 1, 2019, 9:53:14 PM MDT, John Cassidy<EMAIL_ADDRESS>wrote:

I've started work on a login page. Can you assign this issue to me?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Hi John,  could you add instructions (preferably under docs) as to what needs to be added to the other web pages so:

The web page does not allow a user to see or make any changes until they have been authenticated
Redirects the user to the login page for authentication
Returns the user to the original page after after authentication

Thanks!

John added code for the login page in PL#29.  Subsequent changes by John and others added the logout page and the LoginRequiredMixin to require/redirect to the login page as appropriate.


Unable to download files greather than 64Mb through PROXY

The problem
I have enabled internal proxy in my project by setting up global property Configuration.proxyEnabled = true.
During attempt of downloading files using method FOLDER or PROXY I receiving errors in the console log and can't download file.
The problem related to the limit in the built-in proxy server https://github.com/selenide/selenide/blob/master/src/main/java/com/codeborne/selenide/proxy/BrowserUpProxyServerUnlimited.java line 17
My expectation is following:
Option 1. Change limit by default to 4Gbytes, provide ability to change this limit by Configuration.proxyRequestMaxLength
Option 2. Hardcode the most max size for this parameter
Option 3. Provide ability to change parameter by user by setup Configuration.proxyRequestMaxLength and leave 64Mb as default value
Details
It's necessary to change limit
Download code snippet example:
Configuration.proxyEnabled = true;
File downloadedFile = homePage.accessMethodsPageBlock.downloadThinClientX64ForWindowsButton.download(
 DownloadOptions.using(FOLDER)
    .withIncrementTimeout(Duration.ofMillis(6000))
    .withFilter(FileFilters.withExtension("zip"))
);

The console log example:
LittleProxy-0-ProxyToServerWorker-3] ERROR org.littleshoot.proxy.impl.ProxyToServerConnection - (AWAITING_INITIAL) [id: 0xaf349334, L:/<IP_ADDRESS>:50721 ! R:[downloads.scssdsd.ru/<IP_ADDRESS>:443](http://downloads.scssdsd.ru/<IP_ADDRESS>:443)]: Caught an exception on ProxyToServerConnection
io.netty.handler.codec.http.TooLongHttpContentException: Response entity too large: DefaultHttpResponse(decodeResult: success, version: HTTP/1.1)

Tell us about your environment

Selenide Version: 6.10.3
Chrome\Firefox\IE Version: Chrome 108, FireFox latest
Browser Driver Version:
Selenium Version:
OS Version: Windows 10

Code To Reproduce Issue
Configuration.proxyEnabled = true;
File downloadedFile = homePage.accessMethodsPageBlock.downloadThinClientX64ForWindowsButton.download(
 DownloadOptions.using(FOLDER)
    .withIncrementTimeout(Duration.ofMillis(6000))
    .withFilter(FileFilters.withExtension("zip"))
);

@ilya-corp We can increase max payload size from 64Mb to Integer.MAX_VALUE (which is 2GB). Not more. BrowserUpProxy doesn't allow more than 2GB.
BUT
I guess you will get OutOfMemory error in this case. Proxy will need to store the whole 4GB file in memory. Are you sure you really want it?

@ilya-corp I tried to increase this setting in proxy, but it still cannot download 4GB file (I tried both BrowserUpProxy and MockServer). In case of a bit smaller files (1GB), they can download the file, but very slowly (much slower than without the proxy).
So currently I don't know a good solution for downloading 4GB files through proxy. If anyone knows about it, please share your knowledge.

Typically file size of our project is 115-1500 Mbytes.
Also I think, that proxy should not be global, we need to launch independent proxy for every webdriver. For example, I need to download small 5Mb file by proxy in 1 test of 500, and I need to download large 5Gb files without proxy (using FOLDER method) in 10 tests of 500. Another 30 tests should be executed from proxy to analyze outgoing requests and all another tests may be executed without proxy.
So, the code like following will be good:
Selenide.enableProxy();
open("https://mysite.ru)

@ilya-corp Let me ask. If FOLDER method works for you, why do you want to download that one file with PROXY?

Andrey, it's very simple.
In the personal cabinet of out project we can download files (apps, reports, orders etc.) using FOLDER method - it's enough permissions to have Bearer tokens in the Local storage.
However, we also providing ability to download large bases (backups of financial data of bloody 1C) to our users. But those large files stored in the different place (not in the personal cabinet) and requires Basic authorization. Users must to enter credentials (credentials may be different to personal cabinet) before downloading.
I know that it's possible to use combinations of creds in the URL and I have working scenario for this. But it looks like some bycicle. I want to use PROXY to configure automatic headers for specific domains.
For example, domain of cabinet is https://mycompany.com
Domain for databases server is https://largefiles.mycompany.com
In the headers I want to use Authorization with Base64 combination of login:password.
Hope it have sense.
Another argument. I can NOT use proxy in the project if I need to execute some test with downloading of large files (>4Mb).  It's because proxy setting is global now. It's because using proxy brings tests with requests larger 4Mb.
So, my suggestion is to use independent proxies for every driver and made configurable tp limit of proxy size (globally is also acceptable).
If you need any details, we can discuss it in the Telegram.

@ilya-corp I have few suggestions:

Let's set the default limit in Selenide as large as possible: Integer.MAX_VALUE (I don't want to introduce any new setting here. I guess nobody really needs it.)
But I see that downloading of large files through proxy works badly. I tried to debug it, but failed to find how to improve it.
That's why I don't recommend you to download files via proxy.
I didn't understand from your explanation why your test cannot download files exactly as end-users do it. End-users don't set headers, right? They just login and use (de-facto) FOLDER mode. Why can't you do the same?
Anyway, I think you can download your files with FOLDER method like this:

  open("https://largefiles.mycompany.com/favicon.ico");
  localStorage().setItem("whatever auth token you need", "whatever secret you need");
  open("https://largefiles.mycompany.com/");
  File largeFile = $("xx").download(FOLDER);

@asolntsev

Sure, please do that. Thansks in advance.
It's bad, but not critical.
Ok, got it
I have 2 types of downloads. a) Click something and get file. The FOLDER method is ideal for that and it works. b) Click something, ENTER LOGIN AND PASSWORD INTO SYSTEM BROWSER SPECIFIC WINDOW (Basic Auth) and download file.
I can not enter login-password into this system window, I must avoid appearing of it. I can avoid it I will open url with specific header Authorization, but by default browser don't send it (and don't know creds).

And the cherry on the pie. If I will use proxy in some test (it have no matter for the purpose), I will have provlem with downloading files ot TYPE A (via FOLDER method). It's because all request will be processed and failed by proxy. I have no ability to enable proxy for test 1 and disable proxy for tests, which using downloading by FOLDER.
Enabling and disabling proxy now is global setting. In multithreadig changing of Configuration.proxyEnabled may affect different tests and bring to unstable results. It's because I am requesting independent proxy for every driver.

Example of Basic auth window
https://i.stack.imgur.com/2GvZv.png


RSK Testnet issue with the Trezor Modal T

From open slack
more info:

I noticed that the new option for selecting trezor keypath worked great for connecting the wallets and even signing messages, but I'm getting an error when I try to sign a transaction for a method call: "Error: Trezor: FailureError: Trezor: Failure_DataError Forbidden key path". I get the Trezor's pop-up for allowing the transaction but, after that, rather than getting a confirmation on the device, this error pops-up. I'm using web3.js as the provider and I'm using contractMethod.send({ from: walletAddress, value: 0 }) in the code. Should I be doing something different? Additional note: I get the error using any derivation path.

&

error I'm getting happens when calling the following: contractMethod.send({ from: walletAddress, value: 0 })  Here, contractMethod is retrieved via the smart contract's ABI through Web3.js.
Example:  contractMethod = testamentServiceContract.methods.withdrawTestamentFunds(Utils.toBaseUnit(this.inputWithdrawAmount.trim(), 18).toString())

I was unable to recreate with a "Trezor One" so this could be an issue with the Modal T. The Dev Portal has a reference to an issue with the dPath and the T which could be a similar issue here.


Implement S3 Bucket Suitable for Serving Static Websites on S3

what

Create S3 bucket
Enable versioning
Support log storage to S3 bucket
Support A record ALIAS to bucket name
Support CORS
Support Bucket Redirects
Support routing rules

why

Efficient & Affordable hosting of static sites on S3
Use as upstream for CloudFront distributions that require more advanced configurations

But in production, it's better to use CDN.

@aknysh , for this case we've tf_cdn

OK I see that we have tf_cdn_s3 for this use-case.
So tf_s3_website is for simple websites hosted on S3 without CDN.

Tested.

Content is accessible.

@aknysh it's also for sites that require routing_rules which are not supported by vanilla S3 buckets. We have current use-case where we need to redirect an object to a versioned object (e.g. /foo.js -> /foo.1234.js). This kind of redirect requires an S3 website.


Conduct VPAT and Accessibility Check of LCW v2 LTS

Once we finalize a long term support feature set, reconduct a Voluntary Product Accessibility Test and accessibility review (using speech to text) under iOS and Android.

Reconduct accesibility review

@alexfigtree - we did this at the beginning of the year with atomic jolt. Suggest we add accessibility to dev plans for issues. #discussion


LCM Motion Module

Can you add the motion module noted here: https://huggingface.co/wangfuyun/AnimateLCM/tree/main I think the Lora is the usual LCM lora.

The hotshot motion module would also be useful if is not too much trouble.

How hard would it be to have the Depth Anything Preprocessor as well?

@Inner-Reflections Do you know which folder the motion module needs to go in?

Same as any of the other motion modules (ie. temporaldiff, v3) etc.

I've added HotshotXL and AnimateLCM motion modules in https://github.com/fofr/cog-comfyui/commit/1b9d189d6e765593648565c6be03e02e76853802
Please can you let me know if you have any issues with them.
They are in the latest version of
https://replicate.com/fofr/any-comfyui-workflow
508be894cce01cff7e62eda09d6e1f58fe0cc09ecb7cb197698dcabc700af656


obey manifest GenerateDefaultOutputs setting

Fixes #71
The --generate-default-outputs flag works as expected per my testing, but the manifest setting is being ignored.

Pull Request Test Coverage Report for Build 415

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 39.875%

Totals

Change from base Build 414:
0.0%

Covered Lines:
636

Relevant Lines:
1595

💛  - Coveralls


Combining registries?

Is there an elegant way of combining multiple registries in a single encode output?
An example of a use case would be writing an exporter for metrics from an external system, as opposed to the own application's metrics.
The idea is that new metric families would be created and populated on each scrape. But there could also be exporter-related metrics that would be constant between scrapes, such as an info, etc.
One way of doing this right now would be to register the exporter's metrics to a new, per-scrape Registry, together with the scrape metrics and encode that. This approach seems somewhat verbose.
A more ergonomic approach would be for the encode function to take some iterable of Families and encode that, which is basically what the Registry is from its point of view.

Would the Collector pattern be helpful here?
Proposed in https://github.com/prometheus/client_rust/issues/49
Further designed in https://github.com/prometheus/client_rust/issues/29#issuecomment-1172877769

Yeah, I think that could be helpful.
I'd initially glossed over these, seeing how at first they were about "custom encoders", but upon closer reading that's pretty much what I'm after.

Great. Note @vladvasiliu that help here is very much appreciated.

Sure, I'll see if I can come up with something over the weekend.


Remove single quotes from package name

After trying to install the package with composer, of course I copied an pasted the command from the documentation, afterwards getting this weird message:
$ php composer.phar require 'clancats/hydrahon'

  [InvalidArgumentException]
  Could not find package 'clancats/hydrahon'.

  Did you mean this?
      clancats/hydrahon

I don't know if it's related with my version of composer (it should be pretty recent), but I will make a PR to solve this because I don't think there's any version where the name without single quotes would cause an issue.

Thanks!


No user VBL or framecounter in 1.3?

Checking out the exciting new version of LDOS today, and I realized that the interface now does not offer the global framecounter nor the user-specified VBL callback. These were very useful features IMHO.
In kernel.asm it seems the user callback and SVAR_VBL_COUNT is still there, but there is no place in the jumptable to install one or get the frame count.
Are these gone for good?

you're right it's a bit confusing. The counter is now synced with 50hz music driver tick. You can get it using LDOS_MUSIC_GET_TICK.
But I just figure out it's incremented only if you have music. I'll add a global counter too.

Aha! Is the counter reset if a new module Is loaded/started? A global counter is useful!

yes right now LDOS_MUSIC_GET_TICK counter is reset to 0 when you start the music. I'm adding a global counter also right now :) online soon

LDOS_GET_CLOCK_TICK , done :)

Awesome! :)

btw I just figured out I did a bug adding global clock tick. This clock was already incremented by trackloader so incremented by 2 each tick. I just pushed a fix

Good to hear!
What about the user VBL callback, will it be reinstalled? It is not in the kernel jumptable anymore, but the code is still in the kernel.

have to check that, I want to get rid of it. ( I want everything "VBL" synced to be on user side only ). The only reason I keep the VBL right now is just the fade-to-black at boot time... :)

Ok, so I will prepare for no LDOS VBL then! :)
Another thing: the installer now lists all files as "tmpSrc.bin" in the output... :-)

oh that's unfortunate! I'll do a fix for that.
Btw I'm interested to know: is the VBL removal an issue for you? to me all user fx use their own VBL or Copper interrupt handler. But maybe I'm wrong. What's your typical use case for this LDOS VBL irq handler?

Thanks!
 There's no real need for one, and gives more control to be able to cut out the VERTB interrupt.
I am doing a demo now, and have used the callback feature a couple of places, but I can happily switch to setting my own interrupts. :-)

Btw,  I am very happy to see LSP included. Actually I just now tested a modeule that P61 had serious problems with, but LSP handled it perfectly. Looking forward to use it!

glad you like LSP. My main concern about p61 was that the converter is amiga only and it's pretty hard to use on windows platform. LSP is suited with the windows LDOS toolchain

Ok, so I will prepare for no LDOS VBL then! :)
Another thing: the installer now lists all files as "tmpSrc.bin" in the output... :-)

I just tested and that's not what I see when building the sample demo.

Ok, I see I was unxlear.  I meant the lines under 'loading'. Above and at the end they are listed with their names. Sorry!Sendt fra min Galaxy
-------- Opprinnelig melding --------Fra: Arnaud Carré @.> Dato: 06.12.2021  21:21  (GMT+01:00) Til: arnaud-carre/ldos @.> Ko: "Torkild H. Lyngstad" @.>, Author @.> Emne: Re: [arnaud-carre/ldos] No user VBL or framecounter in 1.3? (Issue #4)
Ok, so I will prepare for no LDOS VBL then! :)
Another thing: the installer now lists all files as "tmpSrc.bin" in the output... :-)
I just tested and that's not what I see when building the sample demo.
—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android.


Can't set LabelText on FloatingActionButton

        var fabViolation1 = new Clans.Fab.FloatingActionButton(this);
        fabViolation1.ColorNormal = Color.ParseColor("#272B35");
        fabViolation1.ColorPressed = Resource.Color.accent;
        fabViolation1.ButtonSize = FloatingActionButton.SizeMini;
        fabViolation1.LabelVisibility = 1;
        fabViolation1.LabelText = ExamManager.Instance.LightViolationList.Find(a => a.ID == 1).Description;
        fabViolation1.SetImageResource(Resource.Drawable.icon_fab_end_exam);

fabViolation1.LabelText gives a NullPointerException.

My mistake, sorry!


Require support for the realse notes

I found that there are no release notes for each released version. It is hard for users/developers to know what happened between two different versions. Thanks a lot!

Yes, you're right. I'll create a release notes file.
In general, there should not be any incompatible changes, just bug fixes.


Any plans of llvmlite migration?

One of bitey dependencies - llvm-py (https://github.com/llvmpy/llvmpy) is now deprecated and is replaced with llvmlite (https://github.com/numba/llvmlite). Are there any plans to migrate bitey from llvm-py to llvmlite? Thanks!

Oh. I didn't have any specific plans, but that's a good idea.

Thanks! I will explore the migration to llvmlite.

I've been using llvmlite in my compilers course.  Switching from llvmpy was relatively straightforward if my memory serves.  Bitey is a bit unusual in what it does so I don't know if that will also be the case or not.  However, making this work with llvmlite would be great as it comes shipped by default with Anaconda.

I took a brief look at llvmlite.  It can almost be used for bitey--almost.  It's missing the ability to get argument types and result types from the functions in imported LLVM bitcode modules.   This makes migration impossible at the moment.  However, it might be possible to explore some workarounds.  Perhaps an upstream patch to llvmlite to make it work.

Should be there by now, no? function.ftype?

I can't look at it right this moment, but if this is something that got added and someone thinks they can make it work, I'd definitely be interested!   Bitey is not large so I'd encourage some playing around.


Feat: Backend Changes to Fetch Updated User Data in BlogPage||Darkmode on BlogPage

Description:
This PR addresses the following issue:

Implementing Dark Mode for the Blog Page's new UI
Updating the backend to fetch updated data from the Author's Profile on both the Blog Page and Blog Component

Changes Made:

Added Dark Mode using Context API
Modified the BlogCollection schema:

Removed: AuthorTitle, AuthorCaption, AuthorImage
Added: authorID

Each time the blogs load, the authorID will be matched with the respective author's ID from the UserCollection. The author data, including designation, image, and caption, will be fetched from the UserCollection, eliminating the need for AuthorTitle, AuthorCaption, and AuthorImage in the BlogCollection. This ensures that the author's information is always up-to-date.

Issue Mentioned:
#Closes 1025
Video:
https://github.com/user-attachments/assets/441d2423-2a32-4871-8400-2227438e571f
Additional Context:
N/A

@shreyash3087 Please update the sync fork and resolve conflict. I am merging Ayushmaan's PR, so you need to update the sync fork and conflict as well.


Token Stored in Plaintext

Thanks for a great plugin! A note on GitHub access tokens, they are currently stored in plaintext in Vault. For anyone syncing with GitHub, iCloud, Dropbox, OneCloud, etc. this is something to be very aware of.
File: .obsidian/plugins/github-embeds/data.json
{
  "githubToken": "gho_[REDACTED]",
  "embedIssues": true,
  "embedFiles": true,
  "labelDisplay": "preview",
  "autoOpenThreshold": 10,
  "dateFormat": "YY.MM.DD",
  "showTotalComments": true
}

Thanks for pointing this out! I'll probably merge #19 for now and then look into other methods of handling this properly (or as best I can within the confines of the Obsidian plugin environment lol).

@MrGVSV you're welcome! Thank you again for the plugin. I think crypto is the easiest. This looks promising as potential route.
You could also just come right out and say "DO NOT use your elevated permissions access token - make a new, read-only PAT" or something.
Happy holidays!

I think crypto is the easiest. This looks promising as potential route.

Yeah this could work. Of course, it would only be a bandaid until Obsidian exposes some way for a plugin to safely store user secrets (i.e. we need to store the encryption key somewhere so a malicious plugin could still find and decrypt the token).
I'll still look into adding it, but I really wish there was a better way of achieving this. 🤔

It's definite not straightforward, but may be another good example.
I'll also do some digging on this.

It's definite not straightforward, but may be another good example.

Yeah this works but I'm not sure about asking the user to input an encryption key every time they open the app. We could maybe make that an option for users who do need that kind of security but it's not an ideal UX imo.

Reopening as I would like a proper solution for this in the future (even if we do need to wait for Obsidian to provide an API for it).

@MrGVSV I started doing some research into this. How do you feel about storing a random-string encryption key in a user's home directory?
This would be used to store the key by which PATs are encrypted and decrypted to/from  .obsidian/plugins/github-embeds/data.json.
Spitballing before committing to anything.

How do you feel about storing a random-string encryption key in a user's home directory?

Would this solution be cross-platform? I believe the NodeJS API is desktop-only.

Interesting! Thanks for this, @MrGVSV. Back to the drawing board — I'll dig into the Obsidian docs.

@MrGVSV the complexity and overhead of cross-platform encryption with node are daunting.
I propose:

Refactor Settings actions to read/store GH token to/from separate config file
Refactor DisclaimerSection to mention "Add this file to .gitignore if syncing with remote repo..."

I'd be happy to make these changes and submit an RFC/PR. Let me know what you think!

@dgrebb That works for me as long as we can make it work cross-platform! 😄


bug: leetup test stop working in windows

In windows 11, when i run :
leetup test two-sum.cpp -t "[1,2]\n3"
The error is :
thread '' panicked at 'called Result::unwrap() on an Err value: NotSupported', C:\Users\liran.cargo\registry\src\mirrors.tuna.tsinghua.edu.cn-df7c3c540f42cdbd\spinner-0.5.0\src\lib.rs:164:37
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
Status: 403 Forbidden
Note: If error status is 4XX, make sure you are logged in!
I made sure I am logged in, but this error is still.
❯ rustc --version
rustc 1.72.0 (5680fa18f 2023-08-23)
❯ leetup --version
leetup 1.2.4
thanks!

Can you try with RUST_LOG=debug leetup test two-sum.cpp -t "[1,2]\n3"

sorry, I don't know about rust language.
In windows 11, RUST_LOG=debug not recognized.
Are there other ways to debug?
i am using PowerShell 7.3.6

I don't have a windows machine to reproduce the issue. Can you try this https://stackoverflow.com/questions/18433840/logging-rust-programs

thanks, i will try it

Two separate points in this issue.
The first one is there seems having bugs in the version (1.2.0) of spinners crate that using by leetup currently. But it's working with 4.1.0 on Windows.
Technically, term crate depend by archived spinner-0.5.0 crate is the source where the error msg thread '' panicked at 'called Result::unwrap() on an Err value: NotSupported' comes from and spinner-0.5.0 crate got removed after spinner 2.0 (https://github.com/FGRibreau/spinners/commit/5481120e9).
The second one is testing without -t is not only broken on Windows but Linux.
The testdata param in graphql is not proper prepared while unwrapping None for Option<Option<String>> since nothing provided in command line.
This data should come with problem info from API or may extract from the first example input I guess.


Upgrade clamav k8s ingress version

The code here upgrades k8s version for clamav ingress, minimal k8s version to 1.19 per the deprecation guide.

This would be a huge help, as the clamav chart cannot apply with ingress enabled on my cluster as of now.


typo fix some typos in docs

Change-Id: Ib3b448c7d03f8418fd7654922617743c7d752475
Proposed changes
Issue Number: close #xxx
Problem Summary:
Fix some typos in docs.
Checklist(Required)

Does it affect the original behavior: (No)
Has unit tests been added: (No)
Has document been added or modified: (Yes)
Does it need to update dependencies: (No)
Are there any changes that cannot be rolled back: (No)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

LGTM


*: Bump version v4.0.9

This PR is used to bump TiKV version to v4.0.9
Release note

No Release Note

/run-all-tests

/run-check-release-note

/run-all-tests


Tweak System Configuration and Run Command sections

Settings section:
Not sure if possible, but it would be nice, to have "Enable remote Services" and "Update" to be set as Favorites out of the box after install.
I am pretty sure these two are the most uses things, and for me, they are shown at the top.
"disable low battery warning" - it is not in caps, unlike every other option, maybe change it to "Disable Low Battery Warning"
Shorten some of the options:
"Restore Default Retroarch Settings" - "Reset Retroarch(64) Settings"
"Restore Default Retroarch Core Settings" - "Reset Retroarch(64) Core Settings"
"Restore Default Retroarch32 Settings" - "Reset Retroarch(32) Settings"
"Restore Default Retroarch32 Core Settings" - "Reset Retroarch(32) Core Settings"
"Restore Settings" - "Restore ArkOS Settings"
Run Command section:
It would be nice to rename the whole section to just Libretro at etc/emulationstation/es_systems.cfg
It also could be nice to add some minor description and stock art for retroarch 32/64 too:
https://imgur.com/a/AAOqVQW
	<desc>RetroArch is a free, open-source and cross-platform front-end for emulators, game engines, video games, media players and other applications.</desc> 		<image>/roms/launchimages/ra32.png</image>
	<desc>RetroArch is a free, open-source and cross-platform front-end for emulators, game engines, video games, media players and other applications.</desc> 		<image>/roms/launchimages/ra.png</image>

Most people don't know what Libretro is.  Better chance they've heard of Retroarch.

Not going to set  "Enable remote Services" and "Update" as that could potentially cause more support questions like the low battery indicator does for the rgb10, rk2020, and OGAs.  I'll let the individual users decide on that for their use case.  As an example, even though I regularly use those 2 features, I expect to only see games I regularly play in Favorites.

I've accommodated the following with today's update

[ ] Renamed "disable low battery warning.sh" "Disable Low Battery Warning.sh"
[ ] Renamed "Restore Default Retroarch Settings" - "Reset Retroarch Settings"
[ ] Renamed "Restore Default Retroarch Core Settings" - "Reset Retroarch Core Settings"
[ ] Renamed "Restore Default Retroarch32 Settings" - "Reset Retroarch32 Settings"
[ ] Renamed "Restore Default Retroarch32 Core Settings" - "Reset Retroarch32 Core Settings"
[ ] Renamed "Restore Settings" - "Restore ArkOS Settings"