Friday, May 15, 2015

Re: performance test on sourcing 6800 entries menu vimfile

On Wednesday, May 13, 2015 at 9:00:46 PM UTC+1, ZyX wrote:
> 2015-05-13 19:20 GMT+03:00 Ni Va <nivaemail@gmail.com>:
> > Maybe it's when you have to launch several system or others own commands in an independant way on more than 300 machines (XP, Seven and physical or virtual).
> >
> > Total of all these commands (~20) by 300 machines let you understand that I effectively need to launch independantly command of my choice on one machine or a group of machines.
> >
> > It's not a usual case!
> >
> > commands : (SYS : reboot, shutdown, diskpart, NTP resynch, MSTSC or vmware cmds).
>
> I would rather suggest writing ~20 (or one with three arguments) user
> commands which will accept machine identifier (it does not have to be
> TARGETMACHINEDNSNAME, but it has to be unique) if you need to do this
> from Vim.
>
> And for each of the commands write custom completer, this is rather simple.
>
> As the result you will have a simple function (1 line of code if you
> want to write ~20 user commands and have usual Vim simple prefix
> completion, ~5 if you want to have 1 command), a list of command
> definitions (depending on whether you will have 1 user command or ~20
> this will either be a sequence of :command calls (second case) or one
> :command call and some data structure holding ~20 other commands) and
> a list of machines. Parsing this is *far* faster and you can even
> fetch a list of machines at request (i.e. when you trigger completion)
> from an external file making startup even faster (I do not think you
> will need this).
>
> I see why you think you need such menus. But I can't believe this can
> be efficient.
>
> >
> > --
> > --
> > You received this message from the "vim_use" maillist.
> > Do not top-post! Type your reply below the text you are replying to.
> > For more information, visit http://www.vim.org/maillist.php
> >
> > ---
> > You received this message because you are subscribed to the Google Groups "vim_use" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.

Hi ZyX,

Menus are easier way to non vim users.
Commmand idea is better for me. I join to you the vimscript I wrote that build menu by looping around Dict script entries and treat each function to add to menu entry.

You can see in "Object public methods" that functions' most of part have only machinename in parameter. But you see too that some functions need more than machinename parameter as mstsc that need to know if it take the distant machine in span mode or not.
Regarding all functions exposed :
- some functions need only machinename on which command will execute through psexec
- some functions need machinename + process to kill/run
- one function need machinename + flag like /span flag to Rdp Mstsc control.

First point, I think I can apply commands following your guide lines starting from this vimscript but I would have expert eye to tell me if base script is well structured.

Second point, I am not familiar to commands to see how coding one command to call my existing funcs but see it is more efficient than menu.

Can you just looking at my script and tell me how rewriting it to ensure your commands concept?

s:listofmachine : Dictionnaries of machines

class xmenu#facilities() defines
inner variables as functions~capabilities given on each machine.
inner methods : launching psexec command onto target machine, confirm dialog
public methods : rdp, kill run process, mstsc etc...
building menu by writing 6000 amenu lines and sourcing it

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment