Add long_press release

To receive en event after a click hold release (dimmer release)

By removing the args there is no way to distinguish between each stop event. I'm guessing one of these isn't working. Also, you have to message the Travis CI support and get your account unblocked by them so this build will run.
Congrats btw!

Please rebase to pick up the CI change. We swapped from travis to GH Actions. Sorry for the inconvenience.

Hi! I was confused when I saw ZHA provides triggers for button presses, for buttons being continuously held, but it's missing a trigger for the button being released. That makes it tricky and counter-intuitive to build automations (we have to dive into zha_event details, instead of just using the much simpler device triggers).

I captured a few events. Here's what I found:

Short button presses (on/off) only generate a single event. (Works as intended in ZHA.)
Long button presses generate move and move_with_on_off events with some arguments, but those arguments don't seem to be useful anyway. (So far, also working as intended in ZHA.)
Releasing from a long press generates a stop event with no arguments. Yes, it looks like the same event for either button. (This behavior is still missing from ZHA, and I hope this PR can help bringing it in.)

zha_event logs
Event 7 fired 8:45 AM:
{
    "event_type": "zha_event",
    "data": {
        "device_ieee": "▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒",
        "unique_id": "▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒:1:0x0008",
        "device_id": "▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒",
        "endpoint_id": 1,
        "cluster_id": 8,
        "command": "stop",
        "args": []
    },
    "origin": "LOCAL",
    "time_fired": "2020-12-17T07:45:58.381877+00:00",
    "context": {
        "id": "bfdd7a959402a6b344a07dbf6c8407aa",
        "parent_id": null,
        "user_id": null
    }
}
Event 6 fired 8:45 AM:
{
    "event_type": "zha_event",
    "data": {
        "device_ieee": "▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒",
        "unique_id": "▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒:1:0x0008",
        "device_id": "▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒",
        "endpoint_id": 1,
        "cluster_id": 8,
        "command": "move",
        "args": [
            1,
            83
        ]
    },
    "origin": "LOCAL",
    "time_fired": "2020-12-17T07:45:57.516022+00:00",
    "context": {
        "id": "e1d171d0e3d211ddedc4d0752802e87d",
        "parent_id": null,
        "user_id": null
    }
}
Event 5 fired 8:45 AM:
{
    "event_type": "zha_event",
    "data": {
        "device_ieee": "▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒",
        "unique_id": "▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒:1:0x0008",
        "device_id": "▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒",
        "endpoint_id": 1,
        "cluster_id": 8,
        "command": "stop",
        "args": []
    },
    "origin": "LOCAL",
    "time_fired": "2020-12-17T07:45:55.566549+00:00",
    "context": {
        "id": "016129adc2bae2fc0e39f699e4414d5e",
        "parent_id": null,
        "user_id": null
    }
}
Event 4 fired 8:45 AM:
{
    "event_type": "zha_event",
    "data": {
        "device_ieee": "▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒",
        "unique_id": "▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒:1:0x0008",
        "device_id": "▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒",
        "endpoint_id": 1,
        "cluster_id": 8,
        "command": "move_with_on_off",
        "args": [
            0,
            83
        ]
    },
    "origin": "LOCAL",
    "time_fired": "2020-12-17T07:45:54.786269+00:00",
    "context": {
        "id": "d0185e0424022d4d61e80b55bfec2de7",
        "parent_id": null,
        "user_id": null
    }
}

I have two ideas for solutions:

Send a single "release" trigger that works when any of those two buttons is released. (This looks like the behavior in controllerx.)
Store a state somewhere to remember the last pressed button, so the appropriate "release" trigger can be sent. (I guess that's what deconz does, but I can't test.)

Additionally, looks like other (IKEA) remotes might also be missing the "release" trigger, but I can't test that either.
I hope the logs in my comment prove useful. And I'm sorry, but I don't have time now to contribute with code.

Codecov Report

Merging #246 (fb420dc) into dev (47287d1) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##              dev     #246   +/-   ##
=======================================
  Coverage   81.15%   81.15%
=======================================
  Files         166      166
  Lines        3763     3763
=======================================
  Hits         3054     3054
  Misses        709      709

Impacted Files
Coverage Δ

zhaquirks/ikea/twobtnremote.py
100.00% <ø> (ø)

Continue to review full report at Codecov.

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

Pull Request Test Coverage Report for Build 436491145

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 81.159%

Totals

Change from base Build 436460653:
0.0%

Covered Lines:
3054

Relevant Lines:
3763

💛  - Coveralls

I rebased this and fixed the sort errors. Thanks for the contribution!


Add UnsubmittedRead to follow new API and set_flags().

This PR introduces two API changes:

Add UnsubmittedRead in read part,
set_flags() function in OneshotOutputTransform.

(1) is basically following suggested API change in: https://github.com/tokio-rs/tokio-uring/pull/244 and (2) is for linked operations.
User now can link their operations like below
let read1 = file
    .read_at(buf1, 0)
    .set_flags(io_uring::squeue::Flags::IO_LINK)
    .submit();
let read2 = file.read_at(buf2, HELLO.len() as u64).submit();

let res1 = read1.await;
let res2 = read2.await;

Closes: https://github.com/tokio-rs/tokio-uring/issues/289

THere are some API issue to address here.
Opening up the flags to the user is presents the user with the ability to break the tokio-uring lifecycle managment. Setting IOSQE_CQE_SKIP_SUCCESS is catastrophic.
The link API is also flawed. If a IOSQE_IO_LINK is observed in the final SQE at submission, it is ignored. The current API doesn't protect the user from that, or provide any way of knowing if the ring has been submitted in between the ops
Finally, what stops the user experiencing concurrency errors, if await is called between read1.submit and read2.submit? Another task could submit to the ring.

@ollie-etl Thanks for the review, you're absolutely right for possible edge cases. I myself tried to provide additional API while hiding the set_flags() first but I found it's a bit blurry to me which is the usable API. So here I'm compromising to put some constraints to users while providing the very least primitives which enables their want including us first. (e.g. No yield between links submitting "valid" sequence of operations)
If possible (and viable), I'd like to discuss some of API options in this PR so complete this functionality in here.
Let me leave some approches to discuss that direction before, I added link!() and hardlink() macros before and it looks like,
let read1 = file.read();
let write1 = file.write();

let (res1, res2) = link!(read1, write1);

This will expand as you can easily expect
let read1 = read1.submit().set_flags(Flags::IO_LINK);
let write1 = write1.submit();

(read1.await, write1.await)

With those API, we can hide uring primitive to users and prevent to make mistake.
But I felt it's not very flexible and restricted because user cannot use futures directly. (e.g. what if I want to await only last one?, what if I just want to use existed API like join_all?). To claim value of such API, I felt I should provide wider variants of APIs (e.g. link!() may accept iterables)
(For other directions, I failed all the non-macro approaches as link!() requires basically different output types with different length of inputs.)
Any suggestion would be appreicated.

My thinking on this is that Link becomes a struct, and that one of the Op traits (maybe OneshotOutputTransform ) gains a link method. This would consume the unsubmitted Op, and return a link Op. This would expose the  submit method, which would either succeed in performing an atomic submission, or fail. It would also be responsible for setting the link flags.
I guess there is a question around Futures behaviour. Should the Link struct return a single future on submission? There are options here - do you only return once the chain completes, or do you provide futres for all the ops in the link chain? Both are varid, so we probably want to support both.

I also tried to introduce somehow nested struct Link (I saw your previous PR which is only one that I can find for the reference, and it's definitely cleaner API)
But the problem about Link implementation that I encountered is that it's hard to imagine that what the future which Link op submitted looks like. The future should returns different types of outputs and I felt it's almost impossible in Rust. (Here, I assume, the future should returns every results)
Still, I want to try the direction, as it's far cleaner API so leave here my trials briefly.
struct UnsubmittedOneshot<D> {
     fn link<D2>(self, other: UnsubmittedOneShot<D2>) -> Link<D, D2> {
        // returns Link struct which have two different OneShot(s). It's gonna happen recursively.
     }
}

struct Link<D1, D2> {
    // Somehow awesome nested struct which have all operations.

    fn submit(&self) -> MultiInflightOneshot<D1, D2> {
        // Return new InflightOneshot which have several OPs.
    }
}

impl Future for MultiInflightOneshot<D1, D2> {
    type Item = ??? # This is dynamically decided (D1, D2, D3, D4... etc)
}

struct UnsubmittedOneshot<D> {
     fn link<D2>(self, other: UnsubmittedOneShot<D2>) -> Link<D, D2> {
        // returns Link struct which have two different OneShot(s). It's gonna happen recursively.
     }
}

struct Link<D1, D2> {
    // Somehow awesome nested struct which have all operations.

    fn submit(&self) -> InflightOneshot<Link<D1,D2> {
        // Use the existing Inflight oneshot
    }
}

impl Future for InflightOneshot<Link<D1, D2>> {
    // Link Future returns a tuple of the output of the first operation, and a future for subsequent linked ops
    type Output = (<D1 as Future>::Output, D2)
}

let links = file.read().chain(file.write());

let (read_output, write_future) = links.await;
let (write_output, next_future) = write_future.await;

You are suggesting such API above, right? It may be possible but not sure with the current API (InflightOnshot has unbounded generic D, so I cannot implement Future again and we need to submit all the operations first to make valid links, so here we still need to know all the types before).
Let me try with some more modification.

@ileixe yes, thats what I had in mind, although I haven't fully thought through all the implications / issues

@ollie-etl I added Link struct and introduce new API: Submit(). Can you take a look whether it's viable?
I don't like introducing Submit() trait as it makes breaking change, but could not find a clean way integrating with current traits.

@ileixe I'd like the opinion of @Noah-Kennedy, as this is building on a lot of his work


CFFL

CFFL

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_66avth5oyj/clone/recipe/meta.yaml:14: pip_install_args: pip install should be run with --no-deps.
ERROR: /tmp/abs_66avth5oyj/clone/recipe/meta.yaml:20: missing_wheel: For pypi packages, wheel should be present in the host section
ERROR: /tmp/abs_66avth5oyj/clone/recipe/meta.yaml:40: missing_license_family: The recipe is missing the about/license_family key.
ERROR: /tmp/abs_66avth5oyj/clone/recipe/meta.yaml:40: missing_dev_url: The recipe is missing a dev_url
ERROR: /tmp/abs_66avth5oyj/clone/recipe/meta.yaml:40: http_url: http://github.com/webdataset/webdataset is not https
ERROR: /tmp/abs_66avth5oyj/clone/recipe/meta.yaml:40: missing_documentation: The recipe is missing a doc_url or doc_source_url
WARNING: /tmp/abs_66avth5oyj/clone/recipe/meta.yaml:40: missing_description: The recipe is missing a description
Errors were found


[zxing-cpp] Fixed renaming zxing -> zxing-cpp

Referenced file
vcpkg/installed/x64-windows/tools/zxing-cpp/zxing.exe
did not exist, because it was created at
vcpkg/installed/x64-windows/tools/zxing/zxing.exe
Closes #6616

Could you also bump the version in the CONTROL file to 3.3.3-4?

Also copy_tools_delendencies must be updated ;) I had to do something similar in my #6730, that’s why I know

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: PhilLab sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

Thanks for the review, I fixed the issues.
Actually, I don't fully understand why we deploy the zxing.exe anyways.


Replace logging singleton with a Context-based logging instance

From this thread: https://github.com/hyperledger/aries-framework-go/pull/88#discussion_r313579752

@troyronda  we need design session


Url to calendar event

Would it be possible to include a property that is the url of the event in google calendar (to be able to access directly from Logseq)?
Thanks for your great work!

