DDraceNetwork - developer

Ryozuki 2023-10-06 06:13:24Z

morning

1

https://grugbrain.dev

Yes it’s old. Please compile it from source :)

Replying to @Yek-H I think it's very old

hi old im new

MilkeeyCat

ure making some cool ass 3d projects. heres my triangle on opengl owo

now do it in rust/wgpu

アリヂン

now do it in rust/wgpu

First i need to write it in c++ for uni pepeW

@Robyt3 but the code looks so ugly with composition xd If I revert it, does the the point accessor really need to be a member? It can just be local to the Eval function, since there is no point in using it anywhere else (or at least it is not yet) (edited)

It could be a private variable if it's only used in CEnvelope

09:08

I probably didn't want the variable to get created and destroyed every time so I made it a member variable instead

@Learath2 with shift ucan go faster

No shift on phon

oh xd

Robyt3

I probably didn't want the variable to get created and destroyed every time so I made it a member variable instead

Alright, just noticed I dont like the GetBezier function anyway (which is probably one of the reasons not to use inheritance). Next I will add an interface to CEnvelopePoint and then m_vPoints can probably be private too

1

@Robyt3 I wanted to combine all point implementations (envelope points, bezier control points, quad corners, quad centers, envelope quad centers). My plan was to use inheritance for that (ie have a CPoint class inheriting CEditorComponent with pure virtual methods like SnapToGrid or UpdatePosition, RenderPoint, ... and which handles the logic of calling these). Do you think inheritance is fine in that case?

marmare_314

@Robyt3 I wanted to combine all point implementations (envelope points, bezier control points, quad corners, quad centers, envelope quad centers). My plan was to use inheritance for that (ie have a CPoint class inheriting CEditorComponent with pure virtual methods like SnapToGrid or UpdatePosition, RenderPoint, ... and which handles the logic of calling these). Do you think inheritance is fine in that case?

The inheritance for points makes sense I guess, but conceptually it's a bit odd how CPoint would be a CEditorComponent

10:06

I wouldn't consider individual points "editor components"

Robyt3

I wouldn't consider individual points "editor components"

I guess the naming is not the best. I can maybe introduce another kind of "component" which doesnt have the subcomponent system. This could then be used as a base class instead. Not sure what to call it though

marmare_314

I guess the naming is not the best. I can maybe introduce another kind of "component" which doesnt have the subcomponent system. This could then be used as a base class instead. Not sure what to call it though

Maybe just CEditorComponentBase, it's also called CUIElementBase for the UI elements

Robyt3

Maybe just CEditorComponentBase, it's also called CUIElementBase for the UI elements

How about CEditorObject?

Seems good

Marmare314

[ddnet/ddnet] Pull request opened: #7306 store only pointer to editor in CEditorComponent

Checklist

[x] Tested the change ingame
[ ] Provided screenshots if it is a visual change
[ ] Tested in combination with possibly related configuration options
[ ] Written a unit test (especially base/) or added coverage to integration test
[ ] Considered possible null pointers and out of bounds array indexing
[ ] Changed no physics that affect existing maps
[ ] Tested the change with [ASan+UBSan or valgrind's memcheck](https://github.com/ddnet/ddnet/#using-ad...

Learath2

I used it for the lulz a couple times, but never for anything serious, I vaguely remember @heinrich5991 using it for more serious things

I use zfs almost exclusively everywhere

quite nice: better borrow checker coming, accepting more obviously correct code: https://blog.rust-lang.org/inside-rust/2023/10/06/polonius-update.html

Polonius update | Inside Rust Blog

Want to follow along with Rust development? Curious how you might get involved? Take a look!

github-merge-queue[bot]

[ddnet:master] 2 new commits

73914b3 store only pointer to editor in CEditorComponent - Marmare314 bdcf3e6 Merge pull request #7306 from Marmare314/component-single-member - def-

11:47

def-

[ddnet/ddnet] Pull request closed: #7306 store only pointer to editor in CEditorComponent

11:50

github-merge-queue[bot]

[ddnet:master] 9 new commits

1ccb83b make IEnvelopePointAccess destructor virtual - Marmare314 1bd3e65 extract CEnvelope into seperate header - Marmare314 073f208 split implementations from CEnvelope class - Marmare314 08b8254 use type enum in CEnvelope - Marmare314 283226e init member variables of CEnvelope on declaration - Marmare314 95528ca refactor CEnvelope::FindTopBottom - Marmare314 855ae88 make CEnvelope::Resort private - Marmare314 c2adfc5 make CEnvelope::m_PointsAccess private - Marmare314 48a92f1 Merge pull request #7303 from Marmare314/refactor-env-editor - Robyt3

11:50

Robyt3

[ddnet/ddnet] Pull request closed: #7303 Refactor CEnvelope class

Robyt3

[ddnet/ddnet] Pull request opened: #7307 Fix additional clang-tidy 16 errors, remove some obsolete suppressions

Fix additional clang-tidy errors that are found when running the current checks with clang-tidy 16. Remove some obsolete suppressions and fix the errors instead.

Checklist

[ ] Tested the change ingame
[ ] Provided screenshots if it is a visual change
[ ] Tested in combination with possibly related configuration options
[ ] Written a unit test (especially base/) or added coverage to integration test
[ ] Considered possible null pointers and out of bounds array indexin...

12:17

Marmare314

[ddnet/ddnet] Pull request opened: #7308 Add CEditorObject class

This class is slightly more light-weight than a CEditorComponent and its naming makes it more natural to inherit for envelope points, proof-mode positions etc.

Checklist

[x] Tested the change ingame
[ ] Provided screenshots if it is a visual change
[ ] Tested in combination with possibly related configuration options
[ ] Written a unit test (especially base/) or added coverage to integration test
[ ] Considered possible null pointers and out of bounds array in...

irc pinger wot

@deen since u do lot of testing at ur job, do u have a tool to split rust tests into multiple runners so they finish faster?

Ryozuki

@deen since u do lot of testing at ur job, do u have a tool to split rust tests into multiple runners so they finish faster?

Aren't rust tests already run in parallel?

Learath2

Aren't rust tests already run in parallel?

@Ryozuki sounded like he wants to split tests between machines

ye runners

13:00

horizontal scaling xd

13:01

ah

13:01

its called jobs

13:01

yeah split between jobs

Ryozuki

@deen since u do lot of testing at ur job, do u have a tool to split rust tests into multiple runners so they finish faster?

cargo-nextest

13:08

We use buildkite pipelines and I split the execution into multiple runners, see for example Miri test (which is using cargo-nextest) in https://buildkite.com/materialize/tests/builds/65368

13:09

Here is the logic for this: https://github.com/MaterializeInc/materialize/blob/c80c0c5aee34e5ebd9defcd26d8873b803a36d2b/ci/test/cargo-test-miri-fast.sh#L22-L26

ohh thanks

The trick is nextest's --partition "count:$PARTITION/$TOTAL" feature

can u do this with github actions?