this.timeout() fails when using ES6's arrow functions

When using Node >= 4 with "use strict" and ES6 syntax for arrow functions, mocha fails:
describe('foo', () => {
  this.timeout(100);
});

# => TypeError: this.timeout is not a function

Using ES5 syntax does work:
describe('foo', function() {
  this.timeout(100);
});

So, which kind of ugly trick does mocha with this?

It binds the function to the test context, which can't be done when using arrow functions. From http://mochajs.org/

Sorry about that!

Thanks.
Why so many "magic" that, at the end, produces problems? Why not this?:
var mocha = require('mocha');

mocha.describe('foo', (suite) => {
  suite.timeout(100);

  suite.it('must love bar', () => ... );
});

No globals, no problematic magic... but just JavaScript.

What you're proposing is a major breaking change and something that's being discussed in https://github.com/mochajs/mocha/issues/1969#issuecomment-160925915 A rewrite might introduce those types of semantics :)

Nice to know. Thanks.

@ibc well, it would have to be
var mocha = require('mocha');

mocha.describe('foo', (suite) => {
  suite.timeout(100);

  suite.it('must love bar', (suite) => ... );
});

but are the two suites the same type? probably not, so then you have multiple variable names like so
var mocha = require('mocha');

mocha.describe('foo', (suite) => {
  suite.timeout(100);

  suite.it('must love bar', (test) => ... );
});

anyway, the arrow operator cannot be used in functions that expect contexts.
I don't envision breaking the BDD UI for #1969--right off the bat, anyway--though I could be persuaded.  It was my hope that we keep the existing API, and introduce a separate package containing the BDD UI.  Mocha will ship with a version of the BDD UI which uses the existing API, but then we can release a new version of the BDD UI package using lambdas thereafter--users can choose whether or not to explicitly upgrade to that package.

Maybe alternative ES6 syntax for describe or suite wrapper might solve this problem:
describe({ feature: 'create stuff' , do () {
    it('abc', () => {
    });
}})

This would at least allow binding at the suite level.

Any update on this? I have this
mocha = require('mocha');

mocha.describe('test', (suite) => {

@mroien this is not a Mocha bug.  the arrow syntax is not a 1:1 replacement for function.  please read up on its limitations

Did anything come of this? I like the proposed solution, if only for my love of arrow functions and aversion to 'this' when it's not required

Since timeout is only relevant with done, why not simply attach the timeout function to the done function.
it('makes sense', done => {
    done.timeout(100);
});

@nomilous this still doesn't work. I've had a similar problem. What works for my case is calling setTimeout inside the it block.

@nomilous synchronous or cases returning a promise can also have a timeout.
@andela-engmkwalusimbi this isn't supposed to work. As @boneskull wrote:

@mroien this is not a Mocha bug. the arrow syntax is not a 1:1 replacement for function. please read up on its limitations

For everyone still wondering about this, ensure you understand what an arrow function implies, then come back here and read on (there are plenty of resources out there that can explain this far better than I can).
The only way this arrow functions would work in this case is if we change the bdd API to pass a context object to every Runnable's (hooks, tests) callback, instead of leveraging this.  That's not a bad idea, but it's an earthquake of a breaking change, so will never happen. Instead of this:
it('should do something, function (done) {
  this.timeout(9000);
  // stuff
  done();
});

it'd look like this:
it('should do something', (context, done) => {
  context.timeout(9000);
  done();
});

That'd would break every async Mocha test in existence, regardless if it was backwards-compatible otherwise:
it('should do something', function (context, done) {
  // context is unused, but 'done' is now the second parameter
  this.timeout(9000);
  done();
});

We could provide an alternative bdd implementation that does this, however--it just wouldn't be the default.
That's about the most thorough explanation of "where this issue is at".  :smile:

Maybe it could be taken into consideration for the next major version? I don't think it's an important enough change to create an alternative bdd implementation. Having named arguments might help with future development too and maybe create a simple way to add some kind of test middleware like so:
it('should do something', function ({ context, done }) { ...

We could provide an alternative bdd implementation that does this, however--it just wouldn't be the default.

@boneskull A new bdd-es6 interface would be great :)

Although I am in love with arrow functions which are really useful for e.g. Array functions like .filter(i => i.val), what's the problem with using normal functions? I think it's quite useful to have describe and it globally so I don't have to require them each time. Also since when is this magic, only because you don't understand (arrow) functions? I definitely don't want to provide a variable each time when I can return promises, otherwise I would have switched to something like ava a long time ago. Regarding the simplicity of mocha I think there shouldn't be any large change on normal/arrow functions described in #1969. And please don't tell me arrow functions are faster to type since your editor can transform a single f into function () {\n\t\n}.

i'm unclear, is there a solution to timeout out a before() call that uses arrow functions?

@chovy You're setting the timeout after the timeout occurs in await provider.getData().
Try using this instead:
before(async function () {
  this.timeout(30*1000); // set timeout first, then run the function
  data = await provider.getData();
  console.log(data);
});

i'm unclear, is there a solution to timeout out a  before()  call that uses arrow functions?

Just to be clear on this: there is currently no way to call Mocha's timeout using arrow functions. Any discussion of alternatives (however meritorious) is discussion about possible new (or at least modified) interfaces.

Something I've had in my mind for a while was being able to do:
it('...', (done) => {
  ...
  done()
})

and
it('...', (t) => {
  t.timeout(500)
  t.tag('integration', 'api')
  ...
  t.done()
})

using the same default interface.
Supporting both in the same default interface let's you start using arrow functions in an existing codebase. Worth pointing out that the (done) syntax found in many tutorials online would still work, without flags or anything.
So in this implementation, you get as parameter the traditional done function, but with the utility functions added as properties of that done function object.

using this.timeout() causes elapsed time to disappear in report.

@dasilvacontin no idea why we didn't think of that earlier.  that's an excellent idea.

@dasilvacontin oh, I remember. because you have to call it.  you might not want to.

Sorry, can you elaborate on "have to call it", @boneskull? Are you talking about the problems where Mocha will think that the test is async?

On 29 Jan 2017, at 05:54, Christopher Hiller<EMAIL_ADDRESS>wrote:
@dasilvacontin oh, I remember. because you have to call it. you might not want to.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Also, how do you declare your intent of making an async test when using 't'?
In tape you always have to call 't.done' ('t.end' in their API), or set the expected amount of assertions ('t.plan').

Would it be possible to add a third argument to it() with options?  That would not break API.
it ('accepts lambda', (done)=>{ doWork();  done(); }, {timeout:60000});

@boneskull
What if instead of putting the context first, it was an optional second?

Instead of this:

it('should do something', function (done) {
  this.timeout(9000);
  // stuff
  done();
});

> it'd look like this:

it('should do something', (done, context) => {
context.timeout(9000);
done();
});

it('should do something', function (done, context) {
// context is unused, but 'done' is now the second parameter
this.timeout(9000);
done();
});
> We could provide an alternative bdd implementation that does this, however--it just wouldn't be the default.
>
> That's about the most thorough explanation I have of "where this issue is at". 😄

or if context had to be some defined param
it('should do something', function (done, override) {
  // context is unused, but 'done' is now the second parameter
  override.timeout(9000);
  done();
});

But I'd take a non-default interface too :)

The downside to any solution that requires done is that you have to use done even if returning a promise would be simpler. Speaking for myself, I know I would rather type out function and return than .then(()=>{done()}, done)!
@Flamenco That's an interesting idea, although I might prefer to have the function last (yes, it's technically more "magical" that way but, let's face it, it's easy enough to check if the parameter is a function and it's intuitive enough to use and it's not like Mocha is being fed into some kind of other abstraction that such "magic" could break); such an options object could also be used to provide tags and/or pending-test reasons, both of which are requested features (finding them in the GitHub issues/PR list search box is left as an exercise to the reader) with which I'll admit to sympathizing (even if it's possible to work around their absence, there are advantages to the real thing over the workarounds).

I found a workaround for the use case where a promise is returned to mocha from an arrow function that needs a custom timeout, that I want to share in case others find it useful.
By adding the following when function defined below in a test declaration like so: it('does something', when(() => someFunctionReturningAPromise, customTimeout)) the mocha timeout can be set without giving up arrow functions.
Similarly, and because we're working only with promises, we can retake the first parameter to a test and pass in the context instead of the done callback: it('can access the mocha test context', when(testContext => someFunctionThatNeedsContext(testContext))
const when = (lambda, timeout) =>
  function() { // return a plain function for mocha to bind this to
    this.timeout(timeout || this.timeout() || 1000)
    return lambda(this)
  }

Some test cases to illustrate:
const delay = timeout =>
  new Promise((resolve, reject) => setTimeout(resolve, timeout))

const deject = timeout => // similar to above, but a delayed reject
  new Promise((resolve, reject) => setTimeout(reject, timeout))

describe('mocha testing', () => {
  context('with only arrow functions', () => {
    context('tests that do not time out', () => {
      it('passes fast', when(() => delay(10), 100))
      it('does not usually time out', when(() => delay(2000), 2010))
    })
    context('tests that will time out', () => { // these should fail if the 'when' function works properly
      it('times out fast', when(() => delay(1000), 10)) // will fail in 10ms
      it('times out', when(() => delay(1000), 1000)) // will fail in about 1000ms
    })
    context('tests that will reject', () => { // this shows the when function works as expected when a test rejects
      it('fails fast', when(() => deject(10), 100))
    })
  })
})

@astitt-ripple yep, or you simply write function () {}... Wtf?

Ok luca, ill bite. :-)
The difference with an arrow function, is the return can be skipped. In an
es6 type setup, this can already be a common pattern for promise 'then'
chains.
With a function block, as you suggest, and as far as i know, the return for
the promise must be explicit. Minimally for a promise based test function
{... } is wrong, a test must always return its promise, so the minimal
valid trivialization is actually: function { return ...  }. Otherwise the
test returns undefined to mocha and not the dispatched promise... and the
test author has a bad time.
If most code in a codebase is already arrow functions from promise.then
and/or a functional programming style, adding function return can look
inconsistent. The suggested 'when' form is available instead for those who
prefer arrows and a more functional style than traditional function
callback or function return styles. Its more terse, and fits with the
decribe context it dsl we all agree we like writing tests in, taking into
account the promise async programming abstraction javascript handles so
well. Also its shorter than function+return, even without our pal curly:
when(() => ...).
Maybe thats not the preferred style of this project, i understand that, and
im not proposing it as a change to the project. Maybe its even
reprehensible as your wtf implies. Thats fine. Mocha has to work with
pre-fp friendly js. Backwards compatibility is a first class concern. That
also makes sense.
This is a long and deadlocked thread, and this is one way out. One nice
thing about javascript is there doesnt have to be one way or one style to
get things done. We dont have to agree on style at all. Functionally
speaking, my previous post gives people a way to use arrows and promises
consistently and with the test dsl, without giving up access to the mocha
context, in a clean and functional programming friendly way that had not
been previously suggested.
Thanks.
On Aug 3, 2017 4:07 PM, "Luca Steeb"<EMAIL_ADDRESS>wrote:
@astitt-ripple https://github.com/astitt-ripple yep, or you simply
write function
() {}... Wtf?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mochajs/mocha/issues/2018#issuecomment-320113468, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AXHFOm67lKjNCA3d3RcO29iH9iE04Thhks5sUlLHgaJpZM4G5Tnw
.

