text:
Lesionwise metrics for Competitions

N/A
Proposed Changes

Lesion-wise Metrics calculations for all Brats 2023 challenges
Lesion-wise Metrics calculations for all FeTS 2024 challenges

Simple run can be performed -
 gandlf_generateCompetitionMetrics -c "FeTS-2024" -i ./trial_gandlf.csv -o './metric_trial.yaml'

Checklist

[x] CONTRIBUTING guide has been followed.
[x] PR is based on the current GaNDLF master .
[x] Non-breaking change (does not break existing functionality): provide as many details as possible for any breaking change.
[x] Function/class source code documentation added/updated (ensure typing is used to provide type hints, including and not limited to using Optional if a variable has a pre-defined value).
[x] Code has been blacked for style consistency and linting.
[x] If applicable, version information has been updated in GANDLF/version.py.
[x] If adding a git submodule, add to list of exceptions for black styling in pyproject.toml file.
[x] Usage documentation has been updated, if appropriate.
[x] Tests added or modified to cover the changes; if coverage is reduced, please give explanation.
[x] If customized dependency installation is required (i.e., a separate pip install step is needed for PR to be functional), please ensure it is reflected in all the files that control the CI, namely: python-test.yml, and all docker files [1,2,3].

recheck

hi @rachitsaluja - I am going to mark this PR as draft. Please fix the failing tests, sign the CLA and then mark this PR as ready for review.

recheck

@sarthakpati Would you be able to see why Codacy throws minor errors?
I could probably try to fix 2 of them, but for the __init__.py in cli, I am not sure what needs to be changed. Any thoughts?

Hi @rachitsaluja, you have indicated in your PR that the new additions have corresponding unit tests that cover all added code. However, the changed files do not indicate this:

Are you sure the unit tests have been updated to ensure that the new additions are invoked? Perhaps a commit push is missing somewhere?

@sarthakpati the lesion-wise unit testing is tied up with the test data for all of the competitions and I cannot make that public. The hyper-parameters for the lesion-wise metrics are tied closely with the test data. I could just use two equal masks but that test wouldn't be helpful. How would you like to proceed?

@sarthakpati , I have added my tests now but I am not sure why codecov is not invoked? I have not worked with it so I am unaware.

@VukW Thanks for helping me out today. The new tests in the workflow passed as well. Still not sure why codecov is not invoked.
https://app.codecov.io/gh/mlcommons/GaNDLF/pull/866 Continues to show no information.

This is extremely weird. I have opened a discussion post with them here: https://github.com/codecov/feedback/discussions/368
Additionally, I just pushed a dummy commit on another PR (https://github.com/mlcommons/GaNDLF/pull/864/commits/8b928526e5c5cca6effdc46200c87594f6df009c) to test the code coverage.

@sarthakpati Thanks for the help! I appreciate it.

hey @rachitsaluja, I still haven't heard from the codecov team about this. The test commit I did on the other PR worked as expected. Can I perhaps ask you to base your PR off of the new API branch instead of the current master? An additional reason behind this is that the current master API is due to be deprecated soon, and one of the major changes will be the way CLI apps are being invoked. I have a couple of additional suggestions to improve your PR:

Could you extend this function instead of writing something specifically for a challenge by putting a new use case (i.e., problem_type == "segmentation_brats")? This will negate the need for a separate script, as you can invoke this use case using the current generate metrics app. This will ensure clarity for future extensions/maintenance.
Also, could you put the actual metric calculations in this submodule? This will ensure that all metrics-related code stays in the same place, thereby improving code clarity.

@sarthakpati Thanks for you comments and your effort to work with codecov. Please find my comments below for your questions.

The test commit I did on the other PR worked as expected. Can I perhaps ask you to base your PR off of the new API branch instead of the current master?

I can base my PR of the new APIs branch. Could you send me the documentation for it? I don't know where all the CLI python code went compared to the master branch, or anything about this new branch.

Could you extend this function instead of writing something specifically for a challenge by putting a new use case (i.e., problem_type == "segmentation_brats")? This will negate the need for a separate script, as you can invoke this use case using the current generate metrics app. This will ensure clarity for future extensions/maintenance.

I could probably do this but I have concerns, the present generate_metrics.py needs a Configuration file which consists of a lot of other things that actually is not needed to compute the metrics. My script doesn't need a config file and just needs an argument of which competition's metrics we need to run.

Also, could you put the actual metric calculations in this submodule? This will ensure that all metrics-related code stays in the same place, thereby improving code clarity.

For this, I don't think integrating it within the same script is helpful to users. These "Lesion-wise" Metrics are carefully curated metrics with particular hyper-parameters for sub-challenges and future challenges and not for a normal use. And the sheer difference in metrics in challenges will be known this year again and I think it should be a separate entity.
I think we should think of the competition code as a separate entity just to be clear to the users. It makes it much easier for users who are participating in the competitions to use GaNDLF as it can be confusing for a few folks and this way they don't need learn the GaNDLF workflow to compute simple metrics.
I will be happy to discuss more.

Replies are inline.

@sarthakpati Thanks for you comments and your effort to work with codecov. Please find my comments below for your questions.

The test commit I did on the other PR worked as expected. Can I perhaps ask you to base your PR off of the new API branch instead of the current master?

I can base my PR of the new APIs branch. Could you send me the documentation for it? I don't know where all the CLI python code went compared to the master branch, or anything about this new branch.

Great! There is no explicit documentation about the new API branch, yet. The branch itself is in https://github.com/mlcommons/GaNDLF/tree/new-apis_v0.1.0-dev. As I mentioned earlier, the major changes here are related to the CLI, and if you are extending the metrics submodule as suggested, you won't need to add a new CLI app.

Could you extend this function instead of writing something specifically for a challenge by putting a new use case (i.e., problem_type == "segmentation_brats")? This will negate the need for a separate script, as you can invoke this use case using the current generate metrics app. This will ensure clarity for future extensions/maintenance.

I could probably do this but I have concerns, the present generate_metrics.py needs a Configuration file which consists of a lot of other things that actually is not needed to compute the metrics. My script doesn't need a config file and just needs an argument of which competition's metrics we need to run.

I would suggest you keep in line with the interface that is already provided so that there is a uniform user experience. Otherwise, this will simply add to the maintenance responsibilities of the framework.

Also, could you put the actual metric calculations in this submodule? This will ensure that all metrics-related code stays in the same place, thereby improving code clarity.

For this, I don't think integrating it within the same script is helpful to users. These "Lesion-wise" Metrics are carefully curated metrics with particular hyper-parameters for sub-challenges and future challenges and not for a normal use. And the sheer difference in metrics in challenges will be known this year again and I think it should be a separate entity.

I understand that these metrics are for challenges, but even so, integrating them into a larger framework means that their maintenance and continued code support falls on the shoulders of the framework maintainers. For this reason, I would still recommend that you integrate it with the current generate metrics functionality.

I think we should think of the competition code as a separate entity just to be clear to the users. It makes it much easier for users who are participating in the competitions to use GaNDLF as it can be confusing for a few folks and this way they don't need learn the GaNDLF workflow to compute simple metrics.
I will be happy to discuss more.

GaNDLF's metrics module is fairly independent of the training/inference aspects of the framework [ref], and a user need not learn that to use metrics. As a "compromise", might I suggest that if the config for contains problem_type: "segmentation_brats", no other config needs to be checked, and you can initialize parameters as needed under that specific use case? This will allow the code to be fairly independent while being callable through the metrics module. Thoughts?

Pinging @rachitsaluja for any update.

authors: rachitsaluja sarthakpati

repo: mlcommons/GaNDLF


text:
GW15K-ET cannot connect with version 0.9.9.14

Using 0.9.9.14 I get an error in the log that Goodwe platform is not available. 0.9.9.13 is working fine.
Inverter GW15K-ET.

Update HA to 2024.2.1 and/or show the log

Ohh.. Thanks. I think I'll wait for https://github.com/mletenay/home-assistant-goodwe-inverter/issues/249 before I update anything.

source: gharchive/issue

authors: Brumhilde mletenay

repo: mletenay/home-assistant-goodwe-inverter

license: MIT

license_type: permissive

license_source: github-api


text:
$LOW_FIELD_FILENAME_* as defined in LibreOfficeWriter_Constants.au3

This is first time when Const description from function headers are moved to LibreOfficeWriter_Constants.au3
All others cases should be similarly changed.

This is first time when Const description from function headers are moved to LibreOfficeWriter_Constants.au3
All others cases should be similarly changed.

Should be done in the future.

source: gharchive/pull-request


text:
[Bug] Worklist to Saved Schedules sync should only sync the correct term

Worklists can have courses in both terms, while saved schedules are only for one term. When syncing from a worklist to a saved schedule, the extension should only try to sync courses in the worklist that are in the same term as the target saved schedule.

Note to whoever fixes this in the future: problem is that we don't filter by term, only by worklist, when passing sections to the sync handler (see the sections prop when Form is created in App.tsx). should be easily solvable by adding a helper that removes all sections not in the current term before passing them into Form.

Closing as resolved

repo: mlool/workday-calendar-extension


text:
mlperf-mlbox sprint #2

Aug 24 - Sept 4
Goals

Work towards 0.1 release for Reference Implementation for Training WG.

Milestone date : Dec -10 - 2020

closing sprint-2

repo: mlperf/mlbox


text:
Cannot find module 'gulp-jsdoc3'

Hi @mlucool,
thanks for picking up this project.
When running npm install gulp-jsdoc3 and trying to include it in my gulp file I get an error saying Cannot find module 'gulp-jsdoc3'.
I looked inside node_modules/gulp-jsdoc3 and it seems the index.js is missing…
Any ideas?
Thanks
Felix

I am unable to reproduce this. What version of node/npm are you using?
Can try to delete and reinstall? Maybe you ran out of space or the package didn't download correctly.

The versions shipped by my distro are fairly old: npm: v1.3.10, nodejs: v0.10.25.

Can try to delete and reinstall? Maybe you ran out of space or the package didn't download correctly.

Did that already, didn't work. Other gulp packes work though.

Using tonic I am unable to reproduce with v0.10.40.
Can you provide some way for me to reproduce?

Using tonic I am unable to reproduce with v0.10.40.

Hmm I see that. Strange. I tested on another computer also running Linux Mint 17 with the same node/npm packages installed and it also failed. – Really, no idea.

The output of $ ls node_modules/gulp-jsdoc3/ is
dist  docs  node_modules  package.json  README.md  src

No index.js

Try including it from git directly. I just pushed something that although should not be needed, would get around the bug that may be in your version.

Will try. Wait a sec.
Did you see this: https://github.com/npm/npm/issues/5082

Yes, index.js is now included

Ok, I'll mark as closed now. By default anything listed as main is assumed to be in files, but likely you have a bug in your version. I'll re-release in the near future.

Ehm, @mlucool, you won't believe: now the dist folder is missing.

Ok, I'll mark as closed now. By default anything listed as main is assumed to be in files, but likely you have a bug in your version. I'll re-release in the near future.

This is a bit crazy, I hope I can update my node/npm soon.

Actually, where is the dist folder on your repo?

Try 0.1.1 that I just released. Dist is build only for the release and not committed. Your version of npm seems to have quite a few bugs/issues. Current version of npm would have rebuild the project you depend on from git

Try 0.1.1 that I just released

:+1: Thanks works now.

Your version of npm seems to have quite a few bugs/issues. Current version of npm would have rebuild the project you depend on from git

Really? Well, I hope to get a chance to update soon…

authors: felixhayashi mlucool

license_source: bigquery


text:
Backwards incompatible API-change in 2.16

Hi,
version 2.16 remove cmsGetToneCurveParams(). While the change was intentional, this has broken backward compatibility: 03020d0fdd0f8a79f275657ad1ff757fe2cc4192
The function was not documented, but nonetheless part of the public API. I see two possibilities here:

Re-introduce the function (maybe with a deprecation warning).
Bump the SONAME.

IMHO anything that's undocumented (and accessible) is "use at your own risk." It could go away or change at any time and is not supported. Those functions exist because testing or  other reasons but are not intended for normal operation.
Validating this would encourage the use of other undocumented functions. And I dont want this because it means supporting bug reports, adding test cases etc.

That's rather unfortunate. A few years ago I asked if there is a way to access the parametric constants for tone curves. I was suggested to use cmsGetToneCurveParams, but evidently that's no longer available in v2.16.
https://github.com/mm2/Little-CMS/issues/218

Closing it as not planned

Please don't take my above comment the wrong way. I was merely saying it's an unfortunate situation for us that relied on those undocumented features. And I agree, the responsibility (and the consequences) for using private APIs rests on our shoulders. I did not intend lay blame on you or anyone for these breaking changes, other than myself.

You were told a function would be added to development sources

It was on testing from 2.11 to 2.16 where it finally made its way to the public API

I'm sorry, I must have missed this change in the public API. I skimmed through the ChangeLog, but I could not find notes about new features that queries Tone Curve parametric constants. I'm assuming cmsGetToneCurveSegment is now the correct way to get this data?

Please remember this is open source under MIT license, basically you have the code for free but with no support. That means you need to do a check when upgrading and keep track of this kind of things. If this does not fit your needs, I would recommend to go to any commercial library.

Yes, I am fully aware. And I am actually very grateful for the effort you put into maintaining this project. Thank you!

authors: DominikDeak mm2 thomas-weber


text:
Some dates are not displayed at all

Environment

real device. iPhone 8
Platforms

iOS
Versions

Android: 4.0 AI-193.6911.18.40.6626763
iOS: 11.4.1/11E503a - /usr/bin/xcodebuild
react-native-modal-datetime-picker: "^8.7.1",
react-native-community/datetimepicker: "2.4.0"
react-native: https://github.com/expo/react-native/archive/sdk-38.0.2.tar.gz => 0.62.2
react: 16.11.0

Description

On some iOS devices (not all) there is some strange behaviour where the picker doesn't display all dates:

As suggested on the issue template, I tried using @react-native-community/datetimepicker and it worked as expected. (Edited)
Reproducible Demo
I pasted some relevant parts of my component for some context.
...
const [value, setValue] = useState();
const [showDatePicker, setShowDatePicker] = useState(false);
const show = useCallback(() => {
	setShowDatePicker(true);
}, [setShowDatePicker]);
const hide = useCallback(() => {
	setShowDatePicker(false);
}, [setShowDatePicker]);

const setDate = useCallback(
	(date: Date) => {
		setShowDatePicker(false);
		const newDate = moment(date);
		setValue(newDate);
	},
	[setShowDatePicker, setValue]
);

<View style={localStyles.container}>
	<View style={localStyles.dateContainer}>
		<Text style={[localStyles.date, localStyles.label]}>{label}</Text>
		<TouchableOpacity onPress={show}>
			<Text style={localStyles.date}>{displayDate}</Text>
		</TouchableOpacity>
	</View>
	{showDatePicker && (
		<View style={localStyles.datePickerContainer}>
			<DateTimePickerModal
				isVisible={showDatePicker}
				mode="datetime"
				headerTextIOS={"Set time"}
				minimumDate={minimumDate.toDate()}
				maximumDate={maximumDate.toDate()}
				onConfirm={setDate}
				onCancel={hide}
			/>
		</View>
	)}
</View>

Thanks in advance!
Let me know if I can give you more info. I'm using this package mainly to support android devices but it would be nice to still use it for iOS.
Edited

I can also confirm this with expo sdk 38, react-native-modal-datetime-picker ~> 8.7.1, and @react-native-community/datetimepicker ~> 2.1.0.
I tried to force a light theme with userInterfaceStyle but does not seems to work.
Using colorScheme from react-native works but breaks when the theme is changed while the app is running. Have to restart the app to make it work again.

How's it different from:

https://github.com/mmazzarolo/react-native-modal-datetime-picker#is-the-ios-dark-mode-supported
and https://github.com/mmazzarolo/react-native-modal-datetime-picker#i-cant-see-the-picker-on-iosthe-picker-is-white-on-ios
?

I can confirm it happens when dark mode is on. I see now you've had a bunch of similar issues being opened (apologies for being one more, I thought I had to opt-in to support dark mode).
To solve this I was forced to support dark mode by using https://docs.expo.io/versions/latest/sdk/appearance/:

I've added "userInterfaceStyle": "automatic", on app.json,
used the useColorScheme hook to detect the mode and
used the DateTimePickerModal prop isDarkModeEnabled={colorScheme === "dark"}

No worries :)
Yeah this theming thing is confusing, especially on Expo... not much that we can do on our side to fix it though :/

