php-general Digest 2 Jul 2010 16:25:36 -0000 Issue 6827

Topics (messages 306625 through 306642):

Re: NULL Date Entries...
        306625 by: David Robley
        306626 by: David Robley

PHP 5.2.14RC2 & 5.3.3RC2 Released for Testing
        306627 by: Johannes Schlüter

detect a script crash
        306628 by: Ashley Sheridan
        306629 by: Ashley Sheridan

Re: php processing name vs. id field
        306630 by: Bob McConnell
        306631 by: Ashley Sheridan
        306632 by: Peter Lind
        306634 by: tedd
        306635 by: Bob McConnell
        306636 by: tedd
        306637 by: tedd
        306641 by: Bob McConnell
        306642 by: Kirk.Johnson.zootweb.com

filter_var_array: apply multiple filters to one field
        306633 by: Peter Lafferty

Delegating variable-length argument lists
        306638 by: Jakob Günther
        306640 by: Jakob Günther

Re: Past discussion
        306639 by: Jim Lucas

Administrivia:

To subscribe to the digest, e-mail:
        php-general-digest-subscr...@lists.php.net

To unsubscribe from the digest, e-mail:
        php-general-digest-unsubscr...@lists.php.net

To post to the list, e-mail:
        php-gene...@lists.php.net


----------------------------------------------------------------------
--- Begin Message ---
Paul M Foster wrote:

> 
> <snip>
> 
>> 
>> However, checking to ensure the date is indeed valid and not something
>> like 31st February is a good idea I agree! :)
> 
> Wait-- there's not a 31st of February? When did they change that? ;-}
> 
> Paul
> 
I believe it was last February 30th the decision was made...



Cheers
-- 
David Robley

Kids-They're not sleeping, they're recharging!
Today is Pungenday, the 37th day of Confusion in the YOLD 3176. 


--- End Message ---
--- Begin Message ---
Don Wieland wrote:

> In one of my forms, I am building a variable that I can use as an
> INSERT string.
> 
> On my form, I have several DATE fields which exist of 3 fields MM - DD
> - YYYY
> 
> when I build my string it looks like this:
> 
> array('dbf'=>'applicant_dob',
> 'f'=>array('applicant_dob_1','applicant_dob_2','applicant_dob_3'),
> 'req'=>0, 's'=>'/'),
> 
> This enters in the DB fine when there is a DATE, but when these fields
> are left empty, it inserts into the the DB as 2069-12-31.
> 
> How does one deal with this?
> 
> Don Wieland

Aside from all the good advice already offered, if you want to accept a null
date, check what your DB does with it and whether you can set a default for
an empty date. Mysql for example can use 0000-00-00


Cheers
-- 
David Robley

Microsoft - We put the "backwards" into backwards compatibility.
Today is Pungenday, the 37th day of Confusion in the YOLD 3176. 


--- End Message ---
--- Begin Message ---
The second release candidates of 5.2.14 and 5.3.3 were just released
for testing and can be downloaded here:

http://downloads.php.net/ilia/php-5.2.14RC2.tar.bz2 (md5sum:
d182560b697003d670ae8a3a804759f3)

http://downloads.php.net/johannes/php-5.3.3RC2.tar.bz2 (md5sum:
6c1b6c31f1a701a77bcb64ec4dcaac3f)

The windows binaries are available at: http://windows.php.net/qa/

This is another step in the release process of both versions and goal
is, depending on feedback, having a 3rd RC or a stable release two weeks
from now. Majority of the changes for both versions are of the "bug fix"
variety. To ensure that the release is solid, please test this RC
against your code base and report any problems that you encounter.

Johannes Schlüter
PHP 5.3 Release Master


--- End Message ---
--- Begin Message ---
Hi all,

Bit of a curve ball here (at least I couldn't find anything on Google
yet) but I need a way to be able to detect if a particular php script
crashes and generate some form of report from it.

Here is the system setup:

CentOS system, with the PHP scripts running as CLI called from a bash
script as part of a daemon. The setup is already all in-place for an
existing system, I've just been asked to implement a crash detection
system.

I know I can monitor the error logs with tail() to detect errors, but
that is likely not going to be the main issue which needs tracking.

I've found a bit of documentation online for pcntl_signal() which I
believe should do the trick, but I can't seem to find just a plain old
list of signal monikers and their meanings. Does anyone have any light
to shed on this?

Also, any other input/suggestions would be more than welcome.

Thanks,
Ash
http://www.ashleysheridan.co.uk



