Border issue with styling

Hello ,
White mark ( Border ) appears when using theme='dark_blue.xml' ( Seen with other themes) ,  which is due below styling of QFrame
Environment : PySide2 5.15.2 and qt-material=2.8.4

Issue  seen since v 2.8.2
v2.8.0 – No issue
v2.8.1 – No issue
v2.8.2 – Issue
v2.8.3 – Issue
v2.8.4 – Issue
/*material.css.template */
QFrame {
background-color: {{secondaryDarkColor}};
border: 1px solid {{secondaryColor}};
/* Border appears due to this
Either can have background color which hides this issue
or Border radius can be 0px
*/
border-radius: 4px;
}
Note: Its always possible to override styling in custom,css which I am currently doing which solves the issue. It would be great to have fix in package.
Awesome project nicely done to suit Material Design. Kudo's 👍
Thanks and Regards,
Govind

Hi @govindashrit
I'm not able to reproduce this issue, are you on windows? can you give me minimal code to understand how widgets are placed.
Thanks.

Hello Yeison,
Please find the attached Sample Application (SouceCode src.zip). Yes I am windows OS.
src.zip
Thanks
Govind

Hi @govindashrit
There is no way that I can reproduce this effect in my operating system, if you want, write the style correction and I will check that's not affect anything else and then added it to the source code.

Hello @YeisonCardona
Yes the issue is seen on Windows and NOT on ios
Style Correction
QFrame {
border-radius: 0px;
}
Thanks
Govind

Hi @govindashrit
Looking at your code closely, these changes would handle this issue:
class MainTabBar(QWidget):

    def __init__(self) -> None:
        super().__init__()
        # self.v_layout = QVBoxLayout(self)  # <- self here

        # Initialize tab screen
        self.tabs = QTabWidget(self)
        self.tab1 = Tab1()
        self.tab2 = Tab2()

        self.tabs.addTab(self.tab1, "Tab1")
        self.tabs.addTab(self.tab2, "Tab2")

        self.tab1.get_contents()
        self.tab2.get_contents()
        # self.v_layout.addWidget(self.tabs)
        # self.setLayout(self.v_layout)

Have you try Qt Designer is a really useful tool for handle GUIs development ;)

Hello Yeison,

Hello Yeison,
I tried your code changes, I still see the issue.

Code changes as you suggested
class MainTabBar(QWidget):
def __init__(self) -> None:
    super().__init__()
    # self.v_layout = QVBoxLayout(self)

    # Initialize tab screen
    self.tabs = QTabWidget(self)
    self.tab1 = Tab1()
    self.tab2 = Tab2()

    self.tabs.addTab(self.tab1, create_icon('mdi.home'), "Tab1")
    self.tabs.addTab(self.tab2, create_icon('mdi.script-text-outline'), "Tab2")

    self.tab1.get_contents()
    self.tab2.get_contents()
    # self.v_layout.addWidget(self.tabs)
    # self.setLayout(self.v_layout)

Yes I have tried Qt designer, but for my usecase (dynamic creation of tabs) , I wish to do it programmatically.
For reproducing the issue, made this sample application.
Regards,
Govind R

The sample code is hard to debug, with a lot of unnecessary lines, empty inherited classes, redundant calls, basically is not a minimal code. Somewhere there must be a widget created without the correct parent and avoiding the styles heritage, maybe.


Reading file from base branch

Im trying to write db migration consistency check, for that I need to see if there is any conflict upon new PR with migration file with an existing migration file on the base branch.
Is there any easy way to read the current files on the base branch from a dangerfile?

You'll probably want to use a git command and use the pr info's base_branch I think


PowerTrack V2 Stream/Rules Base URL

The API Reference: http://support.gnip.com/apis/powertrack2.0/api_reference.html#Stream shows the following:
Stream URL: https://gnip-stream.twitter.com/...
Rules URL: https://gnip-api.twitter.com...
But PowerTrackV2UriStrategy.java uses:
public static final String DEFAULT_STREAM_URL_BASE  = "https://stream-data-api.twitter.com";
public static final String DEFAULT_RULE_URL_BASE = "https://data-api.twitter.com";

Are they both valid? Is the latter one deprecated?

Hi, I remember that gnip-api.twitter.com didn't work during the beta. I've updated the rule hostname as it works.
I still need to check the stream hostname.

I've been testing changing  DEFAULT_STREAM_URL_BASE  = "https://stream-data-api.twitter.com"; to gnip-stream.twitter.com as stated at http://support.gnip.com/apis/powertrack2.0/api_reference.html#Stream  but get a connection with my account (502 errors). I'm leaving for now as is.

@jcodagnone I'll test it as well in the next few days and see what happens.
I commented on your commit, but I'll repeat here: the URL you changed contains an extra / which breaks the HTTP request

@jmmk typo fixed at ad2c414ac6

Both domains seem to work fine for me using curl and gnip4j. I asked Gnip support about all the different urls, and this was the reply:

