by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jun 24 12:06
    poconn commented #101
  • Jun 24 11:59
    leudz commented #101
  • Jun 24 11:50
    poconn commented #101
  • Jun 24 11:43
    leudz commented #101
  • Jun 24 11:33
    poconn commented #101
  • Jun 24 10:55
    leudz commented #101
  • Jun 24 10:17
    poconn opened #101
  • Jun 19 16:58
    leudz closed #78
  • Jun 18 01:48
    leudz commented #96
  • Jun 18 00:09
    zicklag commented #96
  • Jun 17 23:12
    leudz commented #96
  • Jun 17 22:35
    zicklag commented #96
  • Jun 17 22:35
    zicklag commented #96
  • Jun 17 22:34
    zicklag commented #96
  • Jun 17 22:14
    leudz commented #96
  • Jun 14 17:22
    zicklag commented #96
  • Jun 13 03:30
    zicklag commented #96
  • Jun 12 13:49
    zicklag commented #96
  • Jun 12 13:46
    zicklag synchronize #99
  • Jun 12 07:01
    leudz commented #96
eldyer
@eldyer
of course that's not needed
Dylan Ancel
@leudz

that felt peculiar ^^

also for this:

world.run::<(EntitiesMut, &mut Parent, &mut Child, &mut usize), _, _>(|data| {
        let (mut views, mut value) = ((data.0, data.1, data.2), data.3);

        ...
});

you can apply the same thing as @dakom earlier:

world.run::<((EntitiesMut, &mut Parent, &mut Child), &mut usize), _, _>(|(mut views, mut value)| {
    ...
});

no need to re-bind

eldyer
@eldyer
:+1:
Dylan Ancel
@leudz
but while we're speaking about it, partial storage sorting is in theory possible
eldyer
@eldyer
oh!
ah, I remember why I used collect
    fn remove(&mut self, id: EntityId) {
        self.detach(id);
        for child_id in (&self.1, &self.2).children(id) {
            self.detach(child_id);
        }
        Remove::<(Parent,)>::remove(&mut self.1, id).0;
    }
this doesn't work because detach borrows mutable and the iterator has already immutably borrowed self
Dylan Ancel
@leudz
of course! yep I'm dumb, will have to wait for the function that allow remove while iterating to not collect
Dylan Ancel
@leudz

I also wanted to speak about views

what I showed yesterday the "new views" (View(Ref<Storage>)) will very likely not be called views

