text:
Add CM support for private configuration for rclone

We had to remove configs with private keys from the CM get-rclone script.
We need to add proper support to handle such private keys. We can use the new CM cfg automation or create a "get-rclone-config" script.
TBD: should brainstorm more.

Hi @arjunsuresh . I didn't manage to merge private key for get-rclone for MLCommons datasets (even though it seems to be "public") - GitHub refused a commit. We should either find a workaround to push it back or create a script to register them locally without pushing to Git ...


text:
buffer write is so slow

Hello authors,
I’ve noticed that most of the time spent running ray_processing/tokenize_shuffle.py is during the buffer write process, while the tokenization itself is relatively fast. Do you have any suggestions for reducing the runtime? I attempted to increase --num_writers_per_node, but it didn’t result in a significant performance improvement.

This is a known issue and the only significant speed up is turning on imbalanced write. You can also try using rust tokenize shuffle on a single node (https://github.com/revbucket/tokshuf-rust).

source: gharchive/issue

authors: Yu-Shi afang-story

repo: mlfoundations/dclm

license: MIT

license_type: permissive

license_source: github-api


text:
'Quiter' logging?

Hey there, just came to ask if theirs an easy way to limit the logging in the console, it's a little verbose for my tastes and most of it has nothing to do with my tests!
Thanks for the great plug-in,
Ben

I'm not sure which output you'd like suppressed, but if you give an example I can probably take a look.
Closing this for now since the issue is so old. Let me know and I'll reopen if necessary

repo: mllrsohn/gulp-protractor

license: mit

license_source: bigquery


text:
[inference] clarify the number of outstanding queries allowed.

My understanding is that:
Single Stream: 1 outstanding queries allowed
Multi Stream: 1 outstanding queries allowed
Server: X outstanding queries allowed with X as the total number of queries
Offline: there is only 1 query sent in total so not applicable.  @briandersn

This matches my understanding. There was a proposed liberalization for Multi-Stream, but it didn't seem like there as a lot of enthusiasm for it in the WG.


text:
Update training_rules.adoc

Proposed language to specify that optimizers must conform to the approved equations provided in the "MLPerf optimizers review" document (for CLOSED only).

I'd suggest we add the content of the optimizer doc as an appendix and drop the for v0.7 tag. Separate docs and version limitations cause trouble. :-)

Sure – I’m not quite sure the best way to organize within the document.
Happy to modify my PR accordingly.
From: Peter Mattson notifications@github.com
Sent: Friday, November 22, 2019 2:00 PM
To: mlperf/training_policies training_policies@noreply.github.com
Cc: Jonathan Cohen JOCOHEN@nvidia.com; Author author@noreply.github.com
Subject: Re: [mlperf/training_policies] Update training_rules.adoc (#264)
I'd suggest we add the content of the optimizer doc as an appendix and drop the for v0.7 tag. Separate docs and version limitations cause trouble. :-)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/mlperf/training_policies/pull/264?email_source=notifications&email_token=AMWGKDRPXL4AU2HBLQL7KHTQVBI53A5CNFSM4JP2C3ZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE67YDY#issuecomment-557710351, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AMWGKDWJZJBDAMZVESX2TZDQVBI53ANCNFSM4JP2C3ZA.

This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.

I'd just create a new appendix at the end for the optimizer info, and cite
the appendix in the main text.
On Fri, Nov 22, 2019 at 2:32 PM jonathan-cohen-nvidia <
notifications@github.com> wrote:

Sure – I’m not quite sure the best way to organize within the document.
Happy to modify my PR accordingly.
From: Peter Mattson notifications@github.com
Sent: Friday, November 22, 2019 2:00 PM
To: mlperf/training_policies training_policies@noreply.github.com
Cc: Jonathan Cohen JOCOHEN@nvidia.com; Author author@noreply.github.com
Subject: Re: [mlperf/training_policies] Update training_rules.adoc (#264)
I'd suggest we add the content of the optimizer doc as an appendix and
drop the for v0.7 tag. Separate docs and version limitations cause trouble.
:-)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<
https://github.com/mlperf/training_policies/pull/264?email_source=notifications&email_token=AMWGKDRPXL4AU2HBLQL7KHTQVBI53A5CNFSM4JP2C3ZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE67YDY#issuecomment-557710351>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/AMWGKDWJZJBDAMZVESX2TZDQVBI53ANCNFSM4JP2C3ZA>.

This email message is for the sole use of the intended recipient(s) and
may contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/mlperf/training_policies/pull/264?email_source=notifications&email_token=AIIVUHPQSS6NAPGKMMIJLG3QVBMWXA5CNFSM4JP2C3ZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE7B2SQ#issuecomment-557718858,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIIVUHNBULBLBU2XJQCSIWLQVBMWXANCNFSM4JP2C3ZA
.

source: gharchive/pull-request

authors: jonathan-cohen-nvidia petermattson


text:
Change width of feature_rows

[X] This is a question about using the theme.
[ ] I believe this to be a bug with the theme --- not Jekyll, GitHub Pages or one of the bundled plugins.
[ ] This is a feature request.
[ ] I have updated all gems with bundle update.
[ ] I have tested locally with bundle exec jekyll build.

Environment informations

Minimal Mistakes version: 3.3.7
github-pages version: 89 (haven't build locally yet)

Expected behavior
First of all let me thank you for this awesome template and great guide. I am playing around with customising the landing page, and I am trying to use your index.md file from gh-pages. I want to have two columns of text and I have used feature_row: for this, but I can't change the widths of these. The two columns are named Research and Recent posts on https://jonbra.github.io/
Steps to reproduce the behavior
https://github.com/jonbra/jonbra.github.io
https://jonbra.github.io/

To do this you'll need to modify the stylesheet slightly. Currently .feature__item's are laid out in 3 columns. If you change this line
@include gallery(4 of 12)

to @include gallery(6 of 12) they'll fill 50% of the parent container and appear as 2 columns.
It looks like you're on a slightly older version of the theme so it might be more work for you to update the stylesheet. You'll need to edit the _scss partial and then rebuild main.css using npm run build:css. Archived instructions here.
The current version of the theme using native Sass/SCSS preprocessing so you just have to edit the file and Jekyll/GitHub Pages takes care of the rest.

Thanks for the prompt reply!
Sorry if this is a very basic question, but is it possible to upgrade to the latest version of the theme using GitHub? I currently don't have the right access to run bundle install etc. on my computer so I can't install the theme locally.  I only have Git installed.

Not easily. Other than going through the most recent commits to the theme and editing your repo to match, it could be pretty painful.
Even if you can do things locally it's not the easiest thing as you'll have to pull down the theme's repo and manage some merge conflicts.
Jekyll just rolled out support for gem themes which will make all of this infinitely easier. You'll just add theme: theme-name in your Jekyll config and won't have to worry about managing outdated layouts, stylesheets, includes, etc.
I'll eventually be rebuilding the theme to support this, but waiting on a few things first:

GitHub Pages to support Jekyll 3.2... coming August 23rd
Jekyll themes to be updated to support bundling Javascript and other assets

I see. Thanks for giving such detailed answers.

authors: jonbra mmistakes

repo: mmistakes/minimal-mistakes


text:
풀리퀘스트

Summary

Context

잔디 심기


text:
BUG: test magnetic dipole

@Eric89GXL
Hi Eric,
I was working on real time chpi, stumble upon test_magnetic_dipole() in test_make_forward.py :-)
Input r0 = np.array([0., 13., -6.]) is in mm however coils locations are in meters _magnetic_dipole_field_vec(rrs, coils): should not we divide by 1000: r0 = np.array([0., 0.13., -0.06.])/1000.
may be a PR like this
def test_magnetic_dipole():
    """Test basic magnetic dipole forward calculation."""
    trans = Transform('mri', 'head')
    info = read_info(fname_raw)
    picks = pick_types(info, meg=True, eeg=False, exclude=[])
    info = pick_info(info, picks[:12])
    coils = _create_meg_coils(info['chs'], 'normal', trans)
    # magnetic dipole at device origin
    r0 = np.array([0., 13., -6.])/1000.
    for ch, coil in zip(info['chs'], coils):
        rr = (ch['loc'][:3] + r0) / 2.
        far_fwd = _magnetic_dipole_field_vec(r0[np.newaxis, :], [coil])
        near_fwd = _magnetic_dipole_field_vec(rr[np.newaxis, :], [coil])
        ratio = 8. if ch['ch_name'][-1] == '1' else 16.  # grad vs mag
        assert_allclose(np.median(near_fwd / far_fwd), ratio, atol=1e-1)

EDIT: changed single-backticks to triple-backticks to have it render properly

Hah! Yeah, sure. Although this makes me think that it's actually okay/useful to test both a dipole that is at device origin (your idea and what I meant to do) and also a dipole that is far from the array (what I actually implemented).
PR welcome :)

Thanks @Eric89GXL
Will prepare the PR with both test cases.
I am currently testing your chpi code on large dataset and comparing with maxfilter. You did an awesome job :-)

