Fixed case where a chat was too big for a single slack message

For extremely large cards

The second commit is to comply with Claude's specs here:
https://console.anthropic.com/docs/troubleshooting/checklist

The first part is a good catch but that seems a bit excessive for what's an edge case. I'd probably just ruthlessly split them down the middle and be done with it. Now that I think about it actually there is a pretty good chance that preserving formatting or markdown blocks is actually not necessary at all.
Consider what it says in the Claude API docs. Human and Assistant need to oscillate, i.e. there is no \n\nHuman after \n\nHuman. It also says that Slack automatically adds the \n\nHuman and \n\nAssistant bits for you. Knowing this, in a Slack thread where we have three messages by a user and then Claude's response it would seem likely that Slack combines all the user messages into one Human prompt.
So let's say we have three Slack messages in the thread like so

Anon: *This is the first part of the context.
Anon: This is the second part of the context.*
Anon: @Claude Assistant:

It would stand to reason that rather than turn that into
\n\nHuman: *This is the first part of the context.
\n\nHuman; This is the second part of the context.*
\n\nHuman: Assistant:

which would break with the formatting required for the API it would instead turn it into
\n\nHuman: *This is the first part of the context.
This is the second part of the context.*
Assistant:

So even if we split a long prompt message right down the middle Slack would stitch it back together again for the API call anyway, so we wouldn't even need to respect markdown blocks or anything like that.
Agree on the second part though. I initially thought it wouldn't matter because we're not actually working with the Claude API directly here but the thought experiment above made me realize this might actually be important after all. In a similar line of thought, I'm considering changing the example dialogue to use the H: and A: formatting suggested by the docs. So if we have messages from the role system with example_user and example_assistant we turn those into H: and A: instead of Human: and Assistant:

I'm not sure about the stitching because it works with multiple people (users) in the thread.
Personally not a risk I'm willing to take given it's already implemented anyways and there are no onuses.
I've added an option of a prefix on the ping message. Because I've had Claude self insert in my chats.
when you ping with @Claude, the text "Claude" is literally send with your prompt. It's unclear which of these happen. But its easily replicable if your PING_MESSAGE is empty/" "
[... context]
\n\nHuman: My last prompt I want completion
Claude

[... context]
\n\nHuman: My last prompt I want completion
\n\nHuman: Claude

With prefix I'm using so it sends "Assistant Claude:" for now to test it out. I haven't been creative enough to think of something better. Since whatever you send HAS to include "Claude"

You're putting me in a tough spot with this PR because you're mixing a lot of changes and while I'd definitely merge some of them and I'm not a hundred percent sure on others yet. But right now I can only merge all of them or none of them. Definitely not dismissing your stuff though, even the stuff I don't entirely agree with got me thinking and reading up on some things that I think might have some very interesting results down the road.
As for the ping message, I was playing around with that myself a bunch recently and I think the default should actually just be nothing. The docs claim that Slack adds Human: and Assistant: automatically so I think what @Claude Assistant: does is basically just
\n\nHuman: [context]
Assistant:
\n\nAssitant:

So the best thing for that space would in my opinion either be nothing for a "vanilla" completion, or an additional main prompt/nsfw prompt/jailbreak as they seem to have extremely strong effects in that area. I don't think it matters too much where the @Claude ping is in the message. It's just what pulls Claude into the thread and I would assume (but obviously can't say for sure) that Slack just filters that part out when forming the "real" prompt.
Maybe instead of having a prefix the message itself could just contain a place holder for the ping. So something like Foo @Claude Bar would just create the ping message with three elements in the postMessage rich text section. First element would be a text type with the text "Foo", second block would be a user type with the Member ID of Claude, third section would be another text type with "Bar". Wouldn't even be too complicated since it could just split the string before and after "@Claude", add those as text sections (empty elements are automatically ignored by slack) and if the string doesn't have an @Claude to split on we just add it at the start as before.
And while I'm at it I might as well pitch this here too, I was messing with prompt formatting a lot over the weekend by manually pasting prompts into Slack in different formats and I had some interesting results adhering more closely to the tips described in the API docs. Replacing Human and Assistant in the example dialogue with H: and A: had such a strong effect on Claude that it even started including the [Start new chat] line in its responses because it considered these part of the examples. XML tags also worked very well to get around that. I had the prompt say "Character definition is in the tag , example dialogue is in  tags" (you could do this in Silly in the main prompt for instance), then wrapped the character definition the tags as described and Claude starting including a lot more details from the definition and examples in its responses.
The big issue with the above is that it would require a lot of prompt fenagling to transform the OpenAI messages into a prompt like that. You'd have to look for "[Start a new chat]" messages, check ahead to the next message to see if it has example_user or example_assistant and only then replace it with an opening  tag (and a closing one before that if it's not the first example).
I think this also means that people could in theory write character cards specifically for Claude in an ironic twist on the W++ format because in Claude's case he is actually trained to understand information enclosed in XML tags but I don't think that's desirable.
One last thing, I'm still a bit torn on "\n\nHuman" and "\n\nAssistant" vs "\nHuman" and "\nAssitant". Not even so much in which one is technically correct. According to specs the first one is no questions asked. The problem is that the prompt we form gets dragged through so god damn many levels of serialization, deserialization and formats that it might honestly not matter at all what we put there, beyond at least making sure there's line breaks between them. Just in JSON stringifying the text, serializing as form data, letting Slack deserialize it and turn it into a rich text and then extract that back out into the actual Slack prompt we have no idea what's going to happen to these line feeds and how much escaping Slack does on its end. For all we know Slack turns them into LF+CR or just deletes them entirely.

You're putting me in a tough spot with this PR

Yes, sorry about that. I'm rushing changes because I'm desperately working on something else for Silly that uses slaude and I'm not organizing features with branches. I only implemented this stuff because it was interfering with the way I'm using it.

I don't think it matters too much where the @Claude ping is in the message.

I've had legitimately frequent problems with Claude self inserting, that I've never had before, when leaving PING_MESSAGE empty, I'm quite sure at this point the literal "Claude" is part of your prompt when you ping and you have to be careful.
my commit changes the ping to:
${config.PING_MESSAGE_PREFIX} Claude ${config.PING_MESSAGE}
of course, each is omitted they are emtpy.

H: A:
XML tags also worked very well to get around that

huh, I've tested XML tags in GPT's OpenAI, but specifically for response templates, for example, fixed terminal UIs, or game-like results. But on that use case, on GPT, it wasn't much different, I'd say it was noticeably worse than using [], and it sometimes started using HTML hahah. Might look into this.

The big issue with the above is that it would require a lot of prompt fenagling to transform the OpenAI messages into a prompt like that
I don't think that's desirable.

Yup yup, sadly it works

I'm still a bit torn on "\n\nHuman" and "\n\nAssistant"

I also have your concerns you list after that, but I can't think of any reason to use single \n, it's not even an extra token if the Claude tokenizer is worth anything at all. You have no chance of being in 100% specs with a single \n, though its better than NO \n at all ofc.

Taken over a few of your changes (or their general intent) with the latest update. I see what you mean with leaving the message blank now though. It worked pretty well on one card I was trying but on another it ended every response with something like "Is it OK like this? Do you want me to change anything?"
I think just leaving Assistant: in there for now is probably the safest bet. For people who don't want to mess with settings it seems to produce results closest to what they're used to from Spermack and people who feel comfortable with experimenting probably already found their own working prompts to put in there.
As for the XML tags, this is what got me thinking about it https://console.anthropic.com/docs/prompt-design/being-explicit#use-xml-tags. The docs recommend to use tags like that to give structure to the prompt and structure is what Claude is sorely lacking over Slack at the moment. I think that plays a part in its perceived dementia. We just throw a huge wall of text at it with a main prompt, character definitions that often have a conflicting mix of "{{char}}, he, she and You:" to describe both the character and the role the user plays in them and then just a big wall of example dialogue with an unhelpful [Start new chat] in front of each block and in front of the actual dialogue. That Claude manages to figure any of this out at all is impressive enough as it is.
I'd honestly almost prefer to just implement proper Claude support in SillyTavern so the prompt we get to work with is already in a format that Claude knows to work with. Then we'd only have to worry about slicing it up into Slack digestible pieces. I know Agnai already got it but I had a brief look at their adapter and it doesn't seem to actually do anything special with the prompt other than shove it between Human and Assistant strings. But I don't have a Claude API key and until I do I'd rather not try to implement API support for something I have no way of testing.

Cheers and thanks for engaging on the discussion!

One of the things I've currently got pushed on a branch is that I separate out the main prompt from the first message we get from SillyTavern and then use that as the Claude ping message at the bottom instead. Has worked pretty well so far. To drill the point home a bit more I've also added "Assistant is {{char}} and Human is {{user}}" to the main prompt (directly in SillyTavern) just to drill it home a bit. Not sure how much of an effect that particular snippet had though. Tried sectioning out the prompt with XML tags too but I'm honestly not sure if that was effective enough to be worth the extra tokens we need both to explain Claude what the tokens mean and then for the tokens themselves.
The Claude ping itself definitely seems to have some weird effects on him though, I agree.   Literally the exact same series of messages that lead to the same reproducible result no matter how many threads you try them in, but depending on which of those messages you add pings to Claude just suddenly starts falling apart when it counts. It feels a little bit like Claude will pull in the context of the thread exactly once, the first time you call him into it with a ping and he'll remember everything up to that point with perfect clarity but anything after the ping might as well not exist anymore.


Create migration guide for SDKv5 to v6

Closes #1179

Also, are we going to have a different guide to make an interoperable module?

@ishantiw currently, I don't think we have planned that. The Hello World app currently only has one module which is not interoperable.
But actually it is a good idea, maybe it should be updated to include such a module, or maybe the Hello module should be directly constructed like that.


[PL] New expansion rules and usage in multiple tests, some optimizations

Added new expansion rules and applied them in multiple tests, some optimizations

@witold-gren @Wojciechgc @rrakso Could some of you please take a look at this, it would be plain unethical for me to just accept my own changes 😀 Thank you!

@witold-gren @rrakso @Misiu
I've looked once again into the whole "całe" situation across the board and I've came to conclusion this should be limited to lights and lights only.
It does not sound right with all other types of instances like covers and fans. And even for lights it would require us to convert all sentences using it to different form (as mentioned by @Misiu in the discussion already).
I'll get rid of it completely for now and create an issue on our Polish issue tracker repository to reevaluate it after the project matures enough.


Multiple Environments

That is the one thing Retool has that I really like over Appsmith. Otherwise I am liking Appsmith a bit more so far. They have a really easy way to flip between production / staging environment with all the same widgets on a page

We use al least 3 environments (dev, staging, and production)

@hexadecy you can achieve this today using our Git Feature. You can connect your app to a git repository and then import it into a staging organization & a dev organization. You will be prompted to enter separate credentials for all your datasources in these organizations

Closing this feature as we're tracking it here #2836


Add functionality to email sender and reply to email

When celts sends an email the sender name and reply to email needs to be updated based on what is in the program table.

Pull request merged.


Support for automatic paging

It would be helpful for this implementation to support the automation of returning the results from all the available pages in a request. I see this as a boolean flag which specifies if you want to get all the results in a single call, or handle this yourself (with the default being the latter - for performance reasons). There are instances where I need to grab all the objects in a list of results, not just the first x results.
I could write this myself for each request I make, or subclass the client, but having this built in by a (named) argument passed to the .get() function would be preferable to keep to DRY principals.
Implementation wise it would require a loop checking for the @odata.nextLink key in the returned JSON dictionary for each fetch, and returning all the results when this key is no longer present in the response.