If most code in a codebase is already ... functional programming style...

...then using this.mutatingMethod(currentConfiguration) for setting behaviors, especially of a function (or rather subroutine) that is already being executed, is way more inconsistent than having to write return (which is just syntax), and inconsistent appearance would be making that reality more obvious rather than actually introducing the inconsistency.
(Don't get me wrong, I'm quite happy with the rise in popularity of functional programming ideas in JS; but the syntax of function/return vs => is not actually essential to functional programming, just a matter of what looks cleaner in that paradigm, whereas other concepts like purity and declarative vs. imperative are actually essential. It'd be neat to have a test runner that was, instead, more functional in its behavior/semantics, at which point switching to arrow functions would probably be trivial...)

I agree with you that this.timeout is mutational and breaks from the functional programming paradigm. Of course its totally inconsistent. At present, is there any other way to declare a custom timeout per test than this.timeout?
In the current implementation of mocha, it seems necessary to escape back to the imperative/mutational paradigm, or give up setting per test timeouts. One or the other.
In the above when abstraction, a timeout is the second parameter to when, allowing a functional style to remain at the test's level. It hides this inevitable escape from FP mode back to imperative programming, but does it in one place. Also, it gives arrow functions access to the mocha context, which isn't otherwise possible without breaking the test function parameter convention. So it potentially solves a few issues for some of this project's users (judging by this issue's history) in the interim until someone explores your test-runner idea.
Also please don't get me wrong either. I don't think functional programming will ever or should ever completely replace the turing machine derived imperative/mutational programming. For example in pretty much every case, in a JS runtime the code, functional or not, is ultimately interpreted by a program written in that more traditional imperative style (probably c++, but not necessarily), running on an operating system also written around mutational and imperative ideas (probably C). Memory is a fixed resource, immutable data structures are a lie the runtime tells us. That fundamentally imperative model is the default in computing, and is here to stay. But that doesn't mean functional programming cant co-exist on top of it. And if so, its inevitable that FP code has to drop down to the underlying model from time to time. I don't think that should mean we throw up our hands and say its all syntax, and lets just use function/return.
Actually we can do functional programming in C given a certain tolerance for detail, just as it is true that you can do functional programming with function/return instead of  => functions. Just don't forget to return your promise. FP in C takes a small amount more typing, which after all, is just mere syntax.../s
At the end of the day, arrow functions get us incrementally closer to a workable and practical way to work in the lambda calculus model, in a popular language. Removing those extra characters makes a small but important difference. There are still many practical limitations, but many of these are solvable, the subject at hand is one of them.
Anyways. I'll use my suggested helper function, and others are free to use it too now. I look forward to your test-runner solution, but in the meantime, I don't know if its going to be particularly productive to continue trying to convince one-another of our own opinions on what syntax is important or not, as though there is one way. I like arrows, and you like functions. I haven't seen a cogent argument that changes my view. I'm open to one, but it had better be more thought out than knee-jerks like: "just use function, wtf" or "you can still do fp with a more verbose syntax".
Solve the problem another way, and then nobody needs to use when. Nuff said. :-)

I don't think that should mean we throw up our hands and say its all syntax, and lets just use function/return.

I like arrows, and you like functions.

...it had better be more thought out than knee-jerks like: ... "you can still do fp with a more verbose syntax".

That's pretty much the opposite of what I said, though -- I was going for the fact that arrow functions that still use this wouldn't be FP in the first place, they'd be OO with arrow functions (the inverse of FP with traditional JS functions). In other words, far from it being just a different syntax, the real problem is that there's a deeper paradigm incompatibility than just the syntax incompatibility (as Mocha is currently designed anyway).
I'm fairly sure it's possible to build an alternative interface on top of Mocha to replace this altogether with parameters. I just want to make it clear that if you want to go FP in writing tests you're going to have to do more than just come up with a way to pass Mocha's this to arrow functions. I'm very much for rising to that sort of challenge, however. ;^)
(There are also several other behaviors of Mocha that are stateful, global, or -- worse -- both, but I don't have time at the moment to come up with a brief way to list them. If you've ever seen the issues surrounding running Mocha more than once, that's an example of them, though.)

At present, is there any other way to declare a custom timeout per test than this.timeout?

Unfortunately, I'm fairly sure there isn't; off the top of my head the suggestion to accept an additional parameter to it that would be a key-value map (as a JS object) of configuration settings sounds like a decent future solution in Mocha, if anyone wants to try implementing it.

At present, is there any other way to declare a custom timeout per test than this.timeout?

Unfortunately, I'm fairly sure there isn't;

Thank you for confirming this detail. This solidifies the point I was making.

off the top of my head the suggestion to accept an additional parameter to it that would be a key-value map (as a JS object) of configuration settings sounds like a decent future solution in Mocha, if anyone wants to try implementing it.

+1 for a more general solution.
From what I can tell though, it seems workable to pass a single parameter still. Combine this with the done callback (so this becomes a function). Then have mocha run each test wrapped with a promise (well, two actually, one for handling the timeout, and one for actually running the test), regardless of the parameter count (departure from how it works today). It could then check that the result of the function was a promise or not. If not, call done after the synchronous function returns to finalize the test. If the result of the function is instead a promise, then wait for it to resolve (or reject). If the timeout occurs, stop the test (same as before). In the case where a test manages to call done and also return a promise. Either done is called before resolution, in which case mocha should wait for the promise and then fail the test for having an ambiguous completion sequence. Or done is called sometime after resolution, in which case somehow the test must be retroactively failed -- or the issue signaled some other reasonable way. Sorry thats a lot of broad strokes, but thats my outsider's understanding of what mocha is trying to do and the quirks its running into. What other considerations might prevent this from being a workable solution?

if you want to go FP in writing tests you're going to have to do more than just come up with a way to pass Mocha's this to arrow functions

agreed. there is a definite change in going to a different computational model, and in addition javascript is a complex ecosystem with much to consider. In my specific use case, however setting the timeout from time to time (such as to be more accurate based on some computation instead of a fixed default value), is the only tangible issue I've encountered writing FP tests with Mocha (so far at least). Which is great. :+1:
That said, I'd like to know what else you see as impending obstacles that specifically have to do with Mocha (as opposed to what writing tests in FP might mean in general).

That's pretty much the opposite of what I said, though

I am sorry if I mischaracterized or misunderstood. For a lot of what I wrote, I'm not sure I was getting across as intended either, based on the replies. Which is unfortunate, since I think if we got down to it, we would probably come to pretty close agreement on what FP should look like in theory. Here it seems however, we disagree as to what a workable reduction to practice might look like in the currently available releases of Mocha today, at least for some users/use-cases. So I'm not quite sure exactly what the major issue is with the proposed add-on function I proposed, from your side.

(Quoted and replied in order, but arguably the more important stuff is later rather than earlier.)

From what I can tell though, it seems workable to pass a single parameter still. Combine  this  with the  done  callback (so  this  becomes a function). Then... What other considerations might prevent this from being a workable solution?

If we break backwards-compatibility, there are way simpler designs we could switch to.
If we keep backwards compatibility, both of these tests need to pass and not time out:
it("runs immediately", () => {
  // call functions and assert whatever
})
it("runs asynchronously", doneWithSomeOtherName => {
  setTimeout(() => {
    // call functions and assert whatever
    doneWithSomeOtherName()
  }, 100)
})

You're welcome to try to come up with some example code to prove otherwise (although I'd suggest focusing on the suggestion at the end of this comment instead), but I'm fairly sure no design will be able to do that and also make this test pass and not time out:
it("looks just like an asynchronous test with a different name for `done`, but never tells Mocha it's done", context => {
  context.configureByMutation("some value")
  // call functions and assert whatever
})

But also, notice the mutation there. More on this below.

In my specific use case, however setting the timeout from time to time (such as to be more accurate based on some computation instead of a fixed default value), is the only tangible issue I've encountered writing FP tests with Mocha (so far at least). Which is great.

:+1:!

That said, I'd like to know what else you see as impending obstacles that specifically have to do with Mocha (as opposed to what writing tests in FP might mean in general).

I think I may not have been communicating this quite focus...edly, so let me see if I can boil it down a bit further. (Also sorry if any of this has come off as antagonistic; it certainly isn't intended to be, although I'll admit to trying to change mindsets here.) Mocha's codebase is very much of the class hierarchies and getters and setters style of "object orientation" (and there are multiple issues or potential issues Mocha has that I believe come down to its mutable state), but that doesn't generally affect your test code if all you're doing is writing tests and letting Mocha run them. You can do weird things with Mocha's imperative mutating configuration:
it("imperatively sets the timeout multiple times", function(done) {
  this.timeout(5000)
  var context = this
  setTimeout(function() {
    context.timeout(1000)
    setTimeout(done, 500)
  }, 4000)
})

...but you don't have to. As with so many elements of programming functionally in non-functional languages: just don't abuse the imperative stuff.
(There's also an argument to be made that exceptions are impure, but I'm not yet convinced that's true of exceptions that are thrown based on the input -- which could just be considered another form of output. So some would say that using assertions that throw is not functional, but I'm not going to tackle that at this point.)
(Important part here:) What I'm trying to get at is, we're looking at potentially either adding complication to an already complex codebase, or else making a backwards-incompatible change. We need justification for either of those things. If the justification is "make tests more functional", that's good (in my book anyway). A design that makes tests more functional might be worth the trouble (depending on how much trouble it is). But if by "make tests more functional" you mean "make arrow functions mutate things", i.e. "make arrow functions less functional", that weakens the case a lot (if it isn't just self-contradictory). More completely: I don't think that making tests look more functional (as clean as arrow functions do look!) while retaining the one bit of mutation involved, however small that bit was to begin with, is nearly as compelling a justification as actually getting rid of that bit of mutation would be -- at least if the point is to make tests more functional.
I probably shouldn't even have got so far off on this tangent though; see below concerning solutions. 😸