Not quite sure what you mean by this? You can currently access select the specific calendar using the command pallet, command shift P.
On 3 Feb 2022, 5:07 PM +0400, gila2000 @.***>, wrote:

Would it be possible to include a property that is the url of the event in google calendar (to be able to access directly from Logseq)?
Thanks for your great work!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

I wonder if it would be possible to create a placeholder in the template to display the url of the event in Google calendar. So, when loading the events in Logseq the url to go to Calendar would appear.

I am thinking of being able to see in Logseq the url of each event shown through the plugin.

Unfortunately the ics format used does not contain this data. A potential solution is to copy paste the link of the calendar into the description in google calendar when creating the event, this can then be copied.
I am curious though whether it would be possible for me to integrate what you plan on doing iwth the link into the plugin.


cmd + shift + click to add mutliple extra cursors in one go

cmd + click adds an extra cursor in the editor.
cmd + shift + click currently behaves in a weird way that does not appear to be intended. My expectation was for cmd + shift + click to add multiple cursors on the lines between the last added cursor and the click position (on the same column as the click).
Does this sound like a good idea? I know I would find it rather useful.

Sounds like an interesting idea for a package :grinning:

@lee-dohm Yes, good point. To be fair I did find a pretty good work around for what I was trying to achieve.
It is possible to simply select a portion of the file and then use the "Selection" > "Split into lines" and then press one of the arrow keys in order to quickly create many cursors over a certain region of text.
Note however, that this is not practical over large selections of texts (> 1000 lines) as the editor becomes unresponsive. Might be worth filing a bug against that.

Actually, there's lots of work going on for performance under large sets of markers :grinning:

Oh, awesome! :-)
On May 16, 2015 6:12 PM, "Lee Dohm"<EMAIL_ADDRESS>wrote:

Actually, there's lots of work going on for performance under large sets
of markers [image: :grinning:]
—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/6812#issuecomment-102718235.

This is actually a duplicate of https://github.com/atom/atom/issues/2306 – please subscribe there for updates.


enhancement(torin): Common ancestor optimization for separate branches with fixed size nodes

What if Torin tried to measure different invalidated nodes branches as separate root candidates if only there was a fixed node in the path to their common ancestor.
Having a fixed size node in the path to their common ancestor would confirm that any change to that node would not affect the other invalidated nodes, thus making measuring faster.
Consider this example

Let's suppose we are modifying [6, 8] and we know [2, 3, 4, 5, 7] have a size dependent on their children. Torin would need to start measuring from 1 because any change to 6 could affect [2, 3] and thus, end up affecting [4, 5, 7, 8]. But what if Torin knows 2 is fixed size? Then we could measure the branch of 2 from 2 itself, and then do 8 from 8 itself as well.

This would for example speed, by a lot, the massive.rs when toggling multiple switches at the same time.


fix setup

What does this implement/fix? Explain your changes.
Fixes a bug in the setup script which prevents it running on an M1 Mac.
Does this close any currently open issues?
No.
Any relevant logs, error output, etc?
No
Any other comments?
This is a simple typo, that doesn't manifest itself unless the NO_CACHE flag is set.

Seems to have made many unintentional updates.


Still creates duplicates!

Are you making separate copies because the current version doesn't match or something?
This is in my test&dev, but it is still painful to recover from - I have to copy the new file content back into the old file content, then delete the new file

