You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
|
Feb
|
Mar
(4) |
Apr
(5) |
May
(4) |
Jun
(1) |
Jul
(2) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
2003 |
Jan
(1) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
2004 |
Jan
|
Feb
(6) |
Mar
(1) |
Apr
|
May
(6) |
Jun
|
Jul
(1) |
Aug
(3) |
Sep
|
Oct
|
Nov
(7) |
Dec
(9) |
2005 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(5) |
Nov
(1) |
Dec
|
2009 |
Jan
|
Feb
|
Mar
(7) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: SourceForge.net <no...@so...> - 2004-11-09 17:17:39
|
Bugs item #1060620, was opened at 2004-11-04 16:24 Message generated for change (Comment added) made by andreas_kupries You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=1060620&group_id=34191 Category: 40. memchan Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Stephen Huntley (blacksqr) >Assigned to: Pat Thoyts (patthoyts) Summary: md5 -channel chokes on memchan Initial Comment: Version 2 of the md5 package has a -channel option, which works for file channels, but hangs when tried with a memchan. ActiveState Tcl 8.4.7 on Win2000. % package require md5 2 % package require vfs % set chan [vfs::memchan] % puts $chan "hello" % seek $chan 0 % md5::md5 -channel $chan ---------------------------------------------------------------------- >Comment By: Andreas Kupries (andreas_kupries) Date: 2004-11-09 09:17 Message: Logged In: YES user_id=75003 I had a look at the code, cvs log and cvs blame. It seems that this code has been in memchan since the beginning. I.e. there is no intervening bugfix or something I thought could have been there. That is good. It most likely means that the change can be done without problems. Pat, I approve of your change, however please make not only this change. Extend the testsuite as well to cover this case and bug. Not only the bad result from the eof as shown in your test script in the comments. I believe we should also have a test case which shows how the fileevents themselves stop working. Do you also have Tcl 8.[23] around ? It would be good to check if these combinations are good or bad as well, with and witohut the change. The stacked channel stuff did change in various minor revisions and while memchan is not a stacked channel the differences might still have a subtle effect on regular channels as well. ---------------------------------------------------------------------- Comment By: Pat Thoyts (patthoyts) Date: 2004-11-09 02:20 Message: Logged In: YES user_id=202636 The following patch fixes this for memchan with md5. It causes the channel to fire another fileevent once we get to the end. This should make it act like a socket I think. --- generic/memchan.c 3 Jun 2004 19:02:57 -0000 1.22 +++ generic/memchan.c 9 Nov 2004 10:18:07 -0000 @@ -528,7 +528,7 @@ return; } - if (chan->rwLoc >= chan->used) + if (chan->rwLoc > chan->used) mask &= ~TCL_READABLE; /* Tell Tcl about the possible events. ---------------------------------------------------------------------- Comment By: Pat Thoyts (patthoyts) Date: 2004-11-09 02:08 Message: Logged In: YES user_id=202636 To continue: the md5 code works correctly on file channels and socket channels. So I belive [memchan] to be incorrect. ---------------------------------------------------------------------- Comment By: Pat Thoyts (patthoyts) Date: 2004-11-09 01:20 Message: Logged In: YES user_id=202636 This pares down to the following difference in behaviour between a file channel and a memory channel. set f [open zxcv.txt w]; puts $f Hello; close $f set f [open zxcv.txt r] set m [memchan]; puts $m Hello; seel $m 0 We now have two channels at seek pos 0 with the same data. % list [eof $f] [eof $m] 0 0 % read $f 4096 ; read $m 4096 (same data returned for each channel) % list [eof $f] [eof $m] 1 0 The md5 command is using fileevents - I think that once we have got to this point there will be no more fileevents, so the if {[eof]} section is never called and we vwait forever. memchan.c: 513 contains the following hint: /* * In-memory channels are always writable (fileevent * writable) and they are readable if the current access * point is before the last byte contained in the channel. */ We are going to be beyond this point. So it appears that the following will always fail to terminate... proc handler {chan} { if {[eof $chan]} { set stop 1 } set data [read $chan] } set chan [memchan] # fill memchan with something fileevent $chan readable [list handle $chan] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=1060620&group_id=34191 |
From: SourceForge.net <no...@so...> - 2004-11-09 10:20:59
|
Bugs item #1060620, was opened at 2004-11-05 00:24 Message generated for change (Comment added) made by patthoyts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=1060620&group_id=34191 Category: 40. memchan Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephen Huntley (blacksqr) Assigned to: Andreas Kupries (andreas_kupries) Summary: md5 -channel chokes on memchan Initial Comment: Version 2 of the md5 package has a -channel option, which works for file channels, but hangs when tried with a memchan. ActiveState Tcl 8.4.7 on Win2000. % package require md5 2 % package require vfs % set chan [vfs::memchan] % puts $chan "hello" % seek $chan 0 % md5::md5 -channel $chan ---------------------------------------------------------------------- >Comment By: Pat Thoyts (patthoyts) Date: 2004-11-09 10:20 Message: Logged In: YES user_id=202636 The following patch fixes this for memchan with md5. It causes the channel to fire another fileevent once we get to the end. This should make it act like a socket I think. --- generic/memchan.c 3 Jun 2004 19:02:57 -0000 1.22 +++ generic/memchan.c 9 Nov 2004 10:18:07 -0000 @@ -528,7 +528,7 @@ return; } - if (chan->rwLoc >= chan->used) + if (chan->rwLoc > chan->used) mask &= ~TCL_READABLE; /* Tell Tcl about the possible events. ---------------------------------------------------------------------- Comment By: Pat Thoyts (patthoyts) Date: 2004-11-09 10:08 Message: Logged In: YES user_id=202636 To continue: the md5 code works correctly on file channels and socket channels. So I belive [memchan] to be incorrect. ---------------------------------------------------------------------- Comment By: Pat Thoyts (patthoyts) Date: 2004-11-09 09:20 Message: Logged In: YES user_id=202636 This pares down to the following difference in behaviour between a file channel and a memory channel. set f [open zxcv.txt w]; puts $f Hello; close $f set f [open zxcv.txt r] set m [memchan]; puts $m Hello; seel $m 0 We now have two channels at seek pos 0 with the same data. % list [eof $f] [eof $m] 0 0 % read $f 4096 ; read $m 4096 (same data returned for each channel) % list [eof $f] [eof $m] 1 0 The md5 command is using fileevents - I think that once we have got to this point there will be no more fileevents, so the if {[eof]} section is never called and we vwait forever. memchan.c: 513 contains the following hint: /* * In-memory channels are always writable (fileevent * writable) and they are readable if the current access * point is before the last byte contained in the channel. */ We are going to be beyond this point. So it appears that the following will always fail to terminate... proc handler {chan} { if {[eof $chan]} { set stop 1 } set data [read $chan] } set chan [memchan] # fill memchan with something fileevent $chan readable [list handle $chan] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=1060620&group_id=34191 |
From: SourceForge.net <no...@so...> - 2004-11-09 10:08:27
|
Bugs item #1060620, was opened at 2004-11-05 00:24 Message generated for change (Comment added) made by patthoyts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=1060620&group_id=34191 Category: 40. memchan Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephen Huntley (blacksqr) Assigned to: Andreas Kupries (andreas_kupries) Summary: md5 -channel chokes on memchan Initial Comment: Version 2 of the md5 package has a -channel option, which works for file channels, but hangs when tried with a memchan. ActiveState Tcl 8.4.7 on Win2000. % package require md5 2 % package require vfs % set chan [vfs::memchan] % puts $chan "hello" % seek $chan 0 % md5::md5 -channel $chan ---------------------------------------------------------------------- >Comment By: Pat Thoyts (patthoyts) Date: 2004-11-09 10:08 Message: Logged In: YES user_id=202636 To continue: the md5 code works correctly on file channels and socket channels. So I belive [memchan] to be incorrect. ---------------------------------------------------------------------- Comment By: Pat Thoyts (patthoyts) Date: 2004-11-09 09:20 Message: Logged In: YES user_id=202636 This pares down to the following difference in behaviour between a file channel and a memory channel. set f [open zxcv.txt w]; puts $f Hello; close $f set f [open zxcv.txt r] set m [memchan]; puts $m Hello; seel $m 0 We now have two channels at seek pos 0 with the same data. % list [eof $f] [eof $m] 0 0 % read $f 4096 ; read $m 4096 (same data returned for each channel) % list [eof $f] [eof $m] 1 0 The md5 command is using fileevents - I think that once we have got to this point there will be no more fileevents, so the if {[eof]} section is never called and we vwait forever. memchan.c: 513 contains the following hint: /* * In-memory channels are always writable (fileevent * writable) and they are readable if the current access * point is before the last byte contained in the channel. */ We are going to be beyond this point. So it appears that the following will always fail to terminate... proc handler {chan} { if {[eof $chan]} { set stop 1 } set data [read $chan] } set chan [memchan] # fill memchan with something fileevent $chan readable [list handle $chan] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=1060620&group_id=34191 |
From: SourceForge.net <no...@so...> - 2004-11-09 09:22:42
|
Bugs item #924025, was opened at 2004-03-26 16:35 Message generated for change (Settings changed) made by patthoyts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=924025&group_id=34191 Category: None Group: v1.0 (example) Status: Open Resolution: None Priority: 5 Submitted By: Larry W. Virden (lvirden) >Assigned to: Andreas Kupries (andreas_kupries) Summary: latest cvs head configuration fails Initial Comment: When I use the latest cvs head memchan's configure, I notice these problems. Platform: sparc solaris, sun c compiler Tcl : tcl 8.4.6 - configured with --enable-symbols 1. When I configure memchan --enable-symbols, it doesn't find the tcl lib.a because it forgets to look to see if there is a libtcl*g.a or *g.so* version available. 2. Also, I notice in the configure script itself that the places it looks does not include the latest versions of tcl. 3. After I hack the configure script so that it finds libtcl*g.so , I discover that the Makefile generated does not set TCL_DBGX = g , which is needed so that the link step is able to find libtcl*g.so . ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-08-15 09:59 Message: Logged In: NO The latest cvs snapshot continues to have these problems - note also that when looking at the old tcl versions (8.3 and older only), memchan does not look for pieces in the same sequence. When looking for the generic directory, memchan's configure looks for tcl 8.2, then 8.3, then 8.2b and before. However, when looking for the unix directory, it looks for 8.3, then 8.2, then 8.2b, ... and finally, when looking for the libtcl, it looks at 8.3, then 8.2, ... lv...@ca... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=924025&group_id=34191 |
From: SourceForge.net <no...@so...> - 2004-11-09 09:20:54
|
Bugs item #1060620, was opened at 2004-11-05 00:24 Message generated for change (Comment added) made by patthoyts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=1060620&group_id=34191 Category: 40. memchan Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephen Huntley (blacksqr) Assigned to: Andreas Kupries (andreas_kupries) Summary: md5 -channel chokes on memchan Initial Comment: Version 2 of the md5 package has a -channel option, which works for file channels, but hangs when tried with a memchan. ActiveState Tcl 8.4.7 on Win2000. % package require md5 2 % package require vfs % set chan [vfs::memchan] % puts $chan "hello" % seek $chan 0 % md5::md5 -channel $chan ---------------------------------------------------------------------- >Comment By: Pat Thoyts (patthoyts) Date: 2004-11-09 09:20 Message: Logged In: YES user_id=202636 This pares down to the following difference in behaviour between a file channel and a memory channel. set f [open zxcv.txt w]; puts $f Hello; close $f set f [open zxcv.txt r] set m [memchan]; puts $m Hello; seel $m 0 We now have two channels at seek pos 0 with the same data. % list [eof $f] [eof $m] 0 0 % read $f 4096 ; read $m 4096 (same data returned for each channel) % list [eof $f] [eof $m] 1 0 The md5 command is using fileevents - I think that once we have got to this point there will be no more fileevents, so the if {[eof]} section is never called and we vwait forever. memchan.c: 513 contains the following hint: /* * In-memory channels are always writable (fileevent * writable) and they are readable if the current access * point is before the last byte contained in the channel. */ We are going to be beyond this point. So it appears that the following will always fail to terminate... proc handler {chan} { if {[eof $chan]} { set stop 1 } set data [read $chan] } set chan [memchan] # fill memchan with something fileevent $chan readable [list handle $chan] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=1060620&group_id=34191 |
From: SourceForge.net <no...@so...> - 2004-11-05 00:24:58
|
Bugs item #1060620, was opened at 2004-11-04 18:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=1060620&group_id=34191 Category: 40. memchan Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephen Huntley (blacksqr) Assigned to: Andreas Kupries (andreas_kupries) Summary: md5 -channel chokes on memchan Initial Comment: Version 2 of the md5 package has a -channel option, which works for file channels, but hangs when tried with a memchan. ActiveState Tcl 8.4.7 on Win2000. % package require md5 2 % package require vfs % set chan [vfs::memchan] % puts $chan "hello" % seek $chan 0 % md5::md5 -channel $chan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=1060620&group_id=34191 |
From: <aku...@sh...> - 2004-08-20 03:32:27
|
11'th Annual Tcl/Tk Conference October 11 - 15, 2004 New Orleans, Louisiana, USA Email Contact tc...@tc... We are pleased to announce the 11'th Annual Tcl/Tk conference (Tcl'2004), sponsored by Noumena Corporation, in cooperation with ActiveState and ExpoTech. Come to New Orleans to: * Learn about the power of Tcl/Tk. * Present exciting new work involving Tcl/Tk. * See the latest developments in Tcl/Tk. * Meet Tcl/Tk researchers and users from academia, government and industry. * Plan for future Tcl/Tk related developments. The conference program will include paper presentations, tutorials, Birds of a Feather (BOF) sessions and invited key-note talks. Registration Online registration is ready now. <http://www.tcl.tk/community/tcl2004/reg.html> Tutorials Come learn about Tcl from the experts. This year's Tcl/Tk Conference includes one of the best sets of Tutorials ever offered including tutorials on Jacl, TclHttpd, Starkit, Advanced GUI construction, and the API. <http://www.tcl.tk/community/tcl2004/tut2004.html> Schedule More details will be added to the schedule as they become available. <http://www.tcl.tk/community/tcl2004/schedule.html> Those attending the conference will be interested in the conference info page. <http://www.tcl.tk/community/tcl2004/info.html> To keep in touch with news regarding the conference and Tcl events in general, subscribe to the tcl-announce list. <http://listserv.activestate.com/mailman/mysubs?show=announce> Other Forms of Participation For those who are not presenting a paper at the conference, but would like to present their work in some form, we do provide several other forms of participation. Slots for Works-in-Progress (WIP) presentations and Birds-of-a-Feather sessions (BOFs) are available on a first-come, first-served basis by sending email to tc...@tc.... Some WIP and BOF time slots will be held open for on-site reservation, so we encourage all attendees with interesting work in progress to consider presenting that work at the conference. Conference Committee Gerald Lester HMS Software General Chair Andreas Kupries ActiveState Corp Clif Flynt Noumena Corp Website Admin Jeffrey Hobbs ActiveState Corp Kevin Kenny GE Global Research Center Ken Jones Avia Training Mac Cody Raytheon Company Kim Richerts Steve Landers Digital Smarties Sheila Miguez Motorola Larry Virden Tcl FAQ Maintainer Contact Information tc...@tc... |
From: SourceForge.net <no...@so...> - 2004-08-15 09:00:09
|
Bugs item #924025, was opened at 2004-03-26 08:35 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=924025&group_id=34191 Category: None Group: v1.0 (example) Status: Open Resolution: None Priority: 5 Submitted By: Larry W. Virden (lvirden) Assigned to: Nobody/Anonymous (nobody) Summary: latest cvs head configuration fails Initial Comment: When I use the latest cvs head memchan's configure, I notice these problems. Platform: sparc solaris, sun c compiler Tcl : tcl 8.4.6 - configured with --enable-symbols 1. When I configure memchan --enable-symbols, it doesn't find the tcl lib.a because it forgets to look to see if there is a libtcl*g.a or *g.so* version available. 2. Also, I notice in the configure script itself that the places it looks does not include the latest versions of tcl. 3. After I hack the configure script so that it finds libtcl*g.so , I discover that the Makefile generated does not set TCL_DBGX = g , which is needed so that the link step is able to find libtcl*g.so . ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-08-15 01:59 Message: Logged In: NO The latest cvs snapshot continues to have these problems - note also that when looking at the old tcl versions (8.3 and older only), memchan does not look for pieces in the same sequence. When looking for the generic directory, memchan's configure looks for tcl 8.2, then 8.3, then 8.2b and before. However, when looking for the unix directory, it looks for 8.3, then 8.2, then 8.2b, ... and finally, when looking for the libtcl, it looks at 8.3, then 8.2, ... lv...@ca... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=924025&group_id=34191 |
From: SourceForge.net <no...@so...> - 2004-08-04 13:58:42
|
Bugs item #996078, was opened at 2004-07-22 19:21 Message generated for change (Comment added) made by patthoyts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=996078&group_id=34191 Category: 21. fifo2 Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Andreas Kupries (andreas_kupries) Summary: Potential Segmentation Violation In Mutex Allocation Initial Comment: In the subroutine MemchanFifo2Cmd the author needs to null (zero set) the value of the dynamically allocated Tcl_Mutex (ChannelLock structure) on a thread-enabled compile. Example: instanceA->lock = (ChannelLock*) Tcl_Alloc (sizeof(ChannelLock)); Additional code: memset((ChannelLock*)instanceA->lock, 0, sizeof (ChannelLock)); The core tcl library function expects the contents of a mutex to == NULL so that the first time in a lock it will allocate a pthread_mutex_t structure. The fifo2 code failed on the first call to a fifo2 handle write, and on exit (channel cleanup/Tcl_MutexFinalize) because of a call to ckfree on a null pointer. The code failed on aix 5.1, irix 6.5.1, sunos 5.9, and linux redhat running tcl 8.4.2 thread enabled tclsh. The addition of the memset command fixed the problem. Thanks, Jeff Gilbertson Email: ku...@sg... ---------------------------------------------------------------------- >Comment By: Pat Thoyts (patthoyts) Date: 2004-08-04 14:58 Message: Logged In: YES user_id=202636 I couldn't reproduce this as a bug with tcl8.5 threaded. However this is a sensible fix so I've applied it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=996078&group_id=34191 |
From: SourceForge.net <no...@so...> - 2004-07-22 18:21:12
|
Bugs item #996078, was opened at 2004-07-22 11:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=996078&group_id=34191 Category: 21. fifo2 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Andreas Kupries (andreas_kupries) Summary: Potential Segmentation Violation In Mutex Allocation Initial Comment: In the subroutine MemchanFifo2Cmd the author needs to null (zero set) the value of the dynamically allocated Tcl_Mutex (ChannelLock structure) on a thread-enabled compile. Example: instanceA->lock = (ChannelLock*) Tcl_Alloc (sizeof(ChannelLock)); Additional code: memset((ChannelLock*)instanceA->lock, 0, sizeof (ChannelLock)); The core tcl library function expects the contents of a mutex to == NULL so that the first time in a lock it will allocate a pthread_mutex_t structure. The fifo2 code failed on the first call to a fifo2 handle write, and on exit (channel cleanup/Tcl_MutexFinalize) because of a call to ckfree on a null pointer. The code failed on aix 5.1, irix 6.5.1, sunos 5.9, and linux redhat running tcl 8.4.2 thread enabled tclsh. The addition of the memset command fixed the problem. Thanks, Jeff Gilbertson Email: ku...@sg... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=996078&group_id=34191 |
From: SourceForge.net <no...@so...> - 2004-05-22 09:11:09
|
Bugs item #681115, was opened at 2003-02-05 18:07 Message generated for change (Comment added) made by patthoyts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=681115&group_id=34191 Category: 01. documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Larry W. Virden (lvirden) Assigned to: Nobody/Anonymous (nobody) Summary: doc target in makefile should have a dependency on doc files Initial Comment: when one does a make in memchan, the library is built and the documentation is generated. when one does a make install , the documentation is generated again. if the doc target was dependant on the doc files, then the doc generation should only occur once. ---------------------------------------------------------------------- >Comment By: Pat Thoyts (patthoyts) Date: 2004-05-22 10:11 Message: Logged In: YES user_id=202636 I have added such a dependency. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=681115&group_id=34191 |
From: SourceForge.net <no...@so...> - 2004-05-22 00:37:59
|
Support Requests item #574853, was opened at 2002-06-28 00:00 Message generated for change (Comment added) made by patthoyts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410296&aid=574853&group_id=34191 Category: 10. compilation/configuration Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Andreas Kupries (andreas_kupries) Summary: missing symbols at link time Initial Comment: MS vc++ 6.0 tcl 8.4b1 I cvsuped memchan, gave it this command line : c:\devel\vcvars32 & nmake /f makefile.vc DEST_DIR=c:\progra~1\tcl TCL=c:\progra~1\tcl TCLLIB=c:\progra~1\tcl\lib\tcl84.lib TOOLS32=C:\Progra~1\Micros~3\VC98 And got this error : C:\Progra~1\Micros~3\VC98\bin\link.exe /RELEASE /NODEFAULTLIB /RELEASE /NOLOGO -align:0x1000 /MACHINE:IX86 -entry:_DllMainCRTStartup@12 -dll c:\progra~1\tcl\lib\tcl84.lib msvcrt.lib oldnames.lib kernel32.lib advapi32.lib user32.lib gdi32.lib comdlg32.lib winspool.lib -out:memchan@mShortDosVersion@.dll .\memchan.obj .\fifo.obj .\init.obj .\counter.obj .\dllEntry.obj LINK : warning LNK4108: /ALIGN specified without /DRIVER or /VXD; image may not run Creating library memchan@mShortDosVersion@.lib and object memchan@mShortDosVersion@.exp fifo.obj : error LNK2001: unresolved external symbol _Buf_FreeQueue fifo.obj : error LNK2001: unresolved external symbol _Buf_QueueRead fifo.obj : error LNK2001: unresolved external symbol _Buf_QueueWrite fifo.obj : error LNK2001: unresolved external symbol _Buf_NewQueue init.obj : error LNK2001: unresolved external symbol _Buf_Init init.obj : error LNK2001: unresolved external symbol _bufStubs init.obj : error LNK2001: unresolved external symbol _MemchanNullCmd init.obj : error LNK2001: unresolved external symbol _MemchanFifo2Cmd memchan@mShortDosVersion@.dll : fatal error LNK1120: 8 unresolved externals NMAKE : fatal error U1077: 'C:\Progra~1\Micros~3\VC98\bin\link.exe' : return code '0x460' Stop. Whast am I doing wrong? ---------------------------------------------------------------------- >Comment By: Pat Thoyts (patthoyts) Date: 2004-05-22 01:37 Message: Logged In: YES user_id=202636 MSVC makefiles have been updated now. ---------------------------------------------------------------------- Comment By: Winfried Harbecke (harbecke) Date: 2003-11-20 16:27 Message: Logged In: YES user_id=913663 Using the Release download of memchan2.2a4 and Vc7 (Visual Studio .NET) I get the same messages. After changing the following two definitions in $(ROOT)/win/makefile.vc TCLLIB = $(TCL)\lib\tcl84.lib $(TCL)\lib\tcl84s.lib MCOBJS = $(TMPDIR)\init.obj $(TMPDIR) \counter.obj $(TMPDIR)\memchan.obj $(TMPDIR)\fifo.obj $(TMPDIR)\fifo2.obj $(TMPDIR)\null.obj $(TMPDIR)\buf.obj $(TMPDIR)\bufQueue.obj $(TMPDIR)\bufRange.obj $(TMPDIR) \bufExt.obj $(TMPDIR)\bufFix.obj $(TMPDIR)\bufStubInit.obj $(TMPDIR)\bufStubLib.obj $(TMPDIR)\dllEntry.obj the compilation just produced the following warnings ..\generic\counter.c(61) : warning C4013: 'ltoa' undefiniert; Annahme: extern mit R?ckgabetyp int ..\generic\memchan.c(392) : warning C4013: 'ltoa' undefiniert; Annahme: extern mit R?ckgabetyp int ..\generic\fifo.c(314) : warning C4013: 'ltoa' undefiniert; Annahme: extern mit R?ckgabetyp int ..\generic\fifo2.c(529) : warning C4013: 'ltoa' undefiniert; Annahme: extern mit R?ckgabetyp int LINK : warning LNK4108: /ALIGN wurde ohne /DRIVER oder /VXD angegeben; Anwendung kann vielleicht nicht ausgefuehrt werden Apparently, all the makefiles in $(ROOT)/win are out of date. C4013 is the classic missing <math.h>, and I assume Andreas intends the /ALIGN to ease core dump debugging, but Microsoft does not grant that anymore. ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2002-07-01 02:19 Message: Logged In: YES user_id=75003 The main problem I see is that a number of object files are missing from the link line. Namely: fifo2.obj, and all buf*.obj I would like to know which makefile was used to compile memchan. It could be that some of them are not completely upto date. If you find that the makefile is not uptodate please file a bug report. Also note a snapshot of the CVS, i.e. something generated by CVSup or similar is not the same as a compileable source distribution. See http://sourceforge.net/docman/display_doc.php?docid=6354&group_id=34191 for more. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410296&aid=574853&group_id=34191 |
From: SourceForge.net <no...@so...> - 2004-05-22 00:35:56
|
Patches item #900771, was opened at 2004-02-19 23:53 Message generated for change (Comment added) made by patthoyts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410297&aid=900771&group_id=34191 Category: 40. memchan Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Pat Thoyts (patthoyts) Assigned to: Andreas Kupries (andreas_kupries) Summary: Updated build files for Win32 Initial Comment: Update Memchan win32 build files for modern VC setup. These are the *.vc files from the Tcl sampleextension. makefile.vc - modified rules.vc - new nmakehlp.c - new Also a slight change the the memchan resource file so it acually works. This file is actually built by cvs diff -u > win32-update.patch diff -u NUL win/rules.vc >> win32-update.patch diff -u NUL win/nmakehlp.c >> win32-update.patch so hopefully it will patch ok. Pat Thoyts. ---------------------------------------------------------------------- >Comment By: Pat Thoyts (patthoyts) Date: 2004-05-22 01:35 Message: Logged In: YES user_id=202636 Applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410297&aid=900771&group_id=34191 |
From: SourceForge.net <no...@so...> - 2004-05-22 00:35:02
|
Patches item #903121, was opened at 2004-02-24 00:55 Message generated for change (Comment added) made by patthoyts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410297&aid=903121&group_id=34191 Category: 40. memchan Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Pat Thoyts (patthoyts) Assigned to: Andreas Kupries (andreas_kupries) Summary: Implementation of random channel Initial Comment: This patch implements the [random] channel. The PRNG is the ISAAC algorithm which has a reasonable period but is cryptographically secure -- unlike the Mersenne Twister which has a longer period but is not secure. The ISAAC implementation is public domain and I have placed these files in an isaac/ subdirectory. The tcl specific code is in generic/. This patch file also includes the Windows nmake makefile modifications that are in the earlier patch. Tested on Win2K and OpenBSD. Usage is as described in the random man page. reads from the channel will yield random bytes. A good example of rapidly generating values is binary scan [read $f 64] c* values or binary scan [read $f 64] I* values Writes to the channel cause a re-seeding of the PRNG state. I have chosen to XOR the input data so as to make it as non-deterministic as possible. An alternative would be to zero the state and then set the input bytes which would give a more predictable result (as we currently get with [expr {srand(2)}]; [expr {rand()}] ...) ---------------------------------------------------------------------- >Comment By: Pat Thoyts (patthoyts) Date: 2004-05-22 01:35 Message: Logged In: YES user_id=202636 Applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410297&aid=903121&group_id=34191 |
From: SourceForge.net <no...@so...> - 2004-05-22 00:33:43
|
Bugs item #528480, was opened at 2002-03-11 13:10 Message generated for change (Comment added) made by patthoyts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=528480&group_id=34191 Category: 40. memchan Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Andreas Kupries (andreas_kupries) Summary: build fails Initial Comment: I get the following problems. In particular, one error, that 'EWOULDBLOCK' is not defined. This is with VC++5.2 on Windows 2000sp2. Vince. c:\progra~1\devstudio\vc\bin\cl.exe -Ox -c - W3 -nologo -YX -Dtry=__try - Dexcept=__except -D_X86_=1 -DWIN32 -D_WIN32 -D_MT - D_DLL -Ic:\progra~1\devstudio \vc\include -I..\win -I..\generic -I.. -Ic:\progra~1 \tcl\include -nologo -D__WI N32__ -DHAVE_STDLIB_H - DMEMCHAN_VERSION=\@mFullVersion@\ -DBUILD_Memchan - DDL L_BUILD -DHAVE_LTOA -Fo.\ ..\generic\memchan.c memchan.c ..\generic\memchan.c(191) : error C2065: 'EWOULDBLOCK' : undeclared identifier ..\generic\memchan.c(313) : warning C4244: '=' : conversion from '__int64 ' to ' long ', possible loss of data ..\generic\memchan.c(317) : warning C4244: '=' : conversion from '__int64 ' to ' long ', possible loss of data ..\generic\memchan.c(321) : warning C4244: '=' : conversion from '__int64 ' to ' long ', possible loss of data ..\generic\memchan.c(400) : warning C4013: 'ltoa' undefined; assuming extern ret urning int ---------------------------------------------------------------------- >Comment By: Pat Thoyts (patthoyts) Date: 2004-05-22 01:33 Message: Logged In: YES user_id=202636 MSVC build files have been updated to support building with MSVC++ 6 or 7. ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2002-10-16 21:17 Message: Logged In: YES user_id=75003 The current head of memchan compiles on Windows, using the TEA build. A 'configure' is part of the distribution (toplevel directory). CONST problems should be gone. No changes have been made to the Windows makefile.vc, so this is likely still out of date. ... The link line does not contain fifo2, nor the buf*.obj files. ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2002-03-11 13:22 Message: Logged In: YES user_id=32170 I can fix the above by adding '#include "tclPort.h"' to the memchanInt.h file, but then get these errors: c:\progra~1\devstudio\vc\bin\cl.exe -Ox -c -W3 - nologo -YX -Dtry=__try - Dexcept=__except -D_X86_=1 -DWIN32 -D_WIN32 -D_MT -D_DLL - Ic:\progra~1\devstudio \vc\include -I..\win -I..\generic -I.. -Ic:\tcl- source/tcl8.4/generic -nologo - D__WIN32__ -DHAVE_STDLIB_H - DMEMCHAN_VERSION=\@mFullVersion@\ -DBUILD_Memchan -DDLL_BUILD -DHAVE_LTOA -Fo.\ ..\generic\init.c init.c ..\generic\init.c(61) : error C2491: 'Memchan_Init' : definition of dllimport fu nction not allowed ..\generic\init.c(126) : error C2491: 'Memchan_SafeInit' : definition of dllimpo rt function not allowed (as well as some CONST problems). I can then fix these errors if I replace the 'EXTERN (int,Memchan_Init)' by 'int Memchan_Init', but then I finally run into this while linking: c:\progra~1 \devstudio\vc\bin\link.exe /RELEASE /NODEFAULTLIB /RELEASE /NOLOGO -align:0x1000 /MACHINE:IX86 - entry:_DllMainCRTStartup@12 -dll c:\prog ra~1\tcl\lib\tcl84.lib c:\progra~1 \devstudio\vc\lib\msvcrt.lib c:\progra~1\devst udio\vc\lib\oldnames.lib c:\progra~1 \devstudio\vc\lib\kernel32.lib c:\prog ra~1\devstudio\vc\lib\advapi32.lib c:\progra~1 \devstudio\vc\lib\user32.lib c:\pr ogra~1\devstudio\vc\lib\gdi32.lib c:\progra~1 \devstudio\vc\lib\comdlg32.lib c:progra~1\devstudio\vc\lib\winspool.lib .\mc.res - out:memchan@mShortDosV ersion@.dll .\memchan.obj .\fifo.obj .\i nit.obj .\count er.obj .\dllEntry.obj fifo.obj : error LNK2001: unresolved external symbol __imp__Buf_FreeQueue fifo.obj : error LNK2001: unresolved external symbol __imp__Buf_QueueRead fifo.obj : error LNK2001: unresolved external symbol __imp__Buf_QueueWrite fifo.obj : error LNK2001: unresolved external symbol __imp__Buf_NewQueue init.obj : error LNK2001: unresolved external symbol __imp__Buf_Init init.obj : error LNK2001: unresolved external symbol _bufStubs init.obj : error LNK2001: unresolved external symbol _MemchanNullCmd init.obj : error LNK2001: unresolved external symbol _MemchanFifo2Cmd memchan@mShortDosVersion@.dll : fatal error LNK1120: 8 unresolved externals So, finally I tried the tea stuff, but that didn't do any better: cd tea $ autoconf NONE:0: /usr/bin/m4: Expecting line feed in frozen file the 'vfs' extension relies on memchan, which means it doesn't work at the moment... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=528480&group_id=34191 |
From: SourceForge.net <no...@so...> - 2004-05-21 22:08:41
|
Bugs item #903103, was opened at 2004-02-24 00:10 Message generated for change (Comment added) made by patthoyts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=903103&group_id=34191 Category: 70. website Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Pat Thoyts (patthoyts) Assigned to: Andreas Kupries (andreas_kupries) Summary: Images should be -kb Initial Comment: The following files should be marked as binary: htdocs/art/logo100.gif htdocs/art/logo100a.gif htdocs/art/logo520.jpg htdocs/art/logo64.gif htdocs/art/logo64a.gif Suggest: cvs admin -kb $file for each one. ---------------------------------------------------------------------- >Comment By: Pat Thoyts (patthoyts) Date: 2004-05-21 23:08 Message: Logged In: YES user_id=202636 Done. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=903103&group_id=34191 |
From: SourceForge.net <no...@so...> - 2004-03-26 16:35:32
|
Bugs item #924025, was opened at 2004-03-26 11:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=924025&group_id=34191 Category: None Group: v1.0 (example) Status: Open Resolution: None Priority: 5 Submitted By: Larry W. Virden (lvirden) Assigned to: Nobody/Anonymous (nobody) Summary: latest cvs head configuration fails Initial Comment: When I use the latest cvs head memchan's configure, I notice these problems. Platform: sparc solaris, sun c compiler Tcl : tcl 8.4.6 - configured with --enable-symbols 1. When I configure memchan --enable-symbols, it doesn't find the tcl lib.a because it forgets to look to see if there is a libtcl*g.a or *g.so* version available. 2. Also, I notice in the configure script itself that the places it looks does not include the latest versions of tcl. 3. After I hack the configure script so that it finds libtcl*g.so , I discover that the Makefile generated does not set TCL_DBGX = g , which is needed so that the link step is able to find libtcl*g.so . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=924025&group_id=34191 |
From: SourceForge.net <no...@so...> - 2004-02-24 01:05:46
|
Patches item #903121, was opened at 2004-02-24 00:55 Message generated for change (Settings changed) made by patthoyts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410297&aid=903121&group_id=34191 Category: 40. memchan Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pat Thoyts (patthoyts) >Assigned to: Andreas Kupries (andreas_kupries) Summary: Implementation of random channel Initial Comment: This patch implements the [random] channel. The PRNG is the ISAAC algorithm which has a reasonable period but is cryptographically secure -- unlike the Mersenne Twister which has a longer period but is not secure. The ISAAC implementation is public domain and I have placed these files in an isaac/ subdirectory. The tcl specific code is in generic/. This patch file also includes the Windows nmake makefile modifications that are in the earlier patch. Tested on Win2K and OpenBSD. Usage is as described in the random man page. reads from the channel will yield random bytes. A good example of rapidly generating values is binary scan [read $f 64] c* values or binary scan [read $f 64] I* values Writes to the channel cause a re-seeding of the PRNG state. I have chosen to XOR the input data so as to make it as non-deterministic as possible. An alternative would be to zero the state and then set the input bytes which would give a more predictable result (as we currently get with [expr {srand(2)}]; [expr {rand()}] ...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410297&aid=903121&group_id=34191 |
From: SourceForge.net <no...@so...> - 2004-02-24 01:05:20
|
Patches item #903121, was opened at 2004-02-24 00:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410297&aid=903121&group_id=34191 Category: 40. memchan Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pat Thoyts (patthoyts) Assigned to: Nobody/Anonymous (nobody) Summary: Implementation of random channel Initial Comment: This patch implements the [random] channel. The PRNG is the ISAAC algorithm which has a reasonable period but is cryptographically secure -- unlike the Mersenne Twister which has a longer period but is not secure. The ISAAC implementation is public domain and I have placed these files in an isaac/ subdirectory. The tcl specific code is in generic/. This patch file also includes the Windows nmake makefile modifications that are in the earlier patch. Tested on Win2K and OpenBSD. Usage is as described in the random man page. reads from the channel will yield random bytes. A good example of rapidly generating values is binary scan [read $f 64] c* values or binary scan [read $f 64] I* values Writes to the channel cause a re-seeding of the PRNG state. I have chosen to XOR the input data so as to make it as non-deterministic as possible. An alternative would be to zero the state and then set the input bytes which would give a more predictable result (as we currently get with [expr {srand(2)}]; [expr {rand()}] ...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410297&aid=903121&group_id=34191 |
From: SourceForge.net <no...@so...> - 2004-02-24 00:29:17
|
Bugs item #903103, was opened at 2004-02-24 00:10 Message generated for change (Settings changed) made by patthoyts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=903103&group_id=34191 Category: 70. website Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pat Thoyts (patthoyts) >Assigned to: Andreas Kupries (andreas_kupries) Summary: Images should be -kb Initial Comment: The following files should be marked as binary: htdocs/art/logo100.gif htdocs/art/logo100a.gif htdocs/art/logo520.jpg htdocs/art/logo64.gif htdocs/art/logo64a.gif Suggest: cvs admin -kb $file for each one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=903103&group_id=34191 |
From: SourceForge.net <no...@so...> - 2004-02-24 00:21:10
|
Bugs item #903103, was opened at 2004-02-24 00:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=903103&group_id=34191 Category: 70. website Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pat Thoyts (patthoyts) Assigned to: Nobody/Anonymous (nobody) Summary: Images should be -kb Initial Comment: The following files should be marked as binary: htdocs/art/logo100.gif htdocs/art/logo100a.gif htdocs/art/logo520.jpg htdocs/art/logo64.gif htdocs/art/logo64a.gif Suggest: cvs admin -kb $file for each one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=903103&group_id=34191 |
From: SourceForge.net <no...@so...> - 2004-02-20 00:01:19
|
Patches item #900771, was opened at 2004-02-19 23:53 Message generated for change (Settings changed) made by patthoyts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410297&aid=900771&group_id=34191 Category: 40. memchan Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pat Thoyts (patthoyts) >Assigned to: Andreas Kupries (andreas_kupries) Summary: Updated build files for Win32 Initial Comment: Update Memchan win32 build files for modern VC setup. These are the *.vc files from the Tcl sampleextension. makefile.vc - modified rules.vc - new nmakehlp.c - new Also a slight change the the memchan resource file so it acually works. This file is actually built by cvs diff -u > win32-update.patch diff -u NUL win/rules.vc >> win32-update.patch diff -u NUL win/nmakehlp.c >> win32-update.patch so hopefully it will patch ok. Pat Thoyts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410297&aid=900771&group_id=34191 |
From: SourceForge.net <no...@so...> - 2004-02-20 00:00:26
|
Patches item #900771, was opened at 2004-02-19 23:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410297&aid=900771&group_id=34191 Category: 40. memchan Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pat Thoyts (patthoyts) Assigned to: Nobody/Anonymous (nobody) Summary: Updated build files for Win32 Initial Comment: Update Memchan win32 build files for modern VC setup. These are the *.vc files from the Tcl sampleextension. makefile.vc - modified rules.vc - new nmakehlp.c - new Also a slight change the the memchan resource file so it acually works. This file is actually built by cvs diff -u > win32-update.patch diff -u NUL win/rules.vc >> win32-update.patch diff -u NUL win/nmakehlp.c >> win32-update.patch so hopefully it will patch ok. Pat Thoyts. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410297&aid=900771&group_id=34191 |
From: SourceForge.net <no...@so...> - 2003-11-20 16:27:10
|
Support Requests item #574853, was opened at 2002-06-28 01:00 Message generated for change (Comment added) made by harbecke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410296&aid=574853&group_id=34191 Category: 10. compilation/configuration Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Andreas Kupries (andreas_kupries) Summary: missing symbols at link time Initial Comment: MS vc++ 6.0 tcl 8.4b1 I cvsuped memchan, gave it this command line : c:\devel\vcvars32 & nmake /f makefile.vc DEST_DIR=c:\progra~1\tcl TCL=c:\progra~1\tcl TCLLIB=c:\progra~1\tcl\lib\tcl84.lib TOOLS32=C:\Progra~1\Micros~3\VC98 And got this error : C:\Progra~1\Micros~3\VC98\bin\link.exe /RELEASE /NODEFAULTLIB /RELEASE /NOLOGO -align:0x1000 /MACHINE:IX86 -entry:_DllMainCRTStartup@12 -dll c:\progra~1\tcl\lib\tcl84.lib msvcrt.lib oldnames.lib kernel32.lib advapi32.lib user32.lib gdi32.lib comdlg32.lib winspool.lib -out:memchan@mShortDosVersion@.dll .\memchan.obj .\fifo.obj .\init.obj .\counter.obj .\dllEntry.obj LINK : warning LNK4108: /ALIGN specified without /DRIVER or /VXD; image may not run Creating library memchan@mShortDosVersion@.lib and object memchan@mShortDosVersion@.exp fifo.obj : error LNK2001: unresolved external symbol _Buf_FreeQueue fifo.obj : error LNK2001: unresolved external symbol _Buf_QueueRead fifo.obj : error LNK2001: unresolved external symbol _Buf_QueueWrite fifo.obj : error LNK2001: unresolved external symbol _Buf_NewQueue init.obj : error LNK2001: unresolved external symbol _Buf_Init init.obj : error LNK2001: unresolved external symbol _bufStubs init.obj : error LNK2001: unresolved external symbol _MemchanNullCmd init.obj : error LNK2001: unresolved external symbol _MemchanFifo2Cmd memchan@mShortDosVersion@.dll : fatal error LNK1120: 8 unresolved externals NMAKE : fatal error U1077: 'C:\Progra~1\Micros~3\VC98\bin\link.exe' : return code '0x460' Stop. Whast am I doing wrong? ---------------------------------------------------------------------- Comment By: Winfried Harbecke (harbecke) Date: 2003-11-20 17:27 Message: Logged In: YES user_id=913663 Using the Release download of memchan2.2a4 and Vc7 (Visual Studio .NET) I get the same messages. After changing the following two definitions in $(ROOT)/win/makefile.vc TCLLIB = $(TCL)\lib\tcl84.lib $(TCL)\lib\tcl84s.lib MCOBJS = $(TMPDIR)\init.obj $(TMPDIR) \counter.obj $(TMPDIR)\memchan.obj $(TMPDIR)\fifo.obj $(TMPDIR)\fifo2.obj $(TMPDIR)\null.obj $(TMPDIR)\buf.obj $(TMPDIR)\bufQueue.obj $(TMPDIR)\bufRange.obj $(TMPDIR) \bufExt.obj $(TMPDIR)\bufFix.obj $(TMPDIR)\bufStubInit.obj $(TMPDIR)\bufStubLib.obj $(TMPDIR)\dllEntry.obj the compilation just produced the following warnings ..\generic\counter.c(61) : warning C4013: 'ltoa' undefiniert; Annahme: extern mit R?ckgabetyp int ..\generic\memchan.c(392) : warning C4013: 'ltoa' undefiniert; Annahme: extern mit R?ckgabetyp int ..\generic\fifo.c(314) : warning C4013: 'ltoa' undefiniert; Annahme: extern mit R?ckgabetyp int ..\generic\fifo2.c(529) : warning C4013: 'ltoa' undefiniert; Annahme: extern mit R?ckgabetyp int LINK : warning LNK4108: /ALIGN wurde ohne /DRIVER oder /VXD angegeben; Anwendung kann vielleicht nicht ausgefuehrt werden Apparently, all the makefiles in $(ROOT)/win are out of date. C4013 is the classic missing <math.h>, and I assume Andreas intends the /ALIGN to ease core dump debugging, but Microsoft does not grant that anymore. ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2002-07-01 03:19 Message: Logged In: YES user_id=75003 The main problem I see is that a number of object files are missing from the link line. Namely: fifo2.obj, and all buf*.obj I would like to know which makefile was used to compile memchan. It could be that some of them are not completely upto date. If you find that the makefile is not uptodate please file a bug report. Also note a snapshot of the CVS, i.e. something generated by CVSup or similar is not the same as a compileable source distribution. See http://sourceforge.net/docman/display_doc.php?docid=6354&group_id=34191 for more. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410296&aid=574853&group_id=34191 |
From: SourceForge.net <no...@so...> - 2003-09-02 07:27:28
|
Feature Requests item #798957, was opened at 2003-09-02 09:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410298&aid=798957&group_id=34191 Category: 50. new channeltype Group: None Status: Open Resolution: None Priority: 5 Submitted By: Markus Elfring (elfring) Assigned to: Nobody/Anonymous (nobody) Summary: Create channel for TCL variables Initial Comment: I dare to create a companion request for the topic "Redirect file output into variables" (https://sourceforge.net/tracker/? func=detail&aid=792990&group_id=10894&atid=36089 4). Can a memory channel be developed that can read from and write into TCL variables? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410298&aid=798957&group_id=34191 |