Thanks for the suggestion, closing as duplicate of https://github.com/microsoftgraph/msgraph-sdk-python-core/issues/105


test helpers

This PR will tighten the linter settings, to make the 47 upgrade easier.  It should not change functionality in any way.

Thanks!


SyntaxError: Expected "," or '}' after property value in JSON at position 336

Setup

Rancher version: 2.6.6
Browser type & version:

Describe the bug

When trying to import or create an Azure/AKS cluster with client secret keys expired, the UI throws:

To Reproduce

Try to import or create an Azure/AKS cluster with client secret keys expired.

Result

Expected Result

A more friendly error message according to what the logs of Rancher it's saying:
The provided client secret keys for app 'a59c8913-d4df-4752-ae69-f6488ab00d62' are expired. Visit the Azure portal to create new keys for your app

Screenshots

Additional context

The initial root cause of this issue is invalid JSON aksLocations endpoint produces when error message contains "s. This is being fixed in https://github.com/rancher/rancher/pull/39612 for the next 2.7.x release. Please note the following from the PR details:

Following this change, in the situation outlined in https://github.com/rancher/dashboard/issues/7285 UI now shows [object Object] error text that is not helpful - but not less helpful than the current SyntaxError: Expected "," or '}' after property value in JSON at position.... UI code needs to be improved to properly handle the returned error object.

Verified as fixed on build: v2.9-360c02b3761f7f2bf621cde5767eb65b67dcc059-head
When trying to create an AKS cluster with client secret keys expired, the UI throws proper error which matches with backend logs:

Logs:
2024/01/09 05:42:31 [ERROR] [aks-handler] error getting locations: failed to get locations: azure.BearerAuthorizer#WithAuthorization: Failed to refresh the Token for request to https://management.azure.com/subscriptions/REDACTED/locations?api-version=2016-06-01: StatusCode=401 -- Original Error: adal: Refresh request failed. Status Code = '401'. Response body: {"error":"invalid_client","error_description":"AADSTS7000222: The provided client secret keys for app 'de9ef773-cdcd-4ce8-bfca-6982d555f417' are expired. Visit the Azure portal to create new keys for your app: https://aka.ms/NewClientSecret, or consider using certificate credentials for added security: https://aka.ms/certCreds. Trace ID: c1fde356-7447-41d2-97cf-4e8ffe453400 Correlation ID: 9998d949-6440-451c-a6ff-09515328ce8b Timestamp: 2024-01-09 05:42:31Z","error_codes":[7000222],"timestamp":"2024-01-09 05:42:31Z","trace_id":"c1fde356-7447-41d2-97cf-4e8ffe453400","correlation_id":"9998d949-6440-451c-a6ff-09515328ce8b","error_uri":"https://login.microsoftonline.com/error?code=7000222"} Endpoint https://login.microsoftonline.com/fcf34994-aac4-4462-afaa-d83f87c5f51d/oauth2/token?api-version=1.0


Extend the check-ipsec-leak bpftrace script to capture additional details of leaked packets

We have been recently witnessing a few conformance ipsec runs reporting leaked packets, with some referring to DNS answers from a coredns pod to a CiliumInternalIP. In order to simplify troubleshooting these issues, and figure out whether they are legitimate or flakes, let's additionally print whether the detected packet was encapsulated or not. Moreover, let's output information about the DNS message itself, so that we can trace down which component performed the request.
The output is along the lines of:
[10:27:49:245997] <IP_ADDRESS>:49662 -> <IP_ADDRESS>:53 (proto: 17, encap: 1, ifindex: 43, netns: f0000000)
[10:27:49:246003] Detected DNS message, ID: 17ef, Flags 120, QD: 1, AN: 0, NS: 0, AR: 1, query googlecom
[10:27:49:246315] <IP_ADDRESS>:53 -> <IP_ADDRESS>:49662 (proto: 17, encap: 1, ifindex: 45, netns: f0000000)
[10:27:49:246317] Detected DNS message, ID: 17ef, Flags 8580, QD: 1, AN: 1, NS: 0, AR: 1, query googlecom

/ci-ipsec-e2e

/test

/test

The last push adds the support for displaying whether the detected flow matched trace_override, as well as the TCP flags in case of TCP packets.

Looks great.

Updated the last commit to use (sort of) character literals rather than strings, as otherwise hitting the stack limit.

/test

:wave: @youngnick, any specific reason why you removed the ready to merge label?
Reviews are in, and all required tests are green. The two failing tests cannot be possibly related given that this PR only touches the bpftrace script used by ipsec-related workflows only.
Cilium E2E Upgrade: has been pretty flaky recently, and looks related to https://github.com/cilium/cilium/issues/32689
CiliumEndpointSlice migration: https://github.com/cilium/cilium/issues/33417 - Based on the occurrences on main, this would be likely fixed by a rebase on main. Considering that the test is not required, and cannot be possibly affected by this PR, I wouldn't trigger another CI run though.

The current tophat guidance is to just rerun CI for failed tests, rather than bypassing the branch protections, which is why I removed ready-to-merge. I think that we should definitely clarify what the tophat is supposed to be doing here, and do a better job of communicating that to everybody.
Let me check with @aanm and @joestringer about this.

The current tophat guidance is to just rerun CI for failed tests, rather than bypassing the branch protections, which is why I removed ready-to-merge.

My understanding is that the re-run CI guidance applies to required tests. Yet, in this case, the only failing tests are not marked as required. If we are forced to re-run then, then what is the value of marking tests known to be flaky (or not yet shown to be stable) as non required?
Moreover:

The ready-to-merge label was added by the bot, not by myself. Which means that the bot agrees that tests marked as non required are not required to merge a PR. If that's not the case, then the bot should be updated accordingly.
AFICT, merging such PR does not require bypassing any protection, and could have been performed by any committer. Hence, this would also leave an inconsistency in terms of what committers could/should do, and external contributors (with the helm of the triager) could/should do.

I think that we should definitely clarify what the tophat is supposed to be doing here, and do a better job of communicating that to everybody.

I agree, there's definitely not 100% alignment on this among different folks. I personally think that the removal of the ready-to-merge label should be also clearly communicated by the tophat (e.g., with a comment explaining the reason), as otherwise easy to miss, and possibly misleading for PR authors.


Echo and Core bot needs structural changes to work in Gov

Describe the bug
ABS portal templates in C# won't work in Gov env
[bug]

We believe the release of 4.4.4 SDK allows these templates to be authored now.
This may be compelted now.

I believe we need to actually get these changes into this repo, as we cut private bits/or separately updated the samples provided to the ABS team to work in Gov.

Individual work items per samples language

[ ] #1558 (@sgellock, C#)
[ ] #1556 (@stevengum, JS, no sample changes required other than a dependency bump)

Closing this as the C# issue is resolved.  The JS issue is still open and will be resolved once 4.5.x JS modules are published.


Data modeling

Determine the data models for the project based on the README information about the site purpose
Poll or Feedback or Post
Comment
Are Votes a separate resource or are they attributes of a Poll or a Comment?
How do Poll/Post/Feedback relate to Comment and Vote?
https://docs.djangoproject.com/en/3.1/topics/db/models/
Use the docs to figure out what kind of fields each piece of data should be stored as in the database.

I would be interested in working on this.

1st attempt at an ERD for the database. I focused mostly on entity types and left out details like datatypes for now.
Devroast_ERD_v1.pdf

Thanks for doing this. I'll look at it tomorrow.

Ok looks like this is using Project, Question and Comment as the main three models.
What's the difference between a Question and a Comment?
Django has already created the auth_user table, which typically uses a foreign key of user_id in the other tables.  Django is particular about the naming of app/table so they might be slightly different than what's in the ERD, but generally I think it looks good.

This ERD is modeled like this:
class Project:
user = ...
title = ...
repo_url = ...
hosted_url = ...
class Comment:
post = Project.id
user = ...
body = ...
neg_votes = ...
pos_votes = ...
parent = models.ForeignKey('self', related_name='reply_set', null=True)
So if the goal is to get all of the comments, you would do:
Project.objects.get(id=5).comment_set.all() to get the first level of comments
then to get the levels under the first comment, you'd have to do a for loop through all the comment_set I think?
for comment in Project.objects.get(id=5).comment_set.all():
replies = comment.reply_set.all()
Can anyone think of a better way to get the 2nd level of comments?

If the ERD instead had one Project that had one Comment:
class Project:
user = ...
title = ...
repo_url = ...
hosted_url = ...
comment = Comment.id
class Comment:
user = ...
body = ...
neg_votes = ...
pos_votes = ...
parent = models.ForeignKey('self', related_name='reply_set', null=True)
In this you would get the first Comment with:
Project.objects.get(id=5).comment
and you'd get the rest of the comments with:
Project.objects.get(id=5).comment.reply_set.all()

I'm think Project should have many comments, and that Comment should be its own model.

I agree with 1 Project : N Comments. Comments have enough separate attributes and behavior to warrant it.

Team decision is to go with a Project has many Comments

When discussing Tags, the team decide to have a link both on Project to Tag and Comment to Tag so that the OP can post a project for feedback with tags and without a comment, and also so that an OP can post a project for feedback with specific questions (Comment) that have tags.

@D-Bits Please add a link between Project and Tag in the PR #31


Use Stiches with Remix

Can you please add support for integrating Stiches with Remix?

Yes, we're working on that, but it's part of a bigger effort which we're already tracking internally. Thanks though! Remix is 🔥


broken link

Extend IoT Plug and Play bridge link broken at bottom.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 84516e04-1144-aa3a-ce92-b8323e082bb5
Version Independent ID: b8384910-42b8-03af-2809-3edb4a57424c
Content: IoT Plug and Play bridge
Content Source: articles/iot-pnp/concepts-iot-pnp-bridge.md
Service: iot-pnp
GitHub Login: @usivagna
Microsoft Alias: ugans

@usivagna Thanks for the feedback! We are currently investigating and will update you shortly.

@usivagna Thanks for the feedback! We are currently investigating and will update you shortly.

@usivagna PR has been crated to fix the link. Please check and update. Here is the link for reference: https://docs.microsoft.com/en-us/azure/iot-pnp/howto-build-deploy-extend-pnp-bridge
I see that you are an author of this doc. For future doc enhancements or updates, you may update the doc yourself by creating a PR against it.

We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.

@usivagna PR has been crated to fix the link. Please check and update. Here is the link for reference: https://docs.microsoft.com/en-us/azure/iot-pnp/howto-build-deploy-extend-pnp-bridge
I see that you are an author of this doc. For future doc enhancements or updates, you may update the doc yourself by creating a PR against it.

We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


SAE class agnostic functions

I'm using some different SAE architectures to what you've got in your AutoEncoder class, but the regular _get_dashboards_data() and get_prompt_data() functions require an AutoEncoder as input, so I've broken these functions up:  _get_dashboards_data() and get_prompt_data() now respectively call parse_dashboards_data() and parse_prompt_data(), which take in only the required inputs, so that they're agnostic to the SAE or model architecture. Now we'll be able to import these functions and use them without relying on the AutoEncoder class. The same thing was done by Stefan in his https://github.com/ApolloResearch/rib_vis fork of your repo, and by Dan Braun and I within our private repo, but having these functions broken up in the main branch here will make it much easier to maintain compatibility.
There should have been no functional changes: just restructuring of the code. This has been tested by running demo.ipynb

Hey, thanks for submitting this! I do feel kinda bad now because I have significantly restructured things (yet again). However after this restructure I'm planning to enable ppl like you and Joseph to make changes directly without going through me first. And hopefully these changes have not only added a few really cool and useful features (see user guide) but should also be more extensible and easier to edit. Let me know if you have any other thoughts!
As for the autoencoder thing specifically, yep I'd intended to change this (possibly to integrate with Joseph's Autoencoder class in that library, or else just make the function more permissive). Any edit here would be much appreciated!