a view will be a fixed window into a storage (currently the mutable one isn't fixed, it can grow), this window could be the whole storage or smaller

while the "new views" will need another name like Borrow

we need both for inserted(_mut) and co. for example - it's not possible to insert into the returned type (it could be in the middle of the storage) but we want to be able to iterate on it

eldyer
@eldyer
maybe Slice?
or Window
difficult to find an apt name for that
Dylan Ancel
@leudz
Window for the "old" views and View for the new one is fine by me
eldyer
@eldyer
okay!
eldyer
@eldyer
with specs I often stored system specific data in the system struct itself, which then could be setup with the system's constructor. In shipyard I'm using Unique components instead for this. I wonder if something like this would be possible to make it a bit more convenient:
#[system_setup(InAcid)]
fn setup(world: &World) {
    // add system specific stuff to the world (e.g. a unique support component)
}
this would then be called when adding the system to the workload
Dylan Ancel
@leudz

since you can have the same system used in multiple workloads or even multiple times in the same workload you probably don't want to add a unique component in there if it's called each time it's added

maybe a World::setup_systems that go through all of them and call the method?

there's also the function that tries the systems borrows, it could double duty

I'm not sure how it would be implemented though, specialization might be required to keep it exactly like currently, I'll have to try a few approaches

eldyer
@eldyer
sounds complicated... and I'm not sure it would be really worth it
Dylan Ancel
@leudz

if the setup is next to the system it seems useful

this is what I'd like:

#[system(InAcid)]
#[with_setup]
fn setup(/*borrow what you want*/) { ... }
fn run(/*borrow what you want*/) { ... }

but I'm pretty sure it's not possible, this might be:

#[system(InAcid)]
#[with_setup]
fn run(/*borrow what you want*/) {
    fn setup(/*borrow what you want*/) { ... }

    ...
}

but it's a bit ugly, so maybe change the whole thing:

#[system]
#[with_setup]
impl InAcid {
    fn setup(/*borrow what you want*/) { ... }
    fn run(/*borrow what you want*/) { ... }
}

what do you think?

Dylan Ancel
@leudz
this is great
eldyer
@eldyer
WOW that's great with those panic messages!
phew I have to think about the syntax... the last one seems plausible, on the other hand we'd give up the nice free standing function syntax
eldyer
@eldyer
"borrow what you want" for setup is nice btw.
or maybe leave the normal systems syntax as it is now, just change it for systems with setup to:
#[system_with_setup]
impl InAcid {
    fn setup(/*borrow what you want*/) { ... }
    fn run(/*borrow what you want*/) { ... }
}
Dylan Ancel
@leudz
I was writing we could do this xD
eldyer
@eldyer
hahah LOL
Dylan Ancel
@leudz
interesting, !Send and !Sync are not possible as is with no_std
Dylan Ancel
@leudz
btw there is Index<EntityId> implemented for SparseSet so view[entity] will be possible instead of view.get(entity).unwrap()
eldyer
@eldyer
nice!
Dylan Ancel
@leudz

the library team has announced they're moving to zulip to join the compiler and language teams (in this post)

while Shipyard isn't as big (by far) and doesn't have the same needs, using the same platform as at least part of the ecosystem would be cool

gitter has some shortcomings, on the web and desktop it's manly the lack of image "recognition", not a big problem but we're in 2020 now, it would be nice to have chat a bit more evolved than the ones from 20 years ago

on mobile it's worst, sometimes the refresh works, sometimes it doesn't so I most of the time close the app to reopen it, there's no way to edit a message, has to go to the web version, open it as desktop and make the edit... and I can't go to the next line, currently I write in my "note app" and copy/paste, that's not what I'd call ideal

I know zulip has threading, we don't really need it for know and maybe ever? (EnTT can live without it), I'm curious to know how it handles the problems I mentioned above

do you a feature you'd really like?

eldyer
@eldyer
I agree that we don't really need threading
yeah we should try zulip IMO
view[entity] would be borrowed only immutably, right? so for mutable access you still have to use (&mut view).get(entity).unwrap()?
Dylan Ancel
@leudz
it'd do both, like for Vec it'll depend on what you do with the value
eldyer
@eldyer
cool :+1:
eldyer
@eldyer
chapter 2.9 "Systems" could be renamed into "Systems and Workloads" (I was looking for workloads in the ToC, but didn't find anything)
eldyer
@eldyer
how about this syntax for systems with setup (to make it a bit more similar to the one without setup):
#[system_with_setup(InAcid)]
{
    fn run(/*borrows*/) { ... }
    fn setup(/*setup borrows*/) { ... }
}
Dylan Ancel
@leudz

for the chapter: good idea!

for the macro AFAIK it's not possible, attribute macro have to be on a lang item, for the simple macro it's on a function, for multiple functions we could use a trait definition, a struct, an enum, a module, the best I could find is an impl block - you can check the list here

Dylan Ancel
@leudz

I downloaded the zulip app - multi-lines on mobile!!!

the threading thing seems to be something you can't live without once you tasted it so we'll see

I'm going to set everything up in a few hours and we'll try it out

eldyer
@eldyer
okay great!
you're right an impl block seems the best one out of that list
Dylan Ancel
@leudz

you can join the zulip with this link, I'm adding github integration but the chat exists

just a small note: your "full name" is your public username if it comes up

eldyer
@eldyer
do you see my test msgs?
Dylan Ancel
@leudz
yep just switching to my laptop =)
David Komer
@dakom
oh switching to zulip? I've been away a bit... will try it out later :)
Dylan Ancel
@leudz
yep, it's promising so far =)