I had lots of help from the Elekta folks to get it going. @bmaess most recently fixed some bugs, too. Hopefully you can find ways to make it better, too

Ping @SherazKhan do you have time for this, or should I take over?

Fixed in https://github.com/mne-tools/mne-python/commit/6a03bed7cb5c8147d645010ab404c376bf1d885b

repo: mne-tools/mne-python


text:
MRG : Add generic grand_average

Adressess #2523

Could we add a method parameter allowing a function, so you could use e.g. medians, trimmed medians ... instead of just the mean?

+2 .
This is also applicable to epochs.average()
On Friday, 30 October 2015, jona-sassenhagen notifications@github.com
wrote:

Could we add a method parameter allowing a function, so you could use
e.g. medians, trimmed medians ... instead of just the mean?
—
Reply to this email directly or view it on GitHub
https://github.com/mne-tools/mne-python/pull/2569#issuecomment-152680065
.

let's focus on plain average for now but I am happy to discuss "robust"
averaging techniques in subsequent PR.

Review please? @jaeilepp

Thanks @jaeilepp

make the PR as MRG when ready.

grand_average in evoked can now be deprecated?

I think so. Is there an example of how to deprecate somewhere?

Change the path in mne.__init__ to use the new grand_average.

I guess the previous deprecation tags were removed with the release, but I think you just add @deprecated('message') before the function.

I tried that before and it somehow didn't work, though maybe I messed up an import.

Is there a test for both cases?

I tried that before and it somehow didn't work, though maybe I messed up an import.

Works for me.

Sorry, what do you mean by "both cases"?

For evoked and tfr.

And also, there should be a simple test for the output data.

Do you mean like in mne/time_frequency/tests/test_tfr.py line 113?

Yeah, kind of. I would also like to see a test where combine_tfr is used with simple data (maybe just lists of ones and twos) and nave param. These kind of tests are light weight and makes sure everything works as expected.

@jaeilepp you okay with this kind of test (assuming it passes travis)?

That looks good. But you don't need to copy the data, since it's not used after that. Just modify in place.

thx @jaeilepp

Ready from my end!

@jaeilepp better now ..?

I personally would have gone with testing just one value in the array, but I guess this is equally good.

Let's see if they can sort out the GUI issue in another PR and rebase after that.

A rebase now should fix the tests. And while you're at it, please change the equalize_channels docs so that it accepts also AverageTFR. Thanks.

@jaeilepp I think I managed a rebase? All tests are fine.

Thanks @jona-sassenhagen

Thanks @jaeilepp

Coverage decreased (-0.02%) to 90.383% when pulling 68d19d82df2d059a95591693b5b499c76d158164 on jona-sassenhagen:patch-8 into e747810d9c9e6e21bb5db73702746e91171b6c61 on mne-tools:master.

authors: agramfort coveralls jaeilepp jona-sassenhagen kingjr


text:
[FIX] Repare scaling of data in _compute_covariance_auto

This fixes a bug discovered in the SPoC MNE example: https://mne-tools.github.io/dev/auto_examples/decoding/plot_decoding_spoc_CMC.html
where the Predicted EMG is not in the same scale than True EMG.
After investigation, it was due to a missing rescaling of the data in _compute_covariance_auto.
This bug did not affect the usage of mne.compute_covariance because that function does a copy internally.
This is the output of this example after bug correction:

cc @agramfort @dengemann @kingjr @alexandrebarachant
It should be ready for review

Ouch, yes it should not modify epochs.get_data() output.
Can you make some change (typo fix or clarify some wording) in examples/decoding/plot_decoding_spoc_CMC.py? Doing so will trigger CircleCI to build the example so we can easily verify that it fixes the output.
For other reviewers, this is what is in master
http://mne-tools.github.io/dev/auto_examples/decoding/plot_decoding_spoc_CMC.html#sphx-glr-auto-examples-decoding-plot-decoding-spoc-cmc-py

... also can you add an entry to whats_new.rst in the BUG section to mention this fix?

We just looked into this issue together with David. No additions from my
side! David please address the points raised by Eric.
On Tue 6 Nov 2018 at 16:44, Eric Larson notifications@github.com wrote:

@larsoner commented on this pull request.
In mne/tests/test_cov.py
https://github.com/mne-tools/mne-python/pull/5698#discussion_r231174840:

@@ -496,6 +497,17 @@ def test_cov_scaling():
_undo_scaling_array(data, picks_list, scalings=scalings)
assert_allclose(data, evoked.data, atol=1e-20)

check that scaling is undone

raw = read_raw_fif(raw_fname).crop(0, 5).load_data()
events = find_events(raw, stim_channel='STI 014')
raw.pick_channels(raw.ch_names[:5])
raw.add_proj([], remove_existing=True)
epochs = Epochs(raw, events, None, tmin=-0.2, tmax=0., preload=True)
data = np.hstack(epochs.get_data())
data_orig = data.copy()
_ = _regularized_covariance(data, info=epochs.info)

you don't need to have _ = here, this is why Travis complains
https://travis-ci.org/mne-tools/mne-python/jobs/451425389#L3283
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/pull/5698#pullrequestreview-172084591,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB0filYam3yzhclrihWpDt_SLmPhYZ0Gks5usa5jgaJpZM4YQq57
.

No it is ugly as it overwrites a local variable and introduces confusion
between data and cov. Please keep it.
On Tue 6 Nov 2018 at 17:13, Joan Massich notifications@github.com wrote:

@massich requested changes on this pull request.
In mne/cov.py
https://github.com/mne-tools/mne-python/pull/5698#discussion_r231186600:

@@ -997,8 +998,9 @@ def _compute_covariance_auto(data, method, info, method_params, cv,
cov_methods = [c.name if callable(c) else c for c in method]
runtime_infos, covs = list(runtime_infos), list(covs)
my_zip = zip(cov_methods, runtime_infos, logliks, covs, estimators)

for this_method, runtime_info, loglik, data, est in my_zip:

   out[this_method] = {'loglik': loglik, 'data': data, 'estimator': est}

for this_method, runtime_info, loglik, cov_data, est in my_zip:

why the variable name change? if it only lives in this scope. No need for
this diff, change back both lines.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/pull/5698#pullrequestreview-172099814,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB0fikkBZCpNqL07ruuw6mJ9wdTih3AWks5usbUMgaJpZM4YQq57
.

No it is ugly as it overwrites a local variable and introduces confusion
between data and cov. Please keep it.

agreed. data is confusing, and it does have the collateral effect of modifying the input parameter which is exactly what @DavidSabbagh is fixing. That's why the rest of the function uses data_ (which is not better).

To build the regression test, I tried a random matrix, and it fails.
def test_xx():
    orig_data = np.empty([5,363], dtype=np.float64)
    data = orig_data.copy()
    _regularized_covariance(data)
    assert_array_almost_equal(data, orig_data)

@larsoner do you see anything wrong with this?

@larsoner do you see anything wrong with this?

Sometimes with empty you get really tiny or huge numbers. The scaling that gets applied and un-applied might not work with the effective tolerances in assert_array_almost_equal. I would use np.random.RandomState(5, 363) and np.allclose(x, y, atol=1e-12, rtol=1e-12) to be more robust.
I doubt this would fix it, but it's a good idea either way. And I agree we can fix this aspect in a follow-up PR

off-topic,
but maybe we should think about adding something like this test in sklearn where they test that parameters are not owverwrite that got in in this PR (https://github.com/scikit-learn/scikit-learn/pull/9019)
However, even if we had a test like this I dubt that this function had been checked 'ocs its private.
Anyway, I just wanted this to be written somewhere.

Ok just checked with David. Good to go on my side.

Thx, @DavidSabbagh 	wellcome to the family

Thank you Sik ! Very proud to be part of it now :-)
Le mer. 7 nov. 2018 à 15:55, Joan Massich notifications@github.com a
écrit :

Thx, @DavidSabbagh https://github.com/DavidSabbagh wellcome to the
family
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/pull/5698#issuecomment-436649986,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AgWoGsD-onIg5muc_NCsaFM-5i8HOlO7ks5usvRYgaJpZM4YQq57
.

authors: DavidSabbagh dengemann larsoner massich


text:
Fix ica.plot_properties with bad data

When plotting ICA component properties, one of the things that gets plotted is the component PSD. This uses the helper function _convert_psds that performs a check on the presense of zeros in the
PSD. When zeros are detected, a warning is printed. To construct the warning message string, it is assumed that the first dimension of the psds array contains channels. However, in the case of ica.plot_properties, the first dimensions contains epochs. Hence, the construction of the warning message string fails with an index out of bounds error.
This PR adds a flag to the _convert_psds helper function to inform it that the first dimension of the psds array contains epochs rather than channels.

It's extremely rare that this happens. I got some data that triggers this condition, but cannot share it freely.

thx @wmvanvliet

authors: agramfort wmvanvliet


text:
WIP, ENH: Be verbose if fitting ICA on rank-deficient data

@agramfort and I encountered a weird, seemingly inexplicable issue when using ICA for EOG and ECG artifact correction. Turned out – the only reason that lead us to "waste" several hours was simply that the input data was rank-deficient, because it had 3 SSP projection vectors in .info.
I have therefore opted to enhance ICA.fit() such that it would (hopefully) detect such cases in the future, and voice its concerns or even fail hard.
I have added a check_rank=True kwarg to ICA.fit(). If True (default), the user will get an extensive warning if the rank of the data is expected to be NOT full even after the PCA step. The error message contains concrete directions on what to do.
My idea is that this message, for now, remains a warning, and will change to an Exception with 0.23 the latest. In fact, I'd prefer if we immediately made it an exception, because I think we should fail hard in this case; but I assume other devs would be against this, therefore we should probably do a deprecation cycle.
If the user passes check_rank=False, we will still produce a warning, but it won't be as extensive. My reasoning behind this is that it helps ensure that one doesn't accidentally leave check_rank =False in the code after testing something and forgetting about it. Once check_rank=True raises an exception, the behavior difference between check_rank=True and check_rank=False will become more clear.
Todo:

[ ] Amend ICA tutorial
[ ] Amend changelog

Voice call with @agramfort:

don't introduce a new parameter to ICA.fit, but offer more options for ICA.max_pca_components, e.g. 'rank' or 'auto' instead
maybe deprecate max_pca_components=None


text:
MRG, MAINT: Refactor volume interpolation code

I am still annoyed by how slow the volumetric morphing is, so I decided to see if I could alleviate one bottleneck, namely the linear and zero-order interpolations. I never 100% understood Matti's volume interpolation code I adapted so many years ago, but based on how it works it should definitely be faster when we have lots of volumes to morph. Whether it's already the same speed as dipy and nibabel (scipy.ndimage) or faster with 1, 10, 100, or 1000 volumes remains to be determined, but I wouldn't be surprised if it were about the same speed with even just 1. It definitely will be with 1000.
In any case, to move toward being able to use the sparse matrix code I:

Refactored our _add_interpolator code to do a generic grid-to-grid interpolation
Added tests showing equivalences between nibabel, dipy, and our code for linear and nearest interpolation (it's a ton of combos but it takes only 0.3 sec on my machine)
Made the code jit-able but it didn't actually speed it up (thanks, vectorization!)
Fixed some minor bugs with our treatment of edge/border volume vertices in _add_interpolator (exposed by the nibabel/dipy equivalency tests), where some vertices could be interpolated to by a subset of the 8 possible vertices (e.g., 4 or 2 or even 1 of them) but it only added the interpolation if all could.

This should allow me to then speed up SourceMorph._morph_vols, but I'll do that in a subsequent PR. Even if it does not speed things up, this is already a nice refactoring + unit testing of our code.

Yes this even fixes some minor bugs in master exposed by the new unit tests. And the existing tests were already pretty good at detecting when something went wrong as well.

+1 for MRG then

authors: agramfort larsoner


text:
listmemberships.create error

This method fails

Resolved by @bernardito-luis in pull request #10


text:
[TRA-33] 기록(간편,상세) 모달 퍼블리싱

작업 분류

[ ] 버그 수정
[x] 신규 기능
[ ] 프로젝트 구조 변경
[ ] 기타

작업 상세 내용
floating menu - '기록하기' 클릭 시 나오는 모달 퍼블리싱

floating menu 컴포넌트와 연결 처리함

다음 할 일
여행계획&기록 (어디로) 퍼블리싱
여행 기록&계획 (최종등록) 페이지 퍼블리싱
체크 리스트

[x] main 브랜치 pull 받기
[x] 아직 작업 중인 파일은 올리지 않기

질문 사항
💬 질문이 있어요!
🔴 이건 반드시 확인해 주세요!

버튼 클릭 시, 간편기록, 상세기록 페이지로의 이동은 추후 작업 예정

Fixes TRA-33

useState는 추후 jotai 라이브러리로 리팩터링 해야할 것 같습니다..!

수고하셨습니다:)

useState는 추후 jotai 라이브러리로 리팩터링 해야할 것 같습니다..!

jotai로 변경해두었습니다 : )

authors: Sueddd nasilKiM yesoryeseul


text:
Screen shot documentation seems incomplete

The screen shot documentation is as follows:
takeScreenshot
takeScreenshot saves a screenshot in a PNG file:
- takeScreenshot: MainScreen    # will be stored as a MainScreen.png

Reference
It would be great if we can somehow mention where the screenshot will be saved and if we can change output directory like we can do in test reports.

Hi @talhahasanzia, I agree we could do a better job here.
Contributions are very welcome!

should be closed with merging of PR #64

closed by #64

authors: bartekpacia niklaskroe talhahasanzia

repo: mobile-dev-inc/maestro-docs


text:
Studio: Added play button with commands

Added back a visible play button with the commands.

For future PRs, a screenshot would be helpful to see the changes visually

authors: Leland-Takamine proksh

repo: mobile-dev-inc/maestro


text:
Update nightly default to 2023-01-2023

Motivation

Current dependencies on/for this PR:

main

PR #81   👈

This comment was auto-generated by Graphite.

repo: mobilecoinfoundation/cookiecutters


text:
Update SwiftNIO dependency to 2.40.0

Soundtrack of this PR: link to song that really fits the mood of this PR
Motivation
SwiftNIO team fixed a CocoaPods link error issue that was preventing clients from building with parallelization enabled: https://github.com/apple/swift-nio/issues/2073#issuecomment-1117138500
This change updates the dependency to pick up the new version so clients can use it.
In this PR
Update MobileCoin.podspec to SwiftNIO 2.40.0
Regenerate Example/Podfile.lock and ExampleHTTP/Podfile.lock

can you remake your PR with just your commit off of the latest master ?
Also, I recently "downgraded"/locked-in an older version of SwiftNIO because of some issues I was seeing, so Id like to verify that this new version doesn't cause a regression on the issue I was fixing for.
This is that commit - https://github.com/mobilecoinofficial/MobileCoin-Swift/commit/af234e621c145ef51029fafb2f48a0fd7d6ae182
this was the PR description
### Motivation

Version lock GRPC and SwiftNIO dependencies to preserve network robustness when connections are idle. Integrating apps may see this error after a connection goes idle `NIOCore/EventLoopFuture.swift:429: Precondition failed: leaking an unfulfilled Promise`.

### In this PR
* Version locking for GRPC and SwiftNIO dependencies, latest versions cause errors
* Revert changes that were implemented based on higher-version's deprecations

after you rebase/remake the PR I can do some testing.

Updated, PTAL

If @the-real-adammork's testing shows that the leak issue is still present, the options are:

make a reduced test case and file an issue against SwiftNIO
fork and land a targeted fix for the compilation issue
decide this isn't a priority and hope it resolves itself on its own

authors: collinjackson the-real-adammork

repo: mobilecoinofficial/MobileCoin-Swift


text:
on send_authorize error

i tried with
call.AuthorizePayload(     {     'id_token': '123',              'type': 'KeyCode'            }      ) at charge point
it throws the following error at server
Error while handling request '<Call - unique_id=bb109810-d0ef-44d3-b939-9766fd217d6e, action=Authorize, payload={'idToken': {'idToken': '123', 'type': 'KeyCode'}}>'
Traceback (most recent call last):
File "C:\Users\x\AppData\Local\Programs\Python\Python37-32\lib\site-packages\ocpp\charge_point.py", line 184, in _handle_call
response = await asyncio.coroutine(handler)(**snake_case_payload)
File "C:\Users\x\AppData\Local\Programs\Python\Python37-32\lib\asyncio\coroutines.py", line 120, in coro
res = func(*args, **kw)
File "C:\Users\x\AppData\Local\Programs\Python\Python37-32\lib\site-packages\ocpp\routing.py", line 31, in inner
return func(*args, **kwargs)
TypeError: on_authorize() got an unexpected keyword argument 'id_token'

Error because missed to place id_token  params at server side..

repo: mobilityhouse/ocpp


text:
🛑 PizzaPiedra Web is down