And for these changes specifically, lmk if there's anything else I can do to help!

All good no worries, the new features look great. So is this the last major restructure for a while, or is there another one coming down the pipe soon? If the latter, just let me know when it's out and I'll make these SAE-agnostic functions again.

Definitely no more restructures planned! There may be additions, but
nothing major / no breaking changes. I anticipate that all future things
I'm interested in adding will be compatible with the current way that the
repo works (don't think that was the case before).
On Sun, 24 Mar 2024 at 16:21, Jordan Taylor @.***>
wrote:

All good no worries, the new features look great. So is this the last
major restructure for a while, or is there another one coming down the pipe
soon? If the latter, just let me know when it's out and I'll make these
SAE-agnostic functions again.
—
Reply to this email directly, view it on GitHub
https://github.com/callummcdougall/sae_vis/pull/15#issuecomment-2016859495,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKZEROQ4ZFQTS6XWWTHVWSTYZ34RPAVCNFSM6AAAAABFEDRMK2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJWHA2TSNBZGU
.
You are receiving this because you commented.Message ID:
@.***>

Excellent, I'll close this and make a new PR next week.


Run mykrobe

This should use the settings used in the head to head paper. These will be released in mykrobe v0.11.0 (currently on master as --ont). If needing to set manually, the settings can found in https://github.com/mbhall88/head_to_head_pipeline/blob/master/analysis/resistance_prediction/workflow/rules/mykrobe.smk.
It is up for debate whether we want to use the -A option to report all calls. Maybe we can have this as an option in tbpore and have it turned off by default?

Closed via https://github.com/mbhall88/tbpore/pull/8


Please release version 0.0.4 on pip

Hello @chrisglass would it be possible to release version 0.0.4 on pip ? I see that the current version on pip is 0.0.3 (https://pypi.python.org/pypi/django-xhtml2pdf/0.0.3) from 2011!
I am using django-xhtml2pdf for my projects and I have to add an ugly
-e git+http://github.com/chrisglass/django-xhtml2pdf.git@94c0d1e42c4ac05ba6ec8f1535700ab78ae1bb26#egg=django_xhtml2pdf
line to my requirements.txt  :(
Thanks !

I am working on preparing a new release shortly.
-Scott


auro-input; upgrade and feature support (combo-issue)

User story
The scope of this story is to encompass the following open issues to be delivered. The following list is prioritized.
Updates and issues to address

[ ] remove light DOM support https://github.com/AlaskaAirlines/auro-input/issues/39
[ ] address increased bundle size https://github.com/AlaskaAirlines/auro-input/issues/36
[ ] default values for boolean attributes https://github.com/AlaskaAirlines/auro-input/issues/35
[ ] address label issues https://github.com/AlaskaAirlines/auro-input/issues/34
[ ] CC and Firefox issue https://github.com/AlaskaAirlines/auro-input/issues/26
[ ] upgrade https://github.com/AlaskaAirlines/auro-input/issues/15

Prior to next major release
It is important that we communicate prior to the next major release that we will be changing the npm namespace. See https://github.com/AlaskaAirlines/auro-radio/commit/2e894a0af517b633a4b24cbc2b3156cd96487d1d for the update to be used.
Development process
This is a placeholder issue for all the issues to be in a single release. As each issue is put into play, please update the issue as IN PROGRESS and move it into the WIP column. Please leave this issue in TO DO until all linked issues are completed.
Definition of “Done” (exit criteria)
This issue will be considered complete and all features released once all issues listed are considered complete.

Removing ticket #23 from this ticket.


Preprocess time

How long does it take to run getPatchImageAndMask.py?

How long does it take to run getPatchImageAndMask.py?

hi,i don't calculate the running time,may be take several days

Several days??!! How many images are going to be created for liver?

”Process finished with exit code  (Interrupted by signal 9: sigkill)” appears when running getpatchimageandmask.py. The online query says that the CPU or running memory is insufficient. My running memory is 32g

”Process finished with exit code (Interrupted by signal 9: sigkill)” appears when running getpatchimageandmask.py. The online query says that the CPU or running memory is insufficient. My running memory is 32g

32g will not be enough, unless you have extra disk space for paging.

thanks, I asked the author that he said his  running memory is 128g.

运行 getpatchimageandmask.py 时出现“Process finished with exit code (Interrupted by signal 9: sigkill)”。网上查询说CPU或者运行内存不足。我的运行内存是32g

32g 是不够的，除非你有额外的磁盘空间用于分页。

Thanks, I asked the author that he said his running memory is 128g.


add Edge to supported browsers, fixes #6269

note that this change is untested but I expect that it is simple enough that nothing wrong will happen


Remove flaky download count assertion

Address https://github.com/NuGet/Engineering/issues/1952.
This is broken since stats don't sync between search and gallery simultaneously.

Is there any assertion we can do instead that isn't flaky? Could we check for ANY download count instead of a specific value?

Is there any assertion we can do instead that isn't flaky?

Theoretically we could regex out the download count and make sure it is within X% of the value found in search... but is this really worth the effort? How many times has this test actually caught a real problem?

Could we check for ANY download count instead of a specific value?

Wouldn't this just be asserting the shape of the HTML? How is this beneficial?
In short, I am not convinced that the test coverage (past observed) that this test provides is worth the pain we have experienced from it.

@scottbommarito, tracked here: https://github.com/NuGet/NuGetGallery/issues/6933.


About Master slave database?

About Master slave database?

You could implement it yourself. Slim-PDO is merely for tool to easily make and execute SQL queries.


Aggregation should skip properties that don't exist

It should also skip properties that are null - i.e. null values should be treated as though the property does not exist.

merged into master


Add support for letting restic run certain commands with sudo

Sometimes, you will need to run an application's backup output tool as root. This change allows you to selectively whitelist some commands, so that you do not have to run restic as root in full.

This is tested and works well, causing no regressions. Just not merging it myself to not be rude :)

@TheLastProject you are doing more work in this repo than I do :smile: Merge when you think code is ok, I won't mind :smile:

Sounds good. Also, maybe time for a new release? Restic 0.9.4 being the default now and all :)

CI needs to be fixed first, without it I cannot do a release :(
I'll take a look at it today or tomorrow.


finch compose run [ARGS...] is not working with specific command

Describe the bug
trying to use finch compose run as docker-compose run, but not working.
finch compose run --remove-orphans web rails new . -d mysql --force --skip-test --javascript=importmap
FATA[0000] unknown flag: --force
FATA[0000] exit status 1

finch compose run db ls -d
FATA[0000] currently flag -i and -d cannot be specified together (FIXME)
FATA[0000] exit status 1

seems like finch does not pass the command to the container, but interprets it as a finch command.
Steps to reproduce
Dockerfile
FROM ruby:3.1.0

ENV APP_PATH /myapp

WORKDIR $APP_PATH

COPY Gemfile $APP_PATH/Gemfile
COPY Gemfile.lock $APP_PATH/Gemfile.lock

RUN bundle install

COPY . $APP_PATH

COPY entrypoint.sh /usr/bin/
RUN chmod +x /usr/bin/entrypoint.sh
ENTRYPOINT ["entrypoint.sh"]
EXPOSE 3000

CMD ["rails", "server", "-b", "<IP_ADDRESS>"]

entrypoint.sh
#!/bin/bash
set -e

# Remove a potentially pre-existing server.pid for Rails.
rm -f /myapp/tmp/pids/server.pid

# Then exec the container's main process (what's set as CMD in the Dockerfile).
exec "$@"

docker-compose.yml
version: "3.7"

services:
  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: password
    ports:
      - '3306:3306'
    volumes:
      - mysql-data:/var/lib/mysql

  web:
    build:
      context: .
      dockerfile: Dockerfile
    command: bash -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '<IP_ADDRESS>'"
    ports:
      - "3000:3000"
    volumes:
      - .:/myapp
    environment:
      RAILS_ENV: development
    depends_on:
      - db
volumes:
  mysql-data:

touch Gemfile.lock
finch compose build
finch compose run --remove-orphans web rails new . -d mysql --force --skip-test --javascript=importmap

# Success without options
finch compose run --remove-orphans web rails new .

Expected behavior
working like docker-compose

This behavior is from containerd/nerdctl because finch uses it internally. And containerd/nerdctl uses spf13/cobra that is not accepted extra arguments with hyphens.
If you want to run the command anyway, you can run it by inserting -- before service, like the following command.
finch compose run --remove-orphans -- web rails new . -d mysql --force --skip-test --javascript=importmap

Thanks for the response @sawadashota. That is correct.

This issue should be fixed now in nerdctl.
https://github.com/containerd/nerdctl/issues/1666


Fixed #29654 -- Made Truncator use ellipsis character instead of three dots. -- Test cases and .po

Additional patch to PR #10280
Fixed the test cases and changed the .po-files for all the translations.
Additional fixes to https://code.djangoproject.com/ticket/29654#ticket

po files shouldn't be changed as those updates have to be made in Transifex. In the future, please run the tests locally and fix failures before creating a pull request.

Withdrawn.

@timgraham Should we just dump this PO and redo it the right way?

No need to open a new PR, you can amend this one.

Commits not preserved :(

Let us reopen #10280 and skip this PR. @timgraham


Prevent memory leaks

We have bunch of memory leaks on pages like Stake, Trade etc. where the latest data are necessary.
Memory leaks happen when pages are rerendered before our async connect and fetch data functions are done.

Most of them are now fixed.
The only one remaining is present in header.js connection indicator.


[SPARK-42878][CONNECT] The table API in DataFrameReader could also accept options

What changes were proposed in this pull request?

It turns out that spark.read.option.table is a valid call chain and the table API does accept options when open a table.
Existing Spark Connect implementation does not consider it.
Why are the changes needed?

Feature parity.
Does this PR introduce any user-facing change?

NO
How was this patch tested?

UT

@hvanhovell

@amaliujia can you add a test that checks if the options are properly propagated from client to server?

@hvanhovell existing codebase uses this to verify the options:
  test("SPARK-32844: DataFrameReader.table take the specified options for V1 relation") {
    withSQLConf(SQLConf.USE_V1_SOURCE_LIST.key -> "parquet") {
      withTable("t") {
        sql("CREATE TABLE t(i int, d double) USING parquet OPTIONS ('p1'='v1', 'p2'='v2')")

        val df = spark.read.option("P2", "v2").option("p3", "v3").table("t")
        val options = df.queryExecution.analyzed.collectFirst {
          case r: LogicalRelation => r.relation.asInstanceOf[HadoopFsRelation].options
        }.get
        assert(options("p2") == "v2")
        assert(options("p3") == "v3")
      }
    }
  }

However this won't work for Spark Connect. Do you know if we have another way to achieve it?

@hvanhovell
oh are you thinking about golden file based tests?

Merged to master and branch-3.4.


The Developer name cannot be empty

Currently the generator doesn't validate that you enter anything in the developer name question

Fixed


Add OSI JSON API checking for OSI Approved

Adds warning when OSI flag does not match the OSI API
Resolves issue #20
Signed-off-by: Gary O'Neall<EMAIL_ADDRESS>

pang422


Please add documents to Component Select's property "onChange" when property "multiple" is set

Please add more documents to Component Select's property onChange when property multiple is set.
I found when multiple is set, the first argument provided to onChange hold a value of type array, namely:
<Select
  multiple
  onChange={({ target: {value} }) {
      console.log(value); // something like [1, 2, 3]
  }}
>
...
</Select>

This is a very convenient behavior, but I've made an array myself to hold multiple Select's value when I first use this Component. So I guess it should be elaborated in documents. Thanks!

[x] I have searched the issues of this repository and believe that this is not a duplicate.

Your Environment

Tech
Version

Material-UI
v1.0.0-beta.38

React

browser

etc

@xiechao06 This behavior is shown in the multiple select demo. Using event.target.value is the idiomatic way to handle forms in React. Any idea how we can improve the documentation?


Feature/replace lancedb

Description
This pr is extension to #1000
This pr basically replaces the lancedb implementation with pylance

Related Issues

Checklist

[ ] Is this code covered by new or existing unit tests or integration tests?
[ ] Did you run make test successfully?
[ ] Do new classes, functions, methods and parameters all have docstrings?
[ ] Were existing docstrings updated, if necessary?
[ ] Was external documentation updated, if necessary?

Additional Notes or Comments

Codecov Report
Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (b4d38a9) 78.84% compared to head (2a44dda) 79.04%.
Report is 2 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1008      +/-   ##
==========================================
+ Coverage   78.84%   79.04%   +0.19%
==========================================
  Files         102      101       -1
  Lines        6306     6250      -56
==========================================
- Hits         4972     4940      -32
+ Misses       1334     1310      -24

Files
Coverage Δ

superduperdb/base/config.py
100.00% <100.00%> (ø)

superduperdb/db/base/backends.py
100.00% <100.00%> (ø)

superduperdb/db/base/db.py
65.71% <100.00%> (+1.14%)
:arrow_up:

superduperdb/vector_search/base.py
94.31% <ø> (-0.13%)
:arrow_down:

superduperdb/vector_search/lance.py
98.21% <98.21%> (ø)

... and 1 file with indirect coverage changes

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


Add demo gif to README

This looks like awesome work! Thanks to everyone involved.
As a person casually browsing jupyterlab extensions on GitHub I came across this repo and had no idea what it did. I felt like I had to do a reasonable amount of reading and clicking links before figuring it out. Given that you have some awesome gifs in the usage section I think it would be awesome to have one up front to quickly show people what the extension does.

Thank you Jacob! Yeah that helps a lot.


Feature/wemo power energy

Im not convinced in the energy meter reporting of this device at all, in fact it may be worthwhile to only report powerMeter capabilities for the device since it is very inconsistent in its values for energy reports (total energy fluctuates a lot including negative values, and it seems very high)
This implementation is based off the way device report payloads are interpreted here and here

Due to the weird energy reports I have gotten from the device I see a few options to move this PR forward:

Remove energyMeter cap from the insight devices
Leave it in there as it is now, but implement a profile switch based on a preference value, so that users can opt into the energy reporting, which is somewhat suspect
Implement energy reporting in software. The energy_today_Wh field that is reported seems to be accurate and could be used to keep a running total for the device and periodically emit that total. This would also allow for resetting of the energyMeter since we control the total rather than the device
Implement the powerConsumptionReport capability instead. This sort of seems like option 3 but the capability is setup for it. Although, I am not sure how accurate all the fields are that would be needed from the device, and if the device is actually resetting the energy totals daily.

Since I suggested it, I'm most partial to option 2.

@cjswedes Should we close this PR?

I would prefer to leave it available for any developer out there to pick up, since there was non-trivial engineering time put into figuring out the message format for energy from these devices. If it needs to be closed, I will move it to a personal repo to avoid losing the work.


Create Posts “goodbye-2023-welcome-2024”

Automatically generated by Netlify CMS

👷 Deploy Preview for shiny-babka-998c7e processing.

Name
Link

🔨 Latest commit
97ea0a768c6d739cc34f61dc8d23bc0d6f9d6039

🔍 Latest deploy log
https://app.netlify.com/sites/shiny-babka-998c7e/deploys/659bea3d127f8100085e78e2


Nice!

I just wanted to say that i had a look at your code and i wanted to thank you!
Good job you did there, cost you some time for sure. I love it. Couldnt help myself but reading everything.  The seeks cost to much 2! But i fixed that by just caching the nodes in a linkedhashmap for N seconds, untill another thread cleans it up if its out of time.
Didn't enjoy a project this much in a while :3

hi - thanks for the kind words. Since this is not a technical issue am closing it :).


Update names.csv

I've added the nicknames "Hap" and "Haps" to Henry, Harry, Harold. I also added the canonical Harrison and nicknames "Harry", "Hap" and "Haps"

closed via #55


Make vectorize threadsafe

Blaze was crashing the LLVM by crashing calling vectorize in multiple threads.

Thanks for the report. Would you have a simple reproducer?


Possible EventEmitter memory leak detected

Hi guys!
I have a problem :)
I run the command "npm run dev", opened application in a browser, after which the "node" runs multiple processes, it is normal behavior? (see screenshot), because of this all hangs, also get an error - Possible EventEmitter memory leak detected. any idea? thanks
node version - 6.3.0

After several hours of searching, I finally found a solution. The problem was in the library<EMAIL_ADDRESS>downgrade to 0.3.0 @, and it solves the problem.


NotImplementedError!: Separable Conv1D is not supported in current MXNet

Description
Getting error that mxnet does not support SaparableConv1d with mxnet 1.5.0 and CUDA 10.1. This error will not occur when running the same code in tensorflow 1.14.0.
Error Message
Traceback (most recent call last):
File "crashModel.py", line 24, in
model = Lstm()
File "crashModel.py", line 17, in Lstm
model.add(SeparableConv1D(filters = 64, kernel_size = (1)))
File "/root/anaconda3/envs/mxnet/lib/python3.6/site-packages/keras/engine/sequential.py", line 181, in add
output_tensor = layer(self.outputs[0])
File "/root/anaconda3/envs/mxnet/lib/python3.6/site-packages/keras/engine/base_layer.py", line 470, in call
output = self.call(inputs, **kwargs)
File "/root/anaconda3/envs/mxnet/lib/python3.6/site-packages/keras/layers/convolutional.py", line 1393, in call
dilation_rate=self.dilation_rate)
File "/root/anaconda3/envs/mxnet/lib/python3.6/site-packages/keras/backend/mxnet_backend.py", line 3773, in separable_conv1d
raise NotImplementedError('MXNet Backend: Separable Conv1D not supported yet!')
NotImplementedError: MXNet Backend: Separable Conv1D not supported yet!
To Reproduce
import os
os.environ["CUDA_VISIBLE_DEVICES"] = "2"
os.environ["KERAS_BACKEND"] = 'mxnet'
from keras.models import Sequential
from keras.layers import Dense, Dropout, Embedding, LSTM, Bidirectional, Reshape, Input, SeparableConv1D, RepeatVector
def Lstm():
model = Sequential()
model.add(Embedding(input_dim = 140, output_dim = 128))
model.add(Bidirectional(LSTM(128)))
model.add(Dropout(0.5))
model.add(Dense(64, activation='relu'))
model.add(Dropout(0.5))
model.add(RepeatVector(3))
model.add(SeparableConv1D(filters = 64, kernel_size = (1)))
model.add(Reshape((192, )))
model.add(Dense(64, activation='relu'))
model.add(Dense(2))
return model
model = Lstm()
model.summary()
Steps to reproduce
(Paste the commands you ran that produced the error.)

