Made it work under python3 BUT python2 now returns an error

Dear,
I ported it to python3 but broke python 2 support :(
Obviously no good for you, nevertheless I create a pull request in case you have a quick fix.
Feel free to reject, of course.
This is a, it works for me situation.
Thanks for the initial efforts.
$ python2
Python 2.7.14 (default, Oct 12 2017, 18:39:18)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.37)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

import japanese_numbers
japanese_numbers.to_arabic_numbers('一を聞いて十を知る。')
(1,)
japanese_numbers.to_arabic('銀河の向こう、六千三百二十一億千五百十一万二千百八十一光年彼方。')
[Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python2.7/site-packages/japanese_numbers/result.py", line 16, in repr
return self.str()
File "/usr/local/lib/python2.7/site-packages/japanese_numbers/result.py", line 23, in str
format(self.class.name, self.dict).encode('utf8')
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe5 in position 19: ordinal not in range(128)

Hi @SteveClement, firstly really thanks for your contribution.
This japanese-numbers-python should be running on Python2 environment.
To reproduce this issue, could you tell me more detail about your environment and code?

Dear @takumakanari I will try and fix the python2 code and let you know exactly where the issue is.
Thanks for the quick reply.

@SteveClement Can you try to add from __future__ import unicode_literals to top of your script?

@SteveClement Could you try the following branch with Python2 environment?
I think it fixes an issue.
https://github.com/takumakanari/japanese-numbers-python/tree/set-encode

@takumakanari that works!

@SteveClement Great! I'll merge & release it later. Is it ok?

I'll close if there is nothing problem.

Dear, there is an issue nevertheless on Python2 (works with python3)
~/code/j-n-py2 -> Branch:set-encode $ git remote -v
origin	git@github.com:takumakanari/japanese-numbers-python.git (fetch)
origin	git@github.com:takumakanari/japanese-numbers-python.git (push)
$ python2
Python 2.7.14 (default, Sep 25 2017, 09:53:22)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.37)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

import japanese_numbers
japanese_numbers.to_arabic('一を聞いて十を知る。', encode='eucjp')
Traceback (most recent call last):
File "", line 1, in
File "japanese_numbers/parser/to_arabic_parser.py", line 33, in to_arabic
decoded_val = val if isinstance(val, unicode) else val.decode(encode)
UnicodeDecodeError: 'euc_jp' codec can't decode bytes in position 2-3: illegal multibyte sequence

This is on a MacBook latest macOS 10.13.2, uname -a:
Darwin MacBook.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov  9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64

@SteveClement Are you using euc-jp in your console? You don't need to set encode option if you're using utf-8.

BTW: v0.1.1, including a patch to fix encoding problem, has already released.

yeah, that was probably it. Thanks, it works for me now.

Thank you 👍


"Blank" screen in web browser

Hi. My balenacam is not working. When I try to access the WebRTC stream, everything but the stream itself loads.
I can double-click to go fullscreen etc - but no video.
The camera and RPI 3 A+ is confirmed working.
From the logs - the only weird thing is the .local address instead of the IP my computer is on?

09.11.20 12:20:45 (+0100) <balena-cam> https://github.com/balena-io-playground/balena-cam 09.11.20 12:20:45 (+0100) <balena-cam> ############################################################# 09.11.20 12:20:45 (+0100) <balena-cam>  09.11.20 12:20:45 (+0100) <balena-cam> ======== Running on http://<IP_ADDRESS>:80 ======== 09.11.20 12:20:45 (+0100) <balena-cam> (Press CTRL+C to quit) 09.11.20 12:21:00 (+0100) <balena-cam> /usr/local/lib/python3.5/dist-packages/pyee/_base.py:81: RuntimeWarning: coroutine 'on_iceconnectionstatechange' was never awaited 09.11.20 12:21:00 (+0100) <balena-cam>   f(*args, **kwargs) 09.11.20 12:21:00 (+0100) <balena-cam> Task exception was never retrieved 09.11.20 12:21:00 (+0100) <balena-cam> future: <Task finished coro=<RTCPeerConnection.__connect() done, defined at /usr/local/lib/python3.5/dist-packages/aiortc/rtcpeerconnection.py:554> exception=ValueError("'2e20163f-0920-4908-b6b7-f6e3b8ce882a.local' does not appear to be an IPv4 or IPv6 address",)> 09.11.20 12:21:00 (+0100) <balena-cam> Traceback (most recent call last): 09.11.20 12:21:00 (+0100) <balena-cam>   File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step 09.11.20 12:21:00 (+0100) <balena-cam>     result = coro.send(None) 09.11.20 12:21:00 (+0100) <balena-cam>   File "/usr/local/lib/python3.5/dist-packages/aiortc/rtcpeerconnection.py", line 559, in __connect 09.11.20 12:21:00 (+0100) <balena-cam>     await iceTransport.start(self.__remoteIce[transceiver]) 09.11.20 12:21:00 (+0100) <balena-cam>   File "/usr/local/lib/python3.5/dist-packages/aiortc/rtcicetransport.py", line 284, in start 09.11.20 12:21:00 (+0100) <balena-cam>     await self._connection.connect() 09.11.20 12:21:00 (+0100) <balena-cam>   File "/usr/local/lib/python3.5/dist-packages/aioice/ice.py", line 356, in connect 09.11.20 12:21:00 (+0100) <balena-cam>     if (protocol.local_candidate.can_pair_with(remote_candidate) and 09.11.20 12:21:00 (+0100) <balena-cam>   File "/usr/local/lib/python3.5/dist-packages/aioice/candidate.py", line 114, in can_pair_with 09.11.20 12:21:00 (+0100) <balena-cam>     b = ipaddress.ip_address(other.host) 09.11.20 12:21:00 (+0100) <balena-cam>   File "/usr/lib/python3.5/ipaddress.py", line 54, in ip_address 09.11.20 12:21:00 (+0100) <balena-cam>     address) 09.11.20 12:21:00 (+0100) <balena-cam> ValueError: '2e20163f-0920-4908-b6b7-f6e3b8ce882a.local' does not appear to be an IPv4 or IPv6 address

3dprintercam_alfheim-prusa-mini-09.11.20_15 16 19.txt
Attached log

Looks like some sort of Bonjour-related problem?
Also tested on my Cellphone wifi sharing, to remove Bonjour from the equation. Same problem

@aweussom balenaCam doesn't work with mdns adresses. In order to disable them see here https://github.com/balenalabs/balena-cam#additional-information.

That option is not available in my Chrome.
I blocked mDNS with the windows 10 firewall, and that worked fine:
[In a dministrator powershell]
Set-NetFirewallRule -DisplayName "Google Chrome (mDNS-In)" -Enabled True -Action Block


add goreleaser in circleci

Signed-off-by: yeya24<EMAIL_ADDRESS>
Ⅰ. Describe what this PR did

Auto build tarballs in each release
publish images to docker hub in each release

Ⅱ. Does this pull request fix one issue?

fixes #1072
Ⅲ. Why don't you add test cases (unit test/integration test)? (你真的觉得不需要加测试吗？)
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

Codecov Report

Merging #1077 into master will increase coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1077      +/-   ##
==========================================
+ Coverage   47.15%   47.17%   +0.01%
==========================================
  Files         117      117
  Lines        7176     7176
==========================================
+ Hits         3384     3385       +1
  Misses       3527     3527
+ Partials      265      264       -1

Impacted Files
Coverage Δ

supernode/daemon/mgr/scheduler/manager.go
22.6% <0%> (+0.68%)
:arrow_up:

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 edec7a8...d37548c. Read the comment docs.

Well done. LGTM.


Visual Studio Code Support?

I keep getting

this error, and i cant select prettier as a formatter for shell scripts even though it works in the cli. Not sure waht to do here.

Thanks for reporting, but I can't reproduce it, and it seems beyond our control, maybe you should post an issue to prettier-vscode.

For reference, I was able to make it work with:
// .vscode/settings.json
{
   "prettier.documentSelectors": ["**/*.sh"],
   "[shellscript]": {
     "editor.defaultFormatter": "esbenp.prettier-vscode",
     "editor.formatOnSave": true
   }
}

Ideally the VS Code extension should automatically discover such files, but not even the CLI does (#281).


Using PSGallery to Install Pester in AppVeyor File

This is for PowerShell/DscResources#147.

This change is

Hi @kwirkykat, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Katie Keim). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

PSSA errors failing the tests have been submitted under #3.


Fix compatibility with pip master (pip>=19.4)

Moved RequirementPreparer.session to Resolver.session.
See https://github.com/pypa/pip/pull/7290

Changelog-friendly one-liner: Add compatibility with pip>=19.4.
Contributor checklist

Provided the tests for the changes.
[X] Gave a clear one-line description in the PR (that the maintainers can add to CHANGELOG.md on release).
[X] Assign the PR to an existing or new milestone for the target version (following Semantic Versioning).

@vphilippon PyPIRepository.resolve_reqs getting uglier version by version 😒

@codingjoe thanks!


DanBot hosting  client

What is the use of danbot hosting client and how should we use it?

Nah it's of 0 use


:optional kills the entire node

If I am trying to adlib something like this:
"url": "{{foo:optional}}/more/stuff/here"

and foo is falsey, then the resulting adlibbed variable url will be undefined, whereas I'd expect it to be "/more/stuff/here".

that's by design.
:optional is a mechanism for templaters to insert a node if and only if a value is present.

Fair enough.


Semi transparent objects rendering