...
app:25942020-04-14 11:51:05.410 am debugprefPkgView
app:25942020-04-14 11:50:58.316 am debugcalled true
app:25942020-04-14 11:50:42.516 am infoMatching up packages
app:25942020-04-14 11:50:42.143 am infoRefreshing RMoRobert (BertABCD1234)
app:25942020-04-14 11:50:41.710 am infoRefreshing storageaanarchy (SANdood)
app:25942020-04-14 11:50:39.052 am infoRefreshing dman2306
app:25942020-04-14 11:50:36.265 am warnFound a bad manifest https://raw.githubusercontent.com/bptworld/Hubitat/master/Apps/Life360 Tracker/packageManifest.json
app:25942020-04-14 11:50:33.104 am infoRefreshing BPTWorld
app:25942020-04-14 11:50:31.577 am infoRefreshing AaronW
app:25942020-04-14 11:50:29.977 am infoRetrieving list of installed drivers
app:25942020-04-14 11:50:29.456 am infoRetrieving list of installed apps
app:25942020-04-14 11:50:29.344 am debugPerforming Package Matching
app:25942020-04-14 11:50:26.446 am debugprefPkgMatchUp
app:25942020-04-14 11:50:23.337 am debugcalled true
app:25942020-04-14 11:50:20.269 am debugcalled false
app:25942020-04-14 11:50:20.182 am debugfalse
app:25942020-04-14 11:50:18.242 am infoInstalling Ecobee Suite Sensor
app:25942020-04-14 11:50:18.168 am debugtrue
app:25942020-04-14 11:50:16.172 am debugtrue
app:25942020-04-14 11:50:14.481 am debugtrue
app:25942020-04-14 11:50:12.462 am debugtrue
app:25942020-04-14 11:50:10.445 am debugtrue
app:25942020-04-14 11:50:08.605 am debugtrue
app:25942020-04-14 11:50:06.573 am debugtrue
app:25942020-04-14 11:50:04.632 am debugtrue
app:25942020-04-14 11:50:02.641 am debugtrue
app:25942020-04-14 11:50:01.150 am infoInstalling Ecobee Suite Thermostat
app:25942020-04-14 11:50:00.209 am debugtrue
app:25942020-04-14 11:49:58.811 am debugtrue
app:25942020-04-14 11:49:56.273 am debugtrue
app:25942020-04-14 11:49:54.810 am infoInstalling ecobee Suite Working From Home
app:25942020-04-14 11:49:54.183 am debugtrue
app:25942020-04-14 11:49:52.287 am debugtrue
app:25942020-04-14 11:49:50.177 am debugtrue
app:25942020-04-14 11:49:49.285 am infoInstalling ecobee Suite Thermal Comfort
app:25942020-04-14 11:49:48.212 am debugtrue
app:25942020-04-14 11:49:46.549 am debugtrue
app:25942020-04-14 11:49:44.282 am debugtrue
app:25942020-04-14 11:49:42.931 am debugtrue
app:25942020-04-14 11:49:40.879 am infoInstalling ecobee Suite Smart Zones
app:25942020-04-14 11:49:40.172 am debugtrue
app:25942020-04-14 11:49:38.206 am debugtrue
app:25942020-04-14 11:49:37.320 am infoInstalling ecobee Suite Smart Vents
app:25942020-04-14 11:49:36.177 am debugtrue
app:25942020-04-14 11:49:35.523 am infoInstalling ecobee Suite Smart Switches
app:25942020-04-14 11:49:34.400 am debugtrue
app:25942020-04-14 11:49:32.162 am debugtrue
app:25942020-04-14 11:49:31.347 am infoInstalling ecobee Suite Smart Room
app:25942020-04-14 11:49:30.193 am debugtrue
app:25942020-04-14 11:49:28.149 am debugtrue
app:25942020-04-14 11:49:26.606 am infoInstalling ecobee Suite Smart Mode
app:25942020-04-14 11:49:26.146 am debugtrue
app:25942020-04-14 11:49:24.381 am infoInstalling ecobee Suite Smart Humidity
app:25942020-04-14 11:49:24.349 am debugtrue
app:25942020-04-14 11:49:22.265 am debugtrue
app:25942020-04-14 11:49:21.325 am infoInstalling ecobee Suite Smart Circulation
app:25942020-04-14 11:49:20.240 am debugtrue
app:25942020-04-14 11:49:18.288 am infoInstalling ecobee Suite Routines
app:25942020-04-14 11:49:18.192 am debugtrue
app:25942020-04-14 11:49:16.207 am debugtrue
app:25942020-04-14 11:49:15.519 am infoInstalling ecobee Suite Quiet Time
app:25942020-04-14 11:49:14.219 am debugtrue
app:25942020-04-14 11:49:11.322 am debugtrue
app:25942020-04-14 11:49:09.458 am debugtrue
app:25942020-04-14 11:49:09.441 am infoInstalling ecobee Suite Open Contacts
app:25942020-04-14 11:49:07.260 am debugtrue
app:25942020-04-14 11:49:05.305 am debugtrue
app:25942020-04-14 11:49:03.211 am debugtrue
app:25942020-04-14 11:49:01.393 am debugtrue
app:25942020-04-14 11:49:00.236 am debugtrue
app:25942020-04-14 11:48:58.144 am debugtrue
app:25942020-04-14 11:48:56.193 am debugtrue
app:25942020-04-14 11:48:54.171 am debugtrue
app:25942020-04-14 11:48:52.395 am debugtrue
app:25942020-04-14 11:48:50.268 am debugtrue
app:25942020-04-14 11:48:48.166 am debugtrue
app:25942020-04-14 11:48:46.186 am debugtrue
app:25942020-04-14 11:48:44.661 am debugtrue
app:25942020-04-14 11:48:42.185 am debugtrue
app:25942020-04-14 11:48:40.345 am debugtrue
app:25942020-04-14 11:48:38.254 am debugtrue
app:25942020-04-14 11:48:36.259 am debugtrue
app:25942020-04-14 11:48:34.373 am debugtrue
app:25942020-04-14 11:48:32.448 am debugtrue
app:25942020-04-14 11:48:30.571 am debugtrue
app:25942020-04-14 11:48:28.267 am debugtrue
app:25942020-04-14 11:48:26.794 am debugtrue
app:25942020-04-14 11:48:24.773 am debugtrue
app:25942020-04-14 11:48:22.505 am debugtrue
app:25942020-04-14 11:48:20.537 am debugtrue
app:25942020-04-14 11:48:18.230 am debugtrue
app:25942020-04-14 11:48:16.630 am debugtrue
app:25942020-04-14 11:48:14.198 am debugtrue
app:25942020-04-14 11:48:11.269 am debugtrue
app:25942020-04-14 11:48:09.432 am debugtrue
app:25942020-04-14 11:48:07.241 am debugtrue
app:25942020-04-14 11:48:05.211 am debugtrue
app:25942020-04-14 11:48:03.294 am debugtrue
app:25942020-04-14 11:48:01.208 am debugtrue
app:25942020-04-14 11:47:59.208 am debugtrue
app:25942020-04-14 11:47:57.463 am infoInstalling Ecobee Suite Manager
app:25942020-04-14 11:47:57.190 am debugtrue
app:25942020-04-14 11:47:57.083 am infoDownloading Ecobee Suite Sensor
app:25942020-04-14 11:47:56.843 am infoDownloading Ecobee Suite Thermostat
app:25942020-04-14 11:47:56.609 am infoDownloading ecobee Suite Working From Home
app:25942020-04-14 11:47:56.326 am infoDownloading ecobee Suite Thermal Comfort
app:25942020-04-14 11:47:56.108 am infoDownloading ecobee Suite Smart Zones
app:25942020-04-14 11:47:55.885 am infoDownloading ecobee Suite Smart Vents
app:25942020-04-14 11:47:55.466 am infoDownloading ecobee Suite Smart Switches
app:25942020-04-14 11:47:55.237 am infoDownloading ecobee Suite Smart Room
app:25942020-04-14 11:47:55.190 am debugtrue
app:25942020-04-14 11:47:54.996 am infoDownloading ecobee Suite Smart Mode
app:25942020-04-14 11:47:54.778 am infoDownloading ecobee Suite Smart Humidity
app:25942020-04-14 11:47:54.562 am infoDownloading ecobee Suite Smart Circulation
app:25942020-04-14 11:47:54.317 am infoDownloading ecobee Suite Routines
app:25942020-04-14 11:47:53.900 am infoDownloading ecobee Suite Quiet Time
app:25942020-04-14 11:47:53.602 am infoDownloading ecobee Suite Open Contacts
app:25942020-04-14 11:47:53.265 am infoDownloading Ecobee Suite Manager
app:25942020-04-14 11:47:53.081 am debugInstall beginning
app:25942020-04-14 11:47:53.079 am debugprefInstall
app:25942020-04-14 11:47:53.053 am debug
app:25942020-04-14 11:47:44.368 am debugprefInstallVerify
app:25942020-04-14 11:47:42.870 am debugprefInstallChoices
app:25942020-04-14 11:47:37.861 am debugprefPkgInstallUrl
app:25942020-04-14 11:47:33.986 am debugprefPkgInstall
app:25942020-04-14 11:47:28.899 am debugcalled true
app:25942020-04-14 11:47:23.675 am debugprefPkgModify
app:25942020-04-14 11:47:17.729 am debugcalled true
app:25942020-04-14 11:47:01.177 am debugprefPkgView
app:25942020-04-14 11:46:50.365 am debugcalled true
app:25942020-04-14 11:46:50.135 am debugRefreshing repository list
app:25942020-04-14 11:46:35.881 am debugcalled true
app:25942020-04-14 11:46:23.951 am debugprefInstallChoices
app:25942020-04-14 11:46:18.168 am debugprefPkgInstallUrl
app:25942020-04-14 11:46:10.834 am debugprefPkgInstall
app:25942020-04-14 11:45:58.488 am debugcalled true
app:25942020-04-14 11:45:52.207 am debugUpdates available
app:25942020-04-14 11:45:51.158 am debugUpdates found for package https://raw.githubusercontent.com/bptworld/Hubitat/master/Apps/Follow Me/packageManifest.json
app:25942020-04-14 11:45:50.965 am infoChecking for updates for Follow Me
app:25942020-04-14 11:45:50.962 am debugUpdates found for driver https://raw.githubusercontent.com/SANdood/Ecobee-Suite/master/devicetypes/sandood/ecobee-suite-sensor.src/ecobee-suite-sensor.groovy -> https://raw.githubusercontent.com/SANdood/Ecobee-Suite/master/packageManifest.json
app:25942020-04-14 11:45:50.959 am debugUpdates found for driver https://raw.githubusercontent.com/SANdood/Ecobee-Suite/master/devicetypes/sandood/ecobee-suite-thermostat.src/ecobee-suite-thermostat.groovy -> https://raw.githubusercontent.com/SANdood/Ecobee-Suite/master/packageManifest.json
app:25942020-04-14 11:45:50.951 am debugUpdates found for app https://raw.githubusercontent.com/SANdood/Ecobee-Suite/master/smartapps/sandood/ecobee-suite-smart-mode.src/ecobee-suite-smart-mode.groovy -> https://raw.githubusercontent.com/SANdood/Ecobee-Suite/master/packageManifest.json
app:25942020-04-14 11:45:50.947 am debugUpdates found for app https://raw.githubusercontent.com/SANdood/Ecobee-Suite/master/smartapps/sandood/ecobee-suite-smart-circulation.src/ecobee-suite-smart-circulation.groovy -> https://raw.githubusercontent.com/SANdood/Ecobee-Suite/master/packageManifest.json
app:25942020-04-14 11:45:50.943 am debugUpdates found for app https://raw.githubusercontent.com/SANdood/Ecobee-Suite/master/smartapps/sandood/ecobee-suite-routines.src/ecobee-suite-routines.groovy -> https://raw.githubusercontent.com/SANdood/Ecobee-Suite/master/packageManifest.json
app:25942020-04-14 11:45:50.939 am debugUpdates found for app https://raw.githubusercontent.com/SANdood/Ecobee-Suite/master/smartapps/sandood/ecobee-suite-open-contacts.src/ecobee-suite-open-contacts.groovy -> https://raw.githubusercontent.com/SANdood/Ecobee-Suite/master/packageManifest.json
app:25942020-04-14 11:45:50.749 am infoChecking for updates for Ecobee Suite
app:25942020-04-14 11:45:50.579 am infoChecking for updates for PurpleAir Air Quality Station
app:25942020-04-14 11:45:50.576 am debugUpdates found for package https://raw.githubusercontent.com/dcmeglio/hubitat-packagemanager/master/packageManifest.json
app:25942020-04-14 11:45:50.414 am infoChecking for updates for Hubitat Package Manager
app:25942020-04-14 11:45:50.262 am infoChecking for updates for MeteoBridge Weather Station
app:25942020-04-14 11:45:50.011 am infoChecking for updates for Hub Watchdog
app:25942020-04-14 11:45:49.915 am debugUpdate chosen
app:25942020-04-14 11:45:42.415 am debugcalled true
app:25942020-04-14 10:28:18.991 am debugcalled false
app:25942020-04-14 10:28:18.760 am debugcalled false
app:25942020-04-14 10:28:18.520 am debugcalled false
app:25942020-04-14 10:28:18.257 am debugcalled false
app:25942020-04-14 10:28:17.936 am debugcalled false
app:25942020-04-14 10:27:59.217 am infoUpgrading Hubitat Package Manager
app:25942020-04-14 10:27:58.972 am infoDownloading Hubitat Package Manager
app:25942020-04-14 10:27:58.625 am debugPerforming update
app:25942020-04-14 10:27:16.588 am infoUpgrading Hubitat Package Manager
app:25942020-04-14 10:27:16.245 am infoDownloading Hubitat Package Manager
app:25942020-04-14 10:27:15.814 am debugPerforming update
app:25942020-04-14 10:27:12.714 am debugprefPkgVerifyUpdates
app:25942020-04-14 10:27:02.295 am debugUpdates available
app:25942020-04-14 10:27:01.688 am debugUpdates found for package https://raw.githubusercontent.com/bptworld/Hubitat/master/Apps/Follow Me/packageManifest.json
app:25942020-04-14 10:27:01.435 am infoChecking for updates for Follow Me
app:25942020-04-14 10:27:01.423 am debugUpdates found for driver https://raw.githubusercontent.com/SANdood/Ecobee-Suite/master/devicetypes/sandood/ecobee-suite-sensor.src/ecobee-suite-sensor.groovy -> https://raw.githubusercontent.com/SANdood/Ecobee-Suite/master/packageManifest.json
app:25942020-04-14 10:27:01.420 am debugUpdates found for driver https://raw.githubusercontent.com/SANdood/Ecobee-Suite/master/devicetypes/sandood/ecobee-suite-thermostat.src/ecobee-suite-thermostat.groovy -> https://raw.githubusercontent.com/SANdood/Ecobee-Suite/master/packageManifest.json
app:25942020-04-14 10:27:01.417 am debugUpdates found for app https://raw.githubusercontent.com/SANdood/Ecobee-Suite/master/smartapps/sandood/ecobee-suite-smart-mode.src/ecobee-suite-smart-mode.groovy -> https://raw.githubusercontent.com/SANdood/Ecobee-Suite/master/packageManifest.json
app:25942020-04-14 10:27:01.413 am debugUpdates found for app https://raw.githubusercontent.com/SANdood/Ecobee-Suite/master/smartapps/sandood/ecobee-suite-smart-circulation.src/ecobee-suite-smart-circulation.groovy -> https://raw.githubusercontent.com/SANdood/Ecobee-Suite/master/packageManifest.json
app:25942020-04-14 10:27:01.399 am debugUpdates found for app https://raw.githubusercontent.com/SANdood/Ecobee-Suite/master/smartapps/sandood/ecobee-suite-routines.src/ecobee-suite-routines.groovy -> https://raw.githubusercontent.com/SANdood/Ecobee-Suite/master/packageManifest.json
app:25942020-04-14 10:27:01.395 am debugUpdates found for app https://raw.githubusercontent.com/SANdood/Ecobee-Suite/master/smartapps/sandood/ecobee-suite-open-contacts.src/ecobee-suite-open-contacts.groovy -> https://raw.githubusercontent.com/SANdood/Ecobee-Suite/master/packageManifest.json
app:25942020-04-14 10:27:01.164 am infoChecking for updates for Ecobee Suite
app:25942020-04-14 10:27:00.961 am infoChecking for updates for PurpleAir Air Quality Station
app:25942020-04-14 10:27:00.951 am debugUpdates found for package https://raw.githubusercontent.com/dcmeglio/hubitat-packagemanager/master/packageManifest.json
app:25942020-04-14 10:27:00.737 am infoChecking for updates for Hubitat Package Manager
app:25942020-04-14 10:27:00.442 am infoChecking for updates for MeteoBridge Weather Station
app:25942020-04-14 10:27:00.210 am infoChecking for updates for Hub Watchdog
app:25942020-04-14 10:27:00.042 am debugUpdate chosen
app:25942020-04-14 10:26:57.742 am debugFound new repository https://raw.githubusercontent.com/RMoRobert/Hubitat/master/repository.json
app:25942020-04-14 10:26:57.488 am debugRefreshing repository list
...

I'm not experiencing this, including with the update to Ecobee you put out today. It should NOT be doing this. Here is my best guess looking at the logs, when this was in pre-release I was pushing code to git every couple hours. Perhaps you grabbed it at a point where I had a bug and put it in a bad state. Could you try uninstalling the package manager and reinstalling? You should not need to reinstall any apps/drivers, just run the Match Up feature and everything should be associated properly. Can you try that and let me know if the next time you update ecobee it works fine? As I said, I just updated to the version you pushed out today/yesterday 10 minutes ago and it worked properly for me.