create a python file and paste code above in it.
set os.environ["KERAS_BACKEND"] = tensorflow and run the file in tensorflow, the model works well.
set os.environ["KERAS_BACKEND"] = mxnet and run the file in mxnet, programme reports an error.

What have you tried to solve it?

I used to run the file in the version of 1.5.0. When the error occured, I updated mxnet to 1.8.0, but it didn't worked.

Environment

Environment Information
----------System Info----------
Platform     : Linux-4.15.0-123-generic-x86_64-with-debian-stretch-sid
system       : Linux
node         : 3bb941e39736
release      : 4.15.0-123-generic
version      : #126-Ubuntu SMP Wed Oct 21 09:40:11 UTC 2020
----------Python Info----------
Version      : 3.6.12
Compiler     : GCC 7.3.0
Build        : ('default', 'Sep  8 2020 23:10:56')
Arch         : ('64bit', '')
mxnet version 1.8.0
cuda version 10.1
tensorflow version 1.14.0

cc @sandeep-krishnamurthy

@szha @sandeep-krishnamurthy  gentle ping~

I think we do support depthwise convolution. One just needs to set the number of groups to be the same as channels with the convolution op: https://mxnet.apache.org/versions/1.8.0/api/python/docs/api/ndarray/ndarray.html?highlight=convolution#mxnet.ndarray.Convolution
However I'm not familiar with where such support can be added.

@szha
In this case, the code works in tensorflow and I run the same code in cntk in which it do not crash. to make the code work in mxnet, how should I modify the model? e.g. modifying some parameters?

I think the keras-mxnet integration needs update to include depth wise convolution support

Till keras-mxnet <IP_ADDRESS>, which is the latest version, the crash isn't fixed.


indilib: 1.8.7 -> 1.8.8

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/indilib/indi/releases.
meta.description for indilib is: "Implementation of the INDI protocol for POSIX operating systems"
meta.homepage for indilib is: "https://www.indilib.org/"
meta.changelog for indilib is: ""
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 1.8.8 with grep in /nix/store/fnvndm5zhjh71bf6psp3k244ni734c26-indilib-1.8.8

directory tree listing: https://gist.github.com/19804651689a400eaef554fd2927f09d

du listing: https://gist.github.com/e275a578c7e623493ccdf7fe65435e90

Rebuild report (if merged into master) (click to expand)

5 total rebuild path(s)

3 package rebuild(s)

3 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
indilib
kstars
phd2

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/fnvndm5zhjh71bf6psp3k244ni734c26-indilib-1.8.8 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A indilib https://github.com/r-ryantm/nixpkgs/archive/fdb8bd5299ccd9c678858e55fc97355f5a39b06b.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/fnvndm5zhjh71bf6psp3k244ni734c26-indilib-1.8.8
ls -la /nix/store/fnvndm5zhjh71bf6psp3k244ni734c26-indilib-1.8.8/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

3 packages built:

indilib
kstars
phd2

Maintainer pings
cc @hjones2199 for testing.

