Implementation of functions in math.h on clc-wiki

[Ronald Bruck]

Please do not snip attributions for material you quote. Your
message would imply that PJP wrote the portion marked ">>>" above.
He did not, you did. This is either carelessness or sneakiness.

I think we're able to count > signs.

--Ron Bruck

 

[Al Balmer]

I think we're able to count > signs.

How does that restore the missing attribution?

 

[Ronald Bruck]

How does that restore the missing attribution?

It doesn't. When you're concentrating on, in this case, Plauger's
remark, you only need to restore sufficient context to understand his
remark. Who cares who made the intermediate comment?

This isn't academia, where everything is referenced, re-referenced, and
footnoted. Thank God.

--Ron Bruck

 

[CBFalconer]

It doesn't. When you're concentrating on, in this case, Plauger's
remark, you only need to restore sufficient context to understand
his remark. Who cares who made the intermediate comment?

If you look, there is nothing in that message that PJP wrote, yet
there is a missing attribute for what niiru wrote. That was the
point. You can't restore missing context lacking the referenced
article.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Al Balmer]

It doesn't. When you're concentrating on, in this case, Plauger's
remark, you only need to restore sufficient context to understand his
remark. Who cares who made the intermediate comment?

Obviously, Chuck and I do. So should you, considering that the above
was *not* Plauger's remark. That was the point of the objection.

 

[Netocrat]

Netocrat said:

As an update for anyone following this: none of the pages have been
restored yet, but I believe it would be possible for quite a few of them
to be restored without raising objections. Everyone concerned seems to
accept the good-faith future intentions of other parties.

Good move. Perhaps it would be a good idea to start again, and ban
anyone from participating if they have access to a copy of TSCL. (In a
curious omission, I never actually got around to buying a copy myself,
so I'd be game for that.)

I'd prefer that too, but I don't think that it's necessary - it blocks a
lot of people from contributing. So long as people disclose all
references that they've used, and any possible unconscious reproduction
along with steps they've taken to avoid it, I think that ethical and legal
principles are upheld.

I've drafted some policies partly in response to this thread:

This morning, I took the opportunity to drop in on the C wiki, and I
have to say it does look like it's becoming a useful site, current
debacle notwithstanding. I am delighted, and encouraged. I may start
dropping by a little more often.

Thanks for the support. I hope you keep on stopping by.

 

[Netocrat]

[some snippage restored]

Great, fresh ideas are welcome.

I also think that these files should be moved into a "pseudo-namespace"
[see http://clc-wiki.net/wiki/Clc_libc/stdio]

I've described a different approach here:

Perhaps MinGW's C library package could be used as material, after all
it is distributed as a public domain.

The policies and conventions that I've just added to the wiki for
discussion discourage this approach without outright prohibiting it,
preferring that contributed code be completely original.

[...]

btw, I use the opportunity to thank you all who have been patiently &
unselfisly posting codes to public domain. The CLC-wiki - project will
certainly be a very important resource for many - Keep up with good
work!

That's also my hope for it. Cheers for the support.

 

[Netocrat]

Gregory Pietsch wrote:
I'm writing a portable implementation of the C standard library for
http://www.clc-wiki.net and I was wondering if someone could check
the functions in math.h for sanity/portability/whatever. I'm almost
halfway through writing the over 200 functions needed to implement
C99's version of math.h, and I would like to have some feedback
and/or expert advice on my implementations.

Caution. Many of the standard library routines are intrinsically
not implementable with portable code. I suggest an enumeration of
these would be worthwhile, together with the sort of assumptions
needed for an implementation. We can start with malloc, realloc,
and free, which require assumptions about alignment and pointer
convertability.

A _lot_ can be done with only a very tiny section of non-portable
code, though. malloc/realloc/free need only two things - a way to get
a [moderately large] block of memory from the OS, and a way to figure
out pointer alignments. (Once a pointer _is_ aligned 'for any data
type', it can be converted to a pointer to any data type)

On many (and certainly most modern) platforms, a heap implementation
that is not thread safe (via true critical sections) is kind of
useless.

The question is what the wiki's focus should be. I think that it should
be on purely portable C code as c.l.c has made that its focus. So the
wiki C implementations needn't cope with threading at all, but that
limitation should be documented if it turns out to be the case.

Locking can be abstracted with macros, to some extent.

If it doesn't add unnecessary complexity, sure, we can use that approach.

No idea.

The approach that I suggest is to quarantine non-portable code into
identifiers prefixed with _np, and to list all those identifiers on a
single page. If an _np identifier encompasses an entire library function,
so be it, but the aim would be to minimise their scope. From there,
whether it's useful to implement a non-portable solution for that
identifier on the wiki depends on how much insight into C that
implementation would provide.

 

[Jordan Abel]

As an update for anyone following this: none of the pages have been
restored yet, but I believe it would be possible for quite a few of them
to be restored without raising objections. Everyone concerned seems to
accept the good-faith future intentions of other parties.


I'd prefer that too, but I don't think that it's necessary - it blocks a
lot of people from contributing. So long as people disclose all
references that they've used, and any possible unconscious reproduction
along with steps they've taken to avoid it, I think that ethical and legal
principles are upheld.

Some issues - I don't like the GFDL [there are certain problems like its
poorly worded DRM restrictions that have been the subject of some
controversy recently] and I think you should seriously consider this
instead of just using the GFDL because wikipedia does it [Sorry if this
isn't the reason, but it's what the combination of GFDL and mediawiki
brings to mind

Second, there's no particular reason that code segments in an article
can't have their own license. [say, the GPL - which the GFDL is
incompatible with.]

 

[Jordan Abel]

[some snippage restored]

Great, fresh ideas are welcome.

I also think that these files should be moved into a "pseudo-namespace"
[see http://clc-wiki.net/wiki/Clc_libc/stdio]

I've described a different approach here:

Perhaps MinGW's C library package could be used as material, after all
it is distributed as a public domain.

The policies and conventions that I've just added to the wiki for
discussion discourage this approach without outright prohibiting it,
preferring that contributed code be completely original.

There's still the issue of code that someone has read in the past
"contaminating" their code with similarities.

There's also libclc to consider, which it might make sense to post in
its entirety or even to some extent 're-home' it or its documentation on
the wiki (are any of the authors still around here? Bjorn Augestad, Dan
Pop, Eric G. Miller, Hallvard B. Furuseth, Jan Engelhardt, Randy Howard,
Bertrand Mollinier Toublet, Howard Chu, Walter Faxon, are all credited,
and I have no idea who the maintainer is) - it's under a BSD-ish
license, but... does the GFDL allow warranty disclaimers? It's not
particularly suited to code, so it might not mention the issue [and if
it has a "no more restrictions" clause that could be a problem]

 

[Jordan Abel]

[some snippage restored]

Great, fresh ideas are welcome.

I also think that these files should be moved into a "pseudo-namespace"
[see http://clc-wiki.net/wiki/Clc_libc/stdio]

I've described a different approach here:
<http://clc-wiki.net/wiki/Talk:Clc_libc>. This includes a few reference
pages.

I think namespaces are still a worthwhile approach, especially if we
ever decide to post code that isn't part of a libc implementation [I
mentioned libclc in my other reply]

A hierarchial namespace is discouraged on wikipedia for a reason, but i
tihnk that reason maybe doesn't fit well here.

How about we [i guess by 'we' i mean 'you'] set it up like the
following?

Standard_Library/string.h [place to put explanations of constants and macros,
and the header file code itself]
Standard_Library/string.h/strcpy

[the current strcpy article moved to Standard_Library/string.h/strcpy
and so on]