**** BEGIN LOGGING AT Tue Nov 04 02:59:57 2008
Nov 04 07:16:04 <trupheenix> hi. can does openmoko's GTK+ support Alpha channels?
Nov 04 08:13:41 <Ainulind2le> Hey guys
Nov 04 10:20:00 <datenmaulwurf> raster: hey
Nov 04 10:21:26 <Hire> i want raster on facebook :\
Nov 04 10:47:07 <ptitjes> Hello!
Nov 04 10:47:39 <ptitjes> SHR guys: I see that the screenshots on the SHR Trac have been made by a man with SFR carrier
Nov 04 10:47:52 <ptitjes> I'd like to know what type of SIM card it is...
Nov 04 10:48:37 <ptitjes> I have a BK SIM card, had a BC one and none of them works as reported on the SIM compatibility problem page
Nov 04 10:48:51 <Hire> pings Ainulind2le
Nov 04 10:48:53 <ptitjes> So what card has the one who made the screenshots please ?
Nov 04 10:49:02 <Hire> he is french
Nov 04 10:49:04 <Ainulind2le> Hire: pong
Nov 04 10:49:20 <ptitjes> Hello Ainulind2le
Nov 04 10:49:27 <Ainulind2le> Coin \_o<
Nov 04 10:49:40 <Hire> hi Ainulindale
Nov 04 10:49:56 <Hire> yesterday I have do a pack of icons for SHR
Nov 04 10:50:02 <Hire> did
Nov 04 10:50:03 <Hire> argh
Nov 04 10:50:08 <ptitjes> Could you tell me what SIM card the guy who made the screenshots of SHR uses ?
Nov 04 10:50:58 <Ainulindale> You mean my SIM ? :-)
Nov 04 10:51:04 <ptitjes> I must go to a SFR shop but I'd like to know what card I must ask them ?
Nov 04 10:51:05 <Hire> here a preview: http://www.okiwii.net/images/yq27dvxlz6fmmvuy6ovf.jpg 
Nov 04 10:51:08 <ptitjes> yes SIM card
Nov 04 10:51:11 <Hire> do you like it?
Nov 04 10:51:15 <Ainulindale> (I was just saying it was mine)
Nov 04 10:51:26 <Ainulindale> I don't know, please wait a minute I'm rebooting to test some stuff
Nov 04 10:51:29 <Hire> http://scap.linuxtogo.org/files/15f203093bcf225abe499239afc3b736.png <-- here a screen from FR
Nov 04 10:51:58 <Ainulindale> Nice :-)
Nov 04 10:53:07 <Hire> well
Nov 04 10:53:22 <Hire> so, how can I call this pack?
Nov 04 10:53:25 <Hire> shr-icons?
Nov 04 10:53:27 <Ainulindale> ptitjes: well, what do you need to know
Nov 04 10:53:28 <Hire> shr-colors?
Nov 04 10:53:32 <Ainulindale> Hire: yep :-)
Nov 04 10:53:40 <Hire> I see
Nov 04 10:54:01 <Hire> now I will finish it 
Nov 04 10:54:40 <ptitjes> Ainulindale: On the back of the SIM card there is a card type code.
Nov 04 10:55:02 <Ainulindale> How many digits ?
Nov 04 10:55:07 <Hire> oh Ainulindale: you get a respond from Mirko on SHR http://n2.nabble.com/Paroli-project-td1449530.html
Nov 04 10:55:19 <ptitjes> It is written "SFR XX", where XX stands for something like BC or BK or... one that works with the FR
Nov 04 10:56:20 <ptitjes> Also on chip side there are written some features like "SIM 250 128ko" that I would be interested in too
Nov 04 10:58:39 <Ainulindale> BC
Nov 04 10:58:47 <Ainulindale> ptitjes: SIM 250 128ko too
Nov 04 10:59:06 <ptitjes> BC ???? but it does not work for me!!
Nov 04 10:59:26 <ptitjes> Could you tell me the other digit please ?
Nov 04 10:59:55 <ptitjes> Did your card work with 2007.2, 2008.8 and FSO ?
Nov 04 11:00:43 <ptitjes> s/digit/digits/
Nov 04 11:01:38 <ptitjes> Or is it only working with SHR ?
Nov 04 11:02:01 <ptitjes> (This is a dumb question but I asked it anyway... :))
Nov 04 11:03:43 <ptitjes> Anuindale: still there ?
Nov 04 11:03:49 <Ainulindale> ptitjes: yep
Nov 04 11:03:51 <Ainulindale> Always worked
Nov 04 11:03:59 <Ainulindale> Query, will be faster
Nov 04 11:08:21 <CM_work> Hire: The icons look good! :-)
Nov 04 11:08:38 <Hire> thx
Nov 04 11:57:04 <MarcOChapeau> Hello freerunners :-)
Nov 04 11:58:58 <Nobody96> moin
Nov 04 12:01:51 <Hire> hi MarcOChapeau
Nov 04 12:07:32 <Ainulindale> Hey MarcOChapeau 
Nov 04 12:07:47 <Ainulindale> MarcOChapeau: when will you be available to end your work on libframeworkd-phonegui-gtk ?
Nov 04 12:11:26 * Hire is testing Android on FR
Nov 04 12:11:37 <Hire> Ainulindale: i think never :D
Nov 04 12:12:56 <Ainulindale> Stop being an ass and package your icons :-)
Nov 04 12:13:15 <Ainulindale> thseiler_: Here ?
Nov 04 12:13:29 <Hire> *sigh*
Nov 04 12:13:37 <Hire> i am in office
Nov 04 12:14:02 <Hire> so I will do it this evening 
Nov 04 12:14:13 <Ainulindale> Ok :-)
Nov 04 12:19:20 <Hire> are you working on SHR now?
Nov 04 12:19:29 * Hire boots android
Nov 04 12:19:34 <Hire> screen is black
Nov 04 12:20:49 <thseiler_> Ainulindale:  hey
Nov 04 12:21:46 <Hire> argh
Nov 04 12:21:52 <Hire> fr is stucked
Nov 04 12:21:56 <Hire> doesn't boot
Nov 04 12:22:23 <Ainulindale> thseiler_: Ok then
Nov 04 12:22:30 <Ainulindale> Where did you see this solution ?
Nov 04 12:22:32 <Ainulindale> (update mime)
Nov 04 12:23:41 <thseiler_> raster gave me the hint (thx again!)
Nov 04 12:24:20 <raster> :)
Nov 04 12:24:56 <Hire> ok
Nov 04 12:25:03 <Hire> android doesn't boot on FR
Nov 04 12:25:07 <Ainulindale> raster: why didn't you tell me that before, lazy pig? :-)
Nov 04 12:25:10 <Hire> this makes me sady
Nov 04 12:25:22 <Ainulindale> raster: and could you tell me how to generate the mime database on the rootfs postprocess ?
Nov 04 12:25:56 <raster> it SHOULD be in the postinst 
Nov 04 12:25:57 <raster> /usr/bin/update-mime-database /usr/share/mime
Nov 04 12:26:09 <Ainulindale> postint of the theme ?
Nov 04 12:26:12 <raster> but the shered-mime-info package that i saw thomas had didnt have a postinst
Nov 04 12:26:19 <raster> someone broke - somehow, the shared mimeinfo package
Nov 04 12:26:32 <raster> how - i dont know as the one i build in my imag eworks and has a postinst that does it right
Nov 04 12:26:35 <raster> no
Nov 04 12:26:43 <raster> of shared-imie-info
Nov 04 12:26:54 <Ainulindale> That's weird because I had the same problem here
Nov 04 12:27:09 <raster> shared-mime-info
Nov 04 12:27:11 <raster> that package
Nov 04 12:27:18 <raster> my buildx work
Nov 04 12:27:33 <raster> and produce a package with a postinst that on first boot runs and produces the mimedatabase (updates it anyway)
Nov 04 12:27:42 <raster> why yours doenst - beats me
Nov 04 12:27:54 <raster> but i knoe the cause and it's definitely not e's code
Nov 04 12:28:03 <raster> whihc was my biggest fear that some bizarreness appeared i'd have to trace
Nov 04 12:28:30 <Ainulindale> do_install_append() { update-mime-database ${D}${datadir}/mime
Nov 04 12:28:34 <raster> i HATE bizarre unknonw origin bugs in my code
Nov 04 12:28:38 <Ainulindale> And that
Nov 04 12:28:38 <Ainulindale>     rm ${D}${datadir}/mime/packages/freedesktop.org.xml
Nov 04 12:28:41 <Ainulindale> in the packag
Nov 04 12:28:42 <Ainulindale> +e
Nov 04 12:29:03 <raster> i only worked this out a few hours ago
Nov 04 12:29:07 <raster> so havent told u
Nov 04 12:29:19 <thseiler_> :-)
Nov 04 12:29:27 <raster> thomas got first dibs on the info
Nov 04 12:29:27 <raster> :)
Nov 04 12:31:38 <MarcOChapeau> Ainulindale: I really don't know...
Nov 04 12:35:07 <Hire> why?
Nov 04 12:35:43 <Hire> get some beers and finish the gtk part of libframeworkd :o
Nov 04 12:47:31 <Ainulindale> raster: Ok saw the probleùm
Nov 04 12:47:45 <Ainulindale> Here we're using shared-mime-info 0.22
Nov 04 12:47:47 <Ainulindale> Not latest
Nov 04 12:47:52 <Ainulindale> 0.22 doesn't update the database
Nov 04 12:48:04 <Ainulindale> Either the sane src revs are borked
Nov 04 12:48:11 <Ainulindale> Or the package has been borked
Nov 04 12:48:33 <Ainulindale> raster: By the way
Nov 04 12:48:52 <Ainulindale> Would you use libframeworkd-glib if I was implementing a way to use e dbus library ?
Nov 04 12:49:20 <Ainulindale> (it's a question, purely, not a way to ask you to do stuff :-) )
Nov 04 12:50:40 <Ainulindale> mickeyl ?
Nov 04 12:51:09 <raster> aaah
Nov 04 12:51:16 <raster> well i am just using oe dev git
Nov 04 12:51:22 <Ainulindale> Same here
Nov 04 12:51:30 <raster> i havent touched srcrev for shared mime info
Nov 04 12:51:44 <raster> hmm
Nov 04 12:51:46 <Ainulindale> check openembedded/packages/shared-mime-info/shared-mime-info_0.22.bb
Nov 04 12:51:50 <raster> libframework-glib
Nov 04 12:51:54 <raster> glib
Nov 04 12:51:57 <raster> likely not
Nov 04 12:52:03 <raster> there's a nice libefso already
Nov 04 12:52:04 <raster> :)
Nov 04 12:52:09 <Ainulindale> distro/include/preferred-om-2008-versions.inc:PREFERRED_VERSION_shared-mime-info ?= "0.22"
Nov 04 12:52:28 <Ainulindale> raster: It wouldn't be using the glib mainloop in the case I'm describing
Nov 04 12:52:39 <Ainulindale> libefso ? implementing all the prototypes ?
Nov 04 12:52:44 <Ainulindale> Because I would like to merge it to lfg
Nov 04 12:53:04 <Ainulindale> It's there for that, offer the dbus session management in C to everyone
Nov 04 12:53:14 <Ainulindale> without mainloop dependency considerations
Nov 04 12:53:26 <raster> sure
Nov 04 12:53:29 <raster> but as i siad
Nov 04 12:53:43 <raster> a libefso that just binds libdbus+edbus and fso :)
Nov 04 12:53:45 <Ainulindale> thseiler_: thanks for the link
Nov 04 12:54:04 <Ainulindale> thseiler_: Please speak here :-)
Nov 04 12:54:08 <thseiler_> sorry
Nov 04 12:54:09 <raster> thomas is working on it
Nov 04 12:54:11 <raster> :)
Nov 04 12:54:15 <thseiler_> got confused with my windows...
Nov 04 12:54:16 <Ainulindale> thseiler_: would you like to integrate it in lfg then ?
Nov 04 12:54:21 <Ainulindale> and rename the package obviously
Nov 04 12:54:48 <Ainulindale> I think it's a pain to waste efforts of so much people to do the same thing :-)
Nov 04 12:55:07 <thseiler_> well i didn't know that a libframework-glib even existed when i started the libefso
Nov 04 12:55:11 <Ainulindale> I know :-)
Nov 04 12:55:20 <thseiler_> thats what i get for not searching...
Nov 04 12:55:31 <thseiler_> actually, i'm happy to integrate the two
Nov 04 12:55:43 <Ainulindale> That would be great
Nov 04 12:55:50 <thseiler_> on the other hand, aren't there many differences in code like the glib type system and so on ?
Nov 04 12:56:08 <thseiler_> i haven't yet had a look at the code, just a feeling ;-)
Nov 04 12:56:08 <Ainulindale> You can use the glib types without bothering about the glib mainloop
Nov 04 12:56:13 <Ainulindale> And we can strip the glib types anyway if necessary
Nov 04 12:56:14 <raster> i can say that i cant use it in e or illume
Nov 04 12:56:23 <Ainulindale> raster: that's because of the mainloop, right ?
Nov 04 12:56:29 <raster> not just that
Nov 04 12:56:33 <Ainulindale> Why then?
Nov 04 12:56:39 <raster> if i made e require something that required glib
Nov 04 12:56:44 <raster> i'd have a revolt on my hands
Nov 04 12:56:48 <thseiler_> hehe
Nov 04 12:56:51 <Ainulindale> raster: heh :-)
Nov 04 12:56:52 <raster> its a political no-no
Nov 04 12:57:01 <raster> if its some extraneous 3rd party optionakl thing
Nov 04 12:57:03 <raster> like emotion
Nov 04 12:57:04 <raster> maybe
Nov 04 12:57:11 <raster> but not e itself
Nov 04 12:57:14 <raster> and illume is in e
Nov 04 12:57:14 <Ainulindale> raster: Then, if the glib types were only internal to lfg ?
Nov 04 12:57:25 <raster> then wouldnt care
Nov 04 12:57:35 <raster> unless glib was a dependency
Nov 04 12:57:43 <Ainulindale> It would be a dependency of lfg 
Nov 04 12:57:48 <thseiler_> well so far, i think we don't really need them. the libefso tries to map everything to plain char* 
Nov 04 12:57:56 <raster> there are a lot of people who really just dont want to know it is depended on
Nov 04 12:58:04 <Ainulindale> thseiler_: what about hashtables ?
Nov 04 12:58:13 <thseiler_> yes thats a problem.
Nov 04 12:58:14 <raster> as i said
Nov 04 12:58:19 <raster> its a political no-no
Nov 04 12:58:29 <Ainulindale> thseiler_: how did you manage to use them then ?
Nov 04 12:58:39 <Ainulindale> Because I personnaly don't care about this or that lib
Nov 04 12:58:43 <DocScrutinizer> political coding - waaaah ;-)
Nov 04 12:58:52 <Ainulindale> I can even put the glib dependency as an optional one
Nov 04 12:59:06 <thseiler_> well, i have struct with the known keys, and i map the a{sv} to that struct members
Nov 04 12:59:15 <thseiler_> the unknown keys are ignored atm
Nov 04 12:59:23 <thseiler_> the idea is to only ever add stuff at the end of the structs
Nov 04 12:59:26 <Ainulindale> Hmmmpf :-)
Nov 04 12:59:29 <thseiler_> yes, i know
Nov 04 12:59:31 <Ainulindale> thseiler_: and what about GPtrArray ?
Nov 04 12:59:38 <Ainulindale> (i.e. calls)
Nov 04 13:00:06 <raster> DocScrutinizer:  open source is full of politics
Nov 04 13:00:10 <raster> hell GNU is all about politics
Nov 04 13:00:22 <Ainulindale> raster: I understand your problem, and I have a question then :-)
Nov 04 13:00:24 <thseiler_> array of struct*, but you are right, it breaks binary compatibility.
Nov 04 13:00:24 <raster> and the whole scene is crawling with people into the "politics" of it all
Nov 04 13:00:31 <Ainulindale> What woudl you use as a sound "typing" system then ?
Nov 04 13:00:35 <DocScrutinizer> PLEASE don't start talk about RMS now :-D
Nov 04 13:00:37 <raster> theres things i can do technically
Nov 04 13:00:44 <raster> and ones i just cant do politically
Nov 04 13:00:58 <Ainulindale> thseiler_: in any case
Nov 04 13:01:04 <thseiler_> the libefso was just somethine we did internally, to help us code
Nov 04 13:01:11 <thseiler_> we belived it was useful to others aswell
Nov 04 13:01:15 <Ainulindale> thseiler_: it should be in the same repository I think -:)
Nov 04 13:01:18 <Ainulindale> thseiler_: same here ;-)
Nov 04 13:01:28 <thseiler_> and that is all the politics there is behind it, as far as i am concerned.
Nov 04 13:01:45 <Ainulindale> thseiler_: It seems logical to me that if we're doing the same thing albeit using a different typing system, we should join forces and help each other
Nov 04 13:01:51 <Ainulindale> We tackled problems with lfg
Nov 04 13:01:59 <Ainulindale> And from what I see we're a bit ahead on the implementation
Nov 04 13:02:04 <thseiler_> hehe
Nov 04 13:02:08 <thseiler_> i know...
Nov 04 13:02:08 <raster> what i wodner is
Nov 04 13:02:17 <Ainulindale> Hence we can help you and the reciprocity is meaningful too :-)
Nov 04 13:02:18 <raster> how much do u really need complex datatypes
Nov 04 13:02:26 <raster> in what is basically a small convenience lib
Nov 04 13:02:30 <raster> for calling dbus calls
Nov 04 13:02:31 <Ainulindale> raster: I don't
Nov 04 13:02:33 <raster> and getting replies
Nov 04 13:02:37 <raster> even internally
Nov 04 13:02:39 <Ainulindale> raster: I'm just thinking about simplicity
Nov 04 13:02:46 <Ainulindale> How to handle something in a safe and sound way
Nov 04 13:02:51 <Ainulindale> i.e. hashtables, and variable arrays
Nov 04 13:02:58 <Ainulindale> that is all that matter to me
Nov 04 13:03:04 <thseiler_> our goal is to keep it as lean as possible also dependency wise
Nov 04 13:03:06 <DocScrutinizer> raster: sure you're right. Anyway it's somewhat... anoying. As coding is all about logics and aesthetics
Nov 04 13:03:07 <Ainulindale> I don't want to reinvent the wheel
Nov 04 13:03:20 <Ainulindale> thseiler_: same here, but that's meaningless as I started it using glib
Nov 04 13:04:10 <raster> Ainulindale:  why do u need hash tables at all?
Nov 04 13:04:15 <raster> thats what i'm asking
Nov 04 13:04:21 <Ainulindale> raster: I need "logical" hashtables
Nov 04 13:04:26 <raster> why?
Nov 04 13:04:27 <raster> thats my q
Nov 04 13:04:30 <thseiler_> yes, trying hard to avoid them, too
Nov 04 13:04:32 <raster> why are u storing anything?
Nov 04 13:04:35 <Ainulindale> I don't
Nov 04 13:04:39 <Ainulindale> frameworkd returns stuff
Nov 04 13:04:51 <Ainulindale> We can't know, in advance, for every thing, the keys of the hashtable
Nov 04 13:05:00 <thseiler_> there is the fso spec
Nov 04 13:05:01 <Ainulindale> If we could I would have built an array
Nov 04 13:05:08 <Ainulindale> Yep, but some stuff are variables
Nov 04 13:05:08 <thseiler_> its pretty clear about what to expect
Nov 04 13:05:15 <raster> rememebr
Nov 04 13:05:15 <Ainulindale> rules as an example
Nov 04 13:05:18 <Ainulindale> contacts on PIM
Nov 04 13:05:19 <raster> a hash table is not light
Nov 04 13:05:23 <thseiler_> yes, rules is complicated
Nov 04 13:05:29 <raster> if u have a has table for every object that has string key -> value
Nov 04 13:05:31 <Ainulindale> raster: I know, that's why I'm talking about a logical hashtable
Nov 04 13:05:34 <raster> u pay a heavy hastabel base price
Nov 04 13:05:36 <raster> just for that
Nov 04 13:05:47 <raster> as fso has a spec
Nov 04 13:05:59 <Ainulindale> raster: Once again
Nov 04 13:06:00 <raster> i would go down the route of just presenting a struct
Nov 04 13:06:03 <Ainulindale> I'm talking about a logical hashtable :-)
Nov 04 13:06:08 <Ainulindale> I don't talk abotu any kind of implementation
Nov 04 13:06:10 <raster> in the end u end up with the same breaks
Nov 04 13:06:13 <Ainulindale> If I have a way to store them as an array
Nov 04 13:06:16 <Ainulindale> If it's simple
Nov 04 13:06:16 <raster> and the has is more complicated in the end
Nov 04 13:06:17 <Ainulindale> I'll do it
Nov 04 13:06:26 <Ainulindale> Fact is :
Nov 04 13:06:28 <raster> ok
Nov 04 13:06:30 <Ainulindale> I don't want to reinvent things
Nov 04 13:06:36 <raster> give me an exampe of where u HAVE to have a hash
Nov 04 13:06:39 <raster> thats the thing
Nov 04 13:06:42 <raster> i'm thinking about it
Nov 04 13:06:48 <raster> and i can't think of why you NEED one
Nov 04 13:06:49 <Ainulindale> Rules are an example
Nov 04 13:06:49 <raster> yes
Nov 04 13:06:53 <raster> for adding new fields
Nov 04 13:06:56 <raster> over time
Nov 04 13:07:04 <raster> but at that point the spec changes
Nov 04 13:07:15 <Ainulindale> But it'll depend, in any case, of the underlying dbus library
Nov 04 13:07:18 <raster> and a new libfwd comes out with a struct expanded with new fields anyway
Nov 04 13:07:26 <raster> structs can be versioend with a version # at the front
Nov 04 13:07:36 <Ainulindale> Here dbus-glib returns HashTable
Nov 04 13:07:54 <raster> so in the ned now you just put more work on the calling app to HAVE to fetch a value and check if it actually exists int he version etc.
Nov 04 13:07:55 <raster> :)
Nov 04 13:07:56 <Ainulindale> This is just merely an example
Nov 04 13:08:12 <Ainulindale> What I won't do is implementing a "buffer type"
Nov 04 13:08:16 <thseiler_> i think i am leaning a bit towards raster here.
Nov 04 13:08:30 <raster> if i have a struct
Nov 04 13:08:31 <thseiler_> hash tables where it makes sense...
Nov 04 13:08:33 <Ainulindale> What I would like to do is to define "types" at runtime
Nov 04 13:08:37 <raster> struct pimentry {
Nov 04 13:08:40 <raster>   int version;
Nov 04 13:08:43 <raster>   char *name;
Nov 04 13:08:47 <thseiler_> but for a telephony interface, we should be able to do without ;-)
Nov 04 13:08:50 <raster>  char *number;
Nov 04 13:08:53 <raster>  ...
Nov 04 13:08:54 <raster> };
Nov 04 13:09:07 <raster> version # is a very efficient chekc for compat
Nov 04 13:09:14 <raster> at runtime
Nov 04 13:09:17 <Ainulindale> raster: I see your point, but you're not answering my question, I didn't express it quite well
Nov 04 13:09:25 <raster> 99% change u'll never remove entries
Nov 04 13:09:27 <raster> just add more fields
Nov 04 13:09:38 <Ainulindale> What I would like to do, in fact, is to be able to write a thing like java Generics
Nov 04 13:09:39 <thseiler_> raster: good idea! will try to implement that
Nov 04 13:09:45 <raster> so as such apps wil always handle the "current set" and a minimum verion #
Nov 04 13:09:46 <Ainulindale> i.e. when I "load" the library
Nov 04 13:09:53 <Ainulindale> I tell it that type "HashTable" is this or that
Nov 04 13:10:04 <raster> if version # at least the verion it likes - it can blindly march on and use the struct
Nov 04 13:10:05 <Ainulindale> Type depending on the dbus management thingy 
Nov 04 13:10:25 <raster> yes
Nov 04 13:10:35 <raster> thats a bi-product og dbus-glib
Nov 04 13:10:37 <raster> and how it works
Nov 04 13:10:52 <raster> it is a wrapper above raw libdbus that presents u with glib types
Nov 04 13:11:17 <raster> when the only tool u have is a hammer.. problems all look like nails :)
Nov 04 13:11:18 <Ainulindale> raster: I wasn't stating a fact but exposing an idea
Nov 04 13:11:24 <raster> depe down inside
Nov 04 13:11:29 <Ainulindale> Of what I would like to be able to do
Nov 04 13:11:32 <raster> in dbus protocol
Nov 04 13:11:34 <Ainulindale> 14:09:38 < Ainulindale> What I would like to do, in fact, is to be able to write a thing like java Generics
Nov 04 13:11:38 <raster> someone sent u a var list dict
Nov 04 13:11:50 <raster> which is basically string key + some encoded value
Nov 04 13:11:51 <raster> maybe string
Nov 04 13:11:54 <raster> maybe something else
Nov 04 13:11:59 <raster> (would have to look)
Nov 04 13:12:05 <Ainulindale> (when raster has an idea, it's basically a blindfold and a straight line i_n front of him, unstoppable... =) )
Nov 04 13:12:19 <raster> i dont know java generics
Nov 04 13:12:20 <thseiler_> Ainulindale: that is a quality, you know ?
Nov 04 13:12:26 <Ainulindale> thseiler_: :-)
Nov 04 13:12:32 <Ainulindale> raster: Hmmm
Nov 04 13:12:50 <Ainulindale> raster: Let's say I define an object saying it uses type A and B
Nov 04 13:12:54 <raster> but what i'm wondering is - again. what is the GOOD reason for needing complex data structs
Nov 04 13:13:07 <Ainulindale> And I define an object implementing the former, albeit with A = HashTable and B = Array
Nov 04 13:13:12 <Ainulindale> The inner logic will be the same
Nov 04 13:13:13 <raster> dbus under the hood presents u with a blob of encoded data
Nov 04 13:13:19 <raster> someoen decided to use string keys + values
Nov 04 13:13:20 <Ainulindale> Except that the type used will be the one specified
Nov 04 13:13:30 <raster> thus u get a hash as its the most generic thing dbus-glib can hand u
Nov 04 13:13:38 <Ainulindale> Aaaarg
Nov 04 13:13:49 <Ainulindale> Stop wondering about useless stuff ! :-)
Nov 04 13:14:00 <Ainulindale> I don't care about how the guys behind dbus-glib decided to do their stuff
Nov 04 13:14:09 <Ainulindale> It's useful out of convenience for glib programs :-)
Nov 04 13:14:13 <raster> you do
Nov 04 13:14:20 <Ainulindale> Using hashtables or not isn't important to me
Nov 04 13:14:21 <raster> because you are using it
Nov 04 13:14:22 <raster> :)
Nov 04 13:14:25 <raster> or you should
Nov 04 13:14:26 <Ainulindale> My problem here isn't to use this or that type
Nov 04 13:14:46 <Ainulindale> My problem is to be able to find out a way to dynamically swap types according to the underlying dbus implementation
Nov 04 13:14:50 <Ainulindale> Regardless of this implementation
Nov 04 13:14:56 <thseiler_> Ainulindale: If I understood you correctly, you want to be able to add a new key i.e. to a contact, send it over dbus and only change the widget to show that additional data, without touching any libs in between, right ?
Nov 04 13:15:03 <Ainulindale> thseiler_: No
Nov 04 13:15:16 <Ainulindale> I'll give you an usecase :-)
Nov 04 13:15:25 <Ainulindale> Let's say I'm using lfg using glib
Nov 04 13:15:34 <Ainulindale> I'll init my connection saying that I use glib
Nov 04 13:15:48 <raster> yay! usecase!
Nov 04 13:15:51 <Ainulindale> lfg will hence know the types used
Nov 04 13:16:07 <Ainulindale> let's say I define an abstract type "RASTER_SUCKS_BEARS_HASHTABLE"
Nov 04 13:16:18 <Ainulindale> If connection == glib then, this type = GHashTable
Nov 04 13:16:28 <Ainulindale> And then my methods will return GHashTable things
Nov 04 13:16:37 <Ainulindale> let's say now that I'm using e
Nov 04 13:16:44 <Ainulindale> I'll init my connection saying it's e
Nov 04 13:16:59 <Ainulindale> and my type won't be the former but "AINULINDALE_CANT_EXPLAIN_THINGS_PROPERLY_HASHTABLE"
Nov 04 13:17:07 <Ainulindale> Which will be interpreted as e expects things
Nov 04 13:17:25 <Ainulindale> Be it a dynamic array or struct or whatever
Nov 04 13:17:26 <raster> imoh a hash table just seems wrong
Nov 04 13:17:29 <raster> what does the hash contain
Nov 04 13:17:29 <thseiler_> you want a build in type converter like the FTP did to the line endings ?
Nov 04 13:17:30 <raster> ?
Nov 04 13:17:34 <Ainulindale> RahahahahAAAAAAAAAAAAAAAAH
Nov 04 13:17:37 * Ainulindale kills himself
Nov 04 13:17:49 <Ainulindale> raster: pleaaaase :-)
Nov 04 13:18:02 <thseiler_> Ainulindale: sorry!
Nov 04 13:18:08 <Ainulindale> I don't care about how the actual data is stored :-)
Nov 04 13:18:10 <Ainulindale> Or managed
Nov 04 13:18:18 <Ainulindale> If we take the integer example
Nov 04 13:18:23 <raster> WE DO
Nov 04 13:18:26 <raster> thats my point
Nov 04 13:18:27 <Ainulindale> glib type will be GInteger
Nov 04 13:18:30 <Ainulindale> e type will eb int
Nov 04 13:18:44 <Ainulindale> get_framework_integer_attribute() will return INTERNAL_INTEGER
Nov 04 13:18:52 <raster> my point is make it something useful no matter what religion
Nov 04 13:18:54 <Ainulindale> INTERNAL_INTEGER will be GInteger or int depending on the initialization
Nov 04 13:18:59 <raster> and dont sugar-coat it per religion
Nov 04 13:19:06 <Ainulindale> raster: that's what I want to do
Nov 04 13:19:09 <raster> for qt or g* or e* or whatever*
Nov 04 13:19:23 <Ainulindale> I don't care about the types, I just want people to be able to use it conveniently regardless of the toolkit
Nov 04 13:19:25 <raster> i am listening
Nov 04 13:19:30 <raster> even tho u dont think it
Nov 04 13:19:37 <Ainulindale> I know you're listening
Nov 04 13:19:43 <raster> i keep repeating my point
Nov 04 13:19:46 <Ainulindale> But you keep hammering on stuff I do'nt talk about :-)
Nov 04 13:19:50 <raster> i dont think u need complex types
Nov 04 13:19:57 <Ainulindale> And I keep telling you
Nov 04 13:19:58 <Ainulindale> Neither do I
Nov 04 13:20:01 <raster> and thus u dont need a ghash
Nov 04 13:20:01 <Ainulindale> I don't care about the type
Nov 04 13:20:03 <raster> or garray
Nov 04 13:20:05 <raster> orginteger
Nov 04 13:20:09 <raster> orwhatever
Nov 04 13:20:12 <Ainulindale> If a gtk developer is used to get GHashTable from dbus-glib
Nov 04 13:20:20 <Ainulindale> It's logical to me to return a GHashTable
Nov 04 13:20:27 <Ainulindale> Because that's what dbus-glib will give me
Nov 04 13:20:37 <raster> u didnt lusten to me earlier
Nov 04 13:20:38 <thseiler_> well, dbus-glib has to work with any dbus messages it receives. a hash makes sense...
Nov 04 13:20:41 <raster> if u are using sbus-glib
Nov 04 13:20:45 <raster> and internally u get ghashtables
Nov 04 13:20:56 <raster> i cant link to libframework-glib
Nov 04 13:20:59 <raster> pretty simple
Nov 04 13:21:02 <raster> dopnt care what u export
Nov 04 13:21:09 <thseiler_> but if you don't care about all possible dbus messages, but only on some, then you can do wthout a hash.
Nov 04 13:21:09 <raster> id u export ghash, ginteger
Nov 04 13:21:10 <raster> int
Nov 04 13:21:10 <Ainulindale> raster: And that's what, as I just told you
Nov 04 13:21:13 <raster> a char ***
Nov 04 13:21:15 <Ainulindale> My point is
Nov 04 13:21:18 <raster> or a giraffe
Nov 04 13:21:25 <Ainulindale> If I can dynamically define the dbus library used
Nov 04 13:21:31 <Ainulindale> be it e or glib or myasslib
Nov 04 13:21:45 <Ainulindale> And if I'm able to use the inner types of that lib dynamically
Nov 04 13:21:53 <Ainulindale> be it gmoronicstuff or estuff
Nov 04 13:21:54 <thseiler_> then make your own type and convert to them...
Nov 04 13:22:06 <Ainulindale> thseiler_: no
Nov 04 13:22:09 <Ainulindale> That's reinventing the wheel
Nov 04 13:22:18 <Ainulindale> Damn, why don't you know about generics guys :-)
Nov 04 13:22:26 <Ainulindale> It'll be simpler to explain
Nov 04 13:22:37 <raster> present a universal representation
Nov 04 13:22:40 <raster> stand back
Nov 04 13:22:48 <raster> u arent looking at the MEANING of your data
Nov 04 13:22:51 <Ainulindale> I want to be able to tell to the library, at runtime, what is the inner representation of the d bus library
Nov 04 13:22:51 <raster> u get a ghash
Nov 04 13:22:52 <raster> why?
Nov 04 13:22:58 <Ainulindale> raster: zekfrhoshdfohsd !
Nov 04 13:23:00 <raster> what is that representing
Nov 04 13:23:01 <Ainulindale> My ponit is
Nov 04 13:23:03 <Ainulindale> I DON'T !
Nov 04 13:23:08 <Ainulindale> I don't want to get a Ghash !
Nov 04 13:23:13 <raster> by just passing a hash on u simply paß the work in interpreting that onto the app
Nov 04 13:23:16 <raster> or next layer up
Nov 04 13:23:20 <raster> you DO
Nov 04 13:23:21 <raster> ghash
Nov 04 13:23:23 <raster> ehash
Nov 04 13:23:24 <raster> qhash
Nov 04 13:23:25 <raster> who cares
Nov 04 13:23:31 <Ainulindale> That's my point !
Nov 04 13:23:35 <Ainulindale> I don't care !
Nov 04 13:23:42 <Ainulindale> But the developer using the library cares 
Nov 04 13:23:47 <raster> why just export a hash
Nov 04 13:23:48 <Ainulindale> And I want him to be able to tell what he expects 
Nov 04 13:23:50 <raster> thats the thing
Nov 04 13:23:58 <Ainulindale> Gaaah
Nov 04 13:24:00 <Ainulindale> Hash is just an example !
Nov 04 13:24:06 <raster> yes
Nov 04 13:24:06 <Ainulindale> 14:22:51 < Ainulindale> I want to be able to tell to the library, at runtime, what is the inner representation of the d bus library
Nov 04 13:24:07 <raster> i know
Nov 04 13:24:10 <Ainulindale> Once again
Nov 04 13:24:14 <raster> i am using this example as a discussion point
Nov 04 13:24:16 <raster> be it a hash
Nov 04 13:24:18 <raster> an array
Nov 04 13:24:27 <raster> a has of arrays of lists of hashes of...
Nov 04 13:24:29 <Ainulindale> This example isn't relevant to this point of the discussion
Nov 04 13:24:43 <Ainulindale> Because what I'm trying to explain is 
Nov 04 13:24:46 <raster> you have a wrapper call
Nov 04 13:24:48 <raster> lets say
Nov 04 13:24:54 <Ainulindale> If e uses bananas or paper foil to store its variables
Nov 04 13:25:03 <Ainulindale> I want the developer to tell to lfg : please use bananas 
Nov 04 13:25:16 <raster> get_pim_entry(0);
Nov 04 13:25:16 <Ainulindale> Or more correctly :
Nov 04 13:25:22 <Ainulindale> I want the developer to tell to lfg
Nov 04 13:25:23 <raster> returns a pim entry
Nov 04 13:25:27 <Ainulindale> Please use e dbus library
Nov 04 13:25:33 <raster> and lets just say that dbus-glib happesn to use a ghash for that\
Nov 04 13:25:36 <raster> as per your example
Nov 04 13:25:37 <Ainulindale> And lfg will know that if he uses e, he has to return bananas
Nov 04 13:25:49 <raster> e_dbus doesnt interpret types at all
Nov 04 13:25:51 <raster> it doesnt even try
Nov 04 13:25:54 <Ainulindale> raster: I'll write a C example
Nov 04 13:25:57 <Ainulindale> Will be clearer
Nov 04 13:26:09 <thseiler_> Ainulindale: good idea
Nov 04 13:26:17 <raster> it just provides convenience libs on top of libdbus for well known protocols
Nov 04 13:26:26 <raster> and otherwise mainloop bindings for libdbus
Nov 04 13:27:09 <thseiler_> i franky don't even know what a java generic is. i will have to read about that before I can discuss with you ;-)
Nov 04 13:27:29 <raster> i get what he means
Nov 04 13:27:39 <raster> return the datatype given the chosen abstraction layer
Nov 04 13:27:48 <raster> eg a ghash or a eina_hash (for e) or a qhash
Nov 04 13:27:50 <raster> or whatever
Nov 04 13:28:10 <raster> that ASSUMEs e4ach geenric "native complex data stype" layer has a version of that type
Nov 04 13:28:19 <raster> (or an STL type for c++)
Nov 04 13:28:28 <raster> but all it is doing is the same thing
Nov 04 13:28:34 <Ainulindale> http://pastebin.com/m7e94f2b7
Nov 04 13:28:39 <raster> just dressing up the same thing per religion (g, q, e etc.)
Nov 04 13:29:10 <Ainulindale> Is it clearer ?
Nov 04 13:29:18 <raster> Ainulindale: again
Nov 04 13:29:21 <raster> i say it
Nov 04 13:29:24 <Ainulindale> Please don't speak about hash
Nov 04 13:29:28 <raster> i disagree on what u are doing
Nov 04 13:29:30 <raster> what you WANT to do
Nov 04 13:29:43 <raster> u can return an int no matter what
Nov 04 13:29:47 <raster> in this case
Nov 04 13:29:49 <Ainulindale> raster: Not with glib
Nov 04 13:29:56 <raster> there is sero need to be comlicated
Nov 04 13:30:01 <raster> yes u can
Nov 04 13:30:09 <Ainulindale> In this can yes I can return int whatever the case
Nov 04 13:30:20 <raster> my point is to use a generic prepresentation for ALL users
Nov 04 13:30:21 <Ainulindale>  But when I'm forced to use complex data types because of the underlying dbus library
Nov 04 13:30:33 <raster> not a sugar-coated religious one per religioun
Nov 04 13:30:36 <raster> religion
Nov 04 13:30:43 <raster> again
Nov 04 13:30:47 <raster> u are not forced to use thewm
Nov 04 13:30:52 <raster> you choose to use dbus-glib
Nov 04 13:30:53 <Ainulindale> I think translating the inner representation of the library to a more generic representation is overhead
Nov 04 13:31:03 <Ainulindale> raster: I stumbled upon dbus-glib you mean =)
Nov 04 13:31:06 <raster> it presents u with a complex data type u now think u HAVE to use
Nov 04 13:31:10 <Ainulindale> No
Nov 04 13:31:14 <raster> you dont HAVE to
Nov 04 13:31:17 <raster> u can use libdbus
Nov 04 13:31:19 <Ainulindale> I don't think that raster, again
Nov 04 13:31:22 <raster> and iterate over the return
Nov 04 13:31:28 <raster> libdbus-glib just happesn to do this for u
Nov 04 13:31:34 <raster> generate a glib type
Nov 04 13:31:36 <Ainulindale> I know, again
Nov 04 13:31:40 <raster> (garray, ghash, gwhatever)
Nov 04 13:31:56 <MarcOChapeau> Ainulindale: Have you noticed how vagalume complains that it can't initialize the audio system ?
Nov 04 13:31:59 <Ainulindale> But listening to you, you're suggesting to reinvent the wheel on that case
Nov 04 13:32:01 <raster> i am saying that THAT layer is possibly your problem
Nov 04 13:32:02 <Ainulindale> MarcOChapeau: yes
Nov 04 13:32:03 <Ainulindale> That's normal
Nov 04 13:32:11 <raster> as it presents u with what appears to u as only 1 soluition
Nov 04 13:32:11 <Ainulindale> gst-mad plugin isn't there
Nov 04 13:32:13 <MarcOChapeau> oh, my bad :-)
Nov 04 13:32:26 <raster> Ainulindale: no
Nov 04 13:32:28 <raster> ok
Nov 04 13:32:36 <raster> let me do a more complicated example
Nov 04 13:32:40 <raster> that illustrates what i mean
Nov 04 13:32:46 <Ainulindale> Listening :-)
Nov 04 13:32:57 <Ainulindale> (I'll love to talk to you in person to see if you're as annoying as me :-p)
Nov 04 13:33:04 <Ainulindale> (And as stubborn)
Nov 04 13:33:38 <Ainulindale> (THough it's a pleasure to discuss about technical things with competent people, it may be painfu; :-p)
Nov 04 13:33:56 <raster> hehehehe
Nov 04 13:34:23 <Ainulindale> raster: I'm going to pee, that gives you a minute to explain your point of view
Nov 04 13:34:40 <Ainulindale> Please enjoy that level of detail in the knowledge of my whereabouts
Nov 04 13:34:53 * sicu is eavesdropping on the conversation ;p
Nov 04 13:36:50 <sicu> but far from competent enough to pitch in
Nov 04 13:41:27 * CM_work sits next to sicu on the fence.
Nov 04 13:43:34 <sicu> =]
Nov 04 13:44:45 <raster> http://pastebin.com/m4ce2e430
Nov 04 13:44:45 <raster> quick
Nov 04 13:44:52 <raster> pseudcore
Nov 04 13:45:48 <raster> the complexity of your code to deal with N flavors of front-end is goping to be as great or greater than just walking the libdbus level returns
Nov 04 13:45:52 <raster> err
Nov 04 13:45:53 <raster> going
Nov 04 13:46:07 <raster> and presenting a "simple well known struct"
Nov 04 13:46:20 <raster> u can add a version # to it so when fields get added u know they are there or not
Nov 04 13:46:29 <raster> and u can just use the struct directly
Nov 04 13:46:33 <raster> no lookups needed into a hash
Nov 04 13:46:38 <raster> the point is
Nov 04 13:46:39 <Ainulindale> (on the phone, will look in a minute)
Nov 04 13:46:46 <raster> the "base" hash type is ACTUALLY encoding higher level data
Nov 04 13:46:51 <raster> names, phone numbers
Nov 04 13:46:52 <raster> ages
Nov 04 13:46:56 <raster> last modified timestamps
Nov 04 13:46:57 <raster> etc.
Nov 04 13:47:27 <raster> u still require the APP to interpret basic hash entries into their real intended types
Nov 04 13:47:44 <raster> (if they are all strings u have to do atoi()'s on the int members (eg timestamp)
Nov 04 13:47:45 <raster> etc. etc.
Nov 04 13:47:48 <raster> (or age)
Nov 04 13:48:00 <thseiler_> raster: i like the iterator over entry thing to solve the array case. Usually you would go trough the array anyway to add items to a list or similar.
Nov 04 13:48:17 <thseiler_> so skip the array copy altogether.
Nov 04 13:48:29 <raster> thseiler_: yeah
Nov 04 13:48:32 <raster> it depends what it returns
Nov 04 13:48:39 <Ainulindale> (still on the phone)
Nov 04 13:48:45 <raster> i was just taking a more complicated pim entry
Nov 04 13:48:51 <raster> but it may return an array of pim entries
Nov 04 13:49:14 <raster> though personally i'd be saying
Nov 04 13:49:28 <raster> "should have a dbus call to fetch just 1 entry - eahc entry is a dbus call"
Nov 04 13:49:35 <raster> so that way u walk the entry list
Nov 04 13:49:40 <raster> each call just gets the next one
Nov 04 13:50:38 <thseiler_> like snmp does. has its own set of drawbacks, but scales better for long lists
Nov 04 13:50:44 <thseiler_> and contacts can get very long ;-)
Nov 04 13:50:46 <alphaone> Ainulindale: For SHR I need to build openmoko-{dialer,contacts,messages}3 ?
Nov 04 13:50:55 <Ainulindale> yes
Nov 04 13:51:03 <Ainulindale> still on the phone...
Nov 04 13:51:43 <raster> if u use libdbus-glib at the core
Nov 04 13:51:48 <raster> u have to translate a ghash into a qhash
Nov 04 13:51:51 <raster> or eina_hash
Nov 04 13:51:58 <raster> that will be always more work
Nov 04 13:52:00 <raster> or
Nov 04 13:52:05 <raster> u are SOL for e
Nov 04 13:52:15 <raster> we dont provide generic types from edbus
Nov 04 13:52:23 <raster> u walk the returns with libdbus calls
Nov 04 13:52:39 <raster> (and build your parameters the same way for calls)
Nov 04 13:52:50 <Ainulindale> Back
Nov 04 13:52:57 <Ainulindale> I'll read your piece
Nov 04 13:53:02 <raster> i am sure qt has its own thing for that stuff
Nov 04 13:53:19 <raster> catering to all religions in 1 lib is going to drive u nuts
Nov 04 13:53:44 <raster> and create more coede by far than just the libdbus - walk return with libdbus's interators
Nov 04 13:53:55 <raster> and p[roduct basic type returns
Nov 04 13:53:56 <raster> :)
Nov 04 13:54:35 <raster> as long as u hand back generic types liek ghash's (ro whatever) the calling apsp still need to do walking/checkign themselevs anyway
Nov 04 13:54:37 <raster> :)
Nov 04 13:54:48 <Ainulindale> Ok, saw your piece, now comments
Nov 04 13:55:16 <Ainulindale> So
Nov 04 13:55:20 <Ainulindale> What you're telling me is
Nov 04 13:55:45 <Ainulindale> dbus-glib or whatever library of this kind generates overhead and implies the use of complex data types when not necessary
Nov 04 13:55:48 <Ainulindale> I agree
Nov 04 13:55:50 <Ainulindale> To that I say
Nov 04 13:56:08 <Ainulindale> The solution I see to that in your piece is : do you own dbus session management and reimplement structures
Nov 04 13:56:12 <Ainulindale> To that I say
Nov 04 13:56:13 <raster> its not the overhead
Nov 04 13:56:13 <Ainulindale> Isn't that too much ?
Nov 04 13:56:20 <raster> its the flase sense fo saving work
Nov 04 13:56:27 <Ainulindale> flase sense ?
Nov 04 13:56:27 <raster> u'll end up doing the same or more work anyway
Nov 04 13:56:28 <raster> :)
Nov 04 13:56:32 <raster> false
Nov 04 13:56:45 <raster> not worrynig about efficiency cycle/mem wise right now
Nov 04 13:56:46 <Ainulindale> raster: Here you're wrong
Nov 04 13:56:53 <Ainulindale> Because I won't end up doing the same work
Nov 04 13:56:56 <raster> just in terms of how has to write how much code and where
Nov 04 13:56:57 <Ainulindale> The developer using lfg will 
Nov 04 13:56:59 <Ainulindale> :-p
Nov 04 13:57:06 <raster> yes
Nov 04 13:57:08 <raster> thats my point
Nov 04 13:57:11 <Ainulindale> But I see your point anyway
Nov 04 13:57:16 <raster> then every app needs to walk the hash key by known key
Nov 04 13:57:19 <raster> check if it exists
Nov 04 13:57:19 <Ainulindale> raster: My problem with what you're telling is
Nov 04 13:57:24 <raster> convert to a native type
Nov 04 13:57:29 <Ainulindale> Regardless of the hash type or anything like that
Nov 04 13:57:35 <raster> (atoi for an int, atof for float, blah blah etc.)
Nov 04 13:57:35 <Ainulindale> The only other solution viable to that problem is
Nov 04 13:57:42 <raster> for a hash for example
Nov 04 13:57:45 <Ainulindale> Build an inner type
Nov 04 13:57:55 <Ainulindale> Isn't that too much ?
Nov 04 13:58:07 <Ainulindale> (Too much work, too much potential problems, too much to learn for developers ?)
Nov 04 13:58:11 <raster> ok
Nov 04 13:58:17 <raster> my example of "age" key
Nov 04 13:58:26 <raster> if its a hash - u likely are goign to have "age" "72"
Nov 04 13:58:31 <raster> string key
Nov 04 13:58:34 <raster> and string value
Nov 04 13:58:47 <raster> u could malloc an int
Nov 04 13:58:56 <raster> and hashh point to that
Nov 04 13:59:01 <Kensan_> raster: hi there.
Nov 04 13:59:12 <raster> uc an play "pad the struct at the end" games with all alloced data there to make it 1 alloc
Nov 04 13:59:23 <raster> but u're goign to have each app have to walk their "hash"
Nov 04 13:59:26 <raster> if its a ghash
Nov 04 13:59:28 <raster> or a qhash
Nov 04 13:59:31 <Ainulindale> raster: Please stop talking about hash
Nov 04 13:59:32 <raster> or eina_hash
Nov 04 13:59:37 <Ainulindale> THat is not the point of the question I'm asking you
Nov 04 13:59:38 <raster> the code will be duplicated
Nov 04 13:59:45 <raster> its my "example"
Nov 04 13:59:46 <Ainulindale> I see and understand what you're describing regarding these types
Nov 04 13:59:48 <Ainulindale> My question is
Nov 04 13:59:52 <Ainulindale> 14:57:45 < Ainulindale> Build an inner type
Nov 04 13:59:52 <Ainulindale> 14:57:55 < Ainulindale> Isn't that too much ?
Nov 04 13:59:52 <Ainulindale> 14:58:07 < Ainulindale> (Too much work, too much potential problems, too much to learn for developers ?)
Nov 04 13:59:52 <raster> the same applies for other types
Nov 04 13:59:58 <raster> Kensan_:  yo
Nov 04 14:00:03 <Kensan_> raster: got my debugboard so I'll be giving qi a spin.
Nov 04 14:00:36 <raster> Kensan_:  cool. tho changes are i wont touch it
Nov 04 14:00:37 <Kensan_> raster: and if I figure out how to not brick my FR, I'll flash a hw-ecc enabled NOR u-boot.
Nov 04 14:00:45 <raster> :)
Nov 04 14:00:59 <Kensan_> raster: yeah I just want to see how big the excpected speedup will be.
Nov 04 14:01:16 <Ainulindale> raster: so ?
Nov 04 14:01:25 <Kensan_> raster: if it boots kernel in <1 sec I won't bother with bootloader.
Nov 04 14:01:27 <raster> Ainulindale: in the end every front end will end up converting to something that isnt a entirely generic type (if its vaguely smart)
Nov 04 14:01:46 <raster> Kensan_:  sure. then thats a solved problem
Nov 04 14:01:48 <raster> :)
Nov 04 14:01:50 <Ainulindale> raster: Hence my question
Nov 04 14:01:59 <Kensan_> raster: that's what I currently expect.
Nov 04 14:02:00 <Ainulindale> raster: Won't it be too much to implement an inner lfg type ?
Nov 04 14:02:04 <raster> Ainulindale: u have a choice
Nov 04 14:02:09 <raster> offer only g* types
Nov 04 14:02:15 <Ainulindale> raster: and that I don't :-)
Nov 04 14:02:17 <raster> or have to convert g* types
Nov 04 14:02:21 <Ainulindale> I don't either
Nov 04 14:02:23 <Kensan_> raster: but the kernel still takes way too long so maybe I should start looking into that since other people are experimenting with init replacements etc.
Nov 04 14:02:31 <raster> (eg arrays/hashes) to other religions
Nov 04 14:02:40 <raster> or have the wrapper libs do that for u
Nov 04 14:02:46 <Ainulindale> raster: Either I didn't understand your point
Nov 04 14:02:50 <Ainulindale> Or you didn't understand mine
Nov 04 14:02:51 <raster> (ebdus doesnt so u have to write all that walking and generation anyway)
Nov 04 14:02:58 <Kensan_> raster: I can't really see where the kernel is spending ~14 secs...
Nov 04 14:03:02 <raster> i do understand your point
Nov 04 14:03:04 <Ainulindale> Your example used calls to dbus
Nov 04 14:03:12 <Ainulindale> direct calls
Nov 04 14:03:15 <raster> i'm predicting how much coee u'll end up writign doing what u want to do
Nov 04 14:03:24 <Ainulindale> raster: once again
Nov 04 14:03:25 <raster> yes
Nov 04 14:03:29 <raster> thats the point of fso
Nov 04 14:03:33 <Ainulindale> I don't want to use dbus-glib, just dbus-glib, and nothing more
Nov 04 14:03:38 <raster> make a call via dbus to a service
Nov 04 14:03:41 <raster> get a response
Nov 04 14:03:46 <raster> or get unsolicited signals
Nov 04 14:03:48 <Ainulindale> I want, in the minimum amount of code, to be able to tie myself to a mainloop
Nov 04 14:03:55 <Ainulindale> And to listen to dbus signals
Nov 04 14:04:03 <Ainulindale> And to return an easy to manage structure for data
Nov 04 14:04:11 <raster> yes
Nov 04 14:04:13 <raster> i know
Nov 04 14:04:13 <Ainulindale> Even if it means that the user will have to construct types himself
Nov 04 14:04:21 <raster> and fdor that u want to return glib types to the caller
Nov 04 14:04:26 <Ainulindale> What I understood from your answer is
Nov 04 14:04:28 <Ainulindale> use libdbus
Nov 04 14:04:32 <Ainulindale> Am I right ?
Nov 04 14:04:36 <raster> yes
Nov 04 14:04:38 <raster> if u use libdbus
Nov 04 14:04:43 <raster> not libdbus-glib
Nov 04 14:04:47 <raster> u are loop agnostic
Nov 04 14:04:52 <raster> u are also "Religion agnostic"
Nov 04 14:04:58 <raster> u dont get ghashes
Nov 04 14:05:01 <Ainulindale> Not quite so, to my eyes, raster 
Nov 04 14:05:05 <raster> u get a dbusmessage type
Nov 04 14:05:08 <raster> or reply
Nov 04 14:05:09 <Ainulindale> Because yes, I won't have glib or e or whatever types
Nov 04 14:05:16 * Hire loves catfight
Nov 04 14:05:16 <Ainulindale> But I'll have to construct *my* types
Nov 04 14:05:16 <raster> and u iterate over it with dbus calls
Nov 04 14:05:24 <Ainulindale> Won't I ?
Nov 04 14:05:30 <raster> yes
Nov 04 14:05:32 <raster> correct
Nov 04 14:05:40 <Ainulindale> And my point was, regarding that
Nov 04 14:05:47 <raster> dbus-glib tries to do this generically as best it can
Nov 04 14:05:49 <Ainulindale> Won't it be too much work, too much problems ?
Nov 04 14:05:58 <Ainulindale> Too much potential flaws ?
Nov 04 14:05:59 <raster> given the input
Nov 04 14:06:06 <raster> always potential flaws
Nov 04 14:06:19 <raster> you just shuffle where the flaws end up
Nov 04 14:06:28 <raster> there are 2 parts to this
Nov 04 14:06:28 <Ainulindale> Kind of, yes
Nov 04 14:06:33 <raster> the mainloop glue
Nov 04 14:06:40 <raster> and what libwfd-glib returns to its user
Nov 04 14:06:47 <raster> what datastypes do they get
Nov 04 14:06:55 <raster> anbd what dependencies libwfd-glib has
Nov 04 14:07:06 <raster> its dependencies are a direct result of its internal needs
Nov 04 14:07:10 <raster> as well as what it returtns
Nov 04 14:07:40 <raster> if libwfd-glib depends on glib "for convenience" to save you work
Nov 04 14:07:45 <raster> technically that is fine
Nov 04 14:08:05 <raster> technically that saves u some work - if all u do is return those types to the libfwd-glib user/caller
Nov 04 14:08:16 <raster> in this case tho technically fine
Nov 04 14:08:23 <raster> i knwo i have political problems
Nov 04 14:08:32 <raster> so your solution there partly is to hide glib
Nov 04 14:08:43 <raster> and return "g" or q" or "e" native types
Nov 04 14:08:48 <raster> instead of only g types
Nov 04 14:08:54 <raster> that hides the deb
Nov 04 14:08:59 <raster> but u still have the glib dep
Nov 04 14:09:07 <raster> and now u ALSO have code to CONVERT the g types to other types
Nov 04 14:09:22 <raster> still depend on glib
Nov 04 14:09:38 <raster> ok - so now u move a step further
Nov 04 14:09:45 <raster> u dlopen() glib or qt or e libs
Nov 04 14:09:56 <raster> and look up symbols runtime based on the caller "religion"
Nov 04 14:10:08 <raster> (caller tells uy its religion)
Nov 04 14:10:12 <raster> your code wil be quite complex
Nov 04 14:10:14 <raster> and heavy
Nov 04 14:10:26 <raster> and be about the same work (imho) or MORE
Nov 04 14:10:32 <raster> than just using libdbus
Nov 04 14:10:42 <raster> walk the dbusmessages with libdbus's iterators
Nov 04 14:10:47 <raster> and return simple basic types
Nov 04 14:10:53 <raster> ie struct {}'s
Nov 04 14:11:07 <raster> with all the stuff filled in and converted/interpreted as a basic c type
Nov 04 14:11:17 <raster> that is agnostic and usabel by everyone
Nov 04 14:11:25 <Ainulindale> (here again)
Nov 04 14:11:26 <raster> be it g* e* q* or even command-line ncurses apps
Nov 04 14:11:47 <raster> u'll end up with the same or less work
Nov 04 14:11:54 <raster> thats my view of it
Nov 04 14:11:58 <Ainulindale> raster: my soltuon wasn't what you're describing
Nov 04 14:12:05 <Ainulindale> You misunderstood it
Nov 04 14:12:09 <Ainulindale> 15:09:08 < raster> and now u ALSO have code to CONVERT the g types to other types
Nov 04 14:12:12 <Ainulindale> That is wrong
Nov 04 14:12:17 <Ainulindale> And that isn't what I was suggesting
Nov 04 14:12:30 <raster> read all that i wrote
Nov 04 14:12:36 <raster> i said u have 2 ways to do it
Nov 04 14:12:44 <raster> 1. get ti as g* then convert
Nov 04 14:12:53 <Ainulindale> raster: No I won't, I just like to tell you you're wrong :-p
Nov 04 14:12:58 <raster> or dlopen the respective g* e* qt* libs
Nov 04 14:13:02 <raster> and hook them in
Nov 04 14:13:24 <Ainulindale> (I indeed read the beginning and wrote my answer along with my reading)
Nov 04 14:13:40 <Ainulindale> (description #2 is closer to what I was suggesting)
Nov 04 14:13:57 <Ainulindale> Though I don't see it as more "difficult" to maintain 
Nov 04 14:14:10 <raster> #2 would only work if everyone has identical api's u can overload
Nov 04 14:14:23 <Ainulindale> Not as such
Nov 04 14:14:27 <Ainulindale> I won't use dlopen for instance
Nov 04 14:14:28 <raster> ie the protypes accept identical typed params and return identicla types and have identicla semantics
Nov 04 14:14:37 <Ainulindale> I would only redefine the "out" types
Nov 04 14:14:45 <raster> if u dont use dlopen then we're back to the political issue
Nov 04 14:14:47 <Ainulindale> But that would imply a dependency on every dbus library implemented
Nov 04 14:14:49 <Ainulindale> Yep
Nov 04 14:14:51 <Ainulindale> That I got
Nov 04 14:14:54 <Ainulindale> Hmmm
Nov 04 14:15:00 <Ainulindale> thseiler_: your opinion ?
Nov 04 14:15:03 <Ainulindale> (interested in that :-) )
Nov 04 14:15:10 <raster> i am sure the qt world wil not be thrilled by using glib based libs
Nov 04 14:15:24 <raster> and vice-versa
Nov 04 14:15:26 <Ainulindale> Idneed
Nov 04 14:15:28 <Ainulindale> Damn
Nov 04 14:15:30 <Ainulindale> You're contagious
Nov 04 14:15:33 <Ainulindale> => Indeed
Nov 04 14:15:37 <raster> the g* world will look at you strangely requirig qt
Nov 04 14:15:40 <raster> :)
Nov 04 14:16:04 <raster> and the e world will just look at you strangely no matter what you do! :) hehehehe
Nov 04 14:16:09 <raster> if u dlopen()
Nov 04 14:16:23 <raster> u can putn off deps to runtime and dynamically figuere it out as u go
Nov 04 14:16:33 <raster> it will make the political camps go quiet
Nov 04 14:16:38 <Ainulindale> But it'll be hell
Nov 04 14:16:39 <raster> even if u dont dlopen
Nov 04 14:16:41 <raster> u'd hasve
Nov 04 14:16:53 <raster> if (mode == 'g) { do g thing; }
Nov 04 14:17:02 <Ainulindale> Indeed, indeed
Nov 04 14:17:03 <raster> else if (mode == 'q') { do q thing; }
Nov 04 14:17:13 <raster> else if (mode == 'e') { do e thing; }
Nov 04 14:17:17 <Ainulindale> raster: what I want is pretty clear and I think this is sensible
Nov 04 14:17:20 <Ainulindale> Avoid code duplication
Nov 04 14:17:22 <raster> for every single api input and output :(
Nov 04 14:17:23 <Ainulindale> Avoid reinventing the wheel
Nov 04 14:17:26 <raster> that is going to suck :(
Nov 04 14:17:28 <Ainulindale> Be as agnostic as possible
Nov 04 14:17:35 <raster> yeah
Nov 04 14:17:38 <raster> i agree
Nov 04 14:17:39 <raster> all for it
Nov 04 14:17:45 <Ainulindale> I don't think this is an unattainable grail
Nov 04 14:17:48 <raster> my suggestion is to use libdbus directly
Nov 04 14:17:53 <Ainulindale> I know this requires work
Nov 04 14:18:01 <Ainulindale> Hmm
Nov 04 14:18:15 <Ainulindale> Do you know a tool similar to dbus-binding-tool for libdbus ?
Nov 04 14:18:35 <raster> return DBusMessage * types
Nov 04 14:18:52 <Ainulindale> Huh?
Nov 04 14:19:15 <raster> then the caller uses dbus_message_iter_init(), dbus_message_iter_get_arg_type(), dbus_message_iter_recurse(),dbus_message_iter_get_basic(), dbus_message_iter_next() et.c to walk the returned message 
Nov 04 14:19:24 * thseiler_ reading up...
Nov 04 14:19:33 <raster> edbus doesnt wrap any of that
Nov 04 14:19:43 <raster> dbus-glib does
Nov 04 14:19:48 <Ainulindale> thseiler_: Do you feel motivated enough to do the solution emerging from all that mess ?
Nov 04 14:19:55 <raster> and thats why it presents u with hashes/gintegers/garrays etc.
Nov 04 14:19:56 <Ainulindale> And to join forces then ?
Nov 04 14:20:00 <raster> qt has somethng similar
Nov 04 14:20:07 <raster> dbus-glib and qt stuff also bind into the mainloop
Nov 04 14:20:31 <Ainulindale> raster: Problem is, anyway
Nov 04 14:20:36 <Ainulindale> We'll have to tie to the mainloop and redevelop stuff
Nov 04 14:20:38 <raster> libdbus in all cases is the lowest common denominator
Nov 04 14:20:43 <Ainulindale> And that tie will be library specific
Nov 04 14:20:49 <raster> and its the lib at least everyone has agreed to use :)
Nov 04 14:20:51 <Ainulindale> Though we can subpackage it
Nov 04 14:21:02 <raster> hmm
Nov 04 14:21:05 <raster> in the e_dbus case
Nov 04 14:21:10 <Ainulindale> i.e. lf-e, lf-glib
Nov 04 14:21:10 <raster> i can say - u dont have to worry
Nov 04 14:21:18 <raster> e_dbus has already tied for u
Nov 04 14:21:23 <Ainulindale> I wasn't talking about e_dbus
Nov 04 14:21:30 <Ainulindale> I was talking about mainloops
Nov 04 14:21:34 <raster> to some extent
Nov 04 14:21:37 <Ainulindale> If we implement an agnostic solution
Nov 04 14:21:44 <Ainulindale> We won't care about dbus libraries
Nov 04 14:21:48 <raster> u do need to use some of its wrappers for sending :)
Nov 04 14:21:51 <Ainulindale> But we'll care about mainloops
Nov 04 14:21:58 <Ainulindale> Why ?
Nov 04 14:22:13 <raster> becaus it needs to add the pending message to its list
Nov 04 14:22:16 <raster> handle timeouts
Nov 04 14:22:17 <Ainulindale> Why not use libdbus directly for that kind of stuff then ?
Nov 04 14:22:26 <raster> handle calling the marshallers on return of the call
Nov 04 14:22:27 <raster> etc.
Nov 04 14:22:39 <raster> the mainloop needs to know about it
Nov 04 14:22:48 <Ainulindale> raster: Hence what I'm saying
Nov 04 14:22:58 <Ainulindale> To really be toolkit/mainloop agnostic
Nov 04 14:23:00 <raster> each religion have their own bindings at that level
Nov 04 14:23:14 <Ainulindale> We'll have to be able to tie to the mainloop of the toolkit, whichever toolkit
Nov 04 14:23:21 <raster> and chances are each is vastly different
Nov 04 14:23:25 <Ainulindale> And to handle send/receive using libdbus
Nov 04 14:23:33 <raster> as they conform to the worldview of each religion
Nov 04 14:23:34 <raster> :)
Nov 04 14:23:35 <Ainulindale> send/receive can be generic
Nov 04 14:23:40 <Ainulindale> mainloop can't
Nov 04 14:24:02 <Ainulindale> What I'd suggest would be to build a "libframeworkd" which will handle send/receive
Nov 04 14:24:11 <Ainulindale> And "libframeworkd-*" which will handle mainloops
Nov 04 14:24:37 <Ainulindale> Without any dependency to dbus-glib, or e_dbus, or whatever
Nov 04 14:25:34 <raster> then u'll need to do that footwork
Nov 04 14:25:39 <raster> in libwfd
Nov 04 14:25:46 <Ainulindale> libwtf ? :-)
Nov 04 14:25:52 <Ainulindale> raster: footwork ?
Nov 04 14:26:04 <raster> for example
Nov 04 14:26:10 <raster> e_dbus_message_send()
Nov 04 14:26:13 <Ainulindale> Indeed
Nov 04 14:26:16 <raster> whihc just sends a dbus message
Nov 04 14:26:23 <Ainulindale> I'll have to reimplement that
Nov 04 14:26:24 <raster> after u've filled it with call info/parameters
Nov 04 14:26:26 <Ainulindale> Using libdbus
Nov 04 14:26:30 <raster> is 2 libdbus calls
Nov 04 14:26:30 <Ainulindale> Is that what you mean ?
Nov 04 14:26:56 <raster> as well as allcing a call pending strruct to hold the callback to call when the reply returns
Nov 04 14:27:03 <raster> also remember
Nov 04 14:27:15 <raster> edbus is not going to do nasty things like blocking calls
Nov 04 14:27:19 <raster> if we can avoid it
Nov 04 14:27:27 <raster> ie reply = my_call_wrapper(x);
Nov 04 14:27:32 <Ainulindale> raster: why are you talking about edbus ?
Nov 04 14:27:33 <raster> that would send a dbus message
Nov 04 14:27:40 <raster> aand block waiting for a reply
Nov 04 14:27:53 <raster> i am taking it as an example of what u'd have to implement
Nov 04 14:28:04 <Ainulindale> Ok, just clearing a possible misunderstanding
Nov 04 14:28:16 <Ainulindale> raster: Anyway, for that kind of stuff, I would think about quietly fork edbus
Nov 04 14:28:18 <raster> glib willhave its wrapepr
Nov 04 14:28:20 <raster> as qt its own
Nov 04 14:28:43 <Ainulindale> edbus or any kind of agnostic dbus management library
Nov 04 14:28:50 <raster> edbus itself is probably the smallest wrapper
Nov 04 14:29:04 <raster> as it only handles a convenience layer to hook to the mainloop
Nov 04 14:29:15 <Ainulindale> Which we would strip of
Nov 04 14:29:32 <raster> tho it does handle other things
Nov 04 14:29:35 <raster> like exposing intropsection
Nov 04 14:29:37 <raster> for u
Nov 04 14:29:43 <raster> if u are a dbus service provider
Nov 04 14:29:43 <raster> :)
Nov 04 14:29:49 <Ainulindale> We don't care about instropection :-)
Nov 04 14:29:52 <thseiler_> Ainulindale: I think you will have to do your own thread, with your own private dbus connection then.
Nov 04 14:30:00 <raster> for libfwd - of course not
Nov 04 14:30:04 <raster> you're a client
Nov 04 14:30:05 <Ainulindale> thseiler_: why ?
Nov 04 14:30:07 <thseiler_> this is the only way to be really agnostic on what happens in the mainloop
Nov 04 14:30:12 <Ainulindale> thseiler_: nope
Nov 04 14:30:18 <thseiler_> if you don't want to integrate there, then have you own loop ;-)
Nov 04 14:30:20 <Ainulindale> You didn't catch my point I think
Nov 04 14:30:27 <thseiler_> quite possible...
Nov 04 14:30:37 <Ainulindale> What I would like to do is build a common base
Nov 04 14:30:39 <raster> Ainulindale:  i agree that u dont want to tie to 1 abstraction and 1 mainloop
Nov 04 14:30:42 <raster> keep agnostic
Nov 04 14:30:43 <thseiler_> i was just skimming over the conversation, sorry, but got a bit of pression here ;-)
Nov 04 14:30:45 <raster> the mroe agnostic u are
Nov 04 14:30:45 <Ainulindale> Able to send and receive messages regardless of the mainloop
Nov 04 14:30:50 <raster> the more work u'll end up doing
Nov 04 14:30:58 <Ainulindale> This library would be closely tied to a set of sublibraries
Nov 04 14:31:03 <Ainulindale> Attaching to the mainloop of a given toolkit
Nov 04 14:31:16 <raster> it depends on your api design
Nov 04 14:31:16 <thseiler_> so you have a mainloop - abstraction
Nov 04 14:31:17 <Ainulindale> i.e. if you want to use dbus over a glib mainloop
Nov 04 14:31:19 <raster> will it be syncrhonous?
Nov 04 14:31:22 <Ainulindale> raster: no
Nov 04 14:31:27 <raster> good
Nov 04 14:31:30 <Ainulindale> let me finish my example
Nov 04 14:31:33 <raster> then it gets complicated
Nov 04 14:31:33 <Ainulindale> i.e. if you want to use dbus over a glib mainloop
Nov 04 14:31:35 <raster> :(
Nov 04 14:31:41 <Ainulindale> you'll have a libframeworkd-glib sublibrary
Nov 04 14:31:53 <Ainulindale> with an abstracted set of methods
Nov 04 14:31:57 <raster> as all replies are deferred and need callbacks and handles to the call itself and its pending callbacks
Nov 04 14:31:58 <raster> :(
Nov 04 14:31:59 <Ainulindale> i.e. mainloop_init()
Nov 04 14:32:08 <Ainulindale> and you'll dlopen the library based on the developer indications
Nov 04 14:32:18 <Ainulindale> i.e. libframeworkd_init(GLIB)
Nov 04 14:32:22 <Ainulindale> which would dlopen the library
Nov 04 14:32:25 <Ainulindale> attach to the mainloop
Nov 04 14:32:29 <Ainulindale> and sit & enjoy
Nov 04 14:32:41 <Ainulindale> raster: we're doing that already
Nov 04 14:32:48 <raster> ok
Nov 04 14:32:52 <Ainulindale> Everything in lfg is asynchronous
Nov 04 14:32:54 <raster> then u already have overlap with edbus
Nov 04 14:32:59 <Ainulindale> I won't implement synchronus
Nov 04 14:33:00 <raster> as it does that too
Nov 04 14:33:01 <Ainulindale> +o
Nov 04 14:33:11 <Ainulindale> raster: when I say asynchronous
Nov 04 14:33:20 <Ainulindale> Just look at the following link
Nov 04 14:33:41 <Ainulindale> http://git.freesmartphone.org/?p=libframeworkd-glib.git;a=blob;f=src/ousaged/frameworkd-glib-ousaged.c;h=436f59040933499cc536f5d092ba425f1bfd0517;hb=HEAD
Nov 04 14:33:44 <Ainulindale> Mere example
Nov 04 14:34:06 <Ainulindale> Here what we'll have to do would be to "agnosticize" the types
Nov 04 14:34:21 <Ainulindale> And replace the org_freesmartphone_ thingies by wrappers to libdbus
Nov 04 14:34:30 <Ainulindale> (they're dbus-binding-tools macros)
Nov 04 14:35:03 <Ainulindale> (and we can easily replace them with a call to a forked edbus library)
Nov 04 14:35:05 <raster> Ainulindale: ok - yup. same stuff edbus does too
Nov 04 14:35:06 <raster> yes
Nov 04 14:35:11 <raster> call and keep processing
Nov 04 14:35:23 <raster> any error return or data returns handled in callback when/if the return comes in
Nov 04 14:35:24 <Ainulindale> raster: Anyway, regardless of that political discussion
Nov 04 14:35:35 <Ainulindale> I think the current architecture of lfg is well and good
Nov 04 14:35:41 <Ainulindale> I think we managed to build a sound thing
Nov 04 14:35:48 <Ainulindale> If we manage to give it this agnostic side
Nov 04 14:35:54 <Ainulindale> And if we manage to use libdbus directly
Nov 04 14:36:02 <Ainulindale> Does this have a meaning for you guys N?
Nov 04 14:36:05 <raster> that'd be the key
Nov 04 14:36:07 <Ainulindale> (i.e. thseiler_, raster)
Nov 04 14:36:14 <raster> libdbus directly
Nov 04 14:36:26 <Ainulindale> I know the tie to glib is problematic know
Nov 04 14:36:29 <Ainulindale> -k
Nov 04 14:36:31 <Ainulindale> Hence this discussion
Nov 04 14:36:39 <raster> but i really see that its going to be a lot of work to abstract
Nov 04 14:36:46 <raster> as u will be re-inventing bits
Nov 04 14:36:53 <Ainulindale> Which bits ?
Nov 04 14:36:56 <raster> nb
Nov 04 14:36:58 <Ainulindale> Types ?
Nov 04 14:36:58 <raster> i see problems
Nov 04 14:37:01 <raster> your callbacks
Nov 04 14:37:03 <raster> u get no handle
Nov 04 14:37:07 <raster> eg
Nov 04 14:37:17 <raster> ousaged_suspend()
Nov 04 14:37:22 <raster> i can provide the callback
Nov 04 14:37:40 <raster> how do i cacnel the call to my callback when the reply comes in?
Nov 04 14:37:42 <raster> :)
Nov 04 14:37:44 <raster> cancel
Nov 04 14:37:51 <Ainulindale> What do you mean by cancel ?
Nov 04 14:38:01 <raster> i call ousaged_suspend()
Nov 04 14:38:05 <raster> provide a callback
Nov 04 14:38:15 <raster> then next function i dont want my callback called anymore
Nov 04 14:38:35 <raster> because i an dlclose()ing the shared object the callback lives in
Nov 04 14:38:36 <raster> :)
Nov 04 14:38:49 <Ainulindale> Right now, this wouldn't be doable
Nov 04 14:38:53 <raster> or the gpointer that is passed
Nov 04 14:39:00 <Ainulindale> But you're talking of an extremely rare case I think
Nov 04 14:39:00 <raster> poitns to a window/widget i have destroyed
Nov 04 14:39:04 <raster> so whent he callback is called
Nov 04 14:39:10 <raster> it tries to access a deleted object
Nov 04 14:39:14 <raster> aaah
Nov 04 14:39:19 <raster> rarfe but important
Nov 04 14:39:22 <raster> rare
Nov 04 14:39:29 <raster> its something e does all the time
Nov 04 14:39:31 <Ainulindale> Rare hence not worth time right now :-)
Nov 04 14:39:43 <Ainulindale> Anyway if I refactor this
Nov 04 14:39:46 <raster> a cause for segvs by design
Nov 04 14:39:50 <raster> yeah
Nov 04 14:39:50 <Ainulindale> I'll build an handler just for you
Nov 04 14:39:53 <raster> at least return some handle
Nov 04 14:39:57 <Ainulindale> So you'll shut up :-)
Nov 04 14:40:00 <raster> so u can "delete' the callback
Nov 04 14:40:06 <raster> even if u dont implement the delete
Nov 04 14:40:11 <Ainulindale> raster: you mean
Nov 04 14:40:14 <raster> at least dont make it buggy by design :)
Nov 04 14:40:25 <Ainulindale> data ousaged_suspend(callback, userdata)
Nov 04 14:40:29 <raster> maye it buggy by "we're too busy to implement the delete properly"
Nov 04 14:40:30 <raster> :)
Nov 04 14:40:30 <Ainulindale> and data->cb = callback
Nov 04 14:40:33 <Ainulindale> is that it ?
Nov 04 14:40:35 <raster> yes
Nov 04 14:40:36 <raster> correct
Nov 04 14:40:40 <Ainulindale> Ok*
Nov 04 14:40:43 <Ainulindale> I see your point
Nov 04 14:40:45 <raster> void ousaged_suspend(void (*callback)(GError *, gpointer), gpointer userdata)
Nov 04 14:40:50 <Ainulindale> It bores me already but I see your point
Nov 04 14:40:52 <raster> imagine its a slower call
Nov 04 14:40:54 <raster> like
Nov 04 14:40:55 <Ainulindale> You're a boring guy you know that ? :-)
Nov 04 14:41:09 <raster> get_my_entire_pim_database
Nov 04 14:41:19 <raster> and my pim database lives in an ldap server over a gprs ppp data link
Nov 04 14:41:25 <raster> it could take many seconds to return
Nov 04 14:41:32 <Ainulindale> A gprs ppp data link to the moon
Nov 04 14:41:39 <raster> user may get bored waiting
Nov 04 14:41:41 <Ainulindale> While I live on venus
Nov 04 14:41:46 <Ainulindale> Or on uranus
Nov 04 14:41:46 <raster> and close his "list contacts" window
Nov 04 14:41:47 <raster> :)
Nov 04 14:41:52 <Ainulindale> Yeah, I know what you mean raster 
Nov 04 14:42:04 <Ainulindale> Just keep in mind I chose the simplest road there
Nov 04 14:42:09 <Ainulindale> I had to have something quick
Nov 04 14:42:11 <raster> i know
Nov 04 14:42:24 <raster> but i'd at least have returned a handle
Nov 04 14:42:30 <Ainulindale> I don't have the pretention to say my stuff is rock solid and bug free :-)
Nov 04 14:42:35 <raster> and then just always return (void *)1
Nov 04 14:42:48 <Ainulindale> anyway
Nov 04 14:42:49 <raster> and implement the handle delete/tracking later
Nov 04 14:42:50 <raster> :)
Nov 04 14:43:06 <Ainulindale> thseiler_: are you interested in helping to realize what we talked about there ?
Nov 04 14:43:28 <Ainulindale> It's boring work, but you may already have realized that doing your stuff
Nov 04 14:43:37 <Ainulindale> Boring but useful for everyone
Nov 04 14:43:52 <raster> yeah
Nov 04 14:43:54 <raster> i do agree
Nov 04 14:43:56 <raster> its boring
Nov 04 14:43:59 <raster> dotting i's
Nov 04 14:44:02 <raster> crossing t's
Nov 04 14:44:15 <raster> i've learnt to just live with it
Nov 04 14:44:19 <raster> over the years
Nov 04 14:44:27 <raster> just one of those "got to be done" things
Nov 04 14:44:29 <Ainulindale> i's and t's ?
Nov 04 14:44:36 <raster> yeah
Nov 04 14:44:38 <joerg_42> :-)
Nov 04 14:44:41 <Ainulindale> You lost me there
Nov 04 14:44:46 <raster> taking care of details == "dotting i's and crossing t's"
Nov 04 14:44:53 <raster> (english expression)
Nov 04 14:44:54 <joerg_42> :@
Nov 04 14:45:10 <Ainulindale> The only thing I find more boring that this is trying to persuade joerg_42 to send me an extra freerunner motherboard to test his gsm buzz fix
Nov 04 14:45:15 <Ainulindale> s/that/than/
Nov 04 14:45:18 <raster> i learnt to at least (hopefully) avoid design mistakes
Nov 04 14:45:26 <joerg_42> lol
Nov 04 14:45:27 <raster> and at least desing something to be solid
Nov 04 14:45:34 <raster> even if the itnernals dont implement it all (yet)
Nov 04 14:45:35 <raster> :)
Nov 04 14:45:46 <Ainulindale> raster: I know how to do that in Java, but it's been a while since I did C
Nov 04 14:47:46 <raster> Ainulindale: :) but overall the api looks good
Nov 04 14:47:48 <raster> simple
Nov 04 14:47:50 <raster> simple is good
Nov 04 14:47:55 <raster> but it just needs a few extras
Nov 04 14:48:19 <Ainulindale> raster: and anyway it's a very good way to pinpoint problem in the specs or in the code :-)
Nov 04 14:48:43 <raster> just was mentioning a problem that stuck out :)
Nov 04 14:48:44 <raster> thats all
Nov 04 14:49:07 <stefan_schmidt> moin
Nov 04 14:49:15 <stefan_schmidt> What are you guys doing?
Nov 04 14:49:34 <Hire> i am working :>
Nov 04 14:49:38 <stefan_schmidt> Making _one_ lib that all apss use for FSO dbus calls within EFL?
Nov 04 14:49:41 <Ainulindale> I am avoiding work
Nov 04 14:49:44 <raster> stefan_schmidt: scratching my.... toes
Nov 04 14:49:45 <Kensan_> stefan_schmidt: reading rasters and Ainulindale's dispute ;)
Nov 04 14:49:50 <stefan_schmidt> Ainulindale: always good :)
Nov 04 14:49:59 <Ainulindale> stefan_schmidt: no
Nov 04 14:50:00 <stefan_schmidt> raster: As always ;)
Nov 04 14:50:08 <Ainulindale> Making one lib all C apps would use for dbus calls
Nov 04 14:50:11 <Ainulindale> Regardless of the toolkit
Nov 04 14:50:11 <stefan_schmidt> Kensan_: To much to read
Nov 04 14:50:17 <Ainulindale> One lib to bind them all in fact
Nov 04 14:50:23 <stefan_schmidt> Ainulindale: ah, even better then :)
Nov 04 14:50:25 <raster> Ainulindale:  if u really wanted to simplify
Nov 04 14:50:27 <Kensan_> stefan_schmidt: indeed.
Nov 04 14:50:29 <Hire> i read all the little e shiny catfight 
Nov 04 14:50:36 <raster> u could jst create a FSO object
Nov 04 14:50:37 <raster> ie
Nov 04 14:50:43 <raster> fso = fso_new();
Nov 04 14:50:46 * stefan_schmidt is more in mood of turning on the Wii to play wiifit :)
Nov 04 14:51:05 <raster> fso_call_suspend(fso, callback, ...);
Nov 04 14:51:07 <Hire> in that case we need a garbage collector :>
Nov 04 14:51:11 <raster> if i fso_del(fso);
Nov 04 14:51:16 <Kensan_> stefan_schmidt: heh that's supposed to be fun for your neighbours to watch ;)
Nov 04 14:51:19 <raster> all pending callbacks are deleted fromt he fso object
Nov 04 14:51:26 <raster> fso object tracks all pending callbacks etc.
Nov 04 14:51:32 <raster> also can track/shadow state etc.
Nov 04 14:51:33 <Ainulindale> raster: http://git.freesmartphone.org/?p=libframeworkd-glib.git;a=blob;f=src/frameworkd-glib-dbus.h;h=8b545face5f16c9c1305a5b061087802fb7a1d3e;hb=HEAD
Nov 04 14:51:33 <raster> if u like
Nov 04 14:51:37 <Ainulindale> See line 33
Nov 04 14:51:52 <quickdev> Hey
Nov 04 14:51:56 <stefan_schmidt> Kensan_: Well, I'm at alphaone place and he lives at 13th floor...
Nov 04 14:51:59 <Ainulindale> quickdev: I'm breaking everything
Nov 04 14:52:04 <Ainulindale> Starting wednesday
Nov 04 14:52:09 <Hire> hi quickdev :>
Nov 04 14:52:15 <quickdev> Ainulindale, libframeworkd-glib?
Nov 04 14:52:18 <Ainulindale> Yes
Nov 04 14:52:28 <quickdev> what are you going to do? :)
Nov 04 14:52:37 <Ainulindale> Bug raster out
Nov 04 14:52:39 <raster> Ainulindale: hmm looks like a start
Nov 04 14:52:40 <Ainulindale> And force him to use my stuff
Nov 04 14:52:44 <raster> tho thats goign to be a big struct
Nov 04 14:52:49 <raster> :)
Nov 04 14:52:51 <Ainulindale> raster: this is just for signals
Nov 04 14:53:12 <Ainulindale> We could decline it per subsystem/interface
Nov 04 14:53:18 <quickdev> raster, for what are you going to use libframeworkd-glib? fso widgets?
Nov 04 14:53:29 <Ainulindale> quickdev: I was merely joking
Nov 04 14:53:31 <raster> quickdev:  right now - unknown
Nov 04 14:53:34 <stefan_schmidt> quickdev: You can going to use elementary for SHR?
Nov 04 14:53:45 <Ainulindale> quickdev: remember that discussion we had about agnosticity of type and mainloop ?
Nov 04 14:53:46 <raster> libefso is preferable
Nov 04 14:53:53 <quickdev> stefan_schmidt, I'm already using it....locally...but it'snot ready 100% ;)
Nov 04 14:53:54 <raster> depends on what efso and libfwd do
Nov 04 14:53:59 <stefan_schmidt> quickdev: good
Nov 04 14:54:23 <stefan_schmidt> Nice to see good apps poping up and the pieces falling together :)
Nov 04 14:54:37 <Ainulindale> stefan_schmidt: though currently SHR is already usable in EFL
Nov 04 14:54:52 <Hire> Ainulindale does always bad jokes :>
Nov 04 14:54:55 <Ainulindale> quickdev: by the way, icon problem
Nov 04 14:55:03 <Ainulindale> quickdev: talking with raster we figured out the problem
Nov 04 14:55:08 <stefan_schmidt> Ainulindale: yeah, alphaone told me.
Nov 04 14:55:10 <quickdev> perfect
Nov 04 14:55:11 <raster> i also need to toss up if elementary should actually do dbus stuff itselgf
Nov 04 14:55:14 <raster> itself
Nov 04 14:55:15 <Ainulindale> We're using shared-mime-info 0.22
Nov 04 14:55:20 <Ainulindale> Which does not regenerate the mime database
Nov 04 14:55:21 <raster> or if elementayr should be data source agnositc
Nov 04 14:55:27 <raster> and require helper libs to provide data
Nov 04 14:55:29 <Ainulindale> We should use latest or modify the bb
Nov 04 14:55:46 <Ainulindale> stefan_schmidt: did you see the screens ?
Nov 04 14:55:49 * stefan_schmidt leaves here in favour of wii fit
Nov 04 14:55:53 <stefan_schmidt> Ainulindale: yes
Nov 04 14:55:58 <Ainulindale> Thoughts ?
Nov 04 14:56:16 <Ainulindale> (Advices?)
Nov 04 14:56:23 <quickdev> Ainulindale, agnosticity of type? type is glib? and what about the main loop?
Nov 04 14:56:32 <stefan_schmidt> Ainulindale: Not yet. Give me some time after MS4 and I'll test them out
Nov 04 14:56:40 <raster> Ainulindale: shared-mime-info_0.22-r1.1_armv4t.ipk
Nov 04 14:56:43 <Ainulindale> quickdev: We were talking a while ago of being able to use lfg without implictely using glib
Nov 04 14:56:45 <raster> thats actually the one i build
Nov 04 14:56:49 <raster> and it does update the mime db
Nov 04 14:56:49 <stefan_schmidt> Ainulindale: Will give you give some personla feedback then
Nov 04 14:57:01 <Ainulindale> quickdev: and the glib mainloop
Nov 04 14:57:06 <Ainulindale> quickdev: that's what I want to do
Nov 04 14:57:08 <quickdev> stefan_schmidt, you should wait till the new elementary apps are there ;)
Nov 04 14:57:11 <Ainulindale> That requires a lot of work though
Nov 04 14:57:16 <Ainulindale> stefan_schmidt: ok then
Nov 04 14:57:20 <Ainulindale> raster: weird
Nov 04 14:57:25 <quickdev> Ainulindale, yeah, open a branch then please
Nov 04 14:57:41 <Ainulindale> quickdev: Well, no
Nov 04 14:57:46 <raster> Ainulindale:  i noted that thseiler_'s image was missing the .postinst file
Nov 04 14:57:48 <Ainulindale> I was thinking of breaking everything including our buildhost
Nov 04 14:57:49 <raster> my image had it
Nov 04 14:57:52 <Ainulindale> Would that please you ? :-)
Nov 04 14:57:54 <stefan_schmidt> quickdev: You have some days...
Nov 04 14:57:55 <raster> and the postinst updated the mime db
Nov 04 14:57:59 <stefan_schmidt> quickdev: joking :)
Nov 04 14:58:05 <raster> (ran the mime update command)
Nov 04 14:58:07 <quickdev> Ainulindale, btw...I figured out what the frameworkd/ophonekitd stablity / gsm lost problem was...alphaone helped me
Nov 04 14:58:14 <Ainulindale> What was it?
Nov 04 14:58:46 <quickdev> Ainulindale, you're joking agan? :)
Nov 04 14:59:09 <Ainulindale> quickdev: Damn ! You got me this time
Nov 04 14:59:24 <quickdev> Ainulindale, when gsm is resumed...it's "disabled" for the first seconds....and ophonekitd makes a call immediately after suspend. we can work around it by waiting some seconds after incoming message trigger
Nov 04 14:59:28 <Ainulindale> I think I'm doomed to be a bad joker or not being understood at all :-)
Nov 04 14:59:53 <Ainulindale> quickdev: I wouldn't do that
Nov 04 15:00:10 <Ainulindale> quickdev: I would do the call and handle the case when GSM is disabled
Nov 04 15:00:21 <quickdev> raster, I'm creating an elementary widget for the keypad. Is it a reasonable way to do it?
Nov 04 15:00:24 <Ainulindale> It would settle the "NO SIM" problem :-)
Nov 04 15:00:44 <raster> quickdev:  table + buttons?
Nov 04 15:00:49 <quickdev> Ainulindale, but in that case GSM is not disabled...it's just not resumed
Nov 04 15:01:10 <Ainulindale> quickdev: I know, but we have a known error
Nov 04 15:01:21 <Ainulindale> i.e. "Resource not enabled" or something like that
Nov 04 15:01:23 <quickdev> raster, edje object with some buttons swallowed...packed in a elm widget for better handling - I don't want swallow all 9 buttons every time
Nov 04 15:01:23 <joerg_42> Ainulindale: (wait) exactly. never introduce a wait to fix a race
Nov 04 15:01:25 <Ainulindale> Haven't we ?
Nov 04 15:01:45 <Ainulindale> joerg_42: Heh :-)
Nov 04 15:02:10 <quickdev> joerg_42, it's just a workaround. alphaone will fix it sooner or later :)
Nov 04 15:02:31 <Ainulindale> quickdev: I'd rather work around this using the right method :-)
Nov 04 15:02:34 <Hire> i cut the head of android
Nov 04 15:02:59 <Ainulindale> We have the same problem if we try to make a call while SIM isn't ready
Nov 04 15:03:07 <quickdev> Ainulindale, although it's very dirty it's very simple and will work ;)
Nov 04 15:03:21 <Ainulindale> quickdev: handling the error is far more pretty and would also work :-)
Nov 04 15:03:30 <raster> quickdev: well u could make the pad 1 edje design
Nov 04 15:03:33 <Ainulindale> And I don't find it that difficult :-)
Nov 04 15:03:44 <raster> and listen to signals telling u what button was pressed
Nov 04 15:03:48 <raster> more freedom in design
Nov 04 15:03:52 <quickdev> raster, yes, but I need to swallow all 9 buttons each time
Nov 04 15:03:52 <raster> but also more work
Nov 04 15:03:59 <raster> dont wallow any
Nov 04 15:04:02 <raster> make buttons part of the edje
Nov 04 15:04:06 <raster> thats one option
Nov 04 15:04:07 <raster> but yes
Nov 04 15:04:13 <raster> othe other optin is creating 9 buttons
Nov 04 15:04:15 <raster> and swallow
Nov 04 15:04:21 <raster> one dy
Nov 04 15:04:22 <raster> day
Nov 04 15:04:25 <raster> read gimp's code
Nov 04 15:04:29 <raster> or most gui apps
Nov 04 15:04:39 <raster> the idea of making 2 buttons and wallowing (packing) them
Nov 04 15:04:43 <Ainulindale> thseiler_: still waiting for your answer here :-)
Nov 04 15:04:48 <raster> is nothing compared to most of the ui stuff they do
Nov 04 15:04:50 <quickdev> raster, how do I make elementary buttons as a part of the edje file?
Nov 04 15:05:00 <raster> well the simple beginner way
Nov 04 15:05:04 <raster> make each just an image
Nov 04 15:05:12 <raster> on mouse,down,1 emit a signal
Nov 04 15:05:25 <raster> arrange them in a 3x4 grid
Nov 04 15:05:35 <joerg_42> Ainulindale: quickdev:  e.g to test for modem responsive U can send "AT" anw test for "OK" answer
Nov 04 15:05:41 <raster> (u actually need 12 not 9 - need 0 and * and #)
Nov 04 15:05:55 <quickdev> joerg_42, we're using frameworkd. not acting with the modem directly :)
Nov 04 15:06:03 <raster> then u need a backspace button
Nov 04 15:06:05 <raster> ...
Nov 04 15:06:05 <joerg_42> i know
Nov 04 15:06:14 <joerg_42> just an example
Nov 04 15:06:20 <quickdev> raster, yes, I have 12. Just wanted to simplify it for your understanding :)
Nov 04 15:06:37 <quickdev> 12 + 3 function buttons
Nov 04 15:07:39 <quickdev> raster, isn't there an advantage if I use images for the buttons? What if the elementary theme changes? I have to replace the image?
Nov 04 15:09:29 <raster> yes
Nov 04 15:09:39 <raster> using images means u can have a custom dialler design
Nov 04 15:09:43 <raster> with csutom buttons and setup
Nov 04 15:09:48 <raster> but u will now not follow a theme change
Nov 04 15:09:54 <raster> its always a tradeoff in amount of work
Nov 04 15:09:55 <raster> consistency
Nov 04 15:10:06 <raster> ability to customise and "be unique"
Nov 04 15:10:17 <raster> and how much you want to "conform"
Nov 04 15:10:37 <quickdev> yeah..I'll go the consistent way
Nov 04 15:12:32 <raster> then a table
Nov 04 15:12:35 <raster> with 12 buttons
Nov 04 15:12:39 <raster> that'll do the job
Nov 04 15:12:39 <raster> :)
Nov 04 15:12:54 <raster> ok
Nov 04 15:13:00 <raster> goign to have to snooze soon
Nov 04 15:13:10 <Hire> here is raining
Nov 04 15:13:17 <Hire> sad
Nov 04 15:13:18 <Hire> :|
Nov 04 15:13:23 <Hire> nice snooze raster
Nov 04 15:13:49 <quickdev> raster, would you pack it into a widget if you have to use it 3 times? and if you only want one clicked callback? ;)
Nov 04 15:13:50 <raster> nite!
Nov 04 15:13:51 <raster> :)
Nov 04 15:14:10 <raster> quickdev:  yes
Nov 04 15:14:19 <quickdev> quickdev, ok, have a good night
Nov 04 15:14:19 <Hire> nite? here is day :o
Nov 04 15:14:24 <raster> i'd just write a "build_me_a_table_ofbuttons()" func
Nov 04 15:14:26 <raster> that does that
Nov 04 15:14:32 <raster> and packs the table with the buttonds
Nov 04 15:14:43 <raster> and a label/entry with the result of your pressing
Nov 04 15:14:44 <raster> :)
Nov 04 15:15:32 <joerg_42> bye
Nov 04 15:17:05 <Hire> oh my god i can't driving with this weather
Nov 04 15:18:28 <sicu_> Hire: you'll have to get you bicycle out ;]
Nov 04 15:18:47 <Hire> i have a car :o
Nov 04 15:19:33 <quickdev> "Now my opinion is that if paroli succeed in doing that, then illume shouldn't be needed at all", people might think different, hehe
Nov 04 15:20:41 <Hire> omg
Nov 04 15:20:48 <Hire> i cant' exit from the office !!!
Nov 04 15:20:51 <Hire> too rain
Nov 04 15:21:07 <Hire> ah yes i read it 
Nov 04 15:21:35 <Hire> but sorry i don't like so much paroli+tichy
Nov 04 15:37:13 <Kensan_> raster: gnight, catch you later.
Nov 04 15:42:20 <alphaone> Ainulindale: | phonegui-messages.c: In function 'add_integer_timestamp_to_message':
Nov 04 15:42:20 <alphaone> | phonegui-messages.c:162: error: 'FIXME' undeclared (first use in this function)
Nov 04 15:45:26 <Ainulindale> alphaone: that's quickdev's fault
Nov 04 15:45:35 <Ainulindale> Please include the SHR srcrev 
Nov 04 15:45:44 <Ainulindale> The corret SVN revision is there
Nov 04 15:45:47 <Ainulindale> +c
Nov 04 15:46:11 <Ainulindale> (openembedded/conf/distro/include/shr-autorev.inc IIRC)
Nov 04 15:46:25 <quickdev> SRCREV_pn-libframeworkd-phonegui-efl = "391"
Nov 04 15:46:59 <Ainulindale> I'm off for a while, got to work for once
Nov 04 15:48:28 <thseiler_> Ainulindale: bye, i will try to answer you when I am done with my work...
Nov 04 15:49:18 <alphaone> bye Ainulindale 
Nov 04 15:49:48 <Hire> good work Ainulindale
Nov 04 15:55:08 <quickdev> Hire, have you talked with him about the icons?
Nov 04 15:56:04 <Hire> yes
Nov 04 15:56:09 <Hire> it's okay for him
Nov 04 15:56:20 <Hire> i need to packing them :D
Nov 04 15:59:37 <Hire> i am going to be crazy to test android
Nov 04 15:59:41 <Hire> i can't it boot on FR
Nov 04 16:19:49 <Hire> OHHH
Nov 04 16:19:53 <Hire> finally i get android boot on FR
Nov 04 16:21:22 <tomboy64> and?
Nov 04 16:23:42 <Hire> it sucks
Nov 04 16:31:01 <sicu> and so say we all
Nov 04 16:32:12 <Hire> i am going to home now
Nov 04 16:32:15 <Hire> bye :D
Nov 04 16:32:26 <MarcOChapeau> alphaone:  'FIXME' undeclared ? rofl
Nov 04 16:32:50 <alphaone> MarcOChapeau: That's what I thought as well :-)
Nov 04 16:34:53 <MarcOChapeau> it's certainly something that needs fixing :-p
Nov 04 16:35:32 <alphaone> hehe
Nov 04 16:35:47 <quickdev> MarcOChapeau, http://rafb.net/p/W584KO36.html
Nov 04 16:36:01 <quickdev> will commit my sources later
Nov 04 16:39:47 <Ainulindale> quickdev: you're a bad boy, committing like this :-)
Nov 04 16:39:54 <Ainulindale> You'll get spanked
Nov 04 16:39:58 <Ainulindale> I'll supervise that personally
Nov 04 16:40:07 <quickdev> it was a fault ;) didn't run svn status to see what else is committed ;)
Nov 04 16:40:28 <Ainulindale> quickdev: Anyway it'll happen to me some day I think
Nov 04 16:40:39 <Ainulindale> I still have a libframeworkd-phonegui-ncurses waiting to be commited on my computer
Nov 04 16:41:07 <quickdev> hehe
Nov 04 16:41:10 <Ainulindale> And some other stuff
Nov 04 16:46:12 <quickdev> brb
Nov 04 17:16:31 <quickdev> alphaone, mickeyl, someone at the ccc this year?
Nov 04 17:18:01 <Kensan_> quickdev: afaik Harald will talk about something gsm related.
Nov 04 17:36:30 <quickdev> alphaone, GSM not enabled problems seems to be there immediately after releasing a call. Might that be possible?
Nov 04 17:42:28 <quickdev> alphaone, will try to confirm it ;)
Nov 04 17:42:37 <Ainulindale> I love that
Nov 04 17:42:46 <Ainulindale> Just by using what we built we're finding dumb problems :-)
Nov 04 17:43:13 * Hire is at home
Nov 04 17:43:29 <Ainulindale> Lucky guy
Nov 04 17:44:41 <Hire> yes
Nov 04 17:44:47 <Hire> here is raining very bad
Nov 04 17:44:49 <Hire> however
Nov 04 17:44:59 <Hire> i have do some screenies from android
Nov 04 17:45:06 <Hire> and I can say... it sucks 
Nov 04 17:45:35 <Hire> http://www.okiwii.net/viewer.php?file=3kuclmmcpptuhvicm23d.jpg
Nov 04 17:45:41 <Hire> http://www.okiwii.net/viewer.php?file=u1mtwj1hi9x8yogeswny.jpg
Nov 04 17:45:44 <Hire> http://www.okiwii.net/viewer.php?file=2epzez31pxtix9hzw2fn.jpg
Nov 04 17:45:48 <Hire> http://www.okiwii.net/viewer.php?file=eo4tog83h3yqqi4hunb8.jpg
Nov 04 17:45:53 <Hire> http://www.okiwii.net/viewer.php?file=e0de8d9bx80syjmdyuei.jpg
Nov 04 17:45:57 <Hire> http://www.okiwii.net/viewer.php?file=qnsqi2uskijxwl3z6jr.jpg
Nov 04 17:46:06 <Hire> if someone want to see android on Fr
Nov 04 17:48:17 <quickdev> see you later
Nov 04 18:25:12 <alexxy> Ainulindale: hi
Nov 04 18:25:35 <alexxy> Ainulindale: is SHR currently usable for regular telephony?
Nov 04 18:30:39 <Hire> mmm
Nov 04 18:30:43 <Hire> yes
Nov 04 18:32:57 <Hire> you can try it 
Nov 04 18:33:27 <Hire> so you can see if shr respect your expectation
Nov 04 18:45:51 <alexxy> i'm currently uses daily builds with qtopia-x11
Nov 04 18:52:41 <Kensan> Does anybody have experience with a debugboard?
Nov 04 18:55:06 <Hire> alexxy: i always used shr as daily phone without problem
Nov 04 18:55:09 <CIA-16> freesmartphone.org: 03morphis * r319 10/trunk/python-elementary/ (Makefile TODO elementary/elementary.pyx tests/test01.py): Added smart callback handling
Nov 04 18:55:20 <Hire> and i think shr is better then om/qtopia/etcetera 
Nov 04 18:56:01 <alexxy> Hire: ok i flashing it now =)
Nov 04 18:56:21 <Hire> nice
Nov 04 18:56:45 <Hire> after you have flashed see want you like from it
Nov 04 18:57:04 <Hire> and talk here about your feeling on SHR
Nov 04 18:57:49 <Hire> however contacts, messages and dialer has a ugly ui for now because quickdev is porting them on elemetary
Nov 04 18:58:00 <alexxy> also i will try to build gentoo + fso 
Nov 04 19:00:50 <Hire> oh
Nov 04 19:00:58 <Hire> why do you want to bash your FR?
Nov 04 19:02:16 <alexxy> just for fun
Nov 04 19:02:16 <alexxy> =)
Nov 04 19:02:23 <alexxy> i use gentoo on my hx4700
Nov 04 19:03:08 <Hire> hx4700?
Nov 04 19:03:21 <alexxy> ipaq hx4700 handheld
Nov 04 19:03:26 <Hire> ahh
Nov 04 19:03:28 <Hire> I see
Nov 04 19:03:57 <Hire> think
Nov 04 19:04:05 <Hire> you can use shr on it if you want :)
Nov 04 19:04:10 <Hire> or fso
Nov 04 19:05:30 <alexxy> i'll try it =)
Nov 04 19:18:53 <Hire> Ainulindale: into the pack I put only icons 48x48?
Nov 04 19:19:31 <Hire> because SHR uses only that
Nov 04 19:19:36 <Hire> those
Nov 04 19:21:30 <Hire> i need to create a index.theme?
Nov 04 19:24:12 <alexxy> Hire: i flash shr snapshot dated 02.11 
Nov 04 19:24:21 <alexxy> all apps fails
Nov 04 19:25:15 <alexxy> it dont even try to registre to network
Nov 04 19:25:35 <Hire> do you have a sim into the FR?
Nov 04 19:26:09 <alexxy> yes of course =)
Nov 04 19:26:24 <alexxy> pincode disabled
Nov 04 19:26:35 <Hire> however yes, it is knowed issue 
Nov 04 19:26:59 <Hire> first you need to get registrated to network next you can launch the apps 
Nov 04 19:27:27 <alexxy> how long i should wait for registration
Nov 04 19:27:28 <alexxy> ?
Nov 04 19:27:34 <Hire> i don't know :o
Nov 04 19:27:41 <alexxy> 5 vinutes or more?
Nov 04 19:27:48 <alexxy> *minutes
Nov 04 19:28:37 <alexxy> it dont even try to register
Nov 04 19:29:01 <Hire> i get registrated almost instantly :o 
Nov 04 19:29:17 * Hire pings Ainulindale
Nov 04 19:29:23 <Hire> do you have tested FSO?
Nov 04 19:46:46 <alexxy> Hire: still dont register to network
Nov 04 19:46:48 <alexxy> what should i do?
Nov 04 19:47:38 <Hire> this is weird
Nov 04 19:47:49 <Hire> with fso you can register?
Nov 04 19:48:28 <alexxy> yes
Nov 04 19:49:45 <Hire> ok
Nov 04 19:50:01 <Hire> i think is an issue with the frameworkd and the last recipe
Nov 04 19:50:17 <alexxy> so?
Nov 04 19:50:32 <Hire> when Ainulindale will be back I talk with him about this
Nov 04 19:50:37 <Hire> test an older images :D
Nov 04 19:50:55 <alexxy> 31.10 has the same problem
Nov 04 19:51:21 <Hire> oh
Nov 04 19:51:26 <Hire> interesting :>
Nov 04 19:51:37 <Hire> we need to to bash Ainulindale :>
Nov 04 19:52:21 <alexxy> its real problem =) phone that cannot be used for calls =)
Nov 04 19:52:56 <Hire> i'm sorry
Nov 04 19:53:09 <Hire> we haven't tested it with all sim :D
Nov 04 19:53:29 <Hire> however when I talk with him I am sure that he will fix this issue
Nov 04 19:53:46 <Hire> and for this reason shr isn't released yet :)
Nov 04 19:54:12 <Hire> because we need more tester to find more issues so when it will be release we will have a stable distro usable for FR
Nov 04 19:54:26 <alexxy> ogsmd thinks that sim there is no sim card
Nov 04 19:54:38 <alexxy> or somethink like that
Nov 04 19:55:07 <Hire> you can post a log of dmesg?
Nov 04 19:55:10 <Hire> with pastebin
Nov 04 19:56:53 <alexxy> ok
Nov 04 19:58:17 <alexxy> http://rafb.net/p/GEjb6K84.html
Nov 04 19:58:40 <alexxy> http://rafb.net/p/awfeQa42.html
Nov 04 19:59:05 <alexxy> http://rafb.net/p/VEv9LU44.html
Nov 04 19:59:19 <alexxy> here dmesg messages and messages.0
Nov 04 19:59:24 <Hire> mmm >
Nov 04 20:00:47 <Hire> Nov  4 19:46:12 om-gta02 user.info 2008.11.04 19:46:12 ogsmd    INFO     <CallChannel via unknown>: Creating channel with timeout = 3600 seconds
Nov 04 20:00:48 <Hire> Nov  4 19:46:12 om-gta02 user.info 2008.11.04 19:46:12 ogsmd    INFO     <UnsolicitedResponseChannel via unknown>: Creating channel with timeout = 5 seconds
Nov 04 20:00:48 <Hire> Nov  4 19:46:12 om-gta02 user.info 2008.11.04 19:46:12 ogsmd    INFO     <MiscChannel via unknown>: Creating channel with timeout = 5 seconds
Nov 04 20:01:46 <Hire> ogsmd works
Nov 04 20:01:55 <alexxy> yep
Nov 04 20:02:15 <Hire> but it doesn't talk about network
Nov 04 20:02:18 <Hire> eh
Nov 04 20:02:21 <alexxy> and then it sets status of sim to not ready and dont even try to register
Nov 04 20:03:08 <Hire> ehhh if quickdev or Ainulindale were here them can help you
Nov 04 20:06:42 <alexxy> how can i enable sim manualy?
Nov 04 20:06:48 <alexxy> via mdbus?
Nov 04 20:09:50 <alexxy> btw what mean connect(): service unavalieble lines after INIT 1.86?
Nov 04 20:11:38 <Hire> i don't know :(
Nov 04 20:11:50 <Hire> i am sad :(
Nov 04 20:12:49 <alexxy> hmmm 
Nov 04 20:13:05 <alexxy> if i enable pin code shr asks me to input it
Nov 04 20:15:10 <alexxy> any ideas?
Nov 04 20:16:02 <Hire> sorry but i don't have a pincode into my sim
Nov 04 20:16:16 <Hire> you can try to disabilitate it and try one more time
Nov 04 20:17:11 <mrmoku> alexxy: have you got a phonebook on that sim?
Nov 04 20:17:27 <alexxy> no
Nov 04 20:17:34 <alexxy> no entris
Nov 04 20:17:56 <Hire> hi quickdev
Nov 04 20:18:02 <quickdev> hey Hire 
Nov 04 20:18:05 <alexxy> hi quickdev
Nov 04 20:18:07 <Hire> can you help alexxy with an issue on ogmsd?
Nov 04 20:18:15 <alexxy> i have problesm with shr
Nov 04 20:18:21 <quickdev> tell me ;)
Nov 04 20:18:33 <alexxy> <alexxy> http://rafb.net/p/GEjb6K84.html
Nov 04 20:18:33 <alexxy> <alexxy> http://rafb.net/p/awfeQa42.html
Nov 04 20:18:33 <alexxy> <alexxy> http://rafb.net/p/VEv9LU44.html
Nov 04 20:18:39 <alexxy> logs
Nov 04 20:18:40 <alexxy> =)
Nov 04 20:18:43 <alexxy> dmesg
Nov 04 20:18:47 <alexxy> messages
Nov 04 20:18:51 <alexxy> messages.0
Nov 04 20:19:02 <Hire> alexxy can't get network registred on SHR
Nov 04 20:19:11 <alexxy> actualy shr doesnt even tryes to register to network
Nov 04 20:19:28 <alexxy> i have no contacts on sim and no sms on it
Nov 04 20:19:45 <alexxy> may be this is an issue
Nov 04 20:20:14 <quickdev> alexxy, I assume you have the most recent image available
Nov 04 20:20:22 <alexxy> yes
Nov 04 20:20:27 <alexxy> 02.11
Nov 04 20:20:29 <quickdev> could you paste the /tmp/ophonekitd.log?
Nov 04 20:20:56 <quickdev> and configure frameworkd to be verbose: edit /etc/frameworkd.conf, log_level = DEBUG, log_to = file log_destination = /tmp/frameworkd.log
Nov 04 20:22:21 <alexxy> http://rafb.net/p/FPVwkH79.html
Nov 04 20:24:48 <quickdev> alexxy, now I need the according frameworkd.log
Nov 04 20:25:06 <alexxy> should i restart freerunner?
Nov 04 20:25:14 <alexxy> or only frameworkd?
Nov 04 20:26:00 <quickdev> restart your freerunner..it's the easiest way ;)
Nov 04 20:27:42 <alexxy> btw what means
Nov 04 20:27:59 <alexxy> connect(): No such file or dirrectory 
Nov 04 20:28:07 <quickdev> alexxy, ignore it, that's no problem ;)
Nov 04 20:28:09 <alexxy> after INIT 1.86 
Nov 04 20:29:57 <Hire> quickdev
Nov 04 20:30:03 <Hire> i need to create a index.theme?
Nov 04 20:30:49 <quickdev> Hire, don't know. You should read about it on the internet :)
Nov 04 20:31:08 <Hire> gnome uses it
Nov 04 20:31:14 <Hire> shr does the same?
Nov 04 20:31:47 <alexxy> http://rafb.net/p/f4R1st22.html
Nov 04 20:31:53 <alexxy> ophoned ^^
Nov 04 20:32:01 <Ainulindale> Yay !!
Nov 04 20:32:06 <Ainulindale> My hotel now has free wifi
Nov 04 20:32:41 <quickdev> Ainulindale, congrats :)
Nov 04 20:33:02 <alexxy> http://rafb.net/p/ZfO6Kx12.html
Nov 04 20:33:05 <Ainulindale> alexxy: yes, SHR is currently usable as a day to day distro for telephony
Nov 04 20:33:06 <quickdev> Ainulindale, you could decide between a bed and wifi all night? :)
Nov 04 20:33:07 <alexxy> frameworkd
Nov 04 20:33:22 <alexxy> if it will register to network 
Nov 04 20:33:29 <alexxy> but for me it cannt do it
Nov 04 20:33:35 <alexxy> see logs
Nov 04 20:33:38 <Hire> *sigh*
Nov 04 20:33:40 <quickdev> alexxy, TIMEOUT is it
Nov 04 20:33:42 <quickdev> one momeent
Nov 04 20:33:58 <Hire> Ainulindale i need to create a index.theme? shr uses it?
Nov 04 20:34:48 <Ainulindale> quickdev: gsm enabled to disabling in this long
Nov 04 20:34:55 <quickdev> alexxy, /usr/lib/python2.5/site-packages/framework/subsystems/ogsmd/gsm/const.py - look for SIMAUTH timeout and set it to a higher value and test again please
Nov 04 20:35:38 <Ainulindale> quickdev: line 41, CPIN OK
Nov 04 20:35:55 <Ainulindale> this is weird
Nov 04 20:36:09 <alexxy> yes it wants me to enter a pin
Nov 04 20:36:11 <Ainulindale> +7
Nov 04 20:36:21 <alexxy> btw FSO images can register to network
Nov 04 20:36:23 <Ainulindale> And anyway, line 753
Nov 04 20:36:24 <Ainulindale> SIM PIN OK
Nov 04 20:36:30 <Ainulindale> alexxy: this is the same thing here
Nov 04 20:36:32 <Ainulindale> same frameworkd version
Nov 04 20:36:34 <Ainulindale> no change
Nov 04 20:37:11 <alexxy> should i increase sim timeout?
Nov 04 20:37:32 <Ainulindale> alexxy: first try the following
Nov 04 20:37:38 <Ainulindale> killall -9 ophonekitd
Nov 04 20:37:42 <quickdev> Ainulindale, CPIN SIM PIN only says: I need a pin
Nov 04 20:37:48 <quickdev> SimSendAuthCode.errorFromChannel: ENTER ('AT+CPIN="xxxx"', ('timeout', 7)),{}
Nov 04 20:37:53 <quickdev> and AT+CPIN is sending the pin
Nov 04 20:37:55 <Ainulindale> then /etc/init.d/frameworkd stop
Nov 04 20:38:04 <Ainulindale> then /etc/init.d/gsm0710muxd stop
Nov 04 20:38:07 <Ainulindale> quickdev: I know, misread here
Nov 04 20:38:18 <quickdev> Ainulindale, timeout might help..
Nov 04 20:38:26 <Ainulindale> quickdev: but anyway I'd like to try on cold start
Nov 04 20:38:40 <Ainulindale> alexxy: then, /etc/init.d/gsm0710muxd start
Nov 04 20:38:52 <Ainulindale> then /etc/init.d/frameworkd start
Nov 04 20:38:57 <alexxy> hmm i doesnt have such procces ophonekitd
Nov 04 20:38:58 <quickdev> Ainulindale, he just rebooted
Nov 04 20:39:09 <quickdev> ophonekitd quit because of the frameworkd problem
Nov 04 20:39:14 <Ainulindale> then DISPLAY=":0" ophonekitd&
Nov 04 20:39:26 <Ainulindale> That's not a problem alexxy 
Nov 04 20:39:29 <Ainulindale> Follow the other steps
Nov 04 20:39:35 <Ainulindale> quickdev: it quits ?!
Nov 04 20:39:44 <Ainulindale> Because of the timeout ?
Nov 04 20:40:07 <quickdev> Ainulindale, when frameworkd receives a timeout, ophonekitd quits with "unknown dbus error". have a look at alexys pasts.
Nov 04 20:40:20 <Ainulindale> I didn't go that far, shame on me
Nov 04 20:40:29 <Ainulindale> We really ought to settle these ophonekitd things
Nov 04 20:41:44 <Ainulindale> quickdev: and anyway
Nov 04 20:41:48 <alexxy> it fails in the same manner
Nov 04 20:41:50 <Ainulindale> I'm nearly drunk
Nov 04 20:41:55 <alexxy> so what next?
Nov 04 20:41:57 <Ainulindale> sanofi-aventis pays for the food
Nov 04 20:42:05 <Ainulindale> and the wine too :-)
Nov 04 20:42:29 <quickdev> hrr :)
Nov 04 20:42:55 <Ainulindale> alexxy: did it askk for pin ?
Nov 04 20:43:16 <mrmoku> has anybody tried a sim _without_ phonebook entries yet?
Nov 04 20:43:54 <Ainulindale> Nope
Nov 04 20:44:56 <mrmoku> greping in framework source for PHB... looks like it is expecting a ready phonebook and otherwise disabling the gsm subsystem
Nov 04 20:45:24 <mrmoku> would be line 755 in the log
Nov 04 20:45:51 <Ainulindale> Hmmm
Nov 04 20:45:54 <Ainulindale> Looks plauible
Nov 04 20:46:02 <Ainulindale> mickeyl: ?
Nov 04 20:46:56 <mrmoku> alexxy: have you got a working phone to put something into the SIM's phonebook and retry
Nov 04 20:47:00 <mrmoku> ?
Nov 04 20:49:32 <alexxy> yes
Nov 04 20:49:48 <alexxy> Ainulindale: yes it asks for pin
Nov 04 20:49:59 <alexxy> also same thing if pin disabled
Nov 04 20:50:08 <Ainulindale> alexxy: could you try mrmoku 's idea ?
Nov 04 20:50:15 <alexxy> ok
Nov 04 20:50:48 <alexxy> btw this seem works wit fso and qtopia
Nov 04 20:50:54 <alexxy> *with
Nov 04 20:51:18 <Ainulindale> with the same sim card ?
Nov 04 20:51:30 <Ainulindale> it may be due to a micro difference on our frameworkd version
Nov 04 20:51:41 <alexxy> yes
Nov 04 20:51:45 <Ainulindale> as the buildhost does not generate automatically anymore, we suspend it f or a while
Nov 04 20:51:50 <alexxy> i have only one simcard
Nov 04 20:51:53 <Ainulindale> +ed
Nov 04 20:54:23 <mrmoku> which fso version works? MS3 or some testing?
Nov 04 20:55:01 <Ainulindale> we're using latest, currently
Nov 04 20:55:08 <Ainulindale> We left he version floating until MS4
Nov 04 20:55:11 <Ainulindale> +t
Nov 04 20:55:36 <alexxy> testing
Nov 04 20:55:38 <mrmoku> I ment alexxy :-)
Nov 04 20:56:11 <alexxy> also version of frameworkd + zhone from testing in openmoko.org
Nov 04 20:56:12 <Ainulindale> mrmoku: sorry :-)
Nov 04 20:56:32 <alexxy> but i dont here anything when i try to call
Nov 04 20:56:58 <mrmoku> at least it registers to the network ;)
Nov 04 20:57:45 <Ainulindale> alexxy: then it's not latest
Nov 04 20:57:54 <Ainulindale> the bug you're describing is old
Nov 04 20:58:28 <alexxy> ok
Nov 04 20:58:35 <alexxy> i addd some contacts to sim
Nov 04 20:58:42 <alexxy> so lets try
Nov 04 20:58:47 <mrmoku> Ainulindale: is there some new image in the works? I have to reflash to get rid of a non-working android :)
Nov 04 20:58:51 <alexxy> latest fso-testing images works
Nov 04 20:59:14 <Ainulindale> mrmoku: SHR is working
Nov 04 21:00:17 <Ainulindale> mrmoku: the icon problem can be fixed by update-mime-database /usr/share/mime IIRC
Nov 04 21:00:53 <Ainulindale> THere may be some remanent problem that will be fixed by thursday if I have enough time to work on them
Nov 04 21:01:05 <mrmoku> I know - just wanted to try the stuff everybody is talking about. Going to reflash 2/11 image
Nov 04 21:01:31 <alexxy> Ainulindale: no
Nov 04 21:01:35 <alexxy> i have same error
Nov 04 21:01:46 <Ainulindale> Anyway I'll rebuild an image on 9/11
Nov 04 21:01:46 <mrmoku> :(
Nov 04 21:02:00 <Ainulindale> just for the nice timestamp
Nov 04 21:02:21 <Ainulindale> alexxy: I have no clue about that then, you should ask mickeyl 
Nov 04 21:02:43 <Ainulindale> Sorry for not being of help
Nov 04 21:02:51 <alexxy> i can try to increse timeout
Nov 04 21:03:23 <quickdev> yeah
Nov 04 21:03:39 <alexxy> or try to flash latest fso-testing image
Nov 04 21:03:50 <alexxy> to see if it works
Nov 04 21:06:08 <Hire> ergh
Nov 04 21:07:15 <alexxy> increasing timeout dont help
Nov 04 21:10:24 <alexxy> hmm
Nov 04 21:10:42 <alexxy> restarting xserver make freerunner registered to network
Nov 04 21:10:50 <alexxy> strange
Nov 04 21:13:21 <Ainulindale> alexxy: Not strange
Nov 04 21:13:26 <Ainulindale> ophonekitrd is launched at X start
Nov 04 21:13:30 <Ainulindale> -r
Nov 04 21:13:37 <Ainulindale> Restart = relaunch
Nov 04 21:13:55 <alexxy> so why it want register on first  start?
Nov 04 21:14:07 <Ainulindale> Sorry, didn't catch that
Nov 04 21:14:13 <alexxy> btw is handsfree working?
Nov 04 21:14:45 <Ainulindale> in FSO ? Didn't ever try
Nov 04 21:15:33 <lindi-> alexxy: handfree?
Nov 04 21:19:31 <alexxy> i mean headphone set =) 
Nov 04 21:20:56 <lindi-> alexxy: just set the right alsa settings?
Nov 04 21:21:19 <alexxy> it plays sound on call 
Nov 04 21:21:29 <alexxy> only
Nov 04 21:21:35 <mrmoku> Ainulindale: are you still looking for a ringtone?
Nov 04 21:23:59 <Ainulindale> mrmoku: may be :-)
Nov 04 21:24:02 <alexxy> btw what do you think about parolli?
Nov 04 21:25:10 <mrmoku> Ainulindale: if so you could try http://zamora.homelinux.org/Leafing.sid
Nov 04 21:30:49 <Ainulindale> alexxy: I expressed myself publicly on the thread
Nov 04 21:30:52 <Ainulindale> mrmoku: I'm afraid :-)
Nov 04 21:31:03 <Ainulindale> And I don't think I have anything to read sid here
Nov 04 21:31:09 <Ainulindale> I'll try that tomorrow :-)
Nov 04 21:31:30 <mrmoku> np :-)
Nov 04 21:31:33 <lindi-> mrmoku: is that DFSG-free?
Nov 04 21:32:02 <mrmoku> lindi- It's from the same collection Arkanoid comes from
Nov 04 21:32:10 <lindi-> mrmoku: ok so it's non-free
Nov 04 21:32:34 <mrmoku> lindi-: not free enough for debian I think ;)
Nov 04 21:37:25 <mrmoku> lindi-: the website says it's public domain
Nov 04 21:41:26 <lindi-> mrmoku: would you trust that?
Nov 04 21:47:22 <Hire> paroli
Nov 04 21:49:45 <mrmoku> lindi-: don't know. The archive is from http://www.hvsc.c64.org/
Nov 04 21:50:42 <lindi-> $ lynx -source http://www.hvsc.c64.org/
Nov 04 21:50:43 <lindi->   </BODY>
Nov 04 21:50:43 <lindi-> </HTML>
Nov 04 21:50:48 <lindi-> mrmoku: quite blank page, that
Nov 04 21:52:02 <mrmoku> lindi-: maybe because it has frames?
Nov 04 21:52:46 <lindi-> mrmoku: then i'd see <frame
Nov 04 21:56:03 <mrmoku> lindi-: <noframes><body bgcolor="#FFFFFF" text="#000000"></body></noframes>
Nov 04 21:56:21 <lindi-> they must send different content here
Nov 04 21:57:12 <lindi-> mrmoku: what browser do you use?
Nov 04 21:57:20 <mrmoku> lindi-: this is from firefox source view... with lynx and wget I have the same result as you
Nov 04 21:58:15 <lindi-> hard to send feedback :)
Nov 04 22:05:33 <mrmoku> lindi-: heh, reloading in firefox give's me a blank page also now, strange. No, maybe I would not trust ;)
Nov 04 22:16:55 <mrmoku> lindi-: ok, the site is back again - and there is a list of mirrors. If you want, you can try http://hvsc.c64.org/ which works for me with lynx
Nov 04 22:38:35 * Hire is going to see an ep of the big bang theory
Nov 04 22:43:28 <Ainulindale> Hire: good choice :-)
Nov 04 22:58:45 <Hire> 2x06 of the big bang theory is stupend 
Nov 04 22:58:57 <Ainulindale> stupend ?
Nov 04 22:59:26 <Hire> ops
Nov 04 22:59:29 <Hire> it's italiano
Nov 04 22:59:36 <Hire> i mean fantastic :D
Nov 04 22:59:44 <Hire> italian
Nov 04 22:59:56 <Hire> i love sheldon
Nov 04 23:01:02 <Hire> now I have to see monk and malcom
Nov 04 23:02:02 <Hire> but not today, I am too tired and I want to read the tomb of Lovecraft
Nov 04 23:21:03 <Ainulindale> Hire: you were right
Nov 04 23:21:11 <Ainulindale> it's tremendous
Nov 04 23:27:14 <Hire> naah i don't think so :o
Nov 04 23:27:27 <Hire> however now I am going to read
Nov 04 23:27:34 <Hire> so good night :)
Nov 04 23:27:38 <Hire> bye :D
Nov 04 23:27:43 <Ainulindale> Hire: I was talking about big bang theory
Nov 04 23:27:47 <Ainulindale> It was greaaaat
Nov 04 23:27:52 <Ainulindale> Just watched it
Nov 04 23:28:34 <Hire> yes i love it :D
Nov 04 23:29:04 <Hire> but I watch it only in english
Nov 04 23:29:26 <Ainulindale> same here
Nov 04 23:29:28 <Hire> because in Italian it loses some nice slang
Nov 04 23:29:43 <Ainulindale> You could watch it subtitled
Nov 04 23:29:53 <Ainulindale> Here in France it's pretty quick, but I watch it in english nonetheless
Nov 04 23:29:55 <Hire> yes, with italian subs :)
Nov 04 23:30:13 <Ainulindale> I'm too lazy to download subtitles
Nov 04 23:31:38 <Hire> here we have itasa that release the sub within 3-4 hours after the ep is available
Nov 04 23:31:50 <Ainulindale> Same here
Nov 04 23:32:00 <Ainulindale> Anyway, too lazy
Nov 04 23:32:03 <Hire> and I use eztv with rss :)
Nov 04 23:32:22 <Hire> i am not so lazy as you :D
Nov 04 23:34:13 <Hire> http://www.sheldonshirts.com/
Nov 04 23:34:22 <Hire> if you want some stuff from big bang theory
Nov 04 23:34:34 <Hire> as t shirt
Nov 04 23:37:40 <Hire> now I am going to the bed :)
Nov 04 23:37:46 <Hire> night :)
**** ENDING LOGGING AT Wed Nov 05 02:59:57 2008