For your real-time stream please use the gnip-stream.twitter.com domain.
For the Rules API use the gnip-api.twitter.com domain.
For Replay use the gnip-stream.gnip.com domain.

These are not expected to change, and no promises on support for the old ones you cited.

Where "old ones" means those mentioned above: stream-data-api.twitter.com and data-api.twitter.com

Cool, I made some extra tests with a new stream (outside powertrack 2 beta) and worked all fine. I updated the hostname at 0a818290

👍  thanks


Activity: Setup environment

Setup project environment.
Acceptance Criteria:

All dependencies sucessfully installed

Tasks:

[x] Create Python virtual environment
[x] Install SQLAlchemy
[x] Install Jest
[x] Install Django

Completed as of fa6d6e5


fix: wrong python file uri in airflow

Python module path was malformed. It looked like gs:.../.../gs:../.../.../ due to excessive concatenation of variables.
This fix should rescue all airflow runs. @ireneisdoomed came out with the same fix separately.

Codecov Report

Merging #242 (8731291) into main (68a77b3) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #242   +/-   ##
=======================================
  Coverage   85.95%   85.95%
=======================================
  Files          80       80
  Lines        1816     1816
=======================================
  Hits         1561     1561
  Misses        255      255

Files
Coverage Δ

src/airflow/dags/common_airflow.py
100.00% <ø> (ø)


Some Facebook events are still not supported

While testing Facebook handovers I discovered that app_roles events are not supported.
While app_roles events aren't hugely important, every event we don't support is a potential problem that customers could encounter, and a potential reason to not use the Bot Framework. There are currently 15 webhook event groups that a Facebook app can subscribe to, with each group potentially corresponding to multiple events. For example, subscribing to messaging_handovers will allow a Facebook app to receive pass_thread_control, take_thread_control, request_thread_control, and app_roles events. It might be a good idea to allow our Facebook connector to pass along any event from those 15 groups to the bot so that nothing gets absorbed.

@craigjensen - I plan to work on a Messenger Platform NuGet package soon: https://github.com/microsoft/botbuilder-dotnet/issues/1931
It would be very helpful if we could solidify the Bot Framework's compatibility with the Messenger Platform before the package gets released. Ideally our connector would not "swallow" any events. I'm hoping there's a way to handle events generically so that they all get forwarded, rather than needing to hard-code in each event we want to support specifically.

@Kyle; this may be something to take up directly with EgorN as a feature request.  I don't think this is as simple as unblocking a set of events.

Thank you @jameslew
I have been in contact with Egor and Artur about this over email. I'm hoping to set up a meeting with them.


Doubled memory usage?

result = cupy.random.normal(size=[128 * 1024 * 1024], dtype=cupy.float32)

I would expect that this is 512mb, while it takes 1115MB on GPU. Same thing in other cases.
Is there something I am missing?

Tried the same with larger sizes of array - still used memory is twice larger than my computations.

Thank you for reporting! I made a PR to fix this issue. #562

ok, thanks, I see the reason.
But why cupy doesn't free the memory of intermediate object? Does it have own memory management?

Yes, CuPy has recently introduced its own memory pool.
That's why intermediate buffers are not apparently released.
Even if it looks leaking, it should have no harm in practice.


KeyChord type not found at runtime for type annotations

Code:
from imgui_bundle import imgui

def test() -> imgui.KeyChord:
	pass

if __name__ == '__main__':
	print("Hello, world!")

Stacktrace
Traceback (most recent call last):
  File "/home/nuck/.local/share/JetBrains/Toolbox/apps/pycharm-community/plugins/python-ce/helpers/pydev/pydevd.py", line 1534, in _exec
    pydev_imports.execfile(file, globals, locals)  # execute the script
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/nuck/.local/share/JetBrains/Toolbox/apps/pycharm-community/plugins/python-ce/helpers/pydev/_pydev_imps/_pydev_execfile.py", line 18, in execfile
    exec(compile(contents+"\n", file, 'exec'), glob, loc)
  File "/home/nuck/PycharmProjects/imgui-stub-test/main.py", line 3, in <module>
    def test() -> imgui.KeyChord:
                  ^^^^^^^^^^^^^^
AttributeError: module 'imgui_bundle._imgui_bundle.imgui' has no attribute 'KeyChord'

See
https://github.com/pthom/imgui_bundle/blob/564cf51ebeba07e9d3173c62499522c36afbdae3/bindings/imgui_bundle/imgui/__init__.pyi#L177-L192
ModFlags = int  # -> enum ModFlags_        # Flags: for io.KeyMods (Ctrl/Shift/Alt/Super)
...
KeyChord = ModFlags  # == int. We generally use ImGuiKeyChord to mean "a ImGuiKey or-ed with any number of

KeyCoord is likely only defined in the stub, which is not a real definition. Use ModFlags_ or int instead.
This is an non standard API in imgui.h anyhow: ImGuiKeyChord is an int which can be selected inside the enum ImGuiKey or the enum ImGuiMod_
typedef int ImGuiKeyChord;          // -> ImGuiKey | ImGuiMod_XXX    // Flags: for IsKeyChordPressed(), Shortcut() etc. an ImGuiKey optionally OR-ed with one or more ImGuiMod_XXX values.


