Please note:The SCons wiki is in read-only mode due to ongoing spam/DoS issues. Also, new account creation is currently disabled. We are looking into alternative wiki hosts.
   1 16:50:31 *	Garyo (~chatzilla@209-6-36-50.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has joined #SCONS
   2 16:55:03 *	jason_at_intel (~chatzilla@185.sub-75-205-7.myvzw.com) has joined #SCONS
   3 16:55:21 *	bdbaddog (~bdeegan@adsl-71-131-10-196.dsl.sntc01.pacbell.net) has joined #SCONS
   4 17:03:18 *	sgk (~sgk@nat/google/x-vdmoydnhvesvboyw) has joined #SCONS
   5 17:05:37 <GregNoel>	Are we ready to go?
   6 17:05:44 <Garyo>	i am
   7 17:05:47 <jason_at_intel>	Hi Steve, think we found the cause of the temp file issue
   8 17:05:53 <sgk>	ready when everyone else is
   9 17:05:54 <jason_at_intel>	I am ready
  10 17:05:57 <GregNoel>	1938 Gary took it
  11 17:05:57 <GregNoel>	1891
  12 17:06:06 <sgk>	i saw your mail, that sounds exactly like what's going on
  13 17:06:42 <Garyo>	1891?
  14 17:07:01 <GregNoel>	That's what's on the spreadsheet.
  15 17:06:56 <sgk>	sorry, that reply was to jason
  16 17:07:00 <jason_at_intel>	I think it just needs a fix to mslink
  17 17:07:08 <sgk>	jason, let's stick to the issue list and we can discuss the tempfile thing in turn
  18 17:07:21 <sgk>	or at the end if we haven't gotten to it
  19 17:07:17 <jason_at_intel>	yep
  20 17:07:27 <jason_at_intel>	so 1891
  21 17:07:34 <jason_at_intel>	I think we need to fix mslink.py
  22 17:07:41 <jason_at_intel>	and this will work
  23 17:08:12 <sgk>	that makes sense
  24 17:08:07 <Garyo>	Agree it can't be that hard.  Who has time?  Jason, would you like to take a crack at it?
  25 17:08:19 <jason_at_intel>	I would be happy to
  26 17:08:27 <Garyo>	2.1 p3 jason?
  27 17:08:33 <jason_at_intel>	I will try it out in the Parts mslink version
  28 17:08:53 <jason_at_intel>	that should be easy to map back to the SCons version
  29 17:09:10 <jason_at_intel>	since it just a new set of actions
  30 17:08:59 <sgk>	cool, thanks
  31 17:09:03 <sgk>	2.1 p3 jason sounds good to me
  32 17:09:06 <GregNoel>	done
  33 17:09:08 <GregNoel>	2153
  34 17:09:31 <sgk>	2153:  this is the email jason was referring to
  35 17:09:36 <jason_at_intel>	so I sent a mail on this to steve.. summarized here
  36 17:09:54 <sgk>	because long-line tempfiles get created as as a side effect of expanding ${TEMPFILE} in the command line
  37 17:10:12 <sgk>	the file gets created when we expand the line for display, too
  38 17:10:32 <sgk>	and since that display expansion doesn't actually get executed, the tempfile deletion never happens
  39 17:10:51 <Garyo>	hmm, makes sense.
  40 17:10:18 <jason_at_intel>	not sure on what is the best fix... thinking about MD5 the string to store the tempfile name in the env
  41 17:11:08 <sgk>	Jason, do you or your intern have cycles to work w/me on fixing this?
  42 17:11:16 <jason_at_intel>	Yep
  43 17:11:20 <sgk>	it might be a little involved, because it's not happening at the right time
  44 17:11:40 <sgk>	but i can provide direction, and if you two have time for the coding+testing, it'll go quicker than if it's on my plate
  45 17:11:43 <sgk>	okay, cool
  46 17:11:56 <jason_at_intel>	need to know if the env we pass to the action is unique or not
  47 17:12:02 <sgk>	2.1 p2 jason then
  48 17:12:10 <Garyo>	+1
  49 17:12:08 <GregNoel>	done
  50 17:12:14 <GregNoel>	2575 I can post the long comment, but I have commitments that will prevent me from taking much part in the discussion.
  51 17:12:44 <jason_at_intel>	honestly we have this fixed in Parts without a chdir
  52 17:13:02 <sgk>	for zip?  or a more general fix?
  53 17:13:07 <jason_at_intel>	it was so critical, we just made our own zipfile builder
  54 17:13:10 <Garyo>	I don't think it's too involved, but that's cause I'm pretty sure just passing a prefix or prefix to eliminate to the zipfile stuff is the way to go
  55 17:13:20 <jason_at_intel>	zipfile, tarfile bz2file
  56 17:13:31 <jason_at_intel>	it all the same basic code
  57 17:14:00 <jason_at_intel>	we can review it when i visit
  58 17:14:28 <sgk>	let's do that
  59 17:14:34 <Garyo>	I thought at least zipfile can already run w/o chdir
  60 17:14:32 <jason_at_intel>	I don't know if greg is in the CA area or not
  61 17:14:41 <jason_at_intel>	I take it he would want to have a say
  62 17:14:40 <sgk>	greg's in San Diego
  63 17:14:56 <jason_at_intel>	that pretty far south.. correct?
  64 17:15:08 <sgk>	yes, prohibitively so
  65 17:15:27 <jason_at_intel>	:-(.. want to meet the master himself :-)
  66 17:15:31 <sgk>	but we could at least start looking at it
  67 17:15:36 <jason_at_intel>	yep
  68 17:15:41 <Garyo>	How about Greg posting the long comment anyway so we can discuss the interface in the Zip builder, then use your code to implement?
  69 17:15:51 <sgk>	++
  70 17:15:59 <GregNoel>	Garyo, good idea
  71 17:16:08 <jason_at_intel>	sounds good
  72 17:16:23 <sgk>	leave it owned as issues@scons and revisit it after discussion?
  73 17:16:30 <Garyo>	I'm ok w/ that
  74 17:16:32 <GregNoel>	What to do with the issue in the meantime?
  75 17:16:46 <Garyo>	nothing?
  76 17:17:02 <GregNoel>	... with a meaning of review next time?
  77 17:16:59 <jason_at_intel>	is it research?
  78 17:17:22 <sgk>	yeah, either research or leave it as is, so we revisit it next time
  79 17:17:23 <Garyo>	I'm ok w/ research jason too -- that way we'll review it.
  80 17:17:47 <GregNoel>	research p1 then?
  81 17:18:02 <sgk>	done
  82 17:18:02 <GregNoel>	Who should own it?
  83 17:18:18 <sgk>	GregNoel until you post the comment, then re-assign to Jason?
  84 17:18:19 <Garyo>	Jason imho.  Jason, when's your meeting with sk?
  85 17:18:38 <jason_at_intel>	aug 18-19
  86 17:19:10 <jason_at_intel>	I get there aug 17.. . I forget what time.
  87 17:19:16 <jason_at_intel>	leave early on saturday
  88 17:19:27 <Garyo>	Anyway we have plenty of time to discuss on the ML
  89 17:18:53 <Garyo>	ok
  90 17:18:57 <sgk>	ok
  91 17:19:01 <GregNoel>	done
  92 17:19:04 <GregNoel>	1450
  93 17:19:22 <jason_at_intel>	ya so this bug
  94 17:19:54 <Garyo>	1450: Jason, do you have anything that would actually break?
  95 17:19:56 <jason_at_intel>	My concern is that the fix seems tied to a given version of mslink
  96 17:20:13 <jason_at_intel>	what about other tools?
  97 17:20:23 <Garyo>	Yeah, it's a fair point -- newlines in a command line makes me nervous too, even if it works now
  98 17:20:38 <jason_at_intel>	I might be missing something.
  99 17:20:46 <jason_at_intel>	but i think more testing is needed
 100 17:21:02 <Garyo>	Could have two versions TEMPFILE and TEMPFILESPACES or something (yuck)
 101 17:21:06 <jason_at_intel>	I am under the view that minus link
 102 17:21:11 <jason_at_intel>	most tools would take a file in a different way
 103 17:21:09 <sgk>	good lord, a command line that actually blows out the temp file limit?  131K characters?
 104 17:21:34 <Garyo>	sgk: I think it blows out the line length limit, hence the newlines.
 105 17:21:54 <Garyo>	and yes, that's a big cmd line! :-/
 106 17:22:02 <jason_at_intel>	per line
 107 17:22:03 <sgk>	the CMD line length limit is already exceeded, that's why it's getting put in the temp file
 108 17:22:12 <sgk>	i'm trying to figure out if there are two limits at work here
 109 17:22:43 <sgk>	or at least, our notion of the CMD line length is exceeded
 110 17:23:01 <sgk>	(bus coming in ~1-2 minutes, i'll have an interrupt)
 111 17:23:12 <Garyo>	The ticket says it generates LNK1170, a linker error (not cmd.exe)
 112 17:23:35 <sgk>	good point
 113 17:23:46 <sgk>	it's the linker that interprets the @tmpfile thing
 114 17:23:57 <sgk>	gotta run, biab
 115 17:23:59 *	sgk has quit (Quit: sgk)
 116 17:24:02 <jason_at_intel>	the fix was to make a new line before that link limit was hit
 117 17:25:28 <Garyo>	yes -- the fix in the post is to just join all the elements with newlines...
 118 17:25:57 <Garyo>	I just googled it and even vs2010 has this limit (128k chars on a line) and the suggested workaround is the same, use newlines
 119 17:26:17 <jason_at_intel>	I believe the icl, cl and link tools handle input files in this format
 120 17:27:05 *	sgk (~sgk@67.218.107.184) has joined #SCONS
 121 17:27:16 <sgk>	hello again
 122 17:27:18 <GregNoel>	So what to do with the issue?  We've pretty much reached the discussion limit.
 123 17:27:19 <Garyo>	right.  Your point is that TEMPFILE could be used for other tools which might barf on newlines, right?
 124 17:27:31 <jason_at_intel>	yep
 125 17:27:47 <Garyo>	I think either (a) an arg to TEMPFILE for what spacer to use, or (b) two versions of TEMPFILE
 126 17:28:05 <jason_at_intel>	... I think it would be easy to tweak tempfile to workaround this however.. I think
 127 17:28:20 <sgk>	yeah, we can make TEMPFILE configurable in some way
 128 17:28:31 <Garyo>	that'd be my 1st choice.
 129 17:28:58 <jason_at_intel>	if we can pass in a separator value to be used to the $Tempfile call.. i do stuff like this in Parts with the mappers objects
 130 17:29:07 <GregNoel>	So what to do with the issue?  We've pretty much reached the discussion limit.
 131 17:29:23 <sgk>	jason 2.1 p3 ?
 132 17:29:28 <jason_at_intel>	Since I seem to be fixing it.. I can take a stab at it
 133 17:29:40 <Garyo>	Jason, if you'll investigate it that'd be awesome.
 134 17:29:46 <GregNoel>	done
 135 17:29:52 <GregNoel>	2281 I'll go with research sk; what priority?
 136 17:30:11 <sgk>	i think it's a corner case, so I'd suggest p4
 137 17:30:19 <Garyo>	fine w/ me
 138 17:30:24 <GregNoel>	done
 139 17:30:34 <GregNoel>	2285
 140 17:30:53 <sgk>	2.1 p4 sk
 141 17:31:09 <GregNoel>	done
 142 17:31:11 <GregNoel>	2380
 143 17:31:11 <Garyo>	I think it has to be -- only you understand that stuff
 144 17:31:19 <sgk>	yeah
 145 17:31:21 <sgk>	:-(
 146 17:31:44 <jason_at_intel>	I woudl want to talk to you about this as well when i visit
 147 17:31:54 <Garyo>	2380?  Is it controversial?
 148 17:31:55 <sgk>	2380:  2.1 p4 ...  who?
 149 17:32:05 <jason_at_intel>	I want Scons to handle symlink and hardlinks on windows
 150 17:32:19 <jason_at_intel>	I Have it working.. but it really needs fixes in SCons
 151 17:33:04 <jason_at_intel>	then there is permission issues on windows.. so link might have to copy
 152 17:33:20 <Garyo>	I could do it but not for 2.1.  If it's me, it'd be 2.2 p3 garyo
 153 17:33:58 <Garyo>	(2380, not symlinks on windows of course)
 154 17:34:03 <sgk>	since it's low priority, 2.x p3 and punt on assigning someone for now?
 155 17:34:46 <GregNoel>	Hearing no objection, done
 156 17:34:50 <Garyo>	ok
 157 17:34:49 <GregNoel>	1745
 158 17:35:09 <Garyo>	see my comment
 159 17:35:16 <jason_at_intel>	ya.. but the issue is related to the File.<api> that needs to replace all os.<fileapi> calls
 160 17:35:38 <jason_at_intel>	:-)
 161 17:35:38 <sgk>	we've been loading up jason
 162 17:35:39 <Garyo>	jason, I think 1745 can be fixed w/o any of that.
 163 17:35:54 <sgk>	i see bdbaddog's signed in, is bill here?
 164 17:35:59 <bdbaddog>	yes
 165 17:36:48 <sgk>	bill, any of these look up your alley?
 166 17:36:20 <jason_at_intel>	why i think making all files precious is better than deleting them by default
 167 17:37:08 <Garyo>	ok, but the minimal change for 1745 is just to make the .ilk file a side effect.
 168 17:37:25 <sgk>	ah
 169 17:37:25 <jason_at_intel>	so is there anyway we can modify the object builder on windows?
 170 17:37:29 <Garyo>	Making incremental links work should maybe be a separate ticket.
 171 17:37:29 <bdbaddog>	so mslink emitter work then right?
 172 17:37:31 <jason_at_intel>	I am not sure where that is
 173 17:37:53 <Garyo>	bdbaddog: seems like it to me
 174 17:37:54 <sgk>	agree w/garyo re: a separate ticket for incremental links
 175 17:38:11 <jason_at_intel>	so this bug directly, is just a addition to .ilk files
 176 17:38:16 <jason_at_intel>	as a sideeffect
 177 17:38:24 <jason_at_intel>	given that the flags support it
 178 17:38:31 <bdbaddog>	are the .ilk's always generated?
 179 17:38:45 <bdbaddog>	or do some ms flags enable/disable them?
 180 17:38:46 <jason_at_intel>	there is some flag to force no incremental build
 181 17:38:47 <Garyo>	unless /noincremental or something like that
 182 17:39:08 <Garyo>	but I think it's ok to declare a side effect that doesn't get generated
 183 17:39:12 <Garyo>	(right?)
 184 17:39:28 <sgk>	i think so
 185 17:39:38 <GregNoel>	I think so, too
 186 17:39:18 <bdbaddog>	o.k. I can take it then.
 187 17:39:27 <Garyo>	thanks!
 188 17:39:38 <bdbaddog>	if the scope is .ilk's get deleted with --clean afterwards.
 189 17:39:54 <Garyo>	agreed, minimal scope
 190 17:39:59 <sgk>	yeah, if it turns into something bigger than that, we should re-review it
 191 17:40:04 <GregNoel>	milestone and priority?
 192 17:40:19 <Garyo>	2.1 p4, imho
 193 17:41:35 <sgk>	sounds good, bdbaddog++
 194 17:40:23 <sgk>	the only pitfall i can think of is if non-existent side-effect files trigger unnecessary rebuilds
 195 17:40:29 <sgk>	i don't think they do, but i don't remember
 196 17:40:47 <bdbaddog>	sgk: 99% sure you're right
 197 17:40:50 <Garyo>	sgk: I'm pretty sure not.
 198 17:41:06 <GregNoel>	sgk, I'm pretty sure they don't; that's why Russel uses them in the LaTeX builder.
 199 17:40:45 <sgk>	we should set a target date for 2.1
 200 17:40:23 <bdbaddog>	when are we thinking 2.1 will be?
 201 17:40:50 <sgk>	discuss after the issues?
 202 17:41:39 <GregNoel>	milestone and priority?
 203 17:41:41 <Garyo>	roadmap says 2.1 rc sept, 2.1 final oct.
 204 17:42:04 <sgk>	1745:  2.1 p4 bdbaddog
 205 17:42:13 <GregNoel>	done
 206 17:42:18 <jason_at_intel>	ahh the option is /INCREMENTAL
 207 17:42:51 <sgk>	why'd they pick an obscure option like that to control incremental linking?  :-)
 208 17:42:16 <GregNoel>	2355
 209 17:43:12 <Garyo>	2355 clearly needs research.
 210 17:43:34 <jason_at_intel>	I agree
 211 17:44:49 <jason_at_intel>	worse case the builder can add a cd <dir> && before the command is the subprocess thing does not work
 212 17:44:03 <Garyo>	Greg, would you like to look into the subprocess thing?
 213 17:45:00 <GregNoel>	Er, no.  I already know chdir= doesn't affect the main process on a Real Operating System; the question is about lesser operating systems.
 214 17:45:24 <bdbaddog>	You mean like MacOS right...;)
 215 17:45:57 <jason_at_intel>	should be simple to test
 216 17:46:24 <Garyo>	Simple to test, a bit scary to implement I think
 217 17:46:27 <sgk>	heh
 218 17:45:21 <Garyo>	In any case it doesn't seem practical to get into 2.1.  How about aiming for 2.2?
 219 17:46:58 <GregNoel>	Well, we've always had converting to subprocess() as a goal, but not in 2.1 I don't believe.
 220 17:47:32 <bdbaddog>	GN: I agree.. 2.2
 221 17:47:33 <Garyo>	So maybe this will just fall out of that conversion?
 222 17:47:38 <Garyo>	That'd be great.
 223 17:47:40 <jason_at_intel>	it seem doing subprocess in SCons first then chdir seem to be the best order
 224 17:47:50 <Garyo>	Agreed.
 225 17:47:51 <bdbaddog>	JAI: +1
 226 17:48:19 <sgk>	GregNoel:  looks like it's ok on windows, the cwd= argument is passed to CreateProcess()
 227 17:48:49 <sgk>	yeah, subprocess first
 228 17:48:55 <bdbaddog>	+1
 229 17:48:59 <bdbaddog>	should we file a bug for that?
 230 17:49:11 <sgk>	if there isn't one already open, yes
 231 17:50:09 <bdbaddog>	1955 might be part of that..
 232 17:50:24 <Garyo>	was just looking at that one
 233 17:50:53 <GregNoel>	What to do with this issue?  We're running short on time.
 234 17:51:10 <bdbaddog>	2.2
 235 17:51:14 <Garyo>	2.2 (but after subprocess), p2, whoever does subprocess.
 236 17:51:14 <sgk>	2.2 sounds right
 237 17:51:19 <jason_at_intel>	Say it depend on SCons Subprocess work
 238 17:51:43 <sgk>	1955 is dup with others that deal with long lines
 239 17:51:53 <sgk>	so I'll open an issue for the subprocess work
 240 17:52:04 <sgk>	and then we make 2355 depends on that one
 241 17:52:14 <Garyo>	sgk: +1
 242 17:52:35 <GregNoel>	sgk, yes, but what for this issue? 2.2 p2?  Who owns it?
 243 17:52:01 <jason_at_intel>	I might be able to help with that as well
 244 17:52:09 <jason_at_intel>	as Parts does this in SCons...
 245 17:52:26 <sgk>	jason_at_intel:  cool, thanks
 246 17:52:35 <jason_at_intel>	not sure what is scons defines the default "SPAWN" function however.. so i have not made a patch to SCons
 247 17:53:05 <Garyo>	Greg: I recommend assigning to sgk for now, he can reassign later if desired.
 248 17:53:11 <bdbaddog>	+1
 249 17:53:12 <bdbaddog>	:)
 250 17:53:13 <sgk>	sounds good
 251 17:53:18 <jason_at_intel>	+1
 252 17:53:16 <GregNoel>	done
 253 17:53:18 <GregNoel>	That covers the issues@scons issues; on to the new issues.
 254 17:53:18 <GregNoel>	2649 I'll go with research sk; what priority?
 255 17:53:40 <Garyo>	p3
 256 17:54:06 <GregNoel>	sgk?  What say you?
 257 17:54:33 <sgk>	yes
 258 17:54:38 <GregNoel>	done
 259 17:54:41 <GregNoel>	2650 consensus review next time
 260 17:54:41 <GregNoel>	2657
 261 17:55:14 <Garyo>	2.1 p2 sk
 262 17:55:19 <jason_at_intel>	Glad i have not seen this on our 64-bit boxes yet
 263 17:55:26 <sgk>	consensus 2.1 p2 sk done
 264 17:55:29 <GregNoel>	done
 265 17:55:31 <GregNoel>	2660 consensus research sk; what priority?
 266 17:55:40 <sgk>	p3
 267 17:56:08 <GregNoel>	done
 268 17:56:14 <GregNoel>	2661 consensus 2.1 p2 Bill
 269 17:56:14 <GregNoel>	2662 OK, I'll take it as 2.2 p4
 270 17:56:14 <GregNoel>	2663 consensus 2.1 p3 Bill
 271 17:56:14 <GregNoel>	That appears to be it for the day...  Anything else?
 272 17:56:28 <Garyo>	nice work all, just under an hour
 273 17:56:32 <sgk>	oh, heh:  my comment about 2661 was "try to keep SCons reasonably current with VC tools"
 274 17:56:34 <bdbaddog>	1.3.1.. push out from last checkpoint?
 275 17:57:04 <sgk>	yes
 276 17:56:56 <Garyo>	bdbaddog: absolutely.  No complaints whatsoever that I've heard.
 277 17:57:49 <bdbaddog>	what about last 2.0.1 checkpoint? release as 2.0.1? rebranch to remove extra changes? other?
 278 17:58:49 <Garyo>	I think we should try not to be pedantic -- push out as 2.0.1 as is, let's get going on 2.1 work.
 279 17:59:15 <Garyo>	(?)
 280 17:59:21 <bdbaddog>	+1 from me.
 281 18:00:06 <sgk>	+1
 282 18:00:31 <jason_at_intel>	+1 for me... I think the patches added here make the first drop we can use at work without breaking anything
 283 18:01:49 <jason_at_intel>	( since 1.2)
 284 18:01:36 <bdbaddog>	K. then I'll try and roll out 1.3.1 and 2.0.1 this weekend.
 285 18:01:46 <Garyo>	yay bdbaddog!
 286 18:01:29 <sgk>	so 2.1 release candidate in september--shall we pick a week to target?
 287 18:01:56 <bdbaddog>	I'm on vaca the whole first week thereof.
 288 18:02:09 <bdbaddog>	so later in ssept would be better.
 289 18:02:42 <sgk>	hmm, looking at the roadmap, i realize my real question is, when do we want to start releasing pre-2.1 checkpoints?
 290 18:03:00 <sgk>	the roadmap suggests one in july and one in august
 291 18:03:14 <sgk>	i'm trying to give myself a tangible near-term deadline to get going on some of these things
 292 18:03:51 <Garyo>	Don't think we have enough in yet for one now.  Maybe end of July?
 293 18:03:17 <bdbaddog>	has trunk diverged from 2.0.1 much?
 294 18:03:57 <sgk>	not much yet, but I'm about to start making some big doc changes
 295 18:04:01 <Garyo>	I'll try to get a few more things done soon.
 296 18:04:12 <Garyo>	This weekend e.g.
 297 18:04:26 <sgk>	okay, ditto
 298 18:04:52 <bdbaddog>	so checkpoint 7/31?
 299 18:05:01 <Garyo>	Let's aim for that.
 300 18:05:05 <sgk>	sounds like a good stake in the ground
 301 18:05:07 <bdbaddog>	k.
 302 18:05:30 <sgk>	any other issues to cover?
 303 18:06:09 <sgk>	going once...
 304 18:06:10 <jason_at_intel>	not from me... I will send some questions tomorrow to get tempfile working
 305 18:06:11 <Garyo>	none here
 306 18:06:11 <bdbaddog>	nope.
 307 18:06:13 <sgk>	going twice...
 308 18:06:18 <sgk>	okay, sold
 309 18:06:24 <sgk>	thanks for the good work, everyone
 310 18:06:39 <GregNoel>	G'night all...
 311 18:06:40 <Garyo>	bye 4 now
 312 18:06:43 <bdbaddog>	gnight
 313 18:06:44 <sgk>	bye
 314 18:06:46 *	sgk (~sgk@67.218.107.184) has left #SCONS
 315 18:06:47 <jason_at_intel>	night!
 316 18:06:58 *	You have been marked as being away
 317 18:07:22 *	jason_at_intel has quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.6/20100625231939])
 318 21:23:49 *	Garyo has quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.7/20100713130626])
 319 23:42:18 *	bdbaddog has quit (Quit: Leaving.)
 320 

BugParty/IrcLog2010-07-20 (last edited 2010-07-22 00:49:38 by ip68-7-79-188)