text:
Access to request object in register_user_listing_buttons

Is your proposal related to a problem?
In Wagtail 6.1, the register_user_listing_buttons hook signature changed to remove the context.
In migrating one of my sites to 6.1, I realised that one of the the buttons I add to the user listing is an 'Impersonate' button, making use of django-hijack to impersonate a specific user.
This button is implemented like:
class HijackFormButton(UserListingButton):
    def __init__(self, *, user_pk, request):
        self.user_pk = user_pk
        self.request = request
        super().__init__(
            "Impersonate",
            None,
            priority=10,
        )

    def render(self):
        csrf_token = csrf.get_token(self.request)
        return f"""
        <form method="POST" action="{reverse("hijack:acquire")}">
            <input type="hidden" name="csrfmiddlewaretoken" value="{csrf_token}">
            <input type="hidden" name="user_pk" value="{self.user_pk}">
            <button class="button button-secondary button-small" title="Login as this user">{self.label}</button>
        </form>
        """

@hooks.register("register_user_listing_buttons")
def user_listing_hijack_button(context, user):
    yield HijackFormButton(
        user_pk=user.pk,
        request=context.request,
    )

Where the request object is used to generate a CSRF token for the form submission.
With the new hook signature, I don't have a clean way to make the request object available to the button.
I'm wondering what the justification for removing access to the request was, and whether there's any reason it couldn't be added back?
Describe the solution you'd like
Adding a request parameter to the register_user_listing_buttons hook.
Alternatively, a hook for adding a common context to all buttons might be useful - in the above example this could be used to generate a single CSRF token that could be reused between instances, and may be useful for performance optimisations in cases where buttons need to retrieve additional data.
Working on this
I'm happy to work on this once I understand the reason it was removed in the first place to avoid repeating or reintroducing any issues that this caused.

The change happened in #11823

Thanks for the report, and sorry for the trouble! Here's my investigation results.
Rationale
The idea was that I wanted to allow the UserViewSet to be customised, just like the GroupViewSet. From there, overriding the listing buttons would be done by creating a custom subclass of the view and overriding the appropriate methods, e.g. https://github.com/wagtail/wagtail/blob/538365fcfc5ea9135663a1b8c2511c499910e419/wagtail/admin/views/generic/models.py#L375
Then, the custom view subclass would be specified in the custom viewset. This would align better with how we're moving towards the viewsets being the one place to configure your views, instead of individual hooks. It also encourages working with the view directly to do any logic instead of treating the context as a grab-bag and relying on whatever is in it.
Another reason is that, none of the other register_{foo}_buttons (i.e. register_snippet_listing_buttons, register_page_listing_buttons, register_page_listing_more_buttons, register_page_header_buttons) hooks give you the context. Apart from a few small differences (e.g. view_name next_url), they all have one thing in common: passing the row's instance as the first argument, and the request's user as the second. The hook was never documented until #9162 and even after that PR, it had no tests, so I opted to remove the context support in favour of making it more consistent with the other hooks.
In the future, I'm imagining a dedicated/expanded section in the Wagtail docs on how to work with and customise Wagtail's generic views and viewsets, so that it includes things like customising the listing view buttons, and the header buttons (the ones you see in the breadcrumbs). Ideally, the guide would be applicable to all views that are customisable, including ModelViewSet, SnippetViewSet, etc.
Unfortunately, we were short on time and I didn't get to implement the ability to customise the UserViewSet before the feature freeze.

Alternatively, a hook for adding a common context to all buttons might be useful - in the above example this could be used to generate a single CSRF token that could be reused between instances, and may be useful for performance optimisations in cases where buttons need to retrieve additional data.

With the move towards using Component classes (now extracted into the laces library), I don't think this is something we want to do (read https://github.com/tbrlpld/laces#using-the-parent-context for more, um, context).
The preferred way would be to pass anything you need in the button directly to the button's constructor, which makes it more explicit compared to accessing the context (which may or may not have what you want, e.g. due to the use of only keyword when using {% include %} in the templates). Moving the button customisation to the view allows you to pass any information available in the view to the button more easily and explicitly.
Reinstating support for the given customisation
Anyway... back to the issue at hand. I couldn't get the provided example to work as expected in 6.0.x nor 5.2.x. Which version was the latest where this still worked @tomusher?
To make it work, I had to change render to render_html (accepting a parent_context argument) and wrapping the return value in mark_safe():
class HijackFormButton(UserListingButton):
    def __init__(self, *, user_pk, request):
        self.user_pk = user_pk
        self.request = request
        super().__init__(
            "Impersonate",
            None,
            priority=10,
        )

    def render_html(self, parent_context):
        csrf_token = get_token(self.request)
        return mark_safe(
            f"""
        <form method="POST" action="{reverse("hijack:acquire")}">
            <input type="hidden" name="csrfmiddlewaretoken" value="{csrf_token}">
            <input type="hidden" name="user_pk" value="{self.user_pk}">
            <button class="button button-secondary button-small" title="Login as this user">{self.label}</button>
        </form>
        """
        )

@hooks.register("register_user_listing_buttons")
def user_listing_hijack_button(context, user):
    yield HijackFormButton(
        user_pk=user.pk,
        request=context.request,
    )

After the above changes, the hook works as expected on 5.2.x and 6.0.x.
With that out of the way, there are a few things that unfortunately make it tricky to fix this in a 6.1.x patch release with minimal impact. I'll separate this into two steps.
1. Ensuring each button can define how it can render itself
The BaseDropdownMenuButton we use for rendering the ... button in listing views unfortunately render the buttons using a template include directly instead of rendering each Button instance as a component (with {% component %}):
https://github.com/wagtail/wagtail/blob/8aaa579befd1cb9ce829c7301ecffc37912af6a2/wagtail/admin/widgets/button.py#L170-L171
https://github.com/wagtail/wagtail/blob/8aaa579befd1cb9ce829c7301ecffc37912af6a2/wagtail/admin/templates/wagtailadmin/pages/listing/_button_with_dropdown.html#L3
https://github.com/wagtail/wagtail/blob/8aaa579befd1cb9ce829c7301ecffc37912af6a2/wagtail/admin/templates/wagtailadmin/pages/listing/_dropdown_items.html#L3-L10
This means that the Button's render_html (or the "deprecated" render() like in your example) isn't used in the rendering process.
We need to fix this if we want to allow a button to have its own markup. This potentially affects the page listing buttons too, so I'd be wary to do it in a patch release. Might be OK if we're extra careful, though.
2. Passing the request
The hook is now called in the view before the context is finalised by get_context_data:
https://github.com/wagtail/wagtail/blob/8aec935f6962f5c6416dc06c28c6590067e85d45/wagtail/users/views/users.py#L200-L236
As such, we're no longer able to give the full context to the hook. However, we can still include the request. In fact, we pass a RequestContext to support the old signature during the deprecation process, as seen in the code above.
This means that with the fix for (1), the customisation will continue to work using the old hook signature (since request is all you need from the context), but you'll get a deprecation warning due to the signature change.
If we want to use the new signature for the hook, we can't retrieve the request from the parent_context argument in Component.get_context_data/Component.render_html because the "parent" BaseDropdownMenuButton component only specifies the following context: https://github.com/wagtail/wagtail/blob/8aaa579befd1cb9ce829c7301ecffc37912af6a2/wagtail/admin/widgets/button.py#L180-L187
Option A: pass the request via parent_context
If we want the individual child button to have access to the request in the context, we need to include it in the parent BaseDropdownMenuButton's context. So if we add something like "request": parent_context.get("request") to the get_context_data() above, we can achieve the customisation with the following:
class HijackFormButton(UserListingButton):
    def __init__(self, *, user_pk):
        self.user_pk = user_pk
        super().__init__("Impersonate", None, priority=10)

    def render_html(self, parent_context):
        csrf_token = get_token(parent_context.get("request"))
        return mark_safe(
            f"""
        <form method="POST" action="{reverse("hijack:acquire")}">
            <input type="hidden" name="csrfmiddlewaretoken" value="{csrf_token}">
            <input type="hidden" name="user_pk" value="{self.user_pk}">
            <button title="Login as this user">{self.label}</button>
        </form>
        """
        )

@hooks.register("register_user_listing_buttons")
def user_listing_hijack_button(user, request_user):
    yield HijackFormButton(user_pk=user.pk)

I'm not too keen with this, as it goes against the plan of not relying on the parent context. That said, I can accept request as an exception to the rule.
Option B: pass the request directly to the hook
Alternatively, we can also pass the request to the hook directly, either by replacing the request_user parameter, or adding a new parameter. If we do it by replacing request_user, this is a breaking change to a breaking change we already made. If we add a new parameter, it's also going to be a breaking change unless developers update the signature to match (or use *args/**kwargs). We can do this a bit more safely by inspecting the hook's signature with accepts_kwarg or catching any TypeErrors, but that adds noise to the code. Not to mention that this goes against the other register_{foo}_buttons hooks.
Option C: do nothing
Or, as another alternative, we can also skip fixing (2) by saying "if you need the request, you need to use the old signature for now, and disregard the deprecation warning until we have a better way to support the use case".
Thoughts @gasman @zerolab?

Hope I'm not too late to the party here :-)

Ensuring each button can define how it can render itself

As just discussed in https://github.com/wagtail/wagtail/pull/12211#issuecomment-2305832623, supporting items with custom renderings (i.e. not plain links) within dropdowns may be a good thing, or may be opening an enormous can of worms. :-) But I'd like to put forward an alternative: anything that isn't a plain link should remain as a top-level button rather than placed inside the 'more' dropdown. We already carve out an exception for items passed to register_user_listing_buttons that are themselves dropdowns:
https://github.com/wagtail/wagtail/blob/a59a2d0585f9b2ee4ff94152a5de4c66b02819df/wagtail/users/views/users.py#L231-L237
so it wouldn't be a huge stretch to treat this in the same way. In principle we could do this automatically by checking whether the render_html method has been overridden from UserListingButton's default, but that feels like a bit too much magic - I'd be inclined to have an explicit "don't put me inside a dropdown" flag instead.

Passing the request

I would support "Option A: pass the request via parent_context" here. In fact, are we absolutely sure we aren't already doing that? From what I can see, the wagtail.admin.ui.tables.BaseColumn class passes request in the context when rendering cells, and the buttons are rendered within that template using {% component button %}, so it should be coming through in parent_context. Either way, I'm satisfied that that would be an acceptable use of the context and the request object - the CSRF token is a detail of how the button should be rendered on this particular request, and not a detail of what the button is, so it makes sense to pick it up in the render method and not the button constructor.

In principle we could do this automatically by checking whether the render_html method has been overridden from UserListingButton's default, but that feels like a bit too much magic

Checking for render_html wouldn't work for custom buttons that only override template_name/get_context_data anyway, so that's not really an option.

I would support "Option A: pass the request via parent_context" here. In fact, are we absolutely sure we aren't already doing that? From what I can see, the wagtail.admin.ui.tables.BaseColumn class passes request in the context when rendering cells, and the buttons are rendered within that template using {% component button %}, so it should be coming through in parent_context.

