text:
Ajax Select Field Doesn't Work As Expected

Hello everyone, I have a problem with Ajax as follows:
Here is my AdminModel:(Attempt #1)
class PlayerTeamModelView(AdminRole):
    def get_query(self):
        return PlayerTeam.query.join(PlayerTeam.player, aliased=True).join(PlayerTeam.team, aliased=True)

    column_labels = dict(player="Oyuncu Adı", shirt_number="Forma Numarası", goals="Gol", team="Takım")
    column_list = ['player', 'shirt_number', 'goals', 'team']
    column_filters = ('player',)
    column_sortable_list = ('goals',)
    form_ajax_refs = {
        'player': {
            'fields': (PlayerTeam.team.name,)
        },
        'team': {
            'fields': (TeamList.name,)
        }
    }

In following part of code I try to query relations attribute:
            'fields': (PlayerTeam.player.name,)
And here is my related Models:

class Team(db.Model):
    __tablename__ = "Team"
    id = db.Column(db.Integer, primary_key=True)
    # ForeignKey for one to many relationship
    fk_seasonandgroup = db.Column(db.Integer, db.ForeignKey(SeasonAndGroup.id), nullable=True)
    season_group = db.relationship(SeasonAndGroup)
    fk_teamlist = db.Column(db.Integer, db.ForeignKey(TeamList.id), nullable=True)
    team = db.relationship(TeamList)
    fk_team_director = db.Column(db.Integer, db.ForeignKey(Director.id), nullable=True)
    director = db.relationship(Director)
    fk_team_president = db.Column(db.Integer, db.ForeignKey(President.id), nullable=True)
    president = db.relationship(President)

    old_team_id = db.Column(db.Integer, unique=True, nullable=True)

    # Defining One to Many relationships with the relationship function on the Parent Table
    players = db.relationship('PlayerTeam')

    def __str__(self):
        return "{}".format(self.team)

class Player(db.Model):
    __tablename__ = "Player"
    id = db.Column(db.Integer, primary_key=True)
    name = db.Column(db.Text, unique=False, nullable=False)
    age = db.Column(db.Integer, unique=False, nullable=True)
    license = db.Column(db.Text, unique=False, nullable=True)
    image_path = db.Column(db.Text, unique=False, nullable=True)
    location = db.Column(db.Text, unique=False, nullable=True)
    city = db.Column(db.Text, unique=False, nullable=True)
    is_active_now = db.Column(db.Boolean, unique=False,
                              nullable=False, default=True)

    def __str__(self):
        return self.name

class PlayerTeam(db.Model):
    __tablename__ = "PlayerTeam"
    id = db.Column(db.Integer, primary_key=True)
    fk_player = db.Column(db.Integer, db.ForeignKey(Player.id), nullable=False)
    player = db.relationship(Player)
    team = db.relationship(Team)
    team_id = db.Column(db.Integer, db.ForeignKey('Team.id'))
    goals = db.Column(db.Integer, unique=False, nullable=False, default=0)
    shirt_number = db.Column(db.Integer, unique=False,
                             nullable=False, default=0)

    def __str__(self):
        return '{}'.format(self.player)

I get following error when I try above solution:
AttributeError: Neither 'InstrumentedAttribute' object nor 'Comparator' object associated with PlayerTeam.team has an attribute 'name'
If I replace following line
            'fields': (PlayerTeam.player.name,)
with
            'fields': (Player.name,)
It works but does not filter correctly. What should I do when I want to achieve ajax filtering over relatoinship's attribute. Eventhough I can't find good examples for AjaxModelLoader and QueryAjaxModelLoader but I tried them too. I really tried hard and can't find a solutoin for this issue, I would be happy if someone can help me. Any answer is appreciated, thanks! :)

from flask import Flask
from flask_sqlalchemy import SQLAlchemy
from flask_admin import Admin
from flask_admin.contrib.sqla import ModelView
from flask_admin.model.ajax import QueryAjaxModelLoader

app = Flask(__name__)
app.config['SECRET_KEY'] = 'your_secret_key'
app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:///test.db'
app.config['SQLALCHEMY_TRACK_MODIFICATIONS'] = False

db = SQLAlchemy(app)
admin = Admin(app)

class TeamList(db.Model):
    __tablename__ = "TeamList"
    id = db.Column(db.Integer, primary_key=True)
    name = db.Column(db.String(100))

class Director(db.Model):
    __tablename__ = "Director"
    id = db.Column(db.Integer, primary_key=True)
    name = db.Column(db.String(100))

class President(db.Model):
    __tablename__ = "President"
    id = db.Column(db.Integer, primary_key=True)
    name = db.Column(db.String(100))

class SeasonAndGroup(db.Model):
    __tablename__ = "SeasonAndGroup"
    id = db.Column(db.Integer, primary_key=True)
    name = db.Column(db.String(100))

class Team(db.Model):
    __tablename__ = "Team"
    id = db.Column(db.Integer, primary_key=True)
    fk_seasonandgroup = db.Column(db.Integer, db.ForeignKey(SeasonAndGroup.id), nullable=True)
    season_group = db.relationship(SeasonAndGroup)
    fk_teamlist = db.Column(db.Integer, db.ForeignKey(TeamList.id), nullable=True)
    team = db.relationship(TeamList)
    fk_team_director = db.Column(db.Integer, db.ForeignKey(Director.id), nullable=True)
    director = db.relationship(Director)
    fk_team_president = db.Column(db.Integer, db.ForeignKey(President.id), nullable=True)
    president = db.relationship(President)
    old_team_id = db.Column(db.Integer, unique=True, nullable=True)
    players = db.relationship('PlayerTeam')

    def __str__(self):
        return "{}".format(self.team)

class Player(db.Model):
    __tablename__ = "Player"
    id = db.Column(db.Integer, primary_key=True)
    name = db.Column(db.String(100))
    age = db.Column(db.Integer, unique=False, nullable=True)
    license = db.Column(db.String(100), unique=False, nullable=True)
    image_path = db.Column(db.String(100), unique=False, nullable=True)
    location = db.Column(db.String(100), unique=False, nullable=True)
    city = db.Column(db.String(100), unique=False, nullable=True)
    is_active_now = db.Column(db.Boolean, unique=False, nullable=False, default=True)

    def __str__(self):
        return self.name

class PlayerTeam(db.Model):
    __tablename__ = "PlayerTeam"
    id = db.Column(db.Integer, primary_key=True)
    fk_player = db.Column(db.Integer, db.ForeignKey(Player.id), nullable=False)
    player = db.relationship(Player)
    team = db.relationship(Team)
    team_id = db.Column(db.Integer, db.ForeignKey('Team.id'))
    goals = db.Column(db.Integer, unique=False, nullable=False, default=0)
    shirt_number = db.Column(db.Integer, unique=False, nullable=False, default=0)

    def __str__(self):
        return '{}'.format(self.player)

authors: ljluestc ozanonurtek

repo: pallets-eco/flask-admin


text:
Flask click SystemError when used with pySimpleGUI output redirect

I have a problem using Flask, that uses click echo method, with pySimpleGUI that permits the redirect of the standard output to a text field in the GUI. I get the following error:
SystemError: built-in method replace of str object at returned a result with an error set
I got a solution using the last answer of https://stackoverflow.com/questions/55677165/python-flask-as-windows-service
The modified code in lib\site-packages\click\utils.py, line 260:
if message:
    try:
        file.write(message)
    except SystemError:
        print(message)

internal python print has been substituted with another print function that redirects the output to the pySimpleGUI text field (output).
I don't know if this is the best solution to solve this problem, for now it just works.
If there is a better solution let me know. Please add the code to the next version of the library if possible.

This seems like an issue with pySimpleGUI, not with Click. I think we would need more context on what what you are trying to do with your Flask or click code, before changing Click.

source: gharchive/issue

repo: pallets/click

license_type: permissive

license_source: bigquery


text:
fix: make bash version detection locale independ

The BASH_VERSION variable holds the bash version number in a much
better consumable and especially locale independent format than the
--version flag.
This fixes #1940
Checklist:

[ ] Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
[ ] Add or update relevant docs, in the docs folder and in code.
[ ] Add an entry in CHANGES.rst summarizing the change and linking to the issue.
[ ] Add .. versionchanged:: entries in any relevant code docs.
[ ] Run pre-commit hooks and fix any issues.
[ ] Run pytest and tox, no tests failed.

Please rebase to 8.0.x and add a changelog entry.

Please rebase to 8.0.x and add a changelog entry.

Done.

I would change it this for now:
        output = subprocess.run(["bash", "--version"], stdout=subprocess.PIPE)
        match = re.search(r"(\d+)\.(\d+)\.\d+", output.stdout.decode())

This solves the locale dependent spelling of version ans also adds support for multi-digit versions (e.g. 5.12.23).  Since this still uses bash --version, it won’t introduce new issues.
So while this may not be the perfect solution, it will certainly improve the current state. :)

Why not use the version variable. This would completely avoid future surprises that always happen when one tries to parse data out of human readable descriptions one does not control.
The variable is at least clearly defined:

BASH_VERSION
The version number of the current instance of Bash.

