Re: Dependency problems after PR 1.2 update to extras builder

2010-03-31 Thread Marius Vollmer
ext Robin Burchell virot...@viroteck.net writes:

 Things as I understand it:
 - Qt 4.5 on Maemo5 had no API/ABI compatibility guarentees.
 - Qt 4.6 took liberal advantage of that to change and fix some rather
 suboptimal parts.

This might have been handled better, though, with a proper soname change
etc.  There are ways to cleanly break an interface, still painful, but
at least sterile.


In general, I think it is not useful to release an SDK update earlier
than the OS.  The way they are joined at the hip, they need to be
released together.  (Yes, in an parallel universe, SDK and OS would be
more independent.  But they are not and we should not pretend they are.)

It is of course better to release earlier than later.  Thus, if we want
to release the SDK early, we simply need to release the OS with it, as a
beta.

But even if there is a SDK release with a corresponding OS beta release,
I'd say it should not be installed in the Extras autobuilder.  People
can try out the new SDK and OS beta by themselves, we don't need to
force them to use it.  The Extras autobuilder should build for the most
recent release of the OS.

(In my dreams, the OS updates would be developed in extras-devel as
well, end-users would eventually SSU from extras, and the SDK as such
would not exist.  We would still have the problem of how to make a
binary that is compiled against Qt 4.6 run with Qt 4.5, but everybody
except us has that figured out.)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: Dependency problems after PR 1.2 update to extras builder

2010-03-31 Thread Timo Härkönen
Hi

2010/3/31 Marius Vollmer marius.voll...@nokia.com

 ext Robin Burchell virot...@viroteck.net writes:

  Things as I understand it:
  - Qt 4.5 on Maemo5 had no API/ABI compatibility guarentees.
  - Qt 4.6 took liberal advantage of that to change and fix some rather
  suboptimal parts.

 This might have been handled better, though, with a proper soname change
 etc.  There are ways to cleanly break an interface, still painful, but
 at least sterile.


 In general, I think it is not useful to release an SDK update earlier
 than the OS.  The way they are joined at the hip, they need to be
 released together.  (Yes, in an parallel universe, SDK and OS would be
 more independent.  But they are not and we should not pretend they are.)


I think it's good to able to test that your applications are working with
the upcoming version so there's a chance to have less broken packages when
the actual update comes. Anyway, time between these releases (SDK and OS) is
already too long.


 It is of course better to release earlier than later.  Thus, if we want
 to release the SDK early, we simply need to release the OS with it, as a
 beta.

 But even if there is a SDK release with a corresponding OS beta release,
 I'd say it should not be installed in the Extras autobuilder.  People
 can try out the new SDK and OS beta by themselves, we don't need to
 force them to use it.  The Extras autobuilder should build for the most
 recent release of the OS.



This brings up a question: Is there a need for one more repo? Something like
extras-experimental that could have these pre-released updates, etc. for
devs to test and play with. The current extras chain
(devel-testing-extras) would be only used with the current SDK only.



 (In my dreams, the OS updates would be developed in extras-devel as
 well, end-users would eventually SSU from extras, and the SDK as such
 would not exist.  We would still have the problem of how to make a
 binary that is compiled against Qt 4.6 run with Qt 4.5, but everybody
 except us has that figured out.)


-Timo
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


SGX library modifications?

2010-03-31 Thread Ahmed Ammar
Hello,

While trying to compile xserver-xorg-video-fbdev_0.4.0-180+0m5.tar.gz I
have come across missing definitions:

sgx_exa.c:79: error: ‘EURASIA_TAG_STRIDE_THRESHOLD’ undeclared (first
use in this function)

After further digging and installing of the maemo5 SDK I found that
these are provided by opengles-sgx-img-common-dev. And after chatting
with Stskeeps on IRC I was informed that Nokia have actually modified
the SGX libraries.

I would like to know how Nokia have managed to do so? Have they gotten
the source for the drivers from ImgTec? Are they actually different to
those available from TI? 

Would it be possible for someone to use your binaries outside the maemo
project?

Also, could this be forward ported to newer libraries from TI/ImgTec? 

Best Regards,
-- 
Ahmed A. Ammar
Senior Systems Engineer 
ConnectmeTV

email:  ahmed.am...@connectmetv.com
tel:+2010 600-5516

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: SGX library modifications?

2010-03-31 Thread Kimmo Hämäläinen
On Wed, 2010-03-31 at 15:16 +0200, ext Ahmed Ammar wrote:
 Hello,
 
 While trying to compile xserver-xorg-video-fbdev_0.4.0-180+0m5.tar.gz I
 have come across missing definitions:
 
 sgx_exa.c:79: error: ‘EURASIA_TAG_STRIDE_THRESHOLD’ undeclared (first
 use in this function)
 
 After further digging and installing of the maemo5 SDK I found that
 these are provided by opengles-sgx-img-common-dev. And after chatting
 with Stskeeps on IRC I was informed that Nokia have actually modified
 the SGX libraries.
 
 I would like to know how Nokia have managed to do so? Have they gotten
 the source for the drivers from ImgTec? Are they actually different to
 those available from TI? 

