From: Phred Phungus on
Lew Pitcher wrote:
> Warning:
>
> Lew Pitcher, who posts to this newsgroup, is a domain thief.
>
> Read the full story at http://www.lewpitcher.ca
>


Whatever.
--
fred
From: Phred Phungus on
John Gordon wrote:
> In <7vl3guFs3gU1(a)mid.individual.net> Phred Phungus <Phred(a)example.invalid> writes:
>
>> fp = popen ("mv *.c backups1/.", "r");
>
> Why are you capturing the output of the mv command? popen() does not return
> error output, only standard output. What standard output are you hoping to
> capture?
>

Should be:

(void) fp = popen ("mv *.c backups1/.", "r");
--
From: Seebs on
On 2010-03-26, David Given <dg(a)cowlark.com> wrote:
> That's a GNUism, I'm afraid. They don't believe in man pages, only in
> texinfo documentation. While I have no problem with texinfo
> documentation as is (apart from the command-line texinfo reader itself,
> which is appalling), texinfo documentation produces *books*, and as a
> result is totally unsuitable for the kind of concise but complete
> reference that man pages are normally so good at --- the information's
> just not arranged in the right way. I find the fact that they refuse to
> provide proper man documentation an utter pain.

Seconded. I think it's based on a fundamental misunderstanding about
the reason man pages exist. Not all documentation is the same kind of
documentation.

A while back, I was asked what we needed before we could publish an
open source project.

One of my answers was: "Man pages." I spent an extra day or so working
on the documentation to make sure it was usable before shipping:

http://github.com/wrpseudo/pseudo

The package doesn't currently install them, but they're there if you
need them. ... And I just fixed a formatting bug.

> As an aside, make is a pretty ghastly piece of software --- it's grown
> and mutated in weird ways for so long the result now no longer resembles
> anything like a sensible program. You may wish to bookmark the manual at
> http://www.gnu.org/software/make/manual/make.html, although it's not
> very easy to find stuff in.

It's worth noting that Berkeley make, GNU make, and at least one or two
other variants, all have INCOMPATIBLE ways of resolving fundamental things.

I've written some fairly crazy GNU make code:

$$(foreach i,$$($(1)_LDAT_indexes),@$$(foreach j,$$(wordlist $$(word $$i,$$($(1)_LDAT_starts)),$$(word $$i,$$($(1)_LDAT_ends)),$$($(1)_LDAT_list)),$$(call $(1),$$j) ; )$$(LDAT_nl))

> I got so fed up with it a while back that I actually ended up writing my
> own build tool, when facing with a large project that make was
> completely failing to handle... (<plug> Prime Mover,
> http://primemover.sf.net </plug>).

Does it regularly shoot small children? If not, it is probably better than
make.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: David Given on
On 26/03/10 00:48, Seebs wrote:
[...]
> I've written some fairly crazy GNU make code:
>
> $$(foreach i,$$($(1)_LDAT_indexes),@$$(foreach j,$$(wordlist $$(word $$i,$$($(1)_LDAT_starts)),$$(word $$i,$$($(1)_LDAT_ends)),$$($(1)_LDAT_list)),$$(call $(1),$$j) ; )$$(LDAT_nl))

I feel your pain.

[...]
> Does it regularly shoot small children? If not, it is probably better than
> make.

Well... it *is* evil and twisted. It's Lua-based, but doesn't require
you to install a Lua interpreter; it deploys as a self-bootstrapping
shell script that invisibly unpacks and compiles the interpreter on
demand. Most likely god kills a kitten every time someone runs it, but
it *is* effective. You can simply drop the pm executable into a project
and distribute and not have to worry about your users having to install
stuff (*cough*scons*cough*). Lua's small enough to make this feasible:
the whole thing --- Lua interpreter source, Prime Mover script and all
--- packs into a single 180kB shell script.

But that's really just an implementation detail; I wrote it to support a
huge compiler project that wanted to build the same binaries over and
over again with slightly different settings, with vast amounts of
dynamically generated source (again, produced over and over again with
multiple settings). The original build system was a nightmare maze of
recursive makefiles and shell scripts building more makefiles, etc. pm
deals with this stuff beautifully, and gets all the dependencies right, too.

It's not perfect: there are bugs and rough edges, and one major design
cockup early on that I'm now not sure how to fix, but it's effective
enough that several years on I'm still using it for all my personal
projects.

Short introduction and example here:

http://primemover.sourceforge.net/about.html

There's an extensive manual on the website. Er, not in man format.

--
┌─── dg@cowlark.com ───── http://www.cowlark.com ─────

│ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ }
│ --- Conway's Game Of Life, in one line of APL
From: Rainer Weikusat on
David Given <dg(a)cowlark.com> writes:
> On 26/03/10 00:48, Seebs wrote:
> [...]
>> I've written some fairly crazy GNU make code:
>>
>> $$(foreach i,$$($(1)_LDAT_indexes),@$$(foreach j,$$(wordlist $$(word $$i,$$($(1)_LDAT_starts)),$$(word $$i,$$($(1)_LDAT_ends)),$$($(1)_LDAT_list)),$$(call $(1),$$j) ; )$$(LDAT_nl))
>
> I feel your pain.

That some people inevitably reinvent the Gordian knot whenever given
enough rope is not something the rope is accountable for.