Hi, I happen to have implemented an expression evaluator for a project I'm working on not too long ago. Here is a somewhat older WIP version: https://gist.github.com/sergof/6e6ebfa632d593ddd73801c10e5f822d
For x64 I generate machine code and use a VM for other targets, so on x64 it beats all the libraries in that benchmark :) So if you want to replace python for driver expressions I might be able to help out. Regards, Sergej. Am Montag, den 05.06.2017, 19:19 +1200 schrieb Joshua Leung: > Hi dima, > > Yep. That's what I just said we need in the long term :) > > Thanks for the link. Bookmarked for further investigation now, > > Cheers, > Joshua > > > On Mon, Jun 5, 2017 at 7:14 PM, dima glib <dima.g...@gmail.com> > wrote: > > > Did anyone consider having an independent math expression > > evaluation > > engine? (e.g. some library from > > https://github.com/ArashPartow/math-parser-benchmark-project) > > It could be added either as a separate driver type, or auto- > > detected based > > on whether a "pure-math" engine can compile a given expression. > > This would likely remove the need to enable scripting for 99% of > > driver > > use-cases. Would it be too complicated to implement? > > > > > > On Sun, Jun 4, 2017 at 2:58 PM, Joshua Leung <aligor...@gmail.com> > > wrote: > > > > > Hi, > > > > > > I agree that the current situation isn't great, and does need to > > > be > > > improved. > > > > > > However, IMO the proposed solution is not good either. > > > Specifically, as > > > presented, it does seem that to imply that that checkbox will > > > always get > > > shown. There are several issues with this: > > > 1) It is highly unlikely that you will want to disable the thing > > > again > > > > once > > > enabled. > > > 2) That setting applies to all scripts/settings, not just the > > > current > > > driver. It is therefore misleading to include it as a checkbox > > > there. > > > 3) When loading existing files (with the autorun setting > > > disabled), > > > > there's > > > the duplication that Sergey mentioned (i.e. info header + this > > > panel). > > > 4) IIRC, just putting the checkbox there isn't enough to get > > > everything > > > running properly for the current session only. > > > > > > ------- > > > > > > That said, when this autorun setting is disabled (via userpref or > > > commandline options), there *is* the annoying problem that newly > > > created > > > drivers cannot be run, with no obvious way to get them working. > > > This is a > > > usability issue. > > > > > > As a short-term compromise, I propose that beside/under the error > > > prompt, > > > we include the "Reload Trusted" operator button (shown in the > > > info header > > > when loading files when autorun is disabled). We'd have to prompt > > > the > > > > user > > > to save their work (or do it for them), and perhaps the label > > > would need > > > > to > > > be different (something like "Enable Python autorun"). > > > > > > ------ > > > > > > In the long-term though, IMO we really should look into building > > > our own > > > little "mini-Python interpreter" for interpreting driver > > > expressions. > > > Campbell's work with sandboxing the Py interpreter (e.g. by > > > whitelisting > > > bytecode opcodes) is a promising if fragile approach. However, it > > > doesn't > > > mitigate the multithreading problems with Python and the GIL > > > (i.e. there > > > can only be a single Py interpreter instance running/evaluating > > > code at > > > one). I know that Bassam and a few other riggers have been having > > > > problems > > > with some of their rigs running slowly (or even crashing) under > > > the new > > > depsgraph due to multiple pydrivers getting scheduled to run at > > > once, and > > > everything grinding to a halt as they're evaluated one by one. > > > Thus, by > > > building our own "driver expression interpreter" that only > > > handles the > > > subset of Python-like syntax actually needed to evaluate driver > > > expressions, we can solve both security + performance issues at > > > once. > > > > > > As a fallback, "full" Python evaluation can still occur if our > > > > interpreter > > > cannot handle a particular expression (i.e. the rigger tried to > > > access a > > > custom function, or tried to do something "fancy" with > > > indexing/attribute > > > access). That then would still required autorun to be enabled, > > > and would > > > still be subject to the GIL restrictions. However, since fewer > > > drivers > > > should now be affected by the Py bottleneck/limitation, it's > > > still a net > > > positive for users in general over the current situation. > > > > > > Regards, > > > Joshua > > > > > > > > > > > > > > > > > > On Sun, Jun 4, 2017 at 11:06 PM, Gaia Clary < > > > > gaia.cl...@machinimatrix.org> > > > wrote: > > > > > > > The current solution to this situation is also not a good idea > > > > i > > > > believe > > > :) > > > > > > > > However, isn't there a difference here between ? > > > > > > > > - a global definition in user preferences > > > > - a session related setting > > > > > > > > In that sense i believe my proposal is not that bad, as it > > > > allows to > > > > set the autorun option right on spot (where the drivers are > > > > defined) > > > > but only for the current session. And it avoids the display of > > > > an error > > > > and it seemsvery intuitive to me. > > > > > > > > Also i believe when there is a bad idea at all here, then it is > > > > to > > > > force > > > > the user to enable scripting when all they want is to use > > > > drivers. > > > > Of course i know Campbell has put some effort into this to see > > > > how > > > > python > > > > could be made more secure so that using it within drivers would > > > > no > > > > longer > > > > be a security problem, and "python in drivers" could be always > > > > enabled. > > > > But as far as i know there is no satisfying solution for this, > > > > so drivers still need to have auto run enabled. > > > > > > > > Anyways, it was just a proposal, if its not useful, then its ok > > > > for me. > > > > I asked at least :) > > > > > > > > cheers, > > > > Gaia > > > > > > > > On 04.06.2017 10:26, Sergey Sharybin wrote: > > > > > Hi, > > > > > > > > > > This isn't a good idea. You should not expose same user > > > > > setting all > > > > > > over > > > > > the interface. All those settings should be kept in a > > > > > centralized > > > > > > place. > > > > > > > > > > On Sun, Jun 4, 2017 at 1:04 AM, Aaron Carlisle < > > > > carlisle....@gmail.com > > > > > > > > > wrote: > > > > > > > > > > > I think it is a good idea, I also think that it would be > > > > > > fine to > > > > have > > > > this > > > > > > in 2.79. > > > > > > > > > > > > Aaron Carlisle > > > > > > > > > > > > Picture taker | Bit cruncher | Pixel pusher | Document > > > > > > writer | > > > > Artist > > > > > > Project administrator for the Blender 3D Documentation > > > > > > Project > > > > > > > > > > > > On Sat, Jun 3, 2017 at 1:04 PM, Gaia Clary < > > > > > > > > gaia.cl...@machinimatrix.org> > > > > > > wrote: > > > > > > > > > > > > > Hi; > > > > > > > > > > > > > > Assume you have disabled "Autorun Python Scripts" by > > > > > > > default. > > > > > > > Now add a new driver and step into the graph editor to > > > > > > > edit > > > > > > > the Driver python expression. > > > > > > > > > > > > > > Currently you will see an error text in the panel. > > > > > > > But what about a change like in the image here: > > > > > > > > > > > > > > http://pasteall.org/pic/show.php?id=116080 > > > > > > > > > > > > > > If this is an acceptable improvement, is that something > > > > > > > that > > > > > > > could possibly already go into Blender 2.79 or would that > > > > > > > be only > > > > > > > good for Blender 2.8 ? > > > > > > > > > > > > > > cheers, > > > > > > > Gaia > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Bf-committers mailing list > > > > > > > Bf-committers@blender.org > > > > > > > https://lists.blender.org/mailman/listinfo/bf-committers > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Bf-committers mailing list > > > > > > Bf-committers@blender.org > > > > > > https://lists.blender.org/mailman/listinfo/bf-committers > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Bf-committers mailing list > > > > Bf-committers@blender.org > > > > https://lists.blender.org/mailman/listinfo/bf-committers > > > > > > > > > > _______________________________________________ > > > Bf-committers mailing list > > > Bf-committers@blender.org > > > https://lists.blender.org/mailman/listinfo/bf-committers > > > > > > > _______________________________________________ > > Bf-committers mailing list > > Bf-committers@blender.org > > https://lists.blender.org/mailman/listinfo/bf-committers > > > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > https://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list Bf-committers@blender.org https://lists.blender.org/mailman/listinfo/bf-committers