(From  https://www.gnu.org/software/bash/manual/html_node/Bash-Variables.html)

source: gharchive/pull-request

authors: davidism janLo sscherfke


text:
'cli' is not found in my library

@app.cli.command('initdb')
def initdb_command():
"""Creates the database tables."""
init_db()
print('Initialized the database.')

#1048

authors: davidism pythonhunter

repo: pallets/flask

license_source: github-api


text:
Werkzeug useragent parsing is off for Motorola One Macro Android phone

I noticed this in a flask app but that uses werkzeug to parse useragent info and saw the same behavior in both the flask request object and standalone werkzeug useragent parser.
It looks like the presence of the substring "mac" in "macro" (the device model) is throwing it off. However, I feel like that should be overridden by the clear "Linux" and/or "Android 9".
>>> from werkzeug.useragents import UserAgent
>>> UserAgent("Mozilla/5.0 (Linux; Android 9; motorola one macro) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.111 Mobile Safari/537.36").platform
'macos'

I would expect the platform for this useragent string to be "android".
Environment: Linux

Python version: 3.7.3
Werkzeug version: 1.01

The issue is that UserAgentParser finds the platform by naively searching for keywords.
Here's the relevant code snippet:
    platforms: Any = (
        (" cros ", "chromeos"),
        ("iphone|ios", "iphone"),
        ("ipad", "ipad"),
        (r"darwin|mac|os\s*x", "macos"),
        ("win", "windows"),
        (r"android", "android"),
        ...

In your case, "darwin|mac|os\s*x" finds a match before "android" is searched. From what I've seen of user agent headers, they can vary wildly. Perhaps someone who has more experience can suggest better regex patterns. I'm concerned that our simple keyword search is inadequate and that there could be more unnoticed bugs like yours.

Rather than doing this in-house, maybe you can consider adding dependency on [ua-parser](https://github.com/ua-parser/uap-python/commits/0.10.0/ua_parser/user_agent_parser.py) library. I did a review of the project and its based on a pretty popular cross language core that has a very large test set. The python version supports a very wide array of python versions and the code itself should be pretty stable.

I'll offer up a PR unless you want to take a crack at it. Seems like a good solution.

I would like to take a crack at it. Thanks!

Rad! Thanks!

This is an interesting challenge. I'm new to Werkzeug so I had to do some analysis to get a baseline understanding.
It appears that one of Werkzeug's primary mandates is to not enforce any dependencies. Therefore its impossible to accomplish this with a pull request to the werkzeug library itself.
I think that the only way to use ua-parser with Werkzeug is to create a Request wrapper class in a separate python module; maybe werkzeugdep which would allow for dependencies. In that library, it would have its own Request class in wrappers.request.py that would include a UserAgentMixin which uses the ua-parser library.
Has there been any precedent for external werkzueg wrappers that have dependencies?

FYI - As I am not using Werkzeug for any current projects, I'm going to pass on doing any further work on this issue.

I'm happy to consider a PR that adjusts the matching rules to fix how this agent is matched, but we won't add a dependency for this.

The ua-parser package finds the appropriate user agent by using regex patterns (similar to our approach, but obviously more thorough). Their regex patterns take up ~5500 lines of code.
I think it's clear that we can't offer a complete UserAgentParser without adding ua-parser as a dependency or including parts of their code into Werkzeug.
Alternatively, we can add a message in the readme and/or docs to explain that our UserAgentParser is basic and won't work in many scenarios.

I've opened #1989 to address this platform string but it is far from a complete fix for the rest of the conversation here.

I've opened #1989 to address this platform string but it is far from a complete fix for the rest of the conversation here.

authors: JavaScriptDude davidism jcorvino mhelmetag tonydelanuez

repo: pallets/werkzeug


text:
Add missing documentation about None return type.

The documentation misses valuable information about the default return types for user agent.
From the documentation it is unclear if the attributes exist, are None or are empty strings when the user agent is not recognised.

Don't think the failing test has anything to do with these changes.


text:
Make @cached_property generic over the return type

fixes #2113

Checklist:

[ ] Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
[ ] Add or update relevant docs, in the docs folder and in code.
[ ] Add an entry in CHANGES.rst summarizing the change and linking to the issue.
[ ] Add .. versionchanged:: entries in any relevant code docs.
[ ] Run pre-commit hooks and fix any issues.
[x] Run pytest and tox, no tests failed.

The first two items should not be relevant for this PR, I am unsure about the middle two items.

Please rebase this onto the "2.0.x" branch, since it's a typing change it seems fine for a point release.

Closing, will reopen a new PR against the 2.0.x branch.

authors: davidism srittau


text:
Upgrade dependences and add language translations.

Upgrade:

Webpack
React

Language:

English
Chinese Simplified

Great contribution @tinymins, thank you.

authors: pamelus tinymins

repo: pamelus/lua-captive-portal

license: mit


text:
Katex公式解析多下标解析bug

代码提交不了，所以在这里直接反馈下：

katexRender方法(大概在1431行)中，传入解析的文本先替换xxx ->  _xxx_

var tex  = $(this), html = tex.html().replace(/(.+?)<\/em>/ig, '_$1_');
editormd.$katex.render($(html).text(), tex[0]);

katexHandle方法（大概在3839行）中，传入的文本解析修改如下：

katex.render(tex.html().replace(/(.+?)<\/em>/ig,'_$1_').replace(/</g, "<").replace(/>/g, ">").replace(/
]*>/ig,'\n'), tex[0]);

上列问题示例代码：
$$
NV_{n} = NV_{0} \times P_{0} \times P_{1} \times P_{2} \times \dots \times P_{n}
$$

遇到相同的问题，下标解析不了，请问解决了没

着急使用可以先按我说的自己修改下代码。

着急使用可以先按我说的自己修改下代码。

谢谢，这个问题按照你的方式我已经解决了。还请教一个问题，像下面这种公式，带反斜杠的问题，能解决吗
$$ {} $$
编辑器认为\是一个转义符，直接忽略了

着急使用可以先按我说的自己修改下代码。

谢谢，这个问题按照你的方式我已经解决了。还请教一个问题，像下面这种公式，带反斜杠的问题，能解决吗
$$ {} $$
编辑器认为\是一个转义符，直接忽略了

公式解析问题应该是在解析之前先mk解析了，最终解决办法感觉还是应该把公式解析部分独立传入公式解析器，解析完了再进行mk解析。
你这个问题因为我没遇到，可以在katex.render()这个地方把传入的内容console.log()打印出来，看看是不是已经被处理掉了，如果是，那就转回来再传入公式解析器。

您好! 我遇到了下标解析类似的问题，按照您的方法修改后依然无效
具体表现为：输入
where $$t_{ox}$$ and $$a_a$$
表现 正常

输入
where $$t_{ox}$$ and $$a_{ab}$$
错误表现为

但如果错开一行，表现依然恢复为正常，请问有比较好的解决方法吗

我遇到了同 @sjtuwzd 的问题。两个 inline 的公式，第二个没有被渲染正确。

这个是marked.min.js这个文件导致的，它解析后会把_解析成em标签，可以升级到最近版本的，就没有这个问题了，不过editormd里面有一行markdownDoc = new String(markdownDoc);需要注释掉，不然会报错。

这个是marked.min.js这个文件导致的，它解析后会把_解析成em标签，可以升级到最近版本的，就没有这个问题了，不过editormd里面有一行markdownDoc = new String(markdownDoc);需要注释掉，不然会报错。

非常感谢，完美解决！

authors: AndyQsmart insuns luzerochen sjtuwzd turnglight wzpan


text:
BUG: get_item accepts more types than it's type signature says

Pandas version checks

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

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

[X] I have confirmed this bug exists on the main branch of pandas.

Reproducible Example
from enum import Enum
import pandas as pd

class MyEnum(Enum):
    TAYYAR = "tayyar"
    HAYDAR = "haydar"

df = pd.DataFrame(data = [[12.2, 10], [8.8, 15], [22.1, 14]], columns=[MyEnum.TAYYAR, MyEnum.HAYDAR])
print(df[MyEnum.TAYYAR])

Issue Description
The example code above takes an Enum as column to a DataFrame and uses that enum in __get_item__.
It works fine, which creates an inconsistency with the signature of  __get_item__ method.
Here is the signature of __get_item__. According to this signature, enums are not accepted as index.
def __getitem__(self, Union[str, bytes, date, datetime, timedelta, bool, int, float, complex, Timestamp, Timedelta], /) -> Series[Any]

When you use a static type checker e.g. mypy on the code example above, it fails.
mypy_enum.py:12: error: No overload variant of "__getitem__" of "DataFrame" matches argument type "MyEnum"  [call-overload]
mypy_enum.py:12: note: Possible overload variants:
mypy_enum.py:12: note:     def __getitem__(self, Union[str, bytes, date, datetime, timedelta, bool, int, float, complex, Timestamp, Timedelta], /) -> Series[Any]
mypy_enum.py:12: note:     def __getitem__(self, slice, /) -> DataFrame
mypy_enum.py:12: note:     def [ScalarT] __getitem__(self, Union[Tuple[Any, ...], Series[bool], DataFrame, List[str], List[ScalarT], Index, ndarray[Any, dtype[str_]], ndarray[Any, dtype[bool_]], Sequence[Tuple[Union[str, bytes, date, datetime, timedelta, bool, int, float, complex, Timestamp, Timedelta], ...]]], /) -> DataFrame
Found 1 error in 1 file (checked 1 source file)

More info: https://stackoverflow.com/questions/75614405/mypy-indexing-pd-dataframe-with-an-enum-raises-no-overload-variant-error
Expected Behavior
__getitem__'s signature should be updated to support the column type itself. The column type is often not limited to primitive types. In can be custom objects as well.
Installed Versions
assert '_distutils' in core.__file__, core.__file__

Moved to pandas-stubs as pandas's DataFrame.__getitem__ has actually no annotations.

Does the annotation come from pandas-stubs?

Does the annotation come from pandas-stubs?

I assume so. It definitely doesn't come from pandas itself (unless you created an empty file called py.typed inside the pandas folder).

I see. No I definitely haven't created that file :)

I think if we add Hashable to the __getitem__()  declaration here, that should fix this.
https://github.com/pandas-dev/pandas-stubs/blob/fbc5f20d35c0d031fc30dfe2cd8e1dfb21c8610a/pandas-stubs/core/frame.pyi#L519
PR and tests welcome

Thanks @Dr-Irv I just make a PR with a test.

authors: Dr-Irv anilbey twoertwein

repo: pandas-dev/pandas-stubs


text:
GH: 666- fixed nightly issues

[x] Closes #666
[ ] Tests added: Please use assert_type() to assert the type of any return value

Done and it passes now

We're going to use #669 instead.  It will simplify things going forward, meaning that we don't have to keep fixing the code to pass nightly.

thanks

authors: Dr-Irv ramvikrams


text:
Counting negative values

Missing functionality
When asked to provide data overview, the number of negative value (and percentage) can be really helpful to assess data quality. I would like to add the number and the percentage of negative values to the summary.
Proposed feature
Look like it could be an easy implementation. Something like
summary['n_neg'] = series.lt(0).sum()
summary['p_neg'] = series.lt(0).mean()
in describe_numeric_1d
Alternatives considered
None
Additional context
Would be happy to open my first ever  PR

@gverbock Indeed I can imagine this to be useful in some cases, provided that the implementation is efficient.

authors: gverbock sbrugman

repo: pandas-profiling/pandas-profiling

license: MIT


text:
Add cetz support

First, thank you for this awesome package. I would like to know if you have considered adding typst package cetz support, it may be a nice addition to support scientific diagrams.
Typst provides:

an auto size page #set page(width: auto, height: auto, margin: .5cm)
also pdf, png, svg export

I don't know much about Typst, so I'll need help with this. Is it possible to generate standalone pictures with Typst?
It would definitely be a nice addition!

I can create a pull request and you'll give me some feedbacks to integrate it best on the extension.

That'd be great, thanks!

authors: benabel tarleb

repo: pandoc-ext/diagram


text:
Add spec parameter (Ready for Review)

Closes #https://github.com/panel-extensions/panel-graphic-walker/issues/7.
Todo:

[x] Implement, test and document
[ ] Philipp: read, address and close comments.
[ ] Philipp: Review and merge
[ ] Philipp: Release new version

Manual Test
Test via the app_demo.py file.

This is ready for review.

I added the earthquake "reference" example:

Just for the record. I tried to persist spec to url query args. But they will be too long for Microsoft edge. So its not a viable path to enable persisting app state for users:
https://github.com/Kanaries/graphic-walker/issues/420

super seeded by #30

repo: panel-extensions/panel-graphic-walker


text:
Implement scheduler basic functionality

Design scheduler that passes all unit tests

The first part of this project is to create an algorithm that solves all of the test cases that were provided to us, which is what this PR is for. The next part is to create more tests and to add more to the initial functionality, and this is what I am currently working on.

The first part of this project is to create an algorithm that solves all of the test cases that were provided to us, which is what this PR is for. The next part is to create more tests and to add more to the initial functionality, and this is what I am currently working on.

Starting from this project, I would like to see all new code come together with the detailed tests, which should be in the same pull request. I think the tutorial also implicitly indicates this: the step of sending PR comes after writing more tests
https://github.com/panerorenn9541/step/blob/master/walkthroughs/week-5-tdd/project/calendar-walkthrough.md#pull-request

The first part of this project is to create an algorithm that solves all of the test cases that were provided to us, which is what this PR is for. The next part is to create more tests and to add more to the initial functionality, and this is what I am currently working on.

Starting from this project, I would like to see all new code come together with the detailed tests, which should be in the same pull request. I think the tutorial also implicitly indicates this: the step of sending PR comes after writing more tests
https://github.com/panerorenn9541/step/blob/master/walkthroughs/week-5-tdd/project/calendar-walkthrough.md#pull-request


text:
Prevent server from getting stopped during long simulations

So far I am able to run long simulations as long as I keep my session more or less active (i.e. during my working hours). However, as soon as I leave it running during the night, my server is eventually stopped and the simulations get interrupted. I have configured my SSH file .ssh/ssh_config with keep alive as follows:
TCPKeepAlive yes
ClientAliveInterval 30
ClientAliveCountMax 240

X11Forwarding yes
X11UseLocalhost no

Is there anything else I should do in order to avoid that? What am I missing? Thanks in advance!

Ah thanks for reporting this @JordiBolibar, this is a novel situation for me. The automated logic to terminate an "inactive" server is quite intricate, but it won't check for open SSH connections as a sign of activity.

I've opened an issue about this in the project that has enable us to have ssh connections, yuvipanda/jupyterhub-ssh, to our jupyter servers so we could get potential help solving this more thoroughly.
We need to have a workaround for now.
I'm quite confident you can accomplish a workaround if you visit your server via the web UI (hub.jupytearth.org), start any notebook, and keep it running like...import time
# to avoid a mistake keeping a server running for months on end
# adding costs to the cloud bill, avoid putting in 999999999999 etc.
time.sleep(3600*24)

Hi Erik, thanks for the quick reply. I am in fact connecting through the web UI. I forgot I'm not longer attempting to connect from VSCode, since now there's the VSCode integrated in the browser. So indeed, the SSH configuration I posted is useless.
And thanks for the workaround. I will implement the same thing in Julia and see if that does the trick.

Oh hmmm

Do you think the bug I reported in https://github.com/yuvipanda/jupyterhub-ssh/issues/67 is correct or incorrect?
Is it correct that you are using visual studio code via the web interface (hub.jupytearth.org)?
Can you clarify what "running a simulation" implies? Are you running something from a terminal opened in the hub.jupytearth.org based visual studio code UI?

And thanks for the workaround. I will implement the same thing in Julia and see if that does the trick.

The goal is to have a server not be stopped, to do that, you need to be seen as active. For that, this workaround relies on having a "jupyter kernel" running at all time. What's important isn't that you run it in julia or python, but it's actually a registered kernel running. In practice, you can visit https://hub.jupytearth.org/hub/user-redirect/lab and start a python notebook and associated kernel running this sleep command, and then go to https://hub.jupytearth.org/hub/user-redirect/vscode and keep working.
I think you can the running kernels from a terminal with jupyter server list.

It depends if code-server is connecting via SSH or not. I'm not sure if it needs to do so or if it is run in the same server.
Yes, I'm using VSCode via code-server directly in the browser, the one present in the launcher.
Yes, I'm running a Julia simulation from the VSCode browser version from the hub UI.

OK, I see. But Would running sleep in a Julia script run from VSCode in the browser be equivalent to running the equivalent python command on a JupyterNotebook? It's just that I (almost) never work with Jupyter notebooks. So if I can directly integrate that command in my Julia code it would be much more useful. Thanks!

I want to come back to this issue that @JordiBolibar opened some time ago.
I had been using the time.sleep() trick for some time now, and I notice that without further notice the kernel of that notebook also dies without giving news before the established time. I wonder if there is a more stable solution in order to keep a server running for several hours, especially for long and computationally expensive simulations. @consideRatio do you have any idea of how to accomplish this? Running the sleep command from a terminal will have the same effect?
Thank you!

I think the way to do this is to:

Write a jupyter server extension that has  UI that says 'keep this server alive'
When it is enabled, it'll keep reporting that it is active to the server's API
This will ensure that the multiple killers we have (idle and in-server) don't get to it.

So users can go to this page, and say 'keep alive for 8h, 24h, until turned off' etc

@minrk's work on https://github.com/minrk/jupyter-keepalive address this quite well I think.
https://user-images.githubusercontent.com/3837114/194701158-b430aa8a-53e8-4ef0-ab59-8df7388c9b48.mov
With #155 I'll add it to the base image.

Hi @consideRatio, I'm still having issues with this. I cannot find the Keep server alive option, and running the notebook with a sleep command still doesn't work. I cannot run long simulations since my server gets disconnected after a short while.
Is it normal that I cannot access the option you displayed above in the video? Thanks a lot in advance!

Ah, I ended up disabling it when trying to resolve a very challengeng upgrade of other packages with coupled dependencies.
https://github.com/pangeo-data/jupyter-earth/blob/master/hub.jupytearth.org-image/Dockerfile#L415-L422
I'll see if I can upstream a resolution to this by getting the package build and published so that nodejs isn't required.

I opened https://github.com/minrk/jupyter-keepalive/issues/4 @JordiBolibar.
I'll see if I can re-configure something to help you avoid getting shut down.

Awesome, thanks a lot for your help!

@JordiBolibar I've not dropped the ball on this, but I'm swamped with work items. There is progress to getting jupyter-keepalive to help us here, so I'm currently aiming for that as a resolution.

authors: JordiBolibar consideRatio facusapienza21 yuvipanda

repo: pangeo-data/jupyter-earth


text:
Bitmap:

How to get bitmap from sketch Image View. Please give me an answer.

Do not recommend that you get the bitmap from SketchImageView and then work on the bitmap, because SketchImageView bitmap is managed by Sketch, you can Sketch.with().load() method to get uri bitmap
If you just want to view the SketchImageView bitmap, you can do that
sketchImageView.setDisplayListener(new DisplayListener() {
    ...

    @Override
    public void onCompleted(Drawable drawable, ImageFrom imageFrom, ImageAttrs imageAttrs) {
		Drawable lastDrawable = SketchUtils.getLastDrawable(drawable);
		if (lastDrawable != null && lastDrawable instanceof BitmapDrawbale) {
		    BitmapDrawable bitmapDrawable = (BitmapDrawable) lastDrawable;
		    Bitmap bitmap = bitmapDrawable.getBitmap();
		}
    }
});

authors: arunramya panpf

repo: panpf/sketch


text:
Fix VCS lock downloads to respect target.

Previously the ambient Pex interpreter was used to perform VCS downloads
instead of the target interpreter(s) selected by --python,
--python-path and --interpreter-constraint.
Fixes #2092

https://github.com/pantsbuild/pex/actions/runs/4389077036/jobs/7686264655#step:8:1520
Although I don't think a fix is needed for local project requirements, this failure doe show metadata gathering for sdists requires similar target scoping. That goes through pep_517 & pep_518 though, which is used for local project requirements as well. In short, I need to include that fork too here. More work coming...

repo: pantsbuild/pex


text:
Unable to format code on Linux - ./fantomas: No such file or directory

Environment
VsCode on Fedora Linux 33, with fantomas installed using dotnet tool install -g fantomas-tool
Issue
Triggering Fantomas with Ctrl-Shift-P >Format document gives the following error
[fantomas-fmt] Command failed with exit code 127: ./fantomas "/home/cfosli/.vscode/extensions/paolodellepiane.fantomas-fmt-0.3.0/fantomas.tmp.fs"/bin/sh: ./fantomas: No such file or directory
[fantomas-fmt] format failed

Additional info
I can use fantomas fine from the commandline, but I don't have a fantomas executable in the project directory.
It is located in ~/.dotnet/tools/fantomas since I installed it as a global tool, as suggested in the extension README.
It is available in $PATH, so in the commandline I can simply fantomas <filename>
Solution
See PR #21

Happens on macOS as well.

Please update the VSIX package at the VSCode Marketplace.

The location of fantomas binary is /Users/<your username>/.dotnet/tools/fantomas.

authors: AlexZeitler Nekroido christianfosli lulunac27a

repo: paolodellepiane/vscode-fantomas-fmt


text:
Auto-refresh queue

I'm often working with a single queue or queues that do not have subscriptions or event hubs (yet or ever) - I know that F5 will trigger a refresh of an queue however for those monitoring mesasge/DLQ numbers (note I am not suggesting wider use as queue monitoring application!) would auto-refresh be an option?

@Asura5 could you walk through how this would work? I imagine it would be some toggling to have a queue refreshed. But how often? Is it something that should be configured? Etc. You see where I'm leaning with this. Thanks.

This is not the first time that I receive this request. We should introduce two options in the application configuration and options dialog:

Enable autorefesh
Refresh interval in seconds
At each refresh, we should basically refresh the entire TreeView making sure to avoid flickering.

That's pretty much what I had in mind. The refresh rates are global to all queues, so:

Add Queue refresh time (seconds) option to OptionForm.
0 in this box disables auto-refresh, and is the default
Non-zero input will enable auto-refresh with the given number of seconds:

GetEntities called asynchronously (I am not sure of exact implementation details - awaitable Task?)

If it's in the UI I think we should provide a slider with reasonable values to avoid hammering SB because somebody wants to refresh every second, but that's my personal opinion.

@tomkerkhove  I couldn't agree more

Refreshing entities to get message counts is a bad idea.
First, we're on the old client and the new client has removed that functionality for a good reason.
Second, message count is not as accurate as you'd think. So pinging it every second for all entities will be just counterproductive.
Is F5 that hard? SBE is for managing entities and messages, not monitoring. If you need monitoring, I'd argue that's a different tool. My 2c 🙂

As suggested in the initial post I was in not suggesting use for monitoring - not nearly in the order of every second - more along the lines of every x minutes. However - thanks for the very clear feedback. I'll implement locally and close the issue.

authors: Asura5 SeanFeldman paolosalvatori tomkerkhove

repo: paolosalvatori/ServiceBusExplorer


text:
Deleted root app.config

Fixes #462

:x: Build ServiceBusExplorer 4.2.0-RemoveRootAppConfig.74.build.721 failed (commit https://github.com/paolosalvatori/ServiceBusExplorer/commit/7660712fa2 by @ErikMogensen)

:white_check_mark: Build ServiceBusExplorer 4.2.0-RemoveRootAppConfig.75.build.722 completed (commit https://github.com/paolosalvatori/ServiceBusExplorer/commit/3d9022bf30 by @ErikMogensen)

@ErikMogensen  @SeanFeldman another approval is necessary to merge the PR

Paolo, I am not allowed to approve my own PR.

Thanks @SeanFeldman for approving the PR :)

authors: ErikMogensen SeanFeldman paolosalvatori


text:
Showcase more advanced Op payload building

Describe the feature
with https://github.com/paradigmxyz/reth/pull/12229 we will have an easy way to configure the logic how transactions should be ordered.
this take will look something like
struct OpPayloadBuilder<EvmConfig, Txs>

where Txs is responsible for returning a https://github.com/paradigmxyz/reth/blob/c805e2c83acadbb3baafa29c2ce8bfae3793e0e7/crates/transaction-pool/src/traits.rs#L751-L751 instance.
effectively something like
fn best_transactions_for_block<Pool>(&self, attr: Attributes, pool:Pool) -> impl BestTransactions

that is being plugged in like https://github.com/paradigmxyz/reth/blob/c805e2c83acadbb3baafa29c2ce8bfae3793e0e7/crates/optimism/payload/src/builder.rs#L128-L130
the instance of BestTransactions could be anything, that even injects new txs manually top of block. Effectively A special iterator that yields txs to include in a block.
A primitive solution for priotising txs was added here:
https://github.com/paradigmxyz/reth/blob/c805e2c83acadbb3baafa29c2ce8bfae3793e0e7/crates/transaction-pool/src/pool/best.rs#L262-L265
but we can add an impl that is more advanced and can even create new txs, or even combine multiple tx sources (regular pool + something else)
cc @sevazhidkov
Additional context
No response

@mattsse some follow up questions and a proof-of-concept PR to align on the direction to go (#12320)
I was thinking two ways to configure block bundling:

Mega-struct with different rules that implements BestTransactions and manages sources under the hood
Smaller, nested & composable iterators wrapping around other iterators

Approach (2) felt more flexible, extendable and it has less dyn. best.rs already had higher-order BetaTransactions — BestTransactionsWithPrioritizedSenders (mentioned in the issue) and BestTransactionFilter, felt natural to continue that path and add some more primitives.
Here is an example block composition from PR:

        // (1) up to 100 gas: custom top-of-block transaction
        // (2) up to 100 gas: transactions from the priority pool
        // (3) up to 200 gas: only transactions from address A
        // (4) up to 200 gas: only transactions from address B
        // (5) until block gas limit: all transactions from the main pool

And implementation:
        let block = BestTransactionsChain::new(
            // Segment 1
            BestTransactionsFixed::single(Arc::new(
                f.validated(MockTransaction::eip1559().with_sender(address_top_of_block)),
            )),
            Some(100),
            BestTransactionsChain::new(
                // Segment 2
                priority_pool.best(),
                Some(100),
                // Segment 3
                BestTransactionsWithPrioritizedSenders::new(
                    HashSet::from([address_a]),
                    200,
                    // Segment 4
                    BestTransactionsWithPrioritizedSenders::new(
                        HashSet::from([address_b]),
                        200,
                        // Segment 5
                        pool.best(),
                    ),
                ),
                None,
            ),
            None,
        );

There are some issues with this:
        // - If prioritized addresses overlap, a single transaction will be prioritized twice and
        //   therefore use the per-segment gas limit twice.
        // - Priority pool and main pool must synchronize between each other to make sure there are
        //   no conflicts for the same nonce. For example, in this scenario, pools can't reject
        //   transactions with seemingly incorrect nonces, because previous transactions might be in
        //   the other pool.

(and potentially more stuff, will think through this one more time tomorrow, might miss something, particularly around multi-pool syncronizations).
Questions

What are you thoughts on the approach above? Should I explore approach (1) more?

and can even create new txs

This part actually might need more state than just BestTransactionsAttributes — block number comes to mind, but probably many other things. We're making single-block-use BestTransactions objects anyway, so I'm thinking that we can keep it simple and require the builder of impl BestTransactions to generate transactions somehow and include them via BestTransactionsFixed, instead of trying to generate within a trait implementation. Agree?

What's the best place to provide an example (post #12229)? Seems like examples does not have any OptimismNode, is this by design and should I start one to demonstrate the approach?

cool!
yeah 2) seems more flexible, yep lets continue with this

// - If prioritized addresses overlap, a single transaction will be prioritized twice and
//   therefore use the per-segment gas limit twice.
// - Priority pool and main pool must synchronize between each other to make sure there are
//   no conflicts for the same nonce. For example, in this scenario, pools can't reject
//   transactions with seemingly incorrect nonces, because previous transactions might be in
//   the other pool.

these are all valid, and I think we want to give the builder a better way to convey this by extending .mark_invalid with some context, like NonceTooHigh/Low so that the iterator can use that information.

to generate transactions somehow and include them via BestTransactionsFixed

that makes sense. I'm merging #12229 today and introduce some kind of factory trait for BestTransactions, so that this step becomes stateful and we can add more args that include the context, like PayloadAttributes + header, and maybe even the StateProvider, something like
trait PayloadTransactions {
   fn best(&self, pool, attr, ....) -> Box<dyn BestTransactions>
}

The best make to add config example rn, would be somewhere here:
https://github.com/paradigmxyz/reth/blob/5c2e9417fc16172fde117875d95708f3a5fc6ce3/crates/optimism/node/tests/it/main.rs#L3-L4
the way this would work, would be introducing a new builder:
https://github.com/paradigmxyz/reth/blob/5c2e9417fc16172fde117875d95708f3a5fc6ce3/crates/optimism/node/src/node.rs#L289-L289
or ideally we integrate this trait there as well.

@mattsse added some stub code to the PR for the example (#12320, please check if that's what you had in mind), but actually struggling to add the custom logic right now (the most important part of this example, haha)  — starting with the simple case of BestTransactionsFixed. Perhaps, my naive iterator combinator approach is breaking here.
BestTransactions is currently an iterator over ValidPoolTransaction<<Pool as TransactionPool>::Transaction>. So we actually need to create ValidPoolTransaction in BestTransactions implementation to maintain the same type.

We seemingly can't add and delete to the pool right away — as a matter of current TransactionPool interface, add_transaction is async.
We can create ValidPoolTransaction manually, but this requires faking SenderId, because we can't compute in the trait (right?).
We can re-arrange the types a little bit? E.g. return enum from BestTransactions that can be a pool-sourced transactions or custom tx?
Or we can edit interface of the pool a little bit to allow for ad-hoc non-async add transaction method that are assigned sender ID, but that are not actually going to be stored in the pool.

Let me know if you're leaning towards any of this solution or I should take a step back and come up with alternative plan for all of this.

#12320 is great

but actually struggling to add the custom logic right now

yeah I expected some complications here.

We seemingly can't add and delete to the pool right away — as a matter of current TransactionPool interface, add_transaction is async.
We can create ValidPoolTransaction manually, but this requires faking SenderId, because we can't compute in the trait (right?).

right, so it seems like that the BesTransactions isn't the right interface to use for this job, especially because we don't actually need it for execution:
https://github.com/paradigmxyz/reth/blob/4048117bcff47cd720e2bf16a01e031711017040/crates/optimism/payload/src/builder.rs#L765-L765

We can re-arrange the types a little bit? E.g. return enum from BestTransactions that can be a pool-sourced transactions or custom tx?

definitely, I think we can change https://github.com/paradigmxyz/reth/blob/4048117bcff47cd720e2bf16a01e031711017040/crates/optimism/payload/src/builder.rs#L397-L401 how we want. For this Pr it might make sense to just use impl Iterator<Item= TransactionSignedRecovered> and ignore the mark_invalid part for now. I'm thinking about that separately now, how to get rid of the mark_invalid(&Self::Item) part

Or we can edit interface of the pool a little bit to allow for ad-hoc non-async add transaction method that are assigned sender ID, but that are not actually going to be stored in the pool.

I think interacting with the pool (adding) is out of scope here and we should instead only consume from the pool.

or instead of doing impl Iterator<Item= TransactionSignedRecovered> we can introduce a new trait that is similar to BestTransactions but tailor made for block building, because in the future we might want to pass some additional context on next (e.g. the current evm state).
like
trait PayloadTransactions {

  fn next(&mut self, ctx: () /*TDB this could give the impl access to the current state so that it has access to storage, which can be used to determine priority (eventually) */)

  fn mark_invalid(&mut self, Address, Nonce)

}

@mattsse 100% agree about PayloadTransactions. implemented this in the PR, you can do the first pass if you'd like.
I'll need to finish actually starting the node & make the top-of-block transaction real (right now it's a mock) to see it working e2e, then it should be ready for final pass and merge.

@mattsse updated the PR with your suggestion & e2e test with a node that puts custom signed transaction in every block.
Raw ideas from the first experience of implementing the trait (but probably can be addressed in follow up issues / PRs):

Having async in PayloadTransactions would be nice. I'm using a local signed wallet, but I imagine prod users might want to use something like AWS KMS for signing / fetch prices to show in oracle. But I'm seeing that the rest of payload builder is sync, so this might be non-trivial.

Or even stream? But it might be harder to implement Stream for users.

Nonce management is an interesting example of problem that might be solved with state context in PayloadTransactions. If you're putting transaction on top of block, you'd like to have a helper on the state before the block. But if you're putting transaction at the end of block, you want state at the end of block (in case nonce has updated).

good points,
everything is sync here because haven't anticipated that we might need async during payload building itself.
maybe it's worth converting this to a stream which would unlock a few other use cases I guess, but encouraging async could also be problematic because all of this should happen asap, but for signing I can see it, though this could also be solved by blocking in place which would be fine here as well.

authors: mattsse sevazhidkov

repo: paradigmxyz/reth


text:
Revert "Getting green Travis tests"

Reverts parallel-js/parallel.js#142

Reverting because we didn't discuss this.


text:
Add Color Picker to Sneeze Board

Import a color picker from an external library
Enable users to pick a color as a new user or an existing user by using the color picker

Could use this small one https://github.com/omgovich/react-colorful


text:
Add kernel config checks

Fixes: #687
Just opening a draft for visibility, not ready to review yet.

@palash25 Glad that you're working on this. :smile:  Feel free to let me know if you would like me to give an early review or need any direction.

sorry i went travelling a few weeks ago and forgot about this. will take a
look at this next week
On Thu, Apr 20, 2023 at 7:41 PM Vaishali Thakkar @.***>
wrote:

@palash25 https://github.com/palash25 No rush but was wondering if I
can help you with something to revive this?
—
Reply to this email directly, view it on GitHub
https://github.com/parca-dev/parca-agent/pull/1471#issuecomment-1516402831,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFDAXHTRTP5WGETYXMANLDLXCE7ZJANCNFSM6AAAAAAWAHPMSI
.
You are receiving this because you were mentioned.Message ID:
@.***>

@palash25 A lot has changed recently. This needs a rebase if you want to continue working on it.

sorry for the late response, my RSI is back and so I am taking a break from typing for a few weeks, feel free to close this so that someone else can work on the issue

No worries! Hope you feel better soon

authors: javierhonduco kakkoyun palash25 v-thakkar

repo: parca-dev/parca-agent


text:
Fix pointer authentication for FP-based unwinding

This was missed in 872d82a740f8ceff4fce806d4cfa8daea83e5395. We need similar logic for FP unwinding as we already added there for DWARF unwinding.
See that commit message for details about what this is.

I just realized native mixed mode testing fails on arm https://github.com/parca-dev/parca-agent/actions/runs/8791927660/job/24127129336

authors: kakkoyun umanwizard


text:
feat: fix build errored in #197

#197 produced an errored build on CI (https://travis-ci.org/paritytech/js-libs/builds/501492154). This PR attempts to fix it.
I'm putting feat: here because #197 was a feat: and didn't pass.

Pull Request Test Coverage Report for Build 807

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 74.604%

Totals

Change from base Build 797:
0.0%

Covered Lines:
1361

Relevant Lines:
1833

💛  - Coveralls

authors: amaurymartiny coveralls

repo: paritytech/js-libs


text:
Tracking issue for enabling wasmtime

Before promoting the wasmtime wasm backend from hidden behind a cargo feature to just experimental (still off by default) we need to:

[x] clean some questionable unsafe code,
[x] aliasing violations, see https://github.com/paritytech/substrate/issues/4599
[ ] to make it compile (NOT run) on ARM, see #4188
[ ] zeroing for imported memories https://github.com/paritytech/substrate/issues/5036

I think this can be closed now.

repo: paritytech/substrate


text:
Keystore overhaul

Partially address https://github.com/paritytech/substrate/issues/13556
This PR is part of a small overhaul of the keystore related traits and structures.
A followup PR will focus on the keystore methods... I prefer to keep this PR small and quickly reviewable

Mostly delivers:

removal of the CryptoStoreasync trait.
It was introduced a long ago in the hope of a remote keystore.
Today the 90% of our code still depend on the sync version thus there's not point of having it around. If one day™ it will be really required then well can trivially reintroduce it.
But in the meantime is better to have no bloat in an already giant repo.
trivial renaming to better express the traits intent in a less verbose way. May be a bit opinionated but I think that overall the introduced names are a bit more coherent:

trait SyncCryptoStore -> Keystore
trait CryptoStore → removed 🔴
SyncCryptoKeyStorePtr → KeystorePtr
struct testing::KeyStore → testing::MemoryKeystore (this is what it is and is more inline with the other implementation we provide: LocalKeystore).

removal of a couple of unused methods from the trait interface: sign_with_any  and sign_with_all

the former was unused
the latter was used in one single place and can be trivially performed in the iteration that was required anyway for additional operations in the caller.

NOTE: big part of the changes spread through the project are due to the renamings 🫤.
polkadot companion: https://github.com/paritytech/polkadot/pull/6892
cumulus companion: https://github.com/paritytech/cumulus/pull/2336

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2533958

Polkadot CI fails because of https://github.com/paritytech/polkadot/pull/6898

bot merge

bot merge

authors: davxy paritytech-cicd-pr


text:
Documentation for Fees Module

Corresponding to 31

Update after 1924 is merged by uncommenting lines 101-107
Additional comments to the code seemed unnecessary, but can add more if requested
@xlc let me know if I missed anything from our conversation

[clabot:check]

I am uncertain about the goal of fees module (#1993) so I will hold off on review this until I got some clear answers.

I'm also confused regarding the purpose of fees at the moment, especially if an in-memory store is used to track the accumulation of fees in executive (which I agree may be the best path forward). I'll commit changes recommended by @thiolliere and add more comments once the stuff discussed in https://github.com/paritytech/substrate/issues/1993 is completed.

authors: AmarRSingh xlc


text:
Log kademlia errors when get/put record fails.

The current approach makes it difficult to figure out what the underlying error was, that made the operation fail.

Thanks @twittner!

authors: mxinden twittner


text:
Monitor transactions rejected from the pool as invalid

Adds a Prometheus metric counting transactions rejected from the pool as invalid. Fixes https://github.com/paritytech/substrate/issues/5991

[clabot:check]


text:
Remove Offence delay

Description
An offence can and should be immediately processed by the staking pallet.
Fixes #8343
Checklist:

[X] Remove can_report API from OnOffenceHandler
[x] Remove DeferredOffences storage from offences pallet
[x] Implement the storage migration logic
[ ] Update unit tests
[ ] Update benchmarks
[ ] Update docs and changelog

Context
Due to some technical circumstances the Offence delay has been introduced here https://github.com/paritytech/substrate/pull/4517
There's a good discussion about how to properly migrate storages here: https://github.com/paritytech/substrate/pull/8243

One question, the only safe and determinist way to remove the DeferredOffences storage is if the OnOffenceHandler::on_offence always succeed. Otherwise how do we guarantee that all deferred offences has been emitted?

One question, the only safe and determinist way to remove the DeferredOffences storage is if the OnOffenceHandler::on_offence always succeed. Otherwise how do we guarantee that all deferred offences has been emitted?

Sorry, don't get what you mean here?

All unit tests passed 🎉
The only thing that is missing is create a test that verifies if all offences has been resubmitted after on_runtime_upgrade

All unit tests passed 🎉
The only thing that is missing is create a test that verifies if all offences has been resubmitted after on_runtime_upgrade

Yeah, while generally it is a rare scenario, worth having a test for it.

Ok all good, but I don't have permission to add the labels to make CI happy.

I'm thinking about introduce a Versions storage item here, because if in the future anyone create a storage named DeferredOffences again here, will be hard to know if it is related to the old or the new one. Let me know if you agree, I can do it quickly :)

/benchmark runtime pallet pallet_offences

I tried running the benchmark, and it failed with a panic:
     Running `target/release/substrate benchmark --chain=dev --steps=50 --repeat=20 --pallet=pallet_offences '--extrinsic=*' --execution=wasm --wasm-execution=compiled --heap-pages=4096 --output=./frame/offences/src/weights.rs --template=./.maintain/frame-weight-template.hbs`
2021-04-29 02:19:11  panicked at 'assertion failed: `(left == right)`
  left: `1`,
 right: `4`', /home/shawntabrizi/substrate2/frame/offences/benchmarking/src/lib.rs:336:9
Error: Input("Error executing runtime benchmark: Other(\"Wasm execution trapped: wasm trap: unreachable\\nwasm backtrace:\\n    0: 0x349a - <unknown>!rust_begin_unwind\\n    1: 0x2bae - <unknown>!core::panicking::panic_fmt::hfa15f5472ef5e557\\n    2: 0x4a90 - <unknown>!core::panicking::assert_failed_inner::h1ff1547b4e20ab23\\n    3: 0x130a8e - <unknown>!core::panicking::assert_failed::h89bd600a40d6125d\\n    4: 0x27f7c9 - <unknown>!core::ops::function::FnOnce::call_once{{vtable.shim}}::h707e9d86b480d166\\n    5: 0x27c408 - <unknown>!<pallet_offences_benchmarking::Pallet<T> as frame_benchmarking::utils::Benchmarking<frame_benchmarking::utils::BenchmarkResults>>::run_benchmark::{{closure}}::h8f6420f41ee33d2b\\n    6: 0xf3317 - <unknown>!<pallet_offences_benchmarking::Pallet<T> as frame_benchmarking::utils::Benchmarking<frame_benchmarking::utils::BenchmarkResults>>::run_benchmark::heb6c42e5a24d0b3e\\n    7: 0xdfd3c - <unknown>!<node_runtime::Runtime as frame_benchmarking::utils::runtime_decl_for_Benchmark::Benchmark<sp_runtime::generic::block::Block<sp_runtime::generic::header::Header<u32,sp_runtime::traits::BlakeTwo256>,sp_runtime::generic::unchecked_extrinsic::UncheckedExtrinsic<sp_runtime::multiaddress::MultiAddress<<<sp_runtime::MultiSignature as sp_runtime::traits::Verify>::Signer as sp_runtime::traits::IdentifyAccount>::AccountId,u32>,node_runtime::Call,sp_runtime::MultiSignature,(frame_system::extensions::check_spec_version::CheckSpecVersion<node_runtime::Runtime>,frame_system::extensions::check_tx_version::CheckTxVersion<node_runtime::Runtime>,frame_system::extensions::check_genesis::CheckGenesis<node_runtime::Runtime>,frame_system::extensions::check_mortality::CheckMortality<node_runtime::Runtime>,frame_system::extensions::check_nonce::CheckNonce<node_runtime::Runtime>,frame_system::extensions::check_weight::CheckWeight<node_runtime::Runtime>,pallet_transaction_payment::ChargeTransactionPayment<node_runtime::Runtime>)>>>>::dispatch_benchmark::hcfcda55698ecda9f\\n    8: 0x2f10e5 - <unknown>!Benchmark_dispatch_benchmark\\nnote: run with `WASMTIME_BACKTRACE_DETAILS=1` environment variable to display more information\\n\")")

You can try running the following locally:
cargo run --release --features=runtime-benchmarks --manifest-path=bin/node/cli/Cargo.toml -- benchmark --chain=dev --steps=5 --repeat=2 --pallet=pallet_offences --extrinsic="*" --execution=wasm --wasm-execution=compiled --heap-pages=4096 --output=./frame/offences/src/weights.rs --template=./.maintain/frame-weight-template.hbs

Looks okay otherwise 👌

@shawntabrizi Interesting, using your command I'm getting this same error from master branch

@thiolliere good catch, WeightSoftLimit  removed 👍

Now I'm working on the companion PR

bot merge

@Lohann will have Kian merge this when he wakes up and if he is happy

@shawntabrizi sounds good! thx for your patience reviewing this PR 🙏
Btw the Companion section of CONTRIBUTING.adoc#updating-polkadot-as-well needs to be updated, using paths = ["path/to/substrate"] in ~/.cargo/config doesn't work for me (and seems deprecated too).
For create the companion PR I used diener instead, which is not documented but I've found it in the check_polkadot_companion_build.sh script.
git clone --depth 20 https://github.com/paritytech/polkadot.git
cargo install -f diener
diener patch --crates-to-patch ../ --substrate --path Cargo.toml

paths = ["path/to/substrate"] in ~/.cargo/config doesn't work for me (and seems deprecated too).

This works for me last I tried. What did you see was the issue when you tried it?

Will run again, one minute

warning: path override for crate `sp-trie` has altered the original list of
dependencies; the dependency on `sp-core` was either added or
modified to not match the previously resolved version

This is currently allowed but is known to produce buggy behavior with spurious
recompiles and changes to the crate graph. Path overrides unfortunately were
never intended to support this feature, so for now this message is just a
warning. In the future, however, this message will become a hard error.

To change the dependency graph via an override it's recommended to use the
`[replace]` feature of Cargo instead of the path override feature. This is
documented online at the url below for more information.

https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html

error: failed to select a version for `semver-parser`.
    ... required by package `semver v0.11.0`
    ... which is depended on by `cargo_metadata v0.13.1`
    ... which is depended on by `substrate-wasm-builder v4.0.0 (/Users/lohannpaternocoutinhoferreira/Documents/Projects/substrate)`
    ... which is depended on by `kusama-runtime v0.9.0 (/Users/lohannpaternocoutinhoferreira/Documents/Projects/polkadot/runtime/kusama)`
    ... which is depended on by `polkadot-service v0.9.0 (/Users/lohannpaternocoutinhoferreira/Documents/Projects/polkadot/node/service)`
    ... which is depended on by `polkadot v0.9.0 (/Users/lohannpaternocoutinhoferreira/Documents/Projects/polkadot)`
versions that meet the requirements `=0.10.0` are: 0.10.0

all possible versions conflict with previously selected packages.

  previously selected package `semver-parser v0.10.2`
    ... which is depended on by `cargo_metadata v0.13.1`
    ... which is depended on by `substrate-wasm-builder v4.0.0 (/Users/lohannpaternocoutinhoferreira/Documents/Projects/substrate)`
    ... which is depended on by `kusama-runtime v0.9.0 (/Users/lohannpaternocoutinhoferreira/Documents/Projects/polkadot/runtime/kusama)`
    ... which is depended on by `polkadot-service v0.9.0 (/Users/lohannpaternocoutinhoferreira/Documents/Projects/polkadot/node/service)`
    ... which is depended on by `polkadot v0.9.0 (/Users/lohannpaternocoutinhoferreira/Documents/Projects/polkadot)`

failed to select a version for `semver-parser` which could resolve this conflict

bot merge

authors: Lohann kianenigma shawntabrizi


text:
Allow adjusting priority coming from Signed Extensions

Closes #5672
The PR introduces AdjustPriority wrapper for SignedExtension. The motivation for introducing this is defined in the original issue. Basically we want to make sure that the priorities we add (coming from different Signed Extensions) are in reasonable order of magnitude.
The idea is to divide the priority of the CheckWeight so that instead of being in [0..MAX_BLOCK_WEIGHT] (for Normal transactions) range it's in [0..10] range.

Now, the priority is fee/weight ratio returned from TransactionPayment, which is some large-ish value.

Not large enough currently on some chains. The required tip to bump priority might be unreasonably high compared to the priority coming from CheckWeight (pure weight).

To rephrase, I am not sure where the range [0..10] comes from and why it is chosen.

The range is indeed arbitrary, just to have some differentiation between transactions. We can easily scale down by MAX_BLOCK_WEIGHT + 1 to make sure that Normal transactions are always 0. However the CheckWeight priority is still necessary to make sure that Operational and Mandatory transactions are prioritised correctly. Will fix.

it would be good if we can give a guideline of what rationale they should use to choose the range.

Indeed. Basically in case the ChargeTransactionPayment extension is added the original priority for Normal transactions coming from CheckWeight can be easily turned off (i.e. scaled down to 0), since the former takes into account all: weigh&tlength (fee) and the tip.

@kianenigma companion's here: https://github.com/paritytech/polkadot/pull/3743

Closing in favour of #9834


text:
Different registry return different signingPayload

I accidentally creating signingPayload by using another registry since I thought I can do it. The result is it creating incorrect payload that I can not submit to network. Here is the reproduce code:
import * as api from '@polkadot/api';
import * as util from '@polkadot/util';
import * as txwrapper from '@substrate/txwrapper';
import axios from 'axios';

const url = 'http://localhost:8080';

async function main() {
	const material = (await axios.get(`${url}/transaction/material`))
		.data as Record<string, any>;

	const keyring = new api.Keyring();
	const alice = keyring.addFromUri('//Alice', { name: 'Alice' }, 'ecdsa');

	const registry = txwrapper.getRegistry(
		material.chainName,
		material.specName,
		Number(material.specVersion),
	);

	const unsigned = txwrapper.methods.balances.transfer(
		{
			value: '10000',
			dest: '5DpGPTju2gHJKo8cjWRGwzyUPKHBkGVm7d9HH6XUyn5qi1p6', // random address
		},
		{
			tip: 0,
			nonce: 2,
			address: alice.address,
			eraPeriod: 10000,
			blockNumber: Number(material.at.height),
			blockHash: material.at.hash,
			genesisHash: material.genesisHash,
			metadataRpc: material.metadata,
			specVersion: Number(material.specVersion),
			transactionVersion: Number(material.txVersion),
		},
		{
			registry,
			metadataRpc: material.metadata,
		}
	);

	const extrinsicPayload = registry.createType(
		'ExtrinsicPayload',
		unsigned,
		{
			version: 4,
		}
	).toU8a({ method: true });

        const anotherRegistry = txwrapper.getRegistry(
		material.chainName,
		material.specName,
		Number(material.specVersion),
	);
        const anotherExtrinsicPayload = anotherRegistry.createType(
		'ExtrinsicPayload',
		unsigned,
		{
			version: 4,
		}
	).toU8a({ method: true });

        console.log('These payload are different:');
        console.log('extrinsicPayload:', util.u8aToHex(extrinsicPayload));
        console.log('anotherExtrinsicPayload:', util.u8aToHex(anotherExtrinsicPayload)); // This one will always fail after sign and submit to network
}

main().catch(console.log);

Is this behavior expected?

Yes, this is expected behaviour.
tl;dr you need to set the metadataRpc on the registry for it to work correctly. The first registry implicitly has the metadataRpc set on it when you call txwrapper.methods.balances.transfer but this never happens for the second registry (anotherRegistry).
Below is a modified version of your code snippet that shows one approach using getRegistry to to make sure the metadata is set on the registry. Look at the in code comments for a detailed explanation and links to relevant txwrapper code.
Feel free to ask any clarifying questions.
import * as api from '@polkadot/api';
import * as util from '@polkadot/util';
import * as txwrapper from '@substrate/txwrapper';
import { metadataRpc } from '@substrate/txwrapper/lib/util';
import axios from 'axios';

const url = 'http://localhost:8080';

async function main() {
	const material = (await axios.get(`${url}/transaction/material`))
		.data as Record<string, any>;

	const keyring = new api.Keyring();
	const alice = keyring.addFromUri('//Alice', { name: 'Alice' }, 'ecdsa');

	const registry = txwrapper.getRegistry(
		material.chainName,
		material.specName,
		Number(material.specVersion)
	);

	const unsigned = txwrapper.methods.balances.transfer(
		{
			value: '10000',
			dest: '5DpGPTju2gHJKo8cjWRGwzyUPKHBkGVm7d9HH6XUyn5qi1p6', // random address
		},
		{
			tip: 0,
			nonce: 2,
			address: alice.address,
			eraPeriod: 10000,
			blockNumber: Number(material.at.height),
			blockHash: material.at.hash,
			genesisHash: material.genesisHash,
			metadataRpc: material.metadata,
			specVersion: Number(material.specVersion),
			transactionVersion: Number(material.txVersion),
		},
		{
			registry,
			// The metadaRpc is used to set the metadata on the registry when this method is being executed.
			// Because of this, the registry you pass in here will now have the metadata set everytime you use it
			// after this method executes.
			// See here for how the method sets the metadata on the registry:
			// https://github.com/paritytech/txwrapper/blob/18960c95a6830653fc48e098698a8d8b15fd5808/src/util/method.ts#L60
			metadataRpc: material.metadata,
		}
	);

	const extrinsicPayload = registry
		.createType('ExtrinsicPayload', unsigned, {
			version: 4,
		})
		.toU8a({ method: true });

	// Pass in the optional 4th param to `getRegistry` so the metadataRpc will be set on the registry
	// for you
	const anotherRegistry = txwrapper.getRegistry(
		material.chainName,
		material.specName,
		Number(material.specVersion),
		// Here, we can pass in the metadataRpc, and `getRegistry` will set it on the registry for us.
		// However, if we don't pass it in then it will not be set on the registry for us and it will need
		// to be done at some later point with `registry.setMetadata(createMetadata(registry, metadataRpc));`
		// See here for how `getRegistry` sets the metadata on the registry:
		// https://github.com/paritytech/txwrapper/blob/18960c95a6830653fc48e098698a8d8b15fd5808/src/util/metadata.ts#L125
		metadataRpc
	);
	const anotherExtrinsicPayload = anotherRegistry
		.createType('ExtrinsicPayload', unsigned, {
			version: 4,
		})
		.toU8a({ method: true });

	console.log('These payload are different:');
	console.log(
		'The two payloads are the same because they have the same metadata set on the registry: ',
		util.u8aToHex(extrinsicPayload) ==
			util.u8aToHex(anotherExtrinsicPayload)
	);
}

main().catch(console.log);

repo: paritytech/txwrapper


text:
feat: change tooling to pnpm monorepo

Exchanges deno with traditional node tooling.
pnpm is a widely used supported package manager for node, which offers lean monorepo capabilities.
It ships with node>=16 and can be enable with corepack which is part of the node installation.
corepack enable

The pnpm-workspace.yaml defines the path to individual projects of the monorepo.
https://github.com/paritytech/useink/blob/5df27adcf0cc110965a097a77ca9acc04d50e8c3/pnpm-workspace.yaml#L1-L3
Each project can have it's own node setup. As of now we have useink/core and useink/chains under packages and playground contains the useink-kitchen-sink frontend.
Soon we should also add the docs to the repo as well. This way we have everything in a single repo and can create PRs which push changes to all related code in one PR.
Use pnpm install at the root to install all dependencies of defined monorepo projects.
pnpm install

I added some convenience scripts in the root package.json to build a the packages or to start a development environment running the "kitchen-sink" frontend.
https://github.com/paritytech/useink/blob/ac11bff016b4484f8aad71d5294a9e8dd16a8b89/package.json#L6-L9
Build packages:
pnpm build

Run development setup:
pnpm dev

The development setup runs the tsup tooling in watch mode and starts the kitchen sink nextjs setup in development mode for recompilation on file changes.

tsup is a popular choice for bundling ts libraries.
tsup docs

The setup was heavily inspired by the repo setup of wagmi. However, I have great experience using these tools in the past.
Why?

I struggled with compiling useink with deno in "watch" mode for speeding up development cycles

dnt (Deno Node Transform) was super slow for me and I don't want to invoke it manually all the time.

dnt states itself it's under early development and may not be suitable for production: This tool is under active early development and hasn't been tested in a lot of scenarios.

we are catering to the node world first and foremost. We are building a frontend library here, deno nor bun are not as widely used for this just yet. IMHO I don't find it worthwhile to drop all the existing mature tooling and struggling with comparability for {insert deno advantage here}. 🤷

Hey @DoubleOTheven, can you give this a try and see if this works for you.
Just updated this to your recent changes in kitchen sink and useink as well.
As mentioned in the PR description I think it has some key advantages over the current deno setup. Please let me know what you think, if we go with this monorepo node approach I will adapt the gh actions as well.

This is a great change. I love that we get hot reloading and have a mono repo.
As per our call, next steps are to wrap up the PRs for Chaindata and Notifications, then move to this approach.
Nice work!

Amazing direction!
At current FT job I've implemented pnpm along turborepo to simplify overall build process:
https://turbo.build/repo

Amazing direction! At current FT job I've implemented pnpm along turborepo to simplify overall build process:
https://turbo.build/repo

Yes that would be the next step. Not sure if turborepo or nx. I personally I'm a fan and user of nx but haven't tried turborepo in the last 8 months or so. We got it on our radar for further improvement of the development experience.

heya 👋
what the progress on this, I need this to ease my testing regarding this issue:
https://github.com/paritytech/useink/issues/40
if there are any ways I can facilitate this, let me know

Version 1.1.0 has been released. Do you want to look into migrating to node based off of the latest main branch?

Yep will give it another go. 👍:)

Just updated the code in this branch to the most recent useink version.
Fyi it does not have multiple packages as the original deno code doesn't. It's just multiple entry points in a single packages as the deno version did it.
So for this initial switch we only have two projects in this this monorepo workspace, packages/useink as it's working before and the useink-kitchen-sink as playground.
Please give it a try @DoubleOTheven if everything works as expected. Also happy to get some feedback from @nicolad and @felixpolimec (#46).
At best fresh copy of this branch then use pnpm i to install all dependencies and run the playground and bundling of the library with pnpm dev.

hey @peetzweg thanks for giving it another go 🚀
I am using node v18.12.0 currently and it works perfectly, aside those conflicting errors you pointed out.
Switched to v19 using nvm, works perfectly as well.
I had some similar errors while using turborepo + pnpm and fixed with pnpm.overrides, not sure if the same fix might apply here, but worth giving a try.

Thanks this change @peetzweg. It works great on my end. The watch mode is 🔥

I would love to merge this in. Just two requests.
1. Please pull in the latest changes from `1.4.2` and `1.4.3`

2. We lost linting and auto formatting. Deno has this by default. Would you please add prettier and eslint? I'm open to moving that task to another PR if you think it best. Just raising the need...

Great points! Just updated the code.
Instead of prettier and eslint I've removed them from the playground project and added rome instead. It got quite popular and I think it's worth a try. Works great so far. Not so many languages or plugins supported but we got what we need so far.
https://github.com/paritytech/useink/blob/72fbb5c12d027b736bf3653ba384893efb725377/package.json#L11-L13
Furthermore, I've added a settings.json and extensions.json file for the for vscode. Suggestion some extensions and enabling some workspace setting to get up and running with rome.
https://github.com/paritytech/useink/blob/72fbb5c12d027b736bf3653ba384893efb725377/.vscode/settings.json#L1-L7
https://github.com/paritytech/useink/blob/72fbb5c12d027b736bf3653ba384893efb725377/.vscode/extensions.json#L1-L4

@DoubleOTheven
merged with main to resolve conflicts. Fixed lint and spellcheck actions. Had to fix some lint issues so lint ci will succeed. This commit includes the fixes:
https://github.com/paritytech/useink/pull/55/commits/071d27cac79229cb20acdf463e66c421d4dee7cb
Release action should work as well 🤞

authors: DoubleOTheven nicolad peetzweg

repo: paritytech/useink


text:
Can a *parquet.File be used from multiple goroutines?

It looks like, as long as the underlying io.ReaderAt is thread-safe that a *parquet.File is also thread-safe -- since each stateful read operation (that must track state of where the reader's position is) creates a new object. (Those stateful objects are of course not thread-safe.) This appears true of the various readers as well as ColumnChunk.Pages.
However, if this is the intent, there is an issue with column and index offsets: when they are lazy-loaded via ColumnChunk.ColumnIndex or ColumnChunk.OffsetIndex, the chunk will be mutated so the newly loaded data structure can be written to a field.
The above seems rather easy to address by either using atomic pointers for these values are guarding access/update via a mutex. But I wonder if there might be other issues with attempting to re-use a single File from multiple goroutines? My use case would prefer to cache the file (and all of the parsed metadata) and then create multiple readers that all want to seek to different points in the file and then stream rows from that point. So I'm just wondering if it this usage is acceptable. (The io.ReaderAt implementation I am using is thread-safe.)
If it is intended to be acceptable, and the race conditions around lazy-initializing the indexes in ColumnChunk are a bug, I'm happy to contribute a fix.

This is a good question. When I added the lazy loading of column and offset indices I did not take into account concurrency.
This makes sense to me, but would like to hear @achille-roussel's opinion on whether the File type was meant to be used concurrently.

We didn't document that *parquet.File should be safe to use concurrently but it's true that it was implicitly safe before we made some internals lazy-load.
Since it's a read-only type, it seems like a good improvement to guarantee concurrency-safety 👍

authors: achille-roussel fpetkovski jhump

repo: parquet-go/parquet-go


text:
Opting out of token interning

Hey, thanks for making this crate. :)
Would it be possible to call diff without having to intern the input first? In my use case (character-wise diffing) interning doesn't seem necessary, as chars should be as cheap to compare as Tokens (that are just u32's under the hood) - and interning has it's non-trivial cost.
Thanks!

you can use diff_with_tokens for providing arbitrary tokens with your own interning (or no interning at all). Tokens are just u32 newtype wrappers (with a pub inner field) so you can easily provide you own tokens. However you will need to allocate vectors since diffing fundamentally needs random access.
Note that the histogram algorithm fundamentally requires interning (even for char diffs sice it needs a low cardinality input set) but for char diffs I would expect Myers to produce more appropriate results anyway. If you only use Myer diff then the value of num_tokens doesn't matter (its not used) but the correct value would probably be u32::MAX (or the maximum unicode codepoint plus 1).
If you can guarantee that your input is only ascii (or some reasonable other unicode subset) then you could also used histogram and pass 128 for num_tokens

authors: osiewicz pascalkuthe

repo: pascalkuthe/imara-diff


text:
Fatal error when using Relevanssi plugin to search Passle posts

After activating Relevanssi premium and building the index with Passle posts included, I get the error below when performing a search using WP_Query.
I think it may have to do with the filter property of the Passle object the class is trying to treat as a WP_POST, as described here:
https://barn2.com/blog/learn-how-to-create-a-fake-wordpress-post-on-the-fly/
Fatal error: Uncaught Error: Cannot assign stdClass to property Passle\PassleSync\Models\PasslePost::$wp_post of type WP_Post
in .../wp-content/plugins/passle-sync/class/Models/PasslePost.php on line 124
Call stack:
Passle\P\M\PasslePost::__construct()
wp-content/plugins/passle-sync/class/Services/ThemeService.php:72
Passle\P\S\ThemeService::modified_the_content()
wp-includes/class-wp-hook.php:324
WP_Hook::apply_filters()
wp-includes/plugin.php:205
apply_filters()
wp-content/plugins/relevanssi-premium/lib/excerpts-highlights.php:140
relevanssi_do_excerpt()
wp-content/plugins/relevanssi-premium/lib/excerpts-highlights.php:1648
relevanssi_add_excerpt()
wp-content/plugins/relevanssi-premium/lib/search.php:699
relevanssi_do_query()
wp-content/plugins/relevanssi-premium/lib/search.php:88
relevanssi_query()
wp-includes/class-wp-hook.php:324
WP_Hook::apply_filters()
wp-includes/plugin.php:256
apply_filters_ref_array()
wp-includes/class-wp-query.php:3161
WP_Query::get_posts()
wp-includes/class-wp-query.php:3852
WP_Query::query()
wp-includes/class-wp.php:696
WP::query_posts()
wp-includes/class-wp.php:816
WP::main()
wp-includes/functions.php:1336
wp()
wp-blog-header.php:16
require()
index.php:17

I was able to get around this by adding the following at line 118 of class/Models/PasslePost.php. Let me know if you'd like me to create a pull request or if there is another way of avoiding this error.

repo: passle/passle-sync-wordpress


text:
ACL Group Names

I see that the ACL groups being defined are "Pastors" and "Staff".
Depending on how granular the permissions need to get, perhaps this could reflect PCO's permissions structure and use the term "administrators" and/or "schedulers" instead of "staff"? It's pedantic, but staff implies a paid employee, and some PCO schedulers may be trusted, senior volunteers.
I'll wait to hear back before making pull requests.

@Chalta , I was thinking about this today. I started to do a complete overhaul of will bot's acl system. Because we need to be able to edit acl from slack or at least from userland rather than editing a config file. I think the best way to handle it would be to actually check planning center permissions against the slack user. We should be able to match up email address and name to pco users and check their permissions. If we can get this to work then willbot acl will only need to have administrators in it for backend stuff. Would you like to work on this?

I'm going to take a stab at the planning center permissions integration. I'll leave this open so we can figure out what the default ACL groups for will-bot should be.

I changed all Planning Center commands to check permission from planning center rather than use the will bot ACL. I also changed the default ACL:
ACL = {
    "admin": ["some_admin"],
}

Would you like to update the README?

Updated. I'm closing this. @Chalta Feel free to make it better. I like the way you changed it last time :)

authors: Chalta pastorhudson

repo: pastorhudson/pcobot


text:
All searches return (Object doesn't support #inspect) after upgrading from 2.1.x to 3.1.4

Hello,
I just upgraded thinking-sphinx from 2.1.x to 3.1.4, and re-indexed without any issues, however now I cannot retrieve any results, with all searches yielding (Object doesn't support #inspect).
I've found a number of references to this error which appears to be related to the mysql2 library version though I believe I am using the recommended version.
I'm using Sphinx version 2.2.10 (Sphinx 2.2.10-id64-release (2c212e0))
I have the following defined in my gemfile related to thinking-sphinx:
gem 'thinking-sphinx', '~> 3.1.0'
gem 'ts-delayed-delta', '~> 2.0.2'
gem 'mysql2',          '~> 0.3.18', :platform => :ruby
gem 'delayed_job_active_record'
Here's the output from bundle listing the specific versions installed:
bundle
...
Using delayed_job_active_record 4.0.3
Using mysql2 0.3.20
Using thinking-sphinx 3.1.4
Using ts-delayed-delta 2.0.2
Here's the output from a basic search:
City.search('New Milford, CT')
(Object doesn't support #inspect)
=>
Here's what I get by adding .to_a
City.search('New Milford, CT').to_a
NoMethodError: undefined method inject' for nil:NilClass 	from /Users/daniel/.rvm/gems/ruby-1.9.3-p392/gems/thinking-sphinx-3.1.4/lib/thinking_sphinx/middlewares/inquirer.rb:49:in call'
from /Users/daniel/.rvm/gems/ruby-1.9.3-p392/gems/thinking-sphinx-3.1.4/lib/thinking_sphinx/middlewares/inquirer.rb:14:in block in call' 	from /Users/daniel/.rvm/gems/ruby-1.9.3-p392/gems/thinking-sphinx-3.1.4/lib/thinking_sphinx/middlewares/inquirer.rb:13:in each'
from /Users/daniel/.rvm/gems/ruby-1.9.3-p392/gems/thinking-sphinx-3.1.4/lib/thinking_sphinx/middlewares/inquirer.rb:13:in call' 	from /Users/daniel/.rvm/gems/ruby-1.9.3-p392/gems/thinking-sphinx-3.1.4/lib/thinking_sphinx/middlewares/geographer.rb:11:in call'
from /Users/daniel/.rvm/gems/ruby-1.9.3-p392/gems/thinking-sphinx-3.1.4/lib/thinking_sphinx/middlewares/sphinxql.rb:14:in call' 	from /Users/daniel/.rvm/gems/ruby-1.9.3-p392/gems/thinking-sphinx-3.1.4/lib/thinking_sphinx/middlewares/stale_id_filter.rb:10:in call'
from /Users/daniel/.rvm/gems/ruby-1.9.3-p392/gems/middleware-0.1.0/lib/middleware/runner.rb:31:in call' 	from /Users/daniel/.rvm/gems/ruby-1.9.3-p392/gems/middleware-0.1.0/lib/middleware/builder.rb:102:in call'
from /Users/daniel/.rvm/gems/ruby-1.9.3-p392/gems/thinking-sphinx-3.1.4/lib/thinking_sphinx/search.rb:67:in populate' 	from /Users/daniel/.rvm/gems/ruby-1.9.3-p392/gems/thinking-sphinx-3.1.4/lib/thinking_sphinx/search.rb:91:in to_a'
from (irb):2
from /Users/daniel/.rvm/gems/ruby-1.9.3-p392/gems/railties-3.2.22/lib/rails/commands/console.rb:47:in start' 	from /Users/daniel/.rvm/gems/ruby-1.9.3-p392/gems/railties-3.2.22/lib/rails/commands/console.rb:8:in start'
from /Users/daniel/.rvm/gems/ruby-1.9.3-p392/gems/railties-3.2.22/lib/rails/commands.rb:41:in <top (required)>' 	from script/rails:6:in require'
Also, sphinx's search command does retrieve results successfully for all indexes:
search -c config/development.sphinx.conf
using config file 'config/development.sphinx.conf'...
index 'city_core': query '': returned 1000 matches of 2564934 total in 0.062 sec
displaying matches:

document=1033533, weight=1, full_name=Xixerella, full_name_nd=Xixerella, adm1_full_name=Parròquia de la Massana, adm1_code=04, adm2_full_name=, adm2_code=, cc_iso=AD, sort_name=XIXERELLA, sphinx_internal_id=38279, sphinx_internal_class=City, sphinx_deleted=0, id=38279, uni=80500001, weight=0, lat=0.742695, lng=0.025959
document=1033560, ....

Here's my city index definition:
ThinkingSphinx::Index.define(:city, :with => :active_record, :delta => ThinkingSphinx::Deltas::DelayedDelta) do
indexes full_name, full_name_nd, adm1_full_name, adm1_code, adm2_full_name, adm2_code, cc_iso, sort_name, :sortable => true
indexes country(:country_name), :as => :country_name
indexes city_aliases(:alias_name), :as => :alias
has :id
has :uni
has :weight
has "RADIANS(latitude)",  :as => :lat,  :type => :float
has "RADIANS(longitude)", :as => :lng, :type => :float
end
I'm sure I'm missing something stupid, but seem to have hit a dead end on what to look at next.
Any suggestions would be appreciated,
Thanks!

Daniel

Did you get this one sorted? Sounds like Sphinx may have not been compiled with mysql support?

No, unfortunately didn't figure it out.  I put in some rough logging around where the the exception was being thrown and found that the results were being retrieved.
Here's a snippet:
ThinkingSphinx::Middlewares::StaleIdFilter.call first context [#<ThinkingSphinx::Search::Context:0x007fb3d10e1578 @search=[{"id"=>2398812, "weight"=>55907, "full_name"=>"Milford", "full_name_nd"=>"Milford", "adm1_full_name"=>"Connecticut", "adm1_code"=>"CT", "adm2_full_name"=>"New Haven County", "adm2_code"=>"009", "cc_iso"=>"US", "sort_name"=>"MILFORD", "sphinx_internal_id"=>2398812, "sphinx_internal_class"=>"City", "sphinx_deleted"=>0, "uni"=>82860534, "lat"=>0.719465, "lng"=>-1.275077}, {"id"=>2398870, "weight"=>28338, "full_name"=>"New Milford", "full_name_nd"=>"New Milford", "adm1_full_name"=>"Connecticut", "adm1_code"=>"CT", "adm2_full_name"=>"Litchfield County", "adm2_code"=>"005", "cc_iso"=>"US", "sort_name"=>"NEWMILFORD", "sphinx_internal_id"=>2398870, "sphinx_internal_class"=>"City", "sphinx_deleted"=>0, "uni"=>82860592, "lat"=>0.725656, "lng"=>-1.281219}, {"id"=>2398813, "weight"=>0, "full_name"=>"Milford Lawns", "full_name_nd"=>"Milford Lawns", "adm1_full_name"=>"Connecticut", "adm1_code"=>"CT", "adm2_full_name"=>"New Haven County", "adm2_code"=>"009", "cc_iso"=>"US", "sort_name"=>"MILFORDLAWNS", "sphinx_internal_id"=>2398813, "sphinx_internal_class"=>"City", "sphinx_deleted"=>0, "uni"=>82860535, "lat"=>0.719509, "lng"=>-1.274223}], @configuration=#<ThinkingSphinx::Configuration:0x007fb3d489f848 @common=#Riddle::Configuration::Common:0x007fb3d489f820, @indexer=#<Riddle::Configuration::Indexer:0x007fb3d489f7f8 @mem_limit="2048M">, @searchd=#<Riddle::Configuration::Searchd:0x007fb3d489f7d0 @pid_file="/development/ruby/rails/pre_pilot/proto_postgres/log/development.sphinx.pid", @log="/development/ruby/rails/pre_pilot/proto_postgres/log/development.searchd.log", @query_log="/development/ruby/rails/pre_pilot/proto_postgres/log/development.searchd.query.log", @binlog_path="/development/ruby/rails/pre_pilot/proto_postgres/tmp/binlog/development", @address="127.0.0.1", @mysql41=9312, @workers="threads", @max_matches=2000>, @indices=[#<ThinkingSphinx::ActiveRecord::Index:0x007fb3d0df8d48 @reference=:city, @docinfo=:extern, @options={:with=>:active_record, :delta?=>false, :delta_processor=>ThinkingSphinx::Deltas::DelayedDelta}, @offset=0, @type="plain", @name="city_core"....
ThinkingSphinx::Middlewares::StaleIdFilter.call caught exception #<NoMethodError: undefined method `new?' for #Mysql2::Result:0x007fb3d1e42230>
=> [{"id"=>2398812, "weight"=>55907, "full_name"=>"Milford", "full_name_nd"=>"Milford", "adm1_full_name"=>"Connecticut", "adm1_code"=>"CT", "adm2_full_name"=>"New Haven County", "adm2_code"=>"009", "cc_iso"=>"US", "sort_name"=>"MILFORD", "sphinx_internal_id"=>2398812, "sphinx_internal_class"=>"City", "sphinx_deleted"=>0, "uni"=>82860534, "lat"=>0.719465, "lng"=>-1.275077}, {"id"=>2398870, "weight"=>28338, "full_name"=>"New Milford", "full_name_nd"=>"New Milford", "adm1_full_name"=>"Connecticut", "adm1_code"=>"CT", "adm2_full_name"=>"Litchfield County", "adm2_code"=>"005", "cc_iso"=>"US", "sort_name"=>"NEWMILFORD", "sphinx_internal_id"=>2398870, "sphinx_internal_class"=>"City", "sphinx_deleted"=>0, "uni"=>82860592, "lat"=>0.725656, "lng"=>-1.281219}, {"id"=>2398813, "weight"=>0, "full_name"=>"Milford Lawns", "full_name_nd"=>"Milford Lawns", "adm1_full_name"=>"Connecticut", "adm1_code"=>"CT", "adm2_full_name"=>"New Haven County", "adm2_code"=>"009", "cc_iso"=>"US", "sort_name"=>"MILFORDLAWNS", "sphinx_internal_id"=>2398813, "sphinx_internal_class"=>"City", "sphinx_deleted"=>0, "uni"=>82860535, "lat"=>0.719509, "lng"=>-1.274223}]

continued...
That's as far as I got.
I'm guessing it had something to do with the mysql2 gem but since TS 2.x is working well and this wasn't a critical upgrade for us we had to move on to other things for now.
Thanks for the follow up and the awesome software!

Daniel

No worries - shame it wasn't resolved, but if/when you do go down this upgrade path again, I'd recommend the next step to be recompiling Sphinx and explicitly request both MySQL and PostgreSQL support (I'm guessing you're using PostgreSQL as your database) and see if that helps.

Excellent, thank you for the advice.  I do use Postgres and while I noticed output from configure indicated that mysql was detected, I didn’t specifically enable it so perhaps it wasn’t actually compiled in.  Will check that out the next time I attempt the upgrade.
Thanks again,
Daniel
On Sep 15, 2015, at 2:31 PM, Pat Allan notifications@github.com wrote:
No worries - shame it wasn't resolved, but if/when you do go down this upgrade path again, I'd recommend the next step to be recompiling Sphinx and explicitly request both MySQL and PostgreSQL support (I'm guessing you're using PostgreSQL as your database) and see if that helps.
—
Reply to this email directly or view it on GitHub https://github.com/pat/thinking-sphinx/issues/949#issuecomment-140491994.

authors: danielsettanni pat

repo: pat/thinking-sphinx


text:
Get album cover from files

Currently when adding files the album name and artist are correctly extracted from the files (:+1:). Yet the cover isn't. Would it be possible to add that too?

@mkg20001 why not, should be easy.

That's great! It was strange to have to put a random image on purchased music files.

Nice!

:tada: This issue has been resolved in version 2.2.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

authors: NatoBoram metabinspace mkg20001 negamaxi

repo: pathephone/pathephone-desktop


text:
[README] Build Status Shield Button Not Working

SUMMARY
build status shield button embeds incorrectly, probably because it was copied from github directly... and for some reason their "get badge" feature doesn't actually put valid embed code on your Clipboard.
for more information regarding the github badge issue, see here.
SEVERITY = very low
IMAGE EXAMPLE

Good luck, this was bugging me for a minute with my own repositories.

@zudsniper

fullstack development, server administration, web design, branding creation, musical composition & performance, video editing, and more probably

They deleted Travis-CI for Open Source projects, and they now have Free credits that don't work very well. I abandoned Travis long ago.

authors: jcubic zudsniper


text:
Unensembling

I am enjoying Equinox a great deal and it seems a huge ergonomic improvement over raw JAX in many cases. Thank you for building it!
I am using Equinox to do ensembling in a similar way to docs#ensambling, but I would like to recover an unensembled version at the end. Similar to the example in the documentation, only some of my properties have gotten batch axes while others were 'broadcast'.
Is there an easy way to split the ensemble into a list of models? My PyTree-foo isn't up to scratch.
I realise this is probably not computationally advantageous in most cases, but for the final part of my processing I would like to leave JAX-land and and recover individual models that I can plot and play with.

Yup! Probably something like:
ensemble = eqx.filter_vmap(Model)(...)
models = []
for i in range(ensemble_size):
    models.append(jtu.tree_map(lambda x: x[i] if eqx.is_array(x) else x, ensemble))

Thank you so much for this! Works like a charm. I have modified it slightly to work with arbitrary shapes arising from multiple transformations:
shape = ...
models = []
for idx in np.ndindex(shape):
	models.append(jtu.tree_map(lambda x: x[idx] if eqx.is_array(x) else x, ensemble))

I think it could be useful for others to add this to the documentation under the ensambling section.

Quick question: Would it be viable to add metadata to the fields of eqx.Modules (since these are just dataclasses) with the "vectorisation shape" that could be used to unensamble in a general way? This way it would be easy to split apart vectorised models that have been vectorised across different properties (8 branches varying field x, each of these branches containing 8 nodes varying field y, for example)

I think it could be useful for others to add this to the documentation under the ensambling section.

Sounds good. I'd be happy to take a PR on this.
Indeed this is assuming that all arrays are vectorised similarly. It might be nice if we had a way to record what transformations each leaf has undergone, although I'm not sure how that might work and what that might look like, in a general way.

Quick question: Would it be viable to add metadata to the fields of eqx.Modules (since these are just dataclasses) with the "vectorisation shape" that could be used to unensamble in a general way? This way it would be easy to split apart vectorised models that have been vectorised across different properties (8 branches varying field x, each of these branches containing 8 nodes varying field y, for example)

Could you try do something like this using https://docs.kidger.site/equinox/tricks/#custom-per-parameter-behaviour? You could store the metadata either as another field on the wrapper object (in the above example, Symmetric), or in dataclasses.field(..., metadata=...).

This has not been forgotten – I intend to make a PR for this. I have been working a bit on the latter point of in a eqx.Module subclass which allows for "unensambling" and has to_dict and to_df methods which are proving very convenient.
It relies on the implementation to define a vectorisation_shape property which inspects self and returns the shape of the module as transformed by vmap and pmaps. For modules that have a scalar property, the property can simply look up the shape of the scalar.

authors: JeppeKlitgaard patrick-kidger

repo: patrick-kidger/equinox


text:
feat(parser): adding basic parser

Including chore to add testing and ci.

Welcome to Codecov :tada:
Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.
Thanks for integrating Codecov - We've got you covered :open_umbrella:

authors: codecov-commenter patrickhousley

repo: patrickhousley/streaming-json


text:
Husky consolidation and v5

Traditionally in bubs, we had husky perform two checks:

see if the yarn.lock changed, and if so let dev know they need to run yarn install
set chmod permissions on acf json

Now that we have both wp and wordpress with their own package.json files, we're in a little bit of trouble.
We also want to add in linting as a pre-commit hook on our website folder.
Husky has also updated to version 5 which works a little differently:
https://typicode.github.io/husky/#/?id=usage
My recommendation would be to:

Update to Husky version 5
Remove Susky from wordpress
Have Husky live inside of website

@ccorda I got this error when git pulling one of our projects today:
husky > post-merge hook failed (cannot be bypassed with --no-verify due to Git specs)```

Is this related or should I file a new ticket?

Looks like they're up to 6 now, and hopefully it fixes some of the issues that 5 had. Still leaving us on 4 for now:
https://typicode.github.io/husky/#/?id=migrate-from-v4-to-v6

Up to 7 now: https://github.com/typicode/husky/releases/tag/v7.0.0

authors: ccorda kylehotchkiss

repo: patronage/bubs-next


text:
Dark theme with breadcrumbs

Text only breadcrumb elements will not change the textcolor when using with dark theming.
https://pf4.patternfly.org/components/Breadcrumb/examples/

@RolandTa thanks! This should be fixed in https://github.com/patternfly/patternfly-next/pull/1600

Fixed now

authors: RolandTa mcoker

repo: patternfly/patternfly-next


text:
Button html/css across repos

There are some differences in the implementation of Buttons in pf4 core vs pf4 react.
Since Buttons are inline-block elements, additional space is inserted between the buttons as a result of the white space between the html element, and not styles.
In the react implementation, the white space does not exist between the html elements, and therefore additional css is applied to the react buttons to insert the visual spacing between the buttons, to better match the pf core example.
Ideally, these examples would be identical.

Hi @jgiardino is this issue still relevant? Trying to learn a bit more about this one.

Hi @jgiardino is this issue still relevant? Trying to learn a bit more about this one.

Yes, I checked, and it appears this issue is fixed on the React side so that the spacing matches what we have in Core.

authors: jgiardino rachael-phillips


text:
fix(table): update compact table check box

Fix #1450
.pf-c-table__check is currently set to vertical-align: top. This works for "table with checkbox and actions" / "table expandable" because the checkbox lines up with the expandable arrow and the table columns are wider so it is less likely for the content to wrap more than 2 lines. However in the "compact table" the columns are so narrow that content will wrap over multiple lines - the checkbox set to top alignment looks visually off - note the image in #1450. Setting .pf-c-table__check to vertical-align: middle` for the compact table solves this problem.

Deploy preview for pf-next ready!
Built with commit 3d3cdd42ab2886d7cbcce5e62d28fb6776f6f0c2
https://deploy-preview-1472--pf-next.netlify.com

authors: christiemolloy patternfly-build