Menu
▾
▴
memchan-track — Tracker messages
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...> - 2013-02-12 20:20:16
|
Bugs item #681115, was opened at 2003-02-05 10:07 Message generated for change (Settings changed) made by andreas_kupries You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=681115&group_id=34191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 01. documentation Group: None Status: Closed Resolution: Fixed Priority: 5 >Private: Yes 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: Nobody/Anonymous (nobody) Date: 2013-02-11 08:22 Message: uOAEv0 <a href="http://xtffotucwixw.com/">xtffotucwixw</a>, [url=http://pfakaxhbhles.com/]pfakaxhbhles[/url], [link=http://xewbeqnbirsk.com/]xewbeqnbirsk[/link], http://voevmvlnpybn.com/ ---------------------------------------------------------------------- Comment By: Pat Thoyts (patthoyts) Date: 2004-05-22 02: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...> - 2013-02-11 16:22:55
|
Bugs item #681115, was opened at 2003-02-05 10:07 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=681115&group_id=34191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 01. documentation Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No 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: Nobody/Anonymous (nobody) Date: 2013-02-11 08:22 Message: uOAEv0 <a href="http://xtffotucwixw.com/">xtffotucwixw</a>, [url=http://pfakaxhbhles.com/]pfakaxhbhles[/url], [link=http://xewbeqnbirsk.com/]xewbeqnbirsk[/link], http://voevmvlnpybn.com/ ---------------------------------------------------------------------- Comment By: Pat Thoyts (patthoyts) Date: 2004-05-22 02: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...> - 2012-08-19 17:10:17
|
Bugs item #551677, was opened at 2002-05-02 18:12 Message generated for change (Settings changed) made by andreas_kupries You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=551677&group_id=34191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 40. memchan Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Joe English (jenglish) Assigned to: Andreas Kupries (andreas_kupries) Summary: Seek() signature change breaks stubs Initial Comment: I'm not sure if this is a bug in Tcl or a bug in memchan, but: The TIP82 change in the signature of Tcl_DriverSeekProc breaks stub-compatibility. If memchan is compiled against 8.3 headers and loaded into an 8.4a5 interp, all hell breaks loose. Would it be possible for Tcl_Seek() to check the Tcl_ChannelTypeVersion field and act accordingly, passing a 'long' instead of a Tcl_WideInt if the channel driver has a pre-8.3 version? Alternately, the current stub table entry for Tcl_RegisterChannel() could be changed to point to Tcl_RegisterChannelOld() and a new one allocated for the new Tcl_RegisterChannel() (much like what was done for Tcl_Seek and Tcl_Tell). (I think I like this option better). This really ought to get straightened out before 8.4 goes final. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-08-19 04:46 Message: NwTl1a <a href="http://jraecdmbfoxn.com/">jraecdmbfoxn</a>, [url=http://fmrqkcmshlef.com/]fmrqkcmshlef[/url], [link=http://bcnwycozuhkr.com/]bcnwycozuhkr[/link], http://altsotdlevgh.com/ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-11-21 05:38 Message: 8d8YLW <a href="http://otjkzshbasud.com/">otjkzshbasud</a>, [url=http://wnxxcupwgamb.com/]wnxxcupwgamb[/url], [link=http://xpwbpkmunrul.com/]xpwbpkmunrul[/link], http://hkqndzfmlxuf.com/ ---------------------------------------------------------------------- Comment By: Joe English (jenglish) Date: 2002-05-24 18:50 Message: Logged In: YES user_id=68433 DKF just finished implementing TIP 91, which fixes the problem. Closing the issue. (Thanks Donal!) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=551677&group_id=34191 |
|
From: SourceForge.net <no...@so...> - 2012-08-19 11:46:23
|
Bugs item #551677, was opened at 2002-05-02 18:12 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=551677&group_id=34191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 40. memchan Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Joe English (jenglish) Assigned to: Andreas Kupries (andreas_kupries) Summary: Seek() signature change breaks stubs Initial Comment: I'm not sure if this is a bug in Tcl or a bug in memchan, but: The TIP82 change in the signature of Tcl_DriverSeekProc breaks stub-compatibility. If memchan is compiled against 8.3 headers and loaded into an 8.4a5 interp, all hell breaks loose. Would it be possible for Tcl_Seek() to check the Tcl_ChannelTypeVersion field and act accordingly, passing a 'long' instead of a Tcl_WideInt if the channel driver has a pre-8.3 version? Alternately, the current stub table entry for Tcl_RegisterChannel() could be changed to point to Tcl_RegisterChannelOld() and a new one allocated for the new Tcl_RegisterChannel() (much like what was done for Tcl_Seek and Tcl_Tell). (I think I like this option better). This really ought to get straightened out before 8.4 goes final. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-08-19 04:46 Message: NwTl1a <a href="http://jraecdmbfoxn.com/">jraecdmbfoxn</a>, [url=http://fmrqkcmshlef.com/]fmrqkcmshlef[/url], [link=http://bcnwycozuhkr.com/]bcnwycozuhkr[/link], http://altsotdlevgh.com/ ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-11-21 05:38 Message: 8d8YLW <a href="http://otjkzshbasud.com/">otjkzshbasud</a>, [url=http://wnxxcupwgamb.com/]wnxxcupwgamb[/url], [link=http://xpwbpkmunrul.com/]xpwbpkmunrul[/link], http://hkqndzfmlxuf.com/ ---------------------------------------------------------------------- Comment By: Joe English (jenglish) Date: 2002-05-24 18:50 Message: Logged In: YES user_id=68433 DKF just finished implementing TIP 91, which fixes the problem. Closing the issue. (Thanks Donal!) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=551677&group_id=34191 |
|
From: SourceForge.net <no...@so...> - 2012-08-16 02:19:42
|
Bugs item #3558013, was opened at 2012-08-15 11:59 Message generated for change (Settings changed) made by andreas_kupries You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=3558013&group_id=34191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 60. other Group: v1.0 (example) >Status: Deleted >Resolution: Invalid Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Andreas Kupries (andreas_kupries) Summary: kBRbIoNeKGbmFP Initial Comment: jZAoTX <a href="http://uxxnpqkhttrq.com/">uxxnpqkhttrq</a>, [url=http://xdcacvjzbcvo.com/]xdcacvjzbcvo[/url], [link=http://gmreyicwcjbl.com/]gmreyicwcjbl[/link], http://nnjaxkngkdms.com/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=3558013&group_id=34191 |
|
From: SourceForge.net <no...@so...> - 2012-08-15 18:59:55
|
Bugs item #3558013, was opened at 2012-08-15 11:59 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=3558013&group_id=34191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 60. other Group: v1.0 (example) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Andreas Kupries (andreas_kupries) Summary: kBRbIoNeKGbmFP Initial Comment: jZAoTX <a href="http://uxxnpqkhttrq.com/">uxxnpqkhttrq</a>, [url=http://xdcacvjzbcvo.com/]xdcacvjzbcvo[/url], [link=http://gmreyicwcjbl.com/]gmreyicwcjbl[/link], http://nnjaxkngkdms.com/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=3558013&group_id=34191 |
|
From: SourceForge.net <no...@so...> - 2011-05-10 04:27:33
|
Bugs item #1083543, was opened at 2004-12-11 18:11 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=1083543&group_id=34191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 20. fifo Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Andreas Kupries (andreas_kupries) Summary: fileevent readable failure Initial Comment: revision: Memchan 2.2.1 Use of fileevent readable with fifo fails reference case with memchan ------------------------------------- package require Memchan proc isReadable { f } { if {![eof $f]} { puts [read $f] } } set fid [memchan] fileevent $fid readable [list isReadable $fid] after 5 {puts $::fid "successful" ; seek $::fid 0} after 500 {set ::DONE 1} vwait ::DONE close $fid ---------------------------------------- failure case with fifo ------------------------------------ package require Memchan proc isReadable { f } { if {![eof $f]} { puts [read $f] } } set fid [fifo] fileevent $fid readable [list isReadable $fid] after 5 {puts $::fid "fail"} after 500 {set ::DONE 1} vwait ::DONE close $fid ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-05-10 04:27 Message: Sourceforge.. Reposted it :) ---------------------------------------------------------------------- Comment By: Pat Thoyts (patthoyts) Date: 2005-03-08 01:44 Message: Logged In: YES user_id=202636 This looks like the same bug I've been looking into with the rechan extension from tclkit. In my case I've been using fcopy and finding that fcopying from a channel with no data causes a hang. A good example is package require Memchan set done doing set src [fifo] #puts $src \x00 ;# any data in the channel fixes the problem. set dst [zero] proc Complete {args} {set ::done complete} proc Timeout {} {set ::done timeout} set aid [after 2000 Timeout] fcopy $src $dst -command Complete vwait ::done after cancel $aid close $src; close $dst puts "Done: $done" It looks like a general failure in all the memchan channels. Are we missing a flag somewhere? The only setting thats apparent to me is that a short read > 0 sets a blocking flag in the upper channel layer that seems to cause the next call to the WatchProc to have mask be non-zero. This is sufficient to set the timer and ensure we get another fileevent raised with the eof set. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=1083543&group_id=34191 |
|
From: SourceForge.net <no...@so...> - 2010-10-29 12:05:29
|
Bugs item #924025, was opened at 2004-03-26 11:35 Message generated for change (Comment added) made by lvirden You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=924025&group_id=34191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: v1.0 (example) Status: Open Resolution: None Priority: 5 Private: No 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: Larry W. Virden (lvirden) Date: 2010-10-29 08:05 Message: It looks to me like the 2009 version that is currently on the ftp site configures and builds ok with tcl 8.6 ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2010-10-28 13:36 Message: Uh. 6 years old. Larry, is this still true ? ---------------------------------------------------------------------- Comment By: Larry W. Virden (lvirden) Date: 2006-07-26 10:25 Message: Logged In: YES user_id=15949 Note also that make test fails for the latest memchan cvs. I get this error: $ gmake test mv ./../win/pkgIndex.tcl ./../win/pkgIndex.tclX mv: cannot access ./../win/pkgIndex.tcl gmake: *** [test] Error 2 srv29 (376) $ gmake -n test mv ./../win/pkgIndex.tcl ./../win/pkgIndex.tclX LD_LIBRARY_PATH=".:../../tcl/unix"; export LD_LIBRARY_PATH; \ SHLIB_PATH="D_LIBRARY_PATH"; export SHLIB_PATH; \ wish ./../testlib/tester -auto -delay 1 mv ./../win/pkgIndex.tclX ./../win/pkgIndex.tcl srv29 (377) $ wish ./../testlib/tester -auto -delay 1 Error in startup script: couldn't read file "./../testlib/tester": no such file or directory ---------------------------------------------------------------------- Comment By: Larry W. Virden (lvirden) Date: 2006-07-26 10:21 Message: Logged In: YES user_id=15949 here's a patch to try to fix the code which doesn't find the right tcl stuff. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2004-08-15 04: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...> - 2010-10-28 17:36:46
|
Bugs item #924025, was opened at 2004-03-26 08:35 Message generated for change (Comment added) made by andreas_kupries You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=924025&group_id=34191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: v1.0 (example) Status: Open Resolution: None Priority: 5 Private: No 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: Andreas Kupries (andreas_kupries) Date: 2010-10-28 10:36 Message: Uh. 6 years old. Larry, is this still true ? ---------------------------------------------------------------------- Comment By: Larry W. Virden (lvirden) Date: 2006-07-26 07:25 Message: Logged In: YES user_id=15949 Note also that make test fails for the latest memchan cvs. I get this error: $ gmake test mv ./../win/pkgIndex.tcl ./../win/pkgIndex.tclX mv: cannot access ./../win/pkgIndex.tcl gmake: *** [test] Error 2 srv29 (376) $ gmake -n test mv ./../win/pkgIndex.tcl ./../win/pkgIndex.tclX LD_LIBRARY_PATH=".:../../tcl/unix"; export LD_LIBRARY_PATH; \ SHLIB_PATH="D_LIBRARY_PATH"; export SHLIB_PATH; \ wish ./../testlib/tester -auto -delay 1 mv ./../win/pkgIndex.tclX ./../win/pkgIndex.tcl srv29 (377) $ wish ./../testlib/tester -auto -delay 1 Error in startup script: couldn't read file "./../testlib/tester": no such file or directory ---------------------------------------------------------------------- Comment By: Larry W. Virden (lvirden) Date: 2006-07-26 07:21 Message: Logged In: YES user_id=15949 here's a patch to try to fix the code which doesn't find the right tcl stuff. ---------------------------------------------------------------------- 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...> - 2010-10-28 17:34:12
|
Bugs item #3032029, was opened at 2010-07-20 03:49 Message generated for change (Settings changed) made by andreas_kupries You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=3032029&group_id=34191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: 60. other Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Sebastian Reitenbach (buzzzzdeeee) >Assigned to: Andreas Kupries (andreas_kupries) Summary: missing includes to <string.h> Initial Comment: At least on OpenBSD building memchan spits out a lot of warnings regarding implicit declaration of functions. The reason is that <string.h> is not included. Appended patch includes the header where necessary. ---------------------------------------------------------------------- >Comment By: Andreas Kupries (andreas_kupries) Date: 2010-10-28 10:34 Message: This is a duplicate of bugs 2078168 and 2687845, which are fixed in the CVS. The relevant ChangeLog entries are 2009-03-16 Andreas Kupries <and...@ac...> * generic/bugExt.c: Fixed [SF Bug 2687845] by Stuart Cassoff, * generic/bugFix.c: added inclusion of memchanInt.h to these * generic/bugRange.c: files to declare memcpy(). (Sidenote: And memchanInt.h has the string.h include per the entry below). 2008-10-03 Andreas Kupries <and...@ac...> * generic/memchanInt.h: Fixed [SF Bug 2078168] by Larry Virden <lv...@us...>. Added inclusion of header <string.h> to get declarations for strcmp, memcpy, and memset. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=3032029&group_id=34191 |
|
From: SourceForge.net <no...@so...> - 2010-07-20 10:49:02
|
Bugs item #3032029, was opened at 2010-07-20 12:49 Message generated for change (Tracker Item Submitted) made by buzzzzdeeee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=3032029&group_id=34191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sebastian Reitenbach (buzzzzdeeee) Assigned to: Nobody/Anonymous (nobody) Summary: missing includes to <string.h> Initial Comment: At least on OpenBSD building memchan spits out a lot of warnings regarding implicit declaration of functions. The reason is that <string.h> is not included. Appended patch includes the header where necessary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=3032029&group_id=34191 |
|
From: SourceForge.net <no...@so...> - 2009-05-08 07:24:53
|
Feature Requests item #2788805, was opened at 2009-05-08 07:24 Message generated for change (Tracker Item Submitted) made by r_zaumseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410298&aid=2788805&group_id=34191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rene (r_zaumseil) Assigned to: Nobody/Anonymous (nobody) Summary: tag current version Initial Comment: last tag memchan-2-2-1 is some years old and has problems with configure Please create a new tag ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410298&aid=2788805&group_id=34191 |
|
From: SourceForge.net <no...@so...> - 2009-03-16 18:59:07
|
Bugs item #1080325, was opened at 2004-12-06 15:45 Message generated for change (Settings changed) made by andreas_kupries You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=1080325&group_id=34191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 60. other Group: None >Status: Closed >Resolution: Fixed Priority: 6 Private: No Submitted By: Joe English (jenglish) Assigned to: Pat Thoyts (patthoyts) Summary: Cannot build memchan 2.2.1 Initial Comment: Environment: Mandrake Linux 10.0, Tcl 8.5 (recentish CVS HEAD) installed in /usr/local. Take 1: $ tar xzf memchan-2.2.1.tar.gz $ cd memchan-2.2.1 $ sh configure [ ... configure output elided ...] $ make make: *** No rule to make target `memchanStubInit.o', needed by `libMemchan2.2.1.so'. Stop. Take 2: $ tar xzf memchan-2.2.1.tar.gz $ cd memchan-2.2.1/unix $ sh configure [ ... configure output elided ...] $ make [ ... this succeeds, creating libmemchan.so, but: ...] $ tclsh % load ./libmemchan.so couldn't load file "./libmemchan.so": ./libmemchan.so: undefined symbol: memchanStubs Take 3: $ tar xzf memchan-2.2.1.tar.gz $ cd memchan-2.2.1/unix $ sh ../configure [ ... ] $ make make: *** No rule to make target `../../generic/init.c', needed by `init.o'. Stop. Take 4: $ tar xzf memchan-2.2.1.tar.gz $ mkdir /tmp/build $ cd /tmp/build $ sh ~/dl/memchan-2.2.1/configure [...] $ make [ This finally worked. I'm afraid to run 'make install' though.] ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2009-03-16 11:58 Message: nobody, please understand that we (I and stwo) are currently talking about the CVS head of memchan and not the version released in 2004. The head is updated and the old junk Pat refers to is gone there. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-03-15 15:07 Message: I still get basically the same results as before: $ tar xzf memchan-2.2.1.tar.gz $ cd memchan-2.2.1 $ sh configure [...] make: *** No rule to make target `memchan.o', needed by `libMemchan2.2.1.so'. Stop. (and similarly for the other approaches). Recommend closing once a newer release is available. ---------------------------------------------------------------------- Comment By: Stuart Cassoff (stwo) Date: 2009-03-15 10:56 Message: This works now for me, with the exception of building the documentation, which is a separate issue, imho. Recommend closing. ---------------------------------------------------------------------- Comment By: Pat Thoyts (patthoyts) Date: 2004-12-08 03:11 Message: Logged In: YES user_id=202636 I'll take a look at this. Memchan should be TEA 3 compliant and this means the toplevel configure/makefile.in. The stuff in unix/ probably should be removed but that's for Andreas to decide as it's all pre8.2 compatability stuff. Same goes for the old win buld files. Can we clean up the old junk? If the toplevel files don't do the expected TEA things then they need fixing. Worked for me, but I always create a subdirectory to build in. I shall try without. ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2004-12-06 19:57 Message: Logged In: YES user_id=75003 Ok, it seems I misunderstood your sentences regarding autoconf. It souded to me as if you had run autoconf before using the configure. The toplevel configure not working the toplevel directory is a bug IMO, we should fix that. Take 4 is how AS is building memchan for ActiveTcl. I actually never build from within the source tree anymore, no extension. Guess that is why this slipped through. Well, this is to short before my vacation, so I will do nothing on this before the new year. Note however that Pat has CVS write access, and has already fixed bugs, albeit in the code, not the build system. ---------------------------------------------------------------------- Comment By: Joe English (jenglish) Date: 2004-12-06 19:37 Message: Logged In: YES user_id=68433 > Why are you running autoconf ? I didn't run autoconf; just 'configure' and 'make' in various directories (see above). > Is the configure in the distribution not suitable ? The one in unix/ does not seem to work at all. The one in the top-level directory doesn't work if you run it in the top-level directory (which is what README.install says to do.) ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2004-12-06 16:22 Message: Logged In: YES user_id=75003 Note: AS uses the toplevel configure to build. No problems. Might be useful to attach the outputs of the various commands to this report. ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2004-12-06 16:21 Message: Logged In: YES user_id=75003 Why are you running autoconf ? Is the configure in the distribution not suitable ? Which autoconf ? 2.13, 2.5x ? IIRC this is old TEA, based on autoconf 2.13. The configure under unix is even older. This is actually something I wish to drop. Yes, it is not maintained. ---------------------------------------------------------------------- Comment By: Joe English (jenglish) Date: 2004-12-06 16:14 Message: Logged In: YES user_id=68433 Further analysis: Cause of failure in case (1): autoconf is trying to be "helpful" by mangling the VPATH line. (AFAICT, this is to avoid a bug in an old version of 'make' found on an obsolete version of SunOS; it has the unfortunate side effect of screwing things up on modern systems.) The autoconf manual recommends: VPATH = @srcdir@ but that probably won't work for memchan since it has source files spread out across multiple subdirectories. Case (2): It looks like the configure.in, Makefile.in, and other build infrastructure files in this directory are obsolete and no longer maintained. Didn't investigate further; perhaps they should be removed from the distribution? Case (3): Didn't investigate further; probably caused by ../configure picking up the wrong Makefile.in (the one in . instead of ..) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=1080325&group_id=34191 |
|
From: SourceForge.net <no...@so...> - 2009-03-16 18:58:36
|
Bugs item #1080325, was opened at 2004-12-06 15:45 Message generated for change (Comment added) made by andreas_kupries You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=1080325&group_id=34191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 60. other Group: None Status: Open Resolution: None Priority: 6 Private: No Submitted By: Joe English (jenglish) Assigned to: Pat Thoyts (patthoyts) Summary: Cannot build memchan 2.2.1 Initial Comment: Environment: Mandrake Linux 10.0, Tcl 8.5 (recentish CVS HEAD) installed in /usr/local. Take 1: $ tar xzf memchan-2.2.1.tar.gz $ cd memchan-2.2.1 $ sh configure [ ... configure output elided ...] $ make make: *** No rule to make target `memchanStubInit.o', needed by `libMemchan2.2.1.so'. Stop. Take 2: $ tar xzf memchan-2.2.1.tar.gz $ cd memchan-2.2.1/unix $ sh configure [ ... configure output elided ...] $ make [ ... this succeeds, creating libmemchan.so, but: ...] $ tclsh % load ./libmemchan.so couldn't load file "./libmemchan.so": ./libmemchan.so: undefined symbol: memchanStubs Take 3: $ tar xzf memchan-2.2.1.tar.gz $ cd memchan-2.2.1/unix $ sh ../configure [ ... ] $ make make: *** No rule to make target `../../generic/init.c', needed by `init.o'. Stop. Take 4: $ tar xzf memchan-2.2.1.tar.gz $ mkdir /tmp/build $ cd /tmp/build $ sh ~/dl/memchan-2.2.1/configure [...] $ make [ This finally worked. I'm afraid to run 'make install' though.] ---------------------------------------------------------------------- >Comment By: Andreas Kupries (andreas_kupries) Date: 2009-03-16 11:58 Message: nobody, please understand that we (I and stwo) are currently talking about the CVS head of memchan and not the version released in 2004. The head is updated and the old junk Pat refers to is gone there. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-03-15 15:07 Message: I still get basically the same results as before: $ tar xzf memchan-2.2.1.tar.gz $ cd memchan-2.2.1 $ sh configure [...] make: *** No rule to make target `memchan.o', needed by `libMemchan2.2.1.so'. Stop. (and similarly for the other approaches). Recommend closing once a newer release is available. ---------------------------------------------------------------------- Comment By: Stuart Cassoff (stwo) Date: 2009-03-15 10:56 Message: This works now for me, with the exception of building the documentation, which is a separate issue, imho. Recommend closing. ---------------------------------------------------------------------- Comment By: Pat Thoyts (patthoyts) Date: 2004-12-08 03:11 Message: Logged In: YES user_id=202636 I'll take a look at this. Memchan should be TEA 3 compliant and this means the toplevel configure/makefile.in. The stuff in unix/ probably should be removed but that's for Andreas to decide as it's all pre8.2 compatability stuff. Same goes for the old win buld files. Can we clean up the old junk? If the toplevel files don't do the expected TEA things then they need fixing. Worked for me, but I always create a subdirectory to build in. I shall try without. ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2004-12-06 19:57 Message: Logged In: YES user_id=75003 Ok, it seems I misunderstood your sentences regarding autoconf. It souded to me as if you had run autoconf before using the configure. The toplevel configure not working the toplevel directory is a bug IMO, we should fix that. Take 4 is how AS is building memchan for ActiveTcl. I actually never build from within the source tree anymore, no extension. Guess that is why this slipped through. Well, this is to short before my vacation, so I will do nothing on this before the new year. Note however that Pat has CVS write access, and has already fixed bugs, albeit in the code, not the build system. ---------------------------------------------------------------------- Comment By: Joe English (jenglish) Date: 2004-12-06 19:37 Message: Logged In: YES user_id=68433 > Why are you running autoconf ? I didn't run autoconf; just 'configure' and 'make' in various directories (see above). > Is the configure in the distribution not suitable ? The one in unix/ does not seem to work at all. The one in the top-level directory doesn't work if you run it in the top-level directory (which is what README.install says to do.) ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2004-12-06 16:22 Message: Logged In: YES user_id=75003 Note: AS uses the toplevel configure to build. No problems. Might be useful to attach the outputs of the various commands to this report. ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2004-12-06 16:21 Message: Logged In: YES user_id=75003 Why are you running autoconf ? Is the configure in the distribution not suitable ? Which autoconf ? 2.13, 2.5x ? IIRC this is old TEA, based on autoconf 2.13. The configure under unix is even older. This is actually something I wish to drop. Yes, it is not maintained. ---------------------------------------------------------------------- Comment By: Joe English (jenglish) Date: 2004-12-06 16:14 Message: Logged In: YES user_id=68433 Further analysis: Cause of failure in case (1): autoconf is trying to be "helpful" by mangling the VPATH line. (AFAICT, this is to avoid a bug in an old version of 'make' found on an obsolete version of SunOS; it has the unfortunate side effect of screwing things up on modern systems.) The autoconf manual recommends: VPATH = @srcdir@ but that probably won't work for memchan since it has source files spread out across multiple subdirectories. Case (2): It looks like the configure.in, Makefile.in, and other build infrastructure files in this directory are obsolete and no longer maintained. Didn't investigate further; perhaps they should be removed from the distribution? Case (3): Didn't investigate further; probably caused by ../configure picking up the wrong Makefile.in (the one in . instead of ..) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=1080325&group_id=34191 |
|
From: SourceForge.net <no...@so...> - 2009-03-16 18:51:27
|
Bugs item #2687845, was opened at 2009-03-15 11:08 Message generated for change (Settings changed) made by andreas_kupries You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=2687845&group_id=34191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 40. memchan Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Stuart Cassoff (stwo) Assigned to: Andreas Kupries (andreas_kupries) Summary: Missing #include "memchanInt.h" in three files Initial Comment: The files: generic/bufExt.c generic/bufFix.c generic/bufRange.c are missing: #include "memchanInt.h" which is needed in order to #include <string.h> which is needed for the declaration of memcpy(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=2687845&group_id=34191 |
|
From: SourceForge.net <no...@so...> - 2009-03-15 22:08:04
|
Bugs item #1080325, was opened at 2004-12-06 23:45 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=1080325&group_id=34191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 60. other Group: None Status: Open Resolution: None Priority: 6 Private: No Submitted By: Joe English (jenglish) Assigned to: Pat Thoyts (patthoyts) Summary: Cannot build memchan 2.2.1 Initial Comment: Environment: Mandrake Linux 10.0, Tcl 8.5 (recentish CVS HEAD) installed in /usr/local. Take 1: $ tar xzf memchan-2.2.1.tar.gz $ cd memchan-2.2.1 $ sh configure [ ... configure output elided ...] $ make make: *** No rule to make target `memchanStubInit.o', needed by `libMemchan2.2.1.so'. Stop. Take 2: $ tar xzf memchan-2.2.1.tar.gz $ cd memchan-2.2.1/unix $ sh configure [ ... configure output elided ...] $ make [ ... this succeeds, creating libmemchan.so, but: ...] $ tclsh % load ./libmemchan.so couldn't load file "./libmemchan.so": ./libmemchan.so: undefined symbol: memchanStubs Take 3: $ tar xzf memchan-2.2.1.tar.gz $ cd memchan-2.2.1/unix $ sh ../configure [ ... ] $ make make: *** No rule to make target `../../generic/init.c', needed by `init.o'. Stop. Take 4: $ tar xzf memchan-2.2.1.tar.gz $ mkdir /tmp/build $ cd /tmp/build $ sh ~/dl/memchan-2.2.1/configure [...] $ make [ This finally worked. I'm afraid to run 'make install' though.] ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-03-15 22:07 Message: I still get basically the same results as before: $ tar xzf memchan-2.2.1.tar.gz $ cd memchan-2.2.1 $ sh configure [...] make: *** No rule to make target `memchan.o', needed by `libMemchan2.2.1.so'. Stop. (and similarly for the other approaches). Recommend closing once a newer release is available. ---------------------------------------------------------------------- Comment By: Stuart Cassoff (stwo) Date: 2009-03-15 17:56 Message: This works now for me, with the exception of building the documentation, which is a separate issue, imho. Recommend closing. ---------------------------------------------------------------------- Comment By: Pat Thoyts (patthoyts) Date: 2004-12-08 11:11 Message: Logged In: YES user_id=202636 I'll take a look at this. Memchan should be TEA 3 compliant and this means the toplevel configure/makefile.in. The stuff in unix/ probably should be removed but that's for Andreas to decide as it's all pre8.2 compatability stuff. Same goes for the old win buld files. Can we clean up the old junk? If the toplevel files don't do the expected TEA things then they need fixing. Worked for me, but I always create a subdirectory to build in. I shall try without. ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2004-12-07 03:57 Message: Logged In: YES user_id=75003 Ok, it seems I misunderstood your sentences regarding autoconf. It souded to me as if you had run autoconf before using the configure. The toplevel configure not working the toplevel directory is a bug IMO, we should fix that. Take 4 is how AS is building memchan for ActiveTcl. I actually never build from within the source tree anymore, no extension. Guess that is why this slipped through. Well, this is to short before my vacation, so I will do nothing on this before the new year. Note however that Pat has CVS write access, and has already fixed bugs, albeit in the code, not the build system. ---------------------------------------------------------------------- Comment By: Joe English (jenglish) Date: 2004-12-07 03:37 Message: Logged In: YES user_id=68433 > Why are you running autoconf ? I didn't run autoconf; just 'configure' and 'make' in various directories (see above). > Is the configure in the distribution not suitable ? The one in unix/ does not seem to work at all. The one in the top-level directory doesn't work if you run it in the top-level directory (which is what README.install says to do.) ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2004-12-07 00:22 Message: Logged In: YES user_id=75003 Note: AS uses the toplevel configure to build. No problems. Might be useful to attach the outputs of the various commands to this report. ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2004-12-07 00:21 Message: Logged In: YES user_id=75003 Why are you running autoconf ? Is the configure in the distribution not suitable ? Which autoconf ? 2.13, 2.5x ? IIRC this is old TEA, based on autoconf 2.13. The configure under unix is even older. This is actually something I wish to drop. Yes, it is not maintained. ---------------------------------------------------------------------- Comment By: Joe English (jenglish) Date: 2004-12-07 00:14 Message: Logged In: YES user_id=68433 Further analysis: Cause of failure in case (1): autoconf is trying to be "helpful" by mangling the VPATH line. (AFAICT, this is to avoid a bug in an old version of 'make' found on an obsolete version of SunOS; it has the unfortunate side effect of screwing things up on modern systems.) The autoconf manual recommends: VPATH = @srcdir@ but that probably won't work for memchan since it has source files spread out across multiple subdirectories. Case (2): It looks like the configure.in, Makefile.in, and other build infrastructure files in this directory are obsolete and no longer maintained. Didn't investigate further; perhaps they should be removed from the distribution? Case (3): Didn't investigate further; probably caused by ../configure picking up the wrong Makefile.in (the one in . instead of ..) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=1080325&group_id=34191 |
|
From: SourceForge.net <no...@so...> - 2009-03-15 18:09:20
|
Bugs item #2687845, was opened at 2009-03-15 11:08 Message generated for change (Settings changed) made by stwo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=2687845&group_id=34191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: 40. memchan Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stuart Cassoff (stwo) >Assigned to: Andreas Kupries (andreas_kupries) Summary: Missing #include "memchanInt.h" in three files Initial Comment: The files: generic/bufExt.c generic/bufFix.c generic/bufRange.c are missing: #include "memchanInt.h" which is needed in order to #include <string.h> which is needed for the declaration of memcpy(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=2687845&group_id=34191 |
|
From: SourceForge.net <no...@so...> - 2009-03-15 18:08:45
|
Bugs item #2687845, was opened at 2009-03-15 11:08 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=2687845&group_id=34191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stuart Cassoff (stwo) Assigned to: Nobody/Anonymous (nobody) Summary: Missing #include "memchanInt.h" in three files Initial Comment: The files: generic/bufExt.c generic/bufFix.c generic/bufRange.c are missing: #include "memchanInt.h" which is needed in order to #include <string.h> which is needed for the declaration of memcpy(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=2687845&group_id=34191 |
|
From: SourceForge.net <no...@so...> - 2009-03-15 17:56:49
|
Bugs item #1080325, was opened at 2004-12-06 15:45 Message generated for change (Comment added) made by stwo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=1080325&group_id=34191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 60. other Group: None Status: Open Resolution: None Priority: 6 Private: No Submitted By: Joe English (jenglish) Assigned to: Pat Thoyts (patthoyts) Summary: Cannot build memchan 2.2.1 Initial Comment: Environment: Mandrake Linux 10.0, Tcl 8.5 (recentish CVS HEAD) installed in /usr/local. Take 1: $ tar xzf memchan-2.2.1.tar.gz $ cd memchan-2.2.1 $ sh configure [ ... configure output elided ...] $ make make: *** No rule to make target `memchanStubInit.o', needed by `libMemchan2.2.1.so'. Stop. Take 2: $ tar xzf memchan-2.2.1.tar.gz $ cd memchan-2.2.1/unix $ sh configure [ ... configure output elided ...] $ make [ ... this succeeds, creating libmemchan.so, but: ...] $ tclsh % load ./libmemchan.so couldn't load file "./libmemchan.so": ./libmemchan.so: undefined symbol: memchanStubs Take 3: $ tar xzf memchan-2.2.1.tar.gz $ cd memchan-2.2.1/unix $ sh ../configure [ ... ] $ make make: *** No rule to make target `../../generic/init.c', needed by `init.o'. Stop. Take 4: $ tar xzf memchan-2.2.1.tar.gz $ mkdir /tmp/build $ cd /tmp/build $ sh ~/dl/memchan-2.2.1/configure [...] $ make [ This finally worked. I'm afraid to run 'make install' though.] ---------------------------------------------------------------------- Comment By: Stuart Cassoff (stwo) Date: 2009-03-15 10:56 Message: This works now for me, with the exception of building the documentation, which is a separate issue, imho. Recommend closing. ---------------------------------------------------------------------- Comment By: Pat Thoyts (patthoyts) Date: 2004-12-08 03:11 Message: Logged In: YES user_id=202636 I'll take a look at this. Memchan should be TEA 3 compliant and this means the toplevel configure/makefile.in. The stuff in unix/ probably should be removed but that's for Andreas to decide as it's all pre8.2 compatability stuff. Same goes for the old win buld files. Can we clean up the old junk? If the toplevel files don't do the expected TEA things then they need fixing. Worked for me, but I always create a subdirectory to build in. I shall try without. ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2004-12-06 19:57 Message: Logged In: YES user_id=75003 Ok, it seems I misunderstood your sentences regarding autoconf. It souded to me as if you had run autoconf before using the configure. The toplevel configure not working the toplevel directory is a bug IMO, we should fix that. Take 4 is how AS is building memchan for ActiveTcl. I actually never build from within the source tree anymore, no extension. Guess that is why this slipped through. Well, this is to short before my vacation, so I will do nothing on this before the new year. Note however that Pat has CVS write access, and has already fixed bugs, albeit in the code, not the build system. ---------------------------------------------------------------------- Comment By: Joe English (jenglish) Date: 2004-12-06 19:37 Message: Logged In: YES user_id=68433 > Why are you running autoconf ? I didn't run autoconf; just 'configure' and 'make' in various directories (see above). > Is the configure in the distribution not suitable ? The one in unix/ does not seem to work at all. The one in the top-level directory doesn't work if you run it in the top-level directory (which is what README.install says to do.) ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2004-12-06 16:22 Message: Logged In: YES user_id=75003 Note: AS uses the toplevel configure to build. No problems. Might be useful to attach the outputs of the various commands to this report. ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2004-12-06 16:21 Message: Logged In: YES user_id=75003 Why are you running autoconf ? Is the configure in the distribution not suitable ? Which autoconf ? 2.13, 2.5x ? IIRC this is old TEA, based on autoconf 2.13. The configure under unix is even older. This is actually something I wish to drop. Yes, it is not maintained. ---------------------------------------------------------------------- Comment By: Joe English (jenglish) Date: 2004-12-06 16:14 Message: Logged In: YES user_id=68433 Further analysis: Cause of failure in case (1): autoconf is trying to be "helpful" by mangling the VPATH line. (AFAICT, this is to avoid a bug in an old version of 'make' found on an obsolete version of SunOS; it has the unfortunate side effect of screwing things up on modern systems.) The autoconf manual recommends: VPATH = @srcdir@ but that probably won't work for memchan since it has source files spread out across multiple subdirectories. Case (2): It looks like the configure.in, Makefile.in, and other build infrastructure files in this directory are obsolete and no longer maintained. Didn't investigate further; perhaps they should be removed from the distribution? Case (3): Didn't investigate further; probably caused by ../configure picking up the wrong Makefile.in (the one in . instead of ..) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=1080325&group_id=34191 |
|
From: SourceForge.net <no...@so...> - 2008-11-21 13:38:41
|
Bugs item #551677, was opened at 2002-05-03 01:12 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=551677&group_id=34191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 40. memchan Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Joe English (jenglish) Assigned to: Andreas Kupries (andreas_kupries) Summary: Seek() signature change breaks stubs Initial Comment: I'm not sure if this is a bug in Tcl or a bug in memchan, but: The TIP82 change in the signature of Tcl_DriverSeekProc breaks stub-compatibility. If memchan is compiled against 8.3 headers and loaded into an 8.4a5 interp, all hell breaks loose. Would it be possible for Tcl_Seek() to check the Tcl_ChannelTypeVersion field and act accordingly, passing a 'long' instead of a Tcl_WideInt if the channel driver has a pre-8.3 version? Alternately, the current stub table entry for Tcl_RegisterChannel() could be changed to point to Tcl_RegisterChannelOld() and a new one allocated for the new Tcl_RegisterChannel() (much like what was done for Tcl_Seek and Tcl_Tell). (I think I like this option better). This really ought to get straightened out before 8.4 goes final. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-11-21 13:38 Message: 8d8YLW <a href="http://otjkzshbasud.com/">otjkzshbasud</a>, [url=http://wnxxcupwgamb.com/]wnxxcupwgamb[/url], [link=http://xpwbpkmunrul.com/]xpwbpkmunrul[/link], http://hkqndzfmlxuf.com/ ---------------------------------------------------------------------- Comment By: Joe English (jenglish) Date: 2002-05-25 01:50 Message: Logged In: YES user_id=68433 DKF just finished implementing TIP 91, which fixes the problem. Closing the issue. (Thanks Donal!) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=551677&group_id=34191 |
|
From: SourceForge.net <no...@so...> - 2008-10-03 21:47:46
|
Bugs item #2078168, was opened at 2008-08-27 04:50 Message generated for change (Settings changed) made by andreas_kupries You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=2078168&group_id=34191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 40. memchan Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Larry W. Virden (lvirden) Assigned to: Andreas Kupries (andreas_kupries) Summary: compile warnings note Initial Comment: Using tcl 8.5.4, memchan cvs head, and compiling on sparc solaris 8 and sun's compiler, the following warnings occur. Including certain headers would resolve many of these. "../generic/fifo.c", line 328: warning: implicit function declaration: strcmp "../generic/fifo2.c", line 593: warning: implicit function declaration: strcmp "../generic/fifo2.c", line 888: warning: implicit function declaration: memset "../generic/zero.c", line 201: warning: implicit function declaration: memset "../generic/zero.c", line 395: warning: implicit function declaration: strcmp "../generic/random.c", line 204: warning: implicit function declaration: memcpy "../generic/random.c", line 416: warning: implicit function declaration: strcmp "../generic/bufFix.c", line 203: warning: implicit function declaration: memcpy "../generic/bufExt.c", line 200: warning: implicit function declaration: memcpy "../generic/bufRange.c", line 229: warning: implicit function declaration: memcpy ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2008-10-03 13:46 Message: Do you believe that #include <string.h> is enough to resolve these ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=2078168&group_id=34191 |
|
From: SourceForge.net <no...@so...> - 2008-10-03 21:31:11
|
Patches item #2143333, was opened at 2008-10-02 17:14 Message generated for change (Comment added) made by andreas_kupries You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410297&aid=2143333&group_id=34191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 60. other Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stuart Cassoff (stwo) Assigned to: Andreas Kupries (andreas_kupries) Summary: Build/test upgrade and small fixes. Initial Comment: Build -> TEA 3.6 plus improvements. Tests -> tcltest 2.2. Fixes: 2078168, 1080325 Probably fixes: 1831784, 1831776, 924025 Patch against memchan-2.2.1. Regen of 'configure' required; it's not in the patch. It does the trick but some manual intervention is still needed. ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2008-10-03 14:30 Message: Stu, may I impose and you and ask to make this patch against the CVS head instead of the very old 2.2.1 release ? The CVS Head is at TEA 3.5 already, which means that the major Makefile, configure.in, tcl.m4 changes are done. To go 3.6 we will likely need only very small changes. The #include <string.h> changes seem to me to be Larry's https://sourceforge.net/tracker2/?func=detail&atid=410295&aid=2078168&group_id=34191 These I had done today as well, except that added the line only once, in "memchanInt.h", instead of in every .c file. It seems that the testsuite changes are the only major thing I do not have yet. Note that there is a tests/all script you can change, instead of all.tcl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410297&aid=2143333&group_id=34191 |
|
From: SourceForge.net <no...@so...> - 2008-10-03 20:46:25
|
Bugs item #2078168, was opened at 2008-08-27 04:50 Message generated for change (Comment added) made by andreas_kupries You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=2078168&group_id=34191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 40. memchan Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Larry W. Virden (lvirden) Assigned to: Andreas Kupries (andreas_kupries) Summary: compile warnings note Initial Comment: Using tcl 8.5.4, memchan cvs head, and compiling on sparc solaris 8 and sun's compiler, the following warnings occur. Including certain headers would resolve many of these. "../generic/fifo.c", line 328: warning: implicit function declaration: strcmp "../generic/fifo2.c", line 593: warning: implicit function declaration: strcmp "../generic/fifo2.c", line 888: warning: implicit function declaration: memset "../generic/zero.c", line 201: warning: implicit function declaration: memset "../generic/zero.c", line 395: warning: implicit function declaration: strcmp "../generic/random.c", line 204: warning: implicit function declaration: memcpy "../generic/random.c", line 416: warning: implicit function declaration: strcmp "../generic/bufFix.c", line 203: warning: implicit function declaration: memcpy "../generic/bufExt.c", line 200: warning: implicit function declaration: memcpy "../generic/bufRange.c", line 229: warning: implicit function declaration: memcpy ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2008-10-03 13:46 Message: Do you believe that #include <string.h> is enough to resolve these ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410295&aid=2078168&group_id=34191 |
|
From: SourceForge.net <no...@so...> - 2008-10-03 20:44:59
|
Patches item #2143333, was opened at 2008-10-02 17:14 Message generated for change (Settings changed) made by andreas_kupries You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410297&aid=2143333&group_id=34191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: 60. other Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stuart Cassoff (stwo) >Assigned to: Andreas Kupries (andreas_kupries) Summary: Build/test upgrade and small fixes. Initial Comment: Build -> TEA 3.6 plus improvements. Tests -> tcltest 2.2. Fixes: 2078168, 1080325 Probably fixes: 1831784, 1831776, 924025 Patch against memchan-2.2.1. Regen of 'configure' required; it's not in the patch. It does the trick but some manual intervention is still needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410297&aid=2143333&group_id=34191 |
|
From: SourceForge.net <no...@so...> - 2008-10-03 00:14:07
|
Patches item #2143333, was opened at 2008-10-02 17:14 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=2143333&group_id=34191 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stuart Cassoff (stwo) Assigned to: Nobody/Anonymous (nobody) Summary: Build/test upgrade and small fixes. Initial Comment: Build -> TEA 3.6 plus improvements. Tests -> tcltest 2.2. Fixes: 2078168, 1080325 Probably fixes: 1831784, 1831776, 924025 Patch against memchan-2.2.1. Regen of 'configure' required; it's not in the patch. It does the trick but some manual intervention is still needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410297&aid=2143333&group_id=34191 |
