On Sat, 18 Nov 2017 23:21:11 +0000 Peter Flynn <pe...@silmaril.ie> said:
> On 18/11/17 23:02, Conrad Knight wrote: > > Hi, > > > > How do i read/edit E's *.cfg files? > > E has always worked so well I've never needed even to think about this, > so I just went and had a look. That's how it's meant to be... :) > OMG they're binary files. Good grief. Is this for speed or some other > reason. I'm probably showing my age, but I would have picked a > human-readable format myself... 1. Speed. 2. Code re-use (we already have binary for our theme files etc.) 3. Ease of use from code (far less code). 4. Reliability (The code re-used is tested and used a LOT). 5. Size (they are compressed) We have an entire library devoted to the task of data storage and retrieval. It's name is eet. It handles files like zip files with multiple "keys" and blobs of data per key. Ask yourself the question - why do people use Mysql or Postgres or Oracle instead of just writing everything into big flat text files? Those database files are big binaries! Similar answers here. Enlightenment is continually writing out config AND state to these files. All those remembers you set up - if you modify the window (e.g. move or resize it) E is quietly writing out the remembered state in the background so it's stored for next time. Every time you run something in E to the exehist.cfg file. (This is was used by the exebuf launcher module to give better launch results by sorting by what you used more often and/or more recently - Everything doesn't seem to use it, but maintains a cache cfg file of it's own though). If you decompressed those config files, they'd be 3-5 times the size. E also keeps 9 backups of your cfg files just in case (the last 9 versions), so it can go back to an older one were things to go bad. My core e cfg file is 56k. extracting the config as text makes it 372k. That's 6.6 times more space. Multiply that extra space by 10 for the backups. Everything's exebuf cache is 144k as a cfg file, 508k extracted as text. 3.5x bigger. Exehist is 28k as a cfg file, 144k extracted. 5x bigger. As for speed. I wrote up a good comparison of eet vs libjson (and indirectly libjson vs libxml) on our phab news page a long time ago: https://phab.enlightenment.org/phame/post/view/12/eet_compared_with_json_-_eet_comes_out_on_top/ Using something like json (with libjson) would make reading 7 times slower. Writes 40% slower. On a cold read (fresh boot) 10 times slower. Using XML would have been far worse. But where it matters to me is read times as that determines time for startup of E etc. ... and thus determines what users perceive as responsiveness. But ... speed is just one goal. We could do better I think and chop memory usage down, but that's for a future library or feature of eet, But I have plans in the back of my head. But the REAL place eet shines is in ease of use for the programmer. Eet will literally take a data structure base pointer in memory and WALK it ... all of it... including linked lists, array,s hashes of strings or child structures and so on, and just serialize it out. It also does the reverse. Take the data blob we've compressed and serialized and return you an allocated data structure in memory, all filled in, verified etc. etc. with all the lists, hashed, arrays filled as you would have done by code. And it does these 2 in 1 line of code each (assuming you have an eet file open already). 1 line of code. one. uno. THAT is what makes this awesome. Its fast. It verifies everything for you. It spews out and consumes data structures natively like the programmer does. Eet can even encrypt, signature check files cryptographically and more. It can be used to just serialize blobs for sending/receiving over a network connection. It also does this all portably without being tied to 32 vs 64bit or big vs little endian etc. We use eet archive files like zip files. We can random-access any key at any time REALLY fast without having to use multiple files. It leads to less filesystem use. We can also store any data there. Images, audio, and much more. All in the same file. That's how edj files work. They stuff the images into the edj file. It's just an eet archive. Slight catch - you have to DESCRIBE your data struct once. It amounts to 1 line to start a struct and 1 line per field in the struct you wish to have encoded and decoded. Eet is actually very well documented. If you want to know more read its documentation, our examples, test suites, and read the code in applications like enlightenment, terminology etc. Now... what you may not know is we provided commandline tools. One major one. It's unsurprisingly called: eet Run it for help. It can list content of an eet archive (eet -l filename). Extract, insert or remove keys and their data. It can just dump the binary or decode it if it's encoded. It can sign files with your private/certificate, change compression of a key's data and so on. When it decodes a key .. it decodes into TEXT and you can read it and edit that decoded text file. You can then encode it again back into the key it was living in (with compression as desired). We even provided a script to do just this for you: vieet Read it. It's super simple. ... Eet files are really only binary in the sense that a zip file of lots of text files is binary. Or that you take a txt file and run gzip on it. The default config files for E in our src tree are text. The Makefiles "compile" the default config files when we build using the eet tool. Like you'd use gzip or zip or tar etc. ... We provide not only cmdline tools to do whatever is needed with an eet arch but also a comprehensive and "walk in the park" API to deal with these files from code. And dealing with them from code is done far more often by programmers and by the machine than it is ever done by a human. If a human wants to... they can dig around. See above. I made this choice. I wrote the code. I'm not actually crazy. I thought things through carefully after many years of experience. > ///Peter > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
