Бляди тоже ок, ага. Войти !bnw Сегодня Клубы
Привет, TbI — HRWKA! 1103.1 пользователей не могут ошибаться!
?6225
прекрасное5890
говно5759
говнорашка5050
хуита4042
anime2764
linux2461
bnw2302
music2274
log2067
рашка2012
pic1876
ололо1760
быдло1415
украина1365
сталирасты1204
гімно1143
дыбр1117
роботы_не_одобряют1005
bnw_ppl899

Не блокчейн! И вообще arm. https://moikrug.ru/vacancies/1000046253
#ZKBCHX (0+8) / @o01eg / 44 дня назад
О, clippy в стабильный компилятор завезли: https://blog.rust-lang.org/2018/09/13/Rust-1.29.html "cargo clippy Speaking of warnings, you can now check out a preview of cargo clippy through Rustup. Clippy is a large number of additional warnings that you can run against your Rust code. For example: let mut lock_guard = mutex.lock(); std::mem::drop(&lock_guard) operation_that_requires_mutex_to_be_unlocked(); This code is syntactically correct, but may have a deadlock! You see, we dropped a reference to lock_guard, not the guard itself. Dropping a reference is a no-op, and so this is almost certainly a bug. We can get the preview of Clippy from Rustup: $ rustup component add clippy-preview and then run it: $ cargo clippy error: calls to `std::mem::drop` with a reference instead of an owned value. Dropping a reference does nothing. --> src\main.rs:5:5 | 5 | std::mem::drop(&lock_guard); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: #[deny(drop_ref)] on by default note: argument has type &std::result::Result<std::sync::MutexGuard<&#39;_, i32>, std::sync::PoisonError<std::sync::MutexGuard<&#39;_, i32>>> --> src\main.rs:5:20 | 5 | std::mem::drop(&lock_guard); | ^^^^^^^^^^^ = help: for further information visit https://rust-lang-nursery.github.io/rust-clippy/v0.0.212/index.html#drop_ref As you can see from that help message, you can view all of the lints that clippy offers on the web. Please note that this is a preview; clippy has not yet reached 1.0. As such, its lints may change. We’ll release a clippy component once it has stabilized; please give the preview a try and let us know how it goes."
#RJRN61 (0+8) / @o01eg / 89 дней назад
Раст готов к аниме: https://github.com/xiph/rav1e/pull/437
#52ARTP (13+8) / @o01eg / 125 дней назад
почитал всякие циклы. Есть отличия от c++, но в целом понятно и похоже. Есть определенные странности, сделано местами "а вот тут автору было удобнее сделать так, поэтому вот вам костыль на всякий случай".
#LOYAIJ (1) / @voker57 / 168 дней назад
Японцы знают толк в языках: https://d-cube.connpass.com/event/90317/
#4UBMHQ (1+7) / @o01eg / 192 дня назад
https://blog.rust-lang.org/2018/05/10/Rust-1.26.html "At long last, impl Trait is here! This feature has been highly desired for quite a while, and provides a feature known as “existential types.” It’s simpler than that sounds, however. The core of it is this idea: ... Speaking of papercuts, since Rust uses the Result type for returning errors, and ? to make handling them easy, a common pain-point of new Rustaceans is to try and use ? in main: ... Inclusive ranges with ..= ... Another long-awaited feature is “slice patterns.” These let you match on slices similar to how you match on other data types."
#AAH45X (7+7) / @o01eg / 215 дней назад
Смотрите, я пишу на расте как на го https://play.rust-lang.org/?gist=f3a0d0b2ba4fd836364810ff01e3c59e&version=stable
#W31P3M (0) / @anonymous / 247 дней назад
https://github.com/xiph/rav1e The fastest and safest AV1 encoder.
#JCOB1X (0+7) / @o01eg / 255 дней назад

Сегодня на радио http://radio.fags.ga в 22:00 будет эфир про язык программирования Rust

