| |
| |
| |
|
Comments:
<0> behdad: so we're down to 5 syscalls per font directory now; stat(dir), open(cache), fstat(cache), mmap(cache), close(cache)
<0> oh, but something bad has happened to font matching :-)
<0> oops
<1> keithp: neat
<0> behdad: yeah, doing a fc-list foo takes about 0.030 secs now
<1> keithp: does that mean every subdirectory too?
<0> of wall clock time, no CPU time to speak of
<1> nice
<0> behdad: yes, of course, cache files are still per directory
<0> of course, matching is completely fubar at present, but I'll get that fixed eventually
<1> keithp: my fc-list is as fast now, but i don't have many dirs
<0> One question is how much validation we should do on the cache files; I'm not doing much at present, aside from checking the magic number and making sure it hasn't been truncated
<0> I've got 84 dirs
<1> keithp: that doesn't fix the problem some people have with ~1000 directories
<0> right, the question is whether we want to give up on the promise of detecting changes
<1> keithp: that sounds like enough to me
<0> The separate issue is whether we merge subdirectory cache contents into the parent directory cache
<0> That would avoid open/fstat/mmap/close for every subdir
<0> I think it's actually fairly easy to manage too
<1> keithp: that looks like an improvement to me
<0> but, it would mean rebuilding the entire cache everytime anything changed
<1> keithp: but if you can merge subdirs instead of scanning all the fonts in the tree, that may be fast enough
<0> oh, leave the per-dir caches around and merge them up the tree then?
<1> keithp: it will take a kinda quadratic space, but that's not an issue I suppose
<1> keithp: yeah
<0> could do taht
<0> Given the current cache structure, it's actually trivial to do too
<1> cool
<0> hmm. Could avoid fstat if I stuck the dir timestamp in the cache file. That seems like a good change
<1> keithp: how?
<1> keithp: iow, what happens if cache is out of date?
<0> the fstat checks to make sure the cache is 'newer' than the directory; just writing the directory mtime into the cache would suffice
<0> and be more reliable in fact; if you copy the caches around you can confuse the timestamp checking
<1> oh, remove the fstat on the cache
<0> right
<1> yes, good point
<1> inodes should have had a serial number..
<0> yeah, or at least finer granularity timestamps
<1> yeah
<2> and they usually have one, in the implementation
<0> You really have to sleep(1) during font install for things to work right
<2> you just don't get to see it. puny userspace mortals.
<0> ajax: userspace has sec/nsec
<1> aw
<1> keithp: make goes to sub-sec. can't fc-cache go too?
<0> behdad: yeah, it does. I remember sticking a sleep in there somewhere though
<1> ah
<3> hi
<3> Is there are "standard" for configuration files in the open source world? or can i just use INI-files?
<4> it would sure be nice if there was oe
<5> szilky1: yurk
<5> if you don't need structure use a basic key=value file
<5> if you do need structure and sections there are plenty better choices than ini files
<6> szilky1: no, each app has used whatever they see fit, but you can find libs, and it always depends what you need to store, what features and how nice for editing and so on
<5> xml comes to mind
<3> hmm
<5> (note you can do terrible xml, it's no magic bullet)
<6> that fits into not so nice to edit or process if unixy target ;]
<3> the whole configuration should be scalable.. even if my app (linux installer) had 10000 entries
<5> UnNamed: xml is plenty easier to process on unix than .ini
<3> thats why i thought about sqlite
<7> nim-nim no it's not...
<6> nim-nim: that is not saying much
<7> nim-nim I can write ini parser in like few lines in perl
<3> XML using SAX/DOM and XPath is a big Overhead and has no advantages at all..
<6> nim-nim: you can say 1000 is smaller than 1100... but that is different than saying 10 is small in general
<2> that's why people just use expat
<5> nakee: perl people can always write things in a few lines of code ;)
<3> what do you think about my sqlite idea? or should i save all thing somewhere in /tmp/etc/..
<7> szilky1 what do you want to save in sql lite?the configuration?
<3> nakee: yeah
<6> szilky1: and what kind of app? the purpose, in few words
<5> szilky1: depends what exactly you need. I wouldn't call a 10000 entry a conf file but a small database
<5> conf file is something which can be reasonably parsed by a human being in a reasonable time
<3> UnNamed: at first a small linux installer (installs workstations), the second step will be installing a cluster
<6> szilky1: so some kind of automated OS cloner?
<3> UnNamed: no its always a fresh install.. but in general you could use the same config for cloning the cluster or the workstation..
<5> also you need to consider robustness vs speed
<5> the samba people used an unstructured ini-like syntax
<2> also, bikesheds are always prettier when they're blue
<6> szilky1: sounds like what someone would do with some scripts :/
<5> and they had to write a whole conf file validator app because people where getting it wrong all the time
<5> a higher overhead format with more built-in checks would have saved everyone time
<3> UnNamed: i m sure "someone" would do anything even coffee with some perl-scripts :)
<3> anyway, so there are also no de facto standards..?
<7> szilky1 why would a program like that use such a huge config file?
<6> szilky1: it is just mounting disks, format, dump data, change config files
<3> It will do a littl more
<6> szilky1: like?
<3> for example bookmarks of users are also in the config
<3> or backup information
<3> cron information
<7> szilky1 I would have kept the configuration tree
<6> szilky1: that is not config, that is data, imo
<7> szilky1 then it's also simpler to copy it on the installed /etc
<5> szilky1: there are no de facto standards because you find examples of terrible conf files for every option (flat files, ini files, whatever)
<5> so everyone can argue the neighour's solution is bad because someone made a mess of it
<3> i d have a sql table USER, STORAGE, BACKUP and so on..
<3> an user can have an attribute "bookmark-file", "backup" "cron" and so on
<3> i m just collecting ideas.. but thats the idea for now..
<8> dobey: hi, somehow I can't add you to my yahoo list. You don't use jabber, do you?
<9> hola
<1> font meeting people here?
<10> hi bedad we're on ##fonts
<1> keithp: not joining the fonts conference call?
<0> behdad: just joined
<0> ##fonts?
<1> keithp: fc-cache.c:226: error: implicit declaration of function FcDirScanConfig
<0> behdad: yeah, I committed busted goop by mistake
<0> sorry
<1> np
<0> hmm. Can't see any diffs here though
<0> oh, that's fc-cache
<0> yeah, working on that
<0> good plan
<0> I'm dropping extra family names at present; fixing that first
<1> go ahead, rip the bitch off
<1> we also need to go over the default config after you are done with the code
<0> oh, no problem
<11> keithp: new fontconfig breaks evince :(
<1> I'm sure he's not surprised ;)
<11> I was, a bit. everything else was looking so good.
<12> anholt_: the poppler part or the ui?
<11> krh: keithp is on it. it complains about things like "Error: Couldn't find a font for 'Helvetica BoldOblique'
<11> some font thing failed" and the characters are all wrong
<12> oh... could a poppler problem, though
Return to
#freedesktop
or
Go to some related
logs:
crystal snd-cd4236
install-crossover-standard-4.2.sh
fluxbox background stretch
can i delete ibdata file in mysql?
#bash
flat memory or sparse memory
#linux
#kde
dapper to edgy xwindows
postfix 2.3 mysql5 debian
|
|