#Problem with dereferencing and namespaces in Rust

323 messages · Page 1 of 1 (latest)

fervent current
#

Hello, I am having issues with dereferencing. Coming from C++ background, decided to write a GUI toolkit in Rust, started today, like 1h ago. Here's the context.

#

Besides, I just got this. How am I supposed to fix this?

#

Problem with dereferencing and namespaces in Rust

warm path
#

try putting in the loop

"for .. in .."

something like this

"for &.. in .."

#

because its expecting the struct

#

and you are giving a reference to it

#

when you put "&" before loop assing then it dereferences

#

in your case:

for /*notice the "&" -->*/ &m in connected {
  monitors.push(m);
}
#

if m doesnt implements Copy then try taking ownership of connected instead

fervent current
#

ooo yes yes

#

thanks

#

I fixed the other problem

#

with the Window thing

#

also made them lowercase

#

to follow convention

#

Now this error

warm path
#

let me think

#

mmm

#

what type is connected_monitors?

#

@fervent current

#

is it reference?

fervent current
#

let me see quickly again

#

An opaque handle

#

&[window::droplet_window::glfw::Monitor]

warm path
#

that is the type of m

#

right?

fervent current
warm path
#

but the error code says that is the type of m

fervent current
#

And the type of m is window::droplet_window::glfw::Monitor

warm path
#

ahhhh

#

ok

#

i miss read

#

they didnt give the ownership

fervent current
#

yes, so what shall I do?

warm path
#

does window::droplet_window::glfw::Monitor implements Clone?

fervent current
#

no it does not

#

You meant the Copy trait, but neither

warm path
#

no

#

Clone is different

fervent current
#

when I do .clone() it still underlines it

warm path
#

do you really need to have a vector of owned window::droplet_window::glfw::Monitor?

#

or you just need the reference

fervent current
#

Reference is fine

warm path
#

then make the vector of references instead owned

#

its cheaper in memory too

fervent current
#

Lifetime issue

warm path
#

i was expecting it

fervent current
#

Now I removed the reference from for &m

#

but I still get this

warm path
#

you are dropping glfw before monitors

#

probably

#

no, connected_monitors is in clousure

fervent current
#

Here, to get a fuller picture

warm path
#

i think you can remove that & right?

#

m its self is &

#

it will not help anyways

fervent current
#

yeah

#

I removed it

#

nothing changed

warm path
#

i k but it makes it cleaner

#

wait

#

you are using monitor

#

but you never assign it

#

monitor without s

fervent current
#

This might be helping

fervent current
warm path
#

its a start but is not the problem

#

ye

fervent current
#

Another way is I just spawn everything on the primary monitor

#

But that will make things very limiting

warm path
#

the problem is

#

if you save it like reference

#

its dropped and you get danging reference

#

and the compiler knows it

#

and you cant owned because the library doesnt allow you to copy it, that is maybe obvious because its monitor handling

fervent current
warm path
#

i think the only way is only using monitors inside the clousure

#

its not about satisfying the compiler

#

its about dangling references

fervent current
#

Well, I can make it select the monitor and then create the window inside it

#

I just have no idea how to know about a monitor's name at run time

warm path
#

why do you need a vector of them?

fervent current
#

I thought it'd let me select the monitor they ran it from

#

Because the Rust crate only exports two things

#

Shall I just do "with primary monitor"

#

and roll with it

#

It's always possible to go back at this later and fix it

warm path
#

i think saving monitors can result in errors, and maybe that is because you can

#

try
monitors = connected_monitors.to_vec();

fervent current
#

this is the C library itself

warm path
#

what you want to index them?

fervent current
fervent current
#

Where I can label them with names such as "Display1" (primary display)

#

and so on

warm path
#

then why you want to make a vector of monitors?

fervent current
warm path
#

looks like the library only wants to give you the monitors inside the function .with_connected_monitors

fervent current
fervent current
#

Because I want to let people to select a monitor

#

where this opens

warm path
#

worry i want to help but i want to go to dinner

fervent current
#

We can talk later

#

It's ok

#

I will be awake

#

it's just 4:33

#

I am just starting