In b295cc6, PizzaPiedra Web (https://pizzapiedra.com.uy) was down:

HTTP code: 0
Response time: 0 ms

Resolved: PizzaPiedra Web is back up in cdd64f3.

repo: mobilitysol/monitorweb


text:
Update Posts “asdasdas”

Automatically generated by Netlify CMS

👷 Deploy Preview for goofy-fermat-b72eff processing.
🔨 Explore the source changes: 20fc81f0fdff36df891558607fd4039be3c63c19
🔍 Inspect the deploy log: https://app.netlify.com/sites/goofy-fermat-b72eff/deploys/61604b4f225b9400082229a0

repo: mobley-digital/nextjs-netlify-blog


text:
Unable to resolve module ./assertEnvironment

After upgrading from "mobx": "^5.15.7" and "mobx-react": "^6.3.0" to "mobx": "^6.0.0" and "mobx-react": "^7.0.0" I receive an Unable to resolve module `./assertEnvironment error.
Intended outcome
The app doesn't have any errors
Actual outcome
error: Error: Unable to resolve module `./assertEnvironment` from `node_modules/mobx-react-lite/es/index.js`:

None of these files exist:
  * node_modules/mobx-react-lite/es/assertEnvironment(.native|.android.js|.native.js|.js|.android.json|.native.json|.json|.android.ts|.native.ts|.ts|.android.tsx|.native.tsx|.tsx)
  * node_modules/mobx-react-lite/es/assertEnvironment/index(.native|.android.js|.native.js|.js|.android.json|.native.json|.json|.android.ts|.native.ts|.ts|.android.tsx|.native.tsx|.tsx)
    at ModuleResolver.resolveDependency (/Users/virtumonde/Desktop/dev/project/project-client/node_modules/metro/src/node-haste/DependencyGraph/ModuleResolution.js:163:15)
    at ResolutionRequest.resolveDependency (/Users/virtumonde/Desktop/dev/project/project-client/node_modules/metro/src/node-haste/DependencyGraph/ResolutionRequest.js:52:18)
    at DependencyGraph.resolveDependency (/Users/virtumonde/Desktop/dev/project/project-client/node_modules/metro/src/node-haste/DependencyGraph.js:287:16)
    at Object.resolve (/Users/virtumonde/Desktop/dev/project/project-client/node_modules/metro/src/lib/transformHelpers.js:267:42)
    at /Users/virtumonde/Desktop/dev/project/project-client/node_modules/metro/src/DeltaBundler/traverseDependencies.js:434:31
    at Array.map (<anonymous>)
    at resolveDependencies (/Users/virtumonde/Desktop/dev/project/project-client/node_modules/metro/src/DeltaBundler/traverseDependencies.js:431:18)
    at /Users/virtumonde/Desktop/dev/project/project-client/node_modules/metro/src/DeltaBundler/traverseDependencies.js:275:33
    at Generator.next (<anonymous>)
    at asyncGeneratorStep (/Users/virtumonde/Desktop/dev/project/project-client/node_modules/metro/src/DeltaBundler/traverseDependencies.js:87:24)

How to reproduce the issue
Install "mobx": "^6.0.0" and "mobx-react": "^7.0.0" on  "react-native": "0.63.3"
Versions
"mobx": "^6.0.0",
"mobx-react": "^7.0.0"
"react-native": "0.63.3"

could you verify in your lockfile / node_modules which version of mobx-react-lite is installed? should be 3.0.0 at least

@mweststrate Isn't the path wrong here?
node_modules/mobx-react-lite/es/assertEnvironment
Should be in utils dir ... https://unpkg.com/browse/mobx-react-lite@3.0.0/es/utils/

What I mean is the assertEnvironment is used by mobx-react-lite internally only. How is it possible something else is importing it from a different path?

@mweststrate
    "mobx-react": {
      "version": "6.3.1",
      "resolved": "https://registry.npmjs.org/mobx-react/-/mobx-react-6.3.1.tgz",
      "integrity": "sha512-IOxdJGnRSNSJrL2uGpWO5w9JH5q5HoxEqwOF4gye1gmZYdjoYkkMzSGMDnRCUpN/BNzZcFoMdHXrjvkwO7KgaQ==",
      "requires": {
        "mobx-react-lite": "^2.2.0"
      }
    },
    "mobx-react-lite": {
      "version": "2.2.2",
      "resolved": "https://registry.npmjs.org/mobx-react-lite/-/mobx-react-lite-2.2.2.tgz",
      "integrity": "sha512-2SlXALHIkyUPDsV4VTKVR9DW7K3Ksh1aaIv3NrNJygTbhXe2A9GrcKHZ2ovIiOp/BXilOcTYemfHHZubP431dg=="
    },

@virtumonde yeah that sounds like you have somehow a hardcoded import into the mobx-react-library somewhere? VSCode tends to do that sometimes :-P. I suspect this issue is further unrelated to the actual package. That file has moved indeed recently, but is internal so should not affect anything.

    "mobx-react": {
      "version": "7.0.0",
      "resolved": "https://registry.npmjs.org/mobx-react/-/mobx-react-7.0.0.tgz",
      "integrity": "sha512-yxbTG+ovn/GbgF3+QdQahkL5sXiITtwvkoXM6PNqd0V4jvO53cnr/YM4PYuA+0Ig95IW1nojA3qViJx9ufJm6w==",
      "requires": {
        "mobx-react-lite": "^3.0.0"
      }
    },
    "mobx-react-lite": {
      "version": "3.0.0",
      "resolved": "https://registry.npmjs.org/mobx-react-lite/-/mobx-react-lite-3.0.0.tgz",
      "integrity": "sha512-SJgrTD9mfClFOsamB+0y6zjteSMr4gkp9usnpIeEi8E+lW3lMgDa3hnD4PJgLGoENpJ8/9OmO3vrkA50SNy0mw=="
    },

@mweststrate let me look into it.

@mweststrate by hardcoded import you mean I am myself trying to access node_modules/mobx-react-lite/es/index.js?

yes
On Thu, Oct 1, 2020 at 2:44 PM Dan Clipca notifications@github.com wrote:

@mweststrate https://github.com/mweststrate by hardcoded import you
mean I am myself trying to access node_modules/mobx-react-lite/es/index.js
?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mobxjs/mobx-react/issues/899#issuecomment-702145603,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAN4NBABVZOMB5LV35LVQCTSISBVDANCNFSM4SALP44A
.

having something in the form of import from "mobx-react-lite/something"
On Thu, Oct 1, 2020 at 2:46 PM Michel Weststrate mweststrate@gmail.com
wrote:

yes
On Thu, Oct 1, 2020 at 2:44 PM Dan Clipca notifications@github.com
wrote:

@mweststrate https://github.com/mweststrate by hardcoded import you
mean I am myself trying to access
node_modules/mobx-react-lite/es/index.js?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mobxjs/mobx-react/issues/899#issuecomment-702145603,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAN4NBABVZOMB5LV35LVQCTSISBVDANCNFSM4SALP44A
.

@mweststrate the only mention of mobx-react-lite is in my package-lock.json. I am sure that my code does not import it. Might other packages might import it? Here are my dependencies:
  "dependencies": {
    "@react-native-community/async-storage": "^1.12.0",
    "@react-native-firebase/app": "^8.4.5",
    "@react-native-firebase/crashlytics": "^8.4.8",
    "@react-native-mapbox-gl/maps": "^8.1.0-rc.4",
    "google-protobuf": "^3.13.0",
    "grpc-web": "^1.2.1",
    "lottie-react-native": "^3.5.0",
    "mobx": "^6.0.0",
    "mobx-react": "^7.0.0",
    "react": "16.13.1",
    "react-native": "0.63.3",
    "react-native-action-button": "^2.8.5",
    "react-native-modal": "^11.5.6",
    "react-native-permissions": "^2.2.2",
    "react-native-popup-menu": "^0.15.9",
    "react-native-safe-area-context": "^3.1.8",
    "react-native-sound": "^0.11.0",
    "react-native-toast-message": "^1.3.3",
    "react-native-vector-icons": "^7.1.0"
  },
  "devDependencies": {
    "@babel/core": "^7.11.6",
    "@babel/plugin-proposal-class-properties": "^7.10.4",
    "@babel/plugin-proposal-decorators": "^7.10.5",
    "@babel/runtime": "^7.11.2",
    "@react-native-community/eslint-config": "^2.0.0",
    "@types/geojson": "^7946.0.7",
    "@types/jest": "^26.0.14",
    "@types/react-native": "^0.63.23",
    "@types/react-test-renderer": "^16.9.3",
    "@types/uuid-parse": "^1.0.0",
    "@typescript-eslint/eslint-plugin": "^4.3.0",
    "@typescript-eslint/parser": "^4.3.0",
    "@types/google-protobuf": "^3.7.3",
    "@types/react-native-vector-icons": "^6.4.6",
    "babel-jest": "^26.3.0",
    "eslint": "^7.10.0",
    "jest": "^26.4.2",
    "metro-react-native-babel-preset": "^0.63.0",
    "prettier": "^2.1.2",
    "react-test-renderer": "16.13.1",
    "typescript": "^4.0.3"
  }

Also, switching back to "mobx-react": "^6.3.0" and "mobx": "^6.0.0" doesn't trigger the error.

Something is apparently importing the old file. Maybe even some sort of cache? Might be even duplicate versions of packages. I recommend deleting node_modules and reinstalling from the scratch.

@FredyC I already did that 5 times. I will look into other possibilities soon as for now this is not critical to me.

If switching to mobx-react:6.3 and mobx:6 does work for you, there is
definitely something wrong, as those should normally not be able to work
together :-P. There is something weird, are you sure you have cleared all
caches, have the same folder open in terminal, ide and project that is
running, etc? Otherwise I recommend to build a minimal repro, usually the
process of doing that finds the culprit
On Thu, Oct 1, 2020 at 2:55 PM Dan Clipca notifications@github.com wrote:

@FredyC https://github.com/FredyC I already did that 5 times. I will
look into other possibilities soon as for now this is not critical to me.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mobxjs/mobx-react/issues/899#issuecomment-702152939,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAN4NBHRF44T2FSJ6B4RYUTSISC6LANCNFSM4SALP44A
.

@mweststrate I meant "mobx": "^5.15.7" instead of "mobx": "^6.0.0". My bad.

ok, nonetheless would be great to build a minimal reproduction. Might be an
uncommon module format or something that messes things up.

Just for confirmation, I just tried both a fresh CRA and a fresh RN project with mobx@6 + mobx-react@7 and they work fine. So this really seems to be a local issue. You can try to run yarn why mobx-react-lite (or the other 2) to see if another package accidentally brings a different version of those packages.

Healthy output looks like:
yarn why mobx-react-lite
yarn why v1.22.4
[1/4] 🤔  Why do we have the module "mobx-react-lite"...?
[2/4] 🚚  Initialising dependency graph...
[3/4] 🔍  Finding dependency...
[4/4] 🚡  Calculating file sizes...
=> Found "mobx-react-lite@3.0.0"
info Reasons this module exists
   - "mobx-react" depends on it
   - Hoisted from "mobx-react#mobx-react-lite"
info Disk size without dependencies: "316KB"
info Disk size with unique dependencies: "316KB"
info Disk size with transitive dependencies: "316KB"
info Number of shared dependencies: 0
✨  Done in 0.48s.

Closing until more info becomes available

authors: FredyC mweststrate virtumonde

repo: mobxjs/mobx-react


text:
It should be possible to create a network without assigning the bridge an IP address

Using the default bridge and IPAM drivers, it should be possible to create a bridge without assigning it an IP address. This is expressed at the gateway address through the CLI, and although I can set the gateway address within the subnet assigned to the network, there appears to be no way to specify that the bridge should not be assigned an IP address at all.
This is strange when considered in the context or isolated networks where there should be no connectivity outside the isolated network, and therefore no need for a gateway.  This is important in the case of untrusted or possibly compromised containers on the isolated docker network, as the bridge address exposes host services. (i.e. if the host is running SSH, HTTP, or (god forbid) Docker listening over TCP without binding to a particular IP address, then these services will be accessible through the bridge IP, and open to compromise from an attacker)
What I'd like to see would be that if I specify a new flag (e.g. "--noip") or provide a special value (e.g. "0.0.0.0") to the "--gateway" flag when using the CLI "docker network create" command that it would create the bridge with no IP address. I am not familiar enough with the internal libnetwork APIs to know what it would be at this layer.
Any comments, pointers on how to implement this change, or workarounds, would be appreciated

+1
I thought this is what --ipam-driver=null is for, but it does not work. I would like to use the macvlan driver with --ipam=driver=null and then use a DHCP client to assign an IP address , but this does not work. At least not in docker 17.06.

+100

Apparently "moby" is the upstream from where changes trickle out, so I opened an issue:
https://github.com/moby/moby/issues/37430
and a proposed pull request:
https://github.com/moby/moby/pull/37432
there.

Google "com.docker.network.bridge.inhibit_ipv4=true" if anyone lands on this page looking for solutions

terrible things....
the "com.docker.network.bridge.inhibit_ipv4=true" dosen't work on macvlan
docker network create -d macvlan -o parent="eth1" -o com.docker.network.bridge.inhibit_ipv4=true veth2
docker network inpect veth2
I got
....
"IPAM": {
"Driver": "default",
"Options": {},
"Config": [
{
"Subnet": "172.23.0.0/16",
"Gateway": "172.23.0.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {},
"Options": {
"com.docker.network.bridge.inhibit_ipv4": "true",
"parent": "eth1"
},
....
when I create a new container with veth2. docker assigns 172.23.0.2 to me
docker version is 20.10.1

authors: crazybert dbarrosop greyarch gsomlo longforrich nategraf

repo: moby/libnetwork


text:
After enable ipv6 in the docker, it works for only static ipv6 address, but not DHCP ipv6 address

Warning
libnetwork was moved to https://github.com/moby/moby/tree/master/libnetwork
libnetwork has been merged to the main repo of Moby since Docker 22.06.
The old libnetwork repo (https://github.com/moby/libnetwork) now only accepts PR for Docker 20.10,
and will be archived after the EOL of Docker 20.10.

Sorry to trouble all of you.
Recently, I follow the guidance to enable ipv6 for the docker in my linux machine
I directly edit the /etc/docker/daemon.json file for adding these parameters:
"ipv6": true,
"ip6tables": true,
"experimental": true,
"fixed-cidr-v6": "2001:db8:abc1::/64"
Then just restart the docker.
Then for example, here are two ipv6 addresses
static ipv6 address A
DHCP(dynamic) generated ipv6 address B
Case1:
When I use "ping6 A" in my linux machine, it works with response
Case2:
When I use "ping6 B" in my linux machine, it works but should have a zone identifier behind, like "B%eth0"
Case3:
when I use "docker exec -it myDocker bash" to get inside a docker, and then run "ping6 A", it works with response
Case4:
when I use "docker exec -it myDocker bash" to get inside a docker, and then run "ping6 B", it always throws the error message "ping6: sendto: Invalid argument"
Then I also try "ping6 B%eth0", it will be time out without any response.
For case4, I do not understand, for DHCP generated ipv6 address, why we cannot use it or ping6 it inside the docker? Why the docker cannot automatically assign a zone identifier to it? what is the problem here? how to fix it?
Thanks a lot. Really need your help.

Hi, could you please send the output of
ip -f inet6 addr show
From within the container and from the host?
Also, there is/was a problem with a /64, can you try again with a /80 ?
Kind regards,
Ed
On 3/24/23 09:52, Haochen Sui wrote:

*Warning*
libnetwork was moved to
https://github.com/moby/moby/tree/master/libnetwork

libnetwork has been merged to the main repo of Moby since Docker
22.06.

The old libnetwork repo (https://github.com/moby/libnetwork) now
only accepts PR for Docker 20.10,
and will be archived after the EOL of Docker 20.10.

Sorry to trouble all of you.
Recently, I follow the guidance to enable ipv6 for the docker in my
linux machine
I directly edit the /etc/docker/daemon.json file for adding these
parameters:
"ipv6": true,
"ip6tables": true,
"experimental": true,
"fixed-cidr-v6": "2001:db8:abc1::/64"
Then just restart the docker.
Then for example, here are two ipv6 addresses
static ipv6 address A
DHCP(dynamic) generated ipv6 address B
Case1:
When I use "ping6 A" in my linux machine, it works with response
Case2:
When I use "ping6 B" in my linux machine, it works but should have a
zone identifier behind, like "B%eth0"
Case3:
when I use "docker exec -it myDocker bash" to get inside a docker, and
then run "ping6 A", it works with response
Case4:
when I use "docker exec -it myDocker bash" to get inside a docker, and
then run "ping6 B", it always throws the error message "ping6: sendto:
Invalid argument"
Then I also try "ping6 B%eth0", it will be time out without any response.
For case4, I do not understand, for DHCP generated ipv6 address, why
we cannot use it or ping6 it inside the docker? Why the docker cannot
automatically assign a zone identifier to it? what is the problem
here? how to fix it?
Thanks a lot. Really need your help.
—
Reply to this email directly, view it on GitHub
https://github.com/moby/libnetwork/issues/2675, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABPTWE4UTWU3YOEKML72E73W5VOGHANCNFSM6AAAAAAWGIS3KQ.
You are receiving this because you are subscribed to this
thread.Message ID: @.***>

authors: WallaceSUI kapiteined


text:
Web Worker support

See https://github.com/visionmedia/mocha/pull/780#issuecomment-18275542

Was added in https://github.com/mochajs/mocha/pull/867 :)

This got broken again when mocha thinks it's node while in fact it isn't
due to typeof document === 'undefined'

authors: danielstjules jimmywarting tanx

repo: mochajs/mocha


text:
fix improper warnings for invalid reporters

also: reorganize, add, and refactor a bunch of problematic unit tests for lib/mocha.js.  better isolation except where we can't really do that (calling require)
there's still missing tests in here, but this is an improvement.
@craigtaub this touches some stuff regarding warnings for invalid reporters.  it looks like the conditionals were backwards?

I should note that I started out adding more coverage and refactoring, but I found a bug while I was doing that...

Odd the logic been broken for so long for such an important part. Would have been good to see an issue or details in the description to help replicate locally.

Would this logic only really apply for programmatic use of mocha as seems cli will catch bad reporter when I try locally?
Is this a semvar major if something which used to pass now fails?

can't use require.resolve in unit tests because browser.  will need to move some of these into test/node-unit/mocha.spec.js

OK, we can't use rewiremock in test/unit/*.spec.js because it's apparently incompatible with browserify as written.  so I've ripped it out of there, and moved some tests for Mocha#reporter() into test/node-unit/mocha.spec.js where we can safely test reporter resolution.
Ref: https://github.com/theKashey/rewiremock/issues/113
cc @Munter -- how's the transpilation coming? 😄

Coverage increased (+0.07%) to 93.113% when pulling 89cb1e7d5447c0b369c5f2b886a415683e19f40a on boneskull/mocha-unit-tests into c0137eb698add08f29035467ea1dc230904f82ba on master.

tests broke because you can't use Object.assign() in IE11 (I forgot), but I noticed we also didn't have a lint rule preventing it, so I added one.

@nicojs I had heavily refactored test/unit/mocha.spec.js, where most of your new tests live--so they, too, are assimilated in this PR.  May want to take a look.

@boneskull  You're not kidding, file looks like a Christmas tree in my browser 🎄. Will checkout this branch locally to take a better look. Will have to wait till tomorrow.

your changes highlight that Mocha.prototype.run has a very strange API.
It accepts an optional callback, and that callback is called with a single parameter, failures, a number.  This doesn't conform to a typical convention.  If it did use an error-first style, that convention expects the function to not throw, and rather call the callback w/ an Error instance.
It would likely be highly disruptive to break this, unfortunately.  Off the top of my head, two ways we could improve the situation:

The way forward may instead be to create a new runAsync (or whatever) in the future and return a Promise.  If the Runner instance is needed (the current return value) then this would not be appropriate.
In Mocha.prototype.run, inspect the callback.  If it exists and has an arity greater than 1, use an error-first style; otherwise use the current behavior.

Consumers of Mocha.prototype.run don't currently expect it to throw (for any reason), and the current situation may be awkward to work with.

authors: boneskull coveralls craigtaub nicojs


text:
[1.3] Vol. II Command processing optimizations in domain.c

Additional porting from 1.2.x
Follows up on pull 191
to match 1.2.x pull 190.

@jfclere ???


text:
Rework tests

What that would be good to do:

[ ] Make tests more modular
[ ] Remove duplication
[ ] Consider using local image repository instead of quay.io
[ ] Run tests in CI (or a reasonable subset)
[ ] Rework directory structure – java part is not used, so we might drop it and flatten the whole part
[x] Consider making function names more structured, rename some, etc.

I also fixed the following:
diff --git a/test/native/Dockerfile b/test/native/Dockerfile
index 3955f91..40b72bd 100644
--- a/test/native/Dockerfile
+++ b/test/native/Dockerfile
@@ -2,7 +2,7 @@ FROM tomcat:8.5
WORKDIR /usr/local/tomcat
-COPY target/dependency/.jar ./lib/
+COPY target/.jar ./lib/
COPY ./files/server.xml ./conf/
COPY ./files/context.xml ./conf/
COPY ./files/start.sh ./
diff --git a/test/native/pom.xml b/test/native/pom.xml
index 0c78ef8..88ee4b8 100644
--- a/test/native/pom.xml
+++ b/test/native/pom.xml
@@ -41,7 +41,7 @@
-->

org.jboss.mod_cluster

           <artifactId>mod_cluster-container-tomcat85</artifactId>

           <artifactId>mod_cluster-container-tomcat-8.5</artifactId>
           <version>${project.version}</version>
       </dependency>
       <dependency>

diff --git a/test/native/tests.sh b/test/native/tests.sh
index a1f81b5..b543063 100644
--- a/test/native/tests.sh
+++ b/test/native/tests.sh
@@ -12,7 +12,7 @@ if [ -z ${ITERATION_COUNT+x} ]; then
ITERATION_COUNT=50 # the number of iteration of starting/stopping a tomcat
fi
if [ -z ${IMG+x} ]; then

IMG=IMG=quay.io/$USER/tomcat_mod_cluster

IMG=quay.io/$USER/tomcat_mod_cluster
fi

echo -n "Test values are FOREVER_PAUSE=$FOREVER_PAUSE, TOMCAT_CYCLE_COUNT=$TOMCAT_CYCLE_COUNT,"

I also fixed the following:
diff --git a/test/native/Dockerfile b/test/native/Dockerfile
index 3955f91..40b72bd 100644
--- a/test/native/Dockerfile
+++ b/test/native/Dockerfile
@@ -2,7 +2,7 @@ FROM tomcat:8.5

 WORKDIR /usr/local/tomcat

-COPY target/dependency/*.jar ./lib/
+COPY target/*.jar ./lib/
 COPY ./files/server.xml ./conf/
 COPY ./files/context.xml ./conf/
 COPY ./files/start.sh ./
diff --git a/test/native/pom.xml b/test/native/pom.xml
index 0c78ef8..88ee4b8 100644
--- a/test/native/pom.xml
+++ b/test/native/pom.xml
@@ -41,7 +41,7 @@
 -->
             <dependency>
                 <groupId>org.jboss.mod_cluster</groupId>
-                <artifactId>mod_cluster-container-tomcat85</artifactId>
+                <artifactId>mod_cluster-container-tomcat-8.5</artifactId>
                 <version>${project.version}</version>
             </dependency>
             <dependency>
diff --git a/test/native/tests.sh b/test/native/tests.sh
index a1f81b5..b543063 100644
--- a/test/native/tests.sh
+++ b/test/native/tests.sh
@@ -12,7 +12,7 @@ if [ -z ${ITERATION_COUNT+x} ]; then
     ITERATION_COUNT=50 # the number of iteration of starting/stopping a tomcat
 fi
 if [ -z ${IMG+x} ]; then
-    IMG=IMG=quay.io/$USER/tomcat_mod_cluster
+    IMG=quay.io/$USER/tomcat_mod_cluster
 fi

 echo -n "Test values are FOREVER_PAUSE=$FOREVER_PAUSE, TOMCAT_CYCLE_COUNT=$TOMCAT_CYCLE_COUNT,"

You're right, I forgot about it. I put it into #119 if you want to merge it. (I ran into issues while working on this; once I'll get CI working, I'll create another PR.)

Once #120 and #121 are merged, we can close this one.

authors: jajik jfclere


text:
Consistent use of term technologieparameters

Reported by beutlich on 16 Dec 2015 23:03 UTC
There are the terms technologieparameters and technologyparameters used in Spice3. I guess only one of them should be used consistently.

Migrated-From: https://trac.modelica.org/Modelica/ticket/1864

Comment by ahaumer on 18 Dec 2015 12:14 UTC
In my opinion there's no English term "technologie" but "technology".
I suppose that's a typo.
Since this is no big issue, I'm shifting the milestone.

Changed the term "technologie" into "technology" in Modelica.Electrical.Spice3
SHA-1: a91a0a91d7a43efa21abd328917667f1baa3f708

authors: kristinmajetta modelica-trac-importer

repo: modelica/Modelica


text:
feat: use command replace io

Background
Description

[x] ReWrite WriteNpm func.

Others

@zaunist  cc.

Codecov Report

Merging #23 (93f2384) into master (7523ace) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #23   +/-   ##
=======================================
  Coverage   75.00%   75.00%
=======================================
  Files           2        2
  Lines          20       20
=======================================
  Hits           15       15
  Misses          4        4
  Partials        1        1

Flag
Coverage Δ

unittests
75.00% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

You can view npm config docs. Can found npm config set registry uri. So i think we can use npm command replace past io operate. From my point, We use npm command can reduce unnecessary code of grm. And get more friendly err log from npm self. If user set a err uri.

I push new code. This commit I just kept the err return at  write_ini.go file.

@zaunist  cc

authors: XeryYue codecov-commenter

repo: modern-magic/grm


text:
[check-html-links]Last version is not working

I tried to run check-html-links on latest version 0.2.2, but it's not working because slash is not found.
My dockerfile:
FROM node:16-alpine3.13
RUN npm install check-html-links@0.2.2
ENTRYPOINT ["/usr/local/bin/check-html-links"]

Execution trace:
node:internal/process/esm_loader:74
    internalBinding('errors').triggerUncaughtException(
                              ^

Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'slash' imported from /usr/local/lib/node_modules/check-html-links/src/validateFolder.js
    at new NodeError (node:internal/errors:363:5)
    at packageResolve (node:internal/modules/esm/resolve:698:9)
    at moduleResolve (node:internal/modules/esm/resolve:739:18)
    at Loader.defaultResolve [as _resolve] (node:internal/modules/esm/resolve:853:11)
    at Loader.resolve (node:internal/modules/esm/loader:89:40)
    at Loader.getModuleJob (node:internal/modules/esm/loader:242:28)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:73:40)
    at link (node:internal/modules/esm/module_job:72:36) {
  code: 'ERR_MODULE_NOT_FOUND'
}

This is because the validateFolder.js import slash but it's not included into the package.json
As a work around, I manually install slash

oh - good catch 👍

authors: daKmoR lvjp

repo: modernweb-dev/rocket


text:
Some checks for defaulting to Pandas can give misleading passing results, and we don't catch all instances of defaulting to pandas.

System information

OS Platform and Distribution (e.g., Linux Ubuntu 16.04): MacOS Big Sur 11.5.2 on MacBook Pro 16-inch, 2019
Modin version (modin.__version__): 0.11.1+38.g8acad95e
Python version: 3.8.8

Describe the problem
There are several places where we check that Modin defaults to Pandas. Consider this check:
https://github.com/modin-project/modin/blob/8acad95ed2dea2c7671d6dc3518d4b0b12c8b682/modin/pandas/test/test_reshape.py#L23-L26
If I change the code to:
s = pd.Series(list("abca"))
with pytest.warns(UserWarning, match="impossible match"):
        pd.get_dummies(s)

I get the failure message:
Failed: DID NOT WARN. No warnings of type (<class 'UserWarning'>,) matching ('impossible match') was emitted. The list of emitted warnings is: [UserWarning('`get_dummies` on non-DataFrame defaulting to pandas implementation.\nTo request implementation, send an email to feature_requests@modin.org.'), UserWarning("Distributing <class 'pandas.core.frame.DataFrame'> object. This may take some time.")].

In the list of warnings, there's both the warning about "defaulting to pandas implementation" and another warning about ""Distributing <class 'pandas.core.frame.DataFrame'> object". Presumably, the latter would happen even if Modin were not defaulting to Pandas. Indeed, if I comment out this line that raises the exception and use the original test code from master, the test passes.
In such cases, we need to look for a UserWarning warning that we are defaulting to Pandas, not just any user warning.

I'm expanding this issue to include the fact that we are not explicitly catching all cases where we default to Pandas in tests. Eventually, we should.

repo: modin-project/modin


text:
Unable to locate remote module in correct registerRemotes shareScop

Describe the bug
console output：
Uncaught (in promise) Error: [ Federation Runtime ]:
        Unable to locate pcyyBase/components/BottomBar/ChannelBottomBar in MFBottom. Potential reasons for failure include:

        1. pcyyBase/components/BottomBar/ChannelBottomBar was not included in the 'remotes' parameter of MFBottom.

        2. pcyyBase/components/BottomBar/ChannelBottomBar could not be found in the 'remotes' of MFBottom with either 'name' or 'alias' attributes.
        3. pcyyBase/components/BottomBar/ChannelBottomBar is not online, injected, or loaded.
        4. pcyyBase/components/BottomBar/ChannelBottomBar  cannot be accessed on the expected.
        5. The 'beforeRequest' hook was provided but did not return the correct 'remoteInfo' when attempting to load pcyyBase/components/BottomBar/ChannelBottomBar.

the code:
registerRemotes([
  {
    name: 'MFBottom',
    entry: 'xxx1.js',
  },
]);

loadRemote('MFBottom/xxx')

registerRemotes([
  {
    name: 'pcyyBase',
    entry: 'xxx2.js',
  },
]);

loadRemote('pcyyBase/components/BottomBar/ChannelBottomBar')

ChannelBottomBar is a module of pcyyBase, but the module federation runtime looks for it from MFBottom.!!!!
Reproduction
the code is show in Describe
Used Package Manager
pnpm
System Info
chorme latest

Validations

[X] Read the docs.
[X] Read the common issues list.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Module federation issue and not a framework-specific issue.
[X] The provided reproduction is a minimal reproducible example of the bug.

it will be ok after add await like this
registerRemotes([
  {
    name: 'MFBottom',
    entry: 'xxx1.js',
  },
]);

await loadRemote('MFBottom/xxx')  // add the await here

registerRemotes([
  {
    name: 'pcyyBase',
    entry: 'xxx2.js',
  },
]);

loadRemote('pcyyBase/components/BottomBar/ChannelBottomBar')

+1

please provide the reproduction repo

Too much content is encapsulated in the project, making it difficult to create a demo. Specifically, when calling loadRemote, the value of host.options. remotes should be reset to an empty array. Currently, we expose init, registerRemotes, and loadRemote to Windows and load them into HTML using script. JS bundles are packaged using TSUP. Let's pinpoint where the problem lies

I find the problem When externals libs
    '@module-federation/runtime': `MFRuntime`,
    '@module-federation/sdk': `MFSDK`,

and MFRuntime,MFSDK in windows:wndow.MFSDK window.MFRuntime

The runtime is stateful. It cannot be externalized currently. We will work on a feature to do so in the future but this will absolutely not work today.
I'm about to introduce hoisted runtime which is the first half of supporting capabilities to share the runtime package.
Try not externalizing the runtime and let me know

fixed it https://github.com/module-federation/core/pull/2930

authors: 2heal1 ScriptedAlchemy ckken doerme

repo: module-federation/core


text:
Error loading remotes with "_" in the entry name

Thanks for all the hard work on the plugin! I was testing a few scenarios and ran into an issue where I have a remote name "vite_webpack" and it was replacing the "_" with "/" in the remote name and causing some failures.
The code causing the issue is here:
https://github.com/module-federation/vite/blob/4291753aaddc6ee54a6439ad9525cb7721f1f0e5/src/plugins/pluginProxyRemotes.ts#L41
I am not sure all the cases to cover here, but I was thinking maybe we can solve it like this:
matchRemotesList.forEach((matchValue) => {
          const parts = devRemoteModuleName?.split(matchValue);
          if (!parts) return;
          const processedParts = parts.map((part, index) => {
            if (index === 0) {
              // Process the part before matchValue
              return part.replace(/\//g, '').replace(/_/g, '/').replace('.js', '');
            } else {
              // Process the part after matchValue
              return matchValue + part.replace(/\//g, '').replace(/_/g, '/').replace('.js', '');
            }
          });
          const processedDevRemoteModuleName = processedParts.join('');
          if (!processedDevRemoteModuleName) return;
          return generateRemotes(processedDevRemoteModuleName, command);
        });

Basically only try to normalize/parse the pieces after the remove name or before. But not the actual remote name. I am not sure all the implications to call it a fix :)

Thank you for your fix, but I have deleted this code recently when I was compatible with nuxt. I will release a new version in the next two days. The latest code will not have this problem.

That's great @zhangHongEn
Looking forward to seeing your PR

Sorry, I need to clarify that I haven't completed nuxt yet. The next PR will support manifestion.json
---- Replied Message ----
| From | Giorgio @.> |
| Date | 09/15/2024 00:43 |
| To | module-federation/vite @.> |
| Cc | zhn @.>,
Mention @.> |
| Subject | Re: [module-federation/vite] Error loading remotes with "_" in the entry name (Issue #85) |
That's great @zhangHongEn
Looking forward to seeing your PR
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

Closed by #86

authors: RussellCanfield gioboa zhangHongEn

repo: module-federation/vite


text:
Fix typo in the Textarea story name

Was playing around with the radix storybook and found this small typo.
Before:

After:

Thanks @Tom-Bonnike!

authors: Tom-Bonnike benoitgrelard

repo: modulz/radix


text:
Styles not applied on deployed/built site

Bug report
Describe the bug
In for example Next.js, when running
yarn build

and then
yarn start

And then going to localhost:3000, the styles don't seem to get applied until the next rerender or something.
To Reproduce
Build for example a button component with a lot of different variants. When using it, pass the props using state hooks.

Make sure it works in dev mode
Build project
Run built project
See the styles not being applied until the state hook changes

Expected behavior
The initial style should be applied as it gets in dev mode
Screenshots
Dev (first render)

Built (first render)

After changing one of the dropdowns (ie. updating props) it will look as expected
System information

OS: macOS
Browser: Chrome
Version of Next.js: 9.5.3

Additional context
Repository
Demo

Thanks for submitting this @albingroen
looking into this now

Hey @albingroen
Looking at your repo, it seems that you don't have SSR setup
Alternatively, you could also use our nextjs stitches template by creating a next project using the following command:
npx create-next-app --example with-stitches

Will be closing this issue now as you haven't configured SSR in your next project.
Let me know if you need any help.

authors: albingroen hadihallak

repo: modulz/stitches


text:
Build error for linux 5.0 beta

sudo apt reinstall libjsoncpp1 libsecret-1-0 libjsoncpp-dev libsecret-1-dev -y
~/Documents/flutter_secure_storage/flutter_secure_storage/example$ flutter drive --target=test_driver/app.dart
Running "flutter pub get" in example...                                ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ 2,138ms
Multiple devices found:
Linux (desktop) ï¿½ï¿½ï¿½ linux  ï¿½ï¿½ï¿½ linux-x64      ï¿½ï¿½ï¿½ Ubuntu 20.04.1 LTS 4.19.76-linuxkit
Chrome (web)    ï¿½ï¿½ï¿½ chrome ï¿½ï¿½ï¿½ web-javascript ï¿½ï¿½ï¿½ Google Chrome 90.0.4430.93
[1]: Linux (linux)
[2]: Chrome (chrome)
Please choose one (To quit, press "q/Q"): 1
CMake Error at /usr/share/cmake-3.16/Modules/FindPkgConfig.cmake:463 (message):
A required package was not found
Call Stack (most recent call first):
/usr/share/cmake-3.16/Modules/FindPkgConfig.cmake:643 (_pkg_check_modules_internal)
flutter/CMakeLists.txt:28 (pkg_check_modules)
Building Linux application...                                          ï¿½ï¿½
Unable to generate build files

Are you using the Snap version of flutter?

Please try the following: https://github.com/mogol/flutter_secure_storage/issues/213#issuecomment-796829086

authors: juliansteenbakker talhabalaj tmtong


text:
Breakdown hub.go

When a new block comes in, send it to some processing queue
Processing queue will process them one at a time,(like what we do). IT will concurrently call geth to get the information it needs instead of one transaction at a time, should use BatchRPC and Go Routins
Then it passes the result to the Aggegator Queue. and passes the result to the subscription channel
The aggregator queue will be processed once every minute. It will do a bunch of aggegations many metrics
The latest entry per aggregation type (minute, hour, day, week, month, year) would be stored in memory and remaining persisted to disk (after that aggregation completed)
Now the hard part is how to serve these in real-time, the aggregation we stored in memory will be streamed to all users as well in its own aggregator Channel

It is broken down with stats

repo: mohamedmansour/ethereum-burn-stats


text:
moleculer-bull: Queue events are called several times simultaneously.

Hi,
i dont know if i do something wrong or if it is a bug, but I am currently confronted with a problem, where the events of the queue cause multiple calls.
Here is some code to reproduce it:
mixins: [
         QueueService(),
     ],

     actions: {
         start: {
             async handler(ctx) {
                 const job = await this.createJob('auto.fight', { blah: 'blah' });

                 const failed = await this.getQueue('auto.fight').on('failed', async (job, error) => {
                    this.logger.error(`An error occured in 'auto.fight' queue on job id '${job.id}': ${error.message}`);
                 });

                 const completed = await this.getQueue('auto.fight').on('completed', async (job, res) => {
                    this.logger.info(`Job with the id '${job.id}' completed.`);
                 });

                 const stalled = await this.getQueue('auto.fight').on('stalled', async (job) => {
                    this.logger.warn(`The job with the id '${job} got stalled!`);
                  });
             }
         }
     },

     queues: {
         'auto.fight': {
             async process(job) {
                 this.logger.info(`Processing queue...`);
                 const accounts = await this.broker.call('v1.users.list');
                 this.logger.info(accounts);
                 return Promise.resolve({ id: job.id, worker: process.pid });
             }
         }
     },