Yes, we had access to the source code, but mostly the modifications were
done by ImgTec developers.

 Would it be possible for someone to use your binaries outside the maemo
 project?

I guess if the SGX chip is the same (and you have compatible X parts).

 Also, could this be forward ported to newer libraries from TI/ImgTec? 

I'm sure all generic fixes were forward ported, but notice that the
driver in Fremantle is a bit old compared to the upstream.

-Kimmo

 
 Best Regards,

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: SGX library modifications?

2010-03-31 Thread Ahmed Ammar
On Wed, 2010-03-31 at 18:18 +0300, Kimmo Hämäläinen wrote:
 On Wed, 2010-03-31 at 15:16 +0200, ext Ahmed Ammar wrote:
  Hello,
  
  While trying to compile xserver-xorg-video-fbdev_0.4.0-180+0m5.tar.gz I
  have come across missing definitions:
  
  sgx_exa.c:79: error: ‘EURASIA_TAG_STRIDE_THRESHOLD’ undeclared (first
  use in this function)
  
  After further digging and installing of the maemo5 SDK I found that
  these are provided by opengles-sgx-img-common-dev. And after chatting
  with Stskeeps on IRC I was informed that Nokia have actually modified
  the SGX libraries.
  
  I would like to know how Nokia have managed to do so? Have they gotten
  the source for the drivers from ImgTec? Are they actually different to
  those available from TI? 
 
 Yes, we had access to the source code, but mostly the modifications were
 done by ImgTec developers.
 
  Would it be possible for someone to use your binaries outside the maemo
  project?
 
 I guess if the SGX chip is the same (and you have compatible X parts).
 
  Also, could this be forward ported to newer libraries from TI/ImgTec? 
 
 I'm sure all generic fixes were forward ported, but notice that the
 driver in Fremantle is a bit old compared to the upstream.

Thanks for the quick response Kimmo,

So as I expected, any reason why ImgTec decided not to take this into
their TI driver pack? 

I've currently got most things ported correctly using your xorg server.
Just doing the big part of porting your kernel changes to 2.6.33.

Best Regards,
-- 
Ahmed A. Ammar
Senior Systems Engineer 
ConnectmeTV

email:  ahmed.am...@connectmetv.com
tel:+2010 600-5516

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: refinding the syncing question

2010-03-31 Thread Aniello Del Sorbo
On Wed, 2010-03-31 at 10:27 +0100, Graham Cobb wrote:
 On Wednesday 31 March 2010 01:19:17 Aniello Del Sorbo wrote:
  According to this page:
 
  https://www.forge.funambol.org/download/
 
  It looks like the source code is available.
  Not sure about licensing, though.
 
 Thanks, Aniello, but I am not looking for Funambol source, but Nokia's 
 changes 
 to it.  Carsten believes that as Nokia have licensed Funambol through a 
 commercial licence they do not need to make their changes available.  It is 
 the Nokia changes which I am asking to be opened up.
 
 Graham

Sorry, I thought you were looking for those and indeed I wondered why
you simply didn't go to their website :)

Aniello

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Re: problem with dbus-scripts and Phone.SMS

2010-03-31 Thread Nicolas Chuche
Hello,

 reinventing the wheel could be hard and dangerous so I was thinking
 about something like yaml. On the plus side, it's easy to parse with
 libraries. On the minus side, you need to have the library on n900.

I've coded some kind of POC. It's not finished (my C is a bit
rusted...) and just print a json dump of the dbus message for the
moment.

I've only tested it on my linux workstation for the moment. You need
http://oss.metaparadigm.com/json-c/ to compile it.

If you are interested I can finish and clean it this to release it.
--- dbus-scripts.c.orig	2010-03-25 20:50:21.0 +0100
+++ dbus-scripts.c	2010-03-31 21:44:15.0 +0200
@@ -30,12 +30,15 @@
 #include unistd.h
 #include sys/wait.h
 
+#include json.h
 #include glib.h
 #include glib-object.h
 #define DBUS_API_SUBJECT_TO_CHANGE 1
 #include dbus/dbus-glib-lowlevel.h
 #include dbus/dbus.h
 
+
+
 #define DBUS_CONF_DIR /etc/dbus-scripts.d
 #define DBUS_RUN_SCRIPTS 
 
@@ -155,106 +158,135 @@
   g_slist_foreach(script_list, (GFunc)script_file_call_if_matched, args);
 }
 
