Can someone test if SystemDialogInput["FileOpen", "test*.nb"] allows you to restrict the dialog to only files which start with "test" and end with ".nb" (use whatever strings make sense for you)
@Kuba I wonder does it make sense to have a flag that's similar but still allows people to answer.
For instance a working answer to that would only take a few minutes to put together and could be a teaching moment, but at the same time I wouldn't want to put that question at the same level as a really interesting and detailed question
and there are clearly things the OP could do to fix the question in that case :)
@CarlLange I hardly ever close off topic questions that have an upvoted answer so you can be quick, ask mods to reopen, edit the question to put it on reopen review queue.
> [...] Mathematica (which I have used ever since it was first released) can no longer claim monopoly on having simple and elegant tools to explore mathematics and demonstrate concepts. [...]
@b3m2a1 No way to filter this way also. Strange thing, if I remove the dot in "test*.nb" so it becomes "test*nb", then it crashes the whole session (FE+Kernel) !
@b3m2a1 Can you help me figure out what the doc centre toolbar is made of? It's ``DockedCells -> FEPrivate`FrontEndResource["FEExpressions", "HelpViewerToolbar"]``. How do I get the source of that front end resource?
I did this before and I forgot.
I am simply looking to programmatically trigger the Reload button.
I have a grid of coordinates as a nested array, e.g. as comes out of CoordinateBoundsArray. I'd like to take some slice of this array, so take, say, the 5th array and then drop the first element from each coordinate. This is what I currently have:
Is it possible to do this faster? Cleaner isn't a worry for me right now, as this is package code that just needs to work well, but not really be read by other people.
@rhennigan I get that and it's a convenient box structure to have around if you're working with resource functions. You could always package that thing up as a TemplateBox to embed in the ResourceSystemClient and then provide some access mechanism through that.
Presumably they can also attach autocompletion to ResourceFunction directly, too, by using the standard FEPrivate mechanism.
@rhennigan can you comment on the general turn around for function submission to publication or for hosting these things outside of the cloud? I know you're not explicitly on this, but you seem to have used it.
One use can for this I can see is as a supplement for my current process of putting my functions on GitHub
@rhennigan Never submitted anything to either it or the data one. I'll try to add some stuff some day, but for the most part I prefer to make packages instead of functions and so the idea of just giving a single standalone function without easy access to the rest of the code is a little weird to me.
The paclet repository, on the other hand, is something I'd submit to day one (or in the beta if there is one).
I don't think it's documented yet, but you can use "DefinitionNotebook" as the second argument to ResourceFunction to view code. Example: ResourceFunction["CheckMatch", "DefinitionNotebook"]
@rhennigan that's how I was looking at yours, but that's still not...great. What I mean is it's useful to be able to use package functions too. Like I define function Pkg`A as my main package function but to do that I write lower-level but still useful functions Pkg`Package`a1, Pkg`Package`a2, ... and those functions a1, a2, can be incredibly handy if A isn't quite what you need but you want to do something like it.
And the thought of making every single one of those functions a ResourceFunction and duplicating all the requisite code for all of them hurts me physically.
It's just disaster after disaster waiting to happen.
I think the appeal is the ease of distributing to others. All the functions I've written that I use regularly are sitting in autoloading paclets, but that's not something I can quickly (or easily) give to a beginner user for them to use.
@rhennigan I get that, although for that purpose I'd just use GitHub and Get. I can do more faster and more flexibly with GitHub than ResourceFunction.
@rhennigan I do appreciate all the work WRI has put into the function repo and I'm sure it serves its purpose well. Its purpose just isn't the one I care about.
I personally think the function repo could be uniquely useful in a stack exchange context. Quite often answers to questions are single functions that can be useful in many cases.
And instead of copying and pasting those functions from notebook to notebook, having one place to store them (where they might be improved in future etc) could be handy.
For instance, I have some code to parse well-known-text gis data. I copy and paste that between dozens of notebooks before I can start doing any work. If I could do {ImportWKTString,ExportWKTString} = ResouceFunction["csl/wkt"] that would be less copy-pasting, at least :)
and others could discover and use it, without me having to do any real work
and if a question such as "How do I use WKT data in Mathematica" shows up, I can simply refer to the function repo page.
This is all hypothetical, I haven't actually used it yet. Just my 2c
(I'm extrapolating, I don't know if I can do two functions in one ResourceFunction or anything. I also only have ParseWKT, not exportwkt, but it's a formality)
@CarlLange 99% functions here are only the guts. They need error handling and polished definitions etc. They are not production ready, which is fine because it is not the point. If you are fine with that that also means FunRepo can fit you needs which is fine too. It just does not fit mine or @b3m2a1 's.
Paclet repository should exist and I can make use of it. But I wouldn't say I care, I learned to live with GitHub, PackageData.net etc What I need is a set of standard developer tools, robust, cross version compatible, not spread around on WWB MMA GitHub but in one place. Documentation of PacletManager, Internal and other heavily used contexts. Not to mention modern workflows to manage versioned dependencies etc.
I also understand that not everyone needs them but I am not sure current attitude towards serious WL users pays off.