I also tried to use done as return return { done: true , worker: process.pid }
It seems that only the events got fired multiple times the job is processed only once.
best regards
Probber

I think you call the start action multiple times which makes the event subscriptions. Move this code part into the service started event handler, instead.

authors: DerProbber icebob

repo: moleculerjs/moleculer-addons


text:
Mollie module giving errors

Since a couple of days, the module is only giving errors, which resulting in being unable to reach the site and change the payment status.
Customers  dont recieve any info, not knowing if the payment was succesfull, or recieving an error the paymant has failed, but actually not failed since i recieve them and payment is done.
Also module will not update, followd the instructions, installed again, but still listing as version 1.3 while files from the new update are on the server.

Also same errors as listed below, saying the API is not right( it is) or that the cart has already been used.
The first store never had any issues with returning the cart status. But the second now doesn't get some things work. I am using Mollie payment module. ( https://github.com/mollie/Prestashop ). The shop is NOT in maintenance mode during the tests.
Order is correctly handled -> Payment is accepted in the order screen (only sometimes, most of them fail to show this)
Customer gets screen with 'no final payment status'
Customer gets NO e-mail of confirmation.
SSL is enabled.
The error in the log is the following:
" Frontcontroller::init - Cart cannot be loaded or an order has already been placed using this cart "

