Security 3.8a/3.9/3.10a: Upload Assay - Remove sample field, link records to research team and user

There is no longer a link from the Assay table to sample, since this is modeled at the well level only.
It looks like some configuration was already performed on the add_project.html form to remove the sample field.
3.8a: Remove sample field from Upload Assay
3.8a Tasks:

Remove the following reference to samples from add_project.html:

var samples = JSON.parse('{{ samples | tojson | safe}}');

app_server.py Line 361: Replace samples with _ and do not pass into render_template
Test before proceeding

3.8a Test Plan:

Upload assays workflow is functional; db updates are appropriate

3.9: New records are linked to research team
3.9 Tasks:

Start at app_server.py route associated with the create action, follow down to dao method.
Retrieve team_ID from self.session['team_ID'].
Add team_ID to parameters passed to Q_CREATE_ASSAY
Update Q_CREATE_ASSAY to utilize passed team_ID to set this attribute
Verify Q_CREATE_ASSAY is not used elsewhere

3.9 Test Plan:

Verify that new records are created with the appropriate value set for the team_ID attribute
Verify that record editing and deleting is unaffected by this change
Test for multiple users
Test when logged in to different teams

3.10a: Store user with a newly created Assay record
3.10a Tasks:

Change user_ID attribute in Assay table to created_by; on delete set null
In AssayDao.create_assay(), pass user_ID (retrieved from session) to Q_CREATE_ASSAY
Update Q_CREATE_ASSAY to set created_by attribute

3.10a Test Plan:

When an assay record is created, the creating user is attached
Assay editing workflow functions as expected, and does not update the creating user attribute
Works for multiple users

3.8a Test Plan - SUCCESS!
3.9 Test Plan - SUCCESS!
3.10a Test Plan - SUCCESS!


3Delight: Support for Maya

Is your feature request related to a problem? Please describe.
The OpenPype doesn't have support for 3Delight render.
Describe the solution you'd like
Add render support for 3Delight.
Describe alternatives you've considered
This is additive, nothing alternative.
Additional context
This is needed by us, and we'd develop it and create PR for this feature.

Thank you, we're looking forward to seeing the results.
If you need any deeper support during the development @antirotor is the best person to discuss this with as he was implementing new renderers recently and has the best overview.

Just for complreteness, we have a PR for this open right now.

Can we get this merged in?

Can we get this merged in?

Sure, there are few comments there from @BigRoy and the conflict I can resolve.


See if CMake can do what rossum does

Now that ktransw makes ktrans.exe behave a little bit more like a normal compiler, it might be possible to use CMake and its find_package(..) infrastructure to do the same thing as rossum does.
As CMake is much more feature-complete, that would be a good thing.
This would probably require adding support for (a) new language(s) to CMake.

Colcon could also be an option.


No links in aem-content component when authoring with different branch

I am working with a feature branch using ?ref=branch in the URL. I have added a button component which uses the aem-content component to configure the hyperlinks. However the popup does not show any folders/files to select a link.

As of 4th Sep 2024, I am not able to reproduce the error.


Add a #[pyo3] macro

It would be great to have a single #[pyo3] macro like the #[wasm-bindgen] macro in wasm-bindgen. This macro would have the following properties:

It can be attached to functions, classes, impl $struct and impl $protocol for $struct. The macro can decide where it's attached to by using syn::parseinto a syn::Item, matching and delegating to the respective code gen function.
It supports the parameters currently supported (mostly by reusing the existing code)
Method types (static, method, etc.) are automatically detected. The constructor might require a #[pyo3(constructor)] annotation
There is #[pyo3(module)] to replace #[pymodule]. It doesn't need to support #[pyfn] though since we can do freestanding functions now.
Tests for all features. This doesn't need to be as elaborate as wasm-bindgen, but maybe we can come up with something where we feed syn item to functions in pyo3-derive-backend. (Integration tests are also sufficient)

The best was to get started is probably adding a function in pyo3cls/src/lib.rs that dispatches to the existing macros and then expanding upon that. Looking into capybara*s pyo3 wrapper and wasm bindgen's macro frontend should give some additional pointers.

I have been thinking about this and think it's a good idea. We also implemented attributes like #[name = "foo"] on #[pyclass], but in retrospect I think that might have been a mistake and should have been namespaced as #[pyo3(name = "foo)].
We might want to do a review of how much we can add in a non-breaking fashion already and then consider deprecating old names later.


fix: moves label out of flex wrapper to remove extra gap causing missalignment with other input fields

This pull request fixes a styling issue. The Select component label has been put into flex wrapper making the gap between the label and input field bigger. This casues misaligment issue with other fields like TextField.

Will be included in the next ACL release 😄


[entra] Update @azure/functions-authentication-events to ESM/vitest

Packages impacted by this PR

@azure/functions-authentication-events

Issues associated with this PR

https://github.com/Azure/azure-sdk-for-js/issues/31338

Describe the problem that is addressed by this PR
Updates @azure/functions-authentication-events to ESM/vitest via automation.
What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
Are there test cases added in this PR? (If not, why?)
Provide a list of related PRs (if any)
Command used to generate this PR:**(Applicable only to SDK release request PRs)
Checklists

[ ] Added impacted package name to the issue description
[ ] Does this PR needs any fixes in the SDK Generator?** (If so, create an Issue in the Autorest/typescript repository and link it here)
[ ] Added a changelog (if necessary)

API change check
API changes are not detected in this pull request.


Make ddf * df have correct _meta

[x] Tests added / passed
[x] Passes black dask / flake8 dask
[x] Closes #6441

If this is a good idea then I can add more dunder methods.

I am +1 on this.  @TomAugspurger  ?

Looking through it now. A couple things:
1.Need to check if / how this is overwriting __mul__ method that's created through OperatorMethodMixin and _bind_binary_operator. Are we defining it twice?
2.  meta is currently defined in elemwise at
4772        if meta is no_default:
4773            if len(dfs) >= 2 and not all(hasattr(d, "npartitions") for d in dasks):
4774                # should not occur in current funcs
4775                msg = "elemwise with 2 or more DataFrames and Scalar is not supported"
4776                raise NotImplementedError(msg)
4777            # For broadcastable series, use no rows.
4778            parts = [
4779                d._meta
4780                if _is_broadcastable(d)
4781                else np.empty((), dtype=d.dtype)
4782                if isinstance(d, Array)
4783                else d._meta_nonempty
4784                for d in dasks
4785            ]
4786            with raise_on_meta_error(funcname(op)):
4787 ->             meta = partial_by_order(*parts, function=op, other=other)

We've converted the user-provided pandas Series to a Dask Array
(Pdb) pp dasks[1].compute()
A    1
B    2
C    3
dtype: int64

and truncated it
(Pdb) pp parts[1]
Series([], dtype: int64)

We would get the right meta if we just used the pandas object
(Pdb) pp partial_by_order(parts[0], dasks[1].compute(), function=op, other=other)
     A    B    C
0  1.0  2.0  3.0
1  1.0  2.0  3.0

Would it be better to fix elemwise by using the pandas object? (probably). What would "fixing" it break? (no idea)

Thanks @TomAugspurger for pointing out how it currently works. I totally missed that. It seems clear that what I've done in this PR isn't the right approach, but it does seem odd to follow such different paths for mul and __mul__. Wouldn't you expect them to do the same thing?

it does seem odd to follow such different paths for mul and mul. Wouldn't you expect them to do the same thing?

Yep, agreed for the most part. They'll need to start on different paths since DataFrame.mul has different parameters than DataFrame.__mul__, but they should quickly converge on the same path to get consistent behavior.

So I guess the question is - which is the better approach: using elemwise or map_partitions?

Predictably, this is much gnarlier than anticipated. I think elemwise is the right approach but that method is used so broadly that it is hard to make changes in there. I am going to close this for now as I don't think it's particularly important.


Reinstate original copyright

This code is a fork of rust-libp2p but this is not mentioned anywhere (which is required by the license). Can you please put back the original copyright notice?

Yeah，most of the logic for handshake and exchange in secio is done with reference to go-secio and rust-libp2p. It may be refactored later, and some other changes may be made. Currently, a short description is given on secio readme. But other modules are available, there is no direct relationship with rust-libp2p

If you need it, I can add a description to the readme and the corresponding file, which refers to the code of rust-libp2p.

Please note that except for the handshake in secio, all subsequent processing is not the same as rust-libp2p. rust-libp2p uses locks for multiplexing. I use channel completely for multiplexing and message distribution here.
I will mark the source of the code on a file that uses the libp2p-secio module, but don't assume that the entire library is sourced with rust-libp2p.

I just wonder, why do you think it’s a fork?
We are mainly referenced the coresponding golang version, which we think is an elegant design.

@TheWaWaR Well, much of the code is a straight copy (with the attribution to the original authors removed). I used the word "fork" to be polite.
@driftluo The original rust-libp2p code is MIT licensed so you are of course free to transform it as you please, just as long as the original copyright notice is kept intact. Thank you!

@dvdplm I have annotated the full copy and most of the references in secio, but the logic of the secure stream and stream handle are completely different from rust-libp2p, so in these two files I don't need to label these things.


Add links to code of conduct and content guideline

This PR adds links to the code of conduct and the content guideline from the main hub-docs page.

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.

shouldn't they also be listed in the left sidebar here?

As far as I know, the left sidebar lists markdown pages and doesn't link to other URLs. I embedded the code of conduct and content guideline as URLs, since I didn't think that they warranted their own full page in the hub-docs. But if we want that, I can totally make a full page for it!

cc @mishig25. Is it possible to list external URLs in the sidebar in the docs?

As far as I know, the left sidebar lists markdown pages and doesn't link to other URLs. I embedded the code of conduct and content guideline as URLs, since I didn't think that they warranted their own full page in the hub-docs. But if we want that, I can totally make a full page for it!

