Enable Packit for automatic Copr builds

Add configuration for packit-as-a-service to enable automatic Copr builds for pull requests.
We can also use this in the future to simplify updating the Fedora Rawhide package.

Coverage remained the same at ?% when pulling aedcd98f85d27ff399a8404fcbc3b5106af47321 on tyll:packit into b211229a7d3087b2f4bf30fa94bd7cd0bb5364c2 on nmstate:master.

Any example how to use this packit? It seems create a copr repo for each PR which I don't see any use of it.

Any example how to use this packit? It seems create a copr repo for each PR which I don't see any use of it.

The Copr repo for each PR makes it easier to test the PR for others to check if their specific bug is fixed. In a next step we can also use it to automate updating the Fedora Rawhide package.

@lachmanfrantisek another question:
We have different spec files in Fedora and downstream, because we do GPG verification in the Fedora spec file:
https://src.fedoraproject.org/rpms/nmstate/blob/master/f/nmstate.spec#_45
We cannot do this for downstream CI releases, do you have any recommendations about how to handle this if we also want to enable automatic updates for releases in Fedora Rawhide?

Travis CI succeeded on the optional jobs and RPM building worked on the required job, therefore I will ignore the Travis failure.

We cannot do this for downstream CI releases, do you have any recommendations about how to handle this if we also want to enable automatic updates for releases in Fedora Rawhide?

You can probably download the Fedora version in the pre-sync action (https://packit.dev/docs/actions/).
Something like this should work:
actions:
  pre-sync:
    - "curl https://src.fedoraproject.org/rpms/nmstate/raw/master/f/nmstate.spec -o nmstate.spec"


php artisan admin:create-user 失败

Laravel Version: 5.7
PHP Version: 7.2.1
Laravel-admin: 1.6.1

Description:
php artisan admin:create-user 失败,到 Please enter a username to login: 时输入完成按回车
提示   LogicException  : Choice question must have at least 1 choice available.
Steps To Reproduce:
php artisan admin:create-user 输入完成后按步骤进行到 Please enter a username to login:
输入完毕后出现的异常

Check table admin_roles it should not be empty

My admin_roles was empty and when I did a php artisan admin:install command and administrator role was added to the table. after that when I ran a php artisan admin:create-user, I managed to create the user successfully without getting the same error.


Add offsets in SimpleParser to better specify regions in the spritesheet

(downward compatible)
Super MX spritesheets (https://supermx.itch.io/super-mx) contain 4 animations per sheets for each direction (UP, DOWN, LEFT, RIGHT), I solved this easily with offsets in the SimpleParser, each parser for one direction/animation
(Minify was done with https://javascript-minifier.com/)
Great and simple library!

Thanks a lot @SuperMX !


Don't get a write lock when querying the parent reseed_count or strength

A read lock should be sufficient when all we are doing is querying the parent DRBG reseed_count or strength.
Partially fixes #20286
I've marked this for master/3.1/3.0 although it is unclear to what extent this is backportable since it adds new API in the fetchable DRBG interface.

Thinking about it more - the strength should be constant, shouldn't it? In that case no lock would be needed at all.

I am not quite sure this is worth it as the most interesting function - EVP_RAND_generate() is still taking the write lock. IMO there should be another way to improve the locking - i.e. do not actually take a lock at all if we are in the per-thread instance. Only take it when inside the primary drbg.

This is not correct. We already do this. EVP_RAND_generate() does not take a write lock to do the actual generation. It already runs locklessly for the per-thread instance. It is only when we invoke calls on the primary DRBG that we hit the write lock.

The thread local instances don't get locking enabled, so applications aren't generally going to see any change. The primary DRBG will have locking but it's queried rarely and as part of expensive blocking operations.

I re-examined this issue to check what I was seeing wasn't some illusion due to running this in a debugger. I instrumented libcrypto to keep a count of the number of write locks obtained and then ran this code against it:
#include <openssl/rand.h>
#include <stdio.h>

extern int wlockcnt;

int main(void)
{
    unsigned char buf[32];
    int i;

    /* Warm us up and cache everything we can */
    for (i = 0; i < 10; i++) {
        if (!RAND_bytes(buf, sizeof(buf)))
            abort();
    }

    tmp_reset_write_lock_cnt();

    for (i = 0; i < 1000; i++) {
        if (!RAND_bytes(buf, sizeof(buf)))
            abort();
    }

    printf("Write locks taken: %d\n", tmp_get_write_lock_cnt());

    return EXIT_SUCCESS;
}

The output was:
$ ./randbytes
Write locks taken: 2000

Or in other words 2 write locks taken per call to RAND_bytes(). One of those comes from the issue fixed by #20929. The other one is fixed by this PR. I applied the fix from #20929 and this fix on top of my instrumented master and re-ran the above test:
$ ./randbytes
Write locks taken: 0

The reason that we hit the primary DRBG lock on every generate call is this code in ossl_prov_drbg_generate():
https://github.com/openssl/openssl/blob/e0f1ec3b2ec1b137695abc3199a62def5965351f/providers/implementations/rands/drbg.c#L662-L664
i.e. we get the parent reseed count every time we generate and use the parent lock to do so.
It turns out that we only get the parent strength on a reseed event. The changes in this PR will turn that from taking a write lock to a read lock. We could additionally cache it but I'm not too sure its worth it.

Fixup pushed addressing feedback. Please take another look.

The reason that we hit the primary DRBG lock on every generate call is this code in ossl_prov_drbg_generate():
https://github.com/openssl/openssl/blob/e0f1ec3b2ec1b137695abc3199a62def5965351f/providers/implementations/rands/drbg.c#L662-L664

I still feel like adding another provided call just for this is a little bit overkill. What happens if we do not get the correct reseed count? At worst we needlessly reseed now or we reseed in next call instead of now. That does not seem to me like a disaster. Same for the get_strength. Perhaps we could just remove the parent lock calls in these two places completely?

I still feel like adding another provided call just for this is a little bit overkill. What happens if we do not get the correct reseed count? At worst we needlessly reseed now or we reseed in next call instead of now. That does not seem to me like a disaster. Same for the get_strength. Perhaps we could just remove the parent lock calls in these two places completely?

We could manage the reseed count as an atomic instead of via lock. That helps to ensure we always get the right value for our own providers but not for 3rd party authors. If we go this route though there is an implied behaviour change (DRBG authors can no longer rely on the lock being obtained when reading the reseed count)

We could manage the reseed count as an atomic instead of via lock.

As a general strategy, that is what we should be doing IMHO.
No code should be relying on the implementation details of whether we lock or use atomics within the implementation of a given function. If we haven't documented that explicitly as something DRBG authors can rely on then it isn't part of the API and we should (when we change this) also add some explicit text about authors not being able to make any assumptions about the locking state when their implementation is called unless it has been explicitly documented as being guaranteed.

I still feel like adding another provided call just for this is a little bit overkill. What happens if we do not get the correct reseed count? At worst we needlessly reseed now or we reseed in next call instead of now. That does not seem to me like a disaster. Same for the get_strength. Perhaps we could just remove the parent lock calls in these two places completely?

Reseeding next time instead of this time is the most likely possibility.
Reseeding now and again next time might be possible with a partially updated counter -- not sure about this.
An alternative might be to try without lock and if there is a change, repeat with lock.
Adding another public provider API just for this does seem like a lot to me too.
@mattcaswell wrote:

We could manage the reseed count as an atomic instead of via lock. That helps to ensure we always get the right value for our own providers but not for 3rd party authors. If we go this route though there is an implied behaviour change (DRBG authors can no longer rely on the lock being obtained when reading the reseed count)

I considered this at the time and have even made a couple of false starts changing it (& will likely do so again in the future).  Each time I came to the conclusion that it wasn't ideal because we cannot know what semantics a third party provider required -- we don't know how much computation is required e.g. or if the provider state changes on access or even if this triggers a reseed.

I have an alternative version to this in #20970. In that version we obtain the reseed_count without a lock and there are no API or behaviour changes required to achieve it.

Just a read with a memory barrier should be sufficient for this!

Just a read with a memory barrier should be sufficient for this!

It would be if we knew enough about the parent.  I don't think we do.
The problem is the architecture of the parent is alien and unknowable (as per the provider design).
We don't even know where to read from or what size the value is.
I'm okay with this PR if the rand_lock_ex API is removed.  Stick with the write lock -- it's not perfect but the performance impact shouldn't be noticeable since it is rarely taken.

Just a read with a memory barrier should be sufficient for this!

It would be if we knew enough about the parent. I don't think we do. The problem is the architecture of the parent is alien and unknowable (as per the provider design). We don't even know where to read from or what size the value is.
I'm okay with this PR if the rand_lock_ex API is removed. Stick with the write lock -- it's not perfect but the performance impact shouldn't be noticeable since it is rarely taken.

Could you be more specific, please? Do you mean to remove the lock function calls for the cases where this PR takes read locks?

Use a write lock instead of a read in those cases.

Use a write lock instead of a read in those cases.

Then the write lock will be taken for every RAND_bytes() call. This makes the PR moot.

Argh, ignore my ramblings.  I was thinking strength again.
Getting it sans lock then.  Worst case a late or extra reseed - both are livable.  Importantly, none of the FIPS mandated reseedings will be missed or delayed.

Agreed.

Closing this one in favour of #20970


ci: use subcommands in helper and stop using jq

In #101 and #103, I agreed to port the code from jq to pure python. This pr implements that change and also merges the two helper python scripts into one file.
I also fixed a regression where not all cargo debs were being produced, and not all binaries were getting copied into the artifacts dir.

Side note: writing this script really made me regret not just using rust. Having an actual type checker so I didn't have to guess all the time, would have been really nice.


Add on demand profiling / heapdump

It would be nice to trigger CPU profiler and heapdump via SIGHUB, file or socket.
https://www.npmjs.com/package/v8-profiler
https://www.npmjs.com/package/heapdump

Mmmm, yum.  Would be even nicer to be able to get it into SPM, like the JVM profiler data - https://sematext.com/blog/2016/03/17/on-demand-java-profiling/


Gear icon links to developer docs, but looks like settings

Google, e.g., uses a very similar icon for settings.

this is fixed!


docs: The README in the docs folder needs intro & expansion on content for all the pages

There should be a brief overview about how the documents are laid out on the Docs README page.

One additional suggestion ~ we should reorganize the Components section so that the main Application Model constructs are grouped together (Component, Trait, Application Configuration) and then related concepts should be nested under their parent (ie workloads under Component)

I created a new issue to track the follow up comment as they can be addressed independently.
One additional suggestion ~ we should reorganize the Components section so that the main Application Model constructs are grouped together (Component, Trait, Application Configuration) and then related concepts should be nested under their parent (ie workloads under Component)

@macolso, do you think #451 fixes this?


Can't use original text as might still be "Copied"

If the 1s timeout hadn't passed then we'll be reinstating the wrong
text for subsequent events, easy to trigger with a double click.
No change to the C++ resource as this feature is in the online HTML
only.
See https://github.com/lancaster-university/codal-microbit-v2/issues/110#issuecomment-859475124

You can test this with the file built with npm run test in this folder. It uses local references to the dl.{js,css} files that are usually on microbit.org. I'll update the microbit.org files once this is merged.

CC @jaustin for review

thanks @microbit-matt-hillsdon!


Revert "[feat][doc] Add saslJaasServerRoleTokenSignerSecret parameter in security-kerberos.md"

Reverts apache/pulsar#15172

Why revert that patch ?   Please add motivation.

When dealing with conflicts, this pr also adds other modifications and needs to be adjusted.


Network Switcher overhaul

Network Switcher updates

Changes 👷♀
Extended networks config with links.
Updated network switcher render components to show new links sections.
Implemented new behavior for revealing/hiding links sections.
Implemented L2Beat link section below the separator
Implemented showing/hiding the bridge widget
How to test 🧪
Follow up ticket and linked figma design with all relevant comments to track all UI changes.

@jakubswierczek Fixed comments. Please have a look :)


Sending packets with increasing timestamp according to Akamai docs

Temp PR to demonstrate sample implementation of sending frames with increasing timestamp

In short, the algorithm works as follows:
Collect all frames until the next video and audio frame has larger timestamp than some current pivotFrame. Then send all the frames sorted by timestamp and assign a new pivotFrame.
Basically, in order for it to work both audio and video frames have to be sent regularly as I wait for both audio and video frame dts to be larger than pivot frame dts before sending anything out. I thought it will be problematic when audio is muted, but you send "empty" audio frames in that case. So it works fine when audio is muted. Is there any case when only video or audio frames would be sent?
I also removed assigning mAudioSequenceHeader and mVideoSequenceHeader as you don't use it anywhere.
BTW I've tested this on Vimeo as well which doesn't require such timestamp sorting and it works fine too.

I don't understand. What do you means with "worked for a while"?
Do you means your implementation or with my implementation?
Where is the error? Stream stop after few minutes?

@pedroSG94 Sorry for providing that little info :)
I've tested your solution again. The result is that either there is video but no audio or the stream works fine for 2 seconds and stops (like it was before applying changes).
I've logged dts values in SrsFlvMuxer.sendFlvTag() method. It turned out that subsequent frames didn't have increasing dts. Correct me if I'm wrong, but It's probably because
frame.dts = (int)((System.nanoTime() / 1000 - startTs) / 1000);
was added in StsFlvMuxer.writeRtmpPacket() method which can be called from either Video or Audio encoder, which works on different threads.
After moving this line frame.dts = (int)((System.nanoTime() / 1000 - startTs) / 1000);
to SrsFlvMuxer.sendFlvTag() method, which is right before sending a frame, the dts values are increasing and stream works well.
So basically your simple solution works very well, we'd just need to move setting dts just before sending a frame.

You are right but that was working for me for some reason O.O (maybe only luck)
This should be like this:
https://github.com/pedroSG94/rtmp-rtsp-stream-client-java/commit/ad6eccb392f37ada61be354cd55fbbf18a1ec2e8
Also I added a method to make it optional

@pedroSG94 Works well. Good idea with making it optional, however, there is no access to SrsFlvMuxer class from RtmpCamera class so we can't set this flag.
What do you think about adding a comment above the akamaiTs flag to make it clear what is it for, like:

Some Livestream hosts use Akamai auth that requires RTMP packets to be sent with increasing timestamp order regardless of packet type. More info here https://learn.akamai.com/en-us/webhelp/media-services-live/media-services-live-encoder-compatibility-testing-and-qualification-guide-v4.0/GUID-F941C88B-9128-4BF4-A81B-C2E5CFD35BBF.html

Yes, good idea.
I will provide access to it and set that comment in the method.

I merged this feature to master. Thanks for your help

Thank you :)


Help

Please set your Discord Presence to Online to talk to the bot!
It keep saying

Is your status showing online for your account?

yes

Hmm well the only check i have for that is on line 136-139
if ( !msg.author.presence.status || msg.author.presence.status == 'offline' || msg.author.presence.status == 'invisible' ) {...}

And checking the docs those objects should still be the same

Same issue here. It seems like msg.author.presence.status is returning offline even though the user account i'm testing with has online status.

Ah i see, its most likely related to discord changes with privileged intents, ill look into this https://discordjs.guide/popular-topics/intents.html#the-intents-bitfield

And how it fix ?


fix: import job app-store bucket Failed when it does not exist

When execute import task, if the BUCKET do not exist, the task continues to the end,  in fact ,the import task failed.

/lgtm

/cc @zheng1


feature/ZeroMQ

Add ZMQSubSource and SMQPubSink for streaming over ZeroMQ protocol which is also by default in GNU Radio.
I think I have made it as a feature activated by default.
It also come with two binaries (one receiver, one emitter) that can talk to each other and/or with GNU Radio.
Apparently the topics is not settable in GNU Radio thus I have not provided way to set it. Maybe I should?
Close #3

Awesome! With example and even feature-gated. Really cool :-)
I'll merge this as is and do some minor follow-up patches (mainly because I'll be afk the next days and want to avoid stalling this through a lot of back-and-forth).
Regarding error handling: in the functions that return a Result<X>, you can use the ? operator to deal with errors. In case of an Option<X>, you could use .context("option was none")? instead of expect() or assert!(....is_ok()).
There are also some related questions, I thought about. Maybe you have some thoughts here as well:

I'm not sure if such blocks should be typed, i.e., ZmqSubSource(4, ...) or ZmqSubSource<u32>(...). I think at some point, we might have to switch to typed blocks, since the alignment of data in the buffer cannot only be determined by the size of the data (see align_of). I'll also have adapt Copy and NullSource etc.
I also prefer ZMQSubSource but it seems to be idiomatic Rust to write ZmqSubSource. It's also why I called PMTs Pmts. But in this case, we could anyway get around this by putting the blocks in a submodule/subfolder and have zmq::SubSource. This also eases feature-gating and (IIRC) there are other transfer modes, so we might add more blocks in the future.
I'm not sure what to do with default features. Since compile times tend to get large, I thought about keeping them minimal and also remove soapy and vulkan. The binaries and examples can be annotated with required-features so one will get a nice message, telling the user to enable the feature. Unfortunately, there doesn't seem to be a user config to overwrite default features, for example, if you work on the ZMQ stuff. So the only option would be to edit Cargo.toml temporary and add the feature.

Thanks again!

Concerning having typed blocks, I have mix feeling. Somehow I think the runtime could do the transformation and thus we can have "agnostic" blocks. But on the other side, It would probably increase overhead and thus may not be a good idea.
So maybe we should have transformation blocks moreover with typed blocks indeed.
NB: Thanks for the tip about context (I am a rust newbie).


Add Object.map method

Example code:
Object.map = function(obj, fn) {
    var result = [];
    Object.each(obj, function(key, value) {
        result.push(fn(key, value));
    });
    return result;
}

What does it? Converts all key, value properties to a list. "map" cause I go trough all properties and map them to a new object. Example:
var obj = {foo: 'bar', bar: 'foo'}
var result = Object.map(obj, function(key, value) {
    return {
        key: key,
        value: value
    };
});
console.log(result); // [{ key: 'foo', value: 'bar'}, { key: 'bar', value: 'foo' }]

Useful when you does some map reduce work and used your object as hash map and want to convert it the key/value pairs in single objects.
Or is it already included?

Well, Object.each will step through each property of an object, so I think more straightforward would be simply:
var result = {};
Object.each(obj, function(key, value) {
  result[key] = someNewValue(value);
});

etc. If you were trying to get values from an object into an array, then this method would be more what you want:
Object.keys(obj).map(function() {
   return someNewValue(obj[key]);
});

Object.values also exist, and may also be of use. In any case between the 3 methods there is probably a way to achieve what you are trying to do that would be the preferred, more explicit way of doing it.

Thanks for the advice I thing this issue now unnecessary.


Enable ccache for interactive builds

Reattempting reverted #225
This PR enables ccache in build-in-docker script by default, closes #222.
A repeated no-change build with the native build dir cleaned is ~90 seconds
A repeated no-change build without removing the native build dir is ~30 seconds
The PR proposes to change the default to not skipping the clean of libcudf build unless CCACHE_DISABLE=1 is set.
Manual override of libcudf.clean.skip is honored.
Signed-off-by: Gera Shegalov<EMAIL_ADDRESS>

build

build


Add Bulgarian to the list of languages

Bulgarian is now at 100% for Riot iOS and MatrixKit.
It has been tested, including on small screen devices (iPhone 5S).

Thanks a lot @rbozhkova for your contribution.


KCFloatingActionButton layout issue

Hi, I'm getting the layout issue in the picture below. Is there any way to resolve this?

Also, this might be an edge case but KCFABOpened(_ fab: KCFloatingActionButton) is getting called even when menu is open. In order to test edge cases and try to reproduce the issue above, I opened the menu, minimized the app and clicked on the menu again. Instead of closing the menu as the menu was already open, clicking on the menu created another layer of menu items on top of the previous menu items as KCFABOpened(_ fab: KCFloatingActionButton) was getting called rather than KCFABClosed(_ fab: KCFloatingActionButton). Any ideas?

You might need to check the 'closed' property if its being set correctly in the lib, chances are that something is causing it to be set to true when you put the app in the background. A quick fix would be to subscribe to the didEnterBackground notification for you app and manually close the menu by calling the close() method on the fab.


Incorrect rendering of form with radio buttons