Hi @loetje88 ,
We are Mollie's prestashop partner and we also provide support for Prestashop. Could you please contact us at info@trendweb.nl so we can provide you with a sollution?
Regards

Hi trendweb!
just replied by mail :)
regards

repo: mollie/PrestaShop


text:
Daylight Saving Time(DST) problem

Due to DST the hour change in my country (Cuba) from GMT -5  to GMT -4 last saturday (March 11) - sunday(March 12)
https://www.timeanddate.com/time/dst/2017.html
But if I execute in Chrome  Console  the following commads the current week is not end at saturday as I expect it
Previous week  is OK

moment().add(-1, 'week').startOf('week')
Moment {_isAMomentObject: true, _isUTC: false, _pf: Object, _locale: Locale, _d: Sun Mar 05 2017 00:00:00 GMT-0500 (CST)…}
moment().add(-1, 'week').endOf('week')
Moment {_isAMomentObject: true, _isUTC: false, _pf: Object, _locale: Locale, _d: Sat Mar 11 2017 23:59:59 GMT-0500 (CST)…}

Current Week # (Problem!!)

moment().startOf('week')
Moment {_isAMomentObject: true, _isUTC: false, _pf: Object, _locale: Locale, _d: Sun Mar 12 2017 01:00:00 GMT-0400 (CDT)…}
moment().endOf('week')
Moment {_isAMomentObject: true, _isUTC: false, _pf: Object, _locale: Locale, _d: Sun Mar 19 2017 00:59:59 GMT-0400 (CDT)…}

