Syntax too cryptic?

I know it's early days for this project, and perhaps too soon to critique anything - but I'm following along, as I've been very interested in Sinuous for a while now, and this promises to be a "rewrite of Sinous", and I would love to see those ideas evolve from here. 🙂
I'm looking at the example, and frankly I'm finding it a bit obscure. One of the things Sinuous has going for it, is it's reasonably intuitive to get started with - I really wouldn't like to see that get lost in a rewrite.
So here's my (full disclaimer:) really opinionated comments, take'em or leave'em. 😁
import { wS, wR, v$ } from '../src/wire/index.js';

☝ These functions need proper names.
I think I pointed you to dipole already? This has fairly intuitive naming, once you're used to the terminology: observable(value) creates an observable value, computed(() => { ... }) creates a computed reaction, reaction(() => { ... }) creates reactive effects, and so on.
I also like that Dipole's observables make reading and writing explicit with .get() and .set(value) methods - it requires slightly more work on the keyboard, but makes it much easier to skim through a large chunk of code and spot where the reads/writes are taking place. Opinionated, but readable code is more important than writable code: you only have to write it once, but you have to read it many times, your coworkers have to read it, and so on.
const data = wS({
  text: '',
  count: 0,
  countPlusOne: wR(($): number => {
    console.log('Conputing countPlusOne');
    return data.count($) + 1;
  }),
  countPlusTwo: wR(($): number => {
    console.log('Conputing countPlusTwo');
    return data.countPlusOne($) + 1;
  }),
});

☝ These APIs need to be consistent.
Why does wS accept an object with many observable values, and reactions mixed in?
The text and count observables, and the countPlusOne and countPlusTwo reactions, do not have any relationship with each other, as far as I can figure? I don't think there's any compelling reason to pack unrelated initializations into a single function - so I'd prefer these two functions were more consistently both singular factory functions, something like:
const data = {
  text: observable(''),
  count: observable(0),
  countPlusOne: reaction(($): number => {
    console.log('Conputing countPlusOne');
    return data.count($) + 1;
  }),
  countPlusTwo: reaction(($): number => {
    console.log('Conputing countPlusTwo');
    return data.countPlusOne($) + 1;
  }),
};

This is already more readable, consistent and intuitive - it should simplify typing with TS as well.

Here's math:
      {wR(($) => data.count($) < 5
        ? Math.PI * data.count($)
        : `Text: "${data.text($)}" is ${data.text($).length} chars`)}

☝ Too many dollar signs 💸
I think I get what you're trying to do here, and I love the fact that the reactive context isn't somehow established by some magic behind a dark curtain.
Side story: I recently made a friend try out Sinuous, and the magic actually bit him. He had a parent component that contained a reactive expression - and in a child component that was used in that reactive expression, he thought he could safely read from an observable, in a section of the child component's code that wasn't reactive. Which you absolutely can - but the reactive expression in the parent component will pick up the usage and associate it with updates of the parent, which caused unexpected updates. It took him a very long time to fix this. That's nasty and frustrating learning curve, and it's something anybody is likely to run into at first.
Dipole has the same problem, btw.
Fixing that would be awesome.
But the syntax here is a bit ugh - manually passing that same argument again and again everywhere.
Also, you end up unnecessarily reading the same observables more than once. (which, yeah, you could assign the values to variables first, but then almost nothing dynamic would ever be just a single, elegant expression, so, ugh.)
Did you consider maybe something like this instead?

Here's math:
      {reaction([count, text], (count, text) => count < 5
        ? Math.PI * count
        : `Text: "${text}" is ${text.length} chars`))}

This is even more explicit - though perhaps too explicit, and creates subscriptions on things that might not actually be used, so, meh. You might could get around that with even more explicitness:

Here's math:
      {reaction([count], count => count < 5
        ? Math.PI * count
        : reaction([text], text => `Text: "${text}" is ${text.length} chars`)))}

This gives you the right subscriptions but, eh, that's not pretty.
Yeah, I'm not really sure what to suggest here. 🤔
And this last thing:
    <input value={wR(data.text)}/>

☝ I know that's actually the same operation as the other reaction - that data.text is the reader function, and it'll receive the $ argument, so it's equivalent to the redundant wR($ => data.text($))... but it looks like two completely different things.
I know Sinuous does something similar, allowing observables to be used directly in expressions, where it'll create the reaction for you, but it's not a favorite feature of mine either...
I like consistent patterns in UI libraries - where you recognize operations intuitively, without parsing.
I don't know, maybe this is yet another thing you just have to get over - but it's worth thinking about learning curve and adoption rate. Not at all cost, of course - but it's not as much fun being the one guy who gets something, going through life struggling to get other people to get it, and I think that's really the key to React's success, and certainly to the introduction of hooks, even though those are absolutely horrendous and nasty behind the curtains.
I wouldn't want to trade off good or clean or correct for something magical that "looks cool", but is there something we can do to make this more intuitive and palatable?
I hope you don't find any of this too offensive, but feel free to tell me to f_ck off and mind my own business. 😄

Thanks for the write up - lots to unpack and respond to but having a critique means a lot. I'll message back soon :)

Here's something I thought of this morning.
Since you like grouping states into "container" like structures, how about something like this...
const data = container({
  text: '',
  count: 0,
  countPlusOne: (({ count }): number => {
    console.log('Conputing countPlusOne');
    return count + 1;
  }),
  countPlusTwo: (({ count, countPlusOne }): number => {
    console.log('Conputing countPlusTwo');
    return countPlusOne + 1;
  }),
});

How this might work:

container internally creates a prototype with getters for every given property.
values become observables, functions become computed reactive expressions.
what gets passed to a computed is an instance of that internal prototype already bound to the $ context.
when you destructure e.g. ({ count }) from that instance, you're actually calling a getter that tracks the dependency and reads it's current value.

It looks nice, but what do you think, could that work? 🤔

Hi thanks again for feedback about the project. I've definitely been at it too long and can't see the forest from the trees anymore; things feel intuitive to me but I can only guess how it comes off to others. Also, you're right that it is in the early stages, and I didn't want people to see the "examples/index.tsx" as an intro or an example - it's only my syntax testing area to make sure it doesn't crash and TS is happy - but I have no docs/intro yet so it's fair that you're critiquing it.
I'll make a real intro and move the syntax testing off the repo. I think that's the right option for working in public, otherwise people get confused and that's totally fair.
I've made a lot of design decisions through evaluating different options and choosing the least bad of them, sometimes I'll have big code comments about that, but I've meant to be better about documenting how/why those decisions are made. Your comment is a good opportunity to start that.
I'll address your message bit by bit.

... and this promises to be a "rewrite of Sinuous" ... I really wouldn't like to see that get lost in a rewrite.

I've actually never mention trying to be a rewrite or replacement of Sinuous 😅 That's a non-goal! I love Sinuous, and I think it's doing great. We just have different goals: I focus on TypeScript, JSX, and having as-little-code-as-possible; Sinuous is into JavaScript, HTML tag templates, and having a lot of additional packages in a monorepo like sinuous/{data, template, map, hydrate, etc}.
I see this in Solid too, which has a lot of packages linked together across different repos, npm packages, and code editions - it's a lot of code to search through and understand.

☝ These functions need proper names.

They have proper names actually. I import the shorthand because I'm me, but they're actually exported as wireSignals and wireReactor. Also, they have JSDoc comments so you should be able to hover over the element and it'll talk about it.

Speaking of making a proper intro, $v is more of an edge usecase, when you're working with a large team or interacting with code you haven't written or don't trust. It shouldn't be in an intro/example. I'll talk about naming below when I talk about the choice of "$" tokens.
I'll consider a more descriptive name like createNamedSignals() and createReactiveContext() but as part of the "no magic" rule I need reactive expressions to be explicit, and in JSX that means:
There are {items} items
 isn't good enough. There has to be a reactor. I actually changed haptic/dom to serialize functions specifically so it's clear that passing {items} is wrong and won't silently fail - it'll print the whole function body to the page. That's why I chose wR because it's small. You could use the full version...

The text is {wireReactor($ => data.text($))}

But... I don't know if I can sell that in a way people will use. In a intro/readme I'll explain the long form first and then say "Don't worry you can shorten this to just wR(data.text)".

I think I pointed you to dipole already? This has fairly intuitive naming ...

Yeah it's a pretty common naming schema. Sinuous does it too. I have pretty much the same thing, observables ➡ signals, reaction ➡ reactor (which I get from Reactor.js). I specifically don't have a third "computed" type; it's confusing to people that in other reactive libraries a computed is kind-of-a-signal in that you can read/sub it but you can't write to it. Even in my initial port of Sinuous' engine I called them "WritableSignal" and "ComputedSignal". In Haptic Wire a computed-signal is literally a signal. There's only ever one signal type, and I know I haven't described that very well. One sec...

☝ These APIs need to be consistent.
Why does wS accept an object with many observable values, and reactions mixed in?
The text and count observables, and the countPlusOne and countPlusTwo reactions, do not have any relationship with each other, as far as I can figure?

Yeah again I need to intro what's happening here. Thanks for calling it out! So there's actually a super important reason for packing it as a single object; signals/reactors have names! 😁 Like real names! They appear in stack traces and make debugging super easy in the console.

Useful too when looking into a reactor:

Especially lovely for errors

