text:
Do not resolve Python Path symlinks for datafile hash

Fixes #67
In some cases, the Python binaries of multiple virtual environments can
be symlinks that point to the same file. In this case, the hash of the
reentry data file is the same for these environments, since
Path.resolve() also resolves symlinks.
As sys.executable already returns the absolute path to the environment
Python binary, we can just remove .resolve() to avoid resolving the
symlinks.

Strange, if I run the tests locally with tox they all pass. @ltalirz any ideas?

hm... is it possible that the test setup was missing a reentry scan somewhere that is now surfacing because symlinks are no longer resolved?

Codecov Report

Merging #68 (676977b) into develop (32bfd09) will increase coverage by 0.19%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           develop      #68      +/-   ##
===========================================
+ Coverage    70.95%   71.14%   +0.19%
===========================================
  Files            7        8       +1
  Lines          451      454       +3
===========================================
+ Hits           320      323       +3
  Misses         131      131

Impacted Files
Coverage Δ

reentry/config.py
87.27% <100.00%> (ø)

reentry/__init__.py
100.00% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 577e5bb...676977b. Read the comment docs.

Seems moving up the reentry scan did the trick, thanks @ltalirz!

version 1.3.3 released on pypi

authors: codecov-commenter ltalirz mbercx

repo: aiidateam/reentry


text:
Update neural-networks-2.md

일단 목차만 번역.

Just wanted to use my previous branch. Please forget about this.

source: gharchive/pull-request

license: MIT

license_type: permissive

license_source: github-api


text:
Сделать кнопку "Посмотреть БД" на форме заполнения опросника

Кнопка "Посмотреть БД" раскрывает таблицу.
Первая строка таблицы - это названия таблиц БД, которые являются кнопками.
Ниже выводятся атрибуты с данными, где лимит 10

Оценка 4 ч
Выведу атрибуты без данных

source: gharchive/issue

authors: Nenuahule germanovn

repo: aikus/sql-exam


text:
Add source distribution (tar.gz)

Would it be possible to add a source distribution (tarball/tar.gz) here on github or on pypi? I would like to add this package to the conda-forge in order to make this package accessible to a wider user base.

@mahnerak @alberttorosyan I am also trying to update the outdated conda-forge aim package and would need to package aimrocks. It's easier and preferred to do that from the sdist package instead of the GH repo. Would that be possible for you to upload a sdist package to pypi please? Thank you.

@alberttorosyan would that be possible to also upload the sdist package to pypi instead of only the wheels? This is important for packaging.

Friendly ping here. A gift tag os a sdist file is the only thing needed here. If you add it to your auto release process, it should be all automatic next time.

authors: d-cunningham hadim

repo: aimhubio/aimrocks


text:
let's go to python3

also fixes test_pretty_j1587.py to be runnable

Transition to python3 was overdue. Nice motivation.

authors: BenGardiner salnoobie


text:
Load testing using Jmeter

Create a JMeter file to test the API Gateway and upload images of results

Commit URL: https://github.com/airavata-courses/Team-Rocket/commit/626de71c1cb56526d648091eb582b27f51077ab4

repo: airavata-courses/Team-Rocket


text:
Wrapper.update() not re-render

Hello!!
Bug description:
I'm trying to test if my function is called:
in MyComponent.jsx:
import React from 'react'

class MyComponent extends React.Component {
    calledFunction = () => {
        console.log('I was called')
    }

    render () {
        this.calledFunction()

        return null
    }
}

export default MyComponent

in my MyComponent.test.js:
import React from 'react'
import { mount } from 'enzyme'

import MyComponent from '../components/MyComponent'

describe("<MyComponent />", () => {
    const wrapper = mount(<MyComponent />)

    it('should call calledFunction()', async () => {
        const spy = await jest.spyOn(wrapper.instance(), 'calledFunction')

        await wrapper.update()
        await expect(spy).toHaveBeenCalledTimes(1)
    })
})

The result:

I didn't understood something, for me I should see "I was called" twice because wrapper.update() should forces re-render.
Thank you so much!

The issue is that you're using arrow functions in class fields. You can't spy on them because the rendered tree already has a reference to the original first.
Instead, do this:
class MyComponent extends React.Component {
    calledFunction = this.calledFunction.bind(this);
    calledFunction() {
        console.log('I was called')
    }

    render () {
        this.calledFunction()

        return null
    }
}

and things should work fine.

I trying something like:
in MyComponent.test.js
import React from 'react'
import { mount } from 'enzyme'

import MyComponent from '../components/MyComponent'

describe('<MyComponent />', () => {
  it('should call calledFunction()', () => {
    const wrapper = mount(<MyComponent />)
    const spy = jest.spyOn(wrapper.instance(), 'calledFunction')

    wrapper.forceUpdate()
    expect(spy)
      .toHaveBeenCalledTimes(1)
  })
})

in MyComponent.jsx:
import React from 'react'

class MyComponent extends React.Component {
  calledFunction = this.calledFunction.bind(this)
  calledFunction() {
    const str = "I was called"
    console.log(str)

    return str
  }

  render() {
    this.calledFunction()

    return <div />
  }
}

export default MyComponent

You have these lines in the wrong order:
 const wrapper = mount(<MyComponent />)
 const spy = jest.spyOn(wrapper.instance(), 'calledFunction')

instead, do this:
 const spy = jest.spyOn(wrapper.instance(), 'calledFunction');
 const wrapper = mount(<MyComponent />);

logically got this error:  ReferenceError: wrapper is not defined

oh lol, sorry. do this:
 const spy = jest.spyOn(MyComponent.prototype, 'calledFunction');
 const wrapper = mount(<MyComponent />);

thanks you saved my weekend man!

I found something that works.
Add these middle two lines.
wrapper .find(...Your thing) .simulate('click'); //Click event on wrapper
await wrapper.instance().forceUpdate(); //THIS ONE
wrapper.update();  //AND THIS ONE
expect(....).toHaveLength(1); //Your assertion here

authors: Jlevett ljharb mi-mazouz

repo: airbnb/enzyme

license: mit

license_source: bigquery


text:
Add documentation and unit tests for index parameter for map and forEach methods

Addresses https://github.com/airbnb/enzyme/issues/366
Also added unit tests to cover the index parameter.

LGTM

authors: ljharb marcin-mazurek


text:
React 17 peer support

NPM warning airbnb-prop-types@2.16.0 requires a peer of react@^0.14 || ^15.0.0 || ^16.0.0-alpha but none is installed. You must install peer dependencies yourself. with React 17.
Please release support for the peer dependency.

I put up #74; it's blocked by the lack of an enzyme adapter for react 17.

I put up #74; it's blocked by the lack of an enzyme adapter for react 17.

Check out https://github.com/wojtekmaj/enzyme-adapter-react-17
It might not be the official adapter, but it does work.

Is there no way we can get a version of this published that has v17 support? It doesn't seem enzyme adapter 17 is going to arrive anytime soon, and it is only a dev dependency for this package.

What about re-writing the tests to use an alternative testing library? How much does it actually use Enzyme? I can't see much usage of it. This means we could release this without waiting for Enzyme adaptor?

I’m not particularly interested in doing that; and either way, there doesn’t exist an alternative react testing library for testing in a non-browser context.

Hello, there is now an adapter for Enzyme, i will link it here.
Can we please have an update for this. it is really important as React 17 is growing on popularity.
https://www.npmjs.com/package/@wojtekmaj/enzyme-adapter-react-17
You can see that this package has 300.000 downloads weekly.

No, there isn’t. That’s an unofficial one.

There's enzyme-adapter-react-17 package, Can we re-open this issue again?

@Luksys5 no, because that's an unofficial package. if it worked reliably, i'd have published the official one.

def can benefit from this! thanks op

is there any version of airbnb-prop-types which depends on react 17 version

Not yet, otherwise this issue would be closed.

ok

repo: airbnb/prop-types


text:
Add missing onKeyDown function to CalendarDay

Eep.
Fixes https://github.com/airbnb/react-dates/issues/899
@ljharb

Coverage decreased (-0.2%) to 85.487% when pulling 4d3b312a5367c7711a78d9e9e4c43824fef08bbf on maja-fix-on-key-down-error into 94e18523fa8559fbf68d667b6f42697d8db3cdf4 on master.

authors: coveralls majapw

repo: airbnb/react-dates


text:
[improvement] Add ability to over-write existing outputs

Background
Mentioned on Slack: https://streamalert.slack.com/archives/C3BHE2Z0S/p1558386389107200
Are you on the latest version of StreamAlert? Yes
Description
If you configure a Slack webhook, and want to change it, then trying to rerun ./manage.py output slack with the same name will result in an error.  Currently, you have to manually edit conf/outputs.json to remove the output and then retry that command.  It would be nice to have a way to over-write or delete the existing output.
Steps to Reproduce
Run ./manage.py output slack and configure an output.
Rerun the same command with the same output name and a new webhook URL and you'll get an error.
Desired Change
Provide a --override to delete the current output and add the new one.

👍

Hi @0xdabbad00 @Ryxias , I'm interested in working on this feature. Can I please work on it and submit a PR?

@0xdabbad00 Will add a PR for this feature for release-3-1-0

@jack1902 I'm not sure if you meant to say that you will be adding this feature, but just to clarify, I unfortunately do not have the time to add it.

@0xdabbad00 yeah sorry for the confusion. Coffee hadn't kicked in

@0xdabbad00 I believe this issue can be closed at the output command has now got some new features :)

Thanks @jack1902 !

repo: airbnb/streamalert


text:
Fix config.py to respect firehose being disabled

to: @ryandeivert
cc: @airbnb/streamalert-maintainers
related to: #1158
resolves: #1158
Background
Having just pulled down release-3-0-0 for a fresh deployment, the firehose s3 notification was being passed through even though enabled was set to False
Changes

config.py now respects enabled on the firehose config

Testing

Was able to deploy the infrastructure :)
ran ./tests/scripts/unit_tests.sh
ran ./tests/scripts/pylint.sh

Coverage increased (+0.02%) to 95.926% when pulling 168178a6984962f2dacdaba2b4c82ffae50b4b83 on jack1902:bug/firehose_config into 9718c28d2da86d09b5be487f875e339c37a8a1ea on airbnb:release-3-0-0.

Closing this PR as work has been carried out by @ryandeivert based on this PR


text:
Add an Express installation doc

Adds an installation doc for Express.

Thanks @thompiler!

repo: airbrake/airbrake-docs


text:
feat(erc20): adding support for erc20

So, I tried to add support for ERC20-Tokens in this PR.
I have not tested it using a real TX so far, but adding this PR in order to get input whether this is the correct way to do it.

