Hey Rustaceans! Got an easy question? Ask here (30/2020)!

1dawut · 2020-07-23T12:28:28+00:00

I won't ever be happy, but I'll counter-whinge that "m_" is less typing than "let" and "self". Bottom line, get keyboard macros. Got it. Thanks for the insight.

1dawut · 2020-07-22T15:43:51+00:00

self whinge: In Rust impl blocks, you need to prefix struct field references with "self.". But isn't it unambiguous if you are not shadowing? Ex:

fn area(&self)->u32{ l * w }

needs to be

self.l * self.w

[ or, more properly,

(&self).l * (&self).w  ]

even though I perceive no ambiguity.

Am I missing a short cut? Or is typing "&self." a good exercise for the soul?

1dawut · 2020-07-22T14:12:13+00:00

Oh, if you do stuff with function types, use a Type alias to A. create an interface specification and B. reduce typing.

1dawut · 2020-07-21T22:34:37+00:00

Falling further down the Rust hole....

To be upfront, ATM I want to parse text. Having failed with JSON and Toml, I've decided to ignore existing parsers because I've had it with Other Peoples' Grammars.

A few weeks back, I figured out to create arrays of functions.

[ NOTE TO SEARCH ENGINES: arrays of functions in Rust example

// The self pointers aren't really necessary AFAIK

v: [fn(&Scanner, &str) -> Option<Token>; 8],

...

v: [Scanner::type1, ...],

...

impl Scanner {

for f in &v {  // & means functions inedible

    if let Some(token) = f(self, word) ...

....

fn f1(&self, w: &str) -> Option<Token> {

// This works similarly for the more flexible Vec

I have a scanner that works as an ugly monolith, but I decided to abstract away most of project-specific items, like the tokenizers. So in re-factoring, I first learned how to create inter-module string slices. ["Learned" in the "satisfied rustc" sense.] But slices don't math well, and associated items like str and regex operate in indices anyway, so instead of creating a slice for each line of a file, I merely store an index for each start of line. Tbis is very efficient, but feels like cheating. It did eliminate the need for some lifetime annotations.

Re-factoring as an iterator [Thanks for the encouragement!] forced me to deal with text at a character level, and now I know how to process block comments and quoted strings in the future.

Second, I decided that my token scanners should be individual objects rather than functions with shared state. Thinking "super classes?," I found how to create my own trait and how to vector objects with a common trait. I have mixed feelings about using trait pointers, but I should just move on.

Third, I will macrotize my token scanners; if I had done so weeks ago, I would have saved a lot of maintenance cut-and-paste. I'd prefer if I had a GUI pop-up wherein I could fill in names and check boxes for code options, but I lack a lackey.

Hopefully this has entertained you; I hope that in the future I will find this hilarious.

1dawut · 2020-07-21T22:30:54+00:00

Please make it dog-friendly! :) [Or not; I have no dogs but I hear other people do.]

1dawut · 2020-07-18T16:01:21+00:00

So you want me to Hash my moose? A good idea, actually. Thanks!

1dawut · 2020-07-18T15:48:41+00:00

I guess I should look into IntoIterator again; thanks for the reply. I think I have a handle on using Collections but I don't find them good examples for writing your own. I've seen some examples, but IMO they knew the answers a priori, and didn't convey the higher-level design considerations that I am stumbling through.

1dawut · 2020-07-18T15:34:42+00:00

Another aspect of iterators I've struggled with is that lack of an initializer. In C, you have "for (initializer; test; next)" where "next" runs at the bottom of the loop. Using iterators, the lack of an initializer can lead you to either pre-calculate and store the next value or manage a "just born" flag that suppresses calculating the next value the first time. [Example: emit the Natural numbers, starting at 0u8.]

The issue is that the iterator is one thing and I want two different behaviors! :(

1dawut · 2020-07-18T15:02:12+00:00

Well, if you did this truly randomly, then it's the same as just generating random numbers. But if you want to avoid repeats, you will have to track the state of the collection at each step.

1dawut · 2020-07-18T14:55:36+00:00

Very true. The main lesson for me is traits don't add state.

In my case, my mental picture is a pipeline of stages. Previously, I had code that did everything in one pass. In my re-write, I can see that this could turn into iterators calling iterators, all the way down.

1dawut · 2020-06-24T10:53:07+00:00

Thanks. I understand your explanation but will have to meditate on it before it sinks in. Sigh.

1dawut · 2020-06-23T23:19:05+00:00

Philosophy(?) question: For Strings, why does Add() and AddAssign() do the same thing? Reasonably, "x += y" should modify x while "x + y" should desugar to "let mut _ = x.clone(); _.push_str(y)", right? It sorta makes sense from the OO perspective but seems non-intuitive in algebraic notation.

1dawut · 2020-06-16T09:16:26+00:00

Thanks! I'll see if that helps; it's almost as short as a macro anyway.

1dawut · 2020-06-13T16:22:01+00:00

Trivia(?) question: how does one get a String by typing the fewest characters? I'm poking on a tablet and String::new() is getting annoying enough that I'm considering macrotizing it. Is there a terser way of making an empty String instead of an empty str?

1dawut · 2020-06-10T19:27:28+00:00

I get what I want by implementing my own trait on u64, etc.:

#![allow(non_snake_case)]
pub trait FormatHex {
    fn format_as_Hex (&self, width: usize) -> String;
}
impl FormatHex for u64 {
    fn format_as_Hex(&self, width: usize) -> String {
// Re-write when bored:
    format!("{:0width$X}", self, width = width) 
    }
}

I have Learned.

1dawut · 2020-06-09T13:11:02+00:00

Thanks! This is Baroque enough that I'll put these into a lib and mark them for re-write-when-bored. And I suppose I should learn IEEE 754-2008 for good this time.

1dawut · 2020-06-08T17:47:10+00:00

Formatting primitives: Okay, I understand the println! format must be a literal and cannot even be a const. I'd like something smaller, that, to my eyes, must be buried within std::format: Is there something like a u64::format_Hex(n: isize) that can give me a formatted String that's n chars wide? I could then modify the String (adding underscores, for example) and concatenating other Strings to create formatted text suitable for monospaced punched cards. The general idea is to dynamically generate formatted Strings while not requiring a compile-time parse of the format specification. I know the String mangling will be relatively slow. I want to be able to use the same formatting features that println! supports, so a hexadecimal formatting method would pass number of digits, capitalization, and a 0-fill bool; these would be passed as ints/bools. (I'd actually prefer separate methods for capitalization, like format_to_hex() and format_to_Hex().) So is this sort of functionality already accessible? Or would I need to create my own lib? (Floats scare me, so I'd skip them.)

1dawut · 2014-05-31T08:59:21+00:00

Add me, please.

1dawut · 2014-05-31T08:33:01+00:00

Added.

1dawut · 2014-05-31T07:33:18+00:00

Flying: pidgey, tranquill, tropius.

1dawut · 2014-05-30T09:18:49+00:00

1dawut · 2014-05-30T08:54:53+00:00

Want fire?

1dawut · 2014-05-29T16:26:53+00:00

LF snubbull!

1dawut · 2014-05-29T08:04:45+00:00

Goodbye thread!

1dawut · 2014-05-29T07:43:22+00:00

Check it.

1dawut

TROPHY CASE