I haven't seen anyone else do this before.
I get that you like const count = observable(0) but due to JS evaluation order there's no way to know the name unless you do count count = o(0, 'count) which I don't think anyone will want to do. I want people to have autocomplete too, and having a single object gives them that - they can type "data." and the editor shows them all the signals available. I'm also against your computeds-as-functions proposal for this reason too, I don't think you can unpack the signals into a function during its own initialization and have successful autocomplete due to limitations of the TS compiler https://github.com/microsoft/TypeScript/issues/43683.
You mentioned getting bit by signals. When an error throws or something isn't linked up right, it's so important that you have names for free. No work! No compiler hacks (like https://github.com/luwes/sinuous/issues/78) to inject a name!
So about computed-signals and reactors in the wireSignals block. PR here https://github.com/heyheyhello/haptic/pull/1 this is honestly some magic. Feels bad, but I want people to be able to use a function as a value in a signal and no have anything odd happen; I have no interest in intercepting a random function. If I need to introduce special behaviour it has to be with a data type I own - I only have signals and reactors, and it's important that there's only one type of a signal. Reactors are computation engines, so it followed that passing a reactor into a signal creates a computed-signal. That's some magic, which doesn't feel great. Many I should have a dedicated createComputedSignal but at the end of the day it's still going to be a normal signal, which means you can write a value to it. If I write "10" to a computed-signal, the computed is gone, and it's now just a container for "10". In Sinuous/others you can't write to a computed because they're special.

☝ Too many dollar signs 💸

But Dipole constantly writing ".get()" every time is not too much? 😉 I picked a symbol because I want it to read as English and doing data.count(sub) or data.count(s) (which actually I used to use s back in the day) reads as the plural "data counts"? Isn't that weird? Open to other symbols!

... ugh - manually passing that same argument again and again everywhere.

You said yourself that you only write code once and read it a ton more.

Did you consider maybe something like this instead?

Yeah I did and didn't like it. I went with making "$" an unpacker function (with type safety too!)
const [count, text] = $(data.count, data.text);

☝ I know that's actually the same operation as the other reaction... I know Sinuous does something similar

Ok I'm glad that clicked! Yeah I agree it's a bit of magic. I'll write about it in an intro. Yes I totally stole that from Sinuous haha. Again, I want to be explicit but I want it to be short enough to have a good developer experience... I hope it's still more explicit than Sinuous' inline ${count} magic syntax. Also, in the screenshots above, you'll see "wR:1{wS:2{count}}" and that naming only happens when using the shorthand syntax, since using $ => ... is an anonymous function so the reactor doesn't get a name. So with the shorthand notation you can tell at a glance in the console that the reactor's job is to simply print a signal to the page, nothing else.
Re: https://github.com/heyheyhello/haptic/issues/5#issuecomment-827397013

... you like grouping states into "container" like structures

I actually just like names!

... functions become computed reactive expressions.

Ok but I want to store functions in signals and have them be untouched. How do I do that? I'd have to pack/unpack it in an object/array to sidestep Haptic touching my function? That's why I picked reactors, since that's a data type I can have control over.

Part of the naming is for debugging like doing a JSON stringify of a reactor

You can see the function body right next to the signal names and reactor names.
This actually isn't reproducible rn since I've paused the dev bundle work to work on other things. The last time I was serializing reactors was in https://github.com/heyheyhello/haptic/commit/9f16cec8cac138c96628decac0a458566c2d7efb#diff-e3953e774715849eafdab3fdea6846ca283fadf588237fcb4c019a028419e17b but I'll be back soon!

I've actually never mention trying to be a rewrite or replacement of Sinuous 😅 That's a non-goal!

I'm sorry, I misquoted you! The README says "fork of Sinuous", and my assumption was wrong. 😊
(I might suggest something like "inspired by Sinuous" or "borrowing ideas from Sinuous", or maybe even leave Sinuous out of the description altogether, since this looks and feels quite different.)

They have proper names actually.

Oh, I know - I just wish you would give them more down-to-earth names. wireReactor is the most important, because you'll be using that everywhere, and it's the first thing people will be exposed to. I'm not wiring a nuclear reactor, that sounds terrifying. 😅 ... I wish you would go with just reaction, like Dipole - a reaction is the thing we're trying to get out of it. Since you'll be typing this more than anything, it's also nice that this doesn't involve pressing the SHIFT key - typing wR takes me longer than typing reaction and typos are more likely. It also, as said, doesn't read well, since there's not an actual word you can recognize on the page. (I sort of wish $ could be described with a two or three letter word for the same reasons - it's clumsy to type and it looks noisy.)
I realize that's completely opinionated, and feel free to ignore these comments! But Sinuous, to me, personally, reads a lot better than the two-letter abbreviations and $ signs everywhere. I understand (and agree with) your arguments for the explicit call to create reactions, type-safety and all, but that in itself already adds a lot of parens and dollars-signs, making it harder to parse and read. Using proper words decreases the per-character density of symbols, which (for most people, perhaps other than dyslexics) makes it overall easier to parse and read.

Yeah again I need to intro what's happening here. Thanks for calling it out! So there's actually a super important reason for packing it as a single object; signals/reactors have names! 😁 Like real names! They appear in stack traces and make debugging super easy in the console.

I can see that - I actually did something similar in an experimental state management library for React a couple of years back, but ultimately abandoned the idea. For one, it forced a grouping of potentially unrelated dependencies - you loose the "atomicity" of individual observables, you have to work with these state "molecules" instead. It wasn't practical when your component has only a single state value.
Presumably, with your implementation, you can still "pull off" one of the individual observables and pass it around though? They're not coupled to each other per se, right? You're just using the object syntax as a means of ensuring the observables have a name in the source-code that correlates with a name at run-time? I definitely don't hate that. 😁
It's completely individual how you'd weigh the pros and cons here, so I completely respect if that's the way you want to go. 🙂

I get that you like const count = observable(0) but due to JS evaluation order there's no way to know the name unless you do count count = o(0, 'count') which I don't think anyone will want to do.

I think it would be nice to have the option though, since that's actually what it's doing at a low level, right? I mean, for a component with only a single state value, this isn't any better:
let count = wS({ count: 0 }).count; // count, count, count!

At least with let count = o(0, 'count') you're only repeating yourself twice.
Also, maybe the name could be optional, since it's not required for anything other than debugging? All these names will add to the overall source footprint of an application, and the repeated data. dereferencing also contributes to footprint and causes a minimal run-time overhead - so it might be nice to have the option to go the Sinuous route and forego the extra debugging convenience in favor of "smallness". It's only "free" in terms of effort - names always leave a source footprint.

But Dipole constantly writing ".get()" every time is not too much? 😉

Well, but it's a word - I can skim across the page and recognize the word "get" easily. With something like Sinuous, it's much harder to recognize () in a sea of other parens and other symbols. Words are just inherently (for most people) easier to parse than symbols, much less pairs of symbols, which requires you to parse as well...

You said yourself that you only write code once and read it a ton more.

...yes, but words 😄

I want to allow storing functions into signals and have them be untouched. How do I do that?

In situations like this, I like to use an explicit "value cast", e.g. value(() => { ... }) - this would return a boxed value, so the container knows you want the actual function and not a reaction.
To me, it's a question of weighing the most likely use-case. How often do you really want to put a function in an observable? Seems like this would be pretty rare, compared with how often you'd want to compute something.
It's not an incredibly important point for me though - if you want to stick with object properties as a means of establishing logical names, I'd be fine with something like this as well:
const data = wire({
  text: observable(''),
  count: observable(0),
  countPlusOne: reaction($ => data.count($) + 1),
  countPlusTwo: reaction($ => data.countPlusOne($) + 1),
});

The main point for me is use words - make it easy to spot all the observables and reactions being wired together. 🙂
(By the way, $ => data.count($) + 1 should work fine without the explicit return-type, right? The return-type can be inferred?)

I've been thinking about your comments on the naming of exports and on anonymous signals. Sorry to leave you hanging, I'm moving houses right now. I see where you're coming from - I'm not sure I agree, but I tried it in a new branch at https://github.com/heyheyhello/haptic/tree/haptic-wire-signal-subscriber. It adds 21 bytes (min+gzip) to the bundle. It's doable.

I don't actually think pressing the shift key is an issue; if I'm wrong then they can always alias the import. I don't like "wS" though, and I do like "signalObject" more in this new branch...
I don't think reactors are scary, but then again, I think nuclear energy is a beautiful thing 🌺. However, if that's truly what people immediately think of then that's not great, so thanks.
A "reaction" to me is one single event, rather than a thing/device that reacts multiple times. In this project if you define a reactor it reacts multiple times. I see what you mean though. In the new branch I called it a "subscriber" (rather than subscription) and I think "sub" is short enough to inline in JSX like "wR" was. Not sure how I feel about it next to the recent rename of "h" to "haptic/dom"... naming is hard.
I actually find it really interesting that you talk about the difference between words and symbols. I guess we're wired differently, and that's fine, but I treat symbols like emojis - I don't parse or read them, they just exist and modify the vibe of the sentence. Also jQuery used "$" heavily so I thought the symbol was familiar to others...

Naming is really hard. I spent a ton of time in a thesaurus haha.  I was hoping the shared prefix and two-letter short form indicated that.

... you have to work with these state "molecules" instead

Yes like Flux/Redux state stores. It's popular and my coworkers love it... For single state values you can use wS/wR like:
function SimpleComp() {
  const local = wS({ count: 0 });
  return
....{wR(local.count)}...

}

Even tighter you can do const { count } = wS({ count: 0 }); and that's only two uses of "count", not three. It's also type safe since you have to unpack as "count" but with signal(0, 'count') you're open to making a typo in the naming and never seeing it in code since the name is internal.
I'd also argue that it's harder for a JS minifier to remove the name for signal(0, 'name') because it's a function parameter - minifiers don't want to touch that. Meanwhile in React it's the default to use state/setState with an object and minifiers are OK mangling object keys. We use this at work all the time to obfuscate the code.

... dereferencing run-time overhead

Sorry but I'm not interested in debating the performance run-time overhead of an object lookup... I think effort is the important thing to offer for "free"; everything else we have tools for like minifiers and source maps.

I can skim across the page and recognize the word "get" easily

I like that functions are bold in most colour themes. I get that not everyone has colour themes like that, but I think the bold stands out enough that using "get" makes the actual signal name fade into the background.

I'd be fine with something like this as well

Function names are immutable, so I'd have to wrap them, which adds to the size of every stack trace... I'll think about it more :)

By the way, $ => data.count($) + 1 should work fine without the explicit return-type, right?

I wish but no. It's a limitation of the TS compiler. I picked the best of many bad options as seen in the TypeScript Playground link at https://github.com/microsoft/TypeScript/issues/43683

I like these names better, though I still with it sounded less like technical jargon and more like everyday words - for example, I really like Dipole's "action" and "reaction", and I think part of the reason React succeeded with hooks is by "dumbing it down" to mostly plain english phrases like "use state" and "use effect".
IMO there's no shame in naming things naively, as opposed to being technically correct. Ordinary people have to build ordinary things on top of these core concepts - when things already have ordinary names, it encourages people to do the same, which leads to a more inclusive community.
Naming things is hard. My own personal struggle is not usually to find the correct computer science terminology - but rather to find plain english words that help people relate to the concepts. 😊

