[PATCH] Fix compiler errors, and a little cleanup in cornucopia
Hi all,
Attaching couple of tiny patches which fixes a build error in fsodeviced and
minor cleanup in common.vala under libfsoframework
--
Regards
Sudharshan S
Blog : http://www.sudharsh.wordpress.com
IRC : Sup3rkiddo @ Freenode, Gimpnet
From 6d006d245bdc4a99a52e8a8d659628ab32fab2c8 Mon Sep 17 00:00:00 2001
From: Sudharshan 'Sup3rkiddo' S sudha...@gmail.com
Date: Fri, 3 Apr 2009 20:57:31 +0530
Subject: [PATCH] Fix wrong usage of Dir which caused compiler error
Signed-off-by: Sudharshan 'Sup3rkiddo' S sudha...@gmail.com
---
fsodeviced/src/plugins/kernel26_leds/plugin.vala |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fsodeviced/src/plugins/kernel26_leds/plugin.vala b/fsodeviced/src/plugins/kernel26_leds/plugin.vala
index cc1901a..5dd4e68 100644
--- a/fsodeviced/src/plugins/kernel26_leds/plugin.vala
+++ b/fsodeviced/src/plugins/kernel26_leds/plugin.vala
@@ -138,8 +138,8 @@ ListKernel26.Led instances;
public static string fso_factory_function( FsoFramework.Subsystem subsystem ) throws Error
{
// scan sysfs path for leds
-var dir = new Dir( Kernel26.SYS_CLASS_LEDS );
-var entry = dir.read_name();
+Dir dir = Dir.open( Kernel26.SYS_CLASS_LEDS, 0 );
+string entry = dir.read_name();
while ( entry != null )
{
var filename = Path.build_filename( Kernel26.SYS_CLASS_LEDS, entry );
--
1.6.0.6
From 23b14af25dcb492ee417b68ce61b2909c12c2958 Mon Sep 17 00:00:00 2001
From: Sudharshan 'Sup3rkiddo' S sudha...@gmail.com
Date: Fri, 3 Apr 2009 21:03:44 +0530
Subject: [PATCH] Clean up a bit in common
Signed-off-by: Sudharshan 'Sup3rkiddo' S sudha...@gmail.com
---
libfsoframework/fsoframework/common.vala | 26 --
1 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/libfsoframework/fsoframework/common.vala b/libfsoframework/fsoframework/common.vala
index 84eb919..d668226 100644
--- a/libfsoframework/fsoframework/common.vala
+++ b/libfsoframework/fsoframework/common.vala
@@ -34,17 +34,23 @@ internal static SmartKeyFile _masterkeyfile = null;
public static SmartKeyFile theMasterKeyFile()
{
-if ( _masterkeyfile == null )
-{
+if ( _masterkeyfile == null ) {
+
_masterkeyfile = new SmartKeyFile();
-var try0 = ./frameworkd.conf;
-var try1 = %s/.frameworkd.conf.printf( Environment.get_home_dir() );
-var try2 = /etc/frameworkd.conf;
-if ( !_masterkeyfile.loadFromFile( try0 ) !_masterkeyfile.loadFromFile( try1 ) !_masterkeyfile.loadFromFile( try2 ) )
-{
-warning( could not load %s nor %s nor %s, try0, try1, try2 );
-}
-}
+
+ string[] possible_paths = {
+ ./frameworkd.conf,
+ %s/.frameworkd.conf.printf( Environment.get_home_dir()),
+ /etc/frameworkd.conf
+ };
+
+foreach (string path in possible_paths) {
+ if (_masterkeyfile.loadFromFile(path)) {
+print(FSO framework configuration file loaded from %s.printf(path));
+break;
+ }
+ }
+ }
return _masterkeyfile;
}
--
1.6.0.6
___
smartphones-standards mailing list
smartphones-standards@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Three different databases for gsm celltower locations
Hello. I'm wondering what happended to the discussion about three different databases available. Back at the last time this topic came up I felt that there will be ongoing work to avoid this concurency and try to get the databases merged. Seems this has failed so far. Is it just bad communication or is every group siting there and thinks that their approach is the best one and the other should to the first step? I know that everyone of you had put a lot erngy and love in his project to get it to this state. This is great. Even greater would it be imho when you guys could collaborate on the goal to collect gsm tower locations. I can see some technical problems you may face here. Cellhunter needs some db fields for the group management and ranking. OpenBmap likes to have more fields for quality informations about GPS and GSM. Different layouts of the databases, etc. What should work easily is that the fields of the cellhunter db that are not relevant to the group management get synced to opencellid and openbmap. Then these both have to figure out a way how to sync with the different ideas of stored data for position quality. That one is of course harder. Best would still be to join forces and go for one central collection point. I don't see this happen tho. So please, step back and think about how you are able to sync for efforts at least. Freesmartphone, which will hopefully a big consumer of this in the future, also would like to see a effort to collect the position of wifis and use them in combination with GSM for better accuracy outdoor and also in buildings where no GPS is possible at all. I'm working on the networking part of FSO to give the logging clients an easy interface for the wifis around you. And please, before answering here. Step back and think about it. I don't want flames but constructive work here. :) regards Stefan Schmidt ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
Re: Three different databases for gsm celltower locations
Hi, On Sat, 4 Apr 2009 00:05:43 +0200 Stefan Schmidt ste...@datenfreihafen.org wrote: I'm wondering what happended to the discussion about three different databases available. Back at the last time this topic came up I felt that there will be ongoing work to avoid this concurency and try to get the databases merged. thanks for bringing that up, it's quite sad, actually. Best would still be to join forces and go for one central collection point. I don't see this happen tho. So please, step back and think about how you are able to sync for efforts at least. One other possibility if this isn't possible for one reason or the other is to aggregate the individual databases into one big database. The licenses would allow for it and opencellid as well as cellhunter export the raw data (Openbmap's Offline API will be available during first semester 2009 according to their website). I would think of this as purely a generated database without any upload functionality to avoid yet another cell location database project pulling into a fourth direction. Freesmartphone, which will hopefully a big consumer of this in the future, also would like to see a effort to collect the position of wifis and use them in combination with GSM for better accuracy outdoor and also in buildings where no GPS is possible at all. Right, during the OpenExpo in Bern Jan hacked something together to see how well GSM locating would perform using the cellhunter db and accuracy was quite okay (position was about 200-500m off). Regards, Daniel Willmann signature.asc Description: PGP signature ___ smartphones-standards mailing list smartphones-standards@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
