From owner-freebsd-chat@FreeBSD.ORG Mon Apr 13 09:09:45 2009 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B5FC1065740 for ; Mon, 13 Apr 2009 09:09:42 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id 6E20F8FC18 for ; Mon, 13 Apr 2009 09:09:42 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: by fxm11 with SMTP id 11so1933332fxm.43 for ; Mon, 13 Apr 2009 02:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=xwzTMQL9D/zrC2yJWse/tE96MevpYdP4ExcNU3SzNac=; b=xniZAA5DDPk/VPLx0M5EmIf/bREGlAhQBsIh/EQKgb/rRed5uqulrpWZZkCCvb9/Dt rpqC4rIfTSr0uUr7uXd3EHCwJLVxPYzR/mFjG0ZPxioke5KNn9qDO8wrzsAQistXE/ZE f2R8p6N1dcQHK2NuDyGaj84WKSjauyKMfvI6o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=h6XycSohITyc72WEYiRUgUgbjZ7qYQzMjj7u4M93zLrvEJD0oCHUwD/C5+kOmT4tSA L/nVwPiFOPS2TSp3KlynY0bxCQxfb+2D9FtO9wxSHcZ9cxB8IMIQRRU0ZJ7KljTqD9kH p3cRQT0W+sjFluzFT1lmOefr5jwH+gw0j/NIM= Received: by 10.103.182.3 with SMTP id j3mr3190690mup.113.1239612312604; Mon, 13 Apr 2009 01:45:12 -0700 (PDT) Received: from ?157.181.96.136? (quark.teteny.elte.hu [157.181.96.136]) by mx.google.com with ESMTPS id 12sm9334199muq.35.2009.04.13.01.45.10 (version=SSLv3 cipher=RC4-MD5); Mon, 13 Apr 2009 01:45:11 -0700 (PDT) Message-ID: <49E2FBE2.8020305@gmail.com> Date: Mon, 13 Apr 2009 10:46:26 +0200 From: deeptech71@gmail.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 MultiZilla/1.8.3.4e SeaMonkey/1.1.15 MIME-Version: 1.0 To: freebsd-chat@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: My whitespace style (was: Why?? (prog question)) X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 09:09:46 -0000 Tabs are better, because they allow the programmer to specify the desired width, and is dynamically changable at any time. Width could be geared towards a purpose, for example: I've read somewhere that the linux kernel guide recommends 8 characters per tab, because the distance clearly separates levels, and warns the coder if statements are nested too deep. So a linux kernel programmer sets the tab with to 8, while another programmer with a small monitor prefers 4 to see code like "if(..) { if(..) { if(..) { if(..) { if(..) { if(..) { ...". This is all possible without text processing programs that convert indentation sizes required if the code were hard-indented with spaces. Tabs are to be considered non-constant in width. Specifically they should be used for and only for indentation. So here's my style. First, a display with a tab-size of 8. The arrows ("------->") denote tabs. struct datatype { ------->int field_one; // this is the ... ------->int field_two; // this contains ... -------> ------->long long int field_three; // and this one is used for ... ------->long long int field_four; // this one is useless }; void function( int x ) { ------->if( x > 1234567891011121314 ) { ------->------->do_something(); ------->------->do_something_else(); ------->} ------->else { ------->------->do_something_else(); ------->------->do_something(); ------->} -------> ------->assert( c89_is_outdated ); -------> ------->struct datatype data; -------> ------->while( check_me_first() && then_check_me() || -------> read(&data) && data.field_three > x ) ------->{ ------->------->do_something(); ------->------->x = x + 2*x + 4*x*x + 5*x*x*x + 5*x*x*x*x ------->-------> + x*x*x*x*x*x - 9*x*x*x*x*x*x*x; ------->} } The same code with 4 spaces per tab: struct datatype { --->int field_one; // this is the ... --->int field_two; // this contains ... ---> --->long long int field_three; // and this one is used for ... --->long long int field_four; // this one is useless }; void function( int x ) { --->if( x > 1234567891011121314 ) { --->--->do_something(); --->--->do_something_else(); --->} --->else { --->--->do_something_else(); --->--->do_something(); --->} ---> --->assert( c89_is_outdated ); ---> --->struct datatype data; ---> --->while( check_me_first() && then_check_me() || ---> read(&data) && data.field_three > x ) --->{ --->--->do_something(); --->--->x = x + 2*x + 4*x*x + 5*x*x*x + 5*x*x*x*x --->---> + x*x*x*x*x*x - 9*x*x*x*x*x*x*x; --->} } For every left curly brace, the indentation increases, as the number of tabs on a line. But take a look at the loop: It has level 1 nesting, but the condition is as long as 2 lines. The second line of the condition is indented properly by 1 tab, and is polished a bit by spaces. Finally, I find it more readable to put the left curly brace on a new line for such long conditions. I like the idea of writing appropriate amount of tabs for empty lines too, it could possibly make a diff output readable (note even the additional spaces in the empty line of the struct definition). Although I haven't used it in practice. On a side note, I use spaces inside the outermost parentheses, but not in the deeper ones. I rarely write "} else {" on one line. Everything else I can think of is based on opinion and good looks. Finally, another possible definition of the struct: struct datatype { ------->int field_one; ------->// this is the ... ------->int field_two; ------->// this contains ... -------> -------> ------->long long int field_three;------->// and this one is used for ... ------->long long int field_four; ------->// this one is useless }; Elastic tabstops look cool, they are just what I need. I'm open to critics. From owner-freebsd-chat@FreeBSD.ORG Mon Apr 13 14:35:54 2009 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 405B8106564A for ; Mon, 13 Apr 2009 14:35:54 +0000 (UTC) (envelope-from dkelly@Grumpy.DynDNS.org) Received: from smtp.knology.net (smtp.knology.net [24.214.63.101]) by mx1.freebsd.org (Postfix) with ESMTP id C23BD8FC19 for ; Mon, 13 Apr 2009 14:35:53 +0000 (UTC) (envelope-from dkelly@Grumpy.DynDNS.org) Received: (qmail 31204 invoked by uid 0); 13 Apr 2009 14:09:13 -0000 Received: from unknown (HELO Grumpy.DynDNS.org) (75.76.211.79) by smtp7.knology.net with SMTP; 13 Apr 2009 14:09:13 -0000 Received: by Grumpy.DynDNS.org (Postfix, from userid 928) id ECEE128429; Mon, 13 Apr 2009 09:09:12 -0500 (CDT) Date: Mon, 13 Apr 2009 09:09:12 -0500 From: David Kelly To: deeptech71@gmail.com Message-ID: <20090413140912.GC29833@Grumpy.DynDNS.org> References: <49E2FBE2.8020305@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49E2FBE2.8020305@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-chat@freebsd.org Subject: Re: My whitespace style (was: Why?? (prog question)) X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-chat@freebsd.org List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 14:35:54 -0000 On Mon, Apr 13, 2009 at 10:46:26AM +0200, deeptech71@gmail.com wrote: > Tabs are better, because they allow the programmer to specify the > desired width, and is dynamically changable at any time. Spaces are better because they let the author specify the formatting and not left to some other re-interpretation. Can put the following as the first line and vim will adjust its settings accordingly: // vim: smartindent cindent tabstop=4 shiftwidth=4 expandtab -- David Kelly N4HHE, dkelly@HiWAAY.net ======================================================================== Whom computers would destroy, they must first drive mad. From owner-freebsd-chat@FreeBSD.ORG Tue Apr 14 08:55:48 2009 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D58E1065670 for ; Tue, 14 Apr 2009 08:55:48 +0000 (UTC) (envelope-from dmlb@dmlb.org) Received: from dmlb.org (dmlb.org [82.138.252.10]) by mx1.freebsd.org (Postfix) with ESMTP id 100198FC1B for ; Tue, 14 Apr 2009 08:55:47 +0000 (UTC) (envelope-from dmlb@dmlb.org) Received: from host217-44-131-150.range217-44.btcentralplus.com ([217.44.131.150] helo=[192.168.1.108]) by dmlb.org with esmtpa (Exim 4.68 (FreeBSD)) (envelope-from ) id 1LteQj-000BcY-Ez; Tue, 14 Apr 2009 09:55:45 +0100 Message-ID: <49E44F92.90705@dmlb.org> Date: Tue, 14 Apr 2009 09:55:46 +0100 From: Duncan Barclay User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Chuck Robey References: <49DD0DD2.8080806@telenix.org> <20090409085601.b54eb5y31ckwcwww@0x20.net> <49DDB2DA.9090409@unsane.co.uk> <49DE2449.8050007@telenix.org> <49DE5489.5060201@dmlb.org> <86r600uxrr.fsf@ds4.des.no> <49E0E4A7.6020406@telenix.org> In-Reply-To: <49E0E4A7.6020406@telenix.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= , Vincent Hoffman , freebsd-chat@freebsd.org, Lars Engels Subject: Re: do we have support for the Beagle Board? X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 08:55:48 -0000 Chuck Robey wrote: > > According to what I thought I read, the arm7 has changes from the arm5 it's > derived from. Supposed to me 2-3 times more code-efficient? I hope I learn > more before I get my toy. > > Do you have any idea what the FP environment is? softfp? > > It's a hardware FP implementation. IEEE 754 standard. Duncan From owner-freebsd-chat@FreeBSD.ORG Tue Apr 14 23:23:27 2009 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D03C3106564A for ; Tue, 14 Apr 2009 23:23:27 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 5FD468FC0A for ; Tue, 14 Apr 2009 23:23:27 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: by ewy19 with SMTP id 19so2788625ewy.43 for ; Tue, 14 Apr 2009 16:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ToKWOlqhWuetGT7l6ClDtBXvUzc7d5vBmZipS7YFDQY=; b=NB+TkR7hj1WYpNkQvOdrG848bdrfWRCGwPMQpLMIu8qEilHvgTpljP0IB6XxIJfiGD QBUZMTGZTf0QGvtRPaIAT8FRaMgBAY+OnpbZwMHmSaM5G67KzxXt1HoUWqxe36jRyIgn 6s+VgLfaktxlO4hbeh4HaXTLJcAoKF9NFSYps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=w37GOlHAkoaGxoh78f6nkXPaK3rHG5Ru4cszyHbyFf7RIP3cOZDZH+2ZXy871GW43S q+Z7C3cWE2kAy2RE6dyWSbbJZgMuk98X0jIQ4SeLfqj23mrxY+W70pErL2Blqkeocehx lW+ieH3JnW89th6nCkvaEXBuRt83k7Yy37ax8= Received: by 10.216.30.71 with SMTP id j49mr1902496wea.89.1239751406129; Tue, 14 Apr 2009 16:23:26 -0700 (PDT) Received: from ?157.181.96.136? (quark.teteny.elte.hu [157.181.96.136]) by mx.google.com with ESMTPS id g11sm17163152gve.5.2009.04.14.16.23.25 (version=SSLv3 cipher=RC4-MD5); Tue, 14 Apr 2009 16:23:25 -0700 (PDT) Message-ID: <49E51B42.2060405@gmail.com> Date: Wed, 15 Apr 2009 01:24:50 +0200 From: deeptech71@gmail.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 MIME-Version: 1.0 To: freebsd-chat@freebsd.org References: <49E2FBE2.8020305@gmail.com> <20090413140912.GC29833@Grumpy.DynDNS.org> In-Reply-To: <20090413140912.GC29833@Grumpy.DynDNS.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: My whitespace style X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 23:23:28 -0000 David Kelly wrote: > On Mon, Apr 13, 2009 at 10:46:26AM +0200, deeptech71@gmail.com wrote: >> Tabs are better, because they allow the programmer to specify the >> desired width, and is dynamically changable at any time. > > Spaces are better because they let the author specify the formatting and > not left to some other re-interpretation. And indeed they should used where formatting is important. However, C/C++ indentation is not of this nature. From owner-freebsd-chat@FreeBSD.ORG Wed Apr 15 01:02:03 2009 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8274C10656CA for ; Wed, 15 Apr 2009 01:02:03 +0000 (UTC) (envelope-from dkelly@hiwaay.net) Received: from bee.hiwaay.net (bee.hiwaay.net [216.180.54.11]) by mx1.freebsd.org (Postfix) with ESMTP id 4A0288FC1F for ; Wed, 15 Apr 2009 01:02:03 +0000 (UTC) (envelope-from dkelly@hiwaay.net) Received: from [10.0.0.183] (dynamic-75-76-211-79.knology.net [75.76.211.79] (may be forged)) (authenticated bits=0) by bee.hiwaay.net (8.13.8/8.13.8) with ESMTP id n3F0nCBH1177715 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 14 Apr 2009 19:49:13 -0500 (CDT) From: David Kelly To: deeptech71@gmail.com In-Reply-To: <49E51B42.2060405@gmail.com> References: <49E2FBE2.8020305@gmail.com> <20090413140912.GC29833@Grumpy.DynDNS.org> <49E51B42.2060405@gmail.com> Message-Id: <320BA0A7-C5E0-40E5-97F9-F19BF1C61B29@hiwaay.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Apr 2009 19:49:11 -0500 X-Mailer: Apple Mail (2.930.3) Cc: freebsd-chat@freebsd.org Subject: Re: My whitespace style X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-chat@freebsd.org List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 01:02:04 -0000 On Apr 14, 2009, at 6:24 PM, deeptech71@gmail.com wrote: > David Kelly wrote: >> On Mon, Apr 13, 2009 at 10:46:26AM +0200, deeptech71@gmail.com wrote: >>> Tabs are better, because they allow the programmer to specify the >>> desired width, and is dynamically changable at any time. >> Spaces are better because they let the author specify the >> formatting and >> not left to some other re-interpretation. > > And indeed they should used where formatting is important. However, > C/C++ indentation is not of this nature. It is if you want your comments to stay lined up, and code remain readable. There are many sections of code I write C in *columns*, especially when making repetitive calls to the same function with different arguments. I make the arguments line up in a column. printf() is a common example, that I want the arguments to line up no matter it has no effect on the output. I indent for readability and the result almost never survives variable tab interpretation. If I write the code and indent 3 or 4 or 8 spaces then by golly thats the way it should remain. If there is a project format spec then it should be written in .indent.pro and I will use it and make sure my code is readable after a pass through indent(1). This notion of tabs as a flexible indent is flawed. -- David Kelly N4HHE, dkelly@HiWAAY.net ======================================================================== Whom computers would destroy, they must first drive mad. From owner-freebsd-chat@FreeBSD.ORG Wed Apr 15 04:46:53 2009 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 779F2106564A for ; Wed, 15 Apr 2009 04:46:53 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id CCF3A8FC16 for ; Wed, 15 Apr 2009 04:46:52 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: by fxm11 with SMTP id 11so2758429fxm.43 for ; Tue, 14 Apr 2009 21:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=GeNgCB5yIvGV1/x8WwRYhkbJTyfB6/JucBjw7/lMZCM=; b=uyCY/UurJsluIiZ5BC/ViY5skEuHirejAqwOc+ezxMThN7/Iv2gsgHFI6DO5jfaR5c ELxHLO631hceNGE/iiSs3kUh7bjFPCne0es/ztPHFaCDINXhLTnIyJDGA+lMSORTWVcp wC9Tcw/53f+8cDBxVvzUipdlNHZDHukaUuuAI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=YY4yvOINOSSBjbjdyayFJ9LDoHN0UgcbY3MWCxIXLMQGqIHkKeV0b6KN+WYwnfb1s7 8MA+zN4xYSJsdL63+LZJ27vgg2Nzvv732fq9iT9ZCFrqjDkJHixtjhfDuOhDDJkqSiTu vtbFTLeHzzB42Y16BVM26sDWmLDTLuN/O5I94= Received: by 10.204.119.71 with SMTP id y7mr7671556bkq.16.1239770811843; Tue, 14 Apr 2009 21:46:51 -0700 (PDT) Received: from ?157.181.96.136? (quark.teteny.elte.hu [157.181.96.136]) by mx.google.com with ESMTPS id d13sm7701077fka.0.2009.04.14.21.46.50 (version=SSLv3 cipher=RC4-MD5); Tue, 14 Apr 2009 21:46:51 -0700 (PDT) Message-ID: <49E5670C.8070708@gmail.com> Date: Wed, 15 Apr 2009 06:48:12 +0200 From: deeptech71@gmail.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 MIME-Version: 1.0 To: freebsd-chat@freebsd.org References: <49E2FBE2.8020305@gmail.com> <20090413140912.GC29833@Grumpy.DynDNS.org> <49E51B42.2060405@gmail.com> <320BA0A7-C5E0-40E5-97F9-F19BF1C61B29@hiwaay.net> In-Reply-To: <320BA0A7-C5E0-40E5-97F9-F19BF1C61B29@hiwaay.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: My whitespace style X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 04:46:53 -0000 David Kelly wrote: > > On Apr 14, 2009, at 6:24 PM, deeptech71@gmail.com wrote: > >> David Kelly wrote: >>> On Mon, Apr 13, 2009 at 10:46:26AM +0200, deeptech71@gmail.com wrote: >>>> Tabs are better, because they allow the programmer to specify the >>>> desired width, and is dynamically changable at any time. >>> Spaces are better because they let the author specify the formatting and >>> not left to some other re-interpretation. >> >> And indeed they should used where formatting is important. However, >> C/C++ indentation is not of this nature. > > > It is if you want your comments to stay lined up, and code remain readable. I don't want to make my comments stay lined up, and code still remains reabable. > There are many sections of code I write C in *columns*, especially when > making repetitive calls to the same function with different arguments. I > make the arguments line up in a column. printf() is a common example, > that I want the arguments to line up no matter it has no effect on the > output. I indent for readability and the result almost never survives > variable tab interpretation. Could you please give me a (preferrably widely used) example of columnizing calls which cross different levels of indentation? From owner-freebsd-chat@FreeBSD.ORG Wed Apr 15 07:40:18 2009 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CFF710657F3 for ; Wed, 15 Apr 2009 07:40:18 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id E92EA8FC1A for ; Wed, 15 Apr 2009 07:40:07 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id AD835EB58C2; Wed, 15 Apr 2009 10:20:09 +0300 (EEST) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 7088B4509B; Wed, 15 Apr 2009 10:20:09 +0300 (EEST) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUXjlsrpGrng; Wed, 15 Apr 2009 10:20:09 +0300 (EEST) Received: from kobe.laptop (adsl167-129.kln.forthnet.gr [62.1.146.129]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 3D6E445088; Wed, 15 Apr 2009 10:20:09 +0300 (EEST) Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n3F7K81x027741; Wed, 15 Apr 2009 10:20:08 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n3F7K8b1027740; Wed, 15 Apr 2009 10:20:08 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: deeptech71@gmail.com References: <49E2FBE2.8020305@gmail.com> <20090413140912.GC29833@Grumpy.DynDNS.org> <49E51B42.2060405@gmail.com> <320BA0A7-C5E0-40E5-97F9-F19BF1C61B29@hiwaay.net> <49E5670C.8070708@gmail.com> Date: Wed, 15 Apr 2009 10:20:08 +0300 In-Reply-To: <49E5670C.8070708@gmail.com> (deeptech's message of "Wed, 15 Apr 2009 06:48:12 +0200") Message-ID: <87bpqytmc7.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-chat@freebsd.org Subject: Re: My whitespace style X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 07:40:20 -0000 On Wed, 15 Apr 2009 06:48:12 +0200, deeptech71@gmail.com wrote: > Could you please give me a (preferrably widely used) example of > columnizing calls which cross different levels of indentation? It's not so uncommon as it may initially seem... I've seen switch() cases in several programs indented like this: switch (value) { case SOME_CONSTANT_NAME: do_stuff_here(); break; case ANOTHER_CONSTANT_NAME: do_some_other_stuff(); break; default: default_stuff(); break; } I find this style horrible to read, but it does come with its own variation of TAB- and space-related issues and it is apparently attractive to a lot of people. Composite structure initializations also use a style similar to this, and will almost invariably end up looking horrendously misformatted when TAB sizes are 'elastic', i.e.: struct foo { long magic; const char *name; struct { int curr; int next; } nested; }; const struct foo statetab[] = { { 1, "one", { 1, 2}, }, { 1, "one", { 2, 2}, }, { 1, "one", { 3, 1}, }, { 1, "one", {65535, 1}, }, { 2, "two", { 1, 1}, }, { 2, "two", { 2, 2}, }, { 2, "two", { 3, 65535}, }, { 2, "two", {65535, 1}, }, ... { 65535, "invalid", { 1, 1}, }, { 65535, "invalid", { 2, 1}, }, { 65535, "invalid", { 3, 1}, }, { 65535, "invalid", {65535, 1}, }, }; This sort of alignment tends to generate *lots* of diff output when the alignment of a column changes, but it is often used for state transition tables of automata, and similar constructs. From owner-freebsd-chat@FreeBSD.ORG Wed Apr 15 14:56:08 2009 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 491071065676 for ; Wed, 15 Apr 2009 14:56:08 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from thyme.infocus-llc.com (server.infocus-llc.com [206.156.254.44]) by mx1.freebsd.org (Postfix) with ESMTP id 1BD018FC13 for ; Wed, 15 Apr 2009 14:56:07 +0000 (UTC) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (c-75-64-197-185.hsd1.ms.comcast.net [75.64.197.185]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by thyme.infocus-llc.com (Postfix) with ESMTPSA id 9A11937B5BD; Wed, 15 Apr 2009 09:56:06 -0500 (CDT) Received: by draco.over-yonder.net (Postfix, from userid 100) id B5BE761C45; Wed, 15 Apr 2009 09:56:05 -0500 (CDT) Date: Wed, 15 Apr 2009 09:56:05 -0500 From: "Matthew D. Fuller" To: Giorgos Keramidas Message-ID: <20090415145605.GO40689@over-yonder.net> References: <49E2FBE2.8020305@gmail.com> <20090413140912.GC29833@Grumpy.DynDNS.org> <49E51B42.2060405@gmail.com> <320BA0A7-C5E0-40E5-97F9-F19BF1C61B29@hiwaay.net> <49E5670C.8070708@gmail.com> <87bpqytmc7.fsf@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87bpqytmc7.fsf@kobe.laptop> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.19-fullermd.4 (2009-01-05) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on thyme.infocus-llc.com X-Virus-Status: Clean Cc: freebsd-chat@freebsd.org Subject: Re: My whitespace style X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 14:56:08 -0000 On Wed, Apr 15, 2009 at 10:20:08AM +0300 I heard the voice of Giorgos Keramidas, and lo! it spake thus: > > switch (value) { > case SOME_CONSTANT_NAME: do_stuff_here(); break; > case ANOTHER_CONSTANT_NAME: do_some_other_stuff(); break; > default: default_stuff(); break; > } ^^^^^^^^^ ^^^^^^^^^ This is This is indentation alignment > Composite structure initializations also use a style similar to > this, and will almost invariably end up looking horrendously > misformatted when TAB sizes are 'elastic', i.e.: Only if you abuse tabs for alignment. Indentation is not alignment. It's a pity that the two get conflated and everybody ends up treating them the same, so that advocating tab indentation is read as advocating tab alignment (even by proponents of tab indentation). -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-chat@FreeBSD.ORG Wed Apr 15 15:43:28 2009 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8BE4106566C for ; Wed, 15 Apr 2009 15:43:28 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id 20A828FC15 for ; Wed, 15 Apr 2009 15:43:28 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id 4CB3FEB5A7D; Wed, 15 Apr 2009 18:13:57 +0300 (EEST) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 3EC68450C6; Wed, 15 Apr 2009 18:13:57 +0300 (EEST) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeHdHnUBYvH1; Wed, 15 Apr 2009 18:13:57 +0300 (EEST) Received: from kobe.laptop (adsl167-129.kln.forthnet.gr [62.1.146.129]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 0F9AE4503F; Wed, 15 Apr 2009 18:13:57 +0300 (EEST) Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n3FFDuvC022243; Wed, 15 Apr 2009 18:13:56 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n3FFDsaK022235; Wed, 15 Apr 2009 18:13:54 +0300 (EEST) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: "Matthew D. Fuller" References: <49E2FBE2.8020305@gmail.com> <20090413140912.GC29833@Grumpy.DynDNS.org> <49E51B42.2060405@gmail.com> <320BA0A7-C5E0-40E5-97F9-F19BF1C61B29@hiwaay.net> <49E5670C.8070708@gmail.com> <87bpqytmc7.fsf@kobe.laptop> <20090415145605.GO40689@over-yonder.net> Date: Wed, 15 Apr 2009 18:13:54 +0300 In-Reply-To: <20090415145605.GO40689@over-yonder.net> (Matthew D. Fuller's message of "Wed, 15 Apr 2009 09:56:05 -0500") Message-ID: <87zleiar0t.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-chat@freebsd.org Subject: Re: My whitespace style X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 15:43:29 -0000 On Wed, 15 Apr 2009 09:56:05 -0500, "Matthew D. Fuller" wrote: > On Wed, Apr 15, 2009 at 10:20:08AM +0300 I heard the voice of > Giorgos Keramidas, and lo! it spake thus: >> >> switch (value) { >> case SOME_CONSTANT_NAME: do_stuff_here(); break; >> case ANOTHER_CONSTANT_NAME: do_some_other_stuff(); break; >> default: default_stuff(); break; >> } > > ^^^^^^^^^ ^^^^^^^^^ > This is This is > indentation alignment > > >> Composite structure initializations also use a style similar to >> this, and will almost invariably end up looking horrendously >> misformatted when TAB sizes are 'elastic', i.e.: > > Only if you abuse tabs for alignment. Indentation is not alignment. > It's a pity that the two get conflated and everybody ends up treating > them the same, so that advocating tab indentation is read as > advocating tab alignment (even by proponents of tab indentation). True :) Most of the stuff I see aligned this way falls in one of two styles: a) Code that uses spaces both for indentation and alignment. b) Code that uses TABs only for both. The second sort of code is the one that ends up looking terrible when someone configures their editor to use a non-standard TAB size :) From owner-freebsd-chat@FreeBSD.ORG Thu Apr 16 03:57:19 2009 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B4B41065672 for ; Thu, 16 Apr 2009 03:57:19 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id 735208FC12 for ; Thu, 16 Apr 2009 03:57:18 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: by bwz8 with SMTP id 8so202533bwz.43 for ; Wed, 15 Apr 2009 20:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=EwCdsqxS3iulkwdZPvLtKU85en+9v3Cb6m/9wIe8Uek=; b=LBX8fKfVBWquDp4JQdzwM8k7Owqte4Gh58OsC/IVVaSkwsXb7bkk1uorHM8t/b/TOl DGjz9R+3EzQed9gsV7X3DeTN6F2ZYdJMoBsKPTgp7gO39ATg02pGW7Rqbk7qeoPj7D3n EFir7jaX6CwdK3R+0f1pXwoy9euEm7ttpGpDE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=LTFyW+TqfU/CAHOXi9Sb5+wijSy+2Khb31gK1yHmnwv5WU7SKZTyIHvNGzlJHqVGW+ fp3FIw8Tr77MjeDiP4YdiLgj8skAj+HCZtoz/+63MPFkFJzfIuA9SL6dLjF7XVoickhM kti7JGLPspk9W+vmJGafGqirPi9fWAR7DYIg8= Received: by 10.204.54.65 with SMTP id p1mr817972bkg.195.1239854237255; Wed, 15 Apr 2009 20:57:17 -0700 (PDT) Received: from ?157.181.96.136? (quark.teteny.elte.hu [157.181.96.136]) by mx.google.com with ESMTPS id 13sm768992fks.14.2009.04.15.20.57.16 (version=SSLv3 cipher=RC4-MD5); Wed, 15 Apr 2009 20:57:16 -0700 (PDT) Message-ID: <49E6ACEE.6080301@gmail.com> Date: Thu, 16 Apr 2009 05:58:38 +0200 From: deeptech71@gmail.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 MultiZilla/1.8.3.4e SeaMonkey/1.1.15 MIME-Version: 1.0 To: freebsd-chat@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 03:57:19 -0000 I can reliably (~40%) reproduce a freeze, which I think is related. Using the GENERIC debug kernel built from SVN HEAD: # cd /usr/obj/usr/src/sys/GENERIC/ # kgdb kernel.debug /var/crash/vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: <118>Apr 16 04:22:24 syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Wai tSiynngc i(nmga xd is6k0s ,s evcnoonddess) rfeomra isnyisntge.m. .pr0o cess `syncer' to stop...0 done All buffers synced. Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0 r191101: Wed Apr 15 17:29:58 UTC 2009 devhc@:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2798.67-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Features2=0x4400 Logical CPUs per core: 2 real memory = 536870912 (512 MB) avail memory = 506023936 (482 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 1fef0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xd000-0xd0ff mem 0xd0000000-0xdfffffff,0xfbee0000-0xfbeeffff irq 16 at device 0.0 on pci1 vgapci1: mem 0xe0000000-0xefffffff,0xfbef0000-0xfbefffff at device 0.1 on pci1 uhci0: port 0xc880-0xc89f irq 16 at device 29.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x2030 usbus0: on uhci0 uhci1: port 0xcc00-0xcc1f irq 19 at device 29.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x2030 usbus1: on uhci1 ehci0: mem 0xfbdffc00-0xfbdfffff irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 pcib2: at device 30.0 on pci0 pci2: on pcib2 skc0: <3Com 3C940 Gigabit Ethernet> port 0xe800-0xe8ff mem 0xfbffc000-0xfbffffff irq 22 at device 5.0 on pci2 skc0: 3Com Gigabit LOM (3C940) rev. (0x1) sk0: on skc0 sk0: Ethernet address: 00:0e:a6:35:15:91 miibus0: on sk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto skc0: [ITHREAD] pcm0: port 0xec00-0xec3f irq 20 at device 12.0 on pci2 pcm0: pcm0: [ITHREAD] pcm0: isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 cpu0: on acpi0 p4tcc0: on cpu0 cpu1: on acpi0 p4tcc1: on cpu1 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xccfff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 ad0: 78167MB at ata0-master UDMA100 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 acd0: DMA limited to UDMA33, controller found non-ATA66 cable GEOM: ad0s1: geometry does not match label (255h,63s != 16h,63s). acd0: DVDR at ata1-master UDMA33 SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. GEOM_LABEL: Label for provider ad0s2 is msdosfs/WINXP. GEOM_LABEL: Label for provider ad0s3 is ntfs/STORAGE. GEOM_LABEL: Label for provider ad0s1a is ufsid/49cf0dead38cbdfd. Root mount waiting for: usbus2 usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered Root mount waiting for: usbus2 uhub2: 4 ports with 4 removable, self powered Root mount waiting for: usbus2 Trying to mount root from ufs:/dev/ad0s1a <118>Entropy harvesting: <118> interrupts <118> ethernet <118> point_to_point <118> kickstart <118>. GEOM_LABEL: Label ufsid/49cf0dead38cbdfd removed. <118>/dev/ad0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS <118>/dev/ad0s1a: clean, 576271 free (53999 frags, 65284 blocks, 1.3% fragmentation) GEOM_LABEL: Label for provider ad0s1a is ufsid/49cf0dead38cbdfd. ugen0.2: at usbus0 GEOM_LABEL: Label ufsid/49cf0dead38cbdfd removed. ums0: on usbus0 ums0: 5 buttons and [XYZ] coordinates ID=1 GEOM_LABEL: Label msdosfs/WINXP removed. <118>/etc/rc: WARNING: $hostname is not set -- see rc.conf(5). <118>Starting Network: sk0. <118>Starting Network: lo0. <118>Apr 16 04:23:08 syslogd: bind: Can't assign requested address <118>Apr 16 04:23:08 syslogd: bind: Can't assign requested address <118>syslogd: <118>child pid 546 exited with return code 1 <118> <118>/etc/rc: WARNING: failed to start syslogd <118>moused: <118>unable to open /dev/psm0: No such file or directory <118> <118>/etc/rc: WARNING: $dbus_enable is not set properly - see rc.conf(5). <118>Starting dbus. <118>Starting hald. <118>Configuring syscons: <118> blanktime <118>. <118> <118>Thu Apr 16 04:23:10 UTC 2009 drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xf0000000 128MB info: [drm] Initialized radeon 1.29.0 20080528 info: [drm] Setting GART location based on new memory map info: [drm] Loading R300 Microcode info: [drm] Num pipes: 1 info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] lock order reversal: 1st 0xc31a5270 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2549 2nd 0xc39a3400 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:275 KDB: stack backtrace: db_trace_self_wrapper(c0c2ebcc,d644b860,c0896895,c088879b,c0c319b1,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c088879b,c0c319b1,c3524a80,c3527e18,d644b8bc,...) at kdb_backtrace+0x29 _witness_debugger(c0c319b1,c39a3400,c0c50e61,c3527e18,c0c50afa,...) at _witness_debugger+0x25 witness_checkorder(c39a3400,9,c0c50afa,113,0,...) at witness_checkorder+0x839 _sx_xlock(c39a3400,0,c0c50afa,113,c3b4c7c0,...) at _sx_xlock+0x85 ufsdirhash_acquire(c31a5210,d644b9d4,128,cec0baf0,d644b98c,...) at ufsdirhash_acquire+0x35 ufsdirhash_add(c3b4c7c0,d644b9d4,af0,d644b978,d644b97c,...) at ufsdirhash_add+0x13 ufs_direnter(c3b5ca78,c3df4860,d644b9d4,d644bbe0,0,...) at ufs_direnter+0x729 ufs_makeinode(d644bbe0,d644bb4c,d644bc04,d644bb1c,c0b70e35,...) at ufs_makeinode+0x519 ufs_create(d644bc04,d644bc18,0,d644bb4c,d644bbb4,...) at ufs_create+0x30 VOP_CREATE_APV(c0d2fc20,d644bc04,68,1a4,c39a1aac,...) at VOP_CREATE_APV+0xa5 uipc_bind(c3dc3000,c3741b00,c3c80230,d644bc60,c08c0049,...) at uipc_bind+0x30e sobind(c3dc3000,c3741b00,c3c80230,1a,c38d5658,...) at sobind+0x23 kern_bind(c3c80230,3,c3741b00,c3741b00,80906a4,...) at kern_bind+0x79 bind(c3c80230,d644bcf8,c,c0c321f2,c0d0ed20,...) at bind+0x46 syscall(d644bd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (104, FreeBSD ELF32, bind), eip = 0x2818a983, esp = 0xbfbfe96c, ebp = 0xbfbfea68 --- <118>Apr 16 04:24:28 su: devhc to root on /dev/pts/1 Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex drmdev (drmdev) r = 0 (0xc373f860) locked @ /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:777 KDB: stack backtrace: db_trace_self_wrapper(c0c2ebcc,d67d4980,c0896895,c3d40457,309,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c3d40457,309,ffffffff,c0eba8c4,d67d49b8,...) at kdb_backtrace+0x29 _witness_debugger(c0c30f5d,d67d49cc,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0c62807,0,c42087ec,...) at witness_warn+0x1fd trap(d67d4a58) at trap+0x152 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc0b611b6, esp = 0xd67d4a98, ebp = 0xd67d4b48 --- slow_copyin(c373f800,c4103300,c42e64e0,d67d4b64,0,...) at slow_copyin+0x6 radeon_cp_texture(c373f800,c42e64e0,c4103300,309,c0c26218,...) at radeon_cp_texture+0x199 drm_ioctl(c39d4e00,c018644e,c42e64e0,3,c40afaf0,...) at drm_ioctl+0x356 devfs_ioctl_f(c38c7150,c018644e,c42e64e0,c38d4700,c40afaf0,...) at devfs_ioctl_f+0xf8 kern_ioctl(c40afaf0,24,c018644e,c42e64e0,18901f0,...) at kern_ioctl+0x1dd ioctl(c40afaf0,d67d4cf8,c,c0c65279,c0d0e870,...) at ioctl+0x134 syscall(d67d4d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x2834ec67, esp = 0xbfbf944c, ebp = 0xbfbf9468 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x3f561000 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0b611b6 stack pointer = 0x28:0xd67d4a98 frame pointer = 0x28:0xd67d4b48 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1094 (initial thread) trap number = 12 panic: page fault cpuid = 0 Uptime: 4m53s Physical memory: 494 MB Dumping 107 MB: 92 76 60 44 28 12 Reading symbols from /boot/kernel.GENERIC.r191101.debug/snd_es137x.ko...Reading symbols from /boot/kernel.GENERIC.r191101.debug/snd_es137x.ko.symbols...done. done. Loaded symbols for /boot/kernel.GENERIC.r191101.debug/snd_es137x.ko Reading symbols from /boot/kernel.GENERIC.r191101.debug/sound.ko...Reading symbols from /boot/kernel.GENERIC.r191101.debug/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel.GENERIC.r191101.debug/sound.ko Reading symbols from /boot/kernel.GENERIC.r191101.debug/radeon.ko...Reading symbols from /boot/kernel.GENERIC.r191101.debug/radeon.ko.symbols...done. done. Loaded symbols for /boot/kernel.GENERIC.r191101.debug/radeon.ko Reading symbols from /boot/kernel.GENERIC.r191101.debug/drm.ko...Reading symbols from /boot/kernel.GENERIC.r191101.debug/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel.GENERIC.r191101.debug/drm.ko #0 doadump () at pcpu.h:246 246 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:246 #1 0xc085712e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:420 #2 0xc0857402 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:576 #3 0xc0b63323 in trap_fatal (frame=0xd67d4a58, eva=1062604800) at /usr/src/sys/i386/i386/trap.c:926 #4 0xc0b63c20 in trap (frame=0xd67d4a58) at /usr/src/sys/i386/i386/trap.c:318 #5 0xc0b47b5b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #6 0xc0b611b6 in slow_copyin () at /usr/src/sys/i386/i386/support.s:887 Previous frame inner to this frame (corrupt stack?) (kgdb) list *0xc0b611b6 0xc0b611b6 is at /usr/src/sys/i386/i386/support.s:888. 883 slow_copyin: 884 #endif 885 movb %cl,%al 886 shrl $2,%ecx /* copy longword-wise */ 887 cld 888 rep 889 movsl 890 movb %al,%cl 891 andb $3,%cl /* copy remaining bytes*/ 892 rep (kgdb) OMG, ASM! I don't what this assembly code means or how to debug it. So what now? I can run commands on request. Or should I package the whole vmcore & kernel and upload/send it somewhere for inspection (tell me exactly which files)? 3 more things: The command ddb capture -M /var/crash/vmcore.0 print printed only a few ugly characters. This kernel output really looks bad: Wai tSiynngc i(nmga xd is6k0s ,s evcnoonddess) rfeomra isnyisntge.m. .pr0o cess `syncer' to stop...0 done What's the explanation to: Previous frame inner to this frame (corrupt stack?) ? From owner-freebsd-chat@FreeBSD.ORG Thu Apr 16 12:48:11 2009 Return-Path: Delivered-To: freebsd-chat@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6499210656C6 for ; Thu, 16 Apr 2009 12:48:11 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2D7FF8FC1F for ; Thu, 16 Apr 2009 12:48:08 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id n3GClgXd017317; Thu, 16 Apr 2009 14:48:06 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id n3GClfAl017316; Thu, 16 Apr 2009 14:47:41 +0200 (CEST) (envelope-from olli) Date: Thu, 16 Apr 2009 14:47:41 +0200 (CEST) Message-Id: <200904161247.n3GClfAl017316@lurza.secnetix.de> From: Oliver Fromme To: freebsd-chat@FreeBSD.ORG, fullermd@over-yonder.net, Giorgos Keramidas In-Reply-To: <20090415145605.GO40689@over-yonder.net> X-Newsgroups: list.freebsd-chat User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 16 Apr 2009 14:48:06 +0200 (CEST) Cc: Subject: Re: My whitespace style X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-chat@FreeBSD.ORG, fullermd@over-yonder.net, Giorgos Keramidas List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 12:48:12 -0000 Matthew D. Fuller wrote: > On Wed, Apr 15, 2009 at 10:20:08AM +0300 I heard the voice of > Giorgos Keramidas, and lo! it spake thus: > > > > switch (value) { > > case SOME_CONSTANT_NAME: do_stuff_here(); break; > > case ANOTHER_CONSTANT_NAME: do_some_other_stuff(); break; > > default: default_stuff(); break; > > } > > ^^^^^^^^^ ^^^^^^^^^ > This is This is > indentation alignment > > > > Composite structure initializations also use a style similar to > > this, and will almost invariably end up looking horrendously > > misformatted when TAB sizes are 'elastic', i.e.: > > Only if you abuse tabs for alignment. Indentation is not alignment. > It's a pity that the two get conflated and everybody ends up treating > them the same, so that advocating tab indentation is read as > advocating tab alignment (even by proponents of tab indentation). The problem is that many (most? all?) editors cannot easily be configured to differentiate between them, i.e. insert literal ASCII tabs characters when the key is pressed for indentation, and insert ASCII spaces when the key is pressed for alignment. *And* treat the alignment spaces transparently like tabs, just like the indentation spaces. That's probably not easy to implement, and it gets really messy when you edit the line, remove or insert stuff between the alignment spaces and the indetation tabs and so on. Then suddenly alignment can become indentation, and vice versa. The editor would then have to transparently convert existing ASCII tab characters to spaces or vice versa. This is a huge can of worms. That's another good reason to let the old ASCII tab die and rest in peace (or "lost in space" ... ok, bad pun). Best regards Oliver PS: Don't get me wrong, I'm *not* proposing to change the style(9) sections dealing with tabs. Heaven forbid! ;-) -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Share your knowledge. It is a way to achieve immortality." -- The Dalai Lama From owner-freebsd-chat@FreeBSD.ORG Thu Apr 16 15:56:18 2009 Return-Path: Delivered-To: freebsd-chat@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1191106564A for ; Thu, 16 Apr 2009 15:56:18 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id 39ABB8FC1B for ; Thu, 16 Apr 2009 15:56:18 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: by bwz8 with SMTP id 8so508448bwz.43 for ; Thu, 16 Apr 2009 08:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=DKLXeRUdEKeOgUyWb0vRjHYnCJhO2T7vRJ3aos8fF50=; b=qzLanw4sYpcaPXRF9RHYPUHQTGXVFbzKCUSHYiSf8Zvg1plL71MybMqGhyXIJ40rqI ImUHYMylX+jP9JzfvVXFKl+8B0Bwn2iMYj3Wt6hnBF0OlztDdrYNCcJIgY9krK1dDxMm UrvZYuEljidYu3C2c/33ugfhY4EykZaqctOEw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=SDUgrnIDUCKHj+iyQe+SfgWP4sptLz2Q/JZb2q1K7J51eBeBe4Kf/eH6h0vUHPnxAZ VvP97qma3TBUH1M1EJoa+6YSLUplXywOGJHrOW+4PNByEoZLBzZq6e9eq/lDPyO5HSQZ on+mhRdcXuwN44EXx5l6oQ8PCPoeR/pechclc= Received: by 10.103.224.17 with SMTP id b17mr829559mur.61.1239897377174; Thu, 16 Apr 2009 08:56:17 -0700 (PDT) Received: from ?157.181.96.136? (quark.teteny.elte.hu [157.181.96.136]) by mx.google.com with ESMTPS id y6sm2878305mug.25.2009.04.16.08.56.16 (version=SSLv3 cipher=RC4-MD5); Thu, 16 Apr 2009 08:56:16 -0700 (PDT) Message-ID: <49E75576.8070102@gmail.com> Date: Thu, 16 Apr 2009 17:57:42 +0200 From: deeptech71@gmail.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 MIME-Version: 1.0 To: freebsd-chat@freebsd.org References: <49E2FBE2.8020305@gmail.com> <20090413140912.GC29833@Grumpy.DynDNS.org> <49E51B42.2060405@gmail.com> <320BA0A7-C5E0-40E5-97F9-F19BF1C61B29@hiwaay.net> <49E5670C.8070708@gmail.com> <87bpqytmc7.fsf@kobe.laptop> In-Reply-To: <87bpqytmc7.fsf@kobe.laptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: My whitespace style X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 15:56:19 -0000 Giorgos Keramidas wrote: > On Wed, 15 Apr 2009 06:48:12 +0200, deeptech71@gmail.com wrote: >> Could you please give me a (preferrably widely used) example of >> columnizing calls which cross different levels of indentation? > > It's not so uncommon as it may initially seem... > > I've seen switch() cases in several programs indented like this: > > switch (value) { > case SOME_CONSTANT_NAME: do_stuff_here(); break; > case ANOTHER_CONSTANT_NAME: do_some_other_stuff(); break; > default: default_stuff(); break; > } I only see level 1 indentation, not more, not less. Oliver Fromme wrote: > Matthew D. Fuller wrote: > > Only if you abuse tabs for alignment. Indentation is not alignment. > > It's a pity that the two get conflated and everybody ends up treating > > them the same, so that advocating tab indentation is read as > > advocating tab alignment (even by proponents of tab indentation). > > The problem is that many (most? all?) editors cannot easily > be configured to differentiate between them, i.e. insert > literal ASCII tabs characters when the key is pressed > for indentation, and insert ASCII spaces when the key > is pressed for alignment. *And* treat the alignment spaces > transparently like tabs, just like the indentation spaces. > > That's probably not easy to implement, and it gets really > messy when you edit the line, remove or insert stuff between > the alignment spaces and the indetation tabs and so on. > Then suddenly alignment can become indentation, and vice > versa. The editor would then have to transparently convert > existing ASCII tab characters to spaces or vice versa. > This is a huge can of worms. > > That's another good reason to let the old ASCII tab die and > rest in peace (or "lost in space" ... ok, bad pun). In this and other posts you only give reason to kill off the space, not the tab. If two things conflict, which is wrong is for me to decide, not you. :) Seriously, let's devise a reason why one should die. Yes, it's hard to implement an editor which controls retarded mixes of tabs and spaces. But generally it's hard to implement an editor which controls retarded of any ASCII character. So let's only consider "well-formed" files. For such files, my whitespace style applies: if indentation is width-critical, use spaces, otherwise (like C source) use tabs precisely for indentation. What do you want from not well-formed files? So neither should die, rather the people who voluntarity misuse them. [One more time, if there were no spaces, there would be no problems. :)] From owner-freebsd-chat@FreeBSD.ORG Thu Apr 16 17:24:52 2009 Return-Path: Delivered-To: freebsd-chat@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EBF4106564A for ; Thu, 16 Apr 2009 17:24:52 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id D31628FC1E for ; Thu, 16 Apr 2009 17:24:51 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id n3GHORuN028761; Thu, 16 Apr 2009 19:24:50 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id n3GHORu4028760; Thu, 16 Apr 2009 19:24:27 +0200 (CEST) (envelope-from olli) Date: Thu, 16 Apr 2009 19:24:27 +0200 (CEST) Message-Id: <200904161724.n3GHORu4028760@lurza.secnetix.de> From: Oliver Fromme To: freebsd-chat@FreeBSD.ORG In-Reply-To: <49E75576.8070102@gmail.com> X-Newsgroups: list.freebsd-chat User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Thu, 16 Apr 2009 19:24:50 +0200 (CEST) Cc: Subject: Re: My whitespace style X-BeenThere: freebsd-chat@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Non technical items related to the community List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 17:24:52 -0000 deeptech71@gmail.com wrote: > Oliver Fromme wrote: > > [...] > > That's another good reason to let the old ASCII tab die and > > rest in peace (or "lost in space" ... ok, bad pun). > > In this and other posts you only give reason to kill off the space, not > the tab. If two things conflict, which is wrong is for me to decide, not > you. :) Seriously, let's devise a reason why one should die. > > Yes, it's hard to implement an editor which controls retarded mixes of > tabs and spaces. But generally it's hard to implement an editor which > controls retarded of any ASCII character. So let's only consider > "well-formed" files. For such files, my whitespace style applies: if > indentation is width-critical, use spaces, otherwise (like C source) use > tabs precisely for indentation. What do you want from not well-formed files? A space is a well-defined thing. It behaves like any other printing ASCII character (it is not a control character). A tab character (ASCII 9) is not well defined. Its behaviour depends on the editor and its configuration, on the user's preferences, on the terminal's capabilities, and so on. What's worse, the behaviour of tabs can change in undesirable ways when you move them from one environment to another. For example, when you put source code with tabs on a web page, it depends on the browser how it will be displayed, and it's even possible that some browsers don't display the source code correctly at all. The same when sending source code through e-mail or usenet news: the appearance depends on the client. Given the plethora of clients, chances are that some of them will display the tabbed source code in incomprehensible ways. That's not a bug in the clients, because there is no standard for the correct rendering of tab characters. And it get's even worse when you try to copy&paste such source code, you will often lose all tabs. That's why I believe that the only control character that should belong in source code is the line terminator. Note that even this is not really standardized: There's the newline character (line feed, ASCII 10), the carriage return character (ASCII 13) and combinations thereof, and more. But it's fairly simple to convert between those, there is no ambiguity, and editors usually handle it very well. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "A misleading benchmark test can accomplish in minutes what years of good engineering can never do." -- Dilbert (2009-03-02)