8.0.3 ?

1 view
Skip to first unread message

Alexandre Ferrieux

unread,
Jul 22, 1998, 3:00:00 AM7/22/98
to
Is there somewhere a preliminary version of 8.0.3 ?
Cameron, you talked about compiling it on some machine the other day...
how did you get it ? I've looked on equi4, no such beast. Am I missing
something obvious ?

-Alex

Frederic BONNET

unread,
Jul 22, 1998, 3:00:00 AM7/22/98
to
Hi,

It's planned to be released on the Tcl Consortium's CD around the first
week of August.

CU, Fred
--
Frédéric BONNET frederi...@mim.lu
---------------------------------------------------------------
"Theory may inform, but Practice convinces"
George Bain

Marc Rossi

unread,
Jul 22, 1998, 3:00:00 AM7/22/98
to
In comp.lang.tcl Frederic BONNET <frederi...@mim.lu> wrote:
: Hi,

: Alexandre Ferrieux wrote:
: >
: > Is there somewhere a preliminary version of 8.0.3 ?
: > Cameron, you talked about compiling it on some machine the other day...
: > how did you get it ? I've looked on equi4, no such beast. Am I missing
: > something obvious ?
: >

: It's planned to be released on the Tcl Consortium's CD around the first
: week of August.

Is there any way we can get a patch list beforehand to see what it
includes?

Thanks,
Marc
--
Marc Rossi
mailto:ma...@mcs.com

Alexandre Ferrieux

unread,
Jul 23, 1998, 3:00:00 AM7/23/98
to
Robin Becker wrote:
>
> I only found one patch that had been 'adopted', presumably other stuff
> has been done.
>

OK, but *WHERE* did you see that ???

Don't you think a more interactive process (with the rest of us) would
be more productive ? Even in a pure advisory form (i.e. without them
listening to us), this would soothe our anxieties regarding some
critical bugs and misfeatures.

Sorry to bother you with my personal wishlist, but again, if 8.1's
fileevent-on-pipes-on-Windoze is *not* backported in 8.0.3, I'll be
*very* (and noisily) angry. Am I alone ?

-Alex

Jeffrey Hobbs

unread,
Jul 23, 1998, 3:00:00 AM7/23/98
to
Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> writes:

> Don't you think a more interactive process (with the rest of us) would
> be more productive ? Even in a pure advisory form (i.e. without them
> listening to us), this would soothe our anxieties regarding some

Let me answer.... hmmmm... no.

But to soothe or rile your anxieties, here is a list I just happened
across:

----------------- Released 8.0p2, 11/25/97 -----------------------

12/3/97 (bug fix/optimization) Removed uneeded and potentially dangerous
instances of double evaluations if "if" and "expr" statements from
the library files. It is recommended that unless you need a double
evaluation you always use "expr {...}" instead of "expr ..." and
"if {...} ..." instead of "if ... ...". It will also be faster
thanks to the byte compiler. (DL)

---- Shipped as part of the plugin2.0b5 as 8.0p2Plugin1, Dec 8th 97 ----

12/8/97 (bug fix) Need to protect the newly accepted channel in an
accept callback on a socket, otherwise the callback may close it and
cause an error, which would cause the C code to attempt to close the
now deleted channel. Bumping the refcount assures that the channel sticks
around to be really closed in this case. (JL)

12/8/97 (bug fix) Need to protect the channel in a fileevent so that it
is not deleted before the fileevent handler returns. (CS, JL)

12/18/97 (bug fix) In the opt argument parsing package: if the description
had only flags, the "too many arguments" case was not detected. The default
value was not used for the special "args" ending argument. (DL)

1/15/98 (improvement) Moved common part of initScript in common file.
Moved windows specific initialization to init.tcl so you can initialize
Tcl in windows without having to call Tcl_Init which is now only
searching for init.tcl {back ported from 8.1}. (DL)

---- Shipped as part of the plugin as 8.0p2Plugin2, Jan 15th 98 ----

5/27/98 (bug fix) Windows socket driver did not notice new data arriving
on nonblocking sockets until the event loop was entered. (SS)

5/27/98 (bug fix) Windows socket driver used FIONREAD, which is not
supported correctly by WinSock. (SS)

6/9/98 (bug fix) Generic channel code failed to report readable file
events on buffered data that was left behind by a gets or read that
did not consume all available data. (SS)

6/18/98 (bug fix) Compilation of loop expressions was too aggressive
and incorrectly inlined non-literal expressions. (SS)

6/18/98 (bug fix) "info var" and "info locals" incorrectly reported
the existence of compiler temporary variables. (SS)

6/18/98 (bug fix) Dictionary sorting used signed character
comparisons. (SS)

6/18/98 (bug fix) Compile procs corrupted the exception stack in some
cases. (SS)

6/18/98 (bug fix) Array set had erratic behavior when initializing a
variable from an empty value list. (SS)

6/18/98 (bug fix) The Windows registry package had a bad bounds check
that could lead to a crash. (SS)

6/18/98 (bug fix) The foreach compile proc did not correctly handle
non-local variable references. (SS)

6/25/98 (new features) Added name resolution hooks to support [incr Tcl].
There are new Tcl_*Resolver* APIs to add, query and remove the hooks.
With this changes it should be possible to dynamically load [incr Tcl]
as an extension. (MM)

6/29/98 (compatibility patch) Changed the signature of Tcl_EvalObj
to match that in Tcl 8.1, but added a macro for compatibility with
the 2-argument version of the call. This works with gcc but we
don't know how other compilers will handle it, so
*** POTENTIAL INCOMPATIBILITY ***
The goal of this patch is that simple extensions compiled against
Tcl 8.0.3 will also work with Tcl 8.1.
Contributed by Jan Nijtmans (JN)

7/1/97 (bug fix) The commands "info args, body, default, procs" did
not correctly handle imported procedures. (RJ)

7/6/98 (improvement) pkg_mkIndex now implements the "package require"
command. This makes it possible to create index files for packages
that require another package and then execute code from that package in
their file. Previously, this would throw an error because the required
package had not been loaded. The -nopkgrequied flag is provided to
revert back to the old functionality. (EMS)

7/6/98 (improvement) back-ported the -direct flag from 8.1 into
pkg_mkIndex. This results in pkgIndex.tcl files that contain direct
source or load commands instead of tclPkgSetup commands. (EMS)

7/6/98 (improvement) made changes to the AuxData items structures to support
storage of compiled scripts on disk. Also some related minor changes in
the compilation and execution engine. (EMS)

6/4/98 (enhancement) Added new internal routines to support inserting
and deleting from the stat, access, and open-file-channel mechanisms.
TclAccessInsertProc, TclStatInsertProc, & TclOpenFileChannelInsertProc
insert pointers to such routines; TclAccessDeleteProc, TclStatDeleteProc,
& TclOpenFileChannelDeleteProc delete pointers to such routines. See
the file generic/tclIOUtils.c for more details. (SKS)

7/1/98 (enhancement) Added a new internal C variable
tclPreInitScript. This is a pointer to a string that may hold an
initialization script; If this pointer is non-NULL it is evaluated in
Tcl_Init() prior to the built-in initialization script defined in the
file generic/tclInitScript.h. (SKS)

7/6/98 (bug fix) Removed dead code in PlatformInitExitHandler so that
the TCL_LIBRARY value can be safely patched in binaries. (BW)

That's just the Tcl changes, and not necessarily all or
them, or the correct ones.

--
Jeffrey Hobbs "I'm really just a Tcl-bot"
jeff.hobbs at acm.org | Jeffrey.Hobbs at oen.siemens.de

