| 00:00.18 | dc_ | mallum: just make a dialog that asks them, with only an OK button |
| 00:00.41 | mallum | dc_: yeah, but do you know how much code I have to write to do a dialog box ! |
| 00:00.55 | dc_ | mallum: true... |
| 00:01.01 | pb_ | dc_: sure, make it into gpe-irc if you like. |
| 00:01.41 | dc_ | pb_: maybe I'll just play round, I'll probly end up writing a whole new irc client, and just stealing his irc code. |
| 00:01.49 | pb_ | dc_: righto :-) |
| 00:02.40 | pb_ | hmm, I'm not getting on very well with sylpheed. |
| 00:03.15 | dc_ | :\ |
| 00:03.47 | PaxAnima | has anyone looked at syncing data with evolution? |
| 00:04.34 | pb_ | dneuer was working on data interchange most recently. |
| 00:05.13 | mallum | pb_: okey I will make a minibacklight package or summin, that replaces keylaunch and enables stuff in matchbox |
| 00:05.28 | PaxAnima | pb_: ok.. |
| 00:06.07 | mallum | pb_: or is that a bit evil ? |
| 00:06.07 | pb_ | mallum: it would be best for the package that replaces keylaunch to contain only that functionality. If there is a dockapp or whatever that is not related to keyhandling, that should ideally be packaged separately. |
| 00:06.25 | *** join/#gpe jg (~jg@dialup-63.214.88.178.Dial1.Boston1.Level3.net) |
| 00:08.58 | mallum | pb_: yeah agreed. |
| 00:13.23 | dc_ | pb_: it's probly better in the long run to go about it this way. I always wanted to know how to write and irc client. |
| 00:13.42 | dc_ | pb_: oh, plus we can also save the server lists in an sqlite db. |
| 00:13.43 | dc_ | how cute. |
| 00:13.44 | dc_ | heh |
| 00:13.55 | pb_ | dc_: yeah, that would be neat. |
| 00:14.02 | mallum | pb_: oh, ipkg does do replaces right ? |
| 00:14.06 | pb_ | mallum: yes |
| 00:14.54 | pb_ | mallum: I'm not quite sure that replaces is appropriate in this instance, but in technical terms it will work. |
| 00:15.34 | mallum | pb_: cool, you can set matchbox up at the moment to do keyboard stuff, if you edit /usr/share/matchbox/kbdconfig or do it per user by copying to ~/.mbkbdconfig |
| 00:16.04 | pb_ | ok. |
| 00:16.29 | mallum | pb_: it can change keybinding on the fly, but Im yet to bind it to xsettings / mbcontrol / etc |
| 00:18.14 | dc_ | so, now I've got the plan for my irc client written up.. |
| 00:18.20 | dc_ | lets get cracking :} |
| 00:18.32 | pb_ | dc_: excellent, go to it! |
| 00:35.14 | dc_ | pb_: now.. |
| 00:35.24 | pb_ | dc_: yes. |
| 00:35.26 | dc_ | pb_: do you think it's better to switch tabs the xchat way? |
| 00:35.36 | pb_ | dc_: what d'ya mean? |
| 00:35.59 | dc_ | pb_: where simply the text area is rewriten, and the entry and other widget are the same |
| 00:36.20 | dc_ | pb_: or have a full copy of the widgets on each tab |
| 00:36.49 | pb_ | dc_: ah, I see. yeah, I guess it would be better to only switch the text area. |
| 00:37.04 | dc_ | quite. |
| 00:37.19 | dc_ | in that case we just use buttons instead of a real notebook? |
| 00:37.31 | mallum | pb_: have you tried 0.4pre yet ? |
| 00:37.46 | pb_ | dc_: another option would be to not have tabs at all, just use a seperate native window for each channel and let the user switch them using the wm. that way you would save the real estate for the buttons, but it might lead to a clumsy interface. |
| 00:37.48 | dc_ | or just make a notebook with none of its book filled? |
| 00:38.05 | dc_ | pb_: I think. |
| 00:38.07 | pb_ | dc_: i think olirc does some trick where it creates a gtknotebook and then intercepts the events that would cause it to change pages. |
| 00:38.22 | dc_ | pb_: like I was saying? |
| 00:38.42 | pb_ | dc_: right |
| 00:38.57 | dc_ | so it refills the text area. |
| 00:39.07 | dc_ | I was only wondering if doing that might slow it down |
| 00:39.09 | pb_ | mallum: not yet. |
| 00:39.30 | mallum | pb_: :( |
| 00:39.54 | pb_ | dc_: I think it should be ok. |
| 00:40.07 | *** join/#gpe dc_ipaq (~root@modem-222-42-60-62.vip.uk.com) |
| 00:40.17 | dc_ | hrm |
| 00:40.17 | dc_ | now |
| 00:40.31 | dc_ | pb_: what do you suggest for scaling the text in the buttons? |
| 00:41.00 | pb_ | dc_: don't understand what you mean. |
| 00:41.13 | dc_ | I guess I can get the width of the buttons, and add a ... to the end of the label. |
| 00:41.22 | dc_ | pb_: for when we have lots of tabs.. |
| 00:41.29 | dc_ | pb_: but I'm not using a notebook. |
| 00:41.41 | dc_ | pb_: rather a row of toggle buttons, like xchat |
| 00:42.10 | pb_ | dc_: oh right. |
| 00:42.31 | pb_ | dc_: yeah, I guess you need to calculate the available width, divide it by the number of channels to get a width for each button, and then truncate the string to fit. |
| 00:42.45 | pb_ | dc_: Pango can tell you what bounding box would be required for a particular piece of text. |
| 00:43.06 | dc_ | pb_: bounding box? |
| 00:43.17 | pb_ | dc_: width and height |
| 00:43.29 | dc_ | pb_: ah cool. |
| 00:43.49 | dc_ | pb_: well I'll come to all this much later though |
| 00:43.55 | pb_ | dc_: right. |
| 00:47.02 | pb_ | mallum: ah, it occurs to me that if your new keyhandling thing replaces keylaunch it will break suspending at the login screen. So it might be best to not conflict with or replace keylaunch, and just tell users to edit their startup scripts in the appropriate way. |
| 00:47.45 | mallum | pb_: surely the login screen should handle that itself ? |
| 00:48.07 | pb_ | mallum: well, not really, that's what we have keylaunch for. |
| 00:48.39 | mallum | pb_: does that mean I can launch apps via keylaunch from the login screen ? |
| 00:48.47 | pb_ | mallum: sure, if you configure it that way. |
| 00:48.55 | pb_ | mallum: that is how xcalibrate is launched for example. |
| 00:50.03 | mallum | pb_: oh well looks like it more trouble than its worth to enable the advanced keyboard features of matchbox for gpe |
| 00:50.37 | pb_ | mallum: does seem that way. |
| 00:50.51 | mallum | pb_: *sigh* |
| 00:53.36 | mallum | pb_: I suppose one can hope someone adds xsettings support / startupnotify support / solid single instance handling / decent config file support / removes ugly hacks etc from keylaunch ... |
| 00:53.58 | pb_ | mallum: one can hope. |
| 00:55.31 | mallum | pb_: im sure it would just be a couple of lines of code to remove gpe-login relying on keylaunch ... |
| 00:56.16 | pb_ | mallum: it's a whole new config file, with associated parser, plus the actual code to detect key events and spawn children. |
| 00:57.13 | mallum | pb_: why does it need a new config file ? sure its only a couple of settings ? |
| 00:58.00 | pb_ | mallum: gpe-login's current "config file" is just a way of providing a set of default command line options to enable stuff like hard-keys mode. |
| 00:58.43 | pb_ | mallum: its syntax is extremely primitive, I don't think it would be sufficient for arbitrary keypress/command bindings. |
| 00:58.43 | dc_ | pb_: do we actualy know which source file the irc protcol code is in? |
| 00:59.34 | dc_ | n/m |
| 01:00.19 | mallum | pb_: well sure it only has to bind 2 keys, 1 for the calibration and 1 for the power |
| 01:01.28 | dc_ | oh damn! |
| 01:01.43 | dc_ | rotated my stylus pen the wrong way! |
| 01:01.47 | mallum | pb_: how does gpe-login currently change / set keylaunches behaviour ? |
| 01:01.53 | pb_ | dc_: hell! |
| 01:02.01 | dc_ | thank god.. |
| 01:02.06 | dc_ | it's comming off |
| 01:02.19 | pb_ | mallum: yeah, but also plus backlight toggling again. and users might wish to set other keys, e.g. to shut down X and start Opie. |
| 01:02.57 | pb_ | mallum: it doesn't. keylaunch is just invoked with a different config file. |
| 01:03.22 | pb_ | mallum: there is no support for changing keybindings while gpe-login is running at present. |
| 01:05.06 | mallum | pb_: hmmm, I see but even getting gpe-login to pass its current gpe-login.keylaunchrc itself is going to be pretty trivial |
| 01:05.49 | pb_ | mallum: right, but if I do that, we will effectively have duplicated the entire functionality of keylaunch within gpe-login. That doesn't really seem to buy much. |
| 01:06.09 | mallum | pb_: doesn't gtk have most of that already ? |
| 01:06.29 | pb_ | mallum: dunno. |
| 01:07.18 | mallum | pb_: well gpe-login should really grab the entire keyboard anyway |
| 01:07.32 | pb_ | why? |
| 01:07.58 | mallum | pb_: with the screen locked, I could have an app running in the background that is bound to a key |
| 01:08.22 | pb_ | mallum: screen locking is a different issue. I think it does already grab the keyboard in that situation, and keylaunch is disabled. |
| 01:09.09 | mallum | pb_: try locking the screen with the new matchbox and hitting alt-d on the login keyboard for example .. |
| 01:10.42 | mallum | pb_: no forget that .. ;-) |
| 01:11.14 | *** join/#gpe ljp (~wind@tf0226.peakpeak.com) |
| 01:12.54 | mallum | pb_: hmm I see it does grab the keyboard on a lock ( but not on a login ? ) |
| 01:13.00 | pb_ | mallum: yes. |
| 01:13.27 | mallum | pb_: ah yes I cant send it to sleep when the screen is locked |
| 01:14.14 | pb_ | indeed. |
| 01:14.33 | mallum | pb_: so maybe it should handle keys itself ... ;-) |
| 01:15.37 | mallum | pb_: I can reluctantly add timed held keypresses to matchbox's key stuff if that will make you happier |
| 01:18.05 | mallum | pb_: it seems a shame to not take advantage of extra functionality and help with the problem of the user luanching multiple instances of the same app from the keys ... |
| 01:18.40 | dc_ | hrm |
| 01:19.14 | dc_ | imho gpe-login should really overwrite any user set key bindings |
| 01:21.18 | pb_ | dc_: it does. |
| 01:23.07 | dc_ | :) |
| 01:25.21 | mallum | pb_: ? |
| 01:29.23 | pb_ | mallum: I'm still not very keen on putting this stuff back into gpe-login. |
| 01:30.42 | pb_ | mallum: however, keylaunch is small enough that we could retain it for that purpose alone without seriously upsetting users who wanted to let matchbox handle keybindings during their session. |
| 01:31.10 | mallum | pb_: yes indeed |
| 01:31.24 | mallum | pb_: I dont mind patching the need functionality in gpe-login |
| 01:31.38 | dc_ | an if(!foo) will yeid correct if foo = -1? |
| 01:31.40 | pb_ | mallum: so, my suggestion remains that you should not take any special measures to force keylaunch off the system, and just let it coexist peacefully with matchbox. |
| 01:31.56 | pb_ | dc_: no, if (!foo) will only be true when foo == 0. |
| 01:32.12 | dc_ | oh well. |
| 01:32.14 | dc_ | pb_; :/ |
| 01:33.32 | mallum | pb_: sure ... |
| 01:33.33 | dc_ | then, should I return -1 or 0 from a function that fails? |
| 01:33.41 | pb_ | dc_: your choice. |
| 01:33.45 | dc_ | :] |
| 01:33.47 | dc_ | 0 it is then |
| 01:34.57 | mallum | pb_: Im just not sure they can !! :-( |
| 01:35.10 | pb_ | mallum: what do you mean? |
| 01:35.32 | mallum | pb_: well becuase there both potentially gonna be trying to gran the same keys |
| 01:35.48 | mallum | pb_: unless gpe-login stops it on a succsessful login |
| 01:35.59 | pb_ | mallum: yeah, users who want matchbox to handle keys will have to either not run keylaunch, or configure it to not grab those keys. |
| 01:36.30 | mallum | pb_: yeah but thats the problem, keylaunch is not easy to configure AFAIK |
| 01:36.57 | pb_ | mallum: it's just a case of deleting or commenting out lines in /etc/keylaunchrc (or copying it to ~/.keylaunchrc and editing it there). Shouldn't be too big a deal. |
| 01:37.43 | mallum | pb_: is there a gui front end for it ? |
| 01:38.27 | pb_ | mallum: preventing it from running altogether for particular users is a bit more of a hassle with our current scripts. You can delete it from Xsession.d, but that stops it for all users. The only other option is to use ~/.xsession to replace the whole of Xsession. |
| 01:38.41 | pb_ | mallum: no idea, moray would be the man to ask about that. |
| 01:38.45 | mallum | pb_: yeah thats what I mean |
| 01:39.34 | dc_ | hrm |
| 01:39.41 | pb_ | mallum: that problem isn't specific to keylaunch, we just need to find some appropriate mechanism to deal with it. |
| 01:39.55 | mallum | pb_: whats upsetting me most is it seems that progress is being blocked here |
| 01:39.59 | dc_ | is it safe to use one varible for both storing a socket, and possibly to report an error? |
| 01:40.12 | pb_ | mallum: probably by using ~/.Xsession.d as a replacement for Xsession.d if it exists. |
| 01:40.35 | pb_ | dc_: depends on the context. |
| 01:40.39 | pb_ | mallum: why is progress being blocked? |
| 01:40.42 | mallum | pb_: theres not much point in me trying to improve things in the future, if 'legacy' apps are gonna get in the way |
| 01:40.50 | dc_ | pb_: well, will a socket ever be -1? |
| 01:40.56 | pb_ | dc_: no, sockets are always >= 0 |
| 01:40.57 | dc_ | pb_: or rather 0 |
| 01:41.05 | dc_ | ah good'o then! |
| 01:41.15 | pb_ | dc_: yes, 0 is theoretically a valid socket. |
| 01:41.26 | pb_ | dc_: it is unlikely to occur in practice, but you probably ought to allow for it just in case. |
| 01:41.31 | dc_ | bah |
| 01:41.32 | dc_ | okay.. |
| 01:41.34 | mallum | pb_: becuase as far as Im concerned I've greatly improved key handling in many aspects yet it cant be widely and easily implemented becuse of the old lesser solution |
| 01:42.55 | mallum | pb_: maybe I've got it wrong, but I've said I'll add timeouts, and patch gpe-login to do its own key handling - but you still dont seem happy :-( |
| 01:43.08 | mallum | timed keypresses that is |
| 01:43.14 | pb_ | mallum: I don't think the issue of disabling keylaunch on a per user basis is likely to be much of a blocker in reality. Scarcely any ipaqs are genuinely multi-user in that sense. |
| 01:45.18 | mallum | pb_: it seems silly that the user will have to jump through a load of difficult hoops to get better keyboard functionality |
| 01:45.51 | pb_ | mallum: if you were proposing a drop-in replacement for keylaunch that was just "better" (ie supported your new single-instance stuff, startup notifcation and what have you) then I don't think there would be any dispute. The reason I am a bit uneasy at the moment is that we are talking about doing away with an existing daemon that serves a particular purpose and duplicating its functionality in two different places. |
| 01:46.05 | pb_ | mallum: I guess I just don't really understand why it is better for the window manager to handle keypresses itself. |
| 01:46.51 | mallum | pb_: I understand |
| 01:46.54 | pb_ | i.e. what is possible with matchbox handling keys that couldn't be done with a separate daemon? |
| 01:47.43 | mallum | pb_: I think it makes sense to me to handle it in matchbox as it saves code as matchbox already does key handling anyway - for navigating windows ( and use startup notifiction etc ) |
| 01:48.46 | mallum | pb_: I could cut and paste the stuff out of matchbox, but that would duplicate much code |
| 01:50.08 | pb_ | mallum: don't programs like mbdock and monolaunch also want the startup notification? I would have expected that to be in some kind of shared library. |
| 01:50.26 | mallum | pb_: yes libsn |
| 01:50.48 | mallum | pb_: on mbmenu and mbdesktop currently do it too |
| 01:51.20 | *** join/#gpe dctanner_ (~dctanner@modem-109-53-60-62.vip.uk.com) |
| 01:51.27 | mallum | pb_: its more the case of code to read a config file / code to set up keyboard mappings / event loop etc |
| 01:51.42 | mallum | pb_: matchbox already does althat to handle window navigating from the keybaord |
| 01:52.11 | mallum | pb_: all thats added is basically a fork_exec call and some startup notification magic |
| 01:52.43 | pb_ | mallum: I see. |
| 01:52.52 | mallum | pb_: it also easier for me to maintain |
| 01:53.26 | mallum | pb_: I have to go to bed |
| 01:53.45 | pb_ | mallum: ok. |
| 01:53.46 | mallum | pb_: Have a think about it, I see where your coming from |
| 01:54.00 | pb_ | mallum: I will sleep on it :-) |
| 01:54.15 | mallum | pb_: okey cool ;-) |
| 01:54.34 | mallum | pb_: I will see you in person on monday and beat you into submission anyway ;-) |
| 01:54.43 | pb_ | mallum: ah yes |
| 01:54.50 | mallum | pb_: g'night + sleep well |
| 01:54.52 | pb_ | mallum: night. |
| 01:55.24 | dctanner_ | heh |
| 01:55.35 | pb_ | indeed. |
| 01:55.44 | dctanner_ | honest. |
| 01:55.54 | pb_ | dctanner_: ah, be sure to support ipv6 in your new client. |
| 01:56.12 | pb_ | dctanner_: I was about to try to add that to olirc. :-} |
| 01:56.30 | dctanner_ | oh sure, no problems, I'll just whip it up! |
| 01:56.33 | pb_ | hehe |
| 01:56.44 | dctanner_ | pb_: hehe, well...you can sure have a shot once I get this gpe-irc under control |
| 01:57.19 | pb_ | dctanner_: ipv6 is actually very easy, the only important thing is to do name lookups with getnameinfo() not gethostbyname(). |
| 02:07.16 | pb_ | dctanner_: right, building new gconv packages now |
| 02:07.28 | pb_ | dctanner_: there are 189 of them so it may take a few minutes |
| 02:07.41 | dctanner_ | hehe |
| 02:08.43 | dc__ | pb_: maybe you could help me here by giving me a briefing on the outline of how this socketing works? |
| 02:08.49 | dc__ | pb_: I'm kind of a bit lost. |
| 02:09.04 | pb_ | dc__: sure, I will do what I can |
| 02:09.09 | pb_ | dc__: which bit are you lost with? |
| 02:09.11 | dc__ | pb_: right now, I see that you first have to resolve the ip of the domain |
| 02:09.24 | dc__ | pb_: then make a socket, and conenct to it. |
| 02:09.37 | dc__ | pb_: then somehow listen for things coming from it? |
| 02:09.42 | dc__ | pb_: with a callback? |
| 02:09.57 | pb_ | not quite. it sounds like you might be getting confused with server code there. |
| 02:10.08 | dc__ | yah |
| 02:10.13 | dc__ | very confused. |
| 02:10.20 | pb_ | I guess irc clients do need to incorporate some kind of server stuff for dcc, but that is probably too advanced for yours right now. |
| 02:10.37 | dc__ | right :] |
| 02:11.39 | pb_ | what you need to do is call getaddrinfo(), giving it the hostname and the "service" (which is the port number you want to connect to). It will hand you back a list of address structures. You take one of these, create a socket using the parameters it says, and then call connect() to actually make a TCP connection. |
| 02:12.00 | pb_ | once the connection is made, you use read, write and select on the socket just like any other file descriptor. |
| 02:12.22 | dc__ | oh okay. |
| 02:12.26 | dc__ | fair enough |
| 02:12.30 | dc__ | pb_: when do I know when to read? |
| 02:12.32 | pb_ | if connect fails, you move to the next address in the list and try that one, and so on until either you find one that works, or you come to the end of the list and have to give up. |
| 02:12.47 | pb_ | dc__: use select to find out when data is waiting |
| 02:13.08 | pb_ | dc__: or create a separate thread and do blocking reads. |
| 02:13.32 | dc__ | okay. |
| 02:14.47 | pb_ | if you need to do name lookups without blocking, there is a special asynchronous name service library you can use. |
| 02:15.55 | dc__ | hum |
| 02:16.03 | dc__ | I think I may be able to live without for now |
| 02:16.10 | pb_ | ok. |
| 02:21.38 | dc__ | pb_: how does it store a list in an int? |
| 02:21.54 | pb_ | dc__: getaddrinfo? |
| 02:21.58 | dc__ | yeah |
| 02:22.05 | pb_ | dc__: it doesn't. |
| 02:22.20 | dc__ | oh |
| 02:22.23 | dc__ | connect does? |
| 02:22.52 | pb_ | connect takes a pointer to a struct sockaddr. |
| 02:23.08 | dc__ | so.. |
| 02:23.19 | dc__ | what makes our list of addrs? |
| 02:23.59 | pb_ | getaddrinfo does that. You pass it a pointer to a struct addrinfo *, and it puts the address of this list there. |
| 02:24.06 | pb_ | let me see if I can find some example code. |
| 02:24.28 | dc__ | please :) |
| 02:26.19 | pb_ | hmm, I guess netkit-telnet is as good as anything. |
| 02:26.25 | pb_ | apt-get source telnet |
| 02:26.37 | pb_ | look at telnet/commands.cc, function tn() |
| 02:26.55 | dc__ | right |
| 02:29.43 | pb_ | btw, gconv modules are uploaded now |
| 02:30.17 | pb_ | I haven't actually tested the packaging but I think this ought to fix the bug. |
| 03:08.35 | dc__ | hrm |
| 03:15.49 | pb_ | there's also now a new glib and gtk in unstable. |
| 03:15.56 | dc__ | I see :) |
| 03:16.10 | pb_ | though the packages file has picked up the update partway through, so I recommend not actually upgrading for another ten minutes or so :-} |
| 03:16.43 | pb_ | dc__: how are you getting on with the sockets? |
| 03:16.58 | dc__ | :/ |
| 03:17.06 | dc__ | I'll get there I guess. |
| 03:17.07 | dc__ | hrm |
| 03:17.16 | dc__ | good old'e Unable to load icon |
| 03:17.16 | dc__ | "cancel"Aborted |
| 03:17.30 | pb_ | did you just upgrade? |
| 03:17.37 | dc__ | yeah... |
| 03:17.38 | dc__ | well |
| 03:17.49 | pb_ | you probably got the new pixbuf loaders, but not the new gtk itself. |
| 03:17.49 | dc__ | let me upgrade again |
| 03:17.55 | dc__ | ah |
| 03:17.56 | dc__ | :} |
| 03:18.01 | pb_ | ipkg install http://handhelds.org/familiar/feeds/unstable/packages/armv4l/libgtk2.0-0_2.1.5-1_arm.ipk |
| 03:18.05 | pb_ | should fix it |
| 03:18.12 | dc__ | right |
| 03:18.58 | pb_ | possibly I should version the packages so that doesn't happen, but there is only a 15-minute window when the problem can arise so it doesn't seem all that important. |
| 03:20.00 | dc__ | quite |
| 03:25.02 | pb_ | right |
| 03:25.44 | pb_ | g'night |
| 04:12.28 | *** join/#gpe jg (~jg@dialup-63.214.88.178.Dial1.Boston1.Level3.net) |
| 05:21.45 | *** join/#gpe jg (~jg@dialup-63.214.88.178.Dial1.Boston1.Level3.net) |
| 12:19.12 | *** join/#gpe florian (~boor@p5092939D.dip.t-dialin.net) |
| 12:19.41 | florian | hi all! |
| 12:39.10 | *** join/#gpe wizly (~wizly@217-126-81-209.uc.nombres.ttd.es) |
| 12:39.22 | wizly | hi |
| 12:48.24 | *** join/#gpe florian (~fuchs@p5092939D.dip.t-dialin.net) |
| 13:21.02 | *** join/#gpe HET2 (~diman@chello080110105196.509.15.vie.surfer.at) |
| 13:25.43 | *** join/#gpe pb_ (~pb@pc2-cmbg4-3-cust239.cmbg.cable.ntl.com) |
| 14:25.53 | *** join/#gpe netog (~ernesto@50-121-170.adsl.cust.tie.cl) |
| 14:35.05 | *** join/#gpe dc__ (~dctanner@62.60.119.184) |
| 14:35.20 | pb_ | dc__: afternoon |
| 14:35.24 | dc__ | afternoon :) |
| 14:35.36 | wizly | hi |
| 14:35.40 | dc__ | pb_: I had a look though all my C books, and not one had any sockets stuff :/ |
| 14:35.42 | pb_ | hi wizly |
| 14:35.54 | dc__ | hey wizly |
| 14:36.05 | pb_ | dc__: sockets are a Unix thing. There is a book by Stevens that is kind of the canonical reference for that stuff. |
| 14:37.22 | pb_ | dc__: http://www.amazon.co.uk/exec/obidos/ASIN/013490012X/ref=sr_aps_books_1_1/026-6523779-8206858 |
| 14:38.05 | dc__ | ahh :) |
| 14:39.01 | pb_ | dc__: you might try the glibc manual in case of last resort, I think it has some explanation of the network functions. |
| 14:39.07 | dc__ | oh damn... |
| 14:39.17 | dc__ | my new libc broke wine.. |
| 14:39.18 | dc__ | ? |
| 14:39.20 | wizly | dc__: what do you need about sockets?, normal use is really easy |
| 14:39.35 | dc__ | wizly: I'm in the mists of writing an irc client :/ |
| 14:40.02 | wizly | dc__: from scratch? or porting existing one? |
| 14:40.33 | dc__ | wizly: I'm hoping from scratch, but using olirc as an example |
| 14:41.05 | dc__ | ah. |
| 14:41.12 | dc__ | I found good looking faq for sockets. |
| 14:41.18 | pb_ | ah cool |
| 14:41.21 | wizly | cool |
| 14:45.23 | *** part/#gpe netog (~ernesto@50-121-170.adsl.cust.tie.cl) |
| 14:45.31 | dc__ | pb_: if I think a libc upgrade has broken my wine, can I just make clean ; make to rebuild it? |
| 14:45.45 | pb_ | dc__: worth a try. what kind of breakage are you seeing? |
| 14:46.09 | dc__ | wine: relocation error: /usr/local/lib/libntdll.so: symbol __libc_fork, version GLIBC_2.1.2 not defined in file libc.so.6 with link time reference |
| 14:50.08 | *** join/#gpe flypiper (~pipercub@12-222-141-210.client.insightBB.com) |
| 14:51.32 | *** join/#gpe __moray_ (moray@dsl-217-155-67-241.zen.co.uk) |
| 14:51.33 | *** join/#gpe pb__ (~pb@pc2-cmbg4-3-cust239.cmbg.cable.ntl.com) |
| 14:51.52 | *** join/#gpe Aviator (dsm29@student.cusu.cam.ac.uk) |
| 14:52.23 | pb__ | hmph. |
| 14:53.06 | dc__ | heh |
| 14:53.19 | dc__ | well, atleast this faq is helping clear things up a bit :] |
| 14:53.25 | pb__ | ah good |
| 14:56.26 | dc__ | oh great, I found a full tutorial, even better. |
| 14:56.32 | pb__ | :-) |
| 15:04.27 | flypiper | <PROTECTED> |
| 15:04.41 | pb__ | flypiper: why, what happened? |
| 15:05.01 | flypiper | bunch of busted libs.. have X running but no login...ect |
| 15:05.32 | flypiper | something in libgtk2 but I can't put my finger on it |
| 15:05.39 | pb__ | oh dear. |
| 15:05.49 | pb__ | could be the old ipkg postinst bug again. |
| 15:06.13 | flypiper | well I might play with it a while...then to see if I can find it |
| 15:08.50 | wizly | Package gpe-todo2 wants to install file /usr/bin/gpe-todo |
| 15:08.50 | wizly | <PROTECTED> |
| 15:08.53 | wizly | damm error.. |
| 15:09.05 | pb__ | wizly: just delete the offending file |
| 15:09.18 | pb__ | wizly: seems that your ipkg status database is corrupt, assuming you didn't install the gpe-todo binary by hand. |
| 15:09.31 | wizly | pb__: this happends with all packets to upgrade.. |
| 15:09.32 | wizly | ? |
| 15:09.41 | pb__ | wizly: I guess something must have wiped out your status file. |
| 15:09.54 | pb__ | wizly: did you run out of flash space during an upgrade or anything like that? |
| 15:09.55 | wizly | any fix? |
| 15:10.09 | pb__ | wizly: well, you can use -force-overwrite |
| 15:10.18 | wizly | pb__: may be. my flash is about 95% full |
| 15:10.49 | pb__ | wizly: yeah, the error handling in ipkg is not the best. |
| 15:11.12 | wizly | pb__: I think familiar+gpe is noq too big to 16Mb ipaq |
| 15:11.13 | wizly | :( |
| 15:11.26 | wizly | I need a mem upgrade |
| 15:11.30 | pb__ | wizly: oh dear |
| 15:11.46 | pb__ | wizly: do you mean too big in RAM, or in flash? |
| 15:12.33 | wizly | pb__: both, my /dev/mtdblock/1 15.8M 15.7M 84.0k 99% / |
| 15:12.47 | pb__ | :-/ |
| 15:12.54 | wizly | and my free mem is about 500 k with gpe running |
| 15:13.38 | wizly | i think I'l try to reflash my ipaq |
| 15:15.51 | *** join/#gpe pb_ (~pb@pc2-cmbg4-3-cust239.cmbg.cable.ntl.com) |
| 15:15.55 | pb_ | darn irssi |
| 15:39.49 | wizly | bye |
| 16:35.04 | pb_ | stargirl_: can we get a build of gpe-dasher for GTK 2? |
| 16:52.26 | flypiper | pb_: reflash complete, ipkg updated to unstable and trying to install gpe2 ... I get gtk-locale* error.. do I need a certian package for that? |
| 16:52.59 | pb_ | flypiper: you need a newer version of ipkg. |
| 16:53.10 | flypiper | ahhh |
| 16:53.11 | pb_ | flypiper: ipkg install ipkg and try again |
| 16:53.36 | flypiper | Upgrading ipkg from 0.99.34 to 0.99.42 |
| 16:53.44 | pb_ | ok, that looks better. |
| 16:54.05 | pb_ | "gtk-locale*" is a special syntax that means "the gtk-locale packages for all the selected languages". |
| 16:54.19 | pb_ | it was only added to ipkg relatively recently. |
| 16:54.27 | flypiper | ahhh.. looks like it's installing now.. thanks:) |
| 16:56.19 | *** join/#gpe dc__ (~dctanner@modem-233-42-60-62.vip.uk.com) |
| 16:56.24 | dc__ | right... |
| 16:56.29 | dc__ | back to my tutorials then |
| 16:56.29 | pb_ | dc__: right. |
| 17:01.40 | dc__ | hum |
| 17:02.00 | dc__ | so the address list is in hostent->h_addr_list? |
| 17:02.16 | dc__ | where hostent in a struct hostent |
| 17:02.39 | pb_ | ah, you're using gethostbyname? |
| 17:02.54 | dc__ | quite |
| 17:03.01 | dc__ | is that alright? |
| 17:03.10 | pb_ | well, it sucks a bit. getaddrinfo is better :-) |
| 17:03.43 | dc__ | okay |
| 17:03.50 | pb_ | but yes, if you want to use gethostbyname, I think hostent->h_addr_list is indeed the address list. |
| 17:04.34 | dc__ | pb_: hum, with getaddrinfo, is the first arg a hostname> |
| 17:04.35 | dc__ | ? |
| 17:04.47 | pb_ | yes. |
| 17:04.53 | dc__ | okay |
| 17:05.03 | pb_ | first arg is hostname, second arg is service name. |
| 17:05.16 | dc__ | okay. |
| 17:05.46 | pb_ | you can probably just pass NULL for the hints. |
| 17:06.12 | dc__ | as I thought |
| 17:12.45 | dc__ | pb_: ahh, so I get a struct of addrinfo, with a link to the next addrinfo in the form addrinfo->ai_next |
| 17:13.09 | pb_ | dc__: right |
| 17:13.15 | dc__ | cooool |
| 17:13.16 | dc__ | hum |
| 17:13.23 | dc__ | where do I find info on the sockaddr struct? |
| 17:13.37 | pb_ | dc__: you can just treat the sockaddr struct as opaque, I think |
| 17:13.49 | pb_ | dc__: but it's defined in sys/socket.h, and probably described in man socket. |
| 17:13.54 | pb_ | or the libc manual |
| 17:13.57 | dc__ | right |
| 17:16.05 | dc__ | pb_: and will addrinfo be set to 0 when there are no more in the list? |
| 17:16.21 | pb_ | dc__: yeah |
| 17:16.30 | dc__ | coool |
| 17:17.12 | pb_ | dc__: so for each one, you basically do fd = socket (addrinfo->ai_family, addrinfo->ai_socktype, addrinfo->ai_protocol) |
| 17:17.24 | pb_ | and then connect (fd, addrinfo->ai_addr, addrinfo->ai_addrlen) |
| 17:17.51 | dc__ | great |
| 17:22.33 | dc__ | ack |
| 17:22.41 | dc__ | pointers have me confused again :{ |
| 17:22.44 | pb_ | oh dear |
| 17:22.46 | pb_ | what's wrong? |
| 17:22.46 | dc__ | pb_: I have a struct.... |
| 17:22.53 | dc__ | pb_: struct addrinfo *address |
| 17:23.04 | dc__ | pb_: then do getaddrinfo (hostname, SERVICE, NULL, &address) |
| 17:23.10 | dc__ | pb_: I have hostname etc... |
| 17:23.19 | dc__ | pb_: is that correct? |
| 17:23.24 | pb_ | yup, looks ok to me. |
| 17:23.46 | dc__ | pb_: then, it complains when I try address = address->ai_next; |
| 17:23.57 | pb_ | what does it say? |
| 17:23.58 | dc__ | dereferencing pointer to incomplete type |
| 17:24.16 | pb_ | ah, that may mean you haven't included all the right header files. |
| 17:24.26 | pb_ | do you have <sys/socket.h> and <netdb.h>? |
| 17:24.27 | dc__ | bah |
| 17:24.34 | dc__ | net db.. |
| 17:24.58 | dc__ | oh yay.. |
| 17:25.02 | dc__ | no complains... |
| 17:25.04 | dc__ | but no addresses. |
| 17:25.17 | pb_ | ah. |
| 17:25.27 | dc__ | <PROTECTED> |
| 17:25.27 | pb_ | are you checking the return value from getaddrinfo? maybe there is some error. |
| 17:25.32 | dc__ | I am.. |
| 17:25.39 | florian | did anyone try to boot an ipaq from acf |
| 17:25.49 | dc__ | if it's not 0 I'm printing an error |
| 17:25.50 | florian | oopss... cf |
| 17:25.58 | pb_ | dc__: yeah, that should be an address. |
| 17:26.23 | dc__ | <PROTECTED> |
| 17:26.23 | dc__ | <PROTECTED> |
| 17:26.23 | dc__ | <PROTECTED> |
| 17:26.23 | dc__ | <PROTECTED> |
| 17:26.23 | dc__ | <PROTECTED> |
| 17:26.28 | dc__ | <PROTECTED> |
| 17:26.30 | dc__ | <PROTECTED> |
| 17:26.32 | dc__ | <PROTECTED> |
| 17:26.34 | dc__ | <PROTECTED> |
| 17:26.36 | dc__ | <PROTECTED> |
| 17:27.03 | pb_ | dc__: does it print anything at all? |
| 17:27.17 | dc__ | pb_: yes, just gekk had address |
| 17:27.20 | dc__ | no addresses |
| 17:27.35 | pb_ | oh, sa_data is not a string |
| 17:27.39 | pb_ | you can't print it with %s |
| 17:27.40 | dc__ | bah |
| 17:27.50 | pb_ | it will be in binary. |
| 17:28.16 | dc__ | what fun |
| 17:28.19 | dc__ | can I convert it/ |
| 17:28.24 | pb_ | if you want to convert it to a string, use inet_ntop |
| 17:28.31 | dc__ | okay |
| 17:28.51 | pb_ | florian: yeah, cmarqu runs his ipaq like that |
| 17:29.03 | pb_ | florian: ask ibot about dual boot. |
| 17:29.44 | florian | pb_: ok, i'll try... |
| 17:29.58 | florian | ibot: dual |
| 17:29.59 | | florian: wish i knew |
| 17:30.09 | florian | ibot: dual boot |
| 17:30.10 | | methinks dual boot is two operating systems on one computer, each contained on their own partition. or http://www.handhelds.org/z/wiki/BootingLinuxFromCF or <reply> http://ipaq.secret.org.uk/ipaq-dualboot/ or at http://linux.blacknet.de/ipaq/ |
| 17:30.12 | dc__ | pb_: I don't need to work out the ip address at all do I: |
| 17:30.20 | dc__ | pb_: before I try and connect or whatever. |
| 17:30.25 | pb_ | dc__: nope |
| 17:30.29 | pb_ | dc__: just pass it straight to connect() |
| 17:30.29 | dc__ | pb_: getaddrinfo handles it all? |
| 17:30.35 | pb_ | yes. |
| 17:30.38 | dc__ | pb_: and what if I give it an ip |
| 17:30.49 | pb_ | it should cope with that too |
| 17:30.56 | dc__ | good'o |
| 17:32.34 | florian | pb_: i thinn he knows all i need ;-) |
| 17:34.01 | flypiper | florian: what size Cf do you have? |
| 17:34.43 | florian | flypiper: 128 MB |
| 17:35.30 | pb_ | florian: cool |
| 17:43.01 | dc__ | pb_: so I should do a socket and connect on eveyr address untill I connect to one? |
| 17:43.15 | pb_ | dc__: yep |
| 17:43.19 | dc__ | coolio |
| 18:05.18 | *** join/#gpe jg (~jg@dialup-63.214.113.118.Dial1.Boston1.Level3.net) |
| 18:05.32 | pb_ | jg: hi |
| 18:05.47 | jg | pb_: hi |
| 18:10.04 | dc__ | pb_: help.. |
| 18:10.12 | dc__ | pb_: try and compile gpe-irc in cvs :} |
| 18:10.12 | pb_ | dc__: at your service |
| 18:10.25 | dc__ | pb_: I have another parse error before '*' :{{ |
| 18:10.35 | pb_ | heh |
| 18:10.39 | dc__ | quite |
| 18:10.39 | pb_ | ok, checking it out now |
| 18:10.43 | dc__ | :) |
| 18:11.12 | dc__ | I dare to think what I've misspelled today |
| 18:11.29 | pb_ | "ICRServer" |
| 18:11.32 | pb_ | :-} |
| 18:11.36 | dc__ | hah |
| 18:11.44 | dc__ | I see. |
| 18:11.49 | dc__ | pb_: hehe, thanks :} |
| 18:12.08 | pb_ | any time :-) |
| 18:13.42 | jg | dc__: speling? what, me spel? |
| 18:13.54 | dc__ | jg: hehe |
| 18:14.30 | dc__ | oh wow! |
| 18:14.41 | dc__ | I connected to irc.handhelds.org! |
| 18:15.59 | jg | dc__: I've got an excuse, I'm on drugs :-(. |
| 18:15.59 | jg | dc__: I don't recommend them.... |
| 18:16.00 | jg | dc__: translate uberleet? |
| 18:16.18 | cmarqu | florian: Will you be at the 19C3? Or nils? |
| 18:16.26 | cmarqu | Hi guys. |
| 18:17.15 | dc__ | jg: really really pround and cool :D |
| 18:17.25 | jg | dc__: in what language? |
| 18:17.36 | dc__ | jg: dc_ |
| 18:17.39 | dc__ | jg: hehe |
| 18:17.51 | jg | jg: ach, so, mein herr.... |
| 18:17.56 | cmarqu | :) |
| 18:17.59 | pb_ | dc__: wow, cool! |
| 18:18.06 | dc__ | jg: soon my leet irc client will own the world :) |
| 18:18.07 | jg | pb_: good stuff. |
| 18:18.20 | pb_ | hi cmarqu |
| 18:18.25 | jg | maybe the IRC world. |
| 18:18.30 | dc__ | yeah |
| 18:18.36 | dc__ | I should really start small I guess. |
| 18:18.37 | jg | But IRC is small potatoes in the IM world. |
| 18:18.57 | dc__ | jg: quite. but wait till you see a dc_ clien. |
| 18:18.58 | dc__ | t |
| 18:19.00 | jg | having a good ipaq ui for GAIM would solve the larger problem. |
| 18:19.02 | dc__ | jg: :} |
| 18:19.07 | jg | dc__: I'm looking forward to it. |
| 18:19.12 | dc__ | jg: there's alredy one, no? |
| 18:19.15 | jg | as soon as i'm off drugs. |
| 18:19.19 | jg | dc__: yes, there is, |
| 18:19.20 | dc__ | jg: quite, before for gpe-irc soon. |
| 18:19.25 | dc__ | s/before/beware |
| 18:19.29 | dc__ | jg: and. |
| 18:19.31 | jg | dunno how good the UI is for a hand held, though. |
| 18:19.44 | dc__ | jg: I fixed it up a while ago. |
| 18:19.47 | dc__ | :] |
| 18:19.52 | jg | sounds good. |
| 18:20.01 | jg | having the larger world of IM is *really* important. |
| 18:20.03 | dc__ | jg: even though I never really tested it, though recently I think Disconnect revised my work. |
| 18:20.26 | dc__ | jg: yes. |
| 18:20.39 | dc__ | jg: maybe oneday we can have gpe-im |
| 18:20.39 | dc__ | :} |
| 18:20.50 | jg | dc__: well, as soon as the drugs subside, I won't have many distractions than playing with an iPAQ. |
| 18:21.07 | jg | the table i ordered for use with my bed also has to arrive. |
| 18:21.11 | florian | cmarqu: i don't think so, but i'm not shure about nils... |
| 18:21.20 | jg | lying on the side isn't feasible for N hours a day. |
| 18:22.24 | cmarqu | florian: How lame! :) I just heard that nils will be in Siegen on the 27th, so I guess he is not there either. |
| 18:24.03 | florian | cmarqu: yes, quite right you are... |
| 18:26.52 | florian | cmarqu: my problem is that i have to be here on 28th, i should mark these days in my calendar next year :-/ |
| 18:27.42 | cmarqu | Indeed. Well, I'm going for the first time. |
| 18:28.36 | florian | what's the next large event after 19C3? |
| 18:28.49 | cmarqu | fosdem? |
| 18:28.58 | cmarqu | In February. |
| 18:29.26 | dc__ | jg: is it your leg..? |
| 18:29.28 | florian | yes, this could be... good |
| 18:35.42 | dc__ | oh. |
| 18:35.45 | dc__ | I want to too :} |
| 18:54.40 | dc__ | pb_: :} |
| 18:55.14 | dc__ | pb_: if I strdup to a struct->struct->gchar do I have to do anything special? |
| 18:55.22 | pb_ | dc__: nope |
| 18:55.32 | dc__ | pb_: hum..have a look at cvs.. |
| 18:55.47 | pb_ | I thought that was coming. :-} |
| 18:56.48 | *** join/#gpe dctanner_ (~dctanner@modem-104-54-60-62.vip.uk.com) |
| 18:56.58 | pb_ | dc__: you have to initialise server and server->user_info to point to some real storage. |
| 18:57.04 | dctanner_ | ack |
| 18:57.06 | dctanner_ | pb_: any ideas? |
| 18:57.12 | dctanner_ | pb_: as in = NULL? |
| 18:57.17 | dctanner_ | pb_: or size of :? |
| 18:57.19 | pb_ | server = g_malloc (sizeof (*server)); |
| 18:57.25 | dctanner_ | right.. |
| 18:57.27 | pb_ | server->user_info = g_malloc (sizeof (*server->user_info)); |
| 18:57.31 | dctanner_ | okay |
| 18:59.11 | dctanner_ | weeee |
| 18:59.19 | dctanner_ | it logged me into handhelds.org now :) |
| 18:59.25 | dctanner_ | getting there, one step at a time |
| 18:59.28 | pb_ | heh |
| 18:59.30 | pb_ | cool |
| 19:03.38 | *** join/#gpe ljp2 (~wind@tf0226.peakpeak.com) |
| 19:12.18 | jg | dc__: Yes, I did in my leg: dislocated it badly, and broke the fibia and tibia. |
| 19:28.48 | *** part/#gpe flypiper (~pipercub@12-222-141-210.client.insightBB.com) |
| 19:33.25 | *** join/#gpe flypiper (~pipercub@12-222-141-210.client.insightBB.com) |
| 19:39.18 | pb_ | spung: your mail server would appear to be generating a loop. |
| 19:39.46 | dctanner_ | hum |
| 19:39.54 | dctanner_ | I wish they made anti-ADH coffee. |
| 19:40.11 | dctanner_ | jg: oh dear.. |
| 19:40.17 | dctanner_ | jg: sounds painfull :{ |
| 19:51.49 | spung | pb_: ohh.. why? |
| 19:53.29 | pb_ | spung: goto #flood |
| 19:58.01 | pb_ | spung: oh well. I guess there is nothing much you can do about it, other than complain to them if it goes on happening. |
| 19:58.34 | spung | pb_: ok, please let me know if it continues to happen |
| 19:59.00 | pb_ | spung: the messages that this happens to will probably not get through to your mailbox. If it's only cvs-updates-gpe that is affected, that probably won't bother you too much, but it might be occurring with other stuff as well. |
| 19:59.12 | pb_ | spung: I will let you know what happens. |
| 19:59.23 | spung | right, thanks |
| 19:59.39 | spung | pb_: i guess i should start looking for better mail service ;) |
| 19:59.46 | pb_ | spung: good plan :-) |
| 20:01.41 | dc_ | pb_: if I make a function with IRCServer **server |
| 20:01.50 | dc_ | pb_: and I send it &server |
| 20:02.00 | dc_ | pb_: where server is an IRCServer *server |
| 20:02.02 | dc_ | will it work :/ |
| 20:02.25 | pb_ | dc_: sure. that looks ok. |
| 20:03.16 | dc_ | pb_: then, in the function that has IRCServer **server in the heading, can I send server is just foo(server) to foo (IRCServer *server) |
| 20:03.28 | dc_ | s/is/as |
| 20:03.36 | pb_ | dc_: no, you would have to dereference it one time, foo(*server) |
| 20:04.03 | dc_ | so just I add a * when going from ** to a *? |
| 20:04.20 | dc_ | or I have to do the whole IRCServer *server? |
| 20:04.37 | pb_ | "*" is more or less the opposite of "&" |
| 20:04.44 | dc_ | okay |
| 20:04.51 | dc_ | here. |
| 20:05.00 | dc_ | <PROTECTED> |
| 20:05.03 | dc_ | then |
| 20:05.09 | dc_ | <PROTECTED> |
| 20:05.23 | dc_ | gboolean |
| 20:05.23 | dc_ | irc_server_connect (IRCServer **server) |
| 20:05.23 | dc_ | okay... |
| 20:05.23 | pb_ | looks cool so far |
| 20:05.28 | dc_ | in irc_server_connect |
| 20:05.34 | dc_ | irc_server_login (IRCServer *server) |
| 20:05.40 | dc_ | yah? |
| 20:05.51 | dc_ | gboolean |
| 20:05.51 | dc_ | irc_server_login (IRCServer *server) |
| 20:05.54 | pb_ | just irc_server_login(*server) |
| 20:05.58 | dc_ | oh okay |
| 20:06.01 | pb_ | but |
| 20:06.09 | dc_ | yes? |
| 20:06.17 | pb_ | you may need to make sure that *server points to something real |
| 20:06.36 | pb_ | depending on what irc_server_login will actually do with it. |
| 20:06.36 | dc_ | hum. |
| 20:06.41 | dc_ | okay |
| 20:06.49 | dc_ | well, then irc_server_login has |
| 20:06.58 | dc_ | <PROTECTED> |
| 20:07.16 | dc_ | so basily, they all need to edit server, except irc_server_login |
| 20:07.39 | dc_ | or would it make more sense to pass it all the way through as a &? |
| 20:07.57 | pb_ | I think it would be better to pass it as an IRCServer ** all the way through |
| 20:08.06 | dc_ | right |
| 20:08.22 | pb_ | ie make irc_server_login take (IRCServer **server) |
| 20:08.35 | dc_ | okay |
| 20:08.47 | florian | bbl |
| 20:09.45 | pb_ | brb, need to go cook dinner |
| 20:10.18 | dc_ | :) |
| 20:13.35 | pigeon | Hmm... slashdot has been slashdotted? :\ |
| 20:16.28 | dc_ | heh |
| 20:17.48 | pb_ | darn |
| 20:17.59 | pb_ | looks like I need to wait for the dishwasher to finish first. |
| 20:18.41 | dc_ | pb_: :/ |
| 20:18.43 | dc_ | pb_: hum |
| 20:18.56 | dc_ | pb_: when I have ** in my functions prototype.. |
| 20:19.13 | dc_ | pb_: do I have to use & to pass it onnto another function with ** in the prototype? |
| 20:19.32 | pb_ | dc_: no |
| 20:19.34 | dc_ | pb_: it's complaining it's not a struct. |
| 20:19.53 | pb_ | dc_: hm, check in the code and I'll have a look at it |
| 20:20.01 | dc_ | pb_: done. |
| 20:20.41 | pb_ | dc_: ah, if you have an IRCServer *, you have to dereference it twice to get a struct |
| 20:20.53 | pb_ | er, sorry, I meant if you have an IRCServer ** |
| 20:21.03 | dc_ | pb_: in what function...? |
| 20:21.09 | dc_ | ohh... |
| 20:21.10 | pb_ | dc_: irc_server_join_channel for example |
| 20:21.14 | dc_ | append a *? |
| 20:21.18 | dc_ | preprend :} |
| 20:21.21 | pb_ | dc_: server->fd would be appropriate for an IRCServer * |
| 20:21.29 | pb_ | dc_: so you would need (*server)->fd for an IRCServer ** |
| 20:21.39 | dc_ | hum |
| 20:22.00 | dc_ | but I only want that when passing it onto another irc_server function? |
| 20:22.20 | pb_ | dc_: can you not just use IRCServer * throughout? |
| 20:22.31 | pb_ | dc_: I don't quite understand where the use of IRCServer ** comes from. |
| 20:22.37 | dc_ | pb_: well, I need to be able to edit it... |
| 20:22.38 | dc_ | :/ |
| 20:22.43 | pb_ | dc_: edit it in what sense? |
| 20:22.48 | dc_ | pb_: without passing it back |
| 20:22.59 | pb_ | dc_: if you have IRCServer *server, you can do server->fd = 1; |
| 20:23.05 | dc_ | :} |
| 20:23.08 | pb_ | dc_: and that change will be visible in the caller. |
| 20:24.03 | pb_ | :-} |
| 20:24.40 | dc_ | wee |
| 20:24.55 | dc_ | hrm |
| 20:25.01 | dc_ | it didn't join the irc channel :/ |
| 20:27.53 | dc_ | maybe I should write some code to read from the irc server... |
| 20:28.09 | pb_ | seems like a good idea. |
| 20:34.32 | dc_ | pb_: how do I get an idea of how many bytes to read when I call read ()? |
| 20:34.51 | pb_ | dc_: just pick a buffer size that seems good to you, maybe 1k or something |
| 20:34.55 | dc_ | pb_: or rather, what value should be arg3 of read () |
| 20:34.58 | dc_ | pb_: okay :} |
| 20:35.14 | pb_ | dc_: the third argument needs to be the amount of space available |
| 20:35.22 | dc_ | right |
| 20:35.31 | pb_ | dc_: so for example char buf[256]; n = read (fd, buf, sizeof(buf)); |
| 20:35.37 | dc_ | okay. |
| 20:35.44 | dc_ | hum. |
| 20:36.02 | dc_ | and I guess I read keep reading untill it returns 0 |
| 20:36.28 | pb_ | it will only return 0 at the end of the stream (ie when you are disconnected from the server) |
| 20:36.52 | dc_ | oh... |
| 20:37.01 | dc_ | then....how do I know when to stop? |
| 20:37.32 | pb_ | well, you can use select() to find out whether any data is waiting |
| 20:37.33 | dc_ | I guess I should really have another thread for this...but for now.. |
| 20:37.44 | dc_ | okay |
| 20:39.43 | dc_ | pb_: is select () blocking? |
| 20:39.57 | dc_ | heh |
| 20:39.58 | dc_ | I guess it is. |
| 20:43.02 | pigeon | dc_: Depends on your argument. |
| 20:43.39 | dc_ | pigeon: in what way? |
| 20:43.43 | pigeon | select will block if your timeout is NULL. |
| 20:43.50 | dc_ | okay |
| 20:44.06 | dc_ | but while select is waiting for a change, it wll block won't it? |
| 20:44.46 | pigeon | If timeout is not NULL, then it will wait/block for the timeout you've given. |
| 20:44.52 | dc_ | quite |
| 20:47.37 | pigeon | If timeout is zero, then it will return straight away, so won't block. |
| 20:47.48 | dc_ | :) |
| 20:49.17 | pigeon | i.e. tv_sec and tv_usec are both 0. |
| 20:49.27 | dc_ | yep |
| 20:57.33 | *** join/#gpe dctanner_ (~dctanner@modem-47-41-60-62.vip.uk.com) |
| 20:58.56 | dctanner_ | hrm |
| 21:07.11 | dc__ | pigeon: is int n in select ment to be fd + 1? |
| 21:07.38 | pb_\afk | dc__: it is |
| 21:07.48 | dc__ | pb_\afk: thanks :) |
| 21:08.17 | dc__ | yay, it works.. |
| 21:10.32 | dc__ | weee |
| 21:10.41 | dc__ | the irc server sent me some garbled data |
| 22:03.22 | florian | re |
| 22:04.52 | dc__ | hum |
| 22:04.54 | dc__ | quite |
| 22:08.14 | dc__ | pb_: I guess I have to translate this data then> |
| 22:08.15 | dc__ | ? |
| 22:09.15 | pigeon | Hmm. |
| 22:09.21 | dc__ | pigeon: :} |
| 22:09.23 | pigeon | irc should all be in text. |
| 22:09.26 | dc__ | pigeon: any idea.. |
| 22:09.28 | dc__ | pb_: well... |
| 22:09.31 | dc__ | pigeon: well |
| 22:09.51 | dc__ | pigeon: when I do read on the fd, and print it, I get garble |
| 22:10.14 | pigeon | Hmm maybe you're not getting data properly then... |
| 22:11.05 | dc__ | maybe |
| 22:11.17 | dc__ | pigeon: do I have to do anything special before I read ()? |
| 22:11.17 | pigeon | What are you writing now btw? |
| 22:11.27 | dc__ | pigeon: and irc client :} |
| 22:11.46 | pigeon | Hehe kewl. |
| 22:11.51 | dc__ | pigeon: gpe-irc :} |
| 22:11.59 | dc__ | pigeon: I'll show you what I've got.. |
| 22:12.06 | dc__ | pigeon: #flood |
| 22:12.42 | pigeon | I can help in the client if you need and if I have time... I wrote an irc server before... |
| 22:12.55 | dc__ | oh yay :) |
| 22:13.04 | pigeon | gtk2? |
| 22:13.09 | dc__ | pigeon: well, what I do need help with is the backen |
| 22:13.10 | dc__ | d |
| 22:13.26 | pigeon | Ok... |
| 22:13.30 | dc__ | pigeon: yep. but I'm good for the ui, just all this sockets stuff has confused me |
| 22:13.37 | dc__ | pigeon: you get a copy of gpe cvs> |
| 22:13.37 | dc__ | ? |
| 22:13.59 | pigeon | Yeah, I'm still in the gtk1 world, I know nothing about gtk2 almost :( |
| 22:14.20 | dc__ | pigeon: right well, have a look at base/gpe-irc/irc.c |
| 22:14.29 | dc__ | pigeon: there's very little, but :} |
| 22:14.35 | pigeon | Hmm and I thought you guys are using that olirc thingy? |
| 22:14.40 | dc__ | well |
| 22:14.41 | pigeon | dc__: Ok. |
| 22:15.09 | dc__ | I wanted to have a go at writing one from scratch, so I could learn more about sockets etc :/ |
| 22:15.27 | pigeon | nod... |
| 22:15.47 | pigeon | gpe-money is still in my mind, too. :\ |
| 22:15.55 | dc__ | pigeon: though, I'm not sure if I'm doing the channel join correctly, or even connecting correctly :/ |
| 22:15.57 | dc__ | pigeon: :} |
| 22:16.22 | pigeon | Hang on. |
| 22:18.51 | pb_ | dc__: you need to check the return value from read to find out how much data was returned. |
| 22:19.00 | dc__ | ooh :) |
| 22:19.02 | pb_ | dc__: it could only be one or two bytes at a time. |
| 22:19.44 | dc__ | then, I print that? |
| 22:19.51 | dc__ | only the len I get. |
| 22:19.53 | pb_ | yep |
| 22:21.07 | dc__ | snprintf I guess? |
| 22:25.10 | pigeon | dc__: I think at least you need to specify a port to connect to... :) |
| 22:25.18 | dc__ | oh... |
| 22:25.19 | dc__ | :/ |
| 22:25.25 | dc__ | pigeon: where :} |
| 22:25.38 | *** join/#gpe flypiper (~pipercub@12-222-141-210.client.insightBB.com) |
| 22:26.13 | pigeon | Err hang on. |
| 22:26.27 | pigeon | You're using service, fair enough. But it's not even doing a connection here. |
| 22:26.37 | dc__ | oh. |
| 22:26.47 | dc__ | what's it doing...? |
| 22:26.52 | *** join/#gpe argv[2] (~argv[2]@flu11888-1.gw.connect.com.au) |
| 22:26.59 | pigeon | Heh. |
| 22:27.03 | dc__ | :] |
| 22:27.04 | pigeon | Now that's your code :) |
| 22:27.06 | dc__ | hehe |
| 22:27.08 | dc__ | right |
| 22:27.12 | pigeon | Service should be "ircd" |
| 22:27.13 | dc__ | hoe cute. |
| 22:27.16 | pigeon | Not irc. |
| 22:27.16 | dc__ | :) |
| 22:27.18 | pigeon | Anyway. |
| 22:27.27 | dc__ | oops. |
| 22:27.31 | dc__ | yeah I see the argv stuff. |
| 22:27.32 | dc__ | heh |
| 22:27.51 | dc__ | yay |
| 22:27.54 | dc__ | well it connected :D |
| 22:28.01 | *** join/#gpe dc_gpe-irc (~dc_gpe-ir@flu11888-1.gw.connect.com.au) |
| 22:28.23 | pigeon | Heh |
| 22:28.29 | *** join/#gpe dc___ (~dc___@modem-47-41-60-62.vip.uk.com) |
| 22:28.36 | dc__ | wee |
| 22:29.14 | dc__ | oke, updated cvs... |
| 22:29.23 | dc__ | <PROTECTED> |
| 22:29.23 | dc__ | <PROTECTED> |
| 22:29.23 | dc__ | <PROTECTED> |
| 22:29.29 | dc__ | something's wrong with that :/ |
| 22:29.54 | *** join/#gpe dc___ (~dc___@modem-47-41-60-62.vip.uk.com) |
| 22:29.59 | dc__ | weeeeeeeee |
| 22:30.02 | dc__ | output! |
| 22:30.03 | dc__ | yay |
| 22:30.08 | dc__ | wooow. |
| 22:30.15 | dc__ | pigeon: hooray |
| 22:30.22 | florian | good night |
| 22:30.34 | pigeon | dc__: It's a good idea to check the return value of a read before you do anything else. |
| 22:30.39 | dc__ | pigeon: okay |
| 22:30.55 | pigeon | It returns -1 on failure, so snprintf won't be happy if that happens. |
| 22:31.11 | dc__ | right |
| 22:31.32 | *** join/#gpe dc___ (~dc___@modem-47-41-60-62.vip.uk.com) |
| 22:32.25 | dc__ | now I can just make my parser from the output |
| 22:32.41 | pigeon | Memory leak here and there. :) |
| 22:32.45 | pigeon | dc__: Yeah. |
| 22:32.47 | dc__ | :/ |
| 22:33.27 | *** join/#gpe dc___ (~dc___@modem-47-41-60-62.vip.uk.com) |
| 22:33.32 | dc__ | no lag... |
| 22:33.34 | dc__ | hum |
| 22:34.16 | *** join/#gpe dc___ (~dc___@modem-47-41-60-62.vip.uk.com) |
| 22:35.03 | *** join/#gpe dc___ (~dc___@modem-47-41-60-62.vip.uk.com) |
| 22:35.15 | dc__ | hum |
| 22:35.30 | dc__ | so it won't read data with a timeout of 1 usec |
| 22:36.11 | dc__ | for some reason it's not looping the read... |
| 22:36.42 | *** join/#gpe dc___ (~dc___@modem-47-41-60-62.vip.uk.com) |
| 22:36.47 | dc__ | hum |
| 22:37.22 | *** join/#gpe dc___ (~dc___@modem-47-41-60-62.vip.uk.com) |
| 22:37.26 | dc__ | . |
| 22:37.30 | dc__ | oh |
| 22:37.32 | dc__ | yay |
| 22:38.02 | dc__ | it's giving me a names list with every command |
| 22:38.08 | dc__ | I recieve. |
| 22:58.14 | *** join/#gpe dctanner_ (~dctanner@modem-23-52-60-62.vip.uk.com) |
| 23:06.26 | dctanner_ | pigeon, pb_: do you mind having a look at the code in cvs....see what I've tried to done :/ |
| 23:06.31 | dctanner_ | s/done/do |
| 23:06.33 | dctanner_ | bbl |
| 23:06.36 | pb_ | dctanner_: sure |
| 23:10.54 | pb_ | dctanner_: it's '\n' not '/n' |
| 23:11.29 | pb_ | dctanner_: and I don't think the stuff you are doing with strlen(message) will work. strlen needs a zero terminated string to operate on. |