BB_C @ BB_C @programming.dev

Posts

10

Comments

366

Joined

2 yr. ago

DNS blockers became a thing in part because /etc/hosts can't do stuff like glob subdomain blocking, no?

e.g.

    
*.bla.tld 127.0.0.1

  

Good work.
I don't know if kornel still lurks here, but I think he did/does related/similar analysis for https://lib.rs.

@kornel@programming.dev / @kornel@mastodon.social

You could have just mentioned the project in question since its code is public.

https://git.joinplu.me/plume/plume

    
% git grep '#!\[feature'
plume-common/src/lib.rs:#![feature(associated_type_defaults)]
plume-front/src/lib.rs:#![feature(decl_macro, proc_macro_hygiene)]
plume-models/src/lib.rs:#![feature(never_type)]
plume-models/src/lib.rs:#![feature(proc_macro_hygiene)]
plume-models/src/lib.rs:#![feature(box_patterns)]
src/main.rs:#![feature(decl_macro, proc_macro_hygiene)]

  

    
% cat rust-toolchain
nightly-2022-07-19

  

    
% rm -f rust-toolchain
% cargo check

  

No errors from plume crates, but we get errors in a couple of locked dependencies:

    
error[E0422]: cannot find struct, variant or union type `LineColumn` in crate `proc_macro`
   --> /home/user64/.cargo/registry/src/index.crates.io-6f17d22bba15001f/proc-macro2-1.0.49/src/wrapper.rs:479:33
    |
479 |                 let proc_macro::LineColumn { line, column } = s.start();
    |                                 ^^^^^^^^^^ not found in `proc_macro`
    |
help: consider importing one of these items
    |
1   + use crate::LineColumn;
    |
1   + use crate::fallback::LineColumn;
    |
help: if you import `LineColumn`, refer to it directly
    |
479 -                 let proc_macro::LineColumn { line, column } = s.start();
479 +                 let LineColumn { line, column } = s.start();
    |

   Compiling generic-array v0.14.6
error[E0422]: cannot find struct, variant or union type `LineColumn` in crate `proc_macro`
   --> /home/user64/.cargo/registry/src/index.crates.io-6f17d22bba15001f/proc-macro2-1.0.49/src/wrapper.rs:496:33
    |
496 |                 let proc_macro::LineColumn { line, column } = s.end();
    |                                 ^^^^^^^^^^ not found in `proc_macro`
    |
help: consider importing one of these items
    |
1   + use crate::LineColumn;
    |
1   + use crate::fallback::LineColumn;
    |
help: if you import `LineColumn`, refer to it directly
    |
496 -                 let proc_macro::LineColumn { line, column } = s.end();
496 +                 let LineColumn { line, column } = s.end();
    |

    Checking once_cell v1.17.0
error[E0635]: unknown feature `proc_macro_span_shrink`
  --> /home/user64/.cargo/registry/src/index.crates.io-6f17d22bba15001f/proc-macro2-1.0.49/src/lib.rs:92:30
   |
92 |     feature(proc_macro_span, proc_macro_span_shrink)
   |                              ^^^^^^^^^^^^^^^^^^^^^^


  

Let's see if a full (semver-compatible) deps update works:

    
% cargo update
% cargo check

  

This succeeds.

I will let you pick it from here.
Should be a good learning experience.

What unstable features are used by the project you're trying to fix?

I have no specific knowledge of this stuff. But the generic answer is an obvious one.
However Python code does it can be replicated in Rust.
For example, if python code executes the driver as a subprocess, then that too can be done in Rust.
So checking how Python code does it will probably lead to an answer to this question.

Maybe ask a web dev community about this.
There could be something better written in Rust.
There could be something better NOT written in Rust.
They should know.

Didn't read the post yet. But for future reference, posting archived links to posts from that website is probably preferable since it doesn't appear to be hosted in a way that can handle large traffic.

https://web.archive.org/web/20240602124317/https://smallcultfollowing.com/babysteps/blog/2024/06/02/the-borrow-checker-within/

