text:
Is it possible to make Proxy Manager a suggest instead of a requirement?

Hi @mnapoli,
During an installation of PHP-DI using composer I noticed that 'ocramius/proxy-manager' is being installed, which brings the dependencies zendframework/zend-code, zendframework/zend-eventmanager, zendframework/zend-stdlib.
As far as I can see I do not need those dependencies because I am not using the proxy functionality; would it make sense to move the ocramius/proxy-manager to the require-dev or suggests so that it is not added by default?

Hey @mvriel, glad to know you are giving this package a try!
It's planned and implemented in (future) v5 (see #198). The pull request for v5 is in #200 if you are curious.

Looking good! I am curious: what timeframe are you thinking of with version 5 and is it stable enough to try out in a new project?

I wouldn't say it's stable, even though we are using it in Piwik. The idea is to test features with a real life use case and have the liberty to adjust. Once it's stable, v5 will be released. But I think there might be some changes coming (not 100% sure yet) so if I were you I wouldn't.
The main thing of v5 is support for modular systems (i.e. like Symfony bundles, where modules can extend the base config and override each others). If you don't need that, then v4 should definitely be good enough. And the upgrade path to v5 will be fairly easy and documented.
There is not really a timeframe, it could be in 1 month or up to 3-4 :)

The project on which I am working isn't in a hurry and what you describe does sound appealing; I might give it a try knowing that you will be changing things. That modular systems change, is that already done? I couldn't find docs in the PR so I want to know before I go searching in the sourcecode ;)

That's interesting! Maybe you'll have feedback to give also on those new features.
Regarding documentation, I think you can find everything in the separate issues. Those features are mainly about inheriting definitions and extending definitions (needed for a modular system), and they are mainly discussed in #214. It's quite a read, but I'm very interested in your feeling about it if you do read it. Most of it is not implemented yet.
A smaller issue about string definitions: #224 (implemented)
Also some "syntactic sugar" that I documented in a blog post: http://php-di.org/news/14-php-di-5-syntaxic-sugar.html That is all implemented in the branch except #208 (nested definitions).
The main BC break I'm considering for v5 is this: right now object definitions automatically extend each-other. For example in file A you define an object, and in file B you change one constructor parameter value. The main reason for this feature being the default is to allow simple integration between autowiring, annotations and file configs… E.g. if you have:
public function __construct(LoggerInterface $logger, $dbHost)

You can do only this in the config file:
return [
     'MyClass' => DI\object()
        ->constructorParameter('dbHost', 'localhost');
];

(no need to define again the $logger parameter)
That's cool, but it has some problems, and I'm considering making the default different:

by default, definitions override any previous definition (i.e. file definition would completely override the "autowiring" definition)
you can optionally choose to extend/decorate the previous definition (that requires to explicitly do it)

That behavior would then be consistent across all definition types. See this comment for the detailed arguments.
What do you feel about this change and the related BC break?

If you do start using v5, let me know I'll try to think about you if I push anything that might break. But except the BC break I just detailed, the rest should be pretty stable.
Also will you have very high performance expectations on your application? In most cases the container is just a fraction of the request so it's no problem but just so you know this branch is not benchmarked or optimized yet.

Ohh is that this? That readme sounds super interesting, if you need any help regarding PHP-DI ping me in your project I'll be glad to help! (or you can open an issue here too)

You are absolutely, right! I am trying out PHP-DI 5 in Somos as I believe that Somos will take quite some time for it to be ready enough for beta and that means that with any luck PHP-DI 5 will be launched by then :)
And don't worry about breaks because I am trying it out; I am aware I am using experimental / development releases. I have the same thing going with phly/http

Awesome good luck!

Just a FYI regarding https://github.com/somos/framework/issues/31 (didn't want to derail the topic so I'm posting here), PHP-DI offers a call() method that works a bit like AngularJS:
$parameters = [
    'data' => /* some variable */
];

$container->call(function (Logger $logger, $data) {
    // ...
}, $parameters);

Beyond allowing to inject dependencies at will, it's also a good way to invoke stuff without having to implement it again. In the issue you mention the ability to define business logic as a closure, or an invokable object, or also the class name as a string (which will be resolved using the container): PHP-DI can do that with call().
It gives an interesting solution: you can then use DI both in classes (traditional way with constructor parameters) but also in action callables. That means you can write actions as closures and still benefit from DI even though you don't have a constructor/state. And you can mix injecting services with injecting request parameters (matching is done first by type-hint to find a service, then by argument name).
I've used that in a (not-serious) micro-framework I built to show that feature: https://github.com/mnapoli/minimal-app#dependency-injection-in-controller-actions
Maybe it will give you ideas who knows!

That does sounds interesting! Thank you for sharing that as it will simplify the code that I am currently writing.
Does it also support this use-case?
class MyAction
{
    public function __construct(MyDependency $dependency)
    {
        ...
    }

    public function indexAction(Request $request)
    {
        ...
    }

    public function showAction(Request $request)
    {
        ...
    }
}

$di->call('MyAction::indexAction');

Also: do I understand correctly that in your example the data field in the array $parameters is injected into $data because the name matches?

MyAction::indexAction is actually the only PHP callable format that isn't supported ;) (see this comment). I wouldn't have a problem with adding support for that though, I just didn't bother at the time because using the array notation is much more PHP 5.5 friendly with ::class:
use Super\Long\Namespace\MyAction;

$container->call([MyAction::class, 'indexAction']);

The version that you wrote will try to invoke a static method indexAction instead of constructing an object first; or will PHP-DI create / retrieve an object if it doesn't find a static method?

If it's a static method, it will just call the static method.
If it's an object method, it will resolve the object using the container.
PS: I've updated my comment above with more info.

Awesome! You don't have to change any behaviour then; I will alter the text of https://github.com/somos/framework/issues/31 to match this

One last thing!

Also: do I understand correctly that in your example the data field in the array $parameters is injected into $data because the name matches?

Is this true?

Also: do I understand correctly that in your example the data field in the array $parameters is injected into $data because the name matches?

Yes exactly. It can match for 2 reasons:

the type-hint == a container entry name (which are usually class names when you use autowiring) -> this is dependency injection
the parameter name == the name of an item of the array -> this is just call_user_func_array behavior

I use it e.g. to do something like this:
$controller = function (LoggerInterface $logger, $name) {
    // $name is the same as $_GET['name']
}

$container->call($controller, $_GET + $_POST);

The only problem with that is that it's impossible to inject a container entry that is not indexed by the class name (because you can't type-hint it). I haven't found a clean way to do that yet, except introducing a new array:
$container->set('logger.log_file_name', '/tmp/app.log');

$controller = function ($logFile, $name) {
}

$containerEntriesMapping = [
    'logFile' => 'logger.log_file_name'
];

$container->call($controller, $_GET, $containerEntriesMapping);

2 arrays for similar yet different stuff, quite confusing… So I don't really know about that.