It feels a bit hacky to add it this way, it works for this case, but considering BTC-Support is a longer term goal, we probably need to refactor a bunch of stuff
Maybe we should think about using a slim JS framework to keep the UI in sync? It works for now, but document.createElement isn't exactly pretty.

See #13

@dschoeni can you add directly all common testnets? See topright on MEW

authors: dcale dschoeni

repo: airgap-it/airgap-web-signer


text:
Fix test coverage

Fix test coverage

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 100.00%. Comparing base (41f857f) to head (68f9d99).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff              @@
##             main        #4       +/-   ##
============================================
+ Coverage   76.71%   100.00%   +23.28%
============================================
  Files           5         4        -1
  Lines          73        70        -3
  Branches        6         6
============================================
+ Hits           56        70       +14
+ Misses         14         0       -14
+ Partials        3         0        -3

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

authors: codecov-commenter joostlek

repo: airgradienthq/python-airgradient


text:
Automate publishing releases on GitHub

This will automatically publish a release including the latest changelog on GitHub when the release lane is run.
The latest release (2.3.1) was created using this lane.
Running the whole release lane on CI whenever a prepare pr is merged would be the next step in automating the release process.

@nathan-mohemian Updated .gitignore and Fastfile. 👌

repo: airsidemobile/JOSESwift


text:
自定义主题的变量无法作用于Datetime组件

在自定义主题theme.less里定义
@datetime-header-item-confirm-font-color: #000;

vux-loader配置正确，其他组件已经生效，但是datetime组件的样式依然没有改变。

并不能重现。

authors: airyland joeslee

repo: airyland/vux


text:
[Bug Report] search组件的setFocus问题

VUX version
2.9.2
OS/Browsers version
主流浏览器
Vue version
2.5.17-beta.0
Code
setFocus () {
    this.$refs.search.setFocus()
}

Steps to reproduce
例子：
1、在首页点击搜索按钮跳转到search页面
2、setFocus是一个方法，当进入search页面的时候，我在created调用了setFocus方法
3、浏览器报错：'setFocus' of undefined"
What is Expected?
在另一个页面点击进来的时候，有没有办法自动获取焦点呢？方便用户在点击进来search页面，自动焦点到search就可以输入进行搜索。官方文档写着貌似是需要通过点击才能获取焦点。
What is actually happening?
浏览器报错：'setFocus' of undefined"

貌似我把setFocus方法加在mounted就没有报错了。

貌似我把的setFocus方法加在mounted就没有报错了。


text:
⚠ Turnos 24x7 has degraded performance

In eabf659, Turnos 24x7 (https://reservas-dev.alternativasinteligentes.com/) experienced degraded performance:

HTTP code: 200
Response time: 994 ms

Resolved: Turnos 24x7 performance has improved in 38f7f4f.

repo: aisa-status/status-upptime-dev


text:
⚠ Turnos 24x7 has degraded performance

In 64f7509, Turnos 24x7 (https://reservas-dev.alternativasinteligentes.com/) experienced degraded performance:

HTTP code: 200
Response time: 953 ms

Resolved: Turnos 24x7 performance has improved in b9c3958.


text:
⚠ Turnos 24x7 has degraded performance

In ab35828, Turnos 24x7 (https://reservas-dev.alternativasinteligentes.com/) experienced degraded performance:

HTTP code: 200
Response time: 922 ms

Resolved: Turnos 24x7 performance has improved in 2dc4d7b.


text:
Unable to build docker container

when running docker compose up -d, the following error is returned
failed to solve: process "/bin/sh -c apt-get update && apt-get install -y --no-install-recommends     gcc     libpq-dev     && apt-get install -y libc-bin=2.36-9+deb12u6     && apt-get clean     && rm -rf /var/lib/apt/lists/*" did not complete successfully: exit code: 100

Resolved this with the following change to the Dockerfile

# Update system and install required packages
RUN apt-get update && apt-get install -y --no-install-recommends \
    gcc \
    libpq-dev \
    libc-bin \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*
...
# Upgrade all packages in the final stage to ensure the latest versions are applied
RUN apt-get update && apt-get upgrade -y \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*


text:
Broken unit test: “Should have guessed profile 'mum to one boy and one girl' was 'female', not 'male'”

Split off from https://github.com/ajdavis/twitter-gender-distribution/issues/16#issuecomment-378813452.
$ python2.7 -m unittest discover -v
test_declared_gender (tests.test_declared_gender.TestDeclaredGender) ... FAIL

======================================================================
FAIL: test_declared_gender (tests.test_declared_gender.TestDeclaredGender)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/twitter-gender-distribution/tests/test_declared_gender.py", line 50, in test_declared_gender
    description, expected_gender, guess))
AssertionError: Should have guessed profile 'mum to one boy and one girl' was 'female', not 'male'

----------------------------------------------------------------------
Ran 1 test in 0.080s

FAILED (failures=1)

git bisect says that f2725606923164be1436789febbde6bf99cd1d54 is the first bad commit.

Let’s say, if there is more than one gender clue in the profile text, then
guess using first name as if there were no gender clues.
On Thu, Jun 28, 2018 at 1:28 PM Jackie Scholl notifications@github.com
wrote:

Yup, looks like I did that! You can definitely fix it by reverting part or
all of f272560
https://github.com/ajdavis/twitter-gender-distribution/commit/f2725606923164be1436789febbde6bf99cd1d54,
though if you do that you will break, e.g., "guy who loves his mum." I'm
not sure which formulation is more common, so I don't know if it makes more
sense to change the test or change (back) the priority order
Regardless, I have no personal stake and I'm happy with whatever ends up
happening :)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ajdavis/twitter-gender-distribution/issues/20#issuecomment-401112417,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFIhcIGitr4ObydlvR7yteYnpQzGWF_ks5uBRIhgaJpZM4U602L
.

authors: ajdavis lucaswerkmeister

repo: ajdavis/twitter-gender-distribution


text:
AttributeError: module 'collections' has no attribute 'MutableMapping' when using python 3.10

Traceback (most recent call last):
  File "/usr/lib/python3.10/runpy.py", line 187, in _run_module_as_main
    mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
  File "/usr/lib/python3.10/runpy.py", line 146, in _get_module_details
    return _get_module_details(pkg_main_name, error)
  File "/usr/lib/python3.10/runpy.py", line 110, in _get_module_details
    __import__(pkg_name)
  File "/usr/lib/python3.10/site-packages/livereload/__init__.py", line 15, in <module>
    from .server import Server, shell
  File "/usr/lib/python3.10/site-packages/livereload/server.py", line 20, in <module>
    from tornado.wsgi import WSGIContainer
  File "/home/ente/.local/lib/python3.10/site-packages/tornado/wsgi.py", line 40, in <module>
    from tornado import httputil
  File "/home/ente/.local/lib/python3.10/site-packages/tornado/httputil.py", line 107, in <module>
    class HTTPHeaders(collections.MutableMapping):
AttributeError: module 'collections' has no attribute 'MutableMapping'

Hello. I'm not actively maintaining this repo. But just by looking at the stack trace, I can see upgrading tornado would make this work.
I would happily take a pull request if you send one.

repo: ajitid/live-server


text:
[QUESTION] customizable time and message?

just wondering if you can edit this to say a specific word/command at any given time.

Do you mean time on a 24 hour clock or an interval? Right now the README explains how to modify interval time and the message, but time of day messages have not yet been implemented. I'm sure it wouldn't be too hard to do yourself if that's what you mean, but if you need help I can take a look.

Closing due to inactivity, but if you still have questions or need help with anything I'll be happy to reopen this


text:
Add gausslaguerre

Add a fast gausslaguerre.jl command based on the GLR algorithm, not asymptotics.

Closes #33.


text:
Phase out serapeum dependency

This library currently prevents loading cl-duckdb with Clasp as it doesn't compile:
https://github.com/clasp-developers/clasp/issues/1365
Only serapeum:mvlet* and serapeum:count-cpus are currently used, which doesn't warrant the inclusion of such a large library dependency.

DuckDB seems to be using std::thread::hardware_concurrency to determine the number of threads, maybe this could be exposed via the C API.

@snunez1: I've replaced the single call we have to mvlet* with let+

As a replacement for serapeum:count-cpus, perhaps cl-cpus?

This project was originally using cl-cpus before, but that was even less reliable compared to the serapeum implementation (by less reliable I mean it gave different results compared to the DuckDB defaults in more cases).
I've opened a PR where I simply open a temporary connection to DuckDB to determine their internal defaults when cl-duckdb is first loaded. This should be more future proof in case they decide to change the logic behind the defaults.

repo: ak-coram/cl-duckdb


text:
Problem with set.php

Required Information

PHP version: 5.5.9
PHP Telegram Bot version: latest I think
Using MySQL database: no
Update Method: Webhook
Self-signed certificate: yes

Actual behaviour

What IS happening?
when I open set.php on my browser he return http error 500, but the webhook is correctly set.

I've tried to add
$result = Longman\TelegramBot\Request::sendMessage(['chat_id' => 'myid', 'text' => 'sample message']); 	//echo json_encode($result);
after
$telegram = new Longman\TelegramBot\Telegram($API_KEY, $BOT_NAME);
and the message is correcly sent.
the apache error.log say:
PHP Fatal error: Call to a member function isOk() on a non-object in /var/www/html/set.php on line 21

Then, if I broswe directly to hook.php he return
exception 'Longman\TelegramBot\Exception\TelegramException' with message 'Input is empty!' in /var/www/html/phptelebot/vendor/longman/telegram-bot/src/Telegram.php:252 Stack trace: #0 /var/www/html/hook.php(52): Longman\TelegramBot\Telegram->handle() #1 {main}
What can I try to make it work? Thank you

The code is fine.
I don't understand why you get 500. Could be that the telegram server are in down did you check it?
Then input is empty is correct because with your browser you are not sending a json payload

Is it possible that my server miss something? Is an ubuntu 14 set by me on cloudatcost, what can I check?

I see you are using a custom certificate.
Are the permissions for the certificate file correct? It must be readable by the Apache user, probably www-data.

I know becouse if I browse to https://api.telegram.org/botMYAPI/getUpdates I get {"ok":false,"error_code":409,"description":"Conflict: can't use getUpdates method while webhook is active"}
about the custom certificate, I tried to set www-data as group, but nothing changes, che error is still on line 21