A good time to refresh my Rust folder as a whole to see what features got stabilized, removed, or subsumed.

My current list of used unstable features is down to 20.
Some lang, some lib.
A couple incomplete.
Some are more important than others.

    
#![feature(adt_const_params)]
#![feature(async_closure)]
#![feature(const_type_name)]
#![feature(duration_constants)]
#![feature(extract_if)]
#![feature(generic_arg_infer)]
#![feature(impl_trait_in_assoc_type)]
#![feature(iter_array_chunks)]
#![feature(let_chains)]
#![feature(macro_metavar_expr)]
#![feature(map_try_insert)]
#![feature(never_type)]
#![feature(once_cell_try)]
#![feature(proc_macro_hygiene)]
#![feature(specialization)]
#![feature(step_trait)]
#![feature(stmt_expr_attributes)]
#![feature(try_blocks)]
#![feature(try_find)]
#![feature(type_changing_struct_update)]

  

DISCLAIMER: this is not an endorsement of try_blocks 😐

Maybe I should have written something simpler like "What is the shortest distance between two points, and how does it look like?"

The problem is, if you knew anything about the subject matter, you would know that even JAVA code ends up being compiled ahead-of-time by ART to ELF binaries on Android.
Even non-devs know this stuff!

Yes. That was a part of "1. needed".
Read about how Dart/Flutter does it.

they were practically in denial that it existed 😅 Some serious java hate.

You seem to imply that this is something 1. needed 2. wanted. 3. somehow threatening. Which is a hilarious thought.

I didn't understand your sentence. But: Having concerns is valid.
Having them in the context of this story/ad is misplaced.

IBM invested 1B$ in Linux all the way back in year 2000 (imagine how much that is worth with tech inflation), and they did it again years later.

That 1M$ is nothing. It's not nearly enough to control the Rust foundation for one year, let alone controlling the Rust project as a whole. Calling it a "Vote of Confidence in Rust's Future" was probably a good-spirited joke from the author, at least I hope it was.

Note that IBM still doesn't control Linux (even after acquiring RedHat), and we still have no problem calling them evil. Some of us still have no problem calling MS evil either, although many of the new crop of developers won't, because for them the chance to have the financial privilege of working there someday outweighs any moral considerations. Incidentally, there is a good intersection between this group, and the group that takes moral posturing about whatever in-group approved cause of the month to the maximum. Ironic, isn't it?

This is effective advertisement, not a donation. A real ad (with a campaign) would probably have cost much more, and wouldn't continue to be propagated for free months after the ad campaign is over, like this peace of news.

This type of ad is also much harder to filter/block, since not only it appears to be site-native, but also topic-native.

You should have kept this in the microblogtard platform of your choice.

Thank you for your continued work on this.
We await the rustup reveal with great anticipation.

Edit: Oh, and nice to see a '+' in this update.

Examples ARE usage documentation.

What value is this blog supposed to be adding exactly?
The fact that top-level and API descriptive explanations are important?
The fact that some projects don't have complete documentation?
To whom exactly would this be considered new information?

Not based on, but built on top of Iced.

The fork wouldn't be that different from whatever upstream Iced snapshot it last synced with. There are two major, if peripheral, changes still. A renderer for some Wayland special needs, and some integrated accessibility support. At least that was the case until a few weeks ago. I don't think anything significant changed since.

So the Iced API itself is largely the same. However, since this is built on top of Iced. COSMIC apps are more inclined to use abstractions and tools from libcosmic wherever applicable instead of using Iced API directly. But you still see plenty of direct Iced API use.

p.s. I’m also curious if you have any actual evidence that these two are more reliable than gtk. It’s reasonable to think they might be, but I’d like something more than “they’re written in Rust and have fewer features.”

I based my suggestion based on the logical requirement stated (first quote) which was later ignored (second quote).

I didn't make any specific claims about imaginary reliability score points.

iced or slint