@mnapoli in an earlier comment (https://github.com/mnapoli/PHP-DI/issues/228#issuecomment-74369161) you talked about breaking BC because Object references now extend by default; I am totally ok with that break. In fact: I like it.
It feels intuitive for me to override entries if you redefine them and extending an object should be an explicit action. That just makes sense to me (perhaps because I am used to Pimple?)

:+1: I think all other containers behave that way (at least those that have a way to override/extend definitions).
Thanks for the feedback.

authors: mnapoli mvriel

repo: mnapoli/PHP-DI


text:
[WIP] Add example showing all the eeg helmets

This PR mimics the first step of #6146 for all the montage files. And fix whatever is needed to have a convenient user code like:
for current_montage in get_builtin_montages():
    montage = mne.channels.read_montage(current_montage)
    info = mne.create_info(ch_names=montage.ch_names,
                           sfreq=1,
                           ch_types='eeg',
                           montage=montage)

    plot_alignment(info, trans=None, subject='fsaverage',
                   subjects_dir=subjects_dir,
                   eeg=['original', 'projected'])

What I've used to see if the results are more or less ok

[x] EGI_256 ref
[x] GSN-HydroCel ref datasheet
[x] biosemi ref
[ ] easycap (for the 10 )
[ ] mgh
[ ] standard_1005
[x] standard_1020 ref
[ ] standard_alphabetic
[ ] standard_postfixed
[ ] standard_prefixed
[ ] standard_primed

here is the rendered doc: https://12266-1301584-gh.circle-artifacts.com/0/dev/auto_examples/visualization/plot_montage.html
to should see montage file by montage file what option is needed to make it correct.
I expect some adhoc options that we should make superfluous with a future release
so it jsut works out of the box for any of these files
@massich can you report which should be fixed to move forward here?

the easycap_m10 seems a bit off in pitch.

https://12328-1301584-gh.circle-artifacts.com/0/dev/auto_examples/visualization/plot_montage.html?highlight=plot_montage

This pr was adding a short example. Shame as the example we have with MEG
helmet. But rather than showing the default Meg helmets shows the eeg
default montages.
In other words, a place to point people.
On Sat, Apr 20, 2019, 11:05 Alexandre Gramfort notifications@github.com
wrote:

@agramfort commented on this pull request.
what do we do with this PR? I am now lost.
In mne/channels/montage.py
https://github.com/mne-tools/mne-python/pull/6158#discussion_r277129076:

@@ -132,9 +132,8 @@ def read_montage(kind, ch_names=None, path=None, unit='m', transform=False):
path : str | None
The path of the folder containing the montage file. Defaults to the
mne/channels/data/montages folder in your mne-python installation.

unit : 'm' | 'cm' | 'mm'

   Unit of the input file. If not 'm' (default), coordinates will be

   rescaled to 'm'.

unit : 'm' | 'cm' | 'mm' | 'auto'

   Unit of the input file. Defaults to 'auto'.

'auto' is not documented
In examples/visualization/plot_montage.py
https://github.com/mne-tools/mne-python/pull/6158#discussion_r277129081:

@@ -0,0 +1,45 @@
+# -- coding: utf-8 --
+"""
+Plotting sensor layouts of EEG Systems
+======================================

+Show sensor layouts of different EEG systems.
too short. please explain more what you did.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mne-tools/mne-python/pull/6158#pullrequestreview-228872024,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABVX5Y743CECD4VVAKRXJ4TPRLMEBANCNFSM4HGLFQOA
.

yes I understand the purpose but it contains the fsaverage fetcher so I cannot merge this.

Thanks @massich

source: gharchive/pull-request

authors: agramfort larsoner massich

repo: mne-tools/mne-python

license_type: permissive

license_source: github-api


text:
[DOC] fix typo 'source-based' -> 'surface-based'

as per subject

thx @jjnurminen

authors: agramfort jjnurminen


text:
Fix project urls in pyproject.toml

Sorry for not creating an issue first, I was a bit lazy and I was hoping this would be okay since there is no change to the actual code.
I noticed that the project urls "homepage" and "repository" were pointing to mne-bids-pipeline and not mne-qt-browser (these links appear for example on the PyPi release page).
I fixed the repository url, but don't think there is a homepage, right? An option might be to just remove the homepage url if there isn't any. I made it also point to the GitHub repo for the moment.
Additionally I changed "changelog" to an https not http url.

Great, thanks for the quick merge!

repo: mne-tools/mne-qt-browser


text:
Question: Can this be used on Debian based DietPi or Ubuntu ?

Hi,
I am planning to buy WD MyCloud Home to use with Raspberry Pi.
Can I use this in Debian based OS such as DietPi or Ubuntu ?
Thanks in advance.

Yes, you can. It supports all the flavors of ARM architectures.

source: gharchive/issue

authors: mnencia pradiptabasu

repo: mnencia/mchfuse


text:
Newer version of react-native-camera

This repo is a whole major version behind. You need to use the newer react-native-camera for newest react-native and build tools for android.
What's happening?
Well nothing really, it just works.  We should let people know if they need to use 'general' or 'mlkit' (the former seems to work fine).

Will accept PRs updating to the latest version.

Will accept PRs updating to the latest version.

authors: bramski moaazsidat

repo: moaazsidat/react-native-qrcode-scanner

license: mit

license_source: bigquery


text:
Error encountered while importing the module into my project

Please consider the screenshots step-by-step:

Import statement of QRCodeScanner has been commented out.

App Screen launches perfectly.

Import statement of QRCodeScanner is enabled now.

App encounters an error corresponding to the above change.

I'm a complete novice in the RN world - hence, a helping hand is very much appreciated.

Resolved this problem myself. It's not being triggered by react-native-qrcode-scanner. However, it's a COOL module! Thanks.


text:
Uncaught TypeError: Cannot read property 'oneOf' of undefined

Call Stack:
index.js:415 Uncaught TypeError: Cannot read property 'oneOf' of undefined
    at Object.169../utils.js (index.js:415)
    at s (_prelude.js:1)
    at _prelude.js:1
    at Object.600.prop-types (Form.js:7)
    at s (_prelude.js:1)
    at _prelude.js:1
    at Object.601.../reducers (FormContainer.js:5)
    at s (_prelude.js:1)
    at _prelude.js:1
    at Object.598../ErrorBoundary (App.js:2)

The line it's referring to:
timing: _react2.default.PropTypes.oneOf([// easing type
  'ease', 'ease-in', 'ease-out', 'ease-in-out', 'linear', 'step-start', 'step-end']),

Conflict with React 16? Something else?

If you are using react 16 - https://reactjs.org/docs/typechecking-with-proptypes.html

Thanks. I already updated to the separate prop-types package, but looks like I missed one location. Problem is React.PropTypes here https://github.com/moarwick/react-mt-svg-lines/blob/master/src/index.js#L27
Will fix soon..

Fixed in 0.8.2

Thanks @moarwick. Looks like there's a stray console.log in the release. :)

grrr.. try 0.8.3 :)

authors: AlithAnar logancalldev moarwick

repo: moarwick/react-mt-svg-lines


text:
[Feature]: OpenStreetMap roads mask

@SteffanDavies
See this new example notebook on Google Colab:
https://colab.research.google.com/drive/1xhVedrIvNS66jGKgS30Dgqy0S31uJ8gm?usp=sharing

@mobigroup osmnx seems to have compatibility issues with pygmtsar / dask, I will explain in detail by email.

Please test with the recent PyGMTSAR library on PyPI, which addresses compatibility issues with modern numpy and pandas libraries. By the way, starting from Pandas 2.0, the library uses the PyArrow backend instead of numpy. This update ensures that the PyGMTSAR library remains compatible and efficient with the latest libraries and their features. Make sure to use the updated PyGMTSAR library for seamless integration and improved performance.

@SteffanDavies OSM processing works now in a separate process and it does not interfere with the main code. Also, the unwrapping is much more accurate for the masked OSM roads. In case you still see some unwrapping issues try SNAPHU config option INITMETHOD='MCF':
config = sbas.PRM().snaphu_config(...,INITMETHOD='MCF')
sbas.unwrap_parallel(..., conf=config)

Additionally, I plan to implement a different approach for merging SNAPHU tiles in the future.

authors: SteffanDavies mobigroup

repo: mobigroup/gmtsar


text:
🛑 Mobility Solutions Web is down

In ac0b1a2, Mobility Solutions Web (https://mobilitysol.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Mobility Solutions Web is back up in 0efa336.

repo: mobilitysol/monitorweb

license: MIT


text:
🛑 Mobility Solutions Web is down

In 749ea70, Mobility Solutions Web (https://mobilitysol.com) was down:

HTTP code: 502
Response time: 4865 ms

Resolved: Mobility Solutions Web is back up in 444c0a6.


text:
Print debug logs in CI

In Node CI tests, we should consider setting DEBUG=mocha:* to get the debug logs, if it won't interfere too much with the reporter output (and if we can find a way to deactivate it for integration tests without breaking Node 0.10, see #2897).
In browser CI tests... I don't know, we are currently suppressing the debug module using the browsers entry in package.json; most likely we can't just stop doing that because debug might not support all the old browsers Mocha supports, but maybe we could selectively convince Browserify to not do it for the BUILDTMP build and activate mocha:* for debug logging in Karma?
Why is this worth looking into? I believe getting these logs in the browser runs will show us a message that is being suppressed about #2890.

This issue is inactive, oudated and IMO without any clear benefit, closing.

authors: ScottFreeCode juergba

repo: mochajs/mocha


text:
🛠 Repo: Automate releases

Tooling Suggestion Checklist

[X] I have tried restarting my IDE and the issue persists.
[X] I have pulled the latest master branch of the repository.
[X] I have read and agree to Mocha's Code of Conduct and Contributing Guidelines
[X] I have searched for related issues and issues with the faq label, but none matched my issue.
[X] I want to provide a PR to resolve this

Overview
We should automate the releases of Mocha.
Why?

Lowers the threshold for releases
Minimizes human errors
Attestation of releases package

We could eg. do something similar to what I did in: https://github.com/neostandard/neostandard/commit/c9d442566833bf30cc1c7dc1117dc8de509d95ad
Additional Info
The (granular) access token should be owned by a bot account. I wonder if eg. the OpenJSF account could do this?

+1 from me on this. It's definitely something we should do as a team (as opposed to an external contributor).

authors: JoshuaKGoldberg voxpelli


text:
Proposal of refactoring related with file path collector

Description of the Change

Motivation
For issue #3689, I check all of mocha core code and find code like this.
exports.runMocha = (mocha, options) => {
  const {
    watch = false,
    extension = [],
    ui = 'bdd',
    exit = false,
    ignore = [],
    file = [],
    recursive = false,
    sort = false,
    spec = []
  } = options;

  const fileCollectParams = {
    ignore,
    extension,
    file,
    recursive,
    sort,
    spec
  };

  if (watch) {
    watchRun(mocha, {ui}, fileCollectParams);
  } else {
    exports.singleRun(mocha, {exit}, fileCollectParams);
  }
};

fileCollectParams pass to watchRun and singleRun, but it used by scattered file path collecting functions like below.
exports.singleRun = (mocha, {exit}, fileCollectParams) => {
  const files = collectFiles(fileCollectParams);
  debug('running tests with files', files);
  mocha.files = files;
  return mocha.run(exit ? exitMocha : exitMochaLater);
};

// In watch-run.js
// collectFiles imported from collect-files.js
const files = collectFiles(fileCollectParams);
// ... (some codes) ...
const watchFiles = utils.files(process.cwd(), fileCollectParams.extension);

I've come to think that modules that get file paths like this don't need to be separate. This makes the code hard to read and maintain. So I thought it would be a good idea to create a module related to this feature and integrate it into one.
Changes
First, I make FileCollector. In this time, it just wrapper of utils.files() and collectFiles().
Second, FileCollector manage fileCollectParams from user input options.
Last, Replace all code using utils.files() and collectFiles().
Future development direction
If this proposal is accepted, then I think it is good to integrate utils's file related functions and collect-files.js into FileCollector.
Applicable issues

Is this a breaking change (major release)?
Is it an enhancement (minor release)?
Is it a bug fix, or does it not impact production code (patch release)?

Nope. There is no new feature and not impact production code. Just refactoring proposal.

Coverage decreased (-0.01%) to 92.413% when pulling 924bae7387ba377ebd25dba365ceef33be4f7a01 on DrizzlingCattus:prototype/file-collector into fafa9b98809b941e8e6ea81868eabdc22cbd17af on mochajs:master.

@DrizzlingCattus
Our watch feature is currently undergoing a refactoring, the collecting of the watched files will be done by chokidar. At this point your proposal in this form does not make sense.
I realise you have invested quite an effort in this PR, thank you!

@juergba
I've seen PR #3980 (maybe you reference right?) before.
I realized that the changes were made to parts I didn't recognize.
By the way thank you for answer! :)

authors: DrizzlingCattus coveralls juergba


text:
Add some utilities back to vscode image

Wrapping up a loose end I forgot to include with #2704; apt-installing a few utilities that were included in the old image and might be useful in the context of development (especially git). I'm being more selective than the true code-server because I'd like to minimize the risk of issues with esoteric images, and not all of the utilities included in the code-server image seemed relevant (e.g. it also installed vim and nano which seems unnecessary if the whole point is to provide vscode).

@prbot approve

@prbot automerge

repo: modal-labs/modal-client


text:
Detect when we are compiling std

std is allowed to make use of constructs that other crates are not. We should codegen it differently

A partial solution would be to check for names that begin with std or core. But that fails for functions like this one (done by dumping function names used in the flat_map.rs test
function <std::iter::adapters::flatten::FlattenCompat<std::iter::Map<std::slice::Iter<&str>, [closure@flat_map.rs:21:40: 21:53]>, std::str::Chars> as std::iter::Iterator>::fold::<usize, [closure@<std::iter::FlatMap<std::slice::Iter<&str>, std::str::Chars, [closure@flat_map.rs:21:40: 21:53]> as std::iter::Iterator>::count::{closure#0}]>
	<std::iter::adapters::flatten::FlattenCompat<I, U> as std::iter::Iterator>::fold
	_RINvXsf_NtNtNtCsfEcgbfWSmKH_4core4iter8adapters7flattenINtB6_13FlattenCompatINtNtB8_3map3MapINtNtNtBc_5slice4iter4IterReENCNvCs3WwPDqd8Z2Z_8flat_map18check_flat_map_len0ENtNtNtBc_3str4iter5CharsENtNtNtBa_6traits8iterator8Iterator4foldjNCNvYINtB6_7FlatMapB1s_B2I_B1V_EB37_5count0EB1Z_
	false

repo: model-checking/kani


text:
Adopt Rust's source-based code coverage instrumentation

This PR replaces the line-based coverage instrumentation we introduced in #2609 with the standard source-based code coverage instrumentation performed by the Rust compiler.
As a result, we now insert code coverage checks in the StatementKind::Coverage(..) statements produced by the Rust compiler during compilation. These checks include coverage-relevant information[^note-internal] such as the coverage counter/expression they represent [^note-instrument]. Both the coverage metadata (kanimap) and coverage results (kaniraw) are saved into files after the verification stage.
Unfortunately, we currently have a chicken-egg problem with this PR and #3121, where we introduce a tool named kani-cov to postprocess coverage results. As explained in #3143, kani-cov is expected to be an alias for the cov subcommand and provide most of the postprocessing features for coverage-related purposes. But, the tool will likely be introduced after this change. Therefore, we propose to temporarily print a list of the regions in each function with their associated coverage status (i.e., COVERED or UNCOVERED).
Source-based code coverage: An example
The main advantage of source-based coverage results is their precision with respect to the source code. The Source-based Code Coverage documentation explains more details about the LLVM coverage workflow and its different options.
For example, let's take this Rust code:
1 fn _other_function() {
2    println!("Hello, world!");
3 }
4
5 fn test_cov(val: u32) -> bool {
6     if val < 3 || val == 42 {
7         true
8     } else {
9         false
10    }
11 }
12
13 #[cfg_attr(kani, kani::proof)]
14 fn main() {
15    let test1 = test_cov(1);
16    let test2 = test_cov(2);
17    assert!(test1);
18    assert!(test2);
19 }

Compiling and running the program with rustc and the -C instrument-coverage flag, and using the LLVM tools can get us the following coverage result:

In contrast, the cargo kani --coverage -Zsource-coverage command currently generates:
src/main.rs (main)
 * 14:1 - 19:2 COVERED

src/main.rs (test_cov)
 * 5:1 - 6:15 COVERED
 * 6:19 - 6:28 UNCOVERED
 * 7:9 - 7:13 COVERED
 * 9:9 - 9:14 UNCOVERED
 * 11:1 - 11:2 COVERED

which is a verification-based coverage result almost equivalent to the runtime coverage results.
Benchmarking
We have evaluated the performance impact of the instrumentation using the kani-perf.sh suite (14 benchmarks). For each test, we compare the average time to run standard verification against the average time to run verification with the source-based code coverage feature enabled[^note-line-evaluation].
The evaluation has been performed on an EC2 m5a.4xlarge instance running Ubuntu 22.04. The experimental data has been obtained by running the kani-perf.sh script 10 times for each version (only verification and verification + coverage), computing the average and standard deviation. We've split this data into small (tests taking 60s or less) and large (tests taking more than 60s) and drawn the two graphs below.
Performance comparison - small benchmarks

Performance comparison - large benchmarks

Comments on performance
Looking at the small tests, the performance impact seems negligible in such cases. The difference is more noticeable in the large tests, where the time to run verification and coverage can take 2x or even more. It wouldn't be surprising that, as programs become larger, the complexity of the coverage checking grows exponentially as well. However, since most verification jobs don't take longer than 30min (1800s), it's OK to say that coverage checking represents a 100-200% slowdown in the worst case w.r.t. standard verification.
It's also worth noting a few other things:

The standard deviation remains similar in most cases, meaning that the coverage feature doesn't have an impact on their stability.
We haven't tried any SAT solvers other than the ones used by default for each benchmark. It's possible that other solvers perform better/worse with the coverage feature enabled.

Call-outs

The soundness issue documented in #3441.
The issue with saving coverage mappings for non-reachable functions documented in #3445.
I've modified the test cases in tests/coverage/ to test this feature. Since this technique is simpler, we don't need that many test cases. However, it's possible I've left some test cases which don't contribute much. Please let me know if you want to add/remove a test case.

[^note-internal]: The coverage mappings can't be accessed through the StableMIR interface so we retrieve them through the internal API.
[^note-instrument]: The instrumentation replaces certain counters with expressions based on other counters when possible to avoid a part of the runtime overhead. More details can be found here. Unfortunately, we can't avoid instrumenting expressions at the moment.
[^note-line-evaluation]: We have not compared performance against the line-based code coverage feature because it doesn't seem worth it. The line-based coverage feature is guaranteed to include more coverage checks than the source-based one for any function. In addition, source-based results are more precise than line-based ones. So this change represents both a quantitative and qualitative improvement.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

Thanks for you review, @zhassan-aws ! I'll address your comments soon. Also, please note that I have updated the benchmarking section in the PR description. I'm hoping this makes clear the performance impact of running coverage checking with this technique.

Ready for review again - I've taken the chance to reorganize the tests/coverage folder so that it's not so nested. There's even a known_issue folder that contains the tests with known issues. I've removed some more tests that seemed redundant to me too. Hope that makes it easier to review.

Thank you, @zhassan-aws ! I will hold the merge of this PR until #3143 is merged.
Also, the other we talked about this feature breaking the coverage feature in the VS Code extension. I recall agreeing to keeping the line-based coverage option but, on a second thought, I think it'd just be easier to remove it here and integrate the VS Code extension with the source-based feature. I'm meeting @jaisnan soon to make sure that's the case and coordinate on the integration.


text:
Suite for "fixme" tests

Description of changes:
This PR adds:

A new testing suite rmc-fixme which consists of the ignored rmc tests, while ignoring the usual rmc tests.
Moves/changes to a few tests that were being ignored in rmc but appear to work now.
A workflow to run the "rmc-fixme" testing command every Monday at 7:42 UTC.

Resolves #71
Testing:

How is this change tested? Running CI in this PR. This Actions run is an example of rmc-fixme regression.

Is this a refactor change? No.

Checklist

[x] Each commit message has a non-empty body, explaining why the change was made
[x] Methods or procedures are documented
[x] Regression or unit tests are included, or existing tests cover the modified code
[ ] My PR is restricted to a single feature or bugfix

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

Good point, just updated the PR to add this suite to the normal regression instead.

repo: model-checking/rmc


text:
Provider helper to convert capabilities to tool functions

Is your feature request related to a problem? Please describe.
I would like to expose MCP capabilities to an LLM supporting tool functions.
We assume, although this part is not described in the architecture, that in the Claude desktop app you gather the capabilities via MCP locally and then expose them via tool functions to the underlying LLM. The format seems literally identical (but this is of course not guaranteed). if this assumption is correct, it would be great o have this converstion step available in the SDK for mutiple LLM provider (Anthropic, OpenAi, etc.) so that adopters of MCP do not have to re-implement this.
Describe the solution you'd like
Add helper to convert MCP capabilities into tool functions for various LLM provider.

This might be a better fit for one or more small bindings libraries that sit on top of MCP. We'd like to avoid the need for any MCP SDKs to depend on different providers directly.

@jspahrsummers That makes a lot of sense. However, I think it would be good to host this in the same org, as to my understanding, almost everybody using MCP would need this. It would be also great if you would consider publishing this exact code you used in the Anthropic desktop app. I am aware that this is almost a no op in terms of what it does. However, if formats evolve, it would be good to have this conversion encapsulated and maintained.

We'd really like to avoid anything in the @modelcontextprotocol org being directly coupled to any provider, as this is meant to be a community project, and we don't want uneven levels of support for different providers (e.g., as their APIs evolve over time).

Hi,
Thank you for your thoughtful reply! I completely understand your perspective, and it's ultimately up to you to decide how to proceed. If this feature request doesn't align with your vision, please feel free to close it—I won't take it personally.
That said, I really appreciate the concept and vision of MCP. The idea of a protocol like this has enormous potential, and I think it's heading in a great direction. My perspective comes from my own use case: I'm currently integrating MCP into the Theia IDE (you can read more about it here: [Introducing AI in the Theia IDE](https://eclipsesource.com/blogs/2024/10/08/introducting-ai-theia-ide/)). In this context, I found that a conversation mechanism like the one I suggested is almost essential—not just for my integration, but likely for most adopters of MCP. The aim of this feature request is to reduce redundancy and avoid a situation where each adopter has to implement the same thing individually, even if it's a relatively small addition.
Regarding the concern about keeping the repository provider-neutral, I completely get where you're coming from. However, I feel there's always a balance to strike. MCP Servers already includes integrations with specific providers (e.g., GitHub, Google Maps, Google Drive, Slack), which shows that while the protocol itself remains neutral, the examples and supported integrations are somewhat opinionated. This adds value for adopters, as they can see how things work in practical, real-world scenarios. I think this is a natural trade-off for a framework like MCP: remaining neutral but also practical for adopters.
Lastly, I want to reiterate my appreciation for this project. It's an impressive initiative, and I'm excited to see where it goes! If this suggestion doesn't fit your vision, feel free to close the request—no hard feelings.
Best regards,
Jonas

authors: JonasHelming jspahrsummers

repo: modelcontextprotocol/typescript-sdk


text:
Missing h in documentation of dp_curvedOverall

Reported by hansolsson on 15 Nov 2012 08:59 UTC
Modelica.Fluid.Dissipation.Utilities.SharedDocumentation.PressureLoss.Bend.dp_curvedOverall in 3.2 has the following text (it was not corrected last time I checked):
"There are tree different flow regimes observed (laminar,transition,turbulent). "
The third word should be three.

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

Comment by dietmarw on 15 Nov 2012 10:32 UTC
FIXED in f313bfbaeb2e760a6540f092c941b0210aa1a740.
(Hans, why don't you fix that directly, not really necessary to file tickets for such trivial typos first. It would also save you time ;))

Comment by hansolsson on 15 Nov 2012 12:23 UTC
Replying to [comment:1 dietmarw]:

FIXED in f313bfbaeb2e760a6540f092c941b0210aa1a740.
(Hans, why don't you fix that directly, not really necessary to file tickets for such trivial typos first. It would also save you time ;))

It would save time, but it would at the moment cause a delay (and the risk of forgetting it), since I need access to a network outside of DS for svn commit (due to http-proxying or something).

repo: modelica/Modelica


text:
🛑 Sonarr is down

In aa4fdd5, Sonarr ($SONARR_URL) was down:

HTTP code: 523
Response time: 1009 ms

Resolved: Sonarr is back up in 8df48c3 after 8 minutes.


text:
[Bug]: pnpm v7 和 git hook 的兼容性问题

版本信息
@modern-js/app-tools@1.6.4 -> ./node_modules/.pnpm/registry.npmmirror.com+@modern-js+app-tools@1.6.4_femxfsv7ntf2nz4bpj36nj6mcm/node_modules/@modern-js/app-tools
└─┬ @modern-js/plugin-electron@1.0.19 -> ./node_modules/.pnpm/registry.npmmirror.com+@modern-js+plugin-electron@1.0.19_47l77qdyy2tfsqtk7ztcktvx5m/node_modules/@modern-js/plugin-electron
  └── @modern-js/app-tools@1.6.4 -> ./node_modules/.pnpm/registry.npmmirror.com+@modern-js+app-tools@1.6.4_femxfsv7ntf2nz4bpj36nj6mcm/node_modules/@modern-js/app-tools

问题详情
pnpm 升级到 v7 后，git commit 会报错，降级到 v6 后错误消失
 ERR_PNPM_FETCH_404  GET https://registry.npmjs.org/--no-install: Not Found - 404

--no-install is not in the npm registry, or you have no permission to fetch it.

No authorization header was set for the request.

复现链接
新建一个 electron 项目
复现步骤

npx @modern-js/create mobile-pages
npm install -g pnpm@v7
git add . && git commit "test"

pnpm v7 引入了一些不兼容更新，目前 modern.js 还未完成 pnpm v7 的适配，后续会安排上

这个问题可以通过升级项目中的 husky 到 v8 来解决，升级方式参见 https://github.com/typicode/husky-4-to-8

authors: chenjiahan xalanq


text:
Orphaned section headers

Pagebreaks can happen immediately after a (sub)section header.
Reported as an issue on the original project here and here, and on StackOverflow.
Not sure if this is helpful, or if you plan on "importing" all the issues from the original project (if that's even possible).
I opened this because every time I change my CV, it messes up the pagebreaks again, but feel free to close it if this isn't helpful.
Thanks for reviving this project!!

noted, but I have no idea how to fix this. I resort to manually adjusting things.

noted, but I have no idea how to fix this. I resort to manually adjusting things.

This hack, based on https://github.com/xdanaux/moderncv/issues/82#issuecomment-570812909, "solved" my issue:
\usepackage{needspace}
\let\oldsection=\section
\renewcommand{\section}{%
  \needspace{3\baselineskip}
  \oldsection
}

This hack, based on https://github.com/xdanaux/moderncv/issues/82#issuecomment-570812909, "solved" my issue:
\usepackage{needspace}
\let\oldsection=\section
\renewcommand{\section}{%
  \needspace{3\baselineskip}
  \oldsection
}

is this in all styles or one specific style?

is this in all styles or one specific style?

ok, seems like a proper solution is contained in this post. Posting this for reference.

ok, seems like a proper solution is contained in this post. Posting this for reference.

is this in all styles or one specific style?
I mean, I know that page breaks are horrible with the fancy style, but this is due to a dirty hack that as of now has no other solution.
So in fancy, manual adjustments are needed for sure.

I've only ever used the classic style, so I can only confirm the problem and the solution for classic.

is this in all styles or one specific style?
I mean, I know that page breaks are horrible with the fancy style, but this is due to a dirty hack that as of now has no other solution.
So in fancy, manual adjustments are needed for sure.

I've only ever used the classic style, so I can only confirm the problem and the solution for classic.

I think I fixed it, at least it works with my own CV.
Could someone test if it works with their CV, too? The new code can be found here.

I think I fixed it, at least it works with my own CV.
Could someone test if it works with their CV, too? The new code can be found here.

I just tested it.
With the old code, I had an orphaned section and subsection header. The new code "unorphaned" the subsection header and placed it on the next page, but left the section header orphaned on the previous page.
I don't fully understand how this works, but my guess is that there was "enough" penalty for one header, but not enough for two.
Hope this helps.
I can try to create a MWE if you can't replicate this.
Thanks!

I just tested it.
With the old code, I had an orphaned section and subsection header. The new code "unorphaned" the subsection header and placed it on the next page, but left the section header orphaned on the previous page.
I don't fully understand how this works, but my guess is that there was "enough" penalty for one header, but not enough for two.
Hope this helps.
I can try to create a MWE if you can't replicate this.
Thanks!

uh interesting. I don't use subsections in my cv. maybe I should.
could you try using the command
\ setlength {\ cvstretchability }{<length>}

in your document where  can be e.g. \ baselineskip  or another length like 100pt

uh interesting. I don't use subsections in my cv. maybe I should.
could you try using the command
\ setlength {\ cvstretchability }{<length>}

in your document where  can be e.g. \ baselineskip  or another length like 100pt

I had to go all the way up to \setlength{\cvstretchability}{5\baselineskip} to get it to work, but then another section that previosuly displayed 11 lines of text on page 2 was completely pushed to page 3, leaving a lot of empty space on page 2.

I had to go all the way up to \setlength{\cvstretchability}{5\baselineskip} to get it to work, but then another section that previosuly displayed 11 lines of text on page 2 was completely pushed to page 3, leaving a lot of empty space on page 2.

mhh ok, so I introduced separate stretchabilities for both sections and subsections and played around with that, but the result highly depends on the content of the CV. Notably, I don't see any generic MWE.
Example:
In my section IT Skills I use my new skillmatrix feature. Due to the legend being quite a big block I get an orphaned section.
But if I added another \cventry{}{} before the skill matrix (or instead of that), that item would still fit. Therefore latex does not break the page and rightly so. If I added instead of \cventry a \subsection command, again, we would end up with an orphaned section, subsection pair.
This leads to the following problem: if I increased the  stretchability for \section (and possibly \subsection) by default, I'd force a page break by default in all these situations. In the first and third setting this might be desired, but in the second setting wastes too much space.
So in short, I don't see a generic optimal for all cases. Notably, the „orphaned section“ problem does not seem to have a solution. Therefore, I believe it is best to provide the user with the options
\setlength{\cvsectionstretchability}{<some length>}
\setlength{\cvsubsectionstretchability}{<some other length>}

to adjust the stretchability when needed, but not set it by default. This will be explained in the new user manual.
This means a certain element of manual adjustment for each CV similar to including a manual page breaks or adjusting \arraystretch but I don't see another solution.

mhh ok, so I introduced separate stretchabilities for both sections and subsections and played around with that, but the result highly depends on the content of the CV. Notably, I don't see any generic MWE.
Example:
In my section IT Skills I use my new skillmatrix feature. Due to the legend being quite a big block I get an orphaned section.
But if I added another \cventry{}{} before the skill matrix (or instead of that), that item would still fit. Therefore latex does not break the page and rightly so. If I added instead of \cventry a \subsection command, again, we would end up with an orphaned section, subsection pair.
This leads to the following problem: if I increased the  stretchability for \section (and possibly \subsection) by default, I'd force a page break by default in all these situations. In the first and third setting this might be desired, but in the second setting wastes too much space.
So in short, I don't see a generic optimal for all cases. Notably, the „orphaned section“ problem does not seem to have a solution. Therefore, I believe it is best to provide the user with the options
\setlength{\cvsectionstretchability}{<some length>}
\setlength{\cvsubsectionstretchability}{<some other length>}

to adjust the stretchability when needed, but not set it by default. This will be explained in the new user manual.
This means a certain element of manual adjustment for each CV similar to including a manual page breaks or adjusting \arraystretch but I don't see another solution.

There isn't directly. We can only tell latex to break \section and \subsection to the new page if latex does not have „enough“ space left on the current page for an entire line (or possibly several lines. This is defined by the stretchability command).
I updated the code to
\setlength{\cvsectionstretchability}{.9\baselineskip}
\setlength{\cvsubsectionstretchability}{.9\baselineskip}

by default. This should solve orphaned \section and \subsection commands that are used alone for most people. (Feel free to test after downloading the updated code  by commenting out your subsection command following the section command in your CV).
However latex does not check for content. So in case of using
\section{blub}
\subsection{blubblub}

directly one after the other (like you do in your CV), the subsection will be unorphaned leaving enough space on the previous page for latex not to also break \section{blub} to the new page. One way of solving this is to increase \cvsectionstretchability to an artificially high value to force the break of the section header. (try this!).
However, this will change the behaviour for all \section commands in your CV and might cause a page break in a situation where it would not have been necessary (down the line on another page), e.g. in a case like
\section{blub}
\cvitem{blubblub}

in which the item  previously would have fit on the page. You described this effect yourself in one of your previous posts.
I therefore believe that in that special case (your case) it is better to solve the page break by a \newpage command.

There isn't directly. We can only tell latex to break \section and \subsection to the new page if latex does not have „enough“ space left on the current page for an entire line (or possibly several lines. This is defined by the stretchability command).
I updated the code to
\setlength{\cvsectionstretchability}{.9\baselineskip}
\setlength{\cvsubsectionstretchability}{.9\baselineskip}

by default. This should solve orphaned \section and \subsection commands that are used alone for most people. (Feel free to test after downloading the updated code  by commenting out your subsection command following the section command in your CV).
However latex does not check for content. So in case of using
\section{blub}
\subsection{blubblub}

directly one after the other (like you do in your CV), the subsection will be unorphaned leaving enough space on the previous page for latex not to also break \section{blub} to the new page. One way of solving this is to increase \cvsectionstretchability to an artificially high value to force the break of the section header. (try this!).
However, this will change the behaviour for all \section commands in your CV and might cause a page break in a situation where it would not have been necessary (down the line on another page), e.g. in a case like
\section{blub}
\cvitem{blubblub}

in which the item  previously would have fit on the page. You described this effect yourself in one of your previous posts.
I therefore believe that in that special case (your case) it is better to solve the page break by a \newpage command.

authors: cryptointerest hudcap

repo: moderncv/moderncv


text:
Modin on OmniSci constructs incorrect frame when 'dtype=datetime'

System information

OmniSci branch: intel-go/omniscidb/gal/fix_pytests
Modin branch: intel-go/modin/omnisci-on-ray
Code we can use to reproduce:

import os

os.environ["MODIN_EXPERIMENTAL"] = "True"
os.environ["MODIN_ENGINE"] = "ray"
os.environ["MODIN_BACKEND"] = "omnisci"

if __name__ == "__main__":
    import modin.pandas as pd
    import pandas

    data = pd.date_range("2016-12-31", periods=128, freq="D", tz="Europe/Berlin")
    modin_series = pd.Series(data)
    pandas_series = pandas.Series(data)
    print(f"{len(pandas_series)} != {len(modin_series)}") # Output: 128 != 32

    print("pandas_series:\n", pandas_series, sep="")
    print("modin_series:\n", modin_series, sep="")

Output
128 != 32
pandas_series:
0     2016-12-31 00:00:00+01:00
1     2017-01-01 00:00:00+01:00
2     2017-01-02 00:00:00+01:00
3     2017-01-03 00:00:00+01:00
4     2017-01-04 00:00:00+01:00
                 ...
123   2017-05-03 00:00:00+02:00
124   2017-05-04 00:00:00+02:00
125   2017-05-05 00:00:00+02:00
126   2017-05-06 00:00:00+02:00
127   2017-05-07 00:00:00+02:00
Length: 128, dtype: datetime64[ns, Europe/Berlin]
modin_series:
0    2016-12-30 23:00:00
1    2016-12-31 23:00:00
2    2017-01-01 23:00:00
3    2017-01-02 23:00:00
4    2017-01-03 23:00:00
5    2017-01-04 23:00:00
6    2017-01-05 23:00:00
7    2017-01-06 23:00:00
8    2017-01-07 23:00:00
9    2017-01-08 23:00:00
10   2017-01-09 23:00:00
11   2017-01-10 23:00:00
12   2017-01-11 23:00:00
13   2017-01-12 23:00:00
14   2017-01-13 23:00:00
15   2017-01-14 23:00:00
16   2017-01-15 23:00:00
17   2017-01-16 23:00:00
18   2017-01-17 23:00:00
19   2017-01-18 23:00:00
20   2017-01-19 23:00:00
21   2017-01-20 23:00:00
22   2017-01-21 23:00:00
23   2017-01-22 23:00:00
24   2017-01-23 23:00:00
25   2017-01-24 23:00:00
26   2017-01-25 23:00:00
27   2017-01-26 23:00:00
28   2017-01-27 23:00:00
29   2017-01-28 23:00:00
30   2017-01-29 23:00:00
31   2017-01-30 23:00:00
dtype: datetime64[ns]

Describe the problem
Resulted frame has incorrect length

Something wrong happens with the frame on the way to the OmniSci partition. If I try to print it in OmnisciOnRayFramePartition.put it looks like it has 128 rows, but if I try to call DataFrame.to_csv for this frame then I get
IndexError: index 32 is out of bounds for axis 0 with size 32

I'll look further.

Looks like the problem is in Pandas itself triggered in BaseFrameManager.from_pandas. Here we compute row_chunksize and col_chunksize which seem to be at least 32 by default. Then we perform df.iloc[0 : 128, 0 : 32] for the frame with a single column and the result is a broken frame. Here is a reproducer on Pandas:
import pandas
data = pd.date_range("2016-12-31", periods=128, freq="D", tz="Europe/Berlin")
df = pandas.DataFrame(data)
df = df.iloc[0 : 128, 0 : 32]
print(df)

The output is:
                            0
0   2016-12-31 00:00:00+01:00
1   2017-01-01 00:00:00+01:00
2   2017-01-02 00:00:00+01:00
3   2017-01-03 00:00:00+01:00
4   2017-01-04 00:00:00+01:00
..                        ...
123 2017-01-27 00:00:00+01:00
124 2017-01-28 00:00:00+01:00
125 2017-01-29 00:00:00+01:00
126 2017-01-30 00:00:00+01:00
127 2017-01-31 00:00:00+01:00

[128 rows x 1 columns]

Here index seems to have 128 elements but the last row is the 32nd row of the original frame. Attempt to dump this frame into CSV would cause an error:
IndexError: index 32 is out of bounds for axis 0 with size 32

According to Pandas's doc slice indexers allow out-of-bounds indexing, so problem is in Pandas.

This issue is resolved in Pandas 1.1.1

I saw the work for Pandas 1.1 support is in progress. Are we going to fully migrate to the latest Pandas version? Do we need to support Pandas 1.0.5 and avoid out-of-bounds indexing in partitioner? @devin-petersohn @Garra1980

I suppose we wait Pandas 1.1 support

Yes #1840 is in progress.

#1840 is closed. Now we are on pandas==1.1.2.

The series length is correct now for this case.

authors: Garra1980 YarShev dchigarev devin-petersohn ienkovich

repo: modin-project/modin


text:
BUG: modin.pandas raises dask error

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.

[X] 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 = pd.DataFrame({"Date": pd.date_range("2001-01-01", freq="d", periods=12)})
df["Year"] = df.Date.apply(lambda x: x.isocalendar().year)
df["Week"] = df.Date.apply(lambda x: x.isocalendar().week)
df["Yearweek"] = df.Year * 100 + df.Week

df["Monday"] = pd.to_datetime(
    df.Year.astype(str) + "-" + df.Week.astype(str) + "-" + "1", format="%Y-%W-%w"
)

Issue Description
In 2 out of 3 calls to the above code the error message displayed below is raised. While I first thought that it was related to pd.to_datetime the message also was displayed after a call to df.Date.apply.
Expected Behavior
I'd expect the code to either work or raise an error explaining what I'm doing wrong.
Error Logs

2022-12-31 15:19:43,724 - distributed.worker - ERROR - Exception during execution of task lambda-3ade1fb0d35c6d6f924bbaaf93130a25.
Traceback (most recent call last):
  File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/site-packages/distributed/worker.py", line 2364, in _prepare_args_for_execution
    data[k] = self.data[k]
  File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/site-packages/distributed/spill.py", line 269, in __getitem__
    return super().__getitem__(key)
  File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/site-packages/zict/buffer.py", line 108, in __getitem__
    raise KeyError(key)
KeyError: 'deploy_dask_func-eb9b23df-06bb-4b51-aef4-309397fb2b2b'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/site-packages/distributed/worker.py", line 2246, in execute
    args2, kwargs2 = self._prepare_args_for_execution(ts, args, kwargs)
  File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/site-packages/distributed/worker.py", line 2368, in _prepare_args_for_execution
    data[k] = Actor(type(self.state.actors[k]), self.address, k, self)
KeyError: 'deploy_dask_func-eb9b23df-06bb-4b51-aef4-309397fb2b2b'

Installed Versions

INSTALLED VERSIONS
commit           : 5ebbac683321d23c975d059a995eb7cc1b6353e9
python           : 3.9.15.final.0
python-bits      : 64
OS               : Darwin
OS-release       : 22.2.0
Version          : Darwin Kernel Version 22.2.0: Fri Nov 11 02:08:47 PST 2022; root:xnu-8792.61.2~4/RELEASE_X86_64
machine          : x86_64
processor        : i386
byteorder        : little
LC_ALL           : None
LANG             : en_US.UTF-8
LOCALE           : None.UTF-8
Modin dependencies
modin            : 0.18.0+25.g5ebbac68
ray              : 2.2.0
dask             : 2022.12.1
distributed      : 2022.12.1
hdk              : None
pandas dependencies
pandas           : 1.5.2
numpy            : 1.24.1
pytz             : 2022.7
dateutil         : 2.8.2
setuptools       : 65.6.3
pip              : 22.3.1
Cython           : None
pytest           : None
hypothesis       : None
sphinx           : None
blosc            : None
feather          : None
xlsxwriter       : None
lxml.etree       : None
html5lib         : None
pymysql          : None
psycopg2         : None
jinja2           : 3.1.2
IPython          : 8.7.0
pandas_datareader: None
bs4              : 4.11.1
bottleneck       : None
brotli           :
fastparquet      : None
fsspec           : 2022.11.0
gcsfs            : None
matplotlib       : None
numba            : None
numexpr          : None
odfpy            : None
openpyxl         : None
pandas_gbq       : None
pyarrow          : 10.0.1
pyreadstat       : None
pyxlsb           : None
s3fs             : None
scipy            : None
snappy           : None
sqlalchemy       : None
tables           : None
tabulate         : None
xarray           : None
xlrd             : None
xlwt             : None
zstandard        : None
tzdata           : None

Hi @kaijennissen! Thank you so much for opening this bug! I tried to reproduce it locally, but found that the script failed for a different reason - the output of isocalendar() was a tuple, rather than a named tuple, and so calling year and week failed. When I replaced it with the appropriate index 0, and 1, like below, the whole script worked:
import modin.pandas as pd

df = pd.DataFrame({"Date": pd.date_range("2001-01-01", freq="d", periods=12)})
df["Year"] = df.Date.apply(lambda x: x.isocalendar()[0])
df["Week"] = df.Date.apply(lambda x: x.isocalendar()[1])
df["Yearweek"] = df.Year * 100 + df.Week

df["Monday"] = pd.to_datetime(
    df.Year.astype(str) + "-" + df.Week.astype(str) + "-" + "1", format="%Y-%W-%w"
)

Please let me know if that resolves the issue for you!

For me it's a named tuple.
>>> df.Date[0].isocalendar()
datetime.IsoCalendarDate(year=2001, week=1, weekday=1)

But using your code still raises the same error message. I've also tried to run the code as a script which raises the following error message. I suspect that dask is broken despite having set up a new conda env.

UserWarning: Dask execution environment not yet initialized. Initializing...
To remove this warning, run the following python code before doing dataframe operations:
from distributed import Client

client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...
To remove this warning, run the following python code before doing dataframe operations:
from distributed import Client

client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...
To remove this warning, run the following python code before doing dataframe operations:
from distributed import Client

client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...
To remove this warning, run the following python code before doing dataframe operations:
from distributed import Client

client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...
To remove this warning, run the following python code before doing dataframe operations:
from distributed import Client

client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...
To remove this warning, run the following python code before doing dataframe operations:
from distributed import Client

client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...
To remove this warning, run the following python code before doing dataframe operations:
from distributed import Client

client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...
To remove this warning, run the following python code before doing dataframe operations:
from distributed import Client

client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...
To remove this warning, run the following python code before doing dataframe operations:
from distributed import Client

client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...
To remove this warning, run the following python code before doing dataframe operations:
from distributed import Client

client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...
To remove this warning, run the following python code before doing dataframe operations:
from distributed import Client

client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...
To remove this warning, run the following python code before doing dataframe operations:
from distributed import Client

client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...
To remove this warning, run the following python code before doing dataframe operations:
from distributed import Client

client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...
To remove this warning, run the following python code before doing dataframe operations:
from distributed import Client

client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...
To remove this warning, run the following python code before doing dataframe operations:
from distributed import Client

client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...
To remove this warning, run the following python code before doing dataframe operations:
from distributed import Client

client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...
To remove this warning, run the following python code before doing dataframe operations:
from distributed import Client

client = Client()

UserWarning: Port 8787 is already in use.
Perhaps you already have a cluster running?
Hosting the HTTP server on port 59053 instead
UserWarning: Port 8787 is already in use.
Perhaps you already have a cluster running?
Hosting the HTTP server on port 59054 instead
UserWarning: Port 8787 is already in use.
Perhaps you already have a cluster running?
Hosting the HTTP server on port 59055 instead
UserWarning: Port 8787 is already in use.
Perhaps you already have a cluster running?
Hosting the HTTP server on port 59056 instead
UserWarning: Port 8787 is already in use.
Perhaps you already have a cluster running?
Hosting the HTTP server on port 59062 instead
UserWarning: Port 8787 is already in use.
Perhaps you already have a cluster running?
Hosting the HTTP server on port 59063 instead
UserWarning: Port 8787 is already in use.
Perhaps you already have a cluster running?
Hosting the HTTP server on port 59064 instead
UserWarning: Port 8787 is already in use.
Perhaps you already have a cluster running?
Hosting the HTTP server on port 59066 instead
UserWarning: Port 8787 is already in use.
Perhaps you already have a cluster running?
Hosting the HTTP server on port 59068 instead
UserWarning: Port 8787 is already in use.
Perhaps you already have a cluster running?
Hosting the HTTP server on port 59069 instead
UserWarning: Port 8787 is already in use.
Perhaps you already have a cluster running?
Hosting the HTTP server on port 59070 instead
UserWarning: Port 8787 is already in use.
Perhaps you already have a cluster running?
Hosting the HTTP server on port 59073 instead
UserWarning: Port 8787 is already in use.
Perhaps you already have a cluster running?
Hosting the HTTP server on port 59074 instead
UserWarning: Port 8787 is already in use.
Perhaps you already have a cluster running?
Hosting the HTTP server on port 59079 instead
UserWarning: Port 8787 is already in use.
Perhaps you already have a cluster running?
Hosting the HTTP server on port 59082 instead
UserWarning: Port 8787 is already in use.
Perhaps you already have a cluster running?
Hosting the HTTP server on port 59083 instead
2023-01-03 12:26:30,982 - distributed.nanny - ERROR - Failed to start process
Traceback (most recent call last):
File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/site-packages/distributed/nanny.py", line 442, in instantiate
result = await self.process.start()
File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/site-packages/distributed/nanny.py", line 707, in start
await self.process.start()
File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/site-packages/distributed/process.py", line 38, in _call_and_set_future
res = func(*args, **kwargs)
File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/site-packages/distributed/process.py", line 201, in _start
process.start()
File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/multiprocessing/process.py", line 121, in start
self._popen = self._Popen(self)
File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/multiprocessing/context.py", line 284, in _Popen
return Popen(process_obj)
File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/multiprocessing/popen_spawn_posix.py", line 32, in init
super().init(process_obj)
File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/multiprocessing/popen_fork.py", line 19, in init
self._launch(process_obj)
File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/multiprocessing/popen_spawn_posix.py", line 42, in _launch
prep_data = spawn.get_preparation_data(process_obj._name)
File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/multiprocessing/spawn.py", line 154, in get_preparation_data
_check_not_importing_main()
File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/multiprocessing/spawn.py", line 134, in _check_not_importing_main
raise RuntimeError('''
RuntimeError:
An attempt has been made to start a new process before the
current process has finished its bootstrapping phase.
    This probably means that you are not using fork to start your
    child processes and you have forgotten to use the proper idiom
    in the main module:

        if __name__ == '__main__':
            freeze_support()
            ...

    The "freeze_support()" line can be omitted if the program
    is not going to be frozen to produce an executable.

For me it's a named tuple.

>>> df.Date[0].isocalendar()

datetime.IsoCalendarDate(year=2001, week=1, weekday=1)

But using your code still raises the same error message. I've also tried to run the code as a script which raises the following error message. I suspect that dask is broken despite having set up a new conda env.

UserWarning: Dask execution environment not yet initialized. Initializing...

To remove this warning, run the following python code before doing dataframe operations:

    from distributed import Client

    client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...

To remove this warning, run the following python code before doing dataframe operations:

    from distributed import Client

    client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...

To remove this warning, run the following python code before doing dataframe operations:

    from distributed import Client

    client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...

To remove this warning, run the following python code before doing dataframe operations:

    from distributed import Client

    client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...

To remove this warning, run the following python code before doing dataframe operations:

    from distributed import Client

    client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...

To remove this warning, run the following python code before doing dataframe operations:

    from distributed import Client

    client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...

To remove this warning, run the following python code before doing dataframe operations:

    from distributed import Client

    client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...

To remove this warning, run the following python code before doing dataframe operations:

    from distributed import Client

    client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...

To remove this warning, run the following python code before doing dataframe operations:

    from distributed import Client

    client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...

To remove this warning, run the following python code before doing dataframe operations:

    from distributed import Client

    client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...

To remove this warning, run the following python code before doing dataframe operations:

    from distributed import Client

    client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...

To remove this warning, run the following python code before doing dataframe operations:

    from distributed import Client

    client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...

To remove this warning, run the following python code before doing dataframe operations:

    from distributed import Client

    client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...

To remove this warning, run the following python code before doing dataframe operations:

    from distributed import Client

    client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...

To remove this warning, run the following python code before doing dataframe operations:

    from distributed import Client

    client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...

To remove this warning, run the following python code before doing dataframe operations:

    from distributed import Client

    client = Client()

UserWarning: Dask execution environment not yet initialized. Initializing...

To remove this warning, run the following python code before doing dataframe operations:

    from distributed import Client

    client = Client()

UserWarning: Port 8787 is already in use.

Perhaps you already have a cluster running?

Hosting the HTTP server on port 59053 instead

UserWarning: Port 8787 is already in use.

Perhaps you already have a cluster running?

Hosting the HTTP server on port 59054 instead

UserWarning: Port 8787 is already in use.

Perhaps you already have a cluster running?

Hosting the HTTP server on port 59055 instead

UserWarning: Port 8787 is already in use.

Perhaps you already have a cluster running?

Hosting the HTTP server on port 59056 instead

UserWarning: Port 8787 is already in use.

Perhaps you already have a cluster running?

Hosting the HTTP server on port 59062 instead

UserWarning: Port 8787 is already in use.

Perhaps you already have a cluster running?

Hosting the HTTP server on port 59063 instead

UserWarning: Port 8787 is already in use.

Perhaps you already have a cluster running?

Hosting the HTTP server on port 59064 instead

UserWarning: Port 8787 is already in use.

Perhaps you already have a cluster running?

Hosting the HTTP server on port 59066 instead

UserWarning: Port 8787 is already in use.

Perhaps you already have a cluster running?

Hosting the HTTP server on port 59068 instead

UserWarning: Port 8787 is already in use.

Perhaps you already have a cluster running?

Hosting the HTTP server on port 59069 instead

UserWarning: Port 8787 is already in use.

Perhaps you already have a cluster running?

Hosting the HTTP server on port 59070 instead

UserWarning: Port 8787 is already in use.

Perhaps you already have a cluster running?

Hosting the HTTP server on port 59073 instead

UserWarning: Port 8787 is already in use.

Perhaps you already have a cluster running?

Hosting the HTTP server on port 59074 instead

UserWarning: Port 8787 is already in use.

Perhaps you already have a cluster running?

Hosting the HTTP server on port 59079 instead

UserWarning: Port 8787 is already in use.

Perhaps you already have a cluster running?

Hosting the HTTP server on port 59082 instead

UserWarning: Port 8787 is already in use.

Perhaps you already have a cluster running?

Hosting the HTTP server on port 59083 instead

2023-01-03 12:26:30,982 - distributed.nanny - ERROR - Failed to start process

Traceback (most recent call last):

  File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/site-packages/distributed/nanny.py", line 442, in instantiate

    result = await self.process.start()

  File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/site-packages/distributed/nanny.py", line 707, in start

    await self.process.start()

  File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/site-packages/distributed/process.py", line 38, in _call_and_set_future

    res = func(*args, **kwargs)

  File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/site-packages/distributed/process.py", line 201, in _start

    process.start()

  File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/multiprocessing/process.py", line 121, in start

    self._popen = self._Popen(self)

  File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/multiprocessing/context.py", line 284, in _Popen

    return Popen(process_obj)

  File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/multiprocessing/popen_spawn_posix.py", line 32, in __init__

    super().__init__(process_obj)

  File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/multiprocessing/popen_fork.py", line 19, in __init__

    self._launch(process_obj)

  File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/multiprocessing/popen_spawn_posix.py", line 42, in _launch

    prep_data = spawn.get_preparation_data(process_obj._name)

  File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/multiprocessing/spawn.py", line 154, in get_preparation_data

    _check_not_importing_main()

  File "/usr/local/Caskroom/miniconda/base/envs/modin/lib/python3.9/multiprocessing/spawn.py", line 134, in _check_not_importing_main

    raise RuntimeError('''

RuntimeError:

        An attempt has been made to start a new process before the

        current process has finished its bootstrapping phase.

        This probably means that you are not using fork to start your

        child processes and you have forgotten to use the proper idiom

        in the main module:

            if __name__ == '__main__':

                freeze_support()

                ...

        The "freeze_support()" line can be omitted if the program

        is not going to be frozen to produce an executable.

That makes sense! It seems that the issue here is with starting up Dask - even the original trace seems more to be an internal Dask error, although I can't be certain without seeing the full trace. What happens if you kill all Dask processes and restart? Could you try using Ray as an engine instead to see if the error persists (making it a Modin error) or if it goes away (implying it's an error internal to Dask)!

@kaijennissen, can you put your code under if __name__ == '__main__':? Here you can find more info about the issue.
https://modin.readthedocs.io/en/stable/getting_started/troubleshooting.html#error-when-using-dask-engine-runtimeerror-if-name-main

@RehanSD
Running the script with rayworks fine.
@YarShev
Placing the code inside if __name__ == __'main__' fixed the above error but  does not fix the initial error.

authors: RehanSD YarShev kaijennissen


text:
Fixed sum to use min_count properly

What do these changes do?
Catches some extra errors and fixes it so that min_count is followed properly in sum
Related issue number
resolves #169

[x] passes git diff upstream/master -u -- "*.py" | flake8 --diff
[x] passes black --check modin/

@osalpekar fixed sum better


text:
FIX-#5488: Remove usage of deprecated numpy types

Signed-off-by: Anatoly Myachev anatoly.myachev@intel.com

What do these changes do?

[x] first commit message and PR title follow format outlined here

NOTE:  If you edit the PR title to match this format, you need to add another commit (even if it's empty) or amend your last commit for the CI job that checks the PR title to pick up the new PR title.

[x] passes flake8 modin/ asv_bench/benchmarks scripts/doc_checker.py
[x] passes black --check modin/ asv_bench/benchmarks scripts/doc_checker.py
[x] signed commit with git commit -s
[x] Resolves #5488
[x] tests added and passing
[x] module layout described at docs/development/architecture.rst is up-to-date

Thanks for fixing this!
It's a pity though that pytest doesn't show deprecation warnings that are being generated during tests (even if -s flag was passed)

I think they are not shown because of --disable-pytest-warnings setting: https://github.com/modin-project/modin/blob/b541b6c18e6fb4515e998b9b4f88528490cf69c6/setup.cfg#L15


text:
FEAT-#3044: Create Extentions Module in Modin

What do these changes do?

Adds extensions capability to Modin.

[x] first commit message and PR title follow format outlined here

NOTE:  If you edit the PR title to match this format, you need to add another commit (even if it's empty) or amend your last commit for the CI job that checks the PR title to pick up the new PR title.

[x] passes flake8 modin/ asv_bench/benchmarks scripts/doc_checker.py
[x] passes black --check modin/ asv_bench/benchmarks scripts/doc_checker.py
[x] signed commit with git commit -s
[x] Resolves #3044
[x] tests added and passing
[x] module layout described at docs/development/architecture.rst is up-to-date

Just in case, CI is failing for now and we are working on that in https://github.com/modin-project/modin/pull/6969.

Sounds great @YarShev. I think we can leave this undocumented for the moment since I put some extensive docstrings in the PR. Eventually those should be the docs, but we can enable it in a separate PR.

This is finally passing and ready for final review!

@sfc-gh-dpetersohn, I had some more questions on the changes but not to waste time I went ahead and pushed some changes. Hope, it is fine to you.

Yes, of course this is fine with me @YarShev 😄. I am always forgetting the license headers.


text:
TEST-#7086: Explicitly check for exceptions in test_reduce.py

What do these changes do?

[x] first commit message and PR title follow format outlined here

NOTE:  If you edit the PR title to match this format, you need to add another commit (even if it's empty) or amend your last commit for the CI job that checks the PR title to pick up the new PR title.

[x] passes flake8 modin/ asv_bench/benchmarks scripts/doc_checker.py
[x] passes black --check modin/ asv_bench/benchmarks scripts/doc_checker.py
[x] signed commit with git commit -s
[x] Resolves #7086
[x] tests added and passing
[x] module layout described at docs/development/architecture.rst is up-to-date

Depends on #7089.

Now it doesn't depend.


text:
Unable to unzip the models.zip

Hi,
Thanks for providing the code for the paper!
However, the provided models.zip can not be extracted using unzip models.zip.
Could you help with that?

can you show the error information?

repo: modit-team/MODIT


text:
ModuleFederation remotes are optional

Hello! First, congrats for the awesome work here!
This line throws error when remotes property isnt present, and its common omit it when use dynamic remotes with runtime lazyload.
TypeError: Cannot convert undefined or null to object
    at Function.entries (<anonymous>)

you can replace it with an empty object: {}

Feel free to PR the plugin if there's problems with some options - I've not tested it in the wild so not aware of some of these occasions

authors: ScriptedAlchemy flaviuse menosprezzi

repo: module-federation/nextjs-mf


text:
Could you plz give another examples?

Hi! i'm using your darknetz for my study. first of all , i d'like to thank u for opening this well-made code. but i d'like to train and test anther examples in addition to classifier. so could you plz give another examples for training and testing??

Hi @khw1234 , thanks.
If you want to train another model, you will need to put your data in the correct format under the /root/data/ dir, and then write your model structure in a XXX.cfg file under the root/cfg/ dir.
You can also have a look at generic darknet https://pjreddie.com/darknet/ to get familiar with the training and testing. Then darknetz with TEE is easier.

repo: mofanv/darknetz


text:
[Enchancement] : Support caddy server

Hi there,
Thanks for making this awesome project. Do you guys plan to have support for caddyserver?
Here is a simple config to have caddy support X-Sendfile :
   handle /* {
        reverse_proxy localhost:8000 {
            @sendfile header X-Sendfile *
            handle_response @sendfile {
                rewrite {http.reverse_proxy.header.X-Sendfile}
                file_server
            }
        }
    }

If caddy supports X-Sendfile then it should be good to go already.

Caddy by default doesn't have X-Sendfile directive.
From there document they use X-Accel-Redirect
reverse_proxy localhost:8080 {
	@accel header X-Accel-Redirect *
	handle_response @accel {
		root    * /path/to/private/files
		rewrite * {rp.header.X-Accel-Redirect}
		file_server
	}
}

Shouldn't there be a section in README.md clarifying this ?


text:
Allow error format methods to be overridden

Pull Request Checklist

[x] Have you read How to write the perfect pull request?
[x] Have you read through the contributor guidelines?
[x] Have you squashed your commits?

Purpose
This PR allows users to override the error format methods when extending DefaultSecuredErrorHandler
References
This was discussed in the Gitter channel.

Changes Unknown when pulling 4cc4bdacce9bb912961360ab8a725943db69d182 on jtescher:patch-1 into ** on mohiva:master**.

Thanks :+1:

authors: akkie coveralls jtescher

repo: mohiva/play-silhouette


text:
onPurchasedProductsFetched is always called twice

onPurchasedProductsFetched is called twice on connect().
One time with purchases empty and once with purchases as expected (in case the user purchased).
The worst thing is that there's a race condition so you can't even write a logic based on skipping the first time as sometimes this is the correct data, followed by the false data.
It doesn't help to connect before setting the listener or after.

onPurchasedProductsFetched is called twice on connect(). One time with purchases empty and once with purchases as expected (in case the user purchased). The worst thing is that there's a race condition so you can't even write a logic based on skipping the first time as sometimes this is the correct data, followed by the false data.
It doesn't help to connect before setting the listener or after.

I had the same issue. If your device supports subscriptions, then the code sends first callback to onPurchasedProductsFetched(..) and second one containing the actual purchase history you are interested in. This is how the library is designed currently.
In my case, I am only interested in INAPP purchases so I skipped all redundant callbacks by checking productType == ProductType.INAPP.

I've never had any problems restoring purchases with my app, but I'm only using INAPP
What's the status of the issue? Checking the productType is a workaround or still having issues?

It helps for sure. I still have some reports from users saying they "lose" their Pro purchase experience but I didn't check yet if it's a lib issue or my own implementation issue. I can say that it started happening since I switched to this lib and only when the user opens the app after it was in the background for a while (Don't keep activities doesn't reproduce the same conditions unfortunately).

The onPurchasedProductsFetched is MEANT to be called twice, once for each product type (IN-APP and SUBS).
Try to follow the logic from the RemoveAdsExampleActivity...
Also, it's good to know that Google Billing API returns purchases details for currently owned items without a network request using the Google Play Store cache...


text:
Linking on columns with different names

comparison_columns in settings assumed columns both have the same name in two datasets. Fine for deduping, but not necessarily the case when linking (e.g. l.birth_date = r.dob)

Yep.  This will be a bit annoying for users who will have to rename columns.
But I think the additional complexity of code we'd need in sparklink isn't worth it - e.g. we'd have to fundamentally change the settings object.

I assume this is still not possible with splink3? I have a Phone and CellPhone column in 1 dataset and I want to link either of those to a Phone column in a different dataset.

authors: RobinL rjbks samnlindsay

repo: moj-analytical-services/splink


text:
Issue 1225 - Poor performance of estimate u in a link_only job

Type of PR

[ ] BUG
[x] FEAT
[ ] MAINT
[ ] DOC

Is your Pull Request linked to an existing Issue or Pull Request?
Closes #1225 - see the issue for a detailed description of the underlying cause of the problem
Built on top of #1059 so let's get that merged first, then we can point this at master
Give a brief description for the solution you have provided
The challenge is that for a link only, it's much more efficient to run sql like:
select ...
from df_one
inner join
df_two
[where conditions]

rather than concatenating the two and running:
select ...
from dfs_concat as l
inner join
dfs_concat as r
where l.source_dataset != r.source_dataset
[other where conditions]

The later  is inefficient because intra-dataset comparisons are generated and then rejected, rather than never being generated.
The efficient solution is fine for the n=2 case, but in n=3 you'd need (pseudocode):
df_one inner join df_two
union all
df_one inner join df_three
union all
df_two inner join df_three

This statement will quickly become unmanageable as n grows
Options:

Could try to implement a left join approach for the n=2 case (which is most common).  This is relatively straightforward in the case of 2 input datasets, but results in n choose 2 joins in the more general case of n datasets.

Pros:

Consistent with the approach I currently use for blocking.

Cons:

Doesn't solve the n>2 case.

In the case if unbalanced datasets, (we could test when the ratio of target rows to total comparisons is poor), change link_type to 'link and dedupe' for the purpose of estimating u

Pros:

Generalise to n>2

Cons:

Questionable estimates of u

Conclusion
For the moment I've gone with option 1 since it preserves the quality of estimates.
Note that the code still works for n>2, it just uses the less inefficient where l.source_dataset != r.source_dataset which is  n't too bad in most cases, but gets extremely bad in the case of very unbalanced datsets.
PR Checklist

[ ] Added tests (if appropriate)

Remember that once https://github.com/moj-analytical-services/splink/issues/1061 is merged, it will be possible to write tests of this using the sql that has been generated

Rough Test Results
Some very rough performance metrics for this change (done locally and not w/ pytest):

df_l size
df_r size
old performance
new performance

1000
512,000
1220 seconds
55 seconds

256,000
256,000
70 seconds
52 seconds

For the heavily unbalanced job, this new method appears to be about 24x faster.
It also appears to have an indirect impact on the performance of standard u training jobs, being approx 34% faster in the test below.

Test Code
import time
from splink.duckdb.duckdb_linker import DuckDBLinker
import pandas as pd

from tests.basic_settings import get_settings_dict

df_l = pd.read_csv("./tests/datasets/fake_1000_from_splink_demos.csv")
df_r = df_l.copy()

for _ in range(9):
    df_r = pd.concat([df_r, df_r])

settings = get_settings_dict()
settings["link_type"] = "link_only"

# Equally sized link
# linker = DuckDBLinker(
#     [df_r, df_r],
#     settings,
# )

# Heavily weighted df on right
linker = DuckDBLinker(
    [df_l, df_r],
    settings,
)

start = time.time()
linker.estimate_u_using_random_sampling(target_rows=1e8)
display(time.time()-start)

authors: RobinL ThomasHepworth


text:
Go进阶18:常用加密解密算法总结AES/DES/RSA/Sha1/Sha256/MD5 | MojoTech

https://mojotv.cn/go/golang-crypto

写的不错啊，sha那部分正好解惑了，博主 sha和hmac是两个加密算法，示例是不是不准确？

rsa类型的，使用私钥加密，公钥解密怎么处理

AES加密的import（）里的内容是需要自定义吗

authors: KylinGu fanne mojocn tyxjrstsr

repo: mojocn/gitalk-db


text:
Respect skip configuration

It will be greate if plugin will respect skip option
                <configuration>
                    <skip>true</skip>
                </configuration>

Can you explain a little bit more why you need a skip configuration ? Usually this shows that there is a smell in your build..?

I do not remember what exactly was a problem, but think it was some issue with version replacing/resolving, not a reporting (e.g. update-parent or resolve-ranges goals).

The replacing of versions etc. should be done on command line and not within the pom file...so I'm not sure if a skip would help here...sounds like wrong usage...If you have further information please don't hesitate to reopen the issue..

I also need this option. This setting is needed to speed up the build of work assemblies. Yes, I understand that the plug-in's work is short, but when there are many such plugins...

authors: Alexilmarranen foal khmarbaise

repo: mojohaus/versions-maven-plugin


text:
[Question]: I am Unable to Sort if it is Done & How to Add Filter Form in Header

What happened?
I would like to add this type of Form, using Schema How can achieve it?

Sometime having issue Unable to if it is done: as you see in the first Part of Video
https://github.com/mokhosh/filament-kanban/assets/55267488/d82ee0d5-c184-4553-9ed0-8ed6cc5b76be
How to reproduce the bug
None
Package Version
2.2
PHP Version
8.2
Laravel Version
10.10
Which operating systems does with happen with?
No response
Which browsers does with happen with?
No response
Notes
No response

Filtering: we don't have this in the package. So you will need to create a form in your kanban-view, and then use the data from that form to filter your records in the records method.
The "Done" issue: maybe you can check the dev tools, and see if there are any errors, or create a replication repository so I can check the issue.

getHeaderActions are not rendering, but When I do dd inside the function it is working but not rendering:
is there anything that I am missing
protected function getHeaderActions(): array
{
    return [
        Actions\Action::make('manage-sprints')
            ->button()
            ->visible(fn () => $this->project->currentSprint)
            ->label(__('Manage sprints'))
            ->color('primary')
            ->url(route('filament.admin.resources.projects.edit', ['record' => $this->project, 'tenant' => \Filament\Facades\Filament::getTenant()->id])),

        Actions\Action::make('refresh')
            ->button()
            ->visible(fn () => $this->project->currentSprint)
            ->label(__('Refresh'))
            ->color('secondary')
            ->action(function () {
                $this->getRecords();
                Notification::make()
                    ->title(__('Kanban board updated'))
                    ->success()
                    ->send();
            }),
    ];
}

I copy pasted your code into a project of mine and it works fine.
Check these two things:

Make sure you're importing the right Action class. It should be Filament\Actions\Action.
Check if $this->project->currentSprint is returning true. Because you're hiding it yourself if it's false with visible()

repo: mokhosh/filament-kanban


text:
[NEW]: Niantic(of Pokemon Go fame) Shuts down Ingress Trading Post (for NFTs)

Date
2023-04-10
Description

Niantic announced that the Ingress Trading Post is shutting down on June 9th. The Trading Post was a web3 project from the SpotX team, a web3 research and development group at Niantic, with the goal of connecting Ingress Agents around the world through digital Ingress Bio Cards.

Links
https://community.ingress.com/en/discussion/21379/thank-you-for-all-your-support-trading-post-ingress-community/
https://tradingpost.nianticlabs.com/
https://www.spotx.games/
Agreement

[X] I irrevocably agree to release my contribution under the CC-BY 3.0 License

Attribution name
Mxx
Personal link
No response

https://web3isgoinggreat.com/?id=niantic-shutters-its-web3-project-after-less-than-six-months

authors: molly mxxcon


text:
[misc] Add Header comment with Current Version

Closes #5057

Coverage decreased (-0.01%) to 88.398% when pulling d6c745e7075b67ec2fab4a13bc994429c315ede5 on CaioSR:patch-1 into 13a61b285c095bda7ea8e33156090ea5ccfeaef1 on moment:develop.

Take a look at https://github.com/moment/moment/issues/5057#issuecomment-618592588

authors: CaioSR coveralls ichernev

repo: moment/moment


text:
fix(Icon): new momentum-design icons

IMPORTANT
Currently, this project is closed to any external contributions. Any pull request made against this project from external sources will likely be closed. If you would like to make changes to this project, please fork this project.
Guide
This "Help" section can be deleted before submitting this pull request.
Update the name of this pull request to reflect the following shape:
{type}/{scope?}/{message}

type - A conventional commit type REQUIRED
scope - The kabab-case scope of the changes in this request
message - A short, kebab-case statement describing the changes REQUIRED

Provide a general summary of the scope of the changes in this pull request.

Readme
Getting Started Guide
Contributing Guide

Description
Fixed the active state of in-meeting raise-hand icon.
Before:

After:

Links
Links to relevent resources.
JIRA: https://jira-eng-gpk2.cisco.com/jira/browse/SPARK-394442

using yarn berry

looks good but have some questions:

we already had a PR from Christoph with similar chages, why the new PR?
why yarn berry?

@torgeadelin,

It is a stale PR, we can merge either this or that, doesn't matter i guess. This PR will prolly not have any merge conflicts etc since it is on latest code.

Used Yarn berry since it is the latest version, is there an issue with yarn berry?

Yes I have tested this locally, the above screenshots are from local.

looks good but have some questions:

we already had a PR from Christoph with similar changes, why the new PR?
why yarn berry?
have you tested by locally linking the package in Cantina

@torgeadelin,
It is a stale PR, we can merge either this or that, doesn't matter i guess. This PR will prolly not have any merge conflicts etc since it is on latest code.
Used Yarn berry since it is the latest version, is there an issue with yarn berry?
Yes I have tested this locally, the above screenshots are from local.


text:
Create updated spreadsheet for mass obsoletion review (4 branches)

This issue is for the technical team, and should be done AFTER ALL THE MASS OBSOLETION FOR BRANCHES WERE DONE AND MERGED. (Sabrina or Trish or Nicole will let you know when it is ready)
Context:
We have been reviewing the effects of term obsoletion on their children. We are using the spreadsheet created by Harshad (issue number something), choosing parents for children to become orphan/leaves the branch after the obsoletion.
After reviewing the spreadsheet, we added these new parents and obsoleted terms going ontology branch by branch.
There are 4 ontology branches for which we could get this review "for free" because most (or all?) of the terms to be obsoleted in these branches have already been obsoleted in other branches (the obsoleted terms were in multiple branches of the ontology).
To do:
For the following 4 ontology branches, recreate the spreadsheets by using an updated list of "terms to be obsoleted" that includes only terms that have not been obsoleted yet. (note: please create NEW spreadsheet, and do not remove the previous/existing spreadsheets)
Ontology branches:

branch ID
branch name

MONDO:0021147
disorder of development or morphogenesis

MONDO:0003847
hereditary disease

MONDO:0002254
syndromic disease

MONDO:0024458
disorder of visual system

Terms to be obsoleted:
Please use the original term to be obsoleted list (list can also be found here, in the tab called "terms to obsolete (230913)), and filter out all the terms that are currently obsoleted in the ontology, and keep the one with the "obsoletion candidate" tag (some terms have been removed from the original obsoletion list).
Note: there is a possibility that this list of terms left to be obsoleted might be very small.
Spreadsheets:
run the same code as previously (Harshad's code) for the 4 branches above, using the list of terms to be obsoleted above.
The spreadsheet includes: all children of terms to be obsoleted + their parents in and outside the branch + their ancestors in and outside the branch.

The results can be found here

Thank you @hrshdhgd
Could you please re-run them again, but remove the following from the list of terms to be obsoleted (they have been removed from the obsoletion candidate list):
MONDO:0019054
MONDO:0015338
MONDO:0019713
MONDO:0015337
THANK YOU!

@sabrinatoro can this be closed?

Yes, this has been done. Closing.

authors: hrshdhgd sabrinatoro twhetzel

repo: monarch-initiative/mondo


text:
split Birt-Hogg-Dube syndrome

close #6518
close https://github.com/monarch-initiative/mondo/issues/6546
(the two tickets were related so I addressed them on one branch)

@nicolevasilevsky Apologies, I just saw something to change

authors: nicolevasilevsky sabrinatoro