upgrade changed struct fields, cvt values, use NT for field_info

[zot]

Fixes #40

This PR removes / adds / converts fields in existing structs when the struct definition changes. It does this by

1. Changing properties to be a ref so it can be reassigned
2. Removing the NT type parameter so that assigning a new properties NT can work
3. Adding info to each proto struct that tracks the current shape, world counter, and type params at creation time
4. Placing an updateproto call at the top of the generated methods to check for updates based on the world field

Also, this adds type conversion to the generated constructors.

[zot]

Hmm -- slight change to the type handling. Will push shortly...

Also need to add some updating test cases

[codecov]

Codecov Report

Attention: Patch coverage is 88.59060% with 17 lines in your changes missing coverage. Please review.

Project coverage is 88.13%. Comparing base (df875e2) to head (a3fa771).
Report is 5 commits behind head on master.

Files	Patch %	Lines
src/ProtoStruct.jl	88.59%	17 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master      #41      +/-   ##
==========================================
- Coverage   97.50%   88.13%   -9.37%     
==========================================
  Files           2        2              
  Lines         120      236     +116     
==========================================
+ Hits          117      208      +91     
- Misses          3       28      +25     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[zot]

Not sure why the nightly version of Julia makes so many methods with the same signature but it's the only oddball. I cased-out those method checks for 1.11.

[BeastyBlacksmith]

Can you check what the performance implication of this are? Doing an update before every operation seems quite costly to me.

[zot]

Update just indirects through a ref, does a Dict lookup, and compares ints to check for changes and proceeds of there are none. I'm happy to reduce overhead by using a shared ref for each struct's world counter if you would prefer. That would remove the Dict lookup.

…

On Thu, Jul 18, 2024, 6:47 AM Simon Christ ***@***.***> wrote: Can you check what the performance implication of this are? Doing an update before every operation seems quite costly to me. — Reply to this email directly, view it on GitHub <#41 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAGQKNISL4G6INIZMFC54LZM6MNBAVCNFSM6AAAAABK7XLATOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZWGE4TQMJXGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[BeastyBlacksmith]

Its really hard to make a judgement without having some numbers to compare

[zot]

Honestly I didn't really consider performance because I imagined using @proto for prototyping and changing code, not for production.

Since it's a concern I think I'll make it an option. I can add something like @dynproto (for dyamic) and factor the macro a bit so it can be part of the package and benefit from code improvements but it won't change what @proto does.

[BeastyBlacksmith]

I imagined using @proto for prototyping and changing code, not for production.

Thats true and its fine to be slower than normal structs, my concern is just to not make code using ProtoStructs unreasonable slow, at some point you wouldn't use it otherwise.

[zot]

Well, a friend mentioned that since people use Julia for intense computation like solvers, a significant slowdown during prototyping might have a large impact as well. Since I changed the structs to morph, they're no longer type stable and that could seriously impact tight loop performance -- I had to remove the NT from the type parameters.

So I think it's better just to keep @proto behaving as-is (with the type conversion fix) add another macro, like @dynproto, factoring out common code from the implementation of @proto.

If someone only wants to use @dynproto, they can even import it as @proto if they want to.