Alexandre Ferrieux

unread,
Jul 23, 1998, 3:00:00 AM7/23/98
to
Jeffrey Hobbs wrote:
>
> Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> writes:
>
> > Don't you think a more interactive process (with the rest of us) would
> > be more productive ? Even in a pure advisory form (i.e. without them
> > listening to us), this would soothe our anxieties regarding some
>
> Let me answer.... hmmmm... no.

Okay, that was God's word.
We don't seem to deserve an explanation, too bad.

> But to soothe or rile your anxieties, here is a list I just happened
> across

That's nice of you. Even more constructive would be to say where you got
it.

-Alex

Robin Becker

unread,
Jul 23, 1998, 3:00:00 AM7/23/98
to
In article <35B744...@cnet.francetelecom.fr>, Alexandre Ferrieux
<alexandre...@cnet.francetelecom.fr> writes

>Jeffrey Hobbs wrote:
>>
>> Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> writes:
>>
>> > Don't you think a more interactive process (with the rest of us) would
>> > be more productive ? Even in a pure advisory form (i.e. without them
>> > listening to us), this would soothe our anxieties regarding some
>>
>> Let me answer.... hmmmm... no.
>
>Okay, that was God's word.
>We don't seem to deserve an explanation, too bad.
>
>> But to soothe or rile your anxieties, here is a list I just happened
>> across
>
>That's nice of you. Even more constructive would be to say where you got
>it.
>
>-Alex
I saw only the adopted patch (from Victor) in the 8.0p2 patches for Tcl.
Presumably there's an inner Cabal of Tcl Mystiks who are better
connected than the rest of us.
--
Robin Becker

Bruce Stephens

unread,
Jul 23, 1998, 3:00:00 AM7/23/98
to
Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> writes:

> Jeffrey Hobbs wrote:

> > But to soothe or rile your anxieties, here is a list I just happened
> > across
>

> That's nice of you. Even more constructive would be to say where you got
> it.

Well, he's probably been watching the newsgroup. Since everybody
knows that he was collecting patches, they may well have sent him some
too.

The good news is that Scriptics have a web site, on which they have a
list of patches for Tcl/Tk 8.0p2 and 8.1a2. They don't say which ones
will be in 8.0p3, but that would be making things too easy, I suppose.

There's also a clue in the statement (a few days ago) that [incr Tcl]
will become a pure loadable extension with 8.0.3, so probably getting
itcl3.0a1 and looking at the patches to the core in that would give a
clue.

Andreas Kupries

unread,
Jul 23, 1998, 3:00:00 AM7/23/98
to

Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> writes:

> Robin Becker wrote:
> > I only found one patch that had been 'adopted', presumably other stuff
> > has been done.

> OK, but *WHERE* did you see that ???

Most probably at
http://www.scriptics.com/resource/software/patches/

--
Sincerely,
Andreas Kupries <a.ku...@westend.com>
<http://www.westend.com/~kupries/>
-------------------------------------------------------------------------------

Alexandre Ferrieux

unread,
Jul 24, 1998, 3:00:00 AM7/24/98
to
Andreas Kupries wrote:
>
> Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> writes:
>
> > Robin Becker wrote:
> > > I only found one patch that had been 'adopted', presumably other stuff
> > > has been done.
>
> > OK, but *WHERE* did you see that ???
>
> Most probably at
> http://www.scriptics.com/resource/software/patches/
>

There, you can find individual patches, not the linear, 'changes'-style
file like the one posted.
So ?

Alexandre Ferrieux

unread,
Jul 24, 1998, 3:00:00 AM7/24/98
to
Bruce Stephens wrote:
>
> Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> writes:
>
> > Jeffrey Hobbs wrote:
>
> > > But to soothe or rile your anxieties, here is a list I just happened
> > > across
> >
> > That's nice of you. Even more constructive would be to say where you got
> > it.
>
> Well, he's probably been watching the newsgroup. Since everybody
> knows that he was collecting patches, they may well have sent him some
> too.

This doesn't account for the regular, linearized 'changes' file he sent.

-A

Marc Rossi

unread,
Jul 24, 1998, 3:00:00 AM7/24/98
to
In comp.lang.tcl Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> wrote:

: Robin Becker wrote:
: >
: > I only found one patch that had been 'adopted', presumably other stuff
: > has been done.
: >

: OK, but *WHERE* did you see that ???

: Don't you think a more interactive process (with the rest of us) would


: be more productive ? Even in a pure advisory form (i.e. without them
: listening to us), this would soothe our anxieties regarding some

: critical bugs and misfeatures.

: Sorry to bother you with my personal wishlist, but again, if 8.1's
: fileevent-on-pipes-on-Windoze is *not* backported in 8.0.3, I'll be
: *very* (and noisily) angry. Am I alone ?

: -Alex

That is the same reason I am asking, the "filevent-on-pipes-on-Windoze"
is causing me problems also. Although I have written my own "exec/open"
implementation in C to overcome this, I would much rather use code that
someone else is supporting

Bruce Stephens

unread,
Jul 24, 1998, 3:00:00 AM7/24/98
to
Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> writes:

> Bruce Stephens wrote:

> > Well, he's probably been watching the newsgroup. Since everybody
> > knows that he was collecting patches, they may well have sent him some
> > too.
>
> This doesn't account for the regular, linearized 'changes' file he sent.

Ah. His article was over 100 lines, so my newsreader didn't download
it. In that case, unless he invented it, he must have spies in
Scriptics, or he's helping them test it, or something. I suspect if
you have a real need to see the changes file, emailing someone at
Scriptics would probably get a response.

Personally, I don't see any problem with not having a preview list of
changes for 8.0.3. It's not going to have extra features (beyond
trivial ones), it's just a maintenance release, which I'll get when
it's released.

What would consultation get? If I have a bug, I'll report it; if I
have a pressing need for a new feature, that wouldn't be put in 8.0.3
in any case.

8.1 is different altogether, since it involves quite radical new
features, and there people are being consulted.

I agree this isn't the linux style development model that lots of
projects are using nowadays, where anybody can get the latest source
by cvs, but I'm not convinced that's a problem.

Robin Becker

unread,
Jul 24, 1998, 3:00:00 AM7/24/98
to
In article <6pa1fp$4s0$1...@Nntp1.mcs.net>, Marc Rossi
<ma...@Venus.mcs.net> writes

>In comp.lang.tcl Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr>
>wrote:
>: Robin Becker wrote:
>: >
>: > I only found one patch that had been 'adopted', presumably other stuff
>: > has been done.
>: >
>
>: OK, but *WHERE* did you see that ???
>
>: Don't you think a more interactive process (with the rest of us) would
>: be more productive ? Even in a pure advisory form (i.e. without them
>: listening to us), this would soothe our anxieties regarding some
>: critical bugs and misfeatures.
>
>: Sorry to bother you with my personal wishlist, but again, if 8.1's
>: fileevent-on-pipes-on-Windoze is *not* backported in 8.0.3, I'll be
>: *very* (and noisily) angry. Am I alone ?
>
>: -Alex
>
no I object to this secretiveness as well.

>That is the same reason I am asking, the "filevent-on-pipes-on-Windoze"
>is causing me problems also. Although I have written my own "exec/open"
>implementation in C to overcome this, I would much rather use code that
>someone else is supporting
>
>Marc

--
Robin Becker

Leo Schubert

