Back
[00:09:21] <jmkasunich> jepler: you around?
[00:09:25] <jepler> jmkasunich: yeah
[00:09:27] <jepler> what's up?
[00:09:35] <jepler> i've been playing with my FPGA
[00:09:40] <jmkasunich> does the simulator need to be built "run in place"?
[00:09:45] <jmkasunich> cool
[00:09:52] <jepler> there are probably still problems lurking, but I want it to work "installed"
[00:09:55] <jmkasunich> oops, gotta run...
[00:10:02] <jepler> so tell me about the bugs and I'll fix 'em
[00:10:11] <jmkasunich> ok, I'm setting up a non-rt breezy compile farm slot, it will _not_ do rip
[00:10:15] <jmkasunich> back in an hour or so
[00:10:27] <jepler> I'm pretty sure it builds, but it probably doesn't work after install
[00:10:48] <jepler> flo-h is trying to do nort run-installed and he's reported some problems, at least one of which I haven't fixed yet
[00:25:31] <SWPadnos> alex_joni, I'm back now
[01:00:08] <jmkasunich> I'm back now too ;-)
[01:00:20] <SWPadnos> yay!
[01:15:01] <cradek> can someone else run halscope on head and try triggering on a change of axis.n.joint-pos-cmd?
[01:28:28] <cradek> I'm pretty sure triggering is broken - I can't find anything I'm doing wrong
[01:28:58] <cradek> when I trigger manually the trace crosses the dashed trigger line
[01:33:51] <jmkasunich> I'll give it a try
[01:37:09] <jmkasunich> cradek: which config are you running?
[01:37:43] <jepler> I ran the 'axis' configuration and triggered on rising axis.n.joint-pos-cmd
[01:37:51] <jepler> I didn't know you could trigger on any change
[01:38:00] <jmkasunich> sim/axis?
[01:38:04] <jepler> yes, sim/axis
[01:38:08] <cradek> no it's my own config unfortunately
[01:38:08] <jepler> it worked for me
[01:38:13] <jepler> bbl
[01:38:15] <cradek> not in cvs
[01:38:24] <jmkasunich> you mean I gotta loadrt the scope and everything myself
[01:38:26] <jmkasunich> (whine)
[01:38:34] <cradek> maybe I should make clean
[01:38:54] <jmkasunich> lemme at least test first
[01:41:00] <jmkasunich> triggered for me
[01:41:14] <cradek> http://timeguy.com/cradek-files/emc/trigger.png
[01:41:23] <cradek> here's my setup, manually triggered so you can see it
[01:41:33] <cradek> the bottom is trace 3, you can see it crosses the trigger line
[01:42:10] <cradek> it goes from 6 to 16 and you can see the trigger is +12
[01:42:32] <jepler> yep I see that
[01:42:49] <jepler> I wondered if it was some kind of GUI bug in drawing the trigger line but that doesn't seem to be it
[01:42:54] <jmkasunich> ok - the trigger level is 0, even tho its set to be non-zero
[01:43:12] <jmkasunich> it worked for me the first time because I left the level at zero
[01:43:15] <cradek> jmkasunich: I don't understand
[01:43:31] <cradek> jepler: no I don't think it's a gui problem either
[01:43:31] <jmkasunich> I jogged from 0 to 0.5 and it triggered
[01:43:43] <jmkasunich> then I changed the level from 0 to 1, and jogged from 0.5 to 1.5, no trigger
[01:43:44] <jepler> oh you're right
[01:43:49] <jepler> it is triggering at 0, not where the line is
[01:43:59] <jepler> I also moved across 0 when I tested
[01:44:01] <jmkasunich> then I jogged down to -0.5, then back to 0.5, and it triggered when it crossed zero
[01:44:23] <cradek> yep it triggers at 0 for me too
[01:44:26] <cradek> good, it's not just me
[01:44:38] <cradek> no wonder I was having a terrible time getting the traces I wanted
[01:44:40] <jmkasunich> but you get to fix it
[01:44:42] <jmkasunich> ;-)
[01:44:50] <cradek> argh!
[01:44:56] <cradek> how could this have stopped working?
[01:45:06] <jmkasunich> more like "when"
[01:45:12] <jmkasunich> it could have been quite a while
[01:45:17] <cradek> true
[01:45:55] <jmkasunich> I want to finish setting up another compile farm vm, then maybe I can take a look
[01:46:12] <cradek> ok, I'll look meanwhile, but I'm pretty clueless
[01:46:41] <cradek> http://www.knitemare.org/cats/270915351_bc8e626c68.jpg
[01:47:15] <jmkasunich> you want to gang up on it? I don't want to get bogged down right now, but I'd be happy to help you get oriented
[01:47:33] <cradek> no, I'll look at changes for a while, no sweat
[01:47:59] <jmkasunich> cute pic
[01:48:07] <jepler> I'll be looking at it too
[01:48:21] <jmkasunich> Elros:
[01:48:21] <jmkasunich> <i>are you sure there will be enough strenght in Wyrkfir and Amersfield to drow OT out? Because if we make our move in wrong direction it will turn arround and bite our behinds...</i>
[01:48:21] <jmkasunich> Yes, that is a risk. But there is always risk in war. We will have the assistance of the remaining militia in Koolaris and the peasants there as well - tomorrow those forces will be weaker or gone. Likewise, OT can send reinforcements tomorrow. The time has come to act.
[01:48:21] <jmkasunich> On a purely practical note - the orders to move were given very early in the day (which is how it should be, so that every troop leader gets them). By now, some troop leaders have already started to march, and changing the orders now would be a disaster.
[01:48:25] <jmkasunich> Regards,
[01:48:27] <jmkasunich> oops
[01:48:29] <jmkasunich> dammit
[01:49:10] <jmkasunich> I guess you can't copy and paste from a VM
[01:49:40] <cradek> yeah, that always more or less sucks
[01:49:51] <jmkasunich> http://linuxcnc.org/compile_farm/
[01:49:59] <jmkasunich> thats what I was trying to paste
[01:50:12] <cradek> slick
[01:50:19] <jepler> whee!
[01:50:23] <cradek> a nonrealtime!
[01:50:33] <jmkasunich> breezy RT is coming soon
[01:50:55] <cradek> how long does it take to do a build?
[01:51:10] <jepler> build started at 2006-11-25 04:17:02 build completed successfully at 2006-11-25 04:21:11
[01:51:19] <cradek> not bad!
[01:51:23] <jmkasunich> 4 mins, not bad at all
[01:52:37] <jmkasunich> oops, I got distracted and forgot - there's still some problem, it couldn't send mail to CIA
[01:56:58] <jmk-vm02> esmtp: error while loading shared libraries: libesmtp.so.5: cannot open shared object file: No such file or directory
[01:57:27] <jmk-vm02> any hints? I installed libesmtp (download, configure, make, sudo make install)
[01:58:08] <cradek> where did it put libesmtp.so.5?
[01:59:15] <jmk-vm02> /usr/local/lib/libesmtp.so.5
[01:59:51] <jmk-vm02> I wonder if I have to explicitly tell esmtp where the lib is when I do ./configure for it?
[02:00:01] <cradek> try ldconfig /usr/local/lib
[02:00:15] <cradek> no it's a ld.so problem
[02:04:03] <cradek> the HAL_FLOAT case in check_trigger() makes me cry
[02:05:10] <jmkasunich> heh
[02:05:26] <jmkasunich> the problem is that you might be running the scope in a thread that doesn't support FP
[02:05:42] <jmkasunich> using the FPU would be a very bad thing, because a non-FP thread doesn't save the FPU state
[02:05:45] <cradek> I understand
[02:06:24] <jmkasunich> thats not the problem is it?
[02:06:39] <cradek> no clue yet
[02:06:55] <cradek> you touched check_trigger when you took out those types (but the union can still hold them)
[02:07:33] <jepler> cradek: do you think that "parameter" is important or not important?
[02:07:41] <jepler> I don't usually trigger on parameters...
[02:08:14] <cradek> let me try a pin
[02:08:15] <jmkasunich> I would be amazed if the same bustage didn't also exist with signals and pins
[02:08:51] <cradek> it seems like the bustage must have been jmk removing the types, but I don't see what could have gone wrong
[02:09:04] <jmkasunich> cradek: I missed that union because it doesn't use the HAL types
[02:09:12] <jmkasunich> you're not running x64 are you?
[02:09:38] <jmkasunich> that would bust it good - because I declare d_u32 as an unsigned long
[02:09:40] <jmkasunich> shame on me
[02:09:52] <cradek> no, i386
[02:10:56] <jepler> unless I screwed up, it's busted in the nov 1 version and it doesn't matter if it's a pin or not
[02:11:00] <cradek> same problem in a pin
[02:11:31] <jmkasunich> nov1 is before I went slashing and burning to remove u8 and friends, right?
[02:11:49] <jepler> I think so
[02:12:03] <jmkasunich> I think that was just a week or so ago (they say short term memory is the first to go)
[02:12:55] <jepler> trying oct 15
[02:13:09] <jmkasunich> cradek: a kind of brute force hack that can tell you if the level is getting to the realtime code:
[02:13:16] <jmkasunich> add a static var to check_trigger
[02:13:42] <jmkasunich> compare it to level->u32, if they don't match, print the new value, and store it in the static
[02:13:52] <jmkasunich> (print to kernel log)
[02:14:01] <jmkasunich> then you can see if the value is getting there
[02:14:20] <jmkasunich> if its not, the problem is in userspace I think, and you could gdb it
[02:14:55] <cradek> triggering on encoder.0.rawcounts (not a float) DOES work
[02:15:05] <jmkasunich> hmm
[02:15:17] <jepler> trig_level
[02:15:22] <jepler> d_float = 1.40129846e-45
[02:15:35] <jepler> the bug is how trig_level.d_float is being set (or not)
[02:15:49] <jmkasunich> ok, thats in user space I think
[02:16:04] <jepler> looks like it's still/already there in oct 15
[02:16:45] <jmkasunich> hal_trig.c line 135 sets it I think
[02:17:44] <jepler> here's how I'm testing, btw
[02:17:45] <jepler> loadrt siggen
[02:17:46] <jepler> loadrt threads name1=thread period1=1000000
[02:17:46] <jepler> loadrt scope_rt
[02:17:46] <jepler> addf siggen.0.update thread
[02:17:47] <jepler> start
[02:17:50] <jepler> loadusr -w halscope
[02:17:59] <jepler> ^^ run that in 'halrun' and set the trigger to about 1.2
[02:18:53] <jmkasunich> I found it
[02:19:09] <jmkasunich> line 137 in hal_trig.c
[02:19:16] <jmkasunich> I forgot a break after a case
[02:19:16] <jepler> no "break"
[02:19:40] <jepler> you get the honor of fixing it
[02:19:44] <jmkasunich> but those if's should have no effect
[02:19:52] <jepler> ctrl_shm->trig_level.d_s32 = fp_level;
[02:20:05] <jepler> no, but this statement stores an int-type value in the same memory
[02:20:09] <jmkasunich> right
[02:20:10] <cradek> yeah
[02:20:25] <jmkasunich> I'll fix, test, and commit
[02:20:29] <jepler> hooray
[02:20:40] <jepler> I remember jon elson saying at fest last year that he just couldn't ever get triggering to work right
[02:20:46] <jepler> maybe he was right after all
[02:20:51] <cradek> has it been broken forever?
[02:20:56] <jmkasunich> probably
[02:21:32] <cradek> that seems so hard to believe
[02:21:38] <cradek> I thought I used it all the time
[02:22:03] <jepler> switch (chan->data_type) {
[02:22:04] <jepler> case HAL_FLOAT:
[02:22:04] <jepler> ctrl_shm->trig_level.d_float = fp_level;
[02:22:05] <jepler> case HAL_S8:
[02:22:11] <jepler> </revision 1.1>
[02:22:16] <jepler> maybe it worked less bad when we had 8-bit types
[02:22:24] <jepler> in that case, would it only change some low-order bits?
[02:22:27] <cradek> ohhh
[02:22:30] <jmkasunich> I bet that was it
[02:22:39] <jmkasunich> the break does fix it
[02:23:56] <jepler> it's obvious .. once you're able to see it
[02:24:27] <cradek> it also shows that you can't change *anything* without possibly introducing bugs
[02:24:46] <jmkasunich> my change didn't introduce the bug
[02:24:51] <jmkasunich> it merely unmasked it
[02:25:03] <cradek> right, but your change made the program stop working 'right'
[02:25:09] <jmkasunich> which just proves that you cannot test away bugs
[02:25:34] <jmkasunich> it was working wrong before too - but by a very small amount
[02:26:11] <cradek> thanks guys, back to what I was doing now
[02:26:16] <jmkasunich> ditto
[02:27:11] <cradek> whee, it works
[02:32:48] <jmkasunich> I just noticed that slots 2 thru 5 haven't built since 11/19
[02:33:03] <jmkasunich> "now what" he says in exasperation
[02:35:38] <jmkasunich> this mess again:
[02:35:40] <jmkasunich> cvs update: move away docs/man/man9/.cvsignore; it is in the way
[02:35:40] <jmkasunich> C docs/man/man9/.cvsignore
[02:35:40] <jmkasunich> cvs update: move away docs/man/man9/sampler.9; it is in the way
[02:35:40] <jmkasunich> C docs/man/man9/sampler.9
[02:35:40] <jmkasunich> cvs update: move away docs/man/man9/streamer.9; it is in the way
[02:35:44] <jmkasunich> C docs/man/man9/streamer.9
[02:36:14] <jepler> yuck
[02:38:36] <jmkasunich> I think its because there was already a man9 directory (not in CVS) and we added it to CVS
[02:38:49] <jepler> that has been a problem on a number of occasions
[02:38:55] <jmkasunich> yeah
[02:39:12] <jmkasunich> I dunno if its a "bug" in CVS, or just an inherent thing that can't be fixed
[02:39:42] <jepler> it seems a bit like a bug
[02:39:48] <jmkasunich> usually deleting the offending file or dir fixes it, but sometimes only temporarily
[02:39:51] <jepler> but who knows -- maybe they love that behavior for some reason
[02:40:00] <jepler> you can try removing one level above it too
[02:40:03] <jmkasunich> you get one good checkout, then the next one barfs with the same complaint
[02:43:53] <jmkasunich> ok, all three restarted
[02:44:10] <jmkasunich> and it looks like a one-time only problem
[02:56:13] <jmkasunich> hey - do we want to do the 2.1 branch?
[02:56:42] <jmkasunich> if we do it now, I can add it to the compile farm slots as I set them up, instead of doing it later
[02:58:13] <cradek> fine with me
[02:58:29] <cradek> I'm not going to get angled threading done (and tested) right away so let's not wait for that
[02:58:57] <jmkasunich> I know I'm gonna do a few more man pages, but its no big deal to backport them
[02:59:51] <jmkasunich> I just have to remember my cvs-fu
[03:37:48] <cradek> back
[03:40:54] <cradek> jmkasunich: are you branching or should I?
[03:41:39] <jmkasunich> I'm working on the next slot - if you can do it without having to read alot first, please do
[03:42:09] <cradek> will do, it's easy
[22:23:19] <SWPadnos> we seem to have little luck with loggers
[22:24:09] <SWPadnos> maybe it's not the connection after all
[22:24:32] <SWPadnos> I'm pretty sure it was working last week - I checked the logs when I found that I couldn't connect from the hotel
[22:24:35] <SWPadnos> (stupid hotel)
[22:24:48] <alex_joni> I think they might have rebooted
[22:24:54] <alex_joni> that's what happened the last time
[22:25:20] <SWPadnos> I know they did a couple of weeks ago - maybe they upgraded the RAM in Dinero recently (they had been doing other servers)
[22:26:09] <jtr> logger_emc was good until sometime today
[22:26:21] <jtr> logger_dev: bookmark
[22:26:21] <jtr> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2006-11-26.txt
[22:26:26] <alex_joni> jtr: good, not that long ago then
[22:28:35] <jtr> logger_dev was out from 06:18 to 22:23 today
[22:28:47] <jtr> just noticed
[22:29:12] <SWPadnos> hmmm - maybe I can splice my local log into it
[22:33:15] <alex_joni> sorry guys.. early plane to catch
[22:33:42] <cradek> bye alex
[22:33:45] <jtr> safe trip!
[22:33:54] <alex_joni> yah.. thanks
[22:34:05] <alex_joni> cradek: I'm not sure what to say/think about the configs & 2.1
[22:34:16] <cradek> we don't have to decide today
[22:34:26] <alex_joni> but I think whatever we do will stick for 2.2 & on
[22:34:35] <alex_joni> so let's really think it through ;)
[22:35:04] <cradek> this problem (incomatible configs) will certainly continue with newer versions
[22:35:15] <alex_joni> indeed
[22:35:30] <alex_joni> maybe a version in the ini is not a bad idea afterall
[22:36:47] <alex_joni> brb
[22:37:22] <jtr> swpadnos: logger_emc was out for about the same length of time. I was looking for the discussion on measuring gears when I noticed it.
[22:39:01] <jtr> It would be great if you can splice it.
[22:46:56] <SWPadnos> ok - I
[22:47:03] <SWPadnos> ok - I'll see what I can do
[22:50:08] <jtr> great, thanks!
[22:55:31] <alex_joni> back
[22:56:29] <SWPadnos> actually, I shouldn't mess with those logs until the day is over, which shouldn't be too long :)
[22:57:02] <alex_joni> cradek: still there?
[22:57:22] <jtr> makes sense to me.
[22:57:47] <jtr> oops - getting called for dinner (to help with)
[22:57:53] <cradek> yes
[22:58:00] <alex_joni> SWPadnos: ~emcboard/logger/logger.sh should get the loggers back if they fail
[22:58:40] <alex_joni> cradek: been thinking some more about configs, and I think keeping ~/emc2/ is appropiate
[22:59:19] <alex_joni> the config-picker looks in ~/emc2/<subdirs>/*.ini right?
[22:59:58] <cradek> yes
[23:00:16] <cradek> well it has a pathlist specified at compile time
[23:00:22] <cradek> but that's the current first entry
[23:00:36] <alex_joni> ok, that's what I was asking
[23:00:59] <alex_joni> how about if the convert script renames those folders to foo-2.0
[23:02:04] <alex_joni> e.g. appends "-2.0"
[23:02:18] <SWPadnos> copy to ~/emc2/old-configs or some such, and leave the ~/emc2/configs/XX for modification
[23:02:23] <alex_joni> maybe even makes a copy and names that -2.1
[23:02:28] <alex_joni> or that
[23:02:46] <cradek> I'm starting to think I might be against any auto conversion
[23:02:49] <jmkasunich> as long as they don't already end in -something... otherwise after a while you'll have things like stepper-2.2-2.1.2.0 ;-)
[23:03:00] <alex_joni> we can't do this from preinstall/postinstall anyways
[23:03:03] <cradek> how does the installer know whose home directory to mess with?
[23:03:07] <SWPadnos> consider icons that have been set up to run some particular config (such as a lathe or mill ...) - it would be ideal if the user could get bby with changing as little as possible
[23:03:17] <alex_joni> cradek: yeah.. :/
[23:03:26] <alex_joni> maybe make the convert script separately available
[23:03:29] <alex_joni> by download
[23:03:36] <jmkasunich> as little as possible = changing the config files themselves, just as needed to make them work
[23:03:43] <cradek> wouldn't surprise me if debs are forbidden from doing that anyway (by policy, not program)
[23:03:45] <SWPadnos> yes
[23:03:47] <jmkasunich> no filenames, no new directories, no changes to the icon
[23:03:58] <alex_joni> cradek: I agree doing by deb is wrong
[23:04:07] <SWPadnos> exactly - it's incumbent on the user to make a backup before destroying anything
[23:04:30] <alex_joni> but we either a. use a different folder for the 2.1 stuff, then the user needs to do it manually
[23:04:32] <cradek> I guess I agree, but that leaves me really scared
[23:04:43] <alex_joni> or b. use the same folder, and the user still needs to do something manually
[23:05:06] <alex_joni> a. seems a bit easier to downgrade/recover then b.
[23:06:23] <cradek> agreed
[23:06:45] <alex_joni> but they both assume some involvance from the user
[23:06:49] <cradek> which way is the least savvy user less likely to screw himself?
[23:07:04] <alex_joni> so I guess the "easiest" is to have emc2.1 as a different package
[23:07:11] <alex_joni> and he does get it only if he asks for it
[23:07:18] <cradek> whoah
[23:07:22] <alex_joni> and then he gets to keep the pieces if he breaks it :D
[23:07:23] <cradek> that's a whole other issue alex
[23:07:28] <alex_joni> cradek: I know :(
[23:07:46] <alex_joni> thought jepler touched that aspect earlier
[23:07:48] <SWPadnos> that may be a good policy for anything that could break configs, but it's a real PITA
[23:07:54] <cradek> fwiw I think it's a good idea
[23:08:00] <cradek> (I think)
[23:08:10] <alex_joni> it's certainly food for thoughts
[23:08:13] <cradek> have emc2.1 conflict with emc2
[23:08:15] <alex_joni> (till next week)
[23:08:20] <jmkasunich> it means that the user will _not_ be advised to upgrade automatically
[23:08:27] <cradek> yes
[23:08:27] <alex_joni> jmkasunich: that is correct
[23:08:31] <jmkasunich> which is good for those who want to keep 2.0
[23:08:50] <jmkasunich> bad for those who don't realize 2.1 is out there and would like to use it
[23:09:01] <cradek> the least savvy user will accept all updates that pop up, and then not know how to fix it because he won't read any instructions
[23:09:09] <jmkasunich> right
[23:09:14] <alex_joni> 2.0.5 could advertise it
[23:10:00] <cradek> we'll be bombarded with "yesterday it worked, but I clicked OK on something and today it doesn't work"
[23:10:00] <alex_joni> <brainstorm> news item in the CNC Menu->News. emc2.1 is out, read the info at wiki.....</brainstorm>
[23:10:30] <jmkasunich> in case I wasn't clear (I wasn't), I consider not forcing an upgrade to be a good thing
[23:10:52] <jmkasunich> the failure to advise of an available upgrade can be dealt with other ways, as alex mentioned
[23:11:01] <cradek> we never force an upgrade but people get them by default (clicking OK to things that pop up)
[23:11:08] <jmkasunich> yep
[23:11:25] <jmkasunich> its actually rather inconvenient on an ubuntu box to skip an upgrade
[23:11:38] <cradek> yes
[23:11:43] <jmkasunich> you have to keep skipping it any time any other package upgrades
[23:12:02] <cradek> we could also put 2.1 in a new repository but not rename the package
[23:12:20] <jmkasunich> then you have less than savvy users messing with sources.list
[23:14:30] <cradek> action vs inaction again
[23:14:44] <cradek> by doing nothing (or clicking OK on various things) their system does NOT break
[23:15:11] <jmkasunich> what are the downsides of naming the new package(s) emc2.1?
[23:15:22] <jmkasunich> that is "inaction safe" but doesn'
[23:15:24] <jmkasunich> doesn
[23:15:26] <jmkasunich> dammit
[23:15:40] <jmkasunich> doesn't require changes to sources.list if they _do_ want the update
[23:16:06] <cradek> I don't see a lot of downside to that
[23:16:18] <cradek> they will say apt-get install emc2.1
[23:16:34] <cradek> it will say packages will be REMOVED: emc2 and they say yes if they want that
[23:16:39] <jmkasunich> or using synaptic they can search for emc and will get both
[23:16:46] <jmkasunich> (in the search list)
[23:16:50] <jmkasunich> then click on the one they want
[23:16:59] <cradek> not sure what it says for conflicts - I bet it warns somehow
[23:17:12] <alex_joni> yeah, it deselects one if you select the other
[23:17:12] <cradek> I haven't really used it
[23:17:22] <alex_joni> and gives a warning
[23:17:26] <cradek> thought you were going to bed!
[23:17:36] <alex_joni> shortly away :)
[23:18:37] <alex_joni> I'm definately gonna think more about this, but I'm already in favour not to upgrade people who don't want to
[23:18:57] <alex_joni> * alex_joni is very fond of the IBM motto "never touch a running system"
[23:19:08] <cradek> yeah I'm pretty sure of that too
[23:19:16] <cradek> if someone doesn't need 2.1 features, leave them alone
[23:19:21] <cradek> bbl
[23:19:27] <alex_joni> bye chris
[23:19:36] <alex_joni> see you on thursday probably
[23:19:51] <alex_joni> * alex_joni is off to bed too
[23:19:57] <jmkasunich> goodnight alex
[23:20:00] <alex_joni> getting up in 5 hours and counting :(
[23:20:12] <jmkasunich> I have to catch a flight tomorrow morning too
[23:20:24] <jmkasunich> 7am flight, 4:30 or so wakeup
[23:20:26] <alex_joni> bet it's not 1am over there now :D
[23:20:33] <jmkasunich> not yet ;-)
[23:20:38] <alex_joni> 9am flight, 6:30 wakeup
[23:20:48] <jmkasunich> go to sleep!
[23:20:54] <alex_joni> yeah.. bye all
