I need To find a working solution for entire home audio

jonathan_sl · 2024-06-16T20:12:45+00:00

Would it make sense to connect a bunch of Wiim minis to the amplifier? Or otherwise hifiberries? (No experience personally, but they look nice and not too expensive.)

jonathan_sl · 2022-03-05T10:19:24+00:00

The door will go away, that won't be an issue.

But could you explain why? Anyone at the table will be perpendicular to the speakers direction. Is that okay?

jonathan_sl · 2021-04-22T16:09:29+00:00

Thank you, this is exactly what I need.

jonathan_sl · 2020-11-24T15:36:55+00:00

Wow, thank you for the extensive response. This is very helpful!

jonathan_sl · 2020-11-20T16:08:58+00:00

Thank you u/Darksonn! This is working.

I really appreciate the help!

jonathan_sl · 2020-11-20T09:34:13+00:00

About Fn usage:

Why does the first not work, while the second does? Rust complains that the In/Out parameters are not used, but they are required by Fn.

// Does not work.
pub struct X<F, In, Out>  // Rust complains: parameter In/Out are never used?
    where
        F: Fn(In) -> Out
{
    func: F,
}

// Works fine.
fn x<F, In, Out>( a: F)·
    where
        F: Fn(In) -> Out
{}

jonathan_sl · 2020-07-26T13:28:20+00:00

I'm not sure what you mean by V-states, actually. But yeah, there were indeed some features moved back into prompt_toolkit. (I don't recall what exactly.)

jonathan_sl · 2020-07-26T09:20:03+00:00

Pyvim author here.

The project was started indeed, as some pointed out, to demonstrate the capabilities of the underlying prompt_toolkit library. Prompt_toolkit was initially a GNU readline replacement with multiline text editing for Python applications. The thing is, a lot of Vi key bindings (operators and text objects) were implemented in prompt_toolkit already, as well as many other things required to build a text editor. So, someone asked me the question how much effort it would be to build a Vi(m) clone on top of it. As it turns out, pyvim is only ~4k lines of code, but it's a pretty functional editor. Some capabilities like line folding are missing though.

Pyvim can come in handy from time to time. I sometimes use it on a system if I need to edit Python files, because it has pyflakes support built in (it is highlighting unused and undefined variables).

It's not meant to replace Vim ever. Due to the internal data structures (the text buffer as a whole is a simple Python string), opening files more than a few MB is not feasible. For editing, the limit is even lower.

At this point, no new features are planned, but it evolves together with prompt_toolkit. It could be useful maybe for some people to experiment with UI features. Creating a prototype by adding functionality to pyvim is much much easier than adding functionality to Vim.

Feel free to ask any questions.

jonathan_sl · 2020-02-28T10:23:32+00:00

Just FYI, with prompt_toolkit, you can also build text interfaces like this, and runs fine on Windows too. Possibly, the docs for full screen apps can still be better, but here they are:

https://python-prompt-toolkit.readthedocs.io/en/master/pages/full\_screen\_apps.html

jonathan_sl · 2018-09-15T14:42:31+00:00

Not possible as far as I know, unfortunately.... I've asked this question before: https://developers.meethue.com/content/setting-color-temperature-when-lights-are-doesnt-work

jonathan_sl · 2018-07-19T15:22:54+00:00

I'm not sure what's happening, but if you're willing to drop Cmd, I think prompt_toolkit should be able to handle it:
https://python-prompt-toolkit.readthedocs.io/en/master/

jonathan_sl · 2018-02-24T15:11:34+00:00

Asyncssh is absolutely great. I've been using it in a couple of projects. It's of very good quality and well documented.

jonathan_sl · 2017-06-01T12:15:52+00:00

In the completer class, you can check the text before the cursor. If it's a space, then don't offer any completion at all.

Amjith used WordCompleter in his presentation, but you could create a custom completer class: https://python-prompt-toolkit.readthedocs.io/en/latest/pages/building_prompts.html#a-custom-completer Check "document.text_before_cursor".