So I'm not quite sure exactly what the major issue is with the proposed add-on function I proposed, from your side.

(Also important part here:) Well I like the bit where it takes the timeout as a parameter instead of a method call, actually! If you can come up with a way to generalize that to the rest of Mocha's configuration methods (there are a lot of them -- and some apply to synchronous tests if I recall correct, hence why we can't just add the same methods as properties on done and let people write asynchronous tests that can call configuration through done, but I digress), then I'd definitely want to take a look at it. At the very least we may want to make it a recommendation, and we might even be able to adopt the implementation into it when passed a third parameter (or something like that, maybe it.configured or it(...).configured(...) if we don't want more number-of-parameters shenanigans...) -- which I think would be a backwards-compatible solution that tackles the underlying mutation/imperative matter and gets arrow function support "the right way" (what I'm arguing is such anyway): because it fits the new behavior. I guess what I should have said, rather than going after this in the workaround, is: let's expand the parameter part of it!

I swear I read somewhere you could do something like this:
describe('a slow thing', () => {
 // test code...
}).timeout(5000);

which doesn't alter the parameter contract to the provided function.  Now I can't find any reference to any such thing so maybe I just imagined it.

@thom-nic  this works!  i guess it makes sense since all of mocha's functions returns its context
return this;

It works with me when replacing the arrow function form with the normal function
function() {  .....  }

Hi Folks. I apologize for going dark after sparking the discussion back in august, i've been quite busy and actually have mostly completed/moved-on from that work.
I appreciate the detailed response about the different use cases and how its hard to dovetail them together. That was the most concise showing of the different setups mocha has to support that I've read. So thank you for your time on that one.
Looking back, its clear that I must have over-emphasized getting access to mocha context (this), when that aspect was really more of a convenient after-thought. I didn't realize how easily it would draw attention away from what I was actually trying to do: which was having some fun by adding a temporal'ish extension (when) to the test dsl for streamlining one-off timeout adjustments (plus eliminating a common error for a particular style of tests, which I'll explain below). Returning this was just another fun thing I thought of adding, the main idea (hence the name when) was for handling cases that needed different timeouts than normal.
Obviously, if I wanted to access the bound context I could simply use function directly as many have suggested, rather than hoisting it out with a wrapper. Thats not the issue. 😄 It isn't lost on me how that might seem strange on the face of it. I'm hoping maybe it will round out the picture if I show how I was setting up some of the tests which led me down this path to begin with. To be clear, I'm not trying to sell any particular style here, use what works for you. This is what worked for me.
Ok
First off, start with the assumption that we're testing some setup that basically does one thing, but will do it for a wide range of inputs, and so we must test this thing out in a bunch of scenarios to ensure the outputs are correct. However, since the relevant application code "does one thing", the underlying test procedure is pretty much always the same. I also don't want to duplicate/mutate the test body needlessly, since that slows down how quickly I can add more test cases for new inputs and eventually the maintenance would become unreasonable.
So instead we write a function thats general enough to start the application code up with any potentially supported inputs, perform the test action, and then assert the results... Add that in my case I was working with the Promise abstraction (for reasons that i'll leave out), so this generalized test procedure function naturally has to return that promise.then chain. Bread and butter es6 kind of stuff, so far so good.
Now comes the test scenarios, since we packed everything into our test-procedure function, the test cases are effectively defining the inputs and invoking the function.
So perhaps I write a bunch of tests like this, and everything seems to be working:
it('does something', function() {
  testProcedureFunction('something','1')
})

If you're following along closely, you will have probably noticed already that this example has a bug. It is missing its return, and since testProcedureFunction is built on promises (pun intended), its always going to pass no matter whether the assertions at the end passes or fails. This is a bug, and it can be an extremely subtle one to track down sometimes. To illustrate, depending on how we wrote testProcedureFunction and how the application is written, lets say there is some synchronous code at the start, and that blows up instead of the end-of-test assertions, the testcase might even fail -- leading us to think everything is fine.
The test should of course really look like this with a return:
it('does something', function() {
  return testProcedureFunction('something','1')
})

Now I know this test is going to be one line in most cases. Actually, every case will be one line, except for when the inputs are such that a larger timeout is required. Now among the differences between classical js functions and arrows, there is a particular aspect of arrow functions that is useful here: a single statement arrow function has an implied return when braces are omitted. If instead of writing a function {...}, a test uses the => ..., then I can easily scan those cases for the arrow and the lack of curly braces, and quickly infer that they cannot have this missing return issue, and it will take some extra steps (adding the braces back) for someone to mess that up.
Like so:
it('does something', () => testProcedureFunction('something','1'))

Now what if one of these cases takes longer than the others! We can of course set the timeout like this:
it('does something slow', function() {
  this.timeout(10000)
  return testProcedureFunction('somethingSlow','2')
})

Or maybe someone will make a mistake and do this first (which doesn't work of course):
it('does something slow', () => {
  this.timeout(10000)
  return testProcedureFunction('somethingSlow','2')
})

But now we're back where we started, the codebase has a pattern ripe for repeating, which is susceptible to the missing return bug (either by future me, or the next person to add a feature -- the point is, its an easy mistake to make, it may go unnoticed, and it can be hard to track down). The when function solves this, and lets us use arrows consistently again:
it('does something slow', when(() => testProcedureFunction('somethingSlow','2'), 10000))

(note, i wasn't able to get the .timeout(5000) dot-chaining suggestion above to work, may have been due to the version of mocha i needed to use, I don't remember anymore, will give that a try!)
(note2, notice that the use of when isn't using the this parameter hoisting trick -- it really was just an after-thought).
Maybe there are linters that can flag missing returns-for-promise bugs (or probably more realistically, enforcing a return statement with a rhs for every function). However that wasn't an option at the time, plus I think the arrow syntax comes out shorter and I find it (subjectively/personally) easier to read and work with, which tipped the scales for me away from function.
So there you have it.
I don't know if I'll have time to respond again anytime soon, so I hope that was at least informative and clear, and maybe even puts some of the controversy surrounding the whole "access to mocha-context from arrows" stuff to bed.
Lastly, since I found function vs => confusing for a long time, I'll drop this link in case its not clear to anyone casually reading why arrows can't access this. It was the clearest explanation of functions vs arrows that I've found, and was what helped me finally understand the differences well enough to use them with full confidence.
https://hacks.mozilla.org/2015/06/es6-in-depth-arrow-functions/

@thom-nic It works on it, but not on describe.
describe('my test suite', () => {

  it('test case 1', () => {
    // ...
  }).timeout('10s');  // Works on `it`. This test case doesn't timeout

  it('test case 2', () => {
    // ...
  });  // This test case timeouts.

}).timeout('10s');  // Doesn't work on `describe`. Tests are already created when runs to here.

@thom-nic  , you may use the normal function form
describe('my test suite', function() {
this.timeout(n);

...
}

In case this might help someone else, I had a TypeError() in Karma(!) and after reading this thread, or parts of it at least, I replaced an arrow function callback in a setTimeout call to a regular function and believe you me, the TypeError went missing!

Anyone complaining about this doesn't understand arrow functions.
Arrow functions are NOT a new fancy ES6 thing is supposed to replace the classic function () {}. The only purpose of arrow functions is that it inherits this from it's parent, where the classic function () has it's own this.
Yes, even when using full ES6 syntax, you should still be using function () if you want to use this in the correct context of your function. You should be using both function () and () => in your ES6 application depending on what you are trying to do.
this.timeout() doesn't work with it('....', () => { ... }) because the callback is inheriting this from the parent describe() function, in which this.timeout() doesn't make sense on that level.

Don't lambda functions also allow you to automatically send a single argument to the function without declaring it in the call?
(param)=>aFunction
...then(aFunction)
function(){} can be bound to 'this' but ()=> is 'locked in'
Arrow functions should replace the traditional function when the receiver expects a pre-determined 'this' in the same context that it is called from, (and also benefit from typing less code).
I would go so far as to say never use function() unless you want 'this' to be something other than what 'this' is when invoking it.

There are many different coding styles in JavaScript -- from OOP to FP, from strict type-safety to mixin/duck-typing. In addition, there are advanced patterns in each of those styles (i.e. dependency injection in OOP camp, currying/monad in the FP camp).
If your coding style is closer to FP where this is not used and arrow functions are used to reduce boilerplate, having to preserve this is an extra overhead for any advanced testing (e.g. parameterized testing, creating DSL).
Any experienced developer can just pre-wrap the testing framework to suit their coding style, but that means the framework is less "out-of-the-box". That translates to extra work for upgrading, adopting plugins, and onboarding new engineers.

I like the idea of an alternative bdd interface which doesn’t use this and instead passes what would normally be the context object as a parameter to describe, it and hooks.
But it’s not so straightforward to implement, IIRC. Would be cool to see an attempt though.

i used the below script but i got the same Timeout exceed error.
Myscript :
describe("getBillingDetail", async function (){
this.timeout(55000);
it.only("check given valid Jobname",async function (done){
this.timeout(55000);
var result = await url.getBillingDetail('12254785565647858');
console.log(result);
assert.equal(result,true);
});
});
Error: Timeout of 55000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves.

Don't pass a done callback to an async function

I've created a prototype solution that's backwards compatible. For now it's a separate module, but functionality could easily be merged into mocha proper.
https://github.com/papercuptech/mocha-lambda
quick way
require('mocha-lambda')
// now a global '_tst' can be used where 'this' was before

describe('suite', () => {
  beforeEach(() => {
    _tst.answer = 42
  })

  it('provides "this" as "_tst"', function() {
    assert(this === _tst)
  })

  it('works', () => {
    assert(_tst.answer === 42)
    _tst.skip()
  })
})

for explicit naming (and works with TypeScript)
// if you were previously explicitly importing api (describe, it, etc.) from 'mocha',
// you will have to change to importing from 'mocha-lambda', until (or if) this
// gets merged into mocha proper
import ctx, {describe: d, it: i} from 'mocha-lambda'

d('quite', () => {
  // ctx() is a function that returns "this" as appropriate
  i('works using ctx()', () => {
    ctx().skip()
  })
})

import {Context} from 'mocha'
// ctx() can also rename global
ctx('t')
declare var t: Context
d('quite', () => {
  // ctx() is a function that returns "this" as appropriate
  i('works using renamed global', () => {
    t.skip()
  })
})

@papercuptech The link is 404 not found.

Woops.. was private repo. now public

@aleung @linesh-simplicity, this is superseded by #3485

Thanks.
Why so many "magic" that, at the end, produces problems? Why not this?:
var mocha = require('mocha');

mocha.describe('foo', (suite) => {
  suite.timeout(100);

  suite.it('must love bar', () => ... );
});

No globals, no problematic magic... but just JavaScript.

see @thom-nic answer, clean and did the trick

I swear I read somewhere you could do something like this:
describe('a slow thing', () => {
 // test code...
}).timeout(5000);

which doesn't alter the parameter contract to the provided function. Now I can't find any reference to any such thing so maybe I just imagined it.

@thom-nic solution worked for me, thanks!


[3429] Import missed allocations

Context

https://trello.com/c/x2El42cz/3429-import-additional-allocations

Changes proposed in this pull request
Guidance to review
Checklist

[ ] Make sure all information from the Trello card is in here
[ ] Attach to Trello card
[ ] Rebased master
[ ] Cleaned commit history
[ ] Tested by running locally

 [S] Import additional allocations


Configure continuous deployment of the web app

Is your feature request related to a problem? Please describe.
Configure deployment of the web app.
Describe the solution you'd like
It is offered to deploy the application to firebase.
Currenly only firebase hosting is applcable since the application does not have a backend.
When backend is present, it will be possible to deploy it to firebase functions.

https://medium.com/front-end-weekly/ci-cd-with-github-actions-to-deploy-on-github-pages-73e225f8f131


Abstract security context interface and enable security filter

Coverage decreased (-0.03%) to 55.192% when pulling f8f56ad555a93892754e11e988cbea4d698ea2a4 on ywk253100:170425_authN_interface into 14b2139efcaca8879ef345c8e4cbb7aa55764a4b on vmware:master.


fix input param replacement when workflow is retried

Fixed input param replacement in the retried tasks when a workflow a retried
Allow TIMED_OUT tasks (hence the workflows) to be retried

Pull Request Test Coverage Report for Build 4258

13 of 14 (92.86%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.01%) to 69.467%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

core/src/main/java/com/netflix/conductor/core/execution/WorkflowExecutor.java
13
14
92.86%

Totals

Change from base Build 4246:
0.01%

Covered Lines:
12420

Relevant Lines:
17879

💛  - Coveralls


[Enhancement] : "union-like" collection to enforce one of an "all-optional" set

I am using Yamale to define schema for a linear pipeline; refer to this example: Essentially, every pipeline consists of an entry, zero or more filters, and an exit.
The *entry" element can be one of two things:

a receiver, that listens for connection requests, or
a getter, that reaches out data

My definition of entry is
entry: # one of these is required, how to enforce?
  custom: include('receiver', required=False)
  custom: include('getter', required=False))

My enhancement request is to have a way of specifying that entry must have one and exactly one of those potential values. For example,
entry: union(include('receiver'), include('getter'))
I would use that same technique to force each process to be one and only one of the all-optional elements defined therein (refer to the same URL, above).
Thoughts?

Apologies if I've overlooked some of the nuance to this question, but does the any validator work for you?

Apologies if I've overlooked some of the nuance to this question, but does the any validator work for you?

I cannot believe I missed that: I have had the main page open for days and simply overlooked it. Thank you, @blopker! I'll close this.

No problem! Glad to help. Is there some keyword or phrase we can add to the docs that would have made it easier to find? I've seen other people miss any in the docs as well.

No problem! Glad to help. Is there some keyword or phrase we can add to the docs that would have made it easier to find? I've seen other people miss any in the docs as well.

I started answering this and decided a pull request was just as easy.


Enhance local repository regex matching conditions

The existing regex expression is not complex enough to handle projects within groups/subgroups in GitLab.
See this regex101 for EXISTING support
See this regex101 for PROPOSED support

          1 Error

:no_entry_sign:
Please include a CHANGELOG entry.
You can find it at CHANGELOG.md.

          1 Warning

:warning:
Tests were not updated

  Generated by :no_entry_sign: Danger

poke

apologies, haven't been very active recently. these very well could be valid test failures, and since it's been a long time since I opened this PR, I've forgotten what scenario spawned this change.


[SR SQL Planner Summer Camp] New Parser and Analyzer support User Defined Function-statements

What type of PR is this：

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

Which issues of this PR fixes ：

Fixes #7953
Problem Summary(Required) ：

I just try run UT, so don't need review for me temp.


Add Referrer-Policy via web.config

Hi @klings,
is there possible way or will it ever be possible to configure Referrer-Policy in the nwebsec section of the web.config of asp.net projects?
King Regards

Yes, I'm currently aligning the "old" and "new" NWebsec version so they (mostly) contain the same features. In version 5, Referrer-Policy will also be part of the classic "NWebsec" package.

Released.


Filtering not working in presence of too many categories

This happens in a mobile browser: iPhone 8 with iOS 12.1.4 using Safari.
Code to reproduce the issue
const map = new mapboxgl.Map({
    container: 'map',
    style: carto.basemaps.darkmatter,
    center: [-3.70819, 40.42119],
    zoom: 12,
});

carto.setDefaultAuth({
    apiKey: 'default_public',
    username: 'cartovl'
});

const s = carto.expressions;
const source = new carto.source.Dataset('airbnb_madrid_listings_2018');

const viz = new carto.Viz(`
    @name: $name
    @room_type: $room_type

    strokeWidth: 0
    color: ramp($price_dollars, Temps)

    filter: between($price_dollars, 0, 500)
`);
const layer = new carto.Layer('layer', source, viz);
layer.addTo(map);

After that, you should filter with:
viz.filter.blendTo(s.in(s.prop('room_type'), s.list(['Private room'])));

Result

Expected

Just by removing @name: $name, it works.
I guess it's related to the number of properties we are uploading to the GPU. The number of distinct names is quite high.
However, we don't need that property at the GPU as we are not using it for any of the styling or filtering. The reason to have the name property referenced as a variable is to be able to use it in the interactivity. The open question is: could we only upload the visualization (style + filters) properties and keep the rest for the JS side?


Some questions about class "FourierCrossAttention"

When I was debugging the code, I found that the calculation in both places in the figure was performed by calling key and ignoring value.What are the benefits of this?I would appreciate your reply :）

Sorry, Just saw your question, We used the same learnable weight here for K and V, it helps stabilize the training a little bit, you can use xv_ft_ here as you noticed; it might give better results with careful tuning. If you have further questions, you can ask them here: https://github.com/MAZiqing/FEDformer/.  Don't know why, but we didn't get the email notice from here.


Why is webpage map display available when no internet connect

Hello
I've already connected the osrm-frontend server with my  osrm-backend server and host at the same PC.
My question is:
When there is no internet connected, the osrm-frontend server couldn't request map.png(?) and should just display blank instead.
However, with some zoom level, I can still see the map display well
How is it working?
tks for any replies

If you are using the frontend and pointing it to your local routing engine as per
https://github.com/Project-OSRM/osrm-frontend#changing-backends
the map tiles are still getting loaded over the internet.

You're probably seeing some map tiles because they're cached in your browser.

I'll try to clean my cached
thanks you @daniel-j-h !


ARROW-8178: [C++] Update to Flatbuffers 1.12.0

This includes some UBSAN-related fixes that make our MakeNonNull helper function unneeded with Flatbuffers

cc @emkornfield

+1. The UBSAN issues are affecting me in https://github.com/apache/arrow/pull/6638 so I'm going to merge this and if any issues come up we can investigate

Glad this worked out, I think it was harder for some reason when we weren't vendoring the source.


add _qmc_cy library stub for typing

Please note that this stub should be checked with mypy before merging. I am currently working on my (very very very) old laptop, I can not run mypy.


Update Creating_Run_Configurations_for_Java_Modules_c206766.md

Removed a redundant bullet point, which is not required.

Good catch!! Thank you!


Review links to GDS guidance from our accessibility guidance

What
We need to review the links to GDS accessibility guidance from the NHS digital service manual accessibility guidance.
Why
To ensure that the external links from the NHS digital service manual accessibility guidance are still suitable and relevant in case GDS has made any updates to their gudiance.
Tasks

[ ] Review all links
[ ] Speak with Alistair regarding any new updates to the GDS accessibility guidance that we could link to from the NHS digital service manual
[ ] Create an issue for any links that need updating

Related EPIC: Improve internal linking in service manual #689

Please see issue https://github.com/nhsuk/service-manual-internal/issues/60


How to integrate with other Moko libraries

Hi, can someone help me to understand how this type of intergration should look alike, I have done everything written in Setup part, but checking with Sample app there is a completely different structure compared with mine.
Here is my plugins and dependencies list

And here is Kswift configuration part.

After that it generates shared.podspec, file

and pod successfully installs, but I dont get any generated file in my source code. Not for sealed classes and not for any binding extensions.
Can someone help me to understand what I am doing wrong.

hi. generated swift code not included into Kotlin framework. generated code can be added to Xcode directly via "Add files..." (location of files described here) or by adding second cocoapod - sharedSwift. podspec of sharedSwift generates by gradle task of kswift - kSwiftSharedPodspec.
here sample with direct files - https://github.com/Alex009/moko-kswift-usage-sample/tree/regular-framework
another sample with direct files - https://github.com/Alex009/moko-paging-sample
sample with cocoapods - https://github.com/icerockdev/moko-kswift/tree/master/sample/mpp-library-pods

Thanks, figured it out with cocoapods!


Duration format bug - Class tried to be generated

Duration being a class (plus probably some other factor I do not understand)
https://github.com/microsoft/kiota-typescript/blob/dfbafb0aaf1afdb49e920c2c0c77c15766fce135/packages/abstractions/src/duration.ts#L8
It triggers this exception
https://github.com/microsoft/kiota/blob/c78914ba8b21d33aecba9539b9584edbf4b4fec8/src/Kiota.Builder/Writers/TypeScript/CodePropertyWriter.cs#L26
The following patch to Kiota enables to finish the generation but the resulting code is not satisfactory (I had to edit it to make it build).
It was more a confirmation of the code path that led to the issue.
diff --git a/src/Kiota.Builder/Writers/TypeScript/CodeMethodWriter.cs b/src/Kiota.Builder/Writers/TypeScript/CodeMethodWriter.cs
--- a/src/Kiota.Builder/Writers/TypeScript/CodeMethodWriter.cs
+++ b/src/Kiota.Builder/Writers/TypeScript/CodeMethodWriter.cs
@@ -22,14 +24,13 @@ public class CodeMethodWriter : BaseElementWriter<CodeMethod, TypeScriptConventi
         var isVoid = "void".EqualsIgnoreCase(returnType);
         WriteMethodDocumentation(codeElement, writer, isVoid);
         WriteMethodPrototype(codeElement, writer, returnType, isVoid);
-        if (codeElement.Parent is CodeClass)
-            throw new InvalidOperationException("No method implementations are generated in typescript: either functions or constants.");
     }

     private void WriteMethodDocumentation(CodeMethod code, LanguageWriter writer, bool isVoid)
     {
         WriteMethodDocumentationInternal(code, writer, isVoid, conventions);
     }
diff --git a/src/Kiota.Builder/Writers/TypeScript/CodePropertyWriter.cs b/src/Kiota.Builder/Writers/TypeScript/CodePropertyWriter.cs
--- a/src/Kiota.Builder/Writers/TypeScript/CodePropertyWriter.cs
+++ b/src/Kiota.Builder/Writers/TypeScript/CodePropertyWriter.cs
@@ -17,22 +21,17 @@ public class CodePropertyWriter : BaseElementWriter<CodeProperty, TypeScriptConv
                          && !codeElement.Type.IsCollection;//collection of flagged enums are not supported/don't make sense

         conventions.WriteLongDescription(codeElement, writer);
-        switch (codeElement.Parent)
-        {
-            case CodeInterface:
-                WriteCodePropertyForInterface(codeElement, writer, returnType, isFlagEnum);
-                break;
-            case CodeClass:
-                throw new InvalidOperationException($"All properties are defined on interfaces in TypeScript.");
-        }
+        WriteCodeProperty(codeElement, writer, returnType, isFlagEnum);
     }
-    private static void WriteCodePropertyForInterface(CodeProperty codeElement, LanguageWriter writer, string returnType, bool isFlagEnum)
+
+    private static void WriteCodeProperty(CodeProperty codeElement, LanguageWriter writer, string returnType, bool isFlagEnum)
     {

Hi @gadcam,
Thanks for reporting the issue, do you have a sample openapi yml snippet you were using so that I can use it to debug the issue. Thanks.


ContactPerson role for dmp.contributor is redundant with the dmp.contact in the model

The model has a exactly one contact, and zero or more contributors. However, the contributor.role can also be ContactPerson; this is redundant and inconsistent.

We did this on purpose. We want always to have a contact person for a DMP, so that no DMP is an orphan.
Contributor is to:

list all people involved in managing data and writing the DMP
be able to answer questions from DMPs like “who will be responsible for implementing this DMP”

There is a possibility of redundancy, due to the Datacite contributor types including a value of "ContactPerson", and this is unfortunate.
However, I would not like to throw away the recommendation to use the DataCite contributorTypes just because of this potential redundancy, and I agree with Tomasz that we definitely want the mandatory contact person property as well.
My recommendation: leave this as it is, and seek forgiveness later ;-)

Isn't this contradictive with? https://github.com/RDA-DMP-Common/RDA-DMP-Common-Standard/issues/16#issuecomment-558115485
I think the decision for now is to remove the references to DataCite.

Removing the link to DataCite also solves this issue. Any replacement we insert for Contributor types should "avoid" contact-person roles.

Yes - the decision (based on the discussion in https://github.com/RDA-DMP-Common/RDA-DMP-Common-Standard/issues/16#issuecomment-558115485) is to remove the connection to the DataCite 'roles'.


Add option to support delay initialize

Sometime, A implementation neet to delayed initialize.  I modify the source of npm package to do this. But it's very cumbersome to modify every time。
usage:
await deployProxy(Env, [], { deployer: deployer, unsafeAllowCustomTypes: true, skipInitialize: true });
in npm package:
const data = getInitializerData(Contract, args, opts.initializer, opts.skipInitialize);

function getInitializerData(Contract, args, initializer, skipInitialize) {
    if(skipInitialize) { return "0x"; }
    const allowNoInitialization = initializer === undefined && args.length === 0;
    initializer = initializer !== null && initializer !== void 0 ? initializer : 'initialize';
    const stub = new Contract('');
    if (initializer in stub.contract.methods) {
        return stub.contract.methods[initializer](...args).encodeABI();
    }
    else if (allowNoInitialization) {
        return '0x';
    }
    else {
        throw new Error("Contract ${Contract.name} does not have a function ${initializer}");
    }
}

@chenfux I've added the ability to skip initialization by specifying initializer: false.
It's published in version 1.2.1.


[Bug]: snowflake_share cannot add accounts due to incorrect quoting

Terraform CLI Version
1.8.0
Terraform Provider Version
0.90.0
Terraform Configuration
resource "snowflake_share" "share" {
  name     = var.name
  comment  = var.comment
  accounts = ["abcdefg.${var.target}"]
}

Category
category:identifiers
Object type(s)
resource:share
Expected Behavior
Share should be created and my target account added.
Actual Behavior
Application yields an error:
│ Error: 003516 (0A000): SQL compilation error:
│ Following accounts cannot be added to this share: "abcdefg".TARGET.

Steps to Reproduce
apply
How much impact is this issue causing?
High
Logs
No response
Additional Information
I am able to reproduce the exact error in snowsql if I quote the organization name part (I can quote the target account, but that seems to be parsed correctly as an identifier):
<EMAIL_ADDRESS>share dmfshare add accounts="abcdefg".target;
003516 (0A000): SQL compilation error:
Following accounts cannot be added to this share: "abcdefg".target.
<EMAIL_ADDRESS>share dmfshare add accounts="abcdefg"."target";
003516 (0A000): SQL compilation error:
Following accounts cannot be added to this share: "abcdefg".target.
<EMAIL_ADDRESS>share dmfshare add accounts=abcdefg.target;
+----------------------------------+
| status                           |
|----------------------------------|
| Statement executed successfully. |
+----------------------------------+

I'd use the locator, but:
│ Error: account locators are not allowed - please use 'organization_name.account_name
│
│   with module.my_stuff.snowflake_share.share,
│   on ../../../modules/snowflake/share_source/main.tf line 37, in resource "snowflake_share" "share":
│   37:   accounts = var.target_accounts

Would you like to implement a fix?

[ ] Yeah, I'll take it 😎

Hey @dmfay. Thanks for reaching out to us.
Remember that the casing matters with fully qualified names (the quoted ones). In your example, "target" is written in different ways (lowercase vs. uppercase). I have just reproduced the same behavior while using the wrong casing on our test account. Please try UPPERCASING.

ah, I'd tried uppercasing the target account name earlier, but it needs the organization name uppercased too. The printed error has the account already uppercased (and unquoted) but it looks like the provider parses the string and adds quotes to the organization -- is that behavior documented anywhere? Thanks!

Hey @dmfay. Do I understand correctly that uppercasing both solved your problem?
It may not be documented in one place, but we will work on the documentation clarity before reaching a stable V1. For now, you can assume that casing always matters when using the TF provider.

yes, that's correct.


LOGGER for Unload Query

Can you please add a logger for unload query?

Hi, I'm not actively developing this tool right now, but you're welcome to open a PR if you have an idea of what you want.


fix unreachable code after log.Fatal in fuzzing corpus generator

https://pkg.go.dev/log#Fatal

Fatal is equivalent to Print() followed by a call to os.Exit(1).

see https://go.dev/play/p/fWIT3Iobb0A for example:
package main

import (
	"fmt"
	"log"
)

func main() {
	log.Fatalf("print and exit")
	fmt.Println("will not execute")
}

/* output
2009/11/10 23:00:00 print and exit

Program exited.
*/

@Abirdcfly Can you please rebase this PR on top of the current master? The lint job is failing consistently, and I'm not sure if that's due to changes in the CI setup or if it's something related to this PR.

Can you rebase please, not merge master?

It worked, great! Thank you!


Send feedback to API provider

ParkenDD for Android implemented a way of sending feedback to the provider of the API via a POST request. This app should do the same.

Now includes a MFMailComposeView sending a mail to Johannes & me including app version number and API URL besides whatever the user wants to add as well.


can you write README use English?thanks

README in the archive/eng-notation branch has been updated to English.


Refactor telegrambot subpackage

As the project grows more functions and scenarios are added to the telegrambot subpackage and code becomes look like a spaghetti one.
The task is to refactor the telegrambot/telegram.bot and following files of the subpackage:

msg.go - should contain all the logic for processing message scenarios.
callback-query.go - should contain all the logic for processing callbacks (e.g. from buttons).
search.go - may contain logic on processing search-related stuff (list all the searches and so on...).
errors.go - should contain methods for processing general errors (e.g. from bot.Send(msg)).
telegrambot.go - general logic of the bot.

All the functions should be documented so it's easy to navigate through the package in the documentation.

Changes were merged in #24


Add support for building snaps

Hi Paul,
Can I ask you to add support for snaps for textql?
I think this would be a nice addition to the Snap Store (snapcraft.io/store), and give you extra exposure to Linux users. Snaps are cross-distro Linux software packages, supported on Ubuntu, Debian, Manjaro, Fedora, OpenSUSE and many others distributions. They also come with automatic updates.
I wrote this PR detailing how to build snaps locally using snapcraft, a command-line tool.
You can also build snaps using a CI system  or our free build system (build.snapcraft.io).
Here are the steps to build textql as snap on a stock Ubuntu 18.04:

Install snapcraft, checkout and build snap.

snap install snapcraft --classic --beta
git clone https://github.com/igorljubuncic/textql.git
cd textql
git checkout add-snapcraft
snapcraft
This sequence of commands will create a .snap file, something like textql_1.0_amd64.snap.

Test snap.

This snap can then be installed and tested local with:
snap install textql_1.0_amd64.snap --dangerous
The --dangerous flag is necessary because the app does not come from the store and isn't signed.
After it's installed, you can run the application:
snap run textql

Register & upload.

Next, you will need to:

Register a developer account in the snap store https://snapcraft.io/account.
Register the textql name in the store.

snapcraft login
snapcraft register
snapcraft push textql_1.0_amd64.snap --release edge
The store supports multiple risk levels as “channels” with the 'edge' channel typically used to host the latest build from git master. Stable is where stable releases are pushed. Optionally, beta and candidate channels can also be used if needed. After testing, you can push a stable release to the stable channel.

Test installing on a clean machine.

snap install textql --edge
Once your app is in the store, we can help with the store page, and promote the application online.
Thanks, and let me know if you have any questions on this.

Thanks for your contribution to textql!


Story reloading fix

Closes #98
Todo:

[ ] Right now each story is required to have Roact supplied to it. This should be changed so Roact can be supplied at the storybook level as well

So this works great if Roact is supplied for each story, but unfortunately falls apart when trying to supply it once for the storybook.
Reason being is that I'm now using two ModuleLoaders to manage the storybooks and stories independently. But a problem arises from this in that each loader is loading different copies of Roact (as in the two tables are not equal to each other, along with all the symbols).
It's looking like we'll need to go back to using a single loader, and I'll likely be digging into the ModuleLoader source code to figure out a better way to handle caching and reloading. Currently I'm planning to set it up so each module that gets loaded will have a list of consumers, and when a module is changed the cache is invalidated for that module and all consumers up the chain.
Planning to speak with a colleague about this so I can have a better idea of how to tackle the issue cause this is quite tricky


Lellky/fixes for macos linux

Hello Piotr!
I would very much want to get in contact with you to help you get support in Home Assistant for your awesome Flexit integration.
This PR is just some updates your can have a look at if you want. I had some troubles getting it to work, and still there is some things that a more experienced python developer need to have a look at.
For example, there is something about a bad file descriptor. Don't know why, maybe a file or socket is not closed somewhere in the BAC0 package or in your code 🤷
an error has occurred: [Errno 9] Bad file descriptor
Traceback (most recent call last):
  File "/opt/homebrew/lib/python3.10/site-packages/bacpypes/core.py", line 154, in run
    asyncore.loop(timeout=delta, count=1)
  File<EMAIL_ADDRESS>line 214, in loop
    poll_fun(timeout, map)
  File<EMAIL_ADDRESS>line 151, in poll
    r, w, e = select.select(r, w, e, timeout)
OSError: [Errno 9] Bad file descriptor

The updated "get local device ip address" code was "inspired" by https://stackoverflow.com/questions/166506/finding-local-ip-addresses-using-pythons-stdlib

Hi Jonas,
thanks for reaching out. We definitely need to get this fixed. When is the error occurring? Is it when you run the current_mode.py?

It looks very promising though 🥇


make rng private for selectors

closes #1007 (partly)
The notebook from that issue now works. However, It is now uncertain is the state of the generators that is loaded.
This depends whether OPS is re-imported between loading or not.
# before simulation:
{'bit_generator': 'PCG64',
 'state': {'state':<PHONE_NUMBER>70254096309584224979479325155,
  'inc':<PHONE_NUMBER>84886836437703854582102603205},
 'has_uint32': 0,
 'uinteger': 0}
<numpy.random._pcg64.PCG64 at 0x7f0b819d9d10>

# after running:
 {'bit_generator': 'PCG64',
 'state': {'state':<PHONE_NUMBER>13007235580189205770362297672,
  'inc':<PHONE_NUMBER>84886836437703854582102603205},
 'has_uint32': 1,
 'uinteger':<PHONE_NUMBER>}
 <numpy.random._pcg64.PCG64 at 0x7f0b819d9d10>

# loaded in the same kernel session
{'bit_generator': 'PCG64',
 'state': {'state':<PHONE_NUMBER>13007235580189205770362297672,
  'inc':<PHONE_NUMBER>84886836437703854582102603205},
 'has_uint32': 1,
 'uinteger':<PHONE_NUMBER>}
<numpy.random._pcg64.PCG64 at 0x7f0b819d9d10>

# loaded in a restarted kernel session
 {'bit_generator': 'PCG64',
 'state': {'state':<PHONE_NUMBER>32858718566197330052104521012,
  'inc':<PHONE_NUMBER>5856406385200004491830534511},
 'has_uint32': 0,
 'uinteger': 0}
 <numpy.random._pcg64.PCG64 at 0x7f0ab8347d10>

This is a broader issue to be solved, as OPS does not have a way of storaging mutable objects (such as a rng state)

@dwhswenson this is ready for a review


Need a means to save temporary generated directories on failure

In the event a test fails, there isn't a means for testers to recover necessary data in order to determine why an issue occurred in all cases.
It would be nice if there was a configurable hook in kyua where a set of arbitrary commands could be executed on cleanup to save a the directories, there was a configuration variable where the directory could be saved, etc...

My idea for this was to extend kyua debug with an option to keep the contents if desired. E.g. doing kyua debug --workdir=/tmp/foo some-test would force Kyua to use that work directory and not clean it up on exit.
However, I'm not sure that'd be sufficient. Especially because this requires a re-run of the test.
We could go one step further and support something like kyua test --workdir=/tmp/foo, which would cause us to run all tests and only keep work directories for the tests that failed.
In other words: if no --workdir is provided, Kyua picks a temporary directory on its own and makes sure it's fully wiped on exit. If the user provides his own directory, it is not automatically cleaned up for failures. Makes sense?


Bug fix footer problem

Fixed bug that cause empty view holder (between adapter and footer) get wrong view type id

Thank you!

Released v0.2.2.


scripts: kconfig: Give symbol locations in warnings

Warnings from Kconfiglib itself always give symbol locations, but the
custom value mismatch warning in kconfig.py doesn't. Make it print the
symbol locations too. This is helpful when debugging.
Before:
warning: UART_QMSI_0_HW_FC was assigned the value "y" but got the value "n" -- check dependencies

After:
warning: UART_QMSI_0_HW_FC (defined at /home/ulf/zephyr/drivers/serial/Kconfig.qmsi:35, /home/ulf/zephyr/arch/x86/soc/intel_quark/quark_se/Kconfig.defconfig.series:194) was assigned the value "y" but got the value "n" -- check dependencies

Signed-off-by: Ulf Magnusson<EMAIL_ADDRESS>

Codecov Report

Merging #6791 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #6791   +/-   ##
=======================================
  Coverage   54.64%   54.64%
=======================================
  Files         447      447
  Lines       42587    42587
  Branches     8040     8040
=======================================
  Hits        23272    23272
  Misses      16084    16084
  Partials     3231     3231

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 f77469a...26c1216. Read the comment docs.


[C-1000] Improve copy of Activity Types

Currently, we display a short version of what the activity type means (left). We should make the activity type display more meaningful. Suggestion:

Twitter: Posted a Tweet -> Posted a Tweet with your hashtag
DEV: Commented → Commented on your article
Reddit: Commented on a post → Commented on a post in your Subreddit
Reddit: Posted in subreddit → Posted in your Subreddit
LinkedIn: Commented → Commented on your post
HN: Commented → Commented on a post mentioning you
HN: Post → Posted about you

This data is retrieved from the backend, so the change should be done there
From SyncLinear.com | C-1000

Hi @joanagmaia I would like to contribute to this issue

Hi @joanagmaia I would like to contribute to this issue

Of course 😄

@joanagmaia I have signed the CLA but its still showing pending status

is this issue still open?i would like to work on it

Hey @Vivek-GuptaXCode, yeah it's still open. But I believe this issue needs better scoping because it can affect multiple parts of the app. Will try to look at it once I have more time to make sure it's ready for development. Sorry about his

thanks for the update


Add class to fix card width for resolving seven

Please check the following

[ ] Do the tests still pass? (see Run the Tests)
[ ] Is the code formatted properly? (see Linting (Formatting))
For New Features:

[ ] Have tests been added to cover any new features or fixes?
[ ] Has the documentation been updated accordingly?

Please describe additional details for testing this change
Adds class to fix card width when resolving seven. Fixes #179

Seven resolution now looks good on Firefox with card images appearing at a normal size. Screenshot of result below.

Hi, I just pushed a new commit onto my fork's main branch that accounts for the changes of:

renaming the class to .resolving-seven-card
moving the css into the parent .reveal-top-two while also adding the & nesting alias

I double checked to make sure that everything still looks okay, which it does. Screenshot below.


[Localization] I think you meant "bodypart"?

What a difference a letter can make. :rofl:
This fix (and few other less interesting typo fixes) will be in the next release.

This is fixed in v3.4.1


Remote reindex: Add support for configurable retry mechanism

Description
Remote Reindex mostly involves repeating 2 major steps:

fetch data using scroll call.
Ingest the data fetched using a transport level bulk request.

I've added following minor enhancements to the remote reindex process.

Current retry mechanism retries the entire reindex process from the start. I've changed the behavior of retry logic to scroll requests to remote cluster (Bulk already has a retry mechanism).
Current retry mechanism would only kick in for 429s. I've also added retried for 5xx & ConnectException.
Exposed the retry params behind cluster settings.
Also, changed the logger to prefix based. This is useful to segregate logs from multiple ongoing reindexes for easier debugging.
Added debug logs for few places for ease of tracking the reindex operation.

Related Issues
Resolves https://github.com/opensearch-project/OpenSearch/issues/12560
Check List

[x] New functionality includes testing.

[x] All tests pass

[x] New functionality has been documented.

[x] New functionality has javadoc added

[x] Failing checks are inspected and point to the corresponding known issue(s) (See: Troubleshooting Failing Builds)
[x] Commits are signed per the DCO using --signoff
[x] Commit changes are listed out in CHANGELOG.md file (See: Changelog)
[x] Public documentation issue/PR created

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

I'm still working on adding tests for this change. Wanted to get the changes out for initial feedback while i work on tests.

❌ Gradle check result for fdf7502: FAILURE
Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

Gradle check failure due to flaky test: https://github.com/opensearch-project/OpenSearch/issues/12610

❕ Gradle check result for 9e2fc06: UNSTABLE

TEST FAILURES:

      1 org.opensearch.search.SearchWeightedRoutingIT.testMultiGetWithNetworkDisruption_FailOpenEnabled

Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure.

Flaky test: https://github.com/opensearch-project/OpenSearch/issues/10755

MinimumClusterManagerNodesIT

Flaky test: https://github.com/opensearch-project/OpenSearch/issues/10006

Issue for documentation update: https://github.com/opensearch-project/documentation-website/issues/6674


Team 10 Review

The "Hazard analysis" document is missing critical assumptions.
Missing some important critical assumptions such as the hardware devices are reliable and will function without significant failures.

Added some critical assumptions


Docker PinFactoryFallback Raspberry Pi 5

While being happy that the package got installed and creating this post, I got another issue, that I get error when using gpiozero in python code:
/usr/local/lib/python3.11/site-packages/gpiozero/devices.py:300: PinFactoryFallback: Falling back from lgpio: No module named 'lgpio'
  warnings.warn(
/usr/local/lib/python3.11/site-packages/gpiozero/devices.py:300: PinFactoryFallback: Falling back from rpigpio: No module named 'RPi'
  warnings.warn(
/usr/local/lib/python3.11/site-packages/gpiozero/devices.py:300: PinFactoryFallback: Falling back from pigpio: No module named 'pigpio'
  warnings.warn(
/usr/local/lib/python3.11/site-packages/gpiozero/devices.py:300: PinFactoryFallback: Falling back from native: unable to open /dev/gpiomem or /dev/mem; upgrade your kernel or run as root

this is my dockerfile:
FROM python:3.11-slim-bullseye
ENV PYTHONUNBUFFERED=1 \
    PIP_DISABLE_PIP_VERSION_CHECK=1 \
    PYTHONDONTWRITEBYTECODE=1 \
    PUID=1000\
    PGID=1000

# Set the working directory inside the container
WORKDIR /app

# Create and set volumes

# Install system dependencies for PyAudio, evdev, and build tools
RUN apt-get update && apt-get install -y --no-install-recommends \
    supervisor \
    swig \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

# Copy requirements.txt to the container and install Python dependencies
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt

RUN pip install pigpio gpio gpiozero
RUN pip install https://github.com/Gadgetoid/PY_LGPIO/releases/download/<IP_ADDRESS>/lgpio-<IP_ADDRESS>.tar.gz

# Copy the rest of the application code to the container
COPY . .

# Ensure the entrypoint script is executable
RUN chmod +x ./entrypoint.sh

# Expose the port the app runs on
EXPOSE 8010

ENTRYPOINT ["./entrypoint.sh"]
CMD ["supervisord", "-c", "/supervisord_docker.conf"]

the code runs fine on Raspberry Pi 5 root, but if running docker container with priviliged mode, it doesnt seem to work.
Any Ideas, whats wrong?
Originally posted by @Ed1ks in https://github.com/Gadgetoid/PY_LGPIO/issues/2#issuecomment-2129600938

Ok after hours of testing different dependencys because I thought there is something needed like libgpio, rpigpio, gpiod or something, I finally did find out, it was because I run code without root permission 🙈.
Everyone who want to access gpio with gpiozero inside or not a docker container on a raspberry pi 5:
Dockerfile example:
FROM python:3.11-slim-bullseye
ENV PYTHONUNBUFFERED=1 \
    PIP_DISABLE_PIP_VERSION_CHECK=1 \
    PYTHONDONTWRITEBYTECODE=1 \
    PUID=1000\
    PGID=1000

# Set the working directory inside the container
WORKDIR /app

# install
RUN apt-get update && apt-get install -y --no-install-recommends \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

# Copy requirements.txt to the container and install Python dependencies
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt

# Copy the rest of the application code to the container
COPY . .

# ... rest of dockerfile ...

while in requirements.txt this must be included:
gpiozero>=2.0.1
https://github.com/Gadgetoid/PY_LGPIO/releases/download/<IP_ADDRESS>/lgpio-<IP_ADDRESS>.tar.gz

you must run your python code as root. of course you could install these two packets also in Dockerfile with RUN. But this is probably the better way to go.


Support variants, flavor and buildType implementation dependencies for preflight checks

#250  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @rbro112 and the rest of your teammates on  Graphite


Add themis-fake

Purpose:

Enable developers to work locally on their computers with less remote dependencies.

Description:

When working on a service that depends on themis, instead of pointing to a real themis endpoint, developers can point to this themis-fake, which is deployed in a local k3d on their computers.
themis-fake simply permits all requests.

In meeting 20191204, decided to close for now until further discussion on sdk, bypassing etc.


Corrupted(waiting for packet)

Description

collect log：stat.log
2018-03-15 14:54:04 INFO  type=COUNTER, name=Pinpoint-UDP-Span-Worker.running, count=32
2018-03-15 14:54:04 INFO  type=COUNTER, name=Pinpoint-UDP-Stat-Worker.running, count=0
2018-03-15 14:54:04 INFO  type=COUNTER, name=TCPReceiver-Worker.running, count=0
2018-03-15 14:54:04 INFO  type=METER, name=Pinpoint-UDP-Span-Worker.completed, count=16033484840, mean_rate=1571.6237559767144, m1=2886.1370677784626, m5=3629.221902046388, m15=3707.0868467113864, rate_unit=events/second
2018-03-15 14:54:04 INFO  type=METER, name=Pinpoint-UDP-Span-Worker.rejected, count=4791660335, mean_rate=469.68499287592454, m1=1287.7584583886483, m5=1692.9752827634445, m15=1728.0566945091064, rate_unit=events/second
2018-03-15 14:54:04 INFO  type=METER, name=Pinpoint-UDP-Span-Worker.submitted, count=20825145469, mean_rate=2041.3087776190614, m1=4172.8795456239695, m5=5321.916036558035, m15=5435.047288312015, rate_unit=events/second
2018-03-15 14:54:04 INFO  type=METER, name=Pinpoint-UDP-Stat-Worker.completed, count=1135086, mean_rate=0.11126265702271929, m1=0.13348733160061707, m5=0.13318551932637823, m15=0.13303915942044517, rate_unit=events/second
2018-03-15 14:54:04 INFO  type=METER, name=Pinpoint-UDP-Stat-Worker.rejected, count=0, mean_rate=0.0, m1=0.0, m5=0.0, m15=0.0, rate_unit=events/second
2018-03-15 14:54:04 INFO  type=METER, name=Pinpoint-UDP-Stat-Worker.submitted, count=1135086, mean_rate=0.11126265702062958, m1=0.13348733160061707, m5=0.13318551932637823, m15=0.13303915942044509, rate_unit=events/second
2018-03-15 14:54:04 INFO  type=METER, name=TCPReceiver-Worker.completed, count=360685, mean_rate=0.03535482882295027, m1=2.3245560280042056E-4, m5=0.46932959994644685, m15=0.8354993530664158, rate_unit=events/second
2018-03-15 14:54:04 INFO  type=METER, name=TCPReceiver-Worker.rejected, count=0, mean_rate=0.0, m1=0.0, m5=0.0, m15=0.0, rate_unit=events/second
2018-03-15 14:54:04 INFO  type=METER, name=TCPReceiver-Worker.submitted, count=360685, mean_rate=0.035354828822100594, m1=2.3245560280042056E-4, m5=0.469329658730278, m15=0.8355006614390392, rate_unit=events/second
2018-03-15 14:54:04 INFO  type=TIMER, name=Pinpoint-UDP-Span-Worker.dispatchDuration, count=16033484885, min=0.002242, max=413.515133, mean=20.252365450520266, stddev=23.90036948089838, median=24.112303999999998, p75=26.908652999999997, p95=39.576467, p98=57.570653, p99=65.21825199999999, p999=348.389608, mean_rate=1571.6237601543826, m1=2886.0021067634325, m5=3629.184436519282, m15=3707.0741099235747, rate_unit=events/second, duration_unit=milliseconds
2018-03-15 14:54:04 INFO  type=TIMER, name=Pinpoint-UDP-Span-Worker.duration, count=16033484859, min=0.269063, max=40.491893, mean=2.98746289133848, stddev=2.8328656241356454, median=2.6048679999999997, p75=3.419799, p95=5.829435, p98=7.149723, p99=15.114422, p999=39.040672, mean_rate=1571.6237575013342, m1=2886.1353553520094, m5=3629.221399558039, m15=3707.086699544171, rate_unit=events/second, duration_unit=milliseconds
2018-03-15 14:54:04 INFO  type=TIMER, name=Pinpoint-UDP-Stat-Worker.dispatchDuration, count=1135086, min=0.008002, max=1.756641, mean=0.04878300578446691, stddev=0.04583039753856408, median=0.02462, p75=0.09938799999999999, p95=0.136727, p98=0.136727, p99=0.136727, p999=0.136727, mean_rate=0.11126265699700327, m1=0.13348733160061707, m5=0.13318551932637823, m15=0.13303915942044509, rate_unit=events/second, duration_unit=milliseconds
2018-03-15 14:54:04 INFO  type=TIMER, name=Pinpoint-UDP-Stat-Worker.duration, count=1135086, min=1.386263, max=1424.75037, mean=27.344741169143937, stddev=74.6232841070692, median=6.736765, p75=15.860009999999999, p95=240.806482, p98=240.806482, p99=240.806482, p999=1424.75037, mean_rate=0.1112626569916732, m1=0.13348733160061707, m5=0.13318551932637823, m15=0.13303915942044517, rate_unit=events/second, duration_unit=milliseconds
2018-03-15 14:54:04 INFO  type=TIMER, name=TCPReceiver-Worker.dispatchDuration, count=360685, min=0.001599, max=14.082550999999999, mean=0.44718920412743357, stddev=1.5081744072299865, median=0.021748999999999998, p75=0.2721, p95=1.403204, p98=6.044086, p99=9.84224, p999=13.878141999999999, mean_rate=0.03535482881784753, m1=2.3245560280042056E-4, m5=0.469329658730278, m15=0.8355006614390392, rate_unit=events/second, duration_unit=milliseconds
2018-03-15 14:54:04 INFO  type=TIMER, name=TCPReceiver-Worker.duration, count=360685, min=0.250866, max=8.635444, mean=1.1872283602100677, stddev=1.0531958401538744, median=0.7330669999999999, p75=1.620871, p95=2.9445829999999997, p98=3.111522, p99=3.799663, p999=8.206557, mean_rate=0.035354828815913585, m1=2.3245560280042056E-4, m5=0.46932961921540206, m15=0.8354997867699672, rate_unit=events/second, duration_unit=milliseconds
Environment

Pinpoint version:1.6.2
OS, WAS, affected library, etc:
Additional details (e.g. how your collector/web is set up):

Additional Info

I think Pinpoint-UDP-Span-Worker.rejected some package, so trace corrupted.
Please tell me how to fix it.

hi han14466
If you look at the following log
2018-03-15 14:54:04 INFO type=METER, name=Pinpoint-UDP-Span-Worker.rejected, count=4791660335, mean_rate=469.68499287592454, m1=1287.7584583886483, m5=1692.9752827634445,

It seems that  trying to save beyond the limit of hbase, so all of the spans are not saved.
If you tunning or extend hbase, then this is will be resolved.
thanks.

@koo-taejin - Any insights on how to increase the write performance of Hbase, whether increasing the Hbase region server will help in this case

@dinesh4747 I think that increasing the hbase instance will increase the write performance.
thanks.


Error when extending user store with getters.

When I tried to extend the user store adding getters, I would get a vuex error that isLoggedIn was defined more than once.  Also,  I believe some of the user functionality would fire multiple times.
import coreStore from '@vue-storefront/store/modules/user'
import { extendStore } from 'core/lib/themes'

const getters = {
  ...
}

export default extendStore(coreStore, {
  state,
  getters,
  mutations
})

PLEASE NOTE: This issue was occurring prior to the newest store modifications.

This will be closed after we close #1102

Fixed with the latest change of vuex module registration


70 task testing 70%

Finish task testing and get them to around 80% coverage

New task-testing edit


Cannot add GCE provider due to service account validation

Validation of the Service Account JSON is checking for spaces and not allowing the provider to be added.  The auth for GCE is a json file containing newlines and spaces.

Seems to be introduced with https://github.com/ManageIQ/manageiq/pull/9235

@agrare Perhaps we do not need that space checking validation there. I will take care of it!
Thanks.


qed option does not work with ntheorem loaded with thmmarks

In thm-ntheorem.sty, there is
\define@key{thmstyle}{qed}[\qedsymbol]{%
  \@ifpackagewith{ntheorem}{thmmarks}{%
    \theoremsymbol{#1}%
  }{%
    \thmt@notsupported
      {ntheorem without thmmarks option}%
      {headindent}%
    }%
}

So the qed option should work in \declaretheoremstyle as long as ntheorem is loaded with the thmmarks option. However,
\documentclass{article}
\usepackage[thmmarks]{ntheorem}
\usepackage{thmtools}

\declaretheoremstyle[
      qed=\textasteriskcentered
    ]{mystyle}
\declaretheorem[style=mystyle]{styledtheorem}

\begin{document}

\begin{styledtheorem}[Euclid]
   For every prime $p$\dots
\end{styledtheorem}

\end{document}

shows no qed symbol.
P.S. In \thmt@notsupported, "headindent" should be replaced with "qed" (addressed in #46).

Sorry, this is an ntheorem bug, not a thmtools bug.
\documentclass{article}
\usepackage[thmmarks]{ntheorem}

\theoremsymbol{*}
\newtheorem{example}{Example}

\def\blub{blub}

\begin{document}

\begin{example}
   \dots
\end{example}

\begin{example}
   Not a command
\end{example}

\begin{example}
   \blub
\end{example}

\end{document}

If the last thing in a theorem environment is a command without arguments, it seems ntheorem suppresses the theorem symbol and adds extra vertical space. If thmtools is loaded, a silly way to fix this is adding
\addtotheoremprefoothook{ }

to the preamble.


Builder: update to new Constraints API

This PR does the steps outlined in https://github.com/chainbound/bolt/issues/209 to support the new constraints API
To do: ping Kubi when this is merged

Will not support the top field in this PR as we won't support it any time soon any way


Maybe script editing should be done externally?

Hey,
if you ask me, it can stay where it is for now, it would be cool if it have autosave function. Other thing i think it would be good to start wiki page or something like that for coding because now i related on:
a) your mastodon (with i dont have. I remembered you had a twitter, I even follows you but I think you no longer there).
b) Lizband page from video setup
both of those are not that much.

Hi SteigerHSV!
Thanks for your input. I was mainly considering having scripts edited in an external editor since the experience would be much better than I could easily supply. Like using VScode or some other powerful text editor. One very annoying thing in UltraEd is I sometimes save the script to the wrong actor and override its behavior. I need to address that soon.
Yeah I'm no longer on twitter but I have my own Mastadon instance where I post only things concerning UltraEd's development. I like your idea about starting a wiki! I could add programming information there and provide tutorials. I'm working on a very simple game using UltraEd and it's starting to get some interactivity. Going through the game making progress is helping me shape the tool into something practical.
The videos from Lizband have been super cool but I think get outdated quickly since I'm actively working and changing things in the editor. I try to keep the issues list up to date so everyone can know what I'm spending time on.

Ahoy!
What game do you want to do? because to be honest I was thinking about something super simple that would be proof of concept or good first test of your editor, some thing like 2D or 3D Asteroids. This could be super simple in graphic side and also good to test things like: collisions, shooting etc. I have work, and my own project but if you want We can do something :) (i also have flashcard and n64)

No but you should allow people to reuse scripts and not copy and paste them and have public variables like in unity.

Definitely that would ease development having those features but I don't think I'm ready to tackle that yet. I'm working on allowing messaging between actors and letting custom structs be initialized and attached to an actor so cloned actors can take advantage of the same data too. I made an example of being able to shoot a bullet actor over and over again using instantiation. I'm trying to write a complete mini game that can showcase all of UltraEd's functionality. I need to get back to work on this project lol. Been busy building computers from scratch and right now building an 8 bit breadboard computer.


DBZ-7816: Postgres: Potential data loss on connector restart

Hi @adasari there are some test failures, could you please take a look.

@Naros I am still trying to compile the repo locally. will look into it. thanks.

@Naros Test failures due to this line
The IT tests utilize the Debezium engine, which lacks support for SourceConnectorTask#commitRecord(record, recordmetadata). As a result, the minimum timestamp map remains empty, leading to the absence of database flushes.
I have added min timestamp check to handle major DB upgrade scenarios.
Major DB upgrades reset LSN and old kafka offsets LSN are not supposed to flushed to DB WAL.
An alternative approach to address this scenario is to release the offsets that are more recent than the start time of the corrector or connector task. We may need to discuss Major DB upgrade scenario once all tests have passed successfully.

@Naros Test failures due to this line The IT tests utilize the Debezium engine, which lacks support for SourceConnectorTask#commitRecord(record, recordmetadata). As a result, the minimum timestamp map remains empty, leading to the absence of database flushes.
I have added min timestamp check to handle major DB upgrade scenarios.
Major DB upgrades reset LSN and old kafka offsets LSN are not supposed to flushed to DB WAL. An alternative approach to address this scenario is to release the offsets that are more recent than the start time of the corrector or connector task. We may need to discuss Major DB upgrade scenario once all tests have passed successfully.

@Naros @vjuranek Not sure if DB major upgrade case required to be handled. Alternatives to handle it without a code change,

Send the new offset entry with new replication slot start LSN to offset topic.
Use new kafka offset topic or empty the offset topic.
Create new connector (with new name) with snapshot mode never.

Option#1 ensure new replication slot offset always available in Kafka offset topic.

@adasari Applied, thanks a lot! Could you please create a separate PR with docs update?

@adasari Applied, thanks a lot! Could you please create a separate PR with docs update?

Sure. I'll review the documentation. Do you have a particular section in mind for updates? If not, I'll locate the relevant information.

@adasari I think it can go into section https://debezium.io/documentation/reference/2.6/connectors/postgresql.html#postgresql-when-things-go-wrong


Fix mixed image format for file, S3 and azureblob caches

Fix the usage of mixed image format with the File, S3 and azureblob caches.
Fixes #605.

@weskamm Could you please review this PR?

@weskamm Could you please take a look? If there are changes that need to be made I will fix them right away.

Looks good to me, thanks for the fixup.

We are reverting this PR because it was causing problems in production - especially with existing caches. I think we need backwards compatibility and unit tests to assure that everything works correctly.

What are the problems that this causes? I will work on the issues ASAP.

There was the problem that mapproxy did only return blank images for caches that were created before the update.
In the PR itself I see this problems:

It does not introduce a test that demonstrates the failing case
In the existing tests, it is ensured that every tile is stored with a .png ending. I do not know exactly why that is, but it feels not right to me. See https://github.com/mapproxy/mapproxy/blob/a73fe7fa696d397c14eda069e0a4340f58b8bda6/mapproxy/test/system/test_mixed_mode_format.py#L121
The new tile_location function has this code:

        if self.is_mixed:
            location = self._tile_location(tile, self.cache_dir, 'jpeg', create_dir=create_dir, dimensions=dimensions)
            if not os.path.exists(location):
                tile.location = None
                location = self._tile_location(tile, self.cache_dir, 'png', create_dir=create_dir, dimensions=dimensions)

This will never cause a file with .jpeg to be created. Might be intended so
4. In the tile_location function of the file cache there is code that does nothing. This was there before and maybe is unrelated to the problem: https://github.com/mapproxy/mapproxy/blob/a73fe7fa696d397c14eda069e0a4340f58b8bda6/mapproxy/cache/file.py#L55C13-L55C79
So, if MapProxy should supported reading caches that mix .jpeg and .png files I think it should also create .jpeg and .png files. Furthermore we need to ensure that old caches are still usable.

I do not have a reproducible example, but I hope to get one.
We reverted the commit because we needed a clean working release before merging all of the linting and deprecation issues.

There was the problem that mapproxy did only return blank images for caches that were created before the update.
In the PR itself I see this problems:

It does not introduce a test that demonstrates the failing case
In the existing tests, it is ensured that every tile is stored with a .png ending. I do not know exactly why that is, but it feels not right to me. See https://github.com/mapproxy/mapproxy/blob/a73fe7fa696d397c14eda069e0a4340f58b8bda6/mapproxy/test/system/test_mixed_mode_format.py#L121
The new tile_location function has this code:

        if self.is_mixed:
            location = self._tile_location(tile, self.cache_dir, 'jpeg', create_dir=create_dir, dimensions=dimensions)
            if not os.path.exists(location):
                tile.location = None
                location = self._tile_location(tile, self.cache_dir, 'png', create_dir=create_dir, dimensions=dimensions)

This will never cause a file with .jpeg to be created. Might be intended so 4. In the tile_location function of the file cache there is code that does nothing. This was there before and maybe is unrelated to the problem:
https://github.com/mapproxy/mapproxy/blob/a73fe7fa696d397c14eda069e0a4340f58b8bda6/mapproxy/cache/file.py#L55
So, if MapProxy should supported reading caches that mix .jpeg and .png files I think it should also create .jpeg and .png files. Furthermore we need to ensure that old caches are still usable.

Thank you very much for your review! I will add a failing test as you requested and fix the existing tests.
As for your third point, I see that I have ignored the create_dir parameter that indicates wanting to store a tile insted of just getting it from the cache. I will add the use of this variable in the condition.
I agree that storing mixed tiles is what was intended.


Question : can auto disconnect

Is it possible to auto disconnect the device when not in range?

Just for information if anyone is stuck with an issue with auto disconnect this functionality is already present in the package just when we are not in range it automatically gets disconnected you can check it with isconnected or rssi function by calling it to continue.


Classroom delivery

I put my classroom delivery slides in a folder called classroom_delivery/. Let me know if this feels like an appropriate place to store them!

Purpose/implementation Section
What changes are being implemented in this Pull Request?
What was your approach?
What GitHub issue does your pull request address?
Tell potential reviewers what kind of feedback you are soliciting.
New Content Checklist

[ ] New content/chapter is in an Rmd file with this kind of format and headers.

[ ] New content/chapter contains Learning Objectives and are in the correct format.

[ ] Bookdown successfully re-renders and any new content files have been added to the _bookdown.yml.

[ ] Spell check runs successfully in Github actions style-n-check).

[ ] Any newly necessary packages that are needed have been added to the Dockerfile and image.

[ ] Images are in the correct format for rendering.

[ ] Every new image has alt text and is in a Google Slide.

[ ] Each slide is described in the notes of the slide so learners relying on a screen reader can access the content. See https://lastcallmedia.com/blog/accessible-comics for more guidance on this.

[ ] The color palette choices of the slide are contrasted in a way that is friendly to those with color vision deficiencies.
You can check this using Color Oracle.

Love it!! Thanks @caalo !!