Problem parsing % character as plain text

Hi, I've been using this awesome plugin but I found that there are some issues when a % symbol is written onto the .md file as plain text
Let me show a couple of examples

... test coverage of at least 70%. (Measures to show this for each PR will need to be investigated)

Threw this error

And had to be changed to

... test coverage of at least 70 percent (Measures to show this for each PR will need to be investigated)

Another example (with the url changed - in bold the part that stays the same and has the problem)

For that, first you need to configure kubectl like described here: https://mypage.com/folder/anotherfolder/guides_%26_docs/yetanotherfolder

Threw this error

And had to be changed to be shown as a link to work

For that, first you need to configure kubectl like described here DOCUMENTATION

While this kind of error requires a workaround that is not that terrible to do, the main issue at least for me was to actually understand what was going on. I think it worth checking if there's something that can be done for this.

Hi @sebastianaguerre
Thanks to use such plugin and for your valuable feedbacks.  I'll check asap

Hi @sebastianaguerre
I've find out the problem. during markdown parsing has been used String.format() and then % is marked as special char.
Currently you can add another % as workaround
test coverage of at least 70%%. (Measures to show this for each PR will need to be investigated)

Hi @sebastianaguerre
I've deployed version 7.9-SNAPSHOT with the fix. Please take a chance to test it so I can arrange a new production release

Also ran into this exact issue. Nice seeing it already being solved.
There's is an issue with 7.9 not being available however:
https://search.maven.org/artifact/org.bsc.maven/confluence-reporting-maven-plugin
https://mvnrepository.com/artifact/org.bsc.maven/confluence-reporting-maven-plugin
Strangely enough I was able to fetch 7.9-SNAPSHOT and can confirm that the fix  solves the issue with "%" in md files. (also figured out the "%%" workaround)
I would like however to use 7.9 and not  7.9-SNAPSHOT or 7.8+%% workaround so please lookinto the issue with 7.9 not being available


Catch errors during launch and set the task future exception appropriately

This addresses one of the issues that causes #1274 and possibly #1267.
The gist of it is that, with monitoring enabled, launch_if_ready calls _create_task_log_info which accesses an nonexistent property on AppFutures. That causes an exception to be thrown. Now, launch_if_ready is called from submit(), in particular this snippet:
        def callback_adapter(dep_fut):
            self.launch_if_ready(task_id)

        try:
            d.add_done_callback(callback_adapter)
        except Exception as e:
            logger.error("add_done_callback got an exception {} which will be ignored".format(e))

The issue is that Future.add_done_callback, if the future is closed, directly invokes the callback. Long story short, such errors are explicitly ignored. Perhaps the right solution is to assume that other code paths handle this properly, but, to be safe, I wrapped launch_if_ready in a try/catch which sets an exception on the AppFuture that represents the task currently launched.

i) A bunch of stuff needs to happen at task completion (even failed task completion). A more consistent way to do this would be in the same way as memoization or dependency failure does it: use a Future from somewhere other than submit to be the exec future with the appropriate value/exception, and say "this task ran and here is its result".
In the case of memoization, that's a previously used executor future coming via check_memo (line 423 of dflow.py); in the case of dep fail handling - see unmerged PR #1258 around line 385.
I think the dep fail handling would roughly the right thing to do here, but using States.failed instead of States.dep_fail
ii) There is also a potential race condition/fragility here that I'm not entirely sure of: once the task has been launched with executor.submit inside self.launch_task, but then after that an exception is raised, I'm unclear if it is safe to catch that exception and be able to recover safely: we'd potentially end up potentially with two concurrent things (the real one, and the error handling fake-one) both claiming to be the definitive provider of the tasks result.
For exceptions happening before the submit, I think this is straightforward to deal with: catch and create a failure Future deeper in the launch code rather than around the outside of
launch_if_ready.
For exceptions happening after the submit - I'm not sure what the right thing to do is... catch-and-log at the least.

Let me see if I get this straight. We're implementing
seq(
etc1(), exec_fu = seq(etc2(), future(exec())), etc3(), wait(exec_fu)
)

errors are maybe handled asynchronously in exec(), but it's not clear what happens with errors in etc2().
there is no error propagation defined for the etcs() in general (i.e. it gets ignored).
you are suggesting that a failure in etc1() or etc2() should fake an exec() and create a failed exec_fu, which must go through a particular path in the call stack. Let me rephrase that: if etc1() or etc2() fail, I need to still call exec() (or repeat some of its steps) and put some fake exec_fu where the real one was supposed to be.
etc3() races with the wait(), so the proper way of handling etc3() failure depends on when that failure happens.

I mean we're obviously not implementing the above kseudocode, but do we want to? Because if we do, the first error in the flattened sequence (etc1(), etc2(), etc3(), exec()) propagates to the app_fu and there is no race because the wait is after etc3().