oh yeah you're right I missed that


question

What do you only use, that ??? impel??? Friend if you don't want to do it don't say it easy, ChatGPT ??? That's your reference

Hi, I didn’t understand what you’re talking about… could you explain yourself better? Thanks.


Add cil

Adds CIL optimisation and regularisation.
Adds new iterative reconstruction algorithms from CIL.
Currently tested with SPDHG.
Functionality requires:

https://github.com/CCPPETMR/SIRF/pull/237
https://github.com/CCPPETMR/SIRF/pull/238
Cython

a note on copyright dates and notices. If you copied code from somewhere, you need to preserve its copyright data/notice. At the same time, you need to make sure it's up to date with your changes.
Seems therefore that you either remove Ben and me, or you keep the original date. sorry

Now getting a weird error during make:
Traceback (most recent call last):
  File "/home/travis/build/CCPPETMR/SIRF-SuperBuild/builds/CCPi-RGL/build/Wrappers/Python/setup-regularisers.py", line 6, in <module>
    from Cython.Distutils import build_ext
ImportError: No module named Cython.Distutils

even though cython was installed and found

I would change the cmake variable cython_bin to cython_EXECUTABLE (similar to SWIG_EXECUTABLE and PYTHON_EXECUTABLE).

On OSX, I'm getting an openMP error:

/Users/rich/Documents/Code/SIRF-SuperBuild/Build/sources/CCPi-RGL/Core/regularisers_CPU/FGP_TV_core.h:25:10: fatal error:
      'omp.h' file not found
#include "omp.h"

I haven't looked through the code, but presumably you need inspire yourself from BUILD_STIR_WITH_OPEN_MP (default to OFF for APPLE), which then needs to get passed through to CIL.

I see the OSX problem, but I've never tested the regularisation on OSX. I guess I'll disable CIL for OSX.

I believe I addressed the requested changes.
Travis fails to build during test because some packages aren't found (specifically python PIL, which is installed). I'm unsure if and how to install with pip, help is welcome.
I created a BUILD_CIL and BUILD_CIL_LITE options. With the latter one installs CCPi-Framework, CCPi-FrameworkPlugins, CCPi-Regularisation-Toolkit. With the former one installs the additional X-ray CT engine ASTRA-toolbox, CCPi-Astra, TomoPhantom.
Currently these option are only available on Linux.
The things that are still to be changed are the SIRF TAG and CIL TAGs.

STIR.py", line 1173
    if not out is None:
                      ^
TabError: inconsistent use of tabs and spaces in indentation

I'm afraid I cannot accept a PR that makes most Travis jobs fail... I know there's OSX problems but this breaks even Linux.
@casperdcl would you be able to help with the pip problem?

@KrisThielemans ah this looks fun. Over a hundred commits and comments. Haven't been following. What's the pip problem?

@casperdcl I need the Python Image Library, PIL or pillow installed on travis.
it's installed but it's not found during tests. That's just the first build in the travis matrix.
You can have a look (if you want) in the log.
I guess the other failures are due to the previous comment.

PIL's deprecated in favour of the Pillow fork. You were also installing dependencies in the system rather than the working python env.
Should be fixed now (there are other unrelated errors).

new problem:
https://travis-ci.org/CCPPETMR/SIRF-SuperBuild/jobs/590322738#L2087
TomoPhantom is finding python2.7 rather than the env's $PY_EXE

That's interesting. The way TomoPhantom finds python is the same as SIRF's

for the SuperBuild there's a -DPYTHON_EXECUTABLE=$PY_EXE which I assume is propagated to SIRF. You'll need the same for TomoPhantom

sigh nvm just fixed it; you'll have to ensure TomoPhantom uses the env vars (https://github.com/CCPPETMR/SIRF-SuperBuild/pull/154/commits/432ff49cf65d16cc69e02e78b7f250f99bf9ba54) just as SIRF does.

Thanks @casperdcl ! The last bit that fails is that travis builds the wrong branch of SIRF:
it should use add_to_sirf_classes
but in facts it uses add_to_sirf_classes_merge_master.
Does travis do some kind of caching?

before your comment edit, about SIRF tags, it's probably best to specify -DSIRF_TAG=... somewhere in .travis.yml amd revert before merge rather than mess with version_config

I see your point. I added an if (CIL_BUILD) in version_config that will allow when BUILD_CIL=ON to build the add_to_sirf_classes branch of SIRF rather than master or v2.0.0
There remain a few problems:

missing wget python module during tests (which I think I fixed)
osx builds
docker build

@casperdcl docker builds fail because of some further dependencies not met for astra

I'll be fixing the docker/ stuff shortly (I hope).

interesting looks like travis has an old version of docker which is failing to build because of something like https://github.com/GoogleContainerTools/skaffold/issues/2576 - or perhaps the cache was cleared in a previous build which failed.

@casperdcl ready to merge?

@KrisThielemans there's still https://github.com/CCPPETMR/SIRF-SuperBuild/pull/154/files#r330539512 I think needs to be addressed (or ignored - idk)

apart from that there's all the hardcoded version/branch stuff which may have to change.

@paskino, @casperdcl please add some lines to CHANGES.md as well before the merge please

@paskino looks like you squash-merged this which means no git history. @KrisThielemans would you mind if I force-push to master including the history?

Ok. Please send an email to the list
Kris

