Thanks for reaching out. Our events team will contact to get size and shipping details. Congratulations again. Also, I actually used some of your code to beat information from our knowledge base in one of my WFR examples.

The winners are now announced in the top head post. Congratulations to all winnders! And deepest thanks to all who has taken a part in this event!

@Daniel Lichtblau I love the idea of the function repository to facilitate sharing functions. The above thread helped answer a question I had about how non-public helper functions are treated (and how they don't contaminate the users namespace)

My question for you is: What's the best way of distributing a set of closely related functions all of them drawing on a core of helper functions (and each other)? Can these multiple public functions be part of a single Wolfram repository "function"? I've developed a set of functions for doing Huckel calculations and visualizations on Molecule[]s, and had originally planned to disseminate it in the WFR, which would make it easy for students and teachers. There are about 6 public functions; since they are all highly related and rely on a shared core, breaking it up into separate WFR entries seemed undesirable. What's your recommendation? .

What's the best way of distributing a set of closely related functions all of them drawing on a core of helper functions (and each other)?

I think that the only good answer to this is that the functions should go into a package. I would not use the function repository.

You can publish a package now, without waiting for a package repository. An official Wolfram package repository is not a prerequisite (although it would be useful for the community as it would facilitate the adoption of packages). People have been writing packages for Mathematica since the system was first released.

I am concerned about the future of packages (and the planned package repository) because I repeatedly see people express the opinion that "the function repository is sufficient", when someone writes some useful code that "you should submit it to the function repository", or simply not even realizing the huge difference between these concepts, and that the more valuable some work is the less likely it is that it is suitable for the function repository.

I do not see how Mathematica could compete with other systems without any well supported facilities to create packages, and I am puzzled about why this is not prioritized over things like the function repo which is just not an alternative.

The remarks by @SzabolcsHorvat and @J.M. about package vs individual function construction are all valid of course. I will point out that there is an intermediate path that is, in some cases, also viable. One can use a "container" function and support different operations therein. (I believe this is a subset of what goes as Object Oriented Programming, but I predate OOP so I'm not really certain). One example of what I have in mind is the WFR entry "ExpressionBag" by Richard Hennigan.

https://resources.wolframcloud.com/FunctionRepository/resources/ExpressionBag

This really only applies in cases where it makes sense to have a single "function" supporting multiple operations. Implementation of specific data structures is one area where this use case might be common. If time permits I might post a related example to Community.

Anton,

This might be a bug you are reporting, but...how is it relevant to this particular thread? Assuming it is, please edit to make that connection clear.

I'm not sure if it was this comment or another comment where the issue with PackageData's URL size limit was raised. In any case, I'm sorry about that! I've now fixed it.

We have had quite the Sprint. All told, we received (I think) more than 100 submissions during the Sprint submission period*. As a result the reviewers are somewhat submerged (glug), which I guess counts as a big success. We are now holding a review session every working day. It looks like we will get most of the submissions reviewed, and nearly all of the exceptions will be from in-house authors.

Now for some remarks.

(1) I thank all participants. We've at this point published more than half of the received submissions and are happy to see that overall quality is high.

(2) We are recognizing a number of pain points for authors, from formatting issues to problems with resubmission. We hope to clarify many of these obscure details going forward.

(3) There will be a Wolfram Function Repository talk/meet-up at the upcoming Wolfram Tech Conference. In addition to discussing some of the problematic aspects to authoring WFR content, we will make time to get feedback from attendees. While we have been made aware of several trouble spots, I'm sure there are more out there.

(4) For those not attending, feel free to send remarks in responses to this thread. No need to mention the fact that the Cloud submission is not working, it's already in here.

(5) For those who have submissions that are not yet reviewed, my apologies. We try to prioritize based on whether an author is new or relatively new. And some take a long time to edit; when pressed for time, we have to defer on such submissions. We thank you for your patience in any case.

Again, our thanks to those of you who participated. And my thanks to the extremely busy review team members.

• I did not actually count them. I am dimly aware this could be done programatically.

I forgot to add:

• Search in Mathematica includes WFR functions. Especially when the built-in search has no hits, it could look at WFR
• F1/(Cmd+shift+f) with an orange pill selected leads to doc page. (I see tooltip already works in 12.1 beta: great!)

How are submissions handled that require (minor) changes before being accepted? (I'm asking since it looks like re-submitting creates a new submission for the current date, instead of updating the old one)

Great idea!

I asked and was informed that the Cloud platform does not yet support WFR submissions. Sorry about that. If you have actual notebooks you can send them to us (or to me directly, if you like).

@Alexey Popkov,

You are absolutely correct. Indeed, we vastly prefer that helper functions not be nested inside the main function.

Also there is no need to make it a Wolfram Language package. So you could simply use the code between but not including the Begin["Private"] and End[].

Actually it all goes into some cell context, so they should not appear in the users name space(s).

As for whether it is possible anyway to keep a submission in Package form, off the top of my head I'm not sure if that is supported by the WFR infrastructure. I guess you could try it, and add a note to the Author notes to let the review team know it's your preference. If we decide it might not work we can just strip off the packaging part in the review process.

We look forward to the submissions (I write this as we are doing a WFR review meeting).

No need to do anything special. Just send submissions in the time frame. As for the Most Prolific category, prior work of course already counts.

Note to others: Sander is among the more prolific of external contributors (and has a number of excellent published functions). But to reiterate, most awards apply to the submission time frame, where it's a clean slate going in.