I don't understand how any of that pseudocode is really meant to map to the existing parsl code so my answers are going to be a bit vague.

you are suggesting that a failure in etc1() or etc2() should fake an exec() and create a failed exec_fu, which must go through a particular path in the call stack. Let me rephrase that: if etc1() or etc2() fail, I need to still call exec() (or repeat some of its steps) and put some fake exec_fu where the real one was supposed to be.

Approximately.

etc3() races with the wait(), so the proper way of handling etc3() failure depends on when that failure happens.

There is no wait in the submission code path for exec_fu - there's a callback added for handle_exec_update though, which handles post-completion (for both success and failure completion).
I'm unclear why you argue that:
etc1(), exec_fu = seq(etc2(), future(exec())), etc3(), wait(exec_fu)
can flatten to:
So I'm unclear what you're expecting here:

A related thing to this, maybe, is that there is no reasonable "everything-is-broken-time-to-abandon-everything" behaviour: this is a library sitting inside other code, not a workflow system where we can exit the top level unix process. Something that I think is related arises with (non-)lazy failures - issues #282 has some discussion there.

I don't understand how any of that pseudocode is really meant to map to the existing parsl code so my answers are going to be a bit vague.

This is going to be a mess without a blackboard, but let's try.

you are suggesting that a failure in etc1() or etc2() should fake an exec() and create a failed exec_fu, which must go through a particular path in the call stack. Let me rephrase that: if etc1() or etc2() fail, I need to still call exec() (or repeat some of its steps) and put some fake exec_fu where the real one was supposed to be.

Approximately.

Maybe I misunderstand things. The app_fu is done when a bunch of constituent fus and/or non-fus are done. Presumably any errors in the constituents should cause the app_fu to fail. I see in the code that there is handling on the failure of the exec_fu, which triggers retries and whatnot. Let's call those things, your stuff that needs to happen, exec_cb. What you suggest says that we, in fact, want exec_cb invoked not just when exec_fu fails, but also when other things fail. So it seems to me that we are not clear on what's handled when and where. If exec_cb needs to be called when other app_fu constituents fail, then it should really be an app_cb. Or at least we should be clear and list, perhaps in a table, what an app_fu is made of, and at what level failures on each of those components should be handled.

etc3() races with the wait(), so the proper way of handling etc3() failure depends on when that failure happens.

There is no wait in the submission code path for exec_fu - there's a callback added for handle_exec_update though, which handles post-completion (for both success and failure completion).

pseudocode. It means that the app_fu is only done when the exec_fu is done.

I'm unclear why you argue that:
etc1(), exec_fu = seq(etc2(), future(exec())), etc3(), wait(exec_fu)
can flatten to:
etc1(), etc2(), etc3(), exec()
These are all side-effectful things, and exec() could plausibly run entirely before etc3 even starts, which would be a different behaviour to etc1(), etc2(), etc3(), exec().

I should have said "for reasonable observable purposes". Let's try with fork/join:
exec_fu = fork(exec()), etc3(), join(exec_fu)
It doesn't matter how things run if exec() and etc3() don't change shared state.
So the point is to add the callback handler to the exec_fu after etc3() completes, i.e., as the very last step in the whole launch process. That guarantees that the exec_cb cannot be called nondeterministically, not that exec() completes deterministically. Adding a callback is equivalent to wait() or join() on the future, which, for the purpose of our discussion, do not mean anything at the Python thread level but describe the behavior at an abstract level.

If etc3() is code that has to happen after execution submission has happened - for example code that logs in monitoring that the task has been submitted - that's wrong to be doing before the task been submitted.

In the pseudocode, future(x) launches x, so that happens before etc3(). x runs in parallel with etc3().

I'm unclear if that's an artefact of the not-Python language you are using for pseudocode - I would be more comfortable discussing technical details of execution ordering and error propagation using Python-style pseudocode based more around what the actual DFK code does.

Using a language whose semantics are fundamentally ill-equipped to deal with concurrency leads to a lot of unsaid things about what happens when. But let's try:
def submit(app_fu, task):
try:
etc1() # there is no point in retrying this since exceptions here are not related to how some executable runs on some remote resource
exec_fu = launch(task)
exec_fu.add_callback(...)
except:
app_fu.fail()
(optionally)
if exec_fu: exec_fu.cancel()
def launch(task):
etc2() # same as etc1()
exec_fu = executor.submit(task) # this call guarantees that either an exception is thrown or that task is launched and an exec_fu is returned. All exceptions related to task after this method returns are set on exec_fu
etc3() # unless etc3() does nothing meaningful, which I don't think can be guaranteed easily, failures of etc3() should be consequential.
return exec_fu

A related thing to this, maybe, is that there is no reasonable "everything-is-broken-time-to-abandon-everything" behaviour: this is a library sitting inside other code, not a workflow system where we can exit the top level unix process. Something that I think is related arises with (non-)lazy failures - issues #282 has some discussion there.

