Re: Total size of Fedora source
Bunch of random strings somewhat related to your proposal: Build: * Assuming loaded source DB (during distribution build) * Source query: pkg:gnome-keyring[@fgit='3f7ff7']//cfunc:gkm_rpc_log/trans-calls::*/arg:line/c:string/string() (All string "line" [1] literals used in calls (direct and transitive) to gkm_rpc_log [**]) * Filling the err-message grammar (snippet from [3]): err-message = "WARNING: " "gnome-keyring" ":: " ( ... | "couldn't secure socket: " everything | "couldn't connect to: " everything ": " everything | "couldn't send socket credentials: " everything ... ) (the grammar is needed for parsing the user input for points 1st and 3rd of your note (see also [***] alternative)) Runtime: * parse the user/service query "WARNING: gnome-keyring:: couldn...": applying the above gremmar and rendering part of the syntax tree in response. Kind Regards, Alek [*] Let's forget for a minute about the fact of hundreds different patters in the whole codebase, let's pretend that we have to handle just the sample error message from your propsal ;-) [**] Imaginary xpath/xquery-like language for code queries ([4,5,6] - leading large scale implementation AFAIK): pkg: pacakges namespace 3f7ff7: 3f7ff7289907d2a27912909e63908eadb16d97bf == 3.2.1-3: Current F16 git for gnome-keyring - implies upstream 6d5818 [2] cfunc: C functions namespace trans-calls: transitive calls axis (like ancestor-or-self but for "calling" relation instead of "nesting" tree relation) arg: argument names namespace c: C language constructs namespace string(): in xpath string() function tries to convert the context tree node to string scalar [***] Less elegant, but also less complicated (we do not need grammar and parsing, but just code-point _key_ matching) option is to convince Tomas to include build instrumentation in the spec (David's gcc plugin based in case of gnome-keyring) for hard error messages pre-enumeration with the following effect: [3] L250 becomes: "[FGKR0TK] couldn't secure socket: %s" [3] L256 becomes: "[FGKR0TL] couldn't connect to: %s: %s" [3] L262 becomes: "[FGKR0TM] couldn't send socket credentials: %s" [1] http://git.gnome.org/browse/gnome-keyring/tree/pkcs11/rpc-layer/gkm-rpc-dispatch.c?id=6d5818#n72 [2] http://git.gnome.org/browse/gnome-keyring/tree/?id=6d58181fcddc5c13762a1920a464787ebc27d4bc [3] http://git.gnome.org/browse/gnome-keyring/tree/pkcs11/rpc-layer/gkm-rpc-module.c?id=6d5818#n246 [4] http://www.lug-erding.de/vortrag/Purely%20Relational%20XQuery%20LUG%20Erding.pdf [5] http://hackage.haskell.org/package/Pathfinder [6] http://dev.monetdb.org/hg/MonetDB/file/f7d6c302cc9c/pathfinder/compiler/algebra/algebra.c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Total size of Fedora source
On 18.05.2012 16:38, Pádraig Brady wrote: An online equivalent to http://livegrep.com/ would rock :) At least ;-). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Total size of Fedora source
On Fri, May 18, 2012 at 04:17:29PM +0300, Alek Paunov wrote: > Hi Rich, > > On 18.05.2012 15:49, Richard W.M. Jones wrote: > >The reason is that I want to check out all the source for an > >experiment, and I need to know what order of disk space I will need [:-)] > > Would you like to elaborate - What kind of experiment you are preparing? > > [Asking because I live with the idea about Fxx-snapshot mass source > indexing/XRref for long time already (based mainly on the great > David Malcolm's gcc-python-plugin, the openjdk compiler and several > other tools) and if your work will be in the same direction I am > willing to take part of the tasks - e.g. DBs related work ...] It's more of a thought rather than a fully worked out idea, but here you go: Often when something goes wrong, the only thing you have is an error message. Programmers don't always write good errors, and even when they do they are often very context specific (ie. they mean something only in the context of the source code that generates the message, meaning there're a lot of hidden assumptions behind an error). Also it's likely that some errors are encountered by our users very frequently, whereas the vast majority of errors are never printed at all. So [if those assumptions are true] can we do something more useful about error messages? Some ill-formed ideas I had: - Take the text of an error message and display the piece of code which generated it. Not great for end users, but useful for programmers, whom I think of as Fedora's core audience. - Extract error messages from the code and find out how common they are (eg. in Google searches or Bugzilla). This would give us some idea of which error messages should be fixed first to make them more explanatory, or simply bugs which are important to fix. - Some sort of web service for error messages. Google is pretty poor for looking up errors. Try searching for this in Google: "WARNING: gnome-keyring:: couldn't connect to: /run/user/rjones/keyring-IrcfPu/pkcs11: No such file or directory" Currently there are no hits, even though this is a common and long- running bug (RHBZ#783568). The reason is that Google doesn't understand the structure of the error message - the fact that some parts are common to all errors in this class, and others (the pathname) is specific to my machine. But a web service might be able to do better, especially if it has knowledge extracted from the Fedora source code. You could imagine the source code annotated with references to the relevant Bugzilla number. (BTW I'm not claiming exclusivity to any of these ideas. If they sound interesting, please jump in and implement them :-) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Total size of Fedora source
On 05/18/2012 02:17 PM, Alek Paunov wrote: > Hi Rich, > > On 18.05.2012 15:49, Richard W.M. Jones wrote: >> The reason is that I want to check out all the source for an >> experiment, and I need to know what order of disk space I will need [:-)] > > Would you like to elaborate - What kind of experiment you are preparing? > > [Asking because I live with the idea about Fxx-snapshot mass source > indexing/XRref for long time already (based mainly on the great David > Malcolm's gcc-python-plugin, the openjdk compiler and several other tools) > and if your work will be in the same direction I am willing to take part of > the tasks - e.g. DBs related work ...] An online equivalent to http://livegrep.com/ would rock :) cheers, Pádraig. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Total size of Fedora source
Hi Rich, On 18.05.2012 15:49, Richard W.M. Jones wrote: The reason is that I want to check out all the source for an experiment, and I need to know what order of disk space I will need [:-)] Would you like to elaborate - What kind of experiment you are preparing? [Asking because I live with the idea about Fxx-snapshot mass source indexing/XRref for long time already (based mainly on the great David Malcolm's gcc-python-plugin, the openjdk compiler and several other tools) and if your work will be in the same direction I am willing to take part of the tasks - e.g. DBs related work ...] Kind Regards, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Total size of Fedora source
On 05/18/2012 01:49 PM, Richard W.M. Jones wrote: > Does anyone have an estimate for the total size of the checked out and > "prepped" source code (w/o binaries) in Fedora (eg. in F17)? > > The reason is that I want to check out all the source for an > experiment, and I need to know what order of disk space I will need [:-)] > > Rich. > Dave Jones did that recently: http://codemonkey.org.uk/2012/02/24/fedora-master-branch-statistics/ cheers, Pádraig. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