Even tighter you can do const { count } = wS({ count: 0 }); and that's only two uses of "count", not three.

Nice, I hadn't thought of that. 🙂👍

I like that functions are bold in most colour themes.

This is in deed a good point! I had only been viewing/editing in the <textarea> here, so I hadn't thought of that. Forget "get" 😁

By the way, $ => data.count($) + 1 should work fine without the explicit return-type, right?

I wish but no. It's a limitation of the TS compiler.

Ugh. 😕
I remember having similar issues when attempting to write a type-safe IOC container for TypeScript a couple of years back, I also eventually gave up on that for the same reason.
Typing out redundant type-hints for every closure is going to be a big detractor for me.
It's pretty frustrating when you hit a complete dead-end in TypeScript - where you can describe exactly what it is you want, but TypeScript just won't let you do it. The inconsistency with double-nested closures is just straight up wonky. 🤨
Anyhow.
Thanks for the discussion, and feel free to close this issue. 🙂

Thankfully you never need to manually specify the type for signals or reactions, only when defining a computed-signal that uses signals defined in its own object/molecule. The TS issue is about "data" referencing itself in in its own initializer. So it's pretty rare to need to manually specify the type, and, oddly, if you specify the wrong type the compiler will error 🙃 which means it's pretty safe.
Some people like to have a separation of concerns too and might opt to storing computed-signals in a different object entirely, in which case there is no error.
I'll leave the issue for a bit while I write docs/intros and decide on naming. Lots to think about.

I'll leave the issue for a bit while I write docs/intros and decide on naming. Lots to think about.

I appreciate your considering my input - I'm quite interested in seeing where this project goes! 🙂

The TS issue is about "data" referencing itself in in its own initializer.

This was exactly the issue with my IOC container, it had the exact same type relationship - here's the question and answers on StackOverflow, sadly with no happy conclusion:
https://stackoverflow.com/questions/51176441/how-to-declare-generic-mapped-types-for-this-dependency-injection-container-in
I'm pretty sure I opened an issue in the TS repo as well, but I couldn't find it...

Wait a minute. If I'm required to call wR explicitly wherever I want to create a reaction, isn't that enough? 🤔
I mean, doesn't that mitigate the risk of accidental subscriptions in itself?
I guess I can see how explicitly passing the $ context also removes element of "magic" though.
But I might want to take one step first and see how that works out in practice.
I might try it out in my own toy Sinuous clone to see how that pans out. 🙂

Yeah no the $ token is important because while you're right that wR is explicit for a reaction, it's only explicit at the top level, like that function body only. So in other libraries calling  doThing() inside your reaction doesn't tell you if it'll subscribe to things, but in wire you have to explicitly give consent to the function by giving it a valid $ token as a parameter (that's also where v$ comes from, if you don't want to give that consent)
Wire is opt-in while other libraries use sample() to opt-out. I didn't like that because the only safe way to call a function is to always wrap every function call in a sample()...

Yeah, hmm.
What if we implicitly created a reactive context at every component boundary?
I realize that would result in a lot of "unused" reactive contexts with no subscribers - but I've been wondering, in the reactivity layer, what if we had a function that only creates a context if the function actually subscribes to something? If the function doesn't subscribes, no harm, it just returns the value of the function call as it would anyhow, but no actual listener gets created.
That could work?

It could work but why tho... I think passing a parameter is the most explicit and least magic way to do it.
I did a weird thing with arguments.caller in my haptic-reactivity repo (different repo) way back where I isolated by function call. Subscriptions were always limited to their function scope. For nested functions you had to choose to merge its subscriptions into the reaction (called "sFrom()") or explicitly ignore them ("sIgnore()")... Not sure if the code would be useful if you're trying to implement something similar with function boundaries.
I don't think I'd prefer it over what wire currently does

It could work but why tho...

Convenience.

I think passing a parameter is the most explicit and least magic way to do it.

Definitely.
Are there any practical uses of $ for anything other than passing it back to observables?
If it isn't of any practical use to the developer, I think it makes sense to hide it somehow. In that case, hiding it is probably less "magical" and more "abstraction", e.g. hiding an implementation detail.
Is there anything meaningful a developer can do with it, other than slavishly passing it along?

There has to be a way to differentiate between a read-pass (neutral? read) and a read-subscribe. This code will update when count changes but not when text changes:

Number is {wR($ => data.text().length + data.count($))}

I'm not too sure how this could hidden unless you use sample() but I want wire to be opt-in not opt-out.

Number is {wR(() => sample(data.text().length) + data.count())}

Also I know I haven't written an intro - busy moving/unpacking still - but this is also where void tokens come in:
import { thirdPartyLatLngRecalculation } from '@company/someOtherTeam';
//       ^ function($: SubToken): [number, number];

Number is {wR($ => {
  thirdPartyLatLngRecalculation()
  // ^ Expected 1 arguments, but got 0. ts(2554) An argument for '$' was not provided.
  return data.myStuff($)
})}

You can fix this by calling it as thirdPartyLatLngRecalculation($v). This will skip subscriptions and TS is ok with it.
They should have typed their function as function($ = v$): [...] but every developer has dealt with an npm package that has a bug needing a workaround...

I'd like to try it out, but you haven't published to npm in 6 months?
I tried to add it directly from https://github.com/heyheyhello/haptic/tarball/haptic-win codesandbox, but I don't think that's supported - I was able to install it from tarball locally with a real npm, but would prefer to work in a public sandbox so we can review and discuss the results together.
Publishing unstable work with tag next is pretty conventional, I think? 🙂

Let me know how "core" feels!

Still extremely confusing. 😅
I had to dig into the source-code to understand which was what, then into the source-code, the git history, and the deleted example... I finally arrived at something like this:
import { signal, core } from 'haptic/wire';

const value = signal("foo");

core($ => console.log("value:", value($)));

value("bar");

It doesn't work, but it doesn't error either. As said, TS isn't picking up the types, so I'm flying blind - but from reading the source-code, I think this looks right? I'm a couple of hours in, and I still don't have a working "hello world". I feel dumb now. 🙄
You did mention this earlier:

I went with making "$" an unpacker function

Did you? The type declarations don't seem to reflect that change though? Not sure, as I'm reading them manually, as said TS isn't picking them up... If you did change this, then reading a value now would be the reverse call, right? $(symbol) would return a Sinuous-style reader/writer?
core($ => console.log("value:", $(value)()));

That didn't work for me either - no function I pass to core ever seems to get called.
I noticed in a comment somewhere, it says "activate the core by manually running it", so I tried that as well:
const value = signal("foo");

core($ => console.log("value:", value($)))();
//                                        ^^ <- activate?

That does print undefined, at least - but not the signal's value. And doing something like value("bar") afterwards, trying to update the value, does not call the function again.
Well, I'm lost. Let me know when there's a working example, some documentation, or some tests I can refer to. 😊

I'm eager to know how this pattern would work in practice.
Since I can't get your code to work, today I tried changing dipole to explicitly pass in context, just to see how different that would be. For observables and computed values, this was actually straight forward. For reactions, not so much - it needs to track the parent reaction so it can dispose of nested reactions, and there's no obvious way to do that. Manually passing the parent reaction to nested reactions looks and feels weird.
I looked the old example, which you deleted, but it didn't have an example of nested reactions.
Do you have a plan for that, or do you have any idea what that would look like?
To be clear, I mean reactive expressions, like (in Sinuous) for example:
    ${() => currentTab() === "A"
      ? <FormA/>
      : <FormB/>)}

Where FormA and FormB contain two different forms (that you can toggle with currentTab) which have entirely different reactions - when switching between tabs, these forms would get created/destroyed, and their reactions would be to different observables. How would you go about passing down the reactive context that gets created if it's explicit?
    ${wire($ => currentTab($) === "A"
      ? <FormA/ context={$}>
      : <FormB/ context={$}>)}

Not pretty. 🤨
Or will this bit still be "magic" and tracked via global state in Haptic?

I hope my questions didn't make you quit? I'm still really interested in this idea. 🙂

Heyy no not at all; life is just busy. I started working fulltime in software and have university, partners, and friends on top of that. I seem to not be doing a lot of hobby programming lately 🌲🚵. I haven't forgotten about your comments or my projects! They're on a list! Just have a lot of lists :) That's definitely part of not having published a new version in a long time. Thanks for your patience
With the lil energy I do have I've been putting it towards https://github.com/heyheyhello/acorn-macros. I mentioned it a bit in #6 that "[Haptic's] blocked on porting styletakeout.macro from Babel to Acorn so I can have CSS-in-JS". It's close tho! It fully works sync but still need to fix it for async and then do tests, docs, publishing etc etc... Haptic will come soon 🌺
You've got me here now tho so lemme answer your posts!

Publishing unstable work with tag next is pretty conventional, I think? :slightly_smiling_face:

OH! That's an AMAZING IDEA. Thanks! I've actually never made use of that in any other projects but it absolutely takes the edge off of publishing.

It doesn't work, but it doesn't error either.

Yeah your code is "fine" 😅. Reminds me a bit of writing just <App/>; in a React entrypoint - it won't mount on the DOM or do anything, but it's there...
In Haptic, like Dipole, you need to activate a core to start things. When you do core($ => {...}) you're defining it but it has never run (and never read any signals either). You do:
const c = core($ => {...});
c(); // Start!
value("bar");

I'll be sure to document that very carefully! It's in a JSDoc comment right now too but I'll be more explicit.

$(symbol) would return a Sinuous-style reader/writer?

Um no it's actually just supposed to make unpacking less painful to write. In Sinuous I often wanted to read a bunch of signals, something like this in Haptic:
core($ => {
  const [a, b, c] = [data.a($), data.b($), data.c($)];
  // Do stuff with the now-read values
})

Which works. But I made $ work also as /** Allow $(...signals) to return an array of read values */ which lets you write this: (Note that a, b, c will have the correct data type in TypeScript).
const [a, b, c] = $(data.a, data.b, data.c);

Just a shorthand.

That does print undefined, at least - but not the signal's value.

Huh that's odd. I'll make sure there's a test case for that :)

Manually passing the parent reaction to nested reactions looks and feels weird.
I looked the old example, which you deleted, but it didn't have an example of nested reactions.
Do you have a plan for that, or do you have any idea what that would look like?