I tried to create a simple form with 2 radio buttons and the buttons are rendered side by side horizontally. Would have expected that the radio buttons would be vertically stacked by default (as this is the bootstrap 4 default according to docs, see url below).
view/form:
from django.views.generic import FormView

class TestForm(forms.Form):
    OPTIONS = (('1', 'Yes'), ('0', 'No'))

    options = forms.ChoiceField(
        label="Simple form",
        choices=OPTIONS,
        widget=forms.RadioSelect)

class Index(FormView):
    template_name = 'index.html'
    form_class = TestForm

template index.html:
{% load bootstrap4 %}

{# Load CSS and JavaScript #}
{% bootstrap_css %}
{% bootstrap_javascript jquery='full' %}

{# Display django.contrib.messages as Bootstrap alerts #}
{% bootstrap_messages %}

{# Display a form #}
<form action="/url/to/submit/" method="post" class="form">
  {% csrf_token %}
  {% bootstrap_form form %}
  {% buttons %}
    <button type="submit" class="btn btn-primary">
      Submit
    </button>
  {% endbuttons %}
</form>

result:
Simple form
( ) Yes  ( ) No
[Submit]

expected result:
Simple form
( ) Yes
( ) No
[Submit]

The form part of the generated HTML looks something like this:
<form action="/url/to/submit/" method="post" class="form">

    Simple form

        <input type="radio" name="options" value="1" class="" title="" required="" id="id_options_0"> Yes

        <input type="radio" name="options" value="0" class="" title="" required="" id="id_options_1"> No

    <button type="submit" class="btn btn-primary">
      Submit
    </button>

</form>

Looking at the bootstrap 4 documentation it looks like each radio button should be placed inside a div with the class form-check to get the default stacked layout.
Furthermore i cannot find any references to the classes radio and radio-success in bootstrap 4, these 2 are added in post_widget_render for RadioSelect.
After browsing through the django-bootstrap4 code quickly i found def radio_list_to_class(self, html, klass) which maps
 and
 to empty string. If the radio buttons really are supposed to be inside a div with class form-check then we should probably change the mapping to look like this
mapping = [
            ("<ul", '<div class="{klass}"'.format(klass=classes)),
            ("
", "
"),
            ("
", '
'),
            ("
", "
"),
        ]

Trying this locally at least I get the default stacked layout that I expected, but I'm not sure if this will break some other layout. Or am I missing some other parameter here which can solve the initial problem?

I also noticed this same problem with the radios rendering horizontally instead of vertically by default. The rendering works as expected in 0.0.6 but changed to horizontal in 0.0.7.
Looking at the rendered markup, the .radio class is being applied to a div containing all of the labels/inputs, which is "incorrect" Bootstrap markup according to their docs.

Yip, noticed just that and was driving me nuts. Please fix!

I forked the repo and fixed this long time ago. However since nobody replied to this issue, until recently, I just assumed that nobody else cared or that the current behavior was intentionally. I've done a pull request #145  for this together with a fix for the submit button styling (should have btn-primary). We'll let the maintainers decide if the fix should be included or not.
Meanwhile if you want to try it out you can get the fork from
https://github.com/parander/django-bootstrap4/tree/radio-button-layout-fix
This branch is up to date with the latest master & also has the 2 fixes mentioned above.

I forked the repo and fixed this long time ago. However since nobody replied to this issue, until recently, I just assumed that nobody else cared or that the current behavior was intentionally. I've done a pull request #145 for this together with a fix for the submit button styling (should have btn-primary). We'll let the maintainers decide if the fix should be included or not.
Meanwhile if you want to try it out you can get the fork from
https://github.com/parander/django-bootstrap4/tree/radio-button-layout-fix
This branch is up to date with the latest master & also has the 2 fixes mentioned above.

Thank you very much Sir. Much appreciated.

Thanks @parander! We @zostera are a bit stuck in BS3 because of long running projects using Bs3. Please feel free to submit PR's for anything that can be improved. If you would be interested in help maintaining the BS4 package, contact us.

Does aabd551aefc6c2dbd56dac4c5030d175c1120f96 fix this for you?

Closing this issue because the original poster does not seem to respond.


Add revertable commands

Pull Request
Title
Add revertable commands (competing with #384).
Type of Change

[x] New feature
[x] Refactoring
[x] UI/UX improvement

Description
Revertable commands are added, and a database of commands which have previously been run is stored (in ~/.local/state/linutil_scripts.toml). At startup, the toml is read to determine which entries should be set to revert by default, and when a command (either normal or revert) is completed successfully, the appropriate data is written to the toml.
This is based upon the multi selection PR (#338), so the feature is fully implemented. Pressing 'r' inverts the entries shown (Revert -> Normal and vice versa). Scripts which don't support reversion have revertable = false added to their tab data entry & function normally. When multi selection is enabled, pressing 'r' does not invert currently selected options.
This is also based upon #247, since the refactoring done there could otherwise cause merge conflicts. That pull request has no downsides and should be merged before this one regardless.
Implementation within scripts matches #384; revertable scripts have a run() and revert() function, and they're run by sourcing the script and running the appropriate function. Non revertable scripts (which are not possible in #384), are executed exactly the same way they were prior to these changes. Revertable scripts were implemented by @nnyyxxxx, the commits are fully intact and can be viewed within this PR.
UI example: https://github.com/user-attachments/assets/e773d71f-c410-4a29-b38b-a95b0133f6d4
Please reference https://github.com/ChrisTitusTech/linutil/pull/401#issuecomment-2351825078 and https://github.com/ChrisTitusTech/linutil/pull/401#issuecomment-2351828878 regarding accusations that I've "stolen" code. TLDR; the person making this accusation was not acting in good faith whatsoever and just wanted to shut down discussion.
Testing
Commands are correctly updated in the TOML & UI on next entry, reversion of scripts works correctly
Impact
The dirs crate has been added as a dependency for linutil_core in order to fetch the preferred state directory (typically ~/.local/state) as well as possible. Another TOML is being read at startup & written to after successful command execution, which will slightly degrade performance.
Issue related to PR

Resolves https://github.com/ChrisTitusTech/linutil/issues/240
Resolves https://github.com/ChrisTitusTech/linutil/issues/260
Resolves https://github.com/ChrisTitusTech/linutil/pull/362

Additional Information

Checklist

[x] My code adheres to the coding and style guidelines of the project.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generate no errors/warnings/merge conflicts.

As discussed in #384 This PR is disgusting, this guy has spent a total of 5+ hours arguing with us over unneeded functionality that hes adding. I don't agree with these changes and I never will. And on top of that these new UI changes would be incompatible with #338 where as me and Adams PR should be fully compatible. Also these new UI changes just over complicate things, in the original PR a keybind is used "R" to instantly revert the changes, and it is shown in the dynamic hotkey list when hovering over an option: The original revert approach is much better and simpler and costs much less to use instead of having to gather data based on what the user is doing. Not to mention that this guy is LITERALLY taking everything that I made and tested into this junk, not even bothering making new functionality to suit his PR.

this guy has spent a total of 5+ hours arguing with us over unneeded functionality that hes adding

Healthy discussion over implementation details is incredibly important for any project. I'm very pleased to confirm that I've spent quite a while discussing these details and both improving my design and giving them ideas to improve theirs.
It's true that the functionality is "unneeded". But just about nothing is "needed", we make improvements regardless. Script reversion is a feature, it's not mandatory for the project to include it.

And on top of that these new UI changes would be incompatible with https://github.com/ChrisTitusTech/linutil/pull/338 where as me and Adams PR should be fully compatible.

This is total nonsense, I've quite literally built this PR on top of #338, and made sure to include full compatibility. The competing PR, on the other hand, will absolutely not work correctly with the aforementioned changes.

in the original PR a keybind is used "R" to instantly revert the changes, and it is shown in the dynamic hotkey list when hovering over an option

This PR proposes offering the user default options based on which scripts they've previously run and completed. The key to invert suggestions is only a backup in case someone wants to re-run a script or if a script has been renamed or the default is otherwise inaccurate. Multi selection, as previously mentioned, would be totally incompatible with the competing PR without a major rework.

The original revert approach is much better and simpler and costs much less to use instead of having to gather data based on what the user is doing

The performance impact of this PR is insignificant; we're already reading many TOML files due to #153, and this only adds one additional file. The performance impact of writing to a TOML file after a command is finished will also be negligible. Which UX is simpler to use is the topic up for debate here, and it's quite literally the reason I worked on this. Storing data locally on which scripts have been run is not problematic in any way, and similar functionality exists in countless programs. The commenter has accused these changes of being "telemetry", which is factually incorrect.

Not to mention that this guy is LITERALLY taking everything that I made and tested into this junk

The commenter has written these scripts for a revert implementation, and published the code in a repository under the MIT license. If he would like to write future software under a proprietary license, that is his choice, but I retain the rights that apply to the existing code. I agree with the way these scripts are implemented, so I chose to keep them. He appears to be suggesting that I waste unnecessary time writing duplicate code due to the idea that it's 'theft' to use permissively licensed code, and that he has exclusive rights over the code & exact accompanying implementation, which unfortunately is not true.

AND I do not agree with the non-revertible commands feature hes making, IMO an echo should be shown if the script is not revertible

I disagree with this, and that's part of the reason I created this PR. Instead, I decided to not even offer the user to revert a script if the script doesn't support the feature. It's good to have discussion over which solution is preferable.

This PR Is taking me and Adams work, rebranding it as LJ's

Nothing that Adam has written is included within this PR. Adam wrote a UI implementation competing with this one; No code from his implementation is contained within my PR. I have indeed brought your scripts into the PR, which I have full rights to do nearly anything with, including even rebranding them as my own. However, I have not rebranded them. Your commits remain fully intact, and I have explicitly stated numerous times that you were the author of them.

adds user data collection and tracking that is also unneeded

This was mentioned earlier, in his accusation that I've added "telemetry". Nothing is being sent to a server or anywhere off the user's device, so this is completely untrue. I have given a full explanation as to why I think storing a file locally with already run scripts is a good idea; Everyone should be free to discuss the merits of the idea, presuming they remain within reason rather than making unfounded accusations.

and does not give ANY credit for the revert functionalities that I WROTE everywhere in this PR

I have not tried to obscure that you wrote those scripts whatsoever. I've edited the PR to be even more clear that the current revert scripts were completely implemented by you and I didn't contribute to them whatsoever. I hope this meets your expectations.

adds user data collection and tracking that is also unneeded

This was mentioned earlier, in his accusation that I've added "telemetry". Nothing is being sent to a server or anywhere off the user's device, so this is completely untrue. I have given a full explanation as to why I think storing a file locally with already run scripts is a good idea; Everyone should be free to discuss the merits of the idea, presuming they remain within reason rather than making unfounded accusations.

In all projects we REMOVE telementry not add it. So this will not be merged.

In all projects we REMOVE telementry not add it. So this will not be merged.

You see, you've fallen for his nonsensical framing of the issue. This is not telemetry. Telemetry is when you send data to a remote server. This data is being stored entirely locally and never leaves the user's device. I develop primarily free software, and I do not add telemetry to anything I work on.

In all projects we REMOVE telementry not add it. So this will not be merged.

You see, you've fallen for his nonsensical framing of the issue. This is not telemetry. Telemetry is when you send data to a remote server. This data is being stored entirely locally and never leaves the user's device. I develop primarily free software, and I do not add telemetry to anything I work on. This is the problem with these accusations, they lead to ideas being shut out without proper thought. And that's very clearly what he was intending with that accusation.
If you're opposed to storing data locally, please make commits to your favourite text editor removing the list of recently opened files. Or to nearly any GUI application, removing storing the previous window size and position. Or to your package manager, for storing a database of installed packages.

Well adding what you call not telementry is called BLOAT what is not needed. I have been helping Chris since June so I know what PR's he likes and what PR's he does not. As this does steal code from other contributors this will most likely be denied. And the PR that was original will be merged.

Healthy discussion over implementation details is incredibly important for any project.

https://github.com/ChrisTitusTech/linutil/pull/384#issuecomment-2351761222 https://github.com/ChrisTitusTech/linutil/pull/384#issuecomment-2351762809 https://github.com/ChrisTitusTech/linutil/pull/384#issuecomment-2351764809 https://github.com/ChrisTitusTech/linutil/pull/384#issuecomment-2351772987 https://github.com/ChrisTitusTech/linutil/pull/384#issuecomment-2351793942
Doesn't look very healthy to me.

The performance impact of this PR is insignificant; we're already reading many TOML files due to https://github.com/ChrisTitusTech/linutil/pull/153, and this only adds one additional file.

Reading a file and making TUI changes at runtime can cause performance issues with a lot of entries. You've said it yourself before.

The commenter has accused these changes of being "telemetry", which is factually incorrect.

This is still collecting data based on user's actions. Could be 100% avoided.

He appears to be suggesting that I waste unnecessary time writing duplicate code due to the idea that it's 'theft' to use permissively licensed code, and that he has exclusive rights over the code & exact accompanying implementation, which unfortunately is not true.

No one said you broke MIT license's terms. What we said is we have a moral issue with you taking nyx's code with pernission. Morality != law.
(this applies to your other points too)

Adam wrote a UI implementation competing with this one

Once again, I'm not here to compete.

Well adding what you call not telementry is called BLOAT what is not needed.

It's called a feature addition, it serves a very real purpose. Storing this data without a real functional use would indeed be bloat and wouldn't belong here.

As this does steal code from other contributors this will most likely be denied.

"Steal". Huh. By fully crediting the person who wrote the code and including completely intact commits? As I stated in the other PR, I could wait for the other PR to be merged and only include code within it that removes @adamperkowski's code and replaces it with mine. That would change nearly nothing.

And the PR that was original will be merged.

The PR which has better UI/UX should be merged. Discussion should be had over that, and I'm certain it will continue. Unfounded accusations of theft and spyware are extremely damaging to that discussion, and we should discontinue them immediately.

Doesn't look very healthy to me.

I can assure you the discussion is completely healthy. Of course, a few of those comments were in slightly bad taste, since they were made in reply to either absurd accusations or extraordinary hypocritical in my eyes. I would like to extend my apologies to those I wrote comments like that to, and would hope they can do the same if they've made untrue and damaging accusations.

Reading a file and making TUI changes at runtime can cause performance issues with a lot of entries.

Well adding what you call not telementry is called BLOAT what is not needed.

It's called a feature addition, it serves a very real purpose. Storing this data without a real functional use would indeed be bloat and wouldn't belong here.

As this does steal code from other contributors this will most likely be denied.

"Steal". Huh. By fully crediting the person who wrote the code and including completely intact commits? As I stated in the other PR, I could wait for the other PR to be merged and only include code within it that removes @adamperkowski's code and replaces it with mine. That would change nearly nothing.

And the PR that was original will be merged.

The PR which has better UI/UX should be merged. Discussion should be had over that, and I'm certain it will continue. Unfounded accusations of theft and spyware are extremely damaging to that discussion, and we should discontinue them immediately.

Again this PR just adds unneeded functionality.. And once again: morality != law you shouldn't just take my work that I sat down and wrote and took time out of my day to do without my approval especially if this is between 2 PRs.

Please read https://github.com/ChrisTitusTech/linutil/pull/401#issuecomment-2351794655 it gives a perfect explanation on why these UI changes are not needed, I have been trying to explain this to you for hours, but you just don't understand..

@lj3954 Please read #401 (comment) it gives a perfect explanation on why these UI changes are not needed, I have been trying to explain this to you for hours, but you just don't understand..

There are plenty of changes that aren't "needed". #153 wasn't needed, but it was a huge improvement to the project, as I'm sure you could agree. #60, and then #82 which was the selected improvement after I discussed with @JustLinuxUser over the merits and chose to back his solution, also majorly improved the project. What's up for discussion is whether these changes improve the project, whether they make the UX simpler, or improve the UI. Not whether they're strictly necessary, which neither of our PRs are.

@lj3954 Please read #401 (comment) it gives a perfect explanation on why these UI changes are not needed, I have been trying to explain this to you for hours, but you just don't understand..

There are plenty of changes that aren't "needed". #153 wasn't needed, but it was a huge improvement to the project, as I'm sure you could agree. #60, and then #82 which was the selected improvement after I discussed with @JustLinuxUser over the merits and chose to back his solution, also majorly improved the project. What's up for discussion is whether these changes improve the project, whether they make the UX simpler, or improve the UI. Not whether they're strictly necessary, which neither of our PRs are.

This change does not improve the UI, what don't you understand? This just adds extra unneeded steps to revert a script... In my approach all you have to do is press R to begin reverting the selected script, in your approach you add unneeded UI changes and unneeded extra steps when trying to revert functionality, and again you're taking my work that I put my time into with my permission: Morality != law... If anything this script just bloats up my approach with extra stuff.. And please drop the sarcasm it's disrespectful.

@lj3954 Please read #401 (comment) it gives a perfect explanation on why these UI changes are not needed, I have been trying to explain this to you for hours, but you just don't understand..

There are plenty of changes that aren't "needed". #153 wasn't needed, but it was a huge improvement to the project, as I'm sure you could agree. #60, and then #82 which was the selected improvement after I discussed with @JustLinuxUser over the merits and chose to back his solution, also majorly improved the project. What's up for discussion is whether these changes improve the project, whether they make the UX simpler, or improve the UI. Not whether they're strictly necessary, which neither of our PRs are.

This change does not improve the UI, what don't you understand? This just adds extra unneeded steps to revert a script... In my approach all you have to do is press R to begin reverting the selected script, in your approach you add unneeded UI changes and unneeded extra steps when trying to revert functionality, and again you're taking my work that I put my time into without my permission: Morality != law... If anything this script just bloats up my approach with extra stuff.. And please drop the sarcasm it's disrespectful.

"Steal". Huh. By fully crediting the person who wrote the code and including completely intact commits?

Exactly. Without (explicit) permission to do so. Again, not saying you broke license terms. We have a strictly MORAL issue with this.

Indeed, we're not competing against each other. We're just writing different implementations and discussing which is preferable and should be kept.

I'm confused. You use the word "compete" / "competing" all the time. It's in the title section of this PRs description for crying out loud.

This just adds extra unneeded steps to revert a script..

In most cases, it actually removes steps, by doing the one thing you've made the worst accusations about (storing a file locally, the horror).

And please drop the sarcasm it's disrespectful.

I was not being sarcastic in the specified text, I just gave you examples of 'unnecessary' changes which still happened to improve the project, as well as even an example where I had a discussion similar to this, with someone else, and we ended up on one solution based on the merits.

Exactly. Without (explicit) permission to do so. Again, not saying you broke license terms.

I'm sorry, I think the suggestion I need to demand permission from anyone to touch a line of their code with full credit given is totally absurd. Or to give them full control over implementation details, just because they wrote something that's required for the implementation, which is what appears to be his main issue here.

I'm confused. You use the word "compete" / "competing" all the time.

#223 also uses it, and it's used in countless other examples. It doesn't mean we're fighting. The solutions are the things competing, and we do disagree on which solution is better. But a discussion over the merits should happen nonetheless, which definitely isn't occurring when you're accusing someone of theft and other things which just aren't true.

Exactly. Without (explicit) permission to do so. Again, not saying you broke license terms.

I'm sorry, I think the suggestion I need to demand permission from anyone to touch a line of their code with full credit given is totally absurd. Or to give them full control over implementation details, just because they wrote something that's required for the implementation, which is what appears to be his main issue here.

I'm confused. You use the word "compete" / "competing" all the time.

#223 also uses it, and it's used in countless other examples. It doesn't mean we're fighting. The solutions are the things competing, and we do disagree on which solution is better. But a discussion over the merits should happen nonetheless, which definitely isn't occurring when you're accusing someone of theft and other things which just aren't true. As I've said above, we should immediately discontinue said accusations, and exclusively discuss which solution for the UI/UX is preferable.

"Competing" is not taking someone elses functionality and adding extra steps / bloat to then actually use the functionality..

In most cases, it actually removes steps

Can you please be more specific about those steps?

I think the suggestion I need to demand permission from anyone to touch a line of their code with full credit given is totally absurd.

No one said that. You're putting words in my mouth. I said we have a moral issue with you knowing we are against you using our (nyx's) code and still doing so.

Should I also get the list of contributors to the project and ask every single one of them individually for every change I'm making if they're okay with me using their code?

And there's the sarcasm @nnyyxxxx is talking about.

"Competing" is not taking someone elses functionality

I agree, I'd propose direct changes to that PR if I was trying to make small changes to the functionality. I'm not, though. I've written a completely different implementation of reversion. Your scripts are compatible with either implementation, and regardless of whichever you prefer, it shouldn't anger anyone that the work they've done, intending to get merged in, is getting merged regardless of the solution used.
You even asked me to start working on such an implementation a few days ago, don't you remember? https://github.com/ChrisTitusTech/linutil/pull/362#issuecomment-2349530281

Can you please be more specific about those steps?

By default, revert is shown for scripts which have already been run; the list of scripts which are stored locally. For nearly all users, that's the behaviour they'd like, so they just need to execute it and it performs what they want it to do.

I said we have a moral issue with you knowing we are against you using our (nyx's) code and still doing so.

This isn't my own project, it's Chris's linutil. @nnyyxxxx proposed merging his changes to the scripts into linutil, and what I've done here matches his wishes. I'm not keeping it to my own project, or sublicensing his work, or doing anything else that would even in the slightest go against his wishes as to what happens to his code. His code would end up in my repositories if #384 was instead merged as well, in the git history.
Writing that part of the code that's used for both implementations doesn't give him the exclusive rights to select which implementation he prefers the project remain with for eternity. That's why, again, I have proposed countless times removing his contributions from this PR and making the PR depend upon yours being merged first instead. But, he has clearly ignored my proposition. So the real concern he has isn't that his commits are included in the PR.

And there's the sarcasm @nnyyxxxx is talking about.

No, it's a reasonable question. Where do these bounds end? His code is included in my PR, yes, but so is Chris's code, as well as the code in the PRs this is based on, and every PR that has been merged beforehand. I'd like to know how far these exclusive rights over where the code can be contained extend.

"Competing" is not taking someone elses functionality

I agree, I'd propose direct changes to that PR if I was trying to make small changes to the functionality. I'm not, though. I've written a completely different implementation of reversion. Your scripts are compatible with either implementation, and regardless of whichever you prefer, it shouldn't anger anyone that the work they've done, intending to get merged in, is getting merged regardless of the solution used.
You even asked me to start working on such an implementation a few days ago, don't you remember? #362 (comment)

That's before I ended up making the functionality and implemented it..

Can you please be more specific about those steps?

By default, revert is shown for scripts which have already been run; the list of scripts which are stored locally. For nearly all users, that's the behaviour they'd like, so they just need to execute it and it performs what they want it to do.

I said we have a moral issue with you knowing we are against you using our (nyx's) code and still doing so.

This isn't my own project, it's Chris's linutil. @nnyyxxxx proposed merging his changes to the scripts into linutil, and what I've done here matches his wishes. I'm not keeping it to my own project, or sublicensing his work, or doing anything else that would even in the slightest go against his wishes as to what happens to his code. His code would end up in my repositories if #384 was instead merged as well, in the git history.
Writing that part of the code that's used for both implementations doesn't give him the exclusive rights to select which implementation he prefers the project remain with for eternity. That's why, again, I have proposed countless times removing his contributions from this PR and making the PR depend upon yours being merged first instead. But, he has clearly ignored my proposition. So the real concern he has isn't that his commits are included in the PR.

And there's the sarcasm @nnyyxxxx is talking about.

No, it's a reasonable question. Where do these bounds end? His code is included in my PR, yes, but so is Chris's code, as well as the code in the PRs this is based on, and every PR that has been merged beforehand. I'd like to know how far these exclusive rights over where the code can be contained extend.

And once again read the first comment of this post.. The added functionality in this PR is not needed and just creates bad UX with extra steps extra functionality and practically bloats the code up..

I'm not keeping it to my own project, or sublicensing his work

Again, NO ONE SAYS YOU ARE. Who are you talking to?

and what I've done here matches his wishes.

I won't speak for nyx, but I'd beg to differ.

No, it's a reasonable question.

I won't even respod to this one.

That's before I ended up making the functionality and implemented it..

Nearly everything I've done here is in writing the Rust for the TUI, and I had and still have no reason to suspect you were asking me to write implementations for each script. I've proposed an implementation for the UI, while using the scripts you want to be merged into the project regardless of who's UI is chosen. Correct?
If you were the one who had written the UI as well, I'd definitely have waited longer, likely for yours to be merged first, before offering a counter suggestion for the UI. There are a couple of PRs that I've been waiting for exactly that for. However, I think it's a different case when the PR is joint work between multiple people.

That's before I ended up making the functionality and implemented it..

Nearly everything I've done here is in writing the Rust for the TUI, and I had and still have no reason to suspect you were asking me to write implementations for each script. I've proposed an implementation for the UI, while using the scripts you want to be merged into the project regardless of who's UI is chosen. Correct?
If you were the one who had written the UI as well, I'd definitely have waited longer, likely for yours to be merged first, before offering a counter suggestion for the UI. There are a couple of PRs that I've been waiting for exactly that for. However, I think it's a different case when the PR is joint work between multiple people.

AGAIN, this UI implementation is not good, it produces bad UX and adds extra steps to the revert process. Please read what we are telling you man.

If you were the one who had written the UI as well, I'd definitely have waited longer, likely for yours to be merged first, before offering a counter suggestion for the UI. There are a couple of PRs that I've been waiting for exactly that for. However, I think it's a different case when the PR is joint work between multiple people.

And yet I have said many times I do not approve of you taking my revert functions that I sat down and wrote..

The added functionality in this PR is not needed and just creates bad UX with extra steps extra functionality and practically bloats the code up.

It does add complexity, and I've been transparent about that. I just think the improved features justify that. You disagree over whether my implementation is better than yours, but that's something to be discussed. No one person gets ultimate control over that discussion (well, actually, Chris does), but I'd be happy to talk about that more, productively, with you.

what people are telling you (Me, Adam, MullaC)

I think MullaC misinterpreted what I was saying, but I could be wrong about that. Regardless, I disagree. I also could be mistaken, but I don't think any of you have actually pulled my code down and tested it, and commenting before doing so is just silly.

I think MullaC misinterpreted what I was saying

If literally everyone is misunderstanding you, maybe you should say it differently.

The added functionality in this PR is not needed and just creates bad UX with extra steps extra functionality and practically bloats the code up.

It does add complexity, and I've been transparent about that. I just think the improved features justify that. You disagree over whether my implementation is better than yours, but that's something to be discussed. No one person gets ultimate control over that discussion (well, actually, Chris does), but I'd be happy to talk about that more, productively, with you.

what people are telling you (Me, Adam, MullaC)

I think MullaC misinterpreted what I was saying, but I could be wrong about that. Regardless, I disagree. I also could be mistaken, but I don't think any of you have actually pulled my code down and tested it, and commenting before doing so is just silly.

It's not improving UI if it's worsening UX and adds unnecessary extra steps to the revert process, please read the comments I'm sending; its clear to me that you're only partially reading them and not taking into account the statements i'm providing against your functionality.

 Who are you talking to?

Theft is quite an accusation. I gave you several examples of things I could have done that would've been slightly questionable, though of course still legal and therefore not theft. But I haven't done anything of the like, I've offered my code alongside the preexisting compatible code that @nnyyxxxx wants to be merged.
I'm not interested in discussing the nonsense accusation of theft going forward, let's keep this conversation civil.

 Who are you talking to?

Theft is quite an accusation. I gave you several examples of things I could have done that would've been slightly questionable, though of course still legal and therefore not theft. But I haven't done anything of the like, I've offered my code alongside the preexisting compatible code that @nnyyxxxx wants to be merged.
I'm not interested in discussing the nonsense accusation of theft going forward, let's keep this conversation civil.

And once again I don't give you permission to use the revert functionality that I sat down and made, morality != law.

If literally everyone is misunderstanding you, maybe you should say it differently.

@nnyyxxxx misinterpreted or forgot a few details of my implementation before I submitted it, but that's very minor, and nobody needs to be concerned with that, or with who's responsibility that is. MullaC very clearly misunderstood, as he thought I proposed adding telemetry, which of course isn't the case, and his thought that I had added bloat likely came without the realization that it was done for a very clear and major feature addition.

Theft is quite an accusation.
I'm not interested in discussing the nonsense accusation of theft going forward, let's keep this conversation civil.

Are you just going to ignore the one sentence I'm repeating over and over again?
"We have a moral issue with you knowing we are against you using our (nyx's) code and still doing so."

Me and Adams PR is more than enough for the revert functionality, this PR just adds extra steps to reverting and adds bad UX...

And once again I don't give you permission to use the revert functionality that I sat down and made, morality != law.

Would this complaint drop if I removed everything you've written from this PR and instead proposed only removing @adamperkowski's code and adding my own UI implementation as a replacement? Once again, I've been offering this for hours. You haven't replied. You can't have things both ways. Keep rejecting that and I have zero reason to believe you have any care whatsoever over whether your code is contained within this PR.

MullaC very clearly misunderstood, as he thought I proposed adding telemetry, which of course isn't the case, and his thought that I had added bloat likely came without the realization that it was done for a very clear and major feature addition.

Was this feature tested? As you did not mention this testing in the descritption. We also do not have this feature in WinUtil to remember screen size this could be as it is classed as WinUtil collecting data. What chris does not want. Chris wants NO data being collected locally or externally.

And once again I don't give you permission to use the revert functionality that I sat down and made, morality != law.

Would this complaint drop if I removed everything you've written from this PR and instead proposed only removing @adamperkowski's code and adding my own UI implementation as a replacement? Once again, I've been offering this for hours. You haven't replied. You can't have things both ways. Keep rejecting that and I have zero reason to believe you have any care whatsoever over whether your code is contained within this PR.

Have you been listening to what we've been saying? The extra UI code is unneeded, adds extra steps to reverting, makes UX terrible for reverting, and is just bloat in general. We have been arguing with you about this since 3 AM EST I think you should just close this. Me and Adams PR includes complete functionality for the reverting and this PR is unnecessary.

 I will not discuss anything with a person like that. I'm sorry, it's not something I'm willing to put up with. Settle that discussion and we can continue.

 I will not discuss anything with a person like that. I'm sorry, it's not something I'm willing to put up with. Settle that discussion and we can continue.

You didn't contradict anything please re-read what I said, thanks. :-1:

Was this feature tested? As you did not mention this testing in the descritption.

Yes, it was. "Commands are correctly updated in the TOML & UI on next entry"

We also do not have this feature in WinUtil to remember screen size this could be as it is classed as WinUtil collecting data.

I'm not particularly familiar with what's going on in winutil. Can you provide citation for anything keeping data locally being rejected because of security or privacy concerns? I'd very much reconsider if you could, since the project maintainer's wishes obviously must be respected.

absolutely ridiculous accusation of theft

This is the last time I'm going to say this, @lj3954.

What we are saying is we have a MORAL issue with you taking nyx's code KNOWING nyx is against that.
morality != law

You didn't contradict anything please re-read what I said, thanks. 👎

You restated for the 50th time that you don't like my UI. I know. I just disagree with you, and if you wouldn't like to debate specifics, I'd rather this discussion be with someone else.
The main issue that I have is that you keep accusing me of theft, and then when I give you an offer that goes far beyond reason in respecting your wishes when it comes to where your code is, you completely ignore it. I have offered this in probably nearly 10 comments at this point, and you 2 totally ignored it every single time. Given that, I have zero reason to believe you have any interest in a productive conversation.
Again, I'd like to request an answer. Will your complaint about me 'stealing' your code (which I still disagree with, but we can put aside our differences on that), be rescinded if I remove all traces of your code from this PR, and rather make it depend on #384 being merged first, removing only @adamperkowski's code and replacing it with my own implementation?

Was this feature tested? As you did not mention this testing in the descritption.

Yes, it was. "Commands are correctly updated in the TOML & UI on next entry"

We also do not have this feature in WinUtil to remember screen size this could be as it is classed as WinUtil collecting data.

I'm not particularly familiar with what's going on in winutil. Can you provide citation for anything keeping data locally being rejected because of security or privacy concerns? I'd very much reconsider if you could, since the project maintainer's wishes obviously must be respected.

If you want to carry on this argument please go into the community discord server please. So things can be modded.

If you want to carry on this argument please go into the community discord server please. So things can be modded.

I don't have an account with that platform; we can move this to the discussions tab if you'd like. I don't see the purpose, though. Discussions on implementation details can be had within the PR. The discussion over the idea that I've "stolen" someone's code should end immediately, @nnyyxxxx has a very clear offer presented in front of him that would go far above and beyond and he must respond if he's concerned about my PR containing any of his code.

You didn't contradict anything please re-read what I said, thanks. 👎

You restated for the 50th time that you don't like my UI. I know. I just disagree with you, and if you wouldn't like to debate specifics, I'd rather this discussion be with someone else.
The main issue that I have is that you keep accusing me of theft, and then when I give you an offer that goes far beyond reason in respecting your wishes when it comes to where your code is, you completely ignore it. I have offered this in probably nearly 10 comments at this point, and you 2 totally ignored it every single time. Given that, I have zero reason to believe you have any interest in a productive conversation.
Again, I'd like to request an answer. Will your complaint about me 'stealing' your code (which I still disagree with, but we can put aside our differences on that), be rescinded if I remove all traces of your code from this PR, and rather make it depend on #384 being merged first, removing only @adamperkowski's code and replacing it with my own implementation?

Again your UI implementation is not needed, here is a quick summary why:
The extra UI code is unneeded, adds extra steps to reverting, makes UX terrible for reverting, and is just bloat in general.

If you want to carry on this argument please go into the community discord server please. So things can be modded.

I don't have an account with that platform, I do not like what I've heard about the hostility to privacy and security the owners of that platform have; we can move this to the discussions tab if you'd like. I don't see the purpose, though. Discussions on implementation details can be had within the PR. The discussion over the idea that I've "stolen" someone's code should end immediately, @nnyyxxxx has a very clear offer presented in front of him that would go far above and beyond and he must respond if he's concerned about my PR containing any of his code.

Once again please read: https://github.com/ChrisTitusTech/linutil/pull/401#issuecomment-2351821247

If you want to carry on this argument please go into the community discord server please. So things can be modded.

I don't have an account with that platform, I do not like what I've heard about the hostility to privacy and security the owners of that platform have; we can move this to the discussions tab if you'd like. I don't see the purpose, though. Discussions on implementation details can be had within the PR. The discussion over the idea that I've "stolen" someone's code should end immediately, @nnyyxxxx has a very clear offer presented in front of him that would go far above and beyond and he must respond if he's concerned about my PR containing any of his code.

Please make an account as we can mod what is said and if things go to far it can be stopped easily. By our mods and very harsh bots.

Respond to my proposition immediately. We're not going in a loop, this is a massive waste of time. If you don't want your code to touch my PR, I'm fully willing to do just that and you know it.

Respond to my proposition immediately. We're not going in a loop, this is a massive waste of time. If you don't want your code to touch my PR, I'm fully willing to do just that and you know it.

And once again your UI changes and other changes in the code are unnecessary and are bad UX, / extra steps for the user...

Nope. We're not having this. I'll talk about UI with you after you make your decision as stated above. I don't want to discuss about "theft" any longer.

Nope. We're not having this. I'll talk about UI with you after you make your decision as stated above. I don't want to discuss about "theft" any longer.

Once again read: https://github.com/ChrisTitusTech/linutil/pull/401#issuecomment-2351821247

Nope. We're not having this. I'll talk about UI with you after you make your decision as stated above. I don't want to discuss about "theft" any longer.

And please read: https://github.com/ChrisTitusTech/linutil/pull/401#issuecomment-2351823308

You're not here in good faith. You keep accusing me of theft, but you have intentionally avoided responding to my offer to remove all traces of your code from my PR and make it depend directly upon yours, for hours. My discussion with you is over if this isn't resolved immediately.
Once again, I'll restate myself if it's not clear enough. If your wish is for your scripts not to touch my PR, I'll make my PR depend upon yours first being merged & remove all scripts you wrote from this PR. Does that solve the problem? We can discuss UI once this is resolved. If you don't accept that suggestion, then kindly shut up about your code being included here, since that would completely remove it.

You're not here in good faith. You keep accusing me of theft, but you have intentionally avoided responding to my offer to remove all traces of your code from my PR and make it depend directly upon yours, for hours. My discussion with you is over if this isn't resolved immediately.
Once again, I'll restate myself if it's not clear enough. If your wish is for your scripts not to touch my PR, I'll make my PR depend upon yours first being merged & remove all scripts you wrote from this PR. Does that solve the problem? We can discuss UI once this is resolved. If you don't accept that proposition, then kindly shut up about your code being included here, since that would completely remove it.

Every change you're making in this PR is unnecessary (how many times do i have to say this dude, my prior comments summarize why pretty well maybe start reading them?", nobody is accusing you of theft as stated by Adam many times.

nobody is accusing you of theft as stated by Adam many times.

Okay, so you're accusing me of doing something immoral. Whatever immoral thing I'm allegedly doing, would my offer, as stated above, cause you to discontinue these accusations? I would like a response in 10 minutes time, I'm willing to immediately work on said changes to address your concerns. Then, we can debate over the UI. Alright? Otherwise, you must not be interested in anything other than throwing horrible and baseless accusations upon me, and this discussion will cease.

This commit was worked on earlier, don't mind it. Not that I should apologize to you for making a commit with my own code regardless.

@lj3954 I'm not interested with arguing with you any longer, as MullaC stated: "Data collection via local or cloud is not allowed & Chris does not like that", And my personal statements aswell: Nyx: "The extra UI code is unneeded, adds extra steps to reverting, makes UX terrible for reverting, and is just bloat in general."
Here's where I take my leave, I hope this PR does not get accepted as It's just a duplicated and made bloated implementation of my original PR.

So you really don't care about your code being present here, and you just wanted to use that accusation to shut down discussion.  I hope you can reconsider using such a strategy in a discussion. @adamperkowski, do you stand by this?
Now that we have this nonsense over with, I'd like to discuss over the merits of the 2 UIs against each other. Would anyone who's interested in discussing with good faith be willing to participate?

So you really don't care about your code being present here, and you just wanted to use that accusation to shut down discussion.  I hope you can reconsider using such a strategy in a discussion. @adamperkowski, do you stand by this?

Don't @ me just to provoke me and nyx. Read my comments first (especially this one: https://github.com/ChrisTitusTech/linutil/pull/401#issuecomment-2351821247), then we can have a normal, civilized discussion over on Discord. This is my last comment on this PR.

So you really don't care about your code being present here, and you just wanted to use that accusation to shut down discussion.  I hope you can reconsider using such a strategy in a discussion. @adamperkowski, do you stand by this?

Don't @ me just to provoke me and nyx. Read my comments first (especially this one: #401 (comment)), then we can have a normal, civilized discussion over on Discord. This is my last comment on this PR.

I offered to address these concerns, despite the fact that I disagree over whether they're reasonable. The person in question, though, rejected my offer, so obviously he's not acting in good faith. I'm not trying to provoke you, I'd just hope you're not interested in standing by such a disgraceful attempt at shutting down discussion. Discussion over the merits of the UI approaches should proceed, without accusations that one isn't willing to stand by.

Let's keep it civil there is no need for finger pointing or name calling. We are all simply trying to make the best program possible. Constructive criticism of their code is good (Example. This PR has performance issues, I'd recommend X or Y).
Attacking a person with name calling is not. (Example. You are fat).
I also like to credit anyone that contributes code. So if anyone does use someone else code just @ the person or reference the PR the code was taken from letting them know that you incorporated the code or the idea from that PR in the project.
Thanks for understanding lets keep this a fun project to work on.

I also like to credit anyone that contributes code. So if anyone does use someone else code just @ the person or reference the PR the code was taken from letting them know that you incorporated the code or the idea from that PR in the project.

I've done exactly this, and offered to go way above and beyond when someone suggested that any of their code being within my PR would go against their wishes. I hope for more people to enter this discussion now that these comments have been resolved, in order to discuss in a civilized manner whether my solution or the solution presented in #384 is preferable.

@lj3954 Yeah sorry about that argument, we kind of overreacted. I have decided to agree and cooperate with the UI change; can you remove the Revert functionality // my commits from the existing scripts, and I'll do the rest for the rust functionality // echo statements for no revert on #384 .


Edge details: display new network informations (if) available on nuvlabox-status

[ ] All detected IPs (local, public, vpn, swarm).
[ ] IPs of all (or only physical one [TBDiscussed]) network interfaces

https://github.com/nuvla/api-server/pull/722/files#


Fix notifications out of cluster

This PR aims to fix a long running issue: the notifications only report for clusters currently being checked + they don't work outside of a cluster (e. g. in the home view).
There are a few issues I am fixing still (introduced by this PR):

[x] Notifications don't get the cluster tag
[x] Notifications seem to be duplicated

The code LGTM, but I am not sure how to test this cc: @joaquimrocha

Clear the notifications in the local storage. Then see if the new notifications look good (they work, have the cluster set up in them, they are not repeated, etc.).


$cordovaOauth.linkedin returning  null data and status -1

Hi, I have been using ngCordovaOauth with LinkedIn provider in an Ionic 1.3.1 project. However, I keep getting "Problem authenticating" message from the library.
I cloned the repository, tried adding some debug messages and this is what is going on:

auth code is retrieve successfully (the GET request to  https://www.linkedin.com/uas/oauth2/authorization )
the following POST request fails with the data object containing:    {"data":null,"status":-1,"config":{"method":"POST","transformRequest":[null],"transformResponse":[null],

Observations:

the same behavior is experienced on both Android and iOS emulators, so it does not seem to be a matter of App Transport Security;
I was able to test the OAuth flow on Linkedin correctly using Postman (so the client ID and secret are correct);
I replaced the $http with another http library we are using (wlresourcerequest as we built our app using MobileFirst Platform , but that's another story) and it works, which clearly indicates that the POST request is the one that has problems.

Are you able to reproduce, and perhaps suggest what could be wrong?
Thanks

Hey @gmaggini,
Thanks for the level of detail you've given me!
A few questions:

Has this library ever worked for you when it comes to LinkedIn?
If the answer to the previous was yes, can you try to use 0.2.9 of the library rather than the latest which is 0.2.10? Wondering if I broke something.

Best,

Hi @nraboy , this is my first time using this library so I went straight to the latest version.
I will however test the library using a new empty app and see if it works and update this issue.
While we are at it: LinkedIn's documentation for OAuth (here) suggests to use https://www.linkedin.com/oauth/v2/authorization and https://www.linkedin.com/oauth/v2/accessToken as endpoints, while the ones currently in the library seem to be the endpoints for the legacy Oauth . However, even replacing them did not solve the problem for me, which seems to lies into the $http post request ...

Hey @gmaggini,
I just tried LinkedIn with the example app that I put on GitHub:
https://github.com/nraboy/ng-cordova-oauth-example
I replaced the library in that sample project with the latest ng-cordova-oauth release and LinkedIn worked fine.  This leads me to believe that maybe you didn't configure your application correctly in the LinkedIn dashboard.
However, if LinkedIn is recommending a new set of URLs, this could be a problem in the long term.  Although they haven't deprecated the current, now we know it is coming.  Would you like to contribute to this project and make the changes?  It would get you some bonus points being an open source contributor.
Let me know, otherwise I'll see about updating the URLs in the next week or so.
Best,
cc @matheusrocha89

I will work again on this by end of this week and update this issue. Also contribute to this project.
In the meanwhile, additional finding: the status -1 returned from $http in my Ionic prokect is a problem I have everywhere in the app.

Hi. The issue was related to the config.xml file not having the right allow-intent set.
Thank you for your help

@gmaggini can you please let me know which allow-intent need to set??


希望能添加dialog和loadingMask

希望有dialog，loadingMask，calendar，lightbox

We are unable to provide assistance in languages other than English and German.


DOI only converted to URL for first reference when also using package hyperref

I'm using APA style, with citation-style-language {2022-09-23} {v0.2.2} in TexLive 2022, and compiling with LuaLatex.  DOIs should be converted to URLs in the reference list by prepending https://doi.org/ to the DOI.  However, when package hyperref is also used, only the first reference in the list has https://doi.org/ prepended to the DOI.  Here's a MRE:
\documentclass{article}

\begin{filecontents}[overwrite, noheader]{mwe-csl.bib}
@article{edge-garza.etal-2014-Mol.Breed.,
  title = {A high-throughput and cost-efficient {{DNA}} extraction protocol for the tree fruit crops of apple, sweet cherry, and peach relying on silica beads during tissue sampling},
  author = {Edge-Garza, Daniel A. and Rowland, Terrence V. and Haendiges, Stacey and Peace, Cameron},
  date = {2014-12-01},
  journaltitle = {Molecular Breeding},
  volume = {34},
  number = {4},
  pages = {2225--2228},
  issn = {1380-3743, 1572-9788},
  doi = {10.1007/s11032-014-0160-x},
}

@article{paris.etal-2017-MethodsEcolEvola,
  title = {Lost in parameter space: {{A}} road map for {{Stacks}}},
  shorttitle = {Lost in parameter space},
  author = {Paris, Josephine R and Stevens, Jamie R and Catchen, Julian M},
  date = {2017-03-01},
  journaltitle = {Methods in Ecology and Evolution},
  shortjournal = {Methods Ecol Evol},
  volume = {8},
  pages = {1360--1373},
  issn = {2041-210X},
  doi = {10.1111/2041-210X.12775},
}

@article{peterson.etal-2012-PLoSONE,
  title = {Double digest {{RADseq}}: an inexpensive method for de novo {{SNP}} discovery and genotyping in model and non-model species},
  shorttitle = {Double {{Digest RADseq}}},
  author = {Peterson, Brant K. and Weber, Jesse N. and Kay, Emily H. and Fisher, Heidi S. and Hoekstra, Hopi E.},
  date = {2012-05-31},
  journaltitle = {PLoS ONE},
  volume = {7},
  number = {5},
  pages = {e37135},
  issn = {1932-6203},
  doi = {10.1371/journal.pone.0037135},
}
\end{filecontents}

\usepackage{citation-style-language}
\cslsetup{style = apa}
\addbibresource{mwe-csl.bib}

\usepackage{hyperref}

\begin{document}

        First citation \cite{edge-garza.etal-2014-Mol.Breed.}.

        Second citation \cite{peterson.etal-2012-PLoSONE}.

        Third citation \cite{paris.etal-2017-MethodsEcolEvola}.

        \printbibliography

\end{document}

Thanks for your feedback and I can reproduce this bug.

It should be fixed in 83caeb9.

Thanks!  That fixed the issue and your work makes mine much easier.


EncodeList not working correctly

Context
I'm trying to test that if a encode a list of values, I get the expected decoded value.
Problem
This is what I'm trying to achieve:
List<byte[]> byteArrayList = new List<byte[]>();

           byte[] byte1 = HexByteConvertorExtensions.HexToByteArray("0x");
           byte[] byte2 = HexByteConvertorExtensions.HexToByteArray("0x");
           byte[] byte3 = HexByteConvertorExtensions.HexToByteArray("0x");

           byteArrayList.Add(byte1);
           byteArrayList.Add(byte2);
           byteArrayList.Add(byte3);

           byte[] expectedEncoded2 = HexByteConvertorExtensions.HexToByteArray("0xc3808080");

           byte[] encoded = RLP.EncodeList(byteArrayList.ToArray());

           // Assert
           Assert.AreEqual(expectedEncoded2, encoded);

I send a list to encode and then I expect that the result is the expected one. For assertions I'm using the test data that ethersjs uses for their RLP tests (https://github.com/ethers-io/ethers.js/blob/main/src.ts/_tests/test-rlp.ts), for example:

Additional context
I have this problem only with EncodeList method, because the method EncodeElement is working as expected.

@FSM1 @KBryan unless ethersjs test data is wrong, but I'm not sure how to manually encode a list to know the expected result

I'm pretty sure that the ethers tests are correct.
This is likely a problem in the implementation.

Not sure if this helps, but if I encode a list using EncodeList method and then I decoded using RLP.Decode, the decoded.RLPData equals the encoded:
           byte[] encoded = RLP.EncodeList(byteArrayList.ToArray());
            IRLPElement decoded = RLP.Decode(encoded);

            // Assert
           Assert.AreEqual(decoded.RLPData, encoded);

I think it makes sense, because is our code, but yeah looks like there is an issue on the EncodeList method


Add ORB_PICKUP 1.8 Sound

Hope i did this right.

Hey, thank you for your Pull Request! I will merge it into the main branch as soon as the rest of release 0.3.3 is ready to release, which is expected in a few days.


RuntimeError When Loading State_Dict for WorldModel

I am trying to run the model that was downloaded from the website using the following command:
python evaluate.py task=mt30 model_size=48 checkpoint="/home/pcy/Research/code/tdmpc2/models/mt30-48M.pt"

Unfortunately, an error appears during execution as follows:
Creating multi-task environment with tasks: [...] (list of tasks omitted for clarity)
Error executing job with overrides: ['task=mt30', 'model_size=1', 'checkpoint=/home/pcy/Research/code/tdmpc2/models/mt30-1M.pt']
Traceback (most recent call last):
  File "/home/pcy/Research/code/tdmpc2/tdmpc2/evaluate.py", line 59, in evaluate
    agent.load(cfg.checkpoint)
  File "/home/pcy/Research/code/tdmpc2/tdmpc2/tdmpc2.py", line 68, in load
    self.model.load_state_dict(state_dict["model"])
  File "/home/pcy/mambaforge/envs/tdmpc/lib/python3.9/site-packages/torch/nn/modules/module.py", line 2152, in load_state_dict
    raise RuntimeError('Error(s) in loading state_dict for {}:\n\t{}'.format(
RuntimeError: Error(s) in loading state_dict for WorldModel:
        Missing key(s) in state_dict: "_target_Qs.params.0", "_target_Qs.params.1", "_target_Qs.params.2", "_target_Qs.params.3", "_target_Qs.params.4", "_target_Qs.params.5", "_target_Qs.params.6", "_target_Qs.params.7", "_target_Qs.params.8", "_target_Qs.params.9".

Set the environment variable HYDRA_FULL_ERROR=1 for a complete stack trace.

I am wondering if anyone else has come across the same issue. I am suspecting potential compatibility issues between the released model and the latest version of the code. Any information will be highly appreciated!

Hi @jc-bao, the models hosted on google drive are for an anonymized version of our codebase. Our public release hosts models on huggingface and are listed here: https://nicklashansen.github.io/td-mpc2/models
Weights are identical but internal modules have been restructured which is the reason for your error. Sorry for the confusion!

Got it. I believe that will resolve the issue. Thanks for the prompt reply!

Great -- let me know if there's anything else!


NSPredicate keypath collection query fails on evaluateWithObject:

This was originally reported in an issue with RBQFetchedResultsController: https://github.com/Roobiq/RBQFetchedResultsController/issues/50
Here is the sample project (I made a few updates to the one the user originally provided):
RBQFetchedResultsControllerExample.zip
If you run the project, you will notice that the predicate (@"inTable = YES AND objects.@count > 0") for the RBQFetchRequest works correctly and only objects in the first section appear because those are the only objects with any linked objects in their RLMArray objects property.
However, if you click the delete button in the nav bar and then click insert, a new object will be created with a linked object and then it is added to Realm with a notification to trigger the FRC. The FRC will then evaluate the objects that are passed through the notification to verify they match the predicate for the fetch request.
In this case the predicate evaluation fails: [self.predicate evaluateWithObject:object]. From what I can tell it seems that internally, this triggers calling valueForKey: on the object, with the key being: @count.
Is this an incorrect parse of the predicate or do we need to enable support for this sort of valueForKey: request?

Our array types do not yet implement the KVC collection operators. They should.

Is this really a bug? I'd tend to say it's a missing feature / API inconsistency.


Create goals fieldset modifier

Alphabetised Fieldset modifiers
Creates a goals css modifier for Fieldset
Adds corresponding type  to angular rb-fieldset
Updated demos to show new modifier
Added test

TP https://rockabox.tpondemand.com/entity/9389

:+1: for CSS, besides comment consistency.


fix Exception stack information acquisition optimization #6984

fix Exception stack information acquisition optimization #6984

Codecov Report

Merging #6985 (9c44077) into master (3fc2d10) will decrease coverage by 0.59%.
The diff coverage is 83.33%.

@@             Coverage Diff              @@
##             master    #6985      +/-   ##
============================================
- Coverage     59.44%   58.84%   -0.60%
+ Complexity      511      504       -7
============================================
  Files          1028     1028
  Lines         41519    41475      -44
  Branches       6037     6006      -31
============================================
- Hits          24681    24408     -273
- Misses        14102    14307     +205
- Partials       2736     2760      +24

Impacted Files
Coverage Δ
Complexity Δ

...ache/dubbo/rpc/proxy/InvokerInvocationHandler.java
80.55% <80.00%> (-0.09%)
0.00 <0.00> (ø)

...rc/main/java/org/apache/dubbo/rpc/AppResponse.java
51.38% <100.00%> (-3.16%)
0.00 <0.00> (ø)

...a/org/apache/dubbo/rpc/filter/AccessLogFilter.java
36.00% <0.00%> (-45.34%)
0.00% <0.00%> (ø%)

...va/org/apache/dubbo/rpc/support/AccessLogData.java
47.88% <0.00%> (-42.26%)
0.00% <0.00%> (ø%)

...ng/transport/dispatcher/all/AllChannelHandler.java
62.06% <0.00%> (-34.49%)
0.00% <0.00%> (ø%)

...rg/apache/dubbo/remoting/utils/PayloadDropper.java
15.38% <0.00%> (-30.77%)
0.00% <0.00%> (ø%)

...bbo/common/bytecode/CustomizedLoaderClassPath.java
28.00% <0.00%> (-16.00%)
0.00% <0.00%> (ø%)

...ng/transport/dispatcher/WrappedChannelHandler.java
47.82% <0.00%> (-15.22%)
0.00% <0.00%> (ø%)

...org/apache/dubbo/registry/dubbo/DubboRegistry.java
43.13% <0.00%> (-13.73%)
9.00% <0.00%> (-1.00%)

...mmon/threadpool/support/AbortPolicyWithReport.java
85.00% <0.00%> (-12.50%)
0.00% <0.00%> (ø%)

... and 64 more

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 3fc2d10...9c44077. Read the comment docs.


added two more example games

Added two more example games:
1 - The first game is fill in the blanks where a random word is picked and some letters are removed, the player is then asked to write the full word.
2- the second game is word jumble which scrambles a word and asks the player to organize it.

LGTM! Thank you for your awesome work! The Pull Request is ready to merge.


New Transport: NKN ?

It might be interesting to add the NKN network as a new transport type.
The P2P messaging in NKN is working just fine behind NAT, there is a nkn-sdk-go package: https://github.com/nknorg/nkn-sdk-go
I was experimenting with NKN messaging in Go and JavaScript (browser and node) and it's fast, secure, reliable (using MultiClient) and free. The messaging is totally free , just pub-sub need a small amount of payment only on the pub side.
Simple example:
account, err := nkn.NewAccount()
if err != nil {
    log.Println("Error creating account NKN ", err)
}
fmt.Println("Seed = ",hex.EncodeToString(account.Seed()))
fmt.Println("PubKey = ", hex.EncodeToString(account.PubKey()))

numSubClients := 3
originalClient := false
config := nkn.GetDefaultClientConfig()

var err_nmc error

multiclient, err_nmc = nkn.NewMultiClient(account, "my_identity", numSubClients, originalClient,config)
if err_nmc != nil {
    log.Println("ERROR creating client NKN",err_nmc)
}

time.Sleep(time.Second)
<- multiclient.OnConnect.C
log.Println("Ready to send/receive messages")

response, err_send := multiclient.Send(nkn.NewStringArray("receiver_address"), "Ready to Babble?", nil)
if err_send != nil {
    log.Println("ERROR cannot send message ",err_send)
}

go func() {
    msg := <- response.C
    fmt.Println("Receive message from", msg.Src + ":", string(msg.Data))
}()

I think that this new transport can solve the NAT traversal and supply a better connectivity!
Best regards,
Constantin Teodorescu

Thanks that is very interesting. First time I here of NKN.
I ll have a look at it.

Any NKN node can run behind a router/firewall, no need for public IP or port forwarding.
Every NKN client has a Private/Public Key,  (both can be restored from a previous saved seed) all I need in order to send/receive messages from othe NKN client is the Public Key.
Communication is encrypted and you can design distributed apps that are swarming private messages without any need of a VPN. I'm keeping with NKN a local database in sync with a remote "backup database" on a laptop that don't need a fixed IP address, today it's in a local network, tomorrow it can be in another place, no problem, when I start the "receiving updates" app, it just need a connection to internet because I have the same NKN address (restored from the seed saved in an encrypted database).
Babble could benefit from this kind of transport making possible to design a distributed app that manages to keep a consensus between far, distributed nodes.
Best regards,
Teo

Hi @brailateo ,
FYI I have this PR to add the NKN network.
The integration was very easy but the connections seem very slow and unreliable.
You mentionned that you obtained fast and reliable results in your experiments.. I think I might be doing something wrong.. perhaps a bad configuration.

Yes, my tests were just fine, with <10ms round-trip packages between nodes, tested also with go, nodejs and JavaScript browser clients. On some rare occasions some nodes had connection problems  because of some faulty DNS servers. If the problem persists, I think that you might get some support from NKN team on Discord, Yilun is a developer, a kind fellow ( skysniper ).


A few recommended commits to fix some more warnings

Hey @amosavian here's a few bits and pieces, hope you'll accept them.
Regarding the AEXML classes, I recommend these classes stay public, there's no need to make them internal, and it only makes life harder for people like me trying to help you work on this library, for no added benefit.
(I'm using this stuff in code that "observes" filepaths for changes, but its not ready yet to be added to this library).
The RemoteSession.swift change was to make it build for me in my project, it was failing complaining about URLSessionStreamTask because its only available in iOS 9.
The FPSStreamTask.swift change is just so it stops giving a warning about an unused output.
The only change I was unsure about was the FTPHelper.swift change. It was giving a warning about unused output here too, but it kinda looks like you wanted to feed that output into the next function call.

Thank you skela, but I noticed and fixed it already https://github.com/amosavian/FileProvider/commit/6959a14dc12ba340d766cfa6983f3a3e8865778b.
write(timeout:) result method should not be marked as @dicardedResult. I suppressed the warning in method that doesn't need it but this alarm warned me about a potential bug in another methods.
About AEXML, I can't get why it's needed. But if so, we should make a wrapper inside FileProvider classes to preserve encapsulation. This library is not part of FIleProvider and can be dropped in future releases! That's why I made them internal.
For observers of filepaths for changes that you've implemented, You can fork this repo, create a new branch and commit these observers to that branch so I can see it and give my recommendations before pull request & merging.

The AEXML stuff is needed because my observer stuff is nowhere near complete, but I'm perfectly happy sticking that code into fileprovider somewhere, I'll do that now.

Ok I'm gonna bail on this pull request @amosavian , will make a new one once ive got the XML stuff inside a FileProvider method instead. :) Thx

Thanks, I'm eagerly waiting.

Hey @amosavian will you be ok with something like this?
Can't see a better place to stick it except DavResponse, which seems to be an internal / private thing anyway.
public extension WebDAVFileProvider
{
    public static func parseETag(data xmldata:Data) -> String?
    {
        do
        {
            let xml = try AEXMLDocument(xml:xmldata)
            var rootnode = xml.root
            var responsetag = "response"
            for node in rootnode.all ?? [] where node.name.lowercased().hasSuffix("multistatus")
            {
                rootnode = node
            }
            for node in rootnode.children where node.name.lowercased().hasSuffix("response")
            {
                responsetag = node.name
                break
            }

            if let rnode = rootnode[responsetag].first
            {
                for node in rnode.children
                {
                    if node.name.lowercased().hasSuffix("propstat")
                    {
                        for psnode in node.children
                        {
                            if psnode.name.lowercased().hasSuffix("prop")
                            {
                                for pnode in psnode.children
                                {
                                    if pnode.name.lowercased().hasSuffix("getetag")
                                    {
                                        if let tag = pnode.value
                                        {
                                            return tag
                                        }
                                    }
                                }
                            }
                        }
                    }
                }
            }
        }
        catch _
        {

        }
        return nil
    }
}


Remove undefined attempts variable completely

Retries used to be managed using a number of attempts that gets incremented after each try.
4ce5aaa changed that to only using a timeout as pointed out in #31
In the process, the attempts variable incrementation was left and now causes a bug.
This PR fixes that.

Good catch. Thanks!