unread,
Jul 24, 1998, 3:00:00 AM7/24/98
to
On 24 Jul 1998 13:16:41 GMT, Marc Rossi <ma...@Venus.mcs.net> wrote:
>In comp.lang.tcl Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> wrote:
>: Sorry to bother you with my personal wishlist, but again, if 8.1's
>: fileevent-on-pipes-on-Windoze is *not* backported in 8.0.3, I'll be
>: *very* (and noisily) angry. Am I alone ?
>
>: -Alex
>
>That is the same reason I am asking, the "filevent-on-pipes-on-Windoze"
>is causing me problems also. Although I have written my own "exec/open"
>implementation in C to overcome this, I would much rather use code that
>someone else is supporting
>
>Marc

In the expect for NT distribution
http://bmrc.berkeley.edu/people/chaffee/expectnt.html
the fileevent problem on windows is solved too.
This distribution has a modified tclWinPipe.c and
an additional tclWinReader.c, which implements the piping with
Threads, comparable to the 8.1a2 solution.
Works for me and seems to be more Windows-compliant than the 8.1 solution and
promises to handle console handles (stdin-still not tested by me).
Tcl8.1 uses TerminateThread() and the Win32 SDK states:
TerminateThread is a dangerous function that should only be used in the most extreme cases.
The expect NT-port avoids this, however I noticed that a "close" on a
descriptor created with
open "|foo.exe" (and foo running forever)
hung.
Turned out that the filedescriptors of the pipe were closed AFTER the
Tcl_WaitPid, so Tcl_WaitPid did never return.
I just exchanged the lines and it worked...


*** /home/leo/expectsrc/tcl8.0/win/tclWinPipe.c Tue Jul 21 13:23:20 1998
--- ./tclWinPipe.c Fri Jul 24 17:13:17 1998

***************
*** 2160,2167 ****
} else {
errChan = NULL;
}
- /*result = TclCleanupChildren(interp, pipePtr->numPids, pipePtr->pidPtr,
- errChan);*/

errorCode = 0;
if (pipePtr->readFile != NULL) {
--- 2190,2195 ----
***************
*** 2185,2190 ****
--- 2213,2219 ----

result = TclCleanupChildren(interp, pipePtr->numPids, pipePtr->pidPtr,
errChan);
+
pipePtr->refCount--;
PipeFreeProc((ClientData) pipePtr);

Would be good to have the
"filevent-on-pipes-on-Windoze-patch" somewhere handy anyway.

Regards,
Leo

--
Leo Schubert, Brueckner&Jarosch Ing.-GmbH Erfurt, Germany 99084
Andreasstr. 37, TEL +49=361-21240.14, FAX .19, EMAIL l...@bj-ig.de

Alexandre Ferrieux

unread,
Jul 27, 1998, 3:00:00 AM7/27/98
to
Leo Schubert wrote:
>
> In the expect for NT distribution
> http://bmrc.berkeley.edu/people/chaffee/expectnt.html
> the fileevent problem on windows is solved too.
> This distribution has a modified tclWinPipe.c and
> an additional tclWinReader.c, which implements the piping with
> Threads, comparable to the 8.1a2 solution.
>

By the way, could someone explain *why* it's not possible to make it
work *without* threads, just with the normal WaitForMultipleObject ( ==
select) ?

> Would be good to have the
> "filevent-on-pipes-on-Windoze-patch" somewhere handy anyway.

Definitely.

-Alex

lvi...@cas.org

unread,
Jul 27, 1998, 3:00:00 AM7/27/98
to

According to Robin Becker <ro...@jessikat.demon.co.uk>:
:In article <6pa1fp$4s0$1...@Nntp1.mcs.net>, Marc Rossi
:<ma...@Venus.mcs.net> writes
:>In comp.lang.tcl Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr>
:>wrote:
:>: Don't you think a more interactive process (with the rest of us) would

:>: be more productive ? Even in a pure advisory form (i.e. without them
:>: listening to us), this would soothe our anxieties regarding some
:>: critical bugs and misfeatures.

More productive for whom? Scriptics have a product to get out and if
I were in their shoes, I doubt I would be in much favor of spending time
on interactiveness in a newsgroup as opposed to completing the first product
necessary to generate income for the company. But I don't work for them
and wouldn't presume to speak for them.

They have accumulated bug reports and patches from the newsgroup.
They have a number of bugs that they are fixing themselves, and of course
we hope that the patches and bug reports on 8.0.2 that have appeared.
However, the Tcl core is produced by Scriptics, and of course they have
final say in what they are comfortable supporting. I do not know what
the Scriptics level of support for Windows is right now. However, I do
notice that both Windows and Unix are mentioned on the Scriptics beta page
for TclPro, so I assume that someone is providing some level of support.

:>: Sorry to bother you with my personal wishlist, but again, if 8.1's


:>: fileevent-on-pipes-on-Windoze is *not* backported in 8.0.3, I'll be
:>: *very* (and noisily) angry. Am I alone ?

So what's new <that's a JOKE Alex...>.


:no I object to this secretiveness as well.

To what secretiveness do you refer? The fact that the list of bugs fixed
in an unreleased software package (in other words, one in which bugs
are still being fixed) is not available? Most products that I see
barely report bugs fixed at the time of a release...


--
<URL:mailto:lvi...@cas.org> Quote: In heaven, there is no panic,
<*> O- <URL:http://www.teraform.com/%7Elvirden/> only planning.
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.

dema...@my-dejanews.com

unread,
Jul 27, 1998, 3:00:00 AM7/27/98
to
Time constraints, limited resources, and other factors
are understandable but afaik Tcl/Tk is not a 'product'
but an open source effort and that's why a lot of people
(including me) put an higher expectation level on it than
if it was just another product.

I wish I could attend the upcoming panel "Tcl in the Bazaar"
at the upcoming Tcl conference because I think Tcl *might*
benefit greatly from that kind of open development model
(Would the end result have been better, I don't know, but it
would have been surely much different if a wider set of developers
are able to contribute directly (then there is feature creep
and consistency issues, but other projects (Linux,...) have
handled that pretty well)).

--
http://www.demailly.com/~dl/

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum

Andreas Kupries

unread,
Jul 27, 1998, 3:00:00 AM7/27/98
to

Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> writes:

> Andreas Kupries wrote:

> > Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> writes:

> > > Robin Becker wrote:
> > > > I only found one patch that had been 'adopted', presumably other stuff
> > > > has been done.

> > > OK, but *WHERE* did you see that ???

> > Most probably at
> > http://www.scriptics.com/resource/software/patches/

> There, you can find individual patches, not the linear, 'changes'-style
> file like the one posted.
> So ?

Well, I thought that your question refered to the 'adopted' /
not-'adopted' information. This you will find at the given
location. About a linear file I know nothing, sorry.

Laurent Demailly

unread,
Jul 28, 1998, 3:00:00 AM7/28/98
to
(repost because of stupid @my-dejanews.com email
email that I never read in initial post -- sorry)

Alexandre Ferrieux

unread,
Jul 28, 1998, 3:00:00 AM7/28/98
to
lvi...@cas.org wrote:
>
> According to Robin Becker <ro...@jessikat.demon.co.uk>:
> :In article <6pa1fp$4s0$1...@Nntp1.mcs.net>, Marc Rossi
> :<ma...@Venus.mcs.net> writes
> :>In comp.lang.tcl Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr>
> :>wrote:
> :>: Don't you think a more interactive process (with the rest of us) would
> :>: be more productive ? Even in a pure advisory form (i.e. without them
> :>: listening to us), this would soothe our anxieties regarding some
> :>: critical bugs and misfeatures.
>
> More productive for whom? Scriptics have a product to get out and if
> I were in their shoes, I doubt I would be in much favor of spending time
> on interactiveness in a newsgroup as opposed to completing the first product
> necessary to generate income for the company. But I don't work for them
> and wouldn't presume to speak for them.

OK Larry you win :)
But I'm afraid this highlights a sad point: the 'business model' of the
pair {TclPro,Tcl core} is really weird. When I saw the Tcl Consortium
manifesto, I thought it was great, because it seemed to adequately
decouple the free software community from the specific Scriptic
business. In my idea, JO's (and other's) contribution to Tcl would be
done through the Consortium, while the Scriptics story guaranteed his
interest in not seeing Tcl drift away towards some MS-like bloatware.
But apparently I am massively wrong :(

> :no I object to this secretiveness as well.
>
> To what secretiveness do you refer? The fact that the list of bugs fixed
> in an unreleased software package (in other words, one in which bugs
> are still being fixed) is not available? Most products that I see
> barely report bugs fixed at the time of a release...

I'm afraid it's not the availability which is under scrutiny, but its
spatial derivative :), since some people seem to have better access than
other. Now you already told us about Tclburn. It's just that Mr Hobbs
could have been a little more informative (and pleasant) in telling it
himself instead of throwing his secret list to our faces out of warning.

-Alex

lvi...@cas.org

unread,
Jul 28, 1998, 3:00:00 AM7/28/98
to

According to <dema...@my-dejanews.com>:
:Time constraints, limited resources, and other factors

:are understandable but afaik Tcl/Tk is not a 'product'
:but an open source effort and that's why a lot of people
:(including me) put an higher expectation level on it than
:if it was just another product.

The problem that I see - and I am speaking only for myself -
is that there are folk (and I don't necessarily mean you) who
seem to think that it is fine to put their higher expectations
onto someone to do the work.

It is fine to expect more from one's self. For that matter,
to expect more from one's team mates. But when I find myself
working on a project, and folk who are getting the results of
my work for free attempt to put onto me their own personal agendas
in the form of a demand, then I tend to bristle. I am afraid that
might have come across rather apparent last summer at the workshop
when folk tried to tell me that I _must_ change the format of the
FAQ because it didn't suit them. I appreciate ideas, software
contributions, updates, etc. But I have a lesser appreciation
of someone telling me that I must change because they don't like
the way I am doing something.

Likewise if I were one of the primary tcl software developers
then I would have less appreciation for someone demanding that
I change the way I was doing something than I would would have
towards someone who decided to take the code and try out the new
model on their own, offering a parallel version (ala tclx, plus-dash,
incr tcl, etc.) running in an alternate model.

Robin Becker

unread,
Jul 28, 1998, 3:00:00 AM7/28/98
to
In article <6pkmep$f14$1...@srv38s4u.cas.org>, lvi...@cas.org writes
If the open developement model is dead because the 'primary' developers
are just secretive then we're dealing with the wrong people. If they're
secretive because they can't be bothered that's also a big minus; if
they're secretive because of financial things count me out.
--
Robin Becker

Leo Schubert

unread,
Jul 29, 1998, 3:00:00 AM7/29/98
to
On Mon, 27 Jul 1998 10:58:39 +0200, Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> wrote:
>Leo Schubert wrote:
>>
>> In the expect for NT distribution
>> http://bmrc.berkeley.edu/people/chaffee/expectnt.html
>> the fileevent problem on windows is solved too.
>> This distribution has a modified tclWinPipe.c and
>> an additional tclWinReader.c, which implements the piping with
>> Threads, comparable to the 8.1a2 solution.
>>
>
>By the way, could someone explain *why* it's not possible to make it
>work *without* threads, just with the normal WaitForMultipleObject ( ==
>select) ?
because WaitForMultipleObject doesn't work on filehandles ( != select),
you can use Threads, Processes, Events , but no file descriptors.
Believe me I tried it. RTFM.

Regards , Leo

Alexandre Ferrieux

unread,
Jul 29, 1998, 3:00:00 AM7/29/98
to
Leo Schubert wrote:

>
> Alexandre Ferrieux wrote:
> >
> > By the way, could someone explain *why* it's not possible to make it
> > work *without* threads, just with the normal WaitForMultipleObject (
> > == select) ?
>
> because WaitForMultipleObject doesn't work on filehandles ( !=
> select), you can use Threads, Processes, Events , but no file
> descriptors. Believe me I tried it. RTFM.

RTFM:(WaitForMultipleObject documentation):

In some circumstances, you can specify a handle of a file, named
pipe, or communications device as a synchronization object in
lpHandles. However, their use for this purpose is discouraged.

So ? Did you *really* try ?

Anyway, I am amazed at how people can obediently accept things like
that. It's just like "Buy my $-20,000 car. It's designed to turn right
only. It can turn left in some circumstances, but it is discouraged.".

This very example leads me to state once again: Win32 is pure sh*t.
I know some people round here don't like dirty language like this, but
this time I don't think it is just one more MS shortcoming. I do feel
intellectually offended by the implied notion that MS's production is of
sufficient quality for us, non-Redmond-native sub-humans.

-Alex

Leo Schubert

unread,
Jul 29, 1998, 3:00:00 AM7/29/98
to
On Wed, 29 Jul 1998 15:34:38 +0200, Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> wrote:
>Leo Schubert wrote:
>>
>> Alexandre Ferrieux wrote:
>> >
>> > By the way, could someone explain *why* it's not possible to make it
>> > work *without* threads, just with the normal WaitForMultipleObject (
>> > == select) ?
>>
>> because WaitForMultipleObject doesn't work on filehandles ( !=
>> select), you can use Threads, Processes, Events , but no file
>> descriptors. Believe me I tried it. RTFM.
>
>RTFM:(WaitForMultipleObject documentation):
good guy :-)

>
> In some circumstances, you can specify a handle of a file, named
> pipe, or communications device as a synchronization object in
> lpHandles. However, their use for this purpose is discouraged.
>
Because of this really funny part of the doc, I didn't expect that I can do
such a simple thing like waiting for file descriptor.

>
>So ? Did you *really* try ?
Yes yes yes. I wrote hundreds of debugging lines to be shure.
Yes, it *really* *doesn't* work for anonymous pipes.
Waitblabla simply returns if you pass a pipe descriptor to it, the
next ReadFile blocks ...
I also tried all that overlapped and callback stuff, but here the doc
already says that it's only for named pipes.
really sad story

>
>This very example leads me to state once again: Win32 is pure sh*t.
>
It's an API with a totally different philosophy,
it's not simple and that's why difficult to maintain.
Compared to UNIX with a handful functions for the core part it is
a real pain.
But if you have a look at the win32 programmer newsgroups there are
a lot of people loving to have pain.
Perhaps the hidden secrets and the every-day-a-new-function-for-whatever
are more interesting than a dry man page from 1970 :-)
I don't like the MS philosophy, however we should try to provide
the Windows world with a good tcl.
If the people are realising that they can do tcl even better on UNIX,
it would be great step.
That mean , we have to implement fileevent properly, regardless of the
used-super-duper-Ex32-together-with10threads-function.
Howgh

(We recommend our customers to use Linux)

Cameron Laird

unread,
Jul 29, 1998, 3:00:00 AM7/29/98
to
In article <OwfirHA2...@jessikat.demon.co.uk>,
Robin Becker <ro...@jessikat.demon.co.uk> wrote:
.
.

.
>If the open developement model is dead because the 'primary' developers
>are just secretive then we're dealing with the wrong people. If they're
>secretive because they can't be bothered that's also a big minus; if
>they're secretive because of financial things count me out.
>--
>Robin Becker

There are several other possibilities, of course;
the core team might just have made priority deci-
sions which don't even include financial or
secrecy values, and which still result in what we
see today.

My intuition is that more "openness" would be good,
and I've let a number of people know that. More
certain than that, though, is that I don't have all
the facts I'd want to have before making a decision.

Even more certain than that, as Larry recently
pointed out, is that most any of us can start making
a substantive contribution NOW through mere action.
I've got lots of ideas for anyone with more motiva-
tion than experience: public bug lists, reworked
source bundles maintained outside Scriptics, and
many, many more projects are available.

If I had the energy, I'd work in here a slick adver-
tisement for membership in the Consortium. I don't,
though, now, so I'll just ask that everyone look into
the opportunity.
--

Cameron Laird http://starbase.neosoft.com/~claird/home.html
cla...@NeoSoft.com +1 713 996 8546 FAX

Cameron Laird

unread,
Jul 29, 1998, 3:00:00 AM7/29/98
to
In article <6pni1s$7kl$1...@Starbase.NeoSoft.COM>, I emoted:
.
.

.
>Even more certain than that, as Larry recently
>pointed out, is that most any of us can start making
>a substantive contribution NOW through mere action.
>I've got lots of ideas for anyone with more motiva-
>tion than experience: public bug lists, reworked
>source bundles maintained outside Scriptics, and
>many, many more projects are available.
>
>If I had the energy, I'd work in here a slick adver-
>tisement for membership in the Consortium. I don't,
>though, now, so I'll just ask that everyone look into
>the opportunity.
.
.
.
If, for example, you kept up with <URL:http://
www.tclconsortium.org/resources/headlines.html>,
you would have been led to John's own words on the
subject, as reported in <URL:http://
www.sunworld.com/sunworldonline/swol-07-1998/swol-07-tcl.html>

Nat Pryce

unread,
Jul 29, 1998, 3:00:00 AM7/29/98
to
Alexandre Ferrieux wrote:
> RTFM:(WaitForMultipleObject documentation):

>
> In some circumstances, you can specify a handle of a file, named
> pipe, or communications device as a synchronization object in
> lpHandles. However, their use for this purpose is discouraged.
>
> So ? Did you *really* try ?
>
> Anyway, I am amazed at how people can obediently accept things like
> that. It's just like "Buy my $-20,000 car. It's designed to turn right
> only. It can turn left in some circumstances, but it is discouraged.".

This is basically saying that, although it works at the moment, it
shouldn't be relied upon because is not guaranteed to work in future
versions of windows, and that writers of device drivers do not have to
implement the behaviour for file handles opened on their devices.

If don't mind the risk of your code breaking in future versions of
windows or when new device drivers are installed, then you are
perfectly free to pass such handles to WaitForMultipleObjects.

The accepted method to do asynchronous I/O is to use overlapped IO
and wait on the event handles associated with each I/O request.
Or, if sockets are used, you can use the WSAEventSelect function
to associate an event handle with a socket.

> This very example leads me to state once again: Win32 is pure sh*t.

> I know some people round here don't like dirty language like this, but
> this time I don't think it is just one more MS shortcoming. I do feel
> intellectually offended by the implied notion that MS's production is of
> sufficient quality for us, non-Redmond-native sub-humans.

Well, I have come across the same type of manual entries for various
UNIX features as well. It is a good thing that they warn us.
Otherwise you'd be posting this kind of comment when your code
broke in Win98 or NT5 :-)

Cheers,
Nat.

--
+------------------------------------------+---------------------+
| Name: Nat Pryce MEng ACGI | Dept. of Computing, |
| Email: n...@doc.ic.ac.uk | Imperial College, |
| Tel: +44 (0)171 594 8394 | 180 Queen's Gate, |
| Fax: +44 (0)171 581 8024 | London SW7 2BZ, |
| WWW: http://www-dse.doc.ic.ac.uk/~np2 | United Kingdom |
+------------------------------------------+---------------------+

Alexandre Ferrieux

unread,
Jul 30, 1998, 3:00:00 AM7/30/98
to
Nat Pryce wrote:
>
> Alexandre Ferrieux wrote:
> > RTFM:(WaitForMultipleObject documentation):
> >
> > In some circumstances, you can specify a handle of a file, named
> > pipe, or communications device as a synchronization object in
> > lpHandles. However, their use for this purpose is discouraged.
> >
> > So ? Did you *really* try ?
> >
> > Anyway, I am amazed at how people can obediently accept things like
> > that. It's just like "Buy my $-20,000 car. It's designed to turn right
> > only. It can turn left in some circumstances, but it is discouraged.".
>
> This is basically saying that, although it works at the moment, it
> shouldn't be relied upon because is not guaranteed to work in future
> versions of windows, and that writers of device drivers do not have to
> implement the behaviour for file handles opened on their devices.
>
> If don't mind the risk of your code breaking in future versions of
> windows or when new device drivers are installed, then you are
> perfectly free to pass such handles to WaitForMultipleObjects.
>
> The accepted method to do asynchronous I/O is to use overlapped IO
> and wait on the event handles associated with each I/O request.
> Or, if sockets are used, you can use the WSAEventSelect function
> to associate an event handle with a socket.


You don't need to lecture us; I guess a pretty large part of the
community knows what the word 'guarantee' means.
Instead, the purpose of my $20,000-car analogy was to stress the fact
that *this* shortcoming was a very serious one. To be more precise, the
very existence of WSAEventSelect (socket case) shows that even MS
recognizes that the event semantics is useful for IPC. In this context,
no healthy mind could support the idea that it's not useful for pipes
(named or not), which are just another kind of IPC.

Now saying that the 'accepted method to do async I/O is overlapping'
is, if you allow another analogy, like saying that the accepted method
to turn left is to turn 270 degrees right :)

> > This very example leads me to state once again: Win32 is pure sh*t.
> > I know some people round here don't like dirty language like this, but
> > this time I don't think it is just one more MS shortcoming. I do feel
> > intellectually offended by the implied notion that MS's production is of
> > sufficient quality for us, non-Redmond-native sub-humans.
>
> Well, I have come across the same type of manual entries for various
> UNIX features as well. It is a good thing that they warn us.
> Otherwise you'd be posting this kind of comment when your code
> broke in Win98 or NT5 :-)

Same type of warning, but not same type of shortcoming. See above.

-Alex

Leo Schubert

unread,
Jul 30, 1998, 3:00:00 AM7/30/98
to
On Wed, 29 Jul 1998 16:29:58 +0100, Nat Pryce <n...@doc.ic.ac.uk> wrote:
>Alexandre Ferrieux wrote:
>> RTFM:(WaitForMultipleObject documentation):
>> In some circumstances, you can specify a handle of a file, named
>> pipe, or communications device as a synchronization object in
>> lpHandles. However, their use for this purpose is discouraged.
>This is basically saying that, although it works at the moment, it
>shouldn't be relied upon because is not guaranteed to work in future
>versions of windows, and that writers of device drivers do not have to
>implement the behaviour for file handles opened on their devices.
>

It doesn't work in the sense a unixian would expect it.

>
>The accepted method to do asynchronous I/O is to use overlapped IO
>and wait on the event handles associated with each I/O request.
>Or, if sockets are used, you can use the WSAEventSelect function
>to associate an event handle with a socket.
>

From the Win32 SDK :
(Win32 Programmers reference,Overviews,System Services,Pipes,About Pipes,Anonymous Pipe Operations)
Asynchronous (overlapped) read and write operations are not supported by
anonymous pipes.
This means that you cannot use the ReadFileEx and WriteFileEx functions
with anonymous pipes.
In addition, the lpOverLapped parameter of ReadFile and WriteFile is ignored
when these functions are used with anonymous pipes.

It is stated that overlapped IO is possible on ordinary disk files(but only
under NT), however I think the usage of "fileevent" to read in disk files
is of less priority.
What the folk mostly wants to do is "open "|foo.exe" r" ,to
establish an anonymous pipe and to use "fileevent" to prevent wish/tclsh
from blocking.
And exactly this is not possible in a single threaded program. Shure.
I wrote an rlogin-daemon for NT, and I made lot's of tests adressing this
issue ...
If it would be possible to handle anonymous pipes nonblocking in a single
threaded program, I'm shure that Scott would have implemented it.
Anyway , the problem is solved by the win32-magician Gordon Chaffee
(expect on NT is one of the trickiest win32 stuff I ever saw, it's a cool
description how to write your own debugger on Win95/NT) and
by the sun/scriptics team in tcl8.1 using threading.
For the Tcl programmer on Windows it makes no difference, *how* the problem
is solved, it should work reliable and stable.
(BTW, if somebody opens a socket under NT wish80, the Task-Manage shows 2
Threads, it's the internal implementation of Winsock)
The tclish win32 programmers could discuss, which implementation is the
better one. I'd prefer the expect on NT solution, it handles ConsoleHandles
(stdin) as well and avoids some dangerous function calls (TerminateThread).
Perhaps the scriptics team should have a look at that.

Regards, Leo

Nat Pryce

unread,
Jul 30, 1998, 3:00:00 AM7/30/98
to
Alexandre Ferrieux wrote:
> You don't need to lecture us; I guess a pretty large part of the
> community knows what the word 'guarantee' means.
> Instead, the purpose of my $20,000-car analogy was to stress the fact
> that *this* shortcoming was a very serious one. To be more precise, the
> very existence of WSAEventSelect (socket case) shows that even MS
> recognizes that the event semantics is useful for IPC. In this context,
> no healthy mind could support the idea that it's not useful for pipes
> (named or not), which are just another kind of IPC.
>
> Now saying that the 'accepted method to do async I/O is overlapping'
> is, if you allow another analogy, like saying that the accepted method
> to turn left is to turn 270 degrees right :)

It wasn't meant as a lecture. I was only pointing out that Win32
has an accepted way of performing reactive IO and that is to issue
overlapped I/O requests and wait on the handles associated with
each request, rather than wait on the device handle and react
to data being queued for the application. It's different from the
way UNIX does reactive I/O, but that doesn't mean it's any worse.
In fact it has some advantages: the operating system can read data
from the device directly into the application's address space which
avoids the copying that is inherent in the UNIX scheme of things.

Alexandre Ferrieux

unread,
Jul 30, 1998, 3:00:00 AM7/30/98
to
Leo Schubert wrote:
>
> What the folk mostly wants to do is "open "|foo.exe" r" ,to
> establish an anonymous pipe and to use "fileevent" to prevent wish/tclsh
> from blocking.
> And exactly this is not possible in a single threaded program. Shure.
>

Thanks for this statement, so I won't waste time on the impossible.

I still can't figure out what happened under the skulls of the MS Win32
team, to yield this state of affairs. And I also can't understand people
who say "Okay, it's just different from you mindset, please respect it".
Nope. It is objectively, utterly stupid. Period. And I wish things like
that about Microsoft were better known in the industry.

> Anyway , the problem is solved by the win32-magician Gordon Chaffee

> ... and by the sun/scriptics team in tcl8.1 using threading.


> For the Tcl programmer on Windows it makes no difference, *how* the problem
> is solved, it should work reliable and stable.
> (BTW, if somebody opens a socket under NT wish80, the Task-Manage shows 2
> Threads, it's the internal implementation of Winsock)

Given your unavoidable statement above, I fully agree.
Now an interesting question is: why not encapsulate completely this
data-awaiting thread so that its threadedness doesn't appear at the Tcl
level, just like the socket example you give (or, for that matter, any
audio I/O on Windoze) ? Indeed, the full thread-safety of 8.1 is needed
only if *tclish* things happen in different threads. While here, the
thread could just blockingly read to a channel buffer, and then signal
an event which would be used (from the main Tcl thread) by the notifier
via WiatForMultipleObject. So this thing could easily be backported to
8.02 (or 3), despite the thread implied. What do you think ? Any takers
?


> The tclish win32 programmers could discuss, which implementation is the
> better one. I'd prefer the expect on NT solution, it handles ConsoleHandles
> (stdin) as well and avoids some dangerous function calls (TerminateThread).
> Perhaps the scriptics team should have a look at that.

Sorry - no time to verify; maybe Expect's solution is close to the one
sketched above... :)

Anyway, thank you again for settling this issue at last !

-Alex

Alexandre Ferrieux

unread,
Jul 30, 1998, 3:00:00 AM7/30/98
to
Nat Pryce wrote:
>
> I was only pointing out that Win32
> has an accepted way of performing reactive IO and that is to issue
> overlapped I/O requests and wait on the handles associated with
> each request, rather than wait on the device handle and react
> to data being queued for the application. It's different from the
> way UNIX does reactive I/O, but that doesn't mean it's any worse.

Except it simply doesn't work for pipes. So it *is* worse :)

(See Leo Schubert's detailed review on this thread)

> In fact it has some advantages: the operating system can read data
> from the device directly into the application's address space which
> avoids the copying that is inherent in the UNIX scheme of things.

BTW, unix also has aioread, which does work on *any* descriptor.

But please continue the comparison, it's so interesting :)

-Alex

lvi...@cas.org

unread,
Jul 30, 1998, 3:00:00 AM7/30/98
to

According to Robin Becker <ro...@jessikat.demon.co.uk>:
:In article <6pkmep$f14$1...@srv38s4u.cas.org>, lvi...@cas.org writes
:>
:If the open developement model is dead because the 'primary' developers

:are just secretive then we're dealing with the wrong people. If they're

What is the purpose of inflamatory msgs? Why is it that people seem
to feel it necessary to say things like 'secretive'? Have you been
told 'we refuse to give you that info'?

:secretive because they can't be bothered that's also a big minus; if


:they're secretive because of financial things count me out.

If I asked someone 'have you stopped cheating on your taxes or do you still
bribe officials', when neither were the case, then am I justified in
my belief if neither happens to be the case and the person is too busy
making a living to be bothered? No. Why assume someone is being secretive
because they haven't given folk something that they want. Has anyone
specifically written to the president of Scriptics and asked for specific
information? There are many companies who happen to occasionally monitor
a usenet group but don't have time to spend 10+ hrs a day reading and
replying to every message on a newsgroup.

From what I can tell, Scriptics is NOT a commercial site whose primary
business is providing free support for a free language. They appear to
be a business who appear to be writing commercial software, providing
commercial training and support, for a language which one of their
founders created and several of their staff have improved. They also
appear to be committed to continuing to provide ongoing improvements to
said language.

However, as has been said numerous times, anyone who doesn't like the direction
tcl is going can take tcl from a particular point in time, go off, start
their own development team, create their own extensions, etc. All they
are required to do is maintain the original copyrights under the provisions
described in the source.

Rather than trying to demand a business that one is not currently in contract
with change their staffing priorities, it would seem better to develop an
alternative if there are perceived philosophical differences.

Robin Becker

unread,
Jul 30, 1998, 3:00:00 AM7/30/98
to
In article <6ppruu$t95$1...@srv38s4u.cas.org>, lvi...@cas.org writes

>
>According to Robin Becker <ro...@jessikat.demon.co.uk>:
>:In article <6pkmep$f14$1...@srv38s4u.cas.org>, lvi...@cas.org writes
>:>
>:If the open developement model is dead because the 'primary' developers
>:are just secretive then we're dealing with the wrong people. If they're
>
>What is the purpose of inflamatory msgs? Why is it that people seem
>to feel it necessary to say things like 'secretive'? Have you been
>told 'we refuse to give you that info'?
>
>:secretive because they can't be bothered that's also a big minus; if
>:they're secretive because of financial things count me out.
>
I didn't start the secretive stuff I just commented on it.
There's no intention on my part to be critical of anyone.
Your reaction to my libertarianism is revealing.
Scriptics doesn't need defending if it maintains the open developement
model; this would be seen by nearly everyone as a 'good' thing.
My response doen't mention Scriptics.
Tcl/Tk has also grown because of the enthusiasts.

>If I asked someone 'have you stopped cheating on your taxes or do you still
>bribe officials', when neither were the case, then am I justified in
>my belief if neither happens to be the case and the person is too busy
>making a living to be bothered? No. Why assume someone is being secretive
>because they haven't given folk something that they want. Has anyone
>specifically written to the president of Scriptics and asked for specific
>information? There are many companies who happen to occasionally monitor
>a usenet group but don't have time to spend 10+ hrs a day reading and
>replying to every message on a newsgroup.
>
coming from you Larry that's good :)

>From what I can tell, Scriptics is NOT a commercial site whose primary
>business is providing free support for a free language. They appear to
>be a business who appear to be writing commercial software, providing
>commercial training and support, for a language which one of their
>founders created and several of their staff have improved. They also
>appear to be committed to continuing to provide ongoing improvements to
>said language.
>
it is in Scriptics' own interest that a concensus language is developed;
the alternative is in JO's own terms that the users will have to vote
for more than one Tcl; splitting the vote isn't good.

>However, as has been said numerous times, anyone who doesn't like the direction
>tcl is going can take tcl from a particular point in time, go off, start
>their own development team, create their own extensions, etc. All they
>are required to do is maintain the original copyrights under the provisions
>described in the source.
>
>Rather than trying to demand a business that one is not currently in contract
>with change their staffing priorities, it would seem better to develop an
>alternative if there are perceived philosophical differences.
no demands were made or intended
--
Robin Becker

Mark Harrison

unread,
Jul 31, 1998, 3:00:00 AM7/31/98
to
Robin Becker wrote in message ...

>If the open developement model is dead because the 'primary' developers
>are just secretive then we're dealing with the wrong people. If they're
>secretive because they can't be bothered that's also a big minus; if
>they're secretive because of financial things count me out.


Here's the story:

8.0.3 is a byproduct of the Tcl Consortium CD-ROM project, which was
announced here a while back.

One of the big goals of the CD-ROM Project was to unify the various
versions of Tcl which patched the core, namely:

Incr Tcl
Plus and Dash patches

Last month Michael McLennan released Itcl alpha 3.0, which still came
with it's own (modified) copy of Tcl/Tk 8.0. So, as Michael and the
Scriptics guys had planned in advance, the Scriptics guys would incorporate
Michael's modifications and release a new minor version of Tcl/Tk 8.0,
so that Itcl could ship only with itcl/itk/iwidgets in a "pure" loadable
form.

As part of the CD-ROM work, people have been building the various extensions
as shared libraries. One problem is that the Plush/Dash patches add some
extra fields to one of the Tcl internal structures, so that it seemed that
two versions of each extension would need to be provided: one that worked
with "standard" Tcl and one that worked with "plus" Tcl.

This seemed like a big headache, so the other major change is adding the
extra "plus" fields to the standard release, allowing dynamically loaded
packages to work with both versions.

Scriptics changed their naming scheme from X.YpZ to the more usual X.Y.Z,
so this is how 8.0.3 came to be. Looking back there would probably have
been no drawbacks to generally releasing it, but since the focus at that
time was on building the CD-ROM it was only announced to the CD-ROM
mailing list.

Tcl has generally been on the more conservative "fewer, more carefully
tested releases" side, so this was probably influenced by that thinking.
Definitely no obvious evil intentions on anyone's part.

Brent even mentioned to the CD-ROM list that John O. has suggested putting
the Tcl core on an anonymous CVS server. (IMHO: A wonderful idea!)

Mark.

ma...@usai.asiainfo.com
Mark Harrison at AsiaInfo Computer Networks,
Beijing, China

Leo Schubert

unread,
Jul 31, 1998, 3:00:00 AM7/31/98
to
On Thu, 30 Jul 1998 12:52:24 +0200, Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> wrote:
>Leo Schubert wrote:
>>
>> Anyway , the problem is solved by the win32-magician Gordon Chaffee
>> ... and by the sun/scriptics team in tcl8.1 using threading.
>> For the Tcl programmer on Windows it makes no difference, *how* the problem
>> is solved, it should work reliable and stable.
>
>Given your unavoidable statement above, I fully agree.
>Now an interesting question is: why not encapsulate completely this
>data-awaiting thread so that its threadedness doesn't appear at the Tcl
>level, just like the socket example you give (or, for that matter, any
>audio I/O on Windoze) ? ...

>only if *tclish* things happen in different threads. While here, the
>thread could just blockingly read to a channel buffer, and then signal
>an event which would be used (from the main Tcl thread) by the notifier
>via WiatForMultipleObject. So this thing could easily be backported to
>8.02 (or 3), despite the thread implied. What do you think ? Any takers
>?
Alex, this is exactly the case with the expect on NT changes.
Gordon Chaffe implemented it as "hidden" threads and patched the
tcl8.0 /win-core (In the thread function there is a blocking
ReadFile() and via a special message the main thread is notified).
So the good message is, it's already done for Tcl8.0.
What I did is to adapt the source to the tcl8.0p2 distribution
( 10yy p and cp tclWinReader.c /tcldev/tcl8.0p2/win/tclwinreader.c :-),
the expect on NT distribution only includes tcl8.0 .
Currently I play a little bit with the thing to test some cases,
cause I want to use it in an app for a customer.
If the app for the customer is ready, I make the handy patch and will
post it here.
I don't know if I will be able to do it before the Tcl-conference, but
I promise it at least for this year...
(note:promises of free beer let me work faster :-)

Regards , Leo


>Sorry - no time to verify; maybe Expect's solution is close to the one
>sketched above... :)

It's the same principle, you are right

lvi...@cas.org

unread,
Aug 1, 1998, 3:00:00 AM8/1/98
to

According to Robin Becker <ro...@jessikat.demon.co.uk>:
:I didn't start the secretive stuff I just commented on it.

And I didn't mean to imply that you did - sorry.

:Your reaction to my libertarianism is revealing.

Yup - but it's only revealing about me - not Scriptics.

:Scriptics doesn't need defending if it maintains the open developement


:model; this would be seen by nearly everyone as a 'good' thing.

And they've never asked me to defend them. Sorry if that didn't
come across.

:>information? There are many companies who happen to occasionally monitor


:>a usenet group but don't have time to spend 10+ hrs a day reading and
:>replying to every message on a newsgroup.
:>
:coming from you Larry that's good :)

Yes. Thank goodness for a family who put up with me hogging the only
web machine ...

:it is in Scriptics' own interest that a concensus language is developed;


:the alternative is in JO's own terms that the users will have to vote
:for more than one Tcl; splitting the vote isn't good.

I don't know if I agree with this or not - however I am more than willing
to leave it at this time or move it off line if someone wants to discuss
further. At this point, I feel I probably have over reacted to the
perceived intentions between the lines and further ranting on my part just
makes me look stupider than I already do. I apologize if I've offended you
Robin - I really appreciate all your contributions and never intended to
insult you, Alex, or anyone else in this thread. Sometimes I get out of
hand. I guess I know where my kids get it now...

Alexandre Ferrieux

unread,
Aug 2, 1998, 3:00:00 AM8/2/98
to
Larry wrote:

> I really appreciate all your contributions and never intended to
> insult you, Alex, or anyone else in this thread.

No offense :)

-A


>


Alexandre Ferrieux

unread,
Aug 2, 1998, 3:00:00 AM8/2/98
to Leo Schubert

Leo Schubert wrote:

> On Thu, 30 Jul 1998 12:52:24 +0200, Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> wrote:
> >Leo Schubert wrote:
> >>
> So the good message is, it's already done for Tcl8.0.
> What I did is to adapt the source to the tcl8.0p2 distribution
> ( 10yy p and cp tclWinReader.c /tcldev/tcl8.0p2/win/tclwinreader.c :-),
> the expect on NT distribution only includes tcl8.0 .
> Currently I play a little bit with the thing to test some cases,
> cause I want to use it in an app for a customer.
> If the app for the customer is ready, I make the handy patch and will
> post it here.
> I don't know if I will be able to do it before the Tcl-conference, but
> I promise it at least for this year...

> (note:promises of free beer let me work faster :-)

>
>

Hey, this is great !!!
Don't you think having it done before the CD freeze data would be an enormous gain ?
Tcl's credibility in highly Windoze-biased environments strongly depends on strict protability, one key
point being tat nasty Win* sub-feature. Larry, Cameron, can you say something ? Send beer ? Scott, could you
use his solution ? Needn't be fully tested for the release, since the current state is *no* feature at all
:).
Pleas guys, come on... Missing this one would be too bad !

-Alex

Robin Becker

unread,
Aug 2, 1998, 3:00:00 AM8/2/98
to
In article <6q0752$h5s$1...@srv38s4u.cas.org>, lvi...@cas.org writes

...
>:it is in Scriptics' own interest that a concensus language is developed;
>:the alternative is in JO's own terms that the users will have to vote
>:for more than one Tcl; splitting the vote isn't good.
>
>I don't know if I agree with this or not - however I am more than willing
>to leave it at this time or move it off line if someone wants to discuss
>further. At this point, I feel I probably have over reacted to the
>perceived intentions between the lines and further ranting on my part just
>makes me look stupider than I already do. I apologize if I've offended you
>Robin - I really appreciate all your contributions and never intended to
>insult you, Alex, or anyone else in this thread. Sometimes I get out of
>hand. I guess I know where my kids get it now...
>
no apology was required as no offence was taken; my defence against your
non attack also reveals my origin as an old style programmer. If it
worked we used to duplicate the card deck and give it away to anyone
around. I guess 30 years have gone by and I've stood still.

I used to imagine that better computers would drive software costs to
zero; I suppose we'll have to wait for real progress (ie true AI) before
they finish us off completely.

A little passion is no bad thing; if it's worth attacking it's probably
worth defending.

As for family, I sure wish I had one left to alienate :(
--
Robin Becker

Cameron Laird

unread,
Aug 3, 1998, 3:00:00 AM8/3/98
to
In article <35BD8E...@cnet.francetelecom.fr>,
Alexandre Ferrieux <alexandre...@cnet.francetelecom.fr> wrote:
.
.
.

>But I'm afraid this highlights a sad point: the 'business model' of the
>pair {TclPro,Tcl core} is really weird. When I saw the Tcl Consortium
My impression is that Scriptics is aiming
more for "innovative" than "weird". Anyone
plan to hear John's talk, "Free Software
Needs Profit?" in San Jose on the 21st?
RMS is on the agenda just a few hours later,
by the way; it ought to be interesting.

>manifesto, I thought it was great, because it seemed to adequately
>decouple the free software community from the specific Scriptic
>business. In my idea, JO's (and other's) contribution to Tcl would be
>done through the Consortium, while the Scriptics story guaranteed his
>interest in not seeing Tcl drift away towards some MS-like bloatware.
>But apparently I am massively wrong :(
The Consortium welcomes at least some
volunteer efforts. Tell 'em what they
should be doing; there's a fair chance
they'll agree to the point of letting
"outsiders" do the work. The Director
of the Consortium, by the way, is former
Vice President of the FSF and former
Executive Director of Usenix. The Con-
sortium certainly understands the big
ideas.
.
.

.
>I'm afraid it's not the availability which is under scrutiny, but its
>spatial derivative :), since some people seem to have better access than
>other. Now you already told us about Tclburn. It's just that Mr Hobbs
Right. I find it more fruitful to see
in these data personal style and indi-
vidual priorities rather than collective
secretiveness. I like your point that
examination of the first partials helps
diagnose community health, though.
.
.
.

Bryan Oakley

unread,
Aug 3, 1998, 3:00:00 AM8/3/98
to
Cameron Laird wrote:
> My impression is that Scriptics is aiming
> more for "innovative" than "weird". Anyone
> plan to hear John's talk, "Free Software
> Needs Profit?" in San Jose on the 21st?
> RMS is on the agenda just a few hours later,
> by the way; it ought to be interesting.

Gee, I would *love* to hear that! Kinda problematic since I don't live
anywhere close to Silicon Valley. Oh well. Sure would be great if they
would broadcast that over readaudio.


--
Bryan Oakley
ChannelPoint, Inc.

Cameron Laird

unread,
Aug 4, 1998, 3:00:00 AM8/4/98
to
In article <6q4jje$6ci$1...@Starbase.NeoSoft.COM>, I remarked:
.
.
.

>more for "innovative" than "weird". Anyone
>plan to hear John's talk, "Free Software
>Needs Profit?" in San Jose on the 21st?
.
.
.
I've been asked for details. <URL:http://
opensource.oreilly.com/townmeet.html> is all
I've been able to track down so far. The
panelists have already set their topics, I
know, and I'll pass those on once I have an
authoritative source for 'em.

Karsten M. Self

unread,
Aug 4, 1998, 3:00:00 AM8/4/98
to

Thanks, I hadn't seen this yet.

On the panelists, among the names familiar to the OSS/FSF crowd, is
Pamela Samuelson. She is a leading intellectual property (IP) law
expert, who has written several influential papers questioning the
applicability of copyright and patent law as they currently stand to
the software industry. She is controversial, but highly respected, with
articles published in law journals, Proceedings of the ACM, Wired, and
other popular and technical periodicals.

She has a website with additional biographical information and several
published papers here: http://www.sims.berkeley.edu/~pam/

I've been trying to round her up for her impressions of OSS, as have
several others. I'm thrilled that Tim O'Reilly and/or cohorts have
succeeded.

--
Karsten M. Self (kms...@ix.netcom.com)

What part of "gestalt" don't you understand?
Welchen Teil von "gestalt" verstehen Sie nicht?

web: http://www.netcom.com/~kmself
SAS/Linux: http://www.netcom.com/~kmself/SAS/SAS4Linux.html

10:41am up 52 days, 8:10, 3 users, load average: 1.12, 1.14, 1.17

Cameron Laird

unread,
Aug 4, 1998, 3:00:00 AM8/4/98
to
In article <6q6sbk$lmq$1...@Starbase.NeoSoft.COM>, I promised:

> .
> .
>I've been asked for details. <URL:http://
>opensource.oreilly.com/townmeet.html> is all
>I've been able to track down so far. The
>panelists have already set their topics, I
>know, and I'll pass those on once I have an
>authoritative source for 'em.
.
.
.
Agenda: <URL:http://opensource.oreilly.com/osdd/>.
Reply all
Reply to author
Forward
0 new messages