well, figured out the errors:
first, I had an old version of longman telegram-bot (don't know why, did a composer update couple times).
Then, I was trying to use as webhook www.domain.com/hook.php, but my certificate was for domain.com ... yes i feel so stupid. Thank you all

Great that you figured it out and that it's working now 🎉

authors: KilluaFein MBoretto noplanman

repo: akalongman/php-telegram-bot


text:
Very minor fix: changes some methods to camelCase for style consistency

Some methods in stringutilities.py were underscored, while some were camelCased, and so I made all methods camelCase for code style consistency.

@jfsawin after changes did you test all of methods?

I tripled-checked all the replacements I did to make sure they didn't change the program logic, but yes, I've also just manually confirmed that all the modified methods still work as before.

authors: akalongman jfsawin

repo: akalongman/sublimetext-stringutilities


text:
Migrate Tensorflow v1 code to v2

Hey, the existing codebase is written in tensorflow v1 which isn't very compatible these days, can I send in a patch to migrate it to v2?

@ashok-arora that would be really helpful

authors: akaraspt ashok-arora

repo: akaraspt/tinysleepnet


text:
Set app.toml

Is there a way to set app.toml. I need to change some preconfigured values but cannot find a way to do it.

See the Configuration section here, specifically the introduction. You can use environment variables to change any of the configuration in the files.
e.g. to change the persistent-peers config in the p2p section, for the CosmosHub blockchain, it would be:
GAIAD_P2P_PERSISTENT_PEERS=id@ip

All of those envs are for common all cosmos chains. What I need is a way to modify app.toml which may have different keys/values in different chains. For example modify osmosis's max-gas-wanted-per-tx.
The way run.sh works it initialise the chain which creates default app.toml but there is no way to modify it after.
https://github.com/akash-network/cosmos-omnibus/blob/786abe4107291f0858c4fc613828b81dcdda29f0/run.sh#L204-L217
Something like how peers are updated may work:
https://github.com/akash-network/cosmos-omnibus/blob/786abe4107291f0858c4fc613828b81dcdda29f0/run.sh#L213-L216
I understand this is not trivial and may I be wrong tho in how run.sh works but for no, I could not find a way to modify the default app.toml in chains.

@mrcr0cket all Tendermint config, regardless of chain, can be configured like this. None of this is Omnibus specific, Tendermint/Cosmos SDK chains can be configured using environment variables as above. The precedence is command line arguments > env variables > config files.
An example Osmosis config I'm using is OSMOSISD_MIN_GAS_PRICE_FOR_HIGH_GAS_TX=.01
The main thing is determining the section it's in if applicable (i.e. p2p for seeds/persistent-peers, mempool, consensus etc), and the prefix which is always the binary name capitalised.

repo: akash-network/cosmos-omnibus


text:
feature request: support client-managed healthchecks (livenessProbe, readinessProbe) and imagePullPolicy

This would solve one of the important use-cases - a self-updating image through livenessProbe.
With the livenessProbe pointed to query the releases link comparing against the current version would allow it to fail once there is a new image available, causing the pod restart allowing it to self-update. This requires imagePullPolicy: Always set for this specific deployment.
Add client-managed healthchecks (livenessProbe, readinessProbe and their parameters) and setting imagePullPolicy to Always.
Refs
https://discord.com/channels/747885925232672829/1090670585555730563/1091261402729156608
https://github.com/akash-network/provider/pull/54
https://github.com/akash-network/support/issues/50
https://github.com/arno01/self-update

PoC

Dockerfile

FROM nginx
RUN echo ver1 > /usr/share/nginx/html/index.html

pod.yaml

---
apiVersion: v1
kind: Pod
metadata:
  name: pod1
spec:
  containers:
  - name: container1
    #image: nginx
    image: andrey01/testimage
    imagePullPolicy: Always
    livenessProbe:
      httpGet:
        path: /health2
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 10
      timeoutSeconds: 15

@anilmurty would this be a good experiment for us to create a bounty for the community.  Currently, this is needed for Pre-Search.
Andy has more info on it, and link attached to the convo in our discord channel with them.

potentially but first we need to clean up the local dev env set up (readme on the github repo) for node and provider repos, so that others can get set up (we did this for console before engaging OSS dev community)

authors: andy108369 anilmurty bmenzalji

repo: akash-network/support


text:
feat: クロスフェード機構を追加

このpull requestが解決する内容

g.AudioUtil を追加

音声のフェードイン・フェードアウト・クロスフェードの機能を提供します

g.Game#onUpdate を追加

ティックの進行後 (g.Scene#onUpdate が発火した後) に発火するトリガ

g.Util#clamp() を追加
EasingFunction EasingFinishFunctions を追加

動作確認
以下のミニマムコンテンツにて動作確認済み

展開
赤い四角をクリックするとフェードイン・クロスフェード・フェードアウトするサンプル
module.exports = () => {
  const game = g.game;
  const scene = new g.Scene({
    game,
    assetPaths: [
      "/assets/**/*"
    ],
  });
  scene.onLoad.addOnce(() => {
    const rect = new g.FilledRect({
      scene,
      cssColor: "red",
      width: 32,
      height: 32,
      touchable: true,
    });
    rect.onPointDown.addOnce(() => {
      const akiurara = game.audio.create(scene.asset.getAudio("/assets/audio/akiurara"));
      const yume = game.audio.create(scene.asset.getAudio("/assets/audio/yume"));
      scene.setTimeout(() => {
        console.log("fadeIn");
        g.AudioUtil.fadeIn(game, akiurara, 5000, 0.1);
      }, 0);
      scene.setTimeout(() => {
        console.log("crossFade");
        g.AudioUtil.crossFade(game, yume, akiurara, 5000, 0.1);
      }, 6000);
      scene.setTimeout(() => {
        console.log("fadeOut");
        g.AudioUtil.fadeOut(game, yume, 5000);
      }, 12000);
      rect.remove();
    });
    scene.append(rect);
  });
  game.pushScene(scene);
};

破壊的な変更を含んでいるか?

なし

議論メモ:

fade() → transtionVolume()

"fade" という語は "transisionVolume + 便利処理" に使う: 特に fadeIn() は play() を伴うことにする

from はさすがに不要か

必要なら自力で事前に volume を変えておけばよい
徹底すると cross fade の from が二種類必要になってしまいそうなのもちょっと

戻り値の型は AudioUtil には入れない

authors: xnv yu-ogi

repo: akashic-games/akashic-engine


text:
Update links to new website: http://www.vtki.org/

Check out the new domain http://www.vtki.org/ where the documentation is hosted.
Note: I have also added email forwarding on that domain which we will need to set up for user support per the JOSS submission guidelines.
Currently, support@vtki.org forwards to my email. Perhaps we create an actual email account under the vtki.org domain that active maintainers can access?

Thanks for doing that!  I accepted the google domains request.
It's up to you if we'll create a maintainers email account under the new domain.

I'll just keep the email forwarding for now because it's free. Maybe down the road when vtki grows we can set up a maintainer's email account.

authors: akaszynski banesullivan

repo: akaszynski/vtki


text:
Fixes: safePreventDefault Prevents Scrolling With Preact

Fixes #2068

Oh, is this PR still opening? I face this issue as well :)

repo: akiran/react-slick


text:
Support for SteamChina clients

What problem is this solving
When I start cs demo manager with SteamChina (exclusive version client produced for review in Chinese Mainland for games such as Counter Strike), it is considered that Steam has not been started. It seems that the SteamChina client is no different from the original Steam client, but the name is changed to SteamChina and it will connect to the perfectworld server in Chinese Mainland by default. Hope to add support for SteamChina.
Proposed solution
I hope that CS Demo Manager can also be used properly when using the SteamChina client.
Describe alternatives you've considered
Using the original Steam client may cause some connectivity issues, resulting in the inability to open demos properly.

The next version should support it.
I'm using should because I couldn't fully test it.
I installed the client in a VM and stopped going further after seeing this window asking for personal information.

The only difference seems to be the executable name - let me know if it works when the next version is released.

Thank you very much for your reply. I will test it after the next version is released.

I have tested it and it runs very well! :)

authors: EventHorizonV akiver

repo: akiver/cs-demo-manager


text:
Bump Akka.TestKit dependency to 1.5.30 + Akka.TestKit.NUnit package to 1.5.30

Changes
This pull request bumps Akka.TestKit dependency to version 1.5.30 and removes the preview version I introduced in #136 (where Akka.TestKit.NUnit was published as 1.6.0-preview.1). Instead, both Akka.TestKit.NUnit and Akka.TestKit.NUnit3 NuGet packages use the same version as Akka.TestKit, 1.5.30.
Checklist

[x] I have reviewed my own pull request.

@Aaronontheweb this is a follow-up to my comments from the previous PR (you were probably not notified because I posted them after the PR was merged and closed).

https://github.com/akkadotnet/Akka.TestKit.NUnit/pull/136#issuecomment-2338658718
https://github.com/akkadotnet/Akka.TestKit.NUnit/pull/136#issuecomment-2353338911

Important - because Akka.TestKit.NUnit now depends on NUnit 4, it can no longer be used in projects that still have to use NUnit 3. I recommend that you also publish Akka.TestKit.NUnit3 as built by this pull request (i.e. version 1.5.30). This will allow projects that use NUnit 3 to target the latest Akka.NET.
Akka.TestKit.NUnit3 currently available from Microsoft NuGet registry is at version 1.3.8, which is quite dated. The deprecation message "... please use Akka.TestKit.NUnit (which also supports NUnit3)" made sense up to version 1.5.24, but doesn't make sense now that Akka.testKit.NUnit no longer supports NUnit 3.

@Aaronontheweb any feedback for the PR?

Sorry @milang - this looks good to me

authors: Aaronontheweb milang


text:
Newsbeuter unresponsive while running bookmark command

I have a question regarding the use of newsbeuter bookmark command option.
I am using a bash script as the bookmark command. It takes the url, parses it and downloads the targets of certain links in the page using wget. The issue I am facing is that newsbeuter becomes unresponsive until the script finishes execution. Is there anyway for newsbeuter to run the bookmark script in the background while I am able to use it to, say, read other feeds?

You can make the bash script fork and run in the background.
#!/bin/bash
do_bookmarking() {
wget "$1"
do other stuff here
}
exec >/dev/null 2>&1
do_bookmarking "$@" &

authors: IsaacG PolevaulterDonkeyman

repo: akrennmair/newsbeuter


text:
URLs tree

Would be nice to have a way to group URLs into "folders", like a tree. Very useful when there are hundreds of feeds.

#487
Randomly decided to check this project and you've brought up both my ideal features for newsbeuter. Are you an QuiteRSS/RSSowl user looking for a new client?

Are you an QuiteRSS/RSSowl user looking for a new client?

Nope, just a command line lover who likes clean interfaces :)

Just as @kyyu points out, this is a duplicate of #487.

authors: Minoru gtr6ytuuygf kyyu


text:
UCF101 and HMDB51 data splits

Hi Akshita,
Thanks for sharing your codes.
Would you mind sharing more .mat files? For example, ucf101 and hmdb51 dataset splits that include 'traing_loc' and 'test_seen_loc' and so on.
Thanks in advance.