I am suspecting that maybe, if I edit the files after using your installer, that it gets out of sync… Are you doing anything that might break if I edit the files…
From: dcmeglio<EMAIL_ADDRESS>Sent: Tuesday, April 14, 2020 2:21 PM
To: dcmeglio/hubitat-packagemanager<EMAIL_ADDRESS>Cc: Barry Burke<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [dcmeglio/hubitat-packagemanager] Still creates duplicates! (#48)
I'm not experiencing this, including with the update to Ecobee you put out today. It should NOT be doing this. Here is my best guess looking at the logs, when this was in pre-release I was pushing code to git every couple hours. Perhaps you grabbed it at a point where I had a bug and put it in a bad state. Could you try uninstalling the package manager and reinstalling? You should not need to reinstall any apps/drivers, just run the Match Up feature and everything should be associated properly. Can you try that and let me know if the next time you update ecobee it works fine? As I said, I just updated to the version you pushed out today/yesterday 10 minutes ago and it worked properly for me.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/dcmeglio/hubitat-packagemanager/issues/48#issuecomment-613602097 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AB5FQUB7JRXTNT26PPKAKS3RMSSO5ANCNFSM4MH3J6ZA .  https://github.com/notifications/beacon/AB5FQUETEXAXSMWQRRHW3XDRMSSO5A5CNFSM4MH3J6ZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOESJNGMI.gif

Nope, it never looks at the contents of the files.

How about the date stamps?
I can’t seem to find the REMOVE button for your package manager – I’d like to start over clean… (There is a remove button somewhere, right?)
From: dcmeglio<EMAIL_ADDRESS>Sent: Tuesday, April 14, 2020 2:45 PM
To: dcmeglio/hubitat-packagemanager<EMAIL_ADDRESS>Cc: Barry Burke<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [dcmeglio/hubitat-packagemanager] Still creates duplicates! (#48)
Nope, it never looks at the contents of the files.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/dcmeglio/hubitat-packagemanager/issues/48#issuecomment-613615611 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AB5FQUCYPGLJJLVOTHD5GYTRMSVMPANCNFSM4MH3J6ZA .  https://github.com/notifications/beacon/AB5FQUBHBBWYRE3S5HLNDO3RMSVMPA5CNFSM4MH3J6ZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOESJQP6Y.gif

I don't currently have the Remove button shown in app. I'm trying to think of the best place to show it (I don't want people confused on remove a package vs remove the whole thing). However, you can of course always get to the remove button by clicking the gear icon. HE has that remove functionality built in.

Think I tracked this down, should be fixed in the next version.


Read only variable

Since commit 86a936fbf026c1f2c417fe4fe5fed64a7d45afd6, I can no longer build "binaries":
Generating trAInsported with LÖVE 0.9.1 for Debian...
/usr/share/love-release/scripts/debian.sh: line 3: OPTIONS: readonly variable
Generating trAInsported with LÖVE 0.9.1 for Mac OS X...
/usr/share/love-release/scripts/macosx.sh: line 3: OPTIONS: readonly variable
Generating trAInsported with LÖVE 0.9.1 for Windows...
/usr/share/love-release/scripts/windows.sh: line 3: OPTIONS: readonly variable

Works fine when checkout out the commit before that one.
I'm on Ubuntu 15.04.
the .love version gets generated just fine.

 I'll fix this in a moment, sorry :)


When is the PyTorch supported?

As title.

This should be closed. The repo for PyTorch is here

Pytorch support is not related to this repo. Please edit the title or submit a new issue if you are talking about TorchXLA, thanks!

This question has been inactive for more than 2 weeks, will close it soon if no more feedback, thanks!


[fix](jdbc catalog) Fixed the metadata_refresh_interval_sec properties cannot be set

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


Fails to compile on OTP 22

The use of an older rustler version means this is currently failing to compile on OTP 22.

I don’t have the time to maintsin this library. PR‘s are very welcome though if you want to try 😊


chore: checkout to satisfy the codeql tool

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 92.071%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
4157

Relevant Lines:
4515

💛  - Coveralls


Add test meter to stress app with meter and instrument tags

For testing https://github.com/dotnet/aspire/issues/4380
Microsoft Reviewers: Open in CodeFlow

/azp run


UWP Wrong Token

I followed the instructions from the App Center well setting up a Universal Windows App. I associated my app to the store using Visual Studio. Then navigated to the Url that was given on the app center website. The instructions are slightly vague for where to get the 'Security Key' because under the Microsoft Store page there is just Application Secrets and a key there. I copied those values and put them into App Center but yet my app notifications fail.

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

ID: c9d6b620-92c6-9689-6af4-161e1f34429b
Version Independent ID: e983d887-f1c4-4a39-81de-c55085bdb98c
Content: Push Troubleshooting - Visual Studio App Center
Content Source: docs/push/troubleshooting.md
Service: vs-appcenter
GitHub Login: @manb-msft
Microsoft Alias: manb

@BaileyMillerSSI We just updated the docs last week to address the setup issues (and Microsoft moving to a new experience for Windows apps), Can you check to see that the docs there are the same as you followed? https://docs.microsoft.com/en-us/appcenter/sdk/push/uwp.
The best way to work through this is with help from our support team. App Center support is provided directly from within the App Center portal. Any time you need help, just click the blue chat button in the lower-right corner of any page and our dedicated support team will respond. For additional information, see the App Center Help Center.
Get it working with our support team, then lets see what has to happen to the docs to make this more clear.

@BaileyMillerSSI any progress on your end? Was our support team able to help you?

@jwargo Sadly, I have become to busy to look into this so I would chalk it up to a configuration issue on my end and have to close this issue 🤷♂


feat(tools): foundry support

Dapptools unfortunately is in maintenance mode as of two days ago.
I am actually using your Mock Provider in a test suite, and thought you might find it useful potentially
forge test  -f $ETH_RPC_URL -vvv  -- debug $TEST_$1

1=test_SetResponse_For_Query
2=test_SetResponse_For_Selector
3=test_SetResponse_ToFail_ForQuery
4=test_DefaultCalldata_Returns_SetResponse

Running 4 tests for MockProviderTest.json:MockProviderTest
[PASS] test_DefaultCalldata_Returns_SetResponse(bytes) (runs: 256, μ: 209327, ~: 196998)
[PASS] test_SetResponse_For_Query() (gas: 83724)
Logs:
  0x5678
  0x5678

[PASS] test_SetResponse_For_Selector(bytes) (runs: 256, μ: 86446, ~: 86394)
[PASS] test_SetResponse_ToFail_ForQuery() (gas: 39710)

I'm glad this is useful for you. However, I am also developing a forge template
https://github.com/cleanunicorn/ethereum-smartcontract-template
I would prefer to migrate this repo to be compatible with that template since I am supporting both of them.
Thank you for the PR, but I will create another PR that migrates this repo to be closer to cleanunicorn/ethereum-smartcontract-template which also supports foundry.

@sambacha Could you check this PR that does a full migration to Foundry?
https://github.com/cleanunicorn/mockprovider/pull/6

Thanks for asking. Foundry config file can be autogenerated by forge config > foundry.toml I see that you are calling forge config in your CI.
I am actually using these contracts for testing, although I am using Justfile instead of Makefile. Here is an example of using s justfile and the pattern matching option I am using for different mock tests
https://github.com/sambacha/foundry-scripts/blob/master/justfile
Also fwiw foundry is suppose to respect dapptools env settings!
Cheers 🍻


Fails to login on v3.8.2

When i try to login i get the following error:
<mattermost> There doesn't appear to be an api call for the url='/api/v3/teams/1cm3b7b91fddbqye4hm1ckw1hc/channels/more'.  Typo? are you missing a team_id or user_id as part of the url?
it seems that api doesn't exsist anymore?

Are you sure you're using matterircd 0.11.3 ?


[lint] Fix various Verilator lint width errors in different IPs

I think these changes are relatively uncontroversial, so it touches 5 IPs, but I can split this up into separate PRs as well.

Thank you for having a look @tjaychen.
I guess I have 3 types of casting in here:

Casting from int to bits, where the bit length is defined by the clog2 of the int.
Casting from bits to int.
Casting from NrHarts+3 to 4-bit value.

I think the first case is fine and doesn't need any changes. For the second case I could add an assert that the bit length is less than or equal to 32 and for the last case I could add an assert that NrHarts+3 can fit in a 4-bit value.
Alternatively, I can remove cases 2 and 3 to leave this PR with just the changes that are guaranteed fine.


Make error macro C99 friendly

The C99 standard defines the func macro for the function name, so that should be the preferred macro to use for C99 and later. This makes it a conditional define that uses func if it is C99 or later, and FUNCTION for the other cases (which will be compiler dependent).
This isn't actually an error when using C99 and GCC, but it triggers a warning that gets annoying.

Thanks for spotting this!


Lost all (70+) items after upgading to <IP_ADDRESS>1

Lost all (70+) items after upgrading to <IP_ADDRESS>1
Desktop (please complete the following information):

TumblThree version:  <IP_ADDRESS>1 <IP_ADDRESS>1
OS: Windows 10  pro 10.0.19044.0
Browser  Chrome
Version 100.0.4896.127

Additional context
After restart I got only 1 line in my tumbler list ( more than 75 items were before)
Is there any backup config?

Please provide us more details. Normally the blog list doesn't get lost on update.
Have you done the automatic update or manually? Are you using portable or normal mode? Has your download location changed in the settings?
Are there still files inside the Index subfolder of the download location? Is there something in a Backup or Archive subfolder?

Idk if it's related. I lost settings. there was file in app folder, but won't load. And app reset setting to default. When I ticked "activate portable mode" app rewrite setting file and I lost my old one. Used app's autoupdate.

Unfortunately, due to an error, it could happen that the settings file was lost the first time the app was used after the update.
@veneamin + others
You should be able to 'recover' your blogs by setting your correct download location again. And check the settings once, if you changed other settings too.

Please provide us more details. Normally the blog list doesn't get lost on update. Have you done the automatic update or manually?

App started and i saw message "New version aviable. Download and upgrade" - something like that. It download new version and automatically restarted withoun any errors.

Are you using portable or normal mode?

Normal mode

Has your download location changed in the settings?

Didn't changed since first install

Are there still files inside the Index subfolder of the download location?

All folders and files in download destination still there

Is there something in a Backup or Archive subfolder?

there are no such folders in app folder

If I will change destination in settings - all blogs will restored?

Yes, all blogs reappear and have unchanged blog settings. Only check the app settings once, if you used non-default settings.

there are no such folders in app folder

These two folders can be inside the Index folder.
Unfortunately, this bug happened, but luckily it can be solved easily.

For the documentation and to make it more clear.
The cause of this problem was solved in version 2.6.1.
If you skipped version 2.6.0 you are not affected.
Else you only need to set your download location again and check your app settings once.

The issue has been closed. You can still comment. Feel free to ask for reopening the issue if needed.


[FEAT] Breadcumbs configure displayed elements

Describe the bug
It appears that the breadcrumb component doesn't display anything when the array contains only a single element. This undermines the consistency of the layout, as I would like to maintain a consistent breadcrumb style across all pages, even when there is only one breadcrumb item. Could you kindly add a property to define the minimum number of elements required for the breadcrumb to be displayed?
Steps To Reproduce
import { Toolbar } from "@mui/material";
import { useBreadcrumb } from "@refinedev/core";
import { Breadcrumb, ThemedLayoutV2 } from "@refinedev/mui";
import { Outlet } from "react-router-dom";

const Header = () => {
  const breadcumb = useBreadcrumb();
  console.log(breadcumb);

  return (
    <Toolbar>
      <Breadcrumb showHome meta={{ projectId: "123" }} key={1} />
    </Toolbar>
  );
};

const SidebarLayout = () => (
  <ThemedLayoutV2 Header={Header}>
    <Outlet context={{ component: "main", sx: { flex: 1 } }} />
  </ThemedLayoutV2>
);

export default SidebarLayout;

Expected behavior
See above.
Packages
Latest.
Additional Context
No response

Hello, @aress31, Thanks for the detailed explanation!
Yes, It would be great! Do you want to work on this?
Source code:
https://github.com/refinedev/refine/blob/9ecbd45fe0b0f4e09c5389a9095691c6511a4445/packages/mui/src/components/breadcrumb/index.tsx#L44-L45

Sure

We discussed with the core team and decided that the implementation would be better as follows:

<Breadcrumb /> should take a new prop as minItems(or better name) and the breadcrumbs.length === 1 check should be compared with this new prop.

new prop's type should be added to @refinedev/ui-types

/**
* Minimum number of breadcrumb items required for rendering. Component won't render if items * are less than this number.
*/
minItems?: number;

All UI packages should be updated

https://github.com/refinedev/refine/tree/master/packages/mui/src/components/breadcrumb
https://github.com/refinedev/refine/tree/master/packages/core/src/hooks/breadcrumb
https://github.com/refinedev/refine/tree/master/packages/antd/src/components/breadcrumb
https://github.com/refinedev/refine/tree/master/packages/mantine/src/components/breadcrumb
https://github.com/refinedev/refine/tree/master/packages/chakra-ui/src/components/breadcrumb

All tests should be updated. If possible, it should be implemented in the @refinedev/ui-tests package; otherwise, it can be implemented in the package's own test file.

All documentations should be updated.

If I missed anything, please feel free to update it 🚀

@alicanerdurmaz, I’ve made further updates to the PR, and it’s now ready for your review. However, I have a few points:
I’m unsure how to implement the guidance from this file or if I’m missing something in your approach. Any clarification or guidance would be appreciated.
Some tests are failing, and I suspect it’s because I haven’t yet addressed the issues mentioned in this file. Could you kindly review that part?
I’m finding it difficult to work on the PR as I don’t have full visibility of the changes. I’ve followed the contributing guide, but running pnpm dev --scope @refinedev/mui doesn’t start a local server where I can preview the changes. Could you provide guidance on this? It would also be helpful if the guide could be improved for future contributors.

@alicanerdurmaz any help with:

I’m finding it difficult to work on the PR as I don’t have full visibility of the changes. I’ve followed the contributing guide, but running pnpm dev --scope @refinedev/mui doesn’t start a local server where I can preview the changes. Could you provide guidance on this? It would also be helpful if the guide could be improved for future contributors.

@alicanerdurmaz / @BatuhanW any help with:

I’m finding it difficult to work on the PR as I don’t have full visibility of the changes. I’ve followed the contributing guide, but running pnpm dev --scope @refinedev/mui doesn’t start a local server where I can preview the changes. Could you provide guidance on this? It would also be helpful if the guide could be improved for future contributors.

@aress31 You can start base-mui example the same way to see your changes.

@BatuhanW sorry for being a bit slow but what would be the exact command that I need to run?

@BatuhanW sorry for being a bit slow but what would be the exact command that I need to run?

Hey @aress31 I guess you need to run pnpm run dev --scope @refinedev/mui --scope @examples/base-mui  command.


Add support for kernel 6.2

Original patch was suggested by Crashdummyy.
Since commit 9877d8f6bc374912b08dfe862cddbb78b395a5ef
in linux kernel
feild fbdev has been renamed to info in struct drm_fb_helper.
Fixes: https://github.com/DisplayLink/evdi/issues/394
Fixes: https://github.com/DisplayLink/evdi/issues/384
Fixes: https://github.com/DisplayLink/evdi/issues/402
Signed-off-by: listout<EMAIL_ADDRESS>Before submitting the PR please make sure you have run ci scripts:

./ci/build_against_kernel (see --help for all options)
We need backward compatibility and this script is a handy way of testing
build compliance with many kernel versions.
./ci/run_style_check
We want to be as style compliant as possible. Again, this is a handy way of
checking it.

If you have more than one change consider creating separate PRs for them; it
will make the review process much easier. Also provide some description (links
to source code or mailing list are welcome - this might help to understand the
change).
Thanks for the contribution!

The following warning showed up on running the style check script
/module/evdi_fb.c:408: WARNING: Comparisons should place the constant on the right side of the test
./module/evdi_fb.c:466: WARNING: Comparisons should place the constant on the right side of the test
./module/evdi_fb.c:549: WARNING: Comparisons should place the constant on the right side of the test

I'm having a bit of hard time under standing the usage of LINUX_VERSION_CODE and KERNEL_VERSION, if someone could help it would be wonderful.
I'm tested it against 6.2 on gentoo linux with my ThinkPad docking station, seems to be working fine.

The following warning showed up on running the style check script
./module/evdi_fb.c:408: WARNING: Comparisons should place the constant on the right side of the test
./module/evdi_fb.c:466: WARNING: Comparisons should place the constant on the right side of the test
./module/evdi_fb.c:549: WARNING: Comparisons should place the constant on the right side of the test

I'm having a bit of hard time under standing the usage of LINUX_VERSION_CODE and KERNEL_VERSION, if someone could help it would be wonderful.
I'm tested it against 6.2 on gentoo linux with my ThinkPad docking station, seems to be working fine.

Its actually not that complicated.
This script sets LINUX_VERSION_CODE.
It basically just deconstructs the semantic version.
Eg  your current Kernel version ( 6.2.0 ) displays as:
major: 6
minor: 2
patch: 0
The CI needs that to build the latest version of this repository against all kernel versions it wants to.
That allows it to work trunkbased and saves the trouble of maintaining a 5.19, 6.0, 6.1, 6.2 etc. branches ;)

@SimonSchwendele Thanks a lot. What I'm having trouble keeping the current coding convention. For example is this correct?
#if KERNEL_VERSION(6, 1, 12) <= LINUX_VERSION_CODE
    do stuff for kernel version 6.1.12 and below
#else
    do stuff for kernel version 6.2.0 and above
#endif

@SimonSchwendele Thanks a lot. What I'm having trouble keeping up with the current coding convention. For example is this correct?
#if KERNEL_VERSION(6, 1, 12) <= LINUX_VERSION_CODE
    do stuff for kernel version 6.1.12 and below
#else
    do stuff for kernel version 6.2.0 and above
#endif

The other way around.
#if LINUX_VERSION_CODE <= KERNEL_VERSION(6, 1, 12)
     do stuff for all Kernels at 6.1.12 and below

This is what I have, and the script is complaining.

That's what I have done, and the script is complaining. Current coding convention has KERNEL_VERSION(6, 1, 12) on left.

Well if thats the codestyle you have to keep it that way.
You can invert it like I mentioned it above to understand it.
Your usage in thie pr is correct

Works for me on Ubuntu 22.10 with kernel 6.2.0-060200-generic

@xtermi2 thanks for testing.

Will this actually work as intended when building against kernel v6.1.13? I haven't checked, the question just popped up during an ocular inspection of the pr.

Note: my patch will fail if you're using 6.1.13. I need to refine the patch.

Tested and works in Arch.

Also working for me on 6.2.1-arch1-1. Hopefully this gets merged soon. (poke @displaylink-emajewsk)

Apologies, everyone. We've had a lot of work. The reason this isn't merged is because we've already done the work to support the newest Linux kernel, but it's sitting on our internal repository waiting for the driver release, as they have been released in sync so far.
There's definitely room for improvement in this process, and I am forwarding all the suggestions and concerns I see here (or on the AUR), but ultimately I don't make the decisions.

Shall I close this pr then?

No need. We can leave it open for people to find, until we can release the driver.

Unfortunately Arch Linux isn't officially supported. 😢

Apologies, everyone. We've had a lot of work. The reason this isn't merged is because we've already done the work to support the newest Linux kernel, but it's sitting on our internal repository waiting for the driver release, as they have been released in sync so far. There's definitely room for improvement in this process, and I am forwarding all the suggestions and concerns I see here (or on the AUR), but ultimately I don't make the decisions.

Have you considered upstreaming this work as mentioned in #25 so that it doesn't break on new kernel releases in the first place? It would be greatly beneficial to users of your product, and we would be able to use it without installing the modules ourselves.

@listout
So your fix does restore support for multiple displays, but there other conflicts with a connected DisplayLink and what I believe is btusb support.

I am able to boot up just fine without the DisplayLink connected; everything including Bluetooth works. I can then connect the DisplayLink, and everything still works as expected.
If I boot with the DisplayLink connected, then btusb is unable to detect any BT controllers.

Take all this with a grain of salt, as I am on a Dell XPS 15 9500, with the Qualcomm QCA6390 WiFi/Bluetooth chip. I am running through the usual CLI tooling trying to identify where exactly things break. Also want to mention that this was tested against LTS Kernel with no change.
Boot WITHOUT Connected DisplayLink
➜ uname -srm
Linux 6.2.1-arch1-1 x86_64

➜ sudo pacman -Qe | grep linux-firmware
linux-firmware 20230210.bf4115c-1

➜ sudo lsmod | grep bt
btqca                  28672  1 hci_uart
btrtl                  28672  1 hci_uart
btbcm                  24576  1 hci_uart
btintel                53248  1 hci_uart
bluetooth            1077248  38 btrtl,btqca,btintel,hci_uart,btbcm,bnep,rfcomm

➜ sudo dmesg | grep -iE 'bluetooth|btusb|btqca'
[   21.898213] Bluetooth: Core ver 2.22
[   21.898235] NET: Registered PF_BLUETOOTH protocol family
[   21.898238] Bluetooth: HCI device and connection manager initialized
[   21.898242] Bluetooth: HCI socket layer initialized
[   21.898245] Bluetooth: L2CAP socket layer initialized
[   21.898250] Bluetooth: SCO socket layer initialized
[   22.595112] Bluetooth: HCI UART driver ver 2.3
[   22.595117] Bluetooth: HCI UART protocol H4 registered
[   22.595119] Bluetooth: HCI UART protocol BCSP registered
[   22.595144] Bluetooth: HCI UART protocol LL registered
[   22.595145] Bluetooth: HCI UART protocol ATH3K registered
[   22.595163] Bluetooth: HCI UART protocol Three-wire (H5) registered
[   22.595208] Bluetooth: HCI UART protocol Intel registered
[   22.595271] Bluetooth: HCI UART protocol Broadcom registered
[   22.595315] Bluetooth: HCI UART protocol QCA registered
[   22.595317] Bluetooth: HCI UART protocol AG6XX registered
[   22.595327] Bluetooth: HCI UART protocol Marvell registered
[   22.601427] Bluetooth: hci0: setting up ROME/QCA6390
[   22.928385] Bluetooth: hci0: QCA Product ID   :0x00000010
[   22.928389] Bluetooth: hci0: QCA SOC Version  :0x400a0200
[   22.928391] Bluetooth: hci0: QCA ROM Version  :0x00000200
[   22.928393] Bluetooth: hci0: QCA Patch Version:0x00000d2b
[   22.928395] Bluetooth: hci0: QCA controller version 0x02000200
[   22.928397] Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv
[   23.600404] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   23.600409] Bluetooth: BNEP filters: protocol multicast
[   23.600413] Bluetooth: BNEP socket layer initialized
[   23.881028] Bluetooth: hci0: QCA Downloading qca/htnv20.bin
[   24.172004] Bluetooth: hci0: QCA setup on UART is completed
[   24.189678] Bluetooth: MGMT ver 1.22
[   24.743847] hid-generic 0005:046D:B034.0004: input,hidraw2: BLUETOOTH HID v0.03 Mouse [MX Master 3S] on 28:c2:1f:89:16:85
[   27.306354] Bluetooth: RFCOMM TTY layer initialized
[   27.306359] Bluetooth: RFCOMM socket layer initialized
[   27.306361] Bluetooth: RFCOMM ver 1.11
[  683.698693] Bluetooth: hci0: ACL packet for unknown connection handle 129
[  685.423766] Bluetooth: Frame is too long (len 142, expected len 14)
[  685.423774] Bluetooth: hci0: ACL packet for unknown connection handle 16

Boot WITH Connected DisplayLink
Pending....

Apologies, everyone. We've had a lot of work. The reason this isn't merged is because we've already done the work to support the newest Linux kernel, but it's sitting on our internal repository waiting for the driver release, as they have been released in sync so far. There's definitely room for improvement in this process, and I am forwarding all the suggestions and concerns I see here (or on the AUR), but ultimately I don't make the decisions.

Honestly, all kernel breakage mess makes me want to sell my VisionTek VT4900 and just buy a Thunderbolt 3 dock. I think the Dell WD19TB should be comparable, and then I don't have to deal with this driver anymore. This is an awful user experience, and it makes it much less compelling to continue using DisplayLink technology. I'd love to see mainline or at least very up-to-date drivers released as close to possible if not with new kernel releases.

Unfortunately Arch Linux isn't officially supported. cry

@displaylink-emajewsk  Ubuntu is the chosen distro by DisplayLink, which is fine, but I do not think anyone is looking for DisplayLink to support any distro over another.
I think the community here would just rather see closer support for the Linux kernel itself. I am guessing the conversation in #25 (h/t @dylanmtaylor), which was almost seven (7) years ago, probably represents most of your community here. The points made then are equally valid today as they were then. Maybe even more so, with the market share growth that DisplayLink has enjoyed since that conversation.

Unfortunately Arch Linux isn't officially supported. cry

@displaylink-emajewsk Ubuntu is the chosen distro by DisplayLink, which is fine, but I do not think anyone is looking for DisplayLink to support any distro over another.
I think the community here would just rather see closer support for the Linux kernel itself. I am guessing the conversation in #25 (h/t @dylanmtaylor), which was almost seven (7) years ago, probably represents most of your community here. The points made then are equally valid today as they were then. Maybe even more so, with the market share growth that DisplayLink has enjoyed since that conversation.

Very well said. You can officially support Ubuntu, but if it were in the kernel the actual distribution would be irrelevant as it would almost certainly just work on any flavor of Linux.

@displaylink-emajewsk Have you looked at issues #404 ? Does the fixes on your internal repository take care of kernel 6.3?

Apologies, everyone. We've had a lot of work. The reason this isn't merged is because we've already done the work to support the newest Linux kernel, but it's sitting on our internal repository waiting for the driver release, as they have been released in sync so far. There's definitely room for improvement in this process, and I am forwarding all the suggestions and concerns I see here (or on the AUR), but ultimately I don't make the decisions.

I understand. Do you have any idea when the next driver release can be expected?

Hi guys, thank you for the PR. I can confirm that this works on my machine:
Linux ArchDT 6.2.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Sun, 26 Feb 2023 03:39:23 +0000 x86_64 GNU/Linux

Ended up modifying the code myself before I saw this PR. Can confirm that changing "->helper.fbdev" to "->helper.info" fixed the build issue and the displays immediately started working after installing the driver.

I confirm this works on Pop_os 22.04. The problem so far is that if i connect one monitor via the dockingstation everything works fine. If i connect two monitors (either HDMI or DisplayPort) the desktop get unresponsive (drag drop of windows is like 3fps). Everything works fine if i connect one monitor via the dockingstation and one directly with the laptop.

For me, one display shows "out-of-sync-y" glitches. The content appears to partially move to the right for a split second and moves back, and this happens like all the time.

For me, one display shows "out-of-sync-y" glitches. The content appears to partially move to the right for a split second and moves back, and this happens like all the time.

That happened to me as well when I used ubuntu 3 years ( or so ) ago.
Are you certain the resolution is correct ?
Mine happened to be 256x1200 instead of 2560x1440.
Does simply restarting help ?
sudo systemctl restart displaylink-driver

Can confirm that this works on Garuda Linux (arch) with kernel 6.2.2-zen1-1-zen
Can you merge so that it can reach AUR please

Apologies, everyone. We've had a lot of work. The reason this isn't merged is because we've already done the work to support the newest Linux kernel, but it's sitting on our internal repository waiting for the driver release, as they have been released in sync so far. There's definitely room for improvement in this process, and I am forwarding all the suggestions and concerns I see here (or on the AUR), but ultimately I don't make the decisions.

Honestly, all of this kernel breakage mess makes me want to sell my VisionTek VT4900 and just buy a Thunderbolt 3 dock. I think the Dell WD19TB should be comparable, and then I don't have to deal with this driver anymore. This is an awful user experience, and it makes it much less compelling to continue using DisplayLink technology. I'd love to see mainline or at least very up-to-date drivers released as close as possible if not with new kernel releases. It's not really a universal dock if it doesn't work on all operating systems, including Linux. And if it constantly breaks on new kernel releases, it makes it feel like Linux users are second-class citizens.

Thanks for the alternative suggestion. I update my linux laptop once a quarter and every single time I do I spend a day trying to figure out how to get my external monitors to work. It's absolutely insane the history of commands I've tried over the year to do this and they never work across another update. I'll be buying that Dell hub and seeing how that works instead, thank you.

Apologies, everyone. We've had a lot of work. The reason this isn't merged is because we've already done the work to support the newest Linux kernel, but it's sitting on our internal repository waiting for the driver release, as they have been released in sync so far. There's definitely room for improvement in this process, and I am forwarding all the suggestions and concerns I see here (or on the AUR), but ultimately I don't make the decisions.

Honestly, all of this kernel breakage mess makes me want to sell my VisionTek VT4900 and just buy a Thunderbolt 3 dock. I think the Dell WD19TB should be comparable, and then I don't have to deal with this driver anymore. This is an awful user experience, and it makes it much less compelling to continue using DisplayLink technology. I'd love to see mainline or at least very up-to-date drivers released as close as possible if not with new kernel releases. It's not really a universal dock if it doesn't work on all operating systems, including Linux. And if it constantly breaks on new kernel releases, it makes it feel like Linux users are second-class citizens.

I have the same feelings
At the time I still didn't use Linux as my main, heck I was not even using it, so I didn't do much research
But if I knew about all of this, I would have never bought my Asus MB169B+
Lesson learned I think, better avoid this mess next time

Works on Pop!_OS 22.04 with kernel 6.2.0-76060200-generic, thanks!!!

Fix Works on Pop!_OS 22.04
Dell Inspiron 7472
Kernel 6.2.0-76060200-generic
GNOME 42.5
DisplayLink QGeeM 3501 Adapter
Thank you very much!

For some reason it broke again on my system, all I can see in the logs is:
io/hpmud/pp.c 627: unable to read device-id ret=-1

@palexdev try cloning and building from the devel branch, they have recently added 6.2 support

Nothing, I still see the same error

It's been 6 weeks now, how is it still not working ?

@bastoune With commit https://github.com/DisplayLink/evdi/commit/a47ded875c208fc38dee3f808f2b0639a86f1730 I think they have patched it for version 6.2

I cloned the devel branch, replaced evdi.tar.gz in the exploded displaylink-driver and ran displaylink-installer.sh. Now I have evdi 1.13.0 but it is not working. Peripherals working, display detected but not working. Kernerl 6.2.0-18-generic on Ubuntu 23.04.

Now I have evdi 1.13.0 but it is not working.

@cmmrandau - That is because DisplayLink 5.6.x is pinned to EVDI 1.12. Some, including myself, have had luck with  Varun-garg/evdi-compat. Ultimately the way Synaptics manages dependencies needs to be fixed, and only they can fix this.

@djallits - thanks, I tried it but it did not work either. I do this: clone the evdi, make a new evdi.tar.gz and replace the one in displaylink-driver, and then run displaylink-installer.sh in the exploded folder. dkms status says evdi/1.13.0, 6.2.8-060208-generic, x86_64: installed so the installation seems to work. dmesg gives many messages like:
[   35.326797] evdi: [I] (card3) Opened by Task 1560 (systemd-logind) of process 1560 (systemd-logind)
...
[   36.797264] evdi: [I] (card3) Closed by Task 4113 (gnome-shell) of process 4113 (gnome-shell)
but google does not make me wiser as to whether this has anything to do with it nor working.

@djallits - thanks, I tried it but it did not work either. I do this: clone the evdi, make a new evdi.tar.gz and replace the one in displaylink-driver, and then run displaylink-installer.sh in the exploded folder. dkms status says evdi/1.13.0, 6.2.8-060208-generic, x86_64: installed so the installation seems to work. dmesg gives many messages like: [ 35.326797] evdi: [I] (card3) Opened by Task 1560 (systemd-logind) of process 1560 (systemd-logind) ... [ 36.797264] evdi: [I] (card3) Closed by Task 4113 (gnome-shell) of process 4113 (gnome-shell) but google does not make me wiser as to whether this has anything to do with it nor working.

The current displaylink requires evdi/1.12.0 .
The current devel runs on 1.13.0.
The changes made to the devel did more than just fixing those issues.
You could set the minor version to 12 and try using that one.
https://github.com/DisplayLink/evdi/blob/85a347a0a6c97df9fd602289229ca6f738ea9924/library/evdi_lib.h#L16

Why not try just skipping the compression part altogether?
Git clone the repo, cd into it and just run make (or make install).
Once done you can just modprobe evdi and restart your dlm service.
I've have using this method and it turned out to be fine
On Wed, Mar 29, 2023 at 3:54 PM Martin Randau @.***>
wrote:

Thanks for the help. Not sure I did it right. I edited evdi_lib.h from the
devel branch to
#define LIBEVDI_VERSION_MAJOR 1
#define LIBEVDI_VERSION_MINOR 12
#define LIBEVDI_VERSION_PATCH 0
and then compressed the evdi folder to evdi.tar.gz and ran
displaylink-installer.sh. This doesn't work. dkms status still says I run
1.13.1
My kernel is 6.2.8-060208-generic
dmesg still says the same, e.g., [ 36.797264] evdi: [I] (card3) Closed by
Task 4113 (gnome-shell) of process 4113 (gnome-shell)
Monitor is detected but not working. Peripherals work.
—
Reply to this email directly, view it on GitHub
https://github.com/DisplayLink/evdi/pull/401#issuecomment-1488335357,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AP4726SIOVES7NSVAHH6H3LW6QEWVANCNFSM6AAAAAAVCEUWPU
.
You are receiving this because you were mentioned.Message ID:
@.***>

I tried that too before, but make failed because I missed pybinds11. Now make completed but it still doesn't work. I would need detailed steps of how to completely remove the previous evdi and displaylink and how to proceed from there. I think I'm doing a mismatch of things and lack a proper understanding of depmod, dkms, etc.. Otherwise, I'll just wait until the official driver is released. I'm using a Lenovo 4 dock with thunderbolt, but connecting with usb-c. For now, I just connect the monitor directly and use the dock for peripherals. Thanks for the help, though. :)