Next Week (OK)

moment().add(1, 'week').startOf('week')
Moment {_isAMomentObject: true, _isUTC: false, _pf: Object, _locale: Locale, _d: Sun Mar 19 2017 00:00:00 GMT-0400 (CDT)…}
moment().add(1, 'week').endOf('week')
Moment {_isAMomentObject: true, _isUTC: false, _pf: Object, _locale: Locale, _d: Sat Mar 25 2017 23:59:59 GMT-0400 (CDT)…}

the problem is just on this week the DST apply
Other information

console.log( (new Date()).toString())
Fri Mar 17 2017 19:35:32 GMT-0400 (CDT)

console.log((new Date()).toLocaleString())
3/17/2017, 7:36:00 PM

console.log( (new Date()).getTimezoneOffset())
240

console.log( navigator.userAgent)
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

console.log(moment.version)
"2.17.1"

Regards
Yo.

Yeah, startOf and endOf are buggy with DSTs. Going to close this as a duplicate of #2749 because I suspect it's the same issue.

authors: icambron ynoval

repo: moment/moment


text:
Update moment-with-locales.js

Fix issue https://github.com/moment/moment/issues/4842

Coverage remained the same at 88.135% when pulling fa9fc392ba9930c6be85667050742af12bd0ee97 on mvaldetaro:develop into c68b4f111c9bedfb00b96652fde09ae78138e3ee on moment:develop.

You shouldn't edit the minified files.
I also don't think this will solve the problem.

authors: coveralls marwahaha mvaldetaro


text:
[bugfix] Fix TypeScript warning

Changes

Fix typescript warnings and add test cases

@Alanscut is this related to an existing issue?

@Alanscut is this related to an existing issue?

no. there are 2 moment.d.ts files,  I compared and validated locally, this PR could fix this warning.

What warning are you talking about?

@Alanscut any updates?

authors: Alanscut marwahaha


text:
MAXO:0035116	oncologist evaluation

MAXO:0035116	oncologist evaluation

This term already exists as 'medical oncologist evaluation'...mainly called medical oncologist because of abms.org website. Will add oncologist evaluation as a synonym.
please use MAXO_0000691 for future use.

I think in this context, "Medical" oncologist can be the synonym, people will search first under plain "Oncologist evaluation"!

authors: LCCarmody pnrobinson

repo: monarch-initiative/MAxO