In zero-shot-actions/util.py
matcontent = sio.loadmat(opt.dataroot + "/" + opt.dataset + "/" + opt.class_embedding + "_splits.mat")
trainval_loc = matcontent['trainval_loc'].squeeze() - 1
train_loc = matcontent['train_loc'].squeeze() - 1
val_unseen_loc = matcontent['val_loc'].squeeze() - 1
test_seen_loc = matcontent['test_seen_loc'].squeeze() - 1
test_unseen_loc = matcontent['test_unseen_loc'].squeeze() - 1

I have found them from gzsl-od repo.


text:
Image in the karma blog is very big

Description
Describe the bug:
in the power of knowledge blogs, the image of karma blog is very big, and needs some margin/padding also
Screenshots

Hey,I'd like to work on this issue.

assign  this issue to me i want to work on this issue


text:
Broken of links  in smaller width

Describe the bug
When we are changing width to smaller all the links are breaking in two parts which is not a good UI . So we can use   so that the links will not breaks in two
To Reproduce
Steps to reproduce the behavior:

Go to 'https://akshitagupta15june.github.io/PetMe/'
Change the size by using devoloper tools in browser
See error

Expected behavior
Link should not break they should in 1 line
Screenshots

You can see the error
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

Hi maintainers pls assign me this issue thank you


text:
Add favicon

Website could use an awesome favicon , currently it doesn't have one.

I would like to work on this. Can you assign me?
@narayan954

nope I can't @SushanthReddy-49

Ok @narayan954

hi, I want to work on this issue ,can you please assign it to me

Hi can I work on it ?

I would like to work on this issue,can you please assign me

This issue is completed


text:
Added Chatbot Functionality for the website

Fixes: #257
What Does this PR do?
This PR creates a Chatbot and also adds  functionalities to redirect to contact, report & donate.

And This is senond Screenshot when you click the chatbot

please don't create pr without issue being assigned

@akshitagupta15june Sister, It was my first PR & I did take help from chatgpt but i worked 4hrs continuously, you even did not review my work & closed it


text:
Testing in appium

Version
Tell us which versions you are using:

react-native-router-flux v3.35.0
react-native v0.33.0
When I load the app in Appium inspector, I can't see an id or name I can use for automation of the tabs. Is there an attribute I can set on the corresponding Scene tag?

Nevermind, i got it working with accessiblityLabel

As far as I can tell there is no accessibility label on the left and right buttons in the navigation bar. How did you manage to click on those?

repo: aksonov/react-native-router-flux


text:
add kargo logo to readme page

Now that we're officially counting this as a Kargo sub-project, the AI-generated octopus can go and we can slap the Kargo logo on the README -- at least until we get a Kargo Render logo. (If we do.)
Correct logo can be found here: https://github.com/akuity/kargo/blob/main/kargo-logo.png
Layout should be similar to Kargo's README

@krancour I want to work on this issue, can you assign me?

@anevski-stefan all yours!

@krancour There was one PR with these changes, in the first issue there was a need to update the logo and to include the logo, so this is a duplicate one.

authors: anevski-stefan krancour

repo: akuity/kargo-render


text:
Faction Manager seems to believe I have about twice as much money as I do, and its making Ascend fail.

As the comment posted, I went ahead and updated scritps to see if that would fix the problem, but it didn't make any difference

bitburnerSave_1654089680_BN9x2.zip
.

Why did you close it? Did you figure out what happened?

authors: Thedakdragon alainbryden

repo: alainbryden/bitburner-scripts


text:
Add method partition(::AbstractMatrix, ...)

Also, relax signature of partition(::AbstractVector, ...) to allow any
vectors, not just vectors of integers.
Fix #361.

@giordano Thanks for this.
It remains to relax the signature altogether to include the tables case. As tables are defined by a trait, we need trait dispatch here. Have a look at the implementation of MLJModelInterface.matrix for a similar case: https://github.com/alan-turing-institute/MLJModelInterface.jl/blob/275beda8e90e7946cd408ab84ca59c8efc34b407/src/data_utils.jl#L26 You can use Tables.istable instead of vtrait (MLJModelInterface does not have Tables as a dep).

Ok, thanks, I relaxed the signature, so now the argument is X::Any and we check at runtime whether X is a matrix/table.
I don't think having a separate method would speed up anything: partition itself for a matrix isn't superfast (for a small matrix it takes time of the order of units of microseconds), which dwarfs the time to look up a specific method, and the X isa AbstractMatrix check should hopefully make it as good as having a dedicated method.

authors: ablaom giordano


text:
test_mesh_cython and test_mesh_cl failing

Two tests are failing. I initially thought that this might be related to a recent edit to the .gitignore file (ignore .vtk file types) but this does not appear to be the case. I returned to the original code and the tests still fail. I have attached details below. @bb515 do you have any idea what might be causing these tests to fail? It isn't clear to me what these tests do.
FAILED peripy/test/test_regression.py::TestRegression::test_mesh_cython - AssertionError: assert [b'BINARY', b...x00\x00', ...] == [b'BINARY', b...x00\x00', ...]
FAILED peripy/test/test_regression.py::TestRegression::test_mesh_cl - AssertionError: assert [b'BINARY', b...x00\x00', ...] == [b'BINARY', b...x00\x00', ...]

E       AssertionError: assert [b'BINARY', b...x00\x00', ...] == [b'BINARY', b...x00\x00', ...]
E         At index 16 diff: b'CELLS 4225 12544' != b'CELLS 4224 16768'
E         Left contains 105 more items, first extra item: b'6\xe2\xeb\x1cC-\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00?'
E         Use -v to get the full diff

You can view the tests in peripy/test/
These tests are listed below. They make sure that the mesh is identical to the one that was given with the package.
The meshes are stored in "peripy/test/data" and you probably haven't changed anything in there, but if you put git ignore vtk then these meshes will not get pushed to the repo, so you can't use gitignore vtk. Instead, you could git ignore the individual files that you create when making a new example.
I would recommend when making a new example, creating a new directory "example3" and just gitignoring that directory.
`    def test_mesh_cython(self, regression_cython, data_path, tmp_path):
"""Ensure mesh file is identical."""
model, displacements, damage, *_ = regression_cython
path = data_path
    mesh = tmp_path / "mesh.vtk"
    expected_mesh = path / "expected_mesh.vtk"
    model.write_mesh(mesh, damage, displacements)

    assert(
        mesh.read_bytes().split(b"\n")[2:] ==
        expected_mesh.read_bytes().split(b"\n")[2:]
        )`

`    def test_mesh_cl(self, regression_cl, data_path, tmp_path):
"""Ensure mesh file is identical."""
model, displacements, damage, *_ = regression_cl
path = data_path
    mesh = tmp_path / "mesh.vtk"
    expected_mesh = path / "expected_mesh_cl.vtk"
    model.write_mesh(mesh, damage, displacements)

    assert(
        mesh.read_bytes().split(b"\n")[2:] ==
        expected_mesh.read_bytes().split(b"\n")[2:]
        )`

Fixed it. Reverted to Jim's original testing code @pytest.mark.skip(reason="Stalling" which skips the test on travis if it stalls like this.

repo: alan-turing-institute/PeriPy


text:
Update README.md

Adding a "documentation" badge

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 91.14%. Comparing base (8c482e6) to head (fdf4003).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #215   +/-   ##
=======================================
  Coverage   91.14%   91.14%
=======================================
  Files          45       45
  Lines        2393     2393
=======================================
  Hits         2181     2181
  Misses        212      212

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

authors: codecov-commenter kallewesterling

repo: alan-turing-institute/autoemulate


text:
[DOC] Add multivariate forecasting examples to forecasting tutorial

Update by @fkiraly: examples for multivariate forecasting should be added to the forecasting notebook.

There are any multivariate forecasting example?

No, currently not - good point! This should be added.
I think it's a good first issue?

@kejsitake has expressed interest - assigned to track interest, revisit later.

now included by https://github.com/alan-turing-institute/sktime/pull/2041

authors: eldritchhh fkiraly

repo: alan-turing-institute/sktime


text:
Forecasting support for multivariate y and multiple input/output types - working prototype

This is a merge/review ready sketch for how multivariate y could be supported for multivariate forecasters, alongside the possibility to pass np.array and pd.Series. This is based on the design in STEP no.5, adapted to the new forecasting base class.
The key ingredient are:

converters parameterized by from, to, and as - in the convertIOmodule. Besides the obvious conversion functionality, the converters can be given access to a dictionary via reference in the store argument, where information for inverting lossy conversions (like from pd.DataFrame to np.array) can be stored
a new tag y_type which encodes the type of y that the private _fit, _predict, and _update assume internally - for now, it's just one type and not a list of compatible types
some logic in the public "plumbing" area of fit, predict, update, which converts inputs to the public layer to the desired input of the logic layer and back

This is for discussion, and I expect major change before we merge.
It might be especially interesting to discuss the following interaction with typing:
the third argument of the converter, the "as" argument, is a scitype, and designed to have the same name as the respective typing composite type. Also see discussion in #965, #973 and #974.
Thinking of the logical continuation of this:

extend this to the other arguments, e.g., X
the individual argument checks like check_X etc should be replaced by checks of the kind check(what, as : scitype), e.g., check(y, "Series") should replace the less generic check_y.
extend this to time series classification, to support 3D numpy arrays, awkward arrays, nested data frames

A "visionary" pathway may see this working with type annotations that are scitypes, not typing machine types, e.g.,
fit(X : Series, Y : Series)
etc
_fit(X: Series, Y : UnivariateSeries)

and checks/conversions being done automatically.

pinging @chrisholder since otherwise I can't add him reviewer

note: this fails with some of the forecasters that are not yet refactored, since it can happen that fit is overridden but predict is not, in which case the variables written in fit are not addressed.
I see two ways to address this:

wait until the re-factoring #955 is done
add some safety checks that turn off the new code in predict if it wasn't called in fit

I've found a better option no.3 - initialize the fit variables with "safe" defaults that are what they would be for all of the forecasters that haven't been refactored. We can change that later, though it might be in general a good idea to have these "safe" defaults.

ready for review

Hi @fkiraly, I had a quick look now, this seems to be a major API change, will need some more time to look into it.

sure - since it's a dev days priority, shall we try to get any questions and change requests out of the way soon-ish? Meeting later today?

what about renaming y to Y? Is it postponed or decided if we want to do it in general? See also discussion here #967

Martin Walter martin_friedrich.walter@daimler.com, Mercedes-Benz AG on behalf of Daimler TSS GmbH.
https://github.com/Daimler/daimler-foss/blob/master/LEGAL_IMPRINT.md