Yeah! I definitely don't recommend passing $ as a context no no no. Nested relationships occur naturally based on JS function execution - this is what happens in Sinuous too. When a core runs, it's set as the "currently active reaction" and if another core is already in that spot, they're linked as parent>child. When the a parent core is destroyed it takes down its nested cores with it. S.js and Sinuous call this "automatic memory management" and I comment that in my code as well.
As for your "Tab" example, I often do this in Haptic:

  {when(core(($) => data.count($) > 5 ? 'T' : 'F'), {
    T: () =>
There have been more than 5 clicks
,
    F: () =>
Current click count is {core(data.count)}
,
  })}

You could do your method of a basic core ternary without using when but then flipping the ternary branches back and forth would constantly destroy and recreate new DOM elements and nested cores. Lots of wasted work!
In when the elements and cores are lazily created and then cached in memory - no work. Plus the branches that are "off screen" (the hidden tabs, in your case) have their cores paused so no work happens in the background even if signals are still firing, those cores are frozen. Hopefully that makes sense.

Or will this bit still be "magic" and tracked via global state in Haptic?

Haha sure it's magic ✨. Every library that I've used for reference and inspiration has done nesting this way, so, I'm doomed to repeat it :)

In Haptic, like Dipole, you need to activate a core to start things.

I see, hmm, well... this is actually something I objected to about Dipole:

The thing that puzzles me is, what do you actually have, if you haven't called the run method yet?
You don't really have a reaction yet - if it hasn't run the function, it doesn't know the function's dependencies, and so it can't actually react to anything yet.
When is an "inactive" reaction useful? Or why isn't the reaction automatically run the first time?