@Crashdummyy thanks for the help. I tried a fresh install of displaylink with the changes to makefile and dkms.conf, but still no luck. Peripherals work and Display is detected but no output. Tried both wayland and xorg. It's a lenovo thunderbolt/usb-c dock and I'm connecting with usb-c since my laptop lacks thunderbolt.
dkms status
evdi/1.12.0, 6.2.9-060209-generic, x86_64: installed

sudo dmesg | grep evdi
[    3.776827] evdi: loading out-of-tree module taints kernel.
[    3.776911] evdi: module verification failed: signature and/or required key missing - tainting kernel
[    3.787270] evdi: [I] Initialising logging on level 4
[    3.787276] evdi: [I] Atomic driver: yes
[    3.787415] evdi: [I] Increasing device count to 4
[    3.787637] evdi: [I] (card1) Opened by Task 358 (systemd-modules) of process 358 (systemd-modules)
[    3.787653] evdi evdi.0: [drm] Cannot find any crtc or sizes
[    3.787941] [drm] Initialized evdi 1.13.1 20230324 for evdi.0 on minor 1
[    3.787970] evdi: [I] Evdi platform_device create
[    3.788053] evdi: [I] (card2) Opened by Task 358 (systemd-modules) of process 358 (systemd-modules)
[    3.788058] evdi evdi.1: [drm] Cannot find any crtc or sizes
[    3.788230] [drm] Initialized evdi 1.13.1 20230324 for evdi.1 on minor 2
[    3.788239] evdi: [I] Evdi platform_device create
[    3.788312] evdi: [I] (card3) Opened by Task 358 (systemd-modules) of process 358 (systemd-modules)
[    3.788318] evdi evdi.2: [drm] Cannot find any crtc or sizes
[    3.788495] [drm] Initialized evdi 1.13.1 20230324 for evdi.2 on minor 3
[    3.788502] evdi: [I] Evdi platform_device create
[    3.788553] evdi: [I] (card4) Opened by Task 358 (systemd-modules) of process 358 (systemd-modules)
[    3.788557] evdi evdi.3: [drm] Cannot find any crtc or sizes
[    3.788692] [drm] Initialized evdi 1.13.1 20230324 for evdi.3 on minor 4
[    3.788701] evdi: [I] Evdi platform_device create
[    3.862385] evdi: [I] (card4) Opened by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.862418] evdi: [I] (card4) Closed by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.862456] evdi: [I] (card3) Opened by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.862464] evdi: [I] (card3) Closed by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.862470] evdi: [I] (card2) Opened by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.862476] evdi: [I] (card2) Closed by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.862481] evdi: [I] (card1) Opened by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.862488] evdi: [I] (card1) Closed by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.862925] evdi: [I] (card4) Opened by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.862933] evdi: [I] (card4) Closed by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.862938] evdi: [I] (card3) Opened by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.862943] evdi: [I] (card3) Closed by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.862948] evdi: [I] (card2) Opened by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.862952] evdi: [I] (card2) Closed by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.862955] evdi: [I] (card1) Opened by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.862959] evdi: [I] (card1) Closed by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.863403] evdi: [I] (card4) Opened by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.863412] evdi: [I] (card4) Closed by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.863418] evdi: [I] (card3) Opened by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.863422] evdi: [I] (card3) Closed by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.863425] evdi: [I] (card2) Opened by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.863430] evdi: [I] (card2) Closed by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.863442] evdi: [I] (card1) Opened by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.863446] evdi: [I] (card1) Closed by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.863900] evdi: [I] (card4) Opened by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.863907] evdi: [I] (card4) Closed by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.863912] evdi: [I] (card3) Opened by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.863916] evdi: [I] (card3) Closed by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.863921] evdi: [I] (card2) Opened by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.863924] evdi: [I] (card2) Closed by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.863931] evdi: [I] (card1) Opened by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.863935] evdi: [I] (card1) Closed by Task 1489 (gpu-manager) of process 1489 (gpu-manager)
[    3.902259] evdi: [I] (card3) Opened by Task 407 (plymouthd) of process 407 (plymouthd)
[    3.902316] evdi: [I] (card3) Closed by Task 407 (plymouthd) of process 407 (plymouthd)
[    3.902349] evdi: [I] (card4) Opened by Task 407 (plymouthd) of process 407 (plymouthd)
[    3.902366] evdi: [I] (card4) Closed by Task 407 (plymouthd) of process 407 (plymouthd)
[    3.902385] evdi: [I] (card2) Opened by Task 407 (plymouthd) of process 407 (plymouthd)
[    3.902409] evdi: [I] (card2) Closed by Task 407 (plymouthd) of process 407 (plymouthd)
[    3.902706] evdi: [I] (card1) Opened by Task 407 (plymouthd) of process 407 (plymouthd)
[    3.902722] evdi: [I] (card1) Closed by Task 407 (plymouthd) of process 407 (plymouthd)
[    4.589162] evdi: [I] (card1) Opened by Task 1551 (systemd-logind) of process 1551 (systemd-logind)
[    4.604786] evdi: [I] (card2) Opened by Task 1551 (systemd-logind) of process 1551 (systemd-logind)
[    4.614968] evdi: [I] (card3) Opened by Task 1551 (systemd-logind) of process 1551 (systemd-logind)
[    4.625420] evdi: [I] (card4) Opened by Task 1551 (systemd-logind) of process 1551 (systemd-logind)
[    5.791594] evdi: [I] (card4) Closed by Task 1948 (gnome-shell) of process 1948 (gnome-shell)
[    5.792502] evdi: [I] (card2) Closed by Task 1948 (gnome-shell) of process 1948 (gnome-shell)
[    5.793559] evdi: [I] (card3) Closed by Task 1948 (gnome-shell) of process 1948 (gnome-shell)
[    5.794970] evdi: [I] (card1) Closed by Task 1948 (gnome-shell) of process 1948 (gnome-shell)
[   11.045641] evdi: [I] (card1) Opened by Task 1551 (systemd-logind) of process 1551 (systemd-logind)
[   11.057786] evdi: [I] (card2) Opened by Task 1551 (systemd-logind) of process 1551 (systemd-logind)
[   11.068249] evdi: [I] (card3) Opened by Task 1551 (systemd-logind) of process 1551 (systemd-logind)
[   11.079563] evdi: [I] (card4) Opened by Task 1551 (systemd-logind) of process 1551 (systemd-logind)
[   12.652302] evdi: [I] (card3) Closed by Task 2861 (gnome-shell) of process 2861 (gnome-shell)
[   12.653724] evdi: [I] (card1) Closed by Task 2861 (gnome-shell) of process 2861 (gnome-shell)
[   12.655159] evdi: [I] (card2) Closed by Task 2861 (gnome-shell) of process 2861 (gnome-shell)
[   12.657004] evdi: [I] (card4) Closed by Task 2861 (gnome-shell) of process 2861 (gnome-shell)

