New package: TestNoAllocations v0.1.0

[JuliaRegistrator]

• Registering package: TestNoAllocations
• Repository: https://github.com/BloodWorkXGaming/TestNoAllocations.jl
• Created by: @BloodWorkXGaming
• Version: v0.1.0
• Commit: b8ec97f99f22c5ea19ad0bbc8d5314f47fac690c
• Git reference: HEAD
• Description: Simple Helper Macro to test for no allocations in Unit Tests
• Release notes:

Initial release

[github-actions]

Your new package pull request met all of the guidelines for auto-merging and is scheduled to be merged when the mandatory waiting period (3 days) has elapsed.

Since you are registering a new package, please make sure that you have read the package naming guidelines: https://julialang.github.io/Pkg.jl/dev/creating-packages/#Package-naming-guidelines-1

---

If you want to prevent this pull request from being auto-merged, simply leave a comment. If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment. You can edit blocking comments, adding [noblock] to them in order to unblock auto-merging.

[PallHaraldsson]

[noblock] EDIT: added this, see comment below.
Blocking for now. It's still great to see this!

I haven't had time to look at the package, I assume it does as intended just test.

I was thinking Dlang has @no_gc annotations, that blocks allocations; could you easily rather make sure that doesn't happen? It's nontrivial possibly, since it also means that you can only call such functions, i.e. those that at similarly annotated or I think if the compiler can proof no allocations.

And this is recursive. This is a functionality you may want to have or both, and then the name isn't the best.

If I don't see an answer here soon, I think I will unblock my comment. Your package would be registered today, maybe even soon? So sorry about blocking, I just think it's inconvenient to rename, or rather more so after registration...

[BloodWorkXGaming]

[noblock] Having a no_gc annotation would be really awesome, but only if it doesn't affect the performance. Could be possible with metaprogramming, however then it would still affect the first time till it runs once, if I am not mistaking.
Recursively checking for an @no_gc annotation would be easier, would however limit the possible function calls quite a bit, as it's not possible to annotate every non-allocating function.

While these are desirable features, am not too sure what would be the best way to approach it. I am open to idea's tho :)

[PallHaraldsson]

[noblock]
I think I have an idea how to implement this (and no performance downside, no allocations; note also the awesome Bumper.jl), basically if a macro would rename my_function to _no_gc_my_function, and all its calls would be be changed to call functions with a prefix _no_go (there are more details). Since I have gotten in touch with you I'm unblocking the registration.

I need to run now, I can drop by your issue page, likely tomorrow to explain. If you really want to go through with registering this package, then you need to add [noblock] too to your comment here. I only blocked to get your attention. But then you're stuck with the name, so you may want to consider that. People can still add your unregistered package with ]add http://...

I do not really want to block you, i.e. get in your way, what you want to do, so I'm sorry for causing the minor delay if you go through with registering.

[BloodWorkXGaming]

[noblock]
Thanks for the insights and the tip for the Bumper.jl package, looks very awesome!
I would be happy if you drop more informations at my issue page, thanks!

As I don't need this package for any time critical project I am leaving it on blocked for now, till I decide to go further with it.
However I am currently not sure, whether the suggested changes by you aren't worthy of it's own package.
Especially considering the desire to have light dependency, which focuses on one thing (testing or disabling allocations outright).

But that being that, thank you for your help :)

[github-actions]

This pull request has been inactive for 30 days and will be automatically closed 7 days from now. If this pull request should not be closed, please either (1) fix the AutoMerge issues and re-trigger Registrator, which will automatically update the pull request, or (2) post a comment explaining why you would like this pull request to be manually merged. [noblock]

[PallHaraldsson]

[noblock]
Hi @BloodWorkXGaming if you want a light dependency, not with my suggested change, then that's fine.

I didn't block your package getting merged, you did by not including [noblock], but I can still drop on your page and discuss, I just forgot. There's not really any problem having your package, and then another BlockAllocations.jl or something like that. It's probably not to hard to make such, if your functions are concretely typed. When they are not, your code is generic, it might be really hard, e.g. code for Floats might be ok, but if you call with BigFloat then you should expect allocations, and I don't see a good way around that...

[BloodWorkXGaming]

[noblock]

Hi @PallHaraldsson thanks for the headsup. No worries, I know you didn't block it, had very little time to work on it myself, which is why I hadn't unblocked it myself.

if you still up for it, I'd be happy to hear your thoughts on this topic on my page :)

[PallHaraldsson]

Hi @BloodWorkXGaming I meant to drop by and discuss, but here is a similar new registered package, I think with all I proposed (and overlap with your package, or making it redundant?):

#95540

[BloodWorkXGaming]

Hey, thanks for the update! That seems like a very promising package!
And you are indeed correct, it might make my package redundant, incase the limitations are lifted (allocation on call). Till then I see it as an addon, like compile checks and runtime checks.

But I will continue to monitor the other package and I am happy that such a package exists in a more official group! :)

Thanks!