-static void
+static struct json_object*
 print_iter (DBusMessageIter *iter, dbus_bool_t literal, int depth)
 {
+  json_object *my_object, *my_array;
+  my_array = json_object_new_array();
+
   do {
   int type = dbus_message_iter_get_arg_type (iter);
   const char *str;
   dbus_uint32_t uint32;
   dbus_int32_t int32;
   dbus_bool_t boolean;
-#if 0
+#if 1
   double d;
   unsigned char byte;
 #endif
 
-  if (type == DBUS_TYPE_INVALID) break;
+  if (type == DBUS_TYPE_INVALID) {
+	my_object = json_object_new_string(invalid);
+	break;
+  }
 
   switch (type) {
 		case DBUS_TYPE_STRING:
   dbus_message_iter_get_basic (iter, str);
 		  strncpy(msgs[nmsgs], str,127);
+		  my_object = json_object_new_string(str);
 		  nmsgs++;
 	  	  break;
 #if 1
 		case DBUS_TYPE_INT32:
 			dbus_message_iter_get_basic (iter, int32);
 	  	  	sprintf (msgsv2[nmsgsv2], %d, int32);
+			my_object = json_object_new_int(int32);
 		  	nmsgsv2++;
 	  	  break;
 
 		case DBUS_TYPE_UINT32:
 			dbus_message_iter_get_basic (iter, uint32);
 	  	  	sprintf (msgsv2[nmsgsv2], %u, uint32);
+			my_object = json_object_new_int(uint32);
 		  	nmsgsv2++;
 	  	  break;
 		case DBUS_TYPE_BOOLEAN:
   			dbus_message_iter_get_basic (iter, boolean);
 			sprintf (msgsv2[nmsgsv2], %s, boolean ? true : false);
+			my_object = json_object_new_boolean(boolean);
 			nmsgsv2++;
   			break;
-			
 #endif
 
-#if 0
+#if 1
 		case DBUS_TYPE_DOUBLE:
 	  		dbus_message_iter_get_basic (iter, d);
-	  		printf (double %g\n, d);
+			my_object = json_object_new_double(d);
 	  		break;
 
 		case DBUS_TYPE_BYTE:
 			dbus_message_iter_get_basic (iter, byte);
-			printf (byte %d\n, byte);
+			my_object = json_object_new_int(byte);
 		break;
 
 		case DBUS_TYPE_VARIANT:
 	  		{
 DBusMessageIter subiter;
-
 dbus_message_iter_recurse (iter, subiter);
-
-printf (variant:);
-print_iter (subiter, literal, depth);
+my_object = print_iter (subiter, literal, depth + 1);
 break;
 	  		}
 		case DBUS_TYPE_ARRAY:
 	  		{
 int current_type;
 DBusMessageIter subiter;
+json_object *local_object;
 
+my_object = json_object_new_array();
 dbus_message_iter_recurse (iter, subiter);
 
-printf([);
 while ((current_type = dbus_message_iter_get_arg_type (subiter)) != DBUS_TYPE_INVALID)
 	  			{
-	print_iter (subiter, literal, depth);
+local_object = print_iter (subiter, literal, depth + 1);
+	json_object_array_add(my_object, local_object);
 	dbus_message_iter_next (subiter);
-	if (dbus_message_iter_get_arg_type (subiter) != DBUS_TYPE_INVALID)
-			  			printf (,);
 	  			}
-printf(]);
 break;
 	  		}
 		case DBUS_TYPE_DICT_ENTRY:
 	  		{
 DBusMessageIter subiter;
+json_object *key, *value;
 
+my_object = json_object_new_object();
 dbus_message_iter_recurse (iter, subiter);
 
-printf({);
-print_iter (subiter, literal, depth);
+key = print_iter (subiter, literal, depth+1);
 dbus_message_iter_next (subiter);
-print_iter (subiter, literal, depth);
-printf(});
+value = print_iter (subiter, literal, depth+1);
+json_object_object_add(my_object, key, value);
 break;
 	  		}
+
+case DBUS_TYPE_STRUCT:
+		{
+			int current_type;
+DBusMessageIter subiter;
+my_object = json_object_new_array();
+
+dbus_message_iter_recurse (iter, subiter);
+
+while ((current_type = dbus_message_iter_get_arg_type (subiter)) != DBUS_TYPE_INVALID)
+  {
+json_object *value;
+value = print_iter (subiter, literal, depth+1);
+json_object_array_add(my_object, value);
+dbus_message_iter_next (subiter);
+  }
+break;
+			}
+
+
 #endif
 		default:
 			break;
   	  }
   
+  json_object_array_add(my_array, my_object);
   } while (dbus_message_iter_next (iter));
+
+  return depth == 1 ? my_array 

WSDL 2.0

2010-03-31 Thread Demetris


Anyone knows of a WSDL 2.0 parser for mobile Java (J2ME CDC)?

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers


Hello dmoc

2010-03-31 Thread dmoc
http://prettypallyaghh5.webs.com?W3vguw5oo


  

___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers