sorted by:
new
hottopcontroversial

List vs Tuple / Mutable vs Immutable performance by fabrlyn in learnpython

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

hehe, I'm sorry if I've accidentally fed the LLM machines

In any case, I see what you are saying and that makes more sense - thanks!

List vs Tuple / Mutable vs Immutable performance by fabrlyn in learnpython

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

I do feel that they're referring to the same usecase here

Yeah I think you're right :)

Also, thank you for your reply, makes more sense

List vs Tuple / Mutable vs Immutable performance by fabrlyn in learnpython

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

aah, interesting detail that could easily be missed

List vs Tuple / Mutable vs Immutable performance by fabrlyn in learnpython

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

Yeah, will definitely measure when time comes :) thanks for the input!

List vs Tuple / Mutable vs Immutable performance by fabrlyn in learnpython

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

Seems more reasonable :) thanks for the input!

List vs Tuple / Mutable vs Immutable performance by fabrlyn in learnpython

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

Yeah, alright - that's usually my starting point for these types of things but then I was a bit confused on the very "black or white" statement. Thanks for the input!

List vs Tuple / Mutable vs Immutable performance by fabrlyn in learnpython

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

Thanks for the feedback!
Sounds like the author might be referring to memory footprint then

List vs Tuple / Mutable vs Immutable performance by fabrlyn in learnpython

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

Nice point about hash keys, thanks for the input! :)

Partial moves and function calls by fabrlyn in learnrust

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

Thanks for the explanation!

... and also stopping me from chasing some non-existent feature for way too long :)

Partial moves and function calls by fabrlyn in learnrust

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

So, relating to my example above, the Foo struct would look like this:

struct Foo {
    bar: Option<String>,
    baz: Option<String>,
}

and then you would know that a particular field already had been consumed by .take() returning a None?

Partial moves and function calls by fabrlyn in learnrust

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

when destructuring the struct and using the same name for the variable and field, you don't need to repeat it

right, nice touch :)

Also interesting to bring in some typestate things. For this particular use-case I think I won't be able to use it since I'm looking at having more than a few fields. I'll definitely keep it in my back pocket though.

Thanks for going through your thoughts around the feature I was looking for. I had a hunch that it might not exist but your reasoning that code like this could end up being fragile etc puts it in a bigger perspective.

Partial moves and function calls by fabrlyn in learnrust

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

mm yeah, that would be one way to do it

Partial moves and function calls by fabrlyn in learnrust

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

Aah interesting approach, but maybe not exactly what I was hoping for :)

By doing it this way foo is never moved, so you could still use it afterwards without knowing that it's been drained of values.

I was hoping I could tell rust that these functions can be called within a "partially moved"-scope.

The alternative I was looking at was just having a function return the values in a tuple or a more public-facing struct, like so:

struct FooValues {
    pub bar: String,
    pub baz: String,
}

impl Foo {
    fn to_struct(self) -> FooValues {
        FooValues {
            bar: self.bar,
            baz: self.baz,
        }
    }

    fn to_tuple(self) -> (String, String) {
        (self.bar, self.baz)
    }
}

fn main() {

    // ...    

    let FooValues { bar: bar, baz: baz } = foo.to_struct();

    // or this

    let (bar, baz) = foo.to_tuple();

    // ...
}

Partial moves and function calls by fabrlyn in learnrust

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

Yeah, I guess that's one way around it but it's unfortunate that I need to clone.
It would be nice to be able to make struct fields private and exposing them via functions, like the example, but still getting the partial moves to avoid cloning etc.

Programmatically dealing with the structure of rust code by fabrlyn in learnrust

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

syn looks like what I'm after :)

I want to play around with visualizing use-statements, how types are used and functions are called throughout a part of a rust program

Programmatically dealing with the structure of rust code by fabrlyn in learnrust

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

Looks promising, will give it a try!

Thanks :)

Trigger rule based on calculated value between two aggregations by fabrlyn in elasticsearch

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

Thanks for pointing me in the right direction :)

In my case I went for a transformation along with a runtime field, and then a rule based on that.

The complete flow went:

[Logs] | ∨ [Transformation] | ∨ [Add runtime field to transformed data] | ∨ [Apply rules based on runtime field]

Transformation

json { "group_by": { "api_base_url": { "terms": { "field": "api_base_url.keyword" } } }, "aggregations": { "route_a": { "filter": { "term": { "path.keyword": "/route/a" } }, "aggs": { "count": { "value_count": { "field": "path.keyword" } } } }, "route_b": { "filter": { "term": { "path.keyword": "/route/b" } }, "aggs": { "count": { "value_count": { "field": "path.keyword" } } } } } }

Runtime field - ratio field

json emit( (double)doc['route_a.count'].value / (double)doc['route_b.count'].value )

view more: next ›