#

Feel free to DM too

warm path
#

here its 22:33

fervent current
#

Easier to get real time to you

fervent current
#

using 24h

#

perfect

warm path
#

ye

#

arg

fervent current
#

Enjoy your dinner

warm path
#

@fervent currenti came back

#

are you sure your api cant give you a vector of monitors?

#

or &[monitors] but independent of a clousure?

#

if not probably there is a reason because it doesn't exist, maybe API wants to be secure when you are not using monitors anymore

#

you can use this (like in C++)

#

but its unsafe (like in C++)

fervent current
#

welcome back

#

ok so

fervent current
#

for now I will just use primary monitor

warm path
fervent current
#

as far as I know

#

Why this now...

warm path
#

why 2 of the matched has the same code?

fervent current
#

and I will do something later

#

with Borderless

#

I will set decoration to false

warm path
#

oh ok srry unfinished code is confusing

fervent current
#

It's finished in this match

#

I will be elaborated after making the window

#

because there is no other way.

warm path
#

anyways

#

what is thee problem

#

in line 69 - 1

fervent current
#

How can I make a value leave a closure?

warm path
fervent current
#

droplet_window.rs(56, 21): window_mode declared here, outside of the closure body
droplet_window.rs(66, 60): monitor is a reference that is only valid in the closure body
droplet_window.rs(68, 33): monitor escapes the closure body here

warm path
#

basically

#

you setted

#

window_mode = &monitor

#

right?

fervent current
#

no

warm path
#

what

fervent current
#

I set window_mode to FullScreen on monitor at &monitor

warm path
#

well yes

#

but its derivated

#

by lifetime

fervent current
#

can I extend its lifetime?

warm path
#

no lifetime doesn't change when it drops

#

basically if you were doing this in another language

#

like C

#

C would let you do it

#

but you will have terrible errors

#

terrible

fervent current
#

When a value leaves scope, C doesn't let you compile

warm path
#

so when you set windows_mode

warm path
#

wait

#

what C compiler are you using

fervent current
#

clang (LLVM)

warm path
#

well no C will let you

fervent current
#

I also use gcc

#

both don't let you

warm path
#

any C compiler detect that anyways

#

basically you set
window_mode to a &monitor derivated

#

when you drop monitor

#

monitor derivated is unvalid

#

if you use it is UB

#

and you will likely get a unvalid object

#

you have 2 options

#

use some unsafe API

#

or cobber all function with that closure

fervent current
warm path
fervent current
#

Or the entire droplet_window.rs file ?

warm path
#

no sorry

#

in entire zone where you need it

warm path
fervent current
#

So the entire thing in new okay

warm path
#

that will let you do it more idiomatic at your risk

fervent current
#

(apart from the return which is Self)

#

I'd rather keep it safe for now

#

if at some point it gets hard

#

I will use ffi

warm path
#

ye i recommend you safe

fervent current
#

You probably understood what I am making when I shared my screen

warm path
#

because when you have a really hard problem

#

uf

fervent current
#

This is a mess

#

If this makes me lose my patience

#

I will code it in C++

#

and let it be

#

because this is too much effort for literally nothing

#

I can always make myself a Rust wrapper

#

after C++

#

I have a vague idea of what I can do

#

but this api is just a mess

warm path
#

@fervent currentbut why not just use the unsafe version

#

its the same as C++ one

fervent current
warm path
#

yes

#

sometimes unsafe is needed

fervent current
#

I'd only do it if I am really ahead and I cannot allow myself to change the language

#

I am trying something

#

give me a sec

warm path
#

post the entire new func

