On 10/16/2011 4:42 PM, Thomas Powderly wrote: > Kent, > > On Sat, Oct 15, 2011 at 10:12 PM, Kent A. Reed<knbr...@erols.com> wrote: >> ... >> I have spent some of my copious free time (which is actually almost no >> time for reasons I won't go into here) seeing how far I had to go to >> create easier-to-understand visualizations of EMC2 configurations. I'm >> not done but I figured I should show my hand. >> >> You can see what I'm up to at >> https://sites.google.com/site/manisbutareed (I apologize for the >> small-ish images. As soon as I figure out how to implement "click to >> enlarge" on a Google site, I'll do it.) >> >> ... > nice work > i tried same in gEDA > some things for thought > > user may want to hilight a signal and see where it goes > > schematics may get quite large and need 'sheets' ( sub-schematics ), > this necessitates 'off-schema signals' ( like 'continued on page 12a') > > hal files may be hierarchical or sequential in the ini ( like includes > or multiply sequential entries ) > > the ability to move elements would be tricky in html, so a 'frozen' > schematic may be a difficulty/expectation for some > > the library of elements (widgets/comps ) needs an editor > > bi-direction... the ability to start with text or graphs and create the other > > the ability to attach to threads ( micges& i created thread widgets > with prioritized pins ) > > the setting of constants > > your work with graphviz/dotty is nice, thanks! > > regards > TomP > Tom:
Thanks for your observations. gEDA was a suite of tools I looked at several years ago but for the reasons I gave on my website I chose not to go that route. Your comments about breaking large models into sheets reminds me of large data-model work I did in the past. None of the existing tools was very easy to use. Most of your comments have to do with using a graphical tool for design and maintenance of an EMC2 configuration. I both agree with them and reiterate that I don't want to go there. I had too much experience dealing with large, multi-sheet graphical models of data when I was still gainfully employed. None of the tools we had available for generating these models were very comfortable and they were hopeless at modifying an existing one. Bi-directional tools remain the dream rather than the reality. Your comment about hal files possibly being hierarchical or sequential is spot on. Handling multiple .hal files would be a trivial extension of my current script (love that Python!). When I first wrote down what I thought would be a useful set of program options, one option was to accept an .ini file as the defining entity and let it pull in all relevant .hal files (handling variable substitution of course). I haven't gotten around to it. To be honest, once I started extracting configurations from running EMC2 I didn't feel the need since EMC2 has already done the work for me. I have thought briefly about dealing with other aspects of the EMC2 configuration such as threads and parameters but so far my ideas have been very pedestrian. Regards, Kent ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
