Hi,
Last month I reported three bugs in the configure step of the xotcl build process. While I was reporting those bugs and for a few days after, I was working on my mail, and so turned off the list's replying to me at first.
Is there a different way to report bugs? Could someone tell me the status of these bugs? Would anyone like copies of the bug reports sent to them?
Anyway, I got my mail working, but I discovered a problem in the list as well... During the period I had replies from the list turned off, I expected to see all my bug reports in the archive, but each time I sent the next bug, I checked the archive, and only my last one showed up. To make matters worse, someone else posted to the list in March after I did, and his/her message replaced mine.
Could the archive be configured to only accept 5 messages? But if that's the case, the behavior of replacing the last message doesn't make much sense. Could there be a bug in the software? Maybe the HD where the archives are kept is out of space?
If anyone replied to my reports, could you resend the replies just to me, at jim@jam.sessionsnet.com?
-Jim
-- Jam sessions community web site: http://jam.sessionsnet.org
Hi Jim,
i've received 4 emails during the last couple of days. Sending them to us or to the mailing list is fine. I've no clue why the archives do not seem to work with your emails. I forward this to our sys admin/try to find out what wents wrong with the list ... the issues you raised I need to discuss with Gustaf, especially the aol server stuff, because I don't know why it is the way it is (up to now, I personally used AOL server only seldomly). I way travelling last week, Gustaf is travelling this week, so we had no chance to talk. So hang in there ;)
Regards,
Uwe
Jim Lynch wrote:
Hi,
Last month I reported three bugs in the configure step of the xotcl build process. While I was reporting those bugs and for a few days after, I was working on my mail, and so turned off the list's replying to me at first.
Is there a different way to report bugs? Could someone tell me the status of these bugs? Would anyone like copies of the bug reports sent to them?
Anyway, I got my mail working, but I discovered a problem in the list as well... During the period I had replies from the list turned off, I expected to see all my bug reports in the archive, but each time I sent the next bug, I checked the archive, and only my last one showed up. To make matters worse, someone else posted to the list in March after I did, and his/her message replaced mine.
Could the archive be configured to only accept 5 messages? But if that's the case, the behavior of replacing the last message doesn't make much sense. Could there be a bug in the software? Maybe the HD where the archives are kept is out of space?
If anyone replied to my reports, could you resend the replies just to me, at jim@jam.sessionsnet.com?
-Jim
-- Jam sessions community web site: http://jam.sessionsnet.org _______________________________________________ Xotcl mailing list - Xotcl@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
On Fri, 02 Apr 2004 09:39:29 +0200 "Uwe Zdun" uwe.zdun@wu-wien.ac.at wrote:
Hi Jim,
i've received 4 emails during the last couple of days. Sending them to us or to the mailing list is fine. I've no clue why the archives do not seem to work with your emails. I forward this to our sys admin/try to find out what wents wrong with the list ... the issues you raised I need to discuss with Gustaf,
I sent him a note earlier about the xotch mailing list archives, since he's listed as maintainer for that.
especially the aol server stuff, because I don't know why it is the way it is (up to now, I personally used AOL server only seldomly).
It's all in the configure step, so it's related to the configure.in file. The problems (all three) are all in that file.
I may be able to fix the problems, but the issues are apparantly ongoing: I'm given to understand from the debian bug tracking system that these build problems have been going on for some time, and that xotcl was orphaned and removed from debian partly because of that.
So while I'm willing to try fixing the problems, I'm not clear that my fixes would be welcomed.
Regards,
Uwe
BTW, either I eliminated the possibility that the archive web site only archives 5 emails a month, or else someone fixed it for this month... the note you replied to is the 6th one for the month and it didn't replace the fifth.
-Jim
-- Jam sessions community web site: http://jam.sessionsnet.org
Jim Lynch wrote:
It's all in the configure step, so it's related to the configure.in file. The problems (all three) are all in that file.
I may be able to fix the problems, but the issues are apparantly ongoing: I'm given to understand from the debian bug tracking system that these build problems have been going on for some time, and that xotcl was orphaned and removed from debian partly because of that.
So while I'm willing to try fixing the problems, I'm not clear that my fixes would be welcomed.
xotcl is an open source project ... so we're happy about other people helping out (actually my opinion is: involvement other people is important in an open source project to keep the community process going ... for instance: I wasn't aware of the debian problem at all) so I understand: you send us a patched configure.in which solves the problem?
Regards,
Uwe
BTW, either I eliminated the possibility that the archive web site only archives 5 emails a month, or else someone fixed it for this month... the note you replied to is the 6th one for the month and it didn't replace the fifth.
there have been some server updates and 1-2 crashes because of a broken memory chip. maybe this problem relates to the backup. our mails of today seem to be ok in the archive ... let's have an eye on this. I've you experience further problems there, please drop us a note.
Uwe
On Friday 02 April 2004 05:37, Jim Lynch wrote:
Hi,
Hi Jim, sorry for the delayed answer, i was last week on vacation.
Last month I reported three bugs in the configure step of the xotcl
you mean last week? well, last week is also last month, just to remove disambiguity, i have received no earlier mails from you.
build process. While I was reporting those bugs and for a few days after, I was working on my mail, and so turned off the list's replying to me at first.
Is there a different way to report bugs? Could someone tell me the status of these bugs? Would anyone like copies of the bug reports sent to them?
as uwe pointed out, we have since last week serious hardware problems on our webserver.
i have received four mails from concerning a) the aolserver, and b) tclsh without path.
concerning (a) you are right, determining to build with AOLserver from the `pwd` is not pretty, also the hardwired path to the AOLserver include directory. i have changed that right now. note, that making an aolserver module is only an issue for AOLserver 3.*, the AOLserver 4* series does not require this at all. Therefore, i have named the configure switch --with-aolserver3=AOL_INCLUDE_DIR where you have to specify the include directory.
Concerning the second problem, you wrote:
When configuring xotcl to build with a tcl which is not the system tcl, the configure step assumes the tclsh in the $PATH, which is a wrong assumption.
The right assumption would be to choose the tclsh located in the tclConfig.sh.
Doing this would ensure the builder will get the tclsh which is in the installation of tcl he/she specified.
well, can you be more specific, where this happens? XOTcl uses in configure.in SC_PROC_TCLSH and uses in all the Makefiles $TCLSH_PROG as far i can see. What version of xotcl are you working with?
-gustaf
Hi Gustaf...
On Mon, 5 Apr 2004 20:51:09 +0200 "Gustaf Neumann" neumann@wu-wien.ac.at wrote:
On Friday 02 April 2004 05:37, Jim Lynch wrote:
Hi,
Hi Jim, sorry for the delayed answer, i was last week on vacation.
Last month I reported three bugs in the configure step of the xotcl
you mean last week? well, last week is also last month, just to remove disambiguity, i have received no earlier mails from you.
build process. While I was reporting those bugs and for a few days after, I was working on my mail, and so turned off the list's replying to me at first.
Is there a different way to report bugs? Could someone tell me the status of these bugs? Would anyone like copies of the bug reports sent to them?
as uwe pointed out, we have since last week serious hardware problems on our webserver.
i have received four mails from concerning a) the aolserver, and b) tclsh without path.
concerning (a) you are right, determining to build with AOLserver from the `pwd` is not pretty, also the hardwired path to the AOLserver include directory. i have changed that right now. note, that making an aolserver module is only an issue for AOLserver 3.*, the AOLserver 4* series does not require this at all. Therefore, i have named the configure switch --with-aolserver3=AOL_INCLUDE_DIR where you have to specify the include directory.
Suggestion, howbout the prefix dir instead? That way, any time you add dependendency on another kind of thing, you already planned for the stem dir. Besides, if this switch is to represent the include dir, it is misnamed, and should be named something like --with-aolserver-inc=.
So if you said to aolserver, "./configure --prefix=/x/y ...", then you'd say to xotcl, "./configure --with-aolserver3=/x/y ..."
Concerning the second problem, you wrote:
When configuring xotcl to build with a tcl which is not the system tcl, the configure step assumes the tclsh in the $PATH, which is a wrong assumption.
The right assumption would be to choose the tclsh located in the tclConfig.sh.
Doing this would ensure the builder will get the tclsh which is in the installation of tcl he/she specified.
well, can you be more specific, where this happens? XOTcl uses in configure.in SC_PROC_TCLSH and uses in all the Makefiles $TCLSH_PROG as far i can see. What version of xotcl are you working with?
I'm using xotcl-1.2.0; my situation is I'm building using a tcl I built specifically for an aolserver4. It's not the system tcl and its bin dir is not in my path.
As far as I've been able to determine, the tclsh which is called has to be able to find the libxotcl thing. Apparantly, not every tclsh I have is able to do that, so I looked closely at the SC_PROG_TCLSH macro (having traced the problem down to that macro) and noticed that it doesn't try to use the tclsh specified in the supplied tclConfig.sh, which as far as I know is the only correct choice (should use the tclsh linked to the same libs that were used in the build process of xotcl, and that can find the modules).
The fix for this is easy, and a patch has already been sent to the list.
-gustaf
-Jim
-- Jam sessions community web site: http://jam.sessionsnet.org
Jim,
As far as I've been able to determine, the tclsh which is called has to be able to find the libxotcl thing. Apparantly, not every tclsh I have is able to do that, so I looked closely at the SC_PROG_TCLSH macro (having traced the problem down to that macro) and noticed that it doesn't try to use the tclsh specified in the supplied tclConfig.sh, which as far as I know is the only correct choice (should use the tclsh linked to the same libs that were used in the build process of xotcl, and that can find the modules).
This is not correct, and indicates a problem elsewhere in the xotcl make/test stuff. I see that it still uses the older TEA stuff though, which might be the core problem (SC_* macros were done away with a couple of years ago).
The TEA_PROG_TCLSH looks at TCL_BIN_DIR (specified in tclConfig.sh), then the exec_prefix, prefix, and finally the regular path. This is the right ordering, as it is better to find the installed version first. It's still based off the tclConfig.sh.
Jeff Hobbs, The Tcl Guy http://www.ActiveState.com/, a division of Sophos
On Tuesday 06 April 2004 16:06, Jim Lynch wrote:
concerning (a) you are right, determining to build with AOLserver from the `pwd` is not pretty, also the hardwired path to the AOLserver include directory. i have changed that right now. note, that making an aolserver module is only an issue for AOLserver 3.*, the AOLserver 4* series does not require this at all. Therefore, i have named the configure switch --with-aolserver3=AOL_INCLUDE_DIR where you have to specify the include directory.
Suggestion, howbout the prefix dir instead? That way, any time you add dependendency on another kind of thing, you already planned for the stem dir.
there might be cases, where the prefix of xotcl is not the same as the aoldirectory. On my system, i have for tcl and xotcl --prefix=/usr and for the aolserver (the default) /usr/local
Besides, if this switch is to represent the include dir, it is misnamed, and should be named something like --with-aolserver-inc=.
well. by using --with-aolserver3 you tell xotcl, that it should build the aolserver 3.* type c module, and you tell it at the same time, where to find the includes. therefor i think --with-aolserver3 is still better.
well, can you be more specific, where this happens? XOTcl uses in configure.in SC_PROC_TCLSH and uses in all the Makefiles $TCLSH_PROG as far i can see. What version of xotcl are you working with?
I'm using xotcl-1.2.0; my situation is I'm building using a tcl I built specifically for an aolserver4. It's not the system tcl and its bin dir is not in my path.
if you only want to build xotcl, you need no tclsh at all (tclsh is used only for doc generation, testing, installing). If you build for aolserver 4 you need in the minimal version # cd xotcl-1.2.0/unix ./configure --enable-threads \ --prefix=/usr/local/aolserver \ --with-tcl=/usr/src/tcl8.4.5/unix # make libxotcl1.2.so # make install-aol
everything including "make libxotcl1.2.so" should be fine without a tclsh. the "make install-aol" uses a tclsh to load xotcl (for a minor purpose, to rebuild the pkgIndex files). If you comment out the last line of the "libraries:" rule in unix/Makefile, you should be fine.
-gustaf
Hi Gustaf and group,
On Sat, 10 Apr 2004 22:52:39 +0200 "Gustaf Neumann" neumann@wu-wien.ac.at wrote:
On Tuesday 06 April 2004 16:06, Jim Lynch wrote:
(this is actually Gustaf talking here, I think)
Therefore, i have named the configure switch --with-aolserver3=AOL_INCLUDE_DIR where you have to specify the include directory.
Suggestion, howbout the prefix dir instead? That way, any time you add dependendency on another kind of thing, you already planned for the stem dir.
there might be cases, where the prefix of xotcl is not the same as the aoldirectory. On my system, i have for tcl and xotcl --prefix=/usr and for the aolserver (the default) /usr/local
Besides, if this switch is to represent the include dir, it is misnamed, and should be named something like --with-aolserver-inc=.
well. by using --with-aolserver3 you tell xotcl, that it should build the aolserver 3.* type c module, and you tell it at the same time, where to find the includes. therefor i think --with-aolserver3 is still better.
Well, of course I meant the aolserver prefix :) The includes should be right there, in <the-aolserver-prefix>/include. Do you not also need the aolserver libs? It's feasible you might in the future.
well, can you be more specific, where this happens? XOTcl uses in configure.in SC_PROC_TCLSH and uses in all the Makefiles $TCLSH_PROG as far i can see. What version of xotcl are you working with?
I'm using xotcl-1.2.0; my situation is I'm building using a tcl I built specifically for an aolserver4. It's not the system tcl and its bin dir is not in my path.
if you only want to build xotcl, you need no tclsh at all (tclsh is used only for doc generation, testing, installing). If you build for aolserver 4 you need in the minimal version # cd xotcl-1.2.0/unix ./configure --enable-threads \ --prefix=/usr/local/aolserver \ --with-tcl=/usr/src/tcl8.4.5/unix # make libxotcl1.2.so # make install-aol
everything including "make libxotcl1.2.so" should be fine without a tclsh. the "make install-aol" uses a tclsh to load xotcl (for a minor purpose, to rebuild the pkgIndex files). If you comment out the last line of the "libraries:" rule in unix/Makefile, you should be fine.
See though, the whole point is not having to edit anything... Having to do so implies C-based clue, which while you could assume it 20 years ago, is just not the case among unix-alike users anymore, and note carefully that this group especially includes people who want to use xotcl.
I want to give them at least two things:
one, an ability to compile xotcl in more situations than is now possible due to the fact that the configure process only half-works;
and two, where it isn't possible in a particular situation, I want to issue a meaningful error message so that they will know the real problem.
One requirement for this, is to find problems as early as when and where they originally occured; it is there that the most information on whatever problem might exist would be available: once you throw the error up the call chain, you lose everything in the stack frame... if an error which should stop the configure process is overlooked, the configure step could appear successful, and might stop the make or some step the make invokes.
-gustaf
-Jim
-- Jam sessions community web site: http://jam.sessionsnet.org
On Sunday 11 April 2004 07:24, Jim Lynch wrote:
well. by using --with-aolserver3 you tell xotcl, that it should build the aolserver 3.* type c module, and you tell it at the same time, where to find the includes. therefor i think --with-aolserver3 is still better.
Well, of course I meant the aolserver prefix :) The includes should be right there, in <the-aolserver-prefix>/include. Do you not also need the aolserver libs? It's feasible you might in the future.
ok. as far as i remember, there is no need to use the aolserver lib, since the external symbols are resolved against the running binary. i have changed this to --with-aolserver3=AOL_SERVER_DIR
everything including "make libxotcl1.2.so" should be fine without a tclsh. the "make install-aol" uses a tclsh to load xotcl (for a minor purpose, to rebuild the pkgIndex files). If you comment out the last line of the "libraries:" rule in unix/Makefile, you should be fine.
See though, the whole point is not having to edit anything...
the suggestion to remove the line was a temporary fix to keep you going and certainly not a permanent fix
Having to do so implies C-based clue, which while you could assume it 20 years ago, is just not the case among unix-alike users anymore, and note carefully that this group especially includes people who want to use xotcl.
we have the same opinion about the goals, no need to argue.
you have certainy a complex setup, which is not the setup of an average user. i have currently on my system 2 tcl versions installed and a aolserver4, and i have not seen the problems you reported, otherwise i would have fixed it. One can only fix problems that you are aware off. your comments are very helpful raise this awarensss and to improve the system
-gustaf
-
Gustaf Neumann -
Jeff Hobbs -
Jim Lynch -
Uwe Zdun