what about renaming y to Y? Is it postponed or decided if we want to do it in general? See also discussion here #967

I'd say variable renaming is a very invasive core interface change and will affect many files.
Therefore, it's best kept separate from this change, which is not breaking core interface contracts (as it works only on the inside).
Due to the breakage of the core interface, I think it's also worth considering not changing y to Y at all, ever.

I think it could work fine, if we depreciate it properly so that users are aware of it.

hm, what's going wrong with manylinux?

@aiwalter, re. y/Y - let's do this in a different PR.
Following the principle that a PR should either be localized in interface or localized in scope/logic. I.e., it can be broad in terms of logic while affecting interfaces minimally, or being broad in terms of the files/places it affects while having a minimal logic scope, but not both, unless it really can't be avoided.

yes sure, this would be a different PR. I was just curious :)

Is this a blocker for anyone at the moment? If I remember correctly, in our sprint planning, the goal for this was to come closer to an API design. I certainly need more time to think about this. It seems like a big change from the more familiar scikit-learn interface and I'm not sure about the consequences. Perhaps we can have a discussion session on this?

It seems like a big change from the more familiar scikit-learn interface and I'm not sure about the consequences. Perhaps we can have a discussion session on this?

How is that? Not sure whether I understand why you think this.
As you see the tests are all running, and - in addition - all outputs are the same when compared to pre-PR behaviour.
All this adds is the ability to input and receive data types that previously would have raised errors.

Is this a blocker for anyone at the moment?

I feel it's crucial to get to our self-set goal of multivariate forecasting by end of week.

I think the type conversion is necessary to have multivariate forecasting under a compatible interface.
Why: otherwise we have to decide per-estimator whether we want it to rely on pd.DataFrame or pd.Series. This either/or seems a bit unnecessary and contrived, since it would split the forecaster interface down the middle.

I think the easy way to introduce support for multivariate forecasting is to work with the existing check_y function and give it an argument for whether it handles univariate or multivariate series based on a boolean tag.