fervent current
#
fn new (title: &str,
        dimensions: (u32, u32),
        decorations: DropletWindowDecorations,
        state: (DropletWindowMinimisedState, DropletWindowFocusedState),
        mode: DropletWindowMode) -> Self
            {
                let mut glfw = glfw::init(glfw::FAIL_ON_ERRORS).unwrap();

                match &mode {
                    DropletWindowMode::Bordered => {
                        let (mut window, events) = glfw.create_window
                                            (dimensions.0, dimensions.1, title,
                                                glfw::WindowMode::Windowed)
                                                .expect("Cannot create window.");
                    },
                    DropletWindowMode::Borderless => {
                        let (mut window, events) = glfw.create_window
                                            (dimensions.0, dimensions.1, title,
                                                glfw::WindowMode::Windowed)
                                                .expect("Cannot create window.");
                        
                                                window.set_decorated(false);
                    },
                    DropletWindowMode::Fullscreen => {
                        let (mut window, events) = glfw.with_primary_monitor(|_, mon|
                            {
                                glfw.create_window
                                            (dimensions.0, dimensions.1, title,
                                            glfw::WindowMode::FullScreen(&mon.unwrap()))
                                            .expect("Cannot create window.")
                            });
                    }
                }

                Self {
                    title: title.to_owned(),
                    dimensions,
                    decorations,
                    state,
                    mode,
                    view: None
                }
    }
#

But I am still getting the same error

#

Actually, if this keeps on bugging me

#

I will just make this a borderless window

#

with the size of the actual display

#

and make it unmovable

warm path
#

dont change your plans

fervent current
#

The fuck of an API literally

#

I give up, I am done for today

#

2 hours spent on this

#

I am literally following the example of this dude

#

He himself doesn't know how to use his API

#

I am done man

warm path
#

you will do it with borderless and bordered?

fervent current
#

No, I will use fullscreen

#

but I will not use his full screen

#

I will use only Windowed from the API

#

but I will disable borders

#

and set the size to the display size

#

why do I need a monitor setup in my toolkit?

#

haha

#

I can just use displays

#

isn't that better

#

unless...

fervent current
#

the one who made the rust wrapper

#

See the big Example letters?

#

That's written by him

warm path
#

anyways did you tried the unsafe one?

fervent current
#

no, I haven't

#

maybe later

#

It's 6:40

#

I am so angry that I won't go to sleep

#

I want to fix this

#

but I am tired to do so

warm path
#

i want to help but i dont wanna ask for entire code

fervent current
#

It's going to be open source

#

lol

warm path
#

lol

fervent current
#

I will legit commit to github now

#

I am making a toolkit for my OS

warm path
#

LOL

fervent current
#

I want to make a Desktop Environment with it

#

and apps

warm path
#

are you making a OS?

fervent current
#

yes

warm path
#

wow

fervent current
#

FreeBSD based

warm path
#

good luck

fervent current
#

I am using a high level API, and maybe that's my mistake

#

But if I use Vulkan directly

#

it's overwhelming

#

and one person cannot make this

#

without abstractions

warm path
#

how big is the code rn?

fervent current
#

It's actually just this

#

I started today

warm path
#

ok pass the entire code if you want and i will find the way

fervent current
#

And I thought "best to start with the Windows, then Widgets"

fervent current
#

I will do so on DM if you want

warm path
#

ok

fervent current
#

I am going to commit this at its current version

#

Are you really interested in contributing?

warm path
#

or advise me when you upload

fervent current
#

thanks a lot

#

We can work together? If you wanna have fun of course

warm path
#

i dont know anything about OS dev

#

im sorry

fervent current
#

Just the toolkit

warm path
#

ok

fervent current
#

everything else I know what to do

#

Since we have guys who have the task to make hardware

#

They will make a processor architecture as well

warm path
#

wait

#

that is a lot actually

fervent current
#

It is, yes

#

We thought about using RISC-V initially

#

But well, we might need a fuller instruction set

#

and x86 is closed source

#

we want to make everything open source

warm path
#

how is the OS called?

fervent current
#

Fluid

#

It will be an OS for phones, computers, tablets, TVs and even smartwatches/any wearables

warm path
#

wow that is impressive

fervent current
#

The goal is to make it as beautiful, stable and user-friendly as possible

#

but also accommodating to developers

#

hence why I chose FreeBSD

#

FreeBSD is better for development than Linux in my opinion

warm path
#

by the name i can make assumptions about his appearance

fervent current
#

But I like both

fervent current
#

I have an unfinished basic concept

warm path
#

lightblue

fervent current
#

from our designer

#

Sure, the colours are blue

#

Come on DM since this got off topic