Hello,
I have been using vtkplotter do develop an application to render anatomical data of the mouse brain in python (https://github.com/BrancoLab/BrainRender).
It has been working great so far, the only problem I have found is when I display multiple actors (brain regions) with alpha < 1. Then, when the scene is rendered it looks weird:

for instance here the two structures circled in blue should be behind the larger one circled in red.
This seems to be a consistent bug: with multiple semi-transparent object they are not rendered so that an object behind another is partially hidden. The effect is even more evident when the objects have multiple colors.
Because of how densely structured the brain is, it's crucial to be able to display structures with some transparency so that you can see what's behind the surface, so it would be great if you could advise a way to fix this.
Thank you,
Federico

Hi Federico
cool project! I think this is a general vtk-related problem, as vtkplotter has no control over it.
Probably it's fixable by setting:
from vtkplotter import settings
settings.useDepthPeeling = True
# settings.useFXAA = True

(perhaps with some combination of the two flags).
See also related example here where actually one can reproduce the issue by setting useDepthPeeling=False.
Hope this helps!
Marco

Hi Marco,
That fixed it!
Just an unrelated question (don't want to open an issue for this): are there ways to improve performance?
I've had some users who expressed the desire to rendered large number of objects (10k - 1M spheres ), but when I tried it my computer started complaining at about 10k objects. Any idea?
Thank you very much,
Federico

Cool!
..if you create many actors independently at some point you will lose performance.. things you can do are:

reduce the number of vertices/resolution in meshes (e.g. with shapes.Sphere(res=10)
decimate large meshes (actor.decimate(fraction))
substitute Sphere with Points (or Spheres)
use glyphs for repeated objects, see examples:
manyspheres.py, manypoints.py and glyphs.py  or glyphs_arrows.py

Let me know if this improves speed/memory
Cheers, Marco


Search engine indexes out of sync ?

Hello
Although the page exists (http://git-scm.com/docs/git-worktree), searching for "git-worktree" returns no matches. Searching without quotes gives some wild matches (basically on the git word) but not the expected page I first mentioned.
Regards

This issue seems to be resolved.


Use of the Loupe within the DTRichTextEditor causes a crash

Hi,
I am using the rich text editor (DTRichTextEditor) in our project and are experiencing an issue with the use of the magnifying glass loupe (i.e. cursor positioning function) that is causing our app to crash.
Here are the repro steps:

Embed the rich text editor into a skeleton app that contains a view that holds the DTRichTextEditor component. You can find our example project that does this here.

Start the app. Do not type any letters, just press and hold for a few seconds to bring out the loupe for cursor positioning.

Lift your finger press to make the loupe disappear

Press and hold again for a few seconds to bring out the loupe again.

Bug: This makes the project crash at: [DTLoupeView refreshLoupeContent] / [DTLoupeLayerDelegate displayLayer:]

The problem can appear on other occasions, but the steps above are the most reliable to reproduce the issue.  We are testing on iOS 8.  xcode 6.3 with iOS sdk 8.3
I'd would like to offer $200 USD to the person who can produce a fix for this issue.  If the fix requires a reimplementation the magnification using the modern snapshotting methods, I'd understand that this would need more work and would pay $800 USD instead of $200 USD.  Transfer of payment on a successful code review from Oliver and subject to final testing within my project.
Many thanks,
Simon.

I think this is literally a one line fix, if you're okay with dropping support for iOS 6. I was able to reproduce quite regularly in the simulator in the original code. I switched to the new API and the crash went away.

Hi Amro,
Thanks for your note.  We do not support iOS 6 with our app, so it is ok for me.  Oliver?
Best,
Simon.

Here's a pull request, in case the fix checks out for you as well. I used your sample to test. Just replace the line in the try block with the line from my patch and you should be good to try it.
https://github.com/Cocoanetics/DTLoupe/pull/2

Hi again,
Unfortunately it does not solve the problem very well.
Its not crashing anymore which is very good! but you can't see text inside the loupe anymore:( - at least on iOS 8

Odd, I could see it in iOS 8 sim.

Yes, showing nicely on simulator but not on device. One of those weird bugs..

I think it's got to do with the editor using CATiledLayer. Maybe this needs an update as well so that it would call the text rendering methods when rendering the hierarchy?

That's one way to fix it but it looks like there's a bug in renderInContext: in iOS 8 that chokes on empty rects when rendering.

@amro please elaborate what you mean with "chokes on empty rects"... is that something we could prevent?

Take another look when you have a chance. I tried to debug views after reproducing the crash and saw that the tools couldn't properly serialize some layers b/c they had NaN x or y positions. The crash can also happen if layers with frames equal to CGRectZero happen.
I'm not sure this is ultimately the right place to fix this problem. It might be that DTRichTextEditor needs to do additional validation on the frames of its layers. But fixing it here means DTLoupe will work with other views that have the same behavior.

This code fixes the crash and seems to be a good security if any layer with a wrong frame comes to rendering method.

hi @amro and @coconetics,
Hope you are both well.
@amro, we have been testing your proposed fix a lot more over the last few days.  It is working well on iOS 8 and iOS 7. While not critical for us now, but it would be valuable to have your opinion on, is the fix does not work on the current Beta of iOS 9.  On our test iOS 9 device, the loupe displays a black image within it (no text) and in fact crashes on the simulator.  Would be great to get any early thoughts on that.
@coconetics, would love your opinion on @amro changes when you get a spare moment so we can wrap this up and get amro some $ :-).
Thanks guys!

@slm-2015 Odd. I just tried my change in your test project on my iPhone 6 running iOS 9b1 and it worked great. It worked fine in the sim as well. I did have to change line 106 in DTRichTextEditorView.m from __unsafe_unretained to __weak before it would build though. Is this the test you ran or did you do something else?

@amro Hey sorry i was testing the loupe in a project with a bit more complicated view hierarchy.
Prepared a sample project that is demonstrating the problem here: http://sendfile.pl/pobierz/412005---zR7B.html
Managed to produce an adhoc fix in DTLoupeView.m line 244 which basically limits the depth of searching for a rootView but probably thats not the best way to fix it.
Any thoughts you had on a better way to fix it would be great.

With your change (line 243 - "return view.superview.superview") still commented, it still works for me. I'm on iOS 9 beta 2 using an iPhone 6. The same is true in the simulator. It seems this is a little tougher to reproduce. You're on beta 2 and using Xcode build 7A121l, right?

Yes Xcode beta 2 build 7A121l. Its easier to get it on the iPad, both device and simulator.

I see. I was able to reproduce the black image issue in the iPad sim. Commenting out my change did not resolve it so I believe it's a separate problem unrelated to this issue. I don't have a lot of time to look into this one immediately but I did try a few things to no avail.

hi @amro ,
Thanks for your response on the iOS 9 issue.  Let's wrap up on this problem first then.  @Cocoanetics, would love your thoughts on the code changes from amro.
Many thanks,
Simon.

hi @slm-2015 - I trust @amro implicitly, he is one of the big contributors to DTCoreText where he implemented cascading CSS support. So if that fixes the issue, then I am good.
I believe that we still want to be able to use the modern way of snapshotting, but the CATiledLayer used to display it needs to draw its content on the main thread when the snapshotting method recurses to it.
So, step 1 would be to merge this fix - if you can verify that the crashes no longer occur.

Thanks all. @amro I have emailed you separately to ask for your payment details.  @Cocoanetics - we will be happy to retest once you have merged the changes.  Cheers.

this didn't work for me on is and issue #8 describes the fix - which isn't in DTLoupe -- for me hideInvalidLayersInView isn't needed either :) [though it won't hurt :D]


Create CONTRIBUTING.MD contributing guideline

Hi, @alemorm I would Iike to work on this.

Hey @Yashs911, awesome! Feel free to fork this project and submit a pull request with the change.
Just remember to clone this repository as well as the hugo-notice submodule by running the following command in any directory:
git clone --recursive https://github.com/alemorm/ucsf-radiology-getting-started.git
As for the Hugo version, I have used different versions (0.72.0 and 0.75.1) so I don't think there should be a compatibility issue as long as you use anything higher than 0.72.0. Just grab a precompiled binary for whatever operating system you are using (I use 64-bit Ubuntu) on their release page.
I will open a new issue to work on a more comprehensive contributing guideline.
Originally posted by @alemorm in https://github.com/alemorm/ucsf-radiology-getting-started/issues/15#issuecomment-701522539

PR #17 was a good starting point for this issue and provided a template for CONTRIBUTING.md but it still needs to be more specific to this project. Reference the Getting Started section of the README.md at the beginning of the file (Issue #18)


added unittest

OK, I think (hope?) I'm getting the hang of this git business, might have to get stuck in and have some fun
:)

@mgbox this all looks good mate. We've all had to struggle with Git at first, it's good that your learning the ropes of open-source contributing. Eventually add a profile photo and some details to your Github profile because recruiters will look at it in future :+1:


ValueError: not enough values to unpack (expected 3, got 2)

Traceback (most recent call last):
File "train.py", line 94, in
train(args)
File "train.py", line 36, in train
for bi, (img, patches, _) in enumerate(dataloader):
File "/home/tq/anaconda3/envs/p3.6torch0.4.1/lib/python3.6/site-packages/torch/utils/data/dataloader.py", line 314, in next
batch = self.collate_fn([self.dataset[i] for i in indices])
File "/home/tq/anaconda3/envs/p3.6torch0.4.1/lib/python3.6/site-packages/torch/utils/data/dataloader.py", line 314, in
batch = self.collate_fn([self.dataset[i] for i in indices])
File "/home/tq/nets/cae/image_folder.py", line 20, in getitem
h, w, c = img.shape[:3] #delete [:3]
ValueError: not enough values to unpack (expected 3, got 2)

It seems that your image only has 2 dimensions (h, w). Are you using grayscale images?


NanoMod issues: Stops at index_reference

Dear all,
Dear @lucacozzuto ,
I would really appreciate your assistance in solving the following issue, which occurred when I tried to run NanoMod.
Please see the issue below.
(base) root@........:/media/localarchive/master_of_pores/NanoMod# nextflow run nanomod.nf -with-docker
N E X T F L O W  ~  version 20.07.1
Launching nanomod.nf [modest_carlsson] - revision: ae4d8a4c65
╔╦╗┌─┐┌─┐┌┬┐┌─┐┬─┐  ┌─┐┌─┐  ╔═╗╔═╗╦═╗╔═╗╔═╗
║║║├─┤└─┐ │ ├┤ ├┬┘  │ │├┤   ╠═╝║ ║╠╦╝║╣ ╚═╗
╩ ╩┴ ┴└─┘ ┴ └─┘┴└─  └─┘└    ╩  ╚═╝╩╚═╚═╝╚═╝
====================================================
BIOCORE@CRG NanoDirectRNA. Detection of modification and polyA length (RNA) - N F  ~  version 0.1
*****************   Input files    *******************
input_path                              : /media/localarchive/MasterOut
comparison                              : /media/localarchive/master_of_pores/NanoMod/comparison.tsv
********** reference has to be the genome *************
reference                               : /media/localarchive/DataRRP/Homo_sapiens.GRCh38.cdna.all.fa
output                                  : /media/localarchive/NanoMod_output
coverage                                : 5
************* tombo and epinano params ****************
tombo_opt                               : --num-bases 5
epinano_opt                             :
email                                   :
executor >  local (1)
[-        ] process > resquiggling                 -
[-        ] process > getModifications             -
[7c/08274e] process > index_reference              [  0%] 0 of 1
[-        ] process > CallVariantsForEpinano       -
executor >  local (1)
[-        ] process > resquiggling                 -
[-        ] process > getModifications             -
[7c/08274e] process > index_reference              [100%] 1 of 1 ✔
[-        ] process > CallVariantsForEpinano       -
[-        ] process > calcVarFrequenciesForEpinano -
Skipping the email

Hi, can you show me the content of comparison.tsv and the content of the folder /media/localarchive/MasterOut, please?

Hi, can you show me the content of comparison.tsv and the content of the folder /media/localarchive/MasterOut, please?

@lucacozzuto, Thanks for the fast reply!
Sure.
Please see below the content of comparison.tsv:

Please see below the content of MasterOut:

Ok so please have a look at the documentation here:
https://biocorecrg.github.io/master_of_pores/nanomod.html
In brief you need to run nanoPreprocess on the two datasets and generate two different outputs (i.e. two folders) and then you can use nanomod to make comparison between them.
L

Ok so please have a look at the documentation here:
https://biocorecrg.github.io/master_of_pores/nanomod.html
In brief you need to run nanoPreprocess on the two datasets and generate two different outputs (i.e. two folders) and then you can use nanomod to make comparison between them.
L

Thanks for sharing that. I have read the documentation https://biocorecrg.github.io/master_of_pores/nanomod.html
and it was clear that we need to work with two data sets (i.e. to compare control/exp).
Just to clarify the main steps:

I run nanopreprocess for .fasta5 files from experimental and control samples (e.g. WT and KO) separately from each other (step-by-step). As result, two or more different nanopreprocess output are folders formed.
Afterwards, I place these two or more nanopreprocess output folders into the common folder, which is intended for the input to Nanomod.
I edit comparison.tsv respectively to the names of nanopreprocess output folders, which correspond to the experimental or control sample.
I run Nanomod

Please let me know is it correct?
Best regards,
Stan

Yes it is fine
L
Il mar 17 nov 2020, 20:17 Stan<EMAIL_ADDRESS>ha scritto:

Ok so please have a look at the documentation here:
https://biocorecrg.github.io/master_of_pores/nanomod.html
In brief you need to run nanoPreprocess on the two datasets and generate
two different outputs (i.e. two folders) and then you can use nanomod to
make comparison between them.
L
Thanks for sharing that. I have read the documentation
https://biocorecrg.github.io/master_of_pores/nanomod.html
and it was clear that we need to work with two data sets (i.e. to compare
control/exp).
Just to clarify the main steps:

I run nanopreprocess for .fasta5 files from experimental and
control samples (e.g. WT and KO) separately from each other (step-by-step).
As result, two or more different nanopreprocess output are folders
formed.
Afterwards, I place these two or more nanopreprocess output
folders into the common folder, which is intended for the input to
Nanomod.
I edit comparison.tsv respectively to the names of nanopreprocess
output folders, which correspond to the experimental or control
sample.
I run Nanomod

Please let me know is it correct?
Best regards,
Stan
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/biocorecrg/master_of_pores/issues/88#issuecomment-729145016,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADZ5FPLC5IHNXCMZNJT5KCDSQLD5BANCNFSM4TY6NTYA
.

Dear @lucacozzuto , everything worked perfectly. Thank you so much for your advice.


API Data

Look into moving the War creation from the API to the Controller. Not sure if this is a good idea or not, but it would save a process of changing code in two places every time a change is made to the schema

Not sure what this is addressing, but it sounds like I have addressed this at least in part already.


Running into an issue with OpenBraceToken child on valid wsdl

Thank you for putting this project together! Really helpful :)
I'm trying to generate a ts-client for a valid wsdl and running into an error A child of the kind OpenBraceToken was expected
I've attached the wsdl file here, curious if I am missing something or what the bug might be. I'm pretty sure ts-morph is throwing the error but unsure if the error is how it is being called or something else.
Human_Resources.wsdl.zip