--- End Message ---
--- Begin Message ---
On Fri, 2010-07-02 at 11:51 +0100, Ashley Sheridan wrote:

> Hi all,
> 
> Bit of a curve ball here (at least I couldn't find anything on Google
> yet) but I need a way to be able to detect if a particular php script
> crashes and generate some form of report from it.
> 
> Here is the system setup:
> 
> CentOS system, with the PHP scripts running as CLI called from a bash
> script as part of a daemon. The setup is already all in-place for an
> existing system, I've just been asked to implement a crash detection
> system.
> 
> I know I can monitor the error logs with tail() to detect errors, but
> that is likely not going to be the main issue which needs tracking.
> 
> I've found a bit of documentation online for pcntl_signal() which I
> believe should do the trick, but I can't seem to find just a plain old
> list of signal monikers and their meanings. Does anyone have any light
> to shed on this?
> 
> Also, any other input/suggestions would be more than welcome.
> 
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
> 
> 


I think I've managed to answer my own question now. I found a list of
system codes at http://www.php.net/manual/en/pcntl.constants.php but
with no accompanying descriptions of what each one means (and quite
frankly they all look foreign to me for what they're worth!)

However, Wikipedia to the rescue, http://en.wikipedia.org/wiki/SIGILL
(and all the other signal pages it has - links at the bottom of that
one) it has a good list of the codes used by Unix systems and even the
Linux only ones which are just synonyms for the Unix ones.

Hopefully, that's useful to someone else who had a similar problem!

Thanks,
Ash
http://www.ashleysheridan.co.uk



--- End Message ---
--- Begin Message ---
From: Ashley Sheridan

> Not sure if my other email got through earlier. Replacing the name
> attribute on form fields with the id one is not feasible at all. They
> don't even behave the same. What would happen if you had two forms on
a
> page that both had an element with the same name? Using the name
> attribute, everything is fine, but not so if you were using the id
> instead.

These conditions sound like a bugs to me. I can't imagine any reason why
different forms could have the same name or id. That applies to any set
of elements on a page. Each one must have a unique moniker, no matter
which attribute you use. Even the simple validations I use will complain
about your duplicates, as they should. Making them all unique also makes
it much simpler to use tools like Selenium or Silk Test to automate the
testing process.

Looking at the HTML 4.01 references given earlier in this thread, I see
that id is now a core attribute, i.e. it is available for all but a
handful of tags, while name is only available for the tags where it is
explicitly included. So it still appears to me that id is the preferred
attribute, as it is more generally available.

Bob McConnell

--- End Message ---
--- Begin Message ---
On Fri, 2010-07-02 at 08:49 -0400, Bob McConnell wrote:

> From: Ashley Sheridan
> 
> > Not sure if my other email got through earlier. Replacing the name
> > attribute on form fields with the id one is not feasible at all. They
> > don't even behave the same. What would happen if you had two forms on
> a
> > page that both had an element with the same name? Using the name
> > attribute, everything is fine, but not so if you were using the id
> > instead.
> 
> These conditions sound like a bugs to me. I can't imagine any reason why
> different forms could have the same name or id. That applies to any set
> of elements on a page. Each one must have a unique moniker, no matter
> which attribute you use. Even the simple validations I use will complain
> about your duplicates, as they should. Making them all unique also makes
> it much simpler to use tools like Selenium or Silk Test to automate the
> testing process.
> 
> Looking at the HTML 4.01 references given earlier in this thread, I see
> that id is now a core attribute, i.e. it is available for all but a
> handful of tags, while name is only available for the tags where it is
> explicitly included. So it still appears to me that id is the preferred
> attribute, as it is more generally available.
> 
> Bob McConnell
> 


It's not a bug in the code. Imagine this scenario:

<form name="product_filter">
    <input type="submit" name="action" value="By Product Name"/>
    <input type="submit" name="action" value="By Product ID"/>
</form>

A valid form with two input elements given the same name, which sends a
different value to the server depending on which button was triggered.
Seems valid enough to me. Only one value is ever sent, so why do I need
to give them unique names and further complicate my server-side code?

Imagine further that there is another form on the page containing the
product listings, and each one has a delete button. Now we all know the
folly of putting things like delete code into an <a> tag, so a button
will do the job:

<button type="submit" name="action" value="pid_1">Delete
Product</button>
<button type="submit" name="action" value="pid_2">Delete
Product</button>
<button type="submit" name="action" value="pid_3">Delete
Product</button>

Perfectly valid, and something that is done a lot on apps I've seen and
built. Giving each a unique name just gets in the way, as you need to
use some sort of loop and pattern matching on the server just to get the
data you need.

ID is not a substitute for name on form elements. The reason name is
only available for a few elements is because it has a specific use-case,
which is not the same as the ID attribute at all.

I never said the forms themselves would have the same name or id, but
elements within them might have the same name, and two forms might have
elements with the same name. If the ID were to be a substitute for the
name attribute, then this could never happen, our scripts would become
more complex, and all for no gain.

Thanks,
Ash
http://www.ashleysheridan.co.uk



--- End Message ---
--- Begin Message ---
On 2 July 2010 15:01, Ashley Sheridan <a...@ashleysheridan.co.uk> wrote:
> On Fri, 2010-07-02 at 08:49 -0400, Bob McConnell wrote:
>
>> From: Ashley Sheridan
>>
>> > Not sure if my other email got through earlier. Replacing the name
>> > attribute on form fields with the id one is not feasible at all. They
>> > don't even behave the same. What would happen if you had two forms on
>> a
>> > page that both had an element with the same name? Using the name
>> > attribute, everything is fine, but not so if you were using the id
>> > instead.
>>
>> These conditions sound like a bugs to me. I can't imagine any reason why
>> different forms could have the same name or id. That applies to any set
>> of elements on a page. Each one must have a unique moniker, no matter
>> which attribute you use. Even the simple validations I use will complain
>> about your duplicates, as they should. Making them all unique also makes
>> it much simpler to use tools like Selenium or Silk Test to automate the
>> testing process.
>>
>> Looking at the HTML 4.01 references given earlier in this thread, I see
>> that id is now a core attribute, i.e. it is available for all but a
>> handful of tags, while name is only available for the tags where it is
>> explicitly included. So it still appears to me that id is the preferred
>> attribute, as it is more generally available.
>>
>> Bob McConnell
>>
>
>
> It's not a bug in the code. Imagine this scenario:
>
> <form name="product_filter">
>    <input type="submit" name="action" value="By Product Name"/>
>    <input type="submit" name="action" value="By Product ID"/>
> </form>
>
> A valid form with two input elements given the same name, which sends a
> different value to the server depending on which button was triggered.
> Seems valid enough to me. Only one value is ever sent, so why do I need
> to give them unique names and further complicate my server-side code?
>
> Imagine further that there is another form on the page containing the
> product listings, and each one has a delete button. Now we all know the
> folly of putting things like delete code into an <a> tag, so a button
> will do the job:
>
> <button type="submit" name="action" value="pid_1">Delete
> Product</button>
> <button type="submit" name="action" value="pid_2">Delete
> Product</button>
> <button type="submit" name="action" value="pid_3">Delete
> Product</button>
>
> Perfectly valid, and something that is done a lot on apps I've seen and
> built. Giving each a unique name just gets in the way, as you need to
> use some sort of loop and pattern matching on the server just to get the
> data you need.
>
> ID is not a substitute for name on form elements. The reason name is
> only available for a few elements is because it has a specific use-case,
> which is not the same as the ID attribute at all.
>
> I never said the forms themselves would have the same name or id, but
> elements within them might have the same name, and two forms might have
> elements with the same name. If the ID were to be a substitute for the
> name attribute, then this could never happen, our scripts would become
> more complex, and all for no gain.
>

Let's also not forget radio buttons that *by design* should have the
same name - if they don't, they don't work properly.

Regards
Peter

-- 
<hype>
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15
</hype>

--- End Message ---
--- Begin Message ---
At 2:01 PM +0100 7/2/10, Ashley Sheridan wrote:
-snip-

I agree with Ash 100%.

There is an "id" and a "name" attribute for input (et al) tags -- that's html.

I can use the attribute "name" for php and the attribute "id" for javascript and css because these are different languages with different scopes running in different environments -- that's the way it is.

Each attribute can be accessed by a variety of languages with no requirement on any specific language to know what the other languages may, or may not, be doing -- that's logical.

I can also use the same value for any attribute because there is no restriction on that either -- as well as it should be.

So, what's the major beef here? Is someone objecting to having both "id" and "name" being legal attributes for a tag? If so, this is really not the place to submit a compliant. However, it is the place to see the error of that thinking.

Giving the slightest bit of thought to dismissing the "name" attribute from tags should result in the realization that the act would break countless forms already in use. So the "beef" here is not well thought out, nor is it likely to happen.

Arguments against using/dismissing the "name" attribute in tags is simply nonsense.

Cheers,

tedd

--
-------
http://sperling.com  http://ancientstones.com  http://earthstones.com

--- End Message ---
--- Begin Message ---
From: tedd

> >At 2:01 PM +0100 7/2/10, Ashley Sheridan wrote:
> -snip-
> 
> I agree with Ash 100%.
> 
> There is an "id" and a "name" attribute for input (et al) tags --
that's html.

...

> So, what's the major beef here? Is someone objecting to having both 
> "id" and "name" being legal attributes for a tag? If so, this is 
> really not the place to submit a compliant. However, it is the place 
> to see the error of that thinking.
> 
> Giving the slightest bit of thought to dismissing the "name" 
> attribute from tags should result in the realization that the act 
> would break countless forms already in use. So the "beef" here is not 
> well thought out, nor is it likely to happen.
> 
> Arguments against using/dismissing the "name" attribute in tags is 
> simply nonsense.

This discussion began when I pointed out that the name attribute is
deprecated in XHTML. This was later confirmed when someone pointed to
the actual specification at <http://www.w3.org/TR/xhtml1/>, however
there may be some confusion about the scope of the change. The
applicable section is shown below. Apparently HTML 5 is planning to take
a different path. Of course, nobody knows that for sure since the spec
is far from complete and will likely be undergoing major changes for
several more years.

Bob McConnell

-----8<------------------------------------------------
4.10. The elements with 'id' and 'name' attributes

HTML 4 defined the name attribute for the elements a, applet, form,
frame, iframe, img, and map. HTML 4 also introduced the id attribute.
Both of these attributes are designed to be used as fragment
identifiers.

In XML, fragment identifiers are of type ID, and there can only be a
single attribute of type ID per element. Therefore, in XHTML 1.0 the id
attribute is defined to be of type ID. In order to ensure that XHTML 1.0
documents are well-structured XML documents, XHTML 1.0 documents MUST
use the id attribute when defining fragment identifiers on the elements
listed above. See the HTML Compatibility Guidelines for information on
ensuring such anchors are backward compatible when serving XHTML
documents as media type text/html.

Note that in XHTML 1.0, the name attribute of these elements is formally
deprecated, and will be removed in a subsequent version of XHTML.
-----8<------------------------------------------------

--- End Message ---
--- Begin Message ---
At 8:49 AM -0400 7/2/10, Bob McConnell wrote:
These conditions sound like a bugs to me. I can't imagine any reason why
different forms could have the same name or id

Bob:

No offense, but duh!

I can imagine, try this:

The first form asks for the user's email address. The input statement has the attributes of "name" and "id" and both have values equal to "email", such as:

<input type="text" id="email name="email">

You have a css rule that styles the email input statement via "id" as the browser gets it from the server and presents it to the user.

You have a javascript routine that does a live-check of the validity of the email address while the user enters the data.

You have a php script that processes the data using "name" after the submission of the form.

All of these are using name and id attributes from an input tag AND there is NO restriction as to what values any of these attributes can hold nor is there any restriction on what you call them, nor does any of this happen at the same time or even in the same stage of action.

The css is delivered from the server to the browser, the javascript routine is triggered by the user entering data via his browser, and the php script is run after the user clicks submit. All of these happen at different times.

The second form (to fulfill your "different forms requirement) simply repeats the email value (i.e., value="<?php echo($email); ?>" and awaits the user to confirm.

End of example -- and that's done routinely.

---------------

 Each one must have a unique moniker, no matter
which attribute you use.

That's nonsense. Why would html require that php, javascript, and css use different values for different attributes?

I don't think you've thought this out.

---------------

Even the simple validations I use will complain
about your duplicates, as they should.

Show me any validation that requires no duplicates in attribute naming convention.

---------------

Making them all unique also makes
it much simpler to use tools like Selenium or Silk Test to automate the
testing process.

Simpler for whom?

Looking at the HTML 4.01 references given earlier in this thread, I see
that id is now a core attribute, i.e. it is available for all but a
handful of tags, while name is only available for the tags where it is
explicitly included. So it still appears to me that id is the preferred
attribute, as it is more generally available.

Bob McConnell

Popularity of attributes is not an indicator of which is correct to use for all languages. It is only an indicator that the "id" attribute is more common, which has no point. The net is a collection of efforts and languages -- while you may want to reduce input statement (and other tags) attributes from allowing both "name" and "id" to just "id" the practice would be devastation on a global scale.

Please rethink.

Cheers,

tedd

--
-------
http://sperling.com  http://ancientstones.com  http://earthstones.com

--- End Message ---
--- Begin Message ---
At 10:53 AM -0400 7/2/10, Bob McConnell wrote:
This discussion began when I pointed out that the name attribute is
deprecated in XHTML. This was later confirmed when someone pointed to
the actual specification at <http://www.w3.org/TR/xhtml1/>, however
there may be some confusion about the scope of the change. The
applicable section is shown below. Apparently HTML 5 is planning to take
a different path. Of course, nobody knows that for sure since the spec
is far from complete and will likely be undergoing major changes for
several more years.

Bob McConnell

What XHTML does is limited to XHTML.

Simply put, HTML is the glue that holds the web-works together. The attributes that HTML uses/approves is what concerns other languages. I am sure that the "powers that be" will consider the affects of changing established and well entrenched attributes (remember that "name" was used as an attribute before "id"). As such, I seriously doubt that "name" will fall by the wayside any time soon.

Cheers,

tedd


--
-------
http://sperling.com  http://ancientstones.com  http://earthstones.com

--- End Message ---
--- Begin Message ---
From: tedd

> At 10:53 AM -0400 7/2/10, Bob McConnell wrote:
> >This discussion began when I pointed out that the name attribute is
> >deprecated in XHTML. This was later confirmed when someone pointed to
> >the actual specification at <http://www.w3.org/TR/xhtml1/>, however
> >there may be some confusion about the scope of the change. The
> >applicable section is shown below. Apparently HTML 5 is planning to
take
> >a different path. Of course, nobody knows that for sure since the
spec
> >is far from complete and will likely be undergoing major changes for
> >several more years.
> 
> What XHTML does is limited to XHTML.
> 
> Simply put, HTML is the glue that holds the web-works together. The 
> attributes that HTML uses/approves is what concerns other languages. 
> I am sure that the "powers that be" will consider the affects of 
> changing established and well entrenched attributes (remember that 
> "name" was used as an attribute before "id"). As such, I seriously 
> doubt that "name" will fall by the wayside any time soon.

Yes, the wonderful thing about standards is that there are so many to
chose from. My head is hurting even trying to consider all of this. We
have settled on XHTML for all corporate pages, since it is final, fixed
and well supported. It can also be validated easily using the HTML
Validator plug-in for Firefox, among others. A significant portion of my
work over the past year has been improving conformance by using that
plug-in.

The only other thing I plan to think about is how soon I should retire.
I'll be eligible for social security in less than six months, and if the
stock market is kind to my 401K, I should be ready by then. Since there
isn't anything left here that allows me to use my primary skills
(Assembly language and hardware device drivers) I am pretty much
treading water until I leave. I think my managers have put me on these
web pages simply to keep me occupied until then. It's obvious I don't
understand the underlying technology very well.

For those in the USofA, have a great Fourth of July holiday.

Bob McConnell

--- End Message ---
--- Begin Message ---
"Bob McConnell" <r...@cbord.com> wrote on 07/02/2010 08:53:30 AM:

> > Arguments against using/dismissing the "name" attribute in tags is 
> > simply nonsense.
> 
> This discussion began when I pointed out that the name attribute is
> deprecated in XHTML. This was later confirmed when someone pointed to
> the actual specification at <http://www.w3.org/TR/xhtml1/>, however
> there may be some confusion about the scope of the change. The
> applicable section is shown below. Apparently HTML 5 is planning to take
> a different path. Of course, nobody knows that for sure since the spec
> is far from complete and will likely be undergoing major changes for
> several more years.
> 
> Bob McConnell
> 
> -----8<------------------------------------------------
> 4.10. The elements with 'id' and 'name' attributes
> 
> HTML 4 defined the name attribute for the elements a, applet, form,
> frame, iframe, img, and map. HTML 4 also introduced the id attribute.
> Both of these attributes are designed to be used as fragment
> identifiers.
> 
> In XML, fragment identifiers are of type ID, and there can only be a
> single attribute of type ID per element. Therefore, in XHTML 1.0 the id
> attribute is defined to be of type ID. In order to ensure that XHTML 1.0
> documents are well-structured XML documents, XHTML 1.0 documents MUST
> use the id attribute when defining fragment identifiers on the elements
> listed above. See the HTML Compatibility Guidelines for information on
> ensuring such anchors are backward compatible when serving XHTML
> documents as media type text/html.
> 
> Note that in XHTML 1.0, the name attribute of these elements is formally
> deprecated, and will be removed in a subsequent version of XHTML.

At the risk of injecting a little light into this discussion ;) note the 
list of elements in the excerpt Bob provided: a, applet, form, frame, 
iframe, img, and map. Almost all replies to date have referred to the name 
attribute of the *form elements*: input, select, and textarea. Two 
different sets of elements.

As far as I am concerned, the "authorities" are free to remove the name 
attribute from the first set. I think it is safe to say that the name 
attribute will not be removed from the *form elements* anytime soon.

For all with a holiday coming up this weekend, have a good one!

Kirk

--- End Message ---
--- Begin Message ---
Is there any way to apply multiple filters to one field using
filter_var_array?

 

Basically I have an email field which I want to sanitize and validate.
The docs and any sites I find only tell how to apply one filter at a
time using filter_var_array.

 

Regards,

Peter Lafferty
Software Developer

Web Reservations International Ltd.,
Block D, Charlemont Exchange
Charlemont Street
Dublin 2, Ireland

email: peter.laffe...@webresint.com
<mailto:peter.laffe...@webresint.com> 

Tel: + 353 1 4980772
Fax: +353 1 4980715


--- End Message ---
--- Begin Message ---
Hi,

i'm writing a custom wrapper for the mysqli_stmt class. I have to
override the method mysqli_stmt::bind_param. This function uses
"variable-length argument lists". In my function i want to delegate its
arguments to the original function.

My first naiv implementation was that:

function bind_param($types) {
        $sParams=array();
        $first=true;
        for($i=1; i < func_num_args(); $i++) {
            $sParams[] = func_get_arg($i);
        }
        
        array_unshift ($sParams ,$types);
        call_user_func_array (array ($this->mysqli_stmt, 'bind_param'), 
                $sParams);
}

But this is not working, because  I need to pass it by reference. Is
there a way to retrieve references to a variable number of arguments?

Thx, Jakob

--- End Message ---
--- Begin Message ---
I did not find a solution, so i tried passing a array with references.

$arr = array(&$a, &$b);
bind_param("ii", $arr);

function bind_param($types, $arr){
        array_unshift($arr, $types);
        call_user_func_array (array ($stmt, 'bind_param'), $arr);
}

This worked in a test-case in one file. But if i call the bind-param-method
from another class it did not work. Do you have any suggestions on this?


Am 02.07.2010 17:25, schrieb Jakob Günther:
> Hi,
>
> i'm writing a custom wrapper for the mysqli_stmt class. I have to
> override the method mysqli_stmt::bind_param. This function uses
> "variable-length argument lists". In my function i want to delegate its
> arguments to the original function.
>
> My first naiv implementation was that:
>
> function bind_param($types) {
>       $sParams=array();
>         $first=true;
>         for($i=1; i < func_num_args(); $i++) {
>             $sParams[] = func_get_arg($i);
>         }
>       
>       array_unshift ($sParams ,$types);
>         call_user_func_array (array ($this->mysqli_stmt, 'bind_param'),       
>               $sParams);
> }
>
> But this is not working, because  I need to pass it by reference. Is
> there a way to retrieve references to a variable number of arguments?
>
> Thx, Jakob
>
>   


--- End Message ---
--- Begin Message ---
David McGlone wrote:
> Hi everyone,
> 
> I have been searching the archives for a past discussion where some software 
> that some folks use to (I think) save code snippets from e-mails for future 
> references or something of such.
> 
> Does anyone remember that discussion? I am trying to figure out a good way to 
> create my own "wiki" type thing so I can use it to help me and be able to go 
> back and review very helpful e-mails or code that was very helpful to my 
> understanding of how it works.
> 
> Here lately I've been remembering things that were brought up on the list 
> that 
> had very helpful info, but remembering what thread they were in or what 
> topic, 
> so I can find it in the archives is harder than I thought it would be.
> 
> Anyone have any suggestions, techniques or remember that discussion so I can 
> find it in the archives again?
> 

David,

Daniel Brown wrote a weekly summary stats app that scanned his email account and
totaled the number of lines of code someone wrote in their email sent to the
mailing list.  It might worth while to ask him for this code detection 
method(s).

-- 
Jim Lucas

A: Maybe because some people are too annoyed by top-posting.
Q: Why do I not get an answer to my question(s)?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

--- End Message ---

Reply via email to