While it is true that the column passes request, the ButtonWithDropdown parent component doesn't. We need to ensure ButtonWithDropdown takes the request from the parent context (the Column's context), then we need to ensure Button does the same from its parent ButtonWithDropdown. Conveniently, ButtonWithDropdown is also a subclass of Button itself, so we should be able to just change Button.get_context_data here and have it apply to both:
https://github.com/wagtail/wagtail/blob/84b3bf70349171e44f283085f1d89ccd9deed40e/wagtail/admin/widgets/button.py#L46-L47
Although, this makes me think whether the Laces library should just do this by default in Component.get_context_data() – then, all components get the request for free as long as their ancestors use super().get_context_data(). Then, having request can be opt-out by not using super().get_context_data().

More thoughts on the rest of the listing buttons situation in https://github.com/wagtail/wagtail/pull/12211#issuecomment-2343301068.

authors: gasman laymonage tomusher zerolab

repo: wagtail/wagtail


text:
Large number of SQL queries generated on the Group edit page

As reported here: https://groups.google.com/d/msg/wagtail/dDpi6mup_j4/C9ZDmx11AAAJ
The new logic for permission checkboxes in 1.6.2 (#2966) is apparently resulting in a large number of SQL queries. An initial look through the logs suggests that this is caused by an unusually large number of ContentType records in the database, although the list of models doesn't seem particularly out-of-the-ordinary.

An initial look through the logs suggests that this is caused by an unusually large number of ContentType records in the database

This is quite common if you run migrations with manage.py migrate --noinput as this doesn't clean up stale ContentType records of deleted or renamed models.

Fixed in #3067

source: gharchive/issue

authors: gasman kaedroho

license_type: permissive

license_source: github-api


text:
Pull new translations from Transifex

Submitting as a PR because I've tweaked the sort order logic for the Language Preferences dropdown and want to make sure it's valid across all Python / Django versions...

Merged in 812f1b97ce770c319400468e531fba0535caf0ab

source: gharchive/pull-request


text:
Fix tagged page page copy regression in _copy_m2m_relations

This pull request fixes a regression that was introduced during the https://github.com/wagtail/wagtail/pull/6277 refactor. Currently copying a page that inherits from a page that inherits from a TaggedPage (a page with ClusterTaggableManager) fails with the following error.
ValueError: Cannot add [] (<class 'modelcluster.queryset.FakeQuerySet'>). Expected <class 'django.db.models.base.ModelBase'> or str. when copying a SubBlogPage.
This is because _copy_m2m_relations (source) uses source._meta.parents instead of source._meta.source._meta.get_parent_list().

Thanks for contributing to Wagtail! 🎉
Before submitting, please review the contributor guidelines https://docs.wagtail.io/en/latest/contributing/index.html and check the following:

Do the tests still pass? Yes
Does the code comply with the style guide? Yes
For Python changes: Have you added tests to cover the new/fixed behaviour? Yes
For front-end changes: Did you test on all of [Wagtail’s supported environments] (https://docs.wagtail.io/en/latest/contributing/developing.html#browser-and-device-support)? N/A
For new features: Has the documentation been updated accordingly? N/A

It may also be helpful to see a full broken example. I've created a proof of concept app that is unable to copy.
In this example trying to copy a SubBlogPage will raise the following error.
`ValueError: Cannot add [] (<class 'modelcluster.queryset.FakeQuerySet'>). Expected <class 'django.db.models.base.ModelBase'> or str.` when copying a `SubBlogPage`.

Once I switch to a patched version of wagtail that uses source._meta.source._meta.get_parent_list() all is well.
#
from django.db import models
from modelcluster.fields import ParentalKey
from modelcluster.contrib.taggit import ClusterTaggableManager
from taggit.models import TaggedItemBase
from wagtail.admin.edit_handlers import FieldPanel
from wagtail.core.models import Page

class BlogPageTag(TaggedItemBase):
    content_object = ParentalKey(
        Page, on_delete=models.CASCADE, related_name="tagged_items"
    )

class HomePage(Page):
    pass

class BlogPage(Page):
    tags = ClusterTaggableManager(through=BlogPageTag, blank=True)

    promote_panels = Page.promote_panels + [
        FieldPanel("tags"),
    ]

class SubBlogPage(BlogPage):
    pass

I'm happy to open an issue or make changes if needed. Thank you!

Hi @cspollar. Thank you very much for the thorough write-up and submission - this is high quality stuff :) I just have one suggestion, which might make for slightly easier reading.

Thanks @ababic your change makes sense to me (and the tests still pass).

@cspollar FYI, I raised this in today's core team meeting to see where this can fit in the release cycle. Because this change has been in place for a few versions, it falls out of the usual pattern of deserving it's own release. However, it looks like there are a couple of other things we might want to release next week, and this may be able to slide in alongside those.
Thanks again for such an excellent contribution! I'll let @gasman pick things up from here.

Thanks @cspollar! This fix looks good to me.
It looks like the incorrect parent model logic was also present in the pre-#6277 version of this code, and your test case does indeed fail when run against the 2.10.x branch too, so it seems that this bug isn't a regression - it's basically been around forever... On that basis, this will go through our regular release cycle and be included in the 2.14 release, rather than being backported to existing releases (which are generally limited to regressions, in the interest of not introducing unintended changes).

Merged in c9a55d8b1bf519f97fab32c854b4332f415b5176

@gasman Thanks for getting this merged. I upgraded from the 2.9.x branch (where the tests do pass). It looks like the regression was probably added in the 2.10.x branch. Regardless, I created a fork and will run from there until 2.14 is released. In the future I'll try to keep our version of Wagtail more up to date.

authors: ababic cspollar gasman


text:
fix: change enrtree public key to pattern

Not sure if I escaped backslash properly.
Please test.
See:

https://github.com/waku-org/js-waku-examples/pull/190/files#r1080774184
https://discord.com/channels/1110799176264056863/1111541029309534249/1158771714868658196

I've run prettier locally (unfortunately --list-different on CI doesn't show the problematic code.
And problem appeared to be in the pattern. I've fixed the complaing, but I don't know how to test that pattern works.
@fryorcraken, @danisharora099, please help to test it.

Sorry, what's the problem here?

I don't think there was an issue. Sorted 🙂

authors: fryorcraken yakimant

repo: waku-org/js-waku-examples


text:
refactor tests for new nodes in fleet

This is a change request
Problem
The wakuv2.test fleet seems to now have new nodes which leads to our current tests failing: https://github.com/waku-org/js-waku/actions/runs/5996826077/job/16262051110
Proposed Solutions
Refactor expectations in the tests

Check if we count nodes without duplicates.

repo: waku-org/js-waku


text:
워드 임베딩 사용법

공식 사이트에서 이미 학습된 한국어 버전의 fasttext를 다운받고 사용법을 찾아보았으나 제 이해력이 낮은 것인지 아직도 어디에 어떻게 적용시켜야 되는지 모르겠습니다. 멘토께서 말씀하신대로면 전처리 과정에 포함되는 부분이지만 임베딩에 관해서 도움을 요쳥합니다

네 성능은 좋다고는 하는데, 제 질문은 모델을 어떻게 적용시켜야하는지, 적용하면 어떤 역할을 하는지를 모르겠습니다

현재 댓글을 형태소 단위로 분리 -> 자모 단위로 나누어 적용한다면
FastText로 사용할 수 있을 것 같습니다.
저도 해보지 않아서 잘 모르지만 가능할 것으로 예상합니다.

알겠습니다. 말씀하신 대로 적용하면 될 듯 합니다.

감사합니다.

license: MIT


text:
Shared logging for launcher->worker scenario

Use case -- I run a command on my laptop (launcher machine), it reserves an AWS worker machine, uploads script and runs it there. Later, you want AWS machine environment for metrics, but also want info from launcher machine, ie original command line in order to be able to reproduce the same run.
Right now my approach is to only start wandb on remote machine, manually log things of interest on local machine => pickle => upload to remote machine => unpickle => add to wandb.

Seems like this could be done using restart API instead

repo: wandb/client


text:
[CLI]: wand.save() does not accept pathlib.Path

Describe the bug
This is contrary to how most python libraries work. For instance, it is perfectly fine to pass a pathlib.Path to

open()
torch.save()
numpy.save()
xarray.to_netcdf()
To give just a few examples. Explicitly requiring a string is unexpected and counter-intuitive.

Additional Files
No response
Environment
WandB version:
OS:
Python version:
Versions of relevant libraries:
Additional Context
No response

Hi @sehoffmann, thanks for reporting this! I'll create a new feature request to allow passing a pathlib.Path to wandb.save(), thanks for the feedback!

Hey @luisbergua,
I would like to work on this, can I pick this up ?

Hey @techytushar, great to hear it! Here you have all the steps to contribute, thanks a lot!

authors: luisbergua sehoffmann techytushar

repo: wandb/wandb


text:
某一个时间点Redis主从切换了？

从这个截图中 能得出哪些信息？
Codis-redis服务都在，为什么会主从切换呢？

你的 log 都被处理过了？删了好多东西？

应该没有 log都在的！
上面的log信息我也没看懂什么意思 仅知道group2的主从切换了。

那可能就是显示的问题，proxy.go:338 那一行应该显示的是完整的 json ，但是截图是被截断了的。
前三行 log 里也会再新的一行打印  err 内容，但是也没有。所以能提供完整内容么？而不是截图。
另外，你们是不是用了 HA？否则不会自动进行主从切换。

2015/12/26 13:45:43 backend.go:45: [WARN] backend conn [0xc209f71ac0] to 172.31.16.34:6380, restart [0]
[error]: use of closed network connection
6   /opt/mygo/src/github.com/wandoulabs/codis/pkg/proxy/redis/conn.go:78
github.com/wandoulabs/codis/pkg/proxy/redis.(*connWriter).Write
5   /usr/lib/golang/src/bufio/bufio.go:530
bufio.(*Writer).flush
4   /usr/lib/golang/src/bufio/bufio.go:519
bufio.(*Writer).Flush
3   /opt/mygo/src/github.com/wandoulabs/codis/pkg/proxy/router/backend.go:259
github.com/wandoulabs/codis/pkg/proxy/router.(*FlushPolicy).Flush
2   /opt/mygo/src/github.com/wandoulabs/codis/pkg/proxy/router/backend.go:273
github.com/wandoulabs/codis/pkg/proxy/router.(*FlushPolicy).Encode
1   /opt/mygo/src/github.com/wandoulabs/codis/pkg/proxy/router/backend.go:105
github.com/wandoulabs/codis/pkg/proxy/router.(*BackendConn).loopWriter
0   /opt/mygo/src/github.com/wandoulabs/codis/pkg/proxy/router/backend.go:36
github.com/wandoulabs/codis/pkg/proxy/router.(*BackendConn).Run
... ...
2015/12/26 13:45:43 session.go:70: [INFO] session [0xc20b0a0d80] closed: {"ops":1,"lastop":1451137543,"create":1451137543,"remote":"172.31.240.91:33550"}, error = use of closed network connection
2015/12/26 13:45:43 session.go:58: [INFO] session [0xc209d7ea80] create: {"ops":0,"lastop":0,"create":1451137543,"remote":"172.31.240.91:33552"}
2015/12/26 13:45:44 session.go:58: [INFO] session [0xc20b0a0f40] create: {"ops":0,"lastop":0,"create":1451137544,"remote":"172.31.240.91:33554"}
2015/12/26 13:45:44 session.go:58: [INFO] session [0xc20b0a1000] create: {"ops":0,"lastop":0,"create":1451137544,"remote":"172.31.240.91:33556"}
2015/12/26 13:45:44 backend.go:45: [WARN] backend conn [0xc209f71ac0] to 172.31.16.34:6380, restart [1]
[error]: dial tcp 172.31.16.34:6380: i/o timeout
3   /opt/mygo/src/github.com/wandoulabs/codis/pkg/proxy/redis/conn.go:26
github.com/wandoulabs/codis/pkg/proxy/redis.DialTimeout
2   /opt/mygo/src/github.com/wandoulabs/codis/pkg/proxy/router/backend.go:123
github.com/wandoulabs/codis/pkg/proxy/router.(*BackendConn).newBackendReader
1   /opt/mygo/src/github.com/wandoulabs/codis/pkg/proxy/router/backend.go:91
github.com/wandoulabs/codis/pkg/proxy/router.(*BackendConn).loopWriter
0   /opt/mygo/src/github.com/wandoulabs/codis/pkg/proxy/router/backend.go:36
github.com/wandoulabs/codis/pkg/proxy/router.(*BackendConn).Run
... ...
2015/12/26 13:45:44 session.go:70: [INFO] session [0xc209d7ea80] closed: {"ops":1,"lastop":1451137543,"create":1451137543,"remote":"172.31.240.91:33552"}, error = dial tcp 172.31.16.34:6380: i/o timeout
2015/12/26 13:45:44 session.go:70: [INFO] session [0xc20b0a0f40] closed: {"ops":1,"lastop":1451137544,"create":1451137544,"remote":"172.31.240.91:33554"}, error = dial tcp 172.31.16.34:6380: i/o timeout
2015/12/26 13:45:44 session.go:70: [INFO] session [0xc20b0a1000] closed: {"ops":1,"lastop":1451137544,"create":1451137544,"remote":"172.31.240.91:33556"}, error = dial tcp 172.31.16.34:6380: i/o timeout
2015/12/26 13:45:44 session.go:58: [INFO] session [0xc20b0a1240] create: {"ops":0,"lastop":0,"create":1451137544,"remote":"172.31.240.91:33558"}
2015/12/26 13:45:45 session.go:58: [INFO] session [0xc20b0a1700] create: {"ops":0,"lastop":0,"create":1451137545,"remote":"172.31.241.178:35563"}
2015/12/26 13:45:46 session.go:58: [INFO] session [0xc209d7eec0] create: {"ops":0,"lastop":0,"create":1451137546,"remote":"172.31.240.91:33561"}
2015/12/26 13:45:46 session.go:58: [INFO] session [0xc209d7f180] create: {"ops":0,"lastop":0,"create":1451137546,"remote":"172.31.240.91:33563"}
2015/12/26 13:45:46 backend.go:45: [WARN] backend conn [0xc209f71ac0] to 172.31.16.34:6380, restart [2]
[error]: dial tcp 172.31.16.34:6380: i/o timeout
3   /opt/mygo/src/github.com/wandoulabs/codis/pkg/proxy/redis/conn.go:26
github.com/wandoulabs/codis/pkg/proxy/redis.DialTimeout
2   /opt/mygo/src/github.com/wandoulabs/codis/pkg/proxy/router/backend.go:123
github.com/wandoulabs/codis/pkg/proxy/router.(*BackendConn).newBackendReader
1   /opt/mygo/src/github.com/wandoulabs/codis/pkg/proxy/router/backend.go:91
github.com/wandoulabs/codis/pkg/proxy/router.(*BackendConn).loopWriter
0   /opt/mygo/src/github.com/wandoulabs/codis/pkg/proxy/router/backend.go:36
github.com/wandoulabs/codis/pkg/proxy/router.(*BackendConn).Run
... ...
2015/12/26 13:45:46 session.go:70: [INFO] session [0xc20b913f40] closed: {"ops":3,"lastop":1451137546,"create":1451137541,"remote":"172.31.240.91:33544"}, error = dial tcp 172.31.16.34:6380: i/o timeout
2015/12/26 13:45:46 session.go:70: [INFO] session [0xc20b0a1240] closed: {"ops":3,"lastop":1451137546,"create":1451137544,"remote":"172.31.240.91:33558"}, error = dial tcp 172.31.16.34:6380: i/o timeout
2015/12/26 13:45:47 session.go:58: [INFO] session [0xc209d7f940] create: {"ops":0,"lastop":0,"create":1451137547,"remote":"172.31.240.91:33565"}
2015/12/26 13:45:47 session.go:70: [INFO] session [0xc209d7f940] closed: {"ops":0,"lastop":0,"create":1451137547,"remote":"172.31.240.91:33565"}, error = EOF
2015/12/26 13:45:47 session.go:58: [INFO] session [0xc209d7fa00] create: {"ops":0,"lastop":0,"create":1451137547,"remote":"172.31.240.91:33567"}
2015/12/26 13:45:47 session.go:58: [INFO] session [0xc209d7fbc0] create: {"ops":0,"lastop":0,"create":1451137547,"remote":"172.31.241.178:35565"}
2015/12/26 13:45:47 session.go:70: [INFO] session [0xc209d7fbc0] closed: {"ops":0,"lastop":0,"create":1451137547,"remote":"172.31.241.178:35565"}, error = EOF
2015/12/26 13:45:47 session.go:58: [INFO] session [0xc209d7fc80] create: {"ops":0,"lastop":0,"create":1451137547,"remote":"172.31.241.178:35567"}
2015/12/26 13:45:47 topology.go:150: [WARN] topo event {Type:EventNodeChildrenChanged State:StateSyncConnected Path:/zk/codis/db_codis_proxy_test/actions Err:}
2015/12/26 13:45:47 proxy.go:448: [INFO] got event proxy_1, {EventNodeChildrenChanged StateSyncConnected /zk/codis/db_codis_proxy_test/actions }, lastActionSeq 2092
2015/12/26 13:45:47 proxy.go:351: [WARN] action 2094 receivers [{"id":"proxy_1","addr":"172.31.16.31:19000","last_event":"","last_event_ts":0,"state":"online","description":"","debug_var_addr":"172.31.16.31:11000","pid":15577,"start_at":"2015-12-21 07:24:46.443663029 +0000 UTC"} {"id":"proxy_2","addr":"172.31.16.35:19000","last_event":"","last_event_ts":0,"state":"online","description":"","debug_var_addr":"172.31.16.35:11000","pid":3671,"start_at":"2015-12-21 07:25:39.726384744 +0000 UTC"}]
2015/12/26 13:45:47 proxy.go:338: [INFO] action &{Type:group_changed Desc: Target:{
"id": 2,
"product_name": "codis_proxy_test",
"servers": [
{
"type": "offline",
"group_id": 2,
"addr": "172.31.16.34:6380"
},
{
"type": "master",
"group_id": 2,
"addr": "172.31.16.32:6380"
}
]
}
Ts:1451137547 Receivers:[{"id":"proxy_1","addr":"172.31.16.31:19000","last_event":"","last_event_ts":0,"state":"online","description":"","debug_var_addr":"172.31.16.31:11000","pid":15577,"start_at":"2015-12-21 07:24:46.443663029 +0000 UTC"} {"id":"proxy_2","addr":"172.31.16.35:19000","last_event":"","last_event_ts":0,"state":"online","description":"","debug_var_addr":"172.31.16.35:11000","pid":3671,"start_at":"2015-12-21 07:25:39.726384744 +0000 UTC"}]}
2015/12/26 13:45:47 proxy.go:316: [INFO] group changed 2
2015/12/26 13:45:47 router.go:167: [INFO] fill slot 0848, backend.addr = 172.31.16.32:6380
2015/12/26 13:45:47 backend.go:34: [INFO] backend conn [0xc20a272300] to 172.31.16.32:6380, start service
2015/12/26 13:45:47 router.go:167: [INFO] fill slot 0793, backend.addr = 172.31.16.32:6380
2015/12/26 13:45:47 router.go:167: [INFO] fill slot 0820, backend.addr = 172.31.16.32:6380
2015/12/26 13:45:47 router.go:167: [INFO] fill slot 0568, backend.addr = 172.31.16.32:6380
2015/12/26 13:45:47 router.go:167: [INFO] fill slot 0930, backend.addr = 172.31.16.32:6380
2015/12/26 13:45:47 router.go:167: [INFO] fill slot 0951, backend.addr = 172.31.16.32:6380
2015/12/26 13:45:47 router.go:167: [INFO] fill slot 0553, backend.addr = 172.31.16.32:6380
2015/12/26 13:45:47 router.go:167: [INFO] fill slot 0865, backend.addr = 172.31.16.32:6380
2015/12/26 13:45:47 router.go:167: [INFO] fill slot 0995, backend.addr = 172.31.16.32:6380

恩 我确实用了codis-ha服务 但是后端的redis服务都没有挂 为什么会出现主从切换呢？

HA 已经认定 172.31.16.34:6380 这台机器有问题了。
并且 proxy 连接 172.31.16.34:6380 已经出现了 i/o timeout，这意味着，同一时刻，HA 也可能出现 i/o timeout，而 HA 出现这个情况时，肯定会切换主从。
虽然可能 172.31.16.34:6380 进程还在，但是那个时间可能出现网络异常，导致 proxy 无法访问。所以请确认这件事情。以及 log 里面的内容挺全的。

Redis进程还在 但是codis-ha和codis-proxy认定redis服务问题 类似于这种问题 有没有好的监控手段和方法 或者思路？

没有。
codis-proxy 不关心服务质量，出问题会通过重连恢复连接，但是到重连成功这段时间的所有指令都会出错。
codis-ha 就是通过 ping 来判断服务质量。ha 判定集群出现故障，就会切换主从。如果不希望这么做，或者不信任 HA，那就只能自己监控，自己切换主从。没有其他拌饭。

你用codis-ha的目的是啥？不就是在master redis不可用的时候把其他slave提升为master吗？那无响应的时候切不是正常的吗？

恩 是正常

或许是网络不稳定吧 我的group2中的redis主从都在 但是还是主备切换了。

repo: wandoulabs/codis

license: mit

license_source: bigquery


text:
从redis cluster迁移

@heroliy

有支持 redis cluster 迁移到codis的方法吗？貌似这个不支持

你是如何进行操作的？具体的命令是什么？

抱歉，没有使用redis-cluster 的经验。
我有一个假设：在 redis-cluster 不发生 slot-migration 的情况下，单个 redis instance 就是普通的 redis，每个 redis instance 都可以单独挂 slave。
如果这个假设成立的话，你可以对 cluster 中的每个 instance 都起独立的 redis-port 向同一个 codis 集群迁移数据。在这个过程中，不要动 cluster 的 topo 结构。这样，数据就能完整的迁移过去了。如果假设不成立的话，我也没有别的好的方法了。

repo: wandoulabs/redis-port


text:
🛑 Chatgpt-web_api is down

In 1ea3157, Chatgpt-web_api (https://chat-wceshi.b4a.run) was down:

HTTP code: 502
Response time: 1461 ms

Resolved: Chatgpt-web_api is back up in 687515b.

repo: wang-task/upptime


text:
gui bug

1、0.0.3.6版本，同步策略进行时，进度条不显示
2、批量同步概率不运行，无响应

0.0.4.2版本已解决这些问题


text:
Add support for flow type imports

This adds support for automatically importing flow types
Fixes #12

@ganemone The code seems has been formatted in this commit by prettier

@wangtao0101 Ok - I updated the PR to remove the formatting changes

@wangtao0101 thoughts on getting this merged? Happy to make any more updates you ask for

@ganemone I think we should not check 'src/index' for main entry, maybe you can scan both mainfile in packagejson and 'src/index'

@wangtao0101 I do check both src/index.js and package.json main.  This is actually the way node.js will handle module resolution. See https://nodejs.org/api/modules.html#modules_all_together

Curious what the status is of this PR? I was hunting for a vscode plugin that does auto imports of flow types and ran into this!

authors: albertywu ganemone wangtao0101


text:
两个 pbkdf 文件似乎忘记了添加

$ make
g++: error: lib/pbkdf2-sha1.c: No such file or directory
g++: error: lib/pbkdf2-sha256.c: No such file or directory

确实，已经加上了。thx


text:
Move between requests with keyboard

Another important feature that's currently missing.

This has been worked on and will be released soon.
https://github.com/warrenday/graphql-network-inspector/pull/18

repo: warrenday/graphql-network-inspector


text:
dateutil could not be imported + "connection error"

i originally got an error on startup, and the log indicated that dateutil could not be imported; a quick apt-get install python-dateutil fixed that. but now, the plugin says "connection error" and im receiving this in the logs:
22:09:34 T:140208712439552   DEBUG: CPythonInvoker(3, /home/xbmc/.kodi/addons/pl
ugin.audio.subsonic/main.py): entering source directory /home/xbmc/.kodi/addons/
plugin.audio.subsonic
22:09:34 T:140208712439552   DEBUG: CPythonInvoker(3, /home/xbmc/.kodi/addons/pl
ugin.audio.subsonic/main.py): instantiating addon using automatically obtained i
d of "plugin.audio.subsonic" dependent on version 2.14.0 of the xbmc.python api
22:09:34 T:140208712439552   DEBUG: plugin.audio.subsonic: <Plugin ['plugin://plugin.audio.subsonic/', '1', '']>
22:09:34 T:140208712439552   DEBUG: plugin.audio.subsonic: Actions: ['list_artists', 'list_tracks', 'list_playlists', 'download_item', 'play_track', 'star_item', 'list_albums', 'menu_tracks', 'root', 'menu_albums']
22:09:34 T:140208712439552   DEBUG: plugin.audio.subsonic: Called action "root" with params "<Params {}>"
22:09:35 T:140208712439552   DEBUG: plugin.audio.subsonic: Action return value: None
22:09:35 T:140208712439552   DEBUG: plugin.audio.subsonic: The action "root" has not returned any valid data to process.
22:09:35 T:140208712439552    INFO: CPythonInvoker(3, /home/xbmc/.kodi/addons/plugin.audio.subsonic/main.py): script successfully run
22:09:35 T:140208712439552    INFO: Python script stopped
22:09:35 T:140208712439552   DEBUG: Thread LanguageInvoker 140208712439552 terminating
22:09:35 T:140208704046848   DEBUG:  WaitOnScriptResult - plugin exited prematurely - terminating
22:09:35 T:140210960373760   ERROR: GetDirectory - Error getting plugin://plugin.audio.subsonic/

i should also note that i originally had basilfx's plugin installed, which i removed from kodi before adding your repo, so the old settings file may be in use. not sure if that matters to this alternate version...

It is weird you had ton install python-dateutil manually since it is declared as dependency in the plugin's addon.xml...
The "connection error" message appears when no internet connection is detected, are u sure you had this when you were conneted ?
Also and probably the most important : what is your OS, plugin and Kodi versions ?

Also got the ImportError on the dateutil.parser, running a fresh OpenElec 6.0.3 om an Pi3.

I'm getting the same error on Win7.  Installed dateutil with pip install python-dateutil which completes successfully but I still get the same fault.

I believe I may have tracked down the error; tomcat stopped on my server somehow, meaning that subsonic was inaccessible! ill retry once i get home.
the client is running latest kodi on xubuntu 16.04
the server should be agnostic, but tomcat 7 and centos 6.

I had to manually install dateutil as well.  Once that was completed, everything worked.

What is your Kodi version please ?

OpenElec 6.0.3 uses Kodi 15.2

Okay;
Let's see if it still occurs with Kodi 17...  I would like to avoid to fix this for old Kodi versions :)

I just updated to OpenElec 7.0.0 with Kodi 16.1 final. Starting the subsonic plugin brings the following error:
21:46:50  75.599861 T:1963991040   ERROR: GetDirectory - Error getting plugin://plugin.audio.subsonic/
21:46:50  75.600136 T:1963991040   ERROR: CGUIMediaWindow::GetDirectory(plugin://plugin.audio.subsonic/) failed
21:46:57  82.932899 T:1534055328   ERROR: EXCEPTION Thrown (PythonToCppException) : -->Python callback/script returned the following error<--
- NOTE: IGNORING THIS CAN LEAD TO MEMORY LEAKS!
Error Type: <type 'exceptions.ImportError'>
Error Contents: No module named six
Traceback (most recent call last):
File "/storage/.kodi/addons/plugin.audio.subsonic/main.py", line 15, in
import dateutil.parser
File "/storage/.kodi/addons/script.module.dateutil/lib/dateutil/parser.py", line 40, in
from six import text_type, binary_type, integer_types
ImportError: No module named six
-->End of Python script error report<--
I'm afraid it will take ages before OpenElec switches to Kodi 17, as this is the a very recent update. :-/

I'm running the latest version of Jarvis. I had been installing the plugin by dropping it in the add on folder and I would get the dateutil error.
When I installed from zip everything worked just fine.
Sent via the Samsung Galaxy Mega™, an AT&T 4G LTE smartphone
-------- Original message --------From: Marius van Herpen  Date:01/03/2017  3:56 PM  (GMT-05:00) To: "gordielachance/plugin.audio.subsonic"  Cc: philvt101 , Comment  Subject: Re: [gordielachance/plugin.audio.subsonic] dateutil could not be
  imported + "connection error" (#5)
I just updated to OpenElec 7.0.0 with Kodi 16.1 final. Starting the subsonic plugin brings the following error:
21:46:50 75.599861 T:1963991040 ERROR: GetDirectory - Error getting plugin://plugin.audio.subsonic/
21:46:50 75.600136 T:1963991040 ERROR: CGUIMediaWindow::GetDirectory(plugin://plugin.audio.subsonic/) failed
21:46:57 82.932899 T:1534055328 ERROR: EXCEPTION Thrown (PythonToCppException) : -->Python callback/script returned the following error<--

NOTE: IGNORING THIS CAN LEAD TO MEMORY LEAKS!
Error Type: <type 'exceptions.ImportError'>
Error Contents: No module named six
Traceback (most recent call last):
File "/storage/.kodi/addons/plugin.audio.subsonic/main.py", line 15, in
import dateutil.parser
File "/storage/.kodi/addons/script.module.dateutil/lib/dateutil/parser.py", line 40, in
from six import text_type, binary_type, integer_types
ImportError: No module named six
-->End of Python script error report<--

I'm afraid it will take ages before OpenElec switches to Kodi 17, as this is the a very recent update. :-/
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Got it!
After lots of searching, I found http://mirrors.kodi.tv/addons/jarvis/script.module.six/ and installed it manually. It now works. Now how to point it to my own server. :-)

The dateutil dependency author says that
That's a known problem of the krypton beta. So please wait for the next beta or final. Or install this from zip file.
So I guess this is not related to the Subsonic plugin.

I've been using a previous version of the plugin by Basilfx for some time and am trying to upgrade ...
I have installed the plugin as directed (Navigate to your .kodi/addons/ folder | Clone this repository: git clone https://github.com/gordielachance/plugin.audio.subsonic.git | (Re)start Kodi.) and I had the "dateutil could not be imported" error.
After a lot of trial and error, I've decided to install the plugin in a more traditional way, using KODI interface and "install from ZIP file". Bingo !! It does not give me this error anymore!   Please correct the installation directions for the next users!
But now, I'm getting a "Connection error!".  Any info I should provide to you to get help ?
BTW - I love this plugin!  Thanks,
André

I found the problem !!
In my addon configuration, the Server Url is : "http://MyServeName:7080/subsonic".  In the file libsonic/connection.py, I found this:
class Connection(object):
    def __init__(self, baseUrl, username=None, password=None, port=4040,
            serverPath='/subsonic/rest', appName='py-sonic', apiVersion=API_VERSION,
            insecure=False, useNetrc=None, legacyAuth=False, useGET=False):

The path that is in the configuration is not used, and is simply replaced by "/rest". "/rest" should be ADDED to the path in the configuration, if present.  I've made a small patch by hard-coding my path, and everything works flawlessly.  My programming skills are quite limited in Python, so I'll let you make the correction.
Merci, et ne lâchez-pas !!!
André

Hi, it's not yet merged; but could you try the 2.0.8 branch and tell me if it works for u ?
https://github.com/gordielachance/plugin.audio.subsonic/tree/2.0.8
Thanks !

Hi, Gordie!  I will try to get some testing done.  At the moment, I'm not
even sure that I have a Kodi system running.  It shouldn't be too hard to
get one set up, though.  It looks like a busy weekend, so it may be a few
days.
Did you try testing it with my Subsonic library?  The credentials that I
gave you should still work.
Jim
On Fri, Dec 1, 2017 at 5:55 PM, gordielachance notifications@github.com
wrote:

Hi, it's not yet merged; but could you try the 2.0.8 branch and tell me if
it works for u ?
https://github.com/gordielachance/plugin.audio.subsonic/tree/2.0.8
Thanks !
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/gordielachance/plugin.audio.subsonic/issues/5#issuecomment-348635980,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AXrprVlMisP7N2qgIyBAFkflNLTml6cLks5s8IPVgaJpZM4KeB1f
.

Same issue here with the instructions from the README. apt-get install python-dateutil worked though!
Thanks for the work on this nice addon!

The instructions in the readme are wrong. If you simply download the latest release from GitHub and then in Kodi select Install from zip, it will automatically install the required dependencies (dateutil).
Simply copying the folder to addons will not work, unless you install dateutil manually.

Closing this issue.
The comment above is still valid for some versions.
**The instructions in the readme are wrong. If you simply download the latest release from GitHub and then in Kodi select Install from zip, it will automatically install the required dependencies (dateutil).
Simply copying the folder to addons will not work, unless you install dateutil manually.**

authors: Harteex JimGilliland Phyks andrelx ch604 gordielachance langtall philvt101 warwickh


text:
[BUG] Unable to redeploy the same application after deletion

Describe the bug
I've encountered a fairly frustrating issue with the wash CLI. Once an application is deleted, it appears that the same application cannot be redeployed.
To Reproduce

Begin with a fresh wasmCloud installation as outlined in the documentation.
Execute wash up in one terminal.
Create a new actor with wash new actor hello.
Deploy the app using wash app deploy wadm.yaml.
Delete the app with wash app del hello v0.0.1.
Attempt to redeploy the same app using wash app deploy wadm.yaml.

Following these steps results in an error: Could not put manifest to deploy. Internal storage error.
In addition, I noticed a warning message: [warning] Failed to look up link definition with ID EE5DDC.... It also appears that link definitions are not being automatically removed upon app deletion.
Interestingly, I found that after rebooting the machine, the same app could be redeployed. I checked the /tmp directory but found no relevant files or data. This suggests that the loaded configuration might only be appending to memory and is not being refreshed properly.
Environment

OS: Ubuntu, MacOS
Shell: zsh
wash Version 0.19.1

Sorry for the frustration @xpepermint. So this was a bug in wadm (https://github.com/wasmCloud/wadm/issues/129) and is fixed, but the latest version of wadm will fix this. The default in wash is 0.4 and that is the one that has the bug
In the meantime, you can use --wadm-version flag to use the latest alpha version: https://github.com/wasmCloud/wadm/releases/tag/v0.5.0-alpha.2

repo: wasmCloud/wash


text:
[DOCS] Incorrect app name in the wash app delete command

At the bottom of the Deploying the Application section in the quickstart guide, the command to delete the app that's listed is:
wash app delete hello-world

However, at least for the tinygo version of this guide, the name of the app is tinygo-hello-world, as seen here: https://github.com/wasmCloud/wasmCloud/blob/9d1d0a43a3027bdd55e683d9345177e5277bc2e9/crates/wash-cli/tests/fixtures/old-examples/http-hello-world-go/wadm.yaml#L4.
So in order to properly delete the tinygo version, it should be:
wash app delete tinygo-hello-world

Looks like the rust version is also prepended: https://github.com/wasmCloud/wasmCloud/blob/9d1d0a43a3027bdd55e683d9345177e5277bc2e9/crates/wash-cli/tests/fixtures/old-examples/http-hello-world-rust/wadm.yaml#L4.
I'd suggest renaming these to a generic hello-world so that the shell command listed above is accurate.
I'm happy to contribute if you like.

Found the typescript yaml for quick access: https://github.com/wasmCloud/wasmCloud/blob/9d1d0a43a3027bdd55e683d9345177e5277bc2e9/examples/typescript/components/http-hello-world/local.wadm.yaml#L5


text:
MMALPythonPort does not support MMAL_ENCODING_H264 and MMAL_ENCODING_MJPEG

Hi Dave,
first of all: thank you for this excellent peace of work!
By writing a h264 decoder I tried to use MMALPythonSource as simple method to create a source stream for the decoder pipeline.
I think I found 3 different errors (or may be I just used it wrong...)

Both video formats are not included in the supported_formats property of the MMALPythonPort class. (I added them manually in my installation to dig deeper in the stuff)
The copy_from() helper raises an error. (may be I added the formats not correctly) source.outputs[0].connect(decoder.inputs[0]) raises an error when source.outputs[0].format is not set explicitly.
source.connection.enable() is not supported.
MMALPythonSource.send_buffer() is raising: PiCameraMMALError(mmal.MMAL_EAGAIN, 'no buffers available')

Thank yo for any help!
Here my code I used for testing:
mmal_h264_decoder_example.py.txt

Both video formats are not included in the supported_formats property of the MMALPythonPort class. (I added them manually in my installation to dig deeper in the stuff)

Yup, that's quite deliberate. The MMALPythonSource class is intended as a base class for Python code that produces "something". I've no way of knowing what, so it's up to the developer to override this in their sub-class with something accurate for their source (e.g. H.264). I should make the docs on this a bit more clear (the mmalobj docs are still way too low level for serious usage).

The copy_from() helper raises an error. (may be I added the formats not correctly) source.outputs[0].connect(decoder.inputs[0]) raises an error when source.outputs[0].format is not set explicitly.

I'm afraid the rest of this stems from not quite understanding how to use mmalobj; I definitely need to improve the docs in this area with some examples and recipes. Now I've finally got a couple of weekends coming up to work on 1.14 I'll try and squeeze this in.

@barney-NG does it play incredibly fast for you as well?

yes.
Dave told me that I didn’t understand the mmal stack  — he’s right :-)
Cheers

authors: barney-NG moritzschaefer waveform80


text:
Use default text component in full player time markers

Removing custom styles on time markers to be consistent with the rest of the app

the styles are like this on purpose though. the regular text is not monospaced, so it makes the text jittery.

Noted. Looks like using Helvetica from the iOS system fonts looks good enough.

authors: SamSamskies blastshielddown

repo: wavlake/mobile


text:
The future of wlc

Hey there,
I am currently working on fireplace as some of you might now, and I also guess most of you know about sway and track its status as well, because it is the most popular and feature complete compositor build upon wlc.
Recently sway decided to switch to an in-house compositor and so far there are no guarantees, that their new compositor will be usable completely independently from sway, if it can be dynamically linked and if we may be able to write rust bindings as a direct result of it.
wlc will of course still exist, but its situation is already complicated, although sway is making use of it as well and maintenance is kept at a bare minimum to keep it functional. I honestly expect this situation to get even worse, once sway has made that transition.
As a result, I am thinking about switching the compositor library as well for fireplace. Current alternatives I see are:

Writing bindings for libweston (it seems quite usable, but more investigation is necessary)
Rewriting wlc in rust. Because this is quite the huge undertaking, I would suggest translating the original wlc library with corrode, fixing the result until it can be used as a direct replacement and then gradually re-write parts of it, writing bindings where required on the way and replacing certain libraries with the rust ecosystem.

I personally don't think wlcs design is overly complicated, it is clearly structured, the biggest difficulty comes from the inherently complex things wlc does.
That said I am in favor of using libweston (if possible) instead of maintaining another project.
The reason, I am bringing up this issue here, should be fairly obvious. way-cooler will be influenced by sway's decision as well and I wanted to suggest to join forces on finding and writing a suitable replacement. What do you think?

Hey there, thanks for reaching out.
You have a done a good job enumerating our options. I also agree that we should not necessarily make a rust fork of wlc. While it would be easier to transition Way Cooler over to something like that, it would be a bad decision in the long run.
Another alternative is to go the sway route and integrate our own compositors. I do not think this is the correct solution, I think that the future of non mainstream window managers (eg non Gnome/KDE) is to use libraries like Libweston and wlc so that they all get the benefits.
Taking a look at that tutorial (I've never looked at Libweston) it looks to be a less abstracted wlc (no longer are there callbacks, and we use most Wayland object directly). We should make sure that it is possible to use the Wayland client libraries that @vberger has made. I know when trying to work with it in the past there were issues due to the user data that both wlc and the Wayland rust libraries need to use.

I have also found libweston-desktop, browsing though their sources, which seems to abstract a lot of the xdg-shell functionality in addition to libweston. This looks quite usable, as you said, basically wlc with wayland types.
I have also noticed @vberger has started/planned a similar project, although this does not seem to be based on libweston, but rather a new take on something like wlc, just in Rust.
I am still in favor of creating libweston bindings, as far less maintenance work would be required to keep up with the upstream changes.
Maybe @vberger can provide some information on why he started smithay? Is it more an educational project or is there a reason libweston would not make a good/idiomatic rust library?
From what I've seen his wayland implementations looks quite stable at least design-wise and the user_data problem was also addressed recently.

Interesting, I had not seen that project he started. I'd be interested in hearing why he is doing it too.
I also agree that going with Libweston seems to be the better way to go.
Nice to hear those user data issues were fixed though

Looking at orbment when I read https://github.com/Cloudef/orbment/issues/141#issuecomment-227720157 and does not look like wlc is over-complicated as much as it is all the things really in wayland. Anyone find compositor using libweston? only I find is https://github.com/gschwind/libweston_tutorial . @cloudef mention https://github.com/letoram/arcan/wiki , did he check more? http://durden.arcan-fe.com/ seem very complete. Then https://github.com/michaelforney/swc also looking like it is developed still.

Then https://github.com/michaelforney/swc also looking like it is developed still.

I had my first tries with swc back almost 2 years ago and that point it's development had stalled and many advertised features were broken. Although development has happened very recently, it hasn't even made the transition to the xdg-shell-v6 protocol and is still using v5. I would not expect libswc to become a more viable alternative to what wlc currently provides in the near future. Although I certainly hope I am wrong. The more options the better.

Although I certainly hope I am wrong. The more options the better.

I agree with @Drakulix, the more frameworks right now that try to achieve what wlc could not (and maybe libweston does) is good. From the bazaar, we will eventually center a round a few good frameworks to use for this.

Looking at orbment when I read Cloudef/orbment#141 (comment) and does not look like wlc is over-complicated as much as it is all the things really in wayland.

I agree, though I think that this complexity can be managed.
Yes, in it's current form Wayland compositors are in a tough place: they need to implement a lot of functionality. However, my hope is that libraries like wlc was meant to be and what libweston might become will become the norm for implementing window managers. wlc was a hobby project that wasn't designed to handle all the complexities that he listed (and that's fine).
Because libweston is from the Wayland devs, and Weston relies on it it is more likely to get these features that window managers shouldn't worry about. There doesn't seem to be any other "real" window managers implemented in it, but I think that has to do with how new it is rather than any indication on the quality of the library itself.

There doesn't seem to be any other "real" window managers implemented in it, but I think that has to do with how new it is rather than any indication on the quality of the library itself.

Right. libweston was only recently split from weston itself. Long after GNOME and KDE did start to provide wayland support. Its understandable that nobody has picked it up yet.

So it seems libweston is the way to go. We should attempt to set it up similar to how you did wlc.rs @Drakulix, with a libweston-sys as the bindgen and a wrapper above it providing safe bindings. Where should the project live, under your namespace or ours? Since it's just bindings, there won't need to be as much maintenance so it doesn't really matter to me.
You did a good job designing the abstractions for wlc, so perhaps you should spear-head the design if you'd like. I'd be more than happy to help you work on it. Once it's built we can begin moving over our respective window managers to libweston.

Here are the main (technical) things that suck about wlc and can maybe act as advice for other peoples dwelling into writing similar library.

Avoid immediate calls.
One problem in wlc is that it tries to process everything immediately. This ruins performance as events and calls are not being throttled, it can easily also cause recursion when calling back into wlc from callback. As a alternative make more use of the event-loop that is required anyways (if using libwayland), or defer calls to stack from which they will be popped later (as bonus the stack can act as valuable replay / debugging resource). This also simplified handling of cases where something should be done only after next wayland display dispatch (many keyboard, focus related issues on wlc would be fixed).

Datastructures could be generated from wayland specifications.
wlc has lots of code written by hand that could've been generated from protocol specifications. The wayland-scanner merely offers you callbacks, but most of time you also want to store the data given from these callbacks somewhere.

Few ideas I had in mind during development:

Make wlc a wayland protocol, which only privilidged process (wm) can use. (Thus being like xserver)
Generate all control flow from finite state machine representation.

libweston should be a safe bet since it is maintained by wayland / weston developers.

You did a good job designing the abstractions for wlc, so perhaps you should spear-head the design if you'd like. I'd be more than happy to help you work on it. Once it's built we can begin moving over our respective window managers to libweston.

Thank you very much. I will open a repository later today and add you as a contributor. Anybody else working on way-cooler is also welcome, just ping me and I will add you.
I might take some days until I add anything reasonable to the repository, I am a bit busy with exams in the next week, but other than that I am looking forward to this project.
Also huge thanks @Cloudef for your insights.

I might take some days until I add anything reasonable to the repository, I am a bit busy with exams in the next week, but other than that I am looking forward to this project.

Same, I should have some time this weekend though so I'll try and stub out at least the basic bindings.

I'm interested in Wayland and may have some time coming up, please add me so I can help!

I have opened a repository and added you two. I currently does not compile, but provides a starting point.
Please use branches and pull requests and let us all review our changes before pushing them to master.
If you have some questions about the overall design feel free to experiment, but open an issue for discussion. Any further discussion about the project may be done in the repository itself.

I see I've been pinged here regarding my very new project smithay. Let me then give you more details about it. :)
About compatibility of wayland-server with wlc/libweston
First of all, regarding the question of compatibility between my wayland bindings and other libs like wlc and libweston, the recent PR I made adding an user_data mechanism does not fix it. The core idea is that my bindings use the user_data mechansim from libwayland-{client,sever}.so to store metadata about the Proxy/Ressources and ensure safety from Rust point of view. An important goal of my bindings was to provide a safe API, and I can't see how to do this without using the user_data.
Now, internally, wlc and libweston also use the user_data field to do their logic. Actually, I recently realized this is almost indispensable, thiw is why I added a similar mechanism on my bindings. But this is a new user_data API built on top of the original C one. It is not compatible with it at all.
Why smithay
As a consequence of it, my bindings cannot be used in conjuction with a C library using this user_data, so basically any lib taking a large control over the program workflow, lib wlc or libweston. This is part of my motivation for smithay: providing a library filling the functionnalities of wlc/libweston, but in Rust, and built on top of my bindings, so hopefully mostly safe-rust.
An other, more personal motivation, is principally intellectual interest. I find this project interesting. But I am well conscious of a particular difficulty of these kinds of libraries: they cannot be built out of nowhere, without being driven by a concrete project (to ensure the API design choices are actually usable). This is mostly why I've implemented the wayland backend of glutin: as a way to ensure my client bindings (and the helper crates wayland-kbd and wayland-window) were properly designed.
Now, I don't have a compositor project in my hat, so needless to say, regarding this, if anybody is interested into building a compositor on top of smithay, I'd be very enthusiast about it! But smithay is also basically empty for now. I'm still figuring out the proper design. And my lack of experience in writing wayland compositors at large does not help.
smithay's design
I think my target design will be quite different from wlc (I don't know about libweston) but probably much more rusty. I plan to build on top of wayland-server's design: the binding crate provides an abstraction for the event loop, the user then provides a set of Handlers, which are structs implementing traits from handling the various client requests (you can think of it as fancy closures provided as callbacks).
The core modularity approach is composition: handlers are composable. For example, wayland-kbd abstracts over wl_keyboard::Handler and require the user to provide a wayland_kbd::Handler instead, which is an higher-level API that the pure wayland one.
Now I plan to plug smithay into this in a very simple way. It should provide:

basic primitives to interacting with the underlying platform (initialize a tty, the link with mesa, libinput, etc...) (this will maybe be done as a set of small independent crates, using smithay as an umbrella)
pre-implemented Handlers simplifying basic functionality that will probably be very common across compositor design

But importantly: it reuses wayland-server's event loop, and does not abstract over it. The user is still responsible for setting it up and running it. The goal in this choice, is that smithay should then be modular: you can use only what you want for it. If you want to plan a very specific design for handling some kind of client requests, just don't use the provided Handler and write your own.

That's my idea with all this for now. As I wrote, I'm still thinking over the overall design of smithay. To kickstart the thing, I'm trying to re-implement the SHM helpers from libwayland-server.so, that also cannot be used with wayland-server due to this user_data issue. You can see the work in progress here: https://github.com/vberger/smithay/tree/shm_handler
Hopefully this answered your questions, @Timidger @Drakulix ?

As a TL;DR: if you want a  working replacement for wlc ASAP, libweston is certainly the best route.
If you're willing to invest time in helping me design smithay, I'd love it (and this is basically the thing I'm looking for). But I know it's a quite long shot, and maybe not an option you're willing to follow.

Some very interesting information.
I would love to switch to smithay at some point, but I have some reservations about it:

first its quite a long shot as you pointed out and I do not know if wlc will be enough for the meantime, I doubt it
second although I bet we all can learn from mistakes that were already made, we are then replacing wlc with something very similar. A rather small hobby project, which will need time to mature and might never be reach the compatibility libweston would provide.

On the other side, I really like the design of your project, I have gone a very similar route in fireplace. I took the basic abstraction wlc provided, used the specialization feature to provide default implementations for them to make them composable and wrote a bunch of rather small handlers providing a complete compositor together. That fits nicely.
I am really in to minds about this. I would like the result of fireplace+smithay much more, once it is done and everything works. But using libweston is a much easier and more maintainable transition.
Also I dont want to switch the framework to often for obvious reasons.

While I lament the loss of using your bindings, I think the best decision for us is to use Libweston. It's already at a mature state, and is very likely to be maintained in the future.
Good luck with smithay, I hope someday that there will be a nice stack for a Rust Wayland window manager to use.

@vberger When smithay matures, please feel free to ping me and I might try to get the minimal required codebase of fireplace ported over. If I will ever do the transition will mostly depend on the state of smithay and I do not enough a lot of time and the required knowledge to contribute much code, but I am more willing to provide feedback to you.
In the meantime, lets focus on libweston. Its not bad to have choice and I also want something reliable in the near future.

I think you're making the wise decisiong by focusing on libweston. I really cannot give you any guarantee about when smithay will be ready.
However, give it seems to interest you nonetheless, I hope I can ping you if I have questions regarding smithay's design possibilities. Your experience in writing compositors would certainly be very helpful!

Hi, I'm the BDFL over at Sway. I have two thoughts to share in this thread:

If you guys want to collab on a wlc replacement I'm down
I've evaluated libweston several times over the past year or two and have concluded every time that it's not the right call. I can expand on this if you'd like. I think you would be wiser to invest in something like smithay. You should always trade immediate gain for a better solution in the long run. Who cares if it's done in 6 months or in 2 years? This is my approach to Sway.

Also, note that the points I raise over at https://github.com/SirCmpwn/sway/issues/1076 are discussion points, not decisions. If you're interested in collaborating on this and changing some details would suit your needs, please bring it up for discussion.

@SirCmpwn
I would really like to hear your thoughts on libweston.
Building a solid foundation is what I want and with limited man power libweston looked like a good choice, but I have not investigated enough into it to call this a fixed decision and if we all develop something together building something completely new becomes a very doable project.
Obvious questions, since most of the people participating here were expecting to write something in rust. Would you rather prefer C and if yes for what reasons? There is no problem in wrapping the C library for Rust, neither is there a problem providing a C API from a rust library, its just that wlc did a pure job fitting with Rust's memory model, as it was not designed with that in mind and the easiest way to avoid that (and in return gain some safety guarantees) is to use rust in the first place. But I would most likely also join a C project as long as something usable and maintainable is the end result.

Building a solid foundation is what I want and with limited man power libweston looked like a good choice, but I have not investigated enough into it to call this a fixed decision and if we all develop something together building something completely new becomes a very doable project.

libweston has a number of problems, in no particular order:

The codebase is generally pretty bad. It's has good performance but the actual code is pretty terrible.
It has a lot of questionable opinions like desktop-shell.xml that you will inherit with it
Weston design choices bubble up to libweston too, like the config parser, keybindings, etc. It does too much.
The API is poorly designed and basically just exposes internal weston headers to libweston users and hopes they'll read around the implementation details
Working on libweston involves collaborating with weston developers, which is... not something I would look forward to

I had more reasons but they don't come to mind at the moment. IMO weston is best suited as a reference compositor and not a practical one.

Obvious questions, since most of the people participating here were expecting to write something in rust. Would you rather prefer C and if yes for what reasons? There is no problem in wrapping the C library for Rust, neither is there a problem providing a C API from a rust library, its just that wlc did a pure job fitting with Rust's memory model, as it was not designed with that in mind and the easiest way to avoid that (and in return gain some safety guarantees) is to use rust in the first place. But I would most likely also join a C project as long as something usable and maintainable is the end result.

You can probably guess that I would prefer C. I have some personal objections to Rust as a programming language that aren't relevant for this thread. I feel that choosing C will lead to better a tighter product (this goes back to my unspoken objections to Rust), better portability, and faster development. For one thing, we can mobilize the small army of Sway contributors in this direction if C is used. I have some strong opinions about C that lead to, among other things, safer C code that's easy to write API wrappers for. I'm not concerned about Rust interop being an issue, especially with a contingent of contributors maintaining a Rust wrapper to integrate with way-cooler and policing the API themselves.
It's unlikely that any effort in Rust is going to be integrated with Sway. The interests of the projects would just be too divergent. If a wlc replacement were written in Rust, it would be better to expose an idiomatic Rustful API for way-cooler to use, and such an API would not integrate cleanly with Sway. No hard feelings if you want to go with a Rust solution - but the hard truth is that using such a solution would probably be bad for Sway. I think both projects and the greater ecosystem would benefit from a shared base, though, so we should consider a C solution carefully.
Unrelated, I object to forking wlc or converting wlc to Rust with that one tool. A greenfield effort would probably turn out better.

The API is poorly designed and basically just exposes internal weston headers to libweston users and hopes they'll read around the implementation details

I had this impression when looking through the public api and did hope this is just some wayland stuff, they did not want to wrap. Too bad..

Working on libweston involves collaborating with weston developers, which is... not something I would look forward to

My hope was not having to work with any of them, because it is the reference implementation, meaning it should work the best, although most likely not perfectly. Did you already have some bad experiences? This sounds like it.

You can probably guess that I would prefer C. I have some personal objections to Rust as a programming language that aren't relevant for this thread.

I already expected that, so no worries. Not every language is for everybody and not every language suits every use case, although I certainly think it would fit this specific one and could be a tight product.
Portability especially with a few BSD-users you have, might actually be an issue and fast development comes mostly down to the amount of C libraries you would need to use, but I give you that point as well.
In case you are interested, I have had quite some experience with C and Rust, if you ever have interest in talking about your opinions or giving the language another chance, but don't know where to start, feel write to write me.

Unrelated, I object to forking wlc or converting wlc to Rust with that one tool. A greenfield effort would probably turn out better.

I would also prefer that, but this brings up the time issue again, which mostly exists because you already have quite advanced plans for your compositor and I had the feel, that we needed to leave the sinking ship asap, if I want to keep using my own compositor.
I am quite happy I got to this point, but the whole wayland ecosystem is moving really fast, xdg-shell-v6 did show how quickly things may break, if something like wlc is not maintained enough.
Developing together with you would of course avoid that problem, as we would probably do the transition together or in quick succession.

I think both projects and the greater ecosystem would benefit from a shared base, though, so we should consider a C solution carefully.

I approve this. The more is build upon it, the more contribution will happen and the more stable and tested the code base will become.

I have some strong opinions about C that lead to, among other things, safer C code that's easy to write API wrappers for.

I would like to hear about this, maybe you have already written something like this in sway contribution guide if something like this exists? If I can see that your project is well suited for my/our needs without facing some additional challenges, I would most likely join.

My hope was not having to work with any of them, because it is the reference implementation, meaning it should work the best, although most likely not perfectly.

The reference implementation works the most correctly, not the best. That's what it means to be the reference implementation. And you would definitely have to work with them, you'll always have to work with a project this close and critical to your own. Sway contributors have a significant amount of code to wlc to make it suit our needs.

I already expected that, so no worries. Not every language is for everybody and not every language suits every use case, although I certainly think it would fit this specific one and could be a tight product.

The concerns I have here are with Rust, not with Rust projects. No product made with Rust could be a tight product in the context of my concerns about Rust.

Portability especially with a few BSD-users you have, might actually be an issue and fast development comes mostly down to the amount of C libraries you would need to use, but I give you that point as well.

Portability amounts to more than Linux and BSD. I see no reason why Sway shouldn't run on any POSIX system with minimal finageling (porting rust does not count as minimal finageling). I expect Sway to be able to be ported to Linux, BSD, Minix, plan9, and your cousin's POSIX clone he wrote in OS class in college, on every architecture ever. C delivers on all of that like no other language can.

I would also prefer that, but this brings up the time issue again, which mostly exists because you already have quite advanced plans for your compositor and I had the feel, that we needed to leave the sinking ship asap, if I want to keep using my own compositor.

I would sacrifice time for a better product any day of the week. Xorg works, people can still use it today. And I think you'll find that if we can get a sufficient force of motivated contributors behind this project, time will be less and less of a problem. Getting Sway from PoC to usable desktop progressed at a blistering pace.

Developing together with you would of course avoid that problem, as we would probably do the transition together or in quick succession.

Aye.

I would like to hear about this, maybe you have already written something like this in sway contribution guide if something like this exists? If I can see that your project is well suited for my/our needs without facing some additional challenges, I would most likely join.

Some of this is written down. Some of it comes from intuition and is made known while reviewing pull requests. The written down parts are here: https://github.com/SirCmpwn/sway/blob/master/CONTRIBUTING.md. I call out unsafe C during review, and forbid certain practices like fixed buffers and carefully watch what happens to untrusted values. Writing safe C requires dicipline but it's definitely achievable. I encourage you to read through Sway and my other C codebases (aerc is another good one) and their pull requests for an idea of how I C.

@SirCmpwn
Thanks for your insight, I'd be willing to work together on a wlc replacement as well. Sway, Way Cooler, and Fireplace don't seem to be going anywhere so I think a library mantained by us will both better suit our needs and more likely to be maintained compared to wlc.
I understand your desire to write it in C, and would be more than happy to contribute to it (I also know C, though not as well as I know Rust). To make it in Rust would probably make it problematic for other languages to bind to it, because even if we expose C bindings they would not be one-to-one with the Rust ones and a divergent API is never good.

I would sacrifice time for a better product any day of the week. Xorg works, people can still use it today. And I think you'll find that if we can get a sufficient force of motivated contributors behind this project, time will be less and less of a problem. Getting Sway from PoC to usable desktop progressed at a blistering pace.

This is also a good point -- it's important that we build something right rather than work to build something fast. wlc was obviously just a hobby projct, but it didn't try to do things right and suffered for it. Since our window managers seem to be the only usable/near-complete tiling window managers in the Wayland ecosystem right now, it seems prudent that we design a good, lasting solution for tiling window managers.

The concerns I have here are with Rust, not with Rust projects. No product made with Rust could be a tight product in the context of my concerns about Rust.

I am sorry, but I cannot hold myself, although I know this is not really related to the issue. I am sold on doing the library in C, no worries, but is this about the rather huge statically linked standard library or how did you end up with that opinion?

... C delivers on all of that like no other language can.

Point made. Although I had recently fun developing a kernel in rust at university, but its definitely not production ready for these things.

Getting Sway from PoC to usable desktop progressed at a blistering pace.

I know, I watched it grow and used it for quite some time. ;)

I encourage you to read through Sway and my other C codebases (aerc is another good one) and their pull requests for an idea of how I C.

I will in the following days, I like what I see in the CONTRIBUTING file so far (although tabs is a bit unusual, but hey, that is something my IDE should handle).

Thanks for your insight, I'd be willing to work together on a wlc replacement as well. Sway, Way Cooler, and Fireplace don't seem to be going anywhere so I think a library mantained by us will both better suit our needs and more likely to be maintained compared to wlc.

Nice to see you on-board here.

Since our window managers seem to be the only usable/near-complete tiling window managers in the Wayland ecosystem right now, it seems prudent that we design a good, lasting solution for tiling window managers.

Just adding my two cents, I do not think a library like wlc should be tailored to tiling at all. Maybe provide some helpers, but that's about it.
@SirCmpwn I see you are managing a lot of your discussion via IRC. I am not a big fan of it, mostly because I always forget to check it and miss important information. If you continue to sum up most of it in https://github.com/SirCmpwn/sway/issues/1076 and if we could organize smaller projects related to the new compositor in their own issues, I would be really happy. Once we have fleshed out, how you would like to structure it and go about it, I am willing to jump straight into development.

I am sorry, but I cannot hold myself, although I know this is not really related to the issue. I am sold on doing the library in C, no worries, but is this about the rather huge statically linked standard library or how did you end up with that opinion?

We can chat about this on IRC or something if you like. Which you don't, it seems.

Just adding my two cents, I do not think a library like wlc should be tailored to tiling at all. Maybe provide some helpers, but that's about it.

Agreed. This was just briefly discussed on, uh, IRC.

@SirCmpwn I see you are managing a lot of your discussion via IRC. I am not a big fan of it, mostly because I always forget to check it and miss important information. If you continue to sum up most of it in SirCmpwn/sway#1076 and if we could organize smaller projects related to the new compositor in their own issues, I would be really happy. Once we have fleshed out, how you would like to structure it and go about it, I am willing to jump straight into development.

I highly reccommend IRC as a medium for collaboration. If important decisions are reached or important topics discussed, they are summarized or pasted into the discussion on GitHub so they won't be missed and are permanently archived. It seems from my readings of the rest of the discussion that some of the direction I'm proposing doesn't mesh quite right with way-cooler's goals - can you guys hop into that discussion and provide feedback? I think before we start actually writing code we need to discuss and stew on this for a few weeks.

@SirCmpwn, I'll be sure to hop on the IRC. I have been there a few times, namely to see ask a question or two and see what it's like. The only thing stopping me before was that I didn't have a client that I knew well enough and so was just using web clients in order to connect. Now's a good a time as any to find an IRC client I like (any recommendations, by the way?).

Do you like terminals? Weechat. Do you like GUIs? HexChat.

@Timidger @Drakulix what's the plan wrt libweston.rs? Still planning to build it?

@Timidger @Drakulix what's the plan wrt libweston.rs? Still planning to build it?

Most likely not. Focus is now on helping @SirCmpwn with his compositor and shape it in the process to be also usable by way-cooler and fireplace.

I have spend quite some time to think about this back and forth in the last days and I want to take my chance and go with @vberger 's project smithay.
This might take a lot of time, but the more I try to integrate with the wlc and wayland apis to e.g. implement the redshift gamma-control api, the less I think I will enjoy working on other rust-bindings. It will most likely never integrate well enough with @vberger 's existing wayland libraries and there will most likely be other challeges to fight.
I know that sway's library will mostly likely be the most stable solution and that smithay maybe will take some more time, but I have another vision for my code base and the api I want to use to integrate with wayland.

@Drakulix, sorry to hear that. Good luck working with smithay.
@SirCmpwn, I'm still down to work with you on a compositor framework if you are.

Best of luck!

I know I'm months too late for this, but just to note for the record (leaving aside 'terrible code' and that we're an awful upstream to work with, which I obviously don't agree with but have no interest in getting into), that whilst libweston does expose a lot of its internal implementation details, that's not the long-term plan.
Current libweston is just an evolution of the original codebase into something which could be exposed as a library; as that wasn't done from the start, we're still going through the process of cleanly separating out an API. We'd be really interested to work with anyone using it, to get feedback on and help fix the - no getting around this - clearly suboptimal current API.
Anyway, best of luck with waycooler and wlc!

authors: Cloudef Drakulix SirCmpwn Timidger chrysehs fooishbar moosingin3space vberger

repo: way-cooler/way-cooler


text:
🛑 博客123 is down

In d2d18ce, 博客123 (https://wr0926.ml) was down:

HTTP code: 0
Response time: 0 ms

Resolved: 博客123 is back up in e3ca198.


text:
It's really interesting

I'm pretty sure you can have projects within your repository as well as projects outside of you repository! I think the main thing missing might be time estimates, depending on how important that really is...

https://github.com/waynew/simplest-python-package/projects/1#card-18003164
Go to the project! Do it now!

repo: waynew/simplest-python-package


text:
chore(master): release 1.4.12

:robot: I have created a release beep boop
1.4.12 (2023-09-12)
Miscellaneous

deps: update docker/login-action action to v3 (f7a2445)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/wayofdev/docker-rabbitmq/releases/tag/v1.4.12 :sunflower:

repo: wayofdev/docker-rabbitmq


text:
Add demo certificates to Indexer packages

Description
[Describe what this change achieves]
Related Issues
Resolves #[Issue number to be closed when this PR is merged]

Check List

[ ] Functionality includes testing.
[ ] API changes companion pull request created, if applicable.
[ ] Public documentation issue/PR created, if applicable.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

This has been migrated from #548. Most work by @QU3B1M .

repo: wazuh/wazuh-indexer


text:
"Open Terminal Here" does nothing

I'm on OSX 10.7.4 with ST2.2207
Niether the keyboard shortcuts or the menu option open a terminal.
The command is logged: command: open_terminal {"paths": ["/Users/someperson/somefolder"]}, but nothing happens.  Is there anything I can try?

This issue seems to be 3 years old. I am going to optimistically close it. If the issue is still occurring, please re-open it.

authors: lstroud twolfson


text:
Any potential support for a Windows version?

Hey, I'd like to use this tool on Windows, but it seems hard-coded to *nix.
I use nvm-windows for node version management (Windows 10).
C:\dev
λ npm install -g avn
C:\Program Files\nodejs\avn -> C:\Program Files\nodejs\node_modules\avn\bin-public\avn
+ avn@0.2.4
added 282 packages from 548 contributors in 28.103s

C:\dev
λ npm install -g avn-nvm
Terminate batch job (Y/N)? y

C:\dev
λ npm install -g avn-nvm
npm WARN avn-nvm@0.2.2 requires a peer of avn@0.2.x but none is installed. You must install peer dependencies yourself.

+ avn-nvm@0.2.2
added 14 packages from 8 contributors in 2.16s

C:\dev
λ avn setup
events.js:174
      throw er; // Unhandled 'error' event
      ^

Error: spawn /bin/cp ENOENT
    at Process.ChildProcess._handle.onexit (internal/child_process.js:240:19)
    at onErrorNT (internal/child_process.js:415:16)
    at process._tickCallback (internal/process/next_tick.js:63:19)
Emitted 'error' event at:
    at Process.ChildProcess._handle.onexit (internal/child_process.js:246:12)
    at onErrorNT (internal/child_process.js:415:16)
    at process._tickCallback (internal/process/next_tick.js:63:19)

PR welcome.

authors: djD-REK wbyoung

repo: wbyoung/avn


text:
您好，关于API有些问题

您好！
我是一名新手，现在我在一个云服务器上搭建了llama2，并且使用text-generation-webui的项目实现了一个webui的界面，最后我也获得了一个公网可以访问我自己搭建的llama2的服务的地址。
现在我希望，在有这个地址的情况下，能不能实现一个公共的api，也就是借助我在云服务器上搭建好的服务，其他电脑可以通过一个公共的api来获取这个服务。
希望得到您的回复，谢谢！

@15899885850 你可以看看这个项目
https://github.com/hyperonym/basaran

repo: weaigc/gradio-chatbot


text:
MSI Stealth

Hi,
First - thank you, I have been waiting over a year for this :-)
For the MSi Stealth GS70 series, only the blink example seams to work but nothing else. Unable to change colours or anything.
I have no errors to show, as there is no output other than setColor:
describe('msi-keyboard', function() {
^
ReferenceError: describe is not defined
at Object. (/home/phill/workspace/keyboard/test/setColor.js:6:1)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Function.Module.runMain (module.js:497:10)
at startup (node.js:119:16)
at node.js:906:3
Hope you can help,
Best Regards,

That error is expected, it is not an example file but a code test.
I have the keyboard in the GS70 Stealth, please run this example with sudo.

Yes, the blinking works perfectly. But none other works.
No wave, etc. the example to set colour.
Ideally would like to have wave when computer is idle otherwise just have
non blinking/moving colours.
On Fri, Mar 13, 2015 at 3:40 PM, Steve Lacy notifications@github.com
wrote:

That error is expected, it is not an example file but a code test.
I have the keyboard in the GS70 Stealth, please run this example
https://github.com/wearefractal/msi-keyboard/blob/master/examples/blinkMulti.js
with sudo.
—
Reply to this email directly or view it on GitHub
https://github.com/wearefractal/msi-keyboard/issues/14#issuecomment-79056289
.

Hi,
Thanks for the fast response.
It is running as root / sudo.
The blinking example work perfectly :-) however wave / breath / just colour set has no output.

The issue with wave and breath will be fixed with #20

authors: phillw stevelacy

repo: wearefractal/msi-keyboard


text:
Use a favicon maker instead of hardcoding all the Favicon junk

There's a great tool here which would save us time and mean we don't need to worry about building favicons.
This should nicely streamline all of this stuff

All done. cc @sergeitatarinov

repo: wearehanno/riggings


text:
🛑 Zoop is down

In 4df944f, Zoop (https://zoop.gg) was down:

HTTP code: 504
Response time: 10264 ms

Resolved: Zoop is back up in ce57e78.

repo: wearezoop/status


text:
Document flags

Currently scope --help outputs this usage text:
Usage:
scope launch [<peer> ...]
scope stop
scope command

scope <peer>    is of the form <ip_address_or_fqdn>[:<port>]

However, there are a few flags (--no-app, --app-only, --no-probe, --probe-only, --service-token, --probe.token), available for at least launch, as seen here.
It would be great to have them in the --help text, as well as in the "Installing" section of the documentation, or a new "Operational guide" as is available for Weave Net.

However, there are a few flags (--no-app, --app-only, --no-probe, --probe-only, --service-token, --probe.token), available for at least launch, as seen here.

Those flags are part fo the launch subcommand, try scope launch --help

@carlpett What would had made it easier to find the flags documentation?

Expanded from the discussion on Slack:
I think the thing that made me not even test scope launch --help was that there is some invocation help already on the first --help, which, in combination with the lack of mention in the docs, made me assume that those were the only available options.
So, it might actually be more intuitive (to me at least) if the top level help hadn't show anything, or somehow indicated that there were many (many many) flags available. Maybe just scope launch [...]? I'm on a phone now so I can't easily look around for good examples, but something along those lines.

perhaps just change the first line of the usage to
scope launch --help | <opts> [<peer> ...]

That would be the Minimal Viable Improvement, I think ;)
Beyond that, I find it mighty odd that scope --help reports
Unknown scope command '--help'
Usage:
scope launch [<peer> ...]
scope stop
scope command

scope <peer>    is of the form <ip_address_or_fqdn>[:<port>]

whereas scope help reports
Usage:

scope help     - Print this

scope launch   - Launch Scope
Usage of /home/weave/scope:
  -alsologtostderr
    	log to standard error as well as files
  -app-only
    	Only run the app
  -app.aws.create.tables
    	Create the tables in DynamoDB
...

Alas this is with 1.1.0; the latest master does things quite differently. Alas I am unable to build it. grrr.

perhaps just change the first line of the usage to
scope launch --help | <opts> [<peer> ...]

This would looks good to me!

As @rade mentioned, this is already "fixed" (or at least, changed) on master, see https://github.com/weaveworks/scope/pull/2077
Basically, the new behaviour is for scope --help to be the same as scope help, and the latter has some readability improvements.
The launch options described under the actual launch script are a subset* of those listed in scope help (since the launch script passes the args through to the raw binary).
There's an argument to be made that the list of options could be edited for clarity so important options (app vs probe) are at the top.
*or at least is meant to be, see https://github.com/weaveworks/scope/issues/2104

authors: 2opremio carlpett ekimekim rade

repo: weaveworks/scope


text:
TF Plan - Add Plan tab contents

As a user, I would like to go to the plan tab to see my TF plans so that I can easily understand the changes that have been made.

[ ] The code in the plan tab should be color coded to designate what will be created, destroyed, and updated. Green text indicates new, yellow text indicates updates, and red text indicates deletion
[ ] I still need to be able to access the  sync and suspend buttons when this tab is selected

Mockups available here: https://github.com/weaveworks/weave-gitops-enterprise/issues/1829#issuecomment-1313604122

Add endpoint for plan retrieval
The endpoint should return a string.
We don't have color information, so we have to figure out how to colorize the output. TODO: find out if we can use a terraform library that colorizes the output.

@josefaworks
Moved creating the Plan button to a separate issue:
https://github.com/weaveworks/weave-gitops/issues/3238

authors: josefaworks opudrovs ozamosi

repo: weaveworks/weave-gitops


text:
Add app status spike findings

Closes: #1188

What changed?
Added findings for the above app status spike.

Why?

How did you test it?

Release notes

Documentation Changes

can we close this now?

can we close (or merge) this now?

...yeah I think that is safe


text:
fix url checking reg exp and make it readable

Fixes #3601

In file ui/lib/__tests__/utils.test.ts, this PR adds more test cases to the isHTTP function to accurately distinguish between HTTP and HTTPS URLs, improving the reliability and functionality of the function.

The added test cases cover scenarios that were previously uncovered, including localhost and private IPs.

In file ui/lib/utils.ts, this PR updates the regular expression used for validating HTTP and HTTPS URIs.

The regular expression is now multiline, uses double quotes for consistency, and uses \\ to escape special characters.
The regular expression has been simplified and organized to improve readability, understandability, and maintainability.

It's looking good Chanwit - unfortunately I can't test as OSS appears to be broken on main

authors: chanwit joshri


text:
returning multiple A records

Our load balancers use A records wired into our dns service to distribute load across multiple machines.  As the machines go up and down our A records change and our load balancers reconfigure themselves to match our DNS records.
We cannot use this scheme today with weave dns because weave dns only returns a single A record even though there may be multiple addresses associated with that record.
More tradition DNS servers usually return multiple ip addresses in a randomized order instead of only returning a single IP address.
Are there plans in the future to support returning multiple A records when they exist?  Perhaps a flag passed to weave-dns to change the behavior.

dup of #733.

Hi Brya - thanks for the feedback!  We're actively work on this right now - checkout #1065

Thanks.  I saws the other links but had trouble finding them in search initially.  I'll keep my eye on #1065.

authors: bmurphy1976 rade tomwilkie

repo: weaveworks/weave


text:
Is it possible to specify the route so that traffic can through internal network?

I have two machines M1, M2, M3

M1 has a public IP address x.x.x.x, and an internal IP address 10.0.0.2
M2 has a public IP address y.y.y.y, and an internal IP address 10.0.0.3
M3 has a public IP address z.z.z.z, and is not in the same subnet with M1 and M2.

M1 and M2 are able to communicate with each other through 10.0.0.* and the public IP.
But the issue is that the bandwidth going though the public IP is limited, so I want the traffic  from M1 to M2 is through the internal network, i.e. 10.0.0.*
I start weave on M1 by
weave launch --init-peer-count 2

and on M2
weave launch --init-peer-count 3 x.x.x.x

and on M3
weave launch --init-peer-count 3 x.x.x.x

And I find that the communication between M1 and M2 is through the public IP, where the bandwidth is limited. May I know is it possible to configure the weave network so the traffic between M1 and M2 can go through internal network?
Thanks.

This has been discussed before, at #646.
There is a flag --no-discovery which restricts peers to using only the addresses they have explicitly been given.
Also (unrelated), please note the same --init-peer-count should be given to each peer.

Thanks bboreham, I'm now able to use --no-discovery to control the network topology.

authors: bboreham tangyouze


text:
[Query]Can weave be used to get IPV6 address for Pod

This is a query, I would like to know if weave supports getting IPV6 address for Pod. If so, is there any documention on steps to follow, thanks

Sorry, no support for IPv6 at present.
Closing as duplicate of #19

authors: bboreham bsshetty