**** BEGIN LOGGING AT Tue Jun 15 02:59:57 2010
Jun 15 14:48:46 <wagi> denkenz: any chance to get my next tech patches for hso included? :)
Jun 15 14:57:12 <denkenz> wagi: Let me try to get to them, too much in the queue right now
Jun 15 14:58:01 <wagi> denkenz: no hurry needed
Jun 15 14:59:00 <wagi> denkenz: in short, the octi/ouwcti/ossysi notify mess is now in gprs.c 
Jun 15 14:59:25 <wagi> denkenz: and there is a new property for CurrentTechnology for DCM
Jun 15 15:00:02 <wagi> denkenz: in my test, it did exactly what I was hopping it would do
Jun 15 15:00:33 <wagi> denkenz: and I tried to read the log output a bit better then last time (netreg update -1, -1 -1, 2)
Jun 15 15:01:20 <denkenz> Ok, I have to mess with my MBM modem to see if it supports EPSB or CPSB
Jun 15 16:18:34 <holtmann> ofonod[18498]: Modem: > AT+CSCB=?\r
Jun 15 16:18:34 <holtmann> ofonod[18498]: Modem: < \r\n+CSCB: (0)\r\n\r\nOK\r\n
Jun 15 16:18:50 <holtmann> So MBM hardware and CBS is funny. They say they support it.
Jun 15 16:19:08 <holtmann> The however when you try to set it
Jun 15 16:19:09 <holtmann> ofonod[18498]: Modem: > AT+CSCB=0,""\r
Jun 15 16:19:09 <holtmann> ofonod[18498]: Modem: < \r\n+CMS ERROR: 500\r\n
Jun 15 16:19:31 <holtmann> ofonod[18498]: Modem: > AT+CSCB=0,"0-999,4352-4356"\r
Jun 15 16:19:31 <holtmann> ofonod[18498]: Modem: < \r\n+CMS ERROR: 500\r\n
Jun 15 18:02:14 <kvalo> cool, borrowed some option 220 modem from a relative and it worked out of box.
Jun 15 19:36:57 <denkenz> holtmann: .
Jun 15 19:36:58 <denkenz> +src_ofonod_LDADD = $(builtin_libadd) @GLIB_LIBS@ @DBUS_LIBS@ @CAPNG_LIBS@ \
Jun 15 19:37:00 <denkenz> +                       -ldl -lm
Jun 15 19:37:03 <denkenz> Any problems with this?
Jun 15 21:06:53 <holtmann> denkenz: What is that for?
Jun 15 21:07:33 <denkenz> holtmann: Some location based crap for sim toolkit
Jun 15 21:07:36 <holtmann> Addition is the -lm right? What functions are you using from the math library.
Jun 15 21:08:00 <denkenz> See patch  [PATCH 13/15] Add 23.032 GAD Shape structs and encoding utility
Jun 15 21:08:02 <holtmann> We really need floating point math for that.
Jun 15 21:09:18 <holtmann> Not for fabs(). Just handcode that.
Jun 15 21:09:40 <holtmann> And then let the compiler optimize it.
Jun 15 21:10:13 <denkenz> Ok, feel free to reply with that
Jun 15 21:10:24 <denkenz> I have my own comments, but thought you'd be against -lm
Jun 15 21:12:03 <holtmann> I am not against, but in this case it is pointless.
Jun 15 21:12:16 <holtmann> And I will reply as soon as the mailing list works again.
Jun 15 21:14:48 <denkenz> ok, I'm not terribly against -lm, highly doubtful that we ever run on a platform with no dedicated FPU
Jun 15 21:19:02 <holtmann> As I said, I am fine with -lm, but not just for an absolute function.
Jun 15 21:19:36 <holtmann> That is some stupid libc crap that fabs() is in -lm while everything simple macro would just do the trick.
Jun 15 21:20:34 <holtmann> Every now and then I am running in that situation.
Jun 15 21:25:50 <balrog-k1n> holtmann: i'd have used macros for fabs, round and ceil if i didn't have to use log() already
Jun 15 21:25:55 <balrog-k1n> it's mainly for log()
Jun 15 21:26:19 <holtmann> Did I miss that one. I only had a quick look.
Jun 15 21:26:25 <holtmann> Why do you need log().
Jun 15 21:27:48 <balrog-k1n> the GAD shapes is geometry stuff, some things like uncertainty radius can be encoded in a kind of exponential notation
Jun 15 21:28:16 <balrog-k1n> i guess it could use a LUT though as there are only 128 values
Jun 15 21:28:24 * balrog-k1n checks
Jun 15 21:29:06 <holtmann> I think floats and double is a bit overkill here.
Jun 15 21:29:15 <holtmann> Can we just use fixed point instead.
Jun 15 21:29:42 <balrog-k1n> yeah, we can
Jun 15 21:30:15 <balrog-k1n> it'll have to be documented because it 
Jun 15 21:30:20 <balrog-k1n> it'll have to be documented because it'll be less obvious then
Jun 15 21:30:27 <denkenz> Btw, that feature is optional
Jun 15 21:30:35 <denkenz> So we don't really need to include it right now
Jun 15 21:31:08 <holtmann> Then lets do that. I like to try to avoid floats and double here. And it seems the bit floating point math we are doing here, it could be easily be done in fixed point.
Jun 15 21:31:21 <kristenc> balrog-k1n: I sent you a revision of that html patch this morning - list is broken, but I did copy you directly.  If you see anything else that needs fixing you can email me directly if you would like.
Jun 15 21:32:04 <holtmann> kristenc: Can you start by fixing the coding style. We are not using camel casing. And please use American English for variable names. Not British English.
Jun 15 21:32:26 <kristenc> holtmann: would you like a copy of the revision?  I fixed that.  The british name matches the spec.
Jun 15 21:32:28 <balrog-k1n> i got the second version, this one fixes the camelcase
Jun 15 21:32:42 <holtmann> kristenc: Also g_string_append_printf() please instead of doing many steps that would potentially require multiple allocations.
Jun 15 21:32:53 <kristenc> I used american english when not trying to match the spec.
Jun 15 21:33:26 <holtmann> Variable names are in American English. You are using colour in it.
Jun 15 21:33:53 <holtmann> Also string = g_string_append(string, ...) is pointless.
Jun 15 21:33:54 <kristenc> yes - the colour variable name matches what the spec defines as a name for that byte.  I can certainly change it.
Jun 15 21:34:29 <kristenc> why pointless?
Jun 15 21:34:40 <kristenc> some details would be constructive.
Jun 15 21:34:42 <holtmann> GString are not like GList. So you can just do g_string_append_printf(string, ...).
Jun 15 21:35:01 <holtmann> I am not that fast in typing right now. Doing other things at the same time.
Jun 15 21:35:15 <kristenc> you can send me a thorough review off line
Jun 15 21:35:24 <holtmann> That makes the code a lot simple to review.
Jun 15 21:35:31 <kristenc> hopefully the list will be fixed soon.
Jun 15 21:35:33 <holtmann> s/review/read/
Jun 15 21:35:33 <balrog-k1n> kristenc: what do you think about replacing <br> with <br />?
Jun 15 21:35:55 <kristenc> balrog-k1n: didn't I fix that?  hum, I wonder if I forgot to commit that change.
Jun 15 21:36:06 <kristenc> I tested it - it works fine, so I was planning to fix it.
Jun 15 21:36:20 <holtmann> The other one I remember from memory was why <p> and not <span> as HTML tag.
Jun 15 21:36:30 <holtmann> Do we really want to make a paragraph.
Jun 15 21:36:42 <balrog-k1n> kristenc: not in the two copies i got :)
Jun 15 21:36:47 <kristenc> holtmann: in the revision, we are using div and span.
Jun 15 21:36:57 <holtmann> Okay.
Jun 15 21:37:17 <kristenc> balrog-k1n: oops - let me commit that change and resend you.
Jun 15 21:37:41 <kristenc> balrog-k1n: I have some tests that I wrote - are you interested in them?
Jun 15 21:37:54 <holtmann> kristenc: Try the mailing list. I hope the fixed it by now. I am off to sleep anyway.
Jun 15 21:38:11 <balrog-k1n> kristenc: you could add them as unit tests
Jun 15 21:38:13 <kristenc> I modified test-stkutil to spit out the html so I could review it in a browser.  It is nothing like the rest of your tests though.
Jun 15 21:38:19 <holtmann> kristenc: Please add the unit test as separate patch and lets include them.
Jun 15 21:38:38 <kristenc> they are very different than your other unit tests.  We create a bunch of files.
Jun 15 21:38:52 <kristenc> wasn't sure if you'd be interested in that.
Jun 15 21:39:00 <kristenc> but I will send it to the list and you can check it out.
Jun 15 21:39:48 <balrog-k1n> are there any complex examples in 3gpp docs?
Jun 15 21:40:21 <balrog-k1n> in the STK tests there are only tests that format the entire text with one format
Jun 15 21:40:40 <kristenc> balrog-k1n: not really - all those were just testing one attribute and a color
Jun 15 21:40:52 <kristenc> but those are the tests I used.
Jun 15 21:41:07 <kristenc> there were none with multiple attributes.
Jun 15 21:41:34 <kristenc> and like you said - none with only partially formatted text
Jun 15 21:42:21 <kristenc> balrog-k1n: do you want me to change the variable name for the colour byte to color?
Jun 15 21:43:41 <balrog-k1n> kristenc: if holtmann thinks it's better
Jun 15 21:43:51 <kristenc> ok - I will include that change.
Jun 15 21:46:19 <holtmann> Yes, we do American English variable names. So color please.
Jun 15 21:52:56 <balrog-k1n> holtmann: should we have a type and some macros to convert to fixed point or leave the converting between formats to the user?
Jun 15 21:53:16 <balrog-k1n> the point of this whole patch was to add utilities to convert from standard c types :)
Jun 15 21:54:08 <holtmann> Don't really know right now. Play with it and see what comes out of it. My current feeling is that we want fixed point.
Jun 15 21:54:20 <denkenz> I see no point in this fixed point stuff
Jun 15 21:54:30 <denkenz> The only reason to do it is if your hardware sucks
Jun 15 21:54:36 <denkenz> Otherwise its just a waste of time
Jun 15 21:54:37 <balrog-k1n> the target format is fixed point (used by the sim... if it's ever used even)
Jun 15 21:54:42 <holtmann> For the user API we have to see. Are we going to export these via D-Bus. Or only use them internally.
Jun 15 21:55:05 <holtmann> denkenz: Why bother with floating point for something simple like this.
Jun 15 21:55:22 <denkenz> Because gcc can do a way better job anyway
Jun 15 21:55:58 <holtmann> Yes and no. Really depends here on the compiler flags and how it is done.
Jun 15 21:56:26 <holtmann> I got burned by floating point already. However I have to admit this is pretty much low CPU overhead anyway.
Jun 15 21:57:10 <denkenz> There's no sense in investing in fixed point arithmetic
Jun 15 21:57:19 <balrog-k1n> holtmann: basically to be nice to the user of the functions
Jun 15 21:57:25 <denkenz> I even fail to see the utility of supporting this envelope in the first place :P
Jun 15 21:57:45 <balrog-k1n> these are encoding utilities, i'm not sure if they are all that useful but the whole point for them is to convert from C types to what the sim speaks
Jun 15 21:57:52 <balrog-k1n> and the sim speaks fixed point
Jun 15 21:58:28 <holtmann> If the SIM talks fixed point, then lets used fixed point.
Jun 15 21:58:29 <denkenz> The sim does sure, but inventing some fixed point format just to convert it to another fixed point format is silly
Jun 15 21:58:47 <holtmann> We just use the fixed point format from the SIM. And that is it.
Jun 15 21:58:58 <balrog-k1n> i think the other option is to accept a ready encoded array of bytes and not bother converting
Jun 15 21:59:20 <holtmann> balrog-k1n: Play with it. I am off to sleep anyway.
Jun 15 22:02:56 <denkenz> I'm seriously thinking we should not even bother with this envelope
Jun 15 22:04:51 <denkenz> This is a class n feature and requires access to a GPS chip
Jun 15 22:04:59 <denkenz> None of which we're going to do any time soon
Jun 15 22:05:12 <balrog-k1n> let's skip it then
Jun 15 22:05:30 <balrog-k1n> most of the envelopes / commands / responses are not going to be used any time soon
Jun 15 22:07:24 <balrog-k1n> (i guess it's only that they're easiest to implement all at once)
Jun 15 22:07:39 <denkenz> I agree, and I let some through for that reason
Jun 15 22:07:45 <denkenz> particularly the MMS ones
Jun 15 22:08:18 <denkenz> However, the open / close channel ones and some of the tech reporting crap are highly unlikely to be used
Jun 15 22:10:02 <denkenz> balrog-k1n: Do you have enough now to start working on menu support & api?
Jun 15 22:10:17 <balrog-k1n> denkenz: yes, working on it now
Jun 15 22:10:34 <denkenz> excellent
Jun 15 22:23:53 <kristenc> is the preference for g_string_append_printf just for readablity?  they seem very similar internally.
Jun 15 22:31:12 <denkenz> let me look
Jun 15 22:32:19 <denkenz> yes that would be more readable
Jun 15 22:36:22 <denkenz> kristen: grep for header_test in unit/test-sms.c
Jun 15 22:36:41 <denkenz> Make sure that we handle that case, feel free to re-use the pdu in your tests
Jun 15 22:53:10 <kristenc> denkenz: ok, thanks.
Jun 15 23:44:20 <kristenc> denkenz: that pdu looks very different than all the other pdu's in test-stkutil.  Do I need to convert it to something else to use the existing code in test-stkutil?
Jun 16 00:08:48 <denkenz> kristen: The pdu is an sms pdu, however the text attributes are the same
Jun 16 00:09:33 <denkenz> kristen: If you want, you can drop your converter in smsutil.h and write the unit test in test-smsutil.c
**** ENDING LOGGING AT Wed Jun 16 02:59:56 2010