I'm assuming we're discussing this in the context of how errors in doing all the things that an app is made of are handled. So I'm not assuming some workflow context, but everything is in the context of that app_fu.

So the point is to add the callback handler to the exec_fu after etc3() completes, i.e., as the very last step in the whole launch process. That guarantees that the exec_cb cannot be called nondeterministically,

It's not just trying to stop the exec_fu callback from happening non-deterministically that I care about: it is that once you've launched the task execution via executor.submit() (the potentially large piece of work that is what the user wants done), then the world is pretty much committed to that happening (or happening and failing itself) - the task can't be unlaunched in the case of a later exception.
After that's happened, it's not clear to me that it is reasonable to say "well that core computation is going to progress, but you don't get the result because we hit an exception in some logging code". It certainly is different than the current behaviour but I don't see that it is better.
Once the commitment has been made that the core task code is going to run inside an executor, (roughly executor.submit returning) then error handling for anything after that has to take into account that that commitment has been made.

Incidentally, I'm assuming that there is some head scratching on how to handle global context, like shutting down various central components or what exactly constitutes a "run" that at the moment is handled in an ad-hoc way, like shutting things down when the last known app completes or when the Python VM shuts down, there being cases when only one of these strategies is ideal, but not necessarily the same.

Broadly the state is: a "run" is a DataFlowKernel instance. You can shut it down explicitly, (using dfk.cleanup or it will get shut down at process termination.
You can many DFKs in a python process at once, although there sometimes a primary one which app invocations will default to using - this happens less in script style user code, but more in notebook style code.
It's legal to have a DFK instance with no work to do - more work can appear later after some other non-parsl computation makes futher parsl app invocations - and that is a common way to do "dependencies", rather than using parsl's dependency handling.

[...]

After that's happened, it's not clear to me that it is reasonable to say "well that core computation is going to progress, but you don't get the result because we hit an exception in some logging code". It certainly is different than the current behaviour but I don't see that it is better.
Once the commitment has been made that the core task code is going to run inside an executor, (roughly executor.submit returning) then error handling for anything after that has to take into account that that commitment has been made.

If it can be guaranteed that the "after" code is only stuff that we don't care about, sure (though we should be careful not to project what we don't care about as something that shouldn't be cared about). But you can't make this guarantee in general. It could be critical code. So I would say it's better to lose some CPU time than have unpredictable behavior. Fail for all uncaught errors in "after" code and, if there's code that we can explicitly identify as non-critical, for some definition of "non-critical", then wrap that portion into a handler that ignores/logs the error.

Maybe I misunderstand things. The app_fu is done when a bunch of constituent fus and/or non-fus are done. Presumably any errors in the constituents should cause the app_fu to fail. I see in the code that there is handling on the failure of the exec_fu, which triggers retries and whatnot. Let's call those things, your stuff that needs to happen, exec_cb. What you suggest says that we, in fact, want exec_cb invoked not just when exec_fu fails, but also when other things fail.

The basic app execution is:
call executor.submit and when the returned executor future completes, whatever comes out of it is used to set the value of the AppFuture.
(Some of) the future related things around that are:

the memoization table already has a result - in which case instead of getting the executor future from executor.submit, an executor future already exists in that memoization table, happens to be completed already, and is used as the executor future for this invocation.

retries are enabled, in which case an exception in a completed executor future does not turn into a exception in the AppFuture, but instead a new executor future is made by calling executor.submit and replaces the old executor future.

dependencies on earlier apps are handled: if a parameter to the current app invocation is a Future, wait for it to complete before doing the executor.submit. So at that point, there is an AppFuture with no executor future to provide the result.
It might be that a dependency completes with an exception rather than a regular result; in that case we cannot proceed and the current app has to fail. To do that, instead of acquiring the executor future with executor.submit, the executor future  is a "constant" future that describes the dependency failure. Otherwise, the executor future will come from the usual executor.submit invocation.

File stage-in can make new app invocations and make the current app depend on those completing. As far as future handling is concern, that should be handled by the above dependency mechanism rather than something separate: a file stage-in error is a dependency error that propagates to this app like any other dependency error.

File stageout can happen as new app invocations which depend on the current exec_fu. The AppFuture does not wait for stage out to complete before it gets a value (for historical implementation reasons, rather than any particularly deliberate choice - see #1279). So as far as the current code is concerned, this isn't a thing that needs to have happened for an AppFuture to complete.

Other sources of breakage are, I think, entirely "parsl internal code" breakages rather than externally caused breakages - the most common at the moment being monitoring code breaking.

Another thing to do with especially monitoring there is that monitoring calls throwing exceptions probably shouldn't be regarded as application failures: they're attempts to describe what is happening, but if they didn't work, that's a failure of monitoring, not a failure of app execution.

Another thing to do with especially monitoring there is that monitoring calls throwing exceptions probably shouldn't be regarded as application failures: they're attempts to describe what is happening, but if they didn't work, that's a failure of monitoring, not a failure of app execution.

We're going a bit backwards here. As I said before, there is no guarantee that errors in etcs() are non-critical. So in deciding how to handle unexpected things, we cannot make the assumption that the right thing to do is ignore errors. It so happens that this discussion was triggered by an error in monitoring, but that has little to do with this PR.
But to get back to your point, yes, they are not application failures. They are failures of the system in running the application with all the bells requested by the user. So when I say parsl.run_my_application_with_bells() and some bell fails, then run_my_application_with_bells() fails.
Perhaps we see things differently because we see monitoring differently: some addon that shouldn't be cared about vs. an integral part of the system. The fact that I jumped on board when monitoring was already there makes me see it more as the latter. But I'd argue that's also how new users would see it.

Monitoring is in no way an integral part of the system, despite its presence laced through out the DFK.
:(

What I think this PR should do:
Audit each part of the task launch code path and decide if it failing is the kind of failure which means the app cannot be launched.
If it is such a failure and it is before executor.submit, use the Future() based method described above to give an Exception result.
If it is not that kind of terminal failure, decide who (if anyone) cares about this kind of failure and send the failure that way instead, and continue with submission. Possibly that is only monitoring, and for that, logging it at log level ERROR is probably the right thing to do for now.
If it is that kind of terminal failure and it is after provider.submit, then this is probably an irrecoverable parsl internal failure and you are welcome to propose some suitable method of exploding the whole of parsl.

Monitoring is in no way an integral part of the system, despite its presence laced through out the DFK.
:(

Precisely. However, to me, and everybody using it, and to future users who see it documented and want it, it is an integral part of the system.
But again, we need to address the fact that errors, in integral or non-integral parts of the system, however subjectively defined those are,, are presently being ignored. This can lead to hangs and is not acceptable.

If it is not that kind of terminal failure, decide who (if anyone) cares about this kind of failure and send the failure that way instead, and continue with submission. Possibly that is only monitoring, and for that, logging it at log level ERROR is probably the right thing to do for now.

That is an impossible decision to make when handling things at the top level.
def f():
  a()
  b()
  c()

def g():
  try:
    f()
  except:
    # cannot generally decide here where the error is coming from and whether the error should cause f() to continue to execute after the error was thrown; that is part of the inner workings of f().

What could happen is this:
def f():
  try:
   a()
  except:
   # somebody decided that this is not relevant, ignore
  b()
  try:
   c()
  except:
   # idem

def g():
  try:
    f()
  except:
    # this still needs to be here and we still need to do something about it irrespective of what the internals of f() are. We cannot, at this point, assume that the error is benign, nor do we have the means to do much about it without some serious abstraction inversion/spaghetti control flow.

So no. This PR is meant to fix g(), not f(). f() needs to be dealt with separately. That said, this particular PR in its current form does not properly fix g() for reasons discussed above, so it needs to be redone.
What I suggest is the following:
def launch_if_ready(task_id):
  assert self.tasks[task_id] is not None
  assert self.tasks[task_id]['app_fu'] is not None
  try:
    exec_fu = self._launch_if_ready(task_id)
    assert exec_fu is not None
    exec_fu.add_done_callback(partial(self.handle_exec_update, task_id))
  except Exception as ex:
    self._fail(task_id, ex)
   # alternatively, self._fail_with_retries(task_id, ex)

def _fail(task_id, ex):
  ...
  fake_exec_fu = Future()
  fake_exec_fu.retries_left = 0
  fake_exec_fu.set_exception(ex)
  self.tasks[task_id]['exec_fu'] = fake_exec_fu
  self.tasks[task_id]['app_fu'].parent_callback(fake_exec_fu)

Additionally, but separately, identify code that is broken in the call path of _launch_if_ready and fix it or remove it. Only ignore errors if code, under the assumption that it is stable, should ignore errors.

A broad catch like this makes sense, but we need to be careful about what we do with the caught exception.

A catch like this would not be there to catch exceptions that we expect to happen during normal usage, but to catch exceptions that otherwise cause silent deadlocks and report them somewhere. So I would recommend not seeing this as a tool that has anything to do with users, except in extreme cases, but something that has to do with us catching a particularly nasty class of problems before the user gets to use the code.

Setting the exception onto the app_future makes sense in fail early mode, but we've so far taken a lazy approach where we let the workflow proceeed as far as possible. Secondly, app_future exceptions in my mental model are for communicating the reason for the failure of user code. I worry about setting an exception when the result was already computed.

It can be difficult to intuitively think about what to do with errors that occur in one of two parallel sub-units of a parent unit. For concrete cases, it may seem like they should be handled differently based on who finishes first or maybe on how mature the code in each sub-unit is. I would urge you to resist that thinking.

If a failure prevents the computation of a task:
    report that via the the app_future.exception.

If a runtime failure potentially blocks the workflow:
    report a critical error and trigger DFK shutdown.
else:
    report to the log.

Do we know what exceptions can bubble up here? Monitoring exceptions for now should be in the non-critical category (report to log, and go on).

That's the problem. Anything can bubble up here and you won't know where it bubbled from, so you must assume the worst.


Slight display issue in dropdowns with more items than their default point to activate scrolling

Tiny follow-up to #2183 for @AlexanderGrooff and friends! Easiest explained with a screen capture:

It seems the scrollable area is correct when it is at or below the threshold for adding scrolling. When more items are added a slight bit of overflowed empty space gets added in the list. Probably just a small calculation quirk somewhere?

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/31312434-slight-display-issue-in-dropdowns-with-more-items-than-their-default-point-to-activate-scrolling?utm_campaign=plugin&utm_content=tracker%2F5279&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F5279&utm_medium=issues&utm_source=github).

Thanks, I'll have a look at it!

Additional thought: Maybe we should leave slightly more than x entries visible if there are > x entries total.
Rationale: If there are exactly three gameplay templates a fixed dropdown showing just three makes perfect sense. If there are four and we show a perfect fit for three maybe it'll be easy for users to miss that there are more?
If we show a partial 4th item to make it obvious there's more to scroll down to see that may help make that more obvious than the visible scrollbar alone.
Not the same as the original item in this ticket, but very similar. Just visibility vs. empty space.

That seems like a good idea :+1:. I'll work on the two subjects simultaneously somewhere this week.

:+1: :+1:

@Cervator I was trying to see this issue but I can't replicate it. All the dropsdowns that I see are actually sized exactly without any extra space below the items. Am I missing something?

@genuinelucifer I am able to replicate it. Assuming the worldgenerator menu has three items in it, you can set the worldGenerator.setVisibleOptions(3); in CreateGameScreen.java to 2. After doing that, I got the same image as @Cervator showed.

@AlexanderGrooff Oops. I understood the issue incorrectly.
Thanks for your help I was able to come up with a patch. I am submitting a PR now.


Split twitter code into separate client

This will allow cleaning up the code and lends itself more to expanding twitter bot.

Do you want this to parse feeds of /u/DealWithItbot? Or should it use PRAW to directly talk to reddit?
We can discuss this at length.

I think the reddit related messages should use local communication (i.e., they have to be running in the same place to share messages.)


java.lang.NoSuchMethodError: No virtual method load(Ljava/lang/String;)Lcom/bumptech/glide/DrawableTypeRequest; in class Lcom/bumptech/glide/RequestManager

I get this error when I try to open Imagepicker

Upgrade to Glide 4. Please try version 1.0.7.

This error is still now resolved in 1.0.8 version, It's keep crashing on my side. @k3j123 @fishwjy

You are facing this error because either you are using glide new version in your project or some library internally using newer version. When Gradle builds your project, It uses a newer version of Gradle. You can confirm this in External libraries of project in android studio. Use same version of glide will solve this problem.


Updated validations.py python script

Closes: #1

It's a good idea to open an issue first for discussion.

[ ] Tests pass
[ ] Appropriate changes to README are included in PR

@googlebot I signed it!


util-images/watch-list: replace ENABLE_CLIENT_GO_WATCH_LIST_ALPHA env var with KUBE_FEATURE_WatchListClient

What type of PR is this?
/kind cleanup

What this PR does / why we need it:
The previous environment variable is being replaced in https://github.com/kubernetes/kubernetes/pull/122791
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

/hold
until https://github.com/kubernetes/kubernetes/pull/122791 is merged

/assign @wojtek-t

with https://github.com/kubernetes/kubernetes/pull/122791, this makes sense to me.
/lgtm
keep the hold until both PRs are ready to merge and then you can coordinate merging them.

@marseel since Wojtek is out would you mind approving his PR?

/lgtm
/approve

the watch-list perf tests are executed once a day around 10 AM CET. The nearest run is tomorrow morning. There is plenty of time to merge both PRs.
/hold cancel


Update to Terraform 0.13 and validate terraform scripts in PRs

Minimum Terraform is bumped to 0.13 and the Packet provider is bumped to 3.0.1.
This also introduces Github workflows as the CI/CD tool and provides basic Terraform validation for PRs. This is step 0 on the way towards https://github.com/packet-labs/google-anthos/issues/91

terraform apply succeeded, but it looks like I have some errors in this deploy.
null_resource.anthos_deploy_workstation[0] (remote-exec): Setting up OS image as a VM template in vSphere...
null_resource.anthos_deploy_workstation[0] (remote-exec): Exit with error:
null_resource.anthos_deploy_workstation[0] (remote-exec): Failed to create and prepare admin workstation: failed to prepare admin workstation: failed to create VM Template for OS image "admin-appliance/1.4.0-gke.13/gke-on-prem-admin-appliance-vsphere-1.4.0-gke.13.ova" from bucket "gke-on-prem-release": datastore 'vsanDatastore' not found
null_resource.anthos_deploy_workstation[0] (remote-exec): *************************************************************************
null_resource.anthos_deploy_workstation[0] (remote-exec): ** Errors in the above section related to enabling APIs and creating   **
null_resource.anthos_deploy_workstation[0] (remote-exec): ** IAM roles are expected and can safely be ignored                    **
null_resource.anthos_deploy_workstation[0] (remote-exec): *************************************************************************

This seems to stem from
null_resource.vsan_claim[0]: Provisioning with 'remote-exec'...
null_resource.vsan_claim[0] (remote-exec): Connecting to remote host via SSH...
null_resource.vsan_claim[0] (remote-exec):   Host: <IP_ADDRESS>
null_resource.vsan_claim[0] (remote-exec):   User: root
null_resource.vsan_claim[0] (remote-exec):   Password: false
null_resource.vsan_claim[0] (remote-exec):   Private key: true
null_resource.vsan_claim[0] (remote-exec):   Certificate: false
null_resource.vsan_claim[0] (remote-exec):   SSH Agent: true
null_resource.vsan_claim[0] (remote-exec):   Checking Host Key: false
null_resource.vsan_claim[0] (remote-exec): Connected!
null_resource.vsan_claim[0] (remote-exec): Traceback (most recent call last):
null_resource.vsan_claim[0] (remote-exec):   File "/root/vsan_claim.py", line 95, in <module>
null_resource.vsan_claim[0] (remote-exec):     smallerSize = min([disk.capacity.block * disk.capacity.blockSize for disk in ssds])
null_resource.vsan_claim[0] (remote-exec): ValueError: min() arg is an empty sequence

I also got null_resource.anthos_deploy_cluster[0] (remote-exec): Error: timeout - last error: dial tcp <IP_ADDRESS>:22: connect: no route to host 🤔

just a suggestion, it might be cleaner to make these 2 changes in 2 separate PRs.

I'm closing this in favor of #113 moving forward first. We can revisit these changes when the vSphere module is independent (which will reduce the changes needed here and avoid duplication of effort).

I'm closing this in favor of #113 moving forward first. We can revisit these changes when the vSphere module is independent (which will reduce the changes needed here and avoid duplication of effort).


Slightly improve performance

Follow-up of #179 for #144.
Avoiding calling addition every time.

I think i resolved this differently.


ReferenceError: Can't find variable: Set

Hey,
so I am getting the following error:
ReferenceError: Can't find variable: Set

  http://localhost:8080/js/webcomponents-lite.js:147
  http://localhost:8080/js/webcomponents-lite.js:192

The actual code is: new Set("…
Any idea why this shows up? Is it possible the phantomjs version does not support Set? Can I avoid this somehow?
Can I provide any more information that could help?
Thanks.

The latest version of PhantomJS does not support ES2015 Set.
You can try the experimental branch of uncss that uses jsdom instead of PhantomJS by installing uncss-jsdom instead. See https://github.com/giakki/uncss/pull/280

Thanks for the info, will try this.

@mikelambert can you close?


microbenchmarks MatrixUtils_persp_transformPoint_iteration regression

Not high enough yet to be a P0:

https://github.com/flutter/flutter/pull/59818 may be the culprit.

Bisected this to https://github.com/dart-lang/sdk/commit/411272691c28edb76ac77c6b2e99014ead00fc9a
@alexmarkov
Interestingly I was only able to reproduce the increase in this benchmark's running time when building the engine and running the benchmark from a Mac.  On a Linux host I see the opposite effect - the Dart PR above yields a slight decrease in the benchmark metric.

@jason-simmons Could you please add more details about this benchmark: how to run it and reproduce the regression, is it running on the host or on the device, what kind of device was used. If it runs on the device, then did you use the same device on your Linux and Mac hosts?

It's a devicelab benchmark (see https://github.com/flutter/flutter/tree/master/dev/devicelab)
It's part of the microbenchmarks suite (https://github.com/flutter/flutter/blob/master/dev/devicelab/lib/tasks/microbenchmarks.dart)
The task measured by the benchmark runs on the device.  I ran it on the reference Android device model used in the device lab (Moto G4).  However, the Mac and Linux runs used two different Moto G4 devices.

Not sure I understand why it could be regressing on one device, but not on another similar device.
I looked at the differences in the ARM disassembly for the following methods which appear in the profile for this benchmark:
main
MatrixUtils.transformRect
MatrixUtils.transformPoint
IntegerImplementation._moduloFromInteger
IntegerImplementation.~/

They are the same modulo differences in object pool offsets.
There are minor differences in the order of compilation, which may cause different order of executable code of compiled functions in the AOT snapshot. Maybe that caused this regression, but this should be only visible on this kind of tight-loop tiny micro-benchmarks.

I'm not sure what we can do about this regression. @mraleph @mkustermann any ideas?

If we don't see any differences in the generated code then I suggest we just rebaseline the benchmark and close this issue.

This was rebaselined.


Marks stale projects with gray background

Hi @barnesjoseph, I think might have implemented the wrong UI design. The one we chose only text, button and author image greyed out. First is what i can see, second is what we agreed on .

@garimame I have updated the styling to match the selected grayed-out design. Let me know if you'd like the stale cards to still have clickable buttons or if those should be inactive.