Same here
I dont think it's my wsdl either

I found what the issue is with
in src/generator.ts on line 322
createClientDeclaration.setBodyText("return soapCreateClientAsync(args[0], args[1], args[2]) as any;");
the generator errors out here. I am very curios as to why

So after digging in a little bit deeper, The file. name of my WSDL started with a number (1) . This caused all kinds of problems with the generator.
I am still not sure why it caused a problem with the setBodyText method above but it did
Further down in the index generator it caused another issue there
Once I removed the number from the file name the generator created all the definitions and the client as well as the index file.
Unfortunately after I generated the index I started to notice another issue.
12 imported file names where wrong
Either the case was wrong in the interface or the file path was wrong

I had one duplicate on FareRouteGrp
file ./definitionsOffpointDetails1 did not exist but ./definitions/OffPointDetails1 did
and the definition from that file was imported 3 separate times I guess ill open another ticket


Implement API to close sqlite db connection

This PR closes https://github.com/Azure/azure-mobile-apps-js-client/issues/128
init opens a connection to the sqlite db and close closes the connection. defineTable implicitly calls init().
Also, execution of all store operations is now serialized
More details in description of individual commits

@danderson00

Hi @shrishrirang, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla.azure.com.

TTYL, AZPRBOT;

@danderson00 - I think you missed this one

I did, sorry. Reviewing now. It's a big PR, looks like the query serialization is a big part.

Looks good! Dang conflicts.


Is this repo dead?

If yes, why and anybody knows good forks of it?

It seems like. Are you interested in a new fork. I would contribute.


How to run script against DataCenter rather than VC

We have a very large VC and some DCs are global. The script starts erroring out around the end of the script because it takes so long.  Would like to run it against a smaller DC than the whole VC.  Or is there a way to exclude certain DCs.  Either way, what is the best route.  Thanks!

See #404, just down the list of open issues.

Yeah but hat do you edit?
Sent from my iPhone

On Nov 18, 2015, at 3:26 PM, Sneddo<EMAIL_ADDRESS>wrote:
See #404, just down the list of open issues.
—
Reply to this email directly or view it on GitHub.

There isn't any really great way to do this at the moment, you just have to filter each of the Get-* cmdlets using the location parameter or Where-Object.


Automated cherry pick of #3005: fix: tenant filter fail to work

Cherry pick of #3005 on release/2.12.
#3005: fix: tenant filter fail to work

/approve
/lgtm

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/2.12@37a589a). Click here to learn what that means.
The diff coverage is n/a.

@@              Coverage Diff               @@
##             release/2.12   #3008   +/-   ##
==============================================
  Coverage                ?   7.17%
==============================================
  Files                   ?     478
  Lines                   ?   76674
  Branches                ?       0
==============================================
  Hits                    ?    5504
  Misses                  ?   70707
  Partials                ?     463

Flag
Coverage Δ

#aFlag
7.17% <ø> (?)

Impacted Files
Coverage Δ

pkg/cloudcommon/db/fetch.go
0% <ø> (ø)

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 37a589a...d8f62b1. Read the comment docs.


Intermittent failure of iree/task/queue_test on arm64

Seeing this intermittently on arm64 linux runners.
The following tests FAILED:
97 - iree/task/queue_test (Failed)
[ RUN      ] QueueTest.TryStealAll
/work/runtime/src/iree/task/queue_test.cc:310: Failure
Expected equality of these values:
  &task_c
    Which is: 0xffffc6ae6260
  iree_task_queue_try_steal(&source_queue, &target_queue, 1000)
    Which is: NULL

/work/runtime/src/iree/task/queue_test.cc:311: Failure
Expected equality of these values:
  &task_d
    Which is: 0xffffc6ae6[220](https://github.com/openxla/iree/actions/runs/6802769949/job/18496627564?pr=15470#step:6:221)
  iree_task_queue_pop_front(&target_queue)
    Which is: NULL

/work/runtime/src/iree/task/queue_test.cc:316: Failure
Value of: iree_task_queue_is_empty(&source_queue)
  Actual: false
Expected: true

Looks like some memory model, atomic, mumble-mumble thing.

cc @freddan80
Some discussion about this on Discord
From @bjacob :

Basically I am going to find how to trigger that arm64 CI job, and then I'll do it on a pr that causes it to run build_and_test_tsan.sh instead of the normal test script.
If anyone knows, please share here how to trigger that CI job .

https://iree.dev/developers/general/contributing/#ci-behavior-manipulation
ci-exactly: build_test_all_arm64 should do that

weird - task_queue is just using a mutex IIRC

Trying at https://github.com/openxla/iree/pull/15491

Results are in in #15491.  All runtime tests pass with TSan. All tests under iree/task were rerun 32 times - no failure.

A a side note: I have run tests with TSan locally on macOS/arm64 and there, we have a bunch of TSan reports of data races in these tests. But it's a different OS and we have in places different code paths for macOS vs Linux (e.g. on futex usage), so that finding could be just false positives or could be about things not relevant to the present Issue.

Definitely macOS specific so not what we're observing here, but here's a fix: https://github.com/openxla/iree/pull/15499

Also trying ASan at https://github.com/openxla/iree/pull/15501

100% runtime tests pass also with ASan...
Summary: at this point, the intermittent here is not reproducing with either ASan or TSan (and the latter with 32 reruns) on the same arm64 CI hosts.  I'm going to leave it there, having reached the end of my basic playbook... if we really care, we're going to have to reproduce that locally, e.g. by installing a linux partition on a mac, or getting shell access into the CI host...

Still no repro with TSan at 100 repetitions (requested 256 but apparently CTest caps at 100).

@bjacob thx for the quick analysis.
I haven't observed this issue yet on our machines (AWS - Graviton 2/3), but I'll try to run it a bunch of times and see if I can see it...
@stellaraccident how often does it occur, roughly? Is there a way for me to access those stats without having to manually clicking my way through the CI workflow runs?

I managed to reproduce this. It usually happens after a few thousand runs. Command:
IREE_CTEST_TESTS_REGEX=queue IREE_CTEST_REPEAT_UNTIL_FAIL_COUNT=100000 ./build_tools/cmake/ctest_all.sh ./iree-build-all/
on bc98b9a04b. And I'm on a 64 core Graviton 2. I haven't got to debugging it yet, but I think I'll have some time for that tomorrow.

Awesome!
Sanitizers might help here - you can see what I did in https://github.com/openxla/iree/pull/15491 (for TSan) and https://github.com/openxla/iree/pull/15501 (for ASan).  Since this is in the runtime and does not depend on the compiler, you can configure like I do there - for example for TSan, these are my CMake flags: https://github.com/openxla/iree/blob/a1448a33f029b8dc8d1755142ba5c4ad2b2dd58a/build_tools/cmake/build_and_test_tsan.sh#L25-L58
Specifically:
cmake \
  -DCMAKE_BUILD_TYPE=RelWithDebInfo \
  -DIREE_ENABLE_ASSERTIONS=ON \
  -DIREE_BUILD_COMPILER=OFF \
  -DIREE_ENABLE_LLD=ON \
  -DIREE_ENABLE_TSAN=ON \

Also note re
IREE_CTEST_TESTS_REGEX=queue IREE_CTEST_REPEAT_UNTIL_FAIL_COUNT=100000

I sometimes find that when trying to reproduce a TSan failure on a specific test with many repetitions, it pays to filter in more tests than just the one I care about, to introduce more non-determinism in the scheduling of threads. It is a problem with CTest that if you filter a single test and set many repetitions, they will run sequentially instead of in parallel -- the parallelization dimension is only "across filtered tests" and not "across repetitions". So my usual workarounds have been either (1) filter in more tests, e.g. filter iree/task not just queue, or (2) write my own testing script launching many parallel processes (in that case, since the goal is to create some scheduling chaos, it's not a bad idea to schedule more threads than the system's hardware concurrency).

:+1: I'll give this a try. I'm not familiar with the tool yet but I'll read up on it

TL;DR - Seems to be related to building in the docker container. I can't reproduce the issues natively, by building on my Gravition 2 Ubuntu 22.04, only by building in the docker container. I'm a bit confused...
Some observations. I can run 100k iterations on the Graviton 2 native (Ubuntu 22.04). The issue happens when I run it in the container based on:
gcr.io/iree-oss/base-arm
64@sha256:942d01a396f81bff06c5ef4643ba3c9f4500a09010cd30d9ed9be691ddaf1353

Trying to build with tsan in the docker container doesn't work for me, which is weird since I use the same docker image and your patch (building with tsan natively works strangely). When I try to build with tsan in the docker container, I get cmake complaints:
-- Performing Test HAVE_POSIX_REGEX -- compiled but failed to run
CMake Error at third_party/benchmark/CMakeLists.txt:316 (message):
  Failed to determine the source files for the regular expression backend

I get around that but adding the cmake args:
  "-DHAVE_STD_REGEX=ON"
  "-DRUN_HAVE_STD_REGEX=1"

But then I get a bunch of errors like this:
FATAL: ThreadSanitizer CHECK failed: /build/llvm-toolchain-9-sL57p3/llvm-toolchain-9-9.0.1/compiler-rt/lib/tsan/rtl/tsan_platform_linux.cc:297 "((personality(old_personality | ADDR_NO_RANDOMIZE))) != ((-1))" (0xffffffffffffffff, 0xffffffffffffffff)
    #0 __tsan::TsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) <null> (generate_embed_data+0x2c3f48)
    #1 __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) <null> (generate_embed_data+0x2d9d30)
    #2 __tsan::InitializePlatform() <null> (generate_embed_data+0x2cb15c)
    #3 __tsan::Initialize(__tsan::ThreadState*) <null> (generate_embed_data+0x2b4c70)
    #4 <null> <null> (ld-linux-aarch64.so.1+0xea38)
    #5 <null> <null> (ld-linux-aarch64.so.1+0x1180)

I'm probably missing something here...
Anyways, it made me think that it has something to do with the LLVM version (container uses v9 by default). So I built using clang-14 instead of clang-9, but the issues is still there.
The only way for me to reproduce the issue natively is by building in the docker container and running ctest on the that build natively.

This is getting interesting! I googled the failed CHECK condition in your error log, and found this: https://github.com/golang/go/issues/35547#issuecomment-571709915 . It gives a plausible reason why this would only happen in a container and only on arm64, and provides a possible work-around. Can you try that?

Works! So now I can build using the thread sanitizer inside the docker container. Let's see if it catches the issue. Feels like I should have been caught it by now, but still running ... (10x slower with tsan?)
I have to go pick up kids now though. I'll check in later

For reference, the workaround (interactive):
docker run --rm -it --mount="type=bind,src=./,dst=/iree" --security-opt seccomp=unconfined gcr.io/iree-oss/base-arm64@sha256:942d01a396f81bff06c5ef4643ba3c9f4500a09010cd30d9ed9be691ddaf1353

Fantastic! Yes, 10x slower sounds plausible for TSan (it varies depending on the workload).

Unfortunately, I don't see the issue - it's still running :shrug:
Two things I can think of doing next 1) look at the disassembly of the working / non-working queue test 2) rule out that the Ubuntu version has nothing to do with it. Will continue on Monday.