Switched to Fedora 38 and the dock works out of the box without even having to install the displaylink driver. <:D
Thanks for the tip!

Checked and tested:
Working like a charm on Ubuntu 23.03 - Beta. "Linux Proton 6.2.0-19-generic #19-Ubuntu"
Working like a charm on Pop OS 22.04 with kernel 6.2.0

Switched to Fedora 38 and the dock works out of the box without even having to install the displaylink driver. <:D
Thanks for the tip!

So, am I right, Fedora 38 supports displaylink out of the box?

Switched to Fedora 38 and the dock works out of the box without even having to install the displaylink driver. <:D
Thanks for the tip!

So, am I right, Fedora 38 supports displaylink out of the box?

Yes, it works without installing the displaylink driver. It's on a Lenovo laptop connected to  Lenovo dock. Can't see evdi in dkms, so I'm not sure what driver it's using or how it works. Let me know if you want me to post any command.

I just installed Fedora 38 beta and my dock wont work without those drivers. Maybe it depends on the dock but I guess yours probably might've worked without displaylink anyway

The same dock did not work ootb in Ubuntu 23.04 and not with displaylink either, which is why I came here in the first place.

Upgraded from Fedora 37 (which recently had stopped working with DL) to Fedora 38. For me it does not work out of the box. I applied (at least I think I did) the patch and then other functions where undefined. I'm left with 'Apr 20 01:45:54 fedora systemd[1]: displaylink-driver.service: Consumed 8.296s CPU time.
Apr 20 01:45:54 fedora systemd[1]: Failed to start displaylink-driver.service - DisplayLink Driver Service.
Apr 20 01:45:54 fedora systemd[1]: displaylink-driver.service: Failed with result 'exit-code'.
Apr 20 01:45:54 fedora systemd[1]: displaylink-driver.service: Control process exited, code=exited, status=10/n/a
Apr 20 01:45:54 fedora sh[7388]: Consult /var/lib/dkms/evdi/1.12.0/build/make.log for more information.
Apr 20 01:45:54 fedora sh[7388]: Error! Bad return status for module build on kernel: 6.2.11-300.fc38.x86_64 (x86_64)
Apr 20 01:45:54 fedora sh[6858]: make -j20 KERNELRELEASE=6.2.11-300.fc38.x86_64 all INCLUDEDIR=/lib/modules/6.2.11-300.fc38.x86_64/build/include KVERSION=6.2.11-300.fc38.x>
Apr 20 01:45:53 fedora sh[6858]: Cleaning build area...
Apr 20 01:45:53 fedora sh[6858]: Building module:
Apr 20 01:45:52 fedora sh[6858]: Public certificate (MOK): /var/lib/dkms/mok.pub
Apr 20 01:45:52 fedora sh[6858]: Signing key: /var/lib/dkms/mok.key
Apr 20 01:45:52 fedora sh[6858]: Sign command: /lib/modules/6.2.11-300.fc38.x86_64/build/scripts/sign-file`


How to use ContainerAwareInterface

Hi there
Is there any tutorial on how to use ContainerAwareInterface ?
I try to pass the container object to my Controller class.
I cant find any tutorial on that..Please advice
Here what i tried:
Controller class:
<?php namespace App\Core;

use League\Container\ContainerAwareTrait;
use League\Container\ContainerAwareInterface;

class AppController implements ContainerAwareInterface
{
    use ContainerAwareTrait;

    public function __get( $name ) {

        var_dump($this->container);
        exit;

        if ( $this->container->has( $name ) ) {
            return $this->container->get( $name );
        }
    }
}

Bootstrap script:

$container = new Container();

#Auto-wiring based on constructor typehints.
#http://container.thephpleague.com/auto-wiring
$container->delegate( new ReflectionContainer() );

$container->inflector( 'ContainerAwareInterface' )
    ->invokeMethod( 'setContainer', [ $container ] );

I got  the following when i try dump the container object

/var/www/html/foo/src/App/Core/AppController.php:12:null

I believe the mistake is in here:
$container->inflector('ContainerAwareInterface')

Try:
$container->inflector(\League\Container\ContainerAwareInterface::class)

or something equivalent.

@hannesvdvreken is correct, it has to be the fully qualified class name

i changed this line
$container->inflector( 'ContainerAwareInterface' )
    ->invokeMethod( 'setContainer', [ $container ] );

to this
$container
->inflector(\League\Container\ContainerAwareInterface::class )
->invokeMethod( 'setContainer', [ $container ] );
yet i got error :

Call to a member function has() on null

Did this work for you, @slier81? Personally I'm still getting nulls where the container is requested in other objects' constructors.
PHP Catchable fatal error:  Argument 1 passed to App\Foo::__construct() must be an instance of App\Container, none given in /var/www/scripts/bridge-adapter/app/Foo.php on line 16

@alanondra yes it work, i need to fully qualify the container class as informed by @hannesvdvreken
maybe you can show your code , so i can help you

I didn't have the problem of not using the full class path. It's just not attempting to actually resolve the dependency on the Container instance, and I was wondering if this is actually the prescribed method of resolving it. I can use withArgument to force it to pass my container instance but that defeats the purpose of autowiring. Using share also does not expose the container instance. It just doesn't work.
use League\Container\ReflectionContainer;
use League\Container\ContainerAwareInterface;

// extends League\Container\Container
$container = new App\Container();

$container->delegate(new ReflectionContainer());

$container->inflector(ContainerAwareInterface::class)
	->invokeMethod('setContainer', [$app]);

$container->inflector(ContainerAwareInterface::class)
	->invokeMethod('setContainer', [$container]); // <--- pass the container

Actually that's a typo from cleaning up the copy.

@alanondra
int the class u expect to use the container u have to implement ContainerAwareInterface
Then use the ContainerAwareTrait to actually implement the ContainerAwareInterface

I'm actually doing that, even though it defeats the purpose of autowiring. It still doesn't resolve the Container.

@alanondra
Auto wiring only attempts to resolve constructor arguments. Inflectors are a completely separate feature.
Firstly, I would not recommend injecting the container in to your classes unless they are a factory of some kind, that is service location and is considered an anti pattern and should be avoided when possible.
Secondly, I would always recommend being explicit with your definitions, auto wiring uses reflection which is slow, so I would only ever consider using it for prototyping before explicitly defining your classes with the container.
For your specific problem here, I see you are extending the container, without seeing what you're doing on top of this container I'm not aware of any side effects you might have introduced. Try accessing the container directly and see if that solves your problem, then you will know where the issue is.

Firstly, I would not recommend injecting the container in to your classes unless they are a factory of some kind, that is service location and is considered an anti pattern and should be avoided when possible.

Service location is something like using named database connections. There is only one instance of this expected to be used, so it's not service location.

Secondly, I would always recommend being explicit with your definitions, auto wiring uses reflection which is slow, so I would only ever consider using it for prototyping before explicitly defining your classes with the container.

So there's really no point using this, then.

Hence...

unless they are a factory of some kind

So this would be considered an anti-pattern if, for instance, one wished to use it to share an instance of the PSR-7 ServerRequest, even though realistically this is probably the only request the application is actually handling?

No, but if you passed the container in to a controller or similar and pulled dependencies from the container, then it would be.

So the purpose I suppose is that DI should never, ever be used outside of the container itself or providers hooked onto it.

No, the opposite, your classes should have no knowledge of the container, the container is just a tool that helps wire them together.
Sent from my iPhone

On 9 Aug 2017, at 17:33, alanondra<EMAIL_ADDRESS>wrote:
So the purpose I suppose is that DI should never, ever be used outside of the container itself or providers hooked onto it.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.


WIREFRAMES: Build Report Part 2

As a user, I want to review the Build report and view specific functionality, including:

Helpful progress information to progress screen
Allowing user to exit progress modal but keep loading build report
Allowing user to cancel in-progress build report
Large scale failure state – report failure
Include time stamp

VC:

Share with ALM team
Share with product team

https://redhat.invisionapp.com/share/G4AJCK6HX
Summit stretch goal: https://redhat.invisionapp.com/share/8UAJD3QVN


Remove opal-activesupport dependency?

React-opal has this as well. If it's possible to remove it (like opal-browser) such that it's only included if higher level code needs it, that might help keep the core GEM lean.

@wied03 If opal-activesupport were any where near the size of ruby active support, I'd definitely agree with you. But opal-activesupport is still quite lean. In fact older versions of react.rb implemented a handful of core extensions that I moved into the opal-activesupport gem to avoid multiple implementations of the same core ext.

Might be a fair point. How small is small though? And will opal-activesupport stay that way?
Maybe as a compromise, getting rid of require 'active_support' from top_level.rb so that the active support requires are more granular might be a good goal. That way active support can grow but the served script to the browser with React.rb doesn't necessarily grow.
I know some files already do a granular require but the top level one is there.

@wied03 I managed to compile all of active support into ~13k. It is quite possible never versions of active support would implement more or it's ruby counter part. I think you are correct to suggest simply being deliberate in only requiring extensions that are needed. That should protect against a growing size as AS matures.

again the suggestion of either a basic vs. full version would answer this, or somehow making it configurable.

For this one I don't think you need a basic or full react.gem. it's just a
matter of a couple more granular requires.
sent from my mobile device
On Mar 29, 2016 07:52, "Mitch VanDuyn"<EMAIL_ADDRESS>wrote:

again the suggestion of either a basic vs. full version would answer this,
or somehow making it configurable.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/zetachang/react.rb/issues/135#issuecomment-202902754

For this one I don't think you need a basic or full react.gem. it's just a
matter of a couple more granular requires.

Exactly. AS isn't providing features to the user here. It's just allowing us to avoid recoding the wheel. Really, the more we lean on AS (and only require what which we need), the better. Users who include AS in their projects will benefit from the overlap.

This issue was moved to reactrb/reactrb#135


fix: fix comment

c.jsonT is removed now, but there is a reference to it in the comment.
I found it when I was reading the code, it may cause confusion for contributors, so I fixed it.
Author should do the followings, if applicable

[ ] Add tests
[x] Run tests
[x] yarn denoify to generate files for Deno

You are right! Thanks @nakasyou !


Should throw error after catching it

It you throw it eventually without any handling in the catch block, then no need to catch it at the first place

@tommyttf  We do have some error handling in api hooks. If we don't throw error, the hooks will not run onError.

I mean
  createPost: async (req: ICreatePostRequest) => {
    try {
      await supabase.from("post").insert({
        url: req.url,
        country_uuid: req.countryUuid,
        province_uuid: req.provinceUuid,
        city_uuid: req.cityUuid,
        industry_uuid: req.industryUuid,
        year_of_experience: req.yearOfExperience,
        created_by: req.createdBy,
        type: req.type,
        company_name: req.companyName.trim(),
        job_title: req.jobTitle.trim(),
        description: req.description.trim(),
      })
    } catch (error) {
      throw error
    }
  },

is the same as
createPost: async (req: ICreatePostRequest) => {
    await supabase.from("post").insert({
      url: req.url,
      country_uuid: req.countryUuid,
      province_uuid: req.provinceUuid,
      city_uuid: req.cityUuid,
      industry_uuid: req.industryUuid,
      year_of_experience: req.yearOfExperience,
      created_by: req.createdBy,
      type: req.type,
      company_name: req.companyName.trim(),
      job_title: req.jobTitle.trim(),
      description: req.description.trim(),
    })
},

Right will do some refactoring later.


Update sql-server-linux-performance-best-practices.md

Add a note for open file limitation.
This setting do not apply to systemd services.
Most Linux dist now have hard limit of nofile at least 1048576.
There is no reason to set a lower soft limit and I don't know why original author choose a value of 32727 ($2^{15}-1-40$).

@tejasaks
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

Adding @amitkh-msft to review. Original entry was made for Red Hat Enterprise Linux 7 which had a much lower default limit and caused certain issues. probably doesn't apply to RHEL 9 or even 8 but needs to be verified.


Feature: show free space on current mount point

Top and bottom status line shows the number of files and total size, additionally would be nice to see a free space on the currently opened path in GiB and percentage.

The difficulty here seems to be getting the mount points, as I know no crate that would reliably do that on multiple platforms. To me it's fine to only implement such a thing on platforms where this is straightforward to implement.
I know the trash-rs crate has some code for that as well.


Unc0ver 3.3.0 and 3.3.0b7 Unsupported iPhone 6+ (A8) 12.2

Describe the bug
Unc0ver 3.3.0 and 3.3.0b7 showing "Unsupported" for iPhone 6+ with iOS 12.2 (Empty exploit list).
To Reproduce
Steps to reproduce the behavior:

Open unc0ver 3.3.0 or 3.3.0b7 on iPhone 6+ with iOS 12.2 installed.
There is no exploit available and it says "Unsupported".

Screenshots

Device (please complete the following information):

iOS Version: 12.2
iOS Device: iPhone 6+
unc0ver Version: 3.3.0 OR 3.3.0b7 (Both is tested and was same)

Place an "x" between the brackets if true:

[x] this is a bug others will be able to reproduce
[x] this issue is present with all tweaks uninstalled(except for default packages) or disabled
[ ] this issue is present after a rootfs restore
[x] this issue is present on the latest version of unc0ver

Logs
Not needed.

Same with Iphone 6 on iOS 12.2.

Same with iPhone 6+ on iOS 12.1.4.

It's cause A7~A8 and A12X devices are not supported with Unc0ver yet... They are supported only till iOS 12.1.2..

It's cause A7~A8 and A12X devices are not supported with Unc0ver yet... They are supported only till iOS 12.1.2..

This is not what has been said on release page...

It's cause A7~A8 and A12X devices are not supported with Unc0ver yet... They are supported only till iOS 12.1.2..

This is not what has been said on release page...

agree

@pwn20wndstuff Hi there,
Is there any major problems with these device so they are being unsupported right now? (Unc0ver on a great number of devices is saying "Unsupported" in recent releases and, You see, must of recent opened issues are about this context...)

https://github.com/pwn20wndstuff/Undecimus/issues/1180#issuecomment-512263553

#1180 (comment)

Thanks, but it was even better if that has been said on release information page...
I upgraded from 11.3.1 to 12.2 few days ago JUST because i was thinking Unc0ver is supporting that, so please write these IMPORTANT points on Readme or Releases page so nobody gets into trouble like me.


[WIP] Fixing the history behavior

Repaint mode switching after the 1sec case
Back to history cursor with len for not used -> fixes the skipping the
most recent
unit tests not yet adapted
None logic not yet smart to be able to leave history traversal

@sholderbach - I'm glad someone is fixing it, tell me if I can help you in any way

@sholderbach - maybe it's useful to integrate with this attempt to fix by sherubthakur https://github.com/sherubthakur/reedline/commits/history-fix-cursor-update

I rebased onto that. But stepped onto new weird interactions

I rebased onto that. But stepped onto new weird interactions

Post-mortem on that one:
The interaction observed that reset the history browsing all the time was the introduction of the separate Up and Down edit commands for multiline, that were missed by the guard at the beginning of run_edit_commands

Looks good!


Feature/#11 improve threshold constructors

Codecov Report

Merging #94 into master will increase coverage by 0.29%.
The diff coverage is 92.85%.

@@             Coverage Diff              @@
##             master      #94      +/-   ##
============================================
+ Coverage     78.56%   78.86%   +0.29%
- Complexity      367      382      +15
============================================
  Files            91       94       +3
  Lines          2622     2678      +56
  Branches        271      276       +5
============================================
+ Hits           2060     2112      +52
- Misses          425      428       +3
- Partials        137      138       +1

Impacted Files
Coverage Δ
Complexity Δ

...r/cryptoconditions/ThresholdSha256Fulfillment.java
94.28% <ø> (ø)
1 <0> (ø)
:arrow_down:

...ger/cryptoconditions/ThresholdSha256Condition.java
92.4% <ø> (ø)
3 <0> (ø)
:arrow_down:

...er/cryptoconditions/PreimageSha256Fulfillment.java
100% <ø> (ø)
1 <0> (ø)
:arrow_down:

.../org/interledger/cryptoconditions/Fulfillment.java
100% <100%> (ø)
1 <1> (?)

...interledger/cryptoconditions/ThresholdFactory.java
91.66% <91.66%> (ø)
10 <10> (?)

...ledger/cryptoconditions/BooleanCircuitFactory.java
94.73% <94.73%> (ø)
4 <4> (?)

Continue to review full report at Codecov.

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

Holding this PR pending the outcome of https://github.com/rfcs/crypto-conditions/issues/34.


fix: terminate lambda: don't specify architecture

Description
https://github.com/npalm/terraform-aws-gitlab-runner/issues/464 reports that the architectures argument was added in the AWS provider 3.61.0 and this module specifies 3.35 as a minimum.
The architectures argument is optional and defaults to 'x86_64' anyway.
This removes it so that it's compatible with the older AWS provider.)
Migrations required
NO
Verification
Verified using the runner-default example
Documentation
N/A

This may not be wanted/needed, considering https://github.com/npalm/terraform-aws-gitlab-runner/pull/460 and the future AWS provider 4 support in this module.

@joshbeard thanks, sorry for the delay

No problem!


[Core] Support 'ExpandoObject' in 'InsertAll' via 'TableName'.

Code below must be supported.
using (var connection = new SqlConnection(connectionString))
{
	var customer = new ExpandoObject() as IDictionary<string, object>();
	customer.Add("Id", 10045);
	customer.Add("LastUpdatedUtc", DateTime.UtcNow);
	connection.InsertAll("Customer", new [] { customer });
}

This is now deployed at RepoDB v1.12.5-beta1.


Use journald as log_driver for the containers

As highlighted by @SeanMooney on https://issues.redhat.com/browse/OSPRH-153, we would like Podman log behaviour to be the one provided by the journald log_driver, which has been the default for a while.
The centralized logging retrieval system for the EDPM will expect the logs for all the containers to be stored in the journal.

recheck

The issue is caused, at least in nova, because the change I introduced is making tests fail. This test:
TASK [Assert the container stdout log exists nova_compute] *********************
fatal: [compute-1]: FAILED! => changed=false
assertion: log_exists.stat.exists
evaluated_to: false
msg: Container stdout log for nova_compute does not exist

It makes sense. As we change the log_driver to podman, the file "/var/log/containers/stdouts/{{ item }}.log" is not written.
I am removing that test and let that run again.

I have decided to remove the test for the moment. Currently, nova does not write their logs to stdout so podman does not pick anything and send it to journald, so there is nothing actually to test.
An appropiate test can be written down when nova starts writing logs to stdout in the container.


baseline performance of RNN and LSTM?

Could someone point me to any reference of baseline RNN and LSTM performances on some character-level text modelling task?
I'm implementing RNN and LSTM with my own code and not sure if I implemented them correctly.
I also posted here:
https://github.com/karpathy/char-rnn/issues/167
Thank you very much!

By the way, I think it might be a good idea to post a chart of baseline performances for this repository so that people can have an idea what performance to expect without/before running the code.


Added the ability to add markers to the map using events

-Added the ability to add markers to the map using events

Changes all look good to me, will test this locally on my end. - Alex

Once that is done. Let me know and I will merge.