See above. This would introduce a lot of boilerplate code.
Also note that we are not talking about hypotheticals here, but a working prototype in the PR, which does not change existing interfaces, adds the capability to pass pd.DataFrame and np.array to forecasters (as attempted in #897 by more manual hacking of the check_xyz etc), and makes any future multivariate forecaster downwards compatible.

So, to summarize our discussion at the dev days:
There's no consensus on merging this - @mloning does not like this, based on arguments that are perhaps best explained by himself here. If I were to paraphrase it:

@mloning proposes an alternative solution that, instead of converting, just throws an error if one of the formats is not supported
this would mean we will have forecaster which support np.array, pd.Series, or pd.DataFrame, or combinations thereof. For example, if you pass a pd.Series to a forecaster that supports pd.DataFrame, it would not be converted, but an error would be thrown, and the user will have to know that they have to convert the pd.Series to a one-column-pd.DataFrame if their data is univariate

In addition, @mloning proposed that we work through all forecasters and make sure they support both pd.Series and pd.DataFrame both; hoping that we can use joint interface points where possible, and otherwise make any necessary conversions inside individual forecasters, and not automated in the base class.
I disagree with this way forward, since:

working through individual forecasters has nothing to do with base class behaviour - i.e., error throw or convert
it's better to convert to the user expected type rather than throw an error and expect the user to make the conversion easily
complex pipeline composites are much less likely to work out of the box
@mloning's suggestion would lead to an "interface split" between pd.Series and pd.DataFrame forecasters going forward with multivariate implementations, along lines that are not obvious to users

To get this involved, I would be invoking our governance document, which we wisely wrote in anticipation of a situation like this, to professionally get to a democratic resolution 😃
https://github.com/alan-turing-institute/sktime/blob/main/GOVERNANCE.rst
As per "decision making" section, @mloning (or another core contributor) should now either, asap:

veto this PR, based on STEP05, to formally express disagreement
not veto this PR, and agree that this is merged soon

If a veto happens, core devs have 5 days (excluding week-ends) to look at this with care and cast a public vote, here in the PR. Deadline would be those 5 days after the veto.

I wrote up my view of the discussion in the hackmd file for the forecasting group of dev days: https://hackmd.io/84rpzQEiQiWQy5oQjs7FYw?both. The summary can be found at the bottom of the hack md.
I highly recommend having a look at it, because it presents a different perspective on ML's views than what FK describes above. (And of course, ML is the best person to say what his perspective is)

@TonyBagnall. I think that is broadly correct!
But, from my understanding, the fundamental disagreement is more about time. Markus did not say he outright disliked option 2, but he wanted us to take more time to consider any downsides thoroughly, whereas Franz does not think there are any downsides that require significant time and is concerned that if we do not merge it quickly, it will just continuously get pushed back. Hence (again from my understanding) Franz invoked the governance document to ensure a timely decision is made.

@Lovkush-A, it's not a good idea to post a hackmd link here when the doc is still editable. A random person or malicious bot from the internet can access this, and, for instance, replace links with malicious links.
Can whoever owns this make the hackmd doc read-only? I'll put the content on the wiki in the meanwhile.

is this (broadly) correct?

In my view, yes, @TonyBagnall.
However, the discussion with @mloning convinced me that this may be sub-optimal, becaues it does not allow individual instances of estimators to accept multiple types, e.g., when it can handle series and pandas by only using joint intervace points (like the imputer).
What I would hence like to change this to, ultimately, is a tag that is a "pass" list. If the input is of a type on the list, fit passes the input to _fit unchanged. If the tag is not on the list, it converts it to the first element that's on the list.

@Lovkush-A, I think this of yours is a very interesting and relevant point:

Thought by LA later, this sounds like a reduction, of multivariate forecasting to univariate forecasting. This suggests a reduction style interface, where user creates multivariate forecaster using reduction function and a univariate forecaster object. Separate to this, can have reductions from multivariate forecasting to tabular regression

I think you indeed identify univariate forecasters correctly as a different scitype than multivariate forecaster.
The subtle point is here that I think it's a sub-scitype, and the inclusion is too "weak" to justify a separate base class.
What do I mean with sub-scitype: multivariate forecasters have the same sci-interface as univariate forecasters whenever presented with a univariate series. When presented with a multivariate series, only multivariate forecasters can do this.
Other examples of this "sub-scitype" relation are:

binary and multi-class classification
transformers that have an inverse transform vs those that don't
supervised regressors that can deal with multivariate target vs those that can't

Note that neither of these have distinct base classes in scikit-learn, since the interfaces are too close (I reckon) - a key design principle of scikit-learn is to avoid the anti-pattern of (base) class proliferation. That's what I mean with "weak" sub-scitype - the added complexity by covering both cases in one base class is small.
Another interesting point: even if you have the same base class, you still can do reduction, it just doesn't mutate the general interface, it only removes the "lack of capability".
Examples are:

the "one-vs-rest-classification" reduction strategy, which creates a multi-class capable classifier out of a binary one
the "apply per output variable" reduction strategy which makes a multi-target regressor out of any regressor

I think univariate forecasting vs multivariate forecasting is precisely such a case, most similar to the multi-output regression example.

What I would hence like to change option no.2 to, ultimately, is a tag that is a "pass" list. If the input is of a type on the list, fit passes the input to _fit unchanged. If the tag is not on the list, it converts it to the first element that's on the list.

so maintain a list of allowable inputs. You will still have to prioritise conversions, so if it can take two types and pass a third, which of the two it allows would be chosen?
have you mocked up the use cases in an example base and subclass forecasters? That may help convince others?

Standard use case 1: passed a type the subclass can handle unary and many to many
Standard use case 2: passed a type the subclass cannot handle, where subclass can handle only one type. Convert and pass
Edge case (?):  passed a type the subclass cannot handle, where subclass can handle more than one type. Convert and pass

@Lovkush-A, it's not a good idea to post a hackmd link here when the doc is still editable.

My bad... I have removed the link from my comment. The description should be enough information for people in this group to find the link. (But I suppose there is still the small risk the link has already been scraped...)

The subtle point here is that it's a sub-scitype, and the inclusion is too "weak" to justify a separate base class.

Makes sense to me. Note we do not need any separate base classes to still have a reduction style interface. We can still have something like MakeMultivariate(UnivariateForecaster(), reduction_strategy)

My bad... I have removed the link from my comment.

You would't have needed to, I've changed it to a static wiki page.

To answer your questions, @TonyBagnall

so maintain a list of allowable inputs. You will still have to prioritise conversions, so if it can take two types and pass a third, which of the two it allows would be chosen?

I'd say there is always a "preferred" type if it can take many, that's what conversion would be attempted to. Easy to implement by making the y_type field being a list; check containedness, if yes pass unconverted; if not, convert to first element.

have you mocked up the use cases in an example base and subclass forecasters? That may help convince others?

This PR implements the functionality already (one internal type only).
It does not change behaviour that currently does not throw an error - all tests pass - your case no.1. It's basically all of the current tests, and the example sheets.
It adds functionality where users can pass more inputs - to all forecasters. - your case no.2.
regarding no.3: there currently does not exist, to my knowledge, a forecaster that can handle more than one case. To my knowledge, @mloning's discussion of this case is purely hypothetical given the current code base.

Makes sense to me. Note we do not need any separate base classes to still have a reduction style interface. We can still have something like MakeMultivariate(UnivariateForecaster(), reduction_strategy)

@Lovkush-A, absolutely agreed! That's what #1038 should do.

so I have just discussed this with my research group, and not wanting to muddy the water, but one suggestion (from chris, supported by aaron) was it could be better to achieve this effect with decorators, along the lines of below (wont let my upload a note book). He can comment more himself if this is of any interest.
import numpy as np
import pandas as pd
def support_df(estimator_class):
estimator_fit = estimator_class.fit

def fit(self, X):
    if isinstance(X, pd.DataFrame):
        print("Converting df to numpy")
        X = X.to_numpy()
    return estimator_fit(self, X)

estimator_class.fit = fit
return estimator_class

def support_list(estimator_class):
estimator_fit = estimator_class.fit

def fit(self, X):
    if isinstance(X, list):
        print("Converting list to numpy")
        X = np.array(X)
    return estimator_fit(self, X)

estimator_class.fit = fit
return estimator_class

@support_list
@support_df
class Example:
def __init__(self, name: str):
    self.name = name

def fit(self, X):
    return isinstance(X, np.ndarray)

numpy_example = np.array([1,2,3,4,5])
df_example = pd.DataFrame({"A": [1, 2], "B": [3, 4]})
list_example = [1,2,3,4,5]
numpy_example_cls = Example("numpy")
print(numpy_example_cls.fit(numpy_example))
print(numpy_example_cls.fit(df_example))
print(numpy_example_cls.fit(df_example))

was it could be better to achieve this effect with decorators, along the lines of below (wont let my upload a note book). He can comment more himself if this is of any interest.

Yes, we've also discussed decorators extensively, see the original STEP05 as well.
The problem with that lies with the extender user archetype (not the notebook/deployment user archetype):

the extender user would have to remember to add/modify decorators. That's similarly error prone as remembering to having to add the checks. It's better to keep "info about the method" localized to tags/capabilities, just one table to fill in, just one failure point, not multiple.
the functionality is not out-of-the-box, i.e., you need to add the decorators
for an extender user, decorators are much harder to debug than the nested function calls, since it's a more advanced programming concept, and obscures the traceback

This is why I believe @mloning was against decorators, and I agreed with him.

I would argue (and potentailly this isn't valid as ML is very different to web dev) that Flask, which is considered one of the most user friendly web development packages in Python; part of the reason it is seen as so user friendly is because of its use of decorators. Not only is it super simple to use, but it's also self documenting. Here is an example:
from flask import Flask, url_for
from markupsafe import escape

app = Flask(__name__)

@app.route('/')
def index():
    return 'index'

@app.route('/login')
def login():
    return 'login'

Just looking at this code with no knowledge of the application you know just from the decorator there are two GET methods for the route '/' and '/login'.
I also think using a decorator approach much better and consistently allows people to support their own custome datatypes. Lets say we support numpy and dataframe like so as a base in sktime.
@dtype_support.dataframe @dtype_support.numpy class SomeClassifier     def __init__():     ..... etc
If someone then comes along and wants to use a pytorch tensor or something, if all the logic is in the base class they're going to have to add a check to the top of their fit() that accounts for it, which is then confusing because if you were just looking at the code I'd wonder where are the rest of the checks?
By using decorators it still allows users to define their method to handle custom datatypes, but allows them to use it consistent manner to the rest of sktime. So for example:
We define our own custom tensor handler data type.
`
def dtype_support_tensor(estimator_class):
estimator_fit = estimator_class.fit
def fit(self, X):
    if torch.is_tensor(X)
        X = torch_tensor.cpu().detach().numpy()
    return estimator_fit(self, X)

estimator_class.fit = fit

return estimator_class
`
And then add it to their model in a consistent manner that makes sense.
@dtype_support.dataframe @dtype_support.numpy **@dtype_support_tensor** class SomeClassifier     def __init__():     ..... etc
My biggest concern with having to many decorators as you can see above 3 is already getting a bit ugly, so you can group ones togethers. So for example you can group a bunch together say we just define 'dtype_support.univariate' and 'type_support.multivariate' and these just encompass everything that @fkiraly (dataframes, numpy etc.) wants and then when looking at our code base it's super easy to determine what the model supports.
@dtype_support.multivariate class SomeClassifier     def __init__():     ..... etc

If someone then comes along and wants to use a pytorch tensor or something.
This is now confusing because if you were just looking at the code wouldn't you wonder where are the rest of the checks are?

No, not at the top of fit - you wouldn't touch that.
To add a new supported data type, you would add it in the converters module.
Once it is "registered" there, you can make use of pytorch tensors, and potentially write individual methods that use them natively (without conversion); while all already implemented methods would be able to use pytorch tensors by conversion (potentially inefficient, of course, but it runs).

This is much more consistent and just by glancing at my class I know it supports numpy, dataframe and tensor. It also doesn't clutter the body of the class.

In this design, you see whether the algorithm supports xyz by querying a tag - that's consistent with querying any other property.
In your design:

you have at least two sources of information about the forecaster: tags, and decorators. The decorators cannot be queried by the convenient all_estimators mechanism, but you have to sift through the code to find all estimators that can do numpy, say.
it is not clear which sequence to add the decorators. It is also not clear how the decorators would make sure that support is automatically added? The internal logic seems speculative, and potentially highly brittle.

and then when looking at our code base it's super easy to determine what the model supports.

but that's not what the "user archetype" is willing to do! They want to call the all-estimators method, say, to be able to query all estimators with a property. They will for sure not go manually through all code files and look at the decorator block.

This is not a great way of doing it I admit but the point being you can do what you like in the decorator and therefore there is definitly a solution for this.

@chrisholder, I agree that decorators are an attractive way of doing this - see the original STEP05 which was written in terms of decorators.
But, as said, the main argument against (brought up by @mloning and which I now follow) is the difficulty for the extender user archetype. The extension guidelines become more difficult to follow than with this suggestion, in my opinion. The less clear interface for inspection (tags vs decorators) is also an argument for the other solution, in my opinion.

So, to speed up this discussion: I think the community and core devs have had ample time to look at this - it's the longest thread in a while if you exclude code annotations; we've also had a dedicated 1+ hour meeting at the dev days. I'd explicitly brought up the opportunity for veto 2 working days ago. I'd say this plus having one more day next week satisfies the "reasonable time" requirement for the "lazy consensus".
So, if no one vetos by end of Monday, I'll merge this. FYI, @mloning - please veto if you don't like this.

(updating from main to prepare for merge - checks should pass but let's wait)

@fkiraly In the governance doc it says:

"To accept proposed changes, we require approval by one core developer (lazy consensus) and no rejection by a core developer (veto right)." - Currently there isn't an even a single approval yet? So why do you think you can merge? What's worse is that you know that there is disagreement. I think your comments above are not helpful at all. Note that on GitHub, we have we even require two approvals (I think that needs to be updated in the governance doc).
"Core developers are expected to give reasonable time to others to give their opinion on the pull request if they’re not confident others would agree." Given that this PR is only 7 days old, that I have asked for more time repeatedly and that the dev days were happening, I don't think that you're giving reasonable time to others.
"When no consensus can be found, any core developer can call for a vote at any point during the discussion." So seems like you can just call a vote. The more important point is that I'd like someone else to review it too.

I will take some more time now to look at the PR, read through the discussions above and write some comments on it.

I've been thinking about the proposed changes in the PR over the last few days. I feel that the discussion has been a bit tense at times, so I'll try to write down my reasons here for why I'm hesitant about this PR.
In general, I think that the proposed solution in this PR is a bit over-engineered: it solves a problem at a level of generality which isn't necessary for supporting multivariate forecasting in sktime. My preference is to work with the current (less general but simpler) input validation/conversion functions.
I think it's a bit over-complicated because we only want to support a few internal data types for the target series. That is, pd.Series for univariate forecasting and pd.DataFrame for multivariate series (supporting pandas data containers of course also gives access to the underlying NumPy arrays). I don't think we want to support other types in the univariate/multivariate forecasting module, or do we?
I believe that supporting these types internally can be solved more easily with the existing input validation/conversion functions (e.g. check_y) and keyword arguments which can be set automatically in the base class based on tags. For example, in fit in the base class, we could call (inside check_y_X):
y = check_y(
    y,
    enforce_univariate=has_tag(self, "univariate-only"),
    enforce_multivariate=has_tag(self, "multivariate-only"))

with one new boolean tag multivariate-only (as suggested by @aiwalter in some other PR) and a few more lines in check_y to handle the new keyword arguments. I could open a PR to see if that works in practice.
The solution in this PR adds:

non-boolean tags (not even string-valued tags, but type-valued tags, possibly with sets of types)
a new module for conversions, with functions relying on machine types, scitypes and type-valued tags
possibility to support multiple output types

My main worries are the following:

these changes may not be obvious for developers/users familiar with the PyData ecosystem, to me it departs significantly from scikit-learn in terms of input validation/conversion,
in order to understand how the data passes through the estimators (e.g. in inspecting, extending or debugging code), users and developers now have to have to be aware of:

the internal type (which may no longer be the same for all forecasters)
non-boolean tags
scitypes
the various conversion functions

non-boolean tags and scitypes are not self-explanatory at all I think. So it may make estimators less transparent and less extendible. In the worst case, undoing much of the work of the recent refactoring.
I also don't think that we want to support multiple output types. Wouldn't that complicate higher-level functionality such as composition (e.g. ensembling), or model evaluation (e.g. evaluate), as they would now have to handle different output types (we have seen the complications of that with the current pred_int interface)?

Do we want to support more internal types than the ones above? My preference is to stick to pd.Series and pd.DataFrames. We have seen that supporting multiple internal data types can lead to costly data copies, making it difficult to write efficient composition models, since each model may have to convert first the data it receives from the previous model (we have seen this in the classification setting).
To me, the proposed type conversions seems more relevant for the panel data setting, especially for user convenience, but even there I wouldn't want to support more internal types than we currently support if avoidable, with the exception of awkward array perhaps. But I would be happy to revisit the idea in that context.
Also note that panel and supervised forecasting probably requires a different API altogether (multiple stages of fit), so may not directly build on the univariate/multivariate forecasting API discussed in this PR.
If this PR finds broader approval from others, I'm happy to support the PR, review the code in more detail and suggest improvements (I agree with @lovkush-A that some minor things can still be improved).
Let me know what you think and if my reasons make sense. I'm happy to discuss them in more detail and I'm open to other arguments.

All I will say at this point is that it is a complex issue in code, in engineering and in toolkit strategy. I have discussed it in my group and we were not sure. This haste, trying to force a decision on a Saturday, is I think inappropriate. There is no actual urgency, and it seems like impatience is creating the impression of Franz trying to steam roller compliance or confrontation. Consensus is better. Let's talk next week, I don't want this issue to damage team relationships.

In general, I think that the proposed solution in this PR is a bit over-engineered: it solves a problem at a level of generality which isn't necessary for supporting multivariate forecasting. My preference is to work with the current (less general but simpler) input validation/conversion functions.

Disagreed, in the sense that supporting multivariate forecasting will be cumbersome, unintuitive, or both, without this. It will lead to writing of boilerplate code and user frustration with unclear interfaces.
There's a clear motivation to avoid this, so I disagree that this is "overengineered" - it is fit-for-purpose and elegant in the sense that it makes all existing forecasters ready for the multivariate extension, without breaking interface contracts.

I believe that supporting these types internally can be solved more easily with the existing input validation/conversion functions (e.g. check_y) and keyword arguments which can be set automatically in the base class based on tags. For example, in fit in the base class, we could call (inside check_y_X):

As said above: this would essentially split the forecasters into "pd.DataFrame only" and a "pd.Series` only" sub-types. Or it will require extensive rework of all forecasters manually. This is not desirable, so it is not a good suggestion.

these changes may not be obvious for developers/users familiar with the PyData ecosystem, to me it departs significantly from scikit-learn in terms of input validation/conversion,

The changes are "under the hood", and both the standard user archetype (in fit, predict etc) as well as the extender user archetype (in _fit, _predict) will deal with the familiar interfaces. We also avoid user frustration through rejection of pd.Seriesorpd.DataFrame` on unclear/uninspectable criteria. I don't see a major or "significant" divergence here.

users and developers now have to be aware of:

I think your list incorrectly frames sktime design principles as problems, or incorrectly "blames" existing problems of sktime on this PR. Let me go through your list.

the internal type (which may no longer be the same for all forecasters)

It already isn't so this is not a change this PR introduces. Search for occurrences of the enforce_numpy flag, we already have numpy vs pandas internally, and you can't blame this on this PR.

scitypes

this is a key design principle of sktime, and advanced users should already be familiar with this. See, e.g., this paper we wrote together. Or, search the code for the string "scitype".
This is nothing that this PR introduces - in fact, it follows core sktime design principles.

the various conversion functions

Look at utils/data_processing - there are a dozen or so from/to conversion functions (for panel time series data) in there, inconsistently named and with inconsistent function signatures. Developers are expected to understand this mess. This is i.m.o. ludicrous, instead there should be convert function, see my new PR #1061.
Here's the list of the converters for your edification:
    from_3d_numpy_to_2d_array,
    from_3d_numpy_to_nested,
    from_nested_to_2d_array,
    from_2d_array_to_nested,
    from_nested_to_3d_numpy,
    from_nested_to_long,
    from_long_to_nested,
    from_multi_index_to_3d_numpy,
    from_3d_numpy_to_multi_index,
    from_multi_index_to_nested,
    from_nested_to_multi_index,
    convert_from_dictionary,

non-boolean tags

This is indeed new, but you agreed in #1013 that non-boolean tags (e.g., string tags) are fine, and they are also needed in your alternate suggestion above.

non-boolean tags and scitypes are not self-explanatory at all I think. So it may make estimators less transparent and less extendible. In the worst case, undoing much of the work of the recent refactoring.

Are they more explanatory than the mess of converters? I think yes.
Is a single tag that lists the data types supported more explanatory than 5 boolean tags? I think yes.
Does it "undo" the recent refactoring? No, because that was done with the purpose to put all the boilerplate stuff in the base forecaster, and not have all the checks and conversions in 100 places in the concrete classes, precisely as this PR suggests.

I also don't think that we want to support multiple output types.

Disagreed - I think the user wants a pd.Series forecast when they pass a pd.Series, and a pd.DataFrame forecast when they pass a pd.DataFrame. Saying "no" in case a forecaster supports multivariate is a source of user frustration. Same for numpy.arrays.

I also agree with @chrisholder that decorators would help here, especially if we want to handle output types, as it keeps the conversion functionality outside of the code of the class and things like converter_store separate from the other class attributes.

Perhaps, but that's an orthogonal point (see #973 and #974) - whether the conversions are in a decorator or explicit in the base class does not touch the point of conversions and simultaneous support of univariate and multivariate data container types.

This haste, trying to force a decision on a Saturday, is I think inappropriate. There is no actual urgency, and it seems like impatience is creating the impression of Franz trying to steam roller compliance or confrontation. Consensus is better. Let's talk next week, I don't want this issue to damage team relationships.

@TonyBagnall, sorry if there was a misunderstanding - I'm not forcing a decision on a Saturday. I do not expect anyone to work on week-ends, and I have said that either someone should veto, or accept that this is merged on Monday (end of day).
That gives enough time to decide whether to veto this.
Once there is a veto, there are 5 more working days to think this through, I think that's ample time.
My fear is that we keep the multivariate issue indefinitely off the table, due to decision making paralysis because none of the potential solutions are perfect. We have been discussing the data container issues since the beginning of sktime, and there is no silver bullet. Perfect is the enemy of good, so if we want to get somewhere with multivariate, we need to stop stalling and get going.
And, of course, friendly working relations in the team should never be in question here. I do appreciate the work that @mloning and you, @TonyBagnall, are doing; I respect and value you as persons and collaborators.

@Lovkush-A, to reply to your high-level comments:

there should be some basic unittests before any PR is merged.

Good point - the current unit test suite tests downwards compatibility, but not the new cases where the input/output data type is flexible, or multivariate cases.
This will be a bit of a project and may also involve some refactoring of the current test suite, so I'll wait for resolution of this discussion.

might need to consider the .name attribute of a pd.Series object as being a candidate for dataframe column name. if this is a concern, then id personally be ok with this being turned into an issue for future consideration

Good idea - in the converters, I guess? Or is there another place this would be relevant?

in discussion, you (Franz) say that you think having lists of types for y_type tag might be better. I agree. Personally id be ok with this being turned into an issue for future consideration/adjustments

Yes, I think I've already decided I'd add this once the discussion is resolved positively.

[Unittests] will be a bit of a project and may also involve some refactoring of the current test suite, so I'll wait for resolution of this discussion.

I was only suggesting very basic checks for this PR - e.g. that the converter functions you created run without error on simple inputs - as opposed to testing how this interacts with everything else.

might need to consider the .name attribute of a pd.Series

Good idea - in the converters, I guess? Or is there another place this would be relevant?

My first instinct is it only matters in converters.

All, I looked at this again after having talked to @mloning and @TonyBagnall in the CC meeting and getting feedback on how this discussion felt from @mloning's perspective.
I think I did forget my good manners, regarding tone. My enthusiasm for multivariate and impatience might have gotten the better of me. Very sorry, @mloning.
I do think that disagreement, and even passionate disagreement, is a core ingredient of seeking scientific truth and engineering insight, but it needs to happen in a civil and friendly manner. I'll give it my best.
Regaring the force-merge, that would not be in line with the rules of governance, since as per reasonable reading, the PR requires at least one approval for that. I could call a vote without such approval in-principle, but I've decided not to do this right now, in the interest of giving core developers more time to review (and potentially approve or ask for amendments).

FYI, for those following this discussion: I think the new PR #1074 is meant as a counterproposal to this one.

My thoughts on Marcus' concerns above.

it solves a problem at a level of generality which isn't necessary for supporting multivariate forecasting.

To me, this is the big attraction! It is not just about multivariate forecasting, but a general framework for all of sktime. E.g. one of somebody's 'frustrations' in the final dev days meeting (not to do with forecasting) would be straightforwardly solved by this input/output framework. I can't remember the example, but you might remember I said 'That would be solved by Franzs input/output suggestion' and Franz said 'I was just about to say the same thing'

I don't think we want to support other types in the univariate/multivariate forecasting module, or do we?

Unlikely no, but this input/output framework makes it easy to adapt the interface if we do want more (or less) supported types

I believe that supporting these types internally can be solved more easily with the existing input validation/conversion functions (e.g. check_y)

That might be true. On the other hand, Franz has already coded this up and it does not look too complex.

non-boolean tags (not even string-valued tags, but type-valued tags, possibly with sets of types)

If this is an issue, we could make all the tags strings, and have a function that parses the string. E.g. instead of {y_inner_type: set([pd.Series, pd.DataFrame])} could have {y_inner_type: "series;dataframe"} and have function lambda tag: set(tag.split(";"))

a new module for conversions, with functions relying on machine types, scitypes and type-valued tags

I like this. It means all conversions are in one place in the codebase, as opposed to being split up in various check functions spread out across sktime.

possibility to support multiple output types (not sure if I have understood this correctly?)

I think that is part of the intended design. If a user inputs a dataframe for univariate forecasting, we convert it into series, do the forecasting, then convert it back to a dataframe.

these changes may not be obvious for developers/users familiar with the PyData ecosystem

For me, the main difficulty for developers/users is understanding the actual mathematics and subtleties of time series, rather than the interface.

to me it departs significantly from scikit-learn in terms of input validation/conversion

Yup, certainly a disadvantage. But I think it is a departure in a good way. E.g. I find it annoying in sklearn that I have to manually convert things back to dataframes, and think about whether index and/or column information has been lost. (Though, maybe the issue is I should be using Pipelines more...)

in order to understand how the data passes through the estimators (e.g. in inspecting, extending or debugging code), users and developers now have to be aware of:

the internal type (which may no longer be the same for all forecasters)
non-boolean tags
scitypes
the various conversion functions

I think most of these are fundamental issues of having a comprehensive time series package.

I also don't think that we want to support multiple output types. Wouldn't that complicate higher-level functionality such as composition (e.g. ensembling), or model evaluation (e.g. evaluate)

This is certainly worth thinking about! I don't know enough about these items to judge.

It looks like @fkiraly and I have come to an agreement, you can find our suggestion below. Feedback is very welcome! And thanks again for all the above comments:

which input types do we want to support for which scitype?

univariate/multivariate series: pd.Series, pd.DataFrame, np.ndarray?
FK opinion: there should just be one concept "series" - pd.Series, pd.DataFrame, 2D np.ndarray, 1D np.dnarray

np.ndarray are interpreted as axis 0 indexed by integers

which internal types do we want to support?

FK opinion: internally (in _fit, _predict etc without conversion), we should have "tiers" of support

low tier: pd.Series or pd.DataFrame (uni/multi)
mid tier: support both pd.Series and pd.DataFrame
high tier: supports all of these interally - target state

which output types do we want to support?

same as internal types?
FK opinion:

default is type in = type out
type out can be controlled by tag (override), this is useful when building pipelines, so conversions can happen only at start/end of long pipeline - push towards pandas internally
no strong opinion about type in = type out
ML does not like this

ML opinion:

target state: output should always be pd.DataFrame

FK would be happy with this

short/mid term: output should be pd.Series for all "univariate" tagged estimators, pd.DataFrame for all "multivariate" tagged estimators, input converted to internal format (usually pd.Series for "univariate")

FK is happy with this

how do we want to indicate whether a forecaster handles univariate data, multivariate data or both?

tags?
FK suggestions if we insist on bool:

scitype:multivariate - can handle multivariate series
requires_y_multivariate - cannot handle univariate series

univariate-only, multivariate-only
scitype:y {"univariate", "multivariate", "both"}

univariate: error if dim>1
multivariate: error if dim<2
both: no error from dim

scitype:y {"univariate", "multivariate", "multi_but_not_univariate"}
agreed on:scitype:y {"univariate", "multivariate", "both"}

edge cases

fbprophet which is univariate but requires pd.DataFrame
combined uni/multi forecasters

unit testing

new tags: test forecasters valid string values for y:scitype tag {"univariate", "multivariate", "both"}

maybe just do this for all tags? registry could also record expected values

input conversion: accepts all accepted inputs: pd.Series, pd.DataFrame, 2D np.ndarray, 1D np.dnarray
simply add "variants" of valid inputs to input checks
univariate/multivariate check: error should be raised if dimension too high/low - 2d np.ndarray and pd.dataframe on one side, 1d np.ndarray on other side

with minor comment, we aim for "mid tier" internal type support only, for the next half year or so.
so as steps, I would now:

remove or turn off the output checks, since the solution assumes (at least for short term) that uni/multivariate forecasters return the "right thing"
add the new tag and concomitant checks
add or modify tests to check multi-input-type compatibility and the tag working properly

Sounds good to me. Does that mean @markus' draft PR is being closed and work will continue on this PR?

Yes, I closed #1074.
@fkiraly let me know if you need help with the implementation.

I'm on it, just need to deal with BaseObject first since this one needs tags.

@mloning, @aiwalter , @TonyBagnall, I think this is now ready to review.
The one failing test is due to the newly enabled doctests, which insists I fill in all the docstrings for the tests because I just changed on line.
This should implement the agreed plan, with minor departures:

I also added conversions for X, while I was at it.
I changed some of the check functions to accommodate for np.ndarray as discussed - e.g., check_equal_time_index
I change the check functionality to allow for None (e.g., when X=None) - the general philosophy is to ignore None series and let them pass.
I replaced forecaster specific checks with scitype specific checks where possible, e.g., check_X by check_series. I think this looks much cleaner and much more general now.
I introduced an mtype function which returns a string representation of the machine type. This is to avoid type valued tags, and will also help later when there are two different representations of the same machine type.
I removed the output conversions by explicitly switching them off rather than removing them entirely, using the constant setting OUTPUT_CONVERSIONS = "off". I think that's a neat compromise for the other side of the "python in python out" ideological fence.

from verbal discussion with @mloning, @mloning reviewed this and did not like two things:

that output conversions were still implemented, just turned off - he thought the option should be removed entirely. That I highlighted as deviation from the agreed plan. @mloning's argument here is the unnecessary code complexity when looking at fit/predict. I concurred with this and agreed to remove entirely.
that I didn't remove the tag for the internal machine type, y_inner_mtype after our discussion. @mloning thought I deviated from the agreement here, though it didn't occur to me that this should have been removed (see list above). @mloning thought that the inner type should be fully determined by the y:scitype tag, and some translation between the y:scitype tag and the convert functionality should happen in fit and update. @mloning thought this was a strong point of contention. I disagreed that the tag should be removed, since I didn't think it was part of the agreement to change this part, and it would add the "glue code" to fit/update as unnecessary complexity in there.

Overall, we agreed that I can make the call to merge this PR - for instance, we can have detail discussions on the necessary tags later, and see it as a delta to this PR rather than a blocker for this PR.
The call I made is as follows:

I remove the output conversions entirely, in line with the spirit of our agreement above, and the argument of code complexity.
I'm keeping y_inner_mtype for the moment, to keep the conversion logic and the content of fit/update simpler; also, in consideration of the time series classification case and facebook prophet where the supposed 1:1 mapping of inner type and scitype is broken. Also, in consideration of potentially slowly adding geomstats like data container functionality to sktime, and development activity where it's not entirely clear yet whether this mapping would be easy to adhere to.

FYI, @aiwalter, @TonyBagnall.

@fkiraly Great effort, Franz! This is one monster of a PR.
I have seen all your comments/resolutions to my review conversations and am happy with decisions made. There was one conversation in which you gave two opposite answers to the same question (whether MvS is always pandas frames or not), but I do not think that is actionable in this PR.

FYI, @mloning: I also made changes to the test which parallel yours in #1074 - the enforce functions were not working properly.

@GuzalBulatova, @thayeylolu, this is now merged - and it should be useable in your work on multivariate forecasters.

authors: Lovkush-A TonyBagnall aiwalter chrisholder fkiraly mloning


text:
Add a filter for TimestampCommitment and BlockHashCommitment

The TrivialCommitment trait includes (optional) support for filtering of the candidate data.
In the case of a TimestampCommitment, the candidate data is a Bitcoin block header. Currently the expected data (a Unix timestamp) is sought inside the whole header, not just the timestamp field. This introduces a possible attack vector. An attacker could produce a header with a different timestamp but which contains, in a different field, the 32 bits matching a different timestamp. Without filtering of the candidate data, this bogus header would be accepted as valid (in the sense that the commitment would verify successfully).
The same applies to the BlockHashCommitment (where we should filter on the Merkle root field).

For this we'll need to:

make TimestampCommitment into a trait in trustchain-core, extending the Commitment trait

include a default implementation of the timestamp() method
also include the new() method signature in the trait (with expected_data argument of type Timestamp)

implement the trait in trustchain-ion
include an implementation of the filter() method that filters out everything from the commitment content (a Bitcoin block header) except the timestamp field.

Ok, this seems to work but the default implementation of the timestamp() method inside the TimestampCommitment trait is brittle:
/// A Commitment whose expected data is a Unix time.
pub trait TimestampCommitment : Commitment {

    /// Gets the timestamp as a Unix time.
    fn timestamp(&self) -> Timestamp {
        self.expected_data()
            .as_u64()
            .unwrap()
            .try_into()
            .expect("Construction guarantees u32.")
    }
}

It would be ok if we could enforce the condition that the expected_data must have type Timestamp, but I can't see a way to do that.
Also, I haven't yet run the implementation tests.
On the plus side, the implementation of verifiable_timestamp in IONVerifier is now a bit simpler, and the filter() is implemented.

Nice one, this is much better and fixes the issue!
I've made a couple of modifications:

Fixed test_block_hash_commitment() given revision and added failing case to test_block_timestamp_commitment() (2f7902ce02edf6858f18db243a8b9d9045784a83)
Changed TrivialCommitment and Commitment traits to take a generic (that defaults to Value) for the expected_data (556f122f1890de8ce39274001df42687d6188d3e). We can then implement these traits with the generic as a Timestamp for the BlockTimestampCommitment (e.g. here). The verify_content() method has an additional json!() on the expected data so it is always a Value.

I think this is good to go in #106 but some potential options for future:

Refactoring BlockHashCommitment to handle committing to both the timestamp and PoW hash as we can implement both Commitment<Value> and Commitment<Timestamp> (distinct generics)
We could refactor the commitment traits to have an associated type to make the candidate data specific relevant types instead of Value e.g.:trait Commitment {
  type Data;
  // ...
  fn decode_candidate_data(&self) -> fn(&[u8]) -> CommitmentResult<Data>;
  // ...
}

A downside of this though would be I don't think default implementations would be possible.

Done in #108

repo: alan-turing-institute/trustchain


text:
Can not send text on shareWhatsapp.share

Hello! Sorry for my english, this is a good plugin, when i used shareWhatsapp.share, overall i can send the files to the selected phone number, but i cannot send the text, how can i solve this?

@ihzadeprian1305 which platform?


text:
Link IFC results in null in revit 2023

Dynamo Revit 2.13.1.3891
Genius Loci 2023.7.13
DynamoIronPython2.7 2.1.0
In revit 2022 works perfect only in revit 2023 not. What's wrong?

Hi,
It is working for me with Revit 2023. Not sure where your issue is.

HI all,
I've got the same issue too :

Not sure what is happening
My packages seem ok too :

Link to discussion added: https://forum.dynamobim.com/t/importing-ifc-files-in-bulk-with-dynamo-into-revit/102060/4

repo: albandechasteigner/GeniusLociForDynamo


text:
Training Deeplab

Hello, can we also train the model by writing our training code (for example, by modifying fcnTrain routine ?

Hi @sm176357, unfortunately I didn't have time to get around to it, but it would certainly be possible.

repo: albanie/mcnDeepLab


text:
Xcode 8 beta 1: install Alcatraz fail

Goals
Install Alcatraz with Xcode 8 Beta 1
Expected Results
The package manager should successfully Install
Actual Results
Install fails to build In Terminal with this error
xcrun: error: unable to find utility "xcodebuild", not a developer tool or in PATH
Steps to Reproduce
Terminal input: curl -fsSL https://raw.githubusercontent.com/supermarin/Alcatraz/deploy/Scripts/install.sh | sh
Version Info
Alcatraz version: latest
Xcode version: 8.0 Beta 1
OSX version:  OS X 10.11.6

Please see: https://github.com/alcatraz/Alcatraz/issues/475

authors: jurre yueqianzhang

repo: alcatraz/Alcatraz


text:
Not working in Xcode8

Xcode8 install the plug-in fail

Try restarting your Mac. Has worked for some people.

i find this is useful  http://www.jianshu.com/p/dc2fc2a680fc  succeed!

https://github.com/alcatraz/Alcatraz/issues/73

Xcode 8 does not support loading plugins out of the box anymore.
Please see #475 for more info.


text:
chore: add eslint rule to check just the re-exported functions have jsdocs

Pull Request Checklist

[ ] Did you add new tests and confirm existing tests pass? (yarn test)
[ ] Did you update relevant docs? (docs are found in the site folder, and guidelines for updating/adding docs can be found in the contribution guide)
[ ] Do your commits follow the Conventional Commits standard?
[ ] Does your PR title also follow the Conventional Commits standard?
[ ] If you have a breaking change, is it correctly reflected in your commit message? (e.g. feat!: breaking change)
[ ] Did you run lint (yarn lint:check) and fix any issues? (yarn lint:write)
[ ] Did you follow the contribution guidelines?

PR-Codex overview
This PR adds custom ESLint rules, configures TypeScript, and sets up linting workflows.
Detailed summary

Added custom ESLint rules for JSDoc comments on re-exported functions
Configured TypeScript for ESLint plugin
Defined linting workflows for ESLint plugin build and testing

The following files were skipped due to too many changes: yarn.lock

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

heads up, gonna hold off on merging this until I've got https://github.com/alchemyplatform/aa-sdk/pull/728 working and then worked my way through batches of backfills of jsdoc comments.
once this branch passes linting, I'll merge it into v4.x.x. Then I'll get the CLI merged in

repo: alchemyplatform/aa-sdk


text:
Include full day when going every 30 minutes

Thank you for such an awesome package!
Is there a way to render cells every 30 minutes and include the full day (from 00:00 to 23:59), I have tried to do
<Scheduler
   week={{
        startHour: 0,
        endHour: 23,
        step: 30,
    }}
}
/>

but that shows from 00:00 to 11:30pm (given endHour is 23 so it only gets until 23:30). endHour doesn't seem to be able to be a float so things like 23.5 don't work sadly.

Good point
I will look into it

After #203 it will work out of the box, just need to change endHour to 24

I tried and see a bit of a margin for exact events and ones that end at midnight. Any suggestion on why this might be happening / how to fix it?

license: Unlicense


text:
🛑 BOS Fahrzeug Info is down

In 7a246c3, BOS Fahrzeug Info (https://bos-fahrzeuge.info/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: BOS Fahrzeug Info is back up in 3025c60 after 10 minutes.