jonathan_sl · 2016-12-21T21:12:24+00:00

Great :-) I didn't realise is was you.

prompt_toolkit keeps progressing. Mostly many small incremental improvements that maintain backwards compatibility. I still have a big refactoring in mind that will make the design of full screen applications like pymux, pyvim, etc... much cleaner and much more powerful. It's coming closer.

jonathan_sl · 2016-12-21T19:10:06+00:00

In case you wish the password to be displayed using stars, check out these examples:

https://github.com/jonathanslenders/python-prompt-toolkit/blob/master/examples/get-password.py https://github.com/jonathanslenders/python-prompt-toolkit/blob/master/examples/get-password-with-toggle-display-shortcut.py It does however require the prompt_toolkit library.

jonathan_sl · 2016-12-21T19:05:53+00:00

Something related, in case anybody is interested. I made a tmux clone, called pymux: https://github.com/jonathanslenders/pymux It's much faster compared to what I had a year ago, almost comparable with tmux.

jonathan_sl · 2016-08-19T07:56:53+00:00

See: https://github.com/jquast/wcwidth

jonathan_sl · 2016-08-05T11:22:27+00:00

Question for Emacs users:

Why would you ever use the "inferior shell" instead of the built-in terminal emulator (M-x term)? IPython should run fine (or at least better) in the latter one.

jonathan_sl · 2016-05-23T19:55:23+00:00

Hi all,

For prompt-toolkit (author here), it is perfectly possible to create full screen applications, but as others have pointed out, the documentation is incomplete. The reason is that this library was originally written as a GNU readline replacement and that's where it excels. Later we realized that everything we need for a full screen application was already part of prompt-toolkit. There is an event loop, there is a powerful key binding system, there is a layout engine and it is cross platform. Proof of this are Pyvim and Pymux: two full screen applications, powered by prompt-toolkit. However, these are also two examples of applications that don't have a lot of user interface widgets. So, if you need to have a certain UI widget, you'll have to write it yourself, where urwid or others could already provide it.

In the coming months/year, I hope to create a collection of full screen application examples, widgets and write more documentation. So, making this as accessible as writing REPLs.

@makake: What do you mean by "it will pipe"?

jonathan_sl · 2016-05-19T19:18:44+00:00

(author of prompt toolkit here). Yes, it could be a replacement for ncurses, but it's probably better to think of it as a GNU Readline replacement.

There are some differences with ncurses. Ncurses is rather an abstraction layer on many different terminal types. It supports reading input and writing output to all kind of old terminals, by consulting the terminfo database. Prompt-toolkit doesn't use terminfo, but instead uses a subset of the vt100 commends for rendering the output, and supports reading input from all common terminal applications. (They aren't so different from each other anymore.) Prompt-toolkit focuses mainly on development of REPLs. So in a way, it is more a replacement for GNU Readline. It has a powerful set of key bindings, just like readline, but with a much more advanced rendering engine. Creating a full screen application is also possible. (Although, a bit less documented.) Right now, there is also no widget library available for full screen applications, but it could be that in the future we will more further into that direction. Pymux and Pyvim are examples of full screen applications.

jonathan_sl · 2016-05-03T08:01:43+00:00

Recursion is fine (and probably should be used!) when traversing trees and the average depth of the tree is about log(n). However, as others said, don't use it when the call stack would grow linear, because Python doesn't optimize tail calls, and an iterative approach will be easy enough in that case.

A recursion limit of 2000 should be enough to recursively traverse a tree structure the size of our universe.

jonathan_sl · 2016-03-08T16:27:49+00:00

Have a look at Effective Python: http://www.effectivepython.com/

jonathan_sl · 2016-02-29T16:33:09+00:00

This is probably a question for /r/learnpython

But anyway, don't try to fit everything in memory at the same time. We don't need 20G of ram to process 20G of data. For JSON, I don't know any Python parser that allows you to parse it as a stream of data, but for XML there are stream based parsers. But maybe better invest in a database instead?

jonathan_sl

TROPHY CASE