In your case, it's a factory function rather than a constructor - but the question is the same: if it's just variables bound to a scope (a context that doesn't actually work yet) what use is it? When or why would you want that?
If the intention is to defer... something? I can't think of what, but that was the Dipole author's argument... if you don't want the function to be run yet for some reason, just defer it's creation - don't make it the consumer's responsibility to "finish running the constructor" for you.
If you want the expose an internal factory function that doesn't fully initialize, that's fine for special use-cases maybe - but I don't think it makes sense as a default? It's really surprising when you call a constructor or factory function, and it returns something that doesn't do the one thing you want it to do. I don't think I'd be the first or only person to get hung up on that.
(fwiw, S.js initializes by default, and I don't think that's ever been a problem.)

I definitely don't recommend passing $ as a context no no no. Nested relationships occur naturally based on JS function execution - this is what happens in Sinuous too. When a core runs, it's set as the "currently active reaction" and if another core is already in that spot, they're linked as parent>child.

When teaching Sinuous to new users, I've found this is a serious stumbling block for them though. They end up accidentally subscribing, in a child-component, to updates from a parent component, leading to unexpected updates - which, in some cases (for example, if the parent context is a reactive expression that toggles a component on/off, or toggles between one or more types of components) can lead to unexpected recreation of the child-component and, subsequently, loss of any state it had. This has been the most frustrating and time-consuming problem for new users of Sinuous, from what I've seen.
If they come from, basically, any other framework, they do not expect updates to propagate into child components - almost all mainstream frameworks have update boundaries at the component boundaries.
State is generally local to component instances, and... I realize we don't have component instances in Sinuous/Haptic, but we do have JSX-style <Component/> tags - and it's really hard for new users to think of these as "just function calls", when in practice the result is something similar to having component instances with local state.
I realize it's not implemented that way - that you could do e.g. {Component({...}, [...])} as a JSX expression and it would work just the same, but... since we have the JSX component-style syntax, conceptually, it's natural for users to think of components in JSX as "component instances". (It would be surprising if they didn't.)
I think we have to let our brains soak on this for a bit? 🧠💭
If we want this type of framework to really catch on, it has to work without any major stumbling blocks. And I'd like it if we didn't resort to things like linters and run-time error messages like hooks for React. 😝
Ergonomics and "early success" is important. There's gotta be some way we can fix that. 🤔

I know you've objected to it lol, I was in that thread and mentioned this library, Haptic Wire. I understand your frustration with it but I still like the separation of concerns. I'm sure there's a lot of people who'd love if React would just automatically mount the entry-level component so they could skip the "useless" React.render() call ;) In the Dipole thread you linked I also made a comment about vanilla DOM nodes - I think I'm mostly trying to be consistent the ecosystem around me.
As an analogy, create a core is me giving you a computer.  I tell you there's a power button to turn it on when you're ready. This is useful if you need to install other components like a GPU which are more difficult to do once it's running. It has a nice computer-shape that feels like a computer (x instanceof Reaction === true) with all the ports you need (TS object shape is valid) so it can be given to functions that are specific/fragile and require a computer. If I put the computer in a box to defer it then these features are lost. There's no way to access it until it's too late and already running. "It's fine if it's already running by the time I get it" you say, well....
The most common thing people want to with reactivity is wire it to the DOM. Like <input value={core($ => someSignal($).toString())}. Two big things here:

In Haptic cores aren't lazy. They're primarily meant to auto-run when subscribed signals update. Manually calling them when no dependencies have changed will still cause a full re-execution.
For this reason, you're not really supposed to read from a core. They're closer to being my version of Sinuous' subscription() function, not its computed() function. There's no magic memo/cache store by default. Instead, you should read from signals because they do store their value; it's cheap to access and doesn't involve any execution*.
Calling the core factory function returns a core. Calling a specific core returns its computation result.

(Now that I've said that out loud I actually think your wire($ => ...) naming might be more clear since I'm confusingly using "core" to refer to both an instance and a factory function...anyway...)
So, if core(...) produced a core that ran automatically then that <input attribute would receive the string content. Not a core. Which is a problem because Haptic DOM never had a chance to actually see and feel the core to install that GPU :) Problem. If I make cores auto-run I can't inline them.
Let's say I somehow overcome this - maybe I change it so calling a core returns itself kind of like how D3 does chaining. However, now calling the component that has the <input will 1) Execute the core, sending the computation result into the void and returning itself, then 2) Be patched by Haptic DOM, which now needs to call it again and do the computation again, which, if the core author had any kind of counter-like logic would be confusing and off by one.
Lastly, if someone needed to get the computation result but the core only returns itself, you either patch the c.fn like Haptic DOM does or you author it like core($ => { return (x = data.sig($)); }...
🤷♀

Unless it's a computed-signal. Then it does lazy evaluation of a core. https://github.com/heyheyhello/haptic/pull/1. This is basically my version of Sinuous' computed(), except it's a signal. I always thought it was a bit backwards that Sinuous' subscription function, by definition, doesn't need/use any caching layer and yet it's implemented under the hood using a computed - it just ignores the whole variable-store mechanism altogether and only uses it for its auto-run functionality... I didn't like that

I honestly can't cope with all those details. 😅
Just. Did you see this note?

if you want to defer the initialization of something, just don't create it yet

But maybe the problem here is I'm creating the instance in my code - and then the framework is supposed to further initialization before activating the instance?
It still seems awfully surprising. Getting an instance that doesn't work. And the car analogy really doesn't work for me. It would be more like receiving a brand new car, but you have to open the hood and connect some wires before you can drive it for the first time. The way I was taught programming, objects should have certain guarantees - they should be born in a complete, working state. If you ship a car with missing parts or disconnected wires, well... no one would be very happy with the car company. 😉
Anyhow, if the reason is the shared responsibility between client code and framework code for actually building and initializing the instance, then, yeah, there might not be any way around it. I don't have to like it though. 😆

(Unless maybe the revealing constructor pattern could help?)

I gave it another try and still can't get it to do anything.
const value = signal("foo");

core($ => console.log("value:", value($)))(); // prints `value: undefined` 🤨
//                                        ^^ core activation 🚀

value("bar"); // does nothing 🤷♂

Like I said I haven't touched Haptic in a while; it's not published because it's known to be in a half-baked state. I have other priorities and have been working on acorn-macros https://github.com/heyheyhello/acorn-macros/commit/e30a758c591d0b2ec79ae16bf998e796e515a6ac.
When I publish a new version of Haptic (even under haptic@next) you'll be the first person to know! :)
The issue you're experiencing is from a bad //@ts-ignore made a variable slip through the renaming from "Reactor" to "Core". You can change line 199 in wire.ts from  && args[0].wR)) { into && args[0].wC)) { and you'll be good to go. I pushed the fix in 163ec1785f3c003f63a6758f6b4546e47567ed35 and will make note to use less ts-ignores... which is hard sometimes because TS has real bugs I need to workaround 🙃

It's alive! 😄
Thanks, this gives me something to play with until you're ready to return to this project. I have a half-baked Sinuous clone based on Dipole that already mostly works, and I want to try to replace Dipole with this, just to see what it feels like in practice.
I will post my results, maybe there's something useful there to help this project move along. 🙂

I'm going to close this issue - I can't promise the syntax isn't cryptic but it sure has changed a lot since we started this thread. Good talk! Lots of ideas from here made it into v0.10. Thanks! When more syntax/cryptic questions come up we can start in a new issue or discussion.


Null pointer dereference in msre_op_within_execute

v2 reoperators.c:
static int msre_op_within_execute(...) {
[...]
if (str->value == NULL) {
*error_msg = "Internal Error: match string is null.";
return -1;
}
[...]
if (error_msg == NULL) return -1;
*error_msg = NULL;
The last 2 lines must be at the very beginning of the function

Hi @marcstern,
I believe you are trying to refer to this part of the code -
https://github.com/SpiderLabs/ModSecurity/blob/28b4be670fc7d02bb6388034032d0061b56c8b64/apache2/re_operators.c#L1998-L2006
The check does not necessarily need to be on the top of this function, but, before the utilization of the error_msg.
Are you willing to submit a pull request?

Before the utilization of the error_msg, indeed.
I don't have the time for a pull request for the moment, as I would need to re-clone everything - unless https://github.com/SpiderLabs/ModSecurity/pull/1577 is merged, so I can reuse the same environment.

I am afraid o don't catch what this has to do with #1577. Even if #1577 got merged, yet, it is outdated by itself. Therefore, the tree update will be necessary. But, I do understand that you have opted to not proceed with the pull request. Thank you for your report.

Hi @marcstern,
As of 176276a931a6d61db38b908237c9aad1cea0d6ad this is no longer an issue. Thank you for the report.


heroku: 3.43.12 -> 3.43.16

Motivation for this change
This is the last version of the deprecated client but using the latest CLI.
We also lose the broken fhs wrapper script because the CLI is now compiled instead of just downloading the binary.
Fixes: #15262 and #20752
Things done

[X] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[X] Fits CONTRIBUTING.md.

rasen@Larry ~/nixpkgs> ./result/bin/heroku pg:psql --app heutagogy
/usr/bin/env: ‘ruby’: No such file or directory

Adding ruby to binPath helps, but now:
rasen@Larry ~/nixpkgs> ./result/bin/heroku
 ▸    dashboard is not a heroku command.
 ▸    Perhaps you meant whoami?
 ▸    Run heroku _ to run heroku whoami.
 ▸    Run heroku help for a list of available commands.

(though, all other commands work fine.)

I have ruby in my global path, so maybe that's why it runs here without it. I have just added it in and running ./result/bin/heroku --help (and the other subcommands) work fine although I do get the peculiar message, when run without any arguments.


The field that converts the EOS tokens to the fiat equivalent does not work.

version: fairy-wallet_0.9.6_amd64
ledger live version: 1.1.11_amd64
operating system: Ubuntu 16.04 LTS

Problem 1:
The field that converts the EOS tokens to the fiat equivalent does not work. As seen in the screenshot, when I enter 6.00 I should get more than 1 EOS, however it does not convert it into EOS. I would also suggest labeling the fields to the following to make it more user friendly.
Example:
Token:    Quantity:      Cash:
EOS          1.1257        6.00
Problem 2:

If the user enters an amount for any EOS token, the fiat equivalent is grayed out or not usable. As seen in the screenshot, when I enter 200 for the IQ token, the fiat equivalent is not recognizing any amount that I enter.

Try as a workaround to change in settings currency value to EUR and back TO UDS. Its not initialized first time.

Right now we have only EOS equivalent. Other tokens that have Fiat value are not available.


Strategy to deal with listeners on $window

Hi,
I have a service which tacks listeners on the window object (via $window). It seems like the $window object is not re-initialised after each test is run (which makes sense). However, this poses a problem when I have services that add a listener. The listeners add up every time a test has run causing my test to fail. I know I can use afterEach, however, it's not always obvious the service is being used when writing tests for another directive/service. This sometimes causes tests to fail in non-obvious ways. I've tried this approach: https://gist.github.com/plestik/d722633cd77164c4e02f but it's pretty hideous to be honest. Is there a better way to deal with this issue?

If using angular, one can mock the $window object using $provide, that way the listeners do not pollute window.
This isn't really a karma issue, and can probably be closed.

thanks @wesleycho, agreed


How to summarize a text using pre-trained models?

Hello,
I have a text of about 70-80 words in a .txt file.
I want to summarize it using the pre-trained model.
Please guide me stepwise how to do.
It is difficult for me to understand due all the complex parameters and as I am getting started at this.

Hey!
Coincidentally, someone already asked this question, here.

Hi @yasersakkaf
Did you find the solution for your question?
I followed the discussion in other issue as well, but I still needs to know how can I use the pretrained model to finetune on my dataset. I also need to know how should I prepare the binary files from my data which is in form of text files.
Any help appreciated! Thanks.

I am afraid the ANSWER IS NO.
But I found some other repo which may be helpful for you too.
please use the link below
https://github.com/Currie32/Text-Summarization-with-Amazon-Reviews

Hi All,  do not fret! I'll clean up my code and post it within the end of the week. I was able to use my own dataset and do both: train a model from scratch and also use the pre-trained model.
Stay tuned!

Thanks @yasersakkaf
@landmann Great! I'll be await of update.

If you want to convert your own data(.txt) to binary data (.bin)
You can clone below repository:
https://github.com/dondon2475848/make_datafiles_for_pgn
Run:
python make_datafiles.py  ./stories  ./output

It processes your test data into the binary format .

@landmann ...Hi Landmann, Can you tell how you used the pre-trained model and fine tuned the pre-trained model? It would be very helpful for me. Thanks in advance!


3.2 BETA 6 - Android Crash - No implementation found for double_tap(int, int) exception.

Godot version:
3.2 BETA 6
OS/device including version:
Windows 10 Pro  64 bit 1909
Issue description:
Since updating to BETA 6, my Android app now crashes when the screen is touched too rapidly. Same app worked fine in BETA 5. This issue is present when using regular Android deployment, as well as a custom build. Logcat output points to:
java.lang.UnsatisfiedLinkError: No implementation found for void org.godotengine.godot.GodotLib.double_tap(int, int) (tried Java_org_godotengine_godot_GodotLib_double_1tap and Java_org_godotengine_godot_GodotLib_double_1tap__II)
Steps to reproduce:
Deploy an app to Android and tap the screen rapidly
If you need any more information, please let me know. Thanks.

Regression from #33630, CC @AlexHolly.

Can confirm. Happens to me as wel l.


clifm: init at v1.1

Motivation for this change
New package
Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[X] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Added a release notes entry if the change is major or breaking
[X] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 125052 at f91e1123 run on x86_64-linux 1

1 package built successfully:

clifm

2 suggestions:

warning: unclear-gpl
gpl2 is a deprecated license, please check if project uses gpl2Plus or gpl2Only and change meta.license accordingly.
Near pkgs/applications/misc/clifm/default.nix:56:5:
   |
56 |     license = licenses.gpl2;
   |     ^

warning: maintainers-missing
Package does not have a maintainer. Consider adding yourself?
Near pkgs/applications/misc/clifm/default.nix:52:3:
   |
52 |   meta = {
   |   ^

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

1 package built:

clifm

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


Theme is not visible for selection

Hi! First of all thanks for this tool!
I'm using CSS Starter.
Here's how i'm trying to test my theme:

Build project
Copy jar archive to docker image using command

docker cp build_keycloak/target/custom-1.0.0.jar docker-image-hash:/opt/keycloak/providers/custom.jar

Restart docker

After doing that i don't see my custom theme anywhere, it's not available for selection.
If i extract jar archive and put it using the same command directly to themes folder, so
docker cp build_keycloak/target/custom-1.0.0 docker-image-hash:/opt/keycloak/themes/custom

I still can't see my theme in
Realm Settings -> Themes -> Login theme
neither in
Realms -> My realm -> Clients -> My client -> Settings -> Login settings -> Login theme
Any ideas about what I'm doing wrong? Thanks.
p.s. in dev mode (npm start) theme looks good

hi @garronej , thanks for the answer. Yes, this is what i did and described at step 2:
docker cp build_keycloak/target/custom-1.0.0.jar docker-image-hash:/opt/keycloak/providers/custom.jar

so in /opt/keycloak/providers appears my custom.jar archive, and restarting the docker has no effect

@inomn Ok sorry I didn't read carefully enough.
Have you tied with the theme of the starter to see if it's detected: https://github.com/garronej/keycloakify-advanced-starter/releases/download/v1.0.6/standalone-keycloak-theme.jar
https://github.com/garronej/keycloakify-advanced-starter/releases/tag/v1.0.6

@garronej thank you, i find an issue. I thought keylock build providers automatically on launch, but actually, I missed the build command in my docker file. Now I see my custom theme, and the issue I have now is that the form action is # instead of actual URL, looks like
<form id="kc-form-login" action="#" method="post">

trying to find the reason. with default theme action is right and login works

Thank you for reporting.
I'll close this, you can open another issue about your other problem.
Is the new problem you are experiencing also hapening with the theme from keycloakify-advanced-starter?
Best


Remove useless submitList

I removed that line because in certain situation it causes the adapter to show empty items when it has to show searched posts.
It works as it is intended to without calling submitList(null).
It happens when the response from the api is faster than submitList(null). Because submitList() checks diff on the background thread, it can return empty list after the api response, resulting the adapter to show empty list.

i signed it!

@googlebot I signed it!

Closing this out as it's no longer applicable to the new sample.


Adds AddTaskCommand, DeleteTaskCommand, EditTaskCommand

Codecov Report
Base: 61.82% // Head: 57.29% // Decreases project coverage by -4.52% :warning:

Coverage data is based on head (f7cea34) compared to base (e19ab14).
Patch coverage: 7.85% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff              @@
##             master      #52      +/-   ##
============================================
- Coverage     61.82%   57.29%   -4.53%
- Complexity      399      403       +4
============================================
  Files            84       87       +3
  Lines          1438     1576     +138
  Branches        149      169      +20
============================================
+ Hits            889      903      +14
- Misses          517      638     +121
- Partials         32       35       +3

Impacted Files
Coverage Δ

...main/java/seedu/address/commons/core/Messages.java
0.00% <ø> (ø)

...a/seedu/address/logic/commands/AddTaskCommand.java
0.00% <0.00%> (ø)

...eedu/address/logic/commands/DeleteTaskCommand.java
0.00% <0.00%> (ø)

.../seedu/address/logic/commands/EditTaskCommand.java
0.00% <0.00%> (ø)

src/main/java/seedu/address/model/Model.java
100.00% <ø> (ø)

...rc/main/java/seedu/address/model/ModelManager.java
76.19% <11.76%> (-23.81%)
:arrow_down:

src/main/java/seedu/address/model/AddressBook.java
66.66% <23.07%> (-25.00%)
:arrow_down:

...ain/java/seedu/address/logic/parser/CliSyntax.java
91.66% <100.00%> (+8.33%)
:arrow_up:

...c/main/java/seedu/address/model/task/TaskList.java
7.35% <0.00%> (+7.35%)
:arrow_up:

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

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


Fix do_close() to avoid condition check errors with concurrent requests.

Currently dynamodb-beaker uses Item.partial_save() to update session data,
which internally performs a conditional write.
As a result if a client sends multiple AJAX requests at once (i.e. a race condition happens),
there's a good chance that some of them fail randomly.
This pull request is a (partial) fix to the problem described above, with allowing do_close()
return gracefully if it was just trying to update the 'accessed time' field.

I'll release this fix as ver.0.1.2, thanks!


Clean up eventing duck types

Clean up eventing duck types.

Introduce Addressable to unify delivery ducks.
Remove Subscribable and Channelable (moved to knative/eventing).
Mark Sinkable and Targetable as retired in favor of Addressable &
annotations for Callable.

See https://docs.google.com/document/d/1xu18lprM8EFknqrsyZeNgYX2sLE13hfT2UKlYfdxv1g/edit#
for interface/naming details.
/assign @vaikas-google @scothis @n3wscott
I selected status.address.hostname as the equivalent of status.domainInternal previously; this seemed like the right mix of explicit and structured.
We'll need to merge this into knative/serving and update the Route and Service, hopefully for 0.2.1 (0.2 will continue to work with the old status.domainInternal).

Updated, thanks.

Thanks, LGTM, but will leave final /lgtm to @vaikas-google or @n3wscott

/lgtm


ceph --cluster cluster osd stat -f json parses wrong output

Bug Report
The task https://github.com/ceph/ceph-ansible/blob/f2bd8ae70f0ae5d0c7c7a36bd6ecdad6383feed9/roles/ceph-osd/tasks/main.yml#L87 parses output from "ceph --cluster cluster osd stat -f json" wrong.
It appears that the commit https://github.com/ceph/ceph-ansible/commit/b9cb0f12e9e79600f1a974dd88ba1ed1d833211f changed to ceph osd stats, and some of the checks were later removed.
I have tested in main branch, stable-4.0 and stable-5.0 branch and they all are affected by the same error.
What happened:
When upgrading form nautilus to octopus, with the stable-5.0 branch, the mons are running nautilus during the first check, and the playbook fails, as the output from osd stats on nautilus is different from octopus.
TASK [ceph-osd : wait for all osd to be up] ***********************************************************************************************************************************************************************************
Monday 06 September 2021  15:46:15 +0200 (0:00:00.045)       0:06:47.097 ******
fatal: [ceph-osd03.test.netic.dk -> ceph-mon01.test.netic.dk]: FAILED! =>
  msg: 'The conditional check ''(wait_for_all_osds_up.stdout | from_json)["num_osds"] | int > 0'' failed. The error was: error while evaluating conditional ((wait_for_all_osds_up.stdout | from_json)["num_osds"] | int > 0): ''dict object'' has no attribute ''num_osds'''

What you expected to happen:
Upgrade of ceph to complete
How to reproduce it (minimal and precise):
Checkout master or stable-4.0 branch and run rolling upgrade play.

Share your group_vars files, inventory and full ceph-ansibe log
Environment:

OS (e.g. from /etc/os-release): Ubuntu 20.04 LTS
Kernel (e.g. uname -a): Linux ceph-master01 4.15.0-115-generic #116-Ubuntu SMP Wed Aug 26 14:04:49 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Docker version if applicable (e.g. docker version): N/A
Ansible version (e.g. ansible-playbook --version):
root@ceph-master01:~# ansible-playbook --version
ansible-playbook 2.9.13
config file = /etc/ansible/ansible.cfg
configured module search path = [u'/root/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
ansible python module location = /usr/local/lib/python2.7/dist-packages/ansible
executable location = /usr/local/bin/ansible-playbook
python version = 2.7.17 (default, Feb 27 2021, 15:10:58) [GCC 7.5.0]
root@ceph-master01:~# ceph-ansible version (e.g. git head or tag or stable branch):
Ceph version (e.g. ceph -v):
ceph version 14.2.22 (ca74598065096e6fcbd8433c8779a2be0c889351) nautilus (stable)

When upgrading form nautilus to octopus, with the stable-5.0 branch, the mons are running nautilus during the first check

the mon should be running octopus at this point


Make umount fuse properly when killing the process

What changes are proposed in this pull request?
fix issue: https://github.com/Alluxio/alluxio/issues/13239
We should treat umount as a no-op when umount timeouts due to the fuse device is busy.
parent PR and context:https://github.com/Alluxio/alluxio/pull/13373
Does this PR introduce any user facing changes?
Yes. The Fuse process may not be killed if device is busy.
Test step you can see https://github.com/Alluxio/alluxio/pull/13875

Codecov Report

Merging #13876 (e9f2f09) into master (19655ac) will decrease coverage by 26.08%.
The diff coverage is 0.00%.

@@              Coverage Diff              @@
##             master   #13876       +/-   ##
=============================================
- Coverage     43.60%   17.51%   -26.09%
+ Complexity     9097     2675     -6422
=============================================
  Files          1386     1387        +1
  Lines         80634    80690       +56
  Branches       9812     9819        +7
=============================================
- Hits          35158    14131    -21027
- Misses        42534    65309    +22775
+ Partials       2942     1250     -1692

Impacted Files
Coverage Δ

...rc/main/java/alluxio/worker/block/FuseManager.java
18.42% <0.00%> (ø)

...n/fuse/src/main/java/alluxio/fuse/AlluxioFuse.java
0.00% <0.00%> (ø)

.../main/java/alluxio/fuse/AlluxioFuseFileSystem.java
0.00% <ø> (-58.64%)
:arrow_down:

...in/java/alluxio/fuse/AlluxioJniFuseFileSystem.java
0.00% <0.00%> (ø)

.../src/main/java/alluxio/fuse/FuseSignalHandler.java
0.00% <0.00%> (ø)

...ion/fuse/src/main/java/alluxio/fuse/StackMain.java
0.00% <0.00%> (ø)

...n/java/alluxio/jnifuse/AbstractFuseFileSystem.java
0.00% <0.00%> (ø)

...mon/src/main/java/alluxio/shell/CommandReturn.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...mon/src/main/java/alluxio/util/ExceptionUtils.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...n/src/main/java/alluxio/wire/AlluxioProxyInfo.java
0.00% <0.00%> (-100.00%)
:arrow_down:

... and 670 more

Continue to review full report at Codecov.

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

Overall LGTM, lets wait for https://github.com/Alluxio/alluxio/pull/13875 merged and then rebase this PR

My test step:

mount fuse dir with alluxio-fuse script
/integration/fuse/bin/alluxio-fuse mount /Users/chenliang.lu/soft/alluxio_data/fuse_data /fuse_data

open operation in fuse dir
less /Users/chenliang.lu/soft/alluxio_data/fuse_data/a.txt

fail to umount fuse dir

The file in the fuse directory is closed.
umount fuse dir successfully

@LuQQiu These two PRs are basically independent and do not affect each other.These two PR is ready now.

@yabola can we make the fuse kill logics similar to the master/worker process kill logics? like using -s as soft kill etc

@LuQQiu OK. But the default behavior before this PR is only kill pid. If add '-s' option,it may change the default behavior(default kill -9 pid if timeout).

@yabola I am not worried too much about changing the behavior since the old Fuse kill behavior may result in a strange state. Better to be same as other processes, thanks!

@LuQQiu
My test step:

mount fuse dir with alluxio-fuse script
/integration/fuse/bin/alluxio-fuse mount /Users/chenliang.lu/soft/alluxio_data/fuse_data /fuse_data

open operation in fuse dir
less /Users/chenliang.lu/soft/alluxio_data/fuse_data/a.txt

umount fuse dir -> forcibly umount fuse dir default
./integration/fuse/bin/alluxio-fuse umount /Users/chenliang.lu/soft/alluxio_data/fuse_data

soft umount fuse dir -> fail to umount fuse dir
./integration/fuse/bin/alluxio-fuse umount -s /Users/chenliang.lu/soft/alluxio_data/fuse_data

@LuQQiu I have updated the related document, please check if the description is appropriate.


phpunit acceptance tests using a model with sluggable failing

Attempting to write an acceptable test using a model that includes sluggable, getting the following error message. It's failing during the setUp function.
  public function setUp(){
    $user = User::create([
      'first_name' => 'Admin',
      'last_name' => 'User',
      'email' =><EMAIL_ADDRESS>    ]);

    $role = Role::create([
      'name' => 'Admin',
      'slug' => 'admin',
      'description' => 'An Admin'
    ]);
    $role->save();
    $user->attach($role);
  }

And the error

1) EditUserTest::test_add_property_function
Illuminate\Contracts\Container\BindingResolutionException: Target [Illuminate\Contracts\Events\Dispatcher] is not instantiable while building [Cviebrock\EloquentSluggable\SluggableObserver].

The error occurs on line that creates the user, which is the model that includes sluggable. Removing that step gets rid of the error (though obviously causes a new one as there is no user to attach the role too).
If this isn't enough information let me know, wasn't really sure what else to include
Laravel version 5.3, sluggable 4.1, phpunit 5.7.20

I'll be totally honest: I don't know what to suggest.
The event system is a bit untested in the package itself, mostly because I'm not sure how to unit test it myself.  You could try disabling events, maybe? (https://laravel.com/docs/5.3/mocking#mocking-events)  Or maybe you are supposed to mock them?
I'm sorry I don't have a good answer for you.  Let me know what you do figure out ... or hopefully someone else will stumble on this issue and comment.

Event::fake() worked, though it can't be used in the setup method so I had to create another function. $this->withoutEvents(); does not work, it looks like you Mockery relies on the packages themselves to provide some kind of template to fake. Here's the error:
BadMethodCallException: Method Mockery_0_Illuminate_Contracts_Events_Dispatcher::until() does not exist on this mock object;
that error message is produced on the line calling the model with sluggable attached, and it's just the user model, so I think the error is with sluggable not the User model.
Event::fake() does what I needed it to do to get around the error at least, so thank you for recommending that! I will do some research over the weekend and see if I can find out how to make event mocks, obviously, it'd be preferable to just skip the events that are failing so I can still test with the rest of them.
Thanks for your helping and for writing sluggable!

The Event::fake() does not work anymore on Laravel 5.5.... The slug just isn't created...

I'm facing the same issue! Using Laravel 5.4 here!

Resolved for me : if you have a setUp method, be sure to call parent::setup() as the first statement in that function.

I am having the same issue under Laravel Framework 5.8.8, not sure why this issue was closed

@wvervuurt  can you please give little bit more info?
Example code maybe.
I can not undarstand how to solve it.
Thankyou.

If you're having the same issue as me, adding $this->refreshApplication(); as the first line to the DataProvider will solve the error. If that doesn't help, maybe you forgot to put Event::fake() in your TestCase's boot method. If that doesn't help, your issue is different than mine and I don't know what could be going wrong.. hope this helps!

Short update from my side.
Sorry for possible offtopic.
I'm using codeception framework.
So when I created the cest like so:
codecept g:cest unit TestingPostModel
the error not appear any more for model where I'm using sluggable.
Codeception have a module Laravel5, so I guess he doing some magic before execution tests, like booting app etc...
Hope this info can help someone.

This topic is about PHPUnit tests failing, Codeception is a different testing framework altogether, so now I understand why previous comments didn't seem to help you. Thanks for adding that info, maybe it helps other Codeception users who test Sluggable models.

A few years on but I found this issue when I hit the same binding resolution issue.
Using Laravel 8, the solution is to extend Illuminate\Foundation\Testing\TestCase rather than PHPUnit\Framework\TestCase and add the \Tests\CreatesApplication trait:
<?php

namespace Tests\Unit;

use Illuminate\Foundation\Testing\TestCase;

use Illuminate\Foundation\Testing\RefreshDatabase;
use Tests\CreatesApplication;

class YourTestName extends TestCase
{

    use RefreshDatabase;
    use CreatesApplication;

    /** @test */
    public function itDoesAThing()
    {
        // Your code that creates a slug
    }
}

A few years on but I found this issue when I hit the same binding resolution issue.
Using Laravel 8, the solution is to extend Illuminate\Foundation\Testing\TestCase rather than PHPUnit\Framework\TestCase and add the \Tests\CreatesApplication trait:
<?php

namespace Tests\Unit;

use Illuminate\Foundation\Testing\TestCase;

use Illuminate\Foundation\Testing\RefreshDatabase;
use Tests\CreatesApplication;

class YourTestName extends TestCase
{

    use RefreshDatabase;
    use CreatesApplication;

    /** @test */
    public function itDoesAThing()
    {
        // Your code that creates a slug
    }
}

Yes, that’s correct

Yes, that’s correct


29 allow non blocking transmit and receive

Updated doc tests now to use include the updated blocking argument for transmit and receive functions


⚠ Bofrost.at has degraded performance

In 9e3b988, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1335 ms

Resolved: Bofrost.at performance has improved in cf1a526.


embed mode and reworked web build system

You can see an example of the built apps here: http://d2w1n8k2hsp0xg.cloudfront.net/dev/index.html
release/deploy_web.sh is intended to accommodate your existing deploy layout, so please let me know if something seems off.
It should produce something like this (though I tested on a different s3 root):
$ aws s3 ls s3://abstreet/
                           PRE dev/
$ aws s3 ls s3://abstreet/dev/
                           PRE abstreet/
                           PRE blog_root/
                           PRE data/
                           PRE fifteen_min/
                           PRE osm_viewer/
                           PRE santa/
                           PRE widgetry_demo/
2021-03-31 18:31:55        206 abstreet.css
2021-03-31 18:31:55        457 abstreet.html
2021-03-31 18:31:55        489 fifteen_min.html
2021-03-31 18:31:56        665 index.html
2021-03-31 18:31:57        463 osm_viewer.html
2021-03-31 18:32:08        456 santa.html
2021-03-31 18:32:09        482 widgetry_demo.html

It presupposes that s3://abstreet/dev/ s3://abstreet/dev/data is uploaded independently of the script, which was my understanding based on our conversation yesterday.

Whoops - I had a typo in the description, I meant that deploy_web.sh assumes you've already uploaded $S3_ROOT/dev/data.

It presupposes that s3://abstreet/dev/ s3://abstreet/dev/data is uploaded independently of the script, which was my understanding based on our conversation yesterday.

ok. I believe I've responded to all of your feedback so far - please take another look @dabreegster.

LGTM! Thanks for exploring the space of bundlers here and finding something simple.
Steps for me:

Finish running deploy_web.sh
Update docs to point to the the new locations of web things
Manually remove some of the old s3 directories (like game)
Fix up the actdev script -- no rush, haven't deployed anything since the workshop a few weeks ago and no need to update

http://abstreet.s3-website.us-east-2.amazonaws.com/dev/ is live!


Remove memoryOverhead recommendations for Standalone Spark

Signed-off-by: Ahmed Hussein (amahussein<EMAIL_ADDRESS>Fixes #553

Add functionality to disable memoryOverhead when spark is standalone
Add unit-test with standalone enabled

@mattahrens I added a quick fix for that.
If the spark.master is set to spark://* then The autotuner assumes this is standalone and the memoryOverhead comments/ recommendations are not added to the output.


Host based routing not working for tcp ports

Bug description
Host based routing on tcp ports seems to be not working. Gateways route traffic to tcp ports which are not described in them. Virtual service routing traffic to destination even if hosts don't match the described hosts.
[ ] Docs
[ ] Installation
[X] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
[ ] Upgrade
Expected behavior
This is the gateway configuration
kind: Gateway
apiVersion: networking.istio.io/v1alpha3
metadata:
name: common--postgres
namespace: database-gateways
spec:
servers:
    - hosts:
        - postgres.internaldomain.com
        - common.postgres.internaldomain.com
    port:
        name: postgres
        number: 5432
        protocol: TCP
selector:
    istio: ingressgateway
---
kind: Gateway
apiVersion: networking.istio.io/v1alpha3
metadata:
name: common--mongodb
namespace: database-gateways
spec:
servers:
    - hosts:
        - mongodb.internaldomain.com
        - common.mongodb.internaldomain.com
    port:
        name: mongo
        number: 27017
        protocol: MONGO
selector:
    istio: ingressgateway

This is the virtual service configuration
kind: VirtualService
apiVersion: networking.istio.io/v1alpha3
metadata:
name: common-mongos
namespace: database--mongodb
spec:
hosts:
    - common.mongodb.internaldomain.com
gateways:
    - database-gateways/common--mongodb
tcp:
    - match:
        port: 27017
    route:
        - destination:
            host: common-mongos
            port:
            number: 27017
---

kind: VirtualService
apiVersion: networking.istio.io/v1alpha3
metadata:
name: common-postgresql
namespace: crunchydata--postgresql
spec:
hosts:
    - common.postgres.internaldomain.com
gateways:
    - database-gateways/common--postgres
tcp:
    - match:
        - port: 5432
    route:
        - destination:
            host: common-postgres
            port:
            number: 5432

common.postgres.internaldomain.com:27017 should not connect to virtual-service common-mongos port 27017
common.mongodb.internaldomain.com:5432 should not connect to virtual-service common-postgresql port 5432
Version (include the output of istioctl version --remote and kubectl version --short and helm version --short if you used Helm)

istioctl version --remote

client version: 1.6.5
control plane version: 1.9.5
data plane version: 1.9.5 (12 proxies)

kubectl version --short

Client Version: v1.18.5
Server Version: v1.18.16-eks-7737de

How was Istio installed?
rancher helm
Environment where the bug was observed (cloud vendor, OS, etc)
EKS + Classic Loadbalancer Internal

TCP Does not have a "Host" header to route on like HTTP. This in progress docs page may explain this better: https://github.com/istio/istio.io/pull/9800

Ah that makes sense, it never crossed my mind that headers are not available for TCP connection. Closing this issue now. Thankyou!


Setup docker container, future
Currently issues with test:prep consistently creating a backup of settings.json, needs investigation
Documentation remains to be done with this PR
Tests that fail currently will not kill http-server and won't restore the settings.json


Request: Theme for SQL Operations Studio

Can you create a new theme for SQL Operations Studio?

Hello @gpattersonm, feel free to create one and send it over https://github.com/dracula/dracula-theme#are-you-going-to-support-editor-x. Thanks for using Dracula!


Update user guide to reflect current features in our application

This is to keep our user guide up to date.

Codecov Report
Base: 74.68% // Head: 74.68% // No change to project coverage :thumbsup:

Coverage data is based on head (fd47910) compared to base (8730c7b).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff            @@
##             master     #124   +/-   ##
=========================================
  Coverage     74.68%   74.68%
  Complexity      497      497
=========================================
  Files            76       76
  Lines          1485     1485
  Branches        155      155
=========================================
  Hits           1109     1109
  Misses          336      336
  Partials         40       40

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

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


feat[CHAOS-785]: add Chaos module support in SMP

This PR has a dependancy on https://github.com/harness/helm-platform/pull/49, PR should be merged as well in order to add CHAOS module support.
In order to install CHAOS module, user needs to toggle the below fields to true in .Values.yaml they are using while helm installation -
global:
    chaos:
      # -- Enable to install Chaos components
      enabled: true

By default, it will be set to false.
If you want to update some configuration values for chaos then it can be handled with the configuration updates as below -
chaos:
  chaos-manager:
    replicaCount: 1
    resources:
      limits:
        cpu: 1500m
        memory: 2048Mi
      requests:
        cpu: 1500m
        memory: 2048Mi

  chaos-driver:
    replicaCount: 3
    resources:
      limits:
        cpu: 500m
        memory: 512Mi
      requests:
        memory: 512Mi

  chaos-web:
    replicaCount: 3
    resources:
      limits:
        cpu: 500m
        memory: 512Mi
      requests:
        cpu: 500m
        memory: 512Mi

Signed-off-by: Sagar Kumar<EMAIL_ADDRESS>

Should demo and prod resource requirements be same ?

Hi @kapilgarg1996 , we would like to keep the per replica resource requests and limits same for both prod and demo as of now.
Anyway, with HA and all in prod, it will be multiple replicas but for a single replica this should be fine for now.


[0.13.x] Backports from develop

See individual commits. These are all PRs currently marked with backport-candidate-13.x.
I'l later also add #2826.

Looks gooks (8c58799)

Added #2826


Setup problems

Thanks a lot for your library.  I think this is exactly what I have been looking for.  I also had the problem you are describeing in your blog post that using shallow rendering is often not sufficient for testing RN components.
I tried using your library but unfortunately I wasn't able to get it to work (yet).
I think I have a pretty standard jest+RN setup, but I wouldn't know what (or where) my  file-that-runs-before-all-of-my-tests.js could be.
I tried just inserting the require('react-native-mock-render/mock') into my individual component test, but that simply led to issues such as
console.error node_modules/react-native/Libraries/Core/ExceptionsManager.js:71
    Warning: Unknown props `keyboardType`, `secureTextEntry`, `underlineColorAndroid`, `selectionColor`, `onChangeText`, `multiline`, `numberOfLines`, `blurOnSubmit`, `onSubmitEditing`, `returnKeyType` on <TextInput> tag. Remove these props from the element. For details, see https://fb.me/react-unknown-prop

Seem like this is not coming from the mock implementation.  Do you happen to have any idea for me how to properly require your library when using jest?

Before that I also had the error message ReferenceError: document is not defined but that was solved by adding
import {jsdom} from 'jsdom'

global.document = jsdom('')
global.window = document.defaultView
Object.keys(document.defaultView).forEach((property) => {
  if (typeof global[property] === 'undefined') {
    global[property] = document.defaultView[property]
  }
})

Just as you are describing in your blog post.  I think it would be very good to also add this to the README of this library.

Hi Jakob! We run our tests with mocha and have a shared setup file. In our package.json we have:
{
  "name": "root-react-native",
  "scripts": {
    "test": "./node_modules/.bin/mocha --require test/setup-tests.js --recursive test",
  }
}

Then we put require('react-native-mock-render/mock') and our jsdom setup in our test/setup-tests.js file.

I accidentally posted too soon. Are you using jest.mock in your tests? We haven't tried using jest specifically. Could you share one of your tests?

So, I figured out how to include a test setup script that runs before the test suite with jest:
in the package.json I added:
"jest": {
  "preset": "react-native",
  "setupFiles": ["<rootDir>/src/test/setup.js"]
},

// src/test/setup.js
console.log('setup test env')

require('react-native-mock-render/mock')

import {jsdom} from 'jsdom'

global.document = jsdom('')
global.window = document.defaultView
Object.keys(document.defaultView).forEach((property) => {
  if (typeof global[property] === 'undefined') {
    global[property] = document.defaultView[property]
  }
})

The setup script is executed correctly, but my component test is still failing with the same Warning: Unknown props error messages.

Are you using jest.mock in your tests?

In this particular component test I'm not using jest.mock

Btw:  I'm also getting an TypeError: ReactWrapper::simulate() event 'press' does not exist error.  I am using this in my test:
const submitButton = wrapper.find(Button)
submitButton.simulate('press')

@jhilden is your component getting mounted? You can check with:
console.log(wrapper.debug());

If that looks good, is it finding the submit button successfully? You should be able to check with console.log(submitButton.debug());. Could you also try calling submitButton.props().onPress(); to see if that works? We've had some issues using simulate on a mounted component and ended up calling functions on the props directly.

I am also getting a lot of similar warnings:
  console.error jest/setup.js:43
    Warning: Unknown props `onLayout`, `keyboardVerticalOffset` on <View> tag. Remove these props from the element. For details, see https://fb.me/react-unknown-prop
        in View (created by View)
        in View (created by KeyboardAvoidingView)
        in KeyboardAvoidingView (created by _LoginView)
        in View (created by View)
        in View (created by _LoginView)
        in _LoginView (created by Connect(_LoginView))
        in Connect(_LoginView) (created by _RootView)
        in _RootView (created by Connect(_RootView))
        in Connect(_RootView)
        in Provider (created by Unknown)
        in Unknown

In my case, however, tests work.
As a workaround, I patched console.error to ignore these messages (as suggested here):
const originalConsoleError = console.error;
console.error = (message) => {
	if (message.startsWith('Warning: Unknown prop')) {
		return;
	}

	originalConsoleError(message);
};

It seems that react-native-mock is not fully compatible with Jest according to this post.
I'm also getting a bunch of those missing props. I'm going to work with this for a bit to see how far I can get. So far, I'm still unable to render a ListView properly as part of my component tree that I'm interested in testing.
I'm hoping to not have to switch to and learn mocha + chai + sinon, etc. just yet as I like that the Jest framework encompasses most of this functionality already.

Hi @jhilden! I've been attempting to look into the issue that you and the others are facing but so far I'm unable to reproduce the issue. I've create a basic boilerplate project here. Would it be possible for you to fork this and see if you can reproduce the issue?

Sorry @kyledecot but I have moved on to a different project, so it's unlikely that I will find the time to jump back to that issue.


[Suggestion]

What you want to be added?
/save-all, to allow people to save the world from discord
/time set, to allow people who have admin to set day and night
/ban, to allow admin role to ban people in server

Look at the config entry for JSON Commands in your config. There you can add custom commands like /time or /ban


[DEVOPS-1131] add ToJSON instance to TLSConfiguration

Description
i needed to turn a TLSConfiguration back into an aeson Value
Linked issue

Type of change

[ ] 🐞 Bug fix (non-breaking change which fixes an issue)
[ ] 🛠 New feature (non-breaking change which adds functionality)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)
[ ] 🏭 Refactoring that does not change existing functionality but does improve things like code readability, structure etc
[ ] 🔨 New or improved tests for existing code
[ ] ⛑ git-flow chore (backport, hotfix, etc)

Developer checklist

[ ] I have read the style guide document, and my code follows the code style of this project.
[ ] If my code deals with exceptions, it follows the guidelines.
[ ] I have updated any documentation accordingly, if needed. Documentation changes can be reflected in opening a PR on cardanodocs.com, amending the inline Haddock comments, any relevant README file or one of the document listed in the docs directory.
[ ] CHANGELOG entry has been added and is linked to the correct PR on GitHub.

Testing checklist

[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

QA Steps

Screenshots (if available)

How to merge
Send the message bors r+ to merge this PR. For more information, see
docs/how-to/bors.md.

bors r+

bors r+

bors r+

bors r+

bors r+


Using hostname breaks the script

Using hostname instead of IP Address breaks the script. Can you add support for hostname please?

Ignore...


Support for controlling HTTP redirect behaviour

Add options and constructor functions to allow redirect behaviour to be controlled

thanks

https://github.com/justinwoo/purescript-milkis/releases/tag/v7.4.0


gom

librealsense
2.35.2 RELEASE

OS
Windows

Please provide a description of the problem

Could you provide details of what you are asking about, please?  Thank you.

Case closed due to no further comments received.


could you provide the results on KITTI val split?

I'm sorry for disturbing you again. I want to do a visual comparison with Disp R-CNN on KITTI val split , could you provide the results on KITTI val split?  Thank you very much.

Download the trained models and results from here.

The results is very large , so the download speed  is slow. Do you have the results which is txt file format,like the KITTI label ?

Which type do you need? If you need pixel-wise depth predictions, the file cannot be small. Try to use a proxy to download the files. You can also run the inference scripts to get the results.

Sorry, I have not  made myself clear. I need the 3D detection results on KITTI val split.

txt.zip
Here are the results for the car category.

Thank you very much for your help.


Major TPS loss when summoning wither with (9) players.

 Maybe the Spark report shows datapacks, not sure. But no other datapack should be affecting TPS.
But besides all of that, upon summoning the wither, the TPS dropped. All nine players were together, so no other chunks were loaded in the world.
It is running Fabric 1.21.
The world is pregenerated for thousands of blocks, and the fight took place in pregenerated chunks.
It has mods like Lithium, VMP, Ferritecore, gpumemleak fix, krypton, modernfix, carpet, etc.
Upon checking the Spark report, all I could really see was that there was a lot of command execution? Is executing commands per person? Or is there a conflict? The lowest my server goes in terms of TPS is 17, when a lot of chunks are being loaded or there are a lot of entities. The only time it's dropped to 5-7 is when we fought the Wither.
Here's the Spark report: https://spark.lucko.me/OlPuMFCxbq

Woops, after further testing, somethings up with my datapacks! One of them is causing TPS lag like crazy... amazing datapack by the way! Highly recommend to anyone who wants a harder wither...


Update the text in the Overview page describing the structure of this document

Update text to match the current structure

Removed from document after restructuring table of contents for better clarity


Sync latest branch docs with main

Motivation
Since we're repointing developers.diem.com to the latest branch, this PR ensures the information is up to date
Test Plan
Regular CI

/canary

:sunny: Canary successful

/land

/cancel

/land

/land

@jsladerman :bulb: This PR is already queued for landing

/cancel

/land

/cancel

/canary

/cancel

/land


scale_value does not scale int to float correctly

"(or possibly, does not scale limited to full entirely, but i have not checked int limited->full)"

It does, just do scale_offset=True

Updated the behaviour such that if the ranges mismatch, by default it will be True


Setup

Codecov Report

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

@@            Coverage Diff            @@
##             master       #1   +/-   ##
=========================================
  Coverage          ?   97.16%
=========================================
  Files             ?        5
  Lines             ?      141
  Branches          ?       21
=========================================
  Hits              ?      137
  Misses            ?        0
  Partials          ?        4

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


Support custom grant types

I had the problem that I am using a custom grant type to sign in the user and retrieve id and access token. Right now, grant types other password are not supported, so this is an attempt to add support for custom grant types.
The fetchTokenUsingGrant function can be used to send a custom grant request to the token endpoint. The logic follows exactly what the fetchTokenUsingPasswordFlow does. I actually moved all the logic out of that function, so the password flow is now just a specialization of the custom grant call.
I also added support for the id_token in the token response. As per spec, the token endpoint can return the id_token as well. For the implementation, I followed the logic of tryLogin, except that I’m skipping the additional stuff from the LoginOptions (users can always do that manually).
To review the change, best look at the diff with w=1 in the URL to ignore whitespace changes. To simplify the http.post call, I used toPromise() to convert the observable into a promise. That avoids having to wrap everything within a Promise constructor (which isn’t the most readable pattern anyway). Unfortunately, that change resulted in a changed indentation, so the diff isn’t that pretty.

Rebased this against the current master.

So there is still no support for custom grant types?

I looked into this earlier today considering that the master has changed quite a lot in the past few days.
I can easily rebase this on top of master, or even generalize this a bit further if desired.
If there's interest, I will gladly move this change in the best direction.

Well, I have to idea yet. Just looking into this library and evaluating it.
I need custom grant types support and found this open issue.
So I guess it's not supported yet..
Can you recommend any other library?

I have made some simple changes to make things easy to extend
#585

Any news about this ? I really need this implementation.

Any news about this ? I really need this implementation.

I gave up to wait for official change and just adopted pull request to my needs and latest version: https://github.com/manfredsteyer/angular-oauth2-oidc/pull/919

For those still following this issue: Support for custom grant types was just merged via #919.


Stream working only with Clappr extension for Chrome

Using this Chrome extension that uses Clappr: https://chrome.google.com/webstore/detail/reproductor-m3u8-hls-play/lcipembjfkmeggpihdpdgnjildgniffl
... I can play this stream: http://livecdn1.news.cn/cnccn/manifest.m3u8
Why can't I play the same stream using Clappr directly?

Playing an http stream in the browser is not the same as in and extension or application scope/environnement.
There are security policies which apply. for example CORS, or attempting to play an http source in an https page, etc...