#Problem with dereferencing and namespaces in Rust
323 messages · Page 1 of 1 (latest)
Besides, I just got this. How am I supposed to fix this?
Problem with dereferencing and namespaces in Rust
first of all
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
ooo yes yes
thanks
I fixed the other problem
with the Window thing
also made them lowercase
to follow convention
Now this error
yes it doesnt implements Copy
let me think
mmm
what type is connected_monitors?
@fervent current
is it reference?
let me see quickly again
An opaque handle
&[window::droplet_window::glfw::Monitor]
that's the connected_monitors
but the error code says that is the type of m
And the type of m is window::droplet_window::glfw::Monitor
yes, so what shall I do?
does window::droplet_window::glfw::Monitor implements Clone?
when I do .clone() it still underlines it
do you really need to have a vector of owned window::droplet_window::glfw::Monitor?
or you just need the reference
Reference is fine
Lifetime issue
i was expecting it
you are dropping glfw before monitors
probably
no, connected_monitors is in clousure
i k but it makes it cleaner
wait
you are using monitor
but you never assign it
monitor without s
This might be helping
That's for later
Another way is I just spawn everything on the primary monitor
But that will make things very limiting
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
https://docs.rs/glfw/latest/glfw/struct.Glfw.html#method.with_primary_monitor
There is this method, for the primary monitor
A token from which to call various GLFW functions. It can be obtained by calling the init function. This cannot be sent to other tasks, and should only be initialized on the main platform thread. Whilst this might make performing some operations harder, this is to ensure thread safety is enforced statically.
i think the only way is only using monitors inside the clousure
its not about satisfying the compiler
its about dangling references
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
why do you need a vector of them?
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
i think saving monitors can result in errors, and maybe that is because you can
try
monitors = connected_monitors.to_vec();
what you want to index them?
I would use them into a struct called DropletDisplay
Where I can label them with names such as "Display1" (primary display)
and so on
then why you want to make a vector of monitors?
I meant monitor
looks like the library only wants to give you the monitors inside the function .with_connected_monitors
That's kinda shitty
Because I want to let people to select a monitor
where this opens
worry i want to help but i want to go to dinner
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
here its 22:33
Easier to get real time to you
Enjoy your dinner
@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
API documentation for the Rust glfwGetMonitors fn in crate glfw.
you can use this (like in C++)
but its unsafe (like in C++)
I decided on a better implementation in the future
for now I will just use primary monitor
anyways this works right?
The crate forbids it
as far as I know
Why this now...
Because the thing only has Windowed mode
and I will do something later
with Borderless
I will set decoration to false
oh ok srry unfinished code is confusing
It's finished in this match
I will be elaborated after making the window
because there is no other way.
How can I make a value leave a closure?
you can, when it leaves the clousure the value doesnt exist anymore
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
no
what
I set window_mode to FullScreen on monitor at &monitor
can I extend its lifetime?
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
When a value leaves scope, C doesn't let you compile
so when you set windows_mode
its not the same
wait
what C compiler are you using
clang (LLVM)
well no C will let you
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
The entire thing in new() ?
API documentation for the Rust glfwGetPrimaryMonitor fn in crate glfw.
Or the entire droplet_window.rs file ?
yes you probably dont want that
no sorry
in entire zone where you need it
but you can use the unsafe version too
So the entire thing in new okay
that will let you do it more idiomatic at your risk
(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
ye i recommend you safe
You probably understood what I am making when I shared my screen
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
.
Because it makes no sense to do so in a safe API
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
post the entire new func
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
dont change your plans
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
you will do it with borderless and bordered?
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...
which dude?
the one who made the rust wrapper
See the big Example letters?
That's written by him
anyways did you tried the unsafe one?
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
i want to help but i dont wanna ask for entire code
lol
LOL
are you making a OS?
yes
wow
FreeBSD based
good luck
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
how big is the code rn?
ok pass the entire code if you want and i will find the way
And I thought "best to start with the Windows, then Widgets"
I will commit to GitHub and send a link
I will do so on DM if you want
ok
I am going to commit this at its current version
Are you really interested in contributing?
or advise me when you upload
Just the toolkit
ok
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
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
how is the OS called?
Fluid
It will be an OS for phones, computers, tablets, TVs and even smartwatches/any wearables
wow that is impressive
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
by the name i can make assumptions about his appearance
But I like both
What do you imagine?
I have an unfinished basic concept
lightblue