Fredrik sent me the test where iree was built inside docker Vs the one where iree was built on the host and I noticed when comparing them that the host version uses outline atomics whereas the one in docker doesn't. I would still expect it to work but since it's related to atomics and this failure is intermittent it seemed potentially significant.
While at it I was looking at the iree_task_queue_try_steal() function used in the tryStealAll test and noticed that no list splitting happens if the caller already hold the mutex. Is that expected? Finally, I've noticed that the stolen_tasks list is initialized both in iree_task_queue_try_steal and in iree_task_list_split. Perhaps the later should be guaranteed by the API and then the former can be removed?
Hopefully I'll make more progress tomorrow.

Humm out-of-line atomics... I wonder what would happen if we linked together armv8.0 code (using LDXR/STXR loops) and armv8.1 code (using LDADD etc single-instruction atomics). Are these 100% compatible or is that a potential cause of data races?

iree_task_queue_try_steal could be reworked to early exit if the try fails, but I wouldn't change the API requirements of split (as that's used elsewhere) - I believe iree_task_queue_try_steal did more in the past when the lock would fail (try stealing in a variety of ways, one of which was via the lock). I don't know if I'd do any of that before figuring out the issue, though, as we have a reproducer of something that should work but isn't and we don't want to lose that.

Humm out-of-line atomics... I wonder what would happen if we linked together armv8.0 code (using LDXR/STXR loops) and armv8.1 code (using LDADD etc single-instruction atomics). Are these 100% compatible or is that a potential cause of data races?

That's where my mind was at but wouldn't that require different part of IREE runtime using different atomic instructions? I'm gonna keep digging.

iree_task_queue_try_steal could be reworked to early exit if the try fails, but I wouldn't change the API requirements of split (as that's used elsewhere) - I believe iree_task_queue_try_steal did more in the past when the lock would fail (try stealing in a variety of ways, one of which was via the lock). I don't know if I'd do any of that before figuring out the issue, though, as we have a reproducer of something that should work but isn't and we don't want to lose that.

I wasn't suggesting a change to solve this problem, just flagging a potential improvement for later on. Also regarding the double initialization I was suggesting for it to be documented as part of split, thus removing the need for the initialization in the caller.

No worries!
In C it's always best to not rely on documentation for things like default initialization - that iree_task_list_split memset(0)'s the list does not mean we want to also not memset(0) it in the callers - compilers are better at eliding redundant memset(0)s than humans are at reading documentation and knowing when they need to do it themselves or not :)

I can reproduce the failure with the test built by @freddan80 in docker by running just queue_test in a loop. From what I could find online googletest does not execute tests in parallel so that suggests more of an uninitialized bug or use after free. However running the tool under valgrind's memcheck with --leak-check=full didn't show anything, even for runs where the test failed.

Short update. I managed to reproduce the issue by building the runtime outside the docker (on ubuntu 22.04). By using clang 12.0.1 coincidentally... Hence, this:

TL;DR - Seems to be related to building in the docker container. I can't reproduce the issues natively, by building on my Gravition 2 Ubuntu 22.04, only by building in the docker container. I'm a bit confused...

is debunked. It makes me believe the issue is generic and just happen appear randomly depending on who-knows-what.  I've ran a few marathon asan and tsan tests with various permutations, but it never triggers the issue. I'll give this some more attention later today.

Great! Focus on TSan. Run the test in a script that runs it in parallel in many threads, not relying on crest to parallelize, due to the above reason. Set a really large number of threads to make scheduling chaotic.

Also maybe edit the test to make it loop more iterations.

Me and @RoboTux had a joint look at this today. It seem the lock fails, which eventually is cause by this:
https://github.com/openxla/iree/blame/f031ce8ea3050c9a87afde41df253472b362c241/runtime/src/iree/base/internal/synchronization.c#L456-L473
which in extension calls this:
https://github.com/openxla/iree/blob/1012586173e74509841f004e46ec5cfa3925285b/runtime/src/iree/base/internal/atomics_clang.h#L62
which return false. By printign, we can see the mutex is not taken. IIUC __c11_atomic_compare_exchange_weak is allowed to fail spuriously (ref). Now, if I replace that call with __c11_atomic_compare_exchange_strong, the test pass 100% of the time.
The asm of __c11_atomic_compare_exchange_weak could look something like this depending on compiler, version etc.:
0000000000242250 <iree_slim_mutex_try_lock>:
  242250:       885ffc08        ldaxr   w8, [x0]
  242254:       34000068        cbz     w8, 242260 <iree_slim_mutex_try_lock+0x10>
  242258:       d5033f5f        clrex
  24225c:       14000004        b       24226c <iree_slim_mutex_try_lock+0x1c>
  242260:       320107e8        mov     w8, #0x80000001                 // #-2147483647
  242264:       88097c08        stxr    w9, w8, [x0]
  242268:       34000069        cbz     w9, 242274 <iree_slim_mutex_try_lock+0x24>
  24226c:       2a1f03e0        mov     w0, wzr
  242270:       d65f03c0        ret
  242274:       52800020        mov     w0, #0x1                        // #1
  242278:       d65f03c0        ret

Looking at the Arm64 docs, I read this:

The CLREX instruction clears the monitors, but unlike in ARMv7, exception entry or return also clears the monitor. The monitor might also be cleared spuriously, for example by cache evictions or other reasons not directly related to the application. Software must avoid having any explicit memory accesses, system control register updates, or cache maintenance instructions between paired LDXR and STXR instructions.

exception entry, cache eviction ... etc. I read it as things can go wrong if using  __c11_atomic_compare_exchange_weak without handling spurious fails. I guess the test need to handle this type of intermittent failures? Or if using __c11_atomic_compare_exchange_strong is preferred (performance penalty?).
Let me know what you think.
Cheers!

Wow, thanks for the debugging!
This has been a compare_exchange_weak ever since this file was first checked-in in 2020:
https://github.com/openxla/iree/blob/24afcead3511e144bf4b55654a4c5b6930b75669/iree/base/synchronization.c
I added the comments much later as an explanation of this code. I thought, then, that the compare_exchange_weak was correct here.

Wow, thanks for the debugging!
This has been a compare_exchange_weak ever since this file was first checked-in in 2020: https://github.com/openxla/iree/blob/24afcead3511e144bf4b55654a4c5b6930b75669/iree/base/synchronization.c
I added the comments much later as an explanation of this code. I thought, then, that the compare_exchange_weak was correct here.

It all depends on what's the intent behind iree_task_queue_try_steal and iree_slim_mutex_try_lock really. The weak locking is not guaranteed to lock even if the lock is free. It seems natural for iree_slim_mutex_try_lock to have the same semantic to me. I'm not sure about iree_task_queue_try_steal but https://github.com/openxla/iree/commit/91af04cb491b51dcf629761747331e17279701c5 seems to suggest that it was intentional to avoid too much contention. If that's the case, then perhaps queue_test.cc itself should be changed:

either to expect NULL or a task upon calling iree_task_queue_try_steal
or to loop around iree_task_queue_try_steal until it returns non NULL.

By the way, when outline atomics end up being used the sequence uses a single casa instruction if lse instructions are available which guarantees a free lock to be locked. FYI, whether outline atomics are used depends on:

the llvm version (must contains 4d7df43ffdb460dddb2877a886f75f45c3fee188)
platform (must be using compiler-rt or libgcc >= 9.3.1 if llvm was built after commit c5e7e649d537067dec7111f3de1430d0fc8a4d11)
target isa (if LSE is available, e.g. Armv8.1-A and later, it will use that instead of outline atomics)

Sorry about the delay, diving into his now...

platform (must be using compiler-rt or libgcc >= 9.3.1 if llvm was built after commit c5e7e649d537067dec7111f3de1430d0fc8a4d11)

We'd have to check but I think the old EL Linux we build deployment artifacts on may have its baseline libraries before this.

Now that I've come back up to speed on this, I think that @RoboTux hit the nail on the head with this:

It all depends on what's the intent behind iree_task_queue_try_steal and iree_slim_mutex_try_lock really. The weak locking is not guaranteed to lock even if the lock is free. It seems natural for iree_slim_mutex_try_lock to have the same semantic to me. I'm not sure about iree_task_queue_try_steal but 91af04c seems to suggest that it was intentional to avoid too much contention. If that's the case, then perhaps queue_test.cc itself should be changed:
* either to expect NULL or a task upon calling iree_task_queue_try_steal
* or to loop around iree_task_queue_try_steal until it returns non NULL.

Indeed, it is intentional that functions that have _try_ in their name can fail, for whatever reason --- trying to specify anything more than "for whatever reason" would be a losing game anyway.
"Whatever reason" may include any combination of thread contention, and implementation details of atomics. So for instance, the above-quoted Arm docs explaining various possible causes of spurious failures are just part of these "whatever reasons". They don't compromise the correctness of iree_slim_mutex_try_lock.
So like @RoboTux suggests, it really is just a buggy test here. Callers of _try_ functions can't require success. This test does just that: https://github.com/openxla/iree/blob/7963ca781b6f3782ad21d20ac24b7adca150e36f/runtime/src/iree/task/queue_test.cc#L309-L310  (this is just one of 6 occurences in this file).
Outside of this test, iree_task_queue_try_steal is called only in one location by iree_task_worker_try_steal_task:
https://github.com/openxla/iree/blob/7963ca781b6f3782ad21d20ac24b7adca150e36f/runtime/src/iree/task/worker.c#L156
In turn, iree_task_worker_try_steal_task is called only in one location by iree_task_executor_try_steal_task_from_affinity_set:
https://github.com/openxla/iree/blob/7963ca781b6f3782ad21d20ac24b7adca150e36f/runtime/src/iree/task/executor.c#L555
This call is inside a for loop for ""max_theft_attempts" iterations. So this caller is quite clearly OK with spurious failures.
So I think the resolution here is:

Treat this as a test bug, fix queue_test.cc.
Clarify in the doc comment that _try_ functions may fail spuriously. For example, the comment on iree_task_worker_try_steal_task could use clearer wording --- it currently says // Returns NULL if no tasks are available and otherwise up to |max_tasks| tasks, that maybe doesn't make it clear that it could also return NULL spuriously even if tasks are available.

@benvanik WDYT?  The alternative is to try to specify _try_ functions as never failing spuriously, switching then to compare_exchange_strong internally, allowing the existing test to pass as-is as noted by @RoboTux @freddan80 . However, since the only non-test caller of iree_task_queue_try_steal seems to be happy with spurious failures, it seems unnecessary to force it to pay the higher cost of non-spuriously-failing compare_exchange_strong.

Note - there is another reason besides performance optimization to avoid compare_exchange_strong if we can. On some targets, compare_exchange_strong has to compile to a loop retrying compare_exchange_weak. These hidden loops mean potentially unbounded number of iterations in contended cases, and in turn causing potentially unbounded contention.  By contrast, compare_exchange_weak is an easier-to-think-about bounded primitive.

Even if there is not a code bug here, I am really grateful for the analysis: these kind of sync/atomic things are as good as the eyes that have been put on them. Thank you.

I wonder if it is reasonable to run the test code in a loop with some high number of max checks. Iiuc, the condition should be eventually meet but the platform is free to be non deterministic about it.