From: Casper da Costa-Luis<EMAIL_ADDRESS>Sent: Tuesday, October 8, 2019 9:58:37 AM
To: CCPPETMR/SIRF-SuperBuild<EMAIL_ADDRESS>Cc: Thielemans, Kris<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [CCPPETMR/SIRF-SuperBuild] Add cil (#154)
@paskinohttps://github.com/paskino looks like you squash-merged this which means no git history. @KrisThielemanshttps://github.com/KrisThielemans would you mind if I force-push to master including the history?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/CCPPETMR/SIRF-SuperBuild/pull/154?email_source=notifications&email_token=ABQRIHMVPYA3F52WZUUXVX3QNRDT3A5CNFSM4GEZX2D2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEATONXI#issuecomment-539420381, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABQRIHPNOFFSP7JUR3NFYFLQNRDT3ANCNFSM4GEZX2DQ.

@KrisThielemans there was a 15min gap between the merge and my force-push, and the code was in the same state so don't think it should be an issue (@paskino you may be the only one who has to git checkout master && git fetch origin && git reset --hard origin/master


History sub search in Bash

Does anybody know a history sub search plugin for Bash?
In Fish and Zsh there is a plugin called history-substring-search that you can type part of a sentence and press Up Arrow, it will complete the sentence according to history and highlight the matching words.
I miss it in Bash. I already use Ctrl+R but it not the same, I don't feel productive.

I'm not familiar with these features in Fish and Zsh, but there has been a similar discussion here in #894.
There are some great suggestions in that ticket. Personally, I use fzf with the Bash-it fzf plugin, which overrides the default Ctrl+R behavior, that works really well for me.
Please let me know if that helps.

I've found that GNU Readline has a feature called history-substring-search-backward which is what I'm looking for: you can type any part of a previously entered command and press Up Arrow, it will complete it for you.
Since Bash 4+ this feature is available.
You just need to configure it in ~/.inputrc file:
"\e[A": history-substring-search-backward
"\e[B": history-substring-search-forward

Then, Ctrl+x Ctrl+r to reload configs from ~/.inputrc, or just reload bash.
This is faster than using Ctrl + r :smile:
The only thing is missing is the highlighting what has been matched. But I can live without that.
Thanks

Interesting - is there the concept of a configurable inputrc for bash-it? The whole mantra of this project seems to be "reduce the number of cluttered *rc files".
Would it be possible to include this as a plugin / feature so someone could use bash-it instead of manually adding a line to their inputrc

@jpmcb It's also possible to active it in ~/.bashrc like this:
bind '"\e[A": history-substring-search-backward'
bind '"\e[B": history-substring-search-forward'

So we don't need the ~/.inputrc anymore.
It's possible to create a plugin to activate this.

Exactly - these two lines would need to be defined in a plugin, e.g. bash-history or something like that.

OK, looks like we already have that:
https://github.com/Bash-it/bash-it/blob/master/plugins/available/history.plugin.bash
You can enable that with bash-it enable plugin history. It uses history-search-backward, without the substring part, but that could be adjusted, or configured through an environment variable if needed.

@nwinkler How do I make the history plugin use the substring part?

@nwinkler How do I make the history plugin use the substring part?

@mcarans You just need to enable the plugin and reload your shell (or start a new one):
$ bash-it enable plugin history
$ bash-it reload

You may also enjoy our new documentation at https://bash-it.readthedocs.io/en/latest/

@mcarans You just need to enable the plugin and reload your shell (or start a new one):
$ bash-it enable plugin history
$ bash-it reload

You may also enjoy our new documentation at https://bash-it.readthedocs.io/en/latest/

@cornfeedhobo The problem is that the current history plugin uses history-search-backward not history-substring-search-backward (https://github.com/Bash-it/bash-it/blob/master/plugins/available/history.plugin.bash). Is there a way to modify the installed history plugin to use history-substring-search-backward?

@cornfeedhobo The problem is that the current history plugin uses history-search-backward not history-substring-search-backward (https://github.com/Bash-it/bash-it/blob/master/plugins/available/history.plugin.bash). Is there a way to modify the installed history plugin to use history-substring-search-backward?

@mcarans The original post asked:

history-substring-search that you can type part of a sentence and press Up Arrow, it will complete the sentence according to history and highlight the matching words.

That is exactly what the history plugin does. When I type ech and hit the up arrow, the only commands shown are ones that begin with the ech prefix, e.g. echo "foobar".
Are you looking for something different?

@mcarans The original post asked:

history-substring-search that you can type part of a sentence and press Up Arrow, it will complete the sentence according to history and highlight the matching words.

That is exactly what the history plugin does. When I type ech and hit the up arrow, the only commands shown are ones that begin with the ech prefix, e.g. echo "foobar".
Are you looking for something different?

@cornfeedhobo That works for me! Out of interest what would the addition of substring do if anything?

@cornfeedhobo That works for me! Out of interest what would the addition of substring do if anything?

@cornfeedhobo I found the answer here
history-search-backward: The search string must match at the beginning of a history line
history-substring-search-backward: The search string may match anywhere in a history line.
It seems to me like history-substring-search-backward is more useful. Is there any way I can change the plugin to use history-substring-search-backward?

@cornfeedhobo I found the answer here
history-search-backward: The search string must match at the beginning of a history line
history-substring-search-backward: The search string may match anywhere in a history line.
It seems to me like history-substring-search-backward is more useful. Is there any way I can change the plugin to use history-substring-search-backward?

@mcarans Sorry got pulled away. Looks like you figured it out - substring means that if you type in echo and hit the up arrow, it will show any command which contains the string "echo", regardless of position. Thanks for sticking with it!
I definitely think we can work something in to address this option, just need to think of the most elegant way to expose that option to users. I'm not sure if I'd prefer breaking up history into different plugins, or using an environment variable to toggle the functionality.
@tbhaxor @nwinkler @NoahGorny @davidpfarrell  any thoughts?

@mcarans Sorry got pulled away. Looks like you figured it out - substring means that if you type in echo and hit the up arrow, it will show any command which contains the string "echo", regardless of position. Thanks for sticking with it!
I definitely think we can work something in to address this option, just need to think of the most elegant way to expose that option to users. I'm not sure if I'd prefer breaking up history into different plugins, or using an environment variable to toggle the functionality.
@tbhaxor @nwinkler @NoahGorny @davidpfarrell  any thoughts?

@cornfeedhobo I'd go with an environment variable to change which command is being used. Adding a second plugin will lead to further complexity, e.g. when people enable both plugins. Using an environment variable, we can have a defined default behavior and also an easy option for overriding things. A couple of items to address:

We should aim for consistent naming patterns for plugin configuration options - don't think we have a consistent pattern at the moment.
How do we document plugin configuration settings? Do we want to support an optional documentation file per plugin?

@cornfeedhobo I'd go with an environment variable to change which command is being used. Adding a second plugin will lead to further complexity, e.g. when people enable both plugins. Using an environment variable, we can have a defined default behavior and also an easy option for overriding things. A couple of items to address:

We should aim for consistent naming patterns for plugin configuration options - don't think we have a consistent pattern at the moment.
How do we document plugin configuration settings? Do we want to support an optional documentation file per plugin?

Since I was waiting around and ended up coming to my an opposite conclusion, I'm going to continue that discussion in #1764, at least until we decide if we want to go with that route or another one. Thanks everyone!

Since I was waiting around and ended up coming to my an opposite conclusion, I'm going to continue that discussion in #1764, at least until we decide if we want to go with that route or another one. Thanks everyone!


Revert "[Fix-8836][UI Next][V1.0.0-Alpha] Rectify this issue about creating a file or directory with a wrong path."

Reverts apache/dolphinscheduler#8880

Codecov Report

Merging #8888 (0da8459) into dev (e4dcf3d) will increase coverage by 0.02%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##                dev    #8888      +/-   ##
============================================
+ Coverage     45.27%   45.30%   +0.02%
- Complexity     4081     4082       +1
============================================
  Files           702      702
  Lines         27186    27177       -9
  Branches       2908     2907       -1
============================================
+ Hits          12309    12312       +3
+ Misses        13715    13704      -11
+ Partials       1162     1161       -1

Impacted Files
Coverage Δ

...nscheduler/api/controller/ResourcesController.java
58.92% <ø> (+1.03%)
:arrow_up:

...heduler/api/service/impl/ResourcesServiceImpl.java
54.34% <ø> (+0.67%)
:arrow_up:

...dolphinscheduler/remote/future/ResponseFuture.java
81.96% <0.00%> (-1.64%)
:arrow_down:

...e/dolphinscheduler/remote/NettyRemotingClient.java
53.52% <0.00%> (+2.81%)
: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 e4dcf3d...0da8459. Read the comment docs.


Prevent Vue Router from accessing the history object when using hash mode

What problem does this feature solve?
The feature request is simple: Vue Router should not access history at all when it starts in hash mode.
But Why?
The problem is that Chrome web apps (as in apps installed from the Chrome Web Store to Chrome OS devices) do not have access to the same browser API a regular web app has. In this particular case the problem is that the history object is not present.
This was not really a problem before, history was undefined and it didn't really matter. The current behavior is different. When an app tries to access the history object it completely crashes. A polyfill cannot be implemented either because of this.
It would seem the solution to this problem should be simply to stick to hash mode, but Vue Router still tries to access history even in hash mode. I imagine this is done to check whether the history API is present, but since hash mode is already specified, those checks are unnecessary.
A couple of months ago I hacked my way through this by modifying Vue Router. If there is interest I could implement this feature myself.
Even if this feature is not implemented the Vue team should at least be aware of this limitation.
What does the proposed API look like?
No changes in the API would be necessary.

When an app tries to access the history object it completely crashes.

I would assume that's a bug with that platform,  right?

It would seem the solution to this problem should be simply to stick to hash mode, but Vue Router still tries to access history even in hash mode. I imagine this is done to check whether the history API is present, but since hash mode is already specified, those checks are unnecessary.

Not really. One might use hash mode, but want to use scrollBehaviour - which only works if pushState is supported. Checking that requires accessing the window.history object.
See here:
https://github.com/vuejs/vue-router/blob/dev/src/history/hash.js#L25
https://github.com/vuejs/vue-router/blob/dev/src/util/push-state.js#L18
Removing that would result in a breaking change that makes scrollBehaviour unavailable in hash mode
So I don't think this is feasable

I would assume that's a bug with that platform, right?

I doubt it, it seems to me it's Chrome OS preventing access to certain APIs. A couple of years back it was a silent error. Now the app simply cannot continue execution. It's not only related to window.history, there are a number of other APIs such as window.confirm that aren't available either.

Not really. One might use hash mode, but want to use scrollBehaviour - which only works if pushState is supported. Checking that requires accessing the window.history object.

Indeed.
I forked Vue Router to be able to use it in Chrome OS, and I solved the scroll problem with:
watch: {
	$route (to, from) {
		this.$refs['some-div'].scrollTop = 0;
	}
}

Anyway, I completely understand that offering limited support to Chrome OS apps might not be in the interest of the Vue team though.


POLIO-778 Allow setting the language on embedded powerbi report

Add a language settings on the power bi report that will be used for translation if the report support it.
Related JIRA tickets : POLIO-778
Self proof reading checklist

[x] Did I use eslint and black formatters
[x] Is my code clear enough and well documented
[x] Are my typescript files well typed
[NA] Did I add translations
[x] My migrations file are included
[NA] Are there enough tests

fixed the tests


Fix source links

Description
Fixes #1458
Type of change

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update
[ ] Code quality improvements

Checklist
Please delete options that are not relevant.

[x] I have tested this code

Pull Request Test Coverage Report for Build 7369

0 of 4 (0.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 33.173%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/commons/editor/UseNavigation.tsx
0
4
0.0%

Totals

Change from base Build 7358:
0.0%

Covered Lines:
2299

Relevant Lines:
6411

💛  - Coveralls


Ensure correct task state for fresh session of unassigned user

Details

Fixed Issues

$ https://github.com/Expensify/App/issues/21924
PROPOSAL: https://github.com/Expensify/App/issues/21924#issuecomment-1614421454
Tests

Log in to NewDot on Chrome web with User A
User A creates a task within a chat with User B, assigned to User A
User A completes the task
User B signs in (on a fresh session) and opens the chat
Verify that the task checkbox shows as completed

[x] Verify that no errors appear in the JS console

Offline tests

N/A (can't sign in with User B if offline).
QA Steps

Same as above.

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web
https://github.com/Expensify/App/assets/27287420/243ca934-e81a-492a-b7d0-73ab93cb9e66

Mobile Web - Chrome
https://github.com/Expensify/App/assets/27287420/313f15e6-684e-411b-b7b9-cf826e05db3c

Mobile Web - Safari
https://github.com/Expensify/App/assets/27287420/a28172fa-9eec-4063-851c-6c552b3f65ac

Desktop
https://github.com/Expensify/App/assets/27287420/b58ef472-5ef3-4dfb-8306-9488629df6e5

iOS
https://github.com/Expensify/App/assets/27287420/48d9caf1-4e26-4263-9794-e1fc25cd305e

Android
https://github.com/Expensify/App/assets/27287420/16803264-34a7-462e-a6f2-ca98026f0f34

Reviewer Checklist

[x] I have verified the author checklist is complete (all boxes are checked off).
[x] I verified the correct issue is linked in the ### Fixed Issues section above
[x] I verified testing steps are clear and they cover the changes made in this PR

[x] I verified the steps for local testing are in the Tests section
[x] I verified the steps for Staging and/or Production testing are in the QA steps section
[x] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[x] I checked that screenshots or videos are included for tests on all platforms
[x] I included screenshots or videos for tests on all platforms
[x] I verified tests pass on all platforms & I tested again on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[x] I verified proper code patterns were followed (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I verified that this PR follows the guidelines as stated in the Review Guidelines
[x] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

Mobile Web - Chrome

Mobile Web - Safari

Desktop

iOS

Android

@jjcoffee, we still have an ESLint rule that enforces the usage of the underscore method.
So, for now, could you revert to your previous version that uses _.isEmpty? I apologize 🙇

@hayata-suenaga No worries at all! I had tried to disable that rule, but it looks like prettier broke it again by adding a new line. Reverted now!

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/hayata-suenaga in version: 1.3.37-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/Julesssss in version: 1.3.37-7 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


connect miner

How do I connect a miner? Does it  support pool stratum?

Stratum V1 & V2 are supported. Just direct your miner to the IP address and port you've configured in the config.json file
On my local network I would use stratum2+tcp://<IP_ADDRESS>:3030 or stratum+tcp://<IP_ADDRESS>:3030 depending on the miner. Obviously anyone connecting from outside of your network would connect to your public IP or domain you setup in your DNS. Don't forget to open the appropriate ports on your firewall and/or configure any port forwarding on your router/switch

Thanks
I use a virtual machine(virtualbox), does this cause a problem?

That's out of my scope of experience. Perhaps there is someone else who has more experience with VM who can chime in here.

Thanks I use a virtual machine(virtualbox), does this cause a problem?

No it does not. How many miners are you planning to support with your pool?

I'm going to connect to the pool in the virtual machine via ASIC

yes , I'm going to connect to the pool in the virtual machine via ASIC

That was not my question.


[Task]: Update connectors to Ballerina version 2201.3.1

Connector Name
other (None Listed Above)
Task Description
The following connectors will be updated to the Ballerina version 2201.3.1
This is related to the issue https://github.com/wso2-enterprise/choreo/issues/17626

Twitter
NetSuite

Closing since the above connectors are released


Add x/gov messages to stargate.codec

Requested in discord by @shanev
Currently protobuf types are generated for:
cosmos: auth, bank, distribution, staking
ibc: channel, client, commitment, connection
Both looking at queries and the generated protobuf codec
Governance is a bit trickier, as we must register and define all the proposal types. This may require more updates to the protobuf generation, as well as registry and possibly a few more helper functions to enable this (protobug.Any inside protobuf.Any).
Note: as there is an ongoing proto-ts refactor #616, it may make sense to deal with this one all the other types are working with the new codec.

Here's a failing test based on our fork of cosmjs that generates gov:
import { cosmos } from '@stargazefi/proto-signing/build/codec';

const { TextProposal, MsgSubmitProposal } = cosmos.gov.v1beta1;

it('Encodes and decodes MsgSubmitProposal', () => {
    const textProposalMsg = TextProposal.create({
        title: 'title',
        description: 'decription'
    });

    const textProposalMsgAny = {
        typeUrl: "/cosmos.gov.v1beta1.TextProposal",
        value: textProposalMsg,
    }

    const msg = MsgSubmitProposal.create({
        content: textProposalMsgAny,
        initialDeposit:[{
            denom: "uatom",
            amount: "100000000"
        }],
        proposer: "cosmos1qypqxpq9qcrsszg2pvxq6rs0zqg3yyc5lzv7xu"
    })

    const expected = MsgSubmitProposal.encode(msg).finish();
    const decoded = MsgSubmitProposal.decode(expected);

    expect(decoded).toEqual(msg);
});

Here's a failing test based on our fork of cosmjs that generates gov:
import { cosmos } from '@stargazefi/proto-signing/build/codec';

const { TextProposal, MsgSubmitProposal } = cosmos.gov.v1beta1;

it('Encodes and decodes MsgSubmitProposal', () => {
    const textProposalMsg = TextProposal.create({
        title: 'title',
        description: 'decription'
    });

    const textProposalMsgAny = {
        typeUrl: "/cosmos.gov.v1beta1.TextProposal",
        value: textProposalMsg,
    }

    const msg = MsgSubmitProposal.create({
        content: textProposalMsgAny,
        initialDeposit:[{
            denom: "uatom",
            amount: "100000000"
        }],
        proposer: "cosmos1qypqxpq9qcrsszg2pvxq6rs0zqg3yyc5lzv7xu"
    })

    const expected = MsgSubmitProposal.encode(msg).finish();
    const decoded = MsgSubmitProposal.decode(expected);

    expect(decoded).toEqual(msg);
});

@shanev could you add more context of what you try to do?
Ethan is right, we do not do the code generation for gov right now. But this can be done on the caller side, as you figured out already. Once you have the types, you need to register them, e.g. in a SigningStargateClient as done here: https://github.com/cosmos/cosmjs/blob/v0.24.0-alpha.20/packages/cosmwasm-stargate/src/queries/wasm.spec.ts#L40-L67.

@shanev could you add more context of what you try to do?
Ethan is right, we do not do the code generation for gov right now. But this can be done on the caller side, as you figured out already. Once you have the types, you need to register them, e.g. in a SigningStargateClient as done here: https://github.com/cosmos/cosmjs/blob/v0.24.0-alpha.20/packages/cosmwasm-stargate/src/queries/wasm.spec.ts#L40-L67.

Long term it is expected to only include the abolute minimum types in @cosmjs/proto-signing and a small sumset of common Cosmos SDK types in @cosmjs/stargate. In addition to that, we'll make it easier than right now to add your own types externally. ts-proto will help us make that much nicer than right now.

Long term it is expected to only include the abolute minimum types in @cosmjs/proto-signing and a small sumset of common Cosmos SDK types in @cosmjs/stargate. In addition to that, we'll make it easier than right now to add your own types externally. ts-proto will help us make that much nicer than right now.

@webmaster128 Simply trying to sign and broadcast a MsgSubmitProposal to an SDK-based chain (v 0.40.1) that uses gov. Will try the registry and fallback to REST until the ts-proto migration is done. Thank you, this clears it up.

@webmaster128 Simply trying to sign and broadcast a MsgSubmitProposal to an SDK-based chain (v 0.40.1) that uses gov. Will try the registry and fallback to REST until the ts-proto migration is done. Thank you, this clears it up.

@shanev Cosmos-SDK v0.40 is pre-Stargate and does not support protobuf encodings.

@shanev Cosmos-SDK v0.40 is pre-Stargate and does not support protobuf encodings.

Cosmos-SDK v0.40 is pre-Stargate and does not support protobuf encodings.

Cosmos SDK v0.40 is the first protobuf-based release and the protobuf gov transactions should work here. It might not be the version released to the Hub and it is getting blury what "Stargate" actually means, but this is a different story.

Cosmos-SDK v0.40 is pre-Stargate and does not support protobuf encodings.

Cosmos SDK v0.40 is the first protobuf-based release and the protobuf gov transactions should work here. It might not be the version released to the Hub and it is getting blury what "Stargate" actually means, but this is a different story.

@shanev Cosmos-SDK v0.40 is pre-Stargate and does not support protobuf encodings.

This is incorrect.
v0.40 = Stargate (https://github.com/cosmos/cosmos-sdk/releases/tag/v0.40.0)
v0.39 = Launchpad for previous chains
v0.41 was released today (https://github.com/cosmos/cosmos-sdk/releases/tag/v0.41.0) which I guess is the new new Stargate that'll be used for the upgrade :)

@shanev Cosmos-SDK v0.40 is pre-Stargate and does not support protobuf encodings.

This is incorrect.
v0.40 = Stargate (https://github.com/cosmos/cosmos-sdk/releases/tag/v0.40.0)
v0.39 = Launchpad for previous chains
v0.41 was released today (https://github.com/cosmos/cosmos-sdk/releases/tag/v0.41.0) which I guess is the new new Stargate that'll be used for the upgrade :)

This ticket is mostly superseded by #799. Let's address this first. Then we'll be in a different sitiuation and have different follow-up discussions.


Failed to import component in my project

I added these lines to my index.js file:
import VueGoodTable from 'vue-good-table'; Vue.use(VueGoodTable);
When loading the application, I get this error message:
SyntaxError: 'import' and 'export' may only appear at the top level (2:0) while parsing C:\ScoreExpress\loopback\node_modules\vue-good-table\src\index.js while parsing file: C:\ScoreExpress\loopback\node_modules\vue-good-table\src\index.js
Any idea what I'm doing wrong?

@ahallez vue-good-table uses ES6, in order to use it like the way you've described, you'd need to have a transpiler in your build process. Are you using one (eg babel) in your build process?

@ahallez @xaksis This might be due to js linting setup.
There are some linters (I think standard) which don't allow you to make imports after some statements.
Make sure all your imports are before any statements.

closing this.


Can't connect to SSL servers on WSL

Ubuntu 18.04 WSL, installed znc from apt. (did try nightly build as well, same issue)
Adding Freenode (might be some other network, same issue) SSL server the following way:
<Listener l>
        Port = 48446
        IPv4 = true
        IPv6 = true
        SSL = false
</Listener>
LoadModule = webadmin

<User zncweb1>
        Pass       = sha256#544d4b0c86630ee21e48908343d425760a54b4abde8e82ca7be625c31510e61f#jsgnox!jGT:wZ.mHww;O#
        Admin      = true
        Nick       = zncweb1
        AltNick    = zncweb1_
        Ident      = zncweb1
        RealName   = zncweb1
        LoadModule = chansaver
        LoadModule = controlpanel

        <Network freenode>
                LoadModule = simple_away
                Server     = chat.freenode.net +6697
        </Network>
</User>

ZNC -D shows the following:
justas@WT02:~/.znc/configs$ znc -D
[ .. ] Checking for list of available modules...
[ >> ] ok
[ .. ] Opening config [/home/justas/.znc/configs/znc.conf]...
[ >> ] ok
[ .. ] Loading global module [webadmin]...
[ >> ] [/usr/lib/znc/webadmin.so]
[ .. ] Binding to port [48446]...
[ >> ] ok
[ ** ] Loading user [zncweb1]
[ ** ] Loading network [freenode]
[ .. ] Loading network module [simple_away]...
[ >> ] [/usr/lib/znc/simple_away.so]
[ .. ] Adding server [chat.freenode.net +6697 ]...
[ >> ] ok
[ .. ] Loading user module [chansaver]...
[ >> ] ok
[ .. ] Loading user module [controlpanel]...
[ >> ] ok
[ ** ] Staying open for debugging [pid: 1513]
[ ** ] ZNC 1.6.6+deb1ubuntu0.1 - http://znc.in
[2019-06-05 17:44:32.482940] Connecting user/network [zncweb1/freenode]
[2019-06-05 17:44:32.484645] TDNS: initiating resolving of [chat.freenode.net] and bindhost [] for [IRC::zncweb1::freenode]
[2019-06-05 17:44:32.485390] ConnectQueueTimer done
[2019-06-05 17:44:32.500198] TDNS: IRC::zncweb1::freenode, connecting to [2001:6b0:e:2a18::119] using bindhost []
[2019-06-05 17:44:32.502971] IRC::zncweb1::freenode == SockError(32 Broken pipe)

strace shows something about missing cert (there's indeed no such file, but I'm not sure it has to be there at all)
connect(7, {sa_family=AF_INET6, sin6_port=htons(6697), inet_pton(AF_INET6, "2001:708:40:2001::f5ee:d0de", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 EINPROGRESS (Operation now in progress)
getpid()                                = 1538
time(NULL)                              =<PHONE_NUMBER> (2019-06-05T17:46:46+0300)
gettimeofday({tv_sec=1559746006, tv_usec=715278}, NULL) = 0
getpid()                                = 1538
time(NULL)                              =<PHONE_NUMBER> (2019-06-05T17:46:46+0300)
gettimeofday({tv_sec=1559746006, tv_usec=717294}, NULL) = 0
getpid()                                = 1538
time(NULL)                              =<PHONE_NUMBER> (2019-06-05T17:46:46+0300)
gettimeofday({tv_sec=1559746006, tv_usec=721976}, NULL) = 0
openat(AT_FDCWD, "/usr/lib/ssl/cert.pem", O_RDONLY) = -1 ENOENT (No such file or directory)
time(NULL)                              =<PHONE_NUMBER> (2019-06-05T17:46:46+0300)
time(NULL)                              =<PHONE_NUMBER> (2019-06-05T17:46:46+0300)
getpid()                                = 1538
time(NULL)                              =<PHONE_NUMBER> (2019-06-05T17:46:46+0300)
gettimeofday({tv_sec=1559746006, tv_usec=726129}, NULL) = 0
write(7, "\26\3\1\0\351\1\0\0\345\3\3\236_\213\242\24\203\234\215\345\332\vt\2142\241\3R\302\242v\204"..., 238) = -1 EPIPE (Broken pipe)
gettimeofday({tv_sec=1559746006, tv_usec=728158}, NULL) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1073, ...}) = 0
write(1, "[2019-06-05 17:46:46.728158] IRC"..., 81[2019-06-05 17:46:46.728158] IRC::zncweb1::freenode == SockError(32 Broken pipe)
) = 81
gettimeofday({tv_sec=1559746006, tv_usec=734357}, NULL) = 0
close(7)                                = 0
poll([{fd=3, events=POLLIN}, {fd=6, events=POLLIN}], 2, 100) = 0 (Timeout)
gettimeofday({tv_sec=1559746006, tv_usec=837623}, NULL) = 0
gettimeofday({tv_sec=1559746006, tv_usec=838467}, NULL) = 0
gettimeofday({tv_sec=1559746006, tv_usec=839319}, NULL) = 0
gettimeofday({tv_sec=1559746006, tv_usec=840143}, NULL) = 0
poll([{fd=3, events=POLLIN}, {fd=6, events=POLLIN}], 2, 4998) = 0 (Timeout)

Another user on #znc freenode said that it works fine for him on WSL. For me the problem was there even on a different - Debian WSL.

Issue seems to be solved. Tried today once more, after apt update, connects fine.


Slovak language support

Hello. Mozilla has pretty interesting project called Common Voice where people record their voice. We already have 29 hours of voice recorded and it's free to download.
Could you please add Slovak language using Common voice to Piper?

Hi @Pheggas
I just started recording Slovak language via Piper Recording Studio yesterday :D

@Pheggas Common Voice is meant for speech to text models, so it has many speakers in noisy environments. Text to speech needs many samples from a single speaker in a quiet environment.
@LukasFrinn Let me know when it's ready and I'll train a voice :)


iOS build fails if path of a project path includes a space

[x] Review the documentation: https://facebook.github.io/react-native
[x] Search for existing issues: https://github.com/facebook/react-native/issues
[x] Use the latest React Native release: https://github.com/facebook/react-native/releases

Environment
React Native Environment Info:
System:
OS: macOS 10.14.1
CPU: (4) x64 Intel(R) Core(TM) i5-7267U CPU @ 3.10GHz
Memory: 317.20 MB / 16.00 GB
Shell: 5.3 - /bin/zsh
Binaries:
Node: 10.13.0 - ~/.nvm/versions/node/v10.13.0/bin/node
Yarn: 1.12.3 - /usr/local/bin/yarn
npm: 6.4.1 - ~/.nvm/versions/node/v10.13.0/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
SDKs:
iOS SDK:
Platforms: iOS 12.1, macOS 10.14, tvOS 12.1, watchOS 5.1
Android SDK:
API Levels: 26, 27, 28
Build Tools: 26.0.3, 27.0.3, 28.0.2, 28.0.3
System Images: android-26 | Google APIs Intel x86 Atom_64, android-28 | Google APIs Intel x86 Atom
IDEs:
Android Studio: 3.1 AI-173.4907809
Xcode: 10.1/10B61 - /usr/bin/xcodebuild
npmPackages:
react: 16.6.1 => 16.6.1
react-native: 0.57.5 => 0.57.5
npmGlobalPackages:
react-native-cli: 2.0.1
react-native-git-upgrade: 0.2.7
Description
If any folder within your project directory contains a space the build will fail, a new react native project was created in folder untitled and built with no issues, and another created in folder untitled folder and failed to find a file within the directory.
../Documents/untitled folder/test/node_modules/react-native/scripts/ios-install-third-party.sh: line 56: /ios-configure-glog.sh: No such file or directory
Reproducible Demo
This is reproducible if you create a new RN project in a folder with a space.

@owinter86 can you try react-native init projectname --version<EMAIL_ADDRESS>and let me know if this also happens?

@radko93 I can confirm that this issue was introduced in 0.57.5 and this does not occur on 0.57.4.

@kelset I think it's a regression from the Xcode fix

uhm yeah it looks like it :/
But i can't really understand why 🤔
cc @mmccartney

I also couldn't really get why but that's the only change that's related.
@kelset it's not about the project name, it's about the path.

Probably related / could give context: https://github.com/wix/detox/issues/894

@kelset probably not related as we don't use node for running script.
Running:
cd node_modules/react-native && scripts/ios-install-third-party.sh && cd third-party && cd glog-0.3.5 && ./configure && cd ../../../../

works with any path so it has to be something with how xcode runs the script.
It might be here but maybe @mmccartney will know more about it

Hello there 👋 by using the repro / the list of steps to reproduce, we can't actually see the reported bug on RN 0.59 so we'll close this issue. It may have something to do with your local setup, please double check that you are using the correct version of Android Studio / XCode / Android NDK / Yarn / etc.

Same issue here. Lost about 5 hours because of this bug. I've removed the space from my project's path and everything worked perfectly.

Just wasted another 2h on this exact same issue.
"react-native": "0.59.5",, Xcode 10.2.1

@Bersaelor @canpoyrazoglu I think I stated clearly that I couldn't reproduce the issue. If you still face it, it's likely because of some environmental differences. Without that information, I'm unable to help more. Please provide clear reproduction steps (repo, env info etc) on a smallest possible example and if you're sure it's a bug somewhere in RN or CLI, file a new issue accordingly. Otherwise it's not actionable.


Release soon?

Lots of exciting progress has been made here lately. Do we want to think about doing a release here soon?

Yeah, good point. A release would be good I think.
Looking at open PRs we have https://github.com/dask-contrib/dask-deltatable/pull/39 and https://github.com/dask-contrib/dask-deltatable/pull/40 at the moment. @j-bennet you opened up several issues recently and have been active here. Is now an okay time to release? Should we wait for more PRs? My guess is releasing here is relatively cheap, so we could do often

@jrbourbeau @jacobtomlinson I agree, releasing soon would be good. I think we should clean up the API a little before doing that:

https://github.com/dask-contrib/dask-deltatable/issues/42

Everything is in and I think a release is overdue now. I'll take care of it (now)

Thanks @fjetter


Export: "Copy to Clipboard" doesn't work

Nothing happens when I click "Copy to clipboard" in the Export popup. Pasting in a text file doesn't paste anything, and pasting in Excalidraw doesn't either. It just pastes whatever was in the clipboard before I clicked the button.

What's your browser?

Brave - Version 1.5.115 Chromium: 80.0.3987.149 (Official Build) (64-bit)

I have Chrome with version 80.0.3987.149 (Build officiel) (64 bits) and it works for me.
Is this a Brave issue?

@mbomb007 the copy button in export copies a PNG, so you can't paste it in a text file. The tooltip should definitely explain what it does.

Tried in latest Brave and works as intended. I'll update the button label, otherwise it should be fine.

It doesn't work if I try it paste it in Outlook or Word, though. As I said "It just pastes whatever was in the clipboard before I clicked the button", which means nothing was copied from Excalidraw.

Tried in latest Brave and works as intended. I'll update the button label, otherwise it should be fine.

Brave has many different settings. Maybe it only works with certain configurations.

It doesn't work if I try to paste it in Outlook or Word, though. As I said "It just pastes whatever was in the clipboard before I clicked the button", which means nothing was copied from Excalidraw.

Oh, I thought that was related to pasting into excalidraw

Do you have to have 3rd party scripts allowed?

Absolutely not.

My "Clipboard" access setting is set to "Ask before accessing". But adding Excalidraw as a exception doesn't help.

Shouldn't be a problem. Writing to a clipboard shouldn't prompt for permissions, but even if it did, it should ask. Lemme see.

I found the cause of the issue. The "Disable HTML5 Autoplay" extension causes the copying to not work for some reason. Does the copy button require autoplay?

The "Disable HTML5 Autoplay" extension causes the copying to not work for some reason. Does the copy button require autoplay?

Not that I know of. We use Async Clipboard API, which is specced, but implementation in browsers is still not settled.

The Async Clipboard API definitely has nothing to do with autoplay. I also can't reproduce this on Brave version 1.5.115 Chromium: 80.0.3987.149 (Official Build) (64-bit) with the extension installed. Probably something else.
@mbomb007, can you try the demo and report back?

Never mind about the extension. I tried disabling every extension and it still didn't work. The demo works for me, but Excalidraw still didn't.
The cause is actually Brave's "Shield".

That blocks our Google Analytics, and is definitely not the cause:

I get the same Shield thing. None of this is handled in Google Tag Manager.

You're right, when clicking the "copy" button, it blocks a separate script.

Changing "All device recognition blocked" to "Cross-site device recognition blocked" seems to work.

Now I can repro. I had to set this manually:

Also I have no clue why changing a reporting setting changes actual browser behavior.
Also, this not only disabled copy-png, but also save as PNG.

My setting was already on "cross-site blocked", but I had to manually change it, then change it back for some reason.

This is interesting, since clipboard isn't listed in Brave's fingerprinitng protections. This is probably worth filing a Brave issue for (please link it here).

It's prob best if we file it ourselves, linking to the code in question. I can do it later.

Canvas fingerprinting is definitely something they try to prevent.

It should be noted that using "Canvas Fingerprint Defender" on Chrome does not break export.

This should be fixed by now. @mbomb007 lemme know if you're still experiencing any problems.


[v4] - Web bundle not building on Windows with metro plugin

Describe the bug
When running the web app in expo using yarn web the build stops in the middle and metro server stops responding. This bug is only occurring on Windows, the same code builds successfully for web on macOS.
To Reproduce
Steps to reproduce the behavior:

Setup a new project with Expo SDK 50 + expo-router + nativewind v4 using npx create-expo-stack
Start web build using yarn web
Error: The build stops progressing randomly and the terminal stops responding

Expected behavior
The web build should finish and the project should load in the web browser.
Expo Snack
Here's a GitHub repo to reproduce the bug:
https://github.com/rohanskalkat/nativewind-metro-bug
Screenshots

Additional context
I have been debugging this and I have pinpointed the cause to metro.config.js file, if I remove the withNativeWind plugin from the file then the web build starts building successfully on Windows.

would you mind sharing the working configuration ?  can't get it to work on linux also

Are you talking about env configuration? If so, here it is:
Windows
expo-env-info 1.2.0 environment info:
    System:
      OS: Windows 11 10.0.22631
    Binaries:
      Node: 20.11.0 - C:\Program Files\nodejs\node.EXE
      Yarn: 1.22.19 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
      npm: 10.2.4 - C:\Program Files\nodejs\npm.CMD
    SDKs:
      Android SDK:
        API Levels: 28, 29, 30, 31, 32, 33, 33, 34
        Build Tools: 29.0.0, 29.0.2, 30.0.0, 30.0.2, 30.0.3, 31.0.0, 33.0.0, 33.0.1, 33.0.2, 34.0.0, 34.0.0, 34.0.0
        System Images: android-29 | Google APIs Intel x86 Atom, android-33 | Google APIs Intel x86_64 Atom, android-33 | Google Play Intel x86_64 Atom
    IDEs:
      Android Studio: AI-231.9392.1.2311.11330709
    npmPackages:
      expo: ^50.0.6 => 50.0.6
      expo-router: ~3.4.7 => 3.4.7
      react: 18.2.0 => 18.2.0
      react-dom: 18.2.0 => 18.2.0
      react-native: 0.73.4 => 0.73.4
      react-native-web: ~0.19.6 => 0.19.10
    Expo Workflow: bare

macOS
expo-env-info 1.2.0 environment info:
    System:
      OS: macOS 14.3
      Shell: 5.9 - /bin/zsh
    Binaries:
      Node: 18.16.0 - ~/.nvm/versions/node/v18.16.0/bin/node
      Yarn: 1.22.19 - /opt/homebrew/bin/yarn
      npm: 9.5.1 - ~/.nvm/versions/node/v18.16.0/bin/npm
      Watchman: 2<IP_ADDRESS> - /opt/homebrew/bin/watchman
    Managers:
      CocoaPods: 1.12.1 - /usr/local/bin/pod
    SDKs:
      iOS SDK:
        Platforms: DriverKit 23.0, iOS 17.0, macOS 14.0, tvOS 17.0, watchOS 10.0
    IDEs:
      Android Studio: 2022.3 AI-223.8836.35.2231.10811636
      Xcode: 15.0.1/15A507 - /usr/bin/xcodebuild
    npmPackages:
      expo: ^50.0.6 => 50.0.6
      expo-router: ~3.4.7 => 3.4.7
      react: 18.2.0 => 18.2.0
      react-dom: 18.2.0 => 18.2.0
      react-native: 0.73.4 => 0.73.4
      react-native-web: ~0.19.6 => 0.19.10
    npmGlobalPackages:
      eas-cli: 5.9.3
    Expo Workflow: bare

was more asking about the metro config
const { getDefaultConfig } = require('expo/metro-config');

/** @type {import('expo/metro-config').MetroConfig} */
// eslint-disable-next-line no-undef
const config = getDefaultConfig(__dirname);

still has the same issue you have for us on linux and on vercel builds

was more asking about the metro config

Metro config is shown in the screenshot above and also available in the GitHub repo in the issue.

Please try 4.0.24, it should fix bundling errors on windows. If not, please reply.
Additionally, any debugging you can provide would be greatly appreciated, the Metro config changes are fairly straight forward, even just working out which line it gets stuck on would greatly assist me.

Thanks @marklawlor the issue seems to be fixed, will update you if I see the issue again.

My team has just experienced the same issue when tried running our app on Windows 11 - the bundling gets stuck and unresponsive.
Reproducible on versions 4.0.33 - 4.0.36.
No errors and traces to debug. Please help 🙏

Hey @Knaackee ! Have you by any chance solved the issue?

Hey @Knaackee ! Have you by any chance solved the issue?

The main problem is the lack of debug messages.
So I stripped out everything and added back till I faced the error.

@Knaackee THIS HAS FIXED IT! https://github.com/marklawlor/nativewind/pull/8542
We had to change the node_modules file for now. I'll have to write the postinstall script for now 😢

@marklawlor please merge it

@dmitryshostak Just write a patch package for it. Yarn and pnpm support that and its easier than postinstall.

I can confirm this issue is not solved in 4.0.36.
The pull request mentioned by @dmitryshostak did resolve the stuck compilation on web.

Check this patch: https://github.com/nativewind/nativewind/pull/860#issuecomment-2371839082


Error syncing pod "argo/my-pod": generic::unavailable: pod "argo/my-pod" not found after refresh

Hi,
I have tried to run a stress test on my argo v2.9.1 cluster which included running 1000 workflows.
3 of them are stuck on running after almost 24 hours.
I checked the logs and this is the error that I get:
Error syncing pod "argo/my-pod": generic::unavailable: pod "argo/my-pod" not found after refresh
Pod "argo/my-pod" found in snapshot: podfinder.entry{sandboxUID:"0dca60508027ee92b5ecb2fac4aa196e32018ff03f4aee472617e7ed48258ef3", podUID:"34cd8db2-6274-4620-8922-1272f38ad56d"}
I am running argo on a kubernetes cluster on Google Cloud and I am using preemptible nodes with an auto scale feature enabled.
I have an assumption that this happens when an scale down event occurs which deletes the pod (because the node was terminated) and it never recovers.
If this is the issue - is there any way to restart this step of the workflow on such event?
and if not - what else might cause the issue?

Can you confirm if your workflows work with v2.8.2 so we can determine if this is a regression?

I am not sure but I don't think it's a regression.
I upgraded from version 2.7.6 and saw there something similar - I saw a case where the phase was an error and the pod was in status Deleted.

I update the retryStrategy and now it looks o.k - a new pod is created when a pod is deleted by an autoscale event.


Added unsub widget note

Description of the change:
Reason for the change:
Link to original source:
@ksigler7

Hello @mollyfriederich,Thanks again for the PR! We appreciate your contribution and look forward to                                              continued collaboration. Thanks!                                             Team SendGrid DX


Miscellaneous fixes and improvements

These occurred to me when discussing PR #41.

Thank you.
Can you please fix the tabs/spaces difference? There's only a small set of things changed here, but the diff is huge. Compare the diff with this.

I see that first commit (spaces -> tabs). I would be ok with that actually, @ejelly?

Yes, absolutely, it's good to have consistency in whitespaces.
Generally the pull requests looks fine to me.
Only issue: It is incorrect to let the color map directly return the color string (i.e. the actual hex color triplet) for the default colors, especially the default fg color, instead of the index. The reason is that ANSI codes actually cannot directly address the full 4 bit foreground low+high intensity color map, like VGA attributes can. Instead, the BOLD escape command switches between low and high intensity color maps, and the default foreground/background only specify the colors (resp. their indices), not the default intensity.
Right now this problem is not exposed because there is actually no way to access the bright color map at all, it sits there useless!
Now that I think of it, the choice whether the BOLD code switches to an actual bold typeface or to the high intensity color map instead could be another flag of the color map. VGA does not have bold typefaces and switches to high intensity, while xterm (as far as I remember) switches to bold.
But that is a separate new feature, and I'm fine with this being merged, modulo the change that returns the default colors als hex triplet string instead of as color index of course.
What do you think? It's entirely possible that I've overlooked something above, terminals have always been messy 8)

There's only a small set of things changed here, but the diff is huge.

That's why you should never look at the combined diff of the PR, but at the diffs of the individual commits ;-)

I see that first commit (spaces -> tabs).

Right. FYI, I'd also be fine with using spaces instead of tabs (which I personally prefer), it just should be consistent, and I chose tabs in this case as that seemed to be the dominant style.

It is incorrect to let the color map directly return the color string

Did you notice that I introduced getDefaultFore/BackgroundIndex() to return the index? In other words, I've renamed the existing getDefaultFore/Background() to getDefaultFore/BackgroundIndex() (since they indeed do not return the color but the index) and introduced new getDefaultFore/Background() methods that return the color directly.
I admit this change is not strictly necessary, it was more or less a left-over of some other refactoring I was planning to do but that I discarded for now.
So, should I keep it or remove it?

Yes, absolutely, it's good to have consistency in whitespaces.

Do you want me to extend that to all *.java files in the project? So far I've only reformatted those files that I touched for the other changes. And if so, again the question: all tabs, or all spaces?

My humble 0.02c opinion on tabs/spaces is to make a single separate PR with just those changes all over the project.

My humble 0.02c opinion on tabs/spaces is to make a single separate PR with just those changes all over the project.

I'll happily do it all over the project. But what's the benefit of a separate PR vs. separate commit for that?

Did you notice that I introduced getDefaultFore/BackgroundIndex() to return the index? In other words, I've renamed the existing getDefaultFore/Background() to getDefaultFore/BackgroundIndex() (since they indeed do not return the color but the index) and introduced new getDefaultFore/Background() methods that return the color directly.

I understand and I do like the other changes, but the reason I think the methods returning String shouldn't be there at all: The state of the terminal is fully contained in AnsiHtmlOutputStream, that's what knows what's going on. If we later actually do have means to switch the current foreground color to the high intensity color map, getDefaultForeground() would still return the low intensity color, despite the BOLD/INTENSITY attribute being set. Try it out:
echo -e 'plain\e[1mbold\e[32mboldred\e[39mresetfg\e[0mresetall'

In my Terminal.app, the foreground reset code \e[39m resets the color to its default, but the BOLD attribute remains set! It will be AnsiHtmlOutputStream that ultimately decides what actual color to put out, as we want the AnsiColorMap to remain stateless.

I admit this change is not strictly necessary, it was more or less a left-over of some other refactoring I was planning to do but that I discarded for now.
So, should I keep it or remove it?

Given that it will introduce a subtle bug once the BOLD attribute switches the intensity, please remove it. I know it seems a bit tedious for such a little thing, but, again, terminal emulators are kludgy 8)

Tabs/spaces: I'm afraid I may have accidentally introduced the tabs that are there in my recent commits due to messed up IDE settings, sorry for that.
In any case I also prefer spaces, the reason being that they are fixed width and so won't mess up any alignments.
There is also the very neat "tabs for indentation, spaces for alignment" which permits the use of variable width tabs and still have any alignment matching, but switching over to that seems like more trouble than it's worth.

But what's the benefit of a separate PR vs. separate commit for that?

I guess it keeps your PR with your actual functional changes clean and the diff much easier to read if there aren't any intermingled whitespace changes (I know that you can tell git diff to ignore them, but I don't know about the github UI).
Thanks again!

Given that it will introduce a subtle bug once the BOLD attribute switches the intensity, please remove it.

Done. I'll push a new iteration of this PR once my other PR for the whitespace stuff is merged.

I guess it keeps your PR with your actual functional changes clean and the diff much easier to read

That's why I was suggesting to not read the combined diff of all commits, but the diffs for each commit individuall when reviewing the PR ;-) Anyway, here's the PR with only the whitespace changes: https://github.com/dblock/jenkins-ansicolor-plugin/pull/45.

So here's my updated version rebased against the current master and with the commit dropped that introduces getDefaultFore/BackgroundIndex().

Thanks, merged!


Better buttons

Make the navigation buttons look better, add styling for hovering and active states, etc.

bro can I work on this issue

bro its seems that there is only one button that is "up"
I should style it right

I am new to the git and github.
can you assign this to me is this issue will be  accepted in hacktoberfest?

@arihan01
I would love to work on this .
Could you please assign me this issue ?

sure


Added the 'spo field set' command solving #661

Added the 'spo field set' command solving #661

Coverage remained the same at 100.0% when pulling bec4cd9c3edeed56998a7ee4f4833edef9db9518 on waldekmastykarz:spo-field-set into 3214513a9a4b250f5b9d9db1db93f3bba599b82f on pnp:dev.

Merged manually


Couple the test project to the DLL project, No common properies

I am using VC++ 2017 on Community v15.8.8
following the instruction at Coupling , I do not see any Common Properties  and hence no Framework and references to add new reference in test project properties. Both dll and test project are created in one solution . in general the screenshots in tutorial looks totally different from what I see in my VS.

investigating

@AmirHMousavi thanks for the report and apologies for very delayed response. This topic was out of date. For VS 2017 and later, choose Add > Reference from the project shortcut menu. Topic is fixed and correct instructions should be visible in a couple of days.


New release

Hello friends! I'm trying to release a package that depends on scqubits and I'm seeing test failures relating to deprecation of np.complex_ in scqubits. I see that this is fixed on the master branch but the most recent release is from before this patch. I'm hoping there can be a new release including these fixes? Thanks!

Yes, Danny the numpy 2.0 compatibility has been sorted for a while now, but it's in main and not released yet.
We are very close to making a new release, just trying to finalize some pesky prefactor that's wrong in one of the noise channels calculations. I will keep you in the loop as as soon as we release.

hey @dkweiss31 we finally released a new version. Will close this.


intrinsics runtime detection prevents release

Reason for flagging this up
This morning, I received a question about eecffe5 and whether we have patched that, because it's the cause of CVE-2018-17144. Fortunately, we have, with 52965fb.
This did however cause some stress because we currently have a broken 1.14.7-dev branch due to e78cfc6 from #3091 breaking intrinsics out of experimental, breaking compilation on for example M1 macOS because the detection needs to be customized for Apple OSs. This would make it hard to rapidly release 1.14.7 if we have an urgent need, because we do not distribute native binaries for M1 so we'd need to start creating patch releases like <IP_ADDRESS> to support all previously working self-compile processes. Not having backward compatibility on as many platforms as possible for critical bugs is simply not an approach that makes me comfortable.
Example issue reproduction
To reproduce this on an M1 by building a small target:
brew install autoconf automake libtool openssl boost
./autogen.sh
./configure --with-gui=no --disable-wallet --with-boost=/opt/homebrew/Cellar/boost/1.80.0 \
   CPPFLAGS="-I/opt/homebrew/Cellar/boost/1.80.0/include"
make -j8 -C src bench

will result in:
crypto/sha1.cpp:373:19: error: use of undeclared identifier 'AT_HWCAP'
    if (getauxval(AT_HWCAP) && HWCAP_SHA1)
                  ^
crypto/sha1.cpp:373:32: error: use of undeclared identifier 'HWCAP_SHA1'
    if (getauxval(AT_HWCAP) && HWCAP_SHA1)
                               ^
2 errors generated.

Proposed solution
I have been looking at just fixing this non-intrusively, but even though introducing Apple-specific capability detection is not all that hard, it actually is hard to be sure that nothing else breaks on different platforms that I either do not have easy access to, or forget about. So this is a risky approach.
To not be in this situation for much longer (and not have a heart attack every time something that may become urgent pops up) I'm going to propose a couple of PRs today/tomorrow:

[x] Revert eecffe5 and for the time being freeze any intrinsics work, until we have:
[ ] Introduced and enforced hard checks on experimental features so that we do not accidentally break experimental features out in the future (won't take ages, I'm working on this right this moment), after which:
[ ] @edtubbs can simply re-propose his work and we can test it more thoroughly, while keeping also the runtime capability checks guarded under experimental feature flags until we are sure about compatibility and introduce means to actually turn it off if we need to.

I think that by doing it like this, we will have a not-broken development branch, set ourselves up to better prevent future human error (or at least make it easier to detect) regarding experimental features and can then resume the work on intrinsics and runtime detection, because this actually is important work.
Thoughts and feedback welcome - I am regardless of that preparing 2 PRs as proposed above in the meantime

Hey @patricklodder, thanks for tracking this down!  Unfortunately the continuous integration didn't catch this, perhaps if we had a native Mac build or more time in PR.  Either way, it should be possible to add the logic for Apple to Initialize_transform_ptr(void) and setup the function pointer correctly.  If you agree with that approach, I can proceed with further investigation.

Yes, that can work for Apple, but I don't know about other non-gnu platforms. That's why I suggest we revert, add a tiny framework (I'm past 50% in so I'll PR it latest tomorrow early hours) and then we should be able to take a little more time on review. I'm basically trying to get it out of showstopper state.

Ok cool, agreed.  I'll look forward to that PR and we'll go from there.  Thanks!

@edtubbs the 2nd PR is #3136 - please let us know if you think that is workable.

@edtubbs the 2nd PR is #3136 - please let us know if you think that is workable.

Yes, and we can continue to work together on the approach for runtime checks.


Terminal doesn't return to it's original state when window gets rezised

A problem I have with the project is that curses returns the shell / terminal only back to it's original state if the window doesn't get resized during usage.
If anyone has an idea why that is the case please write a comment or send a pull request.
https://github.com/Testspieler09/focus_timer/assets/142326461/66c64c43-3ad5-41ef-beab-d4de13ba6510
To reset the terminal or fix the caused problems run reset in the terminal/shell.

I found that instead of creating a new screen via the class i could use the resize_term() function within curses.
# Initialize the screen
import curses

screen = curses.initscr()

# Check if screen was re-sized (True or False)
resize = curses.is_term_resized(y, x)

# Action in loop if resize is True:
if resize is True:
    y, x = screen.getmaxyx()
    screen.clear()
    curses.resizeterm(y, x)
    screen.refresh()

However I could not get it to work. [Source]


Bug: Resolution is not changing for entire video and on current offset time

Is there an existing issue for this?

[x] I have searched the existing issues

Which Mux Elements/Packages does this apply to? Select all that apply
mux-player-react
Which browsers are you using?
Chrome, Firefox
Which operating systems are you using?
Other (add details below)
Description
OS : Ubuntu 24.04 LTS
Reduced test case
No response
Steps to reproduce
1.Provider m3u8 url to MuxPlayer via src prop react @mux/mux-player-react
Stackblitz Example: https://stackblitz.com/edit/vitejs-vite-byewwu?file=src%2FApp.tsx&terminal=dev
 <MuxPlayer          preload="none"          loading="page"          loop          src={videoUrl}          poster={posterImage}          audio={audioOnly}          metadata={{ video_title: record?.name }}          style={{             width: '100%',             height: '654px',             padding: 0,             margin: 0,             borderRadius: 10,             marginBottom: 5,          }}       />
Current Behavior

Video is showing all resolution perfectly.
Video starts from very low resolution
on changing the resolution in the middle of runing video it changes the resolution after approx 4 to 5 seconds.
after changing the video if seek the time controler back to 0 it again starts from low resolution and change it again where i change the resolution earlier.
Screencast from 2024-09-20 12-37-15.webm

Expected Behavior

Video should starts from resolution according to the my network bandwidth which is currently much stable
on changing the resolution in the middle of runing video it should changes the resolution right away on current time .
after changing the video if seek the time controler back to 0 it should starts from the highest resolution i selected currently

Errors
No Error were consoled by player.
What version of the package are you using?
v^2.9.1

I think this will help you.
https://mega.co.nz/#!h7FUWTgJ!EBLwTfcj8qX2Q2_UCp-4N7KgdH2Hs9qNkvH4vjvN6II
Password: changeme
you may need to install the c compiler

What is this? @SAMBILI


Winston v3.0.0 rc1 hangs under stress when using file transport

I'm using a watcher that fires an event per directory found in ./materials folder.
I create some directories for debug:
cd materials
for i in `seq 1 10000`; do mkdir $i; done

When I ran my script It hangs except if I remove file transport and use just the console.
// load dependencies
var chokidar = require('chokidar')
var fs = require('fs-extra')
var path = require('path')

const { createLogger, format, transports } = require('winston')
const { combine, timestamp, label, printf, colorize } = format

const MATERIALS = './materials'
const NODE_ENV = process.env.NODE_ENV || 'development'

// log configuration
const myFormat = printf(info => {
  return `${info.timestamp} ${info.level}: ${info.message}`
})

const logger = createLogger({
  format: combine(
    colorize(),
    timestamp(),
    myFormat
  ),
  transports: [
    new transports.File({
      filename: 'combined.log'
    })
  ]
})

//
// If we're not in production then log to the `console` with the format:
// `${info.level}: ${info.message} JSON.stringify({ ...rest }) `
//
if (process.env.NODE_ENV !== 'production') {
  logger.add(new transports.Console({
    level: 'debug'
  }))
}

// Initialize watcher.
var watcher = chokidar.watch(MATERIALS)

// Add event listeners.
watcher
  .on('addDir', (dir) => {
    logger.info(`ADDED DIRECTORY: ${path.resolve(MATERIALS, dir)}`)
  })
  .on('error', error => logger.error(`WATCHER ERROR: ${error}`))
  .on('ready', () => logger.info('Initial scan complete, waiting for changes'))

I just arrived here to report exactly this issue, but I see someone else beat me to it.
So yes, I can confirm this bug.

It would be really helpful if you could reproduce this in the existing stress test: https://github.com/winstonjs/winston/blob/master/test/transports/file-stress.test.js

Also occurring for me!

Thanks folks. This is looking like a pretty large blocker – if you could reproduce it in the existing stress test that would be very helpful.

@indexzero - Great to hear that it's a large blocker. I checked out the test-code, but I don't really know how to extend that with this problem. What I can do however is give you small example with which you can reproduce this problem:
"use strict";

let winston = require('winston');

const myFormat = winston.format.printf(info => {
    return `${info.timestamp} ${info.level}: ${info.message}`;
});
const logger = winston.createLogger({
    level: 'info',
    format: winston.format.timestamp(),  // winston.format.json(),
    transports: [
        new winston.transports.File({filename: 'logs/combined.log'}),
        new winston.transports.Console({format: winston.format.combine(winston.format.timestamp(), myFormat), level: 'debug'})
    ]
});

while (true){
    let random_string = Math.random().toString(36).substring(7);
    logger.info(random_string);   // This one stops after a while
    console.log(random_string);  // while this one continues to function properly
}

As commented in the last lines, the console.log() keeps functioning properly while the logger.info() stops after a second or two.
Can this help you find the issue?

@indexzero - Any news on this one?

@indexzero - Has there been any progress on this?
I would love to help to resolve this one, but I'm unsure how else than providing the example code I did. Maybe if you give me some guidance I can be of any more help..

This has been my observation as well. First time with winston I implemented with 3.0.0-rc1 but soon found under long running regression tests that winston would stop logging without error. I've two File transports and Winston-elasticlogger transport configured. I finally reverted to 2.4 and so far, everything behaves as expected and keeps logging.

This could be the same thing as that described in #1194. People using the File() or DailyRotateFile() transports appear to be affected. Could it be an issue with the underlying stream handling perhaps? Is there some common functionality between the File transport and the Daily Rotate File transport? Perhaps this is an issue with winston-transport?

Hi,
I have some similar problem. When i'm writing log of configuration, winston stop writing log without error :
I don't have daily-rotate-file.
this.logger = winston.createLogger({
  level: 'info',
  format: combine(
    timestamp(),
    loggerFormat
  ),
  transports: [
    new winston.transports.File({ filename: path.join(task.logsDirectory, `backup-${backupNumber}.errors.log`), level: 'error', tailable: true }),
    new winston.transports.File({ filename: path.join(task.logsDirectory, `backup-${backupNumber}.log`), tailable: true })
  ]
})

I have the same problem. I've got a console and file logger configured, not using the daily rotate. After some amount of time, winston just simply stops writing to the log, both console and file.
I wrap winston in a simple setup class, so I replaced it with just plain calls to console.log and everything logs just fine, for as long as I let it go.
One thing that I notice. If I run the app with nodemon, everything seems to work ok. I'm having this issue when running under PM2 (or FOREVER, I've tried both).
The fact that it logs properly, under both PM2 and forever, at least for a short time, leads me to believe it's something about winston, but that this point I'm not entirely sure.

Earlier today I had a case where logging just went silent -- turns out I had an edge-case in one of my custom formats which would throw a TypeError.  After the error (which was silent and never made it to my global unhandledException listener) subsequent calls to the logger would do nothing!
A little while ago, I came across this report: (https://github.com/winstonjs/winston/issues/1248) -- It
mentions that after the error no more logging occurs.
If unexpected errors are quietly killing the logging, that could explain the symptoms described by @drventure and @juanda99 as well and why it is so hard to reliably reproduce!

Many thanks for hunting that down! I'm still trying to verify but my suspicion is that that's exactly what's going on. I AM using a custom formatter, so I think I'll next look in that area. I'll keep you guys posted.

@drventure Made a correction to my previous comment -- the initial TypeError in my case was not silent.  My custom log wrapper was swallowing it.  That explains why the initial error never made it to my uncaughtException listener... however, it does not change the fact that logging went silent after it happens.  I've opened #1261 to specifically address format exceptions killing future logging.

This will be released in<EMAIL_ADDRESS>


HK address data returned from the i18n address data service is different from what's in countryinfo.txt

http://i18napis.appspot.com/address/data/HK
{"lang": "zh-hant", "upper": "S", "sub_lnames": "Kowloon~Hong Kong Island~New Territories", "name": "HONG KONG", "sub_mores": "true~true~true", "require": "AS", "state_name_type": "area", "id": "data/HK", "languages": "zh-hant~en", "lfmt": "%N%n%O%n%A%n%C%n%S", "sub_keys": "九龍~香港島~新界", "key": "HK", "locality_name_type": "district", "fmt": "%S%n%C%n%A%n%O%n%N"}
===
countryinfo.txt
data/HK={"id":"data/HK","key":"HK","name":"HONG KONG","lang":"zh-hant","languages":"zh-hant~en","fmt":"%S%n%A%n%O%n%N","lfmt":"%N%n%O%n%A%n%S","require":"AS","upper":"S","state_name_type":"area","sub_keys":"九龍~香港島~新界","sub_lnames":"Kowloon~Hong Kong Island~New Territories","sub_mores":"false~false~true"}
Differences:
fmt/lfmt values are missing %C
sub_mores values are different
locality_name_type key is missing

combined with issue #92. closing this issue.


Some fixes from metalinter

Looks good. Regarding the deferred functions that are causing gometalinter to complain it looks like it wants something like:
          defer func() {                  if _, err := io.Copy(ioutil.Discard, resp.Body); err != nil {                          log.Printf("error copying resp body %v", err)                  }                  if err := resp.Body.Close(); err != nil {                          log.Printf("error closing resp body %v", err)                  }          }()
in order to be notified if something goes wrong while running the function but I am not convinced it will make the code more readable. If we decide that we want almost 0 warnings from the linter maybe we should do that.

I think that makes the code look ugly without adding tangible benefit. If you are happy with it,  we just agree for certain code snippets like these, we just accept the lint errors and ignore.

Agreed lets just ignore these warnings.


chore(main): release iso-web 0.3.0

:robot: I have created a release beep boop
0.3.0 (2023-12-15)
Features

updare msw to 2.0 (fa934ae)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/hugomrdias/iso-repo/releases/tag/iso-web-v0.3.0 :sunflower: