[1639] in Coldmud discussion meeting

Re: Genesis 1.1.9 - STABLE

daemon@ATHENA.MIT.EDU (Wed Jan 10 04:24:30 2001 )

Message-ID: <3A5C1753.EDE200E1@geocities.com>
Date: Wed, 10 Jan 2001 02:03:31 -0600
From: Allen Noe <psyclone42@geocities.com>
MIME-Version: 1.0
To: coldstuff@cold.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: coldstuff@cold.org

Bruce wrote:
> 
> Allen Noe wrote:

<big snip>

> > I can always create a separate function to do what I
> > have stack(1) do if it ends up conflicting -- that
> > convention is just to save a function and be slightly
> > portable: (| stack(1) |) || stack() should always compile
> > and work.
> 
> Well, I could make stack() take an optional second argument that
> would control whether or not line numbers were calculated:
> 
> stack() -- current task, generate line numbers
> stack(828)  -- task 828, generate line numbers
> stack(828, 0) -- task 828, don't genererate line numbers
> stack(task_id(), 0) -- current task, don't generate line
>                        numbers
> 
> I could do that if it were seen as important enough.

Sounds good. If you find you don't have time, I could tack the second arg on the
stack(TID) code -- it looks like I'd need to make an INIT_0_TO_2_ARGS, but that
looks relatively simple.

> Are there other outstanding patches or have you created new ones
> since this original post?  Also, I -know- that some of the work
> that I'm aiming to get into this next release will break Win32 as
> it brings in the use of Posix threads.

No new patches, but there's a little module I wrote -- nothing really widely
useful, and the copyright isn't clear on it. If anybody is interested, I could
try to clarify the copyright enough to let it be put in the main source. It has
natives that do the following:

1. The equivalent of strlen for a certain kind of buffer: basically a plain
string which may or may not contain VT100 color codes (ESC[n;n;nm).
2. The equivalent of subrange for the same sort of buffer.
3. Delete certain strings from a list and merge certain remaining other strings.

As for pthreads, I believe they can be .. er .. "simulated" using Win32 API
calls, but would it be too much to ask to surround the bits that need pthreads
with ifdefs so they could be compiled out? It would improve portability greatly,
not just to Win32.