**** BEGIN LOGGING AT Wed May 06 02:59:57 2009
May 06 05:22:18 <spaetz> there is still no mokomaze in the feed, how come?
May 06 05:26:03 <mrmoku|a`> spaetz: in the actual feed or in task-shr-feed.bb?
May 06 05:35:36 <tobii_> good morning
May 06 05:36:57 <mrmoku|a`> mickey|tv: which version of vala supports the 'owned' keyword? mickey/0.7/posix seems not to...
May 06 06:29:58 <spaetz> mrmoku|away: it's not in the actual feed
May 06 06:30:17 <spaetz> also installing shr-config failed with not found (me checks if it exists)
May 06 06:30:42 <spaetz> nope, no shr-config package either
May 06 06:31:10 <spaetz> is there an "owned* keyword?  I only know "unowned"
May 06 06:37:22 <eolson> hmm, any idea why my gta01 won't fast charge a nokia bl-5c battery?  I'm only getting "pre" and 100-200 mA
May 06 07:20:30 <ptitjes> good morning
May 06 07:22:31 <tobii_> morning ptitjes
May 06 07:49:10 <spaetz> mrmoku: what was the problem with automake1-10?
May 06 08:01:15 <spaetz> I just tried to build automake-native 1.10.2 and it quit in "staging" with no make target install, or something similar
May 06 08:16:29 <mrmoku> spaetz: for me it has some patch included that does not apply (at least the target version)
May 06 08:17:16 <spaetz> mmh, weird
May 06 08:18:49 <spaetz> I checked "ode" 0.10 and that also already requires automake 1.10
May 06 08:19:15 <spaetz> and 0.9 doesn't contain some of the calls that are being used by mokomaze, so I guess it's too old
May 06 08:19:34 <mrmoku> yohh... doomed again :P
May 06 08:19:56 <mrmoku> we will have to update that stuff anyway... too much things need newer autofools ;)
May 06 08:20:12 <spaetz> yes, I guess so
May 06 08:20:22 <spaetz> the OE dev branch has recipes for newer stuff
May 06 08:20:38 <spaetz> no clue how easy it is to get a newer set of working stuff from there
May 06 08:21:40 <spaetz> I see you are building om-gta01 right now. Can you retry the gt2 feed when it finished?
May 06 08:21:44 <mrmoku> well... I tried it even there... with no luck
May 06 08:21:51 <spaetz> mmh, sucks
May 06 08:22:15 <mrmoku> the feed fails though
May 06 08:22:52 <PaulFertser> OE users are DOOMED
May 06 08:23:03 <PaulFertser> ~seen Dave
May 06 08:23:04 <bzzbot> dave <n=dave@pool-138-89-1-87.mad.east.verizon.net> was last seen on IRC in channel #openmoko-cdevel, 19d 19h 2m 9s ago, saying: 'dos1, I thought opimd was just a legend!? :o'.
May 06 08:23:04 <mrmoku> yep... true
May 06 08:23:18 <spaetz> I  mean automake 1.10 seems to have been released in 2006
May 06 08:23:31 <spaetz> so it's not like it should be bleeding edge
May 06 08:57:33 <CIA-75> freesmartphone.org: 03ptitjes 07vala-dbus-binding-tool * r64d217f36777 10/src/vala-dbus-binding-tool.vala: 
May 06 08:57:33 <CIA-75> freesmartphone.org: [#418] Add support for errors in XML specs
May 06 08:57:33 <CIA-75> freesmartphone.org: Signed-off-by: Didier 'Ptitjes <ptitjes@free.fr>
May 06 08:58:08 <mirko-paroli> btw anyone knows what this means :Error org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1
May 06 08:58:33 <Zorkman_> yeah; mickey|zzZZzz knows :p
May 06 08:59:43 <CIA-75> freesmartphone.org: 03ptitjes 07specs * rc99fd5ff6030 10/ (Makefile opim/Makefile): 
May 06 08:59:43 <CIA-75> freesmartphone.org: Fix Makefiles to include opimd specs
May 06 08:59:43 <CIA-75> freesmartphone.org: Signed-off-by: Didier 'Ptitjes <ptitjes@free.fr>
May 06 09:04:07 <CIA-75> freesmartphone.org: 03ptitjes 07specs * r4214e36ddd05 10/otapi/org.freesmartphone.GSM.Call.xml.in: 
May 06 09:04:07 <CIA-75> freesmartphone.org: Publish GSM.Call errordomains and throws specifications
May 06 09:04:07 <CIA-75> freesmartphone.org: Signed-off-by: Didier 'Ptitjes <ptitjes@free.fr>
May 06 09:12:32 <CIA-75> freesmartphone.org: 03ptitjes 07vala-dbus-binding-tool * rcb02f826ff01 10/src/vala-dbus-binding-tool.vala: 
May 06 09:12:32 <CIA-75> freesmartphone.org: Fix method names that are registered names
May 06 09:12:32 <CIA-75> freesmartphone.org: Signed-off-by: Didier 'Ptitjes <ptitjes@free.fr>
May 06 09:14:48 <CIA-75> freesmartphone.org: 03ptitjes 07libfso-glib * r08467310f180 10/src/Makefile.am: 
May 06 09:14:48 <CIA-75> freesmartphone.org: Add PIM specs to the build
May 06 09:14:48 <CIA-75> freesmartphone.org: Signed-off-by: Didier 'Ptitjes <ptitjes@free.fr>
May 06 09:14:49 <CIA-75> freesmartphone.org: 03ptitjes 07libfso-glib * r44c32a8a0aae 10/src/ (5 files): 
May 06 09:14:49 <CIA-75> freesmartphone.org: Regenerated from specs
May 06 09:14:50 <CIA-75> freesmartphone.org: Signed-off-by: Didier 'Ptitjes <ptitjes@free.fr>
May 06 09:15:01 <ptitjes> sorry for the noise
May 06 09:15:15 <mirko-paroli> ptitjes: only for you ;)
May 06 09:15:40 <ptitjes> mickey|zzZZzz: you have examples of the errors in libfso-glib/src/freesmartphone-gsm.vala
May 06 09:16:03 <ptitjes> mickey|zzZZzz: also PIM apis generated thanks to mrmoku 
May 06 09:16:14 <ptitjes> mirko-paroli: oh, me I don't mind
May 06 09:16:28 <ptitjes> mirko-paroli: it is kinda nice to have the logs here to check
May 06 09:16:29 <ptitjes> :)
May 06 09:16:32 <mirko-paroli> :)
May 06 09:16:42 <mirko-paroli> makes you important ;)
May 06 09:16:46 <ptitjes> éhéhé
May 06 09:16:59 <mirko-paroli> i am very glad that noone notices my stupid committ messages
May 06 09:17:00 <mirko-paroli> ;)
May 06 09:17:13 <mirko-paroli> let alone what I actually commit ;)
May 06 09:28:06 <ptitjes> mirko-paroli: does python rely on dbus methods's parameter names ?
May 06 09:28:40 <mirko-paroli> I am sure it can, but doesn't have to
May 06 09:28:45 <mirko-paroli> if I get your question right
May 06 09:29:18 <ptitjes> mirko-paroli: I mean if I change the parameter name "call_status" in http://git.freesmartphone.org/?p=specs.git;a=blob;f=otapi/org.freesmartphone.GSM.Call.xml.in;h=bf9564766de771cd2091f9fca21d1406c2e4c1f0;hb=HEAD#l197
May 06 09:29:37 <ptitjes> mirko-paroli: will it break python frameworkd and apps depending on it ?
May 06 09:30:33 <mirko-paroli> i dont think so
May 06 09:30:43 <mirko-paroli> but don't quote me
May 06 09:30:46 <mirko-paroli> :)
May 06 09:31:31 <ptitjes> mickey|zzZZzz: so I ask the question to you...
May 06 09:31:39 <ptitjes> mickey|zzZZzz: if I change the parameter name "call_status" in http://git.freesmartphone.org/?p=specs.git;a=blob;f=otapi/org.freesmartphone.GSM.Call.xml.in;h=bf9564766de771cd2091f9fca21d1406c2e4c1f0;hb=HEAD#l197
May 06 09:31:47 <ptitjes> mickey|zzZZzz: will it break python frameworkd and apps depending on it ?
May 06 09:34:12 <ptitjes> shoragan: hello
May 06 09:34:21 <ptitjes> shoragan: maybe you know about it ?? ^^^^^
May 06 09:34:25 <shoragan> hmm?
May 06 09:35:18 <shoragan> what do you want to change it to?
May 06 09:35:26 <ptitjes> call_details
May 06 09:35:37 <shoragan> what?
May 06 09:35:47 <shoragan> it maps to the CallStatus signal
May 06 09:35:54 <ptitjes> shoragan: nah
May 06 09:35:57 <shoragan> s/what/why/
May 06 09:36:12 <ptitjes> shoragan: in CallStatus signal, the parameter status is the CallStatus
May 06 09:36:52 <ptitjes> shoragan: or the real status (active, ...) must be named CallStatusEnum
May 06 09:36:59 <ptitjes> which I find bad
May 06 09:37:12 <ptitjes> shoragan: do you see what I mean ?
May 06 09:37:50 <shoragan> hmm, i don't think the name attribute is used in the framework
May 06 09:38:03 <ptitjes> ok good
May 06 09:38:16 <shoragan> if you change that, please also adjust the summary
May 06 09:38:39 <ptitjes> shoragan: the summary of list calls ?
May 06 09:39:25 <shoragan> yes
May 06 09:39:41 <shoragan> where it refers to CallStatus
May 06 09:39:57 <ptitjes> shoragan: by adding "signal" then ?
May 06 09:40:07 <ptitjes> "See org.freesmartphone.GSM.Call.CallStatus  signal..."
May 06 09:40:28 <shoragan> yea
May 06 09:40:33 <ptitjes> ok cool
May 06 09:41:24 <ptitjes> shoragan: could make a redesign session for Phone api at the F9N ?
May 06 09:41:28 <ptitjes> +we
May 06 09:42:20 <shoragan> yes, i'd like to hear some ideas
May 06 09:43:31 <CIA-75> freesmartphone.org: 03ptitjes 07specs * r7b61d8811368 10/otapi/org.freesmartphone.GSM.Call.xml.in: 
May 06 09:43:31 <CIA-75> freesmartphone.org: Rename 'call_status' to 'call_details' and rename CallStatusEnum
May 06 09:43:31 <CIA-75> freesmartphone.org: Signed-off-by: Didier 'Ptitjes <ptitjes@free.fr>
May 06 09:43:32 <shoragan> what are the problems with the current api?
May 06 09:43:57 <ptitjes> I think we spoke about it some weeks ago:
May 06 09:44:40 <ptitjes> - the fact there is no Phone.incoming, outgoing and that Phone.Call.incoming and outgoing are void
May 06 09:45:12 <ptitjes> - adding call management at that level (hold, join, ...)
May 06 09:45:38 <ptitjes> - call rerouting at that level also
May 06 09:46:51 <shoragan> yes
May 06 09:47:01 <CIA-75> freesmartphone.org: 03ptitjes 07libfso-glib * rf9551ac7c7cd 10/src/freesmartphone-gsm.vala: 
May 06 09:47:01 <CIA-75> freesmartphone.org: Report call status renaming accordingly
May 06 09:47:01 <CIA-75> freesmartphone.org: Signed-off-by: Didier 'Ptitjes <ptitjes@free.fr>
May 06 09:47:21 <shoragan> my take on the phone interface is to take it as display+buttons on a featurephone
May 06 09:48:11 <ptitjes> shoragan: you mean that it should really be close to what the gui offers ?
May 06 09:48:22 <ptitjes> shoragan: if yes I do aggree
May 06 09:48:25 <shoragan> yea
May 06 09:48:45 <shoragan> i got that idea when implementing support for the BT headset buttons
May 06 09:49:07 <shoragan> i wanted some dbus call to "Accept currently ringing call" or "hangup current call"
May 06 09:49:28 <shoragan> without knowing what the current call really is
May 06 09:56:04 <Ainulindale> ptitjes: resend your mail
May 06 09:56:08 <Ainulindale> you replied to me only
May 06 09:56:18 <ptitjes> arf
May 06 09:56:27 <Ainulindale> shoragan, alphaone, mickey|zzZZzz : still waiting for your opinion
May 06 09:57:56 <ptitjes> resent
May 06 09:58:08 <ptitjes> Ainulindale: hello btw
May 06 09:58:40 <shoragan> Ainulindale, who would call these methods? (i.e. org.shr.ophonekitd.Messages.DisplayMessage(int messageId))
May 06 09:59:19 <Ainulindale> All the apps which want to interact with the UI telephony stack
May 06 09:59:26 <Ainulindale> plus ophonekitd
May 06 10:00:41 <shoragan> why would you do it all in one process?
May 06 10:01:07 <Ainulindale> Because we need one daemon to listen to frameworkd events
May 06 10:01:17 <Ainulindale> And it's just easier with one process
May 06 10:01:41 <shoragan> but the messages app is only interested in message events
May 06 10:01:48 <shoragan> and dailer probably only in calls
May 06 10:01:57 <shoragan> so it's rather orthogonal
May 06 10:02:03 <Ainulindale> That's the point
May 06 10:02:13 <Ainulindale> ophonekitd handles events from frameworkd
May 06 10:02:22 <Ainulindale> and the -dialer library only handle calls
May 06 10:02:37 <shoragan> why the intermidiary ophonekit?
May 06 10:02:48 <Ainulindale> because it's the event dispatcher
May 06 10:02:53 <Ainulindale> because we can have multiple UIs
May 06 10:03:02 <shoragan> if the call api is not good enough for a dialer, then we should fix it
May 06 10:03:03 <Ainulindale> with priorities or contextual choices
May 06 10:03:10 <shoragan> ah, ok
May 06 10:03:18 <Ainulindale> shoragan: don't get me wrong
May 06 10:03:21 <Ainulindale> the call library will use frameworkd
May 06 10:03:26 <Ainulindale> and will use its api
May 06 10:03:39 <Ainulindale> ophonekitd is there to map the event CallStatus with the good UI
May 06 10:03:41 <Ainulindale> and the good window
May 06 10:03:48 <Ainulindale> according to the context & the UI chosen by the user
May 06 10:03:57 <Ainulindale> which may depend on external conditions
May 06 10:04:10 <Ainulindale> or geolocalization, or state of the accelerometers, or battery, or whatever
May 06 10:04:22 <shoragan> have you looked at the stuff google/android does with "intents"?
May 06 10:04:28 <Ainulindale> nope
May 06 10:04:32 <shoragan> please do
May 06 10:04:41 <Ainulindale> Could you say so on the ML? :-)
May 06 10:04:44 <Ainulindale> With references? :-)
May 06 10:05:04 <shoragan> later, after telco
May 06 10:05:10 <Ainulindale> ok thanks! :-)
May 06 10:06:27 <shoragan> http://developer.android.com/reference/android/content/Intent.html
May 06 10:06:56 <shoragan> http://developer.android.com/guide/topics/intents/intents-filters.html
May 06 10:12:09 <PaulFertser> shoragan: Hey :) Can you give me a hint what else is needed to get BT headset work except modifying phone preferences (specify addr and enable it) and ensure proper rules.yaml?
May 06 10:14:04 <shoragan> enable bluetooth?
May 06 10:15:37 <PaulFertser> shoragan: it looks like frameworkd checks for BT headset presence every 10 seconds until bluetoothd reports it's there and after that it should "just work". But i haven't tried it myself, it's pure speculation based on my understanding of the code. It'd be nice if you did a quick review of the wiki section: http://wiki.openmoko.org/wiki/Manually_using_Bluetooth#Once_Again.2C_Bluetooth_Headset_on_Freerunner
May 06 10:16:19 <shoragan> yes, that's the way it should work
May 06 10:16:54 <shoragan> to enable bt please use the resource api
May 06 10:17:31 <PaulFertser> Resource API!
May 06 10:17:46 <shoragan> errr usage ;)
May 06 10:17:49 <shoragan> sry
May 06 10:18:17 <shoragan> bluetoothd should already be running on that image
May 06 10:18:27 <shoragan> or be started via dbus-activation
May 06 10:18:44 <PaulFertser> And not org.freesmartphone.Device.PowerControl.SetPower?
May 06 10:19:23 <PaulFertser> Obviously if bluetoothd wasn't running, the guy couldn't have paired his headset.
May 06 10:19:52 <shoragan> but bluetoothd won't know how to power up the bt device
May 06 10:20:16 <shoragan> PaulFertser, if you use ousaged at all then use it for everything
May 06 10:20:26 <PaulFertser> Yep, most people use SHR Setting for that. And after bt is powered, it's immediately recognised by the bluetoothd.
May 06 10:20:43 <shoragan> org.freesmartphone.Device.PowerControl.SetPower is stateless and so will interfere with control by ousaged
May 06 10:21:01 <shoragan> shr settings uses ousaged, i think
May 06 10:21:29 <PaulFertser> shoragan: yes, but as long as "hcitool dev" shows the device, it means it's powered. And it's easy to ensure bluetoothd is running.
May 06 10:21:55 <shoragan> yes
May 06 10:22:20 <shoragan> but i've seen cases where dbus-activation and initscripts step on each other's toes ;)
May 06 10:23:27 <PaulFertser> Shouldn't matter much as bluetoothd transparently handles bt controller disappearing/reappearing. 
May 06 10:24:11 <shoragan> ok
May 06 10:26:15 <PaulFertser> shoragan: well, thanks for the pointers. If you ever feel like you have some free time to try to help end-users use it, Digital_Pioneer at #openmoko would be glad to follow your advices (but basically he just followed the wiki section he wrote after my words (and i corrected after the latest API changes)).
May 06 10:26:20 <PaulFertser> shoragan: :)
May 06 10:36:48 <CIA-75> freesmartphone.org: 03ptitjes 07vala-dbus-binding-tool * rb6c46e162acc 10/src/vala-dbus-binding-tool.vala: 
May 06 10:36:48 <CIA-75> freesmartphone.org: Enable parameter structs description
May 06 10:36:48 <CIA-75> freesmartphone.org: Signed-off-by: Didier 'Ptitjes <ptitjes@free.fr>
May 06 10:38:38 <CIA-75> freesmartphone.org: 03ptitjes 07specs * r54e826af51c9 10/otapi/org.freesmartphone.GSM.Call.xml.in: 
May 06 10:38:38 <CIA-75> freesmartphone.org: Explicit CallDetail struct
May 06 10:38:38 <CIA-75> freesmartphone.org: Signed-off-by: Didier 'Ptitjes <ptitjes@free.fr>
May 06 10:38:56 <CIA-75> freesmartphone.org: 03ptitjes 07libfso-glib * r0605fce6be5e 10/src/freesmartphone-gsm.vala: 
May 06 10:38:56 <CIA-75> freesmartphone.org: Explicit CallDetail struct
May 06 10:38:56 <CIA-75> freesmartphone.org: Signed-off-by: Didier 'Ptitjes <ptitjes@free.fr>
May 06 10:50:33 <Ainulindale> shoragan: shr settings doesn't use ousaged
May 06 10:50:38 <Ainulindale> it uses it through ophonekitd
May 06 10:50:46 <Ainulindale> although it may be justified in some cases it's not justified per se
May 06 11:01:35 <CIA-75> freesmartphone.org: 03ptitjes 07libfso-glib * r69dddc117da6 10/ (4 files): 
May 06 11:01:35 <CIA-75> freesmartphone.org: Fixed pkgconfig name to fso-glib-1.0.pc
May 06 11:01:35 <CIA-75> freesmartphone.org: WARNING: This may break your build systems
May 06 11:01:36 <CIA-75> freesmartphone.org: Signed-off-by: Didier 'Ptitjes <ptitjes@free.fr>
May 06 11:05:06 <CIA-75> SHR: 03ptitjes 07ophonekitd * rc75089d3733b 10/configure.ac: Fixed pkgconfig names of some dependencies
May 06 11:09:34 <alexxy> mrmoku: Ainulindale: some parts of feed missing
May 06 11:09:40 <alexxy> like cellhunter
May 06 11:09:57 <alexxy> libframeworkd-phonegui-efl2
May 06 11:10:02 <alexxy> and others
May 06 11:13:34 <ptitjes> mickey|zzZZzz: may I update master of vala-lang.git ?
May 06 11:14:48 <mickey|zzZZzz> ptitjes: already done ;)
May 06 11:15:45 <ptitjes> mickeyl: thanks
May 06 11:17:01 <ptitjes> mickeyl: did you see that ? http://git.freesmartphone.org/?p=specs.git;a=commitdiff;h=4214e36ddd050baeb896cfd4e08e368955338b7a
May 06 11:17:49 <mickeyl> nice
May 06 11:18:35 <ptitjes> mickeyl: I also regenerated libfso-glib accordingly
May 06 11:19:09 <ptitjes> mickeyl: so you have you error example here: http://git.freesmartphone.org/?p=libfso-glib.git;a=blob;f=src/freesmartphone-gsm.vala;h=9dd6e26c24ddf85b23bb70cf4e2edd7d288c145d;hb=HEAD
May 06 11:19:40 <ptitjes> mickeyl: also I fixed dbus-experimental to properly report missing throws DBus.Error clause
May 06 11:19:44 <methril|work> good morning
May 06 11:19:56 <mickeyl> ptitjes: good job, thanks. can't wait to play with that
May 06 11:19:57 <mickeyl> morning methril|work 
May 06 11:20:32 <mrmoku> alexxy: feed does not build completely... due to errors on ewl
May 06 11:20:40 <methril|work> mickeyl: i've some questions about python (i'm a litle bit "newbie" to python, or i think in C, not in python)
May 06 11:20:49 <mickeyl> i'm in a telco atm.
May 06 11:20:53 <mickeyl> later please
May 06 11:20:58 <methril|work> ok
May 06 11:21:04 <mrmoku> alexxy: config.status: error: cannot find input file: po/Makefile.in.in
May 06 11:21:33 <CIA-75> freesmartphone.org: 03ptitjes 07libfso-glib * r63c60c1c0e88 10/src/Makefile.am: 
May 06 11:21:33 <CIA-75> freesmartphone.org: Fix vapi name to fso-glib-1.0.vapi
May 06 11:21:33 <CIA-75> freesmartphone.org: WARNING: This may break you build systems
May 06 11:21:33 <CIA-75> freesmartphone.org: Signed-off-by: Didier 'Ptitjes <ptitjes@free.fr>
May 06 11:23:00 <CIA-75> SHR: 03ptitjes 07ophonekitd * r91cc83fdba06 10/src/Makefile.am: Fix fso-glib-1.0 vala package name
May 06 11:23:21 <methril|work> you need vala in order to build vala from OE?
May 06 11:23:27 <methril|work> s/vala/valac
May 06 11:25:22 <mrmoku> yep, you need valac to build vala from git
May 06 11:27:42 <mrmoku> Ainulindale: any idea what needs ewl?
May 06 11:29:52 <mrmoku> ok found it... omview
May 06 11:33:14 <CIA-75> SHR: 03ptitjes 07ophonekitd * r3cbfe205b770 10/src/ (3 files): Use libfso-glib call status enum
May 06 11:58:29 <CIA-75> freesmartphone.org: 03ptitjes 07specs * r5f6282b43fe5 10/otapi/org.freesmartphone.GSM.SIM.xml.in: 
May 06 11:58:29 <CIA-75> freesmartphone.org: Introduce SIMAuthStatus enumeration
May 06 11:58:29 <CIA-75> freesmartphone.org: Signed-off-by: Didier 'Ptitjes <ptitjes@free.fr>
May 06 11:59:06 <CIA-75> freesmartphone.org: 03ptitjes 07libfso-glib * r734b0d945146 10/src/freesmartphone-gsm.vala: 
May 06 11:59:06 <CIA-75> freesmartphone.org: Introduce SIMAuthStatus enumeration
May 06 11:59:06 <CIA-75> freesmartphone.org: Signed-off-by: Didier 'Ptitjes <ptitjes@free.fr>
May 06 12:00:31 <CIA-75> SHR: 03ptitjes 07ophonekitd * r73bfa0f92598 10/src/ophonekitd-phonegui.vala: Use libfso-glib's SIMAuthStatus enumeration
May 06 12:06:49 <morphis> heyho
May 06 12:13:39 <Ainulindale> mrmoku: about zenity
May 06 12:13:41 <Ainulindale> remove it from the feed
May 06 12:20:03 <max_posedon> Ainulindale, about remoko, when it will be fixed? (or you even doesn't know that it is not working)
May 06 12:21:45 <CIA-75> freesmartphone.org: 03ptitjes 07specs * r69014c708af4 10/odevice/org.freesmartphone.Device.IdleNotifier.xml.in: 
May 06 12:21:45 <CIA-75> freesmartphone.org: Introduce IdleState enumeration
May 06 12:21:45 <CIA-75> freesmartphone.org: Signed-off-by: Didier 'Ptitjes <ptitjes@free.fr>
May 06 12:21:58 <CIA-75> freesmartphone.org: 03ptitjes 07libfso-glib * ra419e92f6acd 10/src/freesmartphone-device.vala: 
May 06 12:21:58 <CIA-75> freesmartphone.org: Introduce IdleState enumeration
May 06 12:21:58 <CIA-75> freesmartphone.org: Signed-off-by: Didier 'Ptitjes <ptitjes@free.fr>
May 06 12:22:46 <mrmoku> Ainulindale: yeah, already did that yesterday :P
May 06 12:23:10 <mrmoku> ptitjes: ping
May 06 12:23:20 <ptitjes> mrmoku: pong
May 06 12:23:25 <CIA-75> SHR: 03ptitjes 07ophonekitd * rdaa75a5e1e1b 10/src/ophonekitd-idle-suspend.vala: Use libfso-glib's IdleState enumeration
May 06 12:23:28 <Deubeuliou> Lu' Didier
May 06 12:23:32 <mrmoku> ptitjes: what's the state of pending-upstream-move today?
May 06 12:23:37 <ptitjes> Salut David
May 06 12:23:43 <ptitjes> mrmoku: good
May 06 12:23:45 <ptitjes> :)
May 06 12:23:54 <mrmoku> as good as yesterday? or better ;)
May 06 12:23:59 <ptitjes> mrmoku: I just rebased it on master some minutes ago
May 06 12:24:04 <ptitjes> mrmoku: better :)
May 06 12:24:17 <Deubeuliou> so you come at Bearstech's tommorrow ?
May 06 12:24:21 <mrmoku> hmmm... having problems with mickey/0.7/posix now...
May 06 12:24:29 <ptitjes> mrmoku: there was a deprecated error on sqlite3.vapi that made ophonekitd build fail
May 06 12:24:38 <mrmoku> and on day or the other I would just like to complete the feed :(
May 06 12:24:57 <mrmoku> one day even...
May 06 12:24:58 <ptitjes> mrmoku: what problems with mickey/0.7/posix ?
May 06 12:25:38 <mrmoku> ahh...looking at the log helps sometimes... don't like it so
May 06 12:25:42 <mrmoku> it says valac not found
May 06 12:26:48 <mrmoku> bad... I guess building vala-native from git won't work twice
May 06 12:27:01 <mrmoku> because the second time it gets unstaged first... and thus no valac
May 06 12:27:08 <mrmoku> mickeyl: ping. can that be?
May 06 12:27:57 <mrmoku> and it won't rebuild vala-bootstrap-native... because it thinks it is already there
May 06 12:29:42 <ptitjes> mrmoku: this is not related to mickey/0.7/posix ??
May 06 12:29:52 <ptitjes> mrmoku: this is a OE problem ?
May 06 12:30:22 <mrmoku> yeah
May 06 12:31:07 <ptitjes> mrmoku: I'm afraid I'll be of no help on that :(
May 06 12:32:51 <mrmoku> ptitjes: I switched to mickey/0.7/posix, because pending-upstream-move had problems...
May 06 12:32:57 <mrmoku> are those fixed? can I switch back?
May 06 12:33:09 <ptitjes> mrmoku: what problems ?
May 06 12:33:17 <mrmoku> stuff did not build...
May 06 12:33:24 <ptitjes> please help me
May 06 12:33:38 <ptitjes> this builds with no problem here
May 06 12:34:29 <mrmoku> let me check my bip.log...
May 06 12:34:56 <CIA-75> freesmartphone.org: 03ptitjes 07specs * r14bc7a0d1de9 10/odevice/org.freesmartphone.Device.PowerSupply.xml.in: 
May 06 12:34:56 <CIA-75> freesmartphone.org: Introduce PowerStatus enumeration
May 06 12:34:56 <CIA-75> freesmartphone.org: Signed-off-by: Didier 'Ptitjes <ptitjes@free.fr>
May 06 12:35:05 <CIA-75> freesmartphone.org: 03ptitjes 07libfso-glib * r28f8a574abd5 10/src/freesmartphone-device.vala: 
May 06 12:35:05 <CIA-75> freesmartphone.org: Introduce PowerStatus enumeration
May 06 12:35:05 <CIA-75> freesmartphone.org: Signed-off-by: Didier 'Ptitjes <ptitjes@free.fr>
May 06 12:35:49 <CIA-75> SHR: 03ptitjes 07ophonekitd * ra963b3b52286 10/src/ophonekitd-idle-suspend.vala: Use libfso-glib's PowerStatus enumeration
May 06 12:36:09 <mrmoku> ptitjes: dbus-hlid was not building
May 06 12:36:26 <ptitjes> mrmoku: that is fixed
May 06 12:36:40 <mrmoku> ok, will try to switch back then
May 06 12:36:47 <ptitjes> mrmoku: dbus-hlid was missing some throws clauses and valac did not report it correcly
May 06 12:37:25 <ptitjes> mrmoku: pffff you made me sweat
May 06 12:37:36 <ptitjes> :)
May 06 12:38:13 <mrmoku> ptitjes: switched back and building now...
May 06 12:38:31 <ptitjes> mrmoku, Ainulindale: I think I removed all the fso-related constants in ophonekitd/vala, they all moved to libfso-glib
May 06 12:38:49 <ptitjes> mrmoku, Ainulindale: will now work on moving the errors
May 06 12:40:01 <ptitjes> mrmoku: oh and btw: http://git.freesmartphone.org/?p=libfso-glib.git;a=blob;f=src/freesmartphone-pim.vala;h=9d1fa6dd9b461f1887d2ed340f7c8fabcc4ec00c;hb=44c32a8a0aae9306a319ca8edd42c24838a5ced0
May 06 12:40:15 <ptitjes> mrmoku: much thank to you
May 06 12:45:03 <mrmoku> ptitjes: it is still missing stuff... errors for example
May 06 12:52:03 <ptitjes> mrmoku: hum but you did not follow the new xml syntax :)
May 06 12:53:31 <ptitjes> mrmoku: oh sorry. you meant that you did not add the errors to the spec, right ?
May 06 12:53:40 <mrmoku> ptitjes: yep
May 06 12:53:46 <mrmoku> what new xml syntax?
May 06 12:54:06 <mrmoku> for the error enums you did?
May 06 12:54:28 <ptitjes> mrmoku: this for errors: http://git.freesmartphone.org/?p=specs.git;a=commitdiff;h=4214e36ddd050baeb896cfd4e08e368955338b7a
May 06 12:54:51 <ptitjes> mrmoku: this for enums: http://git.freesmartphone.org/?p=specs.git;a=commitdiff;h=14bc7a0d1de98a428a1fff4074ce757fffd3be94
May 06 12:55:03 <ptitjes> mrmoku: do you like it ? :)
May 06 12:56:40 <playya> ptitjes, which of you branches is needed to compile libmodulo
May 06 12:57:15 <ptitjes> playya: everything must now be built with pending-upstream-move
May 06 12:57:42 <playya> mkay
May 06 12:57:54 <playya> the i'l wait for that move
May 06 12:58:15 <ptitjes> playya: why N
May 06 12:58:16 <ptitjes> ?
May 06 12:58:37 <playya> it is in valas main repo?
May 06 12:58:49 <ptitjes> playya: not yet
May 06 12:59:09 <ptitjes> playya: but this is why we do have our own repo, to let time to Jürg to integrate the stuff
May 06 12:59:18 <ptitjes> playya: and also for that stuff to be tested enough
May 06 12:59:31 <ptitjes> playya: I would be glad if you just use that branch
May 06 12:59:43 <playya> yes. but i'l need gir-writing git-reading?
May 06 13:00:18 <playya> i'm currently using master. but this branch doesn't have a --gir flag
May 06 13:00:33 <ptitjes> playya: every topic branches (gir-writing, gir-parsing, dbus-experimental and mickey/0.7/posix) are united in pending-upstream-move
May 06 13:01:16 <ptitjes> playya: and there is nothing else above master in pending-upstream-move than those topic branches
May 06 13:02:01 <ptitjes> playya: I don't know if my last sentences were clear enough...
May 06 13:03:45 <ptitjes> mrmoku: I need your inspiration
May 06 13:04:34 <ptitjes> playya: also if you want to play
May 06 13:04:44 <ptitjes> see http://git.shr-project.org/git/?p=libmodulo.git;a=blob;f=src/modulo-api.vala;h=1c731fbefa5d024315e1969e4b3ce807be60196a;hb=HEAD#l41
May 06 13:05:26 <ptitjes> I define two (among others) interfaces for services to be initialized and disposed (Initializable and Disposable)
May 06 13:05:46 <ptitjes> playya, mrmoku: I need an alternative verb for disposal
May 06 13:06:00 <ptitjes> because GLib.Object already defines a virtual dispose()
May 06 13:06:13 <ptitjes> playya, mrmoku: any idea ?
May 06 13:07:20 <mrmoku> hmm
May 06 13:07:26 <raster> hmmm
May 06 13:08:09 <playya> add new!
May 06 13:09:36 <mrmoku> ptitjes: remove... garbage... clear... eliminate
May 06 13:09:46 <ptitjes> playya: if I had new, that method won't be called in place of GLib.Object.dispose ?
May 06 13:10:22 <mrmoku> ptitjes: what exactly is it doing?
May 06 13:10:56 <ptitjes> mrmoku: implementors will do used resources disposal in that method
May 06 13:12:07 <mrmoku> release_resources... dispose_resources
May 06 13:13:02 <ptitjes> hum release is nice
May 06 13:13:25 <ptitjes> Releaseable
May 06 13:14:35 <ptitjes> ok Releasable.release()
May 06 13:15:20 <mrmoku> Ainulindale: shouldn't task-shr-feed.bb include all stuff... also what gets built with the images?
May 06 13:15:56 <mrmoku> Ainulindale: if people (like me) do not build the fat image... they will miss stuff
May 06 13:19:52 <playya> i just looked at the .bb for libframework-phonegui-efl2 but theres no SRC_URI
May 06 13:19:58 <CIA-75> SHR: 03ptitjes 07libmodulo * r7595738eea64 10/samples/ (3 files): Use support for dbus enumerations and errors in the samples
May 06 13:20:21 <playya> i want to test a patch. but where should i add it?
May 06 13:20:28 <mrmoku> playya: where are you looking?
May 06 13:21:17 <mrmoku> http://git.shr-project.org/git/?p=shr-overlay.git;a=blob;f=openembedded/recipes/shr/libframeworkd-phonegui-efl2_git.bb;h=0cbd0b2f0937840bad13043986a9197aa745eb15;hb=5ef5206eb03ae9f38228deb2b04ff8896a971d51
May 06 13:21:21 <playya> shr/openembedded/packages/libframeworkd-phonegui-efl/libframeworkd-phonegui-efl_git.bb
May 06 13:21:40 <mrmoku> playya: that is *not* efl2
May 06 13:21:49 <mrmoku> and gets its SRC_URI via the shr.class
May 06 13:21:57 <playya> ok
May 06 13:22:11 <mrmoku> playya: and if you still have packages ... you should update ;)
May 06 13:22:19 <mrmoku> it is called recipes now
May 06 13:22:39 <mrmoku> playya: what patch do you have?
May 06 13:22:47 <playya> i know. i used git pull
May 06 13:22:54 <playya> its not ready yet
May 06 13:23:00 <mrmoku> but what will it do?
May 06 13:23:22 <CIA-75> SHR: 03ptitjes 07libmodulo * r7eeee709f697 10/ (6 files in 2 dirs): Rename Disposable.dispose() to Releasable.release()
May 06 13:23:26 * mrmoku wants to avoid doubled work
May 06 13:23:53 <playya> its a patch for message view. i search for numbers to add a anchor to SMS, call, add to contacts
May 06 13:24:10 <mrmoku> playya: ahh, ok :-)
May 06 13:24:37 <spaetz> sounds useful
May 06 13:25:12 <playya> I'm using this regex: "^(\\+|0|00)?[[:digit:]]{3,31}$"
May 06 13:25:49 <playya> but i have to split the message first. not the best thing but should work
May 06 13:26:10 <playya> GRegex.replace isn't flxible enough
May 06 13:30:56 <CIA-75> SHR: 03ptitjes 07ophonekitd * r53d4c753f08f 10/src/ (6 files): Rename Disposable.dispose() to Releasable.release()
May 06 13:33:22 <spaetz> while you are doing UI work :-)
May 06 13:33:36 <spaetz> the buttons are really not optimally ordered and named
May 06 13:34:10 <spaetz> e.g. in the contact app, it doesn't make sense to have the first button be "new", but hide a "dlelete" under options
May 06 13:34:37 <spaetz> I'd rather have "call" and "sms" first (most often used) and put "New" under options
May 06 13:35:16 <TAsn> spaetz, ++
May 06 13:35:16 <spaetz> and even better call people with a double click on thir entry.
May 06 13:35:23 <TAsn> spaetz, --
May 06 13:35:31 <spaetz> :)
May 06 13:35:42 <TAsn> btw, I think buttons are too big
May 06 13:35:53 <TAsn> and the order lacks consistency
May 06 13:36:08 <spaetz> well, it needs to be finger friendly
May 06 13:36:15 <spaetz> Fully agreed on the consistency part
May 06 13:36:31 <spaetz> but we might not need to show all buttons at all times.
May 06 13:36:53 <TAsn> spaetz, aye.
May 06 13:37:13 <TAsn> I like the popping extra buttons ("Other") it's a good idea
May 06 13:37:18 <TAsn> though as you said, the order is bad.
May 06 13:37:28 <TAsn> the most commonly used are hidden there
May 06 13:37:34 <spaetz> yep
May 06 13:37:50 <TAsn> btw
May 06 13:37:54 <TAsn> I like sliding a lot
May 06 13:38:00 <spaetz> I never use that "new" thing for example. When I add a new contact it is usually from an incoming call or sms
May 06 13:38:18 <TAsn> I mean, sliding your finger to the right on the contact list should do something (maybe fast scroll?)
May 06 13:38:24 <TAsn> same for moving to the seft.
May 06 13:38:38 <TAsn> spaetz, well, you can't add from an incoming call atm ;]
May 06 13:38:57 <spaetz> sounds nice, I just don't know what the framework offers (e)
May 06 13:39:19 <TAsn> spaetz, raster is very extensible ;]
May 06 13:39:21 <spaetz> yeah, from phonelog :)
May 06 13:39:29 <spaetz> at least should be able :)
May 06 13:39:44 <TAsn> spaetz, I also used this feature a lot (on my nokia)
May 06 13:40:39 <TAsn> bah, after trying to debug why there's a contact name that's not identified when I get an incoming call
May 06 13:40:43 <TAsn> I finally figured it out
May 06 13:40:47 <methril|work> mickeyl: are you available now?
May 06 13:40:49 <TAsn> I add the wrong number ;]
May 06 13:40:54 <TAsn> added*
May 06 13:41:28 <spaetz> consistency:I just see that in the dialer app we have a "More" in the middle and "call" on the right side
May 06 13:41:37 <spaetz> Should have the same ordering as in the contact app
May 06 13:42:09 <spaetz> and no close button in the dialer, we don't have that in the other apps either
May 06 13:42:13 <TAsn> yeah
May 06 13:42:23 * spaetz is afraid he will have to dive into that C code at some point
May 06 13:42:41 <TAsn> "More" should always be on the right, since it's the "hardest" part to get to on the screen.
May 06 13:42:51 * spaetz nods
May 06 13:42:56 <TAsn> spaetz, nah, they are porting it to vala, you will have to dive in that C code at some point ;[
May 06 13:42:59 <methril|work> spaetz: i prefer C than python (i'm, more confortable)
May 06 13:43:00 <TAsn> meant ;]
May 06 13:43:39 <spaetz> I'd give it a go if there was some vala port already. But digging into that C code feels like waste of energy
May 06 13:43:39 <TAsn> methril|work, I prefer C for everything except for quick hacks, that's where I prefer python ;]
May 06 13:43:48 <TAsn> though I think that's mostly because I'm not a python expert.
May 06 13:44:08 <methril|work> neither do i
May 06 13:44:28 <methril|work> i 'm trying to improve my knowledge in python
May 06 13:44:44 <TAsn> ffs, where's my python-libmokoui2?! dos1?! ;]
May 06 13:44:51 <TAsn> bah, the phonelog sucks when it's not there.
May 06 13:45:10 <methril|work> TAsn: maybe you could help me as you like C, and know python :)
May 06 13:45:25 <TAsn> methril|work, I only know a little python.
May 06 13:45:31 <TAsn> Though actually my problem is free time atm
May 06 13:45:38 <TAsn> I have a major test tomorrow
May 06 13:45:44 <TAsn> and a big todo list.
May 06 13:45:53 <TAsn> methril|work, though, what do you need?
May 06 13:46:08 <methril|work> hehehehe everybody has a free-time-problem :)
May 06 13:46:40 <TAsn> yep ;]
May 06 13:46:55 <TAsn> I waste most of mine on work+exams+moko dev ;]
May 06 13:47:08 <methril|work> i'm trying to parse some binary data. In C is easy with struct and keeps the code readable. But in python i don't know how to define a class to easy access to that fields of the variable.
May 06 13:47:29 <methril|work> or if i use struct pack & unpack to generate the binary data....
May 06 13:47:31 <TAsn> methril|work, hm.. first of all, iirc there's a ctype python module
May 06 13:47:55 <TAsn> though anyhow, just look at the accelerometer python example script, I think there's a simple way to do that there.
May 06 13:48:06 <methril|work> yes, but i don't klnwo how to initialize properly the desired field with a constructor and pointer data
May 06 13:49:08 <TAsn> methril|work, no idea here as well.
May 06 13:49:14 <TAsn> sorry.
May 06 13:49:18 <methril|work> no problem
May 06 13:49:19 <TAsn> anyhow, I'm off, back to studying.
May 06 13:49:29 <methril|work> i was askin mickeyl, as he's a python master :)
May 06 13:49:40 <methril|work> TAsn: good luck in your exams
May 06 13:49:49 <TAsn> thanks. ;]
May 06 13:49:53 <TAsn> let's wish.
May 06 13:59:06 <methril|work> i've to go home, bbl
May 06 14:01:53 <mickeyl> methril|work: take a look at ogpsd
May 06 14:01:59 <mickeyl> we're using the struct module there
May 06 14:02:07 <mickeyl> alternatively you can also use the ctypes module
May 06 14:02:12 <mickeyl> but struct should be simpler
May 06 14:05:12 <Ainulindale> mickeyl: still waiting for your reply ;-)
May 06 14:05:18 <Ainulindale> Don't be as lazy as I am!
May 06 14:05:47 <mickeyl> i'm not lazy, i'm buried in this bug and can't think about much other things.
May 06 14:06:07 <mickeyl> i'll catch up with mail later tonite
May 06 14:07:14 <Ainulindale> No problem :-)
May 06 14:07:18 <Ainulindale> Just making sure you don't forget :-)
May 06 14:10:48 <ptitjes> mickeyl: what bug ?
May 06 14:11:10 <mickeyl> FSO #416
May 06 14:11:16 <mickeyl> superstrange things happenning here
May 06 14:11:26 <mickeyl> dbus replies getting... "lost"
May 06 14:13:32 <ptitjes> mickeyl: you seem to have identified the fault code
May 06 14:13:42 <ptitjes> the code that fails
May 06 14:14:18 <CIA-75> freesmartphone.org: 03mickey 07framework * ra1737528e70c 10/ (2 files in 2 dirs): 
May 06 14:14:18 <CIA-75> freesmartphone.org: Revert "odeviced: fix idlenotifier" for now
May 06 14:14:18 <CIA-75> freesmartphone.org: This reverts commit 516f48762ab7afa4e4702a0ba01bc0a004ae4c60 which -- for a reason yet unknown --
May 06 14:14:18 <CIA-75> freesmartphone.org: exposes FSO #416.
May 06 14:15:16 <SHR-WugBranler`> tracfeed: Ticket #426 (opendoom + duke3d) created <http://trac.shr-project.org/trac/ticket/426>
May 06 14:30:30 <sepultina> hallo
May 06 14:31:12 <sepultina> I do a big update on my SHR testing system...
May 06 14:32:28 <sepultina> Are the ipk files after downloading saved in a temporary folder?
May 06 14:32:51 <sepultina> Is this right? 
May 06 14:34:24 <sepultina> and after an reboot they are gone?
May 06 14:45:39 <sepultina> hmm, after upgrade and rebooting i have some problem whit the GSM connection.
May 06 14:47:58 <sepultina> And when i start the Settingsmanager i have a massage "ophonekitd is not runnig!"
May 06 14:49:45 <spaetz> if you updated from an shr-testing which is quit old, upgrading won't work
May 06 14:51:04 <spaetz> you'll have to reflash then
May 06 15:08:00 <sepultina> spaetz: Thanks
May 06 15:09:25 <CIA-75> SHR: 03seba.dos1 07sh * r006e605fb6ba 10/libframeworkd-phonegui-efl/src/view/message-show-view.c: libframeworkd-phonegui-efl: finally fix the 'Messages show wrong time' issue
May 06 15:11:24 <spaetz> dos1: do we need to fix phonegui.-efl AND efl2 now?
May 06 15:11:33 <mrmoku> yep
May 06 15:11:43 <spaetz> or what is the plan with respect to tat fork?
May 06 15:11:47 <dos1> have i access to efl2 repo?
May 06 15:11:48 <spaetz> that fork
May 06 15:11:50 <spaetz> ok
May 06 15:12:01 <dos1> spaetz: efl2 is opimd based efl1 ;)
May 06 15:12:28 <spaetz> mrmok: I haven't seen your "use localtime patch" in efl2
May 06 15:12:30 <spaetz> :)
May 06 15:12:42 <mrmoku> no?
May 06 15:12:45 <spaetz> darn, my vserver is crappy slow today, I can hardly type
May 06 15:12:57 <spaetz> last change 4 days ago in efl2,
May 06 15:13:03 <spaetz> ahh, yes it is in there
May 06 15:13:05 <mrmoku> dos1: will do the view...
May 06 15:13:09 <mrmoku> spaetz: no it is not :P
May 06 15:13:11 <spaetz> sorry, I was jsut blind
May 06 15:13:17 <mrmoku> I fixed the list... and forgot the view
May 06 15:13:19 <spaetz> mmh
May 06 15:13:28 <spaetz> ok then :)
May 06 15:13:44 <mrmoku> have some stuff to commit anyway... will do later
May 06 15:14:05 <dos1> i will play today with opimd shr-settings module
May 06 15:14:35 <dos1> mrmoku: btw... PIN is still wrong with efl2 :(
May 06 15:14:48 <dos1> with efl1 it works ok
May 06 15:15:09 <mrmoku> dos1: hmm... didn't you say it worked in the end?
May 06 15:15:15 <dos1> mrmoku: no, i didn't
May 06 15:15:19 <dos1> it worked with efl1
May 06 15:15:37 <mrmoku> which is really strange... because I did not touch it
May 06 15:15:53 <dos1> yep... i will try to debug it
May 06 15:16:04 <mrmoku> thanks... have to do some daywork first
May 06 15:27:59 <alexxy> mrmoku: so times for messages now will be in localtime?
May 06 15:28:32 <mrmoku> alexxy: the times in the list of messages is in localtime in efl and efl2 frontends
May 06 15:29:04 <mrmoku> the view of one messages is fixed for efl (but not yet rebuilt) and will be fixed today for efl2
May 06 15:34:27 <alexxy> mrmoku: also frameworkd bug with timezones for countryes that have more then one timezone still exist
May 06 15:34:47 <dos1> alexxy: that's another bug
May 06 15:34:52 <dos1> very another :D
May 06 15:35:09 <dos1> and i think i've seen it's fixed
May 06 15:36:41 <alexxy> its not fixed
May 06 15:36:42 <alexxy> =)
May 06 15:36:59 <alexxy> at lest i still have it with shr-unstable
May 06 15:37:30 <mrmoku> alexxy: did you un-configure it in frameworkd.conf?
May 06 15:37:46 <alexxy> if i set zonesources = NONE
May 06 15:37:57 <alexxy> and set right timezoneits ok
May 06 15:38:20 <alexxy> http://dpaste.com/41462/
May 06 15:38:23 <mrmoku> that's as it is supposed to be
May 06 15:39:00 <mrmoku> getting the zone via gsm does not work for gsm operators that operate in a multi-timezone country (yet)
May 06 15:39:09 <alexxy> if frameworkd tryes to set timezone it seems take first one with right country code
May 06 15:52:35 <dos1> mrmoku: wifiman.py works with WEP ASCII passphrase in my school :) that was only that <br> issue
May 06 15:52:59 <mrmoku> dos1: time to integrate it ;)
May 06 15:53:15 <mrmoku> ahh... one thing is missing... hiddin sid
May 06 15:53:28 <mrmoku> if the sid is hidden it should ask for it...
May 06 15:53:49 <mwester> Yep.
May 06 15:54:04 <mwester> The hidden sid breaks mofi rather badly, actually... :)
May 06 15:54:12 <dos1> mrmoku: ask for ssid?
May 06 15:54:20 <mrmoku> yep
May 06 15:54:28 * mrmoku has Wifi with hidden ssid at work
May 06 15:54:40 * mwester has a wifi with hidden sid at home. 
May 06 15:54:46 <mrmoku> so I can happily try :P
May 06 15:55:26 <dos1> mrmoku: ok. but what about setting correct route?
May 06 15:55:39 <dos1> i have script "wifi":
May 06 15:56:07 <dos1> ifdown usb0; ifup eth0; ifup usb0; ifdown usb0
May 06 15:56:11 <dos1> ugly, i know
May 06 15:56:37 <dos1> but it sets correct routes and dns addresses
May 06 15:56:38 <mrmoku> dos1: don't know... IIRC correctly we started to discuss that... 
May 06 15:56:42 <dos1> it should be handled automatically
May 06 15:56:57 <mwester> use the route command; don't ifup/ifdown!
May 06 15:57:04 <mrmoku> yep... doesn't connman offer something?
May 06 15:57:31 <dos1> mwester: it's only for my laziness. i don't want to use ifup/ifdown in wifi manager, no! :D
May 06 15:58:04 <mrmoku> off for dinner now... bbl
May 06 16:36:37 <alexxy> mrmoku: Ainulindale : why not add vim and regular coreutils to feed?
**** BEGIN LOGGING AT Wed May 06 17:43:21 2009
May 06 17:44:09 <mwester> DocScrutinizer:  no C available that meets the needs; have to order. :(
May 06 17:44:29 <mwester> I thought I could use one of the buzzfix ones, but the ones I have are only 3V
May 06 17:45:57 <DocScrutinizer> mwester: I recommend using a (bi)axial type and two pieces of 2' each, for test purpose
May 06 17:46:09 <DocScrutinizer> low ESR!
May 06 17:46:19 <mwester> Really?  Isn't that inside the can?
May 06 17:46:39 <DocScrutinizer> yup it is. As I said: for TEST purpose
May 06 17:46:47 <mwester> Ah, ok :)
May 06 17:47:08 <mwester> Let me see what I have in the junk box.
May 06 17:47:23 <mwester> I presume I can pick up gnd anywhere?
May 06 17:47:31 <DocScrutinizer> mwester: and - please - don't spread the word (beyond what Dieter already posted in [hw])
May 06 17:47:37 <mwester> :)
May 06 17:48:45 <DocScrutinizer> I recommend keeping both wires bifilar (parallel maybe twisted) and connect to correct original component's contacts
May 06 17:48:51 <DocScrutinizer> (for GND)
May 06 17:49:34 * mwester looks at his local computer store's web site...  description for a C:  "Has a high capability.  Stores electrons for later use."    hehehe!  
May 06 17:49:50 <DocScrutinizer> mwester: LOL
May 06 17:50:26 <DocScrutinizer> sounds like a popular commercial here in Germany for MARS candybar
May 06 17:50:43 <mwester> pHHTT!   The "tech specs" page lists "Blue" as a spec.
May 06 17:50:58 <DocScrutinizer> omg
May 06 17:50:59 <mwester> And "Supported Languages: English"
May 06 17:51:49 <tmzt> mickeyl: I'm looking at ogsmd to see how adding cdma might work, it looks like abstractmodem is generic enough to have abstractcdmamodem built on it rather than as an alternative, although things like simready won't be used
May 06 17:54:39 <bumbl> ~seen morphis
May 06 17:54:39 <bzzbot> morphis <n=morphis@hfw-ext-wlan.rz.hs-bremen.de> was last seen on IRC in channel #openmoko-cdevel, 5h 47m 50s ago, saying: 'heyho'.
May 06 17:54:49 <bumbl> good boy bzzbot 
May 06 17:55:44 <mwester> DocScrutinizer:  where's the component placement documents?
May 06 17:56:01 <DocScrutinizer> om.com/downloads
May 06 17:56:30 <DocScrutinizer> and always in a window of my desktop ;)
May 06 17:56:40 <tmzt> mickeyl: oh I see, singlelinechannel is were the init commands are set up? so I really want to base abactcdmamodem on singleline and write my own cdmamodem channel or whatever?
May 06 17:57:10 <DocScrutinizer> mwester: also you can find for sure in people.om/joerg
May 06 17:57:29 <bumbl> DocScrutinizer: plasma's folderview
May 06 17:57:36 <bumbl> ;)
May 06 17:57:36 <mwester> Ah, yes - it was the last link that I was remembering
May 06 17:57:40 <DocScrutinizer> which is the "authoritative source"
May 06 18:16:41 <solar_george> hi, I've been trying to build gthumb image viewer using OE from the from scratch info here (http://wiki.openmoko.org/wiki/OpenEmbedded), the build is failing at DO PACKAGE QA and i was wondering if anyone could help me debug it? (build log - http://pastebin.com/m10a5efef)
May 06 18:26:16 <Sharwin_F-> made this little scipt to install packages after reflashing shr, here's the link if it's of help for someone: http://espeweb.no-ip.com/_espacio/openmoko/shr-install.sh
May 06 18:26:57 <playya> solar_george, you should have a log in /home/george/oe/build-om-gta02/tmp/work/armv4t-angstrom-linux-gnueabi/gthumb-2.6.9-r0/temp for you error
May 06 18:29:22 <solar_george> yeah (http://pastebin.com/d72746b6e) are the errors that appear there fatal then?
May 06 18:30:05 <playya> do you use your own recipe?
May 06 18:30:14 <solar_george> no
May 06 18:32:03 <playya> I'm currently building an image so I can't test it
May 06 18:32:54 <solar_george> no probs, i'm just checking the OE git server to see if the recipe's changed
May 06 18:34:27 <solar_george> nope no changed since the one i've got
May 06 18:34:49 <mrmoku> Sharwin_F-: guess what? .... it does not build :( and I don't understand (yet) why...
May 06 18:35:00 <Sharwin_F-> mrmoku, I found the problem with the library
May 06 18:35:07 <Sharwin_F-> mrmoku, names are changed
May 06 18:35:31 <Sharwin_F-> mrmoku, in /usr/lib: $ ls | grep libehal
May 06 18:35:31 <Sharwin_F-> libehal-ver-pre-svn-01.so.0
May 06 18:35:31 <Sharwin_F-> libehal-ver-pre-svn-01.so.0.5.0
May 06 18:35:47 <Sharwin_F-> so I've to link all the libraries
May 06 18:35:56 <Sharwin_F-> mrmoku, may that be the problem when building
May 06 18:36:06 <Sharwin_F-> dependencies have changed name?
May 06 18:40:57 <mrmoku> Sharwin_F|away: lrwxrwxrwx 1 shr shr     32 May  6 15:38 INSTALL -> /usr/share/automake-1.10/INSTALL
May 06 18:41:05 <mrmoku> that's the problem :(
May 06 18:43:11 <solar_george> <playya> do you reckon i should try to fix each error that appears manually?
May 06 18:43:41 <playya> you can write a patch for it and add it to SRC_URI
May 06 18:47:43 <solar_george> I wouldn't know how to stop the .debug directory appearing where it doesn't belong
May 06 19:12:27 <dos1> mrmoku: i have listing all domains, backends and setting some backend as default in some domain in shr-settings
May 06 19:12:53 <dos1> and checkbox for backend being enabled, which i'm programming now
May 06 19:13:21 <mrmoku> dos1: great... and I have the autotools blues :(
May 06 19:15:43 <DocScrutinizer> mrmoku: twinkle, any news?
May 06 19:17:45 <dos1> mrmoku: ok, now only two things are left in PIM shr-settings module (for now): refreshing list after setting some backend as default, and listing properties (if can add, update and delete)
May 06 19:18:19 <dos1> i would like to use elm pager without animations...
May 06 19:22:03 <mrmoku> DocScrutinizer: hehe... kidding?
May 06 19:22:23 <mrmoku> DocScrutinizer: I don't even get intone to build :(
May 06 19:22:43 <DocScrutinizer> :-/
May 06 19:23:44 <dos1> ok... i'm to lazy to do that now :P
May 06 19:23:50 <dos1> s/i'm to/i'm too/
May 06 19:23:50 <bzzbot> dos1 meant: ok... i'm too lazy to do that now :P
May 06 19:24:02 <dos1> i'll commit what i have now
May 06 19:24:35 <mrmoku> DocScrutinizer: what would you think about an 'eliminate-autotools' hacking session at FSOSHRUDCON? :P
May 06 19:25:27 <DocScrutinizer> autotools, yeah.
May 06 19:27:01 <mrmoku> intone builds nicely on my host... on the buildhost the autotools create a link for missing INSTALL to /usr/share/automake...
May 06 19:29:10 <CIA-75> SHR: 03seba.dos1 07shr-settings * rf3331651f677 10/ (shr-settings shr_settings_modules/shr_pim.py): [pim] add new module to control opimd settings
May 06 19:30:08 <BluesLee> woosh!
May 06 19:30:50 <BluesLee> markus bauer did a good job again
May 06 19:33:31 <DocScrutinizer> mrmoku: autotools is a PITA for all I know
May 06 19:33:43 <DocScrutinizer> who's markus bauer?
May 06 19:33:50 <mrmoku> tangogps me thinks...
May 06 19:33:59 <DocScrutinizer> aah
May 06 19:34:58 <DocScrutinizer> (autotools) and things get worse when qmake is involved I'm told
May 06 19:36:29 <BluesLee> mrmoku: the browser is good, really good for a first release
May 06 19:38:16 <mrmoku> DocScrutinizer: you make me hope :P
May 06 19:39:26 <mrmoku> DocScrutinizer: ccrtp fails on configure with
May 06 19:39:27 <mrmoku> configure.ac:38: error: possibly undefined macro: LT_VERSION
May 06 19:39:35 <mrmoku> again... autotools
May 06 19:39:49 <DocScrutinizer> grrrr
May 06 19:40:09 <DocScrutinizer> ccrtp a pita by itself
May 06 19:55:49 <playya> ~seen quickdev
May 06 19:55:49 <bzzbot> quickdev <n=quickdev@p5B054A61.dip.t-dialin.net> was last seen on IRC in channel #openmoko-cdevel, 70d 5h 20m 28s ago, saying: 'and for you?'.
May 06 19:55:57 <playya> :(
May 06 20:07:33 <Onen_away> Zorkman: ping
May 06 20:08:39 <onen> mrmoku: hi. some stats? mrmoku has seen 1859 cells
May 06 20:11:58 <Sharwin_F|away> BluesLee, I've made a little script before to install packages after reflashing shr, maybe it's from your interest :)
May 06 20:14:19 <bumbl> playya: quickdev seems to be dead
May 06 20:14:32 <bumbl> as Dave
May 06 20:15:01 <playya> ok.
May 06 20:15:24 <playya> quickdev= Klaus Kurzmann?
May 06 20:15:57 <bumbl> playya: nah
May 06 20:16:02 <bumbl> klaus kurzmann = mrmoku 
May 06 20:16:15 <playya> ah. juhu
May 06 20:16:18 <bumbl> quickdev = quickdev = ?
May 06 20:17:12 <playya> mrmoku, how can i add a callback for text_content in src/view/message-show-view.c
May 06 20:17:56 <ptitjes> mrmoku: build news ?
May 06 20:20:54 <ptitjes> mrmoku: did the OE stuff build well with pending-upstream-move ?
May 06 20:24:58 <DocScrutinizer> ptitjes: mrmoku mumbled curses against autotools
May 06 20:25:03 <mirko> hey
May 06 20:25:21 <ptitjes> arf
May 06 20:25:31 <mirko> how to i get the kernel-output redirect to the usb-serial device instead of the display?
May 06 20:25:43 <DocScrutinizer> ptitjes: I joined in for mere solidarity ;)
May 06 20:25:43 <mirko> do i have to pass uboot sth.?
May 06 20:25:50 <mrmoku> playya: hmm... I'm not that of an elementary expert...
May 06 20:25:58 <bumbl> mickeyl: does zhone suffer from that "delay" after phone-call-pickup too?
May 06 20:26:43 <mrmoku> ptitjes: well... I don't know... because it did not have to rebuild stuff
May 06 20:26:54 <mrmoku> ~lart autotools
May 06 20:26:55 * bzzbot hits autotools with an anvil and laughs with a contralto voice ... Haha Ha HA Ha
May 06 20:27:58 <DocScrutinizer> ~botsnack
May 06 20:27:59 <bzzbot> :), DocScrutinizer
May 06 20:28:12 <mrmoku> playya: will be back in 5min... and take a look then
May 06 20:28:19 <DocScrutinizer> bzzbot: nice bot
May 06 20:33:30 <solar_george> sorry to bother people again - i've been trying to build gthumb for my FR using "From Scratch: Bitbake" off the wiki, I found that the bitbake recipe in OE was for a sever years old version so I bodged one for the latest release but it still fails as the package qa with the (same as before) following errors - http://pastebin.com/d75a39e03 - so I assume that its a problem with the bb recipe - has anyone seen something 
May 06 20:33:30 <solar_george> like this before and have some quick hints to fix it?
May 06 20:36:17 <solar_george> bb recipe is here if anyone's interested http://pastebin.com/d71fc1845
May 06 20:43:54 <mrmoku> playya: in retrieve_callback2
May 06 20:45:28 <CIA-75> SHR: 03mok 07shr-overlay * rdec58936de9f 10/openembedded/recipes/tasks/task-shr-feed.bb: feed: add vim and emacs
May 06 20:45:41 <mrmoku> playya: src/view/message-show-view.c
May 06 20:46:07 <playya> window_swallow(win, "text_content", obj->text_content); and the add it for text_content?
May 06 20:46:36 <mrmoku> playya: yep, think so
May 06 20:47:09 <playya> ok
May 06 20:47:11 <mrmoku> playya: moment... why window_swallow?
May 06 20:47:49 <playya> which is the object for the texbox?
May 06 20:49:12 <playya> i'm not really familiar with elm...
May 06 20:49:14 <mrmoku> playya: hmm... would be data->content_entry... is not used though :P
May 06 20:49:33 <mrmoku> might be quickdev added it to the data struct and did not use it
May 06 20:49:43 <playya> yes
May 06 20:50:27 <mrmoku> playya: just try it... add it, swallow it and set the callback
May 06 20:50:51 <playya> ok
May 06 20:52:05 <playya> which parent should be used? NULL or window_evas_object_get(win)
May 06 20:55:31 <mrmoku> playya: the second
May 06 20:55:48 <solar_george> can anyone suggest how to fix http://pastebin.com/d75a39e03 while compiling gthumb
May 06 20:55:50 <m0nt0> Ainulindale, any news about the gui? may i do something?
May 06 21:37:57 <Ainulindale> m0nt0: well still waiting for opinions on the ML, yours included
May 06 21:38:51 <m0nt0> well i totally agree with everything you said, it is what was in my mind
May 06 21:39:00 <ptitjes> héhéhéhé
May 06 21:39:12 <m0nt0> so just want to code something
May 06 21:39:56 <tmzt> the dbus thing?
May 06 21:40:00 <m0nt0> ptitjes, i've tried to write the "sms-manager.vaka" but it's not useful the way i wrote it
May 06 21:41:04 <Ainulindale> m0nt0: well even if you agree, suggestions are necessary
May 06 21:41:09 <Ainulindale> even a "I agree" is interesting
May 06 21:41:20 <Ainulindale> If you feel like coding, why not start to write some things down?
May 06 21:41:28 <Ainulindale> Try to pick a functional context and elaborate on that
May 06 21:41:36 <Ainulindale> What would you do for "Dialer" for example
May 06 21:42:11 <m0nt0> yeah, i'd like to look into the vala "plugins" thing
May 06 21:42:28 <ptitjes> Ainulindale: btw I made that exercice and I was wondering whether it was too early to share that on the ML ?
May 06 21:42:35 <Ainulindale> well there I was talking about the dbus thing m0nt0 
May 06 21:42:39 <Ainulindale> that is what is necessary first
May 06 21:42:42 <Ainulindale> writing specs that is
May 06 21:42:52 <Ainulindale> ptitjes: nope it's not early
May 06 21:43:02 <Ainulindale> ptitjes: even if some people disagree it'd be a good thing to share
May 06 21:43:02 <ptitjes> good
May 06 21:43:13 <tmzt> Ainulindale: is a generic "screen manager" needed in a dbus spec/api?
May 06 21:43:31 <Ainulindale> what do you mean by screen manager?
May 06 21:43:42 <m0nt0> oh a thing came in my mind, is the FR conference call capable?
May 06 21:44:04 <Ainulindale> yes 
May 06 21:44:05 <tmzt> like "show dialer" "show incoming call" "hide dialer" "show sms received"
May 06 21:44:09 <Ainulindale> but I don't know if the framework is
May 06 21:44:12 <ptitjes> tmzt: I thought of that too I named the service Modality
May 06 21:44:32 <Ainulindale> ptitjes: what would it do?
May 06 21:44:53 <tmzt> what I really wonder is how you would integrate multiple main loops for different tool kits
May 06 21:44:57 <m0nt0> Ainulindale, i don't pretend to be conference capable now, but in the future it will be nice
May 06 21:45:12 <Ainulindale> tmzt: multiple threads
May 06 21:45:18 <tmzt> maybe it would work better to have the dbus api as the bounary between different implementations?
May 06 21:45:20 <Ainulindale> tmzt: we already do that on ophonekitd
May 06 21:45:44 <m0nt0> tmzt, no not dbus api
May 06 21:45:50 <Ainulindale> tmzt: nah, I'm not comfortable with that
May 06 21:45:57 <Ainulindale> too much overhead I'd think
May 06 21:46:04 <Ainulindale> but if you think it's doable =>
May 06 21:46:07 <Ainulindale> SAY SO ON THE ML!!!
May 06 21:46:10 <m0nt0> else you need another dbus server to stay there and listen for dbus signals
May 06 21:46:11 <Ainulindale> :-)
May 06 21:46:33 <ptitjes> Ainulindale: apps would be attributed some priority levels, some apps could take over screen on top of some other for say... incoming call 
May 06 21:46:42 <tmzt> uh, I mean efl or gtk, not as an alternative to different threads but I could really be wrong about this
May 06 21:47:03 <Ainulindale> ptitjes: I'm not sure this is a functional level by itself
May 06 21:47:32 <Ainulindale> tmzt: well I intended to create a thread per library to abstract this mainloop thing
May 06 21:47:41 <Ainulindale> I think this is the best way but I may be wrong too :-)
May 06 21:48:04 <tmzt> I guess my question is how likely are there to be gtk and efl imlementations running on the same device?
May 06 21:48:20 <Ainulindale> it happens already
May 06 21:48:25 <Ainulindale> see phonelog and phonegui
May 06 21:48:27 <Ainulindale> efl & gtk
May 06 21:48:27 <tmzt> not gtk apps and efl apps, X handles that fine
May 06 21:48:32 <tmzt> oh
May 06 21:48:32 <Ainulindale> if we want to build library out of them
May 06 21:48:39 <Ainulindale> we need to be able to abstract that
May 06 21:48:51 <Ainulindale> and we want to do that so.. :-)
May 06 21:51:36 <m0nt0> why we need to run 2 toolkit concurrently, or efl or gtk
May 06 21:51:45 <Ainulindale> we don't need to
May 06 21:51:52 <Ainulindale> the user might want to use this or that implementation of a library
May 06 21:51:56 <Ainulindale> and I don't intend to prevent him to do so
May 06 21:52:21 <m0nt0> yeah, but everything in gtk or everything in elementary
May 06 21:52:49 <Ainulindale> not with what we intend to do
May 06 21:53:01 <Ainulindale> that is, separate the UI functionnalities into functional contexts
May 06 21:53:13 <Ainulindale> you'll have a libframeworkd-phonegui-dialer for example which will implement the dialer functional context
May 06 21:53:16 <Ainulindale> it might be in gtk or efl
May 06 21:53:23 <Ainulindale> as long as you specify which version you want to use
May 06 21:53:31 <Ainulindale> then let us say you'd rather use another library for another context
May 06 21:53:42 <Ainulindale> it's up to the user in the end
May 06 21:53:52 <Ainulindale> contextual events might even act upon that
May 06 21:54:08 <Ainulindale> let us say I want to use efl in this situation but ncurses when I'm low on battery
May 06 21:55:48 <tmzt> so we can't even depend on X for stacking in that case
May 06 21:56:28 <Ainulindale> yep
May 06 21:57:21 <mickeyl> ptitjes: ping?
May 06 21:57:58 <ptitjes> mickeyl: hello
May 06 21:58:05 <m0nt0> Ainulindale, i was dreaming about curses interface ;D
May 06 21:58:14 <mickeyl> ptitjes: testing the error marshalling atm. instead of marshalling the error, the server just bails out 
May 06 21:58:15 <m0nt0> ahahahah
May 06 21:58:22 <Ainulindale> m0nt0: so did I
May 06 21:58:34 <Ainulindale> ANd I already have a mouse aware ncurses app for the FR
May 06 21:58:37 <ptitjes> mickeyl: damned
May 06 21:58:39 <Ainulindale> if you want to implement it you're welcome
May 06 21:58:44 <Ainulindale> I'd use it for sure
May 06 21:58:44 <mickeyl> ptitjes: perhaps i'm using it wrongly
May 06 21:58:49 <m0nt0> ahahah goood :D
May 06 21:58:51 <mickeyl> ptitjes: i'll pastebin the code
May 06 21:59:06 <ptitjes> mickeyl: bails out = crash ?
May 06 21:59:29 <mickeyl> no, "uncought error"
May 06 21:59:46 <mickeyl> http://rafb.net/p/SjVTa848.html
May 06 21:59:50 <mickeyl> is that wrong usage?
May 06 22:00:08 <ptitjes> mickeyl: do you have an appropriate catch clause ?
May 06 22:00:16 <mickeyl> no
May 06 22:00:20 <mickeyl> this error is supposed to be marshalled
May 06 22:00:24 <mickeyl> why should i catch it?
May 06 22:01:00 <ptitjes> mickeyl: oh you have to add MuxerError to the throws clause
May 06 22:01:19 <mickeyl> is MuxerError not derived from DBus.Error?
May 06 22:01:24 <ptitjes> hum you must have had a warning at build, didn't you ?
May 06 22:01:29 <mickeyl> no warning
May 06 22:01:43 <ptitjes> mickeyl: no real type system for GErrors
May 06 22:01:56 <ptitjes> it is plain dumb
May 06 22:02:00 <ptitjes> unfortunately
May 06 22:02:27 <mickeyl> ok, let me s/DBus.Error/MuxerError
May 06 22:02:54 <mickeyl> hmm, 
May 06 22:02:55 <mickeyl> no go
May 06 22:02:57 <ptitjes> mickeyl: and more over, it is cool because the error are typed
May 06 22:02:59 <mickeyl> now we get the familiar warning
May 06 22:03:03 <mickeyl> err
May 06 22:03:04 <mickeyl> error
May 06 22:03:10 <ptitjes> mickeyl: DBus.Error for technical errors
May 06 22:03:12 <mickeyl> src/server.vala:51.5-51.39: error: D-Bus methods must almost throw DBus.Error
May 06 22:03:12 <mickeyl>     public abstract void ReleaseChannel( string name ) throws MuxerError;
May 06 22:03:22 <mickeyl> ok, so we always need to specify both errors?
May 06 22:03:25 <ptitjes> mickeyl: and MyAppError for my application
May 06 22:03:25 <mickeyl> DBus.Error for generic
May 06 22:03:29 <mickeyl> i see
May 06 22:03:45 <ptitjes> mickeyl: and GLib.Error for generic
May 06 22:03:58 <mickeyl> mmh
May 06 22:04:07 <mickeyl> what happens with GLib.Errors during dbus methods?
May 06 22:04:13 <mickeyl> will they be automarshalled to dbus errors?
May 06 22:04:16 <mickeyl> or does the server bail out?
May 06 22:04:30 <ptitjes> mickeyl: in fact DBus.Error just indicates there is serialization in between caller and callee, resulting behaviour might fail
May 06 22:04:44 <ptitjes> mickeyl: yeah auto-marshalled
May 06 22:04:45 <ptitjes> :)
May 06 22:04:48 <mickeyl> good
May 06 22:04:51 <mickeyl> ok, this looks better:
May 06 22:04:53 <mickeyl> mickey@andromeda:/local/pkg/fso/vala-lang$ mdbus -s org.freesmartphone.omuxerd /org/freesmartphone/GSM/Muxer org.freesmartphone.GSM.MUX.GetVersion
May 06 22:04:59 <ptitjes> this was the goal of my vala contribution
May 06 22:05:01 <mickeyl>  org/freesmartphone/GSM/Muxer: GetVersion failed: org.freesmartphone.GSM.MUX.SessionAlreadyOpen
May 06 22:05:12 <mickeyl> stellar work, man. thanks a lot
May 06 22:05:19 <mickeyl> this removes one showstopper for FSO2
May 06 22:05:25 <ptitjes> héhéhé
May 06 22:05:25 * mickeyl dances a jig
May 06 22:05:27 <ptitjes> :D
May 06 22:05:46 * ptitjes feels happy too
May 06 22:06:31 <mickeyl> ok, i will finish the errors tomorrow and then test the enumerations
May 06 22:06:32 <ptitjes> mickeyl: do you still use the dynamic client ?
May 06 22:06:41 <mickeyl> yes, i don't know anything else :)
May 06 22:07:24 <ptitjes> oh mickeyl another thing
May 06 22:07:28 <mickeyl> do you have an example for static?
May 06 22:07:56 <ptitjes> you don't have to specify the name when it is the camel case equivalent of the error code NAME
May 06 22:08:12 <mickeyl> ooh!
May 06 22:08:14 <mickeyl> that's slick
May 06 22:08:15 * mickeyl trying
May 06 22:08:18 <ptitjes> name is optional
May 06 22:08:49 <mickeyl> yay
May 06 22:08:52 <ptitjes> in the dbus-glib1.vapi I use it for example of org.freedesktop.DBus.Error.IOError
May 06 22:08:52 <mickeyl> works fine, great
May 06 22:09:14 <mickeyl> very clean
May 06 22:09:27 <ptitjes> because IO_ERROR would be came-cased as IoError
May 06 22:09:39 <ptitjes> +l
May 06 22:10:39 <ptitjes> mickeyl: I will have to modify the code however because the error and enum translation code is made inline, and thus produce lots of code
May 06 22:10:59 <ptitjes> mickeyl: I may generate convenience functions instead
May 06 22:12:50 <ptitjes> mickeyl: static client idea is to use typed dbus interface references instead of "dynamic DBus.Object"
May 06 22:13:31 <mickeyl> are there any performance benefits for static or is it "just" better type checking?
May 06 22:13:56 <ptitjes> oh maybe some performance yes
May 06 22:14:45 <ptitjes> mickeyl: in place of if-loops to test|parse for the different types of parameters
May 06 22:15:07 <CIA-75> freesmartphone.org: 03mickey 07libgsm0710mux * rd027b5fdd4f4 10/gsm0710mux/consts.vala: make errordomain MuxerError appear in the public interface
May 06 22:15:21 <ptitjes> mickeyl: that generates calls to the exact types parsed
May 06 22:16:05 <mickeyl> hmm, sounds good
May 06 22:16:19 <ptitjes> mickeyl: in any case publishing APIs as interface sets is the thing to do
May 06 22:16:19 <mickeyl> better typechecking alone would be worth it
May 06 22:16:25 <mickeyl> no doubt
May 06 22:16:43 <mickeyl> now that we are moving to a more static language, I want to get all the benefits from it ;)
May 06 22:17:08 <ptitjes> mickeyl: did you look at the generated C code out of curiosity ?
May 06 22:17:18 <ptitjes> I mean for the errors
May 06 22:18:32 <mickeyl> didn't dare yet :)
May 06 22:20:58 <ptitjes> mickeyl: oh you have to set name="org.freesmartphone.GSM.MUX.Muxer.Error"
May 06 22:21:31 <ptitjes> or GSM.MUX.Error
May 06 22:22:04 <mickeyl> why?
May 06 22:22:12 <mickeyl> i don't like this prefix
May 06 22:22:21 <mickeyl> GetVersion failed: org.freesmartphone.GSM.MUX.ChannelTaken
May 06 22:22:25 <mickeyl> looks pretty good to me
May 06 22:22:35 <mickeyl> no?
May 06 22:24:26 <ptitjes> hum... yeah why not...
May 06 22:24:43 <ptitjes> however I found this less object...
May 06 22:25:10 <ptitjes> mickeyl: you may have sets of possible failures
May 06 22:25:28 <ptitjes> a.k.a domains
May 06 22:25:33 <ptitjes> error domains
May 06 22:25:48 <mickeyl> not until now
May 06 22:25:56 <mickeyl> since we already categorize the interfaces
May 06 22:26:05 <mickeyl> we only have few errors per interface
May 06 22:29:17 <ptitjes> mickeyl: but there may be error types that spans over multiple interfaces
May 06 22:29:56 <mickeyl> yeah. lets cross that bridge when we're there :)
May 06 22:36:29 <mickeyl> do you always add GLib.Error do the clauses, even if you don't throw any?
May 06 22:37:11 <ptitjes> no, exacty because I don't throw any
May 06 22:37:32 <mickeyl> right
May 06 22:38:05 <CIA-75> freesmartphone.org: 03mickey 07libgsm0710mux * rd86911ca334a 10/gsm0710mux/ (manager.vala multiplexer.vala): clean up error situation; declare to throw the errors you actually throw
May 06 22:38:11 <mickeyl> can we have some static warnings?
May 06 22:38:28 <mickeyl> right now we don't get any warning, if we throw an error but didn't declare to throw this error 
May 06 22:38:40 <mickeyl> (this is generic for Vala errors, not dbus-specific)
May 06 22:38:41 <ptitjes> mickeyl: when geting outside of private calls, you need to translate technical errors in application errors
May 06 22:38:49 <ptitjes> like if you would wrap them
May 06 22:39:12 <mickeyl> sure, errors need to follow the abstraction layer
May 06 22:39:54 <ptitjes> it is API contract
May 06 22:40:30 <CIA-75> freesmartphone.org: 03mickey 07fso-abyss * r5d890bcd79a9 10/src/server.vala: declare and throw proper dbus errors
May 06 22:40:53 <mickeyl> ok, great work. will look into enumerations tomorrow. thanks again
May 06 22:40:54 <mickeyl> and g'night
May 06 22:41:41 <ptitjes> so if you think that in future or any other implementation of that method may fail for application reason then define its signature to throw an application error
May 06 22:42:29 <ptitjes> good night
May 06 23:57:01 <CIA-75> freesmartphone.org: 03ptitjes 07vala-dbus-binding-tool * r03ee2966cc05 10/src/vala-dbus-binding-tool.vala: 
May 06 23:57:01 <CIA-75> freesmartphone.org: Fix integer enum values
May 06 23:57:01 <CIA-75> freesmartphone.org: Signed-off-by: Didier 'Ptitjes <ptitjes@free.fr>
May 06 23:59:21 <playya> ptitjes, go to bed. you'll have to work tomorrow
May 06 23:59:38 <ptitjes> héhéhé
May 06 23:59:47 <ptitjes> :)
**** ENDING LOGGING AT Thu May 07 02:59:57 2009