GraphicsComplex[3D] using NumericArray is nonstandard afaics but NumpyArrayListExpr potentially fragile wrt performance
I don't understand what this means. git grep -n GraphicsComplex doesn't find anything.
git grep -n NumericArray doesn't find anything. I don't like to guess meaning.
good direction?
I've know for a long time that the builtin Compile[] was done totally boneheadedly and would have to be redone at some point, after we got a handle on enough of the underlying object system representation and how expressions are evaluated. Things aren't totally clean right now, but clean enough.
I thought it cool that you identified what I think is exactly the right Mathematica Builtin function that seems the more directly applicable for speeding up graphics.
AST?
AST here in my view is synomyous with S-expression (or more correctly M-expression). As best as I can tell, Mathematica is a Lisp-like functional system. Control flow constructs are functions the same as they are in Lisp. At its core, everything is a List or an Atom. (I believe this is Mathematica's terminology). But there is wiggle room for what an "Atom" can be. For example, I think an Atom could be a compiled object that embodies Lists or whatnot.
But again, I'm not sure I understand the question.
who?
Right now Mauricio Matera and I have largely been moving things forward. But my philosophy has always been that if someone else is willing to do the work and that person is competent (which just means doesn't leave a bigger mess for me to clean up afterwards), then I'd rather have someone else own and do the work.
testing?
Yes. Simple vague answer in, simpole vague answer out.
architecture ok?
I think so.
analgous to format, but data structure instead of string any value to merging with format?
Don't understand. In the past, the code base has suffered from trying to unify things which should not be unified. In my experience it is far easier to duplicated code and DRY (do not repeat yourself) afterwards, than unifying first into a more complex object, and often leaving someone else with the problem of how to separate entangled code.
There currently is entangled code that we haven't yet untangled yet.
Currently, I am not sure we have a good handle on format. Even that term is vague. Is this the stuff that comes after boxing? Here I think there is a high-level kind of format, and a low-level kind of format. High level right now for graphics objects that will eventually be PNG, SVG, GIF, Asymptote, might have some common graphics-render indepedent line, curve, dot, kind of thing.
I think this is one of those things like in music where fiddle players spend half their time tuning and the other half playing out of tune as opposed just start playing and if you feel you are constantly bening a note in a particular direction, then tune the string in that direction.
dash vs ipywidgets
Dunno
repository organization how to reuse across front-ends
Dunno.
There currently is https://github.com/Mathics3/Mathics3-notebook-frontends Please let me know to what extent it is relevant and useful and in which areas it is not.
But in many situations like this I try something small, see how it goes and so on. Just be mindful of not making decisions which might paint you into a corner.
how to package front-ends jupyter/jupyterlite packaging - kernel
I think mmatera and I definitely don't want to add more to mathics-core. mmatera doesn't like adding Python packaging dependencies like jupyter, and I agree here. For me it is also about its current size. At one point I think there might have been an idea that numpy, and sympy could be optional. Personally, I think we should assume they are in core (and mpmath too). I think I'm okay with scipy also being required although I don't think it is.
But jupyter is a bit too far in my opinion. A command-line interface doesn't require it. There is evidence that a number of people in fact used a command-line interface. I think you said you used it too. That is not even the fancier mathicsscript (which is a separate repository by the way).
how to use in shell front-end
Right now I think you use a session object that same way that many tests use.
need browser front-end given jupyter?
Dunno.
need GraphicsComplex for performance, but support across the board? with NumpyArrayListExpr or NumericArray?
boxing currently not standard
Boxing independent of any new work is already a mess. That was supposed to be our focus right now. Redoing the way boxing works to make it conform to Mathematica better and to fully separate Box evaluation from normal evaluation. There is this homegrown cache mechanism that should be removed that somehow is needed by Box evaluation (I think) for reasons I don't understand.
needs considerable build-out itself
No one ever said writing Mathematica would be easy.
how to test
That depends a lot on what is written
needs considerable build-out
Yep. There are two reasons I personally have been hesitating on this. First it's not a strength I have here. Second, I suspected that this was done wrong in the first place. Scaling up a bad implementation is a bad idea. (It's happened too often in the code and has personally created a lot of extra work for me and mmatera).
how to test deploy unconditionally or conditionally former requires support across the board
Having taken the big step to split what used to be one repository into 3 or 4, we have a lot of experience in adjusting CI testing when API's mismatch.
Working in git branches can ameliorate things. But as they say on the highway: Expect bumps ahead.
identify others that uses Graphics3D and build out
SparseArray, Vectors and Tensors probably would benefit from using numpy arrays.
GraphicsComplex needed? support across the board?
Dunno - play by ear.
non-standard ManipulateBox vs DynamicModule, Dymanic, Dynamic*Box, etc. other functions like Animate?
Dunno - play by ear?