so weird!
try functions should be allowed to fail - our iree_slim_mutex_try_lock is just pthread_mutex_trylock/std::mutex::try_lock/etc and should have the same behavior. the queue try_steal is the same (as it's based on those). so sounds like a comment improvement and fixing the test is the way to go - I think the test was assuming it couldn't fail in these cases as it really shouldn't be possible, but apparently it is here and that's unfortunate on arm.
we don't want to lose test coverage because of this quirk, so like stella says maybe just loop a bunch? should be fast (compared to our other tests that compile/run entire models).

(really great investigation all - I learned a bunch!)

Yes, let's make the test loop. If the impl was switched to compare_exchange_strong, that would amount to bringing that loop inside the impl.  Instead we're just adding the loop to the test. I think we can just let them loop indefinitely, just like compare_exchange_strong would. Worst case, there are test timeouts --- but that would only happen if there's a bug. Contention and implementation details would only result in a small number of loop iterations.

@RoboTux @freddan80 https://github.com/openxla/iree/pull/15636 is out; it's something we probably want to merge anyway since we have a pretty clear understand now that it's needed anyway, and merging it will make it even easier to retry. But it will be very interesting to hear a confirmation that it actually fixes the problem, and feel free to reopen then.

Yes, let's make the test loop. If the impl was switched to compare_exchange_strong, that would amount to bringing that loop inside the impl. Instead we're just adding the loop to the test. I think we can just let them loop indefinitely, just like compare_exchange_strong would. Worst case, there are test timeouts --- but that would only happen if there's a bug. Contention and implementation details would only result in a small number of loop iterations.

That's what I would have done myself: loop and relying CTest timeout for the worst case where for some weird reason the lock can never be acquired in a reasonable time. I'd argue if no timeout happens for months and we suddenly start having some it indicates the machine might have suddenly got very busy or something worth investigating.

@bjacob @benvanik Fix seem to work :+1: Nice team effort getting this fixed. I learned a lot debugging this issue!


getPixmap not working with shapeLayer

After the upgrade to 2015.5 I'm not able to get generator.getPixmap() to work with this shapeLayer.

Here is the error message when using the generator-assets with the built in generator:
[debug:generator-assets 00:47:05.757 assetmanager.js:560:22] handleChange: { layers: { '70': { layer: [Object], index: 242, changes: [Object] } },
  id: 195,
  timeStamp:<PHONE_NUMBER>.754,
  count: 7 }
[info:generator-assets 00:47:06.070 rendermanager.js:157:30] RenderManager active
[info:generator-assets 00:47:06.071 rendermanager.js:178:26] Rendering: Button BG.png (0;1)
[error:generator-assets 00:47:06.267 assetmanager.js:449:34] Render failed: Button BG.png { [Error: Got a pixmap with zero bounds.] zeroBoundsError: true }
[info:generator-assets 00:47:06.267 rendermanager.js:190:38] RenderManager idle

Update: textLayers don't seem to work either, although it does work for a layerSelection.

Yes, unfortunately we shipped with this bug and are aware of it.  We have a fix ready to be released that will hopefully go out VERY soon!
https://helpx.adobe.com/photoshop/kb/generate-and-export-as-failure.html

https://jira.corp.adobe.com/browse/PS-3397

Is there a rough time line for this?

Yes, but nothing I can share publicly unfortunately.  Very soon...


Official Savage Worlds v1.00.25 Dark Mode Support

Updated Roll Templates to support Dark Mode as well as a few other minor tweaks to the Roll Templates.

Submission Checklist
Required

[x] The pull request title clearly contains the name of the sheet I am editing.
[x] The pull request title clearly states the type of change I am submitting (New Sheet/New Feature/Bugfix/etc.).
[x] The pull request makes changes to files in only one sub-folder.
[x] The pull request does not contain changes to any json files in the translations folder (translation.json is permitted)

New Sheet Details

The name of this game is: <   >  (i.e. Dungeons & Dragons 5th Edition, The Dresden Files RPG)

The publisher of this game is: <   > (i.e. Wizards of the Coast, Evil Hat)

The name of this game system/family is: <   > (i.e. Dungeons & Dragons, FATE)

[ ] I have followed the Character Sheets Standards when building this sheet.

[x] This sheet has been made on behalf of, or by, the game's publisher.
[ ] This game is not a traditionally published game, but a copy of the game rules can be purchased/downloaded/found at: <   >
[ ] This sheet is for an unofficial fan game, modification to an existing game, or a homebrew system.

Changes / Description

Character Sheet Info Roll20 Internal Use only.


Add lib name & version to Logger

Currently all log messages output the version of msal-common being used i.e.
[Wed, 11 Nov 2020 19:37:04 GMT] :  : 1.7.1 : Info - Emitting event: msal:handleRedirectStart
This PR adds lib name and version to Logger constructor so that log messages properly reflect where they are coming from i.e.
[Wed, 11 Nov 2020 19:50:54 GMT]<EMAIL_ADDRESS>: Info - Emitting event: msal:handleRedirectStart
[Wed, 11 Nov 2020 19:54:27 GMT]<EMAIL_ADDRESS>: Info - Navigate url is empty

Coverage decreased (-0.7%) to 81.244% when pulling 2a65416ec2b054abb9e4966ff8f22e1afa9dbb92 on logger-name-version into ffc0b36a6a085f9ac7f619cf0167dca011527bf9 on dev.


Implement a lightning-fast global strategy

Fix #1799
This is the best strategy I could think about, and it comes with no copies or redundant information.
Basically, the behavior of Camel K is now the following when running an integration with a global operator in another namespace:

If there's an integrationplatform in the local integration namespace, then Camel K behaves as today
If there's no integrationplatform in the local integration namespace, then the operator looks for an integrationplatform in the operator namespace (or it creates one when possible, i.e. OpenShift currently) and all the hard work (like checking kits and building images) is done in the global operator namespace

In the new context, when I run an integration, tipically I have:

Integration in the user namespace
IntegrationKit in the operator namespace
Build in the operator namespace
CamelCatalog in the operator namespace
IntegrationPlatform in the operator namespace

I.e. the disconnection happens at integration level, all other pieces remain local (in the operator namespace).
To locate the kit and all other platform resources, a new status -> platformNamespace has been added to the Integration and it represents where all supporting resources are located.
On OpenShift, the pull-secret trait also adds the system:image-puller role (thanks @astefanutti) to the integration service account, so no image transfer between namespaces: all (cluster-wide) integrations with the same set of dependencies will point to the same imagestream.
This allows to have, by default, a single builder with warmed up cache, that also builds images for the whole cluster, so images are shared and time to run the integrations is drastically reduced.
Missing parts:

[x] E2E tests
[x] Handle explicit references to local kits

Release Note
A cluster-wide global Camel K operator now has the same (or better) performance than local Camel K operators

How does this strategy handle the case where you programmatic create an IntegrationKit ?

Woot! For future references, next steps towards the perfect build system is #592, and possibly #1784.

How does this strategy handle the case where you programmatic create an IntegrationKit ?

Well, no problems if the integrationKit is co-located with the integration platform (i.e. it's in the operator namespace).
But probaly we should allow also local references... But at the same time we need not to complicate the model too much... thinking...

How does this strategy handle the case where you programmatic create an IntegrationKit ?

Well, no problems if the integrationKit is co-located with the integration platform (i.e. it's in the operator namespace).

Yep but normal user should not create stuffs in the operator namespace

But probaly we should allow also local references... But at the same time we need not to complicate the model too much... thinking...

Maybe instead of having
status:
    platformNamespace

Each linked resource should report the information about the namespace ?
status:
    kit:
      # optional, current if omitted
      namespace:
      name:

I guess it won't be too hard :D to have cascading lookup.

I've deprecated "kit" and added an "integrationKit" object reference property in both spec and status, and implemented the suggested behavior.
The only caveat is that a kit should always follow a platform (same namespace) in order to be built, with the exception of "external" kits that can also be created in the same namespace as the integration (e2e tests included).


Custom Input: how to detect if the input is being async-validated?

Is there a way in a custom form control to detect when the field is being asynchronously validated?
Tried executing fieldApi.validatingField(), but it always complains about the validatingField not being a function - though when I check in console it is actually shown as a function. Weird.
My idea is to use the main form's validate() method to return a Promise for some fields if that field needs server-side validation. And then custom field control would know it is still pending validation (showing a spinner icon).
How can that be achieved?
Thanks!

I think what your are looking for is formApi.validating see the docs here https://react-form.js.org/#/async-validation


Softlock in Sand Cape chest room

The room where you would normally acquire the Sand Cape can be entered with Flail/Merman Boots but you can only exit with the Sand Cape, which leads to a softlock, if you have bombs you can kill yourself, but if not, you'll have to completely reload.
I'm not really sure how you'd fix it without making the logic really boring (short of always making the chest useless), or allowing you to easily exit the room.

Or adding a way to save and quit or warp back to jesse's house like in zelda


[txn] Add check for prewrite ttl for pessimistic txn

Add check for prewrite TTL for pessimistic transactions like tikv
Refactor some test utilities, increase the raftstore coverage(11% -> 27%)

@coocood @bobotu  PTAL

LGTM


hostapd service, degrated systemd dependencies

Issue description
nixos-version: 16.03.714.69420c5 (Emu)
in nixos/modules/services/networking/hostapd.nix we have this code:
  systemd.services.hostapd =
      { description = "hostapd wireless AP";

        path = [ pkgs.hostapd ];
        wantedBy = [ "network.target" ];

        after = [ "${cfg.interface}-cfg.service" "nat.service" "bind.service" "dhcpd.service"];

        serviceConfig =
          { ExecStart = "${pkgs.hostapd}/bin/hostapd ${configFile}";
            Restart = "always";
          };
      };

when using this with the configuration below:

  services.hostapd = {
    enable = true;
    wpaPassphrase = pw.wpaPassphrase;
    interface = "wlp4s0";
    ssid="flux";
  };

we will see this in the boot log:
boot log
[  OK  ] Started NTP Daemon.
[  OK  ] Started CPU Frequency Governor Setup.
[  OK  ] Started Kernel Auditing.
[  OK  ] Found device I210 Gigabit Network Connection.
[  OK  ] Started Name Service Cache Daemon.
[  OK  ] Started SSH Daemon.
[  OK  ] Reached target User and Group Name Lookups.
         Starting Permit User Sessions...
         Starting Login Service...
[  OK  ] Reached target Host and Network Name Lookups.
[  OK  ] Reached target Local File Systems.
         Starting Create Volatile Files and Directories...
[  OK  ] Started Permit User Sessions.
[  OK  ] Started Create Volatile Files and Directories.
[  OK  ] Stopped hostapd wireless AP.
[  OK  ] Started hostapd wireless AP.
[  OK  ] Started D-Bus System Message Bus.
[  OK  ] Started Serial Getty on ttyS0.
[  OK  ] Started Getty on tty1.
[  OK  ] Reached target Login Prompts.
[  OK  ] Started Login Service.
[  OK  ] Started Firewall.
[  OK  ] Stopped hostapd wireless AP.
[  OK  ] Started hostapd wireless AP.
[  OK  ] Reached target Network (Pre).
[  OK  ] Stopped hostapd wireless AP.
[  OK  ] Started hostapd wireless AP.
[  OK  ] Found device QCA986x/988x 802.11ac Wireless Network Adapter.
         Starting Bridge Interface br0...
[  OK  ] Stopped hostapd wireless AP.
[  OK  ] Started hostapd wireless AP.
[FAILED] Failed to start Bridge Interface br0.
See 'systemctl status br0-netdev.service' for details.
[  OK  ] Stopped hostapd wireless AP.
[FAILED] Failed to start hostapd wireless AP.
See 'systemctl status hostapd.service' for details.
[  OK  ] Reached target All Network Interfaces.
         Starting Networking Setup...
         Starting DHCP Client...
[  OK  ] Started Networking Setup.
         Starting Extra networking commands....
[  OK  ] Started Extra networking commands..
[  OK  ] Started DHCP Client.
[  OK  ] Reached target Network.
[  OK  ] Reached target Multi-User System.

fix
@clever suggested to use:
systemd.services.hostapd.after = [ "sys-subsystem-net-devices-wlp4s0.device" "nat.service" "bind.service" "dhcpd.service" ]; in the configuration.nix
this makes it work! we have to replace:
"${cfg.interface}-cfg.service"
by
sys-subsystem-net-devices-${cfg.interface}.device
note: there is no ${cfg.interface}-cfg.service on my system by looking at systemctl's output. instead i see sys-subsystem-net-devices-${cfg.interface}.device which should be the dependency we want instead. guess: this was probably renamed at some point or something.
shall i crate a PR for this fix?
@edolstra

the cfg is an alias,   cfg = config.services.hostapd;

Looking at your log there is something wrong with the service in my opinion. It seems as if hostapd is started and stopped at least 4 times.
I don't think wantedBy = network.target is correct. Most certainly wantedBy = multi-user.target and after = network.target is more accurate. I believe this should be enough so the sys-subsystem.. ordering can be removed completely.
Can you please check if this works and gets rid of the multiple start/stop messages?

@groxxda
the line below won't work:
systemd.services.hostapd.after = [ "network.target" ];

i even tried:
systemd.services.hostapd.after = [ "sys-subsystem-net-devices-wlp4s0.device" "network.target" ];

what you proposed
using this config:
  systemd.services.hostapd.after = [ "network.target" ];
  systemd.services.hostapd.wantedBy= [ "multi-user.target" ];

it fails with;
[  OK  ] Started Journal Service.
         Starting Flush Journal to Persistent Storage...
[  OK  ] Started Flush Journal to Persistent Storage.
[  OK  ] Started Load Kernel Modules.
[  OK  ] Found device /dev/ttyS0.
         Starting Apply Kernel Variables...
[  OK  ] Started Apply Kernel Variables.
[  OK  ] Found device KINGSTON_SMS200S360G 1.
         Mounting /boot...
[  OK  ] Reached target System Initialization.
[  OK  ] Listening on Nix Daemon Socket.
[  OK  ] Listening on D-Bus System Message Bus Socket.
[  OK  ] Reached target Sockets.
[  OK  ] Reached target Basic System.
         Starting SSH Daemon...
         Starting NTP Daemon...
         Starting Cron Daemon...
         Starting Name Service Cache Daemon...
         Starting CPU Frequency Governor Setup...
         Starting Store Sound Card State...
         Starting Kernel Auditing...
[  OK  ] Started Kernel Log Daemon.
[  OK  ] Started Daily Cleanup of Temporary Directories.
[  OK  ] Reached target Timers.
         Starting Firewall...
[  OK  ] Mounted /boot.
[  OK  ] Started Cron Daemon.
[  OK  ] Started CPU Frequency Governor Setup.
[  OK  ] Started Store Sound Card State.
[  OK  ] Started NTP Daemon.
[  OK  ] Started Kernel Auditing.
[  OK  ] Started SSH Daemon.
[  OK  ] Started Name Service Cache Daemon.
[  OK  ] Found device I210 Gigabit Network Connection.
[  OK  ] Reached target User and Group Name Lookups.
         Starting Login Service...
         Starting Permit User Sessions...
[  OK  ] Reached target Host and Network Name Lookups.
[  OK  ] Reached target Local File Systems.
         Starting Create Volatile Files and Directories...
[  OK  ] Started Permit User Sessions.
[  OK  ] Started Create Volatile Files and Directories.
[  OK  ] Started D-Bus System Message Bus.
[  OK  ] Started Serial Getty on ttyS0.
[  OK  ] Started Getty on tty1.
[  OK  ] Reached target Login Prompts.
[  OK  ] Started Login Service.
[  OK  ] Started Firewall.
[  OK  ] Reached target Network (Pre).
[  OK  ] Found device QCA986x/988x 802.11ac Wireless Network Adapter.
         Starting Bridge Interface br0...
[FAILED] Failed to start Bridge Interface br0.
See 'systemctl status br0-netdev.service' for details.
[  OK  ] Reached target All Network Interfaces.
         Starting DHCP Client...
         Starting Networking Setup...
[  OK  ] Started Networking Setup.
         Starting Extra networking commands....
[  OK  ] Started Extra networking commands..
[  OK  ] Started DHCP Client.
[  OK  ] Reached target Network.
[  OK  ] Started hostapd wireless AP.
[  OK  ] Reached target Multi-User System.

what i proposed
systemd.services.hostapd.after = [ "sys-subsystem-net-devices-wlp4s0.device" "nat.service" "bind.service" "dhcpd.service" ];

results in
         Starting Update UTMP about System Boot/Shutdown...
         Starting Load/Save Random Seed...
[  OK  ] Started Create Static Device Nodes in /dev.
[  OK  ] Started Load/Save Random Seed.
[  OK  ] Started Update UTMP about System Boot/Shutdown.
[  OK  ] Started udev Coldplug all Devices.
[  OK  ] Reached target Local File Systems (Pre).
         Starting udev Kernel Device Manager...
[  OK  ] Started Setup Virtual Console.
[  OK  ] Started udev Kernel Device Manager.
[  OK  ] Started Journal Service.
         Starting Flush Journal to Persistent Storage...
[  OK  ] Started Flush Journal to Persistent Storage.
[  OK  ] Started Load Kernel Modules.
[  OK  ] Found device /dev/ttyS0.
[  OK  ] Found device KINGSTON_SMS200S360G 1.
         Mounting /boot...
         Starting Apply Kernel Variables...
[  OK  ] Started Apply Kernel Variables.
[  OK  ] Mounted /boot.
[  OK  ] Reached target Local File Systems.
         Starting Create Volatile Files and Directories...
[  OK  ] Reached target System Initialization.
[  OK  ] Started Daily Cleanup of Temporary Directories.
[  OK  ] Reached target Timers.
[  OK  ] Listening on D-Bus System Message Bus Socket.
[  OK  ] Listening on Nix Daemon Socket.
[  OK  ] Reached target Sockets.
[  OK  ] Reached target Basic System.
         Starting CPU Frequency Governor Setup...
         Starting SSH Daemon...
         Starting NTP Daemon...
         Starting Store Sound Card State...
         Starting Kernel Auditing...
         Starting Name Service Cache Daemon...
[  OK  ] Started Kernel Log Daemon.
         Starting Cron Daemon...
         Starting Firewall...
[  OK  ] Started Create Volatile Files and Directories.
[  OK  ] Started CPU Frequency Governor Setup.
[  OK  ] Started Store Sound Card State.
[  OK  ] Started Kernel Auditing.
[  OK  ] Started Cron Daemon.
[  OK  ] Started NTP Daemon.
[  OK  ] Found device I210 Gigabit Network Connection.
[  OK  ] Started SSH Daemon.
[  OK  ] Started Name Service Cache Daemon.
[  OK  ] Reached target Host and Network Name Lookups.
[  OK  ] Reached target User and Group Name Lookups.
         Starting Permit User Sessions...
         Starting Login Service...
[  OK  ] Started Permit User Sessions.
[  OK  ] Started Getty on tty1.
[  OK  ] Started Serial Getty on ttyS0.
[  OK  ] Reached target Login Prompts.
[  OK  ] Started D-Bus System Message Bus.
[  OK  ] Started Login Service.
[  OK  ] Started Firewall.
[  OK  ] Reached target Network (Pre).
[  OK  ] Found device QCA986x/988x 802.11ac Wireless Network Adapter.
[  OK  ] Started hostapd wireless AP.
         Starting Bridge Interface br0...
[  OK  ] Started Bridge Interface br0.
[  OK  ] Reached target All Network Interfaces.
         Starting DHCP Client...
         Starting Networking Setup...
[  OK  ] Started Networking Setup.
         Starting Extra networking commands....
[  OK  ] Started Extra networking commands..

works pretty well.
combination
this seems to work also:
systemd.services.hostapd.wantedBy= [ "multi-user.target" ];
systemd.services.hostapd.after = [ "sys-subsystem-net-devices-wlp4s0.device" "nat.service" "bind.service" "dhcpd.service" ];

so what should we do?

My guess is that the problem is not directly related to hostapd but rather by the bridge br0.
Would you mind posting how you setup br0 and the output of systemctl status br0-netdev.service after the failure?
I'm not sure why hostapd has to be started before br0 and more importantly why the ordering with sys-subsystem-net-devices-wlp4s0.device works. This looks random to me :confused:

@groxxda
br0 setup
 networking = {
    hostName = "apu-nixi"; # Define your hostname.
    bridges.br0.interfaces = [ "enp1s0" "wlp4s0" ];
    firewall = {
      enable = true;
      allowPing = true;
      allowedTCPPorts = [ 22 ];
      #allowedUDPPorts = [ 5353 ];
    };

  };

@groxxda ideas?

@qknight
As you can see from your logs hostapd starts without errors in both cases and the problem is really with the bridge.
I'm not using scripted network interfaces myself, and have no detailed knowledge how they should work.
To investigate further it would be handy to see the outputs of

systemctl status br0-netdev.service or better journalctl -u br0-netdev.service
systemctl cat br0-netdev.service
systemctl list-dependencies --after br0-netdev.service (maybe in both cases: with your fixed hostapd.service and my simplified version)

and optionally

systemctl list-dependencies network.target

configuration.nix
  systemd.services.hostapd.wantedBy= [ "multi-user.target" ];
  systemd.services.hostapd.after = [ "sys-subsystem-net-devices-wlp4s0.device" "nat.service" "bind.service" "dhcpd.service" ];

  services.hostapd = {
    enable = true;
    wpaPassphrase = pw.wpaPassphrase;
    interface = "wlp4s0";
    ssid="flux";
  };

systemctl status br0-netdev.service
systemctl status br0-netdev.service                                                                       ~
● br0-netdev.service - Bridge Interface br0
   Loaded: loaded (/nix/store/qg3vglcr6pmq15hsjjrj6w6gvglh296j-unit-br0-netdev.service/br0-netdev.service; bad; vendor pres
   Active: active (exited) since Fri 2016-07-01 11:15:45 CEST; 2min 42s ago
  Process: 710 ExecStart=/nix/store/1n622x4m2q7gc0mijd0v5h50ky633q3d-unit-script/bin/br0-netdev-start (code=exited, status=
 Main PID: 710 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/br0-netdev.service

Jul 01 11:15:44 apu-nixi systemd[1]: Starting Bridge Interface br0...
Jul 01 11:15:44 apu-nixi br0-netdev-start[710]: Removing old bridge br0...
Jul 01 11:15:44 apu-nixi br0-netdev-start[710]: Adding bridge br0...
Jul 01 11:15:45 apu-nixi systemd[1]: Started Bridge Interface br0.

journalctl -u br0-netdev.service
-- Reboot --
Jul 01 11:15:44 apu-nixi systemd[1]: Starting Bridge Interface br0...
Jul 01 11:15:44 apu-nixi br0-netdev-start[710]: Removing old bridge br0...
Jul 01 11:15:44 apu-nixi br0-netdev-start[710]: Adding bridge br0...
Jul 01 11:15:45 apu-nixi systemd[1]: Started Bridge Interface br0.

systemctl cat br0-netdev.service
# /nix/store/qg3vglcr6pmq15hsjjrj6w6gvglh296j-unit-br0-netdev.service/br0-netdev.service
[Unit]
After=network-pre.target mstpd.service sys-subsystem-net-devices-enp1s0.device sys-subsystem-net-devices-wlp4s0.device netw
Before=network-interfaces.target sys-subsystem-net-devices-br0.device
BindsTo=sys-subsystem-net-devices-enp1s0.device sys-subsystem-net-devices-wlp4s0.device
Description=Bridge Interface br0

[Service]
Environment="LOCALE_ARCHIVE=/nix/store/0hjq5fy6ghbkzwdwszvy5k8hm31i5fcz-glibc-locales-2.23/lib/locale/locale-archive"
Environment="PATH=/nix/store/azal5a1w3l4kwrkwjrxva1mflw8cga27-iproute2-4.3.0/bin:/nix/store/lphk3qrh53kv2j69b3sry5jmhfbrz1n
Environment="TZDIR=/nix/store/majymj6knc0j74rrp7m6mlrrmr5h4wqa-tzdata-2015g/share/zoneinfo"

ExecStart=/nix/store/1n622x4m2q7gc0mijd0v5h50ky633q3d-unit-script/bin/br0-netdev-start
ExecStopPost=/nix/store/74g07gm4zdi3d2jak0q2xc863gpxjhg7-unit-script/bin/br0-netdev-post-stop
RemainAfterExit=true
Type=oneshot

systemctl list-dependencies --after br0-netdev.service (my fixed hostapd.service)
br0-netdev.service
x ├─mstpd.service
x ├─network-addresses-enp1s0.service
x ├─network-addresses-wlp4s0.service
x ├─network-link-enp1s0.service
x ├─network-link-wlp4s0.service
● ├─sys-subsystem-net-devices-enp1s0.device
● ├─sys-subsystem-net-devices-wlp4s0.device
● ├─system.slice
● ├─systemd-journald.socket
● ├─basic.target
● │ ├─-.mount
x │ ├─tmp.mount
● │ ├─paths.target
● │ │ ├─systemd-ask-password-console.path
● │ │ └─systemd-ask-password-wall.path
● │ ├─slices.target
● │ │ ├─-.slice
● │ │ ├─system.slice
● │ │ └─user.slice
● │ ├─sockets.target
● │ │ ├─dbus.socket
● │ │ ├─nix-daemon.socket
x │ │ ├─syslog.socket
● │ │ ├─systemd-initctl.socket
● │ │ ├─systemd-journald-audit.socket
● │ │ ├─systemd-journald-dev-log.socket
● │ │ ├─systemd-journald.socket
● │ │ ├─systemd-udevd-control.socket
● │ │ └─systemd-udevd-kernel.socket
● │ └─sysinit.target
● │   ├─dev-hugepages.mount
● │   ├─dev-mqueue.mount
x │   ├─emergency.service
● │   ├─kmod-static-nodes.service
x │   ├─sys-fs-fuse-connections.mount
x │   ├─sys-kernel-config.mount
● │   ├─sys-kernel-debug.mount
● │   ├─systemd-journald.service
● │   ├─systemd-modules-load.service
● │   ├─systemd-random-seed.service
● │   ├─systemd-sysctl.service
● │   ├─systemd-tmpfiles-setup-dev.service
x │   ├─systemd-udev-settle.service
● │   ├─systemd-udev-trigger.service
● │   ├─systemd-udevd.service
● │   ├─systemd-update-utmp.service
● │   ├─systemd-vconsole-setup.service
x │   └─emergency.target
x │     └─emergency.service
● ├─network-pre.target
● │ └─firewall.service
● └─sysinit.target
●   ├─dev-hugepages.mount
●   ├─dev-mqueue.mount
x   ├─emergency.service
●   ├─kmod-static-nodes.service
x   ├─sys-fs-fuse-connections.mount
x   ├─sys-kernel-config.mount
●   ├─sys-kernel-debug.mount
●   ├─systemd-journald.service
●   ├─systemd-modules-load.service
●   ├─systemd-random-seed.service
●   ├─systemd-sysctl.service
●   ├─systemd-tmpfiles-setup-dev.service
x   ├─systemd-udev-settle.service
●   ├─systemd-udev-trigger.service
●   ├─systemd-udevd.service
●   ├─systemd-update-utmp.service
●   ├─systemd-vconsole-setup.service
x   └─emergency.target
x     └─emergency.service

x marks a red dot

systemctl list-dependencies network.target
● ├─br0-netdev.service
● ├─dhcpcd.service
● ├─hostapd.service
● ├─network-local-commands.service
● ├─network-setup.service
● ├─network-interfaces.target
● └─network-pre.target
●   └─firewall.service

Well thanks for the outputs, but they are not really helpful to me because they don't show the error :disappointed:
From the default config:
# For nl80211, this parameter can be used to request the AP interface to be
# added to the bridge automatically (brctl may refuse to do this before hostapd
# has been started to change the interface mode). If needed, the bridge
# interface is also created.
#bridge=br0

Maybe this is enough to get everything working.

I have exactly same problem. A race condition between systemd bridge and hostapd bridge. Have you managed to solve the issue?

@luminoso
i have a workaround, see this thread for it. i'm still working on a proper fix and you are invited to help ;-)

@groxxda
now the output but without the following two lines:
systemd.services.hostapd.wantedBy= [ "multi-user.target" ];
systemd.services.hostapd.after = [ "sys-subsystem-net-devices-wlp4s0.device" "nat.service" "bind.service" "dhcpd.service" ];
configuration.nix
  services.hostapd = {
    enable = true;
    wpaPassphrase = pw.wpaPassphrase;
    interface = "wlp4s0";
    ssid="flux";
  };

systemctl status br0-netdev.service
systemctl status br0-netdev.service                                                                       ~
● br0-netdev.service - Bridge Interface br0
   Loaded: loaded (/nix/store/ac1i3ywzxm809sjvmqikvacbgf33zi5s-unit-br0-netdev.service/br0-netdev.service; bad; vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2016-08-03 16:47:44 CEST; 2min 0s ago
  Process: 891 ExecStart=/nix/store/w9qj52sl052fnm3g35hcp8k8khhkv99a-unit-script/bin/br0-netdev-start (code=exited, status=2)
 Main PID: 891 (code=exited, status=2)

Aug 03 16:47:43 apu-nixi systemd[1]: Starting Bridge Interface br0...
Aug 03 16:47:43 apu-nixi br0-netdev-start[891]: Removing old bridge br0...
Aug 03 16:47:43 apu-nixi br0-netdev-start[891]: Adding bridge br0...
Aug 03 16:47:44 apu-nixi br0-netdev-start[891]: RTNETLINK answers: Operation not supported
Aug 03 16:47:44 apu-nixi systemd[1]: br0-netdev.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Aug 03 16:47:44 apu-nixi systemd[1]: Failed to start Bridge Interface br0.
Aug 03 16:47:44 apu-nixi systemd[1]: br0-netdev.service: Unit entered failed state.
Aug 03 16:47:44 apu-nixi systemd[1]: br0-netdev.service: Failed with result 'exit-code'.

journalctl -u br0-netdev.service
-- Reboot --
Aug 03 16:47:43 apu-nixi systemd[1]: Starting Bridge Interface br0...
Aug 03 16:47:43 apu-nixi br0-netdev-start[891]: Removing old bridge br0...
Aug 03 16:47:43 apu-nixi br0-netdev-start[891]: Adding bridge br0...
Aug 03 16:47:44 apu-nixi br0-netdev-start[891]: RTNETLINK answers: Operation not supported
Aug 03 16:47:44 apu-nixi systemd[1]: br0-netdev.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Aug 03 16:47:44 apu-nixi systemd[1]: Failed to start Bridge Interface br0.
Aug 03 16:47:44 apu-nixi systemd[1]: br0-netdev.service: Unit entered failed state.
Aug 03 16:47:44 apu-nixi systemd[1]: br0-netdev.service: Failed with result 'exit-code'.

systemctl cat br0-netdev.service
# /nix/store/ac1i3ywzxm809sjvmqikvacbgf33zi5s-unit-br0-netdev.service/br0-netdev.service
[Unit]
After=network-pre.target mstpd.service sys-subsystem-net-devices-enp1s0.device sys-subsystem-net-devices-wlp4s0.device network-addresses-enp1s0.service network-link-enp1s0.service network-addresses-wlp4s0.se
Before=network-interfaces.target sys-subsystem-net-devices-br0.device
BindsTo=sys-subsystem-net-devices-enp1s0.device sys-subsystem-net-devices-wlp4s0.device
Description=Bridge Interface br0

[Service]
Environment="LOCALE_ARCHIVE=/nix/store/6c9w544nky66z8ax5rzh941cl6rv0j9c-glibc-locales-2.23/lib/locale/locale-archive"
Environment="PATH=/nix/store/vcd3l2xdfffsbkk5i234zbdq2552w832-iproute2-4.3.0/bin:/nix/store/w8vzn0lsahbd9sfh0v30x65qwq6xrpa8-coreutils-8.25/bin:/nix/store/l65knk24c08q0lwdcf0yyh7x6l5shhqj-findutils-4.4.2/bin
Environment="TZDIR=/nix/store/8qmj1pz36ky95r25c74w6dx48vck3i3b-tzdata-2016e/share/zoneinfo"

ExecStart=/nix/store/w9qj52sl052fnm3g35hcp8k8khhkv99a-unit-script/bin/br0-netdev-start
ExecStopPost=/nix/store/9v82lg0lhjqq7xaix6063bq3wdvv480f-unit-script/bin/br0-netdev-post-stop
RemainAfterExit=true
Type=oneshot

ExecStart=/nix/store/1n622x4m2q7gc0mijd0v5h50ky633q3d-unit-script/bin/br0-netdev-start
ExecStopPost=/nix/store/74g07gm4zdi3d2jak0q2xc863gpxjhg7-unit-script/bin/br0-netdev-post-stop
RemainAfterExit=true
Type=oneshot

systemctl list-dependencies --after br0-netdev.service (my fixed hostapd.service)
br0-netdev.service
x ├─mstpd.service
x ├─network-addresses-enp1s0.service
x ├─network-addresses-wlp4s0.service
x ├─network-link-enp1s0.service
x ├─network-link-wlp4s0.service
● ├─sys-subsystem-net-devices-enp1s0.device
● ├─sys-subsystem-net-devices-wlp4s0.device
● ├─system.slice
● ├─systemd-journald.socket
● ├─basic.target
● │ ├─-.mount
x │ ├─tmp.mount
● │ ├─paths.target
● │ │ ├─systemd-ask-password-console.path
● │ │ └─systemd-ask-password-wall.path
● │ ├─slices.target
● │ │ ├─-.slice
● │ │ ├─system.slice
● │ │ └─user.slice
● │ ├─sockets.target
● │ │ ├─dbus.socket
● │ │ ├─nix-daemon.socket
x │ │ ├─syslog.socket
● │ │ ├─systemd-initctl.socket
● │ │ ├─systemd-journald-audit.socket
● │ │ ├─systemd-journald-dev-log.socket
● │ │ ├─systemd-journald.socket
● │ │ ├─systemd-udevd-control.socket
● │ │ └─systemd-udevd-kernel.socket
● │ └─sysinit.target
● │   ├─dev-hugepages.mount
● │   ├─dev-mqueue.mount
x │   ├─emergency.service
● │   ├─kmod-static-nodes.service
x │   ├─sys-fs-fuse-connections.mount
x │   ├─sys-kernel-config.mount
● │   ├─sys-kernel-debug.mount
● │   ├─systemd-journald.service
● │   ├─systemd-modules-load.service
● │   ├─systemd-random-seed.service
● │   ├─systemd-sysctl.service
● │   ├─systemd-tmpfiles-setup-dev.service
x │   ├─systemd-udev-settle.service
● │   ├─systemd-udev-trigger.service
● │   ├─systemd-udevd.service
● │   ├─systemd-update-utmp.service
● │   ├─systemd-vconsole-setup.service
x │   └─emergency.target
x │     └─emergency.service
● ├─network-pre.target
● │ └─firewall.service
● └─sysinit.target
●   ├─dev-hugepages.mount
●   ├─dev-mqueue.mount
x   ├─emergency.service
●   ├─kmod-static-nodes.service
x   ├─sys-fs-fuse-connections.mount
x   ├─sys-kernel-config.mount
●   ├─sys-kernel-debug.mount
●   ├─systemd-journald.service
●   ├─systemd-modules-load.service
●   ├─systemd-random-seed.service
●   ├─systemd-sysctl.service
●   ├─systemd-tmpfiles-setup-dev.service
x   ├─systemd-udev-settle.service
●   ├─systemd-udev-trigger.service
●   ├─systemd-udevd.service
●   ├─systemd-update-utmp.service
●   ├─systemd-vconsole-setup.service
x   └─emergency.target
x     └─emergency.service

x is actually a red dot

systemctl list-dependencies network.target
x ├─br0-netdev.service
● ├─dhcpcd.service
x ├─hostapd.service
● ├─network-local-commands.service
● ├─network-setup.service
● ├─network-interfaces.target
● └─network-pre.target
●   └─firewall.service

x is actually a red dot

@groxxda
if i just add the code below it'll work:
systemd.services.hostapd.after = [ "sys-subsystem-net-devices-wlp4s0.device" ];

i think the device needs to be up in ordert to add it to a bridge.

@luminoso could you please check if that also fixes your issue?

@qknight I'm sorry for the delay replying.
I was confused when I posted here. I thought I was posting in another topic. I am actually using arch when I noticed that here at NixOS a related problem was being discussed. I shouldn't have posted here. However, the problem is the same, a race condition and I didn't found a way to fix it. I just used a timmer to avoid the race condition (the ugly way)

since nobody has a better idea, i close this as the fix:
systemd.services.hostapd.after = [ "sys-subsystem-net-devices-wlp4s0.device" ];
works for me!

Ah, I've been meaning to comment on this for a while but not gotten around to it.
I've been having trouble with a race condition related to this. I think hostapd was (sometimes) trying to come up before my wifi device was available at boot. A nixos-rebuild switch, depending on what needed restarting, would also (sometimes) fail for the same reason. Things would fail approaching half the time.
My data is limited to just me, but I applied this fix and haven't seen the problem since.
Shouldn't this change be more directly integrated into the hostapd package? It really looks like, logically, it should have been there all along. Or is there other logic which is supposed to regulate the ordering, that is just buggy for me?

@mrobbetts yes, i could fix this in nixpkgs but so far it seemd that i'm the only one affected.
the question is, should i?

I hope so! From my point of view, it looks as though this is a real bug in the module. IMO, bugs ought to be fixed if they are low risk, even if nobody you know of is suffering from them, because they may suffer later and in unpredictable ways. Others may not agree with that, I know.
While I know the hostapd module is not fully developed (currently, the overwhelming majority of my hostapd configuration is poured into extraConfig, because not many of the configuration keys seem to be supported by the module directly), the module does at least know what interface you're using it with, so the needed change for this would presumably be very small.
Of course, I'm assuming this is the real bug. I'm not familiar enough with systemd to know if there is another/better way of handling this, or if it should actually be working but there's a bug elsewhere. If this all sounds logical to you, I'd definitely advocate towards fixing it.

fixed in https://github.com/NixOS/nixpkgs/pull/26573

This issue is not fixed, and the race is still present in the master branch. I have submitted a PR though, and I would welcome testing.
The root cause of this is that if hostapd.service loses the race against br0-netdev.service the latter will call ip link wlp4s0 set master br0 which fails if hostapd hasn't put the device into AP mode yet. The failure bubbles up and the bridge setup all together fails.
The fix is moving hostapd between br0-netdev.service by hanging it below network-link-wlp4s0.service which br0-netdev.service depends on. This is mostly achieved by cleaning up the "after" clause and introducing a requiredBy clause. See PR for a PDF of the cleaned-up systemd dependency tree.

i've tried to reproduce my original problem using (18.03) 45f52f765cd but it doesn't hit the race at all. that said, i tested:

without any patch -> works
tested with my patch -> works
tested with your patch -> works

i'll do some more investitation but don't understand why it works now.

see https://github.com/NixOS/nixpkgs/pull/45464#issuecomment-425430594


Choose a charts library for the dashboard reports

Part of https://github.com/opencollective/opencollective/issues/3689
While designing for the dashboard reports project, the design team based its work on 3 libraries:

https://apexcharts.com
https://www.chartjs.org
https://visjs.org

Apex Charts is the one that is the most resembling what we have in Figma. We should however look at other metrics to pick the library that we think is best for our use case:

Is it maintained (code activity, release history)?
Is it popular/used by large actors?
Is it easily customizable?
Bundle size?
Developer experience / React integration?

So I've done some investigation;
Visjs
I don't think we should use Visjs as it doesn't seem actively maintained anymore; https://github.com/almende/vis/issues/4259#issue-412107497. They have moved the community version to a new org and thus there's two alternatives; vis-charts as a direct all-in-one replacement but that repo recommends not using it as the size is very big but rather recommends using the family of visjs components. I looked at some of those repos but they seem not to be very active in their maintenance. For example take vis-timeline that seems not to have any commits (other than renovate) for a while to the main branch. Another point is that the GitHub stars for this project isn't very high. Although this is a very subjective metric I think it does indicate some measurement of the popularity of a project.
Thus my thinking is we should not use Visjs.
Appex Charts
Well maintained library and reasonably popular it seems (based on GitHub starts and popular articles, I couldn't find the exact companies that use this). The bundle size including everything comes to around 450kb<EMAIL_ADDRESS>It has good react support and the react plugin is officially maintained. This uses SVG to draw the charts which I think is beneficial since this gives good accessibility support. My thinking is that this is quite good for our purposes.
Chart.js
Well maintained library and I believe it's being used more than Appex Charts particularly because its an older library (introduced in 2013 whereas Appex Charts is made in 2018). It doesn't have official react support, but does have some react wrappers such as https://github.com/reactchartjs/react-chartjs-2. However this is for the older version; I couldn't find a popular react wrapper for v3 of charts.js. One exists but I am doubtful about it's popularity and usage; https://github.com/mendesfelipe87/react-chartjs-3. The bundle size for the core library is smaller compare to Appex Charts (with around 183 kb), but note that we will have to use that along with some other plugins/components; such as the wrapper maybe and also components like chartjs-color for manipulating colors in charts and maybe the date-fns adaptor etc. So it might come to around 200 kb bundle size. Chart.js uses canvas elements to draw the charts. Thus there will be a lack in accessibility. This is also stated in the documentation; https://www.chartjs.org/docs/latest/general/accessibility.html

Chart.js charts are rendered on user provided canvas elements. Thus, it is up to the user to create the canvas element in a way that is accessible. The canvas element has support in all browsers and will render on screen but the canvas content will not be accessible to screen readers.

A useful comparison between Appex Charts and Chart.js is given at; https://apexcharts.com/javascript-charts-comparison/. A bit outdated though as for example moment.js isn't needed by Chart.js v3.

Summary
Overall, my thinking is, for our needs Appex Charts is the best fit. It gives a perfect balance between accessibility (due to usage of SVG), overall east of integration (due to official react support) etc. One downside maybe the customizability of Appex Charts which I think might not be great at the moment (I couldn't find in documentation much about customizablity; maybe @Betree can you double check as well?). However if we are not anticipating heavy customizations I think we should be okay as it seems to support almost all graphs that I see on design; https://www.figma.com/file/ZQBMWhnGGtRWeIZknFW1eP/[OC-Design]-Production-Ready-✅?node-id=13711%3A157088
cc: @Betree


Switched to Zulu (Open JDK).

The jdk-wrapper project is now homed here:
https://github.com/KoskiLabs/jdk-wrapper
And information about migrating is here:
https://github.com/KoskiLabs/jdk-wrapper/blob/master/MIGRATION.md
Looks like compiling this project is about 1.5 seconds slower under Zulu than the same version of Oracle (out of about 22 seconds). However, this is very anecdotal. The nice thing is that the enforcer rule doesn't break since it's technically the same point release of the JDK as before.