I'm trying to force light theme by providing "userInterfaceStyle": "light", but picker is not respecting the light theme when dark mode is enabled. Anything we can do about this?

@maharjanaman please see

https://github.com/mmazzarolo/react-native-modal-datetime-picker#is-the-ios-dark-mode-supported
and https://github.com/mmazzarolo/react-native-modal-datetime-picker#i-cant-see-the-picker-on-iosthe-picker-is-white-on-ios

and @dmdmd solution's above ☝

or wait for #458

Supporting dark-mode because of this component gave me trouble on other parts of my app. So I reverted to supporting only light mode.
But even with version "8.9.3" I still have this bug. And "@react-native-community/datetimepicker" works correctly.

hey @dmdmd , sorry to hear that. If you could provide a (complete) reproducible example of the issue that would be great. I tested the example project and it works correctly for on iPhone 11 (both dark and light mode).

My code is the same as above.
Did you try adding "userInterfaceStyle": "light" on your app.json and enabling dark-mode on your device?
I think I tracked down the issue to the usage of DatePicker inside a Modal (I replaced the Modal from react-native-modal-datetime-picker code with a View and the bug didn't manifest). I'm not sure if the Modal component is respecting the light mode rule...

authors: dmdmd maharjanaman mmazzarolo

license: mit


text:
Searched history

Thanks for this great project! I'm using this in conjunction with AutoTorrent. I'm currently just running a full search every 6 hours so that I'm not hammering jackett or the indexers, this works well, but I was thinking of ways to increase frequency in order to maximize the potential upload bonus. I was thinking that maybe adding another file to the .cross-seed where the torrents unique identifier as well as a timestamp for the first seen and last search time could open up the possibility to do date-based invocations and running different sync types at different intervals.
The use case would be, if you are scheduling this via cron, you could:
Every minute, only search torrents that have been added since the last run to catch newly grabbed torrents that may already exist on other trackers.
Every X minutes, search torrents recently added that haven't been searched in Y minutes to catch newly grabbed torrents that have just been added on another tracker
And then run a full sync daily or something.

Glad you like it! That's actually part of my next planned feature, #10. Right now the cache is incredibly barebones, and storing a lot more data in the cache will let cross-seed do things like unseen-only searching, etc. I'm not sure when I'll have time to work on it but probably by the end of the year.
Until then, have you checked out daemon mode? I'm working on improving support for it, and would love to hear suggestions. I'm pretty sure I'm the only user right now so it's very tightly coupled to my own setup.

Cool! I'll checkout daemon mode this weekend. I'm using deluge, not rutorrent, but maybe I'll take a poke at integrating it this weekend if I have time

Cool! The only thing rtorrent-specific is the function getInfoHashesToExclude (at the bottom) which relies on the torrent files being named with their info hashes. if Deluge does this too then it should just work out of the box.
Otherwise, I'm sure a less-performant solution could be easily used instead, something like the following:
function getInfoHashesToExclude() {
	const { torrentDir } = getRuntimeConfig();
	return loadTorrentDir(torrentDir).map((t) => t.infoHash);
}

It ain't pretty; it'll load the full contents of all of your torrent files into memory temporarily, every time you ping the daemon, which could take a few seconds if you have a lot of torrents. My long term solution for this is to remember the info hashes in the cache, but this should work in a pinch. Good luck!
https://github.com/mmgoodnow/cross-seed/blob/b57412c7481c8cc16852e84afedeb121445d0ffd/src/torrent.js#L39-L44

Closed by #25

authors: craigjmidwinter mmgoodnow

repo: mmgoodnow/cross-seed


text:
ci(lint): enable unused linter

Signed-off-by: Matthieu MOREL matthieu.morel35@gmail.com

Pull Request Test Coverage Report for Build 4286798035

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 72.279%

Totals

Change from base Build 4286756884:
0.0%

Covered Lines:
1494

Relevant Lines:
2067

💛  - Coveralls


text:
MAINT: Simplify requirements structure

the pip requirements_* files seem to be multiplying...  is there need/value in specifying them in separate text files rather than directly in setup.py?

for the install shorthands, to me it seems the fewer options the better; something like:

pip install mne  # base
pip install mne[hdf5]  # + hdf5 / export deps; other shortands could be "io" or "export"
pip install mne[dev]  # everything above + doc and testing deps; could also be "all"

so if we find ourselves wanting to add more and more install shorthands as our dependencies evolve, I'd rather think about how to shoe-horn new deps into one of those 3 levels.
Originally posted by @drammock in https://github.com/mne-tools/mne-python/pull/10199#pullrequestreview-855757670

The need/value arises because our CIs make use of them in different ways depending on the different run type (conda, pip, minimal, old, doc-build, notebook, ultraslow, etc.):
$ git grep requirements_
azure-pipelines.yml:        python -m pip install --progress-bar off -r requirements_base.txt -r requirements_hdf5.txt -r requirements_testing.txt
azure-pipelines.yml:    - script: pip install --progress-bar off -r requirements_doc.txt
...
tools/circleci_dependencies.sh: python -m pip install --progress-bar off pillow pytest -r requirements_base.txt -r requirements_doc.txt
tools/circleci_dependencies.sh: python -m pip install --upgrade --progress-bar off --only-binary matplotlib -r requirements.txt -r requirements_testing.txt -r requirements_doc.txt
tools/github_actions_dependencies.sh:   pip install -r requirements_base.txt -r requirements_testing.txt
tools/github_actions_dependencies.sh:   pip install $STD_ARGS $EXTRA_ARGS -r requirements_base.txt -r requirements_testing.txt -r requirements_hdf5.txt
tools/github_actions_dependencies.sh:   pip install $STD_ARGS $EXTRA_ARGS -r requirements_testing_extra.txt

Eventually we could maybe refactor these to all make use of some form of pip install -e .[whatever], but I don't think we should do it in this PR if we decide to go that route. This problem exists to some extent in main so I think we should tackle it separately (even though this PR exacerbates the problem).
Just one counterexample to your suggested hierarchy no give some sense of the problem, requirements_testing.txt is used by all CIs that run pytest, but it can't simply be rolled into something that already includes hdf5 (e.g., dev) because the minimal run should not include h5py (or any doc deps) but does need pytest-related dependencies.
Maybe a good first step would to add comments to the developer docs to lay out more explicitly what each CI job does. This structure would make it clear what each run uses, and why. @GuillaumeFavelier had to suffer quite a bit with this a while back when transitioning to GitHub Actions (from Travis I think?) so this is already a bit overdue. Once that's done, if someone is motivated to propose a structure that would simplify things, having those docs as a reference will make it clearer how it can be done.

I'm going to close this as won'tfix I think, and we can adjust going forward as needed (or if someone comes up with a clear plan)

From @drammock in https://github.com/mne-tools/mne-python/pull/12178#discussion_r1391610123 :

[I think we should suggest that devs install test_extra instead of test...] what motivates me is making it so that new contributors have less to do / think about when setting up environments. IMO they have enough cognitive load learning about how to use pre-commit, pytest, rST, git, etc, so if we can simplify the environment-wrangling / reduce the odds of them hitting missing-dependency-related errors midway through their first contribution experience, then we absolutely should do that if the cost is a few extra MB / tens of seconds during initial environment creation.

I think switching from test to test_extra won't gain contributors much in practice --it will un-skip a small set of tests that are not very super widely developed or changed -- mainly our internal scraper tests, multitaper tests, notebook GUI abstraction tests. The one exception is maybe the extended import/export libs (pybv, EDFLIB-Python, snirf) but these are kind of advanced use cases that necessarily will have those packages installed for anyone working on them, and are generally pretty well isolated from other tests. I can't think of a case in the last year or two where test or test_extra would have helped them at least.
The big win -- and what I think would reduce contributor pain -- would be to give people a way to make sure they have stuff like pandas, scikit-learn, or dipy that are currently only part of full and are used a lot of places -- those can lead to a lot of test skips. These are not part of test_extra.
So instead of modifying test to test_extra (incomplete) or creating dev off of full (Qt problems), we could build dev off of test_extra (even if it's overkill for most devs) and add everything we pytest.importorskip at the moment as well? It will have a lot of redundancies with full but won't be opinionated about Qt. (It's very likely that most devs will have a working Qt binding anyway, so we can just omit it from dev.)
Incidentally, even this dev won't prevent all tests from being skipped because you need MNE-C installed for some of them. But it will at least help the problem!

The big win -- and what I think would reduce contributor pain -- would be to give people a way to make sure they have stuff like pandas, scikit-learn, or dipy that are currently only part of full and are used a lot of places

sounds good so far...

So instead of modifying test to test_extra (incomplete) or creating dev off of full (Qt problems), we could build dev off of test_extra (even if it's overkill for most devs) and add everything we pytest.importorskip at the moment as well

still with you...

It will have a lot of redundancies with full but won't be opinionated about Qt. (It's very likely that most devs will have a working Qt binding anyway, so we can just omit it from dev.)

so this would be better for users who are e.g. missing dipy because they never ran pip install mne[full] --- either because they use conda, or because they never needed mne[full] for their own work (e.g., EEG sensor-space analyses only), or some other reason I haven't thought of --- and who now want to contribute to MNE. Right?

Incidentally, even this dev won't prevent all tests from being skipped because you need MNE-C installed for some of them. But it will at least help the problem!

argh. I think I'm ready to give up this fight. Our dev env is so complicated.

authors: drammock larsoner

repo: mne-tools/mne-python


text:
[MAINT] fix ref link

This fixes the last suboptimal bit of mne.viz.circle.py where there wasn't a reference for the keyword arguments. Needs https://github.com/mne-tools/mne-connectivity/pull/88 so that the arguments are up-to-date.

Thanks @alexrockhill

authors: alexrockhill larsoner


text:
BUG: Better float checking for FT

Closes #8071.
@acquayefrank can you see if this helps with your error at all?

Just going ahead and merging – @acquayefrank if your problem is not fixed, please report back :)

Thanks @larsoner

@larsoner thanks for the help. But I still get the same error even though I'm using this version of the code.  cc @hoechenberger

Can you paste the new traceback in #8071 ?

Hello, @larsoner  I just did.

authors: acquayefrank hoechenberger larsoner


text:
Question on Visitor page view

Hi,
I have a requirement to fetch the Visitor page view objects by using key "visitor_page_view_id" from visitor activity object. Seems that we don't have a direct API object to fetch visitor page view objects.
Can you please help me in finding the right object to fetch visitor page view objects.
Thank you.
Regards,
Surendhar

I'd like to access the visitor page view object using this api, are there any plans to build that feature? I might be able to utilize an existing class to build the feature if there aren't currently plans.

is this repo being maintained?
I don't mind creating a PR adding Visitor Page View and Visitor Referrer - but will there be someone to approve it?

I apologize, I have been largely absent but I will consider & approve PRs
On Wed, Dec 9, 2020, 3:46 PM royt-via notifications@github.com wrote:

is this repo being maintained?
I don't mind creating a PR adding Visitor Page View and Visitor
Referrer - but will there be someone to approve it?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/mneedham91/PyPardot4/issues/21#issuecomment-742039372,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE6IXAFDEAS6DFWEH25ARVTST7O37ANCNFSM4F7PNYXQ
.

authors: def-mycroft mneedham91 royt-via rudrasur


text:
如何实现触发响应?比如收到新邮件或者收到微信等?

我希望agent可以响应像邮箱或者微信这样的新信息提醒,agent可以自动做出操作,这个有什么办法可以实现?

如果是邮箱，应该只能读最后一条吧，读完使用完之后，标为已读，下次再来再读未读的最后一条。

authors: lostingcity wugongxing


text:
ChatGPT安全问题

白皮书：
ChatGPT Security Risks: A Guide for Cyber Security Professionals
https://www.cybertalk.org/wp-content/uploads/2023/03/ChatGPT_eBook_CP_CT_2023.pdf
ChatGPT的安全隐患
http://mtw.so/5TwZBb
博客：
安全测试中的 ChatGPT AI：机遇与挑战    https://www.cyfirma.com/outofband/chatgpt-ai-in-security-testing-opportunities-and-challenges/
ChatGPT 生成代码的安全漏洞    https://www.trendmicro.com/ja_jp/devops/23/e/chatgpt-security-vulnerabilities.html

请提供“ChatGPT的安全隐患”的可用链接；其余已收录。

repo: mo-xiaoxi/GPTSecurity


text:
16 bpc Issue

After a quick try to discover this plugin, which seems awesome, it seems that there is a problem when after effect is in 16bits.
No matter the shader, it outputs a transparent alpha.
Everything works well in 8bits or 32bits
My config:
AE 24.6.2
RTX 3060 Drivers 560.94

Please provide the shader that exhibits this behavior.

This should be fixed in the most recent build. I tested on MacOs although I cannot test on windows at the moment. I will create a new release when I have confirmed it works there.

I tested the build on Windows and it now works in 16bit.
Thanks a lot!

authors: mixsoupe mobile-bungalow


text:
🛑 PizzaRiing Web is down

In 9dc433e, PizzaRiing Web (https://pizzariing.uy) was down:

HTTP code: 0
Response time: 0 ms

Resolved: PizzaRiing Web is back up in abf596c.

repo: mobilitysol/monitorweb


text:
🛑 PizzaRiing Web is down

In bc26ea9, PizzaRiing Web (https://pizzariing.uy) was down:

HTTP code: 403
Response time: 653 ms

Resolved: PizzaRiing Web is back up in 8facb84.


text:
Two questions about this library and realtimes simultaneos connections

Greetings, first I'd like to say thanks for this library.
After reading the docs I have two matters unclear.

If I listen to changed on two nodes for example with multipath, would this count on firebase as 2 simultaneous connections? Or only 1
If I update some values of a node for example with setInt and be done with it, would this count as a connection? As Im not using a stream? Then I would be able to do as many continuous updates no matter connections only data transfer (As example blaze plan is 200k max connections)

Best regards

If your device stay connected, all server event-stream data that pushed to client will not be missed.
You can use different Firebase Data objects for multiple stream sessions, but careful about low memory.
If you have question, use Discussions instead.
The request from all functions that store and read data will count to the transaction count.
The question about Firebase APIs, policies and usages, please contact google or post your question on stackoverflow.
This is the library repository.

authors: efitrillo mobizt

repo: mobizt/Firebase-ESP-Client


text:
Switch to MobX 4 API

See #86

might want to update changelog, this is fairly impt for people just coming into mobx 4 without knowledge of mobx 3

@mendesfelipe87 not sure what "this message" means, but please open new issues rather then commenting on merged PRs

authors: andykog mweststrate tsiq-swyx

repo: mobxjs/mobx-react-devtools


text:
Feat: re-translate for installation one of module

[x] re-translate MobX and Decorators at installation

@iChenLei 辛苦review一下

I am sorry for not reviewing this pull request.

I am sorry for not reviewing this pull request.

It's ok, busy with work and life for anyone, cannot be fixed everything.


text:
Go: fix the handling of defaults over upgrade

Originally we had a single database branch and interpreted

a key being present: a user's setting which must be preserved
a missing key: a "default" value which should be filled in

Since we split the configuration into multiple branches we should always write our default values to the "defaults" branch. The user config goes in the "master" branch, any experimental features are in the "experimental" branch and the final results go in the "state" branch.
This PR

updates the "defaults" branch over upgrades
uncomments and fixes one of the unit tests
adds a new unit test to cover the new desired behaviour

I think the failures are all OCaml related e.g.
The command '/bin/sh -c opam depext -i asl win-eventlog alcotest mtime mirage-flow hvsock     git irmin irmin-unix lwt protocol-9p-unix tyxml redis multipart-form-data     pbkdf tls prometheus-app github git session irmin irmin-unix cmdliner     webmachine alcotest' returned a non-zero code: 1
[2017-07-01 20:36.54] Failed: Command "docker" "build" "--pull" "-f" "Dockerfile.ci" "." exited with status 1

repo: moby/datakit


text:
Why does before each fire after a child describe's before?

Given a (simplified) scenario like this:
describe('foo', function () {
    beforeEach (function (done) {
        deleteAllFoos(done); // clean out tables
    });

    describe('magical model method', function () {
        before (function (done) {
            createTestFoo(done); // create the one record I want to test around
        });

        it ('should be cool', function () {
            // test out what came back from createTestFoo
        });
    });
});

This will insert the test foo in before then call beforeEach and delete the record.
I always found this weird, what is the thought behind it working in this order?

I have notice with mocha 3.2 that a before in the top level describe will run AFTER a before in the nested describe as well.  This seems backwards.

@justinffs can you provide a minimal reproducible example?

@jasonkarns sorry I was mistaken it was just beforeEach that was the issue.

authors: jasonkarns justinffs rschooley

repo: mochajs/mocha


text:
rename "exclude" to "ignore" and create alias; closes #3871

Renamed all occurrences of exclude to ignore, as the latter is now the canonical name
Updated docs to reflect change

Coverage remained the same at 91.704% when pulling 2439e4da4334c1bfa74a32125fe7c7c65bc8ff05 on boneskull/issue/3871 into f1fe632a5aca224994fa8c1240be6852bec236a8 on master.

@mochajs/core any objections?

Have no issue with adding --ignore as cmdline alias for --exclude, but most of the rest just seems like unnecessary churn.
Related but not, I could have sworn many of these "docs/index.md" changes have been made several times over now (e.g., "plain" vs. "text", ["test/"] vs. ["test"]), yet here they are again?

@plroebuck I get the same feeling about those changes... that's why we need to pull  the auto-generated parts of index.md out of VCS.  There's an issue for that, and maybe even a pull request, but haven't checked on its status in awhile

authors: boneskull coveralls plroebuck


text:
Build for NUCLEO_F746ZG - FATAL ERROR MemManage when running hello_world

Hi all,
I have created a build based on the STM32 samples from this repo for NUCLEO_F746ZG with STM32F746ZG. Using a good commit 49521 the compilation and generation of the firmware was successful but when executing the hello_world.py, there was FATAL ERROR MemManage and no more response.
Firmware.elf
 arm-none-eabi-size build/firmware.elf
   text    data     bss     dec     hex filename
 715072     284   83924  799280   c3230 build/firmware.elf

Terminal Output
>>> MicroPython v1.17-333-gcf258c898-dirty on 2022-01-31; NUCLEO_F746ZG MICROLITE with STM32F746
Type "help()" for more information.
>>> import hello_world.py
interpreter_make_new: model size = 2488, tensor area = 2064

FATAL ERROR:
            MemManage

HEAP from Current Micropyhton release
>>> MicroPython v1.18 on 2022-01-17; NUCLEO-F746ZG with STM32F746
Type "help()" for more information.
>>> import gc
>>> gc.collect()
>>> gc.mem_free()
163920

HEAP from this build
MicroPython v1.17-333-gcf258c898-dirty on 2022-01-31; NUCLEO_F746ZG MICROLITE with STM32F746
>>> import gc
>>> gc.collect()
>>> gc.mem_free()
158576

Is there anything else that I can provide for someone to check and provide suggestions on how to debug this ?
Thanks

@jpliew thanks for this report.
I did have a working build for STM32H743ZI2 which worked for hello-world but not micro-speech because there were HAL differences.
I can tell you that the build you are using is definitely not going to work because its from a point in time where the build worked but the program didn't work.
I'm going to spend some time to get the STM32 build working again and/or identify the historical build that was working and you can setup your board at that commit.
the current problem is that the image size is too big.  I have a STM32F405 with 16 MB flash that I plan to use to validate if the code is working and then from there I will find out where the extra size is coming from and remove it.

Thanks @mocleiri , if you need me to test anything, please let me know.

@jpliew sorry for the delay in fixing this.  My first pass I tried to get the builds working and optional ops working but while I got everything compiling it didń´t work when flashed to the device.
I ended up just fixing the build issues for stm32 in #73.
If you rebase your board configs to the latest commit on the main branch you should be able to compile working firmware for the F746ZG board.
The key ingredient to a working build is to  add this option to the mpconfigboard.mk file:
MICROPY_ROM_TEXT_COMPRESSION = 0

I was able to flash the h743zi2 firmware and run hello_world successfully:
https://github.com/mocleiri/tensorflow-micropython-examples/actions/runs/1896970048

Thanks @mocleiri , I will try it and let you know the outcome.
Cheers

authors: jpliew mocleiri


text:
Draft: Emit type stubs

Basically this needs to handle a few things to work:

Create a virtual output module which is to be stubbed.
Add actual python entities (functions, classes, module variables) to be type stubbed in this module's namespace (could often just be the vars of the module, minus any imports)
Traverse all the types used in annotations and make sure the required imports are added to the emitted type stub
Generate source code with annotations and empty bodies

For this to work with synchronicity, we also need to make sure that synchronicity's emitted classes translate things properly with annotations (and some function name translation like __aenter__ -> __enter__). This is handled in the base PR #84
TODOs:

[x] Functions
[x] Classes
[x] classmethod/staticmethod/properties
[x] Class annotations
[x] Module vars
[x] Test with mypy
[x] e2e tests with synchronicity + annotations
[x] Fix regression: *args and **kwargs are now emitted as arguments to wrapped functions... Probably need to skip using inspect.Signature() altogether for function signatures...
[x] Base classes
[x] TypeVars
[x] Forward/Self references ("str" annotations)
[x] cli util for emitting type stub for an input python file

Future improvements:

[ ] Include docstrings
[ ] Include argument comments (this would let us generate even better reference docs for our generated classes too!)
[ ] Generate actual source code and not just type stubs, using the synchronicity base classes as implementation (!)

Nice! Couple of thoughts off the top of my head:

Can you run black on this? (we should set it up to run automatically)
I'm not a super big fan of checking that the output equals a the Python code verbatim. Feels like those assertions will have a high maintenance cost. Is it possible to check for equality in a more fuzzy way, like can you get the AST and make sure it's equal?

This only returns the current interface right? It doesn't translate it to a blocking interface yet right?

This only returns the current interface right? It doesn't translate it to a blocking interface yet right?

Yes, the translation happens in #84 before this code gets the interface handed to it. I intentionally separated the two processes (and PR:s).

In #84 we translate all of the annotations from async to the blocking interface, such that the generated classes have the correct annotations for their "blockyness"
In this PR, we take runtime annotations of any class and output them as source stubs. As it stands this is entirely decoupled from the rest of synchronicity, but works on the generated classes that synchronicity emits. It could be a separate project/package/repo entirely, but I think we'll eventually want to get synchronicity specific stuff in here as well (for example actual source generation based on the annotations...)

Now successfully generates a valid stub for the modal root package: https://gist.github.com/freider/04dd81718dad5fb05c9a982bba082182

authors: erikbern freider

repo: modal-labs/synchronicity


text:
Trying to run cargo kani on firecracker/vm-memory results in goto-cc crash

Running cargo kani on on the vm-memory module of firecracker (even without adding any #[kani::proof] attributes to the code)
unexpected end of input stream
Error: goto-cc exited with status exit status: 70

I tried this code:
https://github.com/firecracker-microvm/firecracker/
using the following command line invocation:
Inside the firecracker repository (assuming a firecracker development environment has been set up), enter the docker container via ./tools/devtool shell -p and install kani in there. Then navigate to src/vm-memory and run cargo kani -p vm-memory@0.3.0.
with Kani version: cargo-kani 0.12.0
I expected to see this happen: kani to not crash
Instead, this happened: kani crashes

This seems to be a spurious error fixed by running cargo clean (see #1591)

repo: model-checking/kani


text:
🛑 Plex is down

In 9c69169, Plex ($PLEX_URL) was down:

HTTP code: 523
Response time: 1029 ms

Resolved: Plex is back up in 7dc3080.


text:
🛑 Tautulli is down

In 6bbad17, Tautulli (https://tautulli.modem7.com/tautulli) was down:

HTTP code: 404
Response time: 630 ms

Resolved: Tautulli is back up in 04b27cb.


text:
🛑 Portainer is down

In 665e849, Portainer ($PORTAINER_URL) was down:

HTTP code: 404
Response time: 409 ms

Resolved: Portainer is back up in a04fd0f.


text:
Switching instrument_file? to be in Instrumentation class

This was done to solve the RequireJS issue (https://github.com/modeset/teaspoon/pull/240), would like to hear your thoughts about this.  Some things:

The reason why this change works with RequireJS is because the decision to instrument is now made in the Sprockets hook, and all RequireJS requests go through Sprockets.
I wasn't sure how to grab the current config so I grabbed the default config with Teaspoon.configuration.suite_configs['default'][:instance].  I can help write specs once this part is figured out.
I was thinking about completely forgoing the addition of instrument=1, but wasn't sure which way to go.  Either way works with RequireJS, as you can add a instrument=1 to the end of every RequireJS request through the urlArgs config.

I'll give this a try and revert if needed.

I removed the stuff you had shifted out of suite, because it was only using the default configuration -- which broke some specs, and seems short sighted.

I now understand what the changes were, but don't fully understand the need for them.. can you explain further?

If I understand correctly, you need to instrument files that are being loaded via requirejs, and thus the instrument=1 param isn't present. I'll poke around a bit, and understand the desire for it, but absolutely abhor having to do shims in teaspoon to support requirejs -- it's at an entirely different level, and one I happen to disagree with.
If it can come at a different layer, it would be better. So the ideas I've kicked around, but can't quite resolve are to add an additional configuration -- but even that doesn't work well, and the core reason is that the instrumentation determination has to come at the level when a file is requested -- with all the context of the configuration used during the test run -- which is not possible when an asset is requested.

I've just opened #315 that simply adds an option to RequireJS from within the boot view which adds instrument=1 to all requests made through require.

I'm sorry I probably can't explain the reasoning as well as I could have, since I haven't looked at this code for a while now haha.  I think your analysis is pretty on point, here is my best guess to what I was thinking at the time:

I forget exactly why, but I believe the requirejs files didn't get the &instrument=1  through Teaspoon::Suite#asset_url.  However, you can around it in requirejs by adding instrument=1 to all files through the config like what @davestevens said
So then, all of the files have instrument=1, but the no_coverage files were not filtered out.  I guess this is why I switched the no_coverage check to Teaspoon::Instrumentation (which can filter the requirejs files because requirejs also goes through Sprockets)

Sorry for the code sloppiness - this was meant to be more of exploratory pull than one with production ready code.  Just wanted to get your thoughts on it because I wasn't really considering how this would impact the non-requirejs use cases of teaspoon.

authors: davestevens golmansax jejacks0n

repo: modeset/teaspoon


text:
BUG: read_csv with iterator=True throws AttributeError

Modin version checks

[X] I have checked that this issue has not already been reported.

[X] I have confirmed this bug exists on the latest released version of Modin.

[ ] I have confirmed this bug exists on the main branch of Modin. (In order to do this you can follow this guide.)

Reproducible Example
import modin.pandas as pd
df_iter = pd.read_csv('path/to/file.csv', iterator=True)

Issue Description
AttributeError: 'TextFileReader' object has no attribute 'columns'
Expected Behavior
returns TextFileReader.
Error Logs

...
venv/lib/python3.10/site-packages/modin/core/io/text/text_file_dispatcher.py", line 1062, in _read
    column_names = pd_df_metadata.columns
AttributeError: 'TextFileReader' object has no attribute 'columns'

Installed Versions

pd.show_versions()

INSTALLED VERSIONS
commit           : b5545c686751f4eed6913f1785f9c68f41f4e51d
python           : 3.10.12.final.0
python-bits      : 64
OS               : Linux
OS-release       : 5.10.16.3-microsoft-standard-WSL2
Version          : #1 SMP Fri Apr 2 22:23:49 UTC 2021
machine          : x86_64
processor        : x86_64
byteorder        : little
LC_ALL           : None
LANG             : C.UTF-8
LOCALE           : en_US.UTF-8
Modin dependencies
modin            : 0.23.1
ray              : 2.6.3
dask             : None
distributed      : None
hdk              : None
pandas dependencies
pandas           : 2.0.3
numpy            : 1.25.2
pytz             : 2023.3.post1
dateutil         : 2.8.2
setuptools       : 59.6.0
pip              : 23.2.1
Cython           : None
pytest           : 7.4.1
hypothesis       : None
sphinx           : None
blosc            : None
feather          : None
xlsxwriter       : None
lxml.etree       : None
html5lib         : 1.1
pymysql          : None
psycopg2         : None
jinja2           : None
IPython          : None
pandas_datareader: None
bs4              : None
bottleneck       : None
brotli           : None
fastparquet      : None
fsspec           : 2023.9.0
gcsfs            : None
matplotlib       : 3.7.2
numba            : None
numexpr          : None
odfpy            : None
openpyxl         : None
pandas_gbq       : None
pyarrow          : 13.0.0
pyreadstat       : None
pyxlsb           : None
s3fs             : None
scipy            : 1.11.2
snappy           : None
sqlalchemy       : None
tables           : None
tabulate         : None
xarray           : None
xlrd             : None
zstandard        : None
tzdata           : 2023.3
qtpy             : None
pyqt5            : None

Thanks @SiRumCz! I can reproduce the problem.

authors: SiRumCz anmyachev

repo: modin-project/modin


text:
Style change causes @font-face files to be re-requested from server

Bug report
Describe the bug
Whenever styles change, the browser re-requests any fonts loaded with @font-face.
To Reproduce
Minimal test case here: https://codesandbox.io/s/lively-tdd-v09pj
It's easiest to tell if you open the preview in its own tab/window and have the network inspector open when you load the page. That way, you can see the initial request(s) for font files alongside the subsequent one when clicking the button in the preview.
Expected behavior
The browser should not request fonts it has already downloaded in the same page load.
System information

OS: macOS
Browser (if applies): Firefox, Chrome, probably others
Version of Stitches: 0.1.9

Additional context
It seems like styled-components ran into this same issue (https://github.com/styled-components/styled-components/issues/1593). They considered splitting out @font-face rules into their own style tag, but ultimately decided to encourage people to set cache headers rather than addressing it (https://github.com/styled-components/styled-components/issues/1593#issuecomment-508748098).
Not sure whether or not y'all will want to make the same tradeoff, but bringing it to your attention anyway.

@jakelazaroff thanks for that, we'll investigate.

Fixed in ^0.2.0
demo: https://codesandbox.io/s/tvzpz
npm i @stitches/react@latest

I've just spent an hour debugging what seemed to be a related issue. However, it turned out it was caused by use of ref preload.
<link
  as='font'
  crossOrigin='anonymous'
  href='/fonts/segoe-ui-regular.woff2'
  rel='preload'
  type='font/woff2'
/>

For whatever reason presence of preload was causing fonts to flicker any time Stitches regenerates global styles.
I didn't find a solution, just removed preload tag.

authors: gajus jakelazaroff peduarte

repo: modulz/stitches


text:
Return the error as String rather than Exception

StandardMessageCodec does not accept Exception values and, therefore, will throw an IllegalArgumentException.
https://github.com/flutter/engine/blob/7f388bf814d302f54379f8528ad2366aa03d5e28/shell/platform/android/io/flutter/plugin/common/StandardMessageCodec.java#L208-L280

Thanks @wytesk133

Actually, I think this PR can be reverted.
Support for Throwable was added in https://github.com/flutter/engine/pull/18490


text:
versions:display-extension-updates doesn't work for core extensions

According to this comment in PR #908 the versions plugin should be able to discover updates for core extensions defined in .mvn/extensions.xml. At least for me this doesn't work (correctly).
The extensions.xml in one of our projects has the following content:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<extensions xmlns="http://maven.apache.org/EXTENSIONS/1.1.0"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://maven.apache.org/EXTENSIONS/1.1.0 https://maven.apache.org/xsd/core-extensions-1.1.0.xsd">
        <extension>
                <groupId>me.qoomon</groupId>
                <artifactId>maven-git-versioning-extension</artifactId>
                <version>9.8.1</version>
        </extension>
</extensions>

Executing this command:
$ mvn versions:display-extension-updates
[INFO] Scanning for projects...
[INFO]
[INFO] --- me.qoomon:maven-git-versioning-extension:9.8.1 [core extension] ----
[INFO] matching ref: BRANCH - master
[INFO] ref configuration: BRANCH - pattern: .+
[INFO]   describeTagFirstParent: true
[INFO]   version: ${describe.tag}${describe.distance:+-}${describe.distance:-}-g${commit.short}${dirty}
[INFO]   properties:
[INFO]     project.build.outputTimestamp - ${commit.timestamp}
[INFO]
[INFO] com.example:myproject
[INFO] set version to 2.1.0-2-g2b309fb-DIRTY
[INFO]
[INFO]
[INFO] -----------------------< com.example:myproject >------------------------
[INFO] Building myproject 2.1.0-2-g2b309fb-DIRTY
[INFO]   from pom.xml
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- versions:2.18.0:display-extension-updates (default-cli) @ myproject ---
[INFO] No extensions have newer versions.
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  1.479 s
[INFO] Finished at: 2024-11-14T20:40:50+01:00
[INFO] ------------------------------------------------------------------------

I'd assume that I'm being informed there's a newer version 9.10.0 for me.qoomon:maven-git-versioning-extension, but... No.
What puzzles me is that by using the goal display-plugin-updates a warning is printed about a missing version declaration for a plugin that isn't declared in the plugins section of the pom:
$ mvn versions:display-plugin-updates
[INFO] Scanning for projects...
[INFO]
[INFO] --- me.qoomon:maven-git-versioning-extension:9.8.1 [core extension] ----
[INFO] matching ref: BRANCH - master
[INFO] ref configuration: BRANCH - pattern: .+
[INFO]   describeTagFirstParent: true
[INFO]   version: ${describe.tag}${describe.distance:+-}${describe.distance:-}-g${commit.short}${dirty}
[INFO]   properties:
[INFO]     project.build.outputTimestamp - ${commit.timestamp}
[INFO]
[INFO] com.example:myproject
[INFO] set version to 2.1.0-2-g2b309fb-DIRTY
[INFO]
[INFO]
[INFO] -----------------------< com.example:myproject >------------------------
[INFO] Building myproject 2.1.0-2-g2b309fb-DIRTY
[INFO]   from pom.xml
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- versions:2.18.0:display-plugin-updates (default-cli) @ myproject ---
[INFO]
[INFO] All plugins with a version specified are using the latest versions.
[INFO]
[WARNING] The following plugins do not have their version specified:
[WARNING]   me.qoomon:maven-git-versioning-extension ................ 9.10.0
[INFO]
[INFO] Project requires minimum Maven version for build of: 3.6.4
[INFO] Plugins require minimum Maven version of: 3.6.4
[INFO]
[INFO] No plugins require a newer version of Maven than specified by the pom.
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  1.923 s
[INFO] Finished at: 2024-11-14T20:47:51+01:00
[INFO] ------------------------------------------------------------------------

Funny: As you can see in the console output the newest version is now shown...

I forgot to mention that this happens for versions-maven-plugin 2.17.x and the just released 2.18.0, and also for 2.16.x.

Please provide a minimal pom.xml reproducing the problem and describe what is the expected outcome.

Reproduced

@theit too bad you didn't see this before we released 2.18.0

@theit too bad you didn't see this before we released 2.18.0

Yes sorry. When I tried this on the command line to figure out what exact command is causing this, versions plugin itself informed me that a new version of itself was available... :-)
Then I checked whether this behaviour was already fixed in the new version and then searched in the issue tracker....

repo: mojohaus/versions


text:
Support for TypeScript moduleResolution: "node16"

TypeScript currently cannot detect wouter's types if moduleResolution is set to "node16" or "nodenext".
This seems to be fixed by referencing the type files for each element under exports:
".": {
  "types": "./types/ts4.1/index.d.ts",
  "require": "some path",
  "default": "some path"
},
"/use-location": "same idea as above"

and so on. types has been added. Is this something that could be added safely?
If not, I think the same result is achieved by ensuring that the .d.ts files are located next to their JS counterparts (but they aren't in wouter).
Here's a long discussion about this issue from TypeScript's perspective.
Here's an example of how you're supposed to export subpath types according to Microsoft's module resolution guy.
It's a bit over my head right now, I wish I could explain exactly how it works. :slightly_smiling_face:
Also the current package.json seems pretty deliberate so I could be totally wrong.
FWIW it seems like when the modern & upcoming module resolution is enabled, exports takes precedence and it becomes necessary to define the types there too. And it sounds like the new way will be the default eventually.

pr welcome

Sure, done!
Wasn't sure whether it's the best solution or if you'd want it, but after thinking a bit I don't see what problems it could cause.
Feel free to close this. :-)

Released in https://github.com/molefrog/wouter/releases/tag/v2.10.0

authors: molefrog toerndev

repo: molefrog/wouter

license: Unlicense


text:
file read errors go uncaught

monofile crashes on a file read error due to such error not being caught. Probably should be fixed

does this still happen in api-v1?

repo: mollersuite/monofile


text:
Table mol_country is missing after module installation

Expected behavior
table mol_country should be created during install
Actual behavior
table mol_country is not created during installation
Steps to reproduce the behavior
Install the module
Notes
Table mol_country is being created as part of upgrade script for 3.4.3 version. This table is NOT created in install.php script

Thank you for reporting this issue. We indeed missed it and it will be fixed in next release.

authors: getdatakick margud

repo: mollie/PrestaShop


text:
Redirect homepage bug on product details page

Expected behavior
When visiting a product the website should show the product details page
Actual behavior
When visiting a product the website redirect to homepage with a parameter domain.be/#_null
Steps to reproduce the behavior
Enable Mollie module,  visit a product's page and you are automatically redirected to homepage
(When I disable the module all work fine but we don't have any payment module :p )
Environment

PrestaShop version: 1.7.5.0
Mollie module version: 4,4,2
PHP version: 7.1.26

Hi @powolnymarcel ,
Thank you for your message.
For this issue also, could you send us the shop  credentials, so we could check it out? Email - support@invertus.eu
Thanks!
--
Best regards,
Invertus Support team

Message sent, thanks for the support

Hi All, we create a new installation of Prestashop 1.7.8 and we installed the Mollie plugin 4.4.2, we have the similar issue. When we try to reach a productdetail page (Just only on Safari- mobile), we dont succeed to the product detail page.

Hi @Scalerecomltd ,
Maybe you could clarify a bit more detailed how to reproduce the issue, and also provide your BO + FTP credentials to - support@invertus.eu for further investigation?
Looking forward to your reply!
--
Best regards,
Invertus Support team

authors: Saimis777 Scalerecomltd powolnymarcel


text:
Localhost Refused to Connect

I've setted all the paths correctly, as you can see below.
{ 	"node_executable_path": "C:/Program Files/nodejs/node.exe", 	"global_node_modules_path": "C:/Users/(My user)/AppData/Roaming/npm/node_modules" }
And it shows the "Live Server running on port 8080" message. The problem comes when trying to run the Open in Browser command, as it shows Localhost refused to connect.
I've seen that another user had the same problem before, but I can't find a way to fix it. Running on Windows 10, using the latest version of Sublime Text, the package seems to be the latest, but even if all looks right, this is what I get. (It is on spanish, but I think I've been clear enough)

Hi,
I assume you have the Live Server package installed globally?
If not, that is a requirement.
If you do, can you try running the live-server command from the command line / powershell, just to see if it fires up?

Indeed!
This is the weird part, I tried using the package itself and sure enough, it works

But when trying to launch a server from the extension it's when it doesn't work! So naturally I've just been using the package, but tried posting this anyway so it may get fixed for future users

Hey, I have the same issue so just like you I am also using it directly from the cmd but mine takes so much time to open folders, did you encounter something similar? Can it be a hardware issue?

Maybe it is hardware issue, my machine is actually really outdated, and runs slowly for certain tasks, so, it wouldn't be a surprise if that's the case with this.
I'm gonna ask one of my buddies with a better pc to try the extension and see if they have the same issue, but I really don't see why it should be a problem tho.

Maybe it also could be permission issues? Node being on drive A, sublime being on drive B, etc. Windows can be problematic with cases like those.
I don't use Windows for development, but when I tested the extension I had no issues myself, but of course I see some people reporting issues like this, so something is definitely up - I'm unable to reproduce the issue though sadly. 😦

So on my end I checked the firewall settings they were alright, port 8080 was also free and no process was using it, disabled controlled foldered access, I had apache running in background turned that off too still the problem persists. My node and Sublime are also on same drive in ssd.

Same here, tried looking into the firewall, and running processes long ago, and I know that everything's alright.
I actually asked one of my friends who has a better pc and everything seems fine on his end.

For once, it actually may be hardware issues. I don't know what else it could be.

Yeah, this is the issue. It only happens for some, thus I can't reproduce it. It also only seems to happen on Windows.

authors: Dashrath158 Sleepy-gogo molnarmark

repo: molnarmark/sublime-live-server


text:
Support for measures

I would like to know if the specs support elements such as measures (distance, angle, dihedral)?

Hi @papillot,
We are considering this as one of the next steps. Thanks for your interest and suggestion. This is helpful to the dev team when it comes to prioritizing features.
Best,
Sebastian

Thanks for the heads-up, that's useful to know

Yes, it sounds like a feature I would use myself when it will be done

authors: Glucksistemi JonStargaryen papillot

repo: molstar/mol-view-spec


text:
[bugfix] Fixes #3717, ensure day-of-year is non-zero

fixes #3717
@icambron

This makes sense, though the regex is a little unfortunate. My only question is whether it would have   been cleaner to allow zero to pass through the parsing and flag it further downstream. For example, we do allow numbers like 455 through at parsing and just mark it as invalid in a later step (overflow, I guess?). Maybe that's a cleaner spot for this check to. Put another way, why is it 1-999 instead of 1-365?

For sure @icambron . A lot simpler that way

Sure. Makes sense.

Merged in c338954aa9b0467692728a7f221ec62f148d86e6

Why below returns true
moment('6259361', [moment.ISO_8601], true).isValid()    // true

authors: icambron ichernev maggiepint marwahaha sushil-car

repo: moment/moment


text:
OMIM "included" entries and not the preferred names on MONDO terms

NV to do:  updated 02/10/22
I need to write out concrete action items for Nico to work on this.

I have run into a couple of cases where an OMIM entry is only once in MONDO, but the disease name it is associated with is the OMIM "included" disorder, not the preferred name from OMIM. We handle these "included" terms as distinct entries in MedGen and thus cannot link a MONDO ID to the term which is OMIM's preferred term. Some examples:
I.	MONDO:0007691 “chronic inflammatory demyelinating polyneuropathy”
a.	Maps to OMIM https://www.omim.org/entry/139393 but this represents Guillain-Barre syndrome, Familial AND “other entity” POLYNEUROPATHY, INFLAMMATORY DEMYELINATING, CHRONIC, INCLUDED; CIDP, INCLUDED
b.	UMLS splits the MIM term among multiple CUIs; we split the OMIM entry into distinct concepts for GBS, familial and then imported the MONDO term separately.  However put the MIM# on the entry with the preferred name (In this case would be Guillain-Barre syndr, familial.)
II.	MONDO:0007608 Desmoid tumor
a.	MIM https://omim.org/entry/135290 is for both desmoid disease, hereditary. AND “other” Desmoid Tumor (caused by somatic mutation)
b.	MONDO includes the Fibromatosis, familial infiltrative (FIF) alt name, but not desmoid disease, hereditary. So we can’t have a MONDO ID for our entry that represents the PT from OMIM (DESMOID DISEASE, HEREDITARY) UMLS CUI: C1851124
c. is this one of the instances where maybe the disorders are similar enough? I'm not a clinician so I can't say.
Nicole, I see your ticket #2745, so it looks like there is a mechanism to manage OMIM entries relating to multiple disease names, I hope that means MONDO can link the MIM#s to the terms of the preferred name and (as needed) the "included" terms.

Hello @kanems
I'm Sabrina, a new curator who recently joined the Mondo team.
We will address your issue as soon as possible. Thank you for your patience.
If this is a high priority, please let me know and we can prioritize it. Thank you!

I asked Ada about this and this was her response:
In most cases, an included title is not the same concept as the parent entry, so the UMLS has handled this correctly.  If you are linking to OMIM so that people can read about it, then use the parent MIM number, but ontologically it cannot be represented as the same.  This is the opposite from alternate titles which are synonyms.  Sometimes included concepts are off-shoots or not clearly distinct.  We may not have looked at them for some time, as well.

Hi Nicole, Ada's response is how I understood the distinction between "included" vs "alternate" terms on the same OMIM number, which is reassuring. However, my question to Mondo may not have been clear initially, let's see if I can clarify.
Is Mondo's policy to map OMIM numbers based on the main "preferred" name on the record or on the "included" name?
MedGen maps on the "preferred name" from OMIM and so if Mondo does the opposite, we cannot replicate the Mondo:OMIM relationship in MedGen, but we'd like to agree with Mondo as much as possible (we're just agreeable folks like that ;-) )
One example is OMIM 139393, which, as I read it, has the primary preferred name of "GUILLAIN-BARRE SYNDROME, FAMILIAL" (see screen shot). However, this OMIM number maps to MONDO:0007691 "chronic inflammatory demyelinating polyneuropathy" which has a related synonym "Guillain-Barre syndrome, familial."  So I think Mondo has appropriately handled that these two disease terms are related but not exactly the same, but I was confused by the selection to use the "included" disease rather than the OMIM primary name on the number.

Depends on @jiaola's work on the OMIM ingest.
@kanems - I'll respond to your comment above soon, thanks!

to do:
Would be nice to have a new xref tag, something like:
MONDO:includedInOMIM or
MONDO:splitFromOMIM

@kanems
we renamed MONDO:0007691 to 'Guillain-Barre syndrome, familial', it should be available in the next release (early September)
We want to use the OMIM preferred labels for Mondo terms, we'll work on cleaning this up. Based on Ada's response too, we'll work on retroactively splitting out the terms that are 'included' in OMIM entries, as these should be separate classes, as noted above.
Thanks for bringing this to our attention! It will take some time as our developer Dazhi is working on improving the OMIM ingest workflow.

On QC call (211105):
Need to break down into a step by step to-do list.
During OMIM ingest, we should tag synonyms to indicate the "included" terms, so curators can go back later and decide whether these "included terms" should be synonyms or a new term.
This requires a lot of work in the ingest pipeline. Will be done in 2022.

NCBI and UMLS have used the strategy of treating each 'included' term as a distinct concept and merging later if review indicates that some of the included terms within a MIM record are synonyms to each other. It is unlikely that an included term is a synonym to the concept represented by the MIM number title and alternate terms, so it may be appropriate to treat as distinct until proven otherwise , rather than treating as the same and then having to split.
caveat:  I am using synonym here as 'different terms for the exact same concept'

I agree with @maglott's suggestion. I think it would be best if we added 'included' entries as new terms in Mondo and they would have the xref to the OMIM ID with a new tag MONDO:includedInOMIM.
I'm not sure how difficult it would be to do this retroactively?

authors: kanems maglott nicolevasilevsky sabrinatoro

repo: monarch-initiative/mondo


text:
Feature Request: Connect to container

Awesome work!
It would be great, if i select a container, if i could say connect to container (docker exec -it  sh, that's the only thing missing for me

Thanks!! Great that you like the tool :)
I like very much the idea, but I still haven't figured out a good way to implement it.
This request is very similar to #21, I would prefer to close this one in favor of the old one.

@moncho sure, it thought #1 is more about executing a command in the container, but if you can solve this in the same run, sure go ahead and close :)

I think at the end both requests want the very same thing, which is to start a shell in a running container, that is why I think that they are kind of duplicates.
But we can leave this open as well, if it happens, it will feel better to close two request with one change :p

@nick-zh Hi Nick, here is a container-web-tty, hope that can help.

@moncho any progress on this? I see there is another duplicate popping up regading this: #125

@moncho any progress on this? I see there is another duplicate popping up regading this: #125

Hey @nick-zh, the feature is not far away, it will be included in the next release, whenever that happens.

@moncho Did this ever happen?

I am sorry to say that I could not make it work in the end. Iirc, I was unable to solve some problems going back to the terminal after creating a shell in a container.

authors: asjur moncho nick-zh wrfly

repo: moncho/dry


text:
German Translation of User Guides (General 1/2)

German translation of the following user guides:

How to make an offline backup
How to run a node on VPS
Importing the Monero blockchain
Monero Tools

Hey @stmax82, would you be interested in reviewing this and the other open pull requests adding German translations? We'll give you a small reward in XMR as a thank you :)

Hey @stmax82, would you be interested in reviewing this and the other open pull requests adding German translations? We'll give you a small reward in XMR as a thank you :)

@erciccione is it the 5 PRs about User Guides General 1+2, Wallets 1+2, Mining and Recovery? I'll start working on it, could take a bit though because other jobs are keeping me quite busy right now.

@erciccione is it the 5 PRs about User Guides General 1+2, Wallets 1+2, Mining and Recovery?

Yes. Basically all PRsopened by @wobole.
Thanks :)

@erciccione is it the 5 PRs about User Guides General 1+2, Wallets 1+2, Mining and Recovery?

Yes. Basically all PRsopened by @Wobole.
Thanks :)

@erciccione @Wobole I think I'm done with all 5 PRs. Hope I didn't miss any parts, otherwise let me know! Hats off to the work you put into this (especially the Multisig part must've been tough to write and translate :)

@stmax82 is there a way to contact you privately? I'm on Freenode (IRC) and matrix with the same nickname.

@erciccione I sent you a message from @stmax:matrix.org

@erciccione @Wobole I think I'm done with all 5 PRs. Hope I didn't miss any parts, otherwise let me know! Hats off to the work you put into this (especially the Multisig part must've been tough to write and translate :)

Thank you so much for your review, @stmax82! And also a big thanks for teaching me that it's "sich verbinden" - I anglicized a bit there, never to be forgotten again. :)

@erciccione @Wobole I think I'm done with all 5 PRs. Hope I didn't miss any parts, otherwise let me know! Hats off to the work you put into this (especially the Multisig part must've been tough to write and translate :)

Thank you so much for your review, @stmax82! And also a big thanks for teaching me that it's "sich verbinden" - I anglicized a bit there, never to be forgotten again. :)

authors: Wobole erciccione stmax82

repo: monero-project/monero-site


text:
🛑 Bitlending Staging Monetix is down

In 34eba4c, Bitlending Staging Monetix (https://api.bitlending-staging.monetix.io/health) was down:

HTTP code: 502
Response time: 872 ms

Resolved: Bitlending Staging Monetix is back up in 5c4441e.

repo: monetixio/upptime


text:
fix: correctly re-establishes pipe destinations

I tried pretty hard to recreate this locally, and I ran into issues, I was also considering stubbing out the #pipe here and testing the createChangeStreamCursor function directly but that would mean exporting it which would make it public. I can't get this code to fire and it does not exist in master anymore.
It does seem verifiably wrong.
const x = ['pipe1', 'pipe2', 'pipe3']
> for (let pipe in x) { console.log(pipe) }
0
1
2
> for (let pipe of x) { console.log(pipe) }
pipe1
pipe2
pipe3

@reggi I think this ticket was about reenabling this test. Looks like you found a bug here, but were you able to get that test passing? Are there other tests we should include here to validate your fix?

@reggi I think this ticket was about reenabling this test. Looks like you found a bug here, but were you able to get that test passing? Are there other tests we should include here to validate your fix?

@mbroadst good learning here to do a search for the jira ticket in the codebase (which I don't normally do). I fixed the test, but in 3.6 it wasn't broken because of this pipe issue, it was the file /tmp/ dir not existing. Fixed this by setting it to a already existing dir, then cleaning up the file using this.defer, master may show different issues.

authors: mbroadst reggi

repo: mongodb/node-mongodb-native


text:
test(NODE-6024): sync skip rangePreview tests on server 8.0+

Description
What is changing?

Synced skip rangePreview tests on server 8.0+
Synced getMore.yml in fle tests

The just added int or long as the type for cursor id instead of just long

Synced fle2v2-MissingKey.yml one of the test names was spell checked

Is there new documentation needed for these changes?
No
What is the motivation for this change?

Clear the server latest failures

Double check the following

[x] Ran npm run check:lint script
[x] Self-review completed using the steps outlined here
[x] PR title follows the correct format: type(NODE-xxxx)[!]: description

Example: feat(NODE-1234)!: rewriting everything in coffeescript

[x] Changes are covered by tests
[x] New TODOs have a related JIRA ticket

@nbbeeken were there changes related to the range index prose tests?  looks like you have a lot of failures

authors: baileympearson nbbeeken


text:
Adding duplicated entries on HABTM array

Hi
Suppose I have this models:
class Post
  include Mongoid::Document

  has_and_belongs_to_many :categories
end

class Category
  include Mongoid::Document
  field :name

  has_and_belongs_to_many :posts
end

After my upgrade to the current commit on 2.2.0-stable branch (I had to upgrade to this version because of the fix of #1225), this test failed:
category = Category.create(:name => "MyCategory")
post = Post.new

post.categories = [category, category]
post.save!

post.categories.should == [category]

We got two elements on categories, both with the same id.
Is this expected ?

I'm still having the same issue with 2.3.3. I see that the fix has been reverted by https://github.com/mongoid/mongoid/commit/4df41091a7c92ab07e1c58640c74fd0968a80ee3
Is this intended?

I'm also running into significant duplication issues with 2.3.4 - assigning arrays of objects to relations (ie image.tags = [tag1, tag2, tag3]) is resulting in duplicates stored in the DB, with all the confusion that entails.

@JamesHarrison Could that be due to #1516?

@nickhoffman My current testing is showing that it is, I'm working on the fix now.

Hi,
I'm experiencing same problem with 2.4.3, but my example would look like a bit modified from above:
category = Category.create(:name => "MyCategory")
post = Post.new

# atomic set performed, no save call necessary
post.categories << category
post.categories << category

post.categories.should == [category] # evals to true
post.category_ids.size.should == 1 # evals to false, 2 ids in array

I'm sure that's not expected behavior. Should the issue be reopened?
Thanks

..just updated to 2.4.4 and same issue is reproduceable

I'll reopen for 2.5.

The problem here, along with the commit in question, 4df41091a7c92ab07e1c58640c74fd0968a80ee3, is that checking inclusion is expensive if there are a large number of documents in the relation. The intention is to change the enumerable target to being backed by a hash instead of arrays, but this big of a change will need to go to 3.0.

authors: JamesHarrison alecnmk durran nickhoffman rodrigoflores venetanji

repo: mongoid/mongoid


text:
Update mongodb-driver-reactivestreams to 4.8.1

Updates org.mongodb:mongodb-driver-reactivestreams from 4.6.1 to 4.8.1.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.mongodb", artifactId = "mongodb-driver-reactivestreams" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "org.mongodb", artifactId = "mongodb-driver-reactivestreams" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, commit-count:1

Superseded by #990.

repo: monix/monix-connect


text:
how can I use multiple line text in canvas?

I have a square and I want to paste dynamic text where in the middle of square. Like new colourful Facebook posts which create background colour and text. Please help me, thank you

This is best to discuss in our forums:
https://forums.xamarin.com/categories/skiasharp

repo: mono/SkiaSharp


text:
HarfBuzzSharp: Add buffer UTF overloads

This PR adds some missing overloads for the hb_buffer to add text with UTF-16 and UTF-32 encoding.
I have also added some overloads that make it possible to only shape some portion of an encoded sequence.
Leave me comments if you have questions or find any mistake.

OPS Build status updates of commit 075bd0c:
:clock10: Preparing: average preparing time is 1 min(s) 50 sec(s)

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: Gillibald sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

OPS Build status updates of commit 075bd0c:
:clock10: Incremental building: average incremental building time is 22 sec(s)

@Gillibald initially the harfbuzz binding was more of a test, so it does not really have a nice workflow. I actually just downloaded the source tar as part of the steps:
https://github.com/mono/SkiaSharp/blob/master/cake/BuildExternals.cake#L715-L739
After downloading, I manually created project files (MSBuild, Xcode, Tizen, Makefile) for each platform to compile. I haven't gotten around to updating and using the CMake targets. The actual version that gets pulled in is read from this file:
https://github.com/mono/SkiaSharp/blob/master/VERSIONS.txt#L5
Just another thing: if this layout is not practical, or you need to get it to build another way, then go ahead and make the adjustments. Due to poor reasoning, it is the way it is now because that is how it was then 😄 Also, the harfbuzz repo has come a long way since 2017.

The reason I used the source tar instead of the code/submodule was - at the time - there was a few extra files that were generated that I didn't want to regenerate on CI. I believe this was because i didn't want to have to depend on cygwin and things like that. As a result, I just downloaded the files and used the platform project files.

OPS Build status updates of commit 3d11954:
:clock10: Preparing: average preparing time is 1 min(s) 50 sec(s)

I will update HarfBuzz in a different PR. My current approach adds a submodule to the repository but still uses custom build scripts. This works great so far and gives us the most control.

Looks like this signature doesn't work:
public extern static void hb_buffer_add_utf16(hb_buffer_t buffer, byte[] text, int text_length, uint item_offset, int item_length);
This works:
public extern static void hb_buffer_add_utf16(hb_buffer_t buffer, ushort[] text, int text_length, uint item_offset, int item_length);
Using ushort[] isn't very practical because it involves some copy. Can we somhow marshall the byte array as an array of ushort?

OPS Build status updates of commit deb1977:
:clock10: Preparing: average preparing time is 1 min(s) 50 sec(s)

OPS Build status updates of commit deb1977:
:clock10: Incremental building: average incremental building time is 22 sec(s)

OPS Build status updates of commit deb1977:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

binding/HarfBuzzSharp.Shared/Buffer.cs
:white_check_mark:Succeeded

source/SkiaSharp.HarfBuzz/SkiaSharp.HarfBuzz.Shared/SKShaper.cs
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

authors: Gillibald mattleibow mikekinsman msftclas


text:
[GTK] Autoscroll GtkViewport when focus moves

Partially Fixes VSTS #752820

@monojenkins backport 2019-10

authors: akoeplinger bratsche

repo: mono/bockbuild


text:
Fix BaseAssemblyResolver.SearchDirectory.

Fix BaseAssemblyResolver.SearchDirectory to try both .exe and .dll when searching for an assembly.
This fixes a scenario when there is a native Foo.exe and a managed Foo.dll in the search directories.

@marek-safar PTAL

repo: mono/cecil


text:
Fix stack buffer overflow in teststringformat.c

Found with asan
Also clean up some ifdefs

Thanks so much for these PRs and sorry for the delay in reviewing 💖

authors: akoeplinger hughbe

repo: mono/libgdiplus


text:
Using SelectLabel globally?

Heya there. Is there a way to globally initialise the SelectLabel property? I'd like to localise vue-multiselect but couldn't find a lot of information in the documentation. Passing the SelectLabel did not work for me, and neither is it a pretty option to pass translation to every single select.

Improving the internationalization support should be the focus for the next releases.
Currently you can create a wrapper for Multiselect that would take care of the repeating props.

@shentao do you have a rough timeframe for that? Then I can estimate if it's worth to wrap or wait ;)

It’s definitely better to wrap. This can also help you with simplifying the rest of the configuration.

After some thinking about it, I guess I could use the provide/inject functionality that shipped with Vue v2.2.0 to be able to set global defaults for selectLabel and similar. What do you think?

A faster working solution will be to use extends for now, until you make vue-multiselect a plugin, which is definitely less hacky / more clean than using inject (wouldn't require people to implement the custom provider logic themselves).

authors: Fohlen shentao toabi

repo: monterail/vue-multiselect


text:
[bug] operation canceled in github actions

Describe the bug
When running moon ci via a GitHub action the runner will take about 10 minutes and then fail, reporting the operation was canceled. This is a fairly large project with a lot of packages, not sure if that could be the culprit or not. When I run all the applicable scripts locally they run just fine, the scripts being ran are:

build
lint
format (prettier)
typecheck
test (jest)

Steps to reproduce
Here's a link to a PR presenting the issue:
https://github.com/project44/manifest/pull/211
Expected behavior

Screenshots

Environment

node 18

Additional context

My initial thought is maybe there's some task that runs forever (like a dev server) that shouldn't be running in CI.

Not seeing any dev tasks running, let me make sure there isn't a hangup in jest. Maybe a test runner is stuck.

Mmm, nope removed any tests that may hang, still just getting a random canceled:

@bclark-p44 That error looks like its coming from the GH runner itself. Can you re-run the job but with GH debug mode enabled?

Also might be a memory issue? https://github.com/actions/runner-images/issues/1918
If you upgrade to v0.22, you can try the new --concurrency setting and try reducing to like only running 6 at time.

I'll try those and report back! Thanks for the help

Looks like --concurrency works! Thanks for the quick responses.

Awesome, glad that worked!

repo: moonrepo/moon


text:
Add a function to remove all closed molecule at the end of the list

We need a function call in molecules_container_t that removes all closed molecules at the end of the list and gives back the imol just like molecules_container_t::pop_back. This is particularly relevant in the slice-n-dice UI component.

Resolved in https://github.com/pemsley/coot/commit/df196f2f31cdec4f510765d92b973fd94b80aa2b

repo: moorhen-coot/Moorhen


text:
build: include a docker-compose setup

Big thanks to Taylor Gunnoe for writing up the initial file in his blog post.
https://medium.com/@tgunnoe/3586757e45d6

Codecov Report

Merging #146 into master will decrease coverage by 3.64%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master    #146      +/-   ##
=========================================
- Coverage   56.44%   52.8%   -3.65%
=========================================
  Files          26      26
  Lines        3543    3543
=========================================
- Hits         2000    1871     -129
- Misses       1147    1293     +146
+ Partials      396     379      -17

Impacted Files
Coverage Δ

accounts.go
9.72% <0%> (-70.84%)
:arrow_down:

internal/database/mysql.go
31.16% <0%> (-44.16%)
:arrow_down:

ofac.go
38.13% <0%> (-35.6%)
:arrow_down:

file_transfer_async.go
47.89% <0%> (-0.34%)
:arrow_down:

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 83a4ed2...5f5b7c3. Read the comment docs.

authors: adamdecaf codecov-io

repo: moov-io/paygate


text:
internal/ofac: move client into separate package

More refactoring to cleanup paygate where I can quickly.

Codecov Report

Merging #263 into master will decrease coverage by 3.92%.
The diff coverage is 62.85%.

@@            Coverage Diff             @@
##           master     #263      +/-   ##
==========================================
- Coverage   61.15%   57.22%   -3.93%
==========================================
  Files          33       34       +1
  Lines        4683     4697      +14
==========================================
- Hits         2864     2688     -176
- Misses       1277     1490     +213
+ Partials      542      519      -23

Impacted Files
Coverage Δ

cmd/server/main.go
4.37% <0%> (ø)
:arrow_up:

internal/receivers.go
48.04% <100%> (ø)
:arrow_up:

internal/originators.go
53.88% <100%> (ø)
:arrow_up:

internal/depositories.go
59.3% <100%> (ø)
:arrow_up:

internal/ofac/client.go
38.65% <53.84%> (ø)

internal/ofac/mock_client.go
57.14% <57.14%> (ø)

internal/accounts.go
10.95% <0%> (-67.13%)
:arrow_down:

internal/database/mysql.go
10.66% <0%> (-50.67%)
:arrow_down:

internal/filetransfer/sftp.go
47.08% <0%> (-24.87%)
:arrow_down:

... and 3 more

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 22a04a2...c307c3e. Read the comment docs.


text:
Add List: US Trade 8-Consolidated Screening List (CSL)

Homepage: https://www.export.gov/article?id=Consolidated-Screening-List
This list seems to combine the information/names/entities from the below lists, a downloader and parser for this single list would be more efficient.
https://github.com/moov-io/watchman/issues?q=is%3Aopen+is%3Aissue+label%3A"Consolidated+Screening+List"
The download requires an API key so requiring an env var like US_CSL_API_KEY should be required. If empty then the list is neither downloaded or indexed.

Note: We should verify this consolidated list does combine the information from the 8 lists mentioned.

Do we still need this issue? PR #197 added the Consolidated Screening List.
The following sources can be easily extracted from it:

Unverified List – Bureau of Industry and Security (Issue #185)
Entity List – Bureau of Industry and Security (done, PR #199)
Nonproliferation Sanctions (ISN) - State Department (Issue #187)
Foreign Sanctions Evaders (FSE) - Treasury Department (Issue #189)
Sectoral Sanctions Identifications List (SSI) - Treasury Department (done, PR #197)
Palestinian Legislative Council List (PLC) - Treasury Department (Issue #191)

The CSL does contain the SDN and DPL, but those lists are available in a better format from the sources currently utilized.

Not really. Thanks for the notice

repo: moov-io/watchman


text:
After Azure migration hubConnection listener is not working.

This is the sample code I am using and it works fine before Azure migration. But after Azure migration, the listener is not responding.
            guard let data = arguments.data(using: .utf8),
                  let filteredArguments = ((try? JSONSerialization.jsonObject(
                                                with: data,
                                                options: .allowFragments) as? [String: Any]) as [String : Any]?)
            else { return }

            if let source = filteredArguments["messageType"] as? String, source == "IsTyping" {}

This report does not contain enough details to understand the problem. I also don't have a bigger picture to understand the code snippet you posted. If the client works well on premise but doesn't work with Azure there is likely a difference between the two services (assuming the client is able to connect successfully to both.

authors: chandananand moozzyk

repo: moozzyk/SignalR-Client-Swift