Changelog
  + New HOBYM Crux telescope driver (#1295)
  + New Rainbow focuser driver (#1304)
  + New ActiveFocuser driver release (#1301)
  + 10Micron: UnattendedFlip handling, implements #1276 (#1298)
  + Bugfix/sat track lx200 julian day (#1305)
  + Improved serial port auto-search.
  + Refactor/satellite tracking properties -> Moving properties to a higher abstraction layer (#1300)
  + SkyWatcher Alt-Az driver improvements.
  + Indibase/refactoring - update INDI::Property (#1302)
  + Update of SmartFocus driver (#1275)
  + Add new helper methods to the AlignmentSubsystemForDrivers (Alt/Az) (#1308)
  + Streammanager/chrono - Fix the 24h time limit. (#1278)
  + Fix remote driver not sending properties to upstream server
  + Delay calculation in indicommon and indicorrelator (#1277)
  + Indidriver/refactoring - fix memory leak, increase performance (#1281)
  + Streammanager/refactoring (#1280)
  + Move absolute position bugfix (#1285)
  + Use of the common mkpath function (#1288)
  + Sesto Senso 2: Support for displaying 12V input voltage. (#1289)
  + Add Microsoft LifeCam Cinema to pixelSizeInfo (#1314)
  + Sesto Senso 2: Log & display firmware version (#1292)
  + fix: inline methods that use unlinked functions (#1312)

Changelog
  + New HOBYM Crux telescope driver (#1295)
  + New Rainbow focuser driver (#1304)
  + New ActiveFocuser driver release (#1301)
  + 10Micron: UnattendedFlip handling, implements #1276 (#1298)
  + Bugfix/sat track lx200 julian day (#1305)
  + Improved serial port auto-search.
  + Refactor/satellite tracking properties -> Moving properties to a higher abstraction layer (#1300)
  + SkyWatcher Alt-Az driver improvements.
  + Indibase/refactoring - update INDI::Property (#1302)
  + Update of SmartFocus driver (#1275)
  + Add new helper methods to the AlignmentSubsystemForDrivers (Alt/Az) (#1308)
  + Streammanager/chrono - Fix the 24h time limit. (#1278)
  + Fix remote driver not sending properties to upstream server
  + Delay calculation in indicommon and indicorrelator (#1277)
  + Indidriver/refactoring - fix memory leak, increase performance (#1281)
  + Streammanager/refactoring (#1280)
  + Move absolute position bugfix (#1285)
  + Use of the common mkpath function (#1288)
  + Sesto Senso 2: Support for displaying 12V input voltage. (#1289)
  + Add Microsoft LifeCam Cinema to pixelSizeInfo (#1314)
  + Sesto Senso 2: Log & display firmware version (#1292)
  + fix: inline methods that use unlinked functions (#1312)


Preview Server Stopped Working

Problem
After developing my site for about an hour this morning, then the preview server went down without any warning or error messages. The site is now previewing the LIVE site, which has no styling -- since it references localhost:8080. Now gives me a bunch of certificate warnings instead:

I've tried the following:

Removed the css I had just added. No luck there.
Restarted slate with yarn start
That didn't work, so tried yarn build and yarn deploy
Tried yarn watch, which didn't work either.
 Still no luck.

Everything was working an hour ago.
Replication steps
There are no replication steps. It randomly stopped after saving changes to a scss file.
More Information
I'm using Chrome 68.0.3440.106 on Mac OS High Sierra
Slate v1 -- I also have a previous Slate v0 installation
Bash 4.4.23
Yarn 1.9.4

Hey @callaginn -- please see the note in step 4 of the Getting Started Guide

I had actually done that when I first set up the site last week. I guess it forgot its settings or something. I'm clearing Chrome caches constantly; maybe that has something to do with it?


Allow to hide element for mobile display

Would be great to have the possibilitie of hiding an element (text or illustration for example), that we want on desktop but not on mobile as <mj-hide> or the possibilitie to add it has an <mj-attribute> only for mobile purpose.

Like for https://github.com/mjmlio/mjml/issues/378, the issue is that such a feature would rely heavily on media queries, except if you have something else in mind to achieve it?

Hello @Lea-lynx, media queries are supported in v3.3.0 (now in beta). Feedback welcome!
Example of implementation: https://mjml.io/try-it-live/HkokV_Due
PS: be careful, media queries are far from being supported in every email clients

MJML v3.3.0 is out, fixing this issue! It's now easy to achieve this behaviour using media queries. Thanks for submitting, it's a great new feature for MJML.
To install: npm install mjml

Is it possible to hide mj-image with this feature?

... or an entire section? It seems illegal to use id on either section or column elements, is here a known workaround for this?

In next version 3.3.3, you will be able to add css-class to any mj-element so you can target it with media queries in mj-style

Hi @iRyusa,
When is the new 3.3.3 version coming out?
Thanks.

hey @vilcuRob, it's going to be released in the coming weeks. We're now trying to get a fully clickable button to work.


Try to speed up data loading providing for markets page

https://markets.atomicdex.io/markets
and filter out zero data

was able to speed up it drastically by using the cache


Full name of the foundation is not readable anywhere on openssf.org on mobile

This report is for the openssf.org homepage. I wasn't sure where to submit it, please let me know if there's a better place.
The current openssf.org homepage looks pretty good on mobile, except for the fact that nowhere on the page can you see the full name of the foundation. Although the acronym expansion is in the logo in the navbar, the text is too small to read without zooming in:

In light of the recent xz security vulnerability there could be another surge in interest in security concerns in the open source community, similar to Heartbleed, which led to the creation of the Core Infrastructure Initiative, the precursor to the OSSF. So it's more important now then ever to put out effective branding that conveys trust and professionalism.

We have made the text slightly larger.

Still illegible in the logo on mobile, but the acronym is expanded in the sub-hero, so not such an issue anymore. Thanks!


application stuck in loop & 100% cpu

Hi, thanks for this application.
I am trying to get it working with a Framework laptop connected to two 1440p displays via Thunderbolt3 dock. It worked as expected at first. I played around with some scaling settings in cfg and so on. Then I connected the displays to the dock, one by one, and they also worked as expected, and closing the lid disabled the internal display.
However, then I tried to change the refresh rate. One display auto-selected ~144hz by default, and the other ~100hz, so I wanted to experiment and try 144 or 120hz on the other. Now, there might be some incompatibility between this high refresh rate through the dock, or maybe the HDMI connection, but i still wanted to experiment. Once I saved the config, the all system got very slow, fans spun up and from what I could tell, the CPU was 100% loaded. In logs I see that the program is failing to set some modes, and then falls back to the preferred mode, and reports (no mode) on this display, but at the same time reports that the mode is changed successfully. This happens many times per second.
Worth noting that during this, even though it reported (no mode), both external displays were still working, and I could successfully open terminals on either of them (though they were near unusable, as you would expect with an overloaded cpu). During this problem, I was able to change the cfg file to attempt removing the custom mode/refresh setting, but that did not help.
This went on until I unplugged the dock with the displays. A similar behaviour happened later when I powered off/on the dock (after clean PC restart), without playing with the config settings, but I did not save the log from that time.
While it's possible that this was caused by some incompatibility between dock/display, I think the program should not cause a never-ending cpu overloaded loop in any cases.\
Attaching partial log from when the issue started (full log is ~45k lines)
I [21:30:11] DP-5 Arrived:
I [21:30:11]   info:
I [21:30:11]     name:     'DP-5'
I [21:30:11]     desc:     'Goldstar Company Ltd 27GL850 912NTLEBE528 (DP-5)'
I [21:30:11]     width:    700mm
I [21:30:11]     height:   390mm
I [21:30:11]     dpi:      93.34 @ 2560x1440
I [21:30:11]     mode:     3840 x 2160 @  60 Hz   60,000 mHz  59,940 mHz
I [21:30:11]     mode:     3840 x 2160 @  50 Hz   50,000 mHz
I [21:30:11]     mode:     3840 x 2160 @  30 Hz   30,000 mHz  29,970 mHz
I [21:30:11]     mode:     3840 x 2160 @  25 Hz   25,000 mHz
I [21:30:11]     mode:     3840 x 2160 @  24 Hz   24,000 mHz  23,976 mHz
I [21:30:11]     mode:     2560 x 1440 @ 144 Hz  143,999 mHz
I [21:30:11]     mode:     2560 x 1440 @ 120 Hz  119,998 mHz
I [21:30:11]     mode:     2560 x 1440 @ 100 Hz   99,946 mHz (preferred)
I [21:30:11]     mode:     2560 x 1440 @  60 Hz   59,951 mHz
I [21:30:11]     mode:     1920 x 1080 @ 120 Hz  120,000 mHz 119,880 mHz
I [21:30:11]     mode:     1920 x 1080 @  60 Hz   60,000 mHz  60,000 mHz  59,940 mHz
I [21:30:11]     mode:     1920 x 1080 @  50 Hz   50,000 mHz
I [21:30:11]     mode:     1680 x 1050 @  60 Hz   59,883 mHz
I [21:30:11]     mode:     1600 x  900 @  60 Hz   60,000 mHz
I [21:30:11]     mode:     1280 x 1024 @  75 Hz   75,025 mHz
I [21:30:11]     mode:     1280 x 1024 @  60 Hz   60,020 mHz
I [21:30:11]     mode:     1280 x  800 @  60 Hz   59,910 mHz
I [21:30:11]     mode:     1280 x  720 @  60 Hz   60,000 mHz  60,000 mHz  59,940 mHz
I [21:30:11]     mode:     1280 x  720 @  50 Hz   50,000 mHz
I [21:30:11]     mode:     1024 x  768 @  75 Hz   75,029 mHz
I [21:30:11]     mode:     1024 x  768 @  60 Hz   60,004 mHz
I [21:30:11]     mode:      800 x  600 @  75 Hz   75,000 mHz
I [21:30:11]     mode:      800 x  600 @  60 Hz   60,317 mHz
I [21:30:11]     mode:      720 x  576 @  50 Hz   50,000 mHz
I [21:30:11]     mode:      720 x  480 @  60 Hz   60,000 mHz  59,940 mHz
I [21:30:11]     mode:      640 x  480 @  75 Hz   75,000 mHz
I [21:30:11]     mode:      640 x  480 @  60 Hz   60,000 mHz  59,940 mHz  59,940 mHz
I [21:30:11]   current:
I [21:30:11]     scale:    1.000
I [21:30:11]     position: 1504,0
I [21:30:11]     mode:     2560x1440@100Hz (99,946mHz) (preferred)
I [21:30:11]
I [21:30:11] eDP-1 Changing:
I [21:30:11]   from:
I [21:30:11]     scale:    1.500
I [21:30:11]     position: 0,0
I [21:30:11]     mode:     2256x1504@60Hz (59,999mHz) (preferred)
I [21:30:11]   to:
I [21:30:11]     position: 0,437
I [21:30:13]
I [21:30:13] DP-6 Arrived:
I [21:30:13]   info:
I [21:30:13]     name:     'DP-6'
I [21:30:13]     desc:     'Goldstar Company Ltd LG ULTRAGEAR 110MADHLT466 (DP-6)'
I [21:30:13]     width:    700mm
I [21:30:13]     height:   390mm
I [21:30:13]     dpi:      93.34 @ 2560x1440
I [21:30:13]     mode:     3840 x 2160 @  60 Hz   60,000 mHz  59,940 mHz
I [21:30:13]     mode:     3840 x 2160 @  50 Hz   50,000 mHz
I [21:30:13]     mode:     3840 x 2160 @  30 Hz   30,000 mHz  29,970 mHz
I [21:30:13]     mode:     3840 x 2160 @  25 Hz   25,000 mHz
I [21:30:13]     mode:     3840 x 2160 @  24 Hz   24,000 mHz  23,976 mHz
I [21:30:13]     mode:     2560 x 1440 @ 144 Hz  143,933 mHz (preferred)
I [21:30:13]     mode:     2560 x 1440 @ 120 Hz  119,998 mHz
I [21:30:13]     mode:     2560 x 1440 @  60 Hz   59,951 mHz
I [21:30:13]     mode:     1920 x 1080 @ 120 Hz  120,000 mHz 119,880 mHz
I [21:30:13]     mode:     1920 x 1080 @  60 Hz   60,000 mHz  60,000 mHz  59,940 mHz
I [21:30:13]     mode:     1920 x 1080 @  50 Hz   50,000 mHz
I [21:30:13]     mode:     1280 x  720 @  60 Hz   60,000 mHz  59,940 mHz
I [21:30:13]     mode:     1280 x  720 @  50 Hz   50,000 mHz
I [21:30:13]     mode:     1024 x  768 @  60 Hz   60,004 mHz
I [21:30:13]     mode:      800 x  600 @  60 Hz   60,317 mHz
I [21:30:13]     mode:      720 x  576 @  50 Hz   50,000 mHz
I [21:30:13]     mode:      720 x  480 @  60 Hz   60,000 mHz  59,940 mHz
I [21:30:13]     mode:      640 x  480 @  60 Hz   60,000 mHz  59,940 mHz  59,940 mHz
I [21:30:13]   current:
I [21:30:13]     scale:    1.000
I [21:30:13]     position: 1504,0
I [21:30:13]     mode:     2560x1440@144Hz (143,933mHz) (preferred)
W [21:30:13]
W [21:30:13] WARNING: Changes cancelled, retrying
I [21:31:59]
I [21:31:59] Lid closed
I [21:31:59]
I [21:31:59] eDP-1 Changing:
I [21:31:59]   from:
I [21:31:59]     scale:    1.500
I [21:31:59]     position: 0,0
I [21:31:59]     mode:     2256x1504@60Hz (59,999mHz) (preferred)
I [21:31:59]     (lid closed)
I [21:31:59]   to:
I [21:31:59]     (disabled)
I [21:31:59]
I [21:31:59] DP-5 Changing:
I [21:31:59]   from:
I [21:31:59]     scale:    1.000
I [21:31:59]     position: 4064,0
I [21:31:59]     mode:     2560x1440@100Hz (99,946mHz) (preferred)
I [21:31:59]   to:
I [21:31:59]     position: 0,0
I [21:31:59]
I [21:31:59] DP-6 Changing:
I [21:31:59]   from:
I [21:31:59]     scale:    1.000
I [21:31:59]     position: 1504,0
I [21:31:59]     mode:     2560x1440@144Hz (143,933mHz) (preferred)
I [21:31:59]   to:
I [21:31:59]     position: 2560,0
I [21:31:59]
I [21:31:59] Changes successful
I [21:41:29]
I [21:41:29] Reloading configuration file: /home/black/.config/way-displays/cfg.yaml
I [21:41:29]   Arrange in a ROW aligned at the BOTTOM
I [21:41:29]   Auto scale: ON
I [21:41:29]   Scale:
I [21:41:29]     eDP-1: 1.500
I [21:41:29]   Mode:
I [21:41:29]     Goldstar Company Ltd 27GL850 912NTLEBE528: 2560x1440
I [21:41:29]
I [21:41:29] DP-5 Changing:
I [21:41:29]   from:
I [21:41:29]     scale:    1.000
I [21:41:29]     position: 0,0
I [21:41:29]     mode:     2560x1440@100Hz (99,946mHz) (preferred)
I [21:41:29]   to:
I [21:41:29]     mode:     2560x1440@144Hz (143,999mHz)
E [21:41:29]
E [21:41:29] ERROR: Changes failed
E [21:41:29] ERROR:   DP-5:
E [21:41:29] ERROR:     mode:     2560x1440@144Hz (143,999mHz)
I [21:41:29]
I [21:41:29] DP-5 Changing:
I [21:41:29]   from:
I [21:41:29]     scale:    1.000
I [21:41:29]     position: 0,0
I [21:41:29]     (no mode)
I [21:41:29]   to:
I [21:41:29]     mode:     2560x1440@120Hz (119,998mHz)
E [21:41:29]
E [21:41:29] ERROR: Changes failed
E [21:41:29] ERROR:   DP-5:
E [21:41:29] ERROR:     mode:     2560x1440@120Hz (119,998mHz)
I [21:41:29]
I [21:41:29] DP-5 Changing:
I [21:41:29]   from:
I [21:41:29]     scale:    1.000
I [21:41:29]     position: 0,0
I [21:41:29]     (no mode)
I [21:41:29]   to:
I [21:41:29]     mode:     2560x1440@100Hz (99,946mHz) (preferred)
I [21:41:29]
I [21:41:29] Changes successful
I [21:41:29]
I [21:41:29] DP-5 Changing:
I [21:41:29]   from:
I [21:41:29]     scale:    1.000
I [21:41:29]     position: 0,0
I [21:41:29]     (no mode)
I [21:41:29]   to:
I [21:41:29]     mode:     2560x1440@100Hz (99,946mHz) (preferred)
I [21:41:29]
I [21:41:29] Changes successful
I [21:41:29]
I [21:41:29] DP-5 Changing:
I [21:41:29]   from:
I [21:41:29]     scale:    1.000
I [21:41:29]     position: 0,0
I [21:41:29]     (no mode)
I [21:41:29]   to:
I [21:41:29]     mode:     2560x1440@100Hz (99,946mHz) (preferred)
I [21:41:30]
I [21:41:30] Changes successful
[....] truncated
[....] end of log follows:
I [21:45:40] DP-5 Changing:
I [21:45:40]   from:
I [21:45:40]     scale:    1.000
I [21:45:40]     position: 0,0
I [21:45:40]     (no mode)
I [21:45:40]   to:
I [21:45:40]     mode:     3840x2160@60Hz (59,940mHz)
E [21:45:40]
E [21:45:40] ERROR: Changes failed
E [21:45:40] ERROR:   DP-5:
E [21:45:40] ERROR:     mode:     3840x2160@60Hz (59,940mHz)
I [21:45:40]
I [21:45:40] DP-5 Changing:
I [21:45:40]   from:
I [21:45:40]     scale:    1.000
I [21:45:40]     position: 0,0
I [21:45:40]     (no mode)
I [21:45:40]   to:
I [21:45:40]     mode:     3840x2160@50Hz (50,000mHz)
I [21:45:51]
I [21:45:51] DP-5 Departed:
I [21:45:51]     name:     'DP-5'
I [21:45:51]     desc:     'Goldstar Company Ltd 27GL850 912NTLEBE528 (DP-5)'
I [21:45:51]
I [21:45:51] DP-6 Departed:
I [21:45:51]     name:     'DP-6'
I [21:45:51]     desc:     'Goldstar Company Ltd LG ULTRAGEAR 110MADHLT466 (DP-6)'
wl_display@1: error 1: invalid arguments for<EMAIL_ADDRESS>E [21:45:51]
E [21:45:51] ERROR: wl_display_dispatch_pending failed at src/server.c:148, exiting: 22 Invalid argument
E [21:45:51]
E [21:45:51] ERROR: Please raise an issue: https://github.com/alex-courtis/way-displays/issues
E [21:45:51] ERROR: Attach this log and describe the events that occurred before this failure.

I will test some more tomorrow, let me know if any additional info is needed.

Thanks for the detailed report.
Yes: monitors can be easily upset by HDMI extenders, docks, bad cables etc. way-displays should handle that, trying modes in descending order until a working one is found. Falling back to 2560x1440@100Hz (99,946mHz) is working as intended.
However... getting stuck in a loop after successfully making that change is definitely not working as intended. That will be fixed: cop. with (no mode) being returned after a successful change.
The final ERROR is to be expected, as we are unplugging during one of the constant configuration changes. Under normal operating conditions that is extremely unlikely.
I will be grateful for your testing a fix; I have a finite amount of hardware available for testing.

Possibly offtopic: what is the native resolution of your monitors? They report 2160p however you have said that they are 1440p. What happens when you attempt to use 2160p?
I have seen logs from a few other users with the same situation.

FYI there is a command line client available for experimenting with changes before persisting them.

Fix applied. I would be grateful if you could test:
git clone git@github.com:alex-courtis/way-displays.git
cd way-displays
git checkout 33-successful-modeset-infinite-loop
make
sudo make install

When you are done you can
sudo make uninstall

Tested the fix on my configuration, seems to be working, though way-displays did crash once.
First attempt - start with eDP-1 only, then plug in dock (with both displays attached) - logged warning but works - then attempt activating 144Hz. Program crashes, but displays stay working.
I [17:33:47] way-displays version 1.5.1-SNAPSHOT
I [17:33:47]
I [17:33:47] Found configuration file: /home/black/.config/way-displays/cfg.yaml
I [17:33:47]
I [17:33:47] Active configuration:
I [17:33:47]   Arrange in a ROW aligned at the BOTTOM
I [17:33:47]   Auto scale: OFF
I [17:33:47]   Scale:
I [17:33:47]     eDP-1: 1.250
I [17:33:47]
I [17:33:47] Monitoring lid device: /dev/input/event0
I [17:33:47]
I [17:33:47] Lid open
I [17:33:47]
I [17:33:47] eDP-1 Arrived:
I [17:33:47]   info:
I [17:33:47]     name:     'eDP-1'
I [17:33:47]     desc:     'Unknown 0x095F 0x00000000 (eDP-1)'
I [17:33:47]     width:    280mm
I [17:33:47]     height:   190mm
I [17:33:47]     dpi:      202.86 @ 2256x1504
I [17:33:47]     mode:     2256 x 1504 @  60 Hz   59,999 mHz (preferred)
I [17:33:47]   current:
I [17:33:47]     scale:    2.000
I [17:33:47]     position: 0,0
I [17:33:47]     mode:     2256x1504@60Hz (59,999mHz) (preferred)
I [17:33:47]
I [17:33:47] eDP-1 Changing:
I [17:33:47]   from:
I [17:33:47]     scale:    2.000
I [17:33:47]     position: 0,0
I [17:33:47]     mode:     2256x1504@60Hz (59,999mHz) (preferred)
I [17:33:47]   to:
I [17:33:47]     scale:    1.250
I [17:33:47]
I [17:33:47] Changes successful
I [17:35:09]
I [17:35:09] DP-5 Arrived:
I [17:35:09]   info:
I [17:35:09]     name:     'DP-5'
I [17:35:09]     desc:     'Goldstar Company Ltd 27GL850 912NTLEBE528 (DP-5)'
I [17:35:09]     width:    700mm
I [17:35:09]     height:   390mm
I [17:35:09]     dpi:      93.34 @ 2560x1440
I [17:35:09]     mode:     3840 x 2160 @  60 Hz   60,000 mHz  59,940 mHz
I [17:35:09]     mode:     3840 x 2160 @  50 Hz   50,000 mHz
I [17:35:09]     mode:     3840 x 2160 @  30 Hz   30,000 mHz  29,970 mHz
I [17:35:09]     mode:     3840 x 2160 @  25 Hz   25,000 mHz
I [17:35:09]     mode:     3840 x 2160 @  24 Hz   24,000 mHz  23,976 mHz
I [17:35:09]     mode:     2560 x 1440 @ 144 Hz  143,999 mHz
I [17:35:09]     mode:     2560 x 1440 @ 120 Hz  119,998 mHz
I [17:35:09]     mode:     2560 x 1440 @ 100 Hz   99,946 mHz (preferred)
I [17:35:09]     mode:     2560 x 1440 @  60 Hz   59,951 mHz
I [17:35:09]     mode:     1920 x 1080 @ 120 Hz  120,000 mHz 119,880 mHz
I [17:35:09]     mode:     1920 x 1080 @  60 Hz   60,000 mHz  60,000 mHz  59,940 mHz
I [17:35:09]     mode:     1920 x 1080 @  50 Hz   50,000 mHz
I [17:35:09]     mode:     1680 x 1050 @  60 Hz   59,883 mHz
I [17:35:09]     mode:     1600 x  900 @  60 Hz   60,000 mHz
I [17:35:09]     mode:     1280 x 1024 @  75 Hz   75,025 mHz
I [17:35:09]     mode:     1280 x 1024 @  60 Hz   60,020 mHz
I [17:35:09]     mode:     1280 x  800 @  60 Hz   59,910 mHz
I [17:35:09]     mode:     1280 x  720 @  60 Hz   60,000 mHz  60,000 mHz  59,940 mHz
I [17:35:09]     mode:     1280 x  720 @  50 Hz   50,000 mHz
I [17:35:09]     mode:     1024 x  768 @  75 Hz   75,029 mHz
I [17:35:09]     mode:     1024 x  768 @  60 Hz   60,004 mHz
I [17:35:09]     mode:      800 x  600 @  75 Hz   75,000 mHz
I [17:35:09]     mode:      800 x  600 @  60 Hz   60,317 mHz
I [17:35:09]     mode:      720 x  576 @  50 Hz   50,000 mHz
I [17:35:09]     mode:      720 x  480 @  60 Hz   60,000 mHz  59,940 mHz
I [17:35:09]     mode:      640 x  480 @  75 Hz   75,000 mHz
I [17:35:09]     mode:      640 x  480 @  60 Hz   60,000 mHz  59,940 mHz  59,940 mHz
I [17:35:09]   current:
I [17:35:09]     scale:    1.000
I [17:35:09]     position: 1804,0
I [17:35:09]     mode:     2560x1440@100Hz (99,946mHz) (preferred)
I [17:35:09]
I [17:35:09] eDP-1 Changing:
I [17:35:09]   from:
I [17:35:09]     scale:    1.250
I [17:35:09]     position: 0,0
I [17:35:09]     mode:     2256x1504@60Hz (59,999mHz) (preferred)
I [17:35:09]   to:
I [17:35:09]     position: 0,237
I [17:35:09]
I [17:35:09] DP-5 Changing:
I [17:35:09]   from:
I [17:35:09]     scale:    1.000
I [17:35:09]     position: 1804,0
I [17:35:09]     mode:     2560x1440@100Hz (99,946mHz) (preferred)
I [17:35:09]   to:
I [17:35:09]     position: 1805,0
I [17:35:10]
I [17:35:10] DP-6 Arrived:
I [17:35:10]   info:
I [17:35:10]     name:     'DP-6'
I [17:35:10]     desc:     'Goldstar Company Ltd LG ULTRAGEAR 110MADHLT466 (DP-6)'
I [17:35:10]     width:    700mm
I [17:35:10]     height:   390mm
I [17:35:10]     dpi:      93.34 @ 2560x1440
I [17:35:10]     mode:     3840 x 2160 @  60 Hz   60,000 mHz  59,940 mHz
I [17:35:10]     mode:     3840 x 2160 @  50 Hz   50,000 mHz
I [17:35:10]     mode:     3840 x 2160 @  30 Hz   30,000 mHz  29,970 mHz
I [17:35:10]     mode:     3840 x 2160 @  25 Hz   25,000 mHz
I [17:35:10]     mode:     3840 x 2160 @  24 Hz   24,000 mHz  23,976 mHz
I [17:35:10]     mode:     2560 x 1440 @ 144 Hz  143,933 mHz (preferred)
I [17:35:10]     mode:     2560 x 1440 @ 120 Hz  119,998 mHz
I [17:35:10]     mode:     2560 x 1440 @  60 Hz   59,951 mHz
I [17:35:10]     mode:     1920 x 1080 @ 120 Hz  120,000 mHz 119,880 mHz
I [17:35:10]     mode:     1920 x 1080 @  60 Hz   60,000 mHz  60,000 mHz  59,940 mHz
I [17:35:10]     mode:     1920 x 1080 @  50 Hz   50,000 mHz
I [17:35:10]     mode:     1280 x  720 @  60 Hz   60,000 mHz  59,940 mHz
I [17:35:10]     mode:     1280 x  720 @  50 Hz   50,000 mHz
I [17:35:10]     mode:     1024 x  768 @  60 Hz   60,004 mHz
I [17:35:10]     mode:      800 x  600 @  60 Hz   60,317 mHz
I [17:35:10]     mode:      720 x  576 @  50 Hz   50,000 mHz
I [17:35:10]     mode:      720 x  480 @  60 Hz   60,000 mHz  59,940 mHz
I [17:35:10]     mode:      640 x  480 @  60 Hz   60,000 mHz  59,940 mHz  59,940 mHz
I [17:35:10]   current:
I [17:35:10]     scale:    1.000
I [17:35:10]     position: 4364,0
I [17:35:10]     mode:     2560x1440@144Hz (143,933mHz) (preferred)
W [17:35:10]
W [17:35:10] WARNING: Changes cancelled, retrying
I [17:38:20]
I [17:38:20] Server received set request:
I [17:38:20]
I [17:38:20] Active configuration:
I [17:38:20]   Mode:
I [17:38:20]     DP-5: 2560x1440@144Hz
I [17:38:20]
I [17:38:20] Applying new configuration:
I [17:38:20]
I [17:38:20] Active configuration:
I [17:38:20]   Arrange in a ROW aligned at the BOTTOM
I [17:38:20]   Auto scale: OFF
I [17:38:20]   Scale:
I [17:38:20]     eDP-1: 1.250
I [17:38:20]   Mode:
I [17:38:20]     DP-5: 2560x1440@144Hz
I [17:38:20]
I [17:38:20] DP-5 Changing:
I [17:38:20]   from:
I [17:38:20]     scale:    1.000
I [17:38:20]     position: 1804,0
I [17:38:20]     mode:     2560x1440@100Hz (99,946mHz) (preferred)
I [17:38:20]   to:
I [17:38:20]     mode:     2560x1440@144Hz (143,999mHz)
E [17:38:20]
E [17:38:20] ERROR: Changes failed
E [17:38:20] ERROR:   DP-5:
E [17:38:20] ERROR:     mode:     2560x1440@144Hz (143,999mHz)
W [17:38:20]
W [17:38:20] WARNING: DP-5: No available mode for 2560x1440@144Hz, falling back to preferred
I [17:38:20]
I [17:38:20] DP-5 Changing:
I [17:38:20]   from:
I [17:38:20]     scale:    1.000
I [17:38:20]     position: 1804,0
I [17:38:20]     (no mode)
I [17:38:20]   to:
I [17:38:20]     mode:     2560x1440@100Hz (99,946mHz) (preferred)
I [17:38:20]
I [17:38:20] Changes successful
I [17:38:20]
I [17:38:20] eDP-1 Changing:
I [17:38:20]   from:
I [17:38:20]     scale:    1.250
I [17:38:20]     position: 0,0
I [17:38:20]     mode:     2256x1504@60Hz (59,999mHz) (preferred)
I [17:38:20]   to:
I [17:38:20]     position: 0,237
I [17:38:20]
I [17:38:20] DP-5 Changing:
I [17:38:20]   from:
I [17:38:20]     scale:    1.000
I [17:38:20]     position: 1804,0
I [17:38:20]     mode:     2560x1440@100Hz (99,946mHz) (preferred)
I [17:38:20]   to:
I [17:38:20]     position: 1805,0
I [17:38:20]
I [17:38:20] DP-6 Changing:
I [17:38:20]   from:
I [17:38:20]     scale:    1.000
I [17:38:20]     position: 4364,0
I [17:38:20]     mode:     2560x1440@144Hz (143,933mHz) (preferred)
I [17:38:20]   to:
I [17:38:20]     position: 4365,0
E [17:38:20]
E [17:38:20] ERROR: Changes failed
E [17:38:20]
E [17:38:20] ERROR: Please raise an issue: https://github.com/alex-courtis/way-displays/issues
E [17:38:20] ERROR: Attach this log and describe the events that occurred before this failure.

Then restarted sway session, attempt to choose a lower resolution than native (works), then attempt higher refresh at native again. Successfully falls back to preferred, program does not crash.
 They report 2160p however you have said that they are 1440p. What happens when you attempt to use 2160p?
I have seen logs from a few other users with the same situation.

Native resolution is 1440p for both. The displays support 2160p input, in which case the full image gets downscaled to native resolution, effectively making items appear smaller and blurry. Not something one would want, I think it's maybe meant to handle media devices that only output in 4K.

Thank you for the detailed testing. It looks like the original issue of the infinite loop is resolved.
Session 3:

Then restarted sway session, attempt to choose a lower resolution than native (works), then attempt higher refresh at native again. Successfully falls back to preferred, program does not crash.

It looks like everything is working as intended.
Session 1:

then attempt activating 144Hz. Program crashes, but displays stay working.

That failure is very concerning. The final three simple changes without mode should not be problematic.
The second set of changes not being retried after cancellation also indicates a problem. The positions were not correct after DP-6 arrival.
Session 2:

program immediately crashes

Definitely a problem. I am wondering if it might be a segfault, as it is unlikely that tee would not have received the line buffered stderr.

The differentiating factor here appears to be the dock: displays are appearing almost immediately after each other. That's not something I've been able to test, and I'm glad you brought it to my attention.
I would be very grateful if you could test again, with some debug added.
Please:
git pull
make
sudo make install

Run with way-displays -L debug
Interesting tests:

start with dock connected and close lid
start with dock disconnected, connect it
set DP-5 to 2560x1440@120Hz

If you do experience an exit without a message, please check for a core dump via coredumpctl -1

I am wondering if it might be a segfault, as it is unlikely that tee would not have received the line buffered stderr.

Actually, on reconsideration, lack of error messages in that log is due to me only calling tee for the default stdout stream. I did not redirect the stderr stream, so it's expected that the second output where the program immediately crashes, contains no error log. The other logs include the error stream as those instances were started by Sway on startup, with stderr redirection.
I will make sure to save the error stream as well when I do the next tests.

Did a few more tests with the newest HEAD from the branch.

Start program unplugged, lid open. Then connect dock (both displays running and waiting for input), then close the lid a little later. Everything works fine.

 Run program and open => close => open => close the lid a few times.
Observation: sometimes the display switches off immediately on closing the lid, sometimes it keeps running for more than a few seconds (I can see the display through a gap with the closed lid). Possibly there is some interaction with my systemd-logind config which has the HandleLidSwitch=suspend-then-hibernate setting.

There is a lid input error in the log, which was output at one of the "delayed" screen occurences, but I also observed the screen staying on at other times when no error appeared.
I [14:12:16] way-displays version 1.5.1-SNAPSHOT
I [14:12:16]
I [14:12:16] Found configuration file: /home/black/.config/way-displays/cfg.yaml
I [14:12:16]
I [14:12:16] Active configuration:
I [14:12:16]   Arrange in a ROW aligned at the MIDDLE
I [14:12:16]   Order:
I [14:12:16]     eDP-1
I [14:12:16]     Goldstar Company Ltd 27GL850 912NTLEBE528
I [14:12:16]     Goldstar Company Ltd LG ULTRAGEAR 110MADHLT466
I [14:12:16]   Auto scale: OFF
I [14:12:16]   Scale:
I [14:12:16]     eDP-1: 1.375
I [14:12:16]   Mode:
I [14:12:16]     DP-5: 2560x1440@100Hz
I [14:12:16]
I [14:12:16] Monitoring lid device: /dev/input/event0
I [14:12:16]
I [14:12:16] Lid open
I [14:12:16]
I [14:12:16] eDP-1 Arrived:
I [14:12:16]   info:
I [14:12:16]     name:     'eDP-1'
I [14:12:16]     desc:     'Unknown 0x095F 0x00000000 (eDP-1)'
I [14:12:16]     width:    280mm
I [14:12:16]     height:   190mm
I [14:12:16]     dpi:      202.86 @ 2256x1504
I [14:12:16]     mode:     2256 x 1504 @  60 Hz   59,999 mHz (preferred)
I [14:12:16]   current:
I [14:12:16]     scale:    2.000
I [14:12:16]     position: 0,0
I [14:12:16]     mode:     2256x1504@60Hz (59,999mHz) (preferred)
I [14:12:16]
I [14:12:16] eDP-1 Changing:
I [14:12:16]   from:
I [14:12:16]     scale:    2.000
I [14:12:16]     position: 0,0
I [14:12:16]     mode:     2256x1504@60Hz (59,999mHz) (preferred)
I [14:12:16]   to:
I [14:12:16]     scale:    1.375
I [14:12:16]
I [14:12:16] Changes successful
I [14:13:33]
I [14:13:33] Lid closed
I [14:13:35]
I [14:13:35] Lid open
I [14:13:39]
I [14:13:39] Lid closed
I [14:13:41]
I [14:13:41] Lid open
I [14:13:48]
I [14:13:48] Lid closed
I [14:14:02]
I [14:14:02] Lid open
I [14:14:28]
I [14:14:28] Lid closed
I [14:14:37]
I [14:14:37] Lid open
I [14:14:48]
I [14:14:48] Lid closed
libinput error: event0  - Lid Switch: client bug: event processing lagging behind by 968ms, your system is too slow
I [14:15:09]
I [14:15:09] Lid open
I [14:15:26]
I [14:15:26] Lid closed
I [14:15:48]
I [14:15:48] Lid open

This is something that doesn't work properly, and I'm not sure if it's something with way-displays or some other component. I start with the laptop docked, lid closed. Displays are configured as expected. Then, I unplug the dock while the lid is closed (thus disconnecting both displays and switching battery to discharging status). Then I open the lid a few seconds later. The laptop is on, but the screen is blank, and I cannot get it back working. Plugging the dock back in does not reactivate any displays. This happened 3 times I tried disconnecting laptop while closed. First 2 times I force-shutdown the laptop, even short-press on power-button does nothing (it is setup to hibernate on button press via systemd-logind config). Third time I was able to switch to a non-graphical console with ctrl+alt+F2 and kill sway process. After restarting sway it works again. The log is from this third occurence.

The last line is probabyl from when I killed sway. Note that before that, the log indicates "Lid Open" action before external display departure, but in reality I opened the lid a few seconds after disconnecting the dock. Again I wonder if there is some misconfiguration on my part, and maybe the system is trying to go to sleep-then-hibernate mode when I disconnect power with the lid closed.

Did some more testing. I think maybe wayland or sway itself is finnicky with constant plugging/unplugging of displays. So far, if I dock the laptop, with lid open, displays are detected fine and are set up properly. Then, when undocking, it works fine as long as the lid is open (after a small delay of black, but illuminated, screen). But if I dock the laptop again the second time, the displays fail to change modes and I am left with the laptop screen only. Interestingly, the displays also usually arrive with different identifiers. But after that, I have been unable to get them to work properly again, until I exit sway and restart sway again - then it works again. During these plug/unplug sequences, I have observed way-displays  both staying active (just unable to change modes with the WARNING: Changes cancelled, retrying), as well as once exiting.
I'm attaching 2 files.
First is of repeatedly plugging and unplugging dock, way-displays stayed running.
way-displays.test.dock-plug-unplug-repeat.log
Second is the same, but way-displays exited this time.
way-displays.1.black.log
Don't be confused that one of displays sometimes reports 1440p@144Hz and @122Hz available, and sometimes doesn't even report them. I noticed that the higher refresh rates are only offered when adaptive-sync is disabled on the monitor. Since I have no need for that, on this display, I had it disabled, but now since the higher refresh rates don't work anyways on this configuration (but fall-back to preferred mode correctly since your fix), I decided to continue testing the plug-unplug sequence with adaptive sync enabled, so the higher refresh rate would not even be offered.

Maybe worth mentioning - at this point I haven't actually tested these behaviors with "static" sway configuration for the additional displays. I only got the docking station a few days ago, and decided to set up way-displays right away, as it seems to provide the features I would want for dynamic configuration of the additional displays.

2 No dock.
Observation: sometimes the display switches off immediately on closing the lid

That is by design, now documented: way-displays will not turn off there are no external displays connected. We rely on sleep/suspend handling to maybe turn it off. That has some delays, which is why we see it remain on for a few seconds.
The event processing lagging message is a result of libinput receiving a lid event, but falling asleep before it can process it. Nothing we can do about that except maybe squish that message.

3 Then I open the lid a few seconds later. The laptop is on, but the screen is blank, and I cannot get it back working.

That is very annoying. I have experienced that once. Created #36. #31 may be a solution.
No misconfiguration on your part. Sleep / hibernation should be handled.

Did some more testing. I think maybe wayland or sway itself is finnicky with constant plugging/unplugging of displays.

It's the displays that are finnicky. The will often disable/enable themselves after plug, depending on timing, whether they are sleeping/deep sleeping/powered off etc. That results in the arrive/depart/arrive.

way-displays.test.dock-plug-unplug-repeat.log   way-displays.1.black.log

I think these cases demonstrate the root of the problem: repeated cancellations that are not successfully retried.
I would be very grateful if you could repeat those tests with debug enabled: start with exec way-displays -L debug > /tmp/way-displays.${XDG_VTNR}.${USER}.log 2>&1 or put LOG_THRESHOLD: DEBUG in your cfg.yaml. That will indicate what is happening after the cancellations, and will allow us to handle it.
The changes in identifier are odd, but should not be an issue, as they are not the "key" to identify displays.

Maybe worth mentioning - at this point I haven't actually tested these behaviors with "static" sway configuration for the additional displays.

That would be a lot of work, however it would be useful and interesting. It is what I will likely do when diagnosing #36

I would be very grateful if you could repeat those tests with debug enabled: start with exec way-displays -L debug > /tmp/way-displays.${XDG_VTNR}.${USER}.log 2>&1 or put LOG_THRESHOLD: DEBUG in your cfg.yaml. That will indicate what is happening after the cancellations, and will allow us to handle it.

Ran program with debug flag, start state - laptop unplugged, lid open. Lid stays open throughout the test. Execute following actions:

Connect dock. Both displays wake up and are set as expected (2160p).
Unplug dock. Integrated display sets as expected. Deliberate pause after this step.
Connect dock. Both displays connect, however, one of them has a resolution below the preferred (1080p), while other is at the preferred (2160p). Did not attempt to change it.
Unplug dock. Works as expected. Pause.
Connect dock. Sway crashes and throws me back to my greetd console login screen. Displays work fine after relaunching Sway (not reflected in the log, as that is another session)

Log attached.
way-displays.debug.plug-unplug-repeat.log

I caught another endless loop while testing for #36 . I think this pertains to both issues, but I am attaching to this issue as it ended in a loop.
Start with laptop connected to dock with 2 displays, lid closed. Then unplug laptop, and open lid. I notice the power led is off and lights up as I open it, indicating the laptop had gone to s2idle suspend mode. Display stays off. Contrary to the previous attempt, I am unable to switch to console no matter how many times I try. I attempt to short-press the power button, which should send the machine to hibernate, with no result. I close and re-open the lid again, and again, the power light had gone off, indicating s2idle was active. Display stays off and laptop unresponsive. I connect the laptop to the dock and displays get detected and get powered on, however one external display gets stuck in lower resolution (1080p). From this point, program gets stuck in a loop and I receive many log entries per second.
way-displays.debug.unplug-closed-2.log
Eventually, I kill the running way-displays instance. I then attempt to start it again, and the loop continues. Next log is from the newly launched instance.
way-displays.debug.unplug-closed-3.log

5. Connect dock. Sway crashes and throws me back to my greetd console login screen.

That is disappointing. Investigating with the other fatal failure: #39

Then unplug laptop, and open lid. I notice the power led is off and lights up as I open it, indicating the laptop had gone to s2idle suspend mode. Display stays off.

That should be resolved by #36

I connect the laptop to the dock and displays get detected and get powered on, however one external display gets stuck in lower resolution (1080p). From this point, program gets stuck in a loop and I receive many log entries per second.

That's a great find. The final modeset of the original 1080p is reported as successful, however that display is also reported as disabled with no mode set.
This looping fix will require more hardening, with some sway diagnostics to see exactly what is being sent in the situation of the final modeset resulting in the original mode before the changes.

Many thanks for all your hard work @0x0013 - you have uncovered a great many issues that I would never have found otherwise.
I have enough information to work with now and I would be grateful if you could test once I've fixed all of these issues.
I will commit a fix for #36 to this branch, however I don't expect you to test that; all the rest of the fixes should go with that and be tested together.

Glad I can help.
Feel free to ping me when the fixes are ready, I will be glad to test them.

@0x0013 I am still working on a proper fix, however I do have a workaround : Unusable Displays Following MODE for a sway bug that I have identified.
Could I possibly ask you to test the workaround with one of your test cases? Second is the same, but way-displays exited this time. would be very useful.

@alex-courtis I did test a few times with my previous sequence - plugging and unplugging several times, lid stays open across all attempts.
Unfortunately, I do not see much improvement with the env variable WLR_DRM_NO_MODIFIERS=1 present. Across my attempts, the first docking would settle on the correct configuration as expected.
On subsequent attempts, I would observe one of the following:

one of the displays going into higher than native (4k) resolution. Note that I believe this might be an issue with the display/dock configuration, not way-displays or wlroots, as I have observed this behaviour with a different laptop running xorg, in which case I would just manually reset the resolution. But I did not attempt any manual config changes here as these were tests for just physical connect/disconnect actions.
one of the displays reporting no signal and going to sleep mode.
one of the displays switching to very low (1080p) resolution. (Note here that I did not pay enough attention if this was actually the case, but it showed in the log. The sizing on the desktop looked fine at first glance)
one of the displays switching on, then going to sleep with "no signal", then finally coming back in the apparently normal resolution. Even though this introduces a longer delay than usual, I would still consider this a success.
On one occasion, both displays got stuck in "no mode" state and would not wake at all, even after several attempts to plug/unplug (log file with no-mode.log suffix)
Sway crashing to greetd screen on docking action. This happened every time I tested, usually on the 3rd docking attempt, but once on the 2nd attempt.

While testing, I would wait for the log output to settle before executing the next action. A few times I also left the laptop unplugged for several minutes after the first plug/unplug sequence, but this did not seem to change anything.
All times but one, the displays would always be correctly set on the first connection after starting up Sway. The one time they didn't, I suspect it was improper cable connection, as they did not get detected at all, but then they worked properly on reconnect (so still the first time they were detected by laptop)
As I mentioned before, some of the incorrect resolution issues could be purely due to the monitor/dock configuration, but I did not currently test manually setting my preferred resolution after the wrong one was set. Obviously, the biggest issue is Sway crashing altogether on 2nd or 3rd connection attempt.
That said, so far I did not observe way-displays exiting and Sway continuing to run, which did happen a few times before if my memory serves me right.
Attaching 3 logs - 2 with approximately similar behaviour, and one where they got stuck in "no mode" no matter how many times I tried to replug.
lidopen-plug-unplug-repeat.log
lidopen-plug-unplug-repeat.no-mode.log
lidopen-plug-unplug-repeat-2.log

Thanks @0x0013 that's really helpful.
It seems that we are done with the catastrophic way-displays failures now, just the bad states remain. I will pursue this from the sway side and output manager interface side.

Still working on this. I've experienced some reproducible errors when plugging / unplugging a dock with two displays.

There have been extensive way-displays rewrites of mode setting (it's now atomic), along with success/fail/cancel case handling for sway and river.
There have also been many bug fixes and updates for wlroots, sway and river around display handling.
Closing this as I can no longer reproduce any such errors.
Many thanks for all your work @0x0013 - please do open a new issue if you encounter any further problems.


Update CSP to be able to use extension-reloader

 connect-src ws://localhost:*/ will do the trick

Done in v1.0.0.


Not displaying my music

Why won't this app display my music that's on my SD Card and there seems to be no settings?

This isn't ready to use music app. Look at the source code, it fetches music library from remote json source. If you want to get music from your SD card, then you should modify this.