#KGIXRP (0+2) / @kerrigan / 255 дней назад
Тем временем тихо и незаметно вышла новая версия 1.25, в которую вошли мои патчи чтобы Make Rust Gentoo Again! https://blog.rust-lang.org/2018/03/29/Rust-1.25.html
#GRTSG6 (1+8) / @o01eg / 257 дней назад
После 1.0 наступит стабильность, говорили они. Обратную совместимость нарушать не будут, говорили они. https://github.com/rust-lang/rust/issues/48716
#DNVUOW (3+2) / @o01eg / 283 дня назад
dev-lang/rust: version bump to 1.23.0
#R0KZP8 (0) / @corpse / 323 дня назад
https://www.mercurial-scm.org/repo/hg/rev/964212780daf "Rust: implementation of `hg` This commit provides a mostly-working implementation of the `hg` script in Rust along with scaffolding to support Rust in the repository. If you are familiar with Rust, the contents of the added rust/ directory should be pretty straightforward. We create an "hgcli" package that implements a binary application to run Mercurial. The output of this package is an "hg" binary. Our Rust `hg` (henceforth "rhg") essentially is a port of the existing `hg` Python script. The main difference is the creation of the embedded CPython interpreter is handled by the binary itself instead of relying on the shebang. In that sense, rhg is more similar to the "exe wrapper" we currently use on Windows. However, unlike the exe wrapper, rhg does not call the `hg` Python script. Instead, it uses the CPython APIs to import mercurial modules and call appropriate functions. The amount of code here is surprisingly small. It is my intent to replace the existing C-based exe wrapper with rhg. Preferably in the next Mercurial release. This should be achievable - at least for some Mercurial distributions. The future/timeline for rhg on other platforms is less clear. We already ship a hg.exe on Windows. So if we get the quirks with Rust worked out, shipping a Rust-based hg.exe should hopefully not be too contentious."
#5QNZH2 (2+1) / @o01eg / 326 дней назад
Теперь в компиляторе rust есть кусочек и моего кода: https://github.com/rust-lang/rust/pull/46592
#ONMV17 (1+2) / @o01eg / 333 дня назад
Программы на Расте, которые мы заслужили: https://github.com/MonkeyLog/BrewStillery "BrewStillery is a brewer&#39;s, vintner&#39;s, and distiller&#39;s calculator. It has a multitude of great functions, such as calculating ABV, determining carbonation, and total sparge water needed."
#GRCQ74 (0+1) / @o01eg / 335 дней назад
Нашёл единственную работающую библиотеку для XMPP: https://github.com/astro/tokio-xmpp Но её даже на crates.io нет
#DOLT4U (1+1) / @o01eg / 335 дней назад
Ещё одна purerust GUI библиотека. На этот раз даже работающая со stable версией: https://christolliday.github.io/limn/limn/index.html
#DU5R95 (0+2) / @o01eg / 338 дней назад
https://www.mercurial-scm.org/wiki/OxidationPlan "Using Rust in Mercurial This page describes the plan and status for leveraging the Rust programming language in Mercurial. Why use Rust? Today, Mercurial is a Python application. It uses Python C extensions in various places to achieve better performance. There are many advantages to being a Python application. But, there are significant disadvantages. Performance is a significant pain point with Python. There are multiple facets to the performance problem: Startup overhead General performance overhead compared to *native* code GIL interfering with parallel execution It takes several dozen milliseconds to start a Python interpreter and load the Mercurial Python modules. If you have many extensions loaded, it could take well over 100ms just to effectively get to a Mercurial command&#39;s main function. Reports of over 250ms are known. While the command itself may complete in mere milliseconds, Python overhead has already made hg seem non-instantaneous to end-users. A few years ago, we measured that CPython interpreter startup overhead amounted to 10-18% of the run time of Mercurial&#39;s test harness. 100ms may not sound like a lot. But it is enough to give the perception that Mercurial is slower than tools like Git (which can run commands in under 10ms). There are also situations like querying hg for shell prompts that require near-instantaneous execution. Mercurial is also heavily scripted by tools like IDEs. We want these tools to provide results near instantaneously. If people are waiting over 100ms for results from hg, it makes these other tools feel sluggish. There are workarounds for startup overhead problems: the CommandServer (start a persistent process and issue multiple commands to it) and CHg (a C binary that speaks with a Mercurial command server and enables chg commands to execute without Python startup overhead). chg&#39;s very existence is because we need hg to be a native binary in order to avoid Python startup overhead. If hg weren&#39;t a Python script, we wouldn&#39;t need chg to be a separate program. Python is also substantially slower than native code. PyPy can deliver substantially better performance than CPython. And some workloads with PyPy might even be faster than native code due to JIT. But overall, Python is slower than native code. But even with PyPy&#39;s magical performance, we still have the GIL. Python doesn&#39;t allow you to execute CPU-bound Python code on multiple threads. If you are CPU bound, you need to offload that work to an extension (which releases the GIL when it executes hot code) or you spawn multiple processes. Since Mercurial needs to run on Windows (where new process overhead is ~10x worse than POSIX and is a platform optimized for spawning threads - not processes), many of the potential speedups we can realize via concurrency are offset on Windows by new process overhead and Python startup overhead. We need thread-level concurrency on Windows to help with shorter-lived CPU-bound workloads. This includes things like revlog reading (which happens on nearly every Mercurial operation). In addition to performance concerns, Python is also hindering us because it is a dynamic programming language. Mercurial is a large project by Python standards. Large projects are harder to maintain. Using a statically typed programming language that finds bugs at compile time will enable us to make wide-sweeping changes more fearlessly. This will improve Mercurial&#39;s development velocity. Today, when performance is an issue, Mercurial developers currently turn to C. But we treat C as a measure of last resort because it is just too brittle. It is too easy to introduce security vulnerabilities, memory leaks, etc. On top of vanilla C, the Python C API is somewhat complicated. It takes significantly longer to develop C components because the barrier to writing bug-free C is much higher..."
#ZFY03P (0+1) / @o01eg / 372 дня назад
ipv6 ready BnW для ведрофона BnW на Реформале Викивач Котятки

Цоперайт © 2010-2016 @stiletto.