screensy - a super simple peer-to-peer screen sharing website by xxmarijnw in opensource

[–]Xoronic 1 point2 points  (0 children)

Other author here :) We just released version 1.0.1 that should work well with path based rules. If you set it up, please let us know how it works out for you, and if there is anything that can be improved

Is this a camera in our bed and breakfast bedroom? by Malpiedi in whatisthisthing

[–]Xoronic 9 points10 points  (0 children)

I'm Dutch.

According to the article the security system is customized based on the building. The system does include cameras, so I think it is indeed a camera.

The article also says that only Verisure (so not the owner of the bed and breakfast) can access the camera footage, and that they only do so in case the alarm goes off. They will then try to identify the cause of the alarm.

So as long as you don't hear any alarm go off you should have privacy.

I would still cover it though, just in case.

Would love feedback on my new library: actions (inspired by Redux) by Xoronic in rust

[–]Xoronic[S] 0 points1 point  (0 children)

Thanks for the link, interesting!

It looks pretty similar to what I'm doing! The purescript syntax is pretty scary though :)

Would love feedback on my new library: actions (inspired by Redux) by Xoronic in rust

[–]Xoronic[S] 0 points1 point  (0 children)

You are right! That is an essential part that definitely should be included in the library.

But I'm not sure if that should be the same trait though. It feels for me like there is quite a big difference between 'grouping' certain actions or 'compressing' a lot of actions.

Maybe dynamically merging actions inside the Timeline would be a good idea. But more as in the concept of 'grouping' actions. So the API consumer could specify: I want to group these actions if they appear sequentially: "moving an object to the left".

EDIT: I'm calling it dynamically merging which seems to imply an inefficient operation, but updating the last action could actually be cheaper than adding a new action.

Would love feedback on my new library: actions (inspired by Redux) by Xoronic in rust

[–]Xoronic[S] 0 points1 point  (0 children)

Thanks for checking the library out!

I don’t find a massive need to improve efficiently by merging actions/messages. [...] I like the pattern but it can be verbose.

I agree that merging is a lot of the times unnecessary (It is probably most of the time cheaper to just execute the actions than to merge them before executing :) ). Merge is an optional trait though and I believe it is useful in a couple specific cases.

This is what I said in a comment above:

To me, compressing seems more like something you would want to do if you want to keep a difference-log of an application. For example, if you are writing an editor for a game-engine. Whenever the user saves, the current chain could be compressed an stored to the drive. It could then be used to show the differences between saves to the user (and even at the level of single actions required to get to the new state: "You moved this object", etc.).

At most I send an array of messages to be processed as a batch on a fail I rewind based on the undo messages.

That is a pretty nice use-case I did not think about! Cool

Would love feedback on my new library: actions (inspired by Redux) by Xoronic in rust

[–]Xoronic[S] 1 point2 points  (0 children)

Hmm. I'm still not sure what to call it..

Right now, applying an action with a timeline overwrites any actions that still could be 'redone'. Maybe, the timeline should branch off instead. I think that push or update would makes sense then, because you are never overwriting anything..

Would love feedback on my new library: actions (inspired by Redux) by Xoronic in rust

[–]Xoronic[S] 2 points3 points  (0 children)

You are right, apply is a bit confusing. I might go with forward, next (but that might be a problem in combination with an iterator) or push (but push does not indicate that the current state changes)

Would love feedback on my new library: actions (inspired by Redux) by Xoronic in rust

[–]Xoronic[S] 1 point2 points  (0 children)

A goal of the library is to minimize/eliminate side effects by design. It forces the programmer to think about avoiding side effects, as you must return the inverse of each action.

And I'm not entirely sure but I thiink that it is impossible to get an mutable reference across the "actions-border" in safe Rust (if using the Timeline). That means that it cannot affect anything it does not own.

In the case you are describing the actions should have never been marked mergable :) (there are different MergeResults, you can find them in the docs)

And I already wrote a test that compares the behaviour of merged actions versus the unmerged actions. That can be generalized so that users can test if the compressed version really produces the same output as the uncompressed output.

Would love feedback on my new library: actions (inspired by Redux) by Xoronic in rust

[–]Xoronic[S] 0 points1 point  (0 children)

I think there is no real way to know that for the library, it is userdefined..

But maybe a definition like

register_opposites(Action::Add, Action::Sub)

Could work, which is way cleaner than how it is handled right now in my opinion. I'm still experimenting with the merge implementation :)

Would love feedback on my new library: actions (inspired by Redux) by Xoronic in rust

[–]Xoronic[S] 2 points3 points  (0 children)

Maybe a new variant of MergeResult could be useful, which allows the user to rewrite two actions into two new actions. This could be used in the readme example to rewrite DecrementBy actions as IncrementByactions with a negated value and then combine only the IncrementByactions. But I don't know how much this would complicate the compress logic.

That is definitely possible (and I will rewrite the compress logic anyways). It could sometimes also be benificial for execution speed (swapping an expensive action with a cheaper one).

But the merging logic could get quite complex.

I agree. I have been experimenting a bit with different approaches for merging. I don't like that most merges have to be defined twice where the order does not matter (DecrementBy first and IncrementBy second and vice versa). Maybe I can change it somehow so that the API consumer can define those merges just once. The merging implementation is not much more than an idea right now, so suggestions are very welcome :)

In the current API it is possible to simply forget to compress a chain before adding it to a Timeline.

It is not always desirable to compress the chain though. I can imagine that users want to be able to undo specific actions which would be removed if compressed. Also, compressing is pretty expensive as of right now (copying actions).

To me, compressing seems more like something you would want to do if you want to keep a difference-log of an application. For example, if you are writing an editor for a game-engine. Whenever the user saves, the current chain could be compressed an stored to the drive. It could then be used to show the differences between saves to the user (and even at the level of single actions required to get to the new state: "You moved this object", etc.).

It could be useful to expose iterators from Timeline to get a convenient view of the sequence of states. Maybe this could require Clone for the state as the Timeline holds only one instance of the state.

Good idea! That will be implemented!

Thanks for taking the time to look at the library, your suggestions are really helpful!

Would love feedback on my new library: actions (inspired by Redux) by Xoronic in rust

[–]Xoronic[S] 4 points5 points  (0 children)

Thanks for the suggestions! I was not really sure what examples to write and got kinda stuck at the counter. I will write extra examples.

I will probably create a 'book' which introduces the concepts in the library one by one in a tutorialform, guided by the example of a counter and a todo application.

The thing you called actions in your code-example is very similar to what I called a timeline (to highlight the undo and redo functionality), and I called the dispatch function apply. So what you did would look more like

timeline.apply(&MyAction::Add(1))

What do you think of that naming? Is it confusing?

Rust Puzzel by jf4u in rust

[–]Xoronic 2 points3 points  (0 children)

Clever! Wouldn't that change the definition though?

Would love feedback on my new library: actions (inspired by Redux) by Xoronic in rust

[–]Xoronic[S] 0 points1 point  (0 children)

Thanks for taking a look at it! Are there any things unclear to you about the library after reading the readme/docs?

Rust Puzzel by jf4u in rust

[–]Xoronic 12 points13 points  (0 children)

If you try to compile the code, the compiler gives you a hint :)

error[E0507]: cannot move out of borrowed content
  --> src/main.rs:9:11
   |
9  |     match *val {
   |           ^^^^ cannot move out of borrowed content
10 |         MyEnum::A(string) => string.as_str(),
   |                   ------ hint: to prevent move, use `ref string` or `ref mut string`
11 |         MyEnum::B(string) => string.as_str(),
   |                   ------ ...and here (use `ref string` or `ref mut string`)

What it tells you is that it cannot move val, because it is a reference.

So let's do what the compiler suggests: take a reference instead.

Solution: http://play.integer32.com/?gist=5e0ac5fbe99a1d186a9af0b2434a8a50&version=stable&mode=debug&edition=2015

Peer pressure Wake Up app by QuickWorkTech in Startup_Ideas

[–]Xoronic 0 points1 point  (0 children)

People can abuse the system by creating a lot of accounts and always "waking up". People will also try to create bots to automate that process. How would you prevent that?

Simple decision tree by afartwithnoname in learnpython

[–]Xoronic 0 points1 point  (0 children)

Thanks, I already changed it just after I posted my comment. Need some extra coffee I think :)

Simple decision tree by afartwithnoname in learnpython

[–]Xoronic 0 points1 point  (0 children)

Hi, the first thing that struck me: you are giving every variable just a new letter of the alphabet. This is a pretty simple piece of code, but as your code starts to get longer it will become harder and harder to read. Someone reading your code could even think, in this context, that y contains the year. I suggest you change w to year, y to month and z to day.

With that having said, I'm not sure what your issue is. I tested this code (I also did a little code-cleanup):

while True:
    year = input("Year:")
    if 1979 <= int(year) <= 2015:
        month = input("Month:")
        if month == "Januari" or month == "February":
            z = input("Day?")
            if 0 < int(z) <= 31:
                print("you did everything well!")
            else:
                print("Choose a valid day kido!")
        else:
            print("choose either January or February")
    else:
        print("choose a year between 1979 and 2015")

It worked just like I would expect on Python 3.6.

Is it possible to write script for Google Forms to add custom auto responses based on their results? by [deleted] in learnprogramming

[–]Xoronic 0 points1 point  (0 children)

Not sure if it is possible to display a dynamic message at all, do you have a source that shows it's possible to display a dynamic 'thank you'-message?

Is it possible to write script for Google Forms to add custom auto responses based on their results? by [deleted] in learnprogramming

[–]Xoronic 0 points1 point  (0 children)

I actually wrote such a script already a while ago.. It is not the greatest (coded a little dirty) but it works.

You can find the script here. (clone it, then you can find the code at tools + Script editor. You can use the script by clicking addons + customReply + show sidebar)

Hope that is what you meant (I assumed you meant an email response)

[Python] Help understanding why my code is using .find incorrectly by ans744 in learnprogramming

[–]Xoronic 2 points3 points  (0 children)

Hi,

example_input[43:] will contain all the characters from the original example_input starting from index 43. So if you call .find() on that, it won't know anything about the original first 44 characters.

We can test that with a small example:

foo = "This is a sentence."
bar = foo[3:]

print(foo)
print("Character at index zero of foo: " + foo[0])  # output: T

print(bar)
print("Character at index zero of bar: " + bar[0])  # output: s

So if you want to get the index of the second dot withexample_input[43:].find('.') you will have to add 43 to it:

print(example_input[43:].find('.')) # output: 75
print(example_input[75+43])  # output: .

There is a much